Two fields in the DDS_ThreadSettings_t structure (see Thread Settings) are related to CPU core affinity: cpu_list and cpu_rotation.
Note: Although DDS_ThreadSettings_t is used in the Event, Database, ReceiverPool, and AsynchronousPublisher QoS policies, cpu_list and cpu_rotation are only relevant in the RECEIVER_POOL QosPolicy (DDS Extension).
While most thread-related QoS settings apply to a single thread, the ReceiverPool QoS policy’s thread-settings control every receive thread created. In this case, there are several schemes to map M threads to N processors; cpu_rotation controls which scheme is used.
The cpu_rotation determines how cpu_list affects processor affinity for thread-related QoS policies that apply to multiple threads. If cpu_list is empty, cpu_rotation is irrelevant since no affinity adjustment will occur. Suppose instead that cpu_list ={0,1} and that the middleware creates three receive threads: {A, B, C}. If cpu_rotation is set to CPU_NO_ROTATION, threads A, B and C will have the same processor affinities (0-1), and the OS will control thread scheduling within this bound.
CPU affinities are commonly denoted with a bitmask, where set bits represent allowed processors to run on. This mask is printed in hex, so a CPU affinity of 0-1 can be represented by the mask 0x3.
If cpu_rotation is CPU_RR_ROTATION, each thread will be assigned in round-robin fashion to one of the processors in cpu_list; perhaps thread A to 0, B to 1, and C to 0. Note that the order in which internal middleware threads spawn is unspecified.
The RTI Connext DDS Core Libraries Platform Notes describe which architectures support this feature.
© 2018 RTI