tech-userlevel archive

[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
<> wrote:
> 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
> that 
> 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.

Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index