Re: spin_unlock optimization(i386)

Erich Boleyn (esboleyn@ichips.intel.com)
Wed, 24 Nov 1999 16:45:20 -0800

> This should be multiprocessor safe 8), I copied these lines from the
> current kernel.
>
> CPU1:
> add_wait_queue(&WAKE_LIST)
> /* smp safe function, adds us to WAKE_LIST */
> xchg(TASK_UNINTERRUITPBLE, &current->state);
> /* use xchg to force memory ordering */
> if(inode->i_state & I_LOCK) {
> schedule();
> /* this function only returns if current->state
> is TASK_RUNNING */
> }
> printk(KERN_DEBUG "no lock-up!\n");
>
> CPU2:
> inode->i_state &= ~I_LOCK;
> /* we are the only thread that has write access to
> this variable, no "lock;" required */
>
> wake_up(&WAKE_LIST);
> /* smp safe function, sets current->state of all
> entries in WAKE_LIST back to TASK_RUNNING */
>
>
> I think that Andrea want's to know if he could replace the xchg with a
> normal "mov" instruction.
> "smp safe function" means that they begin with a spin_lock(), ie
> "lock;bts"

If I understand what you're doing, there appears to be a race after
"add_wait_queue(&WAKE_LIST)" and before "xchg(TASK_UNINTERRUPTIBLE,
&current->state)" where "wake_up(&WAKE_LIST)" may have executed and set
our "current->state"...

...so, maybe I'm confused, but it looks like you may end up with either
"TASK_INTERRUPTIBLE" or "TASK_RUNNING".

This is quite independent of the use of "xchg" to set "current->state" in
the list for CPU1. That is arguably semantically equivalent to any old
store into "current->state".

I'd want to be sure that any changes to our "current->state" were made
before "add_wait_queue(&WAKE_LIST)" to be sure no such race was possible.
So, the safe thing for CPU1 seems to be (again, assuming I've understood
correctly):

current->state = TASK_UNINTERRUPTIBLE;
add_wait_queue(&WAKE_LIST);
if (inode->i_state & I_LOCK) {
schedule();
/* this function only returns if current->state
is TASK_RUNNING */
}

Erich Boleyn
PMD IA32 Architecture
Intel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/