Real Time Operating systems - UniBgrobotics.unibg.it/teaching/srt/pdf/04_RTOperatingSystems.pdf ·...
Transcript of Real Time Operating systems - UniBgrobotics.unibg.it/teaching/srt/pdf/04_RTOperatingSystems.pdf ·...
Concurrency: processes and
threads
Corso di Sistemi RT
Prof. Davide Brugali
Università degli Studi di Bergamo
Slide adapted from : http://retis.sssup.it/~lipari/courses/str06/rtcs.html
A cosa serve ?
A sfruttare al meglio il processore
10-7
10-6
10-5
10-4
10-3
10-2
10-1
102
101
10-8
10-9
Res
ponse
tim
e in
sec
onds
100 human tape
floppy
CD
memory
processor
3UNIBG - Sistemi Real Time - Brugali
Parallelismo tra CPU e I/O Devices
CPU I/O Device
Initiate I/O
Operation Process I/O
Request
Signal Completion
Interrupt I/O
Routine
I/O FinishedContinue with
Outstanding Requests
4UNIBG - Sistemi Real Time - Brugali
A cosa serve ?
A modellare il parallelismo nel mondo reale
L’alternativa consiste nell’utilizzare tecniche di programmazione sequenziale
Il programmatore deve costruire il sistema in modo che le varie attività vengano svolte secondo una sequenza predefinita
5UNIBG - Sistemi Real Time - Brugali
Fundamentals of Concurrency
UNIBG - Sistemi Real Time - Brugali6
Algorithm: It is the logical procedure to solve a certain problem
It is informally specified as a sequence of elementary steps that an “execution machine” must follow to solve the problem
Program: It is the implementation of an algorithm in a programming
language
Can be executed several times with different inputs
Process: An instance of a program that given a sequence of inputs
produces a set of outputs
7
Process traces
When a computer executes a sequential process, it
goes through states
At each step, the state of the process is changed
State:
Set of processor registers
Set of process variables
UNIBG - Sistemi Real Time - Brugali
8
Process states
The OS can execute many processes “at the same time” Only one process can execute at some instant of time, however, by
using time sharing, the OS can switch between all the processes that are ready to execute
From the OS point of view, it is important to understand which process is ready to execute
Each process, during its lifetime can be in one of the following states Starting (the process is being created)
Ready (the process is ready to be executed)
Executing (the process is executing)
Blocked (the process is waiting on a condition)
Terminating (the process is about to terminate)
UNIBG - Sistemi Real Time - Brugali
9
Process states
a) Creation The process is created
b) Dispatch The process is selected to execute
c) Preemption The process leaves the processor
d) Wait on condition The process is blocked on a condition
e) Condition true The process is unblocked
f) Exit The process terminates
Start Ready Running
TerminateBlocked
a
b
c
de
f
UNIBG - Sistemi Real Time - Brugali
10
Time sharing systems
In time sharing systems,
Every process can execute for maximum one
round
For example, 10msec
At the end of the round, the processor is given to
another process
UNIBG - Sistemi Real Time - Brugali
11
Process switch
It happens when The process has been “preempted” by another higher
priority process
The process blocks on some condition
In time-sharing systems, the process has completed its “round” and it is the turn of some other process
We must be able to restore the process later Therefore we must save its state before switching to
another process
UNIBG - Sistemi Real Time - Brugali
12
Causes for a process switch
A process switch can be
Voluntary: the process calls a blocking primitive, i.e. it
executes an INT
For example, by calling a read() on a blocking device
Non-voluntary: an interrupt arrives that causes the process
switch
It can be the timer interrupt , in time-sharing systems
It can be an I/O device which unblocks a blocked process with a
higher priority
UNIBG - Sistemi Real Time - Brugali
13
Multiple blocking queues
CPU
Ready queueAdmit
Preemption
Dispatch
Wait condition 1Event occurs
Wait condition 2Event occurs
Wait condition 3Event occurs
UNIBG - Sistemi Real Time - Brugali
Process
UNIBG - Sistemi Real Time - Brugali15
We can distinguish two aspects in a process
Resource Ownership
A process includes a virtual address space, a process
image (code + data)
It is allocated a set of resources, like file descriptors, I/O
channels, etc
Scheduling/Execution
The execution of a process follows an ececution path, and
generates a trace (sequence of internal states)
It has a state (ready, Running, etc.) and scheduling
parameters (priority, time left in the round, etc.)
16
Threads
Generally, processes do not share memory
To communicate between process, it is necessary to user
OS primitives
Process switch is more complex because we have to
change address space
Two threads in the same process share the same
address space
They can access the same variables in memory
Communication between threads is simpler
Thread switch has less overhead
UNIBG - Sistemi Real Time - Brugali
17
Processes vs. Threads
Processes are mainly used to compete for some resource For example, two different users run two separate
applications that need to print a file
The printer is a shared resource, the two processes compete for the printer
Threads are mainly used to collaborate to some goal For example, one complex calculation can be split in two
parallel phases, each thread does one phase
In a multi-processor machine the two threads go in parallel and the calculation becomes faster
UNIBG - Sistemi Real Time - Brugali
18
1. wait
Example - I
Consider a Word Processor application
Main cycle1. Wait for input from the keyboard
2. Update the document
3. Format the document
4. Check for syntax errors
5. Check for other events (i.e. temporary save)
6. Return to 1
One single process would be a waste of time!
2. update3. format 4. syntax5. Other events
1. wait
UNIBG - Sistemi Real Time - Brugali
19
Example - II
Problems Most of the time, the program waits for input
Idea, while waiting we could perform some other task
Activities 3 and 4 (formatting and syntax checking) are very time consuming Idea: let’s do them while waiting for input
Solution with multiple processes One process waits for input Another process periodically formats the document A third process periodically performs a syntax checking A fourth process visualize the document
InputProcess
FormatProcess
SyntaxProcess
GraphicProcess
UNIBG - Sistemi Real Time - Brugali
20
Example - III
Problem with multiple processes All processes needs to access the same data
structure, the document
Which process holds the data structure?
Solution 1: message passing A dedicated process holds the data, all the others
communicate with it to read/update the data
Very inefficient!
InputProcess
FormatProcess
SyntaxProcess
GraphicProcess
DataServer
UNIBG - Sistemi Real Time - Brugali
21
Example - IV
Another solution...
Solution 2: shared memory
One process holds the data and makes that part of its
memory shareable with the others
Still not very efficient:
We have a lot of process switches
Memory handling becomes very complex
UNIBG - Sistemi Real Time - Brugali
22
Why using threads
Speed of creation
Creating a thread takes far less time than creating a process
Speed of switching
Thread switch is faster than process switch
Shared memory
Threads of the same process run in the same memory space
They can naturally access the same data!
InputThread
FormatThread
SyntaxThread
GraphicThread
DocumentProcess
UNIBG - Sistemi Real Time - Brugali
23
Threads support in OS
Different OS implement threads in different ways Some OS supports directly only processes
Threads are implemented as “special processes”
Some OS supports only threads Processes are threads’ groups
Some OS natively supports both concepts For example Windows NT
For efficiency reasons, most RTOS only support 1 process Many threads inside the process
All threads share the same memory
Examples are RTAI, RT-Linux, Shark, some version of
VxWorks, QNX, etc.
UNIBG - Sistemi Real Time - Brugali
24
OS structures
Non process kernel
The kernel executes in its own context
Every time we do a mode switch,
Registers are saved
The stack is changed
Kernel
P1 P2 P3 P4
UNIBG - Sistemi Real Time - Brugali
25
Execution within User processes
The kernel routines execute in the context of the running process The stack is not changed Local variables of the kernel are saved on top of the process
stack Only a small part (the process switch) is independent of the
process
Linux and Shark and many others have this structure
Process Switching functions
P1 P2 P3 P4
OSFunc-tions
OSFunc-tions
OSFunc-tions
OSFunc-tions
UNIBG - Sistemi Real Time - Brugali
26
Process-based OS
Each routine (service) is a separate process
This is the typical microkernel structure!
Every system call involves a process switch
Advantages: Modularity, Composability, Extendibility
Disadvantages Overhead
Process Switching functions
P1 P2 P3 P4 OS 2OS 1 OS 3
UNIBG - Sistemi Real Time - Brugali
27
Summary
Important concepts
Process: provides the abstraction of memory space
Threads: provide the abstraction of execution trace
The scheduler manages threads!
Processes do not normally share memory
Two threads of the same process share memory
We need to explore all the different ways in which two
threads can communicate
Shared memory
Message passing
In the next section we will only refer to threads
UNIBG - Sistemi Real Time - Brugali
Features of Real-Time Kernels
Most real-time systems do not provide the features found in a standard desktop system Real-time systems are typically single-purpose
Real-time systems often do not require interfacing with a user
Features found in a desktop PC require more substantial hardware that what is typically available in a real-time system
In general, real-time operating systems must provide:
(1) Preemptive, priority-based scheduling
(2) Preemptive kernels
(3) Latency must be minimized
29UNIBG - Sistemi Real Time - Brugali
Minimizing Latency
Event latency is the amount of time from when an
event occurs to when it is serviced.
30UNIBG - Sistemi Real Time - Brugali
Interrupt Latency
Interrupt latency is the period of time from when an
interrupt arrives at the CPU to when it is serviced
31UNIBG - Sistemi Real Time - Brugali
Dispatch Latency
Dispatch latency is the amount of time required for the
scheduler to stop one process and start another
32UNIBG - Sistemi Real Time - Brugali
Real-Time CPU Scheduling
Periodic processes require the CPU at specified
intervals (periods)
p is the duration of the period
d is the deadline by when the process must be serviced
t is the processing time
33UNIBG - Sistemi Real Time - Brugali
Real-Time CPU Scheduling
Multi-tasking OS designed to permit tasks (processes)
to complete within precisely stated deadlines
If deadline constraints cannot be met for a new task, it
may be rejected
If a new task would result in deadline violations for other
tasks, it may be rejected
Example commercial operating systems
Vrtx – Mentor Graphics Systems
VxWorks and pSOS – Wind River Systems
RTLinux – FSMLabs, later acquired by Wind River
Systems
34UNIBG - Sistemi Real Time - Brugali
Early Linux Not Designed for Real-Time Processing
Early Linux (1.x Kernel) installations on retired Windows
PCs
Linux outperformed Windows in reliability and uptime (still does)
Linux Design: Fairness, Throughput and Resource-
Sharing
Basic Unix development design principles applied in Kernel
User tasks should not stall under heavy load
Does not drop network connections or starve users / applications
System resources must be shared fairly between users
Fairness, progress and resource-sharing conflict with the
requirements of time-critical applications
UNIX systems (and Linux) are historically not Real-Time
OS
Evolution of Linux
36UNIBG - Sistemi Real Time - Brugali
Linux Kernel Critical Sections
Critical sections protect shared resources, e.g.
hardware registers, I/O ports, and data in RAM
Critical sections are shared by Processes, Interrupts
and CPUs.
Critical sections must be locked and unlocked
Locked critical sections are not preemptible
Exhaustive Kernel testing to identify worst-case code
paths
Real-Time Inhibitor
37UNIBG - Sistemi Real Time - Brugali
Existing Locking Subsystems are not Priority-Aware
System semaphore Counting semaphore used to wake multiple waiting tasks
No support for priority inheritance
No priority ordering of waiters
Big Kernel Lock (BKL) Originally non-preemptible, now preemptible using system semaphore
Can be released by blocking tasks, re-acquired upon wake-up
No priority-awareness, or priority inheritance for contending tasks
Read – Write Locks Classical blocking / starvation issues with no priority awareness
Real-Time Inhibitor
38UNIBG - Sistemi Real Time - Brugali
Dramatic Reduction in 2.6 Preemption Latencies
Multiple Concurrent Tasks in Independent Critical
Sections
Generally Fully Preemptible “No Delays”
Non-preemptible: lowest-level interrupt management
Non-preemptible: Scheduling and context switching code
Design Flexibility
Provides Full Access to Kernel Resources to RT-
Tasks
Supports existing driver and application code
User-space Real-Time
The Fully Preemptible Linux Kernel
39UNIBG - Sistemi Real Time - Brugali
Linux 2.6 Kernel Real-Time Technology Enhancements
Preemptible Interrupt Handlers in Thread Context Default: IRQs (interrupt request from a device) run in threads IRQ Thread can have private stack Real-Time tasks at Higher Priority than IRQ handlers
Integrated Kernel Mutex with Priority Inheritance (PI)
Preemptible PI Mutex protects Kernel Critical Sections
Big Kernel Lock (BKL) converted to PI Mutex
Read-Write Locks converted to PI Mutex
High Resolution Timers
Linux Real-Time Technology Overview
40UNIBG - Sistemi Real Time - Brugali
Threaded IRQs Pros
RT IRQs do not contend with common IRQs
IRQ Processing does not Interfere with task execution
Flexible priority assignment
can be arranged to emulate hardware-based priorities
Interrupts run fully preemptible
Threaded IRQs Cons
IRQ-Thread Overhead
Scheduler must run to activate IRQ Threads
IRQ Thread Latency
IRQs no longer running at the highest priority
Full task switch required to handle IRQ
Response-Time / Throughput tradeoff
Thread-Context Interrupt Handlers
41UNIBG - Sistemi Real Time - Brugali
Gradual SMP-Oriented Linux Kernel Optimizations
Kernel Critical sections Preemptible
IRQ Subsystem Prioritized and Preemptible
Mutex Locks with Priority Inheritance
High-Resolution Timers
“RT-Preempt” Kernel
Kernel Preemption outside Critical Sections,
Preemptible “BKL”, O(1) SchedulerKernel 2.6
Kernel Preemption outside Critical Sections
Spin-locked Critical Sections“Preempt” Kernel 2.4
No preemption, Spin-locked Critical SectionsSMP Kernel 2.2 - 2.4
No Kernel preemption, “BKL” SMP LockSMP Kernel 2.x
No Kernel preemptionEarly Kernel 1.x
Real-Time Linux Kernel Evolution
42UNIBG - Sistemi Real Time - Brugali
Efficiency and Responsiveness are Inversely Related
Overhead for Real-Time Preemption
Mutex Operations more complex than spinlock operations
Priority Inheritance on Mutex increases task switching
Priority Inheritance increases worst-case execution time
Interrupt overhead
Additional Task Switching
Interrupt Preemption Interrupt throughput reduction
Throughput High responsiveness
Real-Time Response vs. Throughput
43UNIBG - Sistemi Real Time - Brugali
XENOMAI: Real-Time Framework for Linux
Xenomai is a real-time development framework cooperating with the Linux kernel, in order to provide a pervasive, interface-agnostic, hard real-time support to user-space applications, seamlessly integrated into the GNU/Linux environment.
Generic RT-core (“nucleus”)
Kernel-independent, but highly integrated with Linux
RTOS APIs provided via “skins”
Xenomai was born in 2001, out of a basic idea: support traditional RTOS APIs over a Linux-based real-time framework, so that existing industrial applications coming from the proprietary world could migrate easily to a GNU/Linux-based environment, while keeping stringent real-time guarantees. To this end, the core Xenomai technology exhibits an abstract real-time nucleus, which provides generic building blocks for implementing real-time APIs, aka "skins". This way, a skin can emulate a proprietary API efficiently, based on a reusable real-time core.
44UNIBG - Sistemi Real Time - Brugali
Xenomai Skin
http://www.xenomai.org/documentation/branches/v2.3.x/pdf/xenomai.
pdf45UNIBG - Sistemi Real Time - Brugali
Xenomai RTDM
The RTDM (Real-Time Driver Model) interface provides a skin-
independent framework for writing real-time device drivers, and
accessing them through a POSIX interface. RTDM helps to follow the
well-known design principle of clean separation between hardware
interface and application program, also when strict deterministic
behaviour is required. 46
UNIBG - Sistemi Real Time - Brugali
Examples of Commercial RT-OS
Tratto da G.C. Buttazzo, «Sistemi in Tempo Reale», Capitolo 12
http://bwrc.eecs.berkeley.edu/Classes/CS252/Notes/Lec26a-sw.pdf
48 UNIBG - Sistemi Real Time - Brugali
QNX/ Neutrino
POSIX-compliant Unix-like real-time operating system.
Microkernel design – kernel provides essential threads and real-time services
use of a microkernel allows users (developers) to turn off any functionality they do not require without having to change the OS itself.
The system is quite small, fitting in a minimal fashion on a single floppy, and is considered to be both very fast and fairly "complete."
The footprint of microkernel is 12kb.
UNIBG - Sistemi Real Time - Brugali49
QNX/ Neutrino (contd..)
Every driver, application, protocol stack, and file system
runs outside the kernel, in the safety of memory-
protected user space.
As a result, virtually any component can fail - and be
automatically restarted -without affecting other
components or the kernel.
Maximize application portability with extensive support
for the POSIX standard, which lets you quickly migrate
Linux, Unix, and other open source programs
UNIBG - Sistemi Real Time - Brugali50
QNX/ Neutrino (contd..)
QNX is a message passing operating system
Messages are basic means of interprocess
communication among all threads
Follows a message based priority tracking feature
UNIBG - Sistemi Real Time - Brugali51
VxWorks
Created by Wind River.
Current Version: VxWorks 6.0
VxWorks is the most established and most widely
deployed device software operating system.
Currently there are more than 300 million devices
that are VxWorks enabled.
The core attributes of VxWorks, include high
performance, reliability, determinism, low latency and
scalability.
UNIBG - Sistemi Real Time - Brugali52
VxWorks (contd..)
Enhanced error management
Backward compatibility to previous verison features for exception handling and and template support
Extensive POSIX 1003.1, .1b, .1c compatibility (including pthreads )
Scheduling Uses preemptive priority with round robin scheduling to
accommodate for both
Real time processes
Non-real time processes
UNIBG - Sistemi Real Time - Brugali53
VxWorks (contd..)
Memory Protection
MMU based memory protection.
Reduced Context Switch time
Saves only those register windows that are actually in use
(on a Sparc)
When a task’s context is restored, only the relevant register
window is restored
To increase response time, it saves the register windows in
a register cache – useful for recurring tasks
UNIBG - Sistemi Real Time - Brugali54
VxWorks (contd..)
Distinguishing features
efficient POSIX-compliant memory management
multiprocessor facilities
shell for user interface
symbolic and source level debugging capabilities
performance monitoring
Mars Exploration Rovers Spirit and Opportunity and the
Mars Reconnaissance Orbiter use the VxWorks
operating system
UNIBG - Sistemi Real Time - Brugali55
Examples of Open-source RT-OS
Tratto da G.C. Buttazzo, «Sistemi in Tempo Reale», Capitolo 12
http://bwrc.eecs.berkeley.edu/Classes/CS252/Notes/Lec26a-sw.pdf
56 UNIBG - Sistemi Real Time - Brugali
RTLinux
Available as a patch to the regular Linux kernel
Provides an RT API for developers
RTLinux is a hybrid OS that runs a Linux kernel as an idle thread (lowest priority) of the real-time kernel.
Predictable delays. By its small size and limited operations.
Finer timer resolution.
RT kernel and RT applications are kept as simple as possible and non-time critical applications (GUIs, file systems) are handled by the standard Linux.
UNIBG - Sistemi Real Time - Brugali57
RTLinux ( Contd )
Real time threads and interrupt handlers never delayed by non-realtime operations
Preemptible kernel. Its routines are very small and fast, this does not cause
big delays. Interrupts from Linux are disabled.
RT-Linux has many kinds of Schedulers. FIFO.
Used to pass information between real-time process and ordinary Linux process.
Designed to never block the real-time task.
The “earliest deadline first” scheduler. Rate-monotonic scheduler.
UNIBG - Sistemi Real Time - Brugali58
RTAI (Real Time Application Interface)
Hard real-time extension to the Linux kernel
A patch to the Linux kernel which introduces a hardware abstraction layer
A broad variety of services which make realtime programmers' lifes easier
RTAI provides deterministic response to interrupts, POSIX compliant and native RTAI realtime tasks.
Linux application is able to execute without any modification
RTAI considers Linux as a background task running when no real time activity occurs.
UNIBG - Sistemi Real Time - Brugali61
RTAI ( Contd )
RTAI is very much module oriented
real time scheduler module Task functions
Timing functions
Semaphore functions
Mailbox functions
Intertask communication functions
Fifo services
Shared memory
Posix pthread and pqueue(msg queue)
UNIBG - Sistemi Real Time - Brugali62
Comparison of Linux implementations
RTLinux and RTAI
RTAI provides better real-time support than RTLinux
soft real-time in user space along with hard real-time in
kernel space
excellent performance in terms of low jitter and low
latency
better C++ support and more complete feature set
availability of LXRT which allows user space
applications in kernel space
RTAI has the better open source approach with
frequent feedback from developers
UNIBG - Sistemi Real Time - Brugali63