条件变量笔记
1 ,先解锁再唤醒条件变量,和先唤醒条件变量再解锁,哪个好
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(先唤醒再解锁,,例子也是这么写的)
pthread_cond_signal(&empty);
pthread_mutex_unlock(&lock);1）先解锁互斥锁，再唤醒睡眠的线程。
优点：减少了线程再内核态了用户态切换的次数，减少了资源的消耗。因为唤醒线程和解锁，都是需要再内核态完成的，而先解锁，再唤醒，内核会一次将这两个操作完成，这样就减少了用户态和内核态切换的次数，从而节省了资源。
缺点：如果此时存在一个低优先级的线程在等待锁，那么一旦锁被释放，那么这个锁就会被低优先级的线程争抢去，而不会被wait的线程得到，导致wait线程阻塞，无法返回。 , 只有本线程和要唤醒的线程,竞争这把锁的时候,,,,就不会存在这种情况.
（2）先唤醒睡眠的线程，再解锁互斥锁。
优点：唤醒后的线程在等待为该互斥锁加锁，一旦锁被释放，wait线程就会立即加锁，而不会发生上述，锁被抢占额度情况。
缺点：会增加用户态到内核态切换的次数，增加资源的消耗。
虽然在语法这两个都可以，但一般在程序使用先唤醒，再解锁的方式。
2. 虚假唤醒
// wait端
pthread_mutex_lock(mtx);
while(deque.empty())
pthread_cond_wait(...);
deque.pop_front();
pthread_mutex_unlock(mtx);
// signal端
pthread_mutex_lock(mtx);
deque.push_back(x);
pthread_cond_signal(...);
pthread_mutex_unlock(mtx);在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内核）。
虚假唤醒的正解是：
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也可能偶尔返回。