Skip to content
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

Merged
merged 10 commits into from Mar 16, 2020

Conversation

MiguelCompany
Copy link
Member

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.

@MiguelCompany MiguelCompany added the design Issue to track a new design label Nov 14, 2019
@eProsima eProsima deleted a comment from richiware Nov 14, 2019
@eProsima eProsima deleted a comment from richiware Nov 14, 2019
@eProsima eProsima deleted a comment from richiware Nov 14, 2019
@eProsima eProsima deleted a comment from richiware Nov 14, 2019
@eProsima eProsima deleted a comment from richiware Nov 14, 2019
Copy link
Contributor

@IkerLuengo IkerLuengo left a 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


### Objectives

* Increase the communications performance of processes in the same machine.
Copy link
Contributor

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.

Copy link
Contributor

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.
Copy link
Contributor

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?

Copy link
Contributor

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.
Copy link
Contributor

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?

Copy link
Contributor

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.


### Objectives

* Increase the communications performance of processes in the same machine.
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Contributor

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.

@adolfomarver adolfomarver force-pushed the feature/shared-memory/transport-design branch from 79a76d9 to 703bea4 Compare March 13, 2020 09:59
@adolfomarver adolfomarver changed the title Shared memory: transport design Shared memory transport design documents <master> [7932] Mar 13, 2020
@adolfomarver adolfomarver changed the base branch from feature/shared-memory/transport to master March 13, 2020 10:07
Copy link
Contributor

@IkerLuengo IkerLuengo left a 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.

Copy link
Contributor

@IkerLuengo IkerLuengo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@MiguelCompany MiguelCompany merged commit 8936299 into master Mar 16, 2020
@MiguelCompany MiguelCompany deleted the feature/shared-memory/transport-design branch March 16, 2020 11:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Issue to track a new design
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants