Re: pthread_cond_signal() ambiguity

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

David Holland wrote:
>  > 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.
>
> This cannot happen. In order to actually change the condition, B has
> to hold the mutex.  It doesn't matter when B signals the change as long
> as it's not *before* it changes the condition. (But that would be a
> crazy thing to do, so it's not worth thinking about.)

Never said that B changes the condition. I said that B signals a change. 
You have the right to call pth_cd_signal() without enforcing that the 
caller modified the condition.

Programmer has to decide if it considers it safe, or not. But he should 
be aware of it.

> If A comes along before B changes the condition, A will go to sleep,
> then B will change the condition, then B will signal, then A will wake
> up. If A comes along after B changes the condition, it won't sleep and
> it doesn't matter when B signals. And if A is already sleeping, it
> doesn't matter at all.
>
> It is essential for the action "A releases the mutex and goes to
> sleep" to be atomic, but that's true regardless. This reasoning also
> assumes that the condition is being tested in a loop, but that's also
> necessary in general. (There are cases in which one can write code
> that doesn't require a loop, even if the condition variable doesn't
> provide Hoare semantics, but such code is fundamentally hackish and
> should be avoided.)

You still have the risk of spurious/unwanted wakeups, especially if B 
unlocks the mutex and signal() the change sometimes after. Pretty 
worthless to queue a thread in the runqueue if it merely checks the 
condition to get back to sleep after.

> Whether it's worth specifically releasing the mutex first as an
> "optimization" is a separate question entirely, and I'd guess the
> answer is no.

At least, we agree on that :)

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost