Messages in this thread | | | Subject | Re: spin_unlock optimization(i386) | Date | Wed, 24 Nov 1999 16:45:20 -0800 | From | Erich Boleyn <> |
| |
> 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, ¤t->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, ¤t->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/
| |