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()互斥性的錯覺。
pthread cond 執行緒條件變數
條件變數 pthread cond，另外一種執行緒間的同步機制。普通的 mutex 只允許乙個執行緒進入臨界區，就是拿到mutex這把鎖的執行緒，而cond 允許多個執行緒同時進入臨界區，由它來控制，在某些條件成立的時候，來喚醒其中乙個等待著的執行緒，或者是喚醒所有等待著的執行緒。int pthre...
條件變數 pthread cond init
include int pthread cond init pthread cond t cv,const pthread condattr t cattr 返回值 函式成功返回0 任何其他返回值都表示錯誤初始化乙個條件變數。當引數cattr為空指標時，函式建立的是乙個預設的條件變數。否則條件變數的...
條件變數 pthread cond init
include int pthread cond init pthread cond t cv,const pthread condattr t cattr 返回值 函式成功返回0 任何其他返回值都表示錯誤初始化乙個條件變數。當引數cattr為空指標時，函式建立的是乙個預設的條件變數。否則條件變數的...