[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pthread_cond_signal() ambiguity
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
Main Index |
Thread Index |