Scheduling approaches depend on:
•whether a system performs schedulability analysis
(if it does, whether it is done statically or
dynamically)
•whether the result of the analysis itself produces a
scheduler plan according to which tasks are
dispatched at run time
Static table-driven approaches
• performs a static analysis of feasible schedules of
dispatching
• result is a schedule that determines, at run time, when a
task must begin execution
Static priority-driven preemptive approaches
• a static analysis is performed but no schedule is drawn up
• analysis is used to assign priorities to tasks so that a
traditional priority-driven preemptive scheduler can be
used
Dynamic planning-based approaches
• feasibility is determined at run time rather than
offline prior to the start of execution
• one result of the analysis is a schedule or plan
that is used to decide when to dispatch this task
Dynamic best effort approaches
• no feasibility analysis is performed
• system tries to meet all deadlines and aborts any
started process whose deadline is missed
Real-time operating systems are designed with the
objective of starting real-time tasks as rapidly as
possible and emphasize rapid interrupt handling and
task dispatching
Real-time applications are generally not concerned
with sheer speed but rather with completing (or
starting) tasks at the most valuable times
Priorities provide a basic tool and do not capture the
requirement of completion (or initiation) at the most
valuable time
Agenda
Multiprocessor Scheduling
Granularity
Design Issues
Process Scheduling
Thread Scheduling
Real-Time Scheduling
Background
Characteristics of Real-Time Operating Systems
Real-Time Scheduling
Deadline Scheduling
Rate Monotonic Scheduling
Priority Inversion
1
Real-time operating systems are designed with the
objective of starting real-time tasks as rapidly as
possible and emphasize rapid interrupt handling and
task dispatching
Real-time applications are generally not concerned
with sheer speed but rather with completing (or
starting) tasks at the most valuable times
Priorities provide a basic tool and do not capture the
requirement of completion (or initiation) at the most
valuable time
• time task becomes ready
Ready time
for execution Resource • resources required by the
requirements task while it is executing
Starting
• time task must begin
deadline
• measures relative
Priority
importance of the task
Completion • time task must be
deadline completed
• a task may be
Subtask decomposed into a
Processing • time required to execute scheduler mandatory subtask and
time the task to completion an optional subtask
As an example of scheduling periodic tasks
with completion deadlines, consider a system
that collects and processes data from two
sensors, A and B.
The deadline for collecting data from sensor A
must be met every 20 ms, and that for B every
50 ms.
It takes 10 ms, including operating system
overhead, to process each sample of data
from A and 25 ms to process each sample of
data from B.
Table 10.2 summarizes the execution profile of
Two Periodic Tasks
Figure 10.5 compares three scheduling
techniques using the execution profile of Table
10.2 .
The first row of Figure 10.5 repeats the
information in Table 10.2 ; the remaining three
rows illustrate three scheduling techniques.
The computer is capable of making a scheduling
decision every 10 ms. Suppose that, under these
circumstances, we attempted to use a priority
scheduling scheme.
The first two timing diagrams in Figure 10.5 show the
result.
1. If A has higher priority, the first instance of task
B is given only 20 ms of processing time, in two
10-ms chunks, by the time its deadline is reached,
and thus fails.
2. If B is given higher priority, then A will miss its
first deadline.
3. The final timing diagram shows the use of
earliest-deadline scheduling.
At time t = 0 , both A1 and B1 arrive.
Because A1 has the earliest deadline, it is scheduled
first.
When A1 completes, B1 is given the processor.
At t = 20 , A2 arrives. Because A2 has an earlier
deadline than B1, B1 is interrupted so that A2 can
execute to completion.
Then B1 is resumed at t = 30 .
At t = 40 , A3 arrives.
However, B1 has an earlier ending deadline and is
allowed to execute to completion at t = 45 .
A3 is then given the processor and finishes at t = 55 .
In this example, by scheduling to give priority at any
preemption point to the task with the nearest deadline,
all system requirements can be met.
Because the tasks are periodic and predictable, a
static table-driven scheduling approach is used.
Now consider a scheme for dealing with aperiodic
tasks with starting deadlines. The top part of Figure
10.6 shows the arrival times and starting deadlines
for an example consisting of five tasks each of which
has an execution time of 20 ms. Table 10.3
summarizes the execution profile of the five tasks.
When this approach (earliest deadline) is used in the
example of Figure 10.6 , note that although task B
requires immediate service, the service is denied.
This is the risk in dealing with aperiodic tasks,
especially with starting deadlines.
A refinement of the policy will improve performance if
deadlines can be known in advance of the time that a
task is ready.
This policy, referred to as earliest deadline with
unforced idle times, operates as follows: Always
schedule the eligible task with the earliest deadline
and let that task run to completion.
Rate Monotonic Scheduling
•One of the more promising methods of
resolving multitask scheduling conflicts for
periodic tasks is rate monotonic scheduling
(RMS).
•RMS assigns priorities to tasks on the
basis of their periods.
For RMS, the highest-priority task is the one
with the shortest period, the second highest-
priority task is the one with the second shortest
period, and so on.
When more than one task is available for
execution, the one with the shortest period is
serviced first.
If we plot the priority of tasks as a function of
their rate, the result is a monotonically
increasing function ( Figure 10.7 ); hence the
name, rate monotonic scheduling.
Figure 10.7
