Mutex可能對系統性能有什麼副作用？

Question

擁有共享資源的多線程應用程序需要使用互斥鎖對其訪問進行序列化。

如果我想下列條件的應用程序滿足：

1 - 無互斥誤操作導致死鎖，長時間等待或其他災難性的後果。

2 - 共享資源具有處理所有互斥鎖問題的訪問器方法（因爲等待互斥量最大限度地釋放而導致延遲的嘗試）。

接受互斥鎖是解決與共享資源保護相關的許多問題的問題解決者。使用互斥體對性能有任何副作用？如果是的話應該是什麼選擇（可能是其他同步機制）？

爲了更清楚我的意思，我會考慮下面的例子：

線程讀取多個線程之間共享的全局變量的嘗試。如果我可以考慮：

a - 閱讀操作需要（X us）。

b - 互斥量使用會增加（Y us）的開銷。

Ç - 讀操作不得超過ž我們其中Z> = X，但ž< X + Y

其次，我認爲我可以假設互斥確保互斥，但在的負面影響爲代價的表現（這可能是輕微的或相當大的影響取決於上下文）。

互斥鎖在很多情況下都很有用，但是在任何情況下都應該避免（或替換）它們，因爲它們對系統性能有負面影響，儘管它們在使用時非常謹慎？

注意：這裏我指的是作爲內核服務提供的Mutexes。我不是指任何試圖模仿Mutex（內核服務）的應用程序實現。

Answer 1

如果你擔心通過獲得一個免費的互斥量並釋放它而增加的額外開銷，那麼你不應該擔心這一點。是的，獲取和釋放互斥鎖所需的代碼會向使用該資源的線程添加非零數量的開銷。但根據我的經驗，開銷的數量可以忽略不計，我不記得曾經擔心它或解決它。如果你需要一個互斥體來保護共享資源，那麼你應該使用一個互斥體。

如果您擔心一個線程可能會使資源過長，從而阻止另一個線程及時訪問資源，那麼這是一個值得關注的問題，這正是您對系統設計的關注所在。一些用於尋址的設計技術這個問題包括：最小化互斥鎖被佔用的時間，線程優先級和優先級繼承。

在某些情況下，您可以通過限制對單個線程的資源訪問來避免使用互斥鎖。換句話說，不要在線程之間共享資源。其他希望使用資源的線程必須與資源的線程進行通信。例如，您可以有一個負責串行端口傳輸的線程。任何其他需要發送串行消息的線程都會向串行線程的郵箱或隊列發送請求。串行線程簡單地掛在郵箱/隊列上，然後發送所有收到的請求。這樣就不需要互斥體，因爲串行線程是直接使用資源的唯一線程。請注意，由於多個請求可能會堆積在郵箱/隊列中，導致某些消息傳輸延遲，因此該技術仍需要一些系統設計維護。