更好地鎖定共享資源，或有一個線程來滿足請求？

Question

我有一個共享內存池，許多不同的線程可以請求分配。從這個請求分配將在每個線程中發生LOT，但是線程數量可能很小，通常只有一個線程在運行。我不確定以下哪種處理方式更好。

最終，我可能需要實現兩者，看看哪一個會產生更有利的結果......我還擔心，即使考慮＃2可能是過早優化，因爲我實際上沒有使用此共享的代碼資源尚未寫入。但是這個問題非常有趣，它會讓我從其他工作中分心。

1）創建一個互斥鎖，讓一個線程嘗試在獲取分配之前鎖定它，然後解鎖它。

2）讓每個線程註冊一個請求插槽，當它需要分配時，它將請求放入插槽，然後等待請求插槽的塊（while（result == NULL）{usleep（）}）結果。單線程不斷迭代請求時隙，進行分配並將其分配給請求時隙中的結果。

數字1是簡單的解決方案，但如果時機正確，單個線程可能會鎖定鎖定。第二個更復雜，但確保從資源拉出時線程之間的公平性。但是它仍然會阻塞請求的線程，並且如果有多個線程，則迭代可能會在不發生任何實際分配的情況下刻錄循環，直到找到請求來完成。

注意：在Linux上使用pthreads的C

Answer 1

解決方案2是虛假的。這是一個醜陋的黑客，並不能確保內存同步。

我會說解決方案1，但我有點懷疑你提到「內存池」開始的事實。你只是試圖分配內存，還是有一些其他的資源（例如某些特殊類型的內存插槽，內存映射文件，視頻內存中的紋理等）？

如果你只是分配內存，那麼你完全有理由擔心過早的優化。整個問題是不成熟的優化，並且系統malloc將會比你的內存池做得更好或更好。 （或者，如果你的代碼將在一個病理破malloc像一些視頻遊戲機的少數系統之一運行，只是下降的替代，只有對那些已知的破碎系統）

如果你真的有您需要管理的特殊資源，從解決方案1開始，看看它是如何工作的。如果你有問題，你可能會發現你可以用一個條件變量來改善它，當資源管理器通知你什麼時候可以分配一個槽，但是我真的懷疑這是必要的。