為什么boost :: mutex使用原子操作和事件而不是關鍵部分

Question

根據該問題的答案， boost::mutex最新版本使用原子操作和Win32 Event來阻止等待而不是關鍵部分。 為什么？ 背后的原因是什么？

Answer 1

我相信您正在尋找的東西（來自https://www.justsoftwaresolutions.co.uk/articles/implementing_mutexes.html ）：

實現互斥鎖的最簡單方法是為一個本機Windows同步對象編寫一個包裝類。 畢竟，這就是他們的目標。 不幸的是，他們都有自己的問題。 Mutex，Event和Semaphore是內核對象，因此每個同步調用都需要上下文切換到內核。 這可能會相當昂貴，尤其是在沒有競爭的情況下。

Boost互斥鎖僅設計用於單個過程，因此CRITICAL_SECTION看起來很有吸引力。 不幸的是，這也存在問題。 首先，它需要顯式初始化，這意味着它不能可靠地用作具有靜態存儲持續時間的對象的一部分-標准的靜態初始化順序問題由競爭條件的潛在條件加重了，特別是如果互斥量為用作本地靜態變量。 在大多數編譯器上，具有靜態存儲持續時間的對象的動態初始化不是線程安全的，因此兩個線程可能競相運行該初始化，從而可能導致該初始化運行兩次，或者一個線程在不等待初始化運行的情況下運行該線程。其他線程完成。 第二個問題是您不能對CRITICAL_SECTION進行定時等待，這意味着無論如何我們都需要另一種支持定時等待的互斥鎖解決方案。

將CRITICAL_SECTIONs用作高性能互斥鎖還有另一個問題，那就是解鎖CRITICAL_SECTION的線程會將所有權移交給等待的線程。