出自一個unix鎖的問題解答
在unix上做C的開發已經快2年了，一直在我們部門的一個主要產品項目組工作，該產品在大部分客戶那里一直穩定的運行，沒有任何問題，而在少數幾個客戶那里，時不時的出現整個系統的吊死，而且該問題沒有任何規律可尋，除了系統吊死時候，我們對整個系統用pstack進行所有進程堆棧的跟蹤記錄外，我們沒有任何其它線索，沒有系統崩潰時候產生的CORE，我們開始面對來自客戶強大的壓力。
我開始被指派來解決這個問題。其實我們很早的就從進程的堆棧跟蹤里知道這個問題是死unix鎖問題，但是，它是怎么發生的那，我們幾乎排查了整個系統的代碼，但是一無所獲。
我們知道，當主線程退出的時候，操作系統會直接終止該進程里面的其它線程，不會留任何機會讓那個線程做退出處理。而那個線程可能恰恰剛剛獲的了unix鎖，而還沒來得及解鎖，就被扼殺了，于是就造成了其它進程或線程再加這個unix鎖的時候，就會被阻塞，系統死鎖問題也就浮現了出來。
當然，我知道了是競態條件問題造成了死unix鎖，就會通過pthread_join來同步等待那個線程退出，來消除這個競態條件，也就消除了死鎖，問題其實也就解決了。但是，我們有沒有辦法來消除由于一個unix鎖的owner沒有釋放該unix鎖，就死掉了，其它線程再加這個鎖的時候而造成的死鎖問題那？
關于上面這個問題，我曾經請教過很多人，有的人想通過一個網絡unix鎖（就是加鎖、解鎖都要訪問網絡上的一臺機器）來解決，但是這些方法都不成熟，也很復雜，也好像有高手對這個問題不屑。我通過搜集很多資料發現，原來解決這個問題非常的簡單，簡單的不能在簡單了。
在很多系統上，當一個鎖的owner沒有釋放該unix鎖，就退出了，那么默認的方式就是其它線程再去加這個unix鎖的時候，就會阻塞，造成死鎖。而通過不同的屬性初始化這個鎖，我們能夠改變這種默認的方式：
- pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
- pthread_mutexattr_setrobust_np(&mattr,PTHREAD_MUTEX_ROBUST_NP);
通過設置鎖的上面兩個屬性，我們就改變了默認的行為，當一個unix鎖的owner死掉后，其它線程再去加這個鎖的時候，不會被阻塞，而是通過返回值EOWNERDEAD來報告錯誤，那么你可以根據這個錯誤來進行處理：首先是應該調用pthread_mutex_consistent_np函數來恢復該鎖的一致性，然后調用解鎖pthread_mutex_unlock，接下來在調用加鎖，這樣該鎖的行為就恢復正常了。
如果上面這個函數在恢復unix鎖的一致性時候沒有成功，那么你只需要調用解鎖函數就OK了，然后直接返回，而不要去調用加鎖函數，那么接下來的線程在調用加鎖函數的時候，會得到返回值ENOTRECOVERABLE，那么需要你做的就是調用pthread_mutex_destroy來destroy掉該鎖，然后重新用鎖的屬性和unix鎖的初始化函數來重新初始化該鎖。
上面的這些解決死unix鎖方式比較適合在系統中只有一個鎖的情況，如果系統的死鎖是由于多把鎖的資源互相等待而造成的，那么這種解決方式無能為力。
注：上面有一些函數后面有np后綴的，表示not portable，就是不可移值的意思，這些函數是一些系統自己實現的，而不是POSIX標準。
【編輯推薦】
