Messages in this thread | | | Date | Tue, 29 Apr 2008 17:13:22 +0400 | From | Oleg Nesterov <> | Subject | Re: futex code and barriers |
| |
On 04/29, Peter Zijlstra wrote: > Hi All, > > While looking through the futex code I stumbled upon the following bit: > > kernel/futex.c: > > /* add_wait_queue is the barrier after __set_current_state. */
As for me, the comment is very confusing at least.
> __set_current_state(TASK_INTERRUPTIBLE); > add_wait_queue(&q.waiters, &wait);
Not sure I understand this code, but probably it is correct.
Yes, add_wait_queue() is not a barrier, and both __set_current_state() and the "!plist_node_empty()" check below can leak into the add_wait_queue's critical section.
But wake_futex()->wake_up_all() has to lock/unlock the same q->lock, so I think we can't miss the event.
IOW, when wake_futex()->wake_up_all() takes q->lock, it must see TASK_INTERRUPTIBLE.
If wake_futex() takes q->lock before us, we must see the result of plist_del() after add_wait_queue() (more precisely, after add_wait_queue()->spin_lock(q->lock).
But I'd like to know maintainer's opinion, I don't trust myself ;)
Oleg.
| |