This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #20 from Torvald Riegel <triegel at redhat dot com> 2012-09-20 10:43:00 UTC ---
(In reply to comment #18)
> > 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"?

"Block", as I wrote.

> 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's what I'm pointing out.  Glad you agree on this point.

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

Glad you agree on that too. Now please just think about the combination of both
for a minute.

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

You assume that only some threads can count as blocked, which is not guaranteed
by the standard. Signalers are not required to have finished delivering the
signal when they return.  Thus, the scope of which threads are blocked can be
longer than you assume.  Combined with no fairness guarantee this exactly
allows the behavior that we're talking about here.

The standard indeed doesn't talk about the "future".  It doesn't make a sort of
lower-bound requirement on which threads have to be considered blocked, but no
upper bound.  If you think there's an upper bound, please point the requirement
in the standard.  If there is no required upper bound, it's up to the
implementation how to deal with that.

> The claim
> in this bug report is that glibc is randomly failing (race condition) to
> unblock ANY of the threads that have blocked.

No.  The claim is that the "wrong" threads have been unblocked, where "wrong"
is based on an assumption on ordering or an upper-bound-on-blocked-threads
guarantee that is not required by the standard.

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

I have argued that this is allowed behavior, because there is no requirement
that conflicts with it, and pointed out why.  You haven't done that; just
because you think the standard should have a certain requirement doesn't mean
it actually has.

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

I've never talked about "scheduling fairness" (assuming you mean the OS
scheduler here), just about fairness regarding which thread gets wakened. So
much for mischaracterization, eh?

Sorry to hear that you feel frustrated, but I'd like to point out that I don't
think that I'm the cause for this.

Bottom line: In my opinion, this is not a bug.  However, it might be good to
explain why this behavior is allowed (e.g., somewhere in the docs or on the
wiki), so that this doesn't surprise other users.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]