Real Time Operating systems - UniBgrobotics.unibg.it/teaching/srt/pdf/04_RTOperatingSystems.pdf ·...

Real Time Operating systems

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


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


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)


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


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


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


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


13

Multiple blocking queues

CPU

Ready queueAdmit

Preemption

Dispatch

Wait condition 1Event occurs




Processes and Threads

Process


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


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


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


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


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


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


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


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.


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


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


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


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


Real Time Operating Systems


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


Minimizing Latency

Event latency is the amount of time from when an

event occurs to when it is serviced.


Interrupt Latency

Interrupt latency is the period of time from when an

interrupt arrives at the CPU to when it is serviced


Dispatch Latency

Dispatch latency is the amount of time required for the

scheduler to stop one process and start another


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


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


Example of RT Operating System

Real-Time Linux

35 UNIBG - 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


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


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


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


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


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


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


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


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.


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


Xenomai Featuring:


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


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.


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


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


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.


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


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


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


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


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.


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.


Linux Kernel


RTLinux Kernel


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.


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)


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


Date post:	17-May-2018
Category:	Documents
Upload:	trinhthuy
View:	221 times
Download:	0 times

Real Time Operating systems - UniBgrobotics.unibg.it/teaching/srt/pdf/04_RTOperatingSystems.pdf ·...

Documents