[Bug nptl/12875] pthread_cond_timedwait can steal the wakeup of slower thread in pthread_cond_wait

[triegel at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12875

--- Comment #20 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Stephen Dolan from comment #19)
> (In reply to Torvald Riegel from comment #17)
> > The use of pthread_cond_wait is still wrong, because you expect it wake-ups
> > to reveal an ordering -- but spurious wake-ups are allowed.  In the general
> > case, you should always put pthread_cond_wait in a loop and check an actual
> > flag that is set before pthread_cond_signal is called.  Otherwise, you are
> > just using the condvar to optimize how you wait.
> 
> I have just added a simplified version of martin's test case, which uses
> pthread_cond_wait in this textbook style but still exhibits the strange
> behaviour.

That test is better.  However, the test is not guaranteed to terminate because
C would consume the signal that both B and C are allowed to consume. 
Furthermore, I know what you're trying to do with the sleep in the signal
handler, but is sleep() actually allowed in a handler?

> On my machine (Ubuntu 16.04, glibc 2.23), it produces this output:
> 
>     A waiting
>     signal #1 sent to waiters: a=1, b=0, c=0
>     B waiting
>     C waiting
>     signal #2 sent to waiters: a=1, b=1, c=1
>     B woke
>     C: timedwait returned [Success]

This execution should not happen.  B and C consume the two signals (C doesn't
time out), but A should be woken in any case.

> I have not yet tested this on more recent glibc, so it's possible that this
> has been fixed.

Please do test it with a current version of glibc.  This behavior (ie, that
more recent waiting threads could "steal" a signal from earlier waiting
threads) is exactly why we needed a new condvar algorithm.

-- 
You are receiving this mail because:
You are on the CC list for the bug.