Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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
CS461 - Senior Design Project (AY2005) 3
• 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
CS461 - Senior Design Project (AY2005) 4
Misconceptions about real-time systems
CS461 - Senior Design Project (AY2005) 5
• 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.
Misconceptions about real-time systems
CS461 - Senior Design Project (AY2005) 6
• 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.
Misconceptions about real-time 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
CS461 - Senior Design Project (AY2005) 7
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.
CS461 - Senior Design Project (AY2005) 8
Resources
CS461 - Senior Design Project (AY2005) 9
• 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)
InteractiveVideo
High QualityAudio
NetworkFile Access
RemoteLogin
Insufficientresources
Abundantresources
Sufficient but scarceresources
1980 1990 2000
CS461 - Senior Design Project (AY2005) 10
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.
CS461 - Senior Design Project (AY2005) 11
A/D
A/DD/AComputation
ActuatorPlantSensor
The system being controlled
Simple control system
CS461 - Senior Design Project (AY2005) 12
• 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 flight
controller.Do the following in each
1/180-sec. cycle:validate sensor data and
select data source;if failure, reconfigure the
systemEvery sixth cycle do:keyboard input and mode
selection;data normalization and
coordinate transformation;tracking reference updatecontrol laws of the outer
pitch-control loop;control laws of the outer
roll-control loop;control laws of the outer
yaw- and collective-control loop
Every other cycle do:control laws of the inner
pitch-control loop;control laws of the inner
roll- and collective-control loop;
Compute the control laws of the inner yaw-control loop;
Output commands;Carry out built-in test;Wait until beginning of the
next cycle• Note: Having only harmonic
rates simplifies the system.• More complicated control
systems have multiple sensors and actuators and must support control loops of different rates.
CS461 - Senior Design Project (AY2005) 13
Hierarchical control systems
CS461 - Senior Design Project (AY2005) 14
Signal processing systems
CS461 - Senior Design Project (AY2005) 15
• 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
CS461 - Senior Design Project (AY2005) 16
Other real-time applications
CS461 - Senior Design Project (AY2005) 17
• 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
CS461 - Senior Design Project (AY2005) 18
• 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.
CS461 - Senior Design Project (AY2005) 19
Hard real-time systems
CS461 - Senior Design Project (AY2005) 20
• 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.
CS461 - Senior Design Project (AY2005) 21
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.
CS461 - Senior Design Project (AY2005) 22
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).
CS461 - Senior Design Project (AY2005) 23
Reference model
CS461 - Senior Design Project (AY2005) 24
• 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.
CS461 - Senior Design Project (AY2005) 25
Examples• A periodic task Ti with ri = 2, pi = 5, ei = 2, Di = 5 executes like
this:
CS461 - Senior Design Project (AY2005) 26
Some definitions for periodic task systems
CS461 - Senior Design Project (AY2005) 27
• 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.
CS461 - Senior Design Project (AY2005) 28
Scheduling algorithms
CS461 - Senior Design Project (AY2005) 29
• 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
CS461 - Senior Design Project (AY2005) 30
Optimality and feasibility
CS461 - Senior Design Project (AY2005) 31
• 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.
CS461 - Senior Design Project (AY2005) 32
Clock driven (or static) scheduling
CS461 - Senior Design Project (AY2005) 33
• 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.
{
CS461 - Senior Design Project (AY2005) 34
Static, timer-driven scheduling
CS461 - Senior Design Project (AY2005) 35
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), …
CS461 - Senior Design Project (AY2005) 36
Frames
CS461 - Senior Design Project (AY2005) 37
• 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
CS461 - Senior Design Project (AY2005) 38
• 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.
CS461 - Senior Design Project (AY2005) 39
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
CS461 - Senior Design Project (AY2005) 40
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:
CS461 - Senior Design Project (AY2005) 41
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.
CS461 - Senior Design Project (AY2005) 42
Pseudo code for cyclic executive
CS461 - Senior Design Project (AY2005) 43
Improving response times for aperiodicjobs
• Intuitively, it makes sense to give hard real-time jobs higher priority than aperiodic jobs.
• However, this may lengthen the response time of an aperiodicjob.
• Note that there is no point in completing a hard real time job early, as long as it finishes by its deadline.
CS461 - Senior Design Project (AY2005) 44
Slack stealing
CS461 - Senior Design Project (AY2005) 45
• 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
CS461 - Senior Design Project (AY2005) 46
Implementing slack stealing
CS461 - Senior Design Project (AY2005) 47
• 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
CS461 - Senior Design Project (AY2005) 48
• 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
CS461 - Senior Design Project (AY2005) 49
• 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 Sk.
CS461 - Senior Design Project (AY2005) 50
Executing Sporadic tasks
CS461 - Senior Design Project (AY2005) 51
Executing sporadic tasks
CS461 - Senior Design Project (AY2005) 52
• 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 couldexecute when the sporadic job queue is not empty).
Practical considerations
CS461 - Senior Design Project (AY2005) 53
• 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 theacceptance test???)
• Multiprocessors.– Like uniprocessors, but table probably takes longer to
precompute.
Network Flow Algorithm forComputing Static Schedules
CS461 - Senior Design Project (AY2005) 54
• 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
CS461 - Senior Design Project (AY2005) 55
• Denote all jobs in the major cycle of F frames asJ1, 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
CS461 - Senior Design Project (AY2005) 56
Finding a schedule
CS461 - Senior Design Project (AY2005) 57
• 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 sliceit into corresponding subjobs.
Example
CS461 - Senior Design Project (AY2005) 58
Non-independent tasks
CS461 - Senior Design Project (AY2005) 59
• 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’srelease, 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
CS461 - Senior Design Project (AY2005) 60
• 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.
CS461 - Senior Design Project (AY2005) 61
Disadvantages
CS461 - Senior Design Project (AY2005) 62
• 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
CS461 - Senior Design Project (AY2005) 63
• 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
CS461 - Senior Design Project (AY2005) 64
Optimality of EDF
CS461 - Senior Design Project (AY2005) 65
• 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 onlyif 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”:
CS461 - Senior Design Project (AY2005) 66
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:
CS461 - Senior Design Project (AY2005) 67
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.
CS461 - Senior Design Project (AY2005) 68
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 - Senior Design Project (AY2005) 69