The OS/2 Scheduler

The Scheduler is a part of the OS/2 kernel and as such works on the lowest level of the system (for more on this, see the explanations on the Restart WPS page).

The Scheduler is responsible for multitasking and multithreading in OS/2. Since you normally have only one processor, but expect several programs to run at the same time, the Scheduler switches between these programs several dozen times a second, so that these programs appear to run in parallel.

To understand the different settings on the "Scheduler" page in the "OS/2 Kernel" object, the following explanations about how OS/2 manages processes and threads might be helpful. On that settings page, you will receive more specific information on the different settings if you press the "Help" button there.

A thread is the smallest unit for administrating program switches which OS/2 provides. A program can contain several threads, but needs to have at least one thread. The term "thread" was chosen because within one thread program instructions are executed sequentially, while between threads you may never be sure which instruction of one thread will be executed before or after an instruction of another thread.

Well-programmed OS/2 software uses several threads to ensure that the user gets a quick response to his input and mouse actions. For example, if you execute a command in a program which will take a long time, a program should start a secondary thread for this task. While this new thread is working in the background, the user interface (on the main thread of the program) is ready again for new input.

Not-so-well-programmed OS/2 software uses only one thread for both the user interface and executing tasks. As a result, while executing a task, the user interface is blocked. A good example of this stems from IBM themselves: in VIEW.EXE, if you search the whole bookshelf, your computer is blocked completely until the search is completed. This task would have been perfect for multithreading.

Now, threads can have different priorities. In general, a thread with a higher priority gets more processor time that one with lower priority. This is especially true if several threads actually have work to do, i.e. compete for processor time; this does not apply for threads that are "blocked" because they currently have nothing to do. A blocked thread needs no processor time and its priority thus doesn't matter.

OS/2 is capable of controlling thread priorities in a very refined way. It differentiates between four priority classes:

"Idle time priority" is the lowest priority class. This means that a thread only gets processor time if no threads of higher priority classes require it. Such threads are helpful for offloading work that needs to be done, but can be delayed until the computer has time for it. An example of such a thread is the XFolder Worker thread which keeps track of the awake WPS objects on your system. This is fairly time-consuming, but not time-critical, so it's done with idle-time priority.
"Regular priority" is the priority class that most threads use. It is also the default OS/2 priority class if nothing different is specified. Between threads of this class, OS/2 dynamically varies priority levels (more on this below) to make sure that no thread of this class "starves", i.e. gets no processor time.
"Fixed-high priority" is the second-highest priority class for threads that need to prepare data for "regular" class which needs to be done quickly without being influenced by the dynamic priority variations for "regular" threads. This is frequently done for message dispatchers.
"Time-critical priority" is the highest priority class for threads that need to be executed immediately when there's work to do. Such a thread will be given processor time immediately and will not be interrupted until its work is done. This priority class is frequently used for time-critical tasks, for example by network and other communications software.

Within each priority class one can now set a priority level. This is a value from -31 to +31 which determines the precedence of a thread within a priority class.

A few examples:

A "regular" thread with priority level +31 supercedes a "regular" thread with priority level 0.
Within the "regular priority" class however OS/2 ensures that no thread "starves", i.e. never gets processor time, by dynamically raising each thread's priorities after a certain time automatically. This period of time is determined by the MAXWAIT CONFIG.SYS setting. Moreover, OS/2 raises a thread's priority if it is to receive keyboard input, if the process of the thread runs in the foreground, or if the thread is currently accessing devices.
These dynamic adjustments are only then performed if CONFIG.SYS does not contain the command PRIORITY=ABSOLUTE, which is not recommended. (This is why you will not find that setting in the "OS/2 Kernel" object.)
A "time-critical" thread with priority level -31 still supercedes a "regular" thread with priority level +31 because it belongs to a higher priority class. For this case, the dynamic priority adjustments will have no effect, because they only affect the execution of "regular" threads.
The same applies, for example, to a "regular thread" with priority level 0 and an "idle-time" thread with priority level +31.
Two threads with exactly the same priority however run "against" each other, i.e. they alternate with respect to processor usage.

On the other hand side, a process is the OS/2 term for an application which has been loaded into memory. Each process must have at least one thread. Each process contains common data as well as controls access to system resources. Processes are protected against each other in that OS/2 prohibits access to memory which does not belong to the process attempting to access it ("memory protection"). By contrast, several threads within a process may all access the process's memory, because memory is administered on a per-process basis. The same applies to other system resources such as open files.