pthread_cond_wait blocks(sleeps) indefinitely until pthread_cond_signal is called by another thread in C?

Question

If a thread: A is blocked in pthread_cond_wait for a condition, will our thread A will be sleeping indefinitely waiting for pthread_cond_signal being called in another thread? Or it will be woken up even when the condition somehow becomes true (workload > MAXLOAD ) without being signaled using pthread_cond_wait.

Thread A:

while(1) {
    pthread_mutex_lock( &recoveryMutex );  
    while( workload < MAXLOAD ) {                               
        pthread_cond_wait(&recoveryCond, &recoveryMutex );      
    }
    /* Recovery Code */
    /* Recovery Code */
    /* Recovery Code */        
    pthread_mutex_unlock(&recoveryMutex);
}

score 4 · Accepted Answer · answered Jul 22 '19 at 18:45

In short, yes, it block/sleeps indefinitely until you signal it.

pthread_cond_wait may wake "spuriously" for any reason (which would generally not have any relation to the condition becoming true; mechanically there's no reasonable way such a relation could come to be), but has no contract to wake until pthread_cond_signal or pthread_cond_broadcast has been called. You need to call one of these functions whenever you've made some change in state that could cause the truth value of the predicate to change.

score 3 · Answer 2 · answered Jul 22 '19 at 17:30

The POSIX pthread_cond_wait() documentation does a pretty good job of explaining how pthread_cond_wait() works:

Condition Wait Semantics

It is important to note that when pthread_cond_wait() and pthread_cond_timedwait() return without error, the associated predicate may still be false. Similarly, when pthread_cond_timedwait() returns with the timeout error, the associated predicate may be true due to an unavoidable race between the expiration of the timeout and the predicate state change.

The application needs to recheck the predicate on any return because it cannot be sure there is another thread waiting on the thread to handle the signal, and if there is not then the signal is lost. The burden is on the application to check the predicate.

Some implementations, particularly on a multi-processor, may sometimes cause multiple threads to wake up when the condition variable is signaled simultaneously on different processors.

In general, whenever a condition wait returns, the thread has to re-evaluate the predicate associated with the condition wait to determine whether it can safely proceed, should wait again, or should declare a timeout. A return from the wait does not imply that the associated predicate is either true or false.

It is thus recommended that a condition wait be enclosed in the equivalent of a "while loop" that checks the predicate.

Your thread can be woken up at any time, so you need to check your ( workload < MAXLOAD ). But changing that condition (by assigning a new value to workload) will not wake up a thread blocked in pthread_cond_wait().

You need to call pthread_cond_signal() to guarantee a wakeup.

But you also need to handle "spurious wakeups". Per the POSIX pthread_cond_signal() documentation:

POSIX.1-2017 explicitly documents that spurious wakeups may occur.

score 1 · Answer 3 · answered Jul 22 '19 at 17:27

1

I believe you need either pthread_cond_signal() or pthread_cond_broadcast().

Three useful links:

answered Jul 22 '19 at 17:27

paulsm4

114,292
17
138
190

pthread_cond_wait blocks(sleeps) indefinitely until pthread_cond_signal is called by another thread in C?

3 Answers3