Question

我正在使用boost::interpocess::scoped_lock使用named_mutex和timeout;我在Linux OS中运行。

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

最重要的是，如果你看下面的代码，我希望在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

Answer 1

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

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

此代码可以完成所有必要的清理工作。

Answer 2

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

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

Answer 3

命令互斥锁在unix上崩溃时不会释放，请尝试使用boost :: interprocess :: file_lock。发生崩溃时，锁定被释放。

Answer 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将引入新问题，小心!!!“

在崩溃后仍然获得了名为mutex的提升进程

4 个答案: