Week 10 RTOS Real Time Operating Systems v1.2

CENG
CENG--336
336
Introduction
Introduction to
to Embedded
Embedded
Systems
Systems Development
Development
Introduction to
RTOS – Real-time Operating Systems
Based on Lecture Notes by Tuna Tuğcu
Three Central Concepts
 Concurrency – several concurrent
threads of execution
 Reactivity – external input is reacted to
rather than requested
 Real time – timing behavior of reactions
is important
CENG-336 Introduction to Embedded Systems Development 2

Concurrency
 Real world is concurrent, so is real-time
computing
 Several computers running in parallel is a
concurrent system
 For cost effectiveness, we should map many
tasks onto fewer processors (resource
sharing)
 For independent tasks, concurrency is trivial.
 We are interested in tasks that are cooperating

Reactivity
 Who is the active party below? Who calls who?
 the user demanding a result by clicking on the screen
 the program requesting the next mouse click by means of an
OS call
 The active view: the environment (user) acts because
the program demands it (traditional programming)
 The reactive view: the program acts because the
environment (”user”) demands it (embedded systems)
 Nowhere is the clash between these views more
apparent than in the handling of interrupts
 We will study this problem, as well as reactive
programming in general

Real Time
 Someone asks about the current outdoor
temperature. Which response is better?
 A correct reading of 20°C delivered 12 hours later
 A false reading of 10°C delivered immediately
 In a real time system, a “late” response is just
as bad as a wrong one
 In this chapter, we will introduce methods
and models for controlling the timing behavior
of programs, in addition to their functionality

Some
Horror Stories

Goals
 To give some examples of real real-
time systems that have actually been
produced
 To illustrate various ways that the
concept of time may affect system
design
 To warn about the consequences of bad
real time system design!
 To motivate programmers to do better!
Apollo 11 Lunar Landing
 Basic facts:
 First manned lunar landing (July 20, 1969)
 A small 2-person spacecraft descended to the
lunar surface, while mothership stayed in lunar
orbit
 Both spacecrafts equipped with a computer for
navigation and guidance (notice the time & space):
 100 kHz 16-bit CPU
 38K RAM & core memory
 programmed in assembly language
 priority-based event-driven OS of 2K

Apollo 11 Lunar Landing (cont’d)
 During the landing phase, the role of the lunar
lander computer was to measure altitude and
control the overall attitude of the spacecraft
 In the middle of descent, with only minutes to
go before landing, the computer started to
display “1202 alarm”
 This alarm kept repeating itself every 10 seconds
 As the minimum altitude for aborting was
approaching, the software engineers had to
decide whether the alarm was fatal or not
 The advice was to ignore the alarm, and the
landing also proceeded successfully

 Problem: Computer too slow to handle all
tasks concurrently

 Solution: During descent

 Solution: During ascent

 Cause of the alarms
Descent
consequence #1: event buffer overflow every 10s

consequence #2: about 20% of the CPU cycles spent in
the rendezvous radar interrupt
handler

 The engineers knew “1202 alarm” meant overflow of
some event buffer, not clear which one
 However, because of the fixed priorities used,
judgment was that whatever events and computations
being lost, they would be the least important ones
 The decision to ignore the alarms was taken on basis
of that “gut feeling” (instinctive feeling about a given
situation) rather than knowledge
 Analysis and simulations during the 24h moon stay
found the exact alarm cause (the erroneous switch)
 (The engineer in charge of the decision to proceed
was later awarded the President’s Medal together
with the astronauts!)
Therac-25
 The Therac-25 was a computer that
controlled therapeutic radiation machine for
the treatment of tumors
 Deployed in the mid 80’s, it was a modernized
successor to a highly successful, but slow and
bulky machine: the “Therac-20”
 Massive radiation overdoses generated by the
machine resulted in deaths or severe injuries
for at least six people in the USA and Canada
(1985-1987)
 The machine was redesigned in 1987 as the
result of multiple federal investigations

Therac-25 (cont’d)

 DEC PDP-11 responsible for
 Scanning operator input
 Positioning the turntable with the tungsten shield
 Setting up the electron gun, bending magnets, and
various other devices
 Performing treatment timing
 Executing extensive safety checks
 Controlled via an ASCII-based terminal in a
remote room, using cursor keys for moving
between input fields


 Accident cause:
 The operator erroneously enters X-ray mode, realizes
the mistake, and switches back to electron mode – all
within 8 seconds
 During that time window, the treatment phase task is
ignoring the keyboard entry flag because it is delaying
in a busy-wait loop while bending magnets are being set
up
 Thus, the new mode is never copied over to the variable
read by the gun emission control task
 The other tasks register the edit, though, so the
turntable is moved and the screen updated accordingly
 This results in the patient being exposed to unshielded,
high energy radiation, with no indication to the
operator

 The Therac-25 software was written in
assembly language by a single person, who also
wrote the context-switching “kernel”
 Few people seem to have had any clear idea of
how the software really worked
 Safety analyses for the machine never took
timing errors into account
 It turned out that the Therac-20 also
contained the same bugs, but the hardware
sensors and fuses were used as an extra
safety net against high radiation

Mars Pathfinder
 Unmanned spacecraft that landed on Mars in 1997
 Famous for its high-resolution panoramic pictures of
the Mars surface
 Also famous for utilizing balloons in a “bouncing”
landing procedure, and for deploying a surface vehicle
on wheels
 Not so well-known: Severe computer problems on the
Pathfinder that resulted in frequent system resets
and loss of data
 The cause: A classical example of priority inversion

Mars Pathfinder (cont’d)


 The Pathfinder software ran under the VxWorks
RTOS
 VxWorks can be run with a tracing option, which
records every activity within in the kernel
 During simulations on an exact replica of the
Pathfinder, engineers were able to reproduce the
resets, and the problem was identified
 Fortunately, a C interpreter had been left in the
Pathfinder’s version of VxWorks, and a fix could be
uploaded that turned on priority inheritance for the
info bus mutex
 The mutex in question was actually hidden within a
higher-level synchronization construct, that didn’t
offer any priority inheritance option!

Ariene-5 Blow-up
 Launch of Ariane-5 took place in French
Guyana (June 4, 1996)
 The rocket contained a fairly sophisticated,
fault tolerant computer system, with
software written in Ada
 About 40 seconds after take-off, the rocket
self-destructed at an altitude of
approximately 4000 meters
 Telemetry data, and memory readouts from
computer units recovered from the debris
enabled identification of the cause of events
at a high level of detail

Ariene-5 Blow-up (cont’d)

 The rocket started to disintegrate at 39s after
liftoff, which caused automatic self-destruction
 Disintegration was the result of an angle-of-attack of
more than 20°, which in turn was caused by full
nozzle deflections on all engines
 Nozzle deflections were commanded by the OBC
software on basis of data transmitted by SRI2
 SRI2 was actually not transmitting inertial data, but
bit-patterns corresponding to debug information
 SRI2 had aborted because of an unhandled floating-
point exception, and so had SRI1 one cycle earlier

 The FP exception was due to an error fitting a 64-bit
floating-point value into a 16-bit integer
 Exception handling for this conversion had been
turned off in order to squeeze CPU utilization below
80% (as dictated by RM analysis)
 The unexpected value occurred in a task used for
guiding the rocket while still at the launch pad
 This task was left running for 40s after lift-off, due
to extra time allocated in case of short pauses during
countdown (to avoid realigning the gyros)
 The analysis that outruled exceptional values for the
variable after lift-off was most likely based on
trajectory data for Ariane-4!

Conclusions
 If something can go wrong in a real-time concurrent
system, it will eventually go wrong
 Because of the time dimension, the argument “It
works now” has little value for a real-time system
 Correctness of a real-time system should ideally be
established by some form of software verification,
with clearly stated assumptions
 The problem is “This is easier said than done” with
current technology
 Extensive testing can find many errors, but never give full
correctness guarantees
 We, as programmers, can help by choosing program
structures that are clearly correct by construction
CENG
CENG--336
336
Introduction
Introduction to
to Embedded
Embedded
Systems
Systems Development
Development
RTOS – Realtime Operating Systems
What’s an Operating System?
 Properties of a generic OS:
 Provides environment for executing
programs
 Process abstraction for multitasking /
concurrency
 Scheduling
 Hardware abstraction layer (device
drivers)
 Filesystems
 Communication

Do I Need One?
 Not always (e.g., if you wish to control the
processor behaviour with your own code; like
in PIC)
 Simplest approach: “cyclic executive”
loop
do part of task 1
do part of task 2
do part of task 3
...
end loop

Cyclic Executive (CE)
 Advantages
 Simple implementation
 Low overhead
 Very predictable
 Disadvantages
 Can’t handle sporadic events
 Everything must operate in lockstep
 Code must be scheduled manually

Managing Real Time tasks -
Foreground/Background
 The background is a single loop which executes forever, calling subroutines to do
application-specific jobs.
 The foreground consists of interrupt service routines (ISRs) called by asynchronous
events such as a clock tick or the arrival of a byte at a communications port.
 The processor pauses executing the background loop in order to service an interrupt.
 Interrupts may be prioritised, so that an ISR may itself be interrupted so that a more
important event may be serviced.
Background
ISR ISR
Foreground
ISR
(more
important)

Managing Real Time tasks ...
 OK for simple real time systems
 ISR processes briefly then returns. Typically just gets data from
interrupting device and defers it for “substantial” processing to a task in
the background loop.
 Memory only as required by application(s).
 Minimal interrupt latency (time taken to break off from “current” task
and service an interrupt).
 All tasks have same priority and are executed in sequence in the
backgound loop
 eg (with reference to the diagram above):
= check input = monitor status

from device 1 of device 2
= do a = do output
computation to device 2

Cyclic Executive + Interrupts
 Works fine for many signal processing
applications
 56001 has direct hardware support for this
style
 Insanely cheap, predictable interrupt handler:
 When interrupt occurs, execute a single user-
specified instruction
 This typically copies peripheral data into a circular
buffer
 No context switch, no environment save, no delay

Drawbacks of CE +
Interrupts
 Main loop still running in lockstep
 Programmer responsible for scheduling
 Scheduling static
 Sporadic events handled slowly

Managing Real Time tasks ...
 Application software must implement services such
as
 Timeouts,
 time delays,
 messaging, communication between tasks
 resource management
 Typically, application software is in background
while communications, timer management, etc. are
in foreground.
 Code is hard to maintain as the application(s)
develops/grows
 A better approach in general is to use a multi-
tasking operating system kernel.

Managing Real-Time tasks ...
 The kernel manages CPU time and other
system resources required by various
application tasks
 We are interested in multitasking kernels
 The “application software” consists of a number of
tasks which can run concurrently.
 The tasks may have different priorities.
 Each task is (in general) triggered by an event in
the environment of the software.
 A Kernel can be preemptive or non-
preemptive... (explained later)

Why an Embedded OS?
 Demanding applications need access to
system resources for a variety of
some “strict” requirements:
 Criticalapplications with high
functionality (flight control, medical
applications..)
 Critical
applications with low functionality
(pace maker, Atomatic Brake System)
 Non-critical & technology-rich applications
(telephones, smart card..)

Why not use another GP OS?
 Kernel is typically feature rich (many
unused functions)
 Not (modular, fault tolerant, fast,
configurable, predictable,…)
 Takes big space (memory)
 Not power optimized
 Not designed for mission critical
applications (scheduling).
Cooperative Multitasking
 A cheap alternative
 Non-preemptive
 Processes responsible for relinquishing control
 Examples: Original Windows, Macintosh
 A process had to periodically call get_next_event()
to let other processes proceed
 Drawbacks:
 Programmer had to ensure this was called frequently
 An errant program would lock up the whole system
 Alternative: preemptive multitasking

Concurrency Provided by OS
 Basic philosophy:
 Let the operating system handle
scheduling, and let the programmer handle
function
 Scheduling and function usually
orthogonal
 Changing the algorithm would require a
change in scheduling
 First, a little history
Batch Operating Systems
 Original computers ran in batch mode:
 Submit job & its input
 Job runs to completion
 Collect output
 Submit next job
 Processor cycles very expensive at that time
 Jobs involved reading, writing data to/from
tapes
 Cycles were being spent waiting for the tape!

Timesharing Operating
Systems
 Solution
 Store multiple batch jobs in memory at once
 When one is waiting for the tape, run the other
one
 Basic idea of timesharing systems
 Fairness is the primary goal of timesharing
schedulers
 Let no one process consume all the resources
 Make sure every process gets “equal” running time

Why Operating Systems?
 The “first” computers had none
 Application software loaded into the RAM and ran on the
hardware
 Embedded software was like this until surprisingly recently
 Not an efficient way to manage a desktop PC!
 Key presses, mouse events happen from time to time and have
to be handled
 A byte may arrive at the serial port and have to be saved
(MSN, GTalk, etc.)
 In general, a computer has many tasks on the go at
once
 One or more (many) applications
 “house-keeping” – managing memory, disk drives, network
interfaces, input & output devices

Why OSs? ...
 What is needed (at the very least) –
 A scheduler managing several applications running at once
 Each application may get a few milliseconds of processing in turn
 At the and of a tasks turn with the CPU then
– it’s state (the values of the CPU registers, …) is saved
– the CPU registers are loaded with the next task’s state
– the next task gets a few milli-seconds processing
 We get the appearance/illusion of several tasks running at once
 An interrupt mechanism
 whereby an event in the environment (a key press, a byte arriving
at the serial port …) causes the CPU to interrupt processing the
current task, and need arises to service the interrupt, before
resuming the task.
 An alternative might be to include in the schedule a task to poll
all the peripherals but this would be much less efficient. Why?

Interrupts
 Some events can’t wait for next loop
iteration
 Communication channels
 Transient events
 A solution: Cyclic executive plus
interrupt routines
 Interrupt: environmental event that
demands attention
 Example: “byte arrived” interrupt on serial channel
 Interrupt routine: piece of code
executed in response to an interrupt
Handling an Interrupt
1. Normal
program
execution
2. Interrupt 3. Processor
occurs state saved
4. Interrupt routine
runs
6. Processor state
restored 5. Interrupt routine
terminates
7. Normal
program
execution
resumes

Interrupt Service Routines
 Most interrupt routines:
 Copy peripheral data into a buffer
 Indicate to other code that data has arrived
 Acknowledge the interrupt (signal the
hardware)
 Longer reaction to interrupt performed
outside interrupt routine
 E.g., causes a process to start or resume
running

Why OSs? ...
 Also handy; provides
 Means of running tasks sending each other messages
 Means of arbitrating fair sharing of system
resources between tasks
 Means of enforcing mutual exclusion where
necessary
 These are all services provided by a modern
operating system kernel
 So called to distinguish it from the command shell,
 a task which manages user input and output to/from the
system
 In case of PCs, via a graphical “desktop”

Non-Preemptive Kernels
Low priority task
ISR
High priority task
 When a task relinquishes the CPU, the highest priority task in the list of tasks
waiting for the CPU executes
 But lower-priority task cannot lose the CPU to a higher-priority task until it is
done., The higher priority task waits for the other to relinquish the CPU
 The lower priority task can still be interrupted by an ISR; but it resumes
processing after the ISR returns, and the higher priority task still only gets the
CPU when the lower priority task has relinquished it.
 A non-preemptive kernel can suffer from “priority inversion” problems, where a
low-priority task can take a long time and lock out a more important higher
priority task.

Preemptive Kernels
Low priority task
ISR
High priority task
 In this case, a higher priority task can grab the CPU off the lower
priority task as soon as it becomes ready to execute, before the
lower priority task relinquishes it. The lower-priority task waits
(among other tasks of equal priority) to resume.
 If the higher priority task becomes ready to run while an ISR
(which interrupted the lower priority task) is executing, it gets
the CPU on return from the ISR, and the lower priority task must
wait for the higher one to relinquish the CPU before it can
resume.

Tasks
 Each task thinks it has the CPU to itself
 Each task has its own stack space
 Each task has a priority
 A task may well take the form of
 a sequence of initialisation code; followed by
 a loop which iterates forever (or until a flag is set to exit
it)
 Body of loop will contain application code
 A task calls functions which are preferably
reentrant:
 Can be safely called by more than one function at a time
 Interrupting them does not corrupt their data
 Typically implemented using local variables
 Reusable and reentrant Code
Tasks ...
 A task passes through several states in its
“life cycle”:
 When “born” it resides in memory
 “starting” tells the kernel its start address, address of
stack top, priority; the kernel may pass run-time
arguments to the task
 Once “ready”, it joins the prioritised queue of tasks
waiting for CPU cycles.
 Under control of the kernel it will context-switch
between the “running” state where it is receiving
processing cycles and the “ready” state.

Tasks ...
born (dormant) waiting/blocked
event, timeout wait, i/o request, etc.

start
interrupted
ISR
task
ready running completion
context switch
dead

Tasks ...
 Task states & “life cycle”:
 When running it may be forced to wait for
 a resource,
 a mutex
 another task to reach a certain stage (precedence)
 I/O (“blocked”)
 a time delay to expire, etc.
 Once the relevant event has occurred, the
resource is available, a timeout has expired, etc.,
the task returns to the “ready” state.
 The running task may be interrupted by an ISR (as
seen in previous slides, return may be followed
immediately by a context switch.)
Scheduling & Context Switching
 The scheduling task repeatedly decides
whether there is a higher-priority task to run.
 This happens when ...
 a task has to wait for a time expiry or i/o or a mutex lock,
etc
 a task sends a signal or message to another task
 an ISR sends a signal or message to a task (but after all
nested ISR calls have returned).
 The result is either
 a context switch -- if a higher-priority task has become
ready to run; or
 a return to the task interrupted by the scheduling task,
otherwise

Scheduling & Context Switching
 The context is the “dynamic state” of a task.
It includes
 current values in CPU register, floating point
register, memory management registers, etc.
 pointer to “current” TCB (Task Control Block)
and/or Task-Id
 The switch causes these registers to be
saved on the “old” task’s stack, and to be
loaded from the “new” task’s stack.

Tasks and Threads
 A “multithreaded” program is one that is made up of
concurrent tasks in a similar way to this.
 A thread is like a task, but part of a larger software
entity, a program
 A “heavyweight” thread may have its own stack space,
like a task, and some existence independent of its
parent program.
 A “lightweight” thread may share stack space and other
software resources with the parent program.
 A daemon is a thread which can carry on running after
the parent has completed. (Normally a program is
deemed to have finished when all its threads have
finished.)

Tasks and Threads ...
 Threads have a life cycle similar to tasks as
above
 In Java, for example, a Thread object has
 A run() method normally programmed with an infinite
loop
 A sleep(int n) method to put the thread into a waiting
state for n milliseconds
 A notify() method to fire an event to “wake up” a
thread in a waiting state
 A yield() method to give up the CPU and return to the
ready state.

Real-Time is “not Fair”
 Main goal of an RTOS scheduler
 meeting deadlines
 If you have five concurrent homework
assignments and only one is due in an hour, you
work on that one. Wouldn’t you?
 Fairness does not help you meet

deadlines!

OS for Embedded Systems
 Configurable (eliminate unused functions)
 Direct control of devices by tasks
(applications) is enabled:
Standard OS : Real Time OS:
Application Application
Middleware Middleware
Operating System Device Drivers
Device Drivers Real Time Kernel
* Kernel is the basic central part of an OS (no user interface etc.)
 Tasks are directly connected to interrupts

RTOS
 An OS that supports the construction
of real time applications:
 Timing must be predictable (upper bound on
execution time for all services)
 All activities are controlled by a scheduler
 Short times for disabled interrupts
 OS must manage timing and scheduling
 Aware of task deadlines
 Provide precision time services (timer mgmt.)
 OS must be fast
RTOS ...
 Mainly an OS (with scheduling and
memory management)
 with “further” care
 Most of the Kernel resources are
opened for access to the application

Typical RTOS Task Model
 Each task
 is represented as a triplet: (execution time,
period, deadline)
 Usually, deadline = period
 Can be initiated any time during the period
Execution Deadline
Initiation time
Time
Period

Real-Time Operating System
(RTOS)
 Most moderate and complex RT systems have RTOS.
 Some functions of RTOS are similar to normal OS:
 Managing interfaces to the low-level hardware.
 Scheduling and preempting tasks.
 Memory management.
 Providing common services: I/O, standard devices (keyboard,
printer)
 Some functions of RTOS differ:
 Scalability.
 Scheduling policies and synchronization methods.
 Support for embedded, diskless target environment.
 RTOS is tailored and optimized for embedded systems.
 RTOS provides the ability to boot from ROM.
 Many RTOS can operate from ROM.

Scalability
 RTOS is structured so that only the needed
components are included in the RTOS image
executing on the target.
 Kernel: the innermost core, provides the most
essential features of the RTOS.
 Other features are added as necessary.
 Scalability makes RTOS widely applicable to small,
single-processor applications and to large,
distributed ones.
 RTOS vendors call this as “microkernel”
architecture, emphasizing the small size of the
minimalist kernel.
Scheduling
 RTOS most commonly provides priority-
based preemption for control of scheduling.
 The higher priority task always preempts the
lower-priority tasks when the former
becomes ready.
 Average performance is a secondary concern
(fairness may be sacrificed also).
 The primary concern is that system meet all
computational deadlines, even in the absolute
worst case.
Priority-based Scheduling
 Typical RTOS based on fixed-priority
preemptive scheduler
 Assign each process a priority
 At any time, scheduler runs highest
priority process ready to run
 Processruns to completion unless
preempted

Priority-based Preemptive
Scheduling
 Always run the highest-priority
runnable process

Priority-Based Preemptive
Scheduling
 Multiple processes at the same priority level?
 A few solutions:
 Simply prohibit
 Each process has unique priority
 Time-slice processes at the same priority

 Extra context-switch overhead
 No starvation dangers at that level
 Processes at the same priority never preempt the

other
 More efficient
 Still meets deadlines if possible

Rate-Monotonic Scheduling
 RMS
 Common way to assign priorities
 Result from Liu & Layland, 1973 (JACM)
 Simple to understand and implement:
 Processes with shorter period given higher
priority
Period Priority
10 1 (highest)
 E.g., 12
15
2
3
20 4 (lowest)
Key RMS Result
 Rate-monotonic scheduling is optimal
 If there is fixed-priority schedule that
meets all deadlines, then RMS will produce
a feasible schedule
 However, task sets do not always have a
schedule
 Simple example:
 (Exec Time, Period, Deadline)
 P1 = (10, 20, 20) / P2 = (5, 9, 9)
 Requires more than 100% processor utilization

RMS Missing a Deadline
 p1 = (10,20,20) p2 = (15,30,30)
 utilization is 100%
Would have met the deadline if

p2 = (10,30,30), utilization
reduced 83%
P2 misses first deadline

When Is There an RMS
Schedule?
 Key metric is processor utilization:
 sum of compute time divided by period for each process:
U=  (ci / pi)
 No schedule can possibly exist if U > 1
 No processor can be running 110% of the time
 Fundamental result:
 RMS schedule always exists if U < n * (2 1/n – 1)
 Proof based on case analysis (P1 finishes before P2)

Schedule?
n Bound for U
1 100% Trivial: one process
2 83% Two process case
3 78%
4 76%
 69% Asymptotic bound

Schedule?
 Asymptotic result:
 If the required processor utilization is
under 69%, RMS will give a valid schedule
 If the required processor utilization is over
69%, RMS might still give a valid schedule,
but there is no guarantee
 Converse is not true.

 Instead: EDF

EDF Scheduling
 Earliest Deadline First (EDF)
 RMS assumes fixed priorities
 Can you do better with dynamically-chosen
priorities?
 Earliest deadline first

 Processes with soonest deadline given
highest priority

EDF Meeting a Deadline
 p1 = (10,20,20) p2 = (15,30,30) utilization is
100%
P2 takes priority because its

deadline is sooner
Key EDF Results
 Earliest deadline first scheduling is
optimal
 If a dynamic priority schedule exists, EDF
will produce a feasible schedule
 Earliest deadline first scheduling is

efficient
A dynamic priority schedule exists if and
only if utilization is no greater than 100%

Priority Inversion
 RMS and EDF assume no process interaction
 Often a gross oversimplification
 Consider the following scenario:
1
Process 1 tries to acquire lock for resource

Process 1 preempts Process 2
Process 2 acquires lock on resource
Process 2 begins running

Priority Inversion
 Lower-priority process effectively
blocks a higher-priority one
 Lower-priority process’s ownership of
lock prevents higher-priority process
from running
 Nasty: makes high-priority process
runtime unpredictable

Nastier Example
 Higher priority process blocked indefinitely
Process 2 delays process 3’s release of lock
Process 1 tries to acquire lock and is blocked

Process 3 acquires lock on resource
Process 3 begins running

Priority Inheritance
 Solution to priority inversion
 Temporarily increase process’s priority when
it acquires a lock
 Level to increase: highest priority of any
process that might want to acquire same lock
 i.e., high enough to prevent it from being
preempted
 Danger: Low-priority process acquires lock,
gets high priority and hogs the processor
 So much for RMS

Priority Inheritance
 Basic rule: low-priority processes should
acquire high-priority locks only briefly
 An example of why concurrent systems
are so hard to analyze
 RMS gives a strong result
 No equivalent result when locks and
priority inheritance is used

Summary
 Cyclic executive
A way to avoid an RTOS
 Adding interrupts helps somewhat
 Interrupt handlers
 Gather data, acknowledge interrupt as
quickly as possible
 Cooperative multitasking
 But programs don’t like to cooperate

Summary
 Preemptive Priority-Based Multitasking
 Deadlines, not fairness, the goal of RTOSes
 Rate-monotonic analysis/scheduling
 Shorter periods get higher priorities
 Guaranteed at 69% utilization, may work higher
 Earliest deadline first scheduling
 Dynamic priority scheme
 Optimal, guaranteed when utilization 100% or less

Summary
 Priority Inversion
 Low-priority process acquires lock, blocks
higher-priority process
 Priorityinheritance temporarily raises
process priority
 Difficult to analyze

Priority Inversion
Task 1 (high)
Task 2 (medium)
Task 3 (low)
1 2 3 4 5 6
 This can happen even in Preemptive kernels. Eg: 3 task with low, medium, high priority:
 Task 3 (low) runs while 1 and 2 wait for some event. At point 1, 3 acquires an exclusive lock on a
resource.
 At point 2, task 1 becomes ready and preempts task 3
 At point 3, task 1 wants the resource but it is still locked by task 3; so task 1 waits and task 3
resumes
 At point 4, task 2 becomes ready and starts running, preempting task 3.
 Task 2 runs until done, point 5 and task 3 resumes, not task 1 because the latter is still waiting for
the resource locked by task 3
 Finally at point 6, task 3 releases the resource and task 1 acquires it and can run.
 Effectively task 1 has been trapped at the level of task 3 until 3 releases the resource.

Priority Inheritance - a
Solution
Task 1 (high)
Task 2 (medium)
Task 3 (low)
1 2 3 4 5 6
 In a kernel that supports priority inheritance,

 As soon as task 1 wants the resource (point 3) locked by task 3, task 3 is temporarily
promoted to task 1’s priority so that it can continue running until it releases the resource
(point 4)
 Then, task 1 becomes ready because it can acquire the resource released by task 3.
 Task 1 releases the resource at point 5, but keeps running also task 2 is ready, because it
has the highest priority
 Finally at point 6, task 1 finishes and task 2 can run. Task 3, with the lowest priority, waits.
 NB Task 2 could have become ready at point 2 or any after thereafter, with no difference
in outcome..

Interrupts
 The kernel can always interrupt the currently running task
 except when kernel or application has disabled interrupts (by means of a
system call)
 In effect, ISRs have “super-high” priority.
 They are prioritised among themselves and the ISR of a high-priority
interrupt can interrupt the ISR of a lower one.
 “Software interrupts” are triggered by software -- usually in other tasks
 “System calls”
 “Hardware interrupts” are raised by, eg, interrupt request ( IRQ) “lines” --
each is a bit in a CPU IRQ register. Setting bit n to 1 notifies the CPU that
Interrupt number n has occurred.
 Each interrupt has a number. (low number -> high priority) which indexes
into the Interrupt Vector Table -- an array of addresses of (pointers to)
ISRs
 ISR must
 tell the kernel it is processing an interrupt
– could be interrupted by a higher priority ISR: Interrupts can be nested)
 tell the kernel is has finished processing an interrupt
– context switch or return to interrupted task

Interrupts -- the steps
 A task is running; there is an interrupt requests
 If kernel has interrupts disabled, nothing happened until interrupts are enabled
 Then (or immediately) the kernel
 saves the task context
 looks up the ISR in the vector table
 The ISR runs
 notifies kernel of ISR entry
 processes -- possible signals another task
 notifies kernel of ISR exit
 If no higher priority task has become ready
 The original interrupted task’s context is restored and the task resumes
 If a higher-priority task has become ready
 The higher priority task’s context is restored and it resumes.
 The time interval from the interrupt request until the ISR starts is the
interrupt response time.
 The time interval from the ISR exit to task resumption is the interrupt
recovery time. (10s of s)

Clock Tick
 A piece hardware generates interrupts at a regular
interval
 10 -- 100 Hz; usually derived from power line frequency
 (Why 18.2 Hz in an 80x86 ?!?!?!?)
 Used to provide delays and timeouts
 The ISR for a clock tick calls a kernel service to
signal a tick. This may well cause a context switch
 A higher priority task may have become ready to run in the interim
 In “round robin” scheduling, tasks of equal priority get a fixed
number of ticks’ CPU time than go to the back of the queue
 The clock interrupt has higher priority than all tasks
(because it is an interrupt) but lower priority than
other interrupts.

Kernel Services
 The kernel provides services to task software
 time delays
 for n ticks
 task is placed in list of delayed tasks where consumes little on no CPU
time.
 This list can also contain timeouts from other services.
 semaphores
 a mechanism for enforcing synchronisation and mutual exclusion
 see below
 message mailboxes and queues
 see below
 event flags
 pipes
 memory management
 a real-time clock
 change of task priority
 deletion of a task
 etc

Semaphores
 Invented by Edsger Dijkstra
 A simple mechanism for mutual exclusion and condition
synchronisation
 Simple synchronisaton protocols
 No need for busy-wait loops
 A semaphore is a nonnegative integer variable only modifiable
(apart from initialisation) by two procedures wait and signal.
 Dijkstra called these P and V
 Let s denote the semaphore variable,
wait(s) { signal(s) {
if (s > 0) increment s by 1;
decrement s by 1; }
else {
wait until s > 0
decrement s by 1;
}
}
Semaphores for Sync.
 Using a semaphore to synchronise a tasks on a condition
 task1 needs condition = true to proceed; task 2 is signalling process
(see below)
 Assume semaphore variable consyn initialised to 0
 When task 1 executes wait on a 0 semaphore, it will be delayed until
task 2 executes the signal. This sets consyn to 1 and the wait can
succeed. Task 1 can continue and consyn will be decrmeneted to 0
 If task 2 executes signal first, consyn will = 1 and the wait() will will not
delay task1.
 Task 1 could be a task requiring an exclusive lock on a resource; task 2
could signal on releasing the resource.
task1 { task2 {
.... ...
wait(consyn); signal(consyn);
.... ....
} }

Semaphores for Mutual
Exclusion
 Using a semaphore for mutual exclusion
 Assume semaphore variable mutex set initially to 1.
 If the two tasks arer in contention they may execute their wait()
statements simultaneously;
 but wait is atomic. One task will complete wait() before the other begins;
 So one will execute wait with mutex = 1 and so proceed to its critical
section and set mutex to 0. The other will wait(mutex) with mutex = 0 and
have to wait for the other task to signal(mutex) which it will do on leaving
its critical section.
 More generally initially setting mutex to n will allow n simultaneous
accesses to critical section
task1 { task2 {
while (...) { while (...) {
wait(mutex); wait(mutex);
/*critical section*/ /*critical section*/
signal(mutex); signal(mutex);
/*non-critical sect*/ /*non-critical sect*/
} }
} }
Message Queues & Events
 We would like tasks to be able to communicate
asynchronously
 Tasks to send and receive messages
 ISRs to send messages
 Discipline normally FIFO
 Events
 Tasks can be synchronised with occurrence of multiple
events
 Occurrence of an event will signal a list of tasks; the
highest-priority task of these will me made ready to
run.

References
 Alan Burns & Andy Wellings, Real Time Systems &
Programming Languages: Addison-Wesley
 Has a good section of semaphores -- section 8.4 (p233 ff)
 J J Labrosse, MicroC/OS-II: The Real Time Kernel:

CMP Books
 Much of this material is based on this book
 See also Labross’s papers
 Inside Real-Time Kernels
 Designing with Real-Time Kernels
 (Look with Google)

Fly-by-wire Avionics
 Hard real-time system with multirate behavior
Signal Control laws Actuating Actuators

Sensors
Conditioning
Aileron 1
gyros, INU Aileron
Pitch control 1 kHz
accel. 1kHz
500 Hz
GPS Aileron 2
Aileron
GPS 20 Hz 1 kHz
Lateral Control
250 Hz
Air data Elevator
Sensor Elevator
1 kHz 1 kHz
Throttle Control
Joystick Rudder
Stick 250 Hz Rudder
500 Hz 1 kHz

Static Scheduling More
Prevalent
 RMA only guarantees feasibility at 69%
utilization, EDF guarantees it at 100%
 EDF is complicated enough to have
unacceptable overhead
 More complicated than RMA: harder to
analyze
 Less predictable: can’t guarantee which
process runs when

Week 10 RTOS Real Time Operating Systems v1.2

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Week 10 RTOS Real Time Operating Systems v1.2

Enviado por

Direitos autorais:

Formatos disponíveis

CENG

CENG-336 Introduction to Embedded Systems Development 2

CENG-336 Introduction to Embedded Systems Development 3

CENG-336 Introduction to Embedded Systems Development 4

CENG-336 Introduction to Embedded Systems Development 5

CENG-336 Introduction to Embedded Systems Development 6

CENG-336 Introduction to Embedded Systems Development 8

CENG-336 Introduction to Embedded Systems Development 9

CENG-336 Introduction to Embedded Systems Development 10

CENG-336 Introduction to Embedded Systems Development 11

CENG-336 Introduction to Embedded Systems Development 12

consequence #1: event buffer overflow every 10s

CENG-336 Introduction to Embedded Systems Development 13

CENG-336 Introduction to Embedded Systems Development 15

CENG-336 Introduction to Embedded Systems Development 16

CENG-336 Introduction to Embedded Systems Development 17

CENG-336 Introduction to Embedded Systems Development 18

CENG-336 Introduction to Embedded Systems Development 19

CENG-336 Introduction to Embedded Systems Development 20

CENG-336 Introduction to Embedded Systems Development 21

CENG-336 Introduction to Embedded Systems Development 22

CENG-336 Introduction to Embedded Systems Development 23

CENG-336 Introduction to Embedded Systems Development 24

CENG-336 Introduction to Embedded Systems Development 25

CENG-336 Introduction to Embedded Systems Development 26

CENG-336 Introduction to Embedded Systems Development 27

CENG-336 Introduction to Embedded Systems Development 28

CENG-336 Introduction to Embedded Systems Development 31

CENG-336 Introduction to Embedded Systems Development 32

CENG-336 Introduction to Embedded Systems Development 33

CENG-336 Introduction to Embedded Systems Development 34

= check input = monitor status

CENG-336 Introduction to Embedded Systems Development 35

CENG-336 Introduction to Embedded Systems Development 36

CENG-336 Introduction to Embedded Systems Development 37

CENG-336 Introduction to Embedded Systems Development 38

CENG-336 Introduction to Embedded Systems Development 39

CENG-336 Introduction to Embedded Systems Development 40

 Alternative: preemptive multitasking

CENG-336 Introduction to Embedded Systems Development 42

CENG-336 Introduction to Embedded Systems Development 44

CENG-336 Introduction to Embedded Systems Development 45

CENG-336 Introduction to Embedded Systems Development 46

CENG-336 Introduction to Embedded Systems Development 47

CENG-336 Introduction to Embedded Systems Development 49

CENG-336 Introduction to Embedded Systems Development 50

CENG-336 Introduction to Embedded Systems Development 51

High priority task

CENG-336 Introduction to Embedded Systems Development 52

High priority task

CENG-336 Introduction to Embedded Systems Development 53

CENG-336 Introduction to Embedded Systems Development 55

event, timeout wait, i/o request, etc.

CENG-336 Introduction to Embedded Systems Development 56

CENG-336 Introduction to Embedded Systems Development 58

CENG-336 Introduction to Embedded Systems Development 59

CENG-336 Introduction to Embedded Systems Development 60

CENG-336 Introduction to Embedded Systems Development 61

 Fairness does not help you meet

CENG-336 Introduction to Embedded Systems Development 62

* Kernel is the basic central part of an OS (no user interface etc.)

 Tasks are directly connected to interrupts

CENG-336 Introduction to Embedded Systems Development 65

CENG-336 Introduction to Embedded Systems Development 66