Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

boost::named_mutex remains acquired after crash #56

Open
skryv-softserveinc opened this issue May 8, 2018 · 5 comments
Open

boost::named_mutex remains acquired after crash #56

skryv-softserveinc opened this issue May 8, 2018 · 5 comments

Comments

@skryv-softserveinc
Copy link

skryv-softserveinc commented May 8, 2018

tried on macOS

@363568233
Copy link

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
Copy link

Changed the posix mutex implementation to be robust #66

@363568233
Copy link

#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
Copy link

seanlis commented 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
Copy link

Dalzhim commented 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants