从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中（在并发子组中）。

（这些是会议纪要的引用）

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

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

我还没有研究过upgrade_mutex的提升，知道它是如何偏离N3568的，所以我无法评论它。

• 升级锁是否会出现在标准中，还是被视为严重缺陷？

我不认为它们存在严重缺陷。但是，它们的实际用例比shared_mutex更为罕见，mutex的实际用例比unique_lock更罕见。因此，大量观众并不需要它们。但是当你需要它时，它非常方便。

除非有人（更有可能是一个相当大的某些人）选择投入时间和金钱来做到这一点，否则它们永远不会成为标准。有人不会是我，除非我得到一大群人的支持，他们非常希望能够出现在标准会议上，并投票支持它。我不希望这种情况发生，因为用例非常罕见。

令人遗憾的是程序员无法完全实现这一点，因为它会涉及对shared_lock和DECLARE @txt NVARCHAR(MAX)=(SELECT REPLICATE('x',12000)); SELECT LEN(@txt) AS CountCharacters ,DATALENGTH(@txt) AS UsedBytes; 的侵入性更改（三种锁类型之间的转换）。 ＆＃34;程序员无法实现＆＃34;将东西放入std :: lib的原因之一就是其中一个。但是，并没有足够广泛的需要＆＃34;也是将事物排除在std :: lib之外的原因。最后一点需要草根运动来反驳，否则事实上是正确的。