c++ - N3568 提案中排除升级锁的原因是什么

Question

我对此做了一些谷歌搜索，但只找到了很少的信息。 N3568包括升级锁概念的规范，但升级部件是 rejected during the standardisation process and a revised proposal was accepted (N3569) 排除了它们但包括了其他部分。

目前 boost::thread 中存在一个升级锁的实现，并且很想使用它们。但是我很好奇这个概念在使用之前被标准化委员会否决的具体原因。

问题:

• 为什么拒绝从 N3568 中排除升级锁？
• 使用 boost::thread 实现的危险是什么升级锁，任何已知问题？
• 升级锁会出现在标准中吗？被认为存在严重缺陷？

Answer 1

• 为什么拒绝从 N3568 中排除升级锁？

并发小组认为为 upgrade_mutex 确定单个升级线程是不切实际的。

并发组认为升级工具会使互斥量更加昂贵(在引用实现中没有)。

没有兴趣将 upgrade_mutex 放入 C++14(在并发子组中)。

(这些是 session 纪要的引述)

• 使用升级锁的 boost::thread 实现有什么危险，有什么已知问题吗？

如果定义了 BOOST_THREAD_PROVIDES_DEPRECATED_FEATURES_SINCE_V3_0_0，则 shared_mutex 提供升级功能。这是一个坏主意。出于类型安全原因，shared_mutex 和 upgrade_mutex 具有不同的类型非常重要。需要在编译时强制执行哪个互斥锁具有升级能力，因为它的升级锁定状态在其他竞争升级锁定的线程中是排他的。

我对 boost upgrade_mutex 的研究还不够深入，无法了解它与 N3568 有何不同，因此无法对其发表评论。

• 升级锁是否会出现在标准中，或者它们是否被认为存在严重缺陷？

我不认为它们存在严重缺陷。然而，它们的实际用例比 shared_mutex 少，后者的实际用例比 mutex 少。因此，大量观众不需要它们。但当您需要时，它会非常方便。

它们永远不会成为标准，除非有人(更可能是相当大的一群人)选择投入时间和金钱来使之成为标准。那个人不会是我，除非我得到一大群人的支持，他们非常希望它出现在标准 session 上并投票支持它。我不希望发生这种情况，因为用例非常少。

不幸的是，程序员不能自己完全实现它，因为它会涉及对 unique_lock 和 shared_lock 的侵入性更改(三种锁类型之间的转换). “程序员无法实现”是将某些内容放入 std::lib 的动机之一。但是“没有足够广泛的需要”也是将内容排除在 std::lib 之外的一个原因。最后一点需要草根运动来反驳，否则它就是事实。