Re: Futex queue_me/get_user ordering

[Jamie Lokier]

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/