共享/独占锁定，其中共享工作只能执行一次

shared/exclusive lock where the shared work should only be done once?

本文关键字：共享 执行 一次 工作 锁定      更新时间：2023-10-16

我有一个问题，我有一种共享/排他性的情况，除了共享部分不需要真正共享的内容：我会尝试解释。

排他部分很简单：如果持有独占锁，则在独占锁的所有者释放它之前，不允许其他人前进。

（不是真正的）共享工作线程应该像这样操作：

    如果持有独占锁，
  • 或者没有锁：（等待独占释放，并）执行"共享"工作。
    • 如果"共享"锁
  • 已经持有，或者这是等待独占锁的第二个/n个"共享工作线程"：等待（第一个"共享工作线程"）的共享锁被释放，但随后不要做工作，而只是返回，因为第一个"共享工作线程"已经完成了工作。

此锁定/工作模式有名称吗？如果本身没有名字，我很感兴趣是否使用它/我写的有意义。

如果您在工作单元上/为工作单元添加"done"标志，并在排他锁中测试/设置该标志 - 您会缺少什么？

我发现这只是共享工人的额外（正常）锁/互斥锁：

独家/主：

  • shared_mutex.lock(); // or timed_lock(timeout)
    • 做大师级工作...
    • 释放独占锁

工作人员/共享：

  • shared_mutex.lock_shared(); // or timed_lock_shared
    • 已获取共享锁
    • if (worker_mutex.try_lock()) // normal mutex
      • 工作线程互斥锁现已锁定
      • 做工作
      • 释放/返回
    • else if worker_mutex.try_lock() failed
      • 另一个工作人员已在进行中
      • 等待其他工作线程完成：
      • worker_mutex.lock() // or timed lock
        • 工人互斥锁已获得，其他工作线程已完成
        • 什么都不做（工作刚刚完成）
        • 释放/返回

就我而言，整个事情的表现完全无关紧要。独占锁以秒为单位，共享工作可能需要 100 毫秒。这个方案应该防止的是，当多个共享的"客户端"被共享等待独占锁并被释放时，让多个"客户端"做（本质上）相同的工作——然后只有一个"客户端"会做这项工作，而其他人只会等待它完成并返回。

是的，这很混乱，

但对于已经很混乱的情况来说，这是一个

附加方法。

有用的C++课程：

  • shared_mutex @Boost或@Std
  • recursive_mutex
相关文章：