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

问题描述：

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

std::mutex gmtx;

实际上，它是static某个Foo包含以下alpha和beta方法的类的成员。

它被alpha锁定

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不存在....我该如何定义它？（实际上我想确保互斥锁已被某个[间接]调用者锁定在同一个线程中......）

（我想测试一下，assert因为它beta可以在其他地方调用）

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

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

注意：实际程序要复杂一些。实际上，所有方法都位于一个类中，该类维护“项目”的命名双向关系。因此，我在该类中有一个从项目到名称的映射，另一个从名称到项目的映射。beta将是内部方法真正添加命名，而alpha和gamma将是方法通过其名称查找或添加项目，或通过其项目查找或添加名称。

PS：真正的程序尚未发布，但应该成为MELT的一部分- 其未来的监视器；您可以从这里（临时位置）下载它（alpha 阶段，非常有缺陷）

解决方案 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
    bool try_lock()
    {
        if (std::mutex::try_lock()) {
            m_holder = std::thread::id();
            return true;
        }
        return false;
    }
#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 = std::thread::id{};
#endif // #ifndef NDEBUG
};

请注意以下几点：

1. std::mutex在释放模式下，除了可能的构造/析构（对于互斥对象来说不是问题）之外，这没有任何开销。

2. 成员m_holder仅在获取互斥锁和释放互斥锁之间访问。因此，互斥锁本身充当 的互斥锁m_holder。在对 类型的假设非常弱的情况下std::thread::id，locked_by_caller可以正常工作。

3. 其他标准库类型如std::lock_guard模板，因此它们可以很好地与这个新类配合，因为它满足Mutex要求。

解决方案 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
}

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

解决方案 3：

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

解决方案 4：

好吧，如果断言的费用真的不是问题，那么您可以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
}

解决方案 5：

尝试原子（例如atomic<bool>或atomic<int>），它有一个很好的加载函数，可以做你想做的事情，以及其他很好的函数，如compare_exchange_strong。

解决方案 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);
}

缺点：

• 未验证锁是否真正包装了正确的互斥锁。

• 需要虚拟参数。实际上，我通常会将这些不安全的函数保持为私有，因此这不是问题。

解决方案 7：

您可以使用std::unique_lock它的方法.mutex()来检查它所持有的互斥锁。

std::mutex mtx;

void alpha() {
    std::unique_lock<std::mutex> lck(mtx);
    beta(lck);
}

void beta(std::unique_lock<std::mutex>& lck) {
    assert(lck.mutex() == &mtx);
}

在这种情况下，您还会看到beta(...)在调用之前需要一些锁定。

解决方案 8：

我的解决方案很简单，使用 try_lock 进行测试，然后在需要时解锁：

std::mutex mtx;

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