提高managed_shared_memory中的进程间互斥量

Question

I have a thread in process 1 create a boost::interprocess::managed_shared_memory segment. In this segment I allocate a boost::interprocess::deque using a custom allocator and I create a boost::interprocess::interprocess_mutex and 2 boost::interprocess::interprocess_condition variables using the default allocator. I use the find_or_construct method to create these.

I have another process (process 2) which opens these using the find method on the boost::interprocess::managed_shared_memory segment which I have opened in process 2.

I understand that managed_shared_memory segments have kernel or filesystem persistency and the interprocess_mutex/interprocess_condition variables have process level persistency.

The scenario where I am getting stuck.

1) Process 1 starts the thread which creates everything.

2) Process 2 starts and opens everything, at this stage the shared memory and synchronization is working well.

3) Process 1 restarts the thread which tries to create everything again (I believe it shouldnt though as I am using find_or_construct)

4) Process 2 is stuck on a wait call for a condition variable even though the thread in Process 1 has done a notify.

Am I missing something in terms of how I should create the shared memory and mutex/conditons or something along the lines of persistence? I am running this code on Windows.

Answer 1

Consider using:

boost::interprocess::named_mutex
boost::interprocess::scoped_lock<boost::interprocess::named_mutex>
boost::interprocess::named_condition 

Rather than allocating the mutexes & condition variables in an existing shared memory block. Boost handles a lot of the messy details for you.

Note: that you create these named_* objects in process space, not in shared memory. Boost creates the actual shared memory segments containing the mutex & condition variables for you.

I have also had trouble trying to map a shared memory segment twice into the same process. Is there any chance that when you run the second instance of the Process1 thread that is attempting to create a new mapping while the old one still exists?