New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shared memory transport design documents <master> [7932] #859
Shared memory transport design documents <master> [7932] #859
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reworked the ms1_rtps_shared_memory_transport.md, but there are some comments pending
doc/proposals/shared-memory-transport/sony/ms1_rtps_shared_memory_transport.md
Show resolved
Hide resolved
doc/proposals/shared-memory-transport/sony/ms1_rtps_shared_memory_transport.md
Show resolved
Hide resolved
doc/proposals/shared-memory-transport/eprosima/interprocess_shared_mem.md
Outdated
Show resolved
Hide resolved
doc/proposals/shared-memory-transport/eprosima/interprocess_shared_mem.md
Outdated
Show resolved
Hide resolved
doc/proposals/shared-memory-transport/sony/ms1_rtps_shared_memory_transport.md
Show resolved
Hide resolved
doc/proposals/shared-memory-transport/sony/ms1_rtps_shared_memory_transport.md
Show resolved
Hide resolved
doc/proposals/shared-memory-transport/eprosima/interprocess_shared_mem.md
Outdated
Show resolved
Hide resolved
|
||
### Objectives | ||
|
||
* Increase the communications performance of processes in the same machine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the definition by machine? including container which actually in the same machine?
this is also related to how it can detect if inter-process or not, but i guess that better to mention that also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's true "machine" is not a precise definition, The idea is that shared-memory will improve communications between processes capable of sharing local memory, that running in the same operating system instance in a machine, but of course processes running in the same container or virtual machine but not intercontainer or virtual machines.
How could we well define this idea in a phrase?
|
||
### Design considerations | ||
|
||
* **Minimize global interprocess locks**: Interprocess locks are dangerous because, in the case of one of the involved processes crash or hung while holding an interprocess lock, all the collaborating processes could be affected. In this design, the global segment is the critical area, most of accesses will be lock-free reading operations. Interprocess-locks will only be required when registering / unregistering a new listener in a port. Once the setup has been established, the risk of a process locking the whole port is minimized. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think there would be some steps to take,
- basically lock-free is better than lock-required for any reason. but eventually we do need the mutex locks between processes.
- exception must be caught by handler, and it must release the lock before the process gone. (actually process crash means that there is a bug.)
- and we can also consider read/write locks instead of mutex, and also Compare And Swap instruction to get the lock.
one question by here, what about the multiple writer case? it does not require the lock? expecting this is because writer creates local memory space to be shared so that writer does not need a lock with other writers. am i understanding correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a shared-memory port's segment resides a RingBuffer, an interprocess-mutex, and an interprocess-condition variable. Operations over the ring buffer are lock-free atomic (compare and swap) so writers and readers may push or pop data without locking any mutex.
The mutex and condition variable are used to wait on when the ring buffer is empty. So if a reader detects the ring buffer is empty it will wait on the condition. When writers push elements, lock the empy condition before pushing and after pushing notify on the condition to wake-up listeners.
So if no bugs or crashes everything is OK, but if a process crash holding an interprocess-lock it will block all readers and writers using that port. This is bug situation, so involved processes would need to be restarted or a fail-tolerance mecanishm is needed.
|
||
* **Scalable number of processes**: Every process creates its own shared memory segments to store the locally generated messages. This is more scalable than having a global segment shared between all the involved processes. | ||
|
||
* **Per application / process customizable memory usage**: Again, a local shared memory segment allows to adapt the size of the segments to the requirements of the application. Imagine for example an application sending two types of data: Video and status info. It could create a big segment to store video frames, and a small segment for the status messages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there already plan how it provide the interface to configure the memory space? API or configuration file to load?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The memory space can be configured through the transport descriptor, that can be done in the application's C++ code or with an external XML file using the fastrtps XML profiles feature.
doc/proposals/shared-memory-transport/sony/ms1_rtps_shared_memory_transport.md
Show resolved
Hide resolved
doc/proposals/shared-memory-transport/sony/ms1_rtps_shared_memory_transport.md
Show resolved
Hide resolved
doc/proposals/shared-memory-transport/sony/ms1_rtps_shared_memory_transport.md
Show resolved
Hide resolved
doc/proposals/shared-memory-transport/sony/ms1_rtps_shared_memory_transport.md
Show resolved
Hide resolved
|
||
### Objectives | ||
|
||
* Increase the communications performance of processes in the same machine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's true "machine" is not a precise definition, The idea is that shared-memory will improve communications between processes capable of sharing local memory, that running in the same operating system instance in a machine, but of course processes running in the same container or virtual machine but not intercontainer or virtual machines.
How could we well define this idea in a phrase?
|
||
### Design considerations | ||
|
||
* **Minimize global interprocess locks**: Interprocess locks are dangerous because, in the case of one of the involved processes crash or hung while holding an interprocess lock, all the collaborating processes could be affected. In this design, the global segment is the critical area, most of accesses will be lock-free reading operations. Interprocess-locks will only be required when registering / unregistering a new listener in a port. Once the setup has been established, the risk of a process locking the whole port is minimized. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a shared-memory port's segment resides a RingBuffer, an interprocess-mutex, and an interprocess-condition variable. Operations over the ring buffer are lock-free atomic (compare and swap) so writers and readers may push or pop data without locking any mutex.
The mutex and condition variable are used to wait on when the ring buffer is empty. So if a reader detects the ring buffer is empty it will wait on the condition. When writers push elements, lock the empy condition before pushing and after pushing notify on the condition to wake-up listeners.
So if no bugs or crashes everything is OK, but if a process crash holding an interprocess-lock it will block all readers and writers using that port. This is bug situation, so involved processes would need to be restarted or a fail-tolerance mecanishm is needed.
|
||
* **Scalable number of processes**: Every process creates its own shared memory segments to store the locally generated messages. This is more scalable than having a global segment shared between all the involved processes. | ||
|
||
* **Per application / process customizable memory usage**: Again, a local shared memory segment allows to adapt the size of the segments to the requirements of the application. Imagine for example an application sending two types of data: Video and status info. It could create a big segment to store video frames, and a small segment for the status messages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The memory space can be configured through the transport descriptor, that can be done in the application's C++ code or with an external XML file using the fastrtps XML profiles feature.
Signed-off-by: Tomoya.Fujita <Tomoya.Fujita@sony.com>
Co-Authored-By: tomoya <Tomoya.Fujita@sony.com>
79a76d9
to
703bea4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move the documentation of the current implementation (subfolder eprosima
) to doc/design
. Keep the documentation of the proposal by SONY on proposals
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Starting with the proposal information from Sony about shared memory transport and shared memory data sharing (#810), we will discuss and create a final design document for the shared memory transport.