[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 #18 from Rich Felker <bugdal at aerifal dot cx> 2012-09-19 17:23:20 UTC ---
> I'm not aware of any requirement that pthread_cond_signal should block until a
> waiter has actually woken up. (Your test case relies on it to not block, so

Do you mean "should block" or "should not block"? POSIX's definition of threads
has general language that requires that forward process be possible, and
blocking in pthread_cond_signal until a waiter actually wakes up (including
acquiring the mutex) would be non-conformant; in fact it would be a guaranteed
deadlock.

> that it can send out multiple signals while holding the mutex, right?)  I'm

It is definitely required that pthread_cond_signal can be called more than
once.

> also not aware of any ordering requirement wrt. waiters (i.e., fairness).  If
> you combine both, you will see that the behavior you observe is a valid
> execution.

Nobody has asked for glibc to satisfy any fairness constraint. The standard
says it shall unblock at least one thread that "has blocked" on the condition
variable, not that it can randomly fail to do so or instead send the unblocking
event into the future to be consumed by another thread that has not yet blocked
but is about to block (after the signaling thread unlocks the mutex). The claim
in this bug report is that glibc is randomly failing (race condition) to
unblock ANY of the threads that have blocked. A viable mechanism of how this
failure is occurring has also been proposed.

You are free to test this hypothesis and claim that this is not what's
happening, or provide a rigorous proof that it couldn't happen. But what you've
been doing so far is mischaracterizing the bug report and my comments as a
complaint about scheduling fairness, which they are not, and this is getting
really frustrating...

-- 
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.