public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-13165-131-9k20bHk8Sr@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-13165-131@http.sourceware.org/bugzilla/> http://sourceware.org/bugzilla/show_bug.cgi?id=13165 --- Comment #14 from Rich Felker <bugdal at aerifal dot cx> 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.
next prev parent reply other threads:[~2011-09-28 16:06 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-09-07 19:15 [Bug nptl/13165] New: " mihaylov.mihail at gmail dot com 2011-09-21 9:12 ` [Bug nptl/13165] " mihaylov.mihail at gmail dot com 2011-09-21 18:19 ` bugdal at aerifal dot cx 2011-09-21 22:29 ` bugdal at aerifal dot cx 2011-09-22 22:21 ` mihaylov.mihail at gmail dot com 2011-09-25 21:33 ` mihaylov.mihail at gmail dot com 2011-09-25 21:44 ` mihaylov.mihail at gmail dot com 2011-09-26 9:27 ` mihaylov.mihail at gmail dot com 2011-09-26 16:20 ` bugdal at aerifal dot cx 2011-09-27 10:10 ` mihaylov.mihail at gmail dot com 2011-09-27 10:13 ` mihaylov.mihail at gmail dot com 2011-09-28 2:07 ` bugdal at aerifal dot cx 2011-09-28 2:08 ` bugdal at aerifal dot cx 2011-09-28 9:03 ` mihaylov.mihail at gmail dot com 2011-09-28 16:06 ` bugdal at aerifal dot cx [this message] 2011-09-28 21:00 ` mihaylov.mihail at gmail dot com 2012-09-19 15:15 ` triegel at redhat dot com 2012-09-19 15:21 ` triegel at redhat dot com 2012-09-19 17:23 ` bugdal at aerifal dot cx 2012-09-20 10:28 ` mihaylov.mihail at gmail dot com 2012-09-20 10:43 ` triegel at redhat dot com 2012-09-20 11:05 ` mihaylov.mihail at gmail dot com 2012-09-20 11:23 ` triegel at redhat dot com 2012-09-20 11:58 ` triegel at redhat dot com 2012-09-20 12:46 ` mihaylov.mihail at gmail dot com 2012-09-20 12:49 ` mihaylov.mihail at gmail dot com 2012-09-20 16:21 ` triegel at redhat dot com 2012-09-20 18:39 ` bugdal at aerifal dot cx 2012-09-20 19:48 ` mihaylov.mihail at gmail dot com 2012-09-20 20:31 ` bugdal at aerifal dot cx 2012-09-21 8:04 ` triegel at redhat dot com 2012-09-21 8:05 ` siddhesh at redhat dot com 2012-09-21 8:54 ` bugdal at aerifal dot cx 2012-09-21 15:45 ` triegel at redhat dot com 2012-10-18 6:26 ` mihaylov.mihail at gmail dot com 2012-10-18 12:25 ` bugdal at aerifal dot cx 2012-10-24 20:26 ` triegel at redhat dot com 2012-10-25 4:08 ` bugdal at aerifal dot cx 2013-01-19 16:19 ` scot4spam at yahoo dot com 2014-02-16 17:45 ` jackie.rosen at hushmail dot com 2014-03-28 9:23 ` dancol at dancol dot org 2014-05-28 19:44 ` schwab at sourceware dot org 2014-06-27 12:09 ` fweimer at redhat dot com 2014-08-18 21:22 ` triegel at redhat dot com 2014-08-18 21:42 ` bugdal at aerifal dot cx 2015-08-26 15:29 ` kkersten at cray dot com 2017-01-01 21:32 ` triegel at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-13165-131-9k20bHk8Sr@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).