解鎖函數(shù)pthread_mutex_unlock什么情況會失敗返回？

UCfree

在開發(fā)的項目中遇到一個非常怪異的問題，服務(wù)端運行好幾天處理了大量的業(yè)務(wù)，表現(xiàn)算穩(wěn)定。但是今天凌晨出現(xiàn)了不響應(yīng)的情況，分析日志發(fā)現(xiàn)是死鎖了。 可以確定的是這種死鎖不是邏輯上的錯誤導致的死鎖。

在鎖的使用上我本著鎖定盡可能少的代碼的原則，所以加鎖和解鎖之間都是執(zhí)行了少量的代碼(里面也不會有嵌套的函數(shù))。可以說pthread_mutex_lock和pthread_mutex_unlock是成對出現(xiàn)的。所以我可以確定沒有邏輯上的死鎖問題。

唯一的瑕疵是，我調(diào)用pthread_mutex_lock和pthread_mutex_unlock沒有判斷返回值。加鎖pthread_mutex_lock是不需要判斷返回值的，因為它阻塞直到可以鎖定為止，一般不會有失敗的情況。按理說，既然加鎖成功了，那執(zhí)行玩代碼后接著解鎖也一定能成功，所以解鎖也無需判斷返回值吧？
并且我認為對加鎖解鎖判斷返回值是沒什么意義的，即使返回了錯誤，那你又該如何處理？難道就放棄執(zhí)行后面的代碼了嗎？

我項目中的這個死鎖問題很可能是pthread_mutex_unlock調(diào)用失敗了，導致下次加鎖時死鎖了。不知道大家是否遇到過這樣的情況，如果遇到了又是如何處理的呢？

bottles

吧mutex的屬性從PTHREAD_MUTEX_NORMAL改成PTHREAD_MUTEX_ERRORCHECK試試，然后做個判斷檢查，一旦已經(jīng)鎖住返回err，就打印到Log里面去。PTHREAD_MUTEX_NORMAL當當前線程已經(jīng)有鎖了再鎖一次應(yīng)該就會被鎖住的，而PTHREAD_MUTEX_ERRORCHECK會直接返回error。

       If the mutex type is PTHREAD_MUTEX_NORMAL, deadlock detection shall not be provided. Attempting to relock the mutex  causes  deadlock.
       If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, undefined behavior results.

       If  the  mutex type is PTHREAD_MUTEX_ERRORCHECK, then error checking shall be provided. If a thread attempts to relock a mutex that it
       has already locked, an error shall be returned. If a thread attempts to unlock a mutex that it has not locked  or  a  mutex  which  is
       unlocked, an error shall be returned.

UCfree

回復(fù) 2# bottles


默認是PTHREAD _MUTEX_DEFAULT吧。 這種狀態(tài)如果還有加鎖，是在隊列里排隊的，解鎖了就會讓隊首的線程先加鎖。

linux_c_py_php

double lock? double unlock ? non-initial-mutex?

bottles

會不會由于某個線程響應(yīng)了cancel pthread的消息然后退出了，但是這個時候鎖還沒有解鎖，然后這個鎖就一直掛在那里了。

fly3ds

嗯  線程的東西向來難搞！    不過我認為你還是加上解鎖失敗檢查返回值的代碼，下次失敗了，能看到錯誤信息，即使
不能最終解決問題也是能有收獲的！

我還是認為能用多進程，盡量不要用多線程。這次找出問題了，下次換臺機器，換個Linux內(nèi)核版本，或者換到Solaris FreeBSD，出錯的概率很大。

UCfree

回復(fù) 6# fly3ds


   哎   用多進程的毛病就是通信問題，我這種需求太復(fù)雜，只能這樣設(shè)計。 主進程既有單獨傳遞給每個連接的數(shù)據(jù)，也有廣播給每個連接的數(shù)據(jù)，如果一個連接一個進程，那么要創(chuàng)建N個共享內(nèi)存/socket/pipe？  一個連接一個進程一般適用于跟父進程無額外的業(yè)務(wù)交流比較合適吧。

  所以選擇多線程是比較好的方法，只要自定義數(shù)據(jù)結(jié)構(gòu)，所有的線程放在一個list里面進行輪詢就好了。這里要擔心的就是這個list有添加、刪除、讀取、修改時，都要鎖定。 我這個需要有較多個線程來競爭這把鎖，只是我也想不出更好的模式了。

UCfree

回復(fù) 6# fly3ds


    我這種需求的連接其實是雙向服務(wù)的，既要處理來自客戶端的指令(socket通信就OK了)，還有響應(yīng)來自服務(wù)端其他模塊的觸發(fā)指令(這里我選擇了自己實現(xiàn)的緩沖隊列通信模式，而拋棄了進程選擇線程)。

UCfree

回復(fù) 5# bottles


    嗯，分析過這種情況，沒發(fā)現(xiàn)前面的指令有沒處理完就退出的，都有完成工作了。

UCfree

回復(fù) 4# linux_c_py_php


    不至于同一個線程內(nèi)重復(fù)鎖定，重復(fù)解鎖也不會(這種情況就像重復(fù)free一樣會引起崩潰)。 未初始化更不至于，倒是又可能其他變量越界，修改了互斥鎖的內(nèi)容(這種問題是我懷疑的，也是最麻煩的)。