From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18780 invoked by alias); 28 Sep 2011 16:06:59 -0000 Received: (qmail 18765 invoked by uid 22791); 28 Sep 2011 16:06:57 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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, 28 Sep 2011 16:06:40 +0000 From: "bugdal at aerifal dot cx" 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, 28 Sep 2011 16:06: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: bugdal at aerifal dot cx 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: 2011-09/txt/msg00134.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13165 --- Comment #14 from Rich Felker 2011-09-28 16:06:21 UTC --- I think it's clear that the usage you describe needs to be supported. Nowhere does the standard state that predicate must be a pure function of the shared (mutex-protected) state, or that it even need to depend on the shared state whatsoever. For example, this is a valid albeit potentially stupid use of cond variables: Thread 1: Lock mutex. Create thread 2. Wait on cond var. Unlock mutex. Continue with other work. Thread 2: Lock mutex. Signal cond var. Unlock mutex. Continue with other work. There is no guarantee that thread 1 will actually block until thread 2 starts and signals (it could have a spurious wakeup), but there is a guarantee that the signal will cause a wakeup if one has not already occurred. Naturally this example is not analogous to your test (there's nobody else using the cond var), but the point is that it's valid to use cond vars even without predicates. If you read the language of the standard, which is in terms of threads currently blocked rather than predicates, it's clear. By the way, assuming spurious wakeups are rare, my above "stupid" use of cond vars may actually be an efficient way to roughly synchronize typical start times of parallel calculations, perhaps useful in benchmarks or in tweaking cache utilization for a particular machine. Barriers would probably be more appropriate, however. -- 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.