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