Best way to dump data from boost shared memory

Question

I have 2 application. One writes high frequency data to boost managed shared memory, data struct being boost deque.

typedef boost::interprocess::allocator<REALTIME_INFO, boost::interprocess::managed_shared_memory::segment_manager> ShmemAllocator;
typedef boost::interprocess::deque<REALTIME_INFO, ShmemAllocator> MyDeque;

boost::interprocess::managed_shared_memory segment(boost::interprocess::open_or_create, "MySharedMemory",50000000); 
const ShmemAllocator alloc_inst (segment.get_segment_manager());
MyDeque *Mydeque;
Mydeque = segment.find_or_construct<MyDeque>("myd")(alloc_inst);//first ctor parameter

if(Mydeque->size() < 150000){   
    Mydeque->push_back(rtinfo);
}
else{
    Mydeque->pop_front();
    Mydeque->push_back(rtinfo);
}

My second application is a Qt application when pressed button reads from the shared memory and writes to a csv file. Since the data is huge I cannot write the data directly from shared memory so I tried memcpy. I could only get the first value and remaining were garbage.

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

After getting the first pointer I tried to copy it to another MyDeque but I can only access the first pointer and cannot iterate remaining data.

memcpy(Mydeque_new, &Mydeque, Mydeque->size()*sizeof(REALTIME_INFO));

Can anyone suggest a better way to copy data from shared memory to a local memory.

What strategy are you using to avoid data races? From the look of yout enqueuing code, it seems you need to have concurrent access from both applications, so I imagine restricting access to the entire memory block is not going to work for you. How you handle this is going to inform which startegy is appropriate. — , Aug 22 '17 at 19:28
Can we suspect `REALTIME_INFO` is a POD? Also what @Frank said: Protect against race conditions. — user0042, Aug 22 '17 at 19:30
@Frank Actually you are right. I tried using named_mutex but this started crashing the second application. Since the managed_shared _memory is sync automatically i thought of not using any mutex. this is still in initial phase. Can you point me to right direction in using mutex? — PrimeOfKnights, Aug 22 '17 at 19:31
@user0042 REALTIME_INFO is user defined data struct. i agree with Frank. I have also tried scoped_lock. — PrimeOfKnights, Aug 22 '17 at 19:33
@brownKnight I'm afraid that depends too much on the nature of the interaction between the two executables for us to answer. — , Aug 22 '17 at 19:44
Ya thats true. The writing frequency is very high and memory takes upto 40Mb. But thank you. — PrimeOfKnights, Aug 22 '17 at 19:46

score 2 · Accepted Answer · answered Aug 22 '17 at 22:21

memcpy(Mydeque_new, &Mydeque, Mydeque->size()*sizeof(REALTIME_INFO));

This is big fat Undefined Behaviour because deque<> is not a POD type. In fact, even the elements data is not contiguous in memory, so you can't even memcpy that.

Consider using a Boost Interprocess Message Queue
If there's a single consumer and a single producer, consider using spsc_queue: Shared-memory IPC synchronization (lock-free). This is a potentially lock-less solution and it has a bulk-dequeue/enqueue interface as well.

Best way to dump data from boost shared memory

1 Answers1