boost named_condition is not waking up waiting process

Question

I have 2 processes (producer and consumer) sharing an int deque in shared memory, I have the producer process put 2 numbers in the deque and then it gets in a wait state losing its mutex lock. I then have the consumer process removing the numbers and printing them. It then does a notify on the condition which the producer is waiting on. The consumer then goes on its own wait on a second condition. After this case the producer does not wake up. I am using the same mutex between the processes. Please find all code below.

Include file shared_memory.h:

#ifndef SharedMemory_h
#define SharedMemory_h

#include <boost/interprocess/managed_shared_memory.hpp>
#include <boost/interprocess/containers/deque.hpp>
#include <boost/interprocess/allocators/allocator.hpp>
#include <boost/interprocess/sync/scoped_lock.hpp>
#include <boost/interprocess/offset_ptr.hpp>
#include <boost/interprocess/sync/named_condition.hpp>

using namespace boost::interprocess;

typedef allocator<offset_ptr<int>, managed_shared_memory::segment_manager> ShmemAllocator;
typedef deque<offset_ptr<int>, ShmemAllocator> Deque;

#endif 

Producer process:

#include "shared_memory.h"

struct shm_remove
{
    shm_remove() { shared_memory_object::remove("MySharedMemory"); }
    ~shm_remove() { shared_memory_object::remove("MySharedMemory"); }
} remover;

struct mutex_remove
{
    mutex_remove() { named_mutex::remove("MyMutex"); }
    ~mutex_remove() { named_mutex::remove("MyMutex"); }
} mutex_remover;

//Create shared memory, mutex and condtion
managed_shared_memory segment(create_only, "MySharedMemory", 10000000);
named_mutex mutex(create_only,"MyMutex");
named_condition full(open_or_create,"FullCondition");
named_condition empty(open_or_create,"EmptyCondition");

const ShmemAllocator alloc_inst (segment.get_segment_manager());


int main() 
{
    Deque* MyDeque;
    offset_ptr<int> a, b;
    try{
        MyDeque = segment.construct<Deque>("MyDeque")(alloc_inst);
        try{
           a = static_cast<int*> (segment.allocate(sizeof(int)));
           b = static_cast<int*> (segment.allocate(sizeof(int)));
        }catch(bad_alloc &ex){
             std::cout << "Could not allocate int" << std::endl;
        }
    }catch(bad_alloc &ex){
        std::cout << "Could not allocate queue" << std::endl;
    }
    scoped_lock<named_mutex> lock(mutex);
    while(1)
    {
        while (MyDeque->size() == 2)
        {
            full.wait(lock);
            std::cout << "unlocked producer" << std::endl;
        }

        if (MyDeque->size() == 0)
        {
            *a = 2;
            MyDeque->push_back(a);
        }

        if (MyDeque->size() == 1)
        {
            *b = 4;
            MyDeque->push_back(b);
            empty.notify_one();
        }
    }
}

Consumer process:

#include "shared_memory.h"

managed_shared_memory segment(open_only, "MySharedMemory");
Deque* MyDeque = segment.find<Deque>("MyDeque").first;

named_mutex mutex(open_only, "MyMutex");
named_condition full(open_only, "FullCondition");
named_condition empty(open_only, "EmptyCondition");

int main()
{
    scoped_lock<named_mutex> lock(mutex);
    while(1)
    {

         //volatile int size = MyDeque->size();
         while (MyDeque->size() == 0)
         {
             empty.wait(lock);
         }

         if (MyDeque->size() == 2)
         {
             std::cout << "Consumer: " << *MyDeque->front() << std::endl;
             MyDeque->pop_front();
         }

         if (MyDeque->size() == 1)
         {
             std::cout << "Consumer: " << *MyDeque->front() << std::endl;
             MyDeque->pop_front();
             full.notify_one();
         }
    }
}

While debugging things seem to go ok for the first iteration, the producer puts numbers 2 and 4 on the deque then waits on the full condition. The Consumer then gets the lock, prints these numbers, does a notify_one on the full condition and then goes into a wait. After this the producer does not wake up.

Answer 1

The mutex must not be locked across notifying. This is the reason of the deadlock.