为什么boost :: mutex使用原子操作和事件而不是关键部分

Question

根据this question的答案，boost::mutex的最新版本使用原子操作和Win32事件来阻止等待而不是关键部分。为什么？它背后的原因是什么？

Answer 1

我相信你正在寻找的东西（来自https://www.justsoftwaresolutions.co.uk/articles/implementing_mutexes.html）：

  

实现互斥锁的最简单方法是编写包装器   其中一个本机Windows同步对象的类;后   所有这些都是他们的目的所在。不幸的是，他们都有他们的   问题。 Mutex，Event和Semaphore是内核对象，所以每一个   同步调用需要上下文切换到内核。这个可以   相当昂贵，尤其是在没有争用时。

     

Boost互斥锁仅设计用于单个进程，因此   CRITICAL_SECTION看起来很吸引人。不幸的是，有   这个问题也是如此。第一个是它需要的   显式初始化，这意味着它不能可靠地用作   具有静态存储持续时间的对象的一部分 - 标准   静态初始化顺序问题由于其潜力而复杂化   竞争条件，特别是如果互斥锁用作本地静态。上   大多数编译器，使用静态存储动态初始化对象   持续时间不是线程安全的，因此两个线程可能竞争运行   初始化，可能导致初始化运行   两次，或一个线程程序，无需等待初始化   由另一个线程运行来完成。第二个问题是   你不能在CRITICAL_SECTION上进行定时等待，这意味着我们需要   无论如何，支持定时等待的互斥锁的另一种解决方案。

     

使用CRITICAL_SECTIONs还有另一个问题   高性能互斥，这是一个线程解锁   CRITICAL_SECTION会将所有权转交给等待的线程。