Hello,
i have a problem with boost::interprocess::scoped_lock<boost::interprocess::named_recursive_mutex> and using that one recursively in a unix (linux) fork() process environment.
I.e. I create the boost::interprocess::named_recursive_mutex in a root process, then fork a number of child processes and those synchronize each other via boost::interprocess::scoped_lock<boost::interprocess::named_recursive_mutex>.
When i use the named_recursive_mutex in a recursive way, the 2nd instance of the scoped_lock<> of it hangs (for one of the children, the first one, which tries to do a recursive lock.)
I didn't have an issue without recursions (before i just used named_mutex - but i need to protect an application level region on a higher level now).
And i didn't have a problem with a test program that does NOT fork(), which i start #10 instances on linux in parallel, and which also uses nested scoped_lock<>'s for each of them.
Does anybody know about issue of boost::interprocess::named_recursive_mutex or boost::interprocess::scoped_lock<boost::interprocess::named_recursive_mutex> for unix/linux fork()?
Do i have to create my named_recursive_mutex AFTER the fork() for each process instance?
(i use m_mutex = boost::interprocess::named_recursive_mutex(boost::interprocess::open_or_create, _shmId.c_str())).
I read about this here: http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them
It talks about need to call pthread_mutex_init().
Other pages seems to indicate, that there is only a problem, when i lock a mutex and then fork(), inheriting the lock to parent and child process.
- many thanks!
best regards,
Frank