这是来自知乎的一个问题，由@吴志强提出，有意思的是，他看了大家的回答后，突然顿悟了，同一时候也发现有人答错了，于是乎。他自己回答了自己的问题。
我看完后。发现他分析的非常精彩，于是就记录在这。以下是他的自答：
-----------------------------------------------------------------------------
看了之后，我获得了启示，突然认为这也许是跟条件变量的通经常使使用方法有关。首先须要明确两点：
- wait()操作通常伴随着条件检測。如：
while(pass == 0)pthread_cond_wait(...); - signal*()函数通常伴随着条件改变，如：
pass = 1;pthread_cond_signal(...)
所以代码会变成以下这样：
// 条件測试 pthread_mutex_lock(mtx);while(pass == 0)pthread_cond_wait(...);pthread_mutex_unlock(mtx);// 条件发生改动，相应的signal代码pthread_mutex_lock(mtx);pass = 1;pthread_mutex_unlock(mtx);pthread_cond_signal(...);然后，我们如果wait()操作不会自己主动释放、获取锁。那么代码会变成这样：
// 条件測试 pthread_mutex_lock(mtx);while(pass == 0) {pthread_mutex_unlock(mtx);pthread_cond_just_wait(cv);pthread_mutex_lock(mtx);}pthread_mutex_unlock(mtx);// 条件发生改动，相应的signal代码pthread_mutex_lock(mtx);pass = 1;pthread_mutex_unlock(mtx);pthread_cond_signal(cv);久而久之，程序猿发现unlock, just_wait, lock这三个操作始终得在一起。于是就提供了一个pthread_cond_wait()函数来同一时候完毕这三个函数。
另外一个证据是，signal()函数是不须要传递mutex參数的。所以关于mutex參数是用于同步wait()和signal()函数的说法更加站不住脚。
所以我的结论是：传递的mutex并非为了防止wait()函数内部的Race Condition。而是由于调用wait()之前你总是获得了某个mutex（比如用于解决此处pass变量的Race Condition的mutex），而且这个mutex在你调用wait()之前必须得释放掉，调用wait()之后必须得又一次获取。
所以。pthread_cond_wait()函数不是一个细粒度的函数，却是一个有用的函数。
------------------------------------------------------------------------------------------------------------------------------------