The SYSTEM_RESOURCE_LIMITS QosPolicy configures DomainParticipant-independent resources used by Connext DDS. Its main use is to change the maximum number of DomainParticipants that can be created within a single process (address space).
It contains the single member as shown in DDS_SystemResourceLimitsQosPolicy. For the default and valid range, please refer to the API Reference HTML documentation.
|
Type |
Field Name |
Description |
|
DDS_Long |
max_objects_per_thread |
Sizes the thread storage that is allocated on a per-thread basis when the thread calls Connext DDS APIs. |
The only parameter that you can set, max_objects_per_thread, controls the size of thread-specific storage that is allocated by Connext DDS for every thread that invokes a Connext DDS API. This storage is used to cache objects that have to be created on a per-thread basis when a thread traverses different portions of Connext DDS internal code.
Thus instead of dynamically creating and destroying the objects as a thread enters and leaves different parts of the code, Connext DDS caches the objects by storing them in thread-specific storage. We assume that a thread will repeatedly call Connext DDS APIs so that the objects cached will be needed again and again.
The number of objects that will be stored in the cache depends the number of APIs (sections of Connext DDS code) that a thread invokes. It also depends on the number of different DomainParticipants with which the thread interacts. For a single DomainParticipant, the maximum number of objects that could be stored is a constant–independent of the number of Entities created in or by the participant. A safe number to use is 200 objects per DomainParticipant.
A user thread that only interacts with a single DomainParticipant or the Entities thereof, would never have more than 200 objects stored in its cache. However, if the same thread invokes Connext DDS APIs on other Entities of other DomainParticipants, the maximum number of objects that may be stored will increase with the number of participants involved.
The default setting of this resource should work for most user applications. However, if your application uses more than 4 DomainParticipants, you may need to increase the value of max_objects_per_thread.
Say an application uses 10 DomainParticipants. If a single thread was used to create all 10 DomainParticipants, or a single thread is used to call write() on DataWriters belonging to all 10 participants, it is possible to run out of thread-specific storage. Either the creation of the participant or the write() will fail.
In that case, you will need to increase the value of max_objects_per_thread.
This QoS policy cannot be modified after the DomainParticipantFactory is used to create the first DomainParticipant or WaitSet in an application.
This QoS can be set differently in different applications.
There are no interactions with other QosPolicies.
Increasing the value of max_objects_per_thread will increase the amount of memory allocated by Connext DDS for every thread that access Connext DDS code. This includes internal Connext DDS threads as well as user threads. Each object uses about 32 bytes of memory.
© 2018 RTI