针对Windows的Boost互斥实现

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

有没有人知道这个改变背后的理由是什么？是否因性能原因而完成？关键部分是否被弃用？

2012-10-22 nogard

你看看助推更新日志吗？ – PlasmaHH

据我所知，它是为了简化和统一各种互斥体的设计而完成的：目前'mutex'，'timed_mutex'，'try_mutex'都是使用'detail :: basic_timed_mutex'实现的，它不能使用CS。（实际上，使用CS并不总是最好的选择，它取决于并发场景，所以不值得为此设计复杂化。） –

你知道只有boost的设计者才能完全回答这个问题。我们其余的人只能猜测... – Tudor

通过使用boost我们总是有最好的方法没有改变是不是很美妙？在boost的新版本中，boost::mutex被实现为自旋锁，但借助于Windows事件来避免繁忙的等待，并且该事件仅在需要时才会创建，因此它的重量非常轻并且具有非常高的性能，并且还启用boost使用这个轻量级mutex定时等待！我认为这是优秀的

来源

2012-10-22 16:03:03 BigBoss

这不可能是正确的，真正的自旋锁只能在内核模式下使用... – Benj

@Benj和谁告诉我们在这里需要一个真正的自旋锁？ 'boost'的很多部分都依赖于使用原子变量实现的自旋锁，例如看一看'boost :: shared_ptr'和'boost :: detail :: spinlock'的实现，并编写一个比较自旋锁的性能的小程序在Windows和甚至是* nix系统上实现最快的锁，并且您看到结果非常棒！ – BigBoss

你几乎是正确的，但实际上'boost :: mutex'根本不使用螺旋锁！它使用原子操作作为优化：当获取锁定时，它将首先（原子地）检查一个变量，告诉互斥锁是否当前被锁定。如果没有锁定，那么它可以继续（不必考虑win32事件），那就是快速路径。如果支票表示互斥锁被锁定，那么（更多）昂贵的win32资料就会发挥作用。但在这里根本没有螺旋锁;-) – Frunsi

针对Windows的Boost互斥实现

回答

相关问题