我对此进行了一些谷歌搜索，并设法找到了很少的信息。 N3568 包含升级锁概念的规范，但升级部分是 rejected during the standardisation process and a revised proposal was accepted (N3569)，排除了它们但包含了其他部分。
目前boost::thread 中存在升级锁的实现，并且很想使用它们。但我很好奇这个概念在使用之前被标准化委员会拒绝的具体原因。
问题：
boost::thread 实现的危险是什么
升级锁，有什么已知问题吗？ 【问题讨论】：
标签： c++ multithreading boost c++14
并发组认为为upgrade_mutex 确定单个升级线程并不实际。
并发小组认为升级工具会使互斥锁变得更加昂贵（它没有在参考实现中）。
没有兴趣将 upgrade_mutex 放入 C++14（在并发子组中）。
（这些是会议纪要的引述）
如果定义了BOOST_THREAD_PROVIDES_DEPRECATED_FEATURES_SINCE_V3_0_0，shared_mutex 将提供升级功能。这是一个坏主意。出于类型安全的原因，shared_mutex 和 upgrade_mutex 具有不同的类型非常重要。需要在编译时强制执行哪个互斥锁具有升级能力，因为它的升级锁定状态在其他争夺升级锁定的线程中是独占的。
我对 boost upgrade_mutex 的研究还不够多，无法知道它与 N3568 有何不同，因此无法对此发表评论。
我不认为它们存在严重缺陷。但是它们的实际用例比shared_mutex 少，而shared_mutex 的实际用例比mutex 少。因此，大量观众不需要它们。但是当您需要时，它非常方便。
除非有人（更可能是一大群人）选择投入时间和金钱来做到这一点，否则它们永远不会成为标准。那个人不会是我，除非我得到一大群人的支持，他们非常希望它出现在标准会议上并投票支持它。我不希望这种情况发生，因为用例非常少。
不幸的是，程序员无法完全靠自己实现这一点，因为这会涉及对unique_lock 和shared_lock 的侵入性更改（三种锁类型之间的转换）。 “程序员无法实现”是将某些东西放入 std::lib 的动机之一。但是“没有足够广泛的需要”也是将事情排除在 std::lib 之外的一个原因。正是这最后一点需要草根运动来反驳，否则它实际上是正确的。
【讨论】：