我们知道，当调用signal/broadcast唤醒等待条件变量的其他线程时，既可以在加锁的情况下调用signal/broadcast，也可以在解锁的情况下调用。
那么，到底哪种情况更好呢？man手册中其实已经给出了答案：
The pthread_cond_broadcast() or pthread_cond_signal() functions may be called by a thread whether or not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait() have associated with the condition variable during their waits; however, if predictable scheduling behavior is required, then that mutex shall be locked by the thread calling pthread_cond_broadcast() or pthread_cond_signal().
意思就是说，尽管既可以在持有锁的情况下调用signal/broadcast，也可以在解锁的情况下调用，但是如果需要调度行为是可预测的话，则应该在加锁的情况下调用signal/broadcast。
关于上述论点， 文章《Condvars: Signal With Mutex Locked Or Not?》（http://www.domaigne.com/blog/computing/condvars-signal-with-mutex-locked-or-not/）中做了详细解释，下面的描述主要翻译自该文章。
一：加锁时调用signal
某些平台上，在执行了signal/broadcast之后，为了减少延迟，操作系统会将上下文切换到被唤醒的线程。在单核系统上，如果在加锁的情况下调用signal/broadcast，这可能导致不必要的上下文切换。
考虑上图的场景：T2阻塞在条件变量上，T1在持有锁的情况下调用signal，接着上下文切换到T2，并且T2被唤醒，但是T2在从pthread_cond_wait返回时，需要重新加锁，然而此时锁还在T1手中。因此，T2只能继续阻塞（但是此时是阻塞在锁上），并且上下文又切换回T1。当T1解锁时，T2才得以继续运行。如果是调用broadcast唤醒等待条件变量的多个线程的话，那这种情形会变得更糟。
为了弥补这种缺陷，一些Pthreads的实现采用了一种叫做waitmorphing的优化措施，也就是当锁被持有时，直接将线程从条件变量队列移动到互斥锁队列，而无需上下文切换。
如果使用的Pthreads实现没有waitmorphing，我们可能需要在解锁之后在进行signal/broadcast。解锁操作并不会导致上下文切换到T2，因为T2是在条件变量上阻塞的。当T2被唤醒时，它发现锁已经解开了，从而可以对其加锁。
二：解锁后调用signal
解锁后调用signal有问题吗？首先，我们注意到，如果先进行signal/broadcast，则肯定会唤醒一个阻塞在条件变量上的线程；然而如果先解锁，则可能会唤醒一个阻塞在锁上的线程。
这种情形如何发生的呢？一个线程在锁上阻塞，是因为：
a：它要检查条件，并最终会在条件变量上wait；
b：它要改变条件，并最终通知那些等待条件变量的线程；
在a中，可能会发生唤醒截断的情况。重新考虑上图的场景，此时存在第三个线程T3阻塞在锁上。如果T1首先解锁，则上下文可能会切换到T3。现在T3检查到条件为真，进行处理，并在T1进行signal/broadcast之前，将条件重置。当T1进行signal/broadcast之后，T2被唤醒，而此时条件已经不再为真了。当然，在设计正确的应用中，这不是问题。因为T2必须考虑伪唤醒的情况。下面的代码模拟了这种场景：
#define COND_CHECK(func, cond, retv, errv) \
if ( (cond) ) \
{ \
fprintf(stderr, "\n[CHECK FAILED at %s:%d]\n| %s(...)=%d (%s)\n\n",\
__FILE__,__LINE__,func,retv,strerror(errv)); \
exit(EXIT_FAILURE); \
}
#define ErrnoCheck(func,cond,retv) COND_CHECK(func, cond, retv, errno)
#define PthreadCheck(func,rc) COND_CHECK(func,(rc!=0), rc, rc)
#define FOREVER for(;;)
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cv = PTHREAD_COND_INITIALIZER;
int predicate = 0;
unsigned long nwakeup = 0; // number of wakeup
unsigned long nspurious = 0; // number of spurious wakeup
/*****************************************************************************/
/* thread - wait on condvar, do stats and reset the condvar */
/*****************************************************************************/
void*
thread(void* ignore)
{
int rc;
FOREVER {
// wait that predicate becomes true
//
rc = pthread_mutex_lock(&mutex);
PthreadCheck("pthread_mutex_lock", rc);
while (predicate==0) {
rc = pthread_cond_wait(&cv, &mutex);
PthreadCheck("pthread_cond_wait", rc);
nwakeup++; // we've been wakeup
if (predicate==0) nspurious++; // we got a spurious wakeup
}
// reset predicate to false
//
predicate=0;
rc = pthread_mutex_unlock(&mutex);
PthreadCheck("pthread_mutex_unlock", rc);
}
// never reached
//
pthread_exit(NULL);
}
/*****************************************************************************/
/* signal_thread - set predicate to true and signal the condvar */
/*****************************************************************************/
void*
signal_thread(void* ignore)
{
int rc;
FOREVER {
// set the predicate to true and wakeup one thread
//
rc = pthread_mutex_lock(&mutex);
PthreadCheck("pthread_mutex_lock", rc);
predicate=1;
rc = pthread_mutex_unlock(&mutex); // unlock before signal
PthreadCheck("pthread_mutex_unlock", rc);
rc = pthread_cond_signal(&cv);
PthreadCheck("pthread_cond_signal", rc);
}
// never reached
//
pthread_exit(NULL);
}
/*****************************************************************************/
/* main- main thread */
/*****************************************************************************/
const int NTHREADS = 8; // # threads waiting on the condvar
int
main()
{
pthread_t tid[NTHREADS]; // threads waiting on the condvar
pthread_t tsig; // thread that signals the condvar
int rc; // return code
// create our threads
//
for (int i=0; i上面的代码中，使用nwakeup记录pthread_cond_wait被唤醒的次数，用nspurious记录伪唤醒的次数。运行结果如下：
# wakeup = 487936
# spurious = 215469 (44.16%)
可见伪唤醒的占比要在40%左右。（其实，采用先signal/broadcast，后unlock的写法，也依然会发生这种情况（亲测））
在b中，会推迟唤醒线程T2的时间。第三个线程T3阻塞在锁上，T1解锁后，T3得以继续执行。此时，只要T1不被调度，则它没有机会进行signal/broadcast，因此线程T2会一直阻塞。
三：实时的情况
在实时性的程序中，线程的优先级反映了线程deadline的重要性。粗略的说，deadline越重要，则优先级应该越高。如果无法满足deadline的要求，则系统可能会失败、崩溃。
因此，你肯定希望高优先级的线程能尽可能早的获取CPU得以执行，然而，有可能会发生优先级反转的情况，也就是低优先级的线程阻碍了高优先级线程的执行。比如锁被低优先级的线程持有，使得高优先级的线程无法加锁。实际上，只要优先级反转的时间是有界且较短的话，这种情况不会造成太大问题。然而当反转时间变得无界时，这种情况就比较严重了，这会导致高优先级的线程无法满足其deadline。
当采用实时调度策略时，signal/broadcast会唤醒高优先级的线程。如果多个线程具有相同的优先级，则先在条件变量上阻塞的线程会被唤醒。
在线程进行signal/broadcast之前，也可能会发生优先级反转。继续考虑上图的场景：T1是个低优先级（P1）的线程，T2是高优先级（P2）的线程，T3的优先级（P3）介于T1和T2之间：P1 < P3 < P2。
如果T1先进行unlock，则其在unlock和signal/broadcast之间，T1可能被更高优先级的T3抢占，从而T1无法唤醒T2，因此低优先级的T3阻碍了高优先级的T2的运行，发生了优先级反转。
如果T1先进行signal/broadcast，假设锁使用了优先级天花板或继承协议（参考《Programming.With.Posix.Threads》第5.5.5.1节和5.5.5.2节），则可以保证T1在解锁后，T2会立即被调度。
因此，当持有锁时进行signal/broadcast更具优势。基于上面的讨论，在实时调度中，先signal/broadcast后unlock是必须的……。
四：陷阱
如果先解锁，则可能会导致另一种问题：你必须保证解锁之后，用于signal/broadcast的条件变量依然有效。比如下面的代码：
#define COND_CHECK(func, cond, retv, errv) \
if ( (cond) ) \
{ \
fprintf(stderr, "\n[CHECK FAILED at %s:%d]\n| %s(...)=%d (%s)\n\n",\
__FILE__,__LINE__,func,retv,strerror(errv)); \
exit(EXIT_FAILURE); \
}
#define ErrnoCheck(func,cond,retv) COND_CHECK(func, cond, retv, errno)
#define PthreadCheck(func,rc) COND_CHECK(func,(rc!=0), rc, rc)
#define FOREVER for(;;)
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t *ptr_cv;
int predicate = 0;
int nthreads;
/*****************************************************************************/
/* thread - tell the shutdown thread that we're done */
/*****************************************************************************/
void*
thread(void* ignore)
{
int rc;
// this thread now terminate
//
rc = pthread_mutex_lock(&mutex);
PthreadCheck("pthread_mutex_lock", rc);
nthreads--; // we have one thread less in the pool
// note: we unlock first, and then signal
//
rc = pthread_mutex_unlock(&mutex);
PthreadCheck("pthread_mutex_unlock", rc);
rc = pthread_cond_signal(ptr_cv);
PthreadCheck("pthread_cond_signal", rc);
// Ok, time to retire
//
pthread_exit(NULL);
}
/*****************************************************************************/
/* shutdown_thread- wait all threads in the pool to finish and clean-up */
/* condvar */
/*****************************************************************************/
void*
shutdown_thread(void* ignore)
{
int rc;
// wait as long as one thread in the pool is running
//
rc = pthread_mutex_lock(&mutex);
PthreadCheck("pthread_mutex_lock", rc);
while (nthreads>0) {
rc = pthread_cond_wait(ptr_cv, &mutex);
PthreadCheck("pthread_cond_wait", rc);
}
// all thread stopped running: we can destroy the condvar
//
rc = pthread_cond_destroy(ptr_cv);
PthreadCheck("pthread_cond_destroy", rc);
free(ptr_cv);
// unlock mutex, and bye!
//
rc = pthread_mutex_unlock(&mutex);
PthreadCheck("pthread_mutex_unlock", rc);
pthread_exit(NULL);
}
/*****************************************************************************/
/* main- main thread */
/*****************************************************************************/
const int NTHREADS = 8; // # threads in the pool
int
main()
{
pthread_t pool[NTHREADS]; // threads pool
pthread_t tshd; // shutdown thread
unsigned long count=0; // counter
int rc; // return code
FOREVER {
// initialize condvar
//
nthreads=NTHREADS;
ptr_cv = (pthread_cond_t*) malloc(sizeof(*ptr_cv));
ErrnoCheck("malloc", (ptr_cv==NULL), 0);
rc = pthread_cond_init(ptr_cv, NULL);
PthreadCheck("pthread_cond_init", rc);
// create shutdown thread
//
rc = pthread_create(&tshd, NULL, shutdown_thread, NULL);
PthreadCheck("pthread_create", rc);
// create threads pool
//
for (int i=0; i上面的代码在运行时，会发生Segmentationfault。
五：结论
我个人倾向于，在持有锁的情况下进行signal/broadcast。首先，这样做可以避免隐蔽的bug；然后，在使用了wait morphing优化的Pthreads实现中，这样做几乎没有性能损耗；其次，我认为只有在明确表明性能可以得到显著提升时，才有必要先unlock，后signal/broadcast，优化那些并非导致性能瓶颈的点，是没有必要的。
原文：
http://www.domaigne.com/blog/computing/condvars-signal-with-mutex-locked-or-not/