1 Concetti Introduttivi

1 Concetti Introduttivi 1.1 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 J 3 deve essere eseguito prima di J 2 e J 5, J 1 prima di J 3 e J 4. Si possono avere due tipi di precedenze: precedenza immediata J 1 J 3 precedenza non immediata J 1 J 5 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 {J 1,..., J n } la definizione formale di schedule è la seguente: σ : R + {1,..., n} t R + t 1, t 2 : t [t 1, t 2 ) t [t 1, 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 {J 1,..., J n } 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 WCEX i 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 {J t } è 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 M i parte del task che deve essere eseguita in hard real time optional O i 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 O i dallo schedule (Parte opzionale del task eseguita) Errore ɛ i = O i σ i peso di j i : w i errore medio ɛ = n w i ɛ i i=1 Schedule Feasible : ogni Mi viene completato prima di d i (non occorre che anche O i venga completato prima della deadline) Precise : ɛ = 0 6

1.6 Metriche Figura 7: Metriche fondamentali arrival time a i start time s i computation time C i 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 f i dead line assoluta d i deadline relativa D i = d i a i lateness (latenza) L i = f i d i se tale parametro assume valore positivo vuol dire che c è stato uno sforo nella deadline tardiness T i = max(l i, 0) Ci dice di quanto si è attardato un task se quest ultimo si è attardato laxity (lassità) x i = d i a i C i 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 l i (t) = d i t W CET (t) criticalness (criticità) value una sorta di criticità relativa: criticità degli altri task il peso del task nel contesto delle 7

average response time t r = 1 n n (f i a i ) i=1 total completion time t c =max(f i ) min(a i ) weighted sum of completion times t w = maximum lateness L max =max(f i d i ) n w i f i maximum number of late tasks N late = miss(f i ) con miss(f i ) = i=1 { 0 sefi < d i 1 altrimenti 8

Utility Function Non Real Time Utility Function Soft Real Time Utility Function On Time Utility Function Firm Real Time 1.7 Utility functions Le performances di un algoritmo di scheduling possono essere misurate da parametri cumulativi n V = v(f i ) 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 L max non minimizza N late 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 R 1 = 20 T R 2 = 26 T R = 24 T R 3 = 26 Figura 12: Scheduling di tipo FCFS: esempio 1 Esempio 2: T R 1 = 26 T R 2 = 8 T R = 12 T R 3 = 2 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 C i sono costanti) minimizza il tempo di risposta medio Figura 14: Scheduling di tipo SJF visto che f 2 = f 2 e f 1 < f 1 si ha che f 1 + f 2 < f 1 + f 2 quindi T R (SJF) = 1 n (f i a i ) 1 n (f i a i ) = T R (σ) 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 PS = Pi 1 C i SJF P i 1 a i FCFS 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 R i n Q Ci Q = n C i dove n è il numero di task da schedulare Time Sharing ogni task ha a disposizione una CPU n volte più lenta se Q > max(c i ) FCFS δ: tempo necessario al cambiamento di contesto Figura 17: Cambiamento di contesto nel Round Robin T R i n (Q + δ) Ci Q = n C i ( Q + δ Q ) se Q δ T R i = 2 n C i 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 RQ k 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 RQ k+1 4. all attivazione o allo sblocco il task va in RQ 0 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 Scheduling Real time 3.1 Scheduling di task Aperiodici Sincrono Asincrono Preemptive Non preemptive 1955 1974 1971 Task EDD EDF Treee search indipendenti O(n log(n)) O(n 2 ) O(n n!) 1973 1990 1987 Vincoli sulla LDF EDF* SPRING precedenza o O(n 2 ) O(n 2 ) O(n 2 ) sulle risorse Euristico Tabella 1: Algoritmi di scheduling per task aperiodici 16

3.1.1 EDD Earliest Due Date L obiettivo è minimizzare L max 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 σ : L max AB = f B d B ; σ : L max AB = max(l A, L B ) Dimostriamo che L max (σ) è ottima: per ciò che riguarda σ avere che: possiamo se L B L A L max AB = f B d B < f B d B = L max AB se L A L B L max AB = f A d A < f B d B = L max 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 J 1 J 2 J 3 J 4 J 5 C i 1 1 1 3 2 d i 3 10 7 8 5 Figura 20: EDD Esempio 1 L max = L 4 = 1 Esempio 2 J 1 J 2 J 3 J 4 J 5 C i 1 2 1 4 2 d i 2 5 4 8 6 Figura 21: EDD Esempio 2 L max = L 4 = 2 Il task set è dunque schedulabile se sono verificate le condizioni: i {1,..., n} i C k d i dove i è l indice prodotto da EDD (tasks ordinati secondo le loro deadline assolute) k=1 18

3.1.2 EDF Earliest Deadline First L algoritmo opera in modo identico a EDD (l obiettivo è sempre la minimizzazione di L max ) 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 J 1 J 2 J 3 J 4 J 5 a i 0 0 2 3 6 C i 1 2 2 2 2 d i 2 5 4 10 9 Figura 22: EDF: esempio 1 se c i (t) è il tempo di esecuzione residuo di J i all istante t e se i task sono indicizzati secondo EDF allora f i = i c k (t) k=1 il task set è allora schedulabile se sono verificate le: i {1,..., n} i c k (t) < d i k=1 19

Non preemptive scheduling Si ricade in questo caso se EDF non dovesse avere a disposizione la preemption della CPU Esempio J 1 J 2 a i 0 1 Trovare uno scheduling feasible e minimizzare la latenza mas- C i 4 2 d i 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 J 1 J 2 J 3 J 4 a i 4 1 1 0 C i 2 1 2 2 d i 7 5 6 4 Il grafo da costruire ha n! foglie 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: J 4, J 2, J 3, J 1 Figura 25: Tree Search: scheduling feasible 1 Scheduling feasible 2: J 4, J 3, J 2, J 1 Figura 26: Tree Search: scheduling feasible 2 22

3.1.4 LDF Latest Deadline First L obiettivo, ancora una volta, è minimizzare L max ma in presenza di vincoli di precedenza 1 processore tasks sincroni precedenze complessità O(n 2 ) 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 J 1 J 2 J 3 J 4 J 5 J 6 C i 1 1 1 1 1 1 d i 2 5 4 3 5 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 L max sotto vincoli di precedenza 1 processore preemption precedenze minimizza L max 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 (a i ) Dato il vincolo di precedenza J a J b si ha che { sb a b s b a a + C a ossia a b a b = max(a b, a a + C a ) Figura 29: EDF*: tempi di rilascio dei tasks 24

Algoritmo (O(n 2 )) (a) Per ogni nodo iniziale del DAG delle precedenze a i = a i (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 J i altrimenti stop (c) a i = max[a i, max(a h + C h : J h J i )] (d) salta ad (1a) 2. modificare le deadlines (d i ) Sempre secondo il vincolo di precedenza J a J b si ha che { fa d a f a d b C b ossia d a d a = min(d a, d b C b ) Algoritmo (O(n 2 )) Figura 30: EDF*: deadlines dei tasks (a) Per ogni nodo terminale nel DAG delle precedenze d i = d i (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 J i altrimenti stop (c) d i = min[d i, min(d h C h : J i J h )] (d) salta ad (2a) 3.1.6 Spring Algoritmo euristico di complessità n 2 25

3.2 Scheduling di task Periodici 3.2.1 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. T i costante 2. C i costante 3. D i costante = T i 4. non ci sono né precedenze né risorse esclusive Che equivale a dire che, dato un task τ i (φ i, C i, T i ) r i,k = φ i + (k 1) T i d i,k = r i,k + T i = φ i + k T i 26

Altri parametri response time di un job R i,k = f i,k r i,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 k (s i,k r i,k ) (s i,k 1 r i,k 1 ) absolute release jitter di un task: massima deviazione di start time fra tutti i job ARJ i = max k (s i,k r i,k ) min k (s i,k r i,k ) relative finishing jitter di un task: massima deviazione di finishing time di due job consecutivi RF J i = max k (f i,k r i,k ) (f i,k 1 r i,k 1 ) absolute finishing jitter di un task: massima deviazione di finishing time fra tutti i job AF J i = max k (f i,k r i,k ) min k (f i,k r i,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: per cui la misura di carico totale è U i = C i T i U = n i=1 C i T i 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 U 1 = 3 6 U 2 = 4 9 U = 3 6 + 4 9 = 17 18 < 1 Quindi, come volevasi dimostrare U 1, non è una condizione sufficiente per garantire la schedulabilità di Γ 3.2.4 Utilization Upper Bound (U UB ) Figura 34: Utilization Upper Bound: Esempio U 1 = 3 6 U 2 = 3 9 29

U = U 1 + U 2 = 3 6 + 3 9 = 15 18 Se aumenta C 1 o C 2 allora τ 2 manca la deadline. Quindi possiamo dire che U U UB cioè che U trovato è il massimo fattore di utilizzo della CPU relativamente a quel task set e all algoritmo di scheduling utilizzato: U UB (Γ, A) quindi, dato un algoritmo A, se U > U UB (Γ, A) allora Γ non è schedulabile da A. Fissiamo A (l algoritmo di scheduling): UUB A (Γ). Sarebbe interessante sapere se esiste un UUB A più piccolo di tutti e per quale Γ esso si ottiene: U LUB A. Infatti { U A (Γ) ULUB A Γ certamente schedulabile da A U A (Γ) > U A LUB Nulla può dirsi Vediamo quanto vale U LUB 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 U RM LUB = n (2 1 n 1) dove n rappresenta il numero di task schedulati da Rate Monotonic lim U RM n + LUB(n) = ln (2) = 0, 69 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 2. se U(Γ) U RM LUB allora Γ è sicuramente schedulabile da RM 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 U LUB 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 Ricordando che enunciamo il seguente teorema: Teorema 8 (Liv, Layland 73) Figura 36: EDF: confronto con RM Γ schedulabile U(Γ) 1 U EDF LUB = 1 quindi, visto che EDF (priorità variabile) è migliore di RM (priorità fissa) nel senso di U LUB sarà migliore di tutti gli algoritmi a priorità fissa. 32

Esempio φ C T τ 1 0 2 5 τ 2 0 4 7 U = 2 5 + 4 7 0, 97 > ln(2) Figura 37: RM vs. EDF: scheduling secondo RM Caratteristiche di RM: Figura 38: RM vs. EDF: scheduling secondo EDF 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) P i 1 D i statico Esempio: τ 1 τ 2 C 2 3 D 3 6 T 10 8 Ridefiniamo U per DM: Figura 40: Deadline Monotonic: esempio U DM = n i=1 C i = 2 D i 3 + 3 = 1, 16 > 1 6 cioè U DM sovrastima il carico di lavoro k 1 2 3 4 5 Response time (R i,k = f i,k r i,k ) τ 1 2 2 2 2 2 τ 2 5 5 3 3 3 Per k = 1 (corrispondente all istante 5 della timeline di τ 2 ) si ha il critical instant: l istante in cui il rilascio del task produce il maggior tempo di risposta. 34

Calcolo delle interferenze L interferenza I i sul task τ i dovuta alla preemption dei tasks a maggiore priorità, può essere espressa attraverso la formula I i = D k <D i C k Per verificare dunque che R i D i si deve calcolare R i = C i + I i e dunque I i Figura 41: esempio di interferenza Definiamo interferenza di τ k su τ i nell intervallo [0, R i ] Ri I ik = C k dove l operazione x sta ad indicare il primo intero maggiore di x. Interferenze dei task a maggiore priorità su τ i i 1 I i = k=1 T k Ri T k C k quindi i 1 R i = C i + k=1 Ri T k C k 35

Esempio Deadline Monotonic Dato il set di task nella seguente tabella C T D Priorità τ 1 1 4 3 Alta τ 2 1 5 4 τ 3 2 6 5 τ 4 1 11 10 Bassa verificare che R 4 D 4 (è 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à): R 4 = C 4 + I 4 (1) con I 4 = 3 j=1 R4 T j C j = R4 T 1 C 1 + R4 T 2 C 2 + R4 T 3 C 3 (2) Facciamo partire l iterazione da I 4 = 0, calcoliamo R 4 con la (1) poi calcoliamo di volta in volta I 4 applicando la (2) e R 4 applicando la (1) iterazione I 4 R 4 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 I 4 36

uguali tra loro (e di conseguenza anche gli R 4 ) quindi la condizione è soddisfatta. (R 4 = 10) (D 4 = 10) Figura 43: esempio di calcolo delle interferenze: grafico interferenze/tempi di risposta Test di garanzia R i D i per tutti i tasks Algoritmo bool garantisci DM (Γ) { for (ogni τ i Γ) { I = 0; do { R = I + C i if(r > D i ) return false; i 1 I = R C j ; T j j=1 } while(i + C i > R); } return true; } 37

3.2.8 EDF* (EDF con deadlines <dei periodi) In questo tipo di algoritmo P i 1 d i sua deadline relativa ossia la priorità di un job dipende dalla Processor Demand : nell intervallo [t 1, t 2 ] è il tempo di computazione richiesto dai tasks iniziati a partire da t 1 che devono terminare per t 2 P D(t 1, t 2 ) = d k t 2 r k t 1 C k 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 L Di + T i C i i=1 dove x sta per parte intera di x. Il parametro L assume, nel corso dell analisi, il valore della deadline di ogni task T i 38

Processor Demand test: esempio 1 Verificare che L P D(0, L) L T C D τ 1 6 3 6 τ 2 8 2 8 τ 3 10 5 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 time overflow 6 8 10 39

Processor Demand test: esempio 2 (D < T ) T C D τ 1 4 1 3 τ 2 6 2 4 Figura 47: Processor Demand test: esempio 2 (D < T ) 3 3 + 4 3 4 + 6 P D(3) = 1 + 2 = 1 3 4 6 4 3 + 4 4 4 + 6 P D(4) = 1 + 2 = 3 4 4 6 7 3 + 4 7 4 + 6 P D(7) = 1 + 2 = 4 7 4 6 P D(10) =... = 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(t 1,..., T n ) l iperperiodo e L = allora bisogna controllare che n i=1 (T i D i ) U i 1 U P D(0, L) L L {d k d k min(h, L )} 40

Figura 48: Esempio 2 di PDt: diagramma di raggiungibilità 3.2.9 Conclusioni sullo scheduling dei periodici 41

D=T D <T RM DM Priorità Processor Statiche Utilization Response Time i 1 U n (2 1 Ri n 1) R i = C i + C j D i j=1 T j EDF EDF* Priorità Processor Processor Demand Dinamiche Utilization L > 0 n L Di + T i U 1 L C i i=1 T i 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 T C τ 1 4 1 τ 2 6 3 a C J 2 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 BS è vantaggioso quando U è bassa 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 Algoritmi di scheduling dei task periodici dei task ibridi Priorità fissa (RM o DM) PS DS Priorità dinamica (EDF) 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: C T τ 1 1 4 τ 2 2 6 server 2 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 C T Priorità τ 1 1 4 alta server 2 5 - τ 2 2 6 bassa La tabella relativa ai task aperiodici è invece la seguente a C J 1 2 2 J 2 8 1 J 3 12 2 J 4 19 1 Figura 54: Polling Server. Diagramma di Gant relativo all esempio PS diviene attivo ogni T s con capacità di servizio C s se non ci sono aperiodici in coda allora C s è 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 U s = Cs T s 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 parte degli aperiodici diventa U s = m j=1 il fattore di utilizzo della CPU nei task set ibridi è dato dalla formula C j T j U ibridi = U s + U p dove U s è relativo agli m server dei task aperiodici mentre U p è relativo ai task periodici (il cui numero, in generale, è n) affinché il task set sia schedulabile si dovrà avere U p +U s U UB (n, m) come al solito ci interessiamo del fattore U LUB. Tenendo conto del fatto che i server non utilizzano al massimo la CPU possiamo scrivere [ ( ) 1 ] U RM+PS 2 n LUB (n) = U s + n 1 U s + 1 per n U RM+PS LUB ( ) 2 = U s + ln U s + 1 Figura 55: Funzione U RM+PS LUB 50

Test di schedulabilità: se U p + U s U RM+PS LUB allora il task set è sicuramente schedulabile. Possiamo dunque scrivere che ( ) 1 2 n U p n n U s + 1 Figura 56: Scelta di U s U s = C s T s 51

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: C T τ 1 1 4 τ 2 2 6 server 2 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 C T τ 1 2 8 τ 2 3 10 DS 2 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 T 2 4 2 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 U LUB diventa minore di ln(2) = 0, 69 in presenza di DS 54

DS+RM: Analisi di schedulabilità U RM+DS LUB = U s + n per n U RM+DS LUB [ ( 2 + Us 2 U s + 1 = U s + ln ) 1 n 1 ] ( 2 + Us 2 U s + 1 ) Figura 61: Funzione U RM+DS LUB Come si può vedere dalla figura, U RM+DS LUB Per U s < 0, 4 U RM+DS LUB è sempre peggiore di U RM+PS è persino peggiore del valore di U RM LUB LUB. Test di schedulabilità U s + U p U s + ln Progetto del server DS ( ) 2 + Us 2 U s + 1 ( ) 2 + Us U p ln 2 U s + 1 1. stabilire il fattore di utilizzo da parte dei task periodici U p [ ( ) 1 ] 2 + Us n 2. sostituire U p nella formula U p n 1 2 U s + 1 3. trovare Us MAX dalla precedente formula tenendo presente che il simbolo diventerà il simbolo = 4. stabilire U s U MAX s 5. scegliere T s = min(t 1,..., T n ) 6. calcolare infine C s = T s U s 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 U s è definita ampiezza di banda del server quando all istante r k arriva il k-esimo aperiodico gli viene assegnata una deadline d k d k = r k + C k U s dove C k è il tempo di computazione richiesto dall aperiodico stesso ovviamente, per rendere il task set schedulabile U p + U s 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 Esempio C D τ 1 3 6 τ 2 2 8 d k = max(r k, d k 1 ) + C k U s U p = 3 6 + 2 8 = 3 4 U s = 1 U p = 1 4 r C D J 1 3 1 3 + 1 1 4 J 2 9 2 9 + 2 1 4 J 3 14 1 17 + 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 U p + U s 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 U LUB = 0, 69 ma EDF che ha U LUB = 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 U s dove U s è il fattore di utilizzazione della CPU da parte del server. Nella figura che segue ogni server ha la sua banda U s Figura 66: TBS: task isolation. Il server τ x ha banda propria U sx deve ovviamente valere che n U Si 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 Q s ed un periodo T s tali per cui Q s T s + U p = 1 gestisce una coda di aperiodici con una politica arbitraria al task selezionato viene assegnata una deadline tale da non necessitare banda maggiore di Q s T s quando la capacità di servizio si scarica viene ricaricata immediatamente al suo valore massimo Q s, ma la deadline viene spostata in avanti in maniera da mantenere costante l occupazione di banda del server (Se Q s T s = U s = costante raddoppiando Q s, affinché U s si mantenga costante, dovrò raddoppiare anche T s 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 U s = 1 U p = 2 1 6 + 3 ) = 1 9 3 quindi il server avrà un periodo T s = Q s = 2 U 1 = 6. s 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 2 6 ), 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 d 1 (istante 8) viene trasformata nella deadline d 2 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 d 3 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 d 3 (istante 18) viene trasformata nella deadline d 4 (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 J i è servito da CBS con ampiezza di banda U s, allora, per ogni intervallo di tempo t, J i non chiederà un tempo CPU maggiore di U s t schedulabilità hard un task J i (C i, T i ) è schedulabile da CBS con Q s = C i e T s = T i se e solo se J i è 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 C i, allora è possibile fornire una garanzia statistica per i J i 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: J 1 pur essendo a priorità maggiore viene bloccato da J 2 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 Inconveniente Figura 78: HLP: diagramma di Gant 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: ma 1. condivisa con τ: direct blocking 2. condivisa con task a priorità più alta di τ: push-through blocking 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(s k ) = max{p i : τ i utilizza s k } 73

dopodiché un task τ i entrerà in una sua sezione critica solo se P i > max{c(s k ) : s k è bloccato da τ j τ 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: 1. τ 3 si attiva ed entra in A C(C) = P 1 C(B) = P 1 C(A) = P 2 2. τ 2 si attiva e prelaziona τ 3 3. τ 2 chiede A ma PCP lo blocca perché P 2 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é P 1 C(B) 7. τ 3 sblocca B, τ 1 si sveglia e la priorità di τ 3 ritorna a p 2 (perché ora la sola risorsa bloccata è A di priorità P 2 ). A questo punto P 1 > C(A) quindi τ 1 prelaziona τ 3 e va fino alla fine. 8. τ 3 riprende a priorità p 2 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) = P 1 C(B) = P 1 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) = P 1 C(B) = P 1 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 B i, 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 k=1 C k T k + C i + B i T i i (2 1 i 1) stimiamo il tempo di blocco nel caso si abbiano tre task: per i = 3 2 k=1 C k T k + C 3 T 3 3 (2 1 3 1) B 3 = 0 perché τ 3 non può essere bloccato per i = 2 1 k=1 C k T k + C 2 + B 2 T 2 2 (2 1 2 1) per i = 1 C 1 + B 1 T 1 1 dove i valori di B 2 e di B 1 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 P i 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 = 1 T i 78

Resource ceiling R risorsa n R numero di unità di R attualmente disponibili µ R (τ) massima richiesta di R da parte di τ C R Current ceiling: funzione di n R definito come: C R (n R ) = max[{0} {π(τ) : n R < µ R (τ)}] se n R non può soddisfare uno o più tasks allora C R è 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: Dynamic System Ceiling C R = max[{0} {π(τ) : R può bloccare τ}] π s (t) = max(c Ri : i = 1,..., m) 79

Resource Ceiling - Esempio Tasks: τ 1 τ 2 τ 3 Resources: R 1 R 2 R 3 D π µ R1 µ R2 µ R3 τ 1 5 3 1 0 1 τ 2 10 2 2 1 3 τ 3 20 1 3 1 1 C R (3) C R (2) C R (1) C R (0) R 1 0 1 2 3 R 2 - - 0 2 R 3 0 2 2 3 Facciamo un esempio per far vedere come la precedente tabella va letta: C R (3) R 1 0 0 esprime qual è la massima priorità tra tutti i task che utilizzano più di 3 unità di R 1 a disposizione o meglio la criticità della situazione nel caso si abbiano 3 unità di risorsa R 1 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 C R (3) C R (2) C R (1) C R (0) R 1 0 1 2 3 R 2 0 0 0 2 R 3 0 2 2 3 π µ R1 µ R2 µ R3 τ 1 3 1-1 τ 2 2 2 1 3 τ 3 1 3 1 1 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 ) C k i : 1 i n + B i 1 T k T i 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 PIP PCP SRP assegnamento fisso fisso fisso o priorità dinamico numero di blocchi min(n,m) 1 1 momento di all accesso all accesso alla bloccaggio alla risorsa alla risorsa prelazione trasparenza si no no prevenzione no si si deadlock implementazione complessa media semplice calcolo del tempo pesante leggero leggero di blocco Tabella 4: Protocolli per l accesso alle risorse 84

Indice 1 Concetti Introduttivi 1 1.1 Real time............................. 1 1.2 Task e Job............................. 1 1.3 Constraints (vincoli)....................... 2 1.3.1 DAG (Direct Activity Graph).............. 2 1.3.2 Uso dei semafori..................... 2 1.4 Lo Schedule............................ 3 1.5 Tassonomia degli algoritmi di scheduling............ 4 1.6 Metriche.............................. 7 1.7 Utility functions......................... 9 1.8 Anomalie............................. 10 2 Scheduling Non real time 11 2.1 FCFS First Come First Served................. 11 2.2 SJF Shorted Job First...................... 12 2.3 PS Priority Scheduling...................... 13 2.4 RR Round Robin......................... 14 2.5 Code a priorità diversa...................... 15 3 Scheduling Real time 16 3.1 Scheduling di task Aperiodici.................. 16 3.1.1 EDD Earliest Due Date................. 17 3.1.2 EDF Earliest Deadline First............... 19 3.1.3 Pruning Search Trees.................. 21 3.1.4 LDF Latest Deadline First............... 23 3.1.5 EDF* (EDF con vincoli di precedenza)........ 24 3.1.6 Spring........................... 25 3.2 Scheduling di task Periodici................... 26 3.2.1 Concetti fondamentali.................. 26 3.2.2 RM Rate monotonic................... 28 3.2.3 Processor utilization factor (U)............. 29 3.2.4 Utilization Upper Bound (U UB )............. 29 3.2.5 EDF Earliest Deadline First............... 32 3.2.6 Task periodici con D < T................ 34 3.2.7 DM Deadline Monotonic 1982.............. 34 3.2.8 EDF* (EDF con deadlines <dei periodi)........ 38 3.2.9 Conclusioni sullo scheduling dei periodici....... 41 3.3 Scheduling di task Ibridi (periodici e aperiodici)....... 42 3.3.1 Fixed Priority Servers.................. 42 3.3.2 Background service.................... 44 3.3.3 Servers per gli aperiodici................. 46 3.3.4 PS Polling Server..................... 48 85

3.3.5 DS Defferable Server................... 52 3.3.6 TBS Total Bandwidth Server.............. 56 3.3.7 CBS Constant Bandwidth Server............ 61 4 Protocolli per l accesso alle risorse 64 4.1 NPP Non Preemptive Protocol................. 67 4.2 HLP Highest Locker Priority.................. 68 4.3 PIP Priority Inheritance Protocol 90.............. 69 4.4 PCP Priority Ceiling Protocol.................. 73 4.5 SRP Stack Resource Policy................... 78 86