TDDI04
Concurrent Programming,
Operating Systems,
and Real-time Operating Systems
Where are OSs found?
General purpose systems
Embedded systems
Microprocessor
market shares
in 1999
Real-time Operating Systems
Short introduction
99%
1%
[GSS7 Chapter 19]
Acknowledgment:
Some slides are by courtesy of Jörgen Hansson, RTSLAB / IDA.
The lecture notes are originally compiled by C. Kessler, IDA.
Klas Arvidsson, IDA,
Linköpings universitet.
What is a Real-time System?
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
Example: Controlling flow of cooling
water in a nuclear power plant
§ A real-time system is any information processing system
which has to respond to externally generated input stimuli
within a finite and specified period.
•
Correctness depends not only on the logical result but also
the time it was delivered!
•
Failure to respond is as bad as the wrong response!
Interface
•
Pipe
Input flow
reading
Flow meter
Processing
§ Many (but not all) real-time systems are embedded systems.
•
RT.2
Embedded computer system:
the computer is a component in a larger engineering
system.
Ex.: Consumer electronics
devices, car control systems, ...
RT.3
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
Valve (regulator)
Output valve
angle
Time
Computer
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.4
Some Misconceptions about
Real-Time Systems
Some Misconceptions about
Real-Time Systems
MISCONCEPTION #1:
”Real-time computing is equivalent to fast computing!”
MISCONCEPTION #2:
”Advances in hardware performance will
solve real-time problems”
§ CORRECT: Real-time computing aims at predictability
foremost, and secondly, efficiency.
§ Predictability: Time-cognizant behavior of the system, i.e.,
the system is designed and developed to enforce temporal
correctness, preferably by direct awareness and explicit
notion of time.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.5
§ CORRECT: Improving hardware performance is always
desirable, but does not imply (without support of analysis) that
predictability has been maintained / achieved (e.g., release
times of tasks).
§ Most computer architecture techniques improve on the
average case
but may even aggravate the worst case!
• Example: Memory access time with caching, TLB
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.6
1
Utility Function
Terminology
(Value of result relative to time)
§ Hard real-time –
•
Hard real-time system:
systems where it is absolutely imperative
that responses occur within the required deadline
utility
§ Soft real-time –
vv(t)
i (t )
utility loss
systems where deadlines are important but which will still
function correctly if deadlines are occasionally missed.
benefit
•
•
ri
systems which are soft real-time but in which there is no
benefit from late delivery of service
Release time
di
time
penalty
§ Firm real-time –
Deadline
§ A single system may have all hard, soft and firm real-time
subsystems.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.7
Utility function (cont.)
RT.8
Soft Real-Time
§ Multiple requirements
Soft real-time systems:
utility
•
Deadlines can be missed occasionally,
typically with an upper limit of misses within a defined
interval, e.g., a constraint on the maximum number of
consecutive deadline misses
•
Service can occasionally be delivered late,
with an upper bound on tardiness,
i.e., a.k.o. deadline tolerance.
Decay rate
Lin
ear
Exp
one
nti
ri
al
di
di +
time
-p
§ ”Hard real-time is hard, but soft real-time is harder!”
- infinity
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.9
Characteristics of a RTS
§ Extreme reliability and safety
•
•
RTS typically control the environment in which they operate.
Failure to control can result in loss of life, damage to environment or
economic loss.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
Real-Time Computer
Interacting with Its Environment
Real-Time
Clock
We need to be able to predict with confidence the worst case
response times for systems
(period, rel. deadline,
computation time)
– Often ensured a priori
Remote
Monitoring System
sporadic tasks
Data Retrieval
and Display
Display
Devices
(no period, but
relative deadline)
aperiodic tasks
Operator’s
Console
Operator
Interface
– post-processing (… wait and see…)
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.11
Engineering
System
Data Logging
> In conventional systems, performance is:
– system oriented and often throughput oriented
Interface
Database
> In RTS, performance guarantees are:
– Task- and/or class centric
Algorithms for
Digital Control
periodic tasks
§ Guaranteed response times
•
RT.10
(no period,
no or soft deadline)
Real-Time Computer
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.12
2
Towards Real-Time Scheduling
RTS Workload Characteristics
Non-Realtime-Scheduling (as covered earlier)
§ Tasks are preemptable, independent with arbitrary arrival
times
§ Primary Goal: maximize performance
§ Tasks have deadlines (D) and known computation times (C)
§ Secondary Goal: ensure fairness
§ Tasks execute on a uni-processor system
§ Typical metrics:
•
•
•
minimize response time
Example setup:
maximize throughput
T1
e.g., FCFS (First-Come-First-Served),
RR (Round-Robin)
C1
D1
C2
T2
D2
C3
T3
D3
C4
D4
T4
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.13
Example:
Non-preemptive FCFS Scheduling
RT.14
Example:
Round-Robin Scheduling
Missed
deadline!!
Missed
deadline!!
T1
T1
T2
T2
T3
T3
T4
T4
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.15
Real-Time Scheduling
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.16
Spectrum of Scheduling Problems
and Scheduling Algorithms
§ Primary goal: ensure predictability
§ Secondary goal: ensure predictability
§ Typical metrics:
•
•
•
guarantee miss ratio = 0 (hard real-time)
•
minimize overall tardiness; maximize overall usefulness
(soft real-time)
guarantee Prob(missed deadline) < X % (firm real-time)
maximize completion ratio / minimize miss ratio
(firm real-time)
§ e.g., EDF (Earliest Deadline First, LS (Least Slack),
RMS (Rate-Monotonic Scheduling)
§ Recall: Real-time is about enforcing predictability,
and does not equal fast computing!!!
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.17
§ Uni-processor / multiprocessor / distributed system
§ Periodic / sporadic / aperiodic tasks
§ Independent / interdependent tasks
§ Preemptive / non-preemptive
§ Static (at system build time) / dynamic (at run time)
§ Off-line (all tasks initially given) / on-line (don’t know future)
§ Handle transient overloads
§ Support fault tolerance
§ Easier vs. More difficult
§ Heuristic (no guarantees)
vs. Approximation (result provably within X% of opt.)
vs. Provably optimal
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.18
3
RT Task Assignment and Scheduling
Overview
§ Cyclic executive scheduling
•
•
Hardcoded / table-driven cooperative scheduling
fixed at design time
§ Preemptive, priority-driven scheduling
•
Static priority-driven scheduler
Priorities are set assigned pre-execution.
> E.g. Rate-monotonic scheduling (RMS/RMA)
•
Simple RT Process Model
§ Fixed set of processes (tasks)
§ Processes are periodic, with known periods
§ Processes are independent of each other
§ System overheads, context switches etc. are ignored
(zero cost)
§ Processes have a relative deadline equal to their period
•
i.e., each process must complete before its next release
§ Processes have fixed worst-case execution time
Dynamic priority-driven scheduler
can assign, and possibly also redefine, process priorities at
run-time.
> E.g., Earliest Deadline First (EDF)
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.19
Cyclic Executive Approach
§ Clock-driven (time-driven) scheduling algorithm
§ Off-line scheduling algorithm
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
Cyclic Executive (cont.)
loop
Wait_For_Timer_Interrupt;
§ Schedule (hardcoded or) table-driven
§ Minor Cycle (e.g. 25ms)
- gcd of all periods
§ Major Cycle (e.g. 100ms) - lcm of all periods
Construction of a cyclic executive is equivalent to bin packing
Process
A
Period
25
Comp. Time
10
B
25
8
C
50
5
D
50
4
E
100
2
RT.21
Wait_For_Timer_Interrupt;
Procedure_For_A; // 10
Procedure_For_A;
Procedure_For_B;
// 8
Procedure_For_B;
Procedure_For_C; // 5
Procedure_For_C;
Wait_For_Timer_Interrupt;
Wait_For_Timer_Interrupt;
Procedure_For_A; // 10
Procedure_For_A;
Procedure_For_B;
// 5
Procedure_For_B;
Procedure_For_D;
// 4
Procedure_For_E;
// 2
0
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.20
Procedure_For_D;
end loop;
25
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
50
Cyclic Executive (cont.)
Cyclic Executive (cont.)
Observations
Difficulties
§ No actual processes exist at run-time
§ Difficult to incorporate sporadic processes;
•
Each minor cycle is just a sequence of procedure calls
75
100
RT.22
§ Difficult to incorporate processes with long periods;
§ Difficult to handle processes with sizeable computation times.
§ The procedures share a common address space
and can thus pass data between themselves.
•
This data does not need to be protected
(via a semaphore, for example)
because concurrent access is not possible
§ All `process' periods must be a multiple of the minor cycle
time.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.23
§ It makes proving program correctness more difficult;
§ It makes problem decomposition more complex;
§ Programmer needs to consider structures
which really are irrelevant to the control of the tasks at hand;
§ Parallel execution of the program on a multiprocessor
platform will be harder to achieve; and
§ The placement of code to deal with faults becomes more
problematic.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.24
4
Alternative?
Remember: Dynamic Scheduling
§ Use dynamic scheduling
§ + admission control (schedulability test)
•
static test (
RMA) or on-line test (
EDF)
task
activation
scheduling
Ready
termination
Run
preemption
signal from
resource
wait on busy resource
Waiting
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.25
RT.26
Schedulability Test
RMA Assumptions
Test to determine whether a feasible schedule exists
A1: Tasks are periodic (activated at a constant rate).
Period Pi = interval between two consecutive activations of task τi
§ Exact Test
A2: All instances of a periodic task τi have
the same computation time Ci
•
The task set is schedulable
if and only if it passes the test.
A3: All instances of a periodic task τi have the same relative deadline, which
is equal to the period (Di = Pi).
§ Sufficient Test
+ if test is passed, then tasks are definitely schedulable
– if test is not passed, tasks may be schedulable
Implicit assumptions:
A5: Tasks are preemptable
§ Necessary Test
A6: No task can suspend itself
+ if test is passed, tasks may be schedulable
– if test is not passed, tasks are definitely not schedulable
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
A4: All tasks are independent
(i.e., no precedence constraints and no resource constraints).
A7: All tasks are released as soon as they arrive
A8: All overhead in the kernel is assumed to be zero (or part of Ci).
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.27
RT.28
Rate-Monotonic Scheduling
Rate Monotonic Scheduling: Principle
RMA: Priority = inverse periodicity
§ Each process is assigned a (unique) priority
based on its period;
§ the shorter the period, the higher the priority
Example:
§ W.l.o.g. number the tasks in reverse order of priority
§ P1 (period 50, computation time 20) has higher priority than
Example:
P2 (period 100, computation time 35)
Process Period
A
Image source: Silberschatz, Galvin,
Gagne 7th ed. © Wiley 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.29
25
Priority
Name
5
T1
B
60
3
T3
C
42
4
T2
D
105
1
T5
E
75
2
T4
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.30
w.l.o.g. = without loss of generality
5
Example:
Rate Monotonic Scheduling
Example:
Rate Monotonic Scheduling
Tasks and Task instances (jobs),
Release times / Periods, Computation times
Gantt-Chart for RM schedule
P4
T4
T4
T3
T3
T2
T2
T1
T1
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.31
RT.32
RMA: Schedulability test #1
Utilization
U i = C i / Pi
Theorem (Utilization-based Schedulability Test):
A periodic task set τ1, τ2, ...τn, with Di = Pi , 1 ≤ i ≤ n,
is schedulable by the rate monotonic scheduling algorithm
if
utilization of task τi
U1 + .... + U n ≤U n*
P4
n
 Ci 
∑ P  ≤ n(2
i =1
T4

i

1/ n
n
−1), n = 1,2,.....
T3
This schedulability test is ”sufficient”!
T2
Utilization Bound (in %)
1
2
3
5
10
n →∞
100.0%
82.8%
78.0%
74.3%
71.8%
69.3% (ln 2)
§ For harmonic periods (Tj evenly divides Ti),
the utilization bound is 100%
§ For the average workload the utilization bound is ~ 88-92%.
T1
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.33
RMA Schedulability Test #1
Example
RT.34
RMA Schedulability Test #2:
Simulation-based test
§ τi = < Pi , Ci >
§ n=3,
Τ = { τ1 = < 10 , 5 >, τ2 = < 20 , 5 >, τ3 = < 30 , 5 > }
Given
 Ci 
  ≤ n(21/ n − 1), n = 1,2,.....
∑
i =1  Pi 
We get
∑ (5 / 10 + 5 / 20 + 5 / 30) = 0.916 which is > n(2
τ1
τ2
n
τ3
n
1/ n
− 1) = 0.78
0
10
20
30
i =1
1. Start with ``worst case’’ scenario
where all tasks releasing their first job at time 0.
takes time
O(n Pn/P1)
2. Simulate RMA Algorithm until first jobs of all tasks have finished.
Here, the utilization-based schedulability test fails.
A ”false negative” case ?!
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.35
Task τ3 meets its deadline and, thus, τ1 and τ2 also meet their
deadlines. Hence, workload is schedulable!!
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.36
6
RMA: Optimality
RMA Implementation
Theorem (Optimality of RM scheduling):
The rate monotonic scheduling algorithm is optimal among all
fixed priority scheduling algorithms for scheduling periodic
task sets where the deadline of tasks equals the end of their
period (Di = Pi).
§ Fixed priorities -> use pre-sorted array of PCB references
Proof: [Liu and Layland 1973]
But, there may be dynamic-priority algorithms that do better…
Example: P1<50,25>, P2<80,35>
PCB1 PCB2 PCB3 PCB4
…
§ On termination of task τi:
state(τi) = NOT_READY;
Find first READY task (e.g., by linear search).
If there is one, dispatch it (τcurrent ), otherwise idle.
Image source: Silberschatz, Galvin,
Gagne 7th ed. © Wiley 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.37
EDF Scheduling: Principle
A1: Tasks are periodic or aperiodic.
They are activated at a constant rate, with period P.
Principle:
A3: All instances of a periodic task τi have the same relative deadline,
which is equal to the task period (Di = Pi).
A4: All tasks are independent
(i.e., no precedence constraints and no resource constraints).
Implicit assumptions:
τn
Remark: Find in O(n)
time is ok for small n.
A binary tree solution
would allow for O(log n)
insert/find
RT.38
EDF Assumptions
A2: All instances of a periodic task τi have the same computation time Ci
PCBn
τ1
τcurrent
τi
§ On release of new task τi :
state(τi ) = READY;
if (i < current) {
preempt τcurrent; state(τcurrent) = READY;
state(τi) = EXECUTING; dispatch τi to CPU;
}
else keep τcurrent on CPU and set state(τi ) = READY;
§ Preemptive priority-based dynamic scheduling (as before)
§ Each process is assigned a (current) priority based on how
close its deadline is:
•
the shorter the deadline, the higher the priority:
Example:
P1 <50, 25>, P2 <80, 35>
A5: Tasks are preemptable
A6: No task can suspend itself
A7: All tasks are released as soon as they arrive
A8: All overhead in the kernel is assumed to be zero
(or part of Ci).
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.39
Example:
Non-preemptive EDF Scheduling is Not Optimal
RT.40
Image source: Silberschatz, Galvin,
Gagne 7th ed. © Wiley 2005
Example:
Preemptive EDF Scheduling
Missed
deadline!!
τ1
τ1
τ2
τ2
τ3
τ3
τ4
τ4
Feasible schedule!!
EDF is not optimal for non-preemptive scheduling problems.
This picture demonstrates the problem of non-preemptive tasks.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.41
Arrival time
Deadline
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.42
7
EDF with Dynamic Workload?
Example: Domino Effect
EDF: Schedulability test
Theorem (Utilization-based Schedulability Test):
A task set τ1, τ2, ...τn, with Di = Pi , 1 ≤ i ≤ n, is schedulable by
the earliest deadline first (EDF) scheduling algorithm iff
τnew
U1 + ....+ Un ≤ 1
n
 Ci 
τ2

τ3
∑ P  ≤ 1, n = 1,2,.....
i =1
i
Domino
effect!!!
τ1

τ4
§ Schedulability test is ”exact”!
Dynamic workloads may cause transient overloads scenario, i.e., we need
to protect the system of being presented with unschedulable workloads!!!
§ Maximimizes CPU utilization
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
Dertouzos (1974): EDF minimizes lateness of the ”most tardy” task
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.43
Dynamic Scheduling
with Dynamic Admission Control
RT.44
EDF Implementation
EDF has higher run-time overhead than RMA:
scheduling
activation
acceptance
test
YES
NO
§ Need to keep PCB’s / TCB’s sorted by next deadline
termination
Ready
Run
•
> deletemin(), to dequeue the task with closest deadline
> insert(τi, di), to enqueue a task with its next deadline
preemption
signal from
resource
Waiting
Operations:
wait on busy
resource
(when the current instance has terminated)
•
i.e., a Priority Queue
§ There exist data structures for ADT Priority Queue with
Acceptance test is also known as performing admission control
Perform admission control at run-time when
• tasks have dynamic activations
• the arrival times are not known a priori
• execute test every time there is a new task coming into the system
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
•
•
deletemin() in (worst-case) time O(log n)
insert() in (worst-case) time O(log n)
E.g., a balanced search tree (2-4, red-black, …) with doubly linked list of
leaves containing PCB’s, ordered by deadline, plus a pointer to the leaf
with minimum deadline
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.45
RT.46
Fixed vs. Dynamic Priority Scheduling
What if the schedulability test failed?
Fixed Priority Scheduling (e.g., RMA)
§ Dynamic scheduling, but
static analysis (RMA)
§ assumes clairvoyance
What to do if the schedulability test failed for my system?
§ schedules planned for peak load
+ task workloads are periodic
=> no overloads
+ low (RMA) or no (off-line)
overhead at run time
+ simple to implement
- Conservative -> lower utilization
Dynamic Priority Scheduling (e.g., EDF)
•
•
•
•
Dynamic scheduling
With guarantee test: Tasks may be
added dynamically
on-line
no a priori knowledge
+ flexibility
+ maximal utilization
+ adaptability
+ few assumptions about workload
characteristics
- prone to overloads
- non-negligible run-time overhead,
more critical at high loads
§ Get a faster CPU, or replicate hardware (e.g., multiple CPUs)
•
•
•
hardware re-design and/or larger/more expensive chip
higher power consumption
may also require recoding the program
§ Re-design the tasks to take less execution time
§ Aggressive code optimization (compiler issue – TDDC86)
•
(may help more or less)
§ Re-negotiate the specification (i.e., deadlines)
Most suitable for hard RTS
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
More suitable for soft/firm RTS
RT.47
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.48
8
Summary: Scheduling Approaches for RTS
§ Off-line scheduling / analysis (static analysis + static scheduling)
• All tasks, times and priorities given a priori (before system startup)
• Time-driven; schedule computed and hardcoded before system startup
• E.g., Cyclic executives
• Inflexible
• May be combined with static or dynamic scheduling approaches
§ Fixed priority scheduling (static analysis + dynamic scheduling)
• All tasks, times and priorities given a priori (before system startup)
• Priority-driven, dynamic(!) scheduling:
The schedule is (re-)constructed by the OS scheduler at run time
• For hard / safety-critical systems
• E.g., RMA/RMS - Rate Monotonic Analysis/Scheduling, …
§ Dynamic priority scheduling / On-line scheduling
• Scheduler does not know about future task arrivals and their priorities
• Priority-driven
• For best-effort systems
• E.g., EDF - Earliest Deadline First, (Least Slack) …
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.49
Context Switch Time?
§ RMA and EDF assumed
•
zero-delay for context switching
> next task resumes immediately when preceding one
gets preempted
§ In practice, 2 predictability problems:
•
•
Interrupt latency
Dispatch latency
Event latency = interrupt latency + dispatch latency
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.50
Image source: Silberschatz, Galvin,
Gagne 7th ed. © Wiley 2005
Interrupt Latency
Priority inversion problem
n The time from an interrupt assertion
until processing starts
is called interrupt latency
Scenario:
n Predictability issue:
Kernel may disable interrupts temporarily
e.g. for updating kernel data structures atomically
n RTOS must guarantee small bounded interrupt latency
n Approach: Model (major part of) ISR execution as
§ A low-prioritized thread L takes resource R and executes...
§ Then mid-prioritized thread M preempts L and executes...
§ Then high-prioritized thread H preempts M and executes...
...until it needs resource R.
But R is occupied (owned by L), and H waits.
§ Now M will be awake and running, and H will have to wait for
an unrelated thread M to finish ... ?
preemptable process with own priority
n Interrupts have higher priority than other processes
n Interrupts are prioritized among each other
n Interrupts with higher priority
preempt lower priority interrupts
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.51
§ Can be resolved by priority inheritance
•
L temporarily inherits H’s priority while working on R
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.52
Dispatch Latency
Memory management
§ Dispatch latency is the amount of time required for the
scheduler to stop one process and start another.
§ Memory management
in RTOS?
•
Paging, Swapping, Caching,
Virtual Memory:
Source of unpredictability!
> Approach: Software-controlled
paging etc., e.g. page locking
•
Fragmentation
e.g. priority
inversion
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.53
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.54
9
GPOS
Example: Linux as an RTOS?
Example: RTLinux Architecture
§ Disabling of interrupts by Linux subsystems when they are in critical
sections (disk system may disable for > 100ms), blocking clock interrupts
• Solution #1: Rewrite all offending drivers to make their
nonpreemptable sections as short as possible
• Solution #2: Try to live with it
• Solution #3: Avoid it.
Linux
tasks
System calls
§ Tasks = both processes and threads
• Clone: share memory with parent
§ Scheduling: (first 100 priority levels)
• Fully preemptive (since kernel 2.6)
• Real-time tasks have static priorities; FIFO or RR
> Soft real-time scheduling (POSIX.1b)
• Other tasks: Time-sharing, dynamic priorities
§ Clock and timer resolutions: 10 milliseconds (”jiffy”)
• Timing error can be large and unpredictable because of delays introduced
by (i) kernel
execution times of the timer functions
TDDI04, K. Arvidsson,
IDA, Linköpings
universitet. and (ii) large
RT.55
Device drivers
Linux
Kernel
Interrupts
I/O
RTLinux Kernel
Interrupts
Hardware platform
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.56
Example: RTLinux (cont.)
Example: VxWorks 5.x
§ Simulates interrupt disable/enable feature (flag)
§ Popular RTOS supporting hard real-time systems
•
Interrupts are caught by real-time kernel (hardware interrupts are
replaced by software-emulated interrupts)
•
Interrupts are relayed to Linux kernel when no real-time processes are
scheduled for execution
•
•
•
Interrupts are available to RTLinux, but disabled for Linux
Linux kernel becomes completely preemptable
Real-time kernel not preemptible, but optimized for not causing
significant delays
§ Preemptive fixed priority scheduler
•
EDF and Rate Monotonic packages exist
§ Runs on several hardware platforms
§ Direct communication between processes on different kernels not possible
RT
tasks
•
[SGG7] 19.6
By WindRiverSystems
§ Widely used in automobiles, consumer and industrial devices, network
switches, routers etc.
•
The 2 Mars rovers 2004
§ Wind Microkernel:
•
•
tasks = both processes and threads (with Pthreads API)
•
•
Bounded interrupt and dispatch latency
Scheduling: Preemptive round-robin and FCFS
Priority-Driven Scheduling with 256 priority levels
IPC: shared memory and message passing;
> Semaphores and mutex locks
– with priority inheritance protocol
> pipes (file-buffered message passing)
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.57
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
RT.58
10