linux线程同步方式2——条件变量（Condition Variable）

条件变量

#include <pthread.h>

0、背景

互斥量是线程程序必需的工具，但并非是万能的。例如，如果线程正在等待共享数据内某个条件出现，那会发生什么呢？它可能重复对互斥对象锁定和解锁，每次都会检查共享数据结构，以査找某个值。但这是在浪费时间和资源，而且这种繁忙查询的效率非常低。

在每次检查之间，可以让调用线程短暂地进入睡眠，比如睡眠3秒，但是由此线程代码就无法最快作出响应。真正需要的是这样一种方法:当线程在等待满足某些条件时使线程进入睡眠状态，一旦条件满足，就唤醒因等待满足特定条件而睡眠的线程。如果能够做到这一点，线程代码将是非常高效的，并且不会占用宝贵的互斥对象锁。而这正是条件变量能做的事

1、定义

• 条件变量是利用线程间共享的全局变量进行同步的一种机制，这些同步对象为线程提供了会合的场所，理解起来就是两个（或者多个）线程需要碰头（或者说进行交互-一个线程给另外的一个或者多个线程发送消息），我们指定在条件变量这个地方发生，一个线程用于修改这个变量使其满足其它线程继续往下执行的条件，其它线程则接收条件已经发生改变的信号。

• 条件变量同锁一起使用使得线程可以以一种无竞争的方式等待任意条件的发生。所谓无竞争就是，条件改变这个信号会发送到所有等待这个信号的线程。而不是说一个线程接受到这个消息而其它线程就接收不到了。

• 主要包括两个动作:

  • 一个线程等待"条件变量的条件成立"而挂起;
  • 另一个线程使"条件成立"(给出条件成立信号)

举例：

生产者向队列中插入数据，消费者则在生产者发出队列准备好（有数据了）后接收消息，然后取出数据进行处理

条件变量运行流程：

2、创建

1. 静态方式

 pthread_cond_t  cond = PTHREAD_COND_INITIALIZER

2. 动态方式

 int pthread_cond_init(pthread_cond_t *cond, pthread_condattr_t *cond_attr)

• pthread_cond_t:是函数定义将要等待的信号
• cond_attr值通常为NULL,且被忽略

返回值：函数成功返回0；任何其他返回值都表示错误

3、销毁

 int pthread_cond_destroy(pthread_cond_t *cond)

• 成功返回0，出错返回错误编号

注意：

• 只有在没有线程在该条件变量上等待的时候才能注销这个条件变量，否则返回EBUSY。 因为Linux实现的条件变量没有分配什么资源,所以注销动作只包括检查是否有等待线程

4、阻塞（等待）

自动解锁互斥量及等待条件变量

无条件等待

int pthread_cond_wait(pthread_cond_t *cond,pthread_mutex_t *mutex);

• mutex：相关的互斥锁的指针

成功返回0，出错返回错误编号。
注意：

• pthread_cond_wait总和一个互斥锁结合使用。在调用pthread_cond_wait前要先获取锁，mutex保持锁定状态。
  • 原因：以防止多个线程同时请求pthread_cond_wait()（或pthread_cond_timedwait()，下同）的竞争条件（Race Condition）
• mutex互斥锁必须是普通锁（PTHREAD_MUTEX_TIMED_NP）或者适应锁
  （PTHREAD_MUTEX_ADAPTIVE_NP）
• pthread_cond_wait函数执行（线程挂起进入等待前）时先自动释放指定的锁，然后等待条件变量的变化。在函数调用返回之前，自动将指定的互斥量重新锁住。

为什么在唤醒线程后要重新mutex加锁？

pthread_cond_wait执行后的内部操作

pthread _mutex_lock(&mutex)
while(线程执行的条件是否成立)
{
    pthread_cond_wait(&cond, &mutex);
}
pthread_mutex_unlock(&mutex);

pthread_cond_wait执行后的内部操作分为以下几步：

• 将线程放在条件变量的请求队列后，内部解锁
• 线程等待被pthread_cond_broadcast信号唤醒或者pthread_cond_signal信号唤醒，唤醒后去竞争锁
• 若竞争到互斥锁，内部再次加锁

计时等待

int pthread_cond_timedwait(pthread_cond_t *cond,pthread_mutex_t mytex,const struct timespec *abstime);

成功返回0，出错返回错误编号

• abstime指向一个timespec结构。该结构如下：

struct timespec
{
       time_t tv_sec;// seconds
       long tv_nsex;// and nanoseconds纳秒
};

如果在 abstime指定的时间内 cond未触发，互斥量 mutex被重新加锁，并返回错误 ETIMEDOUT，结束等待. 其中abstime以与time()系统调用相同意义的绝对时间形式出现,0表示格林尼治时间1970年1月1日0时0分0秒。

5、激发

signal()激活

函数被用来释放被阻塞在指定条件变量上的一个线程。

 int pthread_cond_signal(pthread_cond_t *cond);

返回值：函数成功返回0；任何其他返回值都表示错误
注意：

• 必须在互斥锁的保护下使用相应的条件变量。否则对条件变量的解锁有可能发生在锁定条件变量之前，从而造成死锁。
• 唤醒阻塞在条件变量上的所有线程的顺序由调度策略决定，如果线程的调度策略是SCHED_OTHER类型的，系统将根据线程的优先级唤醒线程。
• 如果没有线程被阻塞在条件变量上，那么调用pthread_cond_signal()将没有作用。

broadcast() 激活

激活所有等待线程，这些线程被唤醒后将再次竞争相应的互斥锁。

 int pthread_cond_broadcast(pthread_cond_t *cond);

返回值：函数成功返回0；任何其他返回值都表示错误

• 函数唤醒所有被pthread_cond_wait函数阻塞在某个条件变量上的线程，参数cond被用来指定这个条件变量。当没有线程阻塞在这个条件变量上时，pthread_cond_broadcast函数无效。

5、应用举例

《Unix 环境高级编程》 生产者-消费者模型：

• process_msg
• enqueue_msg
• struct msg* workq

#include <pthread.h>
struct msg 
{
	struct msg *m_next;
	/* ... more stuff here ... */
};
struct msg *workq;//作为缓冲队列
pthread_cond_t qready = PTHREAD_COND_INITIALIZER;
pthread_mutex_t qlock = PTHREAD_MUTEX_INITIALIZER;

void process_msg(void)//消费者 
{
	struct msg *mp;
	for (;;) {
	pthread_mutex_lock(&qlock);
	while (workq == NULL)
		pthread_cond_wait(&qready, &qlock);
	mp = workq;
	workq = mp->m_next;
	pthread_mutex_unlock(&qlock);
	/* now process the message mp */
	}
}
void enqueue_msg(struct msg *mp)//生产者  
{
	pthread_mutex_lock(&qlock);
	mp->m_next = workq;
	workq = mp;
	pthread_mutex_unlock(&qlock);
	/** 此时另外一个线程在signal之前，执行了process_msg，刚好把mp元素拿走*/
	pthread_cond_signal(&qready);
	/** 此时执行signal, 在pthread_cond_wait等待的线程被唤醒，
   但是mp元素已经被另外一个线程拿走，所以，workq还是NULL ,因此需要继续等待*/
}

为什么pthread_cond_wait需要加锁？

问题

• pthread_cond_wait中的mutex用于保护条件变量，调用这个函数进行等待条件的发生时,mutex会被自动释放，以供其它线程（生产者）改变条件，pthread_cond_wait中的两个步骤必须是原子性的(atomically,万恶的APUE中文版把这个单词翻译成了『自动』，误人子弟啊)，也就是说必须把两个步骤捆绑到一起：
  • 把调用线程放到条件等待队列上
  • 释放mutex
• 不然呢，如果不是原子性的，上面的两个步骤中间就可能插入其它操作。比如，如果先释放mutex，这时候生产者线程向队列中添加数据，然后signal,之后消费者线程才去『把调用线程放到等待队列上』，signal信号就这样被丢失了。
• 如果先把调用线程放到条件等待队列上，这时候另外一个线程发送了pthread_cond_signal（我们知道这个函数的调用是不需要mutex的），然后调用线程立即获取mutex，两次获取mutex会产生deadlock.

消费者线程中判断条件换成if可不可以呢？

问题

• 一个生产者可能对应着多个消费者，生产者向队列中插入一条数据之后发出signal，然后各个消费者线程的pthread_cond_wait获取mutex后返回，当然，这里只有一个线程获取到了mutex，然后进行处理，其它线程会pending在这里，处理线程处理完毕之后释放mutex，刚才等待的线程中有一个获取mutex，如果这里用if，就会在当前队列为空的状态下继续往下处理，这显然是不合理的。
• 再具体点，有可能多个线程都在等待这个资源可用的信号，信号发出后只有一个资源可用，但是有A，B两个线程都在等待，B比较速度快，获得互斥锁，然后加锁，消耗资源，然后解锁，之后A获得互斥锁，但A回去发现资源已经被使用了，它便有两个选择，一个是去访问不存在的资源，另一个就是继续等待，那么继续等待下去的条件就是使用while，要不然使用if的话pthread_cond_wait返回后，就会顺序执行下去。

signal到底是放在unlock之前还是之后？

问题

void enqueue_msg(struct msg *mp)
{
	pthread_mutex_lock(&qlock);
	mp->m_next = workq;
	workq = mp;
	pthread_mutex_unlock(&qlock);
	pthread_cond_signal(&qready);
}

如果先unlock，再signal,如果这时候有一个消费者线程恰好获取mutex，然后进入条件判断，这里就会判断成功，从而跳过pthread_cond_wait,下面的signal就会不起作用；另外一种情况，一个优先级更低的不需要条件判断的线程正好也需要这个mutex，这时候就会转去执行这个优先级低的线程，就违背了设计的初衷。

 void enqueue_msg(struct msg *mp)
{
	pthread_mutex_lock(&qlock);
	mp->m_next = workq;
	workq = mp;
	pthread_cond_signal(&qready);
	pthread_mutex_unlock(&qlock);
}

如果把signal放在unlock之前，消费者线程会被唤醒，获取mutex发现获取不到，就又去sleep了。浪费了资源.但是在LinuxThreads或者NPTL里面，就不会有这个问题，因为在Linux 线程中，有两个队列，分别是cond_wait队列和mutex_lock队列， cond_signal只是让线程从cond_wait队列移到mutex_lock队列，而不用返回到用户空间，不会有性能的损耗。
所以在Linux中推荐使用这种模式。

互斥量与条件变量

• 互斥量存在的问题：从本质上说互斥量就是一把锁，互斥量串行执行，能确保每次只有一个线程访问。互斥量是线程程序必需的工具，但它们并非万能的。例如，如果线程正在轮询等待共享数据内某个条件出现，那会发生什么呢？它可以重复对互斥对象锁定和解锁，每次都会检查共享数据结构，以查找某个值。但这是在浪费时间和资源，而且这种繁忙查询的效率非常低。同样，在每次检查之间让线程短暂地进入睡眠，比如睡眠3s，但是因此线程代码就无法最快作出响应。
• 条件变量通过允许线程阻塞和等待另一个线程发送信号的方法弥补了互斥锁的不足，条件变量常和互斥锁一起使用。使用时，条件变量被用来阻塞一个线程，当条件不满足时，线程往往解开相应的互斥锁并等待条件发生变化。一旦其它的某个线程改变了条件变量，它将通知相应的条件变量唤醒一个或多个正被此条件变量阻塞的线程。这些线程将重新锁定互斥锁并重新测试条件是否满足。

参考

1、https://www.cnblogs.com/harlanc/p/8596211.html
2、https://www.jb51.net/article/37413.htm
3、http://blog.chinaunix.net/uid-27164517-id-3282242.html
4、https://www.cnblogs.com/lemon-tree/p/5124153.html