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: "triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 19 Sep 2012 15:20:45 +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 #17 from Torvald Riegel <triegel at redhat dot com> 2012-09-19 15:20:45 UTC ---
(In reply to comment #13)
> It is a bug if pthread condition variables should support the following usage:
>
> ...
>
> pthread_mutex_lock(&m);
>
> SomeType localState = f(sharedState);
>
> while ( predicate(sharedState, localState) ) {
> pthread_cond_wait(&c, &m);
> }
>
> ...
>
> In this case it actually matters which thread will wake up, because if the
> wrong thread wakes up, it will retry the wait and the signal will be lost (this
> is what happened to me). Unfortunately the spec is not very clear on the issue.
If the spec doesn't guarantee something, it's usually best to not depend on
this.
> But this is the pattern that the pthread_cond_wait implementation in glibc
> itself uses to detect spurious wakeups on the futex.
Not quite. For one, pthread_cond_wait doesn't try to establish the ordering
that you seem to depend on the piece of code above.
--
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.