Chapter 75 Overview

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 Chapter 76 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 Chapter 77 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 Chapter 78 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 retrieves new interface data and compares it with the previous value. This thread is used in the IP Mobility feature to detect interface changes. You can disable this thread. See 29.1.1.2 Disabling IP Locator Change Propagation.
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 58.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 59.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 59.24 TOPIC_QUERY_DISPATCH_QosPolicy (DDS Extension)).
User Threads: in addition, your application may present threads that are not part of Connext. If those threads call a DDS API, Connext 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 Chapter 82 Unregistering Threads.

Through various QosPolicies, the user application can configure the priorities and other properties of the threads created by Connext. 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.