6

Suppose some condition variable "cond" is associated with a mutex variable "mutex". If a thread is sleeping on cond after calling pthread_cond_wait(&cond,&mutex), and another thread that has mutex locked is finished, does it matter whether that thread calls pthread_cond_signal(&cond) before or after calling pthread_mutex_unlock(&mutex) ? Does it even need to unlock the mutex at all if it calls pthread_cond_signal(&cond), since the sleeping thread will acquire the mutex anyway?

EDIT: According to https://computing.llnl.gov/tutorials/pthreads/#ConVarOverview, "Failing to unlock the mutex after calling pthread_cond_signal() may not allow a matching pthread_cond_wait() routine to complete (it will remain blocked)." I guess then, unlocking, and perhaps only afterwards, is required.

GrahamS
  • 9,980
  • 9
  • 49
  • 63
ManRow
  • 1,563
  • 4
  • 21
  • 40

2 Answers2

4

You should always unlock the mutex after calling pthread_cond_signal. Here are some good questions/answers to read:

Calling pthread_cond_signal without locking mutex

It won't come to me right now, but I'm pretty sure there's a good reason (in terms of race conditions) that you don't want to unlock the mutex before signalling.

Community
  • 1
  • 1
R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • If after signalling the condition variable and unlocking the mutex, the thread immediately calls `pthread_mutex_lock()` on that mutex, is it guaranteed not to starve the threads previously awoken by `pthread_cond_signal()` ? – ManRow Mar 03 '11 at 03:45
  • 1
    @ManRow: There may be such a guarantee in the Priority Scheduling option, if the right priorities are set. Otherwise, definitely not. – R.. GitHub STOP HELPING ICE Mar 03 '11 at 03:53
  • 2
    The good reason is avoiding priority inversion: http://groups.google.com/group/comp.programming.threads/msg/a3721a2fc9b21c64?hl=ky linked from http://stackoverflow.com/questions/4544234/calling-pthread-cond-signal-without-locking-mutex/4544494#4544494 – ninjalj Mar 15 '11 at 23:43
4

If you keep the mutex locked, then the thread being woken cannot acquire the mutex, so will block in pthread_cond_wait waiting to reacquire the mutex.

You do not need to hold the mutex locked to call pthread_cond_signal. In fact, if your application logic can work with a signal when the mutex is not locked then that is a better way to do it --- the OS can schedule the waiting thread immediately, and it doesn't have to wait for the signalling thread to unlock the mutex before proceeding.

However, in this scenario care must be taken to ensure that the wake-up is not lost, and you don't have a problem with the "wrong" thread being woken. If you use a straight-forward predicate, this shouldn't be a problem in practice.

Anthony Williams
  • 66,628
  • 14
  • 133
  • 155