Unit OS9:
Real-Time and Embedded Systems
9.1. Introduction and Vocabulary
Windows Operating System Internals - by David A. Solomon and Mark E. Russinovich with Andreas Polze
Copyright Notice
© 2000-2005 David A. Solomon and Mark Russinovich
These materials are part of the Windows Operating
System Internals Curriculum Development Kit,
developed by David A. Solomon and Mark E.
Russinovich with Andreas Polze
Microsoft has licensed these materials from David
Solomon Expert Seminars, Inc. for distribution to
academic organizations solely for use in academic
environments (and not for commercial use)
2
Roadmap for Section 9.1
Introduction and Vocabulary
Performance Measures
General Structure of a Real-Time System
Task Assignment and Scheduling
Uni- vs. Multi-Processor Scheduling Algorithms
Critical Sections and Priority Inversion
3
Introduction and Vocabulary
What is a Real-time System?
“A real-time system is one in which the correctness of
the computations not only depends on the logical
correctness of the computation, but also on the time at
which the result is produced. If the timing constraints of
the system are not met, system failure is said to have
occurred.”
Confusion:
Not a clear definition!
What are timing constraints ? (tasks have deadlines)
4
More confusion
What is the meaning of a “deadline"?
Do all tasks have to be executed before their deadline? (not
necessarily)
Sometimes “yes”: flight control in an aircraft
Sometimes “no”: Multimedia-App.
What is the meaning of “executed“?
How to decide whether a task has been (completely) executed?
Relatively simple: bank transaction
Impossible: Computation of π
How to deal with tasks that missed their deadlines?
Terminate or run to completion?
Aircraft accident vs. Videoconference
5
Task Value Functions
Value
Value
deadline
deadline
Value
deadline
6
Hard vs. Soft Real-time Systems
Hard real-time systems
Embedded systems: aircraft control, nuclear power plants,
chemical reactors, jet engines
Missing a deadline has life-threatening results.
Soft real-time systems
Multimedia, airline reservation system
Missing a deadline is undesirable and impacts system
performance but has not destroy lives or equipment.
7
Vocabulary
Example: Car & Driver
Well-known example for human control:
Comparable to a real-time computer system in many respects
Driver: real-time controller
Car: controlled process
Road and additional cars: operating environment
Actuators:
Wheels, engine, brakes
Controls:
Steering wheel, brake pedal, switches
8
Mission Statement
Drive within the allowed speed range from start A to
destination B without collisions with other cars or
stationary objects.
How can driver‘s performance be measured?
Departs from A and reaches destination B
Total driving time
But: road conditions have to be taken into account
What, if driver leaves the road?
Success: collision could be avoided
Failure: control over vehicle was lost
9
The Mission – a closer look
Performance is no absolute measure.
Performance measures quality of a result in terms of the
best possible result under the current environmental
conditions.
A closer look onto the mission:
Mission critical:
steering, brakes
Non-critical:
radio, lights
Deadlines are not constants (rush hour vs. Sunday drive)
How to measure the drivers physical condition?
10
Performance Measures
Average values say very little about the
performance of a real-time controller.
In our scenario:
How to value abrupt acceleration/deceleration
maneuvers ?
How to measure for unnecessarily increased fuel
usage?
What about extra slow driving?
11
Problems of RT Computing
Reliability, Fault-tolerance
Harsh environments, electromagnetic noise, rapidly changing
computation loads
Task Scheduling
Traditional Approach: fairness / round robin scheduling / time
slicing
RT System: fixed priority scheduling / generalized rate
monotonic scheduling / earliest deadline first
Memory Management
Swapping / paging
Static pre-allocation (mpin(), vm_wire())
12
Problems of RT Computing (contd.)
Cache Allocation Policy
Preemption may cause cache invalidation -> missed
deadline
Does tA = tA1 + tA2 hold?
A
tA1
B
A
A preempted
A resumed
tA2
A completed
13
Structure of a Real-time System
Environment
Controlled
process
Sensors
Job list
Clock
Trigger
generator
Actuators
Controller: RT-Computer/
Uni- vs. Multiprocessor
Execution
Display
Operator
Input data rates: typically < 1 KB/sec
Fixed set of processes; software is "pre-loaded“
Scheduler (offline vs. online schedules)
Output data rates: typically < 1 command/25 ms
14
Data Rates
Sensors/Actuators/Display/Input
Panels: low
Data conversion/formatting:
medium
(peripheral area)
Control algorithm: high
(central cluster)
Sensor and actuator layer
Peripheral area
Central
cluster
Controlled process often moves
through different phases
Varying sets of priorities,
control tasks, deadlines
15
Task Classes
Periodic, sporadic and aperiodic tasks
Critical and non-critical tasks
Non-critical real-time (soft real-time tasks):
Objective: maximize percentage of jobs
successfully executed
16
Areas of Interest
Architecture
Processor Architecture
Network Architecture
Architectures for Clock Synchronization
Fault-tolerance and Reliability Evaluation
Operating System
Task Assignment and Scheduling
Communication Protocols
Failure Management and Recovery
Clock Synchronization Algorithms
Others
Programming Languages
Databases
Performance Measures
17
Task Assignment and Scheduling
Objective: allocation and scheduling of tasks on
processors to ensure that deadlines are met
Problem statement:
Given a set of tasks, task precedence constraints, task
characteristics, and deadlines, we are asked to devise a
feasible allocation/schedule on a given computer
Task
consumes resources (cpu, memory, input data)
produces results
Precedence constraints: Ti needs output from Tj
18
Task Dependency Graph
Characteristics:
Precedence-relation "<“
Release time
Deadline (hard, soft)
Relative deadline: absolute deadline - release time
19
Periodicity
Periodic: released periodically, every Pi seconds
Period Pi
Runs once every period (not exactly every Pi sec)
Sporadic: not periodic, invoked irregularly
Upper bound on invocation rate
Aperiodic: sporadic but without bounded invocation rate
Example:
Sensor is read every 10 ms.
If value exceeds threshold, signal is send out
Sensor task is periodic; period p = 10ms
Task that sends the signal is sporadic
Maximum invocation rate for this sporadic task?
20
Feasibility of a Schedule
Task assignment/schedule is feasible if all tasks start
after their release times and complete before their
deadlines
Schedule S: Set of processors x Time
Set of tasks
S(i,t) is the task scheduled to be running on processor i at time t
Offline scheduling: precomputed schedule
Online scheduling: tasks are scheduled at arrival
Must be fast
Static-priority algorithms: tasks' priorities do not change within a
mode (Rate Monotonic Scheduling - RMS)
Dynamic-priority algorithms: priority changes with time (Earliest
Deadline First - EDF)
21
Preemptive vs. non-preemptive
Scheduling
Preemptive: tasks can be interrupted by other tasks
More flexible
Critical task must be allowed to interrupt less critical ones
Non-preemptive: task runs until completion or blocking
• S1: sub optimal; non-preemptive
• S2: T2 misses deadline; nonpreemptive
• S3: preemptive; resource optimal
• Overhead for preemption;
bookkeeping
• Preemption not always possible:
disk write
22
Uni-processor Scheduling
Traditional rate-monotonic scheduling (RMS)
Periodic, preemptable tasks
Deadlines equal task period
Set of n tasks is schedulable if total processor utilization is no
greater than n(2 1/n-1)
Task priorities are static; inversely related to periods
Optimal static-priority uniprocessor algorithm
Some results for deadline ≠ period
Rate monotonic deferred server (DS)
Similar to RMS
Can handle both: periodic and aperiodic tasks
23
Uni-processor Scheduling (contd.)
Earliest deadline first (EDF):
Tasks are preemptible
Task with earliest deadline has highest priority
Optimal uni-processor algorithm
If a task set is not schedulable on a single processor by EDF,
there is no other processor that can successfully schedule that
task set
Precedence and exclusion conditions:
RMS & EDF assume independent preemptible tasks
Only processing requirements are taken into account; memory,
I/O, other resource requirements negligible
24
Uni-processor Scheduling (contd.)
Multiple task versions:
System has primary and alternative version of tasks
Vary in execution time and quality of output
Primary: full-fledged task; top quality output
Alternative: bare-bone; lower-quality (acceptable) output; take
less much execution time
Schedule may pick alternative tasks during overload
IRIS tasks (increased reward with increased service):
Quality of output is monotonically nondecreasing function of
execution time
Example: iterative algorithms for computation of π
25
Multiprocessor Scheduling
Task assignment problem generally is NP-hard
Use heuristics
26
Multiprocessor Scheduling
Utilization balancing algorithm:
Assigns tasks to processors one by one
Balanced utilization at end of each step
Preemptive tasks
Next-fit algorithm:
Works in conjunction with RMS uni-processor algorithm
Divides task set into classes
Processors are exclusively assigned to tasks
Preemptive tasks
27
Multiprocessor Scheduling (contd.)
Bin-packing algorithm:
Assigns tasks to processors so, that utilization does not exceed
given threshold
Threshold is set so that uni-processor algorithm is able to
schedule assigned tasks
Preemptive tasks
Myopic offline scheduling algorithm:
Deals with non-preemptive tasks
Builds schedule using a search process
Focused addressing and bidding algorithm:
Tasks arrive at individual processors
If schedule not feasible: processor may offload some of its
workload onto other processors
Other processors may voluntarily take over tasks
28
Multiprocessor Scheduling (contd.)
Buddy strategy:
Three categories: underloaded, fully loaded, and overloaded
processors
Overloaded processors ask underloaded ones to take over
some load
Assignment with precedence constraints:
Takes precedence constraints into account
Trial-and-error process: assign communicating processes onto
same processor
29
Scheduling Problems
Critical Sections:
Source of anomalous behavior: priority inversion
Lower-priority tasks can block higher-priority tasks
Priority inheritance/priority ceiling protocols: finite upper bound to
the period of priority inversion
Mode Changes:
Mission can have multiple phases
Different task sets
Different priorities/arrival rates
How to add/delete tasks of the task list
Fault-Tolerant Scheduling:
Schedule backups in the event of failure
30
Critical Sections
Binary semaphores
Lower priority task may block higher priority task
• T3 has lock; blocks T1
• T2 interrupts T3
Priority inversion
31
Priority Inheritance Protocol
TIME_CRITICAL
TH starts,
request
resource
NORMAL
TL locks
resource
TH continues
to
completion
TL is boosted
until it frees
resource
TL runs as
scheduled
Time
TL blocks TH (by owning a semaphore)...
TL inherits temporarily priority of TH
Every lower priority task may block higher priority task
exactly once per critical section
Priority inheritance protocol may create deadlocks
32
Priority Ceiling Protocol
Priority ceiling of a semaphore is highest priority of any
task that may lock semaphore
Priority owner of lock = priority ceiling
Critical Section
Accessed By
Priority Ceiling
S1
T1, T2
P(T1)
S2
T1, T2, T3
P(T1)
S3
T3
P(T3)
S4
T2, T3
P(T2)
• Priority ceiling protocol prevents deadlocks
33
Requirements for a RT OS
The OS (operating system) must be multithreaded and preemptive
The OS must support thread priority
A system of priority inheritance must exist
The OS must support predictable thread synchronization
mechanisms
In addition, the OS behavior must be predictable. This means real-time
system developers must have detailed information about the system
interrupt levels, system calls, and timing:
The maximum time during which interrupts are masked by the OS and by device
drivers must be known.
The maximum time that device drivers use to process an interrupt, and specific
IRQ information relating to those device drivers, must be known.
The interrupt latency (the time from interrupt to task run) must be predictable and
compatible with application requirements.
34
Further Reading
Jane W.S. Liu, Real Time Systems, Prentice
Hall, ISBN 0-13-099651-3, 2000.
C.M. Krishna and Kang G. Shin, Real-Time
Systems, McGraw-Hill, ISBN: 0-07-057043-4,
1997.
Hermann Kopetz, Real-Time Systems: Design
Principles for Distributed Embedded
Applications, Kluwer Academic Publishers, ISBN
0-79-239894-7, 1997.
35