崩溃后仍获取名为 mutex 的 boost 进程间进程

Posted 2023-02-16

【中文标题】崩溃后仍获取名为 mutex 的 boost 进程间进程

【英文标题】：boost interprocess named mutex remains acquired after a crash

【发布时间】：2011-10-18 14:00:00

【问题描述】：

我正在使用boost::interpocess::scoped_lock 使用named_mutex 和timeout；我在 Linux 操作系统中运行。

在我的一次测试中，我遇到了崩溃：从那时起，每次我尝试再次运行应用程序时，它都会卡在我创建锁的位置；看起来互斥锁仍然以某种方式获得（没有可能使用它的进程正在运行）。

最重要的是，如果您查看下面的代码，我预计在 150 微秒后，计时的 scoped_lock 返回给我一个错误..但事实并非如此..它只是挂在那里。

      #include <boost/interprocess/sync/named_mutex.hpp>
      namespace bi = boost::interprocess;
      bi::named_mutex m_mutex;

 try
      boost::posix_time::ptime pt( 
          boost::posix_time::microsec_clock::local_time() ) ;

      pt+= boost::posix_time::microseconds( 150 );
      bi::scoped_lock< bi::named_mutex > lock( m_mutex, pt );

      if( !lock.owns() )
        FATAL( "I didn't acquire the lock." );
           return EXIT_FAILURE;
      
     ....

我的问题如下：

如何确保boost::interprocess 命名的互斥锁被销毁？ （那么如何查看跨进程的共享互斥体以及如何销毁它们） 为什么在 150 微秒后获取互斥锁没有返回？下面的代码有什么问题吗？

非常感谢

AFG

【参考方案1】：

我找到了解决方案：我错过了调用以下来销毁互斥锁​​

 boost::interprocess::named_mutex::remove( "MutexName" );

这段代码完成了所有必要的清理工作。

【参考方案2】：

boost::interprocess::named_mutex::remove( "MutexName" ); 

这不应该是正确的。 这也将为所有其他进程解锁互斥锁。

【参考方案3】：

在 unix 上崩溃时，命名互斥锁不会释放，请尝试 boost::interprocess::file_lock 代替。 当崩溃发生时，锁被释放。

【讨论】：

在我的情况下，它仍然是在 Windows 上获得的

【参考方案4】：

不要使用 local_time() 函数，而是使用universal_time()： boost::posix_time::ptime abs_time = boost::posix_time::microsec_clock::universal_time() + boost::posix_time::milliseconds(150);

scoped_lock locker(mutex, abs_time);

如果进程崩溃，您应该捕获崩溃信号并解锁 named_mutex 或使用线程作为计时器来检查死锁并解锁它。

使用 boost::interprocess::file_lock 会引入新问题，小心！！！

【讨论】：

可以用宏把named_mutex内部实现改成windows mutex或者posix mutex，但是也有问题，可以查看boost/interprocess gitbub，有更新，不过是最新的boost版本不合并它，您应该更改进程间源代码。或者你只能使用 OS API