[Bug nptl/12875] pthread_cond_timedwait can steal the wakeup of slower thread in pthread_cond_wait

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

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

--- Comment #13 from Rich Felker <bugdal at aerifal dot cx> 2012-09-19 17:30:17 UTC ---
> It says that those have blocked, not that those are exactly the ones that can
> be considered to have blocked (i.e., the first "if" in what you quoted is an
> "if", not an "iff" (if and only if)).

Short of an implementation-defined extension that must be documented, there is
no way a waiter can block on a condition variable short of calling
pthread_cond_wait or pthread_cond_timedwait. Under your proposed
interpretation, pthread_cond_signal would be useless; in order to be useful, at
least one thread needs to unblock, and the application has to be able to know
(based on its knowledge of which threads have blocked) that the signal will
unblock a thread that will allow the program to make forward progress. This of
course requires that every thread which has blocked on the condition at the
time of pthread_cond_signal be a thread whose unblocking would allow forward
progress; if other threads have blocked on the same condition, then it's an
application bug.

As I stated before, I'm not sure this bug report is valid and I was thinking of
the other one. But there is a real issue here that the implementation needs to
take care to satisfy.

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