[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=13165

--- Comment #27 from Rich Felker <bugdal at aerifal dot cx> 2012-09-20 18:39:10 UTC ---
I disagree strongly that the spec even allows Torvald's interpretation.
Torvald's claim is essentially that an implementation can consider an
unspecified set of threads beyond those which "have blocked" per the
specification of pthread_cond_wait to also "have blocked" on the condition. Not
only is there no language in the standard to support this (the only definition
of "blocked" on a condition variable is the one we've cited); it would also
make the specification of pthread_cond_signal completely useless, as the "at
least one" could always be taken to mean "the one invisible thread your
application can't see that's always blocked on every possible condition
variable". This is the pinnacle of absurdity in an attempt to language-lawyer
out of fixing a bug.

The fact of the matter is that POSIX, along with common sense and the entire
intended usage of condition variables, requires pthread_cond_signal to unblock
at least one thread that "has blocked", in the sense of the blocking that
happens atomically with unlocking the mutex as described in the specification
of pthread_cond_wait.

The situation we're looking at here is that the authors of NPTL came up with a
clever hack to reduce spurious wakeups in pthread_cond_wait, but failed to
realize the hack was broken in some corner cases, and now Torvald is unwilling
to admit that the hack is broken and take it out.

It should also be noted that I have been unable to demonstrate any case where
NPTL's hack to prevent spurious wakeups actually has any positive effect. A
while back I wrote a test program to hammer condition variables and look for
spurious wakeups, and I could not generate any with either NPTL's buggy
implementation OR with musl's implementation which does not use any similar
hack and does not suffer from this bug. Thus, in addition to being wrong and
broken, it's my conclusion, unless anybody else can produce evidence to the
contrary, that the hack is also useless (does not have the intended effect of
improving performance).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.