【问题标题】:std library equivalent to boost::upgrade_lock and boost::upgrade_to_unique_lockstd 库等价于 boost::upgrade_lock 和 boost::upgrade_to_unique_lock
【发布时间】:2020-11-17 20:00:54
【问题描述】:

我刚刚完成了使用 std 库删除 boost 依赖项的任务。我遇到了 upgrade_lock 和 upgrade_to_unique_lock,想知道是否有等效的标准库类?

【问题讨论】:

  • 嗯...它真的有什么用吗?不只是发布shared_lock 并创建一个新的unique_lock 来完成这项工作吗?
  • @ALX23z 我认为它会阻止其他线程获得独占所有权,而您想从共享切换到独占,反之亦然
  • @Caleth 但这很危险。因为试图同时使两个这样的结果导致死锁。我想这就是为什么标准会回避这种功能的原因。

标签: c++ boost std locks


【解决方案1】:

最初由 Howard Hinnant 提出的 N3568 提案 shared_mutex 还包含一个 upgrade_mutex 提案,它正好填补了这一空白。 然而,并发小组反对将upgrade_mutex 引入 C++14。 因此,霍华德写了N3569,其中只包括shared_mutex。该提议被 C++17 接受。

霍华德给出了删除in this answer 的更详细原因,并表示他不会投入时间和精力来使upgrade_mutex 标准化。很遗憾,它可能永远不会被标准化。

通常我会建议为此使用 Boost。由于您明确想要替换 Boost,因此剩下的选项不多。

一种方法是使用您的目标操作系统提供的方法,这种方法是不可移植的,可能不是您想要的。如果您的<mutex> 实现提供std::mutex::native_handle(),这将变得更容易。

您也可以编写自己的解决方案,请查看 Howard 的 reference implementation of upgrade_mutex。请注意,您不能直接将其与 std::lib 结合使用,因为 N3568 会向 std::unique_lock 添加七个构造函数,而用户代码显然无法做到这一点。因此,您需要将<mutex> 的适当许可实现克隆到您自己的命名空间中,将其与参考实现结合起来,然后将这些构造函数添加到您实际需要的unique_lock

【讨论】:

    【解决方案2】:

    来自shared_mutex上的cppreference:

    共享互斥锁不支持从共享所有权模式直接转换为唯一所有权模式:必须先使用 unlock_shared() 放弃共享锁,然后才能使用 lock() 获得独占所有权。 boost::upgrade_mutex 可用于此目的。

    所以没有。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-08-30
      • 1970-01-01
      • 1970-01-01
      • 2014-02-02
      • 1970-01-01
      • 2013-06-30
      相关资源
      最近更新 更多