The Scheduler

The heart of the RTOS is the scheduler. The scheduler is the piece of code that figures out which task should run next . Usually at the end of every system call, the system invokes the scheduler to determine if the currently running task should be suspended in favor of some other task.

The OS views each task as being in one of several run states. Each RTOS defines its own set of run states, but three are almost universal: running , ready-to-run , and blocked . At any instant in time, only one task can be in the running state: namely, the currently executing active task. Tasks that could be running if the processor werent already being used by some higher priority task are assigned to the ready-to-run state. Tasks that are waiting for some system call to occur before they can run are assigned to the blocked state. When a blocked task becomes unblocked, it is moved to the ready-to-run state.

When the currently running task finishes or loses its claim to the processor (perhaps because some higher priority task became ready), the OS does a context switch . To perform a context switch, the RTOS saves the current state of the CPU (or context) in some structure dedicated to the active task (usually called a task control block TCB). The RTOS then retrieves the context belonging to the incoming tasks state (from the new tasks TCB) and loads that into the CPU as the new context. If the scheduler is priority based , the new task must have a higher priority than the previously running task because the scheduler always selects the highest priority ready-to-run task. It is important to note that the scheduler always selects the highest priority task that is ready to run . Frequently, there are several tasks in the system with higher priority than the current task, but these tasks are not running because they are not in the ready-to-run state.

Depending on the particular RTOS, the scheduler might be invoked at times other than when the running task makes a system call. If the RTOS supports preemption, a context switch could also occur as the side effect of an interrupt. For example, an interrupt might occur because a peripheral device has input available. The interrupt handler captures this input, saves it for the listening task (via a system call), and then invokes the scheduler as part of its return protocol. If the listening task was blocked waiting for the input, it now becomes ready-to-run. If the listening task (or some other now-ready task) has a higher priority than the interrupted task, the scheduler performs a task switch, suspending the interrupted task and launching the higher priority task.

In cases where a system call causes the current task to be put on hold, the context switch is called synchronous because it occurs through in-line code. In cases where an interrupt occurs and the interrupted task is put on hold, the context switch is called asynchronous because it happens at some arbitrary point during the execution of the interrupted task.