How to use memmapfiles safely for inter-process communication?

15 views (last 30 days)
I am interested in using memory mapped files to implement inter-process communication between a Matlab process and a foreign process. Portability (Windows / Linux) is a concern, but my main concern is reliability.
Looking at the example in Share Memory Between Applications, I am surprised the code is that simple. Does the code actually work? The shared byte m.Data(1) controls which process is allowed to access the shared data, but m.Data(1) itself doesn't seem to be protected against data races. To implement this example in C++, one would typically add some synchronization object, either a locking one (mutex, semaphore or condition variable) or a lock-free one (involving some kind of memory barrier). The Boost library provides some good examples of such mechanisms.
Can we use such synchronization objects with Matlab's memmapfiles? Or is there some kind of magic the Matlab compiler adds behind the scenes, that makes my concern pointless?
Edit: I am specifically concerned by the compiled code of this example.

Answers (1)

Philip Borghesani
Philip Borghesani on 8 Jun 2017
In MATLAB on Intel (x86) platforms I believe this code is safe and will work correctly. Because the communication process is token based and designed to only work between two processes a simple mechanism is possible. If this was done in C with a memory mapped file the only change needed would be to declare the first memory location atomic.
Also note that this is not the most efficient way to do this type of thing. The sleep calls dictate the maximum call throughput and the poling mechanism is inefficient. Doing this with one or two mex files and proper inter-process communication would have much better performance.
Igor Dimitrijevic
Igor Dimitrijevic on 15 Jun 2017
@Philip Borghesani
I misunderstood your point about the intervening instructions that MATLAB generates. I get it now.
In no way am I an expert in this field, but it seems to me that, regarding data races issues with out-of-order execution, one should not compare the intervening instructions with the size of the execution pipeline, nor the instruction decode pipeline. It seems to me the intervening instructions should be compared to the sizes of the reorder buffer or the reservation station. These can be fairly large: for exemple the reorder buffer has 224 uop entries and the reservation station has 97 uop entries on the Intel Skylake.
One should notice that, even if "only" one word of data is altered, this could lead to huge data losses: this one word could be an index needed to interpret other data.
Another thing to keep in mind, is that any of the two processes can be halted for a short time, if the processor that run it decides to swich for some urgent task. This could potentially increase data losses/corruption.

Sign in to comment.


Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!