[Boost-users] [boost 1.47] boost::interprocess::scoped_lock<boost::interprocess::named_recursive_mutex> and fork() (linux)

Subject: [Boost-users] [boost 1.47] boost::interprocess::scoped_lock<boost::interprocess::named_recursive_mutex> and fork() (linux)
From: Frank Bergemann (FBergemann_at_[hidden])
Date: 2013-01-30 15:12:11

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