Sistemi real-time Sistemi real-time

Sistemi real-time
Sistemi
real-time:
la
loro
correttezza
di
funzionamento dipende
dalla consistenza logica delle operazioni eseguite
dalla tempestività di produzione dei risultati.
I risultati delle elaborazioni svolte in risposta ad un
certo evento devono essere prodotti entro un
intervallo di tempo determinato, detto deadline.
Un risultato prodotto oltre la deadline: inutile o
addirittura controproducente per il funzionamento del
sistema stesso.
Es.: sistemi di controllo del traffico aereo, sottosistemi
utilizzati per il controllo di automobili, sistemi di difesa
anti-missile, automated manufacturing, etc.
Eventi che determinano l'innesco dell'azione:
-periodici
-aperiodici (occasionali, non previsti)
-sporadici (ricorrenti, ma non in modo regolare)
1
Sistemi real-time
In base all'effetto del mancato rispetto delle deadline
associate alle operazioni i sistemi real-time si
classificano in:
Sistemi soft real-time: possono tollerare una
violazione occasionale di una deadline anche se ciò
degrada le prestazioni del sistema.
Esempio: sistemi di commutazione telefonica, sistemi
di trasmissione video o audio, automated
manufacturing , etc.
Sistemi hard real-time: le deadline imposte dalle
applicazioni supportate devono essere sempre
rispettate, pena l’insorgere di situazioni critiche o
addirittura pericolose (perdita di vite umane, catastrofi
ambientali).
Esempio: sistemi di controllo del traffico aereo, dei
reattori nucleari, degli impianti industriali; sistemi di
difesa, etc.
Talvolta i sistemi real-time comprendono sottosistemi
hard real-time e sottosistemi soft real-time.
L’obiettivo primario nei sistemi real-time è garantire
la correttezza temporale di funzionamento (timeliness)
del sistema.
Nei sistemi convenzionali, invece, si tende in genere
alla massimizzazione del throughput.
2
Sistemi real-time
In un sistema real-time, accanto alle attività
caratterizzate da un vincolo temporale (sia hard che
soft) esistono anche altre attività non tempo-critiche.
Un sistema real-time ideale dovrebbe:
• garantire che tutti i processi tempo critici rispettino
le loro deadline
• minimizzare il tempo di risposta medio dei processi
non tempo-critici.
Real-time computing is not fast computing!!
1. il concetto di tempo reale è relativo alla dinamica
dell'applicazione controllata e non tutte le
applicazioni richiedono elevate velocità di
esecuzione.
2. Un’elevata velocità di esecuzione non basta da sola
a garantire il rispetto delle deadline → nel progetto
dei sistemi real-time è necessario rivedere le
strategie di schedulazione e di gestione delle risorse
adottate nei sistemi di elaborazione convenzionali
ed introdurre nuovi concetti e paradigmi.
3
Problematiche di progetto e di ricerca nei sistemi
real-time:
Progetto di sistemi operativi in grado di garantire
un’esecuzione prevedibile in ambienti sia paralleli
che distribuiti.
predicibilità: caratteristica fondamentale che un
sistema operativo real-time dovrebbe possedere.
Nei sistemi operativi convenzionali le attese (wait) su
risorse o eventi possono essere arbitrariamente
lunghe.
Un sistema operativo real-time deve esibire un
comportamento predicibile → eseguire le primitive di
sistema entro dei ben specificati limiti temporali.
4
Problematiche di progetto e di ricerca nei sistemi
real-time
L’ambiente real-time necessita di funzionalità per
realizzare:
- cambiamenti di contesto (context switch) veloci
-una gestione degli interrupt rapida e predicibile
- un’efficiente schedulazione in presenza di vincoli
sul tempo e sull’affidabilità.
Obiettivo di un sistema operativo real-time: gestire
ed assegnare le risorse in modo da rispettare i vincoli
temporali delle applicazioni real-time.
Vanno definite politiche di allocazione delle risorse
e schedulazione dei processi tali da assicurare il
rispetto dei vincoli temporali.
Si cerca di determinare in anticipo tutte le risorse di
cui il processo avrà bisogno nel corso della sua
esecuzione, non solo in termini di CPU (worst case
execution time), ma anche di I/O, file, etc.
5
Caratteristiche dei task nei sistemi real-time
I task real-time
•
•
sono attivati da eventi che possono essere:
• periodici
• sporadici (esiste un minimo tempo di interarrivo)
• aperiodici (occasionali)
sono caratterizzati da:
•
deadline d: di tipo
• hard
• firm
• soft
•
tempo di arrivo a: t. in cui diventa ready to run
(chiamato tempo di richiesta per le istanze di
task periodici)
•
tempo di esecuzione C: t. necessario alla CPU
per eseguirlo completamente senza interruzioni
•
start time s: t. in cui va in run per la prima volta
•
finishing time f: t. in cui termina la sua
esecuzione
•
laxity (slack time) LX: LX=d-a-C ritardo di
attivazione max che un task attivo può subire
nella ready queue per non violare la sua
deadline
•
value: importanza relativa del task all'interno di
una classe di criticità
6
Ad ogni task
value_function
real-time
è
associata
una
Value function: esprime il l’andamento del beneficio
che il sistema trae dal completamento del task in
funzione del tempo.
Il value di un task completato all’istante t è dato dalla
sua value_function calcolata a quell’istante.
ƒ
hard real-time tasks
value
value
d
ƒ
d
time
time
soft real-time tasks
value
d
time
ƒ
firm real-time tasks
value
d
time
7
Schedulazione dei task nei sistemi real-time
Definizioni
Processo (task): sequenza di istruzioni che, in
assenza di altre attività, viene eseguita dal processore
in modo continuativo fino al suo completamento.
Processo attivo: potenzialmente in grado di eseguire
su un processore.
Se può usare il processore va in esecuzione
Se deve attendere viene accodato nella ready queue
Schedulazione:
processore
assegnamento
dei
task
al
Gli algoritmi di schedulazione real-time possono
essere classificati in:
- preemptive o non-preemptive
- statici o dinamici
- off-line o on-line
- best-effort o guaranteed
Hp. ad ogni task real-time è assegnata una priorità.
8
Schedulazione dei task nei sistemi real-time
Preemptive: un task T1 in run può essere sospeso
temporaneamente in seguito all'arrivo di un altro task
T2 a priorità maggiore, e la sua esecuzione potrà
riprendere solo quando non ci saranno task a priorità
maggiore pronti per l'esecuzione
Non-preemptive: una volta che un task T1 è andato
in run, continua a tenere il processore per tutta la
durata dell'esecuzione
Problema: inversione di priorità
On-line: la schedulazione viene decisa durante
l'esecuzione.
All'occorrenza di un evento:
un algoritmo on-line preemptive decide "al volo",
cioe’ a run-time, se eseguire il primo task associato
all'evento occorso o continuare l'esecuzione del task
corrente;
un algoritmo on-line e non-preemptive registra il
fatto che un nuovo task (quello associato all'evento) è
runnable, e deciderà quale task mandare in
esecuzione solo dopo la terminazione del task
corrente.
Off-line:
la
schedulazione
(preemptive
o
nonpreemptive) viene decisa prima dell'attivazione
dei processi, sulla base di informazioni note a priori, e
memorizzata in una tabella di schedulazione, che a
run-time viene eseguita da un dispatcher.
9
Schedulazione dei task nei sistemi real-time
Statici: la schedulazione viene decisa in base a
parametri fissi, che sono assegnati ai processi una
volta per tutte prima della loro attivazione
Dinamici: la schedulazione viene decisa in base a
parametri dinamici, che possono variare durante
l’esecuzione dei processi.
Best-effort: la schedulazione viene decisa in base ad
una funzione di costo definita globalmente su tutto
l’insieme di task. Privilegia le prestazioni medie
dell’insieme, piuttosto che garantire i vincoli temporali
di ogni singolo task.
Guaranteed: la schedulazione viene decisa in modo
da garantire individualmente il rispetto dei vincoli
temporali di ogni singolo task. Utilizza un test di
garanzia, che viene eseguito sull’insieme ogni volta
che un nuovo processo entra nel sistema.
10
Test di schedulabilità
Obiettivo degli algoritmi di schedulazione nei sistemi
real-time è garantire il rispetto delle deadline dei task
Occorre un test di schedulabilità per stabilire se
possa esistere o meno una schedulazione che
raggiunga tale obiettivo.
Hp. In un sistema real-time periodico costituito da m
task ed N processori
Pi: periodo del task i
Ci : il tempo di computazione del task i
L'insieme di task è schedulabile nel sistema in
esame se risulta verificata la seguente condizione:
m
Ci
µ=∑ ≤N
i =1 Pi
µ è l'utilizzazione del sistema.
Es. 1 task con Ci=10 ms, Pi=20 ms → µi=0.5 CPUs
5 task del genere richiedono un sistema con 3 CPU.
Il valore 3 ottenuto dalla condizione è un lower bound
sul numero di CPU necessarie, perché non tiene
conto del tempo di commutazione tra i task e di altre
possibili fonti di overhead.
11
Schedulabilità nei sistemi real-time
Un insieme di task è schedulabile se per esso esiste
una schedulazione fattibile,
cioè se esiste un assegnamento di task ai processori
tale che tutti i task dell'insieme terminano entro le
deadline.
Algoritmo ottimo (in generale): massimizza o
minimizza una data funzione di costo definita
sull'insieme di task
Algoritmo ottimo (nel senso della schedulabilità):
Se un insieme di task è schedulabile con un generico
algoritmo A, allora lo sarà sicuramente anche con
l'algoritmo ottimo.
Viceversa, se un insieme di task non è schedulabile
con l'algoritmo ottimo, tale insieme non sarà
schedulabile con nessun'altro algoritmo.
12
Test di schedulabilità
Fattore di utilizzazione U di un insieme di task
periodici: frazione di tempo utilizzata dalla CPU per
eseguire l'insieme di task.
Se i task sono n,
n
U=
∑
i =1
Ci
Ti
Dato un insieme di task periodici da schedulare e un
algoritmo di schedulazione, è possibile calcolare il
limite superiore Uub (upper bound), oltre il quale U
non può più crescere, altrimenti la schedulazione di
quell'insieme diventa non fattibile.
Per un dato algoritmo A si definisce limite superiore
minimo (least upper bound) Ulub(A) del fattore di
utilizzazione il minimo tra i fattori di utilizzazione
calcolati su tutti gli insiemi di task che utilizzano
pienamente il processore.
Dato un algoritmo di schedulazione su un set di task il
processore è pienamente utilizzato dall' insieme se
la schedulazione è fattibile e un aumento comunque
piccolo del tempo di calcolo di un qualsiasi task rende
la schedulazione non fattibile.
Un insieme di task periodici è sicuramente
schedulabile con un algoritmo A se risulta verificata
la seguente condizione:
U≤Ulub(A)
Un insieme di task periodici non è schedulabile se
U>1
13
Algoritmi di schedulazione task periodici
Ipotesi:
1. periodo costante nel tempo,
2. tempo di esecuzione costante da istanza ad istanza,
3. deadline = fine del periodo corrente,
4. task indipendenti.
Rate-Monotonic (RM)
ƒ
ƒ
ƒ
ƒ
usato solo per la schedulazione di task periodici
assegna le priorità in modo direttamente
proporzionale alla frequenza di arrivo (1/T)
essendo il periodo fisso, la priorità è fissa: alg.
statico
preemptive
14
RM è un algoritmo ottimo: se un insieme di task non
è schedulabile con RM, non sarà schedulabile con
nessun'altro
algoritmo
a
priorità
fisse.[Liu,Layland,1973]
Ulub(RM)= n (21/n - 1)
per n=2 Ulub=0.83
n=3 Ulub=0.78
n=4 Ulub=0.76
per grandi valori di n, n→∞ Ulub=ln 2 ≈0.69
Per un generico insieme di task RM garantisce la
schedulabilità fino ad un'utilizzazione della CPU del
69%. Per insiemi di task con U maggiori, RM non
garantisce una schedulazione fattibile.
15
Earliest Deadline First (EDF)
ƒ
ƒ
ƒ
Si utilizza sia con task periodici sia con task non
periodici
La priorità maggiore è data al task con deadline più
imminente
Preemptive: se arriva un task con deadline<di
quello in run, quest'ultimo viene sospeso. Altrimenti
lo scheduler aggiunge il nuovo task alla lista dei
processi pronti.
Conviene tenere tale lista ordinata per deadline.
ƒ Se la lista dei processi pronti non è ordinata per
deadline la complessità è O(n)
ƒ Se le lista dei processi pronti è ordinata per
deadline la complessità è O(n/2).
EDF è un algoritmo ottimo tra tutti gli algoritmi ad
assegnazione dinamica [Liu e Layland, 1973].
Un insieme di task periodici con periodo fisso è
schedulabile con EDF se e solo se:
n
U=
∑
i =1
Ci
≤1
Ti
16
Esempio
Dato il sistema di task periodici
Ci Ti
τ1 1 5
τ2 2 7
τ3 4 9
il fattore di utilizzazione U = 1/5 + 2/7+ 4/9 = 0.93
(93%)
La schedulabilità dell'insieme di task non è garantita
con l'algoritmo RM (U>0.78), mentre è sicuramenrte
fattibile con EDF (U<1).
Ciò perché EDF è dinamico.
17