在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標准。