About the usage of pthread_cond_wait

Question

I'm trying to wrap my head around pthread condition variables. I've seen some code examples that use pthread_cond_wait and pthread_cond_signal and all of them look like this:

while (condition)
{
    // Assume that the mutex is locked before the following call
    pthread_cond_wait(&cond, &mutex);
}

Is there a reason for using a while loop on the condition? why not just use a single if statement?

Answer 1

Spurious wakeups.

See Why does pthread_cond_wait have spurious wakeups? and also https://en.wikipedia.org/wiki/Spurious_wakeup:

Spurious wakeup describes a complication in the use of condition variables as provided by certain multithreading APIs such as POSIX Threads and the Windows API.

Even after a condition variable appears to have been signaled from a waiting thread's point of view, the condition that was awaited may still be false. One of the reasons for this is a spurious wakeup; that is, a thread might be awoken from its waiting state even though no thread signaled the condition variable. For correctness it is necessary, then, to verify that the condition is indeed true after the thread has finished waiting. Because spurious wakeup can happen repeatedly, this is achieved by waiting inside a loop that terminates when the condition is true ...

Answer 2

I believe this is because threads may be spuriously woken up before the condition is met. Man, talk about "gotcha's".

From the Open Group documentation:
"Spurious wakeups from the pthread_cond_wait() or pthread_cond_timedwait() functions may occur."

Source:
http://pubs.opengroup.org/onlinepubs/007908775/xsh/pthread_cond_wait.html

Answer 3

Is there a reason for using a while loop on the condition? why not just use a single if statement?

The idea behind condition variables is to suspend thread execution until a given condition is satisfied. The condition is not built into the variable, however -- it must be provided by the programmer.

If the relevant condition is already satisfied, then there is no need to suspend operation. The key here, however, is that when the thread resumes, the condition might still not be satisfied, either because something changed between the condition variable being signaled and the thread being able to proceed, or because the thread awoke spurriously (this is allowed to happen, though it rarely does). The program therefore checks the condition again upon every wakeup to see whether it must resume waiting.