3

I'm using boost::interprocess::named_upgradable_mutex to synchronize a few processes.

I'm using boost::interprocess::sharable_lock and boost::interprocess::scoped_lock to lock the mutex.

When testing the synchronization, it looks fine as long as the processes are working, and are closed normally.

But, I've notices that if a process is killed (via TaskManager for example) while holding the mutex, the mutex remains locked.

Any idea how i can handle process failures ?

I've thought about using timed_lock() just in case... any other ideas?

curiousguy
  • 8,038
  • 2
  • 40
  • 58
Yochai Timmer
  • 48,127
  • 24
  • 147
  • 185
  • Under which circumstances could a process be killed, such that the whole program instance should be killed? – curiousguy Dec 15 '11 at 02:08
  • possible duplicate of [boost interprocess named mutex remains acquired after a crash](http://stackoverflow.com/questions/7808431/boost-interprocess-named-mutex-remains-acquired-after-a-crash) – Zan Lynx Dec 15 '11 at 02:16
  • @curiousguy - The TaskManager for example can kill a process uncleanly. – Yochai Timmer Dec 15 '11 at 06:31
  • @ZanLynx - It's not the same thing. Sure I remove the mutex at the end of the use. But the process crashes. And if I have multiple process, I cant just randomly remove it from another process, how would i know if it's locked or dead-locked ? – Yochai Timmer Dec 15 '11 at 06:33
  • @YochaiTimmer What does it mean if one process is killed this way? That the program should ignore this accident and continue? – curiousguy Dec 15 '11 at 06:38

2 Answers2

2

You're working on the symptom rather than the problem. The purpose of a mutex is to allow a process or thread to put shared data into an inconsistent state. If the process dies while holding the mutex, the shared data is still in an inconsistent state. The problem is how to return the shared data to a consistent state, not how to unlock the mutex.

When you return the shared data to a consistent state, include the mutex or lock in the data you return to a consistent state. The simplest way is to remove the existing lock and create a new one. You will likely have to do the same thing for the shared data.

If you really need to do this though, I'd suggest you're probably not using the right tool for the job.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • In this case I'm using interprocess mutexes to protect a shared resource. The state doesn't really matter, the resource will close when the application crashes. But the locks stay locked on the process that crashed and aren't released. – Yochai Timmer Dec 20 '11 at 07:48
  • 3
    But how is any process that is capable of putting the data into a consistent state supposed to distinguish between "the process owning the lock is still busy" and "the process owning the lock has died?" If the policy is to remove the mutex and create a new one, it kind of defeats the purpose of having the mutex in the first place. – Kevin Hopps Oct 13 '12 at 13:11
  • @KevinHopps: One way is to actually check if the process is still around with the appropriate call for your platform (`kill(0)` on POSIX platforms). As I said though, if you think you need this, you're probably using the wrong tool for the job in the first place. – David Schwartz Oct 13 '12 at 21:55
  • +1, have seen it in one software using shared memory for messaging. As a sensible workaround I chose to just `/bin/rm -f /dev/shm/` every time the environment is recycled. – bobah Feb 18 '14 at 10:40
  • Recovering from unexpected behavior is good practice and not "the wrong too for the job". On Linux there is the robust lock paradigm that return `EOWNERDEAD` if you try to lock a mutex whose owner died while holding it. That way you can at least throw a usable error message and maybe try to recover the state. – themarex Oct 08 '16 at 12:46
  • @user1944243 I completely agree. That's exactly the point of my answer. Notice, for example, that I said "*The problem is how to return the shared data to a consistent state, not how to unlock the mutex.*" and "*The simplest way is to remove the existing lock and create a new one.*". That's precisely what you can (and must) do with robust locks. – David Schwartz Oct 08 '16 at 20:46
0

In case you kill your app for some reason, you can unlock this lock either by logout from Windows, or by executing command mutex.unlock();

Alex Fihman
  • 9
  • 2