Shared Memory Transport (SHM)
Starting v1.10.0, eProsima Fast DDS features a new Interprocess Communication Mechanism (IPC) based on sharing memory across different processes running in the same host: Shared Memory Transport (SHM). This new transport allows software components to interchange data between them without any networking involvement.
This not only improves data delivery performance in terms of throughput and latency significantly, but it also constitutes a suitable transport layer for real-time publish-subscribe applications using DDS.
Designed with high performance requirements in mind, eProsima Fast DDS Shared Memory Transport features:
- High throughput and latency performance in IPC
- Reduction of memory copies
- Cross-platform solution supported in AMD64 Linux, Windows 10 (32 and 64 bits), Mac OSX, aarch64 Linux, QNX
Why use Shared Memory?
The normal data IPC in ROS 2 uses the loopback mechanism of the operating system. While this is good enough for many cases, in the case of large data and multiple subscribers (such a computer vision application), Fast DDS Shared Memory Transport significantly reduces latency and CPU usage while increasing the throughput.
Available Documentation:
- Shared Memory - Fast DDS docs as a form of transport
- Shared Memory - the Github project
- Shared Memory - at the ROSCon 2019 in Macau
Data Sharing Delivery
Following the Shared Memory transport, Fast DDS 2.2.0 includes now also the Data Sharing delivery, which provides a communication channel between entities within the same machine by sharing the history of the DataWriter with the DataReader through shared memory. This prevents any of the overhead involved in the transport layer, effectively avoiding any data copy between DataWriter and DataReader.
In the above image, you can see how, when the DataWriter is created, Fast DDS will pre-allocate a pool of max_samples extra_samples samples that reside in a shared memory mapped file. When publishing new data, the DataWriter will take a sample from this pool, add a reference to it in its history, and notify the DataReader which sample from the pool holds the new data.
Zero-Copy communication
Now, the ultimate data transport mechanism has finally arrived: the ZERO-COPY communication. This communication can be achieved between publishing and subscribing applications by taking advantage of the following three features:
- Data-sharing delivery: as described above, it provides a copy-less communication channel between a Datawriter and a DataReader using shared memory.
- DataWriter sample loaning: a Fast DDS extension, which allows to borrow a sample buffer from the publishing DataWriter. Doing so, the application can write data in this buffer directly, thus eliminating the necessity of a copy between application and DataWriter.
- Loans from the DataReader: The application gets the received samples as a reference to the receive queue itself. This prevents the copying of the data from the DataReader to the receiving application. Again, if Data-sharing delivery is used, the loaned data will be in the shared memory, and will indeed be the same memory buffer used in the DataWriter history.
In the end, the users are able to save time and resources. You can find multiple examples of different use cases in the eProsima Fast DDS Github repository and the specific ZERO-COPY transfer here.
More information about the eProsima and the tress different delivery mechanisms:
For any questions please contact This email address is being protected from spambots. You need JavaScript enabled to view it.
