[Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting

["triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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.