Boost Mutex 的 Windows 实现答案

【问题标题】：Boost Mutex implementation for WindowsBoost Mutex 的 Windows 实现
【发布时间】：2014-12-21 19:44:49
【问题描述】：

据我所知，在旧版本的 Boost boost::mutex 中，Windows 的实现是使用临界区完成的。但在 Boost 1.51 的最新版本中，我发现现在互斥锁实现是基于事件的。

有人知道这种变化背后的原因是什么吗？是否因为性能原因而这样做？关键部分会被弃用吗？

【问题讨论】：

你看过提升更新日志吗？
据我所知，它是为了简化和统一各种互斥体的设计：目前mutex，timed_mutex，try_mutex - 都是使用detail::basic_timed_mutex实现的，不能用CS。（实际上，使用 CS 并不总是最好的选择，它取决于并发场景，因此不值得为此复杂化设计。）
您确实意识到只有 boost 的设计者才能完全回答这个问题。我们其他人只能推测......

【解决方案1】：

通过使用boost，我们总是有最好的方法而没有改变，这不是很好吗？在新版本的boost 中，boost::mutex 被实现为自旋锁，但借助 windows 事件来避免忙等待，并且该事件仅在需要时创建，因此它非常轻巧，具有非常高的性能和还启用boost 使用这个轻量级mutex 进行定时等待！我觉得这个很好

【讨论】：

@Benj 谁告诉我们这里需要一个真正的自旋锁？ boost 的许多部分依赖于使用原子变量实现的自旋锁，例如查看 boost::shared_ptr 和 boost::detail::spinlock 的实现并编写一个小程序，将该自旋锁实现的性能与在 Windows 上实现的最快锁进行比较即使是 *nix 系统，您也会看到结果非常棒！
您几乎是正确的，但实际上boost::mutex 根本不使用自旋锁！它使用原子操作作为优化：当获取锁时，它将首先（原子地）检查一个变量，该变量告诉互斥锁当前是否被锁定。如果没有锁定，那么它可以继续（根本不必考虑 win32 事件），这就是快速路径。如果检查表明互斥锁被锁定，那么（更）昂贵的 win32 东西就会发挥作用。但是这里根本没有自旋锁;-)