Re: Futex queue_me/get_user ordering

From: Jamie Lokier
Date: Sun Nov 14 2004 - 21:03:25 EST


Hidetoshi Seto wrote:
> >So I don't know if NPTL is buggy, but the pseudo-code given in the bug
> >report is (because of unconditional wake++), and so is the failure
> >example (because it doesn't use a mutex).
>
> from glibc-2.3.3(RHEL4b2):
>
> 31 int
> 32 __pthread_cond_signal (cond)
> 33 pthread_cond_t *cond;
> 34 {
> 35 /* Make sure we are alone. */
> 36 lll_mutex_lock (cond->__data.__lock);
> 37
> 38 /* Are there any waiters to be woken? */
> 39 if (cond->__data.__total_seq > cond->__data.__wakeup_seq)
> 40 {
> 41 /* Yes. Mark one of them as woken. */
> 42 ++cond->__data.__wakeup_seq;
> 43 ++cond->__data.__futex;
> 44
> 45 /* Wake one. */
> 46 lll_futex_wake (&cond->__data.__futex, 1);
> 47 }
> 48
> 49 /* We are done. */
> 50 lll_mutex_unlock (cond->__data.__lock);
> 51
> 52 return 0;
> 53 }
>
> Ingo, is this buggy?
>
> We should start again with a question:
> Is this a kernel's bug or NPTL's bug?

Third possibility: your test is buggy. Do you actually use a mutex in
your test when you call pthread_cond_wait, and does the waker hold it
when it calls pthread_cond_signal?

If you don't use a mutex as you are supposed to with condvars, then it
might not be a kernel or NPTL bug. I'm not sure if POSIX-specified
behaviour is defined when you use condvars without a mutex.

If you do use a mutex (and you just didn't mention it), then the code
above is not enough to decide if there's an NPTL bug. We need to look
at pthread_cond_wait as well, to see how it does the "atomic" wait and
mutex release.

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