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