This section describes the AIX POSIX 1003.1c thread attribute support.
This section describes the AIX POSIX 1003.1c implementation-specific support, behavior, and restrictions for thread scheduling attributes.
The start policy attribute is fully supported by the AIX implementation of the Threads Module and defaults to RW_THR_START_RUNNING.
In POSIX 1003.1c-compliant systems, support for contention scope is optional. Even if the API indicates that priority scheduling is supported, the environment may only allow one policy.
The AIX implementation of POSIX 1003.1c supports both process and system scope threads. The Threads Module maps its RWContentionScope values to the underlying POSIX 1003.1c API as follows:
| Threads Module RWContentionScope | POSIX 1003.1c Contention Scope |
| RW_THR_PROCESS_SCOPE | PTHREAD_SCOPE_PROCESS |
| RW_THR_SYSTEM_SCOPE | PTHREAD_SCOPE_SYSTEM |
The scheduling inheritance policy attribute is fully supported by the AIX implementation of the Threads Module and defaults to RW_THR_INHERIT.
The concurrency policy attribute is not supported in the AIX implementation of the Threads Module. Attempts to get or set this attribute value will result in exceptions.
In POSIX 1003.1c-compliant systems, support for scheduling policy is optional. The Threads Module determines whether scheduling policy is supported by testing for the definition of the macro _POSIX_THREAD_PRIORITY_SCHEDULING.
The AIX implementation of the Threads Module supports all three scheduling policies as defined by the standard:
SCHED_FIFO -- Specifies FIFO Scheduling, where threads run until preempted by a thread of higher priority, or until blocked. Thread priorities are set by the application; the system does not dynamically change a thread's priority.
SCHED_RR -- Selects round-robin scheduling, where the highest-priority threads runs until preempted by a thread of higher priority, until some time-quantum has elapsed, or until blocked. Threads possessing the same priority value get time-sliced and scheduled in a round-robin fashion. Thread priorities are set by the application; the system does not dynamically change a thread's priority.
SCHED_OTHER -- Selects the default scheduling policy for an implementation. This policy typically uses time-slicing with dynamic adjustments to priority and or time-slice quantum.
Note that the AIX POSIX implementation limits the scheduling policies SCHED_RR and SCHED_FIFO to processes with superuser privileges. Therefore, the RWSchedulingPolicy values RW_THR_PREEMPTIVE and RW_THR_TIME_SLICED_FIXED are limited to superusers as well.
Table 2 shows how the Threads Module AIX POSIX implementation maps RWSchedulingPolicy values to the underlying POSIX 1003.1c policy values.
| Threads Module RWSchedulingPolicy Values | POSIX 1003.1c Scheduling Policy |
| RW_THR_PREEMPTIVE | SCHED_FIFO |
| RW_THR_TIME_SLICED_FIXED | SCHED_RR |
| RW_THR_TIME_SLICED_DYNAMIC(RW_THR_OTHER may also be used to set) | SCHED_OTHER |
Attempts to set any other policy values result in an RWTHROperationNotAvailable exception. None of these policies may be explicitly requested unless the process has superuser privileges.
Note that the Threads Module has mapped two policy values to the same underlying policy, SCHED_OTHER. Calls to getSchedulingPolicy() return RW_THR_TIME_SLICED_DYNAMIC because that value gives the most meaningful interpretation.
In POSIX 1003.1c-compliant systems, support for the specification of thread priority is optional. The Threads Module determines whether scheduling priority is supported by testing for the definition of the macro _POSIX_THREAD_PRIORITY_SCHEDULING.
The AIX POSIX implementation does support priority scheduling. The Threads Module uses the standard POSIX.1b (formerly POSIX.4) functions sched_get_priority_min() and sched_get_priority_max() to determine the legal range of priority values.
Under this implementation, the priorities vary according to the scheduling policy, as shown in Table 3.
| Scheduling Policy | Minimum Priority | Maximum Priority | Default Priority |
| RW_THR_PREEMPTIVE | 1 | 127 | 1 |
| RW_THR_TIME_SLICED_FIXED | 1 | 127 | 1 |
| RW_THR_TIME_SLICED_DYNAMIC | 1 | 127 | 1 |
A new thread's priority value is inherited from the creating thread by default, unless the priority attribute has been explicitly set, or the inheritance policy has been changed from its default value of RW_THR_INHERIT to RW_THR_EXPLICIT. If the inheritance policy is RW_THR_EXPLICIT, the Threads Module defines the default priority to be the minimum priority.
The AIX POSIX threads implementation ignores attempts to set the priority if the thread scope is RW_THR_SYSTEM_SCOPE and the scheduling policy is RW_THR_TIME_SLICED_DYNAMIC. Threads with this scheduling policy are subject to continuous priority adjustments.
The allowed range of priorities on AIX is different from the priorities that are actually used. A priority in the range of 1 to 39 results in a priority of 40, and a priority in the range of 81 to 127 results in a priority of 80. So the effective range of priority values is 40 to 80. Only privileged users can set a priority greater than 60.
The time-slice quantum attribute is not supported in the AIX implementation of the Threads Module. Attempts to get or set this attribute value will result in exceptions.
In POSIX 1003.1c-compliant systems, support for user specification of stack attributes is optional. AIX supports size control for a system-managed stack, and supports user-managed stacks.
POSIX 1003.1c-compliant systems provide optional support for controlling the reserve size of a system-managed stack, but provide no support for controlling the commitment of physical memory and page-file space to a thread stack.
Stack Reserve Size. In POSIX 1003.1c-compliant systems, support for user specification of stack reserve size is optional. The Threads Module determines the support for stack reserve size by testing for the definition of the standard POSIX macro _POSIX_THREAD_ATTR_STACKSIZE. AIX does support the stack reserve size attribute for a system-managed stack.
If available, the Threads Module uses the following function call, sysconf(_SC_THREAD_STACK_MIN), as defined in <unistd.h>, to determine recommended minimum size for a thread stack. Otherwise, the Threads Module uses the POSIX macro, PTHREAD_STACK_MIN, to determine the recommended minimum size for a user thread stack. The API defines this value to be 8KB. This is the value that will be returned by the getMinStackSize() member.
If you query for the default stack reserve size, the Threads Module uses the pthread_attr_getstacksize() function to retrieve the default stack size defined by an initialized pthread_attr_t instance. Under this API, the default stack size is 96KB.
The Threads Module imposes no upper limit for stack reserve size; the maximum stack size is effectively limited by available virtual memory and page-file size. If the stack reserve size specified is too large for available resources, an exception will be produced at the time a thread is created using the thread attribute instance with the offending reserve size value.
Stack Commit Size. The stack commit size attribute is not supported in the AIX implementation of the Threads Module. Attempts to get or set this attribute value will result in exceptions.
In POSIX 1003.1c-compliant systems, support for user-defined stacks is optional. The Threads Module determines the support for user-defined stacks by testing for the definition of the standard POSIX macro _POSIX_THREAD_ATTR_STACKADDR.
The Threads Module on AIX supports user-managed stacks.
If an attempt is made to set the user stack address to zero, or to set the user stack size to a value less than the minimum stack size returned by the getMinStackSize() function, a RWTHRBoundsError exception is produced.
The Threads Module imposes no upper limit for user stack size; the maximum stack size is effectively limited by the virtual memory and pagefile size available to the user.
Attempts to query for a default user-stack address value or user-stack size value will result in an RWTHROperationNotAvailable exception. These values may only be queried after they have been set.
The user-managed stack attribute and stack reserve size stack attribute are mutually exclusive, therefore, a call to setStackReserveSize() replaces or nullifies the attribute settings produced by any previous call to setUserStack() and vice versa.
Copyright © Rogue Wave Software, Inc. All Rights Reserved.
The Rogue Wave name and logo, and SourcePro, are registered trademarks of Rogue Wave Software. All other trademarks are the property of their respective owners.
Provide feedback to Rogue Wave about its documentation.