SEWP ZG524

Real - Time Operating Systems

Commonly Used Approaches

to Real-Time Scheduling

Purushotham BV
[email protected]
1
 Agenda
4.1 Clock-driven Approach
4.2 Weighted Round – Robin Approach
4.3 Priority Driven Approach
4.4 Dynamic v/s Static Systems
4.5 Effective Release Times and Deadlines
4.6 Optimality of The EDF and LST Algorithms
4.7 Non-optimality of The EDF and The LST Algorithms
4.8 Challenges in Validating Timing Constraints in Priority –
Driven Systems
4.8.1 Anomalous Behavior Of Priority-driven Systems
4.8.2 Predictability of Executions
4.8.3 Validation Algorithms and Their Performance
4.9 Off-line Versus On-line Scheduling
4.10 Summary 2
 4.1 Clock-driven Approach
• As the name implies, when scheduling is clock-driven (also
called time-driven), decisions on what jobs execute at what
times are made at specific time instants.
• These instants are chosen a priori before the system begins
execution.
• Typically, in a system that uses clock-driven scheduling, all
the parameters of hard real-time jobs are fixed and known.
• A schedule of the jobs is computed off-line and is stored for
use at run time.
• The scheduler schedules the jobs according to this schedule at
each scheduling decision time.
• In this way, scheduling overhead during run-time can be
minimized. 3
 Weighted Round – Robin Approach (Contd.,)

• A frequently adopted choice is to make scheduling decisions at

regularly spaced time instants.
• One way to implement a scheduler that makes scheduling
decisions periodically is to use a hardware timer.
• The timer is set to expire periodically without the intervention of
the scheduler.
• When the system is initialized, the scheduler selects and
schedules the job(s) that will execute until the next scheduling
decision time and then blocks itself waiting for the expiration of
the timer.
• When the timer expires, the scheduler awakes and repeats these
actions.
4
 4.2 Weighted Round-robin Approach

• The round-robin approach is commonly used for

scheduling time-shared applications.
• When jobs are scheduled on a round-robin basis,
every job joins a First-in-first-out (FIFO) queue when
it becomes ready for execution.
• The job at the head of the queue executes for at most
one time slice.
• A time slice is the basic granule of time that is
allocated to jobs. In a timeshared environment, a time
slice is typically in the order of tens of milliseconds.
5
Weighted Round – Robin Approach (Contd.,)

• If the job does not complete by the end of the time

slice, it is preempted and placed at the end of the queue
to wait for its next turn.
• When there are n ready jobs in the queue, each job gets
one time slice every n time slices, that is, every round.
• Because the length of the time slice is relatively short,
the execution of every job begins almost immediately
after it becomes ready.
• In essence, each job gets 1/nth share of the processor
when there are n jobs ready for execution.
• This is why the round-robin algorithm is also called the
processor-sharing algorithm. 6
Weighted Round – Robin Approach (Contd.,)
• The weighted round-robin algorithm has been used for
scheduling real-time traffic in high-speed switched
networks.
• It builds on the basic round-robin scheme.
• Rather than giving all the ready jobs equal shares of the
processor, different jobs may be given different weights.
• Here, the weight of a job refers to the fraction of
processor time allocated to the job.
• Specifically, a job with weight wt gets wt time slices
every round, and the length of a round is equal to the
sum of the weights of all the ready jobs.
• By adjusting the weights of jobs, we can speed up or
retard the progress of each job toward its completion. 7
Weighted Round – Robin Approach (Contd.,)

• By giving each job a fraction of the processor, a round-

robin scheduler delays the completion of every job.
• If it is used to schedule precedence constrained jobs, the
response time of a chain of jobs can be unduly large.
• For this reason, the weighted round-robin approach is not
suitable for scheduling such jobs.
• On the other hand, a successor job may be able to
incrementally consume what is produced by a
predecessor (e.g., as in the case of a UNIX pipe).
• In this case, weighted round-robin scheduling is a
reasonable approach, since a job and its successors can
execute concurrently in a pipelined fashion. 8
Weighted Round – Robin Approach (Contd.,)

• Consider the two sets of jobs, J1 = {J1,1, J1,2} and J2 = {J2,1,

J2,2}, shown in Figure 4–1. The release times of all jobs are 0,
and their execution times are 1.

• J1,1 and J2,1 execute on processor P1, and J1,2 and J2,2 execute
on processor P2. Suppose that J1,1 is the predecessor of J1,2, and
J2,1 is the predecessor of J2,2.

• Figure 4–1(a) shows that both sets of jobs (i.e., the second jobs
J1,2 and J2,2 in the sets) complete approximately at time 4 if the
jobs are scheduled in a weighted round-robin manner.

• We get this completion time when the length of the time slice is
small compared with 1 and the jobs have the same weight. 9
Weighted Round – Robin Approach (Contd.,)

10
Weighted Round – Robin Approach (Contd.,)

• In contrast, the schedule in Figure 4–1(b) shows that

if the jobs on each processor are executed one after
the other, one of the chains can complete at time 2,
while the other can complete at time 3.
• On the other hand, suppose that the result of the first
job in each set is piped to the second job in the set.
• The latter can execute after each one or a few time
slices of the former complete.
• Then it is better to schedule the jobs on the round-
robin basis because both sets can complete a few time
slices after time 2.
11
Weighted Round – Robin Approach (Contd.,)

• The transmission of each message is carried out by

switches en route in a pipeline fashion.
• A switch downstream can begin to transmit an earlier
portion of the message as soon as it receives the portion
without having to wait for the arrival of the later portion
of the message.
• The weighted round-robin approach does not require a
sorted priority queue, only a round-robin queue.
• This is a distinct advantage for scheduling message
transmissions in ultrahigh-speed networks, since
priority queues with the required speed are expensive.
12
 4.3 Priority-Driven Approach
• The term priority-driven algorithms refers to a large class of
scheduling algorithms that never leave any resource idle
intentionally.
• Stated in another way, a resource idles only when no job
requiring the resource is ready for execution.

• Scheduling decisions are made when events such as releases

and completions of jobs occur.
• Hence, priority-driven algorithms are event-driven.
• Other commonly used names for this approach are greedy
scheduling, list scheduling and work-conserving scheduling.

• A priority-driven algorithm is greedy because it tries to make

13
locally optimal decisions.
 Priority – Driven Approach (Contd.,)

• Leaving a resource idle while some job is ready to use

the resource is not locally optimal.
• So when a processor or resource is available and some
job can use it to make progress, such an algorithm
never makes the job wait.
• We will return shortly to illustrate that greed does not
always pay; sometimes it is better to have some jobs
wait even when they are ready to execute and the
resources they require are available.
• Jobs ready for execution are placed in one or more
queues ordered by the priorities of the jobs.
14
 Priority – Driven Approach (Contd.,)

• At any scheduling decision time, the jobs with the highest

priorities are scheduled and executed on the available processors.
• Hence, a priority-driven scheduling algorithm is defined to a great
extent by the list of priorities it assigns to jobs; the priority list and
other rules, such as whether preemption is allowed, define the
scheduling algorithm completely.
• Most scheduling algorithms used in nonreal-time systems are
priority-driven.
• Examples include the FIFO (First-In-First-Out) and LIFO (Last-In-
First-Out) algorithms, which assign priorities to jobs according
their release times, and the SETF (Shortest-Execution-Time-First)
and LETF (Longest-Execution-Time-First) algorithms, which
assign priorities on the basis of job execution times.
15
 Priority – Driven Approach (Contd.,)
• Because we can
dynamically change
the priorities of
jobs, even round-
robin scheduling
can be thought of as
priority-driven: the
priority of the
executing job is
lowered to the
minimum among all
jobs waiting for
execution after the
job has executed for
a time slice. Fig 4–
16
2 gives an example.
 Priority – Driven Approach (Contd.,)
• The task graph shown here is a classical precedence
graph.

• All its edges represent precedence constraints.

• The number next to the name of each job is its

execution time.
• J5 is released at time 4.

• All the other jobs are released at time 0.

• We want to schedule and execute the jobs on two

processors P1 and P2. 17
 Priority – Driven Approach (Contd.,)
• They communicate via a shared memory.
• Hence the costs of communication among jobs are negligible no
matter where they are executed.
• The schedulers of the processors keep one common priority queue
of ready jobs.
• The priority list is given next to the graph:
Ji has a higher priority than Jk if i < k.
• All the jobs are pre-emptable ; scheduling decisions are made
whenever some job becomes ready for execution or some job
completes.
• Figure 4–2(a) shows the schedule of the jobs on the two processors
generated by the priority-driven algorithm following this priority
assignment.
18
 Priority – Driven Approach (Contd.,)
• At time 0, jobs J1, J2, and J7 are ready for execution.
• They are the only jobs in the common priority queue at this time.
• Since J1 and J2 have higher priorities than J7, they are ahead of
J7 in the queue and hence are scheduled.
• The processors continue to execute the jobs scheduled on them
except when the following events occur and new scheduling
decisions are made.

19
 Priority – Driven Approach (Contd.,)
• At time 1, J2 completes and, hence, J3 becomes ready. J3 is
placed in the priority queue ahead of J7 and is scheduled on
P2, the processor freed by J2.
• At time 3, both J1 and J3 complete. J5 is still not released.
J4 and J7 are scheduled.
• At time 4, J5 is released. Now there are three ready jobs. J7
has the lowest priority among them. Consequently, it is
preempted. J4 and J5 have the processors.
• At time 5, J4 completes. J7 resumes on processor P1.
• At time 6, J5 completes. Because J7 is not yet completed,
both J6 and J8 are not ready for execution. Consequently,
processor P2 becomes idle.
• J7 finally completes at time 8.
20
• J6 and J8 can now be scheduled and they are.
 Priority – Driven Approach (Contd.,)

• Figure 4–2(b) shows a non-preemptive schedule according to the

same priority assignment.
• Before time 4, this schedule is the same as the preemptive
schedule. However, at time 4 when J5 is released, both
processors are busy. It has to wait until J4 completes (at time 5)
before it can begin execution.
• It turns out that for this system this postponement of the higher
priority job benefits the set of jobs as a whole.
• The entire set completes 1 unit of time earlier according to the
non-preemptive schedule.

21
 4.4 Dynamic Versus Static Systems

• In the above example, jobs that are ready for execution

are placed in a priority queue common to all processors.
• When a processor is available, the job at the head of the
queue executes on the processor.
• We will refer to such a multiprocessor system as a
dynamic system, because jobs are dynamically dispatched
to processors.
• In the example in Figure 4–2, we allowed each preempted
job to resume on any processor and hence, jobs are
migratable.
• We say that a job migrates if it starts execution on a
processor, is preempted, and later resumes on a different
22
processor.
 Dynamic Versus Static Systems (Contd.,)
• Another approach to scheduling in multiprocessor and
distributed systems is to partition the jobs in the system into
subsystems and assign and bind the subsystems statically to
the processors.
• Jobs are moved among processors only when the system must
be reconfigured, that is, when the operation mode of the
system changes or some processor fails. Such a system is
called a static system, because the system is statically
configured.
• If jobs on different processors are dependent, the schedulers on
the processors must synchronize the jobs according to some
synchronization and resource access-control protocol.
• Except for the constraints thus imposed, the jobs on each
23
processor are scheduled by themselves.
 Dynamic Versus Static Systems (Contd.,)
• As an example, a partition and assignment of the jobs in Figure 4–2 put J1,
J2, J3, and J4 on P1 and the remaining jobs on P2.
• The priority list is segmented into two parts:
• (J1, J2, J3, J4) and (J5, J6, J7, J8). The scheduler of processor P1 uses
the former while the scheduler of processor P2 uses the latter.
• It is easy to see that the jobs on P1 complete by time 8, and the jobs on
P2 complete by time 11.
• J2 completes by time 4 while J6 starts at time 6. Therefore, the
precedence constraint between them is satisfied.
• In this example, the response of the static system is just as good as that of the
dynamic system.
• Intuitively, we expect that we can get better average responses by dynamically
dispatching and executing jobs.

24
4.5 Effective Release Times And Deadlines

• The given release times and deadlines of jobs are

sometimes inconsistent with the precedence constraints of
the jobs.
• By this, we mean that the release time of a job may be
later than that of its successors, and its deadline may be
earlier than that of its predecessors.
• Therefore, rather than working with the given release
times and deadlines, we first derive a set of effective
release times and deadlines from these timing constraints,
together with the given precedence constraints.
• The derived timing constraints are consistent with the
precedence constraints. 25
Effective Release Times And Deadlines (Contd.,)

• When there is only one processor, we can compute the derived

constraints according to the following rules :
• Effective Release Time : The effective release time of a job
without predecessors is equal to its given release time. The
effective release time of a job with predecessors is equal to
the maximum value among its given release time and the
effective release times of all of its predecessors.

• Effective Deadline : The effective deadline of a job without a

successor is equal to its given deadline. The effective
deadline of a job with successors is equal to the minimum
value among its given deadline and the effective deadlines of
all of its successors.
26
Effective Release Times And Deadlines (Contd.,)

• As an example, we look at the set of jobs in Figure 4–3.

• The numbers in the parentheses next to the name of each

job are its given release times and deadlines.
• Because J1 and J2 have no predecessors, their effective
release times are the given release times, that is, 2 and 0,
respectively. 27
Effective Release Times And Deadlines (Contd.,)

• The given release time of J3 is 1, but the latest effective release time
of its predecessors is 2, that of J1 .
• Hence, the effective release time of J3 is 2. One can repeat this
procedure and find that the effective release times of the rest of the
jobs are 4, 2, 4, and 6, respectively.
• Similarly, J6 and J7 have no successors, and their effective
deadlines are equal to their given deadlines, 20 and 21, respectively.
• Since the effective deadlines of the successors of J4 and J5 are larger
than the given deadlines of J4 and J5 , the effective deadlines of J4
and J5 are equal to their given deadlines.
• On the other hand, the given deadline of J3 is equal to 12, which is
larger than the minimum value of 8 among the effective deadlines of
its successors.
• Hence, the effective deadline of J3 is 8. In a similar way, we find that
the effective deadlines of J1 and J2 are 8 and 7, respectively. 28
4.6 Optimality Of The EDF and LST Algorithms

• A way to assign priorities to jobs is on the basis of their

deadlines. In particular, the earlier the deadline, the
higher the priority.
• The priority-driven scheduling algorithm based on this
priority assignment is called the Earliest-Deadline-First
(EDF) algorithm.
• This algorithm is important because it is optimal when
used to schedule jobs on a processor as long as
preemption is allowed and jobs do not contend for
resources.

• This fact is stated formally below in Theorem 4.1. 29

Earliest Deadline First (EDF)

30
 Proof of Optimality for EDF

THEOREM 4.1. When preemption is allowed and jobs

do not contend for resources, the EDF algorithm can
produce a feasible schedule of a set J of jobs with
arbitrary release times and deadlines on a processor if
and only if J has feasible schedules.

Proof: The proof is based on the following fact: Any

feasible schedule of J can be systematically transformed
into an EDF schedule

31
Proof of Optimality for EDF (Contd.,)

32
Proof of Optimality for EDF (Contd.,)

33
Latest Release Time (LRT)

34
Least Slack Time First (LST)

35
 Comparison of EDF, LRT, LST

• Earliest Deadline First (EFT)

 Widely known
 Robust
 Simple to implement
• Latest Release Time (LRT)
 Good to fit in soft real-time tasks
 Requires precise execution time Analysis!
• Least Slack Time First (LST)
 Requires Knowledge of slack

36
4.7 Non-optimality of the EDF and the
LST Algorithms

37
Non-optimality of the EDF and the LST
Algorithms (Contd.,)

38
4.8 Challenges in Validating Timing
Constraints in Priority-driven Systems
• It is difficult to validate that the deadlines of all jobs
scheduled in a priority- driven manner indeed meet
their deadlines when the job parameters vary.

• In general, this validation problem can be stated as

follows:

• Given a set of jobs, the set of resources available to the

jobs, and the scheduling (and resource access-control)
algorithm to allocate processors and resources to jobs,
determine whether all the jobs meet their deadlines.
39
4.8.1 Anomalous Behavior of Priority
Driven Systems

40
Anomalous Behavior of PDS (Contd.,)

41
Anomalous Behavior of PDS (Contd.,)

42
Anomalous Behavior of PDS (Contd.,)

43
4.8.2 Predictability of Executions

44
Proof for Non-Existence

45
Proof for Non-Existence (Contd.,)

46
 4.8.3 Validation Algorithms and
Their Performance

• Determines whether all jobs meet their deadlines.

• Properties:
 Correctness: correct, if no false positives
 Execution time: some run in constant time
 Robustness: violating some assumptions still retains
correctness
 Accuracy: accurate, if no false negatives

47
 4.9 Off-line Versus On-line Scheduling

• Inflexible for run-time changes

• Near optimal use of resource (especially when multi-
resource)
• No run-time overhead for complex scheduling decisions

• Online scheduling is only possibility for unpredictable

workloads

• Caveat: No optimal online schedule for this case!

48
No Optimal Online Scheduling

49
Overload

50
EDF /LST and Overload

51
Theoretic Limit on Competitive Factor

52
Theoretic Limit on Competitive Factor (Contd.,)

53
Theoretic Limit on c (Example)

54
 4.10 Summary

• This chapter gave a brief overview of the clock-driven,

weighted round-robin and priority- driven approaches to
scheduling.
• This chapter also discussed several important facts about
the priority-driven approach.
• An algorithm for scheduling hard real-time jobs is
optimal if it can produce a feasible schedule as long as
feasible schedules of the given jobs exist, that is, when the
system is not overloaded.
• The EDF (Earliest-Deadline-First) algorithm is optimal
for scheduling pre-emptable jobs on one processor.
55
 Summary (Contd.,)

• LST (Least-Slack-Time) algorithm is also optimal for

pre-emptable jobs on one processor, but it requires
information on the execution times of all jobs while the
EDF algorithm does not.
• Neither algorithm is optimal when jobs are non-pre-
emptable or when there is more than one processor.
• The execution behavior of a system is predictable if the
system exhibits no anomalies.
• Systems that use priority-driven scheduling have
scheduling anomalies.

56
 Summary (Contd.,)

• Finally, the EDF and LST algorithms are not optimal

when the system is overloaded so some jobs must be
discarded in order to allow other jobs to complete in
time.
• In fact, these algorithms perform poorly for overloaded
systems: Their competitiveness factors are equal to zero.
• Some kind of overload management algorithm should be
used with these algorithms.

57