Saturday, November 7, 2009
The Scheduler
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 weren’t 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 task’s state (from the new task’s
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.
No comments:
Post a Comment