關於pthread_mutex_lock和pthread_mutex_unlock的一些問題

當一個線程獲得了鎖並執行下面的代碼時，線程是否可以使用return語句來解鎖它所獲取的鎖？一些這樣的代碼。關於pthread_mutex_lock和pthread_mutex_unlock的一些問題

static pthread_mutex_t mutex; 

    int foo() 
    { 
     pthread_mutex_lock(mutex); 

     ......... 
     execute some code here and some errors happen 
       return -1;// but without pthread_mutex_unlock 

     pthread_mutex_unlock(mutext) 
     return 0; 
    }

某些錯誤發生在pthread_mutex_unlock語句和線程返回給被調用者之前。線程是否會返回其他線程的mutext鎖而不執行pthread_mutex_unlock？

來源

2010-09-13 terry

如果它自動解鎖，如何從鎖定互斥鎖的函數返回？你怎麼能寫一個函數，其目的是選擇正確的互斥鎖並鎖定它？ – 2011-08-30 13:09:27

不，它不會自動解鎖互斥鎖。如果互斥鎖已被該函數鎖定，則必須在錯誤路徑中明確呼叫pthread_mutex_unlock()。

來源

2010-09-13 07:10:43 caf

不，鎖不會自動釋放。這就是爲什麼在C++代碼中，通常使用資源獲取初始化（RAII），它利用構造/銷燬來確保每個對鎖定函數的調用都有相應的解鎖呼叫。但是，如果您正在編寫純C代碼，則需要確保在返回之前即使在錯誤情況下解鎖互斥鎖。

請注意，你可以讓你的編碼通過執行以下操作更容易些：

static inline int some_function_critical_section_unsynchronized(void) { 
     // ... 
    } 
    int some_function(void) { 
     int status = 0; 
     pthread_mutex_lock(mutex); 
     status = some_function_critical_section_unsynchronized(); 
     pthread_mutex_unlock(mutex); 
     return status; 
    }

換句話說，如果你能邏輯分成更小的功能，你可以梳理出鎖定來自你的邏輯的代碼。當然，有時候這是不可能的（比如，當以這種方式進行編碼會使關鍵部分太大，並且對於性能而言，需要不太可讀的形式）。

如果您可以使用C++，我強烈建議使用boost :: thread和boost :: scoped_lock來確保獲取的互斥量在使用超出範圍時自動釋放。

來源

2010-09-13 07:11:03

關於pthread_mutex_lock和pthread_mutex_unlock的一些問題

回答

相關問題