This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting
- From: "mihaylov.mihail at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 20 Sep 2012 19:48:25 +0000
- Subject: [Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting
- Auto-submitted: auto-generated
- References: <bug-13165-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13165
--- Comment #28 from Mihail Mihaylov <mihaylov.mihail at gmail dot com> 2012-09-20 19:48:25 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.
Yes, that's what he claims.
> 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);
Yes, there is no language to support it, but I must admit that there is also no
language to explicitly prevent it, even though I too consider this
interpretation completely unreasonable as I tried to explain several times.
Anyway, this whole dispute has been reduced to the question of which threads
are eligible for wakeup, so I've taken the liberty to post a clarification
request to the Austin Group, asking them to add explicit text explaining which
threads should be considered blocked with respect to a pthread_cond_signal()
call. The clarification request is at
http://austingroupbugs.net/view.php?id=609. Torvald, please correct me if have
inadvertently misrepresented your position.
--
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.