The EVENT QosPolicy configures the internal Connext DDS Event thread.
This QoS allows the you to configure thread properties such as priority level and stack size. You can also configure the maximum number of events that can be posted to the event thread. It contains the members in DDS_EventQoSPolicy. For defaults and valid ranges, please refer to the API Reference HTML documentation.
|
Type |
Field Name |
Description |
|
DDS_ThreadSettings_t |
thread.mask thread.priority thread.stack_size |
Thread settings for the event thread used by Connext DDS to wake up for a timed event and possibly execute listener callbacks. The values used for these settings are OS-dependent; see the RTI Connext DDS Core Libraries Platform Notes for details. Note: thread.cpu_list and thread.cpu_rotation are not relevant in this QoS policy. |
|
DDS_Long |
initial_count |
Initial number of events that can be stored simultaneously. |
|
DDS_Long |
max_count |
Maximum number of events that can be stored simultaneously. |
The Event thread is used to wake up and execute timed events posted to the event queue. In a DomainParticipant, different Entities may have constraints that have to be checked at periodic intervals or at specific times. If the constraint is violated, a callback function may need to be executed. Timed events include checking for timeouts and deadlines, and executing internal and user timeout or exception handling routines/callbacks. A combination of a time, constraint, and callback can be considered to be an event. For more information, see Event Thread.
For example, a DataReader may have a constraint that requires data to be received within a period of time specified by the DEADLINE QosPolicy. For that DataReader, an event is stored by the Event thread so that it will wake up periodically to check to see if data has arrived in time. If not, the Event thread will execute the on_requested_deadline_missed() Listener callback of the DataReader (if it was installed and enabled).
A reliable connection between a DataWriter and DataReader will also post events for sending heartbeats used in the reliable protocol discussed in Reliable Communications.
This QoS configures the parameters associated with thread creation as well as the number of events that can be simultaneously stored by the Event thread.
In a real-time operating system, the priority of the Event thread should be set relative to the priority of the events that it must handle. For example, you may want the Event thread to have a high priority if the deadlines and callbacks that it handles are time or safety critical. It may be critical that the data of a particular DataReader arrives on time or if not, alternative action is taken with minimal latency.
If you create many Entities in a DomainParticipant with QosPolicies that will post events that check deadlines, liveliness or send heartbeats, then you may need to increase the maximum number of events that can be stored by the Event thread.
If your application is sending a lot of reliable data, you should increase the event thread priority to be higher than the sending thread priority.
This QosPolicy cannot be modified after the DomainParticipant is created.
It can be set differently on the publishing and subscribing sides.
Increasing initial_count and max_count will increase initial and maximum memory used for storing events.
Setting the thread parameters correctly on a real-time operating system is usually critical to the proper overall functionality of the applications on that system. Larger values for the thread.stack_size parameter will use up more memory.
By default, a DomainParticipant will dynamically allocate memory as needed for events posted to the event thread. However, by setting an maximum value or setting the initial and maximum value to be the same, you can either bound the amount of memory allocated for the event thread or prevent a DomainParticipant from dynamically allocating memory for the event thread after initialization.
© 2017 RTI