StatusConditions are created automatically by Connext DDS, one for each Entity. Connext DDS will trigger the StatusCondition when there is a change to any of that Entity’s enabled statuses.
By default, when Connext DDS creates a StatusCondition, all status bits are turned on, which means it will check for all statuses to determine when to trigger the StatusCondition. If you only want Connext DDS to check for specific statuses, you can use the StatusCondition’s set_enabled_statuses() operation and set just the desired status bits.
The trigger_value of the StatusCondition depends on the communication status of the Entity (e.g., arrival of data, loss of information, etc.), ‘filtered’ by the set of enabled statuses on the StatusCondition.
The set of enabled statuses and its relation to Listeners and WaitSets is detailed in How StatusConditions are Triggered.
StatusCondition Operations lists the operations available on StatusConditions.
|
Operation |
Description |
|
set_enabled_statuses |
Defines the list of communication statuses that are taken into account to determine the trigger_value of the StatusCondition. This operation may change the trigger_value of the StatusCondition. WaitSets behavior depend on the changes of the trigger_value of their attached conditions. Therefore, any WaitSet to which the StatusCondition is attached is potentially affected by this operation. If this function is not invoked, the default list of enabled statuses includes all the statuses. |
|
get_enabled_statuses |
Retrieves the list of communication statuses that are taken into account to determine the trigger_value of the StatusCondition. This operation returns the statuses that were explicitly set on the last call to set_enabled_statuses() or, if set_enabled_statuses() was never called, the default list |
|
get_entity |
Returns the Entity associated with the StatusCondition. Note that there is exactly one Entity associated with each StatusCondition. |
Unlike other types of Conditions, StatusConditions are created by Connext DDS, not by your application. To access an Entity’s StatusCondition, use the Entity’s get_statuscondition() operation. For example:
Condition* my_status_condition = entity->get_statuscondition();
In the Modern C++ API, use the StatusCondition constructor to obtain a reference to the Entity’s condition. For example:
dds::core::cond::StatusCondition my_status_condition(entity)
After a StatusCondition is triggered, call the Entity’s get_status_changes() operation to see which status(es) changed.
Note: Not all statuses will activate the StatusCondition. Refer to the API Reference HTML documentation of the individual statuses for that information.
The trigger_value of a StatusCondition is the boolean OR of the ChangedStatusFlag of all the communication statuses to which it is sensitive. That is, trigger_value is FALSE only if all the values of the ChangedStatusFlags are FALSE.
The sensitivity of the StatusCondition to a particular communication status is controlled by the list of enabled_statuses set on the Condition by means of the set_enabled_statuses() operation.
Once a StatusCondition’s trigger_value becomes true, it remains true until the status that changed is reset. To reset a status, call the related get_*_status() operation. Or, in the case of the data available status, call read(), take(), or one of their variants.
Therefore, if you are using a StatusCondition on a WaitSet to be notified of events, your thread will wake up when one of the statuses associated with the StatusCondition becomes true. If you do not reset the status, the StatusCondition’s trigger_value remains true and your WaitSet will not block again—it will immediately wake up when you call wait().
© 2018 RTI