pthread_cond_wait与signal

http://www.domaigne.com/blog/computing/condvars-signal-with-mutex-locked-or-not/

pthread_mutex_lock(&mutex);predicate=true;pthread_cond_signal(&cv);     // OR: pthread_mutex_unlock(&mutex);pthread_mutex_unlock(&mutex); //   : pthread_cond_signal(&cv);

Signal with Mutex Locked

On some platforms, the OS performs a context switch to the woken thread right after the signal/broadcast operation, to minimize latency. On a single processor system, this may lead to unnecessary context switches if we signal or broadcast while holding the mutex.

Fig 1- signal with mutex locked. We get 2 unnecessary context switch.

Indeed, consider the scenario shown in figure 1. The thread T₂ is blocked on the condition variable. T₁ signals the condition while holding the associated mutex. A context switch to T₂ occurs and T₂ wakes up. But before returning frompthread_cond_wait, T₂ needs to lock the mutex. However that mutex is already hold by T₁. As a result T₂ blocks (but this time contends for the mutex) and a context switch to T₁ occurs. Then T₁ unlocks the mutex, and T₂ becomes finally runnable. The situation appears to be even worse, if we broadcast the condition variable to several threads.