From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4169 invoked by alias); 19 Sep 2012 15:15:20 -0000 Received: (qmail 4156 invoked by uid 22791); 19 Sep 2012 15:15:18 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Sep 2012 15:15:05 +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: Wed, 19 Sep 2012 15:15: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: CC 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/msg00170.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13165 Torvald Riegel changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |triegel at redhat dot com --- Comment #16 from Torvald Riegel 2012-09-19 15:15:02 UTC --- 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 that it can send out multiple signals while holding the mutex, right?) I'm 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. (In reply to comment #5) > 4) After the main thread has sent all signals, it starts waiting for at least > two waiters to block on the second wait. This is facilitated by a counter of > the threads that have reached the second wait and one more auxiliary cond var. And here you do block for waiters to have consumed a signal (i.e., for a call to pthread_cond_signal to have finished its work and delivered a signal), but you do this just for two of the signals / calls. If you do not want to wait for all signals being delivered yet still need a fair cond var implementation, I suggest either (1) building your own (e.g., you could build something like a simple queue lock based on pthread mutexes or cond vars) or (2) propose an addition of a fair cond var to glibc or the respective standards bodies. -- 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.