Chapter 77 Event Thread

During operation, Connext must wake up at different intervals to check the condition of many different time-triggered or periodic events. These events are usually to determine if something happened or did not happen within a specified time. Often the condition must be checked periodically as long as the Entity for which the condition applies still exists. Also, the DomainParticipant may need to do something periodically to maintain connections with remote Entities.

For example, the 59.7 DEADLINE QosPolicy is used to ensure that DataWriters have published data or DataReaders have received data within a specified time period. Similarly, the 59.15 LIVELINESS QosPolicy configures Connext both to check periodically to see if a DataWriter has sent a liveliness message and to send liveliness messages periodically on the behalf of a DataWriter. As a last example, for reliable connections, heartbeats must be sent periodically from the DataWriter to the DataReader so that the DataReader can acknowledge the data that it has received, see Chapter 35 Reliability Models for Sending Data.

Connext uses an internal thread, known as the Event thread, to perform tasks initiated by events, including the following:

• Check whether or not deadlines have been missed
• Invoke user-installed Listener callbacks to notify the application of missed deadlines
• Send heartbeats to maintain reliable connections
• Call the on_data_available() callback to notify the application of instance state changes resulting from the receipt of an instance state consistency response (when you are using RECOVER_INSTANCE_STATE_CONSISTENCY in the 59.21 RELIABILITY QosPolicy).

Note: Only one Event thread is created per DomainParticipant.

The 56.5 EVENT QosPolicy (DDS Extension) of the DomainParticipant configures both the properties and resources of the Event thread. Specifically, the user may want to use this QosPolicy to set the priority, stack size and thread options of the Event thread. You must set these options before the DomainParticipant is created, because once the Event thread is started as a part of participant creation, these properties cannot be changed.

The EVENT QosPolicy also configures the maximum number of events that can be handled by the Event thread. While the Event thread can only service a single event at a time, it must maintain a queue to hold events that are pending. The initial_count and max_count parameters of the QosPolicy set the initial and maximum size of the queue.

The priority of the Event thread should be carefully set with respect to the priorities of the other threads in a system. While many events can tolerate some amount of latency between the time that the event expires and the time that the Event thread services the event, there may be application-specific events that must be handled as soon as possible.

For example, if an application uses the liveliness of a remote DataWriter to infer the correct operation of a remote application, it may be critical for the user code in the DataReader Listener callback, on_liveliness_changed(), to be called by the Event thread as soon as it can be determined that the remote application has died. The operating system uses the priority of the Event thread to schedule this action.