条件变量（Condition Variable）详解（转）

条件变量(Condtion Variable)是在多线程程序中用来实现“等待->唤醒”逻辑常用的方法。举个简单的例子，应用程序A中包含两个线程t1和t2。

t1需要在 bool变量test_cond为true时才能继续执行，而test_cond的值是由t2来改变的，这种情况下，如何来写程序呢？可供选择的方案有两 种：

• 第一种是t1定时的去轮询变量test_cond，如果test_cond为false，则继续休眠；如果test_cond为true，则开始执行。
• 第二种就是上面提到的条件变量，t1在test_cond为false时调用cond_wait进行等待，t2在改变test_cond的值后，调用cond_signal，唤醒在等待中的t1，告诉t1 test_cond的值变了，这样t1便可继续往下执行。

很明显，上面两种方案中，第二种方案是比较优的。在第一种方案中，在每次轮询时，如果t1休眠的时间比较短，会导致cpu浪费很厉害；

如果t1休眠的时间 比较长，又会导致应用逻辑处理不够及时，致使应用程序性能下降。

第二种方案就是为了解决轮询的弊端而生的。然而条件变量在使用的过程中，比较容易出错，如果用得不正确的话，会适得其反的，接下来，我将详细分析如何来使用条件变量，希望能够给在使用条件变量过程中遇到问题的朋友有所帮助。
在开始介绍之前，需要说明一下，在接下来的介绍中，需要用到互斥锁和条件变量相关的内容，在这里我以linux下的pthread_mutex_t为互斥 锁类型，pthread_cond_t为条件变量类型来进行介绍，对pthread不熟的朋友，可以参考一下linux下的manual。
1. 下面是把刚开始举的例子翻译后的程序：

pthread_mutex_t mutex;  ///< 互斥锁
pthread_cond_t  cond;   ///< 条件变量
bool test_cond = false;
/// TODO 初始化mutex和cond
 
/// thread 1:
pthread_mutex_lock(&mutex);            ///< 1
while (!test_cond)
{
    pthread_cond_wait(&cond, &mutex);  ///< 2,3
}
pthread_mutex_unlock(&mutex);          ///< 4
RunThread1Func();
 
/// thread 2:
pthread_mutex_lock(&mutex);            ///< 5
test_cond = true;
pthread_cond_signal(&cond);
pthread_mutex_unlock(&mutex);          ///< 6
 
/// TODO 销毁mutex和cond


通过上面的例子，下面我来介绍一下条件变量在使用过程中需要注意的几点（也是比较容易出错的）：
（1）条件变量的使用过程中，最为关键的一点是互斥锁的使用。细心的朋友应该发现了，我在上面的例子中标了1、2、3、4、5、6个标号。
在这里1、4、 5、6都是正常的lock/unlock，2、3是需要特别说明的。2是进入pthread_cond_wait后 的，pthread_cond_wait调的pthread_mutex_unlock，
这样做的目的是为了保证在thread1阻塞wait 后，thread2获取同一把锁mutex的时候，能够正常获取（即5，6）。
3是thread1被唤醒后，要退出pthead_cond_wait之 前，pthread_cond_wait调的pthread_mutex_lock，
这样做的目的是为了把mutex的控制权还给调用 pthread_cond_wait的线程（即thread1）。整理一下基本的时序为：

thread 1 lock->thread 1 wait-> thread 1 unlock(in wait)
->thread 2 lock->thread 2 signal->thread 2 unlock
->thread 1 lock(in wait)->thread 1 unlock
（2）条件变量使用的过程中，通常会加一个bool或者int的值test_cond来配合使用。这里需要注意的一点是一定要在signal之前来 改变test_cond，
这样才能保证wait的线程被唤醒后，能够取到正确的test_cond的值，否则后果是不可预测的。

------------------------------------------------------------------------------------------------------------------
了解 pthread_cond_wait() 的作用非常重要 -- 它是 POSIX 线程信号发送系统的核心，也是最难以理解的部分。

首先，让我们考虑以下情况：线程为查看已链接列表而锁定了互斥对象，然而该列表恰巧是空的。
这一特定线程什么也干不了 -- 其设计意图是从列表中除去节点，但是现在却没有节点。因此，它只能：

锁定互斥对象时，线程将调用 pthread_cond_wait(&mycond,&mymutex)。pthread_cond_wait() 调用相当复杂，因此我们每次只执行它的一个操作。

pthread_cond_wait() 所做的第一件事就是同时对互斥对象解锁（于是其它线程可以修改已链接列表），
并等待条件 mycond 发生（这样当 pthread_cond_wait() 接收到另一个线程的“信号”时，它将苏醒）。
现在互斥对象已被解锁，其它线程可以访问和修改已链接列表，可能还会添加项。 【要求解锁并阻塞是一个原子操作】

此时，pthread_cond_wait() 调用还未返回。对互斥对象解锁会立即发生，但等待条件 mycond 通常是一个阻塞操作，这意味着线程将睡眠，在它苏醒之前不会消耗 CPU 周期。
这正是我们期待发生的情况。线程将一直睡眠，直到特定条件发生，在这期间不会发生任何浪费 CPU 时间的繁忙查询。从线程的角度来看，它只是在等待 pthread_cond_wait() 调用返回。

现在继续说明，假设另一个线程（称作“2 号线程”）锁定了 mymutex 并对已链接列表添加了一项。
在对互斥对象解锁之后，2 号线程会立即调用函数 pthread_cond_broadcast(&mycond)。此操作之后，
2 号线程将使所有等待 mycond 条件变量的线程立即苏醒。这意味着第一个线程（仍处于 pthread_cond_wait() 调用中）现在将苏醒。

现在，看一下第一个线程发生了什么。您可能会认为在 2 号线程调用 pthread_cond_broadcast(&mymutex) 之后，1 号线程的 pthread_cond_wait() 会立即返回。
不是那样！实际上，pthread_cond_wait() 将执行最后一个操作：重新锁定 mymutex。一旦 pthread_cond_wait() 锁定了互斥对象，那么它将返回并允许 1 号线程继续执行。
那时，它可以马上检查列表，查看它所感兴趣的更改。

来看一个例子（你是否能理解呢?）

In Thread1:

pthread_mutex_lock(&m_mutex);   
pthread_cond_wait(&m_cond,&m_mutex);   
pthread_mutex_unlock(&m_mutex);  

 

In Thread2:

pthread_mutex_lock(&m_mutex);   
pthread_cond_signal(&m_cond);   
pthread_mutex_unlock(&m_mutex);

 

为什么要与pthread_mutex 一起使用呢？ 这是为了应对 线程1在调用pthread_cond_wait()但线程1还没有进入wait cond的状态的时候，此时线程2调用了 cond_singal 的情况。

如果不用mutex锁的话，这个cond_singal就丢失了。加了锁的情况是，线程2必须等到 mutex 被释放（也就是 pthread_cod_wait() 释放锁并进入wait_cond状态 ，此时线程2上锁） 的时候才能调用cond_singal.

pthread_cond_signal即可以放在pthread_mutex_lock和pthread_mutex_unlock之间，也可以放在pthread_mutex_lock和pthread_mutex_unlock之后，但是各有优缺点。

之间：
pthread_mutex_lock
    xxxxxxx
pthread_cond_signal
pthread_mutex_unlock
缺点：在某下线程的实现中，会造成等待线程从内核中唤醒（由于cond_signal)然后又回到内核空间（因为cond_wait返回后会有原子加锁的 行为），所以一来一回会有性能的问题。但是在LinuxThreads或者NPTL里面，就不会有这个问题，因为在Linux 线程中，有两个队列，分别是cond_wait队列和mutex_lock队列， cond_signal只是让线程从cond_wait队列移到mutex_lock队列，而不用返回到用户空间，不会有性能的损耗。
所以在Linux中推荐使用这种模式。

之后：
pthread_mutex_lock
    xxxxxxx
pthread_mutex_unlock
pthread_cond_signal
优点：不会出现之前说的那个潜在的性能损耗，因为在signal之前就已经释放锁了
缺点：如果unlock和signal之前，有个低优先级的线程正在mutex上等待的话，那么这个低优先级的线程就会抢占高优先级的线程（cond_wait的线程)，而这在上面的放中间的模式下是不会出现的。