Corso di
Elettronica dei Sistemi Programmabili
Sistemi Operativi Real Time
Introduzione
Aprile 2014
Stefano Salvatori
1/28
Sommario
Definizioni
livelli di astrazione
processi di tipo batch e processi interattivi
sistemi multiprocesso
ruolo del sistema operativo
soluzione con time sharing
il concetto di sistemi operativi di tipo real time
2/28
Definizioni
Algoritmo
- procedura logica per risolvere un determinato problema
- è specificato da una sequenza di passi elementari che un esecutore
deve svolgere per risolvere il problema
- non è necessariamente espresso in un linguaggio formale di
programmazione!
Programma
- è l'implementazione di un algoritmo in linguaggio di
programmazione
- può essere eseguito diverse volte per input differenti
3/28
Definizioni
Processo
- instanza di un programma che, data una sequenza di input,
produce un set di uscite
- si parla di processi in tutti quei sistemi in cui è implementata
una MMU utile a garantire la protezione della memoria
Task
- istanza specifica di un codice eseguibile e del suo ambiente di
dati
4/28
Definizioni
Un sistema operativo è un programma che
fornisce una “astrazione” di una macchina fisica
fornisce un semplice interfaccia verso la macchina
ogni parte dell'interfaccia è un “servizio”
Il SO rappresenta anche il gestore delle risorse
con “risorsa” denominiamo tutte le entità fisiche di
un apparato per l'elaborazione
il SO permette l'accesso alle risorse fisiche
il SO rappresenta l'astrazione delle risorse
(per esempio, file, pagine virtuali in memoria, ecc.)
5/28
Definizioni
il kernel è il nucleo di un sistema operativo
concetto fondamentale per ogni SO è “processo”
un processo rappresenta l'esecuzione di un
programma
un SO può eseguire diversi processi
contemporaneamente (concurrency)
6/28
Definizioni
quando un computer esegue un processo
sequenziale, esso passerà per diversi stati
ad ogni passo il processo cambia stato;
Stato:
contenuto die registri del processore
valori delle variabili del processo
7/28
Livelli di astrazione
Scanner
8/28
Meccanismo di astrazione
Per quale motivo ricorriamo all'astrazione?
Programmare direttamente l'hardware porta a
divesi inconvenienti
–
è un lavoro piuttosto difficoltoso e porta ad errori
–
non è portabile
Supponiamo di voler scrivere un programma
in grado di leggere un testo contenuto nel file
del disco e lo riportarlo in uscita sul monitor
–
senza un'opportuna interfaccia la sua stesura
può essere impossibile!
9/28
Meccanismo di astrazione
Application Programming Interface (API)
rappresenta un modo conveniente per accedere a un
servizio in modo standard
●
i dettagli HW sono nascosti al programmatore
●
un'applicazione non dipende dall'HW
●
il programmatore può concentrarsi sui task di più alto
livello
Esempio
per leggere un file, linux fornisce le chiamate a
sistema open() e read() che, dato il nome del file,
consentono di caricare i dati dal supporto esterno
10/28
Un po' di storia
All'inizio si avevano processori di tipo batch
macchine ingrombranti e neppure molto potenti
le applicazioni erano pricipalmente per uso scientifico e militare
I programmi venivano eseguiti uno alla volta
ogni programma era un lavoro, job
I programmi consistevano in semplici elaborazioni
sequenziali
lettura dell'ingresso
elaborazione
uscita
non erano di tipo interattivo
11/28
Batch processor
batch = non-interactive
il programma non può essere interrotto o sospeso (non-preemptive)
scheduling:
basato sulla priorità (es. per prime sono servite le applicazioni più critiche)
struttura FIFO pura
i lavori più brevi sono eseguiti per primi (Shortest Job First, SJF)
12/28
Svantaggi per batch­processor
La CPU era inattiva per lunghi periodi di tempo
mentre venivano inserite e lette le schede perforate, la CPU
era in uno stato d'attesa
la lettura delle schede perforate era molto lenta
Soluzione: spooling
uso di dischi magnetici (dispositivi più veloci)
job raggruppati in “job pools”
mentre viene eseguito un job, contemporanenamente
viene inserito il successivo nel disco
quando finisce un job, viene caricato il successivo dal disco
spool = operazioni simultanee su periferiche
13/28
Interattività
Necessità dell'interazione
per la lettura di input da tastiera durante l'elaborazione
per mostrare i risultati intermedi
per salvare i risultati intermedi su supporto fisso
Input/output
può essere fatto con tecnica polling
aspettare finché il dispositivo è pronto per ricevere o fornire i dati
handshaking
anche qui la CPU è inattiva durante le operazioni I/O
14/28
Multi­programming
L'evoluzione naturale fu la cosidetta “concurrency”
IDEA: mentre un job sta leggendo o scrivendo da o verso
un dispositivo I/O, si ha lo schedule dell'esecuzione di un
altro job (preemption)
15/28
Multi­programming
Multi-programming è un concetto comune nella vita di tutti i
giorni
Consideriamo un avvocato che ha diversi clienti:
segue una politica FIFO: serve un cliente alla volta,
dall'inizio fino alla sentenza
in Italia, per una sentenza si può attendere anche più di 10
anni: è impensabile pensare a un avvocato che lavori con
un solo cliente ogni dieci anni!
in realtà, l'avvocato adotta una politica di TIME SHARING!
Tutti noi adottiamo una politica di time-sharing quando
svolgiamo diversi lavori nel medesimo periodo di tempo!
16/28
Il ruolo di un Sistema Operativo
Chi decide quando un lavoro dev'essere sospeso?
Chi decide cosa dev'essere eseguito al prossimo step?
nei primi computer, questi task erano portati avanti
dall'applicazione stessa
ogni lavoro poteva sospendere se stesso e passare il turno al
lavoro successivo (co-routines)
comunque, questa procedura non è generalizzabile e
portabile
Oggi, il sistema operativo fornisce i servizi per la
multi-programmazione
lo scheduler sceglie quale lavoro dev'essere eseguito in un
certo istante, in funzione dello stato del sistema
17/28
Sistemi con time sharing
Nei sistemi con time sharing
il tempo è suddiviso in “slot”,
ogno slot ha una durata pari a un quanto di tempo
fissato
se lo svolgimento di un lavoro non si blocca su una
operazione di I/O prima della fine del quanto, esso
viene sospeso per proseguire più tardi
18/28
Sistemi con time sharing
Nei sistemi con time sharing
ogni processo viene svolto come se esso fosse l'unico eseguito da un
processore più lento
Il SO (grazie allo scheduler) “virtualizza” il processore
un singolo processore è visto come tanti procesori (più lenti) che
lavorano in parallelo (uno per ogni processo)
Il SO può rendere „virtuali“ molte risorse hardware
memoria, dischi, rete, ecc
I sistemi con time sharing non sono di tipo „predicibile“
il tempo totale di esecuzione di un processo dipende dal
numero di processi che il sistema sta gestendo
se volessimo un sistema predicibile è necessario usare
sistemi operativi di tipo rela time (RTOS)
19/28
Prestazioni dei sistemi con time sharing
Tempo di risposta medio
il tempo che intercorre tra una richiesta dell'utente e la risposta del sistema
es., il tempo che intercoprre tra l'istante in cui l'utente preme un pulsante
e l'istante in cui appare il carattere sullo schermo
è impossibile minimizzare il tempo di risposta di ogni programma
l'idea è quella che ogni programma sia eseguito da un processore
equivalente più lento
qual è la frequenza con cui vengono commutati i diversi task?
periodo di cambiamento del contesto: 1ms? 10ms? 50ms?
uso intensivo della CPU → batch
sistema interattivo → timesharing
sistema predicibile → real-time
20/28
Astrazioni e sistemi Operativi
Il SO fornisce un'astrazione della macchina fisica
questo consente di avere portabilità
questo rende più agevole il lavoro del programmatore
Il livello di astrazione dipende dal contesto dell'applicazione
ciò significa che i servizi che il SO fornisce dipendono dal tipo di servizi che
l'applicazione richiede
i SO di tipo general purpose dovrebbero fornire una vasta gamma di servizi per poter
soddisfare quante più applicazioni possibili
SO specializzati dovranno invece fornire solo alcuni servizi specializzati
I SO possono essere classificati in funzione del contesto di applicazione
general purpose (windows, linux, ...)
server
micro-kernel
embedded OS
real-time OS
21/28
Sistemi di tipo
real­time
22/28
Sistemi real­time
Un sistema di elaborazione in grado di rispondere agli
eventi entro un preciso intervallo di tempo sono detti
sistemi Real-Time
23/28
Cos'è un sistema real­time?
è un sistema in cui la correttezza dell'elaborazione non
dipende solo dai valori fornito in uscita ma anche dal
tempo entro cui i risultati sono prodotti.
24/28
Cos'è un sistema real­time?
REAL TIME significa che il sistema dev'essere
sincronizzato con l'ambiente in cui interagisce.
25/28
Applicazioni tipiche dei sistemi RT
Sistemi per il controllo del volo
Sistemi militari
Inseguimento radar
Controllo del traffico aereo
Sistemi di controllo di traffico su rotaia
Sistemi di telecomunicazione
Simulatori di volo
Robotica
...
26/28
Applicazioni tipiche dei sistemi RT
Sistemi di controllo per enegia nucleare o chimica
Applicazioni in ambito automoblistico
Sistemi multimediali
Sistemi embedded
cellllulari
TV digitale
videogiochi
gicattoli intelligenti
Sistemi „indossabili“
In generale, qualunque apparato che debba interagire
o controllare un ambiente
27/28
Real­Time ≠ veloce
Sistema real-time non è detto che sia sinonimo di sistema
veloce
La velocità è relativa allo specifico ambiente
Avere un sistema veloce è sicuramente vantaggiuoso, ma
non è detto che ciò garantisca il corretto funzionamento
L'obiettivo di un sistema di tipo real-time è quello di garantire
una prefissata risposta nel tempo di ogni task coinvolto.
L'obiettivo di un sistema veloce è invece quello di
minimizzare il tempo medio di risposta di un certo
set di task.
28/28
