You are here:

21. Connext DDS Threading Model

This chapter describes the internal threads that Connext DDS uses for sending and receiving data, maintaining internal state, and calling user code when events occur such as the arrival of new DDS data samples. It may be important for you to understand how these threads may interact with your application.

A DomainParticipant uses three main types of threads:

Database Thread maintains the database of DDS Entities stored in the DomainParticipant. It is responsible for purging the objects marked for deletion when they are no longer needed. See 21.1 Database Thread.
Event Thread detects triggered events and acts accordingly, invoking user functions when needed (e.g., when a callback was specified for that specific event). See 21.2 Event Thread.
Receive Threads get bytes from transport plugins, then deserialize and store the (meta)data in the receive queue of a DataReader and invoke the on_data_available() callback. Receive threads are also responsible for processing metadata (e.g., discovery traffic, ACKs, NACKs). See 21.3 Receive Threads.

The actual number of threads depends on the configuration of various QoS policies as well as the implementation of the transports used by the DomainParticipant to send and receive data. In addition, other threads might be created for specific purposes:

Interface Tracking Thread checks if there is new interface data. It notifies the user/application and updates the interface data. Note: this thread is created in support of the IP Mobility feature.
Transport-Specific Threads handle the tasks that are specific to a transport (e.g., the TCP Transport plugin creates two threads, one for control and one for events).
Asynchronous Publishing Threads handle the data transmission for Asynchronous Publishers (see 7.4.1 ASYNCHRONOUS_PUBLISHER QosPolicy (DDS Extension)).
Asynchronous Batch Flushing Threads handle batches of data samples, flushing them when needed. These threads are only created when batching is enabled (see 7.5.2 BATCH QosPolicy (DDS Extension)) and max_flush_delay is not DURATION_INFINITE.
Topic Query Publication Threads publish historical samples in response to a TopicQuery. These threads are only created when topic query dispatch is enabled (see 7.5.24 TOPIC_QUERY_DISPATCH_QosPolicy (DDS Extension)).
User Threads: in addition, your application may present threads that are not part of Connext DDS. If those threads call a DDS API, Connext DDS will automatically register them (i.e., allocate some resources to keep statistics and to handle concurrent access to DDS Entities). To free up all the allocated resources, you may need to unregister these threads, as explained in 21.8 Unregistering Threads.

Through various QosPolicies, the user application can configure the priorities and other properties of the threads created by Connext DDS. In real-time systems, the user often needs to set the priorities of all threads in an application relative to each other for the proper operation of the system.

For information on checking thread names, see 25.5 Identifying Threads Used by Connext DDS.