fix ABA race in cond vars, improve them overall
authorRich Felker <dalias@aerifal.cx>
Sat, 24 Sep 2011 02:58:45 +0000 (22:58 -0400)
committerRich Felker <dalias@aerifal.cx>
Sat, 24 Sep 2011 02:58:45 +0000 (22:58 -0400)
commit97c5b5a87c3d9df54278e1073d6177f77536bd32
treef93711dd0ab36697fb5a56d81b4f439a7b8eca68
parentc41a76f58ce0238172effe982f2cee7bbd2a60a4
fix ABA race in cond vars, improve them overall

previously, a waiter could miss the 1->0 transition of block if
another thread set block to 1 again after the signal function set
block to 0. we now use the caller's thread id as a unique token to
store in block, which no other thread will ever write there. this
ensures that if block still contains the tid, no signal has occurred.
spurious wakeups will of course occur whenever there is a spurious
return from the futex wait and another thread has begun waiting on the
cond var. this should be a rare occurrence except perhaps in the
presence of interrupting signal handlers.

signal/bcast operations have been improved by noting that they need
not avoid inspecting the cond var's memory after changing the futex
value. because the standard allows spurious wakeups, there is no way
for an application to distinguish between a spurious wakeup just
before another thread called signal/bcast, and the deliberate wakeup
resulting from the signal/bcast call. thus the woken thread must
assume that the signalling thread may still be waiting to act on the
cond var, and therefore it cannot destroy/unmap the cond var.
src/thread/pthread_cond_broadcast.c
src/thread/pthread_cond_signal.c
src/thread/pthread_cond_timedwait.c