[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

--- Comment #30 from Torvald Riegel <triegel at redhat dot com> 2012-09-21 08:03:55 UTC ---
(In reply to comment #27)
> I disagree strongly that the spec even allows Torvald's interpretation.
> Torvald's claim is essentially that an implementation can consider an
> unspecified set of threads beyond those which "have blocked" per the
> specification of pthread_cond_wait to also "have blocked" on the condition.

No it's not unspecified. The specification requires a lower bound on this set.
If you think that this is not just a lower bound, argue against the reasons I
gave for this, don't just repeat your opinion here, please.

> Not
> only is there no language in the standard to support this (the only definition
> of "blocked" on a condition variable is the one we've cited);

Which is the lower bound. And this is a meaningful requirement, and provides
cond vars that are useful.

> it would also
> make the specification of pthread_cond_signal completely useless, as the "at
> least one" could always be taken to mean "the one invisible thread your
> application can't see that's always blocked on every possible condition
> variable".

You do see that there is a difference between this and requiring "blocked" but
not requiring an upper bound based on happens before?

> This is the pinnacle of absurdity in an attempt to language-lawyer
> out of fixing a bug.

Frankly, I don't care what you think that my motivations are. And I also don't
speculate here about your motivations, nor about your abilities to distinguish
an implication from equivalence. So please stop making such statements.

What I care about is whether this is indeed a bug or not.  Taking this question
to the standards body for clarification is the right way to go if people think
that the standard should require something else, or be more precise is what is
allowed or not.

> The fact of the matter is that POSIX, along with common sense and the entire
> intended usage of condition variables, requires pthread_cond_signal to unblock
> at least one thread that "has blocked", in the sense of the blocking that
> happens atomically with unlocking the mutex as described in the specification
> of pthread_cond_wait.

That doesn't conflict with what I said. You mention an entirely different point
here.

> The situation we're looking at here is that the authors of NPTL came up with a
> clever hack to reduce spurious wakeups in pthread_cond_wait, but failed to
> realize the hack was broken in some corner cases, and now Torvald is unwilling
> to admit that the hack is broken and take it out.

See above. Aside from this being impolite, speculation like this does not
belong in a bug report.

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