8

私はaと aboost::interpocess::scoped_lockを使用しています。Linux OSで実行しています。named_mutextimeout

テストの 1 つ中にクラッシュが発生しました。それ以来、アプリケーションを再度実行しようとすると、ロックを作成した時点でスタックしてしまいます。ミューテックスが何らかの方法で取得されたままになっているようです (それを使用するプロセスは実行されていません)。

それに加えて、以下のコードを見ると、150 マイクロ秒後に timedscoped_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;
      }
     ....

私の質問は次のとおりです。

  1. boost::interprocess名前付きミューテックスが確実に破棄されるようにするには? （プロセス全体で共有ミューテックスを確認する方法とそれらを破棄する方法）
  2. ミューテックスの取得が 150 マイクロ秒後に返されないのはなぜですか? 以下のコードに何か問題がありますか？

どうもありがとう

AFG

4

4 に答える 4

5

私は解決策を見つけました：ミューテックスを破壊するために以下を呼び出すのを逃しました

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

このコードは、必要なすべてのクリーンアップを行います。

于 2011-10-19T10:05:40.207 に答える
2

Unix でクラッシュした場合、名前付きミューテックスは解放されません。代わりに、boost::interprocess::file_lock を試してください。クラッシュが発生すると、ロックが解除されます。

于 2015-08-18T01:50:50.143 に答える
2

universal_time() を使用する代わりに、local_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 を使用すると、新しい問題が慎重に導入されます!!!

于 2017-10-24T06:34:53.697 に答える