[Bug nptl/25847] pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing

["frankbarrus_sw at shaggy dot cc" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #29 from Frank Barrus <frankbarrus_sw at shaggy dot cc> ---
I should add one more thing about my workaround fix:

Although it's currently implemented as a post-fix wrapper on
pthread_cond_signal() as well as after waiting, it doesn't need to be.  That's
just because it also tries to detect the bug condition *before* the lost wakeup
occurs whenever possible.  Practically speaking, that almost never occurs
anyway since wrefs usually leaves the state ambiguous until the last waiter
exits, and then most of the time, the last exiting G1 waiter is the one who
ends up detecting it first, whether it's before or after the signal was lost.  
Also, checking the condvar in this way in pthread_cond_signal() assumes you
know for sure that the wrapper code is being called while the mutex is held,
which can't be guaranteed in a general-purpose fix for pthread_cond_signal.

So the post-fix check I'm doing could be done instead entirely from the
wrappers for pthread_cond_wait/pthread_cond_timedwait().  That also means it
could go in the common signal wait code, after the mutex is re-acquired.  As
long as the common cases can bail out of the checks fast, there should be
minimal overhead.  The only heavyweight cases will be when it actually detects
that signals have already been lost, or the condvar is in a state that will
lose the next signal.

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