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

["stephen.dolan at cl dot cam.ac.uk" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #19 from Stephen Dolan <stephen.dolan at cl dot cam.ac.uk> ---
(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.

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]

The program hangs at this point, and no other output is produced. Control never
returns from pthread_cond_wait in thread A.

I have not yet tested this on more recent glibc, so it's possible that this has
been fixed. Before trying other versions, though, I'd like to know whether you
think this output is correct.

The messages are printed only when holding the lock, so the happens-before
relation totally orders the lines of output. As you've mentioned, signal #2 can
go to any of the waiters (A, B or C) with no guarantee of fairness, and
spurious wakeups can occur at any moment.

However, when signal #1 is sent, only A is waiting. Threads B and C have not
started. The fact that this signal does not cause A to wake seems like a bug.

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