在多线程同步互斥的应用场景下，通常会用到pthread_cond_wait()和pthread_cond_signal()函数。那么这两个函数到底是如何保证互斥同步的呢？
为了对上面的问题有个直观的了解，可以从下面的问题着手。下面两段这些程序有什么bug么？
a. 等待条件的线程执行的代码：
Thread
1:
{
……………………..
pthread_cond_wait(cv,
mutex);
do_worker_task();
……………………..
}
b.唤醒等待线程的代码：
{
pthread_mutex_lock(mutx);
pthread_cond_signal(cv)
pthread_mutex_unlock(mutex);
}
要知道上面代码问题在哪，关键是必须对pthread_cond_wait()有深入的了解。为了对这个函数又直观的了解，下面给出了pthread_cond_wait(cv,
mutex)正常执行过程中的几个重要子步骤伪码：
pthread_cond_wait(cv,
mutex) 实际做的事情：
a.
pthread_mutex_unlock(mutex);
b.
do_real_cond_wait(cv); // 可能在这阻塞直到其他线程调用pthread_cond_signal(cv)或者 pthread_cond_broadcast(cv)，才会往下执行
c.
pthread_mutex_lock(mutex);
结合在多处理器、多线程、高并发的环境下，上面三个步骤就显得缺一不可，才能保证尽可能地互斥：
步骤a:保证其他线程此后也有等待、申请条件变量的同等机会
步骤b:在条件变量还没就绪的情况下，执行真正的阻塞
步骤c:当前线程得到条件变量之后，阻止其他等待条件变量的线程继续往下执行，而自己可以往下执行。
那么问题来了，考虑步骤c，如果单独一句pthread_cond_wait(cv,
mutex)是无法确保线程尽可能互斥的，这就是为何在执行pthread_cond_wait()之前要求有pthread_mutex_lock(mutx)的原因了，因此正常申请条件变量的线程的流程应该如下：
Thread
1:
{
pthread_mutex_lock(mutx);
pthread_cond_wait(cv,
mutex);
do_worker_task();
pthread_mutex_unlock(mutex);
}
至于释放条件变量，理解了上边的内部机制之后，其实在释放条件变量之前就不需要申请锁再释放锁了。
这里要特别提到的一点是，按照上面正确申请条件变量的的流程，仍然存在多个等待条件变量的线程同时执行步骤b出等待，此时如果有信号释放，就会唤醒多个线程。这也就是为什么手册上说pthread_cond_signal(cv)至少唤醒一个在等待cv的线程（可以计数资源为1）的原因了。
参考文档和手册：
man
pthread_cond_signal