Concurrency Policy
As described in the previous section, some systems support N-to-M thread scheduling. In these systems, a process-scope thread is multiplexed with other process-scope threads on to one or more underlying kernel threads in N-to-M relationship. The concurrency policy attribute can be used to indicate whether or not the underlying threads system should increase the number of kernel threads when it creates a new process-scope thread, as illustrated in Figure 17.
Figure 17 – Concurrency policy
Issues to consider when requesting the creation of additional kernel threads:
You can increase the effective concurrency of the threads in your application because most systems can distribute kernel threads on separate processors and often use time-slicing when scheduling kernel threads on a single processor.When increasing the effective concurrency level, consider the processing cost associated with creating new kernel threads and the higher cost of scheduling and synchronizing them. Process-scope threads are generally scheduled and synchronized by code executing in the underlying threads library in user-space, while the underlying kernel threads are scheduled and synchronized by calls to the kernel.
Even though increasing the effective concurrency level can result in increased processing costs, this method is still preferable to choosing system-scope threads over process-scope threads. The difference is that kernel threads added when the concurrency level is increased are still shared between process-level threads, while system-scope threads are permanently bound to kernel threads, thereby prohibiting their reuse during blocking waits.
Using the feature test macro. The feature test macro for concurrency policy is RW_THR_HAS_CONCURRENCY_POLICY. If this macro is not defined, attempts to query or set the concurrency policy attribute always produce an exception. If it is defined, then the current environment has some level of support or recognition for concurrency policy and might allow you to get or set the concurrency policy attribute.
The enumerated type, RWConcurrencyPolicy, defines these concurrency policies as:
RW_THR_NO_CHANGE — The creation of a new process-scope with this attribute value thread does not force the creation of a new underlying kernel thread. This value does not prohibit the threads system from choosing to create new kernel threads if its own policies dictate such a necessity.RW_THR_INCREASE — Creation of a new process-scope thread forces the creation of a new underlying kernel thread.The RWThreadAttribute member functions that manipulate the concurrency policy attribute value include:
canGetConcurrencyPolicy() — Indicates whether the concurrency policy attribute is supported in the current environment and whether getConcurrencyPolicy() can currently return a legal value.isConcurrencyPolicySet() — Indicates whether the concurrency policy attribute value is the value that was previously set by a call to setConcurrencyPolicy(RWConcurrencyPolicy).getConcurrencyPolicy() — Returns the default concurrency policy value if the attribute value has not yet been defined. Otherwise, it returns the value specified in the last call to setConcurrencyPolicy(RWConcurrencyPolicy). If the current environment does not support or define the concurrency policy attribute, then attempts to use this function result in exceptions.canSetConcurrencyPolicy() — Indicates whether the concurrency policy attribute and attribute value passed as an argument are supported in the current environment.setConcurrencyPolicy(RWConcurrencyPolicy) — Sets the concurrency policy attribute to the value passed as an argument. If the current environment does not support the concurrency policy attribute or the specified attribute value, then attempts to use this function result in exceptions.resetConcurrencyPolicy() — Restores the concurrency policy value to its default value.Changing the contention scope attribute value can cause a previous concurrency policy setting to be discarded and can affect the availability of this attribute, as indicated in the following table:
Contention Scope | Concurrency Policy |
|---|---|
Process Scope(if available) | No Change or Increase(if available) |
System Scope(if available) | Not Available |
The concurrency change requested when creating a thread cannot be undone.
To determine the concurrency policy used when creating 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 getConcurrencyPolicy() member to query the attribute instance for the concurrency policy used when creating the thread.
