Marco Coccia - appunti dalle lezioni dell`AA 2005-6

1
1.1
Concetti Introduttivi
Real time
Esistono vari livelli di real time:
Hard si garantisce che ogni job venga eseguito rigorosamente entro un certo
lasso di tempo (esempio: comandi per il movimento di un braccio
robotico). Se la risposta non arriva entro tale tempo la si considera
non corretta
Soft non si garantisce che ogni job sia eseguito entro un certo lasso di tempo
ma che verrà eseguito il prima possibile (Esempio: decodifica MP3)
Firm una via di mezzo tra Hard e Soft: alcuni job rispettano l’hard real
time, altri semplicemente il soft real-time.
1.2
Task e Job
task processo nella fase attiva: è una sequenza di istruzioni che deve essere
eseguita senza soluzioni di continuità
job frammento di un task
Figura 1: Task e job
1
1.3
Constraints (vincoli)
Si possono avere tre diversi tipi di vincoli da rispettare nell’ambito del real
time:
• Timing naturalmente i più importanti
• Precedenze derivanti dalla priorità di un task rispetto ad un altro
• Resources derivanti dalla condivisione di risorse comuni
1.3.1
DAG (Direct Activity Graph)
Sono grafi che permettono di rappresentare le precedenze.
Figura 2: Esempio di DAG
Nell’esempio J3 deve essere eseguito prima di J2 e J5 , J1 prima di J3 e J4 .
Si possono avere due tipi di precedenze:
precedenza immediata J1 → J3
precedenza non immediata J1 ≺ J5
1.3.2
Uso dei semafori
I semafori servono a bloccare una risorsa condivisa. Nel caso in cui si ha un
processo produttore ed uno consumatore che si scambiano le informazioni
attraverso la risorsa condivisa si applica la regola dei semafori affinché il
processo consumatore non acceda alla risorsa prima che il processo produttore ne abbia completato la modifica. L’uso dei semafori si attua attraverso
l’uso delle istruzioni WAIT e SIGNAL.
2
1.4
Lo Schedule
Poichè nello stato di ready ci potrebbe essere più di un job pronto per essere
eseguito c’è un elemento: lo schedule, che stabilisce quale job passerà nello
stato di esecuzione attraverso l’operazione di dispatch. Lo schedule opera
secondo un algoritmo di scheduling. Dato un insieme di task da schedulare
{J1 , . . . , Jn } la definizione formale di schedule è la seguente:
σ : R+ → {1, . . . , n}
∀t ∈ R+
0
0
∃t1 , t2 : t ∈ [t1 , t2 ) ∧ ∀t ∈ [t1 , t2) σ(t ) = σ(t)
se uno schedule è eseguibile si dice che esso è feasible (fattibile), in tal caso
Figura 3: Significato della definizione formale di schedule (σ = 0:idle)
il set di task {J1 , . . . , Jn } si dice schedulabile.
3
1.5
Tassonomia degli algoritmi di scheduling
preemptive se sopraggiunge un task avente priorità maggiore di quello in
esecuzione quest’ultimo verrà interrotto
non preemptive non esiste la possibilità di interrompere un task in esecuzione
static le decisioni sono basate su parametri fissi assegnati ai task prima
della loro attivazione
dynamic i parametri possono variare durante l’evoluzione del sistema
off line lo scheduling è effettuato prima dell’attivazione dei task
on line lo scheduling è effettuato ad ogni attivazione o termine di un task
optimal lo scheduling minimizza una qualche funzione di costo
euristic tende a minimizzare ma non garantisce
clairvoyant (chiaroveggenza) prevede l’arrivo di ogni nuovo task
4
Guarantee-based Algoritmi per hard real time. Devono garantire la feasibility ponendosi nell’ottica del Worst Case Scenario
statici algoritmi sofisticati ma lo schedule non supporta cambiamenti
dinamici ⇒ le ipotesi che portano ai WCEXi devono essere corrette altrimenti si rischia l’effetto domino.
Figura 4: Effetto domino: diagramma di Gant
Lo svantaggio di questo tipo di algoritmo è che un task potrebbe
essere inutilmente sacrificato
dinamici test di accettazione on-line J ∪ {Jt } è feasible
Figura 5: Schema di un algoritmo guarantee-based dinamico
Best-effort Algoritmi per il soft real time. Fanno del loro meglio ma non
garantiscono la feasibility dello schedule ⇒ un task può anche essere
abortito in fase di esecuzione
Mediamente tali algoritmi si comportano meglio dei guarantee-based
algorithms perché non presuppongono lo scenario del caso peggiore,
quindi un task è rigettato solo se all’atto pratico non si riesce a portarlo
a termine
5
Based on imprecise computation barattano l’accuratezza computazionale
per il soddisfacimento dei requisiti temporali. Ogni task τi è suddiviso
nelle sue due componenti:
mandatory Mi parte del task che deve essere eseguita in hard real
time
optional Oi parte del task che deve essere eseguita in soft real time
Figura 6: Algoritmo basato su imprecise computation: diagramma di Gant
σi : CPU time dedicata ad Oi dallo schedule (Parte opzionale del task
eseguita)
Errore ²i = Oi − σi
peso di ji : wi
errore medio ² =
n
X
wi · ²i
i=1
* Feasible : ogni M viene completato prima di d
i
i
(non occorre che anche Oi venga completato prima della deadline)
Schedule
Precise : ² = 0
6
1.6
Metriche
Figura 7: Metriche fondamentali
arrival time ai
start time si
computation time Ci tempo in cui il task è in escuzione senza interruzione
di tempo. Tale parametro solitamente è stimato facendo riferimento
al WCET (Worst Case Estimation Time)
finishing time fi
dead line assoluta di
deadline relativa Di = di − ai
lateness (latenza) Li = fi − di se tale parametro assume valore positivo
vuol dire che c’è stato uno sforo nella deadline
tardiness Ti = max(Li , 0) Ci dice di quanto si è attardato un task se
quest’ultimo si è attardato
laxity (lassità) xi = di − ai − Ci il gioco temporale che puù avere un task.
residual WCET(t) tempo di computazione rimasto in funzione del tempo. Utile nel caso in cui il task sia attualmente in esecuzione
Figura 8: residual WCET
Possiamo quindi ridefinire anche la lassità come li (t) = di −t−W CET (t)
criticalness (criticità)
value una sorta di criticità relativa: il peso del task nel contesto delle
criticità degli altri task
7
n
1 X
average response time tr = ·
(fi − ai )
n
i=1
total completion time tc =max(fi )−min(ai )
weighted sum of completion times tw =
n
X
wi · fi
i=1
maximum lateness Lmax =max(fi − di )
maximum number of late tasks Nlate
8
½
X
0 sefi < di
=
miss(fi ) con miss(fi ) =
1 altrimenti
1.7
Utility Function Non Real Time
Utility Function Soft Real Time
Utility Function On Time
Utility Function Firm Real Time
Utility functions
Le performances di un algoritmo di scheduling possono essere misurate da
parametri cumulativi
n
X
V =
v(fi )
i=1
9
1.8
Anomalie
Teorema 1 (Graham ’76) Se un insieme di task è schedulato ottimamente con un assegnamento di priorità, un numero fisso di processori, tempi
di esecuzione fissi ed assegnamento di precedenze, allora aumentare il numero di processori, ridurre i tempi di esecuzione o rilassare i vincoli di
precedenza può aumentare la durata dello schedule
Figura 9: Caso in cui minimizzare Lmax non minimizza Nlate
Figura 10: Caso in cui, in presenza di condivisione di risorse, un processore
veloce peggiora la schedulabilità
Figura 11: Caso in cui, in presenza di condivisione di risorse, il minor tempo
di arrivo di un task condiziona la schedulabilità
10
2
Scheduling Non real time
2.1
FCFS First Come First Served
Assegna la CPU ai task in base al loro ordine di arrivo.
• non preemptive
• dinamico
• on line
• best effort
È impredicibile: dato un task set, i tempi di risposta dipendono dalla
cronologia degli arrivi.
Esempio 1:
T R1 = 20
T R2 = 26 T R = 24
T R3 = 26
Figura 12: Scheduling di tipo FCFS: esempio 1
T R1 = 26
Esempio 2: T R2 = 8
T R3 = 2
T R = 12
Figura 13: Scheduling di tipo FCFS: esempio 2
11
2.2
SJF Shorted Job First
Seleziona il task con il più breve tempo di computazione
• statico (i Ci sono costanti)
• minimizza il tempo di risposta medio
Figura 14: Scheduling di tipo SJF
0
0
0
0
• visto che f2 = fP
2 e f0 1 < f1 si ha che f
1 + f2 < f1 + f2 quindi
P
TR (SJF) = n1 · (fi − ai ) ≤ n1 · (fi − ai ) = TR (σ)
• SJF e Real Time: benché minimizzi il tempo di risposta medio, non è
ottimale nel senso della feasibility
Figura 15: SJF: Scheduling non feasible
12
2.3
PS Priority Scheduling
Ad ogni task è associato un valore di priorità. Viene selezionato il task con
la maggiore priorità. A parità di priorità di adotta il FCFS o il RR.
• Preemptive
• On Line
• Starvation: i task a bassa priorità rishiano di non andare mai in
esecuzione ⇒ AGING: le priorità crescono con i tempi di attesa
• PS è una generalizzazione di SJF e FCFS. Lo schema seguente mostra
quando si ricade in tali casi
* P ∝
i
1
Ci
SJF
Pi ∝
1
ai
FCFS
PS =
13
2.4
RR Round Robin
La coda è gestita con una politica FCFS ma ogni task deve essere sospeso e
rimesso in coda allo scadere di un quanto di tempo (Q)
Figura 16: Round Robin
T Ri ' n · Q ·
Ci
= n · Ci
Q
dove n è il numero di task da schedulare
• Time Sharing ogni task ha a disposizione una CPU n volte più lenta
• se Q > max(Ci ) ⇒ FCFS
• δ: tempo necessario al cambiamento di contesto
Figura 17: Cambiamento di contesto nel Round Robin
T Ri ' n · (Q + δ) ·
se
⇒
Ci
Q+δ
= n · Ci · (
)
Q
Q
Q ' δ ⇒ T R i = 2 · n · Ci
il tempo di computazione di un task si raddoppia
14
2.5
Code a priorità diversa
Ci sono più code di processi con priorità decrescente gestite con una politica
Round Robin
Figura 18: Code a priorità diversa
1. lo scheduler prende il primo task nella coda RQk non vuota ed a
maggiore priorità e gli assegna la CPU per un quanto Q
2. se il task termina o si blocca prima di Q si torna ad (1)
3. al termine di Q il task va in RQk+1
4. all’attivazione o allo sblocco il task va in RQ0
5. periodicamente processi a lungo in coda possono essere scalati verso
l’alto
• i task partono tutti dalla maggiore priorità
• i task brevi terminano probabilmente più presto
• I/O-bound task è sempre eseguito subito
• CPU-bound task può andare nell’ultima coda
• in caso di sovraccarico i task CPU-bound vanno a turno in priorità
massima
15
3
3.1
Scheduling Real time
Scheduling di task Aperiodici
Sincrono
Task
indipendenti
Vincoli sulla
precedenza o
sulle risorse
1955
EDD
O(n · log(n))
Asincrono
Preemptive Non preemptive
1974
1971
EDF
Treee search
O(n2 )
O(n · n!)
1973
LDF
O(n2 )
1990
EDF*
O(n2 )
1987
SPRING
O(n2 )
Euristico
Tabella 1: Algoritmi di scheduling per task aperiodici
16
3.1.1
EDD Earliest Due Date
L’obiettivo è minimizzare Lmax
• 1 processore
• i tasks sono sincroni
Teorema 2 (Jackson ’74) Dato un insieme di tasks indipendenti,
ogni algoritmo che li manda in esecuzione con ordinamento crescente
rispetto alle deadline relative minimizza il tempo di latenza massimo
Figura 19: EDD: esempio
Lmax
σ:
= fB − dB
AB
0
;
σ :
Lmax
AB
0
0
0
= max(LA , LB )
0
Dimostriamo che Lmax (σ) è ottima: per ciò che riguarda σ possiamo
avere che:
0
se LB ≥ LA
0
se LA ≥ LB
0
0
⇒
Lmax
⇒
Lmax
0
0
= fB − dB < fB − dB =
AB
0
AB
0
= fA − dA < fB − dB =
Lmax
AB
Lmax
AB
quindi si dimostra quanto si voleva
• La complessità dell’algoritmo è uguale a quella di un ordinamento di
n elementi: O(n · log(n))
17
Esempio 1: Test di garanzia
Ci
di
J1
1
3
J2
1
10
J3
1
7
J4
3
8
J5
2
5
Figura 20: EDD Esempio 1
Lmax = L4 = −1
Esempio 2
Ci
di
J1
1
2
J2
2
5
J3
1
4
J4
4
8
J5
2
6
Figura 21: EDD Esempio 2
Lmax = L4 = 2
Il task set è dunque schedulabile se sono verificate le condizioni:
∀i ∈ {1, . . . , n}
i
X
Ck ≤ di
k=1
dove i è l’indice prodotto da EDD (tasks ordinati secondo le loro deadline
assolute)
18
3.1.2
EDF Earliest Deadline First
L’algoritmo opera in modo identico a EDD (l’obiettivo è sempre la minimizzazione di Lmax ) se non per il fatto che in questo caso si ha la preemption
Teorema 3 (Horn ’74) Dato un insieme di tasks indipendenti e con tempi
di arrivo arbitrari, ogni algoritmo che ad ogni istante esegue quello con la
deadline assoluta più imminente minimizza il tempo di latenza massimo
Esempio 1: Test di garanzia
ai
Ci
di
J1
0
1
2
J2
0
2
5
J3
2
2
4
J4
3
2
10
J5
6
2
9
Figura 22: EDF: esempio 1
se ci (t) è il tempo di esecuzione residuo di Ji all’istante t e se i task sono
indicizzati secondo EDF allora
fi =
i
X
ck (t)
k=1
il task set è allora schedulabile se sono verificate le:
i
X
∀i ∈ {1, . . . , n}
k=1
19
ck (t) < di
Non preemptive scheduling
Si ricade in questo caso se EDF non dovesse avere a disposizione la preemption della CPU
Esempio
J1 J2
ai
0
1
Trovare uno scheduling feasible e minimizzare la latenza masCi 4
2
di
7
5
Figura 23: EDF senza preemption
sima diviene NP-HARD.
Se EDF è non preemptive allora non è ottimale
20
3.1.3
Pruning Search Trees
È la tecnica più generale possibile
• 1 processore
• no preemption
• feasible
Esempio
J1
ai
4
Ci 2
di
7
J2
1
1
5
J3
1
2
6
J4
0
Il grafo da costruire ha n! foglie
2
4
Figura 24: Tree Search Esempio 1
Regole di potatura Algoritmo di Bratley (’71):
• smettere di cercare se si è già trovato (depth first)
• potare il ramo sul quale si è mancata una deadline
21
Scheduling feasible 1: J4 , J2 , J3 , J1
Figura 25: Tree Search: scheduling feasible 1
Scheduling feasible 2: J4 , J3 , J2 , J1
Figura 26: Tree Search: scheduling feasible 2
22
3.1.4
LDF Latest Deadline First
L’obiettivo, ancora una volta, è minimizzare Lmax ma in presenza di vincoli
di precedenza
• 1 processore
• tasks sincroni
• precedenze
• complessità O(n2 )
Teorema 4 (Lawler ’73) Produrre lo schedule risalendo dall’ultimo task
verso il primo. Ad ogni passo selezionare il task con la deadline più lontana
fra quelli che nel DAG delle precedenze non hanno più successori
Esempio
J1
Ci 1
di
2
J2
1
5
J3
1
4
J4
1
3
J5
1
5
J6
1
6
Figura 27: LDF: DAG delle precedenze
Figura 28: LDF schedula un task set che EDF non riesce a schedulare
23
3.1.5
EDF* (EDF con vincoli di precedenza)
EDF* nasce perché applicare EDF (scegliere il task con la deadline più vicina
fra gli elegibili) non è ottimo per Lmax sotto vincoli di precedenza
• 1 processore
• preemption
• precedenze
• minimizza Lmax
Teorema 5 (Chetto, Silly, Bouchentouf ’90) Lo scheduling di n tasks
con vincoli di precedenza e tempi di attivazione dinamici può essere risolto
in tempo polinomiale solo se i tasks sono interrompibili
Si tratta in pratica di operare la trasformazione J → J ∗ dove J ∗ non è
altro che J schedulabile nel rispetto dei vincoli di precedenza. Visto che,
secondo l’albero delle precedenze, ogni task non può iniziare prima di un
suo predecessore e non può interrompere un suo successore prima dobbiamo
1. modificare i tempi di rilascio (ai )
Dato il vincolo di precedenza Ja → Jb si ha che
½
sb ≥ ab
ossia ab ⇒ ab ∗ = max(ab , aa + Ca )
sb ≥ aa + Ca
Figura 29: EDF*: tempi di rilascio dei tasks
24
Algoritmo (O(n2 ))
(a) Per ogni nodo iniziale del DAG delle precedenze ai ∗ = ai
(b) Se esiste un task il cui tempo di rilascio non è stato modificato,
ma lo sono stati i tempi di rilascio di tutti i suoi propedeutici
allora selezionarlo come Ji altrimenti stop
(c) ai ∗ = max[ai , max(ah ∗ + Ch : Jh → Ji )]
(d) salta ad (1a)
2. modificare le deadlines (di )
Sempre secondo il vincolo di precedenza Ja → Jb si ha che
½
fa ≤ da
ossia da ⇒ da ∗ = min(da , db − Cb )
fa ≤ db − Cb
Figura 30: EDF*: deadlines dei tasks
Algoritmo (O(n2 ))
(a) Per ogni nodo terminale nel DAG delle precedenze di ∗ = di
(b) Se esiste un task la cui deadline non è stata modificata, ma lo
sono state tutte le deadline dei suoi immediati successori allora
selezionarlo come Ji altrimenti stop
(c) di ∗ = min[di , min(dh ∗ − Ch : Ji → Jh )]
(d) salta ad (2a)
3.1.6
Spring
Algoritmo euristico di complessità n2
25
3.2
3.2.1
Scheduling di task Periodici
Concetti fondamentali
Con la parola task, nel campo dei periodici, identifichiamo l’intero ciclo di
esecuzione mentre con la parola job identifichiamo il frammento di esecuzione
i-esimo. Facciamo le seguenti assunzioni:
Figura 31: Scheduling task periodici: tassonomia fondamentale
1. Ti costante
2. Ci costante
3. Di costante = Ti
4. non ci sono né precedenze né risorse esclusive
Che equivale a dire che, dato un task τi (φi , Ci , Ti )
• ri,k = φi + (k − 1) · Ti
• di,k = ri,k + Ti = φi + k · Ti
26
Altri parametri
response time di un job Ri,k = fi,k − ri,k
critical instant di un task: istante in cui il rilascio di un task produrrebbe
il maggior tempo di risposta
critical time zone di un task: intervallo fra il critical instant e il response
time della corrispondente richiesta del task
relative release jitter di un task: massima deviazione di start time di due
job consecutivi
RRJ i =
max
|(si,k − ri,k ) − (si,k−1 − ri,k−1 )|
k
absolute release jitter di un task: massima deviazione di start time fra
tutti i job
ARJ i =
max
min
(si,k − ri,k ) −
(si,k − ri,k )
k
k
relative finishing jitter di un task: massima deviazione di finishing time
di due job consecutivi
RF J i =
max
|(fi,k − ri,k ) − (fi,k−1 − ri,k−1 )|
k
absolute finishing jitter di un task: massima deviazione di finishing time
fra tutti i job
AF J i =
max
min
(fi,k − ri,k ) −
(fi,k − ri,k )
k
k
27
3.2.2
RM Rate monotonic
Ad ogni task è associata una priorità fissa proporzionale al suo rate (frequenza)
Figura 32: Rate Monotonic: Diagramma di Gant
• preemptive: il task correntemente in esecuzione è interrotto dall’arrivo
di uno a più elevato rate
Teorema 6 (Liv, Layland ’73) dato un task set Γ, se RM non può schedulare Γ, allora nessun altro algoritmo a priorità fissa può farlo
28
3.2.3
Processor utilization factor (U )
Ogni task utilizza la CPU per una frazione di tempo data da:
Ui =
Ci
Ti
per cui la misura di carico totale è
U=
n
X
Ci
i=1
Ti
Ovviamente se U > 1 → CPU overloaded: Γ non schedulabile ma U ≤ 1
non è condizione sufficiente per garantire la schedulabilità di Γ tramite RM
Figura 33: RM: U ≤ 1 ma Γ non schedulabile
U1 =
3
6
U2 =
4
9
17
3 4
+ =
<1
6 9
18
Quindi, come volevasi dimostrare U ≤ 1, non è una condizione sufficiente
per garantire la schedulabilità di Γ
U=
3.2.4
Utilization Upper Bound (UU B )
Figura 34: Utilization Upper Bound: Esempio
U1 =
3
6
U2 =
29
3
9
15
3 3
+ =
6 9
18
Se aumenta C1 o C2 allora τ2 manca la deadline. Quindi possiamo dire che
U = U1 + U2 =
U , UU B
cioè che U trovato è il massimo fattore di utilizzo della CPU relativamente
a quel task set e all’algoritmo di scheduling utilizzato:
UU B (Γ, A)
quindi, dato un algoritmo A, se U > UU B (Γ, A) allora Γ non è schedulabile
da A.
Fissiamo A (l’algoritmo di scheduling): UUAB (Γ). Sarebbe interessante sapere
A
se esiste un UUAB più piccolo di tutti e per quale Γ esso si ottiene: ULU
B.
Infatti
½ A
A
U (Γ) ≤ ULU
⇒ Γ certamente schedulabile da A
B
A
A
U (Γ) > ULU B Nulla può dirsi
Vediamo quanto vale ULU B per il Rate Monotonic:
Teorema 7 (Liv,Layland ’73) Il valore del Least Upper Bound per l’algoritmo Rate Monotonic può essere espresso dalla seguente formula
1
RM
n
ULU
B = n · (2 − 1)
dove n rappresenta il numero di task schedulati da Rate Monotonic
RM
lim ULU
B (n) = ln (2) = 0, 69
n→+∞
30
Conclusioni
Dato un task set Γ di n tasks da schedulare con priorità fissa, allora:
1. se è schedulabile da un qualche algoritmo, allora lo è sicuramente anche
per RM
RM allora Γ è sicuramente schedulabile da RM
2. se U (Γ) ≤ ULU
B
In pratica U (Γ) ≤ 0, 69 è una condizione sufficiente affinché il task-set sia
schedulabile con RM (non esiste una condizione necessaria).
Statisticamente anche task-set con U (Γ) = 0, 88 è schedulabile con RM.
Figura 35: Significato grafico del fattore ULU B per RM
31
3.2.5
EDF Earliest Deadline First
Si tratta di assegnare la CPU al job con la deadline assoluta più vicina
• dinamico
• la CPU può essere utilizzata al 100 %
• priorità dinamica
Figura 36: EDF: confronto con RM
Ricordando che
Γ schedulabile ] U (Γ) ≤ 1
enunciamo il seguente teorema:
Teorema 8 (Liv, Layland ’73)
EDF
ULU
B =1
quindi, visto che EDF (priorità variabile) è migliore di RM (priorità fissa)
nel senso di ULU B sarà migliore di tutti gli algoritmi a priorità fissa.
32
Esempio
τ1
τ2
φ
0
0
C
2
4
T
5
7
U=
2 4
+ ' 0, 97 > ln(2)
5 7
Figura 37: RM vs. EDF: scheduling secondo RM
Figura 38: RM vs. EDF: scheduling secondo EDF
Caratteristiche di RM:
• semplice da implementare
• più predicibile in caso di sovraccarico
Il motivo per cui si studia ancora RM è dovuto al fatto che, nel caso reale,
in cui si hanno task set con U > 1 ci saranno dei task che saranno comunque
eseguiti: quelli con priorità fissa maggiore.
Caratteristiche di EDF:
• più efficiente
• meno preemption
EDF comporta meno preemption di RM visto che i task a priorità minore
vengono interrotti meno volte da quelli a priorità maggiore.
33
3.2.6
Task periodici con D < T
Figura 39: Task periodici con D < T
3.2.7
DM Deadline Monotonic 1982
Ad ogni istante si seleziona il task con minore D (è molto simile a RM se si
sostituisce D con T)
• Pi ∝
1
Di
• statico
Esempio:
C
D
T
τ1
2
3
10
τ2
3
6
8
Figura 40: Deadline Monotonic: esempio
Ridefiniamo U per DM:
UDM
n
X
Ci
2 3
=
= + = 1, 16 > 1
Di
3 6
i=1
cioè UDM sovrastima il carico di lavoro
k
1 2 3 4
Response time (Ri,k = fi,k − ri,k ) τ1 2 2 2 2
τ2 5 5 3 3
Per k = 1 (corrispondente all’istante 5 della timeline
instant: l’istante in cui il rilascio del task produce
risposta.
34
5
2
3
di τ2 ) si ha il critical
il maggior tempo di
Calcolo delle interferenze
L’interferenza Ii sul task τi dovuta alla preemption dei tasks a maggiore
priorità, può essere espressa attraverso la formula
X
Ck
Ii =
Dk <Di
Per verificare dunque che Ri ≤ Di si deve calcolare Ri = Ci + Ii e dunque
Ii
Figura 41: esempio di interferenza
Definiamo interferenza di τk su τi nell’intervallo [0, Ri ]
» ¼
Ri
Iik =
· Ck
Tk
dove l’operazione dxe sta ad indicare il primo intero maggiore di x.
Interferenze dei task a maggiore priorità su τi
Ii =
¼
i−1 »
X
Ri
k=1
quindi
Ri = Ci +
Tk
· Ck
¼
i−1 »
X
Ri
k=1
35
Tk
· Ck
Esempio Deadline Monotonic
Dato il set di task nella seguente tabella
τ1
τ2
τ3
τ4
C
1
1
2
1
T
4
5
6
11
D
3
4
5
10
Priorità
Alta
—
—
Bassa
verificare che R4 ≤ D4 (è come verificare la schedulabilità visto che il task
τ4 è quello a minore priorità)
Figura 42: esempio di calcolo delle interferenze: diagramma di Gant
Cominciamo col cercare il tempo di risposta nel caso peggiore(naturalmente
relativo al task a minore priorità):
R4 = C4 + I4
con
I4 =
¼
3 »
X
R4
j=1
Tj
¼
» ¼
» ¼
R4
R4
R4
· Cj =
· C1 +
· C2 +
· C3
T1
T2
T3
(1)
»
(2)
Facciamo partire l’iterazione da I4 = 0, calcoliamo R4 con la (1) poi calcoliamo di volta in volta I4 applicando la (2) e R4 applicando la (1)
iterazione I4 R4
0 0
1
1 4
5
2 5
6
3 6
7
4 8
9
5 9 10
6 9 10
Stop
Arrestiamo l’iterazione perché gli ultimi due passi hanno prodotto gli I4
36
uguali tra loro (e di conseguenza anche gli R4 )
⇒ (R4 = 10) ≤ (D4 = 10)
quindi la condizione è soddisfatta.
Figura 43: esempio di calcolo delle interferenze: grafico interferenze/tempi
di risposta
Test di garanzia
Ri ≤ Di per tutti i tasks
Algoritmo
bool garantisci DM (Γ) {
for (ogni τi ∈ Γ) {
I = 0;
do {
R = I + Ci
if(R > Di ) return false;
i−1
X
R
I=
d e · Cj ;
Tj
j=1
} while(I + Ci > R);
}
return true;
}
37
3.2.8
EDF* (EDF con deadlines <dei periodi)
In questo tipo di algoritmo Pi ∝
sua deadline relativa
1
di
ossia la priorità di un job dipende dalla
Processor Demand : nell’intervallo [t1 , t2 ] è il tempo di computazione
richiesto dai tasks iniziati a partire da t1 che devono terminare per t2
P D(t1 , t2 ) =
dX
k ≤t2
Ck
rk ≥t1
Figura 44: Processor Demand: esempio. I task che vengono considerati
sono quelli che hanno sia la deadline che il tempo di arrivo all’interno
dell’intervallo
Ponendo φi = 0 ossia sincronizzando l’inizio dell’intervallo con l’arrivo del
task
Figura 45: Processor Demand: esempio con φ = 0
P D(0, L) =
º
n ¹
X
L − Di + Ti
Ti
i=1
· Ci
dove bxc sta per parte intera di x. Il parametro L assume, nel corso dell’analisi, il valore della deadline di ogni task
38
Processor Demand test: esempio 1
Verificare che ∀L P D(0, L) ≤ L
τ1
τ2
τ3
T
6
8
10
C
3
2
5
D
6
8
10
Figura 46: Processor Demand test: esempio 1
P D(6) =
P D(8) =
P D(10) =
P D(12) =
¹ º
¹ º
¹ º
6
6
6
·3+
·2+
·5=3≤6
6
8
10
¹ º
¹ º
¹ º
8
8
8
·3+
·2+
·5=5≤8
6
8
10
¹ º
¹ º
¹ º
10
10
10
·3+
·2+
· 5 = 10 ≤ 10
6
8
10
¹ º
¹ º
¹ º
12
12
12
·3+
·2+
· 5 = 13 > 12
6
8
10
39
⇒ time overflow
Processor Demand test: esempio 2 (D < T )
τ1
τ2
T
4
6
C
1
2
D
3
4
Figura 47: Processor Demand test: esempio 2 (D < T )
¹
P D(3) =
P D(4) =
P D(7) =
P D(10) =
º
¹
º
3−4+6
3−3+4
·1+
·2=1≤3
4
6
¹
º
¹
º
4−3+4
4−4+6
·1+
·2=3≤4
4
6
¹
º
¹
º
7−3+4
7−4+6
·1+
·2=4≤7
4
6
. . . = 6 ≤ 10
P D(11) = . . . = 7 ≤ 11
P D(15) = . . . = 8 ≤ 15
P D(16) = . . . = 10 ≤ 16
Visto che i task sono sincroni si può terminare l’analisi all’iperperiodo.
Si può limitare ulteriormente il numero di intervalli su cui applicare l’analisi
di schedulabilità.
Sia
H = mcm(T1 , . . . , Tn )
l’iperperiodo e
∗
L =
Pn
i=1 (Ti
− Di ) · Ui
1−U
allora bisogna controllare che
P D(0, L) ≤ L
∀ L ∈ {dk |dk ≤ min(H, L∗ )}
40
Figura 48: Esempio 2 di PDt: diagramma di raggiungibilità
3.2.9
Conclusioni sullo scheduling dei periodici
41
Priorità
Statiche
D=T
D <T
RM
Processor
Utilization
DM
Response Time
¼
i−1 »
X
Ri
· Cj ≤ Di
Ri = Ci +
Tj
1
U ≤ n · (2 n − 1)
j=1
Priorità
Dinamiche
EDF
Processor
Utilization
EDF*
Processor Demand
∀L > 0
º
n ¹
X
L − Di + Ti
· Ci
L≥
Ti
U ≤1
i=1
Tabella 2: Algoritmi di scheduling per task periodici
3.3
Scheduling di task Ibridi (periodici e aperiodici)
L’obiettivo è quello di ridurre i tempi di risposta dei task aperiodici senza
mettere a repentaglio la schedulabilità dei task periodici.
Lo scheduling degli aperiodici può essere di due tipi:
Hard lo scheduling degli aperiodici è garantito anche nel caso peggiore
• garanzia off-line solo per tasks sporadici (task con un tempo
minimo di interarrivo)
Soft lo scheduling degli aperiodici è eseguito ASAP (As Soon As Possible)
• garanzia on-line
• minimizza il tempo di risposta medio
3.3.1
Fixed Priority Servers
Si assumerà che:
• i tasks periodici siano schedulati con algoritmo a priorità fissa (tipicamente RM)
• i tasks periodici siano sincroni e con D = T
• non siano noti i tempi di arrivo dei task aperiodici
42
• il tempo minimo di interarrivo di un task aperiodico coincida con la
sua deadline relativa (gli aperiodici non si possono sovrapporre)
43
3.3.2
Background service
L’obiettivo è servire i tasks aperiodici quando non ci sono jobs da eseguire
Esempio 1:
Figura 49: Background Service. Principio di funzionamento
τ1
τ2
J
T
4
6
a
2
C
1
3
C
3
Figura 50: Esempio 1: periodici schedulati secondo EDF; aperiodico non
schedulato
Figura 51: Esempio1: scheduling secondo Immediate Service
44
Figura 52: Esempio1: scheduling secondo Background Service. Si evita la
deadline overflow presente nell’immediate service (figura (51))
Considerazioni su Background Service
Vantaggi:
• non influenza l’esecuzione dei task periodici
• semplicità
Svantaggi:
• se il fattore di utilizzo della CPU (U ) dei periodici è elevato allora il
tempo di risposta degli aperiodici può divenire inaccettabile
⇓
* U è bassa
BS è vantaggioso quando
C è bassa e T è alta
45
3.3.3
Servers per gli aperiodici
Un server per aperiodici è un task periodico esso stesso. La periodica attività
del kernel è dunque volta a controllare l’esecuzione dei task aperiodici. Un
server per aperiodici è caratterizzato da:
Capacità del server (C) È il tempo di computazione che può mettere a
disposizione dei task aperiodici che deve schedulare
Periodo del server (T ) Visto che il server è un task periodico tale parametro
caratterizza il task stesso
La morale sembra essere: al fine di preservare i tasks periodici, per ogni T
non devono essere eseguiti aperiodici per più di C Praticamente:
Figura 53: Server per aperiodici. Principio di funzionamento
• il server è schedulato come un task periodico
• il server gestisce i suoi task aperiodici con una qualunque politica di
scheduling
I servers per gli aperiodici si distinguono in base all’algoritmo di scheduling
usato per i task periodici (ricordiamo che il server è trattato alla stessa
stregua di un task periodico)
Algoritmo di scheduling
dei task periodici
Priorità fissa (RM o DM)
Priorità dinamica (EDF)
Algoritmi di scheduling
dei task ibridi
PS
DS
TBS
CBS
Tabella 3: Algoritmi di scheduling per task ibridi
• Periodici a Priorità Fissa (RM o DM)
– Polling Server (PS)
– Defferable Server (DS)
• Periodici a Priorità dinamica (EDF)
46
– Total Bandwidth Server (TBS)
– Constant Bandwidth Server (CBS)
47
3.3.4
PS Polling Server
Esempio:
τ1
τ2
server
C
1
2
2
T
4
6
5
Visto che il server ha un periodo minore di τ2 e che nel polling server lo
scheduling dei periodici avviene attraverso Rate Monotonic ⇒ il server
diventa prioritario sul task τ2 .
Riscriviamo la tabella nel rispetto delle precedenze
τ1
server
τ2
C
1
2
2
T
4
5
6
Priorità
alta
bassa
La tabella relativa ai task aperiodici è invece la seguente
J1
J2
J3
J4
a
2
8
12
19
C
2
1
2
1
Figura 54: Polling Server. Diagramma di Gant relativo all’esempio
• PS diviene attivo ogni Ts con capacità di servizio Cs
• se non ci sono aperiodici in coda allora Cs è annullata in favore dei
tasks periodici ⇒ se un aperiodico arriva dopo che il server si è
sospeso deve attendere la prossima attivazione
Possiamo dire qualcosa di rilevante in alcuni istanti di tempo riguardo il
server dell’esempio
48
istante 1 Il server perde immediatamente (dopo averla acquisita) la possibilità di schedulare task aperiodici perché non ha jobs da schedulare
istante 6 La capacità di servizio si è ridotta perché è stato servito un task
aperiodico
istante 11 La capacità di servizio non è stata sfruttata appieno e quindi
persa
istante 13 Ci sarebbe da servire un aperiodico ma il server non può perché
ha perso la sua capacità di servizio all’istante 11 non sfruttandola
istanti 16-17 La capacità di servizio viene mantenuta perché il task relativo al server è stato prelazionato dal task τ1 (a rate maggiore)
49
Analisi di schedulabilità
• nel caso peggiore, PS si comporta come un task periodico con Us =
Cs
Ts
• i server per task aperiodici possono essere più di uno (in generale m
server di tipo PS con diversa priorità) cosicché il fattore di utilizzo da
P
Cj
parte degli aperiodici diventa Us = m
j=1 Tj
• il fattore di utilizzo della CPU nei task set ibridi è dato dalla formula
Uibridi = Us + Up
dove Us è relativo agli m server dei task aperiodici mentre Up è relativo
ai task periodici (il cui numero, in generale, è n)
• affinché il task set sia schedulabile si dovrà avere Up + Us ≤ UU B (n, m)
• come al solito ci interessiamo del fattore ULU B . Tenendo conto del
fatto che i server non utilizzano al massimo la CPU possiamo scrivere
"µ
#
¶1
n
2
RM+PS
ULU
(n) = Us + n ·
−1
B
Us + 1
µ
per n → ∞
RM+PS
ULU
= Us + ln
B
RM+PS
Figura 55: Funzione ULU
B
50
2
Us + 1
¶
RM+PS
• Test di schedulabilità: se Up + Us ≤ ULU
allora il task set è
B
sicuramente schedulabile. Possiamo dunque scrivere che
µ
Up ≤ n ·
2
Us + 1
¶1
n
−n
Figura 56: Scelta di Us∗
⇒
Us∗ =
51
Cs∗
Ts∗
3.3.5
DS Defferable Server
In questo tipo di server la capacità di servizio non si scarica se non ci sono
aperiodici in attesa.
Esempio:
τ1
τ2
server
C
1
2
2
T
4
6
5
Figura 57: Defferable Server:Diagramma di Gant
Ha dei tempi di reazione minori rispetto al Polling Server visto che, non
scaricandosi, è molto più probabile trovare capacità di servizio nel server.
Esempio relativo ad un Deferrable Server con priorità alta
τ1
τ2
DS
C
2
3
2
T
8
10
6
52
Figura 58: Defferable Server: esempio con priorità alta
• DS viola RM che imporrebbe l’esecuzione del task a maggiore priorità
(infatti DS non va in esecuzione a t = 0)
• DS non è equivalente ad un task periodico come si può vedere dall’esempio seguente
C
2
2
T
4
5
Figura 59: RM con task periodici normali
Figura 60: RM con task aperiodici serviti da DS (DS si è sostituito a τ1
della figura (59)
53
L’overflow evidenziato non poteva essere provocato da un Polling Server. PS, infatti, anche se ritarda l’esecuzione degli aperiodici non compromette la schedulabilità di RM a differenza di DS che pur di eseguire
subito gli aperiodici compromette la schedulabilità di RM
• La presenza di server deferibili abbassa il minor limite superiore del
fattore di utilizzazione del processore da parte di RM; in sostanza
ULU B diventa minore di ln(2) = 0, 69 in presenza di DS
54
DS+RM: Analisi di schedulabilità
"µ
#
¶1
n
2 + Us
ULU B
= Us + n ·
−1
2 · Us + 1
¶
µ
2 + Us
RM+DS
per n → ∞
ULU
=
U
+
ln
s
B
2 · Us + 1
RM+DS
RM+DS
Figura 61: Funzione ULU
B
RM+DS
RM+PS
Come si può vedere dalla figura, ULU
è sempre peggiore di ULU
.
B
B
RM+DS
RM
Per Us < 0, 4 ULU B
è persino peggiore del valore di ULU B
Test di schedulabilità
µ
Us + Up ≤ Us + ln
2 + Us
2 · Us + 1
¶
µ
⇒
Up ≤ ln
2 + Us
2 · Us + 1
¶
Progetto del server DS
1. stabilire il fattore di utilizzo da parte dei task periodici Up
"µ
#
¶1
n
2 + Us
2. sostituire Up nella formula Up ≤ n ·
−1
2 · Us + 1
3. trovare UsM AX dalla precedente formula tenendo presente che il simbolo ≤ diventerà il simbolo =
4. stabilire Us ≤ UsM AX
5. scegliere Ts = min(T1 , . . . , Tn )
6. calcolare infine Cs = Ts · Us
55
3.3.6
TBS Total Bandwidth Server
Spuri - Buttazzo ’96
Il server non fa altro che fornire al task aperiodico in arrivo una deadline
tale da poter essere rispettata dandogli tutta la sua capacità di servizio
(bandwidth), poi fa in modo che il task venga schedulato con i periodici
secondo EDF
Figura 62: Total Bandwidth Server: principio di funzionamento
• Us è definita ampiezza di banda del server
• quando all’istante rk arriva il k-esimo aperiodico gli viene assegnata
una deadline dk
Ck
dk = rk +
Us
dove Ck è il tempo di computazione richiesto dall’aperiodico stesso
• ovviamente, per rendere il task set schedulabile Up + Us ≤ 1
56
Regola di assegnamento della deadline
Ricordiamo che l’obiettivo è quello di servire i periodici in hard real time e
servire gli aperiodici in soft real time.
Per stabilire la deadline di un aperiodico, oltre a considerare lo scheduling
dei task periodici bisogna considerare la banda assegnata ai task aperiodici
precedenti. Il tutto secondo la seguente formula
dk = max(rk , dk−1 ) +
Ck
Us
Esempio
τ1
τ2
C
3
2
D
6
8
3
3 2
+ =
6 8
4
Up =
r
C
J1
3
1
3+
J2
9
2
9+
J3
14
1
17 +
⇒
Us = 1 − Up =
1
4
D
1
1
4
2
1
4
1
1
4
=7
= 17
= 21
Figura 63: Total Bandwidth Server: esempio di assegnamento delle deadline
57
Analisi di schedulabilità
• EDF è in grado di schedulare l’intero task set se e solo se Up + Us ≤ 1
• Vantaggi di TBS rispetto ai servers a priorità fissa:
1. ha limite di schedulabilità maggiore (visto che non c’è di mezzo
RM con il suo ULU B = 0, 69 ma EDF che ha ULU B = 1)
2. migliora l’utilizzo della CPU: meno prelazioni grazie a EDF
3. aumenta la capacità di servizio degli aperiodici: viene sfruttata
tutta la banda rimasta inutilizzata dai task periodici
4. riduce i tempi di risposta degli aperiodici senza compromettere la
schedulabilità dei task periodici come invece fa Defferable Server
Inconveniente di TBS
• Premessa: l’obiettivo dei servers nei sistemi ibridi è quello di ridurre
il tempo di risposta medio degli aperiodici senza compromettere la
schedulabilità dei task periodici hard
• Problema: se un aperiodico tiene la CPU più di quanto stabilito i task
periodici hard possono perdere la loro deadline.
Tale inconveniente è ragionevole se si considera che TBS è ottimo in
tutto e per tutto
Figura 64: TBS: inconveniente
58
Soluzione al problema
In presenza di overrun bisogna ritardare solo il task aperiodico che l’ha
provocato (nessun task, infatti, dovrebbe chiedere più banda di quanta
dichiarata τ → U = C
T)
Figura 65: Total Bandwidth Server: soluzione all’inconveniente
59
Task Isolation
• ogni task dovrebbe aver assegnata una porzione di banda e non chiederne
di più
• l’isolation dei tasks si ottiene riservando banda (o meglio frazionandola)
• ogni task è gestito da un server dedicato con banda Us dove Us è il
fattore di utilizzazione della CPU da parte del server.
Nella figura che segue ogni server ha la sua banda Us
Figura 66: TBS: task isolation. Il server τx ha banda propria Usx
deve ovviamente valere che
n
X
USi ≤ 1
i=1
60
3.3.7
CBS Constant Bandwidth Server
È sotto studio ancora oggi. L’idea è quella di far si che non capiti mai che
un aperiodico riceva più banda di quanta il server ne ha (cosı̀ come accade
per il TBS). Il server ridà dunque all’aperiodico che non ha ancora finito
di essere eseguito la stessa capacità di servizio (una sorta di raddoppio del
budget) allungandogli però la deadline nel tempo.
• è un server per gli aperiodici con una capacità di servizio Qs ed un
s
periodo Ts tali per cui Q
Ts + Up = 1
• gestisce una coda di aperiodici con una politica arbitraria
• al task selezionato viene assegnata una deadline tale da non necessitare
s
banda maggiore di Q
Ts
• quando la capacità di servizio si scarica viene ricaricata immediatamente al suo valore massimo Qs , ma la deadline viene spostata in avanti in maniera da mantenere costante l’occupazione di banda del server
s
(Se Q
Ts = Us = costante raddoppiando Qs , affinché Us si mantenga
costante, dovrò raddoppiare anche Ts di conseguenza)
• ad ogni istante l’aperiodico servito ha l’ultima deadline generata dal
server
Esempio
Il fattore
di¶utilizzo della CPU da parte del server è pari a Us = 1 − Up =
µ
2 3
1
Qs
2
1−
+
= quindi il server avrà un periodo Ts =
= 1 = 6.
6 9
3
Us
3
Figura 67: Constant Bandwidth Server: esempio
istante 2 arriva un aperiodico con tempo di computazione pari a 3, il server
calcola la deadline dell’aperiodico in base alla sua capacità di servizio
(pari a 26 ), tale deadline risulta essere d1 all’istante 8. EDF manda in
61
esecuzione l’aperiodico visto che la sua deadline è minore sia di 9 che
di 12 (le deadline dei periodici)
istante 4 la capacità di servizio del server non è stata sufficiente a servire
l’aperiodico quindi la deadline d1 (istante 8) viene trasformata nella
deadline d2 che si trova 6 istanti di tempo più avanti (istante 14) e
viene ricaricata la capacità di servizio del server
istante 9 EDF decide che è la volta dello scheduling degli aperiodici visto
che le deadline dei periodici sono entrambe all’istante 18
istante 10 solo un’unità della capacità di servizio è stata consumata per
servire l’aperiodico, non essendoci altri aperiodici da servire si passa
ai task periodici, in particolare il job 2 di τ2
istante 12 viene servito il server per aperiodici in virtù del fatto che la
sua deadline è all’istante 14. Arriva un aperiodico con tempo di computazione pari a 3. Il server, avendo una capacità residua di 1 unità
decide di ricaricare la sua capacità di servizio al massimo e fissa la
deadline d3 all’istante 18 (12+6)
istante 14 la capacità di servizio del server, ancora una volta, non è sufficiente a servire l’aperiodico quindi la deadline d3 (istante 18) viene
trasformata nella deadline d4 (istante 24) e viene ricaricata la capacità
di servizio del server
istante 17 EDF analizza le varie deadline e decide che è la volta dell’aperiodico
istante 18 il server ha finito di servire l’aperiodico e rimne con una capacità
di servizio residua di una unità
istante 20 il server schedula l’aperiodico arrivato in quell’istante. Per far
ciò usa la sua capacità di servizio residua
Proprietà Gestisce meglio gli aperiodici rispetto a TBS; non ci sono cioè
finestre in cui la CPU è idle
isolamento se un task Ji è servito da CBS con ampiezza di banda Us ,
allora, per ogni intervallo di tempo ∆t, Ji non chiederà un tempo
CPU maggiore di Us · ∆t
schedulabilità hard un task Ji (Ci , Ti ) è schedulabile da CBS con Qs = Ci
e Ts = Ti se e solo se Ji è schedulabile con EDF
• EDF garantisce la gestione efficiente degli aperiodici
• l’isolamento annulla l’effetto dirompente degli overruns
62
• se è nota la distribuzione statistica dei Ci , allora è possibile fornire una
garanzia statistica per i Ji cioè: se si conosce la distribuzione statistica
degli aperiodici allora CBS diventa predicibile
63
4
Protocolli per l’accesso alle risorse
L’accesso concorrente a risorse mutuamente esclusive può comportare l’insorgenza del fenomeno inversione della priorità
Figura 68: Accesso ad una risorsa condivisa da parte di due spezzoni di
codice. SC sta per sezione critica
Figura 69: Risorse condivise: J1 pur essendo a priorità maggiore viene
bloccato da J2
purtroppo il tempo massimo per il quale il task ad alta priorità viene bloccato da quello a bassa priorità non è in generale limitato alla durata della
sezione critica di quest’ultimo per via degli annidamenti che si possono avere
tra sezioni critiche
64
Senza risorse condivise: casi in cui non si ha alcuna inversione
Figura 70: Senza risorse condivise: caso1
Figura 71: Senza risorse condivise: caso2
Figura 72: Senza risorse condivise: caso3
65
Stessi casi ma in presenza di risorse condivise
Figura 73: Risorse condivise: caso1
Figura 74: Risorse condivise: caso2
Figura 75: Risorse condivise: caso3
necessità di utilizzare protocolli per il controllo dell’accesso concorrente a
risorse condivise
66
4.1
NPP Non Preemptive Protocol
L’obiettivo è quello di impedire la preemption di un processo che sta eseguendo una sezione critica.
Per farlo basta alzare al massimo la priorità del processo che entra in una
sezione critica
Figura 76: NPP: diagramma di Gant
Inconveniente
Può andar bene solo per piccole sezioni critiche poiché comporta il blocco di
task ad alta priorità che non sono coinvolti nell’uso della risorsa condivisa
Figura 77: NPP: inconveniente
67
4.2
HLP Highest Locker Priority
Impedire la preemption di un processo che sta eseguendo una sezione critica solo da parte di un altro task che condivide la stessa risorsa. Per farlo
bisogna dare al processo che entra nella sua sezione critica la priorità più
alta fra i processi che condividono quella stessa risorsa
Figura 78: HLP: diagramma di Gant
Inconveniente
Il fatto che un processo condivida una risorsa non significa che la usi come
mostrato dalla figura seguente
Figura 79: HLP: inconveniente
68
4.3
PIP Priority Inheritance Protocol ’90
Un task deve aumentare la sua priorità solo se ne blocca altri, prendendo
temporaneamente la più alta priorità fra i processi bloccati
Figura 80: PIP: diagramma di Gant
il push-through blocking (blocco indotto dall’aumento della priorità) è il prezzo che si paga per limitare il direct blocking
69
Esempi con sezioni critiche innestate
Figura 81: PIP con sezioni critiche innestate: esempio. Notare che all’istante
5 non si revoca a τ3 la priorità ereditata all’istante 2 visto che si sta ancora
utilizzando la risorsa A
Figura 82: PIP con sezioni critiche innestate: esempio di eredità transitiva.
Tra l’istante 4 e 5 τ3 , visto che blocca τ2 , ne eredita la priorità
70
Identificare i tempi di blocco massimi
Un task τ può essere bloccato da una risorsa utilizzata da tasks a priorità
più bassa e:
1. condivisa con τ : direct blocking
2. condivisa con task a priorità più alta di τ : push-through blocking
ma
Teorema 9 τ può essere bloccato al massimo una volta da ciascun semaforo
relativo alle risorse
Figura 83: Risorse bloccate: τ1 e τ2 vengono bloccati una sola volta visto
che condividono una sola risorsa
Teorema 10 Considerando che
n numero dei tasks con priorità minore di τ
m numero dei semafori su cui τ si può bloccare (il numero di risorse condivise)
allora τ può bloccarsi al massimo per la durata di un numero di sezioni
critiche pari al minore fra n ed m
71
Inconvenienti relativi a PIP
• Chained blocking (concatenamento diretto) τ1 ha 2 sezioni critiche
Figura 84: inconvenienti di PIP: Chained blocking
(m = 2) e 2 processi a priorità inferiore (n = 2) per cui sperimenta
l’esperienza di due blocchi. Il problema, infatti, è che i blocchi si
concatenano. La soluzione a tale problema è l’uso del protocollo PCP
• Deadlock (blocco mortale) Impedisce che si possano portare a termine
dei task. Tutti i processi sono in attesa di un evento che può essere
provocato soltanto da uno di loro.
Figura 85: inconvenienti di PIP: Deadlock
Condizioni necessarie e sufficienti al verificarsi di un deadlock
1. mutua esclusione delle risorse
2. no preemption relase (non possono essere rilasciate le risorse)
3. hold & wait (un processo fa richiesta di una risorsa quando ne ha
già un’altra)
4. cicli (sono presenti dei cicli)
72
Figura 86: Loop che origina il deadlock
4.4
PCP Priority Ceiling Protocol
PCP estende PIP con una regola per garantire una richiesta di accesso ad
una risorsa mutuamente esclusiva.
Non viene permesso ad un task di entrare in una sua sezione critica se esistono altri semafori bloccati che potrebbero impedirgli di proseguire
⇓
una volta che il task entra in una sua sezione critica non può essere più
bloccato da processi a priorità minore
Implementazione: ad ogni semaforo viene assegnata una priorità fissa pari
alla priorità del task a priorità più alta fra quello che lo usano (priority
ceiling)
Regola: non si entra in una sezione critica se la priorità non è più alta di
qualsiasi priority ceiling di semafori in quel momento bloccati
Figura 87: Esempio PCP: scheduling secondo PIP
Ad ogni semaforo dunque si assegna un soffitto (C sta per ceiling)
C(sk ) = max{Pi : τi utilizza sk }
73
dopodiché un task τi entrerà in una sua sezione critica solo se
Pi > max{C(sk ) : sk è bloccato da τj 6= τi }
74
Esempio
Figura 88: Esempio PCP: Scheduling secondo PCP. Notare la differenza con
la figura 87
si assegnano i priority ceilings alle risorse condivise:
C(C) = P1
C(B) = P1
C(A) = P2
1. τ3 si attiva ed entra in A
2. τ2 si attiva e prelaziona τ3
3. τ2 chiede A ma PCP lo blocca perché P2 ≯ C(A)
4. τ3 entra in B perché non ci sono altri task a bloccare semafori
5. τ1 si attiva e prelaziona τ3
6. τ1 chiede C ma PCP lo blocca perché P1 ≯ C(B)
7. τ3 sblocca B, τ1 si sveglia e la priorità di τ3 ritorna a p2 (perché ora la
sola risorsa bloccata è A di priorità P2 ). A questo punto P1 > C(A)
quindi τ1 prelaziona τ3 e va fino alla fine.
8. τ3 riprende a priorità p2
9. τ3 sblocca A, τ2 si sveglia e la priorità di τ3 ritorna a quella nominale.
A questo punto τ2 prelaziona τ3 e va fino alla fine
10. τ2 completa e τ3 va fino alla fine
75
Chained blocking
C(A) = P1
C(B) = P1
Figura 89: PCP: Chained blocking
Prima di permettere a τ2 di accedere a B bisogna andare a vedere quali
sono le risorse bloccate in quel momento: troviamo bloccata A il cui priority
ceiling è associato a τ1 . Con PIP, invece, non si entrava in B solo se B era
bloccato.
A differenza di PIP, τ1 è stato bloccato una sola volta e questo privilegio è
dovuto al fatto che è il task a priorità più alta.
Deadlock
C(A) = P1
C(B) = P1
Figura 90: PCP: Deadlock
ceiling blocking blocco provocato dalla regola PCP
τ2 entra anche in B perché l’unica risorsa bloccata è A che è lui stesso a
bloccare quindi la regola non si applica non si verifica mai il deadlock
76
Schedulabilità di PIP e PCP
Dato un generico task τi di un set di n tasks cosı̀ come in figura
Figura 91: Tempi di blocco e prelazione responsabili dell’attardamento di
un task
bisogna stimare il tempo di blocco Bi , tale tempo di blocco è causato dal fatto che τi condivide risorse con task a priorità più bassa della sua; dopodiché
sotto RM bisogna verificare che valgono le n disequazioni
∀i
i−1
X
Ck
k=1
Tk
+
1
Ci + Bi
≤ i · (2 i − 1)
Ti
stimiamo il tempo di blocco nel caso si abbiano tre task:
per i = 3
2
X
Ck
k=1
Tk
+
1
C3
≤ 3 · (2 3 − 1)
T3
B3 = 0 perché τ3 non può essere bloccato
per i = 2
1
X
Ck
k=1
Tk
per i = 1
+
1
C2 + B2
≤ 2 · (2 2 − 1)
T2
C1 + B1
≤1
T1
dove i valori di B2 e di B1 devono essere valutati
77
4.5
SRP Stack Resource Policy
1. Risorse multiunit
2. EDF
3. Condivisione stack di risorse
mentre in PIP ed in PCP un task viene bloccato quando tenta di accedere ad
una risorsa, con SRP questo viene bloccato già quando tenta di prelazionare
il task concorrente
⇓
1. Riduzione concorrenza
2. Riduce i cambi di contesto
3. Semplifica l’implementazione
4. Consente la condivisione a run-time di uno stack di risorse
Si possono definire i seguenti parametri per τi :
Priority Pi dinamico
Preemption Level πi statico
un task τi può prelazionare un altro task τj solo se πi > πj .
Sia con RM (priorità fissa) che con EDF (priorità dinamica) potremmo per
esempio porre:
πi =
78
1
Ti
Resource ceiling
R risorsa
nR numero di unità di R attualmente disponibili
µR (τ ) massima richiesta di R da parte di τ
CR Current ceiling: funzione di nR definito come:
CR (nR ) = max[{0} ∪ {π(τ ) : nR < µR (τ )}]
se nR non può soddisfare uno o più tasks allora CR è dato dal massimo
livello di prelazione fra i tasks potenzialmente bloccabili da R.
Se la risorsa è di una sola unità la formula precedente si riduce alla
seguente:
CR = max[{0} ∪ {π(τ ) : R può bloccare τ }]
Dynamic System Ceiling
πs (t) = max(CRi : i = 1, . . . , m)
79
Resource Ceiling - Esempio
Tasks: τ1
τ2
τ3
Resources:
R1 R2 R3
◦
¤
4
◦
4
◦
4
D π µR1
τ1 5 3
1
τ2 10 2
2
τ3 20 1
3
µR2
0
1
1
µR3
1
3
1
⇓
R1
R2
R3
CR (3)
0
0
CR (2)
1
2
CR (1)
2
0
2
CR (0)
3
2
3
Facciamo un esempio per far vedere come la precedente tabella va letta:
CR (3)
R1
0
0 esprime qual’è la massima priorità tra tutti i task che utilizzano più di
3 unità di R1 a disposizione o meglio la criticità della situazione nel caso si
abbiano 3 unità di risorsa R1 a disposizione. Tale fattore può andare da un
minimo di 0 ad un massimo di 3 visto che 3 sono i livelli di priorità.
Il Dynamic System Ceiling in questo caso è πs (t) = 3.
Protocollo
In definitiva, affinché un job possa prelazionare la CPU non basta che abbia
la più alta priorità fra tutti i jobs pronti, ma è necessario pure che il suo
livello di prelazione sia più alto del dynamic system ceiling
80
Esempio
Figura 92: Esempio SRP: spaccato di codice. Nelle chiamate al WAIT, oltre
a specificare la risorsa si specifica anche il valore di µR
τ1
τ2
τ3
R1
R2
R3
π
3
2
1
CR (3) CR (2) CR (1)
0
1
2
0
0
0
0
2
2
µR1 µR2 µR3
1
1
2
1
3
3
1
1
CR (0)
3
2
3
Figura 93: Esempio SRP: diagramma di Gant
81
Proprietà
• una volta che un task parte non può essere più bloccato ma solo
prelazionato da tasks a più alta priorità
• non c’è deadlock
• se non ha abbastanza risorse per lavorare un task evita di prelazionare
la CPU riducendo cosı̀ i cambiamenti di contesto
• il peggior ritardo che può subire un task è dato dalla più lunga sezione
critica presente nei task sottostanti
• è l’unico protocollo in grado di lavorare sia con EDF che con RM (a
differenza di PIP e PCP che possono lavorare solo con RM)
• un task set può essere schedulato sotto EDF + SRP se
!
à i
X Ck
Bi
+
∀i : 1 ≤ i ≤ n
≤1
Tk
Ti
k=1
82
Condivisione stack
L’obiettivo è quello di risparmiare RAM condividendo lo stack fra tasks
diversi
In generale lo stack può essere condiviso da tasks che non si alternano
Figura 94: Task interlacciati e non interlacciati
Quando si ha una struttura di tipo non interlacciato si può lavorare con un
solo stack cosı̀ come illustrato nella figura che segue
Figura 95: Stack
83
Conclusioni
assegnamento
priorità
numero di blocchi
momento di
bloccaggio
trasparenza
prevenzione
deadlock
implementazione
calcolo del tempo
di blocco
PIP
fisso
PCP
fisso
min(n,m)
all’accesso
alla risorsa
si
no
1
all’accesso
alla risorsa
no
si
SRP
fisso o
dinamico
1
alla
prelazione
no
si
complessa
pesante
media
leggero
semplice
leggero
Tabella 4: Protocolli per l’accesso alle risorse
84
Indice
1 Concetti Introduttivi
1.1 Real time . . . . . . . . . . . . . . . . .
1.2 Task e Job . . . . . . . . . . . . . . . . .
1.3 Constraints (vincoli) . . . . . . . . . . .
1.3.1 DAG (Direct Activity Graph) . .
1.3.2 Uso dei semafori . . . . . . . . .
1.4 Lo Schedule . . . . . . . . . . . . . . . .
1.5 Tassonomia degli algoritmi di scheduling
1.6 Metriche . . . . . . . . . . . . . . . . . .
1.7 Utility functions . . . . . . . . . . . . .
1.8 Anomalie . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
2
2
2
3
4
7
9
10
2 Scheduling Non real time
2.1 FCFS First Come First Served
2.2 SJF Shorted Job First . . . . .
2.3 PS Priority Scheduling . . . . .
2.4 RR Round Robin . . . . . . . .
2.5 Code a priorità diversa . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
13
14
15
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
17
19
21
23
24
25
26
26
28
29
29
32
34
34
38
41
42
42
44
46
48
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Scheduling Real time
3.1 Scheduling di task Aperiodici . . . . . . . . . . .
3.1.1 EDD Earliest Due Date . . . . . . . . . .
3.1.2 EDF Earliest Deadline First . . . . . . . .
3.1.3 Pruning Search Trees . . . . . . . . . . .
3.1.4 LDF Latest Deadline First . . . . . . . .
3.1.5 EDF* (EDF con vincoli di precedenza) .
3.1.6 Spring . . . . . . . . . . . . . . . . . . . .
3.2 Scheduling di task Periodici . . . . . . . . . . . .
3.2.1 Concetti fondamentali . . . . . . . . . . .
3.2.2 RM Rate monotonic . . . . . . . . . . . .
3.2.3 Processor utilization factor (U ) . . . . . .
3.2.4 Utilization Upper Bound (UU B ) . . . . . .
3.2.5 EDF Earliest Deadline First . . . . . . . .
3.2.6 Task periodici con D < T . . . . . . . . .
3.2.7 DM Deadline Monotonic 1982 . . . . . . .
3.2.8 EDF* (EDF con deadlines <dei periodi) .
3.2.9 Conclusioni sullo scheduling dei periodici
3.3 Scheduling di task Ibridi (periodici e aperiodici)
3.3.1 Fixed Priority Servers . . . . . . . . . . .
3.3.2 Background service . . . . . . . . . . . . .
3.3.3 Servers per gli aperiodici . . . . . . . . . .
3.3.4 PS Polling Server . . . . . . . . . . . . . .
85
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.3.5
3.3.6
3.3.7
DS Defferable Server . . . . . . . . . . . . . . . . . . .
TBS Total Bandwidth Server . . . . . . . . . . . . . .
CBS Constant Bandwidth Server . . . . . . . . . . . .
4 Protocolli per l’accesso alle risorse
4.1 NPP Non Preemptive Protocol . . .
4.2 HLP Highest Locker Priority . . . .
4.3 PIP Priority Inheritance Protocol ’90
4.4 PCP Priority Ceiling Protocol . . . .
4.5 SRP Stack Resource Policy . . . . .
86
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
56
61
64
67
68
69
73
78