严格来说，这个问题是关于直接检查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相比开销为零。

1. m_holder成员仅在获取互斥体和释放互斥体之间被访问。因此，互斥体本身充当m_holder的互斥体。在std::thread::id类型的假设非常弱的情况下，locked_by_caller将正确工作。
   1.其他标准库类型（如std::lock_guard）是模板，因此它们可以很好地与这个新类一起工作，因为它满足了Mutex的要求。

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
}

**EDIT：**在此方案中，所有的锁操作都应该通过unique_lock glock执行，而不是通过'raw' mutex gmtx执行。例如，alpha成员函数被重写为lock_guard<unique_lock<mutex>>（或简称为lock_guard<decltype(glock)>）。

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

好吧，如果Assert的开销真的不是问题，那么你可以从另一个线程调用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
}

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

从技术上讲，这不是一个Assert，但我已经使用了类似的方法来防止对共享状态的解锁访问：在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);
}

缺点：

• 不验证锁是否实际 Package 了正确的互斥体。
• 需要虚拟参数。在实践中，我通常将这种不安全的函数保持为私有，因此这不是问题。

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

std::mutex mtx;

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