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-usin... 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