But I cannot get my head around to how the boost library does this.

The boost interprocess mechanism has three necessary components to work:

1. memory-mapped file: a memory-mapped file needs to be created and passed to a boost.interprocess allocator. This allocator will take chunks of the file and use them as if they were returned by a std::allocator, with mapping applied so that the memory is compatible to in-process specific memory.

2. boost.interprocess container; this kind of container will use the memory returned by the allocator and offer a std::container like interface (begin/end/size/push_back, etc).

3. synchronization mechanism; this can be any interprocess mutex and should be used to prevent data access race conditions.

I mean, one application allocates memory, and other access that memory, but how do they communicate? isn’t it unsafe to do this?

The allocated memory is actually a shared memory-mapped file
The communication is indirect, with both applications setting or reading the data, as they need.
The safety comes from using interprocess synchronization primitives.

shared memory is not the complete picture for IPC, its a data-passing mechanism but you still need some way to inform the other process that some data has been updated and is available to be read. How you do this is up to you, typically you’d use an OS mutex or event object, each process waits on this to be set, the application writing sets it once its finished writing. Then threads in the other programs wake up and read.

Alternatively you can poll, read the data regularly for a value that changes when the data is updated (eg a incrementing counter).

Boost uses memory mapping of a file.

Both unix and windows support creation of files that don’t exist on the normal file system for just this purpose.

Then you will need to synchronize access to that memory like you would if different threads were to access it. Meaning concurrent reads can happen without synchronization but as soon as one process want to write you will need to prevent the others from accessing it.

Atomic operations on the shared memory is still possible if you want a lockless synchronization.

Shared memory is still just memory. You can put a mutex, spinlock or any other synchronization primitive in there, and use them to synchronize your processes’ access to the shared memory, exactly like threads use those primitives to synchronize access to the memory visible to them.

The only real differences are:

1. threads share all memory and the same address space, so raw pointers work for them. Memory shared between processes works exactly the same, but may be mapped at different addresses in each process, so you can’t simply pass raw pointers between them

   • NB. this has a knock-on effect on some implementation details of virtual methods, runtime type information, and some other C++ mechanisms. Stick to trivially-initializable (plain old data) types with no virtual methods or dynamic casts in your shared memory, don’t use typeid on them, and you should be fine.

2. some synchronization primitives may need special flags or attributes to work correctly between processes (see the PTHREAD_PROCESS_SHARED attribute for POSIX thread mutexes, for example). This isn’t really to do with the memory and synchronization in themselves, but due to the kernel/scheduler interaction needed to wake up sleeping waiters.

So:

but how do they communicate?

The same way different threads communicate, allowing for the caveats above

isn’t it unsafe to do this?

Yes, it’s exactly as unsafe for processes to communicate via shared memory as it is for threads to communicate via shared memory, and they need equivalent (or identical) synchronization to make it safe.

Notice that C and C++ are different languages.

Shared memory is impossible in purely standard C11, or C++11 (since the standard does not define that), or even C++14 (whose n3690 draft, and presumably official standard, does not mention shared memory outside of multi-threading). So you need extra libraries to get shared memory. But some operating systems have support for shared memory. So several libraries providing shared memory, built above existing operating system services, exist. You could perhaps consider using the POCO framework library (which abstracts over OS specific details)

For Linux (and perhaps POSIX), look into shm_overview(7). You’ll need to synchronize, so see also sem_overview(7)

VXWorks (which I don’t know, but googled for it) has VxMP

You need to carefully understand what is really happening. You probably want to share only plain old data struct-s (not C++ classes!) and you should be very careful about the addresses (each process might get different address for the common shared memory segment) and about synchronization.

Alternatively, use threads. Notice that C++11 standard defines a thread library.