Re: pthread_cond_signal() ambiguity

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On Wed, 2 Dec 2009 14:36:49 +0000, Sad Clouds
<cryintothebluesky%googlemail.com@localhost> 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
blocking.

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
jeanyves.migeon%free.fr@localhost