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

【问题标题】：Why boost::mutex uses atomic operations and events instead of critical sections为什么 boost::mutex 使用原子操作和事件而不是关键部分
【发布时间】：2015-11-03 11:44:22
【问题描述】：

根据this question 的答案boost::mutex 的最新版本使用原子操作和Win32 事件来阻塞等待而不是临界区。为什么？背后的原因是什么？

【问题讨论】：

我猜是为了增强便携性？
@David Haim Win32 在您看来，与关键部分相比，Win32 事件不是特定于平台的东西？
我猜他们更喜欢平台事件+独立的原子操作而不是完全的平台实现
我怀疑你会在这里得到更好的答案，问开发人员在他们挂起的一些与提升相关的资源上做了这件事。这个问题仍然很有趣，因为将关键会话替换为事件看起来不太合理，除非 boost 旨在用于 ring0 代码。
@FrozenHeart 没有人说事件与平台无关。大卫说“增强可移植性”（图书馆）。该库将希望在所有操作系统上保证类似的语义。这可能是一个因素。不是我说“可能”，因为我不知道。所以，“增强可移植性”是关于boost::mutex 的行为，而不是关于代码是否可以在平台上编译。

标签： c++ boost boost-thread

【解决方案1】：

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

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

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

使用 CRITICAL_SECTIONs 作为高性能互斥锁，这是一个线程解锁 CRITICAL_SECTION 会将所有权移交给等待线程。

【讨论】：