3

I used boost::interprocess to create a boost::multi_index data structure in shared memory. There are many client processes that will access this data structure. When accessing, I will lock the data structure. The problem I encountered is Once the client process is accessing the data structure and crashes without releasing the occupied lock, then all other client processes cannot access the data structure. I use boost::interprocess::named_mutex, I Know that boost::interprocess::file_lock can be automatically released when the process crashes, but because he has a lot of restrictions, so I have no use, I don't know if there is any good way to solve this problem, thank you!

quinz
  • 1,282
  • 4
  • 21
  • 33
ben
  • 59
  • 5

2 Answers2

3

Do not place a mutex in shared memory. The boost documentation for named_mutex says:

https://www.boost.org/doc/libs/1_70_0/doc/html/boost/interprocess/named_mutex.html

A mutex with a global name, so it can be found from different processes. This mutex can't be placed in shared memory, and each process should have it's own named_mutex.

The whole point of using a named mutex is that multiple processes can create their own local mutex objects using the same name and they will share an underlying mutex that they can sync on. If a given process locks the mutex and then crashes, the underlying shared mutex will be released automatically by the OS, allowing another process to lock it (depending on OS, the underlying mutex API may report that the mutex had been unlocked abnormally).

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • "If a given process locks the mutex and then crashes, the underlying shared mutex will be released automatically by the OS" -> `named_mutex` does not release the underlying OS mutex though when an application that locked it crashes... – rubenvb Jun 01 '22 at 11:27
  • @rubenvb I wasn't referring to the `named_mutex` class itself, I was referring to the underlying OS mutex object that the `named_mutex` wraps. – Remy Lebeau Jun 01 '22 at 16:53
  • This answer is not fully correct. There is a file corresponding to `named_mutex`. I don't know if there is a underlying mutex in Windows, but the `named_mutex` can not get released if a process crashes. – guan boshen May 10 '23 at 01:55
  • @guanboshen on Windows, the underlying mutex is obtained via `CreateMutex()` and it's `lpName` parameter. The mutex resides in the OS kernel. When a thread locks a mutex and then terminates for any reason, the kernel unlocks the mutex, and a subsequent lock on the same mutex reports that the previous unlock was abnormal, indicating the data being protected by the mutex may be in a bad state (https://devblogs.microsoft.com/oldnewthing/20050912-14/?p=34253) – Remy Lebeau May 10 '23 at 05:44
1

I guess you can try to access the mutex with timed_lock and, if you get a timeout, forcibly delete the mutex with remove.

Joaquín M López Muñoz
  • 5,243
  • 1
  • 15
  • 20
  • If I remove named_mutex, then other client processes that use this named_mutex will have problems? – ben Jul 03 '19 at 08:52