lkml.org 
[lkml]   [1999]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: spin_unlock optimization(i386)
Date
From

> 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.094 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site