18

I'm going through a program written in C/C++ for control in robotics. Basically, three different programs run at the same time, and they communicate via shared memory. Google-ling around I found thinks like vxWorks and the boost libraries interprocess headers (Boost documentation: Sharing memory between processes).

Now, I don't want to look at the implementation, I can read the link above. But I cannot get my head around to how the boost library does this. I mean, one application allocates memory, and other access that memory, but how do they communicate? isn't it unsafe to do this?

cauchi
  • 1,192
  • 2
  • 13
  • 22
  • what looks unclear in the docs you referred? "When placing objects in a mapped region and mapping that region in different address in every process, raw pointers are a problem since they are only valid for the process that placed them there. To solve this, Boost.Interprocess offers a special smart pointer that can be used instead of a raw pointer. So user classes containing raw pointers (or Boost smart pointers, that internally own a raw pointer) can't be safely placed in a process shared mapped region. These pointers must be replaced with..." – gnat Apr 15 '15 at 10:26
  • Don't forget the operating system is the process which actually looks after the memory. The processes which allocate and use the memory at the end of the day use the OS to make their requests. The OS manages multi-processing and makes sure there won't be any conflicts. – Rob Sedgwick Apr 15 '15 at 10:37
  • @gnat The implementation is clear. How does Boost make that implementation is not on those docs... I don't want to replicate it (that would be absurd) but to understand it. – cauchi Apr 15 '15 at 11:06
  • Related: [local communications between two apps](http://programmers.stackexchange.com/q/262897/40980) –  Apr 15 '15 at 18:45
  • @cauchy : Just out of curiosity: Is the robotics program open source and could you link it here for others to have a look at it? – fabian Jan 06 '21 at 19:09

5 Answers5

14

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.

utnapistim
  • 5,285
  • 16
  • 25
  • 2
    Worth noting: All three of these IPC mechanisms require kernel support, so for those who are curious *how* this is done (as the OP indicated), it can't just be done by individual applications. The applications have to ask the kernel to memory map the files or synchronize with other processes. – Cort Ammon Apr 16 '16 at 04:24
  • ACE (Adaptive communications environment) library for C++ has all these a decade and a half. Boost IPC was very much inspired by the ACE library's shm techniques. Have a look at them both to see what you really need. They have POSIX & System V - shm stuff. Their distribution has an examples directory which can give you some insight. Warning - their documentation is very bleak and learning curve is very high but it get's the stuff done - nicely and has been used in high end telecommunication systems since 2 decades or so. Give it a shot. – User9102d82 Oct 28 '20 at 18:40
5

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).

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
4

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.

Basile Starynkevitch
  • 32,434
  • 6
  • 84
  • 125
  • 1
    Of course that shared memory is possible in both C++11 and C11 ! the fact it's not a part of the standard is meaningless, GUI is not a part of the standard either. There are multiple libraries some **cross platform** that allow one to use shared memory and various synchronization methods... – AK_ Apr 15 '15 at 13:47
  • 1
    My point was that shared memory is not defined by the C++11 standard (but some implementations have them thru OS specific services) – Basile Starynkevitch Apr 15 '15 at 17:23
  • I think you should take time to understand what does the term "language standard" actually means, what's a standard compliant implementation, and what's a library. – AK_ Apr 15 '15 at 17:38
  • Please point me to the section in C++11 standard (or in n3690 draft of C++14) talking about shared memory. – Basile Starynkevitch Apr 15 '15 at 17:56
  • 1
    Of course the standard doesn't talk about IPC so what? this morning I was working on a piece of software that uses Shared Memory for IPC. The source is 100% compliant with the c++14(-11?) standard. It compiles on both icc(Intel) and gcc, both standard compliant implementations. It's also cross platform and was tested on both Windows and Linux. – AK_ Apr 15 '15 at 18:42
  • 3
    I thinkl we both agree, but we might disagree on what standard C++11 means. For me, it is exactly (no more than) the ISO C++11 standard (or the free draft equivalent to it). External libraries does not count as standard, even if they are common and cross-platform. – Basile Starynkevitch Apr 15 '15 at 18:49
4

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.

Useless
  • 12,380
  • 2
  • 34
  • 46
4

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.

ratchet freak
  • 25,706
  • 2
  • 62
  • 97
  • Can you expound upon "Atomic operations on the shared memory is still possible if you want a lockless synchronization" please? You mean to say that if each program is C++ you'd have to be using the C++11 `std::atomic` template class (http://www.cplusplus.com/reference/atomic/) in each of the two programs for them to be able to write to the shared space without synchronization enforced via locks? – Gabriel Staples Sep 06 '17 at 03:05
  • @GabrielStaples yeah or the equivalent atomic intrinsics – ratchet freak Sep 06 '17 at 08:09
  • Sorry for bothering you again; I'm not familiar with "atomic intrinsics." Can you please point me to a reference to study them more? A quick google search is unclear. – Gabriel Staples Sep 07 '17 at 06:07