From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4355 invoked by alias); 20 Sep 2012 10:43:24 -0000 Received: (qmail 4315 invoked by uid 48); 20 Sep 2012 10:43:01 -0000 From: "triegel at redhat dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting Date: Thu, 20 Sep 2012 10:43:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: triegel at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-09/txt/msg00179.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13165 --- Comment #20 from Torvald Riegel 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.