|Represents the maximum samples the middleware can store for any one DDSDataWriter (or DDSDataReader). |
|Represents the maximum number of instances a DDSDataWriter (or DDSDataReader) can manage. |
|Represents the maximum number of samples of any one instance a DDSDataWriter (or DDSDataReader) can manage. |
|<<eXtension>> Represents the initial samples the middleware will store for any one DDSDataWriter (or DDSDataReader). |
|<<eXtension>> Represents the initial number of instances a DDSDataWriter (or DDSDataReader) will manage. |
|<<eXtension>> Number of hash buckets for instances. |
In general, this QoS policy is used to limit the amount of system memory that RTI Connext can allocate. For embedded real-time systems and safety-critical systems, pre-determination of maximum memory usage is often required. In addition, dynamic memory allocation could introduce non-deterministic latencies in time-critical paths.
This QoS policy can be set such that an entity does not dynamically allocate any more memory after its initialization phase.
If DDSDataWriter objects are communicating samples faster than they are ultimately taken by the DDSDataReader objects, the middleware will eventually hit against some of the QoS-imposed resource limits. Note that this may occur when just a single DDSDataReader cannot keep up with its corresponding DDSDataWriter. The behavior in this case depends on the setting for the RELIABILITY. If reliability is DDS_BEST_EFFORT_RELIABILITY_QOS, then RTI Connext is allowed to drop samples. If the reliability is DDS_RELIABLE_RELIABILITY_QOS, RTI Connext will block the DDSDataWriter or discard the sample at the DDSDataReader in order not to lose existing samples.
The constant DDS_LENGTH_UNLIMITED may be used to indicate the absence of a particular limit. For example setting DDS_ResourceLimitsQosPolicy::max_samples_per_instance to DDS_LENGTH_UNLIMITED will cause RTI Connext not to enforce this particular limit.
If these resource limits are not set sufficiently, under certain circumstances the DDSDataWriter may block on a write() call even though the DDS_HistoryQosPolicy is DDS_KEEP_LAST_HISTORY_QOS. To guarantee the writer does not block for DDS_KEEP_LAST_HISTORY_QOS, make sure the resource limits are set such that:
DDS_ResourceLimitsQosPolicy::max_samples must be consistent with DDS_ResourceLimitsQosPolicy::max_samples_per_instance. For these two values to be consistent, it must be true that DDS_ResourceLimitsQosPolicy::max_samples >= DDS_ResourceLimitsQosPolicy::max_samples_per_instance. As described above, this limit will not be enforced if DDS_ResourceLimitsQosPolicy::max_samples_per_instance is set to DDS_LENGTH_UNLIMITED.
For unkeyed types, this value has to be equal to max_samples_per_instance if max_samples_per_instance is not equal to DDS_LENGTH_UNLIMITED.
When batching is enabled, the maximum number of data samples a DDSDataWriter can manage will also be limited by DDS_DataWriterResourceLimitsQosPolicy::max_batches.
[range] [1, 100 million] or DDS_LENGTH_UNLIMITED, >= initial_samples, >= max_samples_per_instance, >= DDS_DataReaderResourceLimitsQosPolicy::max_samples_per_remote_writer or >= DDS_RtpsReliableWriterProtocol_t::heartbeats_per_max_samples
For DDS_DataWriterQos max_samples >= DDS_DataWriterProtocolQosPolicy::rtps_reliable_writer.heartbeats_per_max_samples if batching is disabled.
For unkeyed types, this value has to be equal to max_samples or DDS_LENGTH_UNLIMITED.
[range] [1,100 million], <= max_samples
<<eXtension>> Number of hash buckets for instances.
The instance hash table facilitates instance lookup. A higher number of buckets decreases instance lookup time but increases the memory usage.
[default] 1 [range] [1,1 million]