Connext DDS uses internal data structures to store information about locally-created and remotely-discovered Entities. In addition, it will store various objects and data used by Connext DDS for maintaining proper communications between applications. This “database” is created for each DomainParticipant.
As Entities and objects are created and deleted during the normal operation of the user application, different entries in the database may be created and deleted as well. Because multiple threads may access objects stored in the database simultaneously, the deletion and removal of an object from the database happens in two phases to support thread safety.
When an entry/object in the database is deleted either through the actions of user code or as a result of a change in system state, it is only marked for deletion. It cannot be actually deleted and removed from the database until Connext DDS can be sure that no threads are still accessing the object. Instead, the actual removal of the object is delegated to an internal thread that Connext DDS spawns to periodically wake up and purge the database of deleted objects.
This thread is known as the Database thread (also referred to as the database cleanup thread).
The DATABASE QosPolicy (DDS Extension) of the DomainParticipant configures both the resources used by the database as well as the properties of the cleanup thread. Specifically, the user may want to use this QosPolicy to set the priority, stack size and thread options of the cleanup thread. You must set these options before the DomainParticipant is created, because once the cleanup thread is started as a part of participant creation, these properties cannot be changed.
The period at which the database-cleanup thread wakes up to purge deleted objects is also set in the DATABASE QosPolicy. Typically, this period is set to a long time (on the order of a minute) since there is no need to waste CPU cycles to wake up a thread only to find nothing to do.
However, when a DomainParticipant is destroyed, all of the objects created by the DomainParticipant will be destroyed as well. Many of these objects are stored in the database, and thus must be destroyed by the cleanup thread. The DomainParticipant cannot be destroyed until the database is empty and is destroyed itself. Thus, there is a different parameter in the DATABASE QosPolicy, shutdown_cleanup_period, that is used by the database cleanup thread when the DomainParticipant is being destroyed. Typically set to be on the order of a second, this parameter reduces the additional time needed to destroy a DomainParticipant simply due to waiting for the cleanup thread to wake up and purge the database.
© 2015 RTI