DDS: Asynchronous vs Synchronous Publishing

DIFFERENCES BETWEEN PUBLICATION MODES: ADVANTAGES AND CAVEATS

eProsima Fast DDS implements both possible publication modes for the middleware layer: SYNCHRONOUS and ASYNCHRONOUS publication mode. The main difference between them consist in how the write/publish operation is carried out: while the SYNCHRONOUS mode waits until all data has been sent, the ASYNCHRONOUS uses an internal thread to send the data. This post deals with the differences between both publication modes in Fast DDS and the related caveats.

ASYNCHRONOUS Publication Mode

Instead of sending the data directly within the context of the user thread, the ASYNCHRONOUS publication mode uses an internal thread to send the data. Therefore, selecting this publication mode implies that the write operation returns before the data has actually been sent. The ASYNCHRONOUS thread is then in charge of sending the data to all matched DataReaders. The following steps are carried out every time the write operation is invoked:

1. The data is written in the DataWriter’s History, which acts as a queue for the data to be sent.
2. The ASYNCHRONOUS thread is woken up and notified that new data has been added to the queue.
3. The write operation finishes, returning control to the user application.
4. The ASYNCHRONOUS thread takes charge of sending the data to the DataReaders in parallel execution.

SYNCHRONOUS Publication Mode

Setting the SYNCHRONOUS publication mode implies that the data is sent directly within the context of the user thread. Every time the write operation is invoked, the following steps are carried out before returning control to the user:

1. The data is written in the DataWriter’s History.
2. Control to the user application is not returned until the data has been written into the network sockets or shared memory buffers (depending on the transport layer in use).

Additionally, if there are local readers (Intraprocess), the data is directly sent to each one (no transport is involved), their listeners are notified, and the corresponding callbacks are executed before returning control to the user.

Advantages and caveats

Knowing the differences between both publication modes, the associated advantages and disadvantages for each mode are explained in some detail:

User thread control

The ASYNCHRONOUS publication mode allows the user more control of its thread, whereas the SYNCHRONOUS publication mode spends more time in the write operation, effectively preventing other operations in the user thread to be performed.

Using the ASYNCHRONOUS publication mode prevents the user thread to make any network calls and therefore the write operation returns faster and more deterministically, although the actual delivery is slower, as explained in the next point. This could be important when the user thread is executing time-critical code.

Performance

The SYNCHRONOUS publication mode may have better performance because there is no need to notify and wake up the ASYNCHRONOUS thread, thus saving the context switching resources. However, even though the ASYNCHRONOUS publication mode may increase latency, it allows the configuration of flow controllers that avoid flooding the network, which is advisable for large data rates.

Blocking behavior

The DDS standard states that the write operation may block in some specific situations, especially when the History is completely filled. Therefore, it is important to correctly configure the History management related Quality of Service (QoS) policies to prevent this from happening. This QoS policies are:

• History QoS Policy: how many samples are kept within the history. It could be set to KEEP ALL the samples (within the available resource limits explained next) or to KEEP LAST which keeps only a given number of samples (also known as History Depth).
• Resource Limits QoS Policy: this policy controls the maximum resources available.
• Durability QoS Policy: how long the samples are kept within the History in case that a late joiner wants to access those samples.
• Reliability QoS Policy: this policy specifies the delivery of the samples. If set to BEST EFFORT, the sample is sent only once and no confirmation of reception is expected whereas if this QoS is set to RELIABLE, a confirmation for all samples is expected. This latter configuration may be troublesome when sending large samples that need fragmentation because the sample’s lost fragments would have to be delivered again (with the associated network load). Without receiving the acknowledgement, the RELIABLE History is not allowed to dispose of samples.

It is more common to fill the History when the publication mode is ASYNCHRONOUS, as the data is being sent in a separate thread. For example, if the user wants to send large samples and has selected the RELIABLE Reliability QoS Policy but the network is lossy, there is a high probability that the application will block for some time (the write operation keeps adding samples to the History which is not being emptied because the data is being lost in the network). In this case, it is important to know the limits of your network and set up a proper flow controller, and to tune correctly the resource limits for your application. Therefore, configuring the Quality of Service (QoS) of your DataWriters and DataReaders is paramount to prevent this blocking behavior.

Finally, the SYNCHRONOUS publication mode also blocks during callbacks executions. This is important because it can cause a thread deadlock. This is the reason why it is not advisable to call any of the Fast DDS APIs within the callback methods (except for the read and take operations), because it is an undefined behavior due to race conditions and can easily cause a deadlock.

MORE INFORMATION ABOUT EPROSIMA FAST DDS AND QUESTIONS ABOUT ASYNCHRONOUS VS SYNCHRONOUS PUBLISHING :

For any questions please contact This email address is being protected from spambots. You need JavaScript enabled to view it.