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