You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
boost::named_mutex remains acquired after crash #56
It exists on any OS. Because the default named_mutex is spin_wait, you can view the source code, there is macro to change internal implementation. You can change it to posix pthread_mutex on macOS, now it update to robust mutex, maybe you need to update the source code.
#if defined(BOOST_INTERPROCESS_USE_POSIX_SEMAPHORES)
typedef ipcdetail::posix_named_mutex internal_mutex_type;
#undef BOOST_INTERPROCESS_USE_POSIX_SEMAPHORES
#elif defined(BOOST_INTERPROCESS_USE_WINDOWS)
typedef ipcdetail::windows_named_mutex internal_mutex_type;
#undef BOOST_INTERPROCESS_USE_WINDOWS
#else
typedef ipcdetail::shm_named_mutex internal_mutex_type;
#endif
But define BOOST_INTERPROCESS_USE_POSIX_SEMAPHORES, boost using the posix semaphore, deadlock are also possible. You should use posix_mutex shared in process, but named_mutex dont't use posix_mutex. I did it myself...
Would this issue ever get fixed? It has been there for almost a decade.
I spent one whole day to add named_mutex and named_condition to my windows apps, and then found out this issue forcing me to look for other solutions.
I'm also wondering why the PR #66 was closed without ever being merged. Running into this problem is quite annoying when a known solution has existed for so long!
In MacOS, there is no operating system support for robust mutexes in shared memory. In systems with support for robust mutexes in shared memory (e.g. linux), the library already uses this feature.
Activity
363568233 commentedon Dec 17, 2018
It exists on any OS. Because the default named_mutex is spin_wait, you can view the source code, there is macro to change internal implementation. You can change it to posix pthread_mutex on macOS, now it update to robust mutex, maybe you need to update the source code.
363568233 commentedon Dec 17, 2018
Changed the posix mutex implementation to be robust #66
363568233 commentedon Dec 17, 2018
#if defined(BOOST_INTERPROCESS_USE_POSIX_SEMAPHORES)
typedef ipcdetail::posix_named_mutex internal_mutex_type;
#undef BOOST_INTERPROCESS_USE_POSIX_SEMAPHORES
#elif defined(BOOST_INTERPROCESS_USE_WINDOWS)
typedef ipcdetail::windows_named_mutex internal_mutex_type;
#undef BOOST_INTERPROCESS_USE_WINDOWS
#else
typedef ipcdetail::shm_named_mutex internal_mutex_type;
#endif
But define BOOST_INTERPROCESS_USE_POSIX_SEMAPHORES, boost using the posix semaphore, deadlock are also possible. You should use posix_mutex shared in process, but named_mutex dont't use posix_mutex. I did it myself...
seanlis commentedon Oct 31, 2020
Would this issue ever get fixed? It has been there for almost a decade.
I spent one whole day to add named_mutex and named_condition to my windows apps, and then found out this issue forcing me to look for other solutions.
Dalzhim commentedon Nov 11, 2022
I'm also wondering why the PR #66 was closed without ever being merged. Running into this problem is quite annoying when a known solution has existed for so long!
igaztanaga commentedon Jan 7, 2026
In MacOS, there is no operating system support for robust mutexes in shared memory. In systems with support for robust mutexes in shared memory (e.g. linux), the library already uses this feature.