Re: pthread_cond_signal() ambiguity

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Dec 03, 2009 at 10:30:57AM +0100, Jean-Yves Migeon wrote:
> 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.

Yes, you also have the right to execute *(int *)0xdeadbeef = 172.
Both are wrong and will lead to problems. Your point?

>> 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.

Some amount of that is unavoidable.

-- 
David A. Holland
dholland%netbsd.org@localhost