条件变量 pthread_cond

[APUE] 条件变量 pthread_cond

Posted on August 4, 2013

早起翻APUE，查缺补漏。书接上回，看到“条件变量”，七八年前看过，有点模糊的印象。不过还是有些地方解释不过去，看来我当年也只是“看了”但是“没理解”。

根据后面的示例代码，enqueue_msg()和process_msg()因为都调用pthread_mutex_lock要锁住互斥量mutex，那它们应该是互斥的关系。则，若process_msg()先运行，并wait在pthread_cond_wait()，这时候该函数一直锁住着mutex，其它比如enqueue_msg()没法去获得这个mutex以运行。process_msg()等待着队列非空才继续，然后才会解锁mutex，而enqueue_msg()则可以使队列非空，但是现在缺没法获得mutex以运行，这样企不是死锁了。

Google了一下，在“MemoryGarden’s Blog”，用开头的一句话，把这事点明白了。“普通的 mutex 只允许一个线程进入临界区，就是拿到mutex这把锁的线程，而cond允许多个线程同时进入临界区，由它来控制，在某些条件成立的时候，来唤醒其中一个等待着的线程，或者是唤醒所有等待着的线程。”。再结合APUE书上所说，就可以整理出思路了：

1. 通常情况下pthread_mutex_lock()互斥排他性的锁住mutex。即有一个线程锁住了mutex，则其它线程都得等着前面那个线程解锁才行。
2. 在使用cond的时候，上面条目1所述不变，pthread_mutex_lock()依然是互斥排他的。不过pthread_cond_wait()让整体代码和流程看起来是打破了pthread_mutex_lock()的互斥性，其实是pthread_cond_wait()隐藏了一些实现细节。
pthread_cond_wait()有目的性的接收mutex作为参数，其实是调用pthread_cond_wait的时候做了两件事，一是将调用线程放到等待队列的线程列表上，二是对互斥量mutex解锁。然后，当wait_timeout或pthread_cond_signal()唤醒等待条件的线程时，使pthread_cond_wait()函数返回，返回的时候又把互斥量mutex给锁上了（当然是在内部偷偷实现的）。pthread_cond_wait()偷摸的内地里背后里悄悄的做了解锁mutex和又锁定mutex的过程，给调用者一种它打破pthread_mutex_lock()互斥性的错觉。