我相信互斥锁并不足够，这就是条件变量存在的原因；但我还没有能够用具体场景说服自己必须要用条件变量。
条件变量、互斥锁和锁之间的区别问题的被接受答案指出，条件变量是带有“信号”机制的锁。它在线程需要等待资源可用时使用。一个线程可以"等待"一个条件变量，然后资源生成者可以"signal"这个变量，此时等待条件变量的线程会得到通知并且可以继续执行。
让我感到困惑的是，一个线程也可以等待互斥锁，在它被唤醒后，变量就变为可用了，那我为什么需要一个条件变量呢？
P.S.: 而且，无论如何都需要一个互斥锁来保护条件变量，这让我更难以理解条件变量的作用。
Thread1:
while(1) {
lock(mutex); // Blocks waiting for notification from Thread2
... // do work after notification is received
unlock(mutex); // Tells Thread2 we are done
}
线程2：
while(1) {
... // do the work that precedes notification
unlock(mutex); // unblocks Thread1
lock(mutex); // lock the mutex so Thread1 will block again
}
这段代码存在几个问题：
这两个问题都不是小问题，事实上，它们都是主要的设计缺陷和潜在的错误。这两个问题的根源在于互斥体需要在同一个线程中锁定和解锁。那么如何避免以上问题呢？使用条件变量！
顺便说一句，如果您的同步需求确实很简单，您可以使用普通的信号量，这样可以避免使用条件变量所带来的额外复杂性。
互斥锁是用于访问共享资源的独占锁，而条件变量是等待某个条件成立的锁。它们是两种不同类型的内核资源。一些人可能认为可以通过互斥锁自己实现条件变量，一个常见的模式是“标志 + 互斥锁”：
lock(mutex)
while (!flag) {
sleep(100);
}
unlock(mutex)
do_something_on_flag_set();
但这是行不通的，因为您在等待期间从未释放互斥锁，没有其他人可以以线程安全的方式设置标志。这就是我们需要内核支持条件变量的原因，因此当您在等待条件变量时，关联的互斥锁不会被您的线程保持，直到它被信号通知。
我也在思考这个问题，我认为到处都缺少的最重要信息是互斥锁只能由一个线程拥有（或更改）。因此，如果你只有一个生产者和多个消费者，则生产者必须在互斥锁上等待以进行生产。而使用条件变量，则可以随时进行生产。
import threading, time, random
cv = threading.Condition()
buffer = []
MAX = 3
def put(value):
cv.acquire()
while len(buffer) == MAX:
cv.wait()
buffer.append(value)
print("added value ", value, "length =", len(buffer))
cv.notify()
cv.release()
def get():
cv.acquire()
while len(buffer) == 0:
cv.wait()
value = buffer.pop()
print("removed value ", value, "length =", len(buffer))
cv.notify()
cv.release()
def producer():
while True:
put(0) # it doesn't mater what is the value in our example
time.sleep(random.random()/10)
def consumer():
while True:
get()
time.sleep(random.random()/10)
if __name__ == '__main__':
cs = threading.Thread(target=consumer)
pd = threading.Thread(target=producer)
cs.start()
pd.start()
cs.join()
pd.join()
依我之见，或许你可以使用 两个互斥锁 来实现 互斥锁 + 条件变量
以下是具体步骤：
pthread_cond_wait(&cond_var, &mutex) 替换为pthread_mutex_unlock(&mutex);
pthread_mutex_trylock(&mutex_new);
pthread_mutex_lock(&mutex_new);
pthread_mutex_lock(&mutex);
pthread_cond_signal(&cond_var)：pthread_mutex_unlock(&mutex_new);
pthread_mutex_unlock(&mutex);
producer signal!
pthread_mutex_trylock(&mutex_new);
我认为这是实现定义的。
互斥锁是否足够取决于你是否将互斥锁视为临界区的机制或其他更多的东西。
正如在http://en.cppreference.com/w/cpp/thread/mutex/unlock中提到的：
互斥锁必须由当前执行线程锁定，否则行为是未定义的。
这意味着在C++中，一个线程只能解锁自己锁定/拥有的互斥锁。
但在其他编程语言中，你可能可以在进程之间共享互斥锁。
因此，区分这两个概念可能只是性能考虑，对于简单应用程序来说，复杂的所有权识别或进程间共享并不值得。
lock(mutex0);
while(1) {
lock(mutex0); // Blocks waiting for notification from Thread2
... // do work after notification is received
unlock(mutex1); // Tells Thread2 we are done
}
线程2：
while(1) {
lock(mutex1); // lock the mutex so Thread1 will block again
... // do the work that precedes notification
unlock(mutex0); // unblocks Thread1
}
但是你的程序会抱怨你触发了编译器留下的断言（例如，在Visual Studio 2015中的“解锁未拥有的互斥体”）。