pthread_mutex_lock和pthread_mutex_lock在另一個線程中

Question

我在一個線程中調用了pthread_mutex_lock(&th) ，然后我想在另一個線程中解鎖互斥鎖pthread_mutex_unlock(&th)

有可能這樣做嗎？

還是應該在同一線程中解鎖互斥鎖？

Answer 1

它應該在同一線程中解鎖。 在手冊頁中：“如果線程嘗試解鎖尚未鎖定的互斥鎖或已解鎖的互斥鎖，則會導致未定義的行為。” （ http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_mutex_lock.html ）

Answer 2

我只是想補充一下Guijt的答案：當線程鎖定互斥鎖時，假定它位於關鍵部分內。 如果我們允許另一個線程解鎖該互斥鎖，則第一個線程可能仍在關鍵部分內，從而導致問題。

我可以看到針對您的問題的幾種解決方案：

選項1 ：重新考慮您的算法

嘗試了解為什么需要從其他線程解鎖，並查看是否可以在鎖定線程中完成解鎖。 這是最好的解決方案，因為它通常會生成最容易理解的代碼，並且最簡單地證明其實際上正在執行您認為正在做的事情。 由於多線程編程非常復雜，因此要為這種簡單性付出的代價應該很高。

選項2 ：將線程與事件同步

可能有人爭辯說，這只是實現上述選項1的一種方法。 這個想法是，當鎖定線程結束關鍵部分時，它不會執行任何操作，而是等待事件發生。 當第二個線程希望釋放鎖時，它會發出信號通知該事件。 然后，第一個線程釋放鎖定。

該過程的優點是線程2不會過早釋放鎖。

選項3 ：不使用互斥鎖

如果以上兩個選項都不適合您，則很可能不是將互斥鎖用於互斥，而是用於同步。 如果是這種情況，則您可能使用了錯誤的構造。

最類似於互斥量的構造是信號量。 實際上，多年來，Linux內核都沒有互斥鎖，聲稱它只是最大值為1的信號量。與互斥鎖不同，信號量不需要相同的線程鎖定和釋放。

有關sem_init和朋友的RTFM的用法。

請注意，您必須首先對問題建模，然后才選擇要使用的正確同步結構。 如果以相反的方式進行操作，幾乎可以肯定會引入很多確實很難發現和修復的錯誤。

Answer 3

使用Mutex的全部目的是在關鍵部分實現相互排斥，並由內核跟蹤所有權。 因此，互斥鎖必須在獲取它的同一線程中解鎖