条件变量用例--解锁与signal的顺序问题

我们知道，当调用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<NTHREADS; i++) {
      rc = pthread_create(tid+i, NULL, thread, NULL);
      PthreadCheck("pthread_create", rc);
   }
   rc = pthread_create(&tsig, NULL, signal_thread, NULL);
   PthreadCheck("pthread_create", rc);
 
   // wait 3 sec, print statistics and exit
   //
   sleep(3);
   rc = pthread_mutex_lock(&mutex);
   PthreadCheck("pthread_mutex_lock", rc);
   printf("# wakeup   = %8lu\n# spurious = %8lu (%2.2f%%)\n",
          nwakeup, nspurious, (float)nspurious/nwakeup*100.0
         );
   rc = pthread_mutex_unlock(&mutex);
   PthreadCheck("pthread_mutex_unlock", rc);
 
   // that's all, folks!
   //
   return EXIT_SUCCESS;
}

上面的代码中，使用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<NTHREADS; i++) {
         rc = pthread_create(pool+i, NULL, thread, NULL);
         PthreadCheck("pthread_create", rc);
         rc = pthread_detach(pool[i]);
         PthreadCheck("pthread_detach", rc);
      }
 
      // wait shutdown thread completion
      //
      rc = pthread_join(tshd, NULL);
      PthreadCheck("pthread_join", rc);
 
      // great... one more round
      //
      ++count;
      printf("%lu\n", count);
   }
 
   // should be never reached
   //
   return EXIT_SUCCESS;
}

上面的代码在运行时，会发生Segmentationfault。

五：结论

我个人倾向于，在持有锁的情况下进行signal/broadcast。首先，这样做可以避免隐蔽的bug；然后，在使用了wait morphing优化的Pthreads实现中，这样做几乎没有性能损耗；其次，我认为只有在明确表明性能可以得到显著提升时，才有必要先unlock，后signal/broadcast，优化那些并非导致性能瓶颈的点，是没有必要的。

原文：

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