The OSHS kernel contains a very simple process scheduler. This scheduler is sufficient for most tasks and certainly is sufficient in vast majority if not all of the single user systems with no background processing and probably even when background processing is involved in such systems. Even some servers may perform well with this simple scheduler only.
| - | It provides realtime priorities. The processes are grouped into sets based on their priorities. A group of processes is said to be waiting for CPU if it has at least one process that is waiting for CPU. The kernel gives CPU to processes from the group that has the highest priority among groups waiting for CPU (this is called "kernel gives CPU to the group" later), unless told by the currently running process to do otherwise. |
| - | If there are multiple runable processes in the group having the CPU, the kernel rotates these processes on the CPU using "round robin" scheduling policy. The processes form a queue the process at its head is moved to the tail by the kernel and then gets the CPU. Each priority group has its own queue which is altered only when the group gets CPU. The length of the timeslice can be configured but usually it is between ten and fifty milliseconds. |
| - | If a sleeping process awakens (for example a message came to the pipe it was waiting on), it is placed to the head of the queue of the processes waiting for the CPU in its priority group. If multiple processes awakened during one timeslice (e.g. the currently running process sent multiple messages to multiple pipes), they are stacked at the head of the queue i.e. the process that awakened last will be the first one that gets CPU. |
| - | There is no attempt to fairly spread the CPU time to the processes. If a process is unlucky enough, it may become stalled for significant period of time or even forever. |
| - | Update: The real-time priorities allow the "more advanced and featureful scheduler" to be built on top of this simple scheduler. There is a scheduler handle available at the boot of the kernel. This scheduler handle can be used to replace this simple scheduler by a more advanced and featurefull scheduler. |
This "simple and stupid" scheduler is here to avoid deadlocks that can occur in multiprocessing enviroments without regular process switching. The more sophisticated process schedulers involving priorities, execution time honouring and similar advanced features (like the one present in the Linux, the kernel) is written as a which is directly informed by the kernel that a process switch is about to occur (the scheduler then selects new task to be scheduled and resumes the system).
Why the scheduler is designed as a realtime scheduler? Surprisingly, designing a scheduler with realtime priorities is easier, because its algorithm to determine which priority group is the next to be scheduled is simple: always pick the highest. A nonrealtime scheduler uses a special pattern designed to give the highest priority the half of the CPU time (for example), the second highest the half of the remaining half (a quarter) of the CPU time and so on to ensure that the lowest priority groups get CPU even under heavy CPU load from the higher priorities.