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

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

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.