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

bugdal at aerifal dot cx sourceware-bugzilla@sourceware.org
Wed Sep 19 03:21:00 GMT 2012


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

--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> 2012-09-19 03:21:17 UTC ---
> If so, please quote the specification or manpage that this violates.  At the
> very least, we need this for documentation purposes.

"The pthread_cond_signal() function shall unblock at least one of the threads
that are blocked on the specified condition variable cond (if any threads are
blocked on cond)."

Source:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_signal.html

If it's provable that threads 1 through N are waiting on a condition variable C
when thread X calls pthread_cond_signal on C N times, then in order to satisfy
the above, all N must be unblocked. If another waiter arriving after the N
signals consumes any of the signals and prevents those N from being blocked,
then the above cited requirement has been violated; at least one call to
pthread_cond_signal did not "unblock at least one of the threads that are
blocked".

I admit the test case is poorly written and rather obfuscated, but I believe
that it is showing a bug of this nature. Contrary to yours and Mr. Dreppers
characterizations, this is NOT A FAIRNESS ISSUE. No complaint about fairness
has been made by myself or the original poster of the bug. If the bug really
exists in the described form -- and it seems to me that it does, although I'd
like to find a simpler test case -- then it's an issue of the interface
violating its contract.

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



More information about the Glibc-bugs mailing list