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

["triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

Torvald Riegel <triegel at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |triegel at redhat dot com

--- Comment #16 from Torvald Riegel <triegel at redhat dot com> 2012-09-19 15:15:02 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
that it can send out multiple signals while holding the mutex, right?)  I'm
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.

(In reply to comment #5)
> 4) After the main thread has sent all signals, it starts waiting for at least
> two waiters to block on the second wait. This is facilitated by a counter of
> the threads that have reached the second wait and one more auxiliary cond var.

And here you do block for waiters to have consumed a signal (i.e., for a call
to pthread_cond_signal to have finished its work and delivered a signal), but
you do this just for two of the signals / calls.

If you do not want to wait for all signals being delivered yet still need a
fair cond var implementation, I suggest either (1) building your own (e.g., you
could build something like a simple queue lock based on pthread mutexes or cond
vars) or (2) propose an addition of a fair cond var to glibc or the respective
standards bodies.

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