怎么可能两次锁定 GMutex？

Question

我编写了一个测试程序来尝试调试我遇到的 GMutex 问题，但我似乎无法弄清楚。我正在使用下面的类来锁定和解锁作用域上下文中的互斥体。这和BOOST的后卫类似。

   /// @brief Helper class used to create a mutex.
   ///
   /// This helper Mutex class will lock a mutex upon creation and unlock when deleted.
   /// This class may also be referred to as a guard.
   ///
   /// Therefore this class allows scoped access to the Mutex's locking and unlocking operations
   /// and is good practice since it ensures that a Mutex is unlocked, even if an exception is thrown.
   ///
   class cSessionMutex
   {
      GMutex* apMutex;
      /// The object used for logging.
      mutable cLog aLog;

   public:
      cSessionMutex (GMutex *ipMutex) : apMutex(ipMutex), aLog ("LOG", "->")
      {
         g_mutex_lock(apMutex);
         aLog << cLog::msDebug << "MUTEX LOCK " << apMutex << "," << this << cLog::msEndL;
      }

      ~cSessionMutex ()
      {
         aLog << cLog::msDebug << "MUTEX UNLOCK " << apMutex << "," << this << cLog::msEndL;
         g_mutex_unlock(apMutex);
      }
   };

使用此类，我按如下方式调用它：

bool van::cSessionManager::RegisterSession(const std::string &iSessionId)
{
cSessionMutex lRegistryLock (apRegistryLock);

// SOME CODE
}

其中 apRegistryLock 是 GMutex* 类型的成员变量，并在调用 RegisterSession 之前使用 g_mutex_new() 进行初始化。

话虽如此，当我使用多个线程运行应用程序时，我有时会在一开始就注意到，当前几次调用 RegisterSession 时，日志（来自上面的构造函数）

[DEBUG] LOG.-> - MUTEX LOCK 0x26abb40,0x7fc14ad7ae10
[DEBUG] LOG.-> - MUTEX LOCK 0x26abb40,0x7fc14af7ce10

会使用相同的互斥锁连续记录两次，但不同实例;因此，表明互斥锁被锁定两次，或者第二个锁被简单地忽略 - 这是非常糟糕的。

此外，值得注意的是，我还使用 g_thread_self() 函数检查这些日志是否是从同一线程启动的，并且这返回了两个单独的线程标识符；因此，表明互斥体被不同线程锁定了两次。

所以我的问题是，这种情况怎么可能发生？

Answer 1

如果在同一线程的同一调用链中调用它两次，则可能会发生这种情况。第二个锁通常（尽管并非总是）被忽略。至少在 pthreads 中可以配置多个锁。

Answer 2

在我的例子中发生的情况是，有另一个线程正在使用相同的互斥体调用 g_cond_timed_wait 函数，但互斥体已解锁。在这种情况下， g_cond_timed_wait 函数解锁未锁定的互斥锁，并使互斥锁处于未定义状态，这解释了为什么我看到这个问题中解释的行为：互斥锁被锁定两次。