条件变量用例--解锁与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/

         

  • 7
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值