首先关于条件变量的引入：
假想在这样的情况下，多个线程需要等待某个条件才能继续工作（如生产者消费者模型中，消费者需要等待流水线上有产品后才能消费），如果只使用互拆锁，则多个线程要不停的查询流水线是否为空这个状态，并且查询这个操作需要加入临界区，因为流水线不仅同时有多个消费者，还有生产者在生产，不加锁的话可能出现两个甚至多个消费者对同一个产品动手的情况。这种不停查询的操作是很蠢的，因此引入了条件变量，在查询条件不满足的情况下线程休眠，让出CPU。
为什么要传入互斥锁，与互斥锁配套使用？
首先，条件本身就是公共资源，如流水线的状态，因此必须使用互斥锁在临界区内对条件进行保护。
其次，pthread_cond_wait()操作实际上分为两步，第一步将线程挂在等待条件的线程列表上，然后对互斥锁解锁。
如果不传入这个互斥锁，实际上流程变为：
1.加锁
2.判断流水线状态
3.解锁
4.挂起线程
则在3与4间非原子，如果在3之后生产者线程生产了一个产品并进行了notify，而notify结束后这个消费者线程才挂起，则这个notify丢失了，只有生产者再生产一个产品才会唤醒它，如果只有一个消费者的话则这个notify完全丢失，如果有多个消费者则还可能被其他消费者所捕获，但逻辑上出现了问题。
为什么会出现虚假唤醒，为什么要用while来避免虚假唤醒？
虚假唤醒的出现在于生产者的notify并不在临界区内，也就是说，生产者使用临界区保护了修改流水线的这个操作，然后解锁，解锁完毕后才notify。而在这之间是非原子的。
在以下情况：
1).生产者对临界区加锁
2).修改流水线状态
3).生产者解锁
4).notify通知生产者线程
在3)与4)间是有空隙的，如果在3)进行后突然此刻加入了一个新的生产者，这个生产者察觉到流水线的变化，对他进行了消费，然后消费者才notify,notify唤醒了原有的消费者， 但流水线已经为空了，实际上这就是一个虚假唤醒，唤醒后并无工作可做。
因此不能用if来进行条件判断，加入while就可以避免虚假唤醒，在每次唤醒后先判断流水线条件，这样避免了虚假唤醒的情况。