Question

Suppose a condition variable is used in a situation where the signaling thread modifies the state affecting the truth value of the predicate and calls pthread_cond_signal without holding the mutex associated with the condition variable? Is it true that this type of usage is always subject to race conditions where the signal may be missed?

To me, there seems to always be an obvious race:

1. Waiter evaluates the predicate as false, but before it can begin waiting…
2. Another thread changes state in a way that makes the predicate true.
3. That other thread calls pthread_cond_signal, which does nothing because there are no waiters yet.
4. The waiter thread enters pthread_cond_wait, unaware that the predicate is now true, and waits indefinitely.

But does this same kind of race condition always exist if the situation is changed so that either (A) the mutex is held while calling pthread_cond_signal, just not while changing the state, or (B) so that the mutex is held while changing the state, just not while calling pthread_cond_signal?

I’m asking from a standpoint of wanting to know if there are any valid uses of the above not-best-practices usages, i.e. whether a correct condition-variable implementation needs to account for such usages in avoiding race conditions itself, or whether it can ignore them because they’re already inherently racy.

Answer 1

The fundamental race here looks like this:

THREAD A        THREAD B
Mutex lock
Check state
                Change state
                Signal
cvar wait
(never awakens)

If we take a lock EITHER on the state change OR the signal, OR both, then we avoid this; it’s not possible for both the state-change and the signal to occur while thread A is in its critical section and holding the lock.

If we consider the reverse case, where thread A interleaves into thread B, there’s no problem:

THREAD A        THREAD B
                Change state
Mutex lock
Check state
( no need to wait )
Mutex unlock
                Signal (nobody cares)

So there’s no particular need for thread B to hold a mutex over the entire operation; it just need to hold the mutex for some, possible infinitesimally small interval, between the state change and signal. Of course, if the state itself requires locking for safe manipulation, then the lock must be held over the state change as well.

Finally, note that dropping the mutex early is unlikely to be a performance improvement in most cases. Requiring the mutex to be held reduces contention over the internal locks in the condition variable, and in modern pthreads implementations, the system can ‘move’ the waiting thread from waiting on the cvar to waiting on the mutex without waking it up (thus avoiding it waking up only to immediately block on the mutex).
As pointed out in the comments, dropping the mutex may improve performance in some cases, by reducing the number of syscalls needed. Then again it could also lead to extra contention on the condition variable’s internal mutex. Hard to say. It’s probably not worth worrying about in any case.

Note that the applicable standards require that pthread_cond_signal be safely callable without holding the mutex:

The pthread_cond_signal() or pthread_cond_broadcast() functions may be called by a thread whether or not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait() have associated with the condition variable during their waits […]

This usually means that condition variables have an internal lock over their internal data structures, or otherwise use some very careful lock-free algorithm.