为什么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的线程会将所有权移交给等待的线程。