我对此进行了一些谷歌搜索，但只找到了很少的信息。N3568 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3568.html#Wording包括升级锁概念的规范，但升级部件当时已在标准化过程中被拒绝，修订后的提案被接受 https://www.justsoftwaresolutions.co.uk/2013/05/（N3569）排除了它们，但包括了其他部分。
目前存在于boost::thread升级锁的实现，它们很容易使用。但我很好奇这个概念在使用之前被标准化委员会拒绝的具体原因。
问题：
- 为什么升级锁被排除在 N3568 之外而被拒绝？
- 使用有什么危险
boost::thread实施
升级锁，有什么已知问题吗？
- 升级锁是否会出现在标准中？
被认为存在严重缺陷？
并发小组认为为以下任务确定单个升级线程并不实际：upgrade_mutex.
并发小组认为升级设施将使互斥体更加昂贵（在参考实现中没有）。
没有兴趣放upgrade_mutex在 C++14 中（在并发子组中）。
（以上内容摘自会议纪要）
- 使用 boost::thread 实现升级锁有什么危险，有什么已知问题吗？
If BOOST_THREAD_PROVIDES_DEPRECATED_FEATURES_SINCE_V3_0_0被定义为，shared_mutex提供升级功能。这是一个坏主意。非常重要的是shared_mutex and upgrade_mutex出于类型安全的原因，它们具有不同的类型。需要在编译时强制执行哪个互斥体具有升级功能，因为其升级锁定状态在竞争升级锁定的其他线程中是独占的。
我没研究过boostupgrade_mutex足以知道它与 N3568 有何不同，所以我无法对其发表评论。
- 升级锁是否会出现在标准中，或者它们是否被认为存在严重缺陷？
我不认为它们有严重缺陷。然而，它们的实际用例比shared_mutex，其实际用例比mutex。因此，大量观众不需要它们。但当你需要的时候，它就非常方便了。
它们永远不会成为标准，除非有人（更可能是一大群人）选择投入时间和金钱来实现这一目标。这个人不会是我，除非我得到一大群人的支持，他们非常希望出现在标准会议上并投票支持它。我不希望这种情况发生，因为用例非常罕见。
不幸的是，程序员无法完全自己实现这一点，因为这将涉及对unique_lock and shared_lock（三种锁类型之间的转换）。 “程序员无法实现”是将某些内容放入 std::lib 的动机之一。但“需要的不够广泛”也是将内容排除在 std::lib 之外的一个原因。最后一点需要草根运动来反驳，否则它就是事实。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
