[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 #38 from Frank Barrus <frankbarrus_sw at shaggy dot cc> ---
Created attachment 13419
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13419&action=edit
proposed lost wakeup fix with g_signals relative to g1_start and no signal
stealing

Here is my proposed solution to the lost wakeup problem.  Further details are
in the attachment, but the high level summary is that it turns g_signals[] into
an always-advancing value for each new G1 group (using the low 31 bits of the
current g1_start value as the relative base for the signal count), thus
avoiding aliasing issues from G1/G2 re-use and avoiding A/B/A issues on the
signal count.  This eliminates the signal stealing, as well as the need to
block and wait for G1 to fully quiesce when signaling.  This provides a
performance benefit at the same time as fixing the lost wakeup issue, since
pthread_cond_signal no longer has to wait for remaining G1 waiters to wake up
and run, or for pre-empted waiter threads to resume running.  (the latter was
introducing rather high latencies for signaling when waiters got pre-empted)

My own testing (in a multi-core setup that was showing the lost wakeup quite
frequently) has not shown any problems yet, but I'd welcome others to try the
patch and give their feedback/results.  This hasn't been through TLA+ testing
yet.

Note that this patch is against the current master version of glibc/pthreads. 
If you need to patch an older version, make sure the additional futex waits in
pthread_cond_wait_common() all have their "0" value changed to "signals".

This patch could still use some additional cleanup of the comments and some
minor optimizations, but I'd like to get feedback on it (both the specific
patch and the general path this solution is taking) first before polishing it
further.

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