c++ - 怎么可能锁定 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 中，可以根据计数配置多个锁。