針對Windows的Boost互斥實現

據我所知，在舊版本的Boost boost::mutex中，Windows的實現是使用臨界區域完成的。但在最新版本的Boost 1.51中，我發現現在互斥體的實現是基於事件的。針對Windows的Boost互斥實現

有沒有人知道這個改變背後的理由是什麼？是否因性能原因而完成？關鍵部分是否被棄用？

2012-10-22 nogard

你看看助推更新日誌嗎？ – PlasmaHH

據我所知，它是爲了簡化和統一各種互斥體的設計而完成的：目前'mutex'，'timed_mutex'，'try_mutex'都是使用'detail :: basic_timed_mutex'實現的，它不能使用CS。（實際上，使用CS並不總是最好的選擇，它取決於併發場景，所以不值得爲此設計複雜化。） –

你知道只有boost的設計者才能完全回答這個問題。我們其餘的人只能猜測... – Tudor

通過使用boost我們總是有最好的方法沒有改變是不是很美妙？在boost的新版本中，boost::mutex被實現爲自旋鎖，但藉助於Windows事件來避免繁忙的等待，並且該事件僅在需要時纔會創建，因此它的重量非常輕並且具有非常高的性能，並且還啓用boost使用這個輕量級mutex定時等待！我認爲這是優秀的

來源

2012-10-22 16:03:03 BigBoss

這不可能是正確的，真正的自旋鎖只能在內核模式下使用... – Benj

@Benj和誰告訴我們在這裏需要一個真正的自旋鎖？ 'boost'的很多部分都依賴於使用原子變量實現的自旋鎖，例如看一看'boost :: shared_ptr'和'boost :: detail :: spinlock'的實現，並編寫一個比較自旋鎖的性能的小程序在Windows和甚至是* nix系統上實現最快的鎖，並且您看到結果非常棒！ – BigBoss

你幾乎是正確的，但實際上'boost :: mutex'根本不使用螺旋鎖！它使用原子操作作爲優化：當獲取鎖定時，它將首先（原子地）檢查一個變量，告訴互斥鎖是否當前被鎖定。如果沒有鎖定，那麼它可以繼續（不必考慮win32事件），那就是快速路徑。如果支票表示互斥鎖被鎖定，那麼（更多）昂貴的win32資料就會發揮作用。但在這裏根本沒有螺旋鎖;-) – Frunsi

針對Windows的Boost互斥實現

回答

相關問題