Real-time Operating Systems Short introduction [GSS7 - - PDF document

SLIDE 1

1

Klas Arvidsson, IDA, Linköpings universitet.

TDDI04 Concurrent Programming, Operating Systems, and Real-time Operating Systems

Acknowledgment: Some slides are by courtesy of Jörgen Hansson, RTSLAB / IDA. The lecture notes are originally compiled by C. Kessler, IDA.

Real-time Operating Systems

Short introduction [GSS7 Chapter 19]

RT.2

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

• RT.3

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

What is a Real-time System?

§ 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!

§ Many (but not all) real-time systems are embedded systems.

• Embedded computer system:

the computer is a component in a larger engineering system.

• Ex.: Consumer electronics devices, car control systems, ...

RT.4

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Example: Controlling flow of cooling water in a nuclear power plant

Pipe Flow meter Valve (regulator) Interface Computer Time Input flow reading Processing Output valve angle

RT.5

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Some Misconceptions about Real-Time Systems

MISCONCEPTION #1: ”Real-time computing is equivalent to fast computing!” § 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.

RT.6

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Some Misconceptions about Real-Time Systems

MISCONCEPTION #2: ”Advances in hardware performance will solve real-time problems” § 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

SLIDE 2

2

RT.7

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Terminology

§ Hard real-time

• systems where it is absolutely imperative

that responses occur within the required deadline § Soft real-time

• systems where deadlines are important but which will still

function correctly if deadlines are occasionally missed. § Firm real-time

• systems which are soft real-time but in which there is no

benefit from late delivery of service § A single system may have all hard, soft and firm real-time subsystems.

RT.8

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Utility Function

(Value of result relative to time)

utility time v(t) benefit utility loss penalty

i

r

i

d ) (t vi Hard real-time system:

• RT.9

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Utility function (cont.)

utility time Decay rate Linear Exponential i

r

i

d +

i

d

• p
• infinity

Soft real-time systems:

RT.10

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Soft Real-Time

§ Multiple requirements

• 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. § ”Hard real-time is hard, but soft real-time is harder!”

RT.11

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

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.

§ Guaranteed response times

• We need to be able to predict with confidence the worst case

response times for systems

> In RTS, performance guarantees are: Task- and/or class centric Often ensured a priori > In conventional systems, performance is: system oriented and often throughput oriented post-processing ( wait and see)

RT.12

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Real-Time Computer Interacting with Its Environment

Algorithms for Digital Control Data Logging Data Retrieval and Display Operator Interface Interface Remote Monitoring System Real-Time Clock Database Display Devices Real-Time Computer

• Operator’s

Console Engineering System sporadic tasks

(no period, but relative deadline)

SLIDE 3

3

RT.13

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Towards Real-Time Scheduling

Non-Realtime-Scheduling (as covered earlier) § Primary Goal: maximize performance § Secondary Goal: ensure fairness § Typical metrics:

• minimize response time
• maximize throughput
• e.g., FCFS (First-Come-First-Served),

RR (Round-Robin)

RT.14

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

RTS Workload Characteristics

§ Tasks are preemptable, independent with arbitrary arrival times § Tasks have deadlines (D) and known computation times (C) § Tasks execute on a uni-processor system T1 T2 T3 T4

1

C

4

C

3

C

2

C

1

D

4

D

3

D

2

D !

RT.15

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Example: Non-preemptive FCFS Scheduling

T1 T2 T3 T4

Missed deadline!!

RT.16

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Example: Round-Robin Scheduling

T1 T2 T3 T4

Missed deadline!!

RT.17

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Real-Time Scheduling

§ Primary goal: ensure predictability § Secondary goal: ensure predictability § Typical metrics:

• guarantee miss ratio = 0 (hard real-time)
• guarantee Prob(missed deadline) < X % (firm real-time)
• maximize completion ratio / minimize miss ratio

(firm real-time)

• minimize overall tardiness; maximize overall usefulness

(soft 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!!!

RT.18

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Spectrum of Scheduling Problems and Scheduling Algorithms

§ 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

SLIDE 4

4

RT.19

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

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)

• Dynamic priority-driven scheduler

can assign, and possibly also redefine, process priorities at run-time.

> E.g., Earliest Deadline First (EDF)

RT.20

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

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

RT.21

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Cyclic Executive Approach

§ Clock-driven (time-driven) scheduling algorithm § Off-line scheduling algorithm § 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 Period

• Comp. Time

A 25 10 B 25 8 C 50 5 D 50 4 E 100 2

RT.22

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Cyclic Executive (cont.)

loop Wait_For_Timer_Interrupt; Procedure_For_A; // 10 Procedure_For_B; // 8 Procedure_For_C; // 5 Wait_For_Timer_Interrupt; Procedure_For_A; // 10 Procedure_For_B; // 5 Procedure_For_D; // 4 Procedure_For_E; // 2 Wait_For_Timer_Interrupt; Procedure_For_A; Procedure_For_B; Procedure_For_C; Wait_For_Timer_Interrupt; Procedure_For_A; Procedure_For_B; Procedure_For_D; end loop;

100 50 25 75

RT.23

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Cyclic Executive (cont.)

Observations § No actual processes exist at run-time

• Each minor cycle is just a sequence of procedure calls

§ 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.

RT.24

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Cyclic Executive (cont.)

Difficulties § Difficult to incorporate sporadic processes; § Difficult to incorporate processes with long periods; § Difficult to handle processes with sizeable computation times. § 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.

SLIDE 5

5

RT.25

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Alternative?

§ Use dynamic scheduling § + admission control (schedulability test)

• static test ( RMA) or on-line test ( EDF)

RT.26

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Remember: Dynamic Scheduling

task activation scheduling Ready Run Waiting preemption signal from resource wait on busy resource termination

RT.27

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Schedulability Test

Test to determine whether a feasible schedule exists § Exact Test

• The task set is schedulable

if and only if it passes the test. § Sufficient Test + if test is passed, then tasks are definitely schedulable – if test is not passed, tasks may be schedulable § Necessary Test + if test is passed, tasks may be schedulable – if test is not passed, tasks are definitely not schedulable

RT.28

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

RMA Assumptions

A1: Tasks are periodic (activated at a constant rate). Period Pi = interval between two consecutive activations of task τi A2: All instances of a periodic task τihave the same computation time Ci A3: All instances of a periodic task τihave the same relative deadline, which is equal to the period (Di = Pi). A4: All tasks are independent (i.e., no precedence constraints and no resource constraints). Implicit assumptions: 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).

RT.29

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Rate-Monotonic Scheduling

RMA: Priority = inverse periodicity Example:

§ P1 (period 50, computation time 20) has higher priority than

P2 (period 100, computation time 35)

"#!$%& # '( )*++,

RT.30

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Rate Monotonic Scheduling: Principle

§ Each process is assigned a (unique) priority based on its period; § the shorter the period, the higher the priority § W.l.o.g. number the tasks in reverse order of priority Example: Process Period Priority Name A 25 5 T1 B 60 3 T3 C 42 4 T2 D 105 1 T5 E 75 2 T4

w.l.o.g. = without loss of generality

SLIDE 6

6

RT.31

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Example: Rate Monotonic Scheduling

T4 T3 T2 T1

• - .

/01

RT.32

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Example: Rate Monotonic Scheduling

T4 T3 T2 T1

P4

21

RT.33

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Utilization

T4 T3 T2 T1

P4

Ui =Ci /Pi τi

RT.34

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

RMA: Schedulability test #1

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

This schedulability test is ”sufficient”! § For harmonic periods (Tj evenly divides Ti), the utilization bound is 100% § For the average workload the utilization bound is ~ 88-92%.

,..... 2 , 1 ), 1 2 ( ....

/ 1 1 * 1

= − ≤         ≤ + +

∑

=

n n P C U U U

n n i i i n n

n Utilization Bound (in %) 1 100.0% 2 82.8% 3 78.0% 5 74.3% 10 71.8% n →∞ 69.3% (ln 2)

RT.35

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

RMA Schedulability Test #1 Example

§ τi = < Pi , Ci > § n=3, Τ = { τ1 = < 10 , 5 >, τ2 = < 20 , 5 >, τ3 = < 30 , 5 > } Given We get Here, the utilization-based schedulability test fails. A ”false negative” case ?! 78 . ) 1 2 ( is which 916 . ) 30 / 5 20 / 5 10 / 5 ( ,..... 2 , 1 ), 1 2 (

/ 1 1 / 1 1

= − > = + + = − ≤        

∑ ∑

= = n n i n n i i i

n n n P C

RT.36

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

RMA Schedulability Test #2: Simulation-based test

τ1 τ2 τ3 10 20 30

• 1. Start with ``worst case’’ scenario

where all tasks releasing their first job at time 0.

• 2. Simulate RMA Algorithm until first jobs of all tasks have finished.

Task τ3 meets its deadline and, thus, τ1 and τ2 also meet their

• deadlines. Hence, workload is schedulable!!

OnPn/P1

SLIDE 7

7

RT.37

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

RMA: Optimality

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). Proof: [Liu and Layland 1973] But, there may be dynamic-priority algorithms that do better… Example: P1<50,25>, P2<80,35>

"#!$%& # '( )*++,

RT.38

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

RMA Implementation

§ Fixed priorities -> use pre-sorted array of PCB references § 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; § 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.

! 3 On n 4 55 O#n /

016 016* 0167 0168

9

τcurrent τ1 τi τn

016n

RT.39

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

EDF Assumptions

A1: Tasks are periodic or aperiodic. They are activated at a constant rate, with period P. A2: All instances of a periodic task τihave the same computation time Ci A3: All instances of a periodic task τihave 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: 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).

RT.40

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

EDF Scheduling: Principle

Principle: § 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>

"#!$%& # '( )*++,

RT.41

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Example:

Non-preemptive EDF Scheduling is Not Optimal

τ1 τ2 τ3 τ4

Missed deadline!!

EDF is not optimal for non-preemptive scheduling problems. This picture demonstrates the problem of non-preemptive tasks.

RT.42

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Example: Preemptive EDF Scheduling

τ1 τ2 τ3 τ4

Feasible schedule!!

Arrival time Deadline

SLIDE 8

8

RT.43

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

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 § Schedulability test is ”exact”! § Maximimizes CPU utilization

,..... 2 , 1 , 1 1 ....

1 1

= ≤         ≤ + +

∑

=

n P C U U

n i i i n

RT.44

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

EDF with Dynamic Workload? Example: Domino Effect

τnew τ1 τ2 τ3 τ4

Dynamic workloads may cause transient overloads scenario, i.e., we need to protect the system of being presented with unschedulable workloads!!! Dertouzos (1974): EDF minimizes lateness of the ”most tardy” task

• :::

RT.45

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Dynamic Scheduling with Dynamic Admission Control

acceptance test Ready Run Waiting YES NO activation scheduling preemption signal from resource wait on busy resource termination

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

RT.46

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

EDF Implementation

EDF has higher run-time overhead than RMA: § Need to keep PCB’s / TCB’s sorted by next deadline

• Operations:

> deletemin(), to dequeue the task with closest deadline > insert(τi, di), to enqueue a task with its next deadline

(when the current instance has terminated)

• i.e., a Priority Queue

§ There exist data structures for ADT Priority Queue with

• 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

RT.47

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Fixed vs. Dynamic Priority Scheduling

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 Fixed Priority Scheduling (e.g., RMA) § Dynamic scheduling, but static analysis (RMA) § assumes clairvoyance § schedules planned for peak load + task workloads are periodic => no overloads + low (RMA) or no (off-line)

• verhead at run time

+ simple to implement

• Conservative -> lower utilization
• $

/ -$

RT.48

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

What if the schedulability test failed?

What to do if the schedulability test failed for my system? § 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)

SLIDE 9

9

RT.49

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

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) …

RT.50

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

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

RT.51

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Interrupt Latency

nThe time from an interrupt assertion

until processing starts is called interrupt latency

nPredictability issue:

Kernel may disable interrupts temporarily e.g. for updating kernel data structures atomically

nRTOS must guarantee small bounded interrupt latency nApproach: Model (major part of) ISR execution as

preemptable process with own priority

nInterrupts have higher priority than other processes nInterrupts are prioritized among each other nInterrupts with higher priority

preempt lower priority interrupts

"#!$%& # '( )*++,

RT.52

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Priority inversion problem

Scenario: § 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 ... ? § Can be resolved by priority inheritance

• L temporarily inherits H’s priority while working on R

RT.53

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Dispatch Latency

§ Dispatch latency is the amount of time required for the scheduler to stop one process and start another.

# &

RT.54

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Memory management

§ Memory management in RTOS?

• Paging, Swapping, Caching,

Virtual Memory: Source of unpredictability!

> Approach: Software-controlled

paging etc., e.g. page locking

• Fragmentation

SLIDE 10

10

RT.55

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Example: Linux as an RTOS?

§ 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.

§ 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 intro-

duced by (i) kernel and (ii) large execution times of the timer functions

RT.56

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Example: RTLinux Architecture

;5

• & &

$ "/<

" " =

• RT.57

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Example: RTLinux (cont.)

§ Simulates interrupt disable/enable feature (flag)

• 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.58

TDDI04, K. Arvidsson, IDA, Linköpings universitet.

Example: VxWorks 5.x

§ Popular RTOS supporting hard real-time systems

• 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)
• Scheduling: Preemptive round-robin and FCFS

Priority-Driven Scheduling with 256 priority levels

• Bounded interrupt and dispatch latency
• IPC: shared memory and message passing;

> Semaphores and mutex locks – with priority inheritance protocol > pipes (file-buffered message passing)

>$'?@