boost interprocess named mutex remains acquired after a crash

Question

I am using a boost::interpocess::scoped_lock using a named_mutex and a timeout; I am running in Linux OS.

During one of my tests I had a crash: since then, everytime I try to run again the application, it gets stuck on the point where I created the lock; it looks like the mutex remained acquired some way ( no possible process using it is running ).

On top of that if you look at the code below I am expecting that after 150 microseconds, the timed scoped_lock returns to give me an error..but this is not the case..it just hangs there.

      #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;
      }
     ....

My questions are the following:

How to make sure that boost::interprocess named mutex is destroyed? ( so how to see the shared mutex across the processes and how to destroy them )
Why acquiring the mutex doesn't return after 150 microseconds? Is here any something wrong in the code below?

Thanks a lot

AFG

score 4 · Accepted Answer · answered Oct 19 '11 at 10:05

4

I found the solution: I missed to call the following to destroy the mutex

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

This code makes all the necessary clean up.

answered Oct 19 '11 at 10:05

Abruzzo Forte e Gentile

13,055
24
87
163

score 2 · Answer 2 · edited Apr 09 '15 at 13:54

2

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

This should not be correct. This will unlock the mutex for all other processes, too.

edited Apr 09 '15 at 13:54

Piotr Olaszewski

5,521
5
34
58

answered Apr 09 '15 at 11:36

Borislav Ervacanin

21
1

score 2 · Answer 3 · answered Aug 18 '15 at 01:50

2

Named mutex will not release when crash on unix, try boost::interprocess::file_lock instead. When crash happens, the lock is released.

answered Aug 18 '15 at 01:50

east

21
1

In my case it remained acquired on Windows too – Vasilly.Prokopyev Sep 08 '15 at 10:01

score 2 · Answer 4 · answered Oct 24 '17 at 06:34

2

do not use local_time() function, instead of using 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);

if process crash, you should capture crash signal and unlock the named_mutex or have a thread as a timer to check dead lock and unlock it.

using boost::interprocess::file_lock new problems will be introduced, carefully!!!

answered Oct 24 '17 at 06:34

Eric Xu

69
4

you can use macro to change the named_mutex internal implementation to windows mutex or posix mutex, but it also have some problem, you can view the boost/interprocess gitbub, there is something updated, but latest boost version not merge it, you should change the interprocess source code. or you can only use OS API – Eric Xu Dec 17 '18 at 05:31

boost interprocess named mutex remains acquired after a crash

4 Answers4