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

["mihaylov.mihail at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #4 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2011-09-22 22:21:10 UTC ---
Thank you for taking an interest in this issue.

(In reply to comment #3)
> Can you explain how you know (2) is completed before (3) occurs, in your
> scenario? If there's no synchronization to order these steps, then isn't it
> possible that one or more of the signals happens after a thread from group B is
> waiting?

Basically, because we are holding the mutex when signaling, we can tell exactly
which threads started waiting after we finished sending the first N signals.
These are the threads that I call "group B", so by this definition they cannot
start waiting before all signals from step 2 have been sent.

What I'm trying to say is that the scenario is not a test case, but rather a
hypothetical  sequence of events that can happen and can be observed, so it
doesn't specify why exactly no new threads started waiting during step 2, it
just says what happened. This left some ambiguity in my description.

One way to resolve this ambiguity is to say that if during step 2 some threads
acquired the mutex and called pthread_cond_wait(), they should be counted
towards group A.

Another way is to change step 2 and say that the signaling thread acquired the
mutex, sent N signals and only then released the mutex, without releasing it
between the signals.

The second way seems simpler and will probably make the race more likely, but
the first is closer to what I actually observed.

> If you have a minimal self-contained test case for the issue, I'd be interested
> in seeing it.

I don't have such a test case, but I'll try to find time in the next days to
write one and attach it to the bug.

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