|
Description
|
The cond_signal(3C) manpage contains:
The cond_broadcast() function unblocks all threads that are
blocked on the condition variable pointed to by cvp.
If no threads are blocked on the condition variable, then
cond_signal() and cond_broadcast() have no effect.
Both functions should be called under the protection of the
same mutex that is used with the condition variable being
signaled. Otherwise, the condition variable may be signaled
between the test of the associated condition and blocking in
cond_wait(). This can cause an infinite wait.
The justification given in the third paragraph (starting with "Otherwise"
is bogus. In particular, the thread heading into cond_wait() must have
already tested the condition under the lock and concluded it was false in
order to decide to cond_wait(). Since any thread changing state that
would affect the condition must also be holding the lock, there is no way
for the state (and thus the outcome of the test) to change between the
test and the cond_wait(), and thus any cond_signal() sent during that
window would end up being spurious anyway.
Instead, we should introduce wording that parallels what's said in
pthread_cond_signal(3C):
The cond_signal() or cond_broadcast() functions may be called by a
thread whether or not it currently owns the mutex that threads
calling cond_wait(), cond_timedwait(), or cond_reltimedwait() have
associated with the condition variable during their waits. However,
if predictable scheduling behavior is required, then that mutex
should be locked by the thread prior to calling cond_signal() or
cond_broadcast().
|