CODEWITHSUNDEEP
c++multithreadingshared-memory
John Nikolaou
John Nikolaou

Reputation: 161

IPC through a SHM for C++ and concurrent memory accesses

I am trying to improve the performance of a framework I use.

Currently it makes use of a shared memory space(shm), to allow for inter-process communication between two C++ threads. Control to the SHM is passed through a semaphore. This is the current system which works quite well, albeit slightly slower than what I'd like, and with a need of flags for communication.

I have thought of using a master/slave configuration with the signals only being driven by either side. Hence a signal such as Slave_Ready would be written by the slave, and read by the master to show that the slave can take a request.

I would expect this behaviour to be supported, since only one side is writing to a signal ever. However, when the slave is polling the master-driven signals, the master seems unable to change the values of the signals. I've done this in Eclipse, and when I try to step through the write instruction it just doesn't get executed. This is what it looks like : 

shmp->MREADY = true; // in the same time the slave is polling this signal.

So this instruction never goes through. By my understanding, a read/write should be irrelevant. The write should go through, or it should be handled as an atomic request by the memory controller. Even if a read happens half-way through a write, I do not have an issue with corrupted data. If the read sees a true, it goes through and accesses data that was written before the ready signal was asserted. If it reads a false, it accesses the signals the next cycle. Either way the data integrity is preserved. Hence I would expect that this would work without issue, however there is obviously something at play here.

Is it that concurrent read/writes aren't supported? Does the constant spam of polling read request drown out the write request?

Upvotes: 1

Views: 653

Answers (1)

wilx
wilx

Reputation: 18238

I would suggest using C++11's std::atomic<> for the MREADY member. Or at least issue std::atomic_thread_fence(std::memory_order_acq_rel) after the assignment.

Upvotes: 1

Related Questions