POSIX线程-条件变量（二）

pthread_cond_signal()和pthread_cond_wait()的典型使用方法

pthread_mutex_t mtx;

pthread_cond_t cond;

线程A中通知的执行的操作

s = pthread_mutex_lock(&mtx)

if (s != 0)

err_exit();

a++;/*谓词条件*/

……

do some work/*处理共享的数据*/

…….

s = pthread_mutex_unlock(&mtx)

if (s != 0)

err_exit();

pthread_cond_signal(&cond);

 

线程B执行被唤醒的操作

s= pthread_mutex_lock(&mtx);

if (s != 0)

        err_exit();

/*在锁住互斥量之后和在等待条件变量之前，测试谓词是很重要的*/

while (a < 0/*此处要检查共享变量的状态/*)

        pthread_cond_wait(&cond, &mtx);

a--;

/*处理共享数据 */

……………….

s = pthread_mutex_unlock(&mtx)

if (s != 0)

        err_exit();

在线程B中为什么把pthread_cond_wait()放在while循环中？很多人不能理解。大部分人认为把pthread_cond_wait()放在if中就行了。这是因为他们没有理解到，pthread_cond_wait()会苏醒的条件，在《POSIX多线程程序设计》中有很详细的说明，现简约摘录：

1.   被拦截的唤醒：也就是说可能有多个线程被唤醒（被pthread_cond_broadcast唤醒），被唤醒的线程都“争着”去处理共享数据，但只有一个线程能处理到这个共享数据，等它处理完毕后，其他线程也会进入该临界区去处理共享数据，这个时候就会出现共享数据被多次处理的情况，我们的解决方法是在被唤醒后，在去检查一下谓词变量，看该共享数据是否已经被处理了。

2.    松散的谓词：有时候谓词表示了“可能有工作”而不是“有工作”的意思。所以，当线程被唤醒，我们必须确认到底有没有工作。

3.    假唤醒：在有些系统中，我们没有用pthread_cond_signal()或pthread_cond_broadcast()来唤醒用pthread_cond_wait()休眠的线程，但是在休眠的线程还是会被唤醒，这是怎么回事呢？在linux中，被休眠的进程或线程，都有被信号（linux中的信号）打断的可能，也就是说，如果线程或进程在休眠中，会有被唤醒的可能，所以我们在有可能引起休眠的API调用返回后都会检查一下返回值是否为EINT，如果是，那么线程或进程都将继续休眠。

为什么不把线程A中的pthread_cond_signal()放在pthread_mutex_unlock()前面？

当一个等待线程被唤醒的时候，它必须首先加锁互斥量（参见pthread_cond_wait()执行步骤）。如果线程被唤醒而此时通知线程任然锁住互斥量，则被唤醒线程会立刻阻塞在互斥量上，等待通知线程解锁该互斥量，引起线程的上下文切换。当通知线程解锁后，被唤醒线程继续获得锁，再一次的引起上下文切换。这样导致被唤醒线程不能顺利加锁，延长了加锁时间，加重了系统不必要的负担。

pthread_cond_wait()中为什么需要把mtx传递进去？

先考虑没有mtx参数的pthread_cond_wait(), 我们是否可以像下面这样等待“信号”的到来

pthread_mutex_lock(&mtx);

       while(检查谓词)

 pthread_cond_wait(&cond);

pthread_mutex_unlock(&mtx);

上面这种方式在休眠的时候，没有把互斥量释放掉，将会导致通知线程无法获得互斥量，导致死锁。那把pthread_cond_wait(&cond)放在pthread_mutex_lock(&mtx)之前又怎么样呢？

while(检查谓词)

pthread_cond_wait(&cond);

pthread_mutex_lock(&mtx);

pthread_mutex_unlock(&mtx);

看起来好像没什么问题。考虑下面这种情况：

T3:线程C发现a等于0，执行pthread_cond_wait()，线程休眠。

T1:a++，谓词改变。

T2:线程B发现a大于0了，执行pthread_mutex_lock(),由于此时线程A持有互斥量，线程B进入阻塞。

T4:线程A完成了共享数据的操作，执行pthread_cond_signal()唤醒所有等待的线程。

T5:线程C被唤醒，进入临界区操作共享数据，操作完毕后退出。

T6：线程B获得了互斥量，进入临界区操作共享数据，此处会产生错误，重复操作了共享数据！！

造成这种情况的原因是因为对a的访问没有互斥量的保护，导致线程C和线程B读到的a都是不相同的。所以，要把互斥量放在pthread_cond_wait()中，在还没休眠前，锁定a的状态不被其他线程修改。

 

我们来看看pthread_cond_wait()的源代码

int

__pthread_cond_wait (cond, mutex)

     pthread_cond_t *cond;

     pthread_mutex_t *mutex;

{

  struct _pthread_cleanup_buffer buffer;

  struct _condvar_cleanup_buffer cbuffer;

  int err;



  /* Make sure we are along.  */

  lll_mutex_lock (cond->__data.__lock);



  /* Now we can release the mutex.  */

  err = __pthread_mutex_unlock_usercnt (mutex, 0);

  if (__builtin_expect (err, 0))

    {

      lll_mutex_unlock (cond->__data.__lock);

      return err;

}

…………………………….

……….操作该cond的某些字段……

  ++cond->__data.__total_seq;

  ++cond->__data.__futex;

  cond->__data.__nwaiters += 1 << COND_NWAITERS_SHIFT;

……………………………………….

  do

    {

      unsigned int futex_val = cond->__data.__futex;



      /* Prepare to wait.  Release the condvar futex.  */

      lll_mutex_unlock (cond->__data.__lock);



      /* Enable asynchronous cancellation.  Required by the standard.  */

      cbuffer.oldtype = __pthread_enable_asynccancel ();



      /* Wait until woken by signal or broadcast.  */

      lll_futex_wait (&cond->__data.__futex, futex_val);



      /* Disable asynchronous cancellation.  */

      __pthread_disable_asynccancel (cbuffer.oldtype);



      /* We are going to look at shared data again, so get the lock.  */

      lll_mutex_lock (cond->__data.__lock);



      /* If a broadcast happened, we are done.  */

      if (cbuffer.bc_seq != cond->__data.__broadcast_seq)

       goto bc_out;



      /* Check whether we are eligible for wakeup.  */

      val = cond->__data.__wakeup_seq;

    }

  while (val == seq || cond->__data.__woken_seq == val);

………………………………….

  /* We are done with the condvar.  */

  lll_mutex_unlock (cond->__data.__lock);



  /* The cancellation handling is back to normal, remove the handler.  */

  __pthread_cleanup_pop (&buffer, 0);



  /* Get the mutex before returning.  */

  return __pthread_mutex_cond_lock (mutex);

}

首先锁住cond中的锁，然后释放掉作为参数传递进来的互斥量。和在POSIX线程－条件变量(一)说的一样。

那pthread_cond_wait()函数最开始的两个语句能不能交换呢？

  lll_mutex_lock (cond->__data.__lock);

err = __pthread_mutex_unlock_usercnt (mutex, 0);

 

我们把  pthread_cond_signal()和pthread_cond_wait()的典型使用方法 这段中线程B执行

被唤醒的操作简化和抽象一下：

对mtx的操作简化为LOCK, UNLOCK;

对cond中锁的操作简化为__lock, __unlock.

括号中的操作代表了pthread_cond_wait()中锁的操作。

 

抽象的结果为（整个序列表示为M）：

LOCK

{

① __lock

② UNLOCK

……….操作该cond的某些字段……

__unlock

Wait

LOCK

}

UNLOCK

 

 

 

交换①②顺序的结果为(整个序列表示为N)

LOCK

{

② UNLOCK

① __lock

……….操作该cond的某些字段……

__unlock

Wait

LOCK

}

UNLOCK

 

  在N中，②①之间可能会被打断，比如通知线程在②①之间已经发出了“信号”，但N还没有在休眠队列上准备好；那么，当CPU切换到N中，继续执行①后面的语句时，将会造成N的永久等待（因为“信号”被丢失了）。

  在M中就不会有这种情况发生了么？在M中①②之间也可能被打断，但当①执行之后，cond已经被锁定，通知线程在①②之间不可能发出“信号”（因为pthread_cond_signal()也需要锁定cond）。那么该”信号”只有在M完成了对cond的某些字段的更新（相当于把该线程挂入了休眠队列），释放了cond上的锁后，才有机会被发送。通过将解锁操作与等待条件变量原子化，确保了在释放互斥量和等待条件变量之间没有线程可以改变谓词。