CS461 Real Time Systems

Real-Time Systems
Real-time research repository

• For information on real-time research groups,
conferences, journals, books, products, etc., have a look
at:
http://cs-www.bu.edu/pub/ieee-rts/Home.html
CS461 - Senior Design Project (AY2005) 2

Introduction
• A real-time system is a system whose specification
includes both a logical and a temporal correctness
requirement.
– Logical correctness: produce correct output.
• Can be checked by various means including
Hoare axiomatics and other formal methods.
– Temporal correctness: produces output at the right
time.
• A soft real-time system is one that can tolerate
some delay in delivering the result.
• A hard real-time system is one that can not afford
to miss a dealine.

Characteristics of real-time systems
• Event-driven, reactive
• High cost of failure
• Concurrency/multiprogramming
• Stand-alone/continuous operation.
• Reliability/fault tolerance requirements
• PREDICTABLE BEHAVIOR

Misconceptions about real-time
systems
• There is no science in real-time-system design.
– We shall see…
• Advances in supercomputing hardware will take care of
real-time requirements.
– The old “buy a faster processor” argument…
• Real-time computing is equivalent to fast computing.
– Only to ad agencies. To us, it means PREDICTABLE
computing.

systems
• Real-time programming is assembly coding, …
– We would like to automate (as much as possible)
real-time system design, instead of relying on clever
hand-crafted code.
• “Real time” is performance engineering.
– In real-time computing, timeliness is almost always
more important than raw performance …
• “Real-time problems” have all been solved in other
areas of CS or operations research.
– OR people typically use stochastic queuing models or
one-shot scheduling models to reason about
systems.
– CS people are usually interested in optimizing
average-case performance.

systems
• It is not meaningful to talk about guaranteeing real-time
performance when things can fail.
– Though things may fail, we certainly don’t want the
operating system to be the weakest link!
• Real-time systems function in a static environment.
– Not true. We consider systems in which the
operating mode may change dynamically.

Are all systems real-time systems?
• Question: Is a payroll processing system a real-time
system?
– It has a time constraint: Print the pay checks every
month.
• Perhaps it is a real-time system in a definitional sense,
but it doesn’t pay us to view it as such.
• We are interested in systems for which it is not a priori
obvious how to meet timing constraints.

Resources
• Resources may be categorized as:
– Abundant: Virtually any system design
methodology can be used to realize the timing
requirements of the application.
– Insufficient: The application is ahead of the
technology curve; no design methodology can be
used to realize the timing requirements of the
application.
– Sufficient but scarce: It is possible to realize the
timing requirements of the application, but careful
resource allocation is required.

Example: Interactive/multimedia
application
Requirements
(performance)
Interactive Sufficient
Video but scarce
Insufficient resources
resources
High Quality
Audio
Network
File Access
Abundant
Remote resources
Login
1980 1990 2000

Hardware resources in Year X

Example: Real-time application
• Many real-time systems are control systems.
• Example: A simple one-sensor, one-actuator control system.
A/D
Computation D/A
A/D
Sensor Plant Actuator
The system being controlled

Simple control system
• Pseudo-code for this system:
set timer to interrupt periodically with period T;
at each timer interrupt do
do analog-to-digital conversion to get y;
compute control output u;
output u and do digital-to-analog conversion;
od
• T is called the sampling period. T is a key design
choice. Typical range for T: seconds to milliseconds.

Multi-rate control systems
• Example Helicopter Every other cycle do:
flight controller. control laws of the inner
Do the following in each pitch-control loop;
1/180-sec. cycle: control laws of the inner
validate sensor data and roll- and collective-
select data source; control loop;
if failure, reconfigure the Compute the control laws of
system the inner yaw-control
loop;
Every sixth cycle do: Output commands;
keyboard input and mode Carry out built-in test;
selection;
data normalization and Wait until beginning of the
coordinate transformation; next cycle
tracking reference update • Note: Having only
control laws of the outer harmonic rates simplifies
pitch-control loop; the system.
control laws of the outer • More complicated control
roll-control loop; systems have multiple
control laws of the outer sensors and actuators and
yaw- and collective- must support control loops
control loop of different rates.

Hierarchical control systems

Signal processing systems
• Signal-processing systems transform data from one
form to another.
• Examples:
– Digital filtering.
– Video and voice compression/decompression.
– Radar signal processing.
• Response times range from a few milliseconds to a few
seconds.

Example: radar system

Other real-time applications
• Real-time databases.
– Transactions must complete by deadlines.
– Main dilemma: Transaction scheduling algorithms and
real-time scheduling algorithms often have conflicting
goals.
– Data may be subject to absolute and relative
temporal consistency requirements.
• Multimedia.
– Want to process audio and video frames at steady rates.
• TV video rate is 30 frames/sec. HDTV is 60
frames/sec.
• Telephone audio is 16 Kbits/sec. CD audio is 128
Kbits/sec.
– Other requirements: Lip synchronization, low jitter,
low end-to-end response times (if interactive).

Hard vs. soft real-time
• Task: A sequential piece of code.
• Job: Instance of a task.
• Jobs require resources to execute.
– Example resources: CPU, network, disk, critical
section.
– We will simply call all hardware resources
“processors”.
• Release time of a job: The time instant the job
becomes ready to execute.
• Deadline of a job: The time instant by which the job
must complete execution.
• Relative deadline of a job: “Deadline - Release time”.
• Response time of a job: “Completion time - Release
time”.

Example
• Job is released at time 3.

• It’s (absolute) deadline is at time 10.
• It’s relative deadline is 7.
• It’s response time is 6.

Hard real-time systems
• A hard deadline must be met.
– If any hard deadline is ever missed, then the system
is incorrect.
– Requires a means for validating that deadlines are
met.
• Hard real-time system: A real-time system in which
all deadlines are hard.
• Examples: Nuclear power plant control, flight control.

Soft real-time systems
• A soft deadline may occasionally be missed.
– Question: How to define “occasionally”?
• Soft real-time system: A real-time system in which
some deadlines are soft.
• Examples: Telephone switches, multimedia
applications.

Defining “occasionally”
• One Approach: Use probabilistic requirements.
– For example, 99% of deadlines will be met.
• Another Approach: Define a “usefulness” function for each job:
• Note: Validation is trickier here.

Firm deadlines
• Firm deadline: A soft deadline such that the
corresponding job’s usefulness function goes to 0 as
soon as the deadline is reached (late jobs are of no use).

Reference model
• Each job Ji is characterized by its release time ri,
absolute deadline di, relative deadline Di, and execution
time ei.
• Sometimes a range of release times is specified: [ri-, ri+].
This range is called release-time jitter.
• Likewise, sometimes instead of ei, execution time is
specified to range over [ei-, ei+].
– Note: It can be difficult to get a precise estimate of
ei

Periodic, sporadic aperiodic tasks
• Periodic task:
– We associate a period pi with each task Ti.
– pi is the time between job releases.
• Sporadic and aperiodic tasks: Released at arbitrary
times.
– Sporadic: Has a hard deadline.
– Aperiodic: Has no deadline or a soft deadline.

Examples
• A periodic task Ti with ri = 2, pi = 5, ei = 2, Di = 5
executes like this:

Some definitions for periodic task
systems
• The jobs of task Ti are denoted Ji,1, Ji,2, … .
• ri,1 (the release time of Ji,1) is called the phase of Ti.
– Synchronous System: Each task has a phase of 0.
– Asynchronous System: Phases are arbitrary.
• Hyperperiod: Least common multiple of {pi}.
• Task utilization: ui = ei/pi.
• System utilization: U = Σi=1..nui.

Task dependencies
• Two main kinds of dependencies:
– Critical Sections.
– Precedence Constraints.
• For example, job Ji may be constrained to be
released only after job Jk completes.
• Tasks with no dependencies are called independent.

Scheduling algorithms
• We are generally interested in two kinds of algorithms:
1. A scheduler or scheduling algorithm, which
generates a schedule at runtime.
2. A feasibility analysis algorithm, which checks if
timing constraints are met.
• Usually (but not always) Algorithm 1 is pretty
straightforward, while Algorithm 2 is more complex.

Classification of scheduling
algorithms

Optimality and feasibility
• A schedule is feasible if all timing constraints are met.
– The term “correct” is probably better — see the next
slide.
• A task set T is schedulable using scheduling algorithm
A if A always produces a feasible schedule for T.
• A scheduling algorithm is optimal if it always produces
a feasible schedule when one exists (under any
scheduling algorithm).
– Can similarly define optimality for a class of
schedulers, e.g., “an optimal static-priority
scheduling algorithm.”

Feasibility vs. schedulability
• To most people in real-time community, the term “feasibility”
is used to refer to an exact schedulability test, while the term
“schedulability” is used to refer to a sufficient schedulability
test.
• You may find that these terms are used somewhat inconsistently
in the literature.

Clock driven (or static) scheduling
• Model assumes
– n periodic tasks T1,…,Tn.
– The “rest of the world” periodic model is assumed.
– Ti is specified by (i, pi, ei, Di), where
• i is its phase,
• pi is its period,
• ei is its execution cost per job, and
• Di is its relative deadline.
• Will abbreviate as (pi,ei,Di) if i=0, and (pi,ei) if
i=0 ∧ pi=Di.
– We also have aperiodic jobs that are released at
arbitrary times

Schedule table
• Our scheduler will schedule periodic jobs using a static
schedule that is computed offline and stored in a table T.
{
– T(tk) = Ti if Ti is to be scheduled at time tk
I if no periodic task is scheduled at time tk
– For most of this chapter, we assume the table is given.

– Later, we consider one algorithm for producing the table.
• Note: This algorithm need not be highly efficient.
– We will schedule aperiodic jobs (if any are ready) in
intervals not used by periodic jobs.

Static, timer-driven scheduling

Example
• Consider a system of four tasks, T1 = (4,1), T2 =
(5,1.8), T3 = (20,1), T4 = (20,2).
• Consider the following static schedule:
• The first few table entries would be: (0,T1), (1,T3),

(2,T2), (3.8,I), (4, T1), …

Frames
• Let us refine this notion of scheduling…
• To keep the table small, we divide the time line into
frames and make scheduling decisions only at frame
boundaries.
– Each job is executed as a procedure call that must fit
within a frame.
– Multiple jobs may be executed in a frame, but the
table is only examined at frame boundaries (the
number of “columns” in the table = the number of
frames per hyperperiod).
– In addition to making scheduling decisions, the
scheduler also checks for various error conditions,
like task overruns, at the beginning of each frame.
• We let f denote the frame size.

Frame size constraints
• We want frames to be sufficiently long so that every job
can execute within a frame nonpreemptively. So,
• f  max1in(ei).
• To keep table small, f should divide H. Thus, for at least
one task Ti,
pi/f - pi/f = 0.
• Let F = H/f. (Note: F is an integer.) Each interval of
length H is called a major cycle. Each interval of length
f is called a minor cycle.
• There are F minor cycles per major cycle.

Frame size constraints
• We want the frame size to be sufficiently small so that
between the release time and deadline of every job,
there is at least one frame.
• A job released “inside” a frame is not noticed by the
scheduler until the next frame boundary.
• Moreover, if a job has a deadline “inside” frame k + 1, it
essentially must complete execution by the end of
frame k.
• Thus, 2f - gcd(pi, f)  Di.

Example
• Consider a system of four tasks, T1 = (4,1), T2 =
(5,1.8), T3 = (20,1),T4 = (20,2).
• By first constraint, f  2.
• Hyperperiod is 20, so by second constraint, possible
choices for f are 2, 4, 5, 10, and 20.
• Only f = 2 satisfies the third constraint. The following is
a possible cyclic schedule.

Job slices
• What do we do if the frame size constraints cannot be
met?
• Example: Consider T = {(4, 1), (5, 2, 7), (20, 5)}. By
first constraint,
• f  5, but by third constraint, f  4!
• Solution: “Slice” the task (20, 5) into subtasks, (20, 1),
(20, 3), and (20, 1). Then, f = 4 works. Here’s a
schedule:

Summary of design decisions
• Three design decisions:
– choosing a frame size,
– partitioning jobs into slices, and
– placing slices in frames.
• In general, these decisions cannot be made
independently.

Pseudo code for cyclic executive

Improving response times for
aperiodic jobs
• Intuitively, it makes sense to give hard real-time jobs
higher priority than aperiodic jobs.
• However, this may lengthen the response time of an
aperiodic job.
• Note that there is no point in completing a hard

real time job early, as long as it finishes by its
deadline.

Slack stealing
• Let the total amount of time allocated to all the slices
scheduled in frame k be xk.
• Definition: The slack available at the beginning of
frame k is f - xk.
• Change to scheduler:
– If the aperiodic job queue is non-empty, let aperiodic
jobs execute in each frame whenever there is
nonzero slack.

Example

Implementing slack stealing
• Use a pre-computed “initial slack” table.
– Initial slack depends only on static quantities.
• Use an interval timer to keep track of available slack.
– Set the timer when an aperiodic job begins to run. If
it goes off, must start executing periodic jobs.
– Problem: Most OSs do not provide sub-millisecond
granularity interval timers.
– So, to use slack stealing, temporal parameters must
be on the order of 100s of msecs. or secs.

Scheduling sporiadic jobs
• Sporadic jobs arrive at arbitrary times.
• They have hard deadlines.
• Implies we cannot hope to schedule every sporadic job.
• When a sporadic job arrives, the scheduler performs an
acceptance test to see if the job can be completed by
its deadline.
• We must ensure that a new sporadic job does not cause
a previously-accepted sporadic job to miss its deadline.
• We assume sporadic jobs are prioritized on an earliest
deadline- first (EDF) basis.

Acceptance test
• Let s(i, k) be the initial total slack in frames i through k,
where
1  i  k  F. (This quantity only depends on periodic jobs.)
• Suppose we are doing an acceptance test at frame t for a
newly-arrived sporadic job S with deadline d and
execution cost e.
• Suppose d occurs within frame l + 1, i.e., S must
complete by the end of frame l.
• Compute the current total slack in frames t through l
using
(t,l) =  (t,l) - dk  d(ek - k)
• The sum is over previously-accepted sporadic jobs with
equal or earlier deadlines. k is the amount of time
already spent executing Sk before frame t.

Acceptance test
• We’ll specify the rest of the test “algorithmically”…
• To summarize, the scheduler must maintain the following

data:
– pre-computed initial slack table s(i, k);
– xk values to use at the beginning of the current frame
– the current slack sk of every accepted sporadic job S k.

Executing Sporadic tasks

Executing sporadic tasks
• Accepted sporadic jobs are executed like aperiodic obs
in the original alg. (without slack stealing).
– Remember, when meeting a deadline is the main
concern, there is no need to complete a job early.
– One difference: The aperiodic job queue is in FIFO
order, while the sporadic job queue is in EDF order.
• Aperiodic jobs only execute when the sporadic job
queue is empty.
– As before, slack stealing could be used when
executing aperiodic jobs (in which case, some
aperiodic jobs could execute when the sporadic job
queue is not empty).

Practical considerations
• Handling frame overruns.
– Main Issue: Should offending job be completed or
aborted?
• Mode changes.
– During a mode change, the running set of tasks is
replaced by a new set of tasks (i.e., the table is
changed).
– Can implement mode change by having an
aperiodic or sporadic mode-change job. (If
sporadic, what if it fails the acceptance test???)
• Multiprocessors.
– Like uniprocessors, but table probably takes longer
to precompute.

Network Flow Algorithm for
Computing Static Schedules
• Initialization: Compute all frame sizes in accordance
with the second two frame-size constraints:
pi/f - pi/f = 0 2f - gcd(pi, f)  Di
• At this point, we ignore the first constraint, f 
max1in(ei).
• Recall this is the constraint that can force us to “slice” a
task into subtasks.
• Iterative Algorithm: For each possible frame size f,
we compute a network flow graph and run a max-flow
algorithm. If the flow thus found has a certain value,
then we have a schedule.

Flow graph
• Denote all jobs in the major cycle of F frames as
J1, J2, …, JN.
• Vertices:
– N job vertices, denoted J1, J2, …, JN.
– F frame vertices, denoted 1, 2, …, F.
– source and sink.
• Edges:
– (Ji , j) with capacity f iff Ji can be scheduled in frame j.
– (source, Ji) with capacity ei.
– (f, sink) with capacity f.

Example

Finding a schedule
• The maximum attainable flow value is clearly
i=1,…,N ei.
• This corresponds to the exact amount of computation to
be scheduled in the major cycle.
• If a max flow is found with value i=1,…,N ei, then we have
a schedule.
• If a job is scheduled across multiple frames, then we
must slice it into corresponding subjobs.

Example

Non-independent tasks
• Tasks with precedence constraints are no problem.
– We can enforce precedence constraint like “Ji
precedes Jk” by simply making sure Ji’s release is at
or before Jk’s release, and Ji’s deadline is at or before
Jk’s deadline.
– If slices of Ji and Jk are scheduled in the wrong order,
we can just swap them.
• Critical sections pose a greater challenge.
– We can try to “massage” the flow-network schedule
into one where nonpreemption constraints are
respected.
– Unfortunately, there is no known efficient, optimal
algorithm for doing this (the problem is actually NP-
hard).

Pros and Cons of Cyclic Executives
• Main Advantage: CEs are very simple - you just need
a table.
– For example, additional mechanisms for concurrency
control and synchronization are not needed. In fact,
there’s really no notion of a “process” here – just
procedure calls.
– Can validate, test, and certify with very high
confidence.
– Certain anomalies will not occur.
– For these reasons, cyclic executives are the
predominant approach in many safety-critical
applications (like airplanes).

Aside: Scheduling Anomalies
• Here’s an example: On a multiprocessor, decreasing a
job’s execution cost can increase some job’s response
time.
• Example: Suppose we have one job queue,
preemption, but no migration.

Disadvantages
• Disadvantages of cyclic executives:
– Very brittle: Any change, no matter how trivial,
requires that a new table be computed!
– Release times of all jobs must be fixed, i.e., “real-
world” sporadic tasks are difficult to support.
– Temporal parameters essentially must be multiples
of f.
– F could be huge!
– All combinations of periodic tasks that may execute
together must a priori be analyzed.
– From a software engineering standpoint, “slicing”
one procedure into several could be error-prone.

Dynamic-priority scheduling
• Let us consider a priority-based dynamic scheduling
approach.
– Each job is assigned a priority, and the highest-
priority job executes at any time.
• Under dynamic-priority scheduling, different jobs of a
task may be assigned different priorities.
– Can have the following: job Ji,k of task Ti has higher
priority than job Jj,m of task Tj, but job Ji,l of Ti has
lower priority than job Jj,n of Tj.

Outline
• We consider both earliest-deadline-first (EDF) and
least-laxity-first (LLF) scheduling.
• Outline:
– Optimality of EDF and LLF
– Utilization-based schedulability test for EDF

Optimality of EDF
• Theorem: [Liu and Layland] When preemption is
allowed and jobs do not contend for resources, the EDF
algorithm can produce a feasible schedule of a set J of
independent jobs with arbitrary release times and
deadlines on a processor if and only if J has feasible
schedules.
• Notes:
– Applies even if tasks are not periodic.
– If periodic, a task’s relative deadline can be less than
its period, equal to its period, or greater than its
period.

Proof
• We show that any feasible schedule of J can be
systematically transformed into an EDF schedule.
• Suppose parts of two jobs Ji and Jk are executed out of
EDF order:
• This situation can be corrected by performing a “swap”:

Proof
• If we inductively repeat this procedure, we can
eliminate all out-of-order violations.
• The resulting schedule may still fail to be an EDF
schedule because it has idle intervals where some job is
ready:
• Such idle intervals can be eliminated by moving some

jobs forward:

LLF Scheduling
• Definition: At any time t, the slack (or laxity) of a job
with deadline d is equal to d - t minus the time required
to complete the remaining portion of the job.
• LLF Scheduling: The job with the smallest laxity has

highest priority at all times.

Optimality of LLF
• Theorem: When preemption is allowed and jobs do not
contend for resources, the LLF algorithm can produce a
feasible schedule of a set J of independent jobs with
arbitrary release times and deadlines on a processor if
and only if J has feasible schedules.
• The proof is similar to that for EDF.

CS461 Real Time Systems

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CS461 Real Time Systems

Uploaded by

Copyright:

Available Formats

Real-Time Systems

Real-time research repository

CS461 - Senior Design Project (AY2005) 2

CS461 - Senior Design Project (AY2005) 3

CS461 - Senior Design Project (AY2005) 4

CS461 - Senior Design Project (AY2005) 5

CS461 - Senior Design Project (AY2005) 6

CS461 - Senior Design Project (AY2005) 7

CS461 - Senior Design Project (AY2005) 8

CS461 - Senior Design Project (AY2005) 9

1980 1990 2000

CS461 - Senior Design Project (AY2005) 10

Sensor Plant Actuator

The system being controlled

CS461 - Senior Design Project (AY2005) 11

CS461 - Senior Design Project (AY2005) 12

CS461 - Senior Design Project (AY2005) 13

CS461 - Senior Design Project (AY2005) 14

CS461 - Senior Design Project (AY2005) 15

CS461 - Senior Design Project (AY2005) 16

CS461 - Senior Design Project (AY2005) 17

CS461 - Senior Design Project (AY2005) 18

• Job is released at time 3.

CS461 - Senior Design Project (AY2005) 19

CS461 - Senior Design Project (AY2005) 20

CS461 - Senior Design Project (AY2005) 21

CS461 - Senior Design Project (AY2005) 22

CS461 - Senior Design Project (AY2005) 23

CS461 - Senior Design Project (AY2005) 24

CS461 - Senior Design Project (AY2005) 25

CS461 - Senior Design Project (AY2005) 26

CS461 - Senior Design Project (AY2005) 27

CS461 - Senior Design Project (AY2005) 28

CS461 - Senior Design Project (AY2005) 29

CS461 - Senior Design Project (AY2005) 30

CS461 - Senior Design Project (AY2005) 31

CS461 - Senior Design Project (AY2005) 32

CS461 - Senior Design Project (AY2005) 33

– For most of this chapter, we assume the table is given.

CS461 - Senior Design Project (AY2005) 34

CS461 - Senior Design Project (AY2005) 35

• The first few table entries would be: (0,T1), (1,T3),

CS461 - Senior Design Project (AY2005) 36

CS461 - Senior Design Project (AY2005) 37

CS461 - Senior Design Project (AY2005) 38

• Thus, 2f - gcd(pi, f)  Di.

CS461 - Senior Design Project (AY2005) 39

CS461 - Senior Design Project (AY2005) 40

CS461 - Senior Design Project (AY2005) 41

CS461 - Senior Design Project (AY2005) 42

CS461 - Senior Design Project (AY2005) 43

• Note that there is no point in completing a hard

CS461 - Senior Design Project (AY2005) 44

CS461 - Senior Design Project (AY2005) 45

CS461 - Senior Design Project (AY2005) 46

CS461 - Senior Design Project (AY2005) 47

CS461 - Senior Design Project (AY2005) 48

CS461 - Senior Design Project (AY2005) 49

• To summarize, the scheduler must maintain the following

CS461 - Senior Design Project (AY2005) 50

CS461 - Senior Design Project (AY2005) 51

CS461 - Senior Design Project (AY2005) 52

CS461 - Senior Design Project (AY2005) 53