Real-time operating systems
TDDB47 Real Time Systems
•
Lecture 7: Real-time operating systems and
low level programming
"The principal function of operating systems are to manage
the hardware and software resources of the computer and to
provide services to users." [Bick&Shaw88]
•
Two alternatives
– Runtime support of a programming language (e.g. in
smaller embedded systems)
Calin Curescu
– Standalone real-time OS
Real-Time Systems Laboratory
Department of Computer and Information Science
Linköping University, Sweden
– Where is the Java VM situated?
The lecture notes are partly based on lecture notes by Simin Nadjm-Tehrani, Jörgen Hansson, Anders Törne.
They also loosely follow Burns’ and Welling book “Real-Time Systems and Programming Languages”. These
lecture notes should only be used for internal teaching purposes at Linköping University.
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
35 pages
•
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
Predictability
•
Deterministic behaviour of OS services and functions
•
Property applies most critically with respect to time
– Within known bounds
– At known times
•
3 of 35
•
In conventional OS
– Most stuff hidden deliberately
• High level abstractions
• Transparency
•
In real-time systems
– Access and control of mechanisms needed to guarantee
predictability
•
Trick – provide useful and convenient abstractions for the
user while
– Offer detailed configurability
– Give a detailed timeliness specification of components
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
Open system
•
Define and provide the right abstractions, but
•
Do not enforce particular solutions
2 of 35
Visibility and control
Fault detection and management
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
Performs many of the general functions and services of
normal OS + special requirements such as …
4 of 35
Real-time functions and services
•
•
•
•
•
Functions for time access & control
Process and thread management
Interrupt and event handling
Device management
Memory management
– E.g. possible to define different task scheduling policies
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
5 of 35
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
6 of 35
Functions for time access & control
•
Both absolute and relative time
•
Different levels of granularity
•
Operations for
– Reading and setting clocks
– Delaying for a given time
– Programming timeouts
• Recognise and deal with the non-occurrence of some event
•
Clocks should maintain the basic properties of time
•
Thus, clock-related ops:
– highest priority
– not interruptible
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
7 of 35
Basic properties of time
•
Correctness
•
Bounded drift
•
Monotonicity
• Increasing in value all the time
•
Chronoscopicity
• At any time it should be possible to measure a time
interval reasonably accurately (sudden large changes do
not occur)
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
8 of 35
Access to a Clock
•
•
Delays
By having direct access to the environment's time frame
– Environment supplies a regular interrupt
• e.g. GPS also provides a UTC service
By using an internal hardware clock that gives an adequate
approximation to the passage of time in the environment
Time specified by
program
Granularity
difference
between
clock and
delay
Process runnable
here but not
executable
Process
executing
Interrupts
disabled
•
From programmer’s perspective, access
– Via a device driver
– Clock primitive in the language
Time
•
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
9 of 35
Local drift & cumulative drift
• Cumulative drift can be eliminated
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
Absolute vs. relative delays
•
•
•
Relative delay
– By busy waiting
• Wasting CPU time
– By language constructs
• Usually underlying interrupt
• Interrupt can be masked
• Guarantees only a “runnable” state after delay
Absolute delay
Both absolute & relative need language constructs
– Atomicity problem
START := Clock;
– Problematic example:
10 of 35
Programming timeouts
•
Shared variable communications
– Mutexes usually bounded & accounted
– Condition synchronisation however needs timeouts
•
Message-passing
– Synchronous case
– Asynchronous case
•
Timeouts on actions
– Usually associated with timing error
FIRST_ACTION;
delay 10.0 - (Clock - START);
SECOND_ACTION
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
11 of 35
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
12 of 35
Process and thread management
•
•
•
•
•
Create, initialise , activate, terminate RT-tasks
– Static or dynamic creation
• Thread pools – static
• Fork – usually dynamic
Maybe direct support for periodic and sporadic processes
Scheduling facilities should be accessible for
– deciding when scheduler is called
– what policy is used
Availability of preemptive versions of
– Scheduling
– Synchronisation
Priority inheritance policies
– E.g. ceiling protocol
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
Scheduling examples
•
Mars
– Feasible schedule of taskset with well defined timing and
precedenc constraints is developed “off-line”
– Stored in a table
– A table-driven dispatcher used at run-time
Spring
– Critical tasks scheduled statically and guaranteed apriori
– Handles also non-critical tasks that my arrive dynamically
• Attempts to build a new schedule dynamically
• If new schedule is feasible, task guaranteed to meet constr.
Rialto
– Guaranteed allocation of x time units every y time units
•
•
13 of 35
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
Synchronisation & communications
•
Atomic actions
•
Timeouts
•
Messages
– Event messages
• Synchronous, asynchronous
– State messages
• Non - blocking
• Sensors, overwriting old states, asynchronous
– Timestamping
• Causality, age
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
15 of 35
Temporal scopes attributes
•
Deadline — the time by which the execution of a TS must be
finished;
•
Minimum delay — the minimum amount of time that must
elapse before the start of execution of a TS;
•
Maximum delay — the maximum amount of time that can
elapse before the start of execution of a TS;
•
Maximum execution time — of a TS;
•
Maximum elapse time — of a TS.
•
Temporal scopes with combinations of these attributes are
also possible
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
Temporal Scopes
•
•
Can be
– Periodic
– Sporadic
– Aperiodic
16 of 35
Deadline
•
The deadline can itself be expressed in terms of either
– Absolute time
Deadlines can be:
– Hard
– Soft
– Interactive — performance issue
– Firm
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
14 of 35
– Execution time since the start of the temporal scope, or
– Elapsed time since the start of the temporal scope.
17 of 35
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
18 of 35
Fault Tolerance of timing failures
•
It is necessary to be able to detect:
– overrun of deadline
– overrun of worst-case execution time
– sporadic events occurring more often than predicted
– timeout on communications
•
The last three failures in this list do not necessary indicate
that deadlines will be missed
– an overrun of WCET in one process might be
compensated by a sporadic event occurring less often
than the maximum allowed
•
Deadline overrun & FER
Asynchronous notification
– Event handling, behaves like an interrupt
– Similar to exception handling
• Difference: event usually NOT signaled by affected process
•
Termination model
– It assumes that the recovery strategy requires the task to
stop what it is doing
– Asynchronous transfer of control (ATC)
Resumption model
– E.g. allowing the task to continue its execution at a
different priority
A similar approach can be used to detect a deadline overrun in
a sporadic task
•
•
Both forward and backward error recovery is possible
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
•
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
19 of 35
Overrun of WCET
•
•
•
The consequences of an error should be restricted to a welldefined region of the program
– It should be possible to catch the timing error in the
process that caused it
A process that consumes more of the CPU resource than
has been anticipated
– May miss its deadline
– May cause a lower priority process with less slack
available to miss its deadline
The same mechanisms that were used to detect deadline
overrun can be used
– If elapsed time is equal to executed time
– I.e. a process is non preemptively scheduled & does not
block waiting for resources
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
Overrun of Sporadic Events
•
A sporadic event firing more frequently than anticipated has an
enormous consequence for a system with hard deadlines
•
It is necessary either to ensure that this is prohibited or to detect it
when it occurs and take some corrective action
•
There are essentially two approaches to prohibiting sporadic event
overrun
– If the event comes from a hardware interrupt, the interrupt can
be inhibited from occurring by manipulating the associated
device control registers.
– To use sporadic server technology (see later)
•
Most real-time languages and operating systems are woefully
lacking in support for detecting too frequent occurrence
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
21 of 35
Interrupt and event handling
•
•
Sequence
1. State of current task P is saved, interrupt identified, interrupt
handler called
2. Handler (I.e. interrupt service routine) is executed
– Most of the time – non-preemptive
Source
– Hardware – signals external event – e.g. timer
– Software – generated by an instruction a mechanism for
access to shared system routines – e.g. system calls
•
•
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
22 of 35
Interrupts
•
Employed for
– Scheduling
– Asynchronous notification
– Exception handling
20 of 35
23 of 35
3. P state is reloaded and continues from where it was
interrupted, or
4. Interrupt has awakened a previously blocked task P’, and
control is transferred to P’
Interrupt priorities (or levels)
• Highest priority selected first, others executed after or lost
ISR times measured and publicised
• Timer interrupt must be very efficient, depends also on
granularity
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
24 of 35
Device management
•
Normally not accessible in usual OS
•
Needed here for predictability
•
For interaction with sensors, controllers, timers, other IO
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
Device Interface
•
The interface to a device is normally through a set of registers
•
Separate buses:
– two sets of assembly instructions — one for memory access the
other for device register access
– e.g., the Intel 486 and Pentium range
Memory-mapped I/O:
– certain addresses access memory others the device registers –
e.g., M68000 and PowerPC ranges
•
•
The interface is used to control the device’s operations and to
control the data transfer
•
Two control mechanisms: status driven and interrupt driven
control
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
25 of 35
Memory mapped vs. IO operations
26 of 35
Status Driven
Data
Data
•
Memory
CPU
Devices
•
Devices
Address
Address
Data
•
CPU
Memory
Devices
Devices
•
A program performs explicit tests in order to determine the
status of a given device
Then it can use three kinds of hardware instructions:
– test operations to determine the status of the given device
– control operations that direct the device to perform nontransfer device dependent actions
• such as positioning read heads
– I/O operations that perform the actual transfer of data
between the device and the CPU
Nowadays most devices are interrupt driven.
– Interrupts can of course be turned off and polling of device
status used instead.
Interrupts are often no allowed in Safety Critical Systems
Address
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
27 of 35
Interrupt Driven
Elements for interrupt controlled devices
•
•
•
•
Interrupt-driven program-controlled
Interrupt-driven program-initiated (DMA)
Interrupt-driven channel-program controlled
• DMA and channel programs can cause cycle stealing from
the processor; this may make it difficult to estimate the
worst-case execution time of a process
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
•
•
•
29 of 35
28 of 35
Context switching mechanisms
– Preserving the state,processing interrupt, restoring state
– Saving State: PC, registers, program status info, priority, memory
protection etc.
• Basic: just the PC is saved;
• Partial: PC and the PSW are saved;
• Complete: full context is saved.
Interrupting device identification
Interrupt identification
Interrupt control, enabling/disabling of interrupts may be performed by:
– Status mechanisms – provide flags to enable/disable interrupts.
– Mask interrupt – particular locations in an interrupt mask word
– Level-interrupt – the current level of the processor determines
which devices may or may not interrupt
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
30 of 35
Abstract Models
•
•
•
•
Memory Management
All models require facilities for addressing and manipulating
device registers
– A device register may be represented as a program variable,
an object, or even a communications channel
A suitable representation of an interrupt:
– procedure call
– sporadic process invocation
– asynchronous notification
– shared-memory based condition synchronisation
– message-based synchronisation
All except the procedure, view the handler as executing in
the scope of a process, and therefore require a full context
switch
Different models in different languages or OS
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
•
Embedded RTS often have a limited amount of memory
– This is due to: cost, or size, power or weight constraints
•
Fine grained memory control should e possible
– So that it can be used effectively
– Memory allocation restricted to parts of real memory
– Allocation often statically and permanent
•
The more general issue is of storage management of the
– Heap
– Stack
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
31 of 35
Heap management
•
For use with allocators (the new operator)
•
Key problems:
– how much space is required (requires application
knowledge)
– when can allocated space be released
•
Returning allocated space
– require the programmer to do it (malloc, free, sizeof in C)
• error prone
– requires the run-time to monitor memory and determine
when it logically can no longer be accessed
• scoped memory
– requires the run-time to monitor memory and release it when
it it is no longer being used - garbage collection in Java
• Significant impact on response-time
• Not trusted for RT-systems yet
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
33 of 35
Reading
•
•
Chapter 10 of book by Shaw
Chapter 15.1 in Burns & Wellings
– Particularities of Ada/Java etc. not interesting
•
•
Extra Reading
Chapter 12 of Jane Liu’s book on Real-time Systems,
Prentice Hall 2000
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
35 of 35
32 of 35
Stack Management
•
Important for embedded systems
•
Specifying the stack size of a task/thread requires trivial support
•
Calculating the stack size is more difficult
– Tasks enter blocks and execute procedures their stacks grow
– Requires knowledge of the execution behaviour of each task
– This knowledge is similar to that required to undertake WCET
analysis
•
WCET and worst-case stack usage bounds can be obtained from
control flow analysis of the task's code
Lecture 7: Real-time operating systems and low level programming
Calin Curescu
34 of 35