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:
A few examples:
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.)