Call pthread_cond_signal without locking the mutex

Question

I read somewhere that we must lock the mutex before calling pthread_cond_signal and unlock the mutex after calling it:

The pthread_cond_signal () routine is used to signal (or wake up) another thread that the condition variable expects. Must be called after the mutex, locked and must unlock the mutex so that pthread_cond_wait () is complete.

My question is: is it ok to call the pthread_cond_signal or pthread_cond_broadcast methods without locking the mutex?

Answer 1

If you do not block the mutex in a code that changes state and signals, you may lose awakenings. Consider this pair of processes:

Process A:

pthread_mutex_lock(&mutex); while (condition == FALSE) pthread_cond_wait(&cond, &mutex); pthread_mutex_unlock(&mutex); 

Process B (invalid):

 condition = TRUE; pthread_cond_signal(&cond); 

Then consider this possible alternation of instructions, where condition begins as FALSE :

 Process A Process B pthread_mutex_lock(&mutex); while (condition == FALSE) condition = TRUE; pthread_cond_signal(&cond); pthread_cond_wait(&cond, &mutex); 

condition now TRUE , but process A is stuck waiting for a condition variable - it missed the wake-up signal. If we change process B to lock the mutex:

Process B (correct):

 pthread_mutex_lock(&mutex); condition = TRUE; pthread_cond_signal(&cond); pthread_mutex_unlock(&mutex); 

... then the above cannot happen; awakening will never be missed.

(Note that you can actually move pthread_cond_signal() immediately after pthread_mutex_unlock() , but this can lead to less optimal scheduling of threads, and you must block the mutex already in this code path due to a change in the condition itself).

Answer 2

According to this manual:

pthread_cond_broadcast() or pthread_cond_signal() functions can be called by a thread, regardless of whether it currently owns a mutex , which threads calling pthread_cond_wait() or pthread_cond_timedwait() have a condition variable associated with them while they are waiting; however, if predictable scheduling behavior is required, then the mutex must be blocked by calling pthread_cond_broadcast() or pthread_cond_signal() .

The meaning of the predictable description of planning behavior was explained by Dave Butenhof (author of Programming with POSIX Threads ) at comp.programming.threads and is available here .

Answer 3

caf, in your sample code, Process B modifies the condition without locking the mutex first. If Process B simply locked the mutex during this modification and then still unlocked the mutex before calling pthread_cond_signal , there would be no problem --- am I right about that?

I’m sure that the position in the cafe is correct: calling pthread_cond_signal without owning a mutex lock is a bad idea. But the cafe example is not actually evidence in support of this position; it just proves in favor of a much weaker (almost obvious) position that Bad Idea modifies the shared state protected by the mutex if you did not block this mutex in the first place.

Can someone provide some sample code where calling pthread_cond_signal followed by pthread_mutex_unlock gives the correct behavior, but calling pthread_mutex_unlock followed by pthread_cond_signal leads to incorrect behavior?