我們知道，當呼叫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。

一：加鎖時呼叫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/