主要翻抄自陈硕的书和博客
条件变量只有一种正确使用的方式，几乎不可能用错。
对于 wait 端：
1.必须与 mutex 一起使用，该布尔表达式的读写需受此 mutex 保护。
2.在 mutex 已上锁的时候才能调用 wait()。
3.把判断布尔条件和 wait() 放到 while 循环中。
对于 signal/broadcast 端：
1.不一定要在 mutex 已上锁的情况下调用 signal （理论上）。
2.在 signal 之前一般要修改布尔表达式。
3.修改布尔表达式通常要用 mutex 保护（至少用作 full memory barrier）。
4.注意区分 signal 与 broadcast：“broadcast 通常用于表明状态变化，signal 通常用于表示资源可用。（broadcast should generally be used to indicate state change rather than resource availability。）”
只要记住 Pthread 的条件变量是边沿触发（edge trigger），即 signal()/broadcast() 只会唤醒已经等在 wait() 上的线程(s)，我们在编码时必须要考虑 signal() 早于 wait() 的可能
判断以下各个版本的正误:
https://github.com/chenshuo/recipes/blob/master/thread/test/Waiter_test.cc
为什么要跟mutex一起使用
pthread_cond_wait = 原子（mutex_unlock + wait）
mutex保护条件，如果用两个 mutex，一个用于保护“条件”，另一个专门用于和 cond 配合 wait()，相当于人为拆分成mutex_unlock，wait两步。这样可能丢失事件（unlock和wait之间发生signal）
总结：使用条件变量，调用 signal() 的时候无法知道是否已经有线程等待在 wait() 上。因此一般总是要先修改“条件”，使其为 true，再调用 signal()；这样 wait 线程先检查“条件”，只有当条件不成立时才去 wait()，避免了丢事件的可能。换言之，通过使用“条件”，将边沿触发（edge trigger）改为电平触发（level trigger）。这里“修改条件”和“检查条件”都必须在 mutex 保护下进行，而且这个 mutex 必须用于配合 wait()。
如果未在代码路径中锁定互斥锁以更改条件和信号，则可能会丢失唤醒。考虑这对过程：
//流程A：
pthread_mutex_lock(&mutex);
while (condition == FALSE)
pthread_cond_wait(&cond, &mutex);
pthread_mutex_unlock(&mutex);
//流程B（不正确）：
condition = TRUE;
pthread_cond_signal(&cond);
然后考虑这种可能的指令顺序，其condition开头为FALSE：
| Process A | Process B |
|---|---|
| pthread_mutex_lock(&mutex); | |
| while (condition == FALSE) | |
| condition = TRUE; | |
| pthread_cond_signal(&cond); | |
| pthread_cond_wait(&cond, &mutex); |
现在condition是TRUE，但是进程A仍在等待条件变量 - 它错过了唤醒信号。
如果我们正确的处理了互斥锁：
流程B（正确）：
pthread_mutex_lock(&mutex);
condition = TRUE;
pthread_cond_signal(&cond);
pthread_mutex_unlock(&mutex);
那么上面的错误场景就不会发生。
虚假唤醒
在wait端必须使用while来等待条件变量而不能使用if语句，原因在于spurious wakeups,即虚假唤醒。
虚假唤醒很容易被人误解为：如果有多个消费者，这些消费者可能阻塞在同一位置。当生产者通知not empty时，duque立即被第一个被唤醒的消费者清空，则后面的消费者相当于时被虚假唤醒了。
这种情况完全可以通过使用signal而非broadcast解决。signal只会唤醒某个线程，唤醒的依据为等待线程的优先级，若优先级相同，则依据线程的等待时长。
上述现象类似于惊群现象：
惊群效应就是当一个fd的事件被触发时，所有等待这个fd的线程或进程都被唤醒。一般都是socket的accept()会导致惊群（当然也可以弄成一堆线程/进程阻塞read一个fd，但这样写应该没什么意义吧），很多个进程都block在server socket的accept()，一但有客户端进来，所有进程的accept()都会返回，但是只有一个进程会读到数据，就是惊群。实际上现在的Linux内核实现中不会出现惊群了，只会有一个进程被唤醒（Linux2.6内核）。
虚假唤醒的正解是：指的是一次 signal() 调用唤醒两个或以上 wait()ing 的线程，或者没有调用 signal() 却有线程从 wait() 返回。
wikipedia中有关于spurious wakeups的大致描述：https://en.wikipedia.org/wiki/Spurious_wakeup。前半部分的描述不甚清楚。重点在于最后的一段话。
According to David R. Butenhof's Programming with POSIX Threads ISBN 0-201-63392-2:
"This means that when you wait on a condition variable,the wait may (occasionally) return when no thread specifically broadcast or signaled that condition variable.Spurious wakeups may sound strange, but on some multiprocessor systems, making condition wakeup completely predictable might substantially slow all condition variable operations. The race conditions that cause spurious wakeups should be considered rare."
其中提到，即使没有线程broadcast 或者signal条件变量，wait也可能偶尔返回。
signal与unlock的顺序
(1) 按照 unlock(mutex); condition_signal()顺序， 当等待的线程被唤醒时，因为mutex已经解锁，因此被唤醒的线程很容易就锁住了mutex然后从conditon_wait()中返回了。
(2) 按照 condition_signal(); unlock(mutext)顺序，当等待线程被唤醒时，它试图锁住mutex,但是如果此时mutex还未解锁，则线程又进入睡眠，mutex成功解锁后，此线程在再次被唤醒并锁住mutex，从而从condition_wait()中返回。
（但是在LinuxThreads或者NPTL里面，就不会有这个问题，因为在Linux 线程中，有两个队列，分别是cond_wait队列和mutex_lock队列， cond_signal只是让线程从cond_wait队列移到mutex_lock队列，而不用返回到用户空间，不会有性能的损耗。
顺序1
pthread_mutex_lock
xxxxxxx
pthread_cond_signal
pthread_mutex_unlock
缺点：在某下线程的实现中，会造成等待线程从内核中唤醒（由于cond_signal)然后又回到内核空间（因为cond_wait返回后会有原子加锁的行为），所以一来一回会有性能的问题。
在code review中，我会发现很多人喜欢在pthread_mutex_lock()和pthread_mutex_unlock(()之间调用 pthread_cond_signal或者pthread_cond_broadcast函数，从逻辑上来说，这种使用方法是完全正确的。但是在多线程环境中，这种使用方法可能是低效的。posix1标准说，pthread_cond_signal与pthread_cond_broadcast无需考虑调用线程是否是mutex的拥有者，也就是说，可以在lock与unlock以外的区域调用。如果我们对调用行为不关心，那么请在lock区域之外调用吧。这里举个例子：
我们假设系统中有线程1和线程2，他们都想获取mutex后处理共享数据，再释放mutex。请看这种序列：
1)线程1获取mutex，在进行数据处理的时候，线程2也想获取mutex，但是此时被线程1所占用，线程2进入休眠，等待mutex被释放。
2)线程1做完数据处理后，调用pthread_cond_signal（）唤醒等待队列中某个线程，在本例中也就是线程2。线程1在调用pthread_mutex_unlock（）前，因为系统调度的原因，线程2获取使用CPU的权利，那么它就想要开始处理数据，但是在开始处理之前，mutex必须被获取，很遗憾，线程1正在使用mutex，所以线程2被迫再次进入休眠。
3)然后就是线程1执行pthread_mutex_unlock（）后，线程2方能被再次唤醒。
从这里看，使用的效率是比较低的，如果再多线程环境中，这种情况频繁发生的话，是一件比较痛苦的事情。
但是在LinuxThreads或者NPTL里面，就不会有这个问题，因为在Linux 线程中，有两个队列，分别是cond_wait队列和mutex_lock队列， cond_signal只是让线程从cond_wait队列移到mutex_lock队列，而不用返回到用户空间，不会有性能的损耗。
所以在Linux中推荐使用这种模式。
顺序2
pthread_mutex_lock
xxxxxxx
pthread_mutex_unlock
pthread_cond_signal
优点：不会出现之前说的那个潜在的性能损耗，因为在signal之前就已经释放锁了
缺点：如果unlock和signal之前，有个低优先级的线程正在mutex上等待的话，那么这个低优先级的线程就会抢占高优先级的线程（cond_wait的线程)，而这在上面的放中间的模式下是不会出现的。
所以，在Linux下最好pthread_cond_signal放中间，但从编程规则上说，其他两种都可以
