Skip to content

Client Concurrency Model

Martin Thompson edited this page Dec 8, 2016 · 13 revisions

When clients interact with Aeron it is worth being aware of the concurrency model to know what is safe and what is not safe to be used across threads or processes.

Aeron Client

Aeron clients communicate with media driver via the command and control (C'n'C) file which is memory mapped. The media driver can run in or out of process as required. An out of process driver is isolated and can be shared by many clients. Each media driver can have many clients which can concurrently interact. Clients send commands to the driver and the driver will broadcast back events. A bi-directional heart beating protocol is used between the driver and clients to track each others presence.

Within a process the Aeron client is thread safe and can be shared between threads to manage the life-cycles of publications and subscriptions. It is good practice to have one Aeron client per process but this is not a hard requirement.

Publications

Aeron publications are thread safe within and across processes. A Publication object can be used concurrently from many threads. When separate processes add the same Publication (channel and stream id) then they will map to the same underlying memory-mapped file and can be safely used concurrently. Messages offered to the same publication will be serialised. Publications with a different channel and stream id are completely independent from each other and operate in parallel.

Subscriptions

Subscriptions are not thread safe. Each subscribing thread must create its own Subscription and poll for updates. Received messages will be delivered to all subscribers in a similar fashion to how multicast packets are received. Subscriptions to the same channel and stream id in different processes will all receive the same messages from the media driver they are connected to. Subscribers all receive the messages in parallel without additional copies.

Clone this wiki locally