Scheduling Contention Scope
The contention scope attribute is used to specify whether a thread is to compete for processing resources with other threads in the same process or with other processes in the same system.
A process-scope thread is multiplexed with other process-scope threads on one or more underlying kernel threads in a N:1 or N:M relationship. A system-scope thread is typically bound in a 1:1 relationship with a kernel thread. Figure 16 illustrates these relationships.
Figure 16 – Process-scope and system-scope relationships
Choosing between process-scope and system-scope. When choosing between process-scope and system-scope threads, consider the processing cost associated with scheduling and synchronizing them. Process-scope threads are generally scheduled and synchronized by code executing in the underlying threads library in user-space, while system-level threads are scheduled and synchronized by the kernel. Kernel-level synchronization and scheduling is, in general, significantly more expensive than user-level synchronization and scheduling. Because of this high processing cost, specify system contention scope only when system-wide scheduling issues must be addressed by your code, as when your application must include real-time behavior or operate under real-time constraints.
Using the feature test macro. The feature test macro for contention scope is RW_THR_HAS_CONTENTION_SCOPE. If this macro is not defined, attempts to query or set the contention scope attribute always produce an exception. If it is defined, then the current environment has some level of support or recognition for contention scope and might allow you to get or set the contention scope attribute.
The enumerated type, RWContentionScope, defines these contention scope policies as:
RW_THR_PROCESS_SCOPERW_THR_SYSTEM_SCOPEThe RWThreadAttribute member functions that manipulate the contention scope attribute value include:
canGetContentionScope() — Indicates whether the contention scope attribute is supported in the current environment and whether getContentionScope() can currently return a legal value.isContentionScopeSet() — Indicates whether the contention scope attribute value is the value that was previously set by a call to setContentionScope(RWContentionScope).getContentionScope() — Returns the default contention scope value if the attribute value has not yet been defined. Otherwise, it returns the value specified in the last call to setContentionScope(RWContentionScope). If the current environment does not support or define the contention scope attribute, then attempts to use this function result in exceptions.canSetContentionScope() — Indicates whether the contention scope attribute and attribute value passed as an argument are supported in the current environment.setContentionScope(RWContentionScope) — Sets the contention scope attribute to the value passed as an argument. If the current environment does not support the contention scope attribute or the specified attribute value, then attempts to use this function result in exceptions.resetContentionScope() — Restores the contention scope value to its default value.Specifying the contention scope. The contention scope of a thread can only be specified when a thread is created. You cannot change the contention scope of an active thread.
Changing the contention scope. Changing the contention scope value might cause a previous setting of the scheduling policy, priority, time-slice quantum, and concurrency attribute to be discarded. When you change the contention scope attribute, the Threading package validates these related attributes to ensure that any previous setting is compatible with the new scope, and if not, resets that attribute. The availability, default value, and supported range for these dependent attributes often vary in response to changes in the contention scope value. The specific dependencies and validation requirements are unique to each environment, and can be found in the appropriate user’s guide supplement.
Determining contention scope. To determine the contention scope of an active thread:
1. Acquire a handle to the thread’s runnable instance.
2. Use the getActiveAttribute() member in the handle class to retrieve a copy of the RWThreadAttribute instance used to create the thread.
3. Use the getContentionScope() member to query the attribute instance for the contention scope used.
