如何断言 std::mutex 是否被锁定？

Question

使用 GCC 4.8.2（在 Linux/Debian/Sid 64 位上）-或 GCC 4.9（如果可用）-在 C++11 中-我有一些互斥体

std::mutex gmtx;

^{实际上，它是某个类Foo 中的static 成员，其中包含alpha 和beta 下面的方法。}

它被锁定在alphalike

void alpha(void) {
   std::lock_guard<std::mutex> g(gmtx);
   beta(void);
   // some other work
}

我想检查beta 确实gmtx 已锁定：

void beta(void) {
   assert (gmtx.is_locked());
   // some real work
}

^{（注意is_locked 只在assert 内部调用...可能效率非常低，甚至有时不准确）}

当然，我还有其他函数调用beta，例如

void gamma(void) {
   std::lock_guard<std::mutex> g(gmtx);
   beta();
   // some other work
}

但是is_locked 不存在....我应该如何定义它？ （实际上我想确保互斥锁已被某些 [indirect] 调用者锁定在同一个线程中......）

（我想用assert 进行测试的原因是beta 可以在其他地方调用）

我不能使用try_lock（除非使用递归互斥锁），因为在常见情况下它会锁定一个已经锁定的互斥锁...（被调用者锁定在同一个线程中）这不仅是未定义的行为，而且会阻塞完全。

我想避免递归互斥锁（比普通互斥锁更昂贵），除非我真的必须这样做。

---

^{注意：真正的程序有点复杂。实际上，所有方法都在一个类中，该类在“项目”上保持命名双向关系。所以我在那个类里面有一个从项目到名称的映射和另一个从名称到项目的映射。 beta 将是添加真正命名的内部方法，alpha 和 gamma 将是通过项目名称或项目名称查找或添加项目的方法。}

^{PS：真正的程序还没有发布，但应该成为MELT的一部分——它的未来monitor；您可以从here（临时位置）下载它（alpha 阶段，非常错误）}

Answer 1

严格来说，问题是直接检查std::mutex的锁定性。但是，如果允许将其封装在新类中，则很容易做到：

class mutex :
    public std::mutex
{
public:
#ifndef NDEBUG
    void lock()
    {
        std::mutex::lock();
        m_holder = std::this_thread::get_id(); 
    }
#endif // #ifndef NDEBUG

#ifndef NDEBUG
    void unlock()
    {
        m_holder = std::thread::id();
        std::mutex::unlock();
    }
#endif // #ifndef NDEBUG

#ifndef NDEBUG
    /**
    * @return true iff the mutex is locked by the caller of this method. */
    bool locked_by_caller() const
    {
        return m_holder == std::this_thread::get_id();
    }
#endif // #ifndef NDEBUG

private:
#ifndef NDEBUG
    std::atomic<std::thread::id> m_holder;
#endif // #ifndef NDEBUG
};

注意以下几点：

1. 在发布模式下，这与 std::mutex 相比具有零开销，除非可能用于构造/销毁（这对于互斥对象来说不是问题）。
2. m_holder 成员只能在获取互斥体和释放它之间访问。因此，互斥体本身充当m_holder 的互斥体。对 std::thread::id 类型的假设非常弱，locked_by_caller 将正常工作。
3. 其他 STL 组件，例如，std::lock_guard 是模板，因此它们与这个新类配合得很好。

Answer 2

std::unique_lock<L> 具有 owns_lock 成员函数（相当于您所说的 is_locked）。

std::mutex gmtx;
std::unique_lock<std::mutex> glock(gmtx, std::defer_lock);

void alpha(void) {
   std::lock_guard<decltype(glock)> g(glock);
   beta(void);
   // some other work
}
void beta(void) {
   assert(glock.owns_lock()); // or just assert(glock);
   // some real work
}

编辑：在此解决方案中，所有锁定操作都应通过 unique_lock glock 而不是“原始”互斥锁 gmtx 执行。例如，alpha 成员函数被重写为lock_guard<unique_lock<mutex>>（或简单地lock_guard<decltype(glock)>）。

Answer 3

您可以只使用recursive_mutex，它可以在同一个线程上多次锁定。注意：如果是我的代码，我会对其进行重组，这样我就不需要recursive_mutex，但它会解决你的问题。

Answer 4

试试atomic（例如atomic<bool> 或atomic<int>），它有一个很好的load 函数，可以做你想做的事情，还有其他很好的函数，比如compare_exchange_strong。

Answer 5

好吧，如果断言的开销真的不是问题，那么您可以从另一个线程调用try_lock()，保证其行为得到明确定义：

void beta(void) {
  assert(std::async(std::launch::async, [] { return gmtx.try_lock(); })
                 .get() == false &&
         "error, beta called without locking gmtx");
  // some real work
}

Answer 6

从技术上讲，这不是一个断言，但我使用了类似的方法来防止对共享状态的解锁访问：在 unsafe 函数（在您的示例中为 beta）上的锁保护类中添加一个引用参数。然后除非调用者创建了锁守卫，否则无法调用该函数。它解决了在锁外意外调用函数的问题，并且它在编译时这样做，没有竞争。

所以，用你的例子：

typedef std::lock_guard<std::mutex> LockGuard;
void alpha(void) {
   LockGuard g(gmtx);
   beta(g);
   // some other work
}

void beta(LockGuard&) {
   // some real work
}

void gamma(void) {
   LockGuard g(gmtx);
   beta(g);
   // some other work
}

//works recursively too
void delta(LockGuard& g)
{
   beta(g);
}

缺点：

• 不验证锁是否实际包装了正确的互斥体。
• 需要虚拟参数。在实践中，我通常将这些不安全的函数保密，所以这不是问题。

Answer 7

我的解决方案很简单，使用 try_lock 测试，如果需要解锁：

std::mutex mtx;

bool is_locked() {
   if (mtx.try_lock()) {
      mtx.unlock();
      return false;
   }
   return true; // locked thus try_lock failed
}