[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pthread_cond_signal() ambiguity
On Wed, 2 Dec 2009 14:36:49 +0000, Sad Clouds
> Now my question is: does anyone think that NetBSD's implementation of
> pthread_cond_signal() is broken? I think quite a few people intentionally
> unlock the mutex before calling pthread_cond_signal(), so that the thread
> wakes up can lock this mutex asap. and start running, instead of
Or wait forever, as it will race against the pthread_cond_signal: thread A
acquires the mutex, check condition, but thread B signals a condition
change between A wait for it; as B did not acquire the mutex, thread A
might not see the signal.
If you are working in a pipeline, you just created a mutual deadlock: one
thread assumes that the other saw the condition change, but in fact raced
against it. Thread B now waits for thread A: oops. This is what I would
call undefined behaviour.
Depends on what you expect as a behaviour: you have to decide if it
acceptable for you, or not.
Main Index |
Thread Index |