[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 #33 from Frank Barrus <frankbarrus_sw at shaggy dot cc> ---
(In reply to Carlos O'Donell from comment #32)
> I'm working through the review for this issue.

FYI, I'm currently testing a different pthreads fix for this issue that does it
without the suggested "broadcast" solution that some distros appear to be
adopting for now.  It also eliminates the need for the signal-stealing handling
that was leading to the bug in the first place.  While broadcasting might work
as a temporary workaround solution for correctness, it certainly has
performance implications.

My previous workaround I mentioned (detecting the lost wakeup state or the
potential for it after calling pthread_cond_wait/pthread_cond_timedwait and
pthread_cond_signal) is not showing any cases detected when this new pthreads
fix is applied.  However, when I run with the broadcast fix instead, it still
detects cases that look like a potential lost wakeup.  I'm suspecting that
those are just due to the state the condvar is temporarily being left in, and
that all waiters are actually being woken up by the broadcast and just racing
against my detection code which is catching the intermediate state, but it
makes me wonder if there's still a rare edge case the broadcast solution isn't
actually fixing and which could still get stuck.  (consider all threads that
are not actually blocked and are outside the g_refs counted region and possibly
have been pre-empted so they'll make their attempt to grab g_signals at a later
time)  When I was running these tests my other post-detection logic still
contained its fix to send extra signals as necessary also.  I'll have to re-run
that as detection-only and no fix to see if it would have gotten stuck, but my
priority has been the work on the new pthreads fix instead, not proving the
correctness of the fix that uses broadcast.

So far the testing for my new fix is looking good for both correctness and
performance, but of course there are many correctness issues to properly and
thoroughly test.  I'm hoping to be able to post a patch in the near future.

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