The following sections describe the specific support, behavior, and restrictions for thread scheduling attributes under OSF/1 version 4.0 and the POSIX 1003.1c V1 API.
The start policy attribute is fully supported by the OSF/1 implementation of Threads.h++ and defaults to RW_THR_START_RUNNING.
In POSIX 1003.1c-compliant systems, support for contention scope is optional. Threads.h++ determines whether contention scope is supported by testing for the definition of the macro _POSIX_THREAD_PRIORITY_SCHEDULING. Even if the API indicates that priority scheduling is supported, the environment may only allow one policy.
The OSF/1 version 4.0d implementation of POSIX 1003.1c supports both process and system scope threads. Threads.h++ maps its RWContentionScope values to the underlying POSIX 1003.1cAPI as follows:
Threads.h++ RWContentionScope | POSIX 1003.1c V1 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 OSF/1 implementation of Threads.h++ and defaults to RW_THR_INHERIT.
The concurrency policy attribute is not supported in the OSF/1 implementation of Threads.h++. Attempts to get or set this attribute value will result in exceptions.
In POSIX 1003.1c compliant systems, support for the specification of scheduling policy is optional. Threads.h++ determines whether scheduling policy is supported by testing for the definition of the macro _POSIX_THREAD_PRIORITY_SCHEDULING. Even if the API indicates that priority scheduling is supported, the environment may not support all policies.
The OSF/1 4.0d implementation of the POSIX 1003.1c threads API 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 thread runs until preempted by a thread of higher priority, until some time-quantum has elapsed, or until blocked. Threads possessing the same priority value are 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.
The Threads.h++ OSF/1 implementation maps its RWSchedulingPolicy values to the underlying POSIX 1003.1c policy values as follows:
Threads.h++ RWSchedulingPolicy | POSIX 1003.1c V1 Scheduling Policy |
RW_THR_PREEMPTIVE |
SCHED_FIFO |
RW_THR_TIME_SLICED_FIXED |
SCHED_RR |
RW_THR_TIME_SLICED_DYNAMIC (RW_THR_OTHER may be used to set) |
SCHED_OTHER |
Attempts to set any other scheduling policy value will result in an RWTHROperationNotAvailable exception.
Note that Threads.h++ has mapped two policy values to the same underlying policy, SCHED_OTHER. Calls to getSchedulingPolicy() will return RW_THR_TIME_SLICED_DYNAMIC since that value gives the most meaningful interpretation.
A new thread's scheduling policy is inherited from the creating thread by default, unless the scheduling policy 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_INHERIT, and you query for the default policy, Threads.h++ will return the scheduling policy used by the calling thread. If the inheritance policy is RW_THR_EXPLICIT, Threads.h++ defines the default scheduling policy to be RW_THR_TIME_SLICED_DYNAMIC.
In POSIX 1003.1c-compliant systems, support for the specification of thread priority is optional. Threads.h++ determines whether scheduling priority is supported by testing for the definition of the macro _POSIX_THREAD_PRIORITY_SCHEDULING.
The OSF/1 version 4.0f implementation does support priority scheduling. Threads.h++ uses the 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 by scheduling policy as shown in the following table:
Scheduling Policy | Minimum Priority | Maximum Priority | Default Priority |
RW_THR_PREEMPTIVE |
0 |
63 |
19 |
RW_THR_TIME_SLICED_FIXED |
0 |
63 |
19 |
RW_THR_TIME_SLICED_DYNAMIC |
0 |
63 |
19 |
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_INHERIT, and you query for the default priority, Threads.h++ will return the priority of the calling thread. If the inheritance policy is RW_THR_EXPLICIT, Threads.h++ defines the default priority in accordance with the values listed in the table above.
The time-slice quantum attribute is not supported in the OSF/1 implementation of Threads.h++. 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. OSF/1 supports size control for a system-managed stack, but does not support 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. Threads.h++ determines the support for stack reserve size by testing for the definition of the standard POSIX macro _POSIX_THREAD_ATTR_STACKSIZE.
OSF/1 does support the stack reserve size attribute for a system-managed stack.
Threads.h++ uses the POSIX macro, PTHREAD_STACK_MIN, to determine recommended minimum size for a thread stack. OSF/1 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, Threads.h++ uses the pthread_attr_getstacksize() function to retrieve the default stack size defined by an initialized pthread_attr_t instance. Under OSF/1, the default stack size is 21120 bytes (20.625KB).
To ensure that each thread's stack size is always greater than the minimum allowable stack size, Threads.h++ adds the minimum stack size value to any size value retrieved from a thread attribute at the time a thread is created.
Threads.h++ imposes no upper limit for stack reserve size; the maximum stack size is effectively limited by available virtual memory space and page-file size. If the stack reserve size specified is too large for the 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 OSF/1 implementation of Threads.h++. 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. Threads.h++ determines the support for user-defined stacks by testing for the definition of the standard POSIX macro _POSIX_THREAD_ATTR_STACKADDR.
The OSF/1 4.0d implementation does not support user-defined stacks; any attempts to get or set the user stack address and size attributes will result in exceptions.
©Copyright 2000, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.