TDDB47 Real Time Systems
Lecture 7: Real-time operating systems and
low level programming
To OS or not to OS?
Mikael Asplund
Real-Time Systems Laboratory
Department of Computer and Information Science
Linköping University, Sweden
The lecture notes are partly based on lecture notes by Calin Curescu, Simin NadjmTehrani, 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
Mikael Asplund
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
Real-time operating systems
OS Benefits
• Abstraction
• "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]
– Do not need to make programs hardware specific
– Reusability!
• Multitasking support
–
–
–
–
• Two alternatives
Application
Application
OS
2
Process management (scheduling)
Memory management
Inter-process communication / synchronization
I/O management
• Communication protocols
– e.g. TCP/IP stack
Hardware
• File system
• ...
Hardware
Software
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
3
Challenges: Predictability
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
4
Challenges: Visibility and control
• In conventional OS
• Deterministic behaviour of OS services and
functions
– Most stuff hidden deliberately
• High level abstractions
• Transparency
• Property applies most critically with respect to
time
• In real-time systems
– Within known bounds
– At known times
– Access and control of mechanisms needed to guarantee
predictability
• Trick – provide useful and convenient
abstractions for the user while
• Fault detection and management
– Offer detailed configurability
– Give a detailed timeliness specification of components
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
5
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
6
Challenges: Open systems
RTOS-specific Requirements
• Deterministic behaviour
– Synchronization
– Latencies
• Define and provide the right abstractions, but
• Failure management and recovery
• Clock synchronization
• Do not enforce particular solutions
• Configurability
– E.g. possible to define different task scheduling policies
• Modularity / Extensibility
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
7
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
Real-time functions and services
OS Variants
• Nano-kernel
• Interrupt and event handling
– Time and scheduling
• Functions for time access & control
• Micro-kernel
–
–
–
–
–
–
8
Time and scheduling
System calls
SW and HW exceptions
External interrupts
Synchronization
Dynamic memory allocation
• Process and thread management
• Device management
• Memory management
• General Purpose RTOS
– The rest (Communication, GUI, persistence etc.)
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
9
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
10
Interrupt and event handling
• Employed for
– Scheduling
– Asynchronous notification
– Exception handling
Interrupts
!
• 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
Mikael Asplund
11
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
12
Interrupts
Priorities
•
•
•
•
•
•
•
•
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
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’
System shutdown
Power down
Clock interrupt
Highest priority interrupt
:
Lowest priority interrupt
Scheduler priority
Highest thread priority
:
Lowest thread priority
Interrupt
Interrupt response
Task i
ISR
Interrupt
latency
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
13
–
–
–
–
14
External interrupts
• Interrupt service routine take long time
Process timer events
Update execution budget
Update the ready queue
Update monitoring information
– Leads to long blocking times
– Might be unpredictable
• Solution:
– Two steps (split interrupting handling)
– Immediate Interrupt service
• Non-preemptible
• Schedule the rest of the work
– Scheduled Interrupt service
• Preemptible
• Treated as an ordinary task
• Ticks:
– small size: fine granularity + high overhead
– large size: coarse graunularity + low overhead
• Solution:
– Combine time-driven and event-driven scheduling
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
Dispatch
latency
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
Clock interrupts
• At each tick:
Task j
15
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
16
Functions for time access & control
• Both absolute and relative time
• Operations for
– Reading and setting clocks
– Delaying for a given time
– Programming timeouts
• Recognise and deal with the non-occurrence of some
event
Time access & control
• 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
Mikael Asplund
17
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
18
Access to a Clock
• By having direct access to the environment's time
frame
Delays
Time specified by
program
– Environment supplies a regular interrupt
• e.g. GPS also provides a UTC service
Granularity
difference
between
clock and
delay
Process runnable
here but not
executable
• By using an internal hardware clock that gives an
adequate approximation to the passage of time in
the environment
Process
executing
Interrupts
disabled
• From programmer’s perspective, access
– Via a device driver
– Clock primitive in the language
Time
• Local drift & cumulative drift
• Cumulative drift can be eliminated
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
19
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
Delays
20
Programming timeouts
• By busy waiting
– Wasting CPU time
• Shared variable communications
– Mutexes usually bounded & accounted
– Condition synchronisation however needs timeouts
• By language constructs
– Usually underlying interrupt
– Interrupt can be masked
– Guarantees only a “runnable” state after delay
• Message-passing
– Synchronous case
• E.g. send/receive/reply
– Asynchronous case
• Absolute delays need language constructs
– Atomicity problem
START := Clock;
FIRST_ACTION;
delay 10.0 - (Clock - START);
SECOND_ACTION
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
• Timeouts on actions
– Usually associated with timing error
21
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
22
Process and thread management
• Create, initialise , activate, terminate RT-tasks
– Static or dynamic creation
• Thread pools – static
• Fork – usually dynamic
Process and thread
management
• 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
Mikael Asplund
23
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
24
Scheduling examples
• Mars
Synchronisation & communications
• Atomic actions
– Feasible schedule of taskset with well defined timing and
precedence constraints is developed “off-line”
– Stored in a table
– A table-driven dispatcher used at run-time
• Timeouts
• Messages
• Spring
– Event messages
• Synchronous, asynchronous
– State messages
• Non - blocking
• Sensors, overwriting old states, asynchronous
– 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
– Timestamping
• Causality, age
– Guaranteed allocation of x time units every y time units
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
25
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
Fault tolerance of timing failures
• It is necessary to be able to detect:
–
–
–
–
26
Deadline overrun & FER
• Asynchronous notification
overrun of deadline
overrun of worst-case execution time
sporadic events occurring more often than predicted
timeout on communications
– Event handling, behaves like an interrupt
– Similar to exception handling
• Difference: event usually NOT signaled by affected process
• The last three failures in this list do not necessary
indicate that deadlines will be missed
• Termination model
– It assumes that the recovery strategy requires the task to
stop what it is doing
– Asynchronous transfer of control (ATC)
– an overrun of WCET in one process might be
compensated by a sporadic event occurring less often
than the maximum allowed
• Resumption model
• Both forward and backward error recovery is
possible
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
– E.g. allowing the task to continue its execution at a
different priority
27
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
Overrun of WCET
• The consequences of an error should be
restricted to a well-defined region of the program
Overrun of Sporadic Events
• Sporadic events that fire too often can break
scheduling!
– It should be possible to catch the timing error in the
process that caused it
• Avoid if possible, otherwise detect and take
appropriate action
• 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
• Two approaches:
– Hardware interrupt: manipulate associated device control
registers
– To use sporadic server technology (see later)
• 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
Mikael Asplund
28
• Most real-time languages and operating systems
lack support
29
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
30
Device management
• Normally not accessible in usual OS
Device management
• Needed here for predictability
• For interaction with sensors, controllers, timers,
other IO
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
31
Status Driven
Memory mapped vs. IO operations
Data
• A program performs explicit tests in order to determine the
status of a given device
Data
Memory
CPU
Devices
32
• 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
Devices
Address
Address
Data
CPU
Memory
Devices
• Nowadays most devices are interrupt driven.
– Interrupts can of course be turned off and polling of device
status used instead.
Devices
• Interrupts are often not allowed in Safety Critical Systems
Address
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
33
Interrupt Driven
• Interrupt-driven program-controlled
Elements for interrupt controlled devices
•
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.
•
Interrupt identification (and device)
•
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
• 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
Mikael Asplund
35
34
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
36
Abstract Models
•
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
Mikael Asplund
Memory management
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
37
Memory management
•
Limited amount of memory
– This is due to: cost, or size, power or weight constraints
•
Fine grained memory control should be possible
– So that it can be used effectively
•
Memory allocation restricted to parts of real memory
– Avoid problems with paging and virtual 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
Mikael Asplund
39
38
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
Mikael Asplund
40
Stack Management
• Important for embedded systems
• Specifying the stack size of a task/thread requires trivial support
Real-time POSIX
• 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
Mikael Asplund
41
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
42
Real-time POSIX
•
•
Many commercial RTOS - instances of UNIX
Today most conform to POSIX and RT extensions
– E.g. RTMX, LynxOS, VxWorks
•
Pthreads
– Active objects in POSIX
– Share data (heap) with other threads
•
•
Typical implementation maintains a small data structure
– Thread current state
• Register values, program counter, stack pointer
– Status
• Ready, blocked running
– Scheduling information
• Priority, policy, timing data
Kernel and/or user space
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
43
Real-time POSIX contn’d
•
Integer priorities assigned to threads at creation
– Can be changed dynamically
– Supports priority based scheduling
• Ties broken by FIFO, or round-robin
•
Hook for inserting "own" schedulers
– Such as EDF
•
Threads can prevent paging by locking designated parts of
memory space
•
Synchronisation supports prioritized queues
– For mutex, locks, and condition variables
•
Supports priority inheritance & ceiling protocols
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
Real-time POSIX contn’d
•
•
•
Real-time POSIX contn’d
• Supports signals
Message passing communication
– Prioritised by sender
– Queued in priority order for receivers
– asynchronously software interrupts
– RT-POSIX - defines new signals with associated data
and priorities.
– Signal handlers receive queued signals in priority order
Multiple high-resolution clocks and timers available
– Return current time and resolution
– Minimum resolution: tick interval
– At least CLOCK_REALTIME has to be supported
• Storage management
– Possibility for synchronous IO
Timers - one-shot or periodic: generating event o signal
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
44
45
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
46
Some existing systems
• LynxOS
• VxWorks
Existing Real-time OSs
• pSOS
• QNX
• Jbed
• OSE
• RTLinux/RTAI
• (WindowsCE)
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
47
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
48
Reading
Real-time Linux
• Chapter 10 of book by Shaw
P2
P1
• Chapter 12.3 and 15.1 in Burns & Wellings
P3
RT2
Linux
RT1
RT3
Microkernel
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
49
Lecture 7: Real-time operating systems and low level programming
Mikael Asplund
50