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

["triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #17 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Torvald Riegel from comment #16)
> (In reply to comment #15)
> > Created attachment 6639 [details]
> > Test case with explicit happens-before logic rather than usleep
> > 
> > As requested, I've attached a version of the test case that uses the lock,
> > barriers and atomic instructions to enforce happens-before.

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.

> > Why I think this is a bug: my reading of the sentence "The
> > pthread_cond_signal() function shall unblock at least one of the threads that
> > are blocked on the specified condition variable cond (if any threads are
> > blocked on cond)." is that it only affects threads that "are blocked" at the
> > time pthread_cond_signal() is called, not those that call pthread_cond_wait
> > afterwards.

In your test case (and ignoring spurious wake-ups), both C and D start to wait
on the condvar before the signal is issued.  Thus, they are both eligible to
consume the signal, as is A (C and D enter the barrier while having acquired
cs_lock, and B acquires the cs_lock after it exits from both barriers; C and D
release cs_lock atomically with starting to wait on cs_cond; B signals after
having acquired cs_lock, so C and D waiting happens before B's signal).

Therefore, I'm closing this as invalid (because the test complains about
correct behavior).

The new condvar that is now committed upstream fixes all the bugs we are aware
of (see Bug 13165).

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