5.3 LinuxThreads POSIX 1003.1c Thread Attribute Support

This section describes the Linux POSIX 1003.1c implementation-specific support, behavior, and restrictions for thread scheduling attributes.

The start policy attribute is fully supported by the LinuxThreads 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.

LinuxThreads v0.8 does not support process-scope threads because each LinuxThread is a separate Unix process. LinuxThreads has only one scheduler for all processes.¹ Therefore, all threads have a fixed contention scope of RW_THR_SYSTEM_SCOPE.

You may query the contention scope and freely set it to RW_THR_SYSTEM_SCOPE (although it is already set to that by default); but any attempt to change the scope to RW_THR_PROCESS_SCOPE produces an exception.

The LinuxThreads POSIX implementation of Threads.h++ fully supports the scheduling inheritance policy attribute, which defaults to RW_THR_EXPLICIT.

LinuxThreads v0.8 does not support process-scope threads because each LinuxThread is a separate Unix process (see Section 5.4). Therefore, the concurrency policy attribute is not supported in the Linux implementation of Threads.h++. Attempts to get or set this attribute value results in exceptions.

In POSIX 1003.1c-compliant systems, support for scheduling policy is optional. Threads.h++ determines whether scheduling policy is supported by testing for the definition of the macro _POSIX_THREAD_PRIORITY_SCHEDULING.

The LinuxThreads POSIX implementation of Threads.h++ 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. According to the Linux manpage sched_setscheduler(2), under Linux, this policy is "based on the nice level ... and increased for each time quantum the process [i.e. thread] is unable to run."

Note that LinuxThreads 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 10 shows how Threads.h++ LinuxThreads POSIX implementation maps RWSchedulingPolicy values to the underlying POSIX 1003.1c policy values.

Table 10 -- Linux: Mapping of RWSchedulingPolicy to POSIX 1003.1c values

Attempts to set any other policy values will result in an RWTHROperationNotAvailable exception. None of these policies may be explicitly requested unless the process has superuser privileges.

Note that Threads.h++ has mapped two policy values to the same underlying policy, SCHED_OTHER. Calls to getSchedulingPolicy() return RW_THR_TIME_SLICED_DYNAMIC, since that value gives the most meaningful interpretation.

In order for a new thread's scheduling policy to inherit by default from the creating thread, you must change the inheritance policy's default value from RW_THR_EXPLICIT to RW_THR_INHERIT. For the default inheritance policy, 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 macro _POSIX_THREAD_PRIORITY_SCHEDULING.

The LinuxThreads POSIX implementation does support system-scope priority scheduling. Threads.h++ 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 11.

Table 11 -- Linux with POSIX 1003.1c: Scheduling policy priority values

A new thread's priority defaults to 0, unless one of the following statements is true:

• The scheduling policy has been explicitly set to something other than RW_THR_TIME_SLICED_DYNAMIC.

• The inheritance policy has been changed from its default value of RW_THR_EXPLICIT to RW_THR_INHERIT.

LinuxThreads v0.8 does not support process-scope threads because each LinuxThread is a separate Unix process (see Section 5.4). Therefore, process-scope priority is not supported in the Linux implementation of Threads.h++.

The LinuxThreads POSIX implementation of Threads.h++ does not support the time-slice quantum attribute. Any attempt to get or set this attribute value results in an exception.

In POSIX 1003.1c-compliant systems, support for user specification of stack attributes is optional. LinuxThreads supports control for a system-managed stack, and supports user-managed stacks.

The stacks for threads are allocated high in memory with the "grow on demand" flag set and spaced 2 MB apart. This means that they start off small (about 4 KB) and grow to 2 MB. However, the entire 2 MB space is reserved for the stack, which means that mapping something into a fixed address space could cause later growth of the stack to fail. On our test machine with 256 MB RAM and 256 MB swap space, we found that the maximum number of threads that could be created only using pthread_create() was about 230 threads.

The creators of LinuxThreads recommend that you not set stack attributes unless you have strong reasons for doing so, since they believe that the above stack allocation strategy is nearly optimal and that users setting the stack size may result in nonportable and less reliable programs.

©Copyright 2000, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.