The title basically speaks for itself. If I make a call to pthread_cond_wait with a particular condition and mutex, will that thread stay blocked until a call to pthread_cond_signal is made with the corresponding condition? Or will it unblock regardless if the mutex is subsequently unlocked again?
If the answer is the former, I have a follow-up. I have a queue used for message-passing between my threads. I want to ensure only one thread can append an item to the queue at a time (hence the use of mutexes). None of the threads have any idea if any other thread will be waiting to take hold of the mutex themselves.
When attempting to append an item to the queue, I lock the mutex, wait for the queue to not be full with a pthread condition, then perform the append, then unlock the mutex. Before unlocking it, should I perform a pthread_cond_signal, even if I don’t know whether or not any other threads will be waiting? What happens if multiple threads are waiting?
Someone needs to signal/broadcast the condition variable, otherwise waiting threads don’t necessarily get woken up. You can also get “spurious” wake-ups, but don’t rely on them. Once a waiter has been woken (by a signal or broadcast or spuriously), it will start trying to acquire the mutex, and once it has that
pthread_cond_waitreturns.If there are multiple threads waiting then one of them is woken (arbitrarily or according to rules documented by the implementation). In your code as you describe it, the only place a thread ever waits on this condvar is when it’s trying to add an item to a full queue. So you have three options:
signal the condition variable each time you remove an element from a full queue. This wakes one of the 0 or more waiters. Then signal again after it adds an element, if the queue is still not full, just in case there was more than 1 waiter.
broadcast the condition variable each time you remove an element from a full queue. Now you don’t need to signal after adding an element.
signal the condition variable each time you remove an element, regardless of whether the queue is full or not. If you do this, don’t make the mistake of changing the code in future to remove two elements in one go and only signal once. Condition variables reduce the number of waiters by one each time you signal, and this approach works because it prevents there ever simultaneously being at least one waiter, and fewer woken ex-waiters trying to acquire the mutex than there are spaces in the queue. So you never get threads waiting when there’s a space they could use.
The way to think of this is that the “condition” you’re waiting for is, “the queue is not full”. Whenever the condition becomes true, you should signal or broadcast the condition variable. If you choose to signal, and there might be multiple waiters, then each waiter needs to signal (to wake the next waiter) if the condition remains true after it has done its thing.
If you don’t care about the performance cost of a few extra context switches, and provided you have written the code that waits on the condvar correctly to cope with spurious wakes, it is also safe to signal or broadcast a condvar when the condition is still false. This is one of the nice things about condition variables, it makes it easier to reason about the correctness of the code. So the requirement “whenever the condition becomes true, you should signal or broadcast the condition variable” means only what it says. You don’t have to signal if and only if the condition becomes true.
So in this case it would be fine to signal each time you remove an element from the queue, regardless of whether or not it was full beforehand. In this case it’s easy to cut down the number of signals to the minimum necessary, but occasionally it is more trouble than it is worth to work out for sure whether the condition has become true, so instead you signal if it’s now true and might have been false before, or even just signal if it might be true now. I wouldn’t advise putting in extra wakes for no reason, but sometimes it makes the code simpler.