深入理解 pthread_cond_wait()

在多线程同步互斥的应用场景下，通常会用到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)的原因了，因此正常申请条件变量的线程的流程应该如下：

至于释放条件变量，理解了上边的内部机制之后，其实在释放条件变量之前就不需要申请锁再释放锁了。

这里要特别提到的一点是，按照上面正确申请条件变量的的流程，仍然存在多个等待条件变量的线程同时执行步骤b出等待，此时如果有信号释放，就会唤醒多个线程。这也就是为什么手册上说pthread_cond_signal(cv)至少唤醒一个在等待cv的线程（可以计数资源为1）的原因了。

参考文档和手册：

man pthread_cond_signal

本文转自存储之厨51CTO博客，原文链接：http://blog.51cto.com/xiamachao/1952614 ，如需转载请自行联系原作者