Marco Coccia - appunti dalle lezioni dell`AA 2005-6
Transcript
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