参考博客：https://blog.csdn.net/xmm12508/article/details/80977491
之前一直以为条件变量在pthread_cond_wait时会一直持有互斥量，后来看到陈硕的书上的例子，发现如果是这样会很容易造成死锁，因此才考虑到是自己想错了，于是在网上搜索了资料终于弄明白了是怎么回事
第一点：条件变量在pthread_cond_wait状态不持有互斥锁
条件变量进入pthread_cond_wait可分为三个步骤：
pthread_cond_wait(&cond, &cmutex)= { 1、pthread_mutex_unlock(&cmutex); 2、 pthread_cond_wait();等待唤醒，唤醒后再加锁，这样通知条件变量的语句才有机会加锁 3、pthread_mutex_lock(&cmutex); }可以看出，进入wait状态时，会首先释放互斥锁，之后线程阻塞等待唤醒，释放了锁使得唤醒条件变量的线程有机会加锁执行。在这种情况下，我们可以想到该线程释放锁之后，如果没有线程抢占并发送信号激活条件变量，其他消费者线程（与本线程功能一样）就会抢占锁，也会进入wait状态，这样如果长时间没有激活条件变量的信号，就会有多个线程处于被激活状态。这样一个信号到来就会使这多个进程抢占资源产生竞争。
第二点：互斥锁的作用
与条件变量配套使用的互斥锁作用有很多，首先互斥锁保护了queue变量的临界区，看下面代码可以知道，lock加锁解锁中间就是queue的临界区。
int dequeue() { MutexLockGuard lock(mutex); //互斥锁，枷锁 while (queue.empty()) { //wait 第一部分,解锁 cond.wait(); //wait第二部分，阻塞，等待信号激活 //wait第三部分，抢占加锁 } ...... }其次，互斥锁也保护了条件变量避免受到惊群影响
多线程程序中，在使用条件变量前添加互斥锁使得同一时间只有一个线程获得了锁，其他线程处于未得到锁处于阻塞状态节省了系统资源，获得锁的线程进入pthread_cond_wait状态并释放锁，接着要么能获得信号并加锁开始执行业务，要么阻塞在wait状态，其他线程抢占锁，添加互斥锁总能保证获得唤醒的线程均在执行业务，空闲线程都处于阻塞状态
另外上面说的可能存在多个线程处于wait状态，这些线程均能接收到某个线程发来的pthread_cond_signal或者pthread_cond_broadcast，但是由于互斥锁的存在，收到信号的线程被唤醒后立刻抢占互斥锁，其他收到信号的线程再次被阻塞，这样避免了惊群问题。抢占到锁的线程开始处理业务，其他线程继续等待信号。
第三，条件变量为啥使用while而不是if
原因是即使没有线程调用condition_signals，原先调用condition_wait的函数也有可能返回。此时线程被唤醒了，但是条件不满足，如果此时不对条件进行检查而继续往下执行，就可能会导致后续的处理出现错误。
