Schedulazione

UNIVERSIT DEGLI STUDI DI GENOVA FACOLT DI INGEGNERIA
Schedulazione Real Time
Dipartimento di Informatica, Sistemistica e Telematica 2000
INTRODUZIONE
1.1
CONCETTI GENERALI
Introduciamo alcuni concetti e definizioni di base che caratterizzano lo studio della teoria e degli algoritmi della schedulazione real time [But 95]. Definiamo anzitutto il concetto di processo. Definizione 1. Processo. Per processo o task intendiamo una sequenza di istruzioni che, in assenza di altre attivit, viene eseguita dal processore in modo continuativo fino al suo completamento. La situazione di riferimento per un ambiente real time quella in cui sono presenti numerosi processi, ciascuno con particolari esigenze di schedulazione. In questo caso necessario individuare una strategia di assegnazione del processore che sequenzializzi luso della risorsa fisica secondo un criterio stabilito a priori. Consideriamo alcuni attributi caratteristici dei processi. Definiamo attivo un processo potenzialmente in grado di eseguire su un processore. Un processo attivo in attesa di un processore (occupato nellesecuzione di un altro processo) viene definito pronto e accodato in una coda di attesa detta ready queue (coda pronti). Un processo che correntemente utilizza il processore viene indicato come processo in esecuzione. Linsieme delle regole che determinano lesecuzione di un processo pronto presente nella ready queue costituisce lalgoritmo di schedulazione. Solitamente le regole di schedulazione sono applicate allingresso della coda di attesa in modo da ottenere una ready queue gi ordinata secondo la precedenza di esecuzione, in altre parole, lordinamento della coda viene realizzato in modo che il processo da eseguire sia nella prima posizione di uscita.
In alcuni sistemi prevista la possibilit di interrompere in qualsiasi istante il processo in esecuzione per riportarlo nella coda pronti, e dare la possibilit ad un processo a priorit superiore di disporre del processore. Loperazione di sospensione dellesecuzione e reinserimento nella coda pronti di un processo nota con il termine preemption (o revoca della CPU). Si osservi che lassegnazione effettiva del processore al processo pronto che viene schedulato indicata con il termine dispatching, e viene effettuata dal sistema operativo alla terminazione di un task o dopo unoperazione di preemption. La Figura 1.1.1 illustra sinteticamente larchitettura descritta sopra.
ready queue attivazione dispatching dispatching terminazione esecuzione esecuzio-
J4
J3
J2
J1
scheduling
preemption
Figura 1.1.1 Schedulatore
1.2
SCHEDULAZIONE
Considerando linsieme di task J={J1, J2, , Jn}, si definisce come schedulazione un assegnamento al processore dei task appartenenti allinsieme J. Formalmente possiamo enunciare la seguente definizione [But 95]. Definizione 2. Schedulazione. Una schedulazione una funzione : R+N tale che tR+ t1,t2 tali che t[t1,t2) e inoltre t[t1,t2) si abbia (t)=(t). La funzione di schedulazione quindi una funzione costante a tratti. Per convenzione, (t)=k, con k 0, indica che allistante t il processore sta eseguendo il task Jk. Invece (t)=0 indica che il processore libero (idle). La Figura 1.2.1 illustra sinteticamente i concetti appena esposti.
idle J1 J2 J3
idle
(t) 3 2 1
t1
t2
t3
t4
Figura 1.2.1 Esempio di schedulazione Questo esempio consente di introdurre e chiarire alcuni importanti concetti. Negli istanti t1, t2, t3, e t4, avviene un cambiamento dello stato del processore: in t1 il processore passa da idle ad attivo, in t2 e t3 cambia il task in esecuzione sul processore, in t4 il processore commuta da attivo ad idle; questi cambiamenti di stato vengono indicati con il termine context switch. Ciascun intervallo [ti, ti+1) in cui la funzione costante prende il nome di time slice. Una schedulazione detta preemptive nel caso in cui lesecuzione di un processo possa essere interrotta in qualsiasi istante per mandare in esecuzione un altro processo caratterizzato da una priorit maggiore sulla base di una strategia prefissata. In questi casi lesecuzione completa di un task pu avvenire durante intervalli di tempo disgiunti (ovvero non consecutivi). Si osservi che una schedulazione preemptive pu, in generale, essere definita come una sequenza di time slice, ciascuna corrispondente allesecuzione di una porzione di un processo. La Figura 1.2.2 riporta un semplice esempio di schedulazione preemptive, in cui viene mostrata linterruzione di un task J1 da parte di due task J2 e J3 maggiormente prioritari.
idle J1 (t) 3 2 1 J2 J1 J3 J1
idle
t Figura 1.2.2 Esempio di schedulazione preemptive Consideriamo ora due definizioni che risulteranno utili in seguito [But 95]. Definizione 3. Schedulazione fattibile. Una schedulazione detta fattibile se esiste unassegnazione di task al processore tale che tutti i task siano completati rispettando un insieme di vincoli prefissati.
Definizione 4. Insieme di task schedulabile. Un insieme di task J detto schedulabile se per esso esiste una schedulazione fattibile.
1.3
VINCOLI SUI PROCESSI
La definizione di schedulazione fattibile richiede che lesecuzione dei task avvenga rispettando i vincoli a cui questi sono sottoposti. In generale esistono tre categorie di vincoli sui processi: vincoli temporali, vincoli di precedenza, e vincoli su risorse condivise. 1.3.1 Vincoli temporali Nei sistemi real time i task sono soggetti a vincoli temporali che devono essere rispettati perch lelaborazione sia valida. Un tipico esempio di vincolo temporale la deadline di un processo, che rappresenta listante temporale entro cui il processo deve terminare la propria esecuzione e produrre un risultato. Il concetto di deadline centrale nella teoria dello scheduling real time, tanto da determinare una classificazione di base dei processi real time relativamente alle conseguenze di una mancata deadline [But 95]. 5
Definizione 5. Processo hard real time. Un processo real time di tipo hard se il mancato rispetto della propria deadline comporta un effetto catastrofico sul sistema, impedendone il corretto funzionamento.
Definizione 6. Processo soft real time. Un processo real time di tipo soft se il mancato rispetto della propria deadline non compromette il corretto funzionamento del sistema. Si osservi che un processo soft real time non vincolato da una deadline rigida e pu essere completato anche oltre il termine da questa indicato. In generale, un sistema real time sar caratterizzato sia da task di tipo hard che di tipo soft. I parametri che caratterizzano il comportamento temporale di un processo sono i seguenti: arrival time (a): istante di tempo in cui il task diventa pronto per lesecuzione; computation time (C): tempo necessario al processore per eseguire completamente un task senza interruzioni; deadline (d): istante di tempo entro cui il task deve essere completato; start time (s): istante di tempo in cui il task va in esecuzione per la prima volta; finishing time (f): istante di tempo in cui il task termina la sua esecuzione.
Il significato e le relazioni tra i parametri sopra definiti sono chiariti nella Figura 1.3.1.
Ci Ji a si fi d t
Figura 1.3.1 Parametri temporali caratteristici di un processo Esistono altri tre parametri che caratterizzano temporalmente un task e sono utilizzati per analizzare le prestazioni di un algoritmo di schedulazione: lateness (L): rappresenta il ritardo di completamento del task rispetto alla deadline ed cos definita:
L = f d
si osservi che per un task che completa la propria esecuzione prima della deadline caratterizzato da lateness negativa. tardiness (E): rappresenta il tempo in cui un processo rimasto attivo oltre la propria deadline:
E = max{0, L}
detto anche exceeding time. laxity (LX): rappresenta il ritardo di attivazione massimo che un task attivo pu subire nella ready queue senza per questo violare la deadline:
LX = d a C
detto anche exceeding time. Unaltra possibile caratterizzazione temporale dei processi quella che riguarda la regolarit delle attivazioni dei processi stessi. In particolare distinguiamo tra processi periodi e processi sporadici. Definizione 7. Processo periodico. Un processo detto periodico se caratterizzato da una sequenza infinita di attivit identiche, dette istanze. Dato un processo periodico i (nel seguito si indicher sempre un processo periodico generico con i e un processo sporadico generico con Ji) attivato allistante i, la sua prima istanza parte al tempo i, mentre listanza k-esima parte allistante i+(k-1)Ti. Il parametro Ti rappresenta il periodo del processo. Un processo periodico caratterizzato anche da un tempo di calcolo Ci e da una deadline Di (relativa al periodo); si suppone che i parametri Ti, Ci, e Di siano costanti per ogni istanza. La Figura 1.3.2 chiarisce le relazioni tra i parametri che caratterizzano i processi periodici.
Ci i
Di
i
Ti
Figura 1.3.2 Esempio di processo periodico
Definizione 8. Processo sporadico. Un processo detto sporadico se costituito da una sequenza di attivit identiche, ciascuna delle quali caratterizzata da un tempo di arrivo, un tempo di calcolo, e una deadline. Nei sistemi operativi nei quali non esiste un meccanismo di gestione esplicita dei vincoli temporali possibile comunque gestire tali vincoli trasformandoli in priorit. Intuitivamente, un task con caratteristiche temporali molto stringenti, si vedr assegnata una priorit maggiore di quella assegnata a un task con vincoli temporali meno critici. Con questo approccio possibile utilizzare uno schedulatore su base prioritaria per gestire i vincoli temporali dei processi. In Figura 1.3.3 viene riportato uno schema concettuale dellapproccio appena considerato. SCHEDULER
1
Traduzione dei vincoli temporali in priorit
Schedulatore a base prioritaria
Figura 1.3.3 Schema concettuale di uno scheduler che gestisce vincoli temporali
1.3.2 Vincoli di precedenza Esistono applicazioni nelle quali i processi non possono essere eseguiti in ordine arbitrario. In questi casi i processi presenti nel sistema sono legati tra loro da relazioni di precedenza che sono rappresentabili attraverso un grafo orientato e aciclico, detto grafo di precedenza.
CPU
Si dice che J1 precede J2 (J1<J2) se esiste un cammino sul grafo di precedenza che parte dal nodo J1 e arriva al nodo J2. Si dice che J1 immediato predecessore di J2 (J1J2) se esiste nel grafo di precedenza un arco diretto uscente dal nodo J1 ed entrante nel nodo J2.
Nella Figura 1.3.4 illustrato un grafo di precedenza. Si osservi che J1 lunico processo che pu essere eseguito immediatamente e i processi J2, J3 e J4 sono vincolati ad essere eseguiti solo dopo la sua terminazione; J5 pu essere eseguito solo dopo il completamento dei task J2 e J3.
J1
J2
J3
J4
J5
Figura 1.3.4 Grafo di precedenza tra processi
1.3.3 Vincoli su risorse Per risorsa intendiamo una qualunque entit software che pu essere utilizzata da uno o pi processi durante lesecuzione. Tipicamente una risorsa pu essere una struttura dati, una zona di memoria, o una porzione di codice. Una risorsa che pu essere utilizzata da pi processi detta condivisa, mentre se essa riservata ad un solo processo viene detta dedicata. Le risorse condivise che non ammettono accessi contemporanei da parte di pi di un processo, allo scopo ad esempio di mantenere la coerenza delle strutture dati interne, sono dette risorse mutuamente esclusive. Gli accessi a queste risorse devono essere serializzati per garantire il corretto funzionamento del sistema. Una porzione di codice mutuamente esclusiva prende il nome di sezione critica. Per garantire un accesso mutuamente esclusivo alle risorse, il sistema operativo necessita di un meccanismo di sincronizzazione degli accessi, che tipicamente fornito dai semafori. 9
Quando si parla di vincoli su risorse, si intende riferirsi a vincoli di mutua esclusione su risorse condivise. Il rispetto di un vincolo su risorsa ottenuto sincronizzando i processi che utilizzano tale risorsa facendo in modo che laccesso ad essa sia mutuamente esclusivo. I vincoli su risorse hanno importanti conseguenze sulla schedulazione dei processi. Esaminiamo un esempio per comprendere meglio questi effetti. Si supponga di considerare due task J1 e J2 che utilizzano una struttura dati condivisa. Il codice che manipola tale risorsa una sezione critica (SC) in quanto necessario che venga eseguito in modo mutuamente esclusivo. Supponiamo che i due task possano subire preemption e che J 1 abbia una priorit maggiore di J2. In queste condizioni se J2 attivato per primo e J1 arriva quando J2 gi entrato nella sezione critica, si verificher la situazione illustrata nella Figura 1.3.5.
tentativo di accesso alla sezione critica SC J1 SC t J2 SC a1 t1 SC t2 t
Figura 1.3.5 Schedulazione di task con vincoli su risorse Nellistante t1 il processo J1 tenta di accedere alla sezione critica occupata da J2. Il sistema blocca il processo J1 per garantire la mutua esclusione sulla risorsa condivisa. J 1 pu riprendere solo lesecuzione solo allistante t2, quando J2 libera la sezione critica. Definizione 9. Processo bloccato. Un processo detto bloccato (blocked) se in attesa di una risorsa condivisa occupata da un altro processo. I processi bloccati sono accodati in una coda associata al meccanismo di protezione della risorsa condivisa. Il sistema operativo prevede uno stato apposito per la sospensione dei processi bloccati su risorse. Un processo in esecuzione entra nello stato blocked se prova ad accedere ad una risorsa occupata, eseguendo ad esempio una primitiva wait sul semaforo utilizzato per proteggere la risorsa. Un processo bloccato esce dallo stato blocked quando la risorsa occupata viene liberata, a seguito ad esempio dellesecuzione da parte del 10
processo che deteneva la risorsa della primitiva signal. Considerando anche lo stato blocked, il ciclo di vita di un processo rappresentato nella Figura 1.3.6.
scheduling activation READY preemption signal resource free BLOCKED wait on resource busy EXE termination
Figura 1.3.6 Ciclo di vita di un processo
1.4
PROBLEMA GENERALE DELLO SCHEDULING
Dato un insieme di n task J = {J1, J2, , Jn} di cui siano noti i vincoli temporali, il grafo dei vincoli di precedenza e le modalit di utilizzo delle risorse condivise, il problema generale dello scheduling consiste nella determinazione di una schedulazione fattibile dellinsieme J [But 95]. In altre parole, la risoluzione del problema generale dello scheduling deve individuare una sequenza di assegnazione dei task al processore tale che: tutti i task terminino la propria elaborazione entro la deadline; i vincoli di precedenza espressi dal grafo di precedenza siano rispettati; laccesso alle risorse mutuamente esclusive sia correttamente sequenzializzato.
Si pu dimostrare [Gar 75] che il problema dello scheduling nella sua forma pi generale sopra enunciata computazionalmente intrattabile in tempo polinomiale rispetto al numero di processi. Non esiste cio alcun algoritmo con complessit polinomiale in n in grado di individuare una schedulazione fattibile. Al fine di individuare algoritmi con complessit polinomiale si introducono delle ipotesi semplificative rispetto al problema generale dello scheduling. Se si considerano, ad esempio, casi nei quali i vincoli di precedenza sono assenti, oppure ammissibile avere una
11
preemptive, oppure non sono presenti vincoli sulle risorse, il problema della schedulazione viene notevolmente semplificato e pu essere risolto con algoritmi noti. 1.4.1 Classificazione degli algoritmi di scheduling Di seguito viene riportata una sintetica classificazione dei possibili algoritmi di scheduling. Si noti che le tipologie di algoritmi considerate sono tra loro ortogonali [But 95]. Uniprocessore/multiprocessore. Preemptive/Non preemptive. Statici/Dinamici. Offline/Online. Besteffort/Guaranteed.
La prima classificazione riguarda semplicemente il tipo di sistema di elaborazione considerato e in particolare la presenza di uno o pi processori. Gli algoritmi di schedulazione preemptive prevedono la possibilit di sospendere in qualsiasi istante lesecuzione di un processo a favore di un altro; nel caso in cui non prevista la preemption ogni decisione riguardante la schedulazione viene presa a seguito della autosospensione di un task o del suo completamento. Gli algoritmi statici utilizzano una regola di decisione che si basa su parametri fissi, assegnati ai processi una volta per tutte prima della loro attivazione; nel caso dinamico al contrario, i parametri utilizzati dalla regola di decisione sono soggetti a variazioni durante la vita del processo. La classificazione offline/online distingue tra algoritmi che realizzano la schedulazione prima dellattivazione dei processi, sulla base di informazioni note a priori (offline), e algoritmi che operano durante il runtime ricalcolando lordinamento dei task as ogni nuova attivazione. Infine per algoritmo besteffort si intende un algoritmo che massimizza (o minimizza) un indice di prestazione definito globalmente sullinsieme dei task. Adottando una strategia di questo tipo si privilegiano le prestazioni medie del sistema e sono possibili violazioni di vincoli temporali relativi a qualche task. Gli algoritmi guaranteed assicurano il rispetto dei vincoli temporali di ogni singolo task utilizzando un test di garanzia eseguito sullintero insieme dei task ogni volta che un nuovo processo entra nel sistema. Si osservi che negli algoritmi offline possibile integrare implicitamente nello scheduling i vincoli di precedenza e di mutua esclusione sulle risorse. In pratica, sar sufficiente eseguire un processo solo dopo la terminazione di tutti i suoi predecessori e in pre12
senza della disponibilit di tutte le risorse da esso richieste. Operando in questo modo il problema di individuare una schedulazione offline fattibile equivale ad un problema di ricerca su un grafo di complessit non polinomiale (NP). Quando non richiesta una soluzione ottima possibile risolvere il problema facendo uso di algoritmi euristici. Nel caso in cui si adottino algoritmi online, i vincoli di precedenza e di mutua esclusione devono essere rispettati utilizzando costrutti di sincronizzazione espliciti. 1.4.2 Ottimalit In termini generali, un algoritmo di scheduling detto ottimo se massimizza (o minimizza) un qualsiasi indice di prestazione definito sullintero insieme dei task da schedulare. Nel senso della schedulabilit, un algoritmo A* si dice ottimo se gode della seguente propriet: Se un insieme di task J schedulabile con un generico algoritmo A, allora J sicuramente schedulabile con lalgoritmo ottimo A*. Viceversa, se J non schedulabile con lalgoritmo ottimo A*, allora J sicuramente non sar schedulabile con nessun altro algoritmo [But 95]. Va osservato che la propriet appena enunciata si applica ad algoritmi di schedulazione della stessa specie. In altre parole, se J non schedulabile con un algoritmo A* ottimo di tipo statico, non sar schedulabile con nessun altro algoritmo statico, ma potrebbe essere schedulabile, ad esempio, con un algoritmo dinamico. 1.4.3 Chiaroveggenza Un algoritmo di scheduling detto chiaroveggente se conosce esattamente il futuro, ovvero conosce in anticipo tutti i parametri di tutti i task da schedulare, prima che siano attivati [But 95]. Un algoritmo di schedulazione chiaroveggente una pura astrazione utilizzabile nella teoria dello scheduling come paragone per valutare le prestazioni e laffidabilit degli algoritmi reali. 1.5 SISTEMI CON GARANZIA SUL RISPETTO DEI VINCOLI
Nei sistemi real time necessario garantire a priori il rispetto dei vincoli temporali dei singoli task. Questa necessit motivata dal fatto che, in applicazioni critiche, preferibile rinunciare del tutto allesecuzione di un processo piuttosto che rischiare che il processo su-
13
peri la deadline durante la sua esecuzione. Questo comportamento si giustifica pensando che un processo anticipatamente eliminato essendo non garantito il rispetto dei suoi vincoli temporali, pu essere sostituito da opportune procedure di recupero che consentono al sistema di mantenersi in uno stato corretto di funzionamento. La garanzia sul rispetto dei vincoli temporali dei processi ottenuta attraverso un test di garanzia eseguito ogni volta che un nuovo processo entra nel sistema. In sostanza il test deve verificare che la schedulazione di ogni task del sistema avvenga nel rispetto di tutte le deadline. Se un processo critico supera la sua deadline si dice che nel sistema si verificato un timeoverflow. Nella Figura 1.5.1 riportato il diagramma degli stati di un sistema real time con garanzia sul rispetto dei vincoli.
activation
NO Guaranteed YES
scheduling termination READY preemption signal resource free BLOCKED wait on resource busy EXE
Figura 1.5.1 Diagramma di stato di un processo in un sistema con garanzia Dato un insieme di task J schedulabile, allarrivo di un nuovo task Jnew necessario verificare la schedulabilit dellinsieme J = Jnew J, ovvero verificare che Jnew e tutti i task che fanno parte dellinsieme J completino la propria esecuzione entro le rispettive deadline. Lintroduzione del meccanismo di garanzia consente di disaccopiare la strategia di schedulazione e quella di rigetto dei processi in ritardo. In un sistema privo del test di ga-
14
ranzia non esiste alcuna possibilit di prevedere il superamento della deadline da parte dei processi, il sistema evolve guidato dallalgoritmo di scheduling e il processo destinato al superamento della deadline dipende unicamente dal carico corrente e dalla strategia di assegnazione del processore. Lunica operazione che il sistema pu svolgere quella di controllo online per verificare la presenza di timeoverflow. Nei sistemi con garanzia possibile rilevare il superamento delle deadline critiche attraverso il test di garanzia nellistante di attivazione del task che provoca il sovraccarico del sistema. A questo punto, la scelta dellazione di recupero per riportare il sistema in condizioni normali presa in modo indipendente dalla strategia di schedulazione. Esempio 1. Effetto domino. Nei sistemi senza garanzia pu verificarsi il fenomeno noto con il nome di effetto domino. Esso si verifica quando larrivo di un nuovo task nel sistema provoca il superamento delle deadline di tutti i task del sistema. Si consideri la situazione presentata nella Figura 1.5.2 in cui i task sono schedulati sulla base di un algoritmo che assegna il processore al task con deadline pi imminente.
Jnew t J1 t J2 t J3 t J4 t0 t
Figura 1.5.2 Effetto domino Se allistante t0 il task Jnew venisse accettato nel sistema, si verificherebbe leffetto domino e tutti i task appartenenti a J, precedentemente schedulabili, 15
supererebbero la propria deadline. Nei sistemi con garanzia il sovraccarico viene individuato allistante t0 (cio allattivazione di Jnew) consentendo la non accettazione di Jnew al fine di assicurare il rispetto dei vincoli temporali dei processi precedentemente garantiti e gi in esecuzione. In un sistema privo di test di garanzia il task Jnew viene accettato e schedulato; i timeoverflow sono semplicemente rilevati e non possono essere prevenuti. Lesempio sopra riportato mette in luce due importanti caratteristiche dei sistemi con garanzia: (1) una volta che un task viene accettato esso certamente in grado di terminare entro la deadline, (2) laccettazione di un nuovo task avviene senza compromettere la schedulabilit dei task precedentemente garantiti.
SCHEDULAZIONE DI PROCESSI PERIODICI HARD REAL TIME
2.1
INTRODUZIONE
I processi periodici rivestono un ruolo molto importante in ogni sistema real time e rappresentano la maggior parte delle attivit di elaborazione. Moltissime attivit si prestano a essere implementate e gestite attraverso task periodici e tra queste possiamo ricordare le attivit di regolazione, acquisizione di segnali, acquisizione ed elaborazione di dati sensoriali, filtraggio, monitoraggio, comando di attuatori, ecc. Al fine di studiare le caratteristiche degli algoritmi di schedulazione e ricavare risultati analitici sulle loro propriet, utile formulare alcune ipotesi semplificative sul tipo di processi considerati. Senza introdurre eccessive semplificazioni possiamo limitarci a considerare processi che soddisfino le seguenti ipotesi [But 95]: Ipotesi 1 (I1). Le richieste di esecuzione delle varie istanze di un processo periodico sono inoltrate a intervalli di tempo regolari. In altre parole, si assume che il periodo del task periodico sia costante nel tempo. Ipotesi 2 (I2). Il tempo di esecuzione (computation time) di un task periodico costante nel tempo e non varia da istanza a istanza. Ipotesi 3 (I3). La deadline associata ad unistanza periodica coincide con la fine del periodo corrente, e quindi con listante in cui il task inoltra la richiesta di esecuzione successiva.
16
Ipotesi 4 (I4). Tutti i task periodici sono indipendenti. Listante di attivazione di ogni task non dipende dallo stato degli altri processi, cio non ci sono vincoli di precedenza tra i task. Non sono presenti vincoli su risorse condivise.
Le quattro ipotesi sopra riportate consentono di caratterizzare completamente un processo periodico i attraverso due soli parametri: periodo Ti; tempo di esecuzione Ci.
In Figura 2.1.1 fornita una rappresentazione grafica che chiarisce il legame tra il periodo e il tempo di esecuzione di un processo.
t T T
Figura 2.1.1 Caratteristiche dei processi periodici Lipotesi 3 stabilisce implicitamente delle relazioni tra il periodo Ti, il tempo di richiesta ri e la deadline di. Grazie a queste relazione possibile esprimere un processo periodico attraverso gli stessi attributi temporali utilizzati per i processi sporadici, in particolare un task periodico in questo modo caratterizzabile attraverso un tempo di richiesta e una deadline che assumono valori dinamici definiti dalle seguenti relazioni: d i (k ) = ri (k ) + Ti ri (k + 1) = d i (k ) dove
t k= Ti
Per un processo periodico real time valgono inoltre le seguenti definizioni:
17
Istante di richiesta. listante in cui unistanza periodica diventa pronta per essere eseguita. Lintervallo di tempo che intercorre tra due istanti di richiesta consecutivi esattamente pari al periodo del task.
Frequenza di richiesta. definita come linverso del periodo di un task. Tempo di risposta. lintervallo di tempo che intercorre tra listante di richiesta di unistanza periodica e listante del suo completamento.
La Figura 2.1.2 illustra sinteticamente le grandezze sopra definite.

Istanza k-esima T C
r(k) tempo di risposta
r(k+1)=r(k)+T d(k)=r(k+1)
Figura 2.1.2 Istanza di un processo periodico
2.1.1 Fattore di utilizzazione del processore Si considerino ora le seguenti definizioni che torneranno utili per lo studio degli algoritmi di schedulazione di task periodici [But 95]. Definizione 1. Fattore di utilizzazione del processore. Si consideri un insieme di n task periodici T={1, 2, , n}, si definisce fattore di utilizzazione del processore U la frazione di tempo utilizzata dalla CPU per eseguire linsieme di task.
U=
i =1
Ci Ti
Il fattore di utilizzazione U fornisce una misura delloccupazione del tempo di CPU da parte di un insieme di task periodici. Ovviamente, il fattore di utilizzazione tanto pi alto
18
quanto pi sono lunghi i tempi di calcolo a parit di periodo, e quanto pi breve il periodo a parit di tempi di calcolo. Esiste un limite superiore Uub (upper bound) oltre il quale non possibile aumentare U pena la non fattibilit della schedulazione. Tale limite superiore dipende sia dal particolare insieme di task da schedulare che dallalgoritmo di schedulazione utilizzato [But 95]. Definizione 2. Processore pienamente utilizzato. Dato un algoritmo di scheduling su un insieme di processi, il processore detto pienamente utilizzato (fully utilized) dallinsieme se la schedulazione fattibile e un aumento comunque piccolo del tempo di calcolo Ci di qualunque task rende la schedulazione non fattibile.
Definizione 3. Limite superiore minimo Ulub. Dato un algoritmo di scheduling, il limite superiore minimo (least upper bound) Ulub del fattore di utilizzazione U il minimo tra i fattori di utilizzazione calcolati su tutti gli insiemi di task che utilizzano pienamente il processore. Il fattore Ulub dipende dallalgoritmo di scheduling utilizzato e rappresenta una misura del carico massimo che un algoritmo in grado di gestire fornendo una schedulazione fattibile. Il calcolo del fattore Ulub per un dato algoritmo A si articola nelle seguenti fasi [But 95]: 1. Si considerano tutti gli insiemi di task periodici i che si possono ottenere al variare dei periodi Ti dei singoli task 2. Per ogni insieme di task i, si aumentino i valori dei tempi di calcolo Ci dei singoli task, fino ad ottenere la piena utilizzazione del processore. 3. Ogni insieme di task i che utilizza completamente il processore caratterizzato da un limite superiore Uub(i) al di sotto del quale linsieme i schedulabile con lalgoritmo A per qualsiasi combinazione dei valori dei tempi di calcolo Ci, e al di sopra del quale sicuramente non schedulabile con lalgoritmo A. 4. Il limite superiore Ulub calcolabile come minimo tra tutti i valori Uub(i) relativi ai vari insiemi di task che utilizzano pienamente il processore.
U lub =
i (fully utilized)
min
U ub (i)
19
Il limite superiore minimo Ulub un parametro di grande utilit in quanto consente di valutare facilmente se una schedulazione fattibile o meno. Se un insieme di task periodici caratterizzato da un fattore di utilizzazione U minore di Ulub, allora linsieme sicuramente schedulabile con lalgoritmo di schedulazione considerato. necessario evidenziare che al di sopra del limite superiore minimo la schedulabilit non garantita per tutti gli insiemi di task, per cui un insieme con UUlub potrebbe essere schedulabile con successo o meno a seconda delle sue caratteristiche. 2.1.2 Teoremi di schedulabilit Si possono enunciare i seguenti teoremi che riassumono i risultati principali fin qui incontrati [But 95]. Teorema 1. Teorema di schedulabilit generale. Un insieme di task periodici schedulabile con un algoritmo A se risulta: U U lub (A)
Teorema 2. Teorema di non schedulabilit. Un insieme di task periodici non schedulabile se risulta:
U >1
Di seguito sono analizzati alcuni degli algoritmi pi affidabili e ampiamente studiati nel campo della schedulazione real time di processi periodici. 2.2 RATE MONOTONIC
2.2.1 Generalit Consideriamo un insieme ={1, 2,, n} di processi periodici che soddisfano le quattro ipotesi riportate sopra. Si supponga che i task siano caratterizzati da un periodo T i e da un tempo di esecuzione Ci, e che siano ordinati secondo periodi crescenti in modo tale che 1 sia il task con periodo pi breve e n sia quello con periodo pi lungo. Lalgoritmo Rate Monotonic (RM) consiste nellassegnare a ciascun processo una priorit inversamente proporzionale al suo periodo di esecuzione. Cio la priorit pri del processo i risulta essere: 20
pri (RM)
1 Ti
Questa scelta fa s che in ogni istante venga schedulato il processo con il periodo pi breve e per questo motivo lalgoritmo Rate Monotonic noto anche con il nome Shortest Period First (SPF). Siccome abbiamo ipotizzato il periodo di ogni processo costante, RM un algoritmo di schedulazione di tipo statico: la priorit assegnata fissata allinizio e non cambia per tutta la durata dellapplicazione. Inoltre RM intrinsecamente di tipo preemptive. Esempio 1. Schedulazione con Rate Monotonic. Si considerino un insieme A di tre task periodici caratterizzati dai parametri temporali riportati nella Tabella 2.2.1. Arrival Time 0 0 0 Tempo di Calcolo 1 2 1 Tabella 2.2.1
Task 1 2 3
Periodo 4 8 10
La schedulazione dellinsieme A utilizzando lalgoritmo Rate Monotonic riportata nella Figura 2.2.1.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
2
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Figura 2.2.1 Schedulazione dellinsieme A con Rate Monotonic
21
2.2.2 Analisi di schedulabilit Si pu dimostrare [Liu 73] che Rate Monotonic un algoritmo ottimo: se un insieme di processi non schedulabile con RM allora non schedulabile con nessunaltro algoritmo statico di schedulazione. Come conseguenza della ottimalit dellalgoritmo Rate Monotonic si pu osservare che se la schedulazione prodotta da tale algoritmo non fattibile su un certo insieme di task, allora nessunaltra assegnazione di priorit fisse in grado di schedulare tale insieme. Per quanto riguarda il test di schedulabilit su un insieme di processi necessario determinare il fattore Ulub per lalgoritmo RM. Si pu ricavare [But 95] il seguente risultato. Teorema 3. Fattore Ulub per Rate Monotonic. Il limite superiore minimo del fattore di utilizzazione per lalgoritmo Rate Monotonic per un insieme di n task a priorit fissa dato da:
U lub = n (21 / n 1)
Ulub assume valori decrescenti al crescere di n, in particolare: n 2 3 4 5 Ulub 0.83 0.78 0.76 0.74
Conoscendo i valori assunti da Ulub possibile utilizzare il teorema di schedulabilit generale per verificare se un dato insieme di processi schedulabile con Rate Monotonic. Quando n sufficientemente grande si ha che il valore di Ulub converge a: U lub = ln 2 = 0.69 Riassumendo lalgoritmo RM ottimo (nellambito degli algoritmi statici) e garantisce al massimo un fattore di utilizzazione del processore pari al 69%. Questo risultato valido a meno che non sussistano relazioni particolari tra i valori dei periodi dei processi: il limite superiore minimo del fattore di utilizzazione diventa unitario quando i periodi dei processi sono legati tra loro da relazioni armoniche.
22
Esempio 2. Relazioni armoniche tra periodi. Si consideri un insieme B di tre task periodici caratterizzati dai parametri temporali riportati nella Tabella 2.2.2. Arrival Tempo di Time Calcolo 0 0 0 1 1 1 Tabella 2.2.2 In questo caso sono presenti tre task e quindi, per quanto visto sopra, il limite superiore minimo del fattore di utilizzazione pari a: U lub (n = 3) = 0.78 Il fattore di utilizzazione del processore relativo allinsieme di task B pu essere calcolato come segue:
U= 1 1 1 + + = 0.875 > 0.78 2 4 8
Task 1 2 3
Periodo 2 4 8
In questo caso il fattore di utilizzazione maggiore del valore Ulub per n=3, per, come si pu facilmente verificare costruendo lo schedule passo passo, la schedulazione dei task appartenenti a B fattibile. Questo comportamento imputabile alla presenza di relazioni armoniche tra i periodi dei task considerati. Lehoczky, Sha e Ding hanno presentato in [Leh 89] uno studio statistico in cui si dimostrato che su insiemi di task generati casualmente il limite superiore minimo del fattore di utilizzazione vale mediamente 0.88. Il test di schedulabilit che fa uso del limite superiore minimo del fattore di utilizzazione fornisce una condizione sufficiente, ma non necessaria, per la schedulabilit. Una condizione necessaria e sufficiente per Rate Monotonic stata dimostrata in [Leh 89]:
23
Teorema 4. Scheduling Point Test. Si consideri un insieme di task = {1, 2, , n} ordinati per periodo crescente (T1T2Tn). Linsieme schedulabile con lalgoritmo Rate Monotonic se e solo se:
L = max L i 1 , dove
1i n
L i = min L i ( t ) ,
tSi
L i ( t ) = C j ceil( t Tj ) t ,
j=1
Si = {Ti } {k Tj : j = 1,2,..., i 1; k = 1,2,..., floor (Ti Tj )}
Il teorema dello scheduling point test costruisce linsieme dei punti di schedulazione Si per ogni task i. Tale insieme costituito dalla deadline del task i (in questo caso coincidente con il periodo Ti) e dai tempi di partenza di tutti i task a priorit superiore che siano precedenti a Ti. Il teorema afferma che linsieme dei task schedulabile se e solo se, nei punti di schedulazione dellinsieme Si, tutti i task esistenti sono terminati. A partire da questo teorema si pu costruire un semplice algoritmo per verificare la fattibilit della schedulazione di un dato insieme di processi. Nel listato in pseudocodice dellalgoritmo Scheduling Point Test stata utilizzata la seguente convenzione:
SUM (m = 1 to n : C[m]) = C m
m =1 n
Algoritmo 1. Scheduling Point Test.

1. function SchedulingPointTest (n: integer; c[n], T[n]: real) 2. begin 3. 4. 5. for i:= 1 to n do if L_Test(i)=not feasible then return(not feasible); return(feasible); /* Fine routine principale */
6. end.
7. /* Test schedulabilit per {1, 2, , i} */ 8. function L_Test (i: integer) 9. begin 10. 11. if T[i] SUM(m = 1 to i: C[m]T[i]/T[m]) then
return(feasible);
24
12. 13. 14. 15. 16.
for j:= 1 to i-1 do for k:=1 to T[i]/T[j] do if kT[j] SUM(m = 1 to i: C[m]kT[i]/T[m]) then return(feasible); return(not feasible);
17. end;
La complessit di tale algoritmo dipende non soltanto dal numero dei processi ma anche dal loro massimo periodo. Tutto questo valido nellipotesi che i periodi siano espressi come numeri interi (ipotesi non limitativa in quanto si pu sempre pensare ad un cambio opportuno della metrica per la misura dei tempi tenendo conto del fatto che ogni sistema di calcolo reale lavora con una temporizzazione discreta). Si pu dimostrare [Man 98]: Lemma 1. Dato un qualunque intero k, esiste un insieme di task tale che || = 2 e la complessit dellalgoritmo Scheduling Point Test per almeno O(k). Quindi in generale possono esistere casi nei quali, pur con insiemi costituiti da un numero relativamente piccolo di processi, si ha una notevole complessit dellalgoritmo che realizza Scheduling Point Test. Esempio 3. Verifica della schedulabilit con Scheduling Point Test. Si consideri linsieme task B presentato nellesempio 2. Verifichiamone la schedulabilit utilizzando il teorema dello Scheduling Point Test. Gli insiemi dei punti di schedulazione per i tre task sono i seguenti. S1 = {2} S2 = {2,4} S3 = {2,4,6,8} Le quantit Li sono facilmente calcolabile a partire dalle caratteristiche temporali dei task.
1 tS1 2 3 L 2 = min L 2 ( t ) = tS2 4 7 L 3 = min L 3 ( t ) = tS3 8 L1 = min L1 ( t ) =

Il calcolo della quantit L consente di stabilire se linsieme schedulabile. 25
L = max L i =
1i 3
7 1 8
Sulla base del teorema dello Scheduling Point Test si conclude che linsieme B schedulabile. Sha e Sathaye hanno presentato in [Sha 93] un altro algoritmo per verificare la fattibilit della schedulazione con rate monotonic detto Completion Time Test. Algoritmo 2. Completion Time Test.
1. function CompletionTimeTest (n: integer; c[n], T[n]: real) 2. begin 3. 4. 5. for i:= 1 to n do if Completion(i)=not feasible then return(not feasible); return(feasible); /* Fine routine principale */
6. end.
7. /* Test schedulabilit per {1, 2, , i} */ 8. function Completion (i: integer) 9. begin 10. 11. 12. 13. 14. 15. 16. t:=SUM(m = 1 to i: C[i]); repeat if t > T[i] then return(not feasible);
t:=t; t:= SUM(m = 1 to i: C[m]t/T[m]); until(t=t); return(feasible);
17. end;
La logica di funzionamento di questo algoritmo la seguente. Si consideri il passo in cui lalgoritmo verifica la schedulabilit dellinsieme {1, 2, , i}. Per prima cosa viene calcolato il tempo computazionale t necessario per i job inizialmente esistenti. Siccome nuove istanze dei task possono cominciare entro t, viene calcolato il tempo computazionale t complessivamente richiesto fino a t. In particolare si ha:
t := C m ceil(
m =1
t ) Tm
26
Se t=t, tutti i job sono terminati al tempo t e quindi linsieme {1, 2, , i} schedulabile. Se tt, il tempo computazionale richiesto dai job fino a t viene ricalcolato e se t>Di linsieme dei task non schedulabile. Quanto osservato a proposito della complessit dellalgoritmo Scheduling Point Test pu essere ripetuto anche per lalgoritmo Completion Time Test. In particolare in [Man 98] viene dimostrato il seguente risultato. Lemma 2. Dato un qualunque intero k, esiste un insieme di task tale che || = 2 e la complessit dellalgoritmo Completion Time Test per almeno O(k). Quindi anche utilizzando lalgoritmo Completion Time Test possono presentarsi dei casi per cui la complessit dellalgoritmo elevata anche con insiemi con un numero di task costanti. [Man 98] presenta una nuova condizione necessaria e sufficiente per la schedulabilit con rate monotonic. Si consideri un insieme di task = {1, 2, , n} ordinati per periodo crescente (T1T2Tn). Per ogni task i appartenente allinsieme possibile definire linsieme ridotto dei punti di schedulazione Ri. Definizione 1. Insieme ridotto dei punti di schedulazione Ri (per RM).
R i = j=1 Q ij , dove
i
Q ii = { Ti } ,
Q ij = floor( t Tj ) Tj : t Q ik ( j + 1 k i) (1 j < i)
Si osservi che esiste la seguente relazione di inclusione tra linsieme dei punti di schedulazione Si e linsieme ridotto dei punti di schedulazione Ri:
R i Si
Definito linsieme ridotto dei punti di schedulazione possibile estendere il Teorema dello Scheduling Point Test riportato sopra considerando i soli punti in Ri. Teorema 5. Reduced Scheduling Point Test. Si consideri un insieme di task = {1, 2, , n} ordinati per periodo crescente (T1T2Tn). Linsieme schedulabile con lalgoritmo Rate Monotonic se e solo se:
1i n
27
L i = min L i ( t ) ,
tR i
L i ( t ) = C j ceil( t Tj ) t
j=1
Il teorema 5 consente la costruzione dellalgoritmo Reduced Scheduling Point Test per la verifica della schedulabit di un insieme di task periodici. Nel listato in pseudocodice riportato sotto sono state utilizzate le seguenti notazioni:
Q(k, i) = Q ik U(k = j + 1 to i : Q(k, i)) =

k = j+1
i k
Algoritmo 3. Reduced Scheduling Point Test.

1. function ReducedSchedulingPointTest (n: integer; c[n], T[n]: real) 2. begin 3. 4. 5. for i:= 1 to n do if L_Test(i)=not feasible then return(not feasible); return(feasible); /* Fine routine principale */
6. end.
7. /* Test schedulabilit per {1, 2, , i} */ 8. function L_Test (i: integer) 9. var rlist, rlist2: list; 10. begin 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. if T[i] SUM(m = 1 to i: C[m]T[i]/T[m]) then /* Liste di scheduling point */
return(feasible); rlist:={T[i]}; /* rlist = Q(i,i) */
for j:= i-1 to 1 step -1 do begin copy rlist to rlist2; /* rlist2 = U(k = j+1 to i: Q(k,i)) */ for each element trlist2 do begin /* Considera un elemento da Q(j,i) */ t0:=floor(t/T[j])T[j]; if t < t0 + T[j] and t0rlist then /* t0 un nuovo elemento */ begin if t0 SUM(m = 1 to i: C[m]ceil(t0/T[m])) then
28
24. 25. 26. 27. 28. 29.
return(feasible); insert t0 to rlist; end end end; return(not feasible); /* fine del loop su rlist2 */ /* fine del loop su j */
30. end;
Allinizio del ciclo su j, rlist contiene gli elementi di U(k=j+1 to i: Q(k,i)). Nel ciclo eseguito su rlist2 viene calcolato ogni elemento tQ(j,i). Nel caso in cui trlist, Li(t) calcolata per verificare la fattibilit della schedulazione e t aggiunto a rlist. Se Li(t)1 per qualche trlist, allora Li1. possibile stimare la complessit dellalgoritmo Reduced Scheduling Point Test; per ogni elemento tRi, sono necessarie O(i) moltiplicazioni e divisioni per controllare che Li(t)1. Siccome |Ri|2i-1 e Li controllato per ogni i (1in), il numero delle moltiplicazione e divisioni sar O(i|Ri| 1in) e cio O(n2n). Si pu notare che la complessit dellalgoritmo non dipende dal periodo dei processi, ma solo dal numero dei processi. Quindi se il numero dei processi costante anche la complessit dellalgoritmo costante. Esempio 4. Verifica della schedulabilit con Reduced Scheduling Point Test. Si consideri linsieme task B presentato nellesempio 2. Verifichiamone la schedulabilit utilizzando il teorema del Reduced Scheduling Point Test. Gli insiemi dei punti di schedulazione per i tre task sono i seguenti. R 1 = {2} R 2 = {4} R 3 = {8} Le quantit Li si possono calcolare calcolabile a partire dalle caratteristiche temporali dei task.
1 tR1 2 3 L2 = min L2 ( t ) = tR 2 4 7 L3 = min L3 ( t ) = tR 3 8 L1 = min L1 ( t ) =

Il calcolo della quantit L consente di stabilire se linsieme schedulabile.
29
L = max Li =
1i 3
7 1 8
Sulla base del teorema del Reduced Scheduling Point Test si conclude che linsieme B schedulabile.
2.2.3 Osservazioni Lalgoritmo rate monotonic consente la schedulazione di un insieme di task periodici hard real time. Unipotesi importante su cui poggia questo algoritmo che la deadline del task coincida sempre con la fine del periodo. In linea generale lapplicazione quindi la schedulazione attraverso Rate Monotonic pu portare alla situazione rappresentata in Figura 2.2.2.
Istanza kesima T C Istanza k+1esima
t Figura 2.2.2 Esempio di schedulazione con Rate Monotonic Lalgoritmo Rate Monotonic garantisce che lesecuzione di ogni istanza del task termini entro la fine del periodo, senza la possibilit di prevedere quando il processo sar eseguito allinterno del periodo. In generale, unistanza potr andare in esecuzione nellistante di inizio del suo periodo cos come nellultimo istante utile perch possa terminare entro la deadline. Va osservato che la situazione presentata in Figura 2.2.2, pur sempre possibile, si pu verificare solo in casi particolari e comunque con probabilit bassa. 2.3 EARLIEST DEADLINE FIRST
2.3.1 Generalit Lalgoritmo Earliest Deadline First (EDF) uno degli algoritmi pi usati nei sistemi real time per la schedulazione dinamica dei processi. La regola di schedulazione che caratterizza lalgoritmo EDF la seguente: ad ogni istante viene selezionato per lesecuzione il task con deadline pi imminente. 30
Si tratta di un algoritmo di tipo preemptive in quanto allarrivo di un task caratterizzato da una deadline minore rispetto a quella del task in esecuzione, questultimo viene sospeso a favore del nuovo task. Se il sistema operativo non supporta esplicitamente la gestione dei vincoli temporali, lalgoritmo EDF pu essere implementato con un sistema a base prioritaria. In particolare ad ogni task viene assegnata una priorit inversamente proporzionale alla propria deadline; questa assegnazione di tipo dinamico, in quanto la valutazione della prossimit della deadline dipende ovviamente dallistante di tempo nel quale tale valutazione realizzata. Lalgoritmo EDF pu essere usato per schedulare anche insiemi misti di processi periodici e sporadici; per i processi periodici la deadline coincide con la fine del periodo, mentre per i processi sporadici la deadline dipende dalle esigenze di temporizzazione richieste dal particolare compito che il processo deve portare a termine. Si pu dimostrare mediante il metodo di Dertouzos [Der 74] che EDF ottimo tra gli algoritmi ad assegnazione dinamica della priorit. Liu e Layland hanno dimostrato [Liu 73] che lalgoritmo EDF consente di schedulare insiemi di task con fattore di utilizzazione unitario. Teorema 1. Teorema di schedulabilit per EDF. Un insieme = {1, 2,, n} di n task periodici che soddisfano le quattro ipotesi I1, I2, I3, I4, schedulabile con lalgoritmo EDF se e solo se risulta:
U=
i =1
Ci 1 Ti
Esempio 1. Confronto tra Rate Monotonic e Earliest Deadline First. Si consideri linsieme di task A={1, 2, 3} le cui caratteristiche temporali sono riportate in Tabella 2.3.1. Arrival Tempo di Periodo Time Calcolo 0 0 0 1 2 2 4 5 7
Task 1 2 3
Tabella 2.3.1 31
Il fattore di utilizzazione per linsieme A pu essere calcolato come segue:

U= 1 2 2 131 + + = = 0.94 1 4 5 7 140
Per quanto riguarda la schedulazione con RM si osserva che:

RM U > U lub (n = 3)
La schedulazione dellinsieme A utilizzando lalgoritmo Rate Monotonic riportata nella Figura 2.3.1.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
2
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
timeoverflow
Figura 2.3.1 Schedulazione dellinsieme A con Rate Monotonic La prima istanza del task 3 non termina entro la deadline generando un time overflow allistante 7, la schedulazione con Rate Monotonic quindi non fattibile. Se si schedula linsieme A con lalgoritmo Earliest Deadline First si ottiene si ottiene la schedulazione riportata in Figura 2.3.2.
32
10
11
12 13
14 15
16 17
18
19 20
21 22
1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
2
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Figura 2.3.2 Schedulazione di A con Earliest Deadline First La schedulazione attraverso lalgoritmo EDF fattibile in quanto il fattore di utilizzazione dellinsieme dei task considerato minore di uno.
2.3.2 Osservazioni In linea generale, si pu osservare che le politiche di assegnazione dinamica delle priorit portano ad una maggiore utilizzazione del processore rispetto a quelle con assegnazione statica. A livello implementativo, tuttavia, le prime sono caratterizzate da una complessit superiore rispetto alle seconde, limitandone di fatto lutilizzo pratico. Anche per lalgoritmo Earliest Deadline First, come gi visto per Rate Monotonic, si pu evidenziare come lassenza di una deadline interna al periodo sia fonte di rigidit per la schedulazione ottenuta. 2.4 DEADLINE MONOTONIC
2.4.1 Generalit Come osservato sopra, Rate Monotonic e Earliest Deadline First garantiscono lesecuzione dei processi allinterno del proprio periodo per non forniscono alcuna garanzia sullesecuzione allinterno di un determinato intervallo di tempo. In alcune applicazioni, tuttavia, pu essere necessario disporre di un meccanismo che consenta di vincolare lesecuzione di un task ciclico in un determinato intervallo di tempo interno al periodo. Lalgoritmo Deadline Monotonic, definito da Leung e Whitehead nel 1982 [Leu 82], una estensione del Rate Monotonic che consente la schedulazione di un processo periodico
33
con deadline indipendente dal periodo. In questo contesto ogni task caratterizzato da tre parametri: Tempo massimo di esecuzione Ci; Periodo di attivazione Ti; Deadline relativa Di.
La deadline relativa rappresenta lintervallo di tempo, a partire dallistante di richiesta, entro cui il processo deve terminare la sua esecuzione. La deadline relativa tale che:
D i = d i ri C i D i Ti
I parametri sopra definiti sono rappresentati in Figura 2.4.1.
Ti Ci
Di di
Figura 2.4.1 Processo periodico con deadline non coincidente con la fine del periodo Secondo lalgoritmo Deadline Monotonic viene eseguito in ogni istante il processo con deadline relativa pi corta. Nei sistemi a base prioritaria, la politica adottata quella di assegnare ad ogni task i una priorit pri inversamente proporzionale alla propria deadline relativa:
pri 1 Di
Essendo Di una quantit costante per ogni processo segue che DM un algoritmo statico. Infine si pu facilmente mostrare che DM anche di tipo preemptive. Rispetto ai due algoritmi visti in precedenza, nellalgoritmo Deadline Monotonic viene rilasciata lipotesi per cui la deadline sia coincidenti con la fine del periodo, pertanto le ipotesi semplificative su cui esso basato sono le seguenti [But 95]: Ipotesi 1 (I1). Il periodo Ti costante per ogni processo. 34
Ipotesi 2 (I2). Il tempo di esecuzione massimo Ci costante nel tempo e non varia da istanza a istanza. Ipotesi 3 (I3). La deadline relativa Di costante nel tempo e non varia da istanza a istanza. Ipotesi 4 (I4). Tutti i task periodici sono indipendenti e non sono presenti vincoli su risorse condivise.
Sotto queste ipotesi, si pu dimostrare che lalgoritmo Deadline Monotonic ottimo nellambito degli algoritmi statici di schedulazione. Esempio 1. Schedulazione con Deadline Monotonic. Si consideri linsieme A={1, 2, 3} di tre task periodici caratterizzati dai parametri temporali riportati nella Tabella 2.4.1. Arrival Time 0 0 0 Tempo di Calcolo 1 2 1 Tabella 2.4.1 Utilizzando lalgoritmo Deadline Monotonic ciascun task riceve una priorit inversamente proporzionale alla propria deadline, quindi il task 1 ricever la priorit massima mentre il task 3 quella minima. La schedulazione dellinsieme A utilizzando lalgoritmo Deadline Monotonic riportata nella Figura 2.4.2.
Task 1 2 3
Deadline Periodo 3 5 7 4 8 10
35
10
11
12 13
14 15
16 17
18
19 20
21 22
1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
2
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Figura 2.4.2 Schedulazione dellinsieme A con Deadline Monotonic
2.4.2 Analisi di schedulabilit A differenza di quanto accade con RM ed EDF, con Deadline Monotonic lanalisi di schedulabilit di un insieme di processi non formulabile con un semplice test sul valore delloccupazione del processore. possibile in prima approssimazione pensare di ricondurre il test di schedulabilit per DM a quello per RM, sostituendo al periodo il valore della deadline relativa [But 95]:
D
i =1
Ci
i
n (21 / n 1)
Questo test rappresenta per solo una condizione sufficiente per la schedulabilit, e inoltre, cosa ben pi grave, quando le deadline relative risultano essere molto pi brevi dei periodi, tale test risulta estremamente inefficiente. Un esempio pu chiarire meglio questo aspetto. Esempio 1. Test di schedulabilit sufficiente. Si consideri linsieme di task A={1, 2} con le caratteristiche riportate in Tabella 2.4.2. Arrival Tempo di Deadline Periodo Time Calcolo 0 0 4 3 Tabella 2.4.2 4 7 50 100
Task 1 2
36
Lapplicazione della condizione sufficiente fornisce il seguente risultato:
D
i =1
Ci
i
4 3 10 + = 2 (21 2 1) = 0.83 4 7 7
Disponendo della sola condizione sufficiente non si potrebbe stabilire la schedulabilit dellinsieme. In questo caso per facile convincersi che linsieme dei task schedulabile con Deadline Monotonic. I risultati visti per Rate Monotonic sono stati estesi al Deadline Monotonic. In particolare [Leh 91] estende il teorema dello Scheduling Point Test. Teorema 1. Scheduling Point Test. Si consideri un insieme di task = {1, 2, , n} ordinati per deadline crescente (D1D2Dn). schedulabile con lalgoritmo Deadline Monotonic se e solo se:
1i n
Linsieme
L i = min L i ( t ) ,
tSi
L i ( t ) = C j ceil( t Tj ) t ,
j=1
Si = {D i } {k Tj : j = 1,2,..., i 1; k = 1,2,..., floor (D i Tj )}
Le considerazioni fatte a proposito dello Scheduling Point Test nellambito dellanalisi di schedulabilit con lalgoritmo Rate Monotonic possono essere estese allanalisi di schedulabilit con lalgoritmo Deadline Monotonic. In questo caso linsieme dei punti di schedulazione Si per il task i costituito dalla prima deadline Di e dagli istanti di partenza, precedenti a Di, dei job a priorit superiore. Il teorema 1 assicura che linsieme dei task schedulabile se e solo se, nei punti di schedulazione, tutti i job esistenti sono finiti. Analogamente a quanto visto per Rate Monotonic, possibile costruire un algoritmo basato sullo Scheduling Point Test per la verifica della schedulabilit di un insieme di task. Algoritmo 1. Scheduling Point Test.
1. function SchedulingPointTest (n: integer; c[n], T[n], D[n]: real) 2. begin
37
3. 4. 5.
for i:= 1 to n do if L_Test(i)=not feasible then return(not feasible); return(feasible); /* Fine routine principale */
6. end.
7. /* Test schedulabilit per {1, 2, , i} */ 8. function L_Test (i: integer) 9. begin 10. 11. 12. 13. 14. 15. 16. if D[i] SUM(m = 1 to i: C[m]D[i]/T[m]) then
return(feasible); for j:= 1 to i-1 do for k:=1 to D[i]/T[j] do if kT[j] SUM(m = 1 to i: C[m]kT[i]/T[m]) then return(feasible); return(not feasible);
17. end;
Lanalisi di complessit per lalgoritmo resta inalterata. Per comodit di lettura riportato il lemma enunciato precedentemente. Lemma 1. Dato un qualunque intero k, esiste un insieme di task tale che || = 2 e la complessit dellalgoritmo Scheduling Point Test per almeno O(k). In [Man 98] si dimostra che lanalisi di schedulabilit per lalgoritmo Deadline Monotonic pu essere realizzata considerando linsieme ridotto dei punti di schedulazione Ri. Nel caso di Deadline Monotonic la deadline relativa non coincide, in generale, con il periodo del processo e quindi la definizione dellinsieme Ri si modifica come segue: Definizione 1. Insieme ridotto dei punti di schedulazione.
R i = j=1 Q ij , dove
i
Q ii = {D i } ,
Q ij = {floor( t Tj ) Tj : t Q ik ( j + 1 k i) and t < floor( t Tj ) Tj + D j } (1 j < i)
Si noti che la condizione t < floor(t/Tj)Tj + Dj sempre verificata nel caso in cui Di = Ti. Di seguito riportiamo il teorema del Reduced Scheduling Point Test per Deadline Monotonic che assuma la stessa forma di quello visto per Rate Monotonic.
38
Teorema 2. Reduced Scheduling Point Test. Si consideri un insieme di task = {1, 2, , n} ordinati per deadline crescente (D1D2Dn). Linsieme schedulabile con lalgoritmo Deadline Monotonic se e solo se:
1i n
L i = min L i ( t ) ,
tR i
L i ( t ) = C j ceil( t Tj ) t
j=1
Analogamente a quanto visto per Rate Monotonic, possibile a partire dal teorema 2 ricavare un algoritmo per la verifica della schedulabilit di un insieme di task che faccia uso del Reduced Scheduling Point Test. Algoritmo 2. Reduced Scheduling Point Test.
1. function ReducedSchedulingPointTest (n: integer; c[n], T[n], D[n]: real) 2. begin 3. 4. 5. for i:= 1 to n do if L_Test(i)=not feasible then return(not feasible); return(feasible); /* Fine routine principale */
6. end.
7. /* Test schedulabilit per {1, 2, , i} */ 8. function L_Test (i: integer) 9. var rlist, rlist2: list; 10. begin 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. if D[i] SUM(m = 1 to i: C[m]D[i]/T[m]) then /* Liste di scheduling point */
return(feasible); rlist:={D[i]}; /* rlist = Q(i,i) */
for j:= i-1 to 1 step -1 do begin copy rlist to rlist2; /* rlist2 = U(k = j+1 to i: Q(k,i)) */ for each element trlist2 do begin /* Considera un elemento da Q(j,i) */ t0:=floor(t/T[j])T[j]; if t < t0 + D[j] and t0rlist then /* t0 un nuovo elemento */
39
22. 23. 24. 25. 26. 27. 28. 29. 30.
begin if t0 SUM(m = 1 to i: C[m]ceil(t0/T[m])) then return(feasible); insert t0 to rlist; end end end; return(not feasible); end; /* fine del loop su rlist2 */ /* fine del loop su j */
Il comportamento dellalgoritmo identico a quello analizzato nel paragrafo su Rate Monotonic, lunica differenza sta nel valore delle deadline che in questo caso non coincidono necessariamente con la fine del periodo del task. La complessit dellalgoritmo che fa uso del Reduced Scheduling Point Test pari a O(n2n), con n numero dei processi dellinsieme da schedulare. La complessit dunque costante se costante il numero dei processi. Esempio 2. Analisi di schedulabilit con Reduced Scheduling Point Test. Si consideri linsieme di task A dellesempio 1 sopra riportato. Gli insiemi ridotti dei punti di schedulazione dei task 1 e 2 sono: R 1 = {4} R 2 = {7} Le quantit Li assumono i seguenti valori:
L1 = min L1 ( t ) = 1
tR1
L = min L 2 ( t ) = 1
2 tR 2
Si pu calcolare la quantit L:
L = max Li = 1 1
1i 2
Essendo L uguale a 1 si pu concludere che linsieme A schedulabile con Deadline Monotonic.
Esempio 3. Analisi di schedulabilit con Reduced Scheduling Point Test. Si consideri linsieme di task B le cui caratteristiche sono riportate nella Tabella 2.4.3. 40
Task 1 2 3
Arrival Tempo di Deadline Periodo Time Calcolo 0 0 0 2 6 6 Tabella 2.4.3 4 10 20 10 15 25
Gli insiemi ridotti dei punti di schedulazione dei task appartenenti allinsieme B sono: R 1 = {4} R 2 = {10} R 3 = {15,20} Le quantit Li assumono i seguenti valori:
1 tR1 2 4 L2 = min L 2 ( t ) = tR 2 5 16 L3 = min L 3 ( t ) = tR 3 15 L1 = min L1 ( t ) =

Si pu calcolare la quantit L:
L = max Li =
1i 3
16 >1 15
Essendo L maggiore di uno si pu concludere che linsieme B non schedulabile con lalgoritmo Deadline Monotonic. Landamento temporale della schedulazione di B con Deadline Monotonic, riportata in Figura 2.4.3, evidenzia il verificarsi di un timeoverflow causato dalla mancata deadline da parte del task 3.
41
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
2
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
timeoverflow
Figura 2.4.3 Schedulazione di B con Deadline Monotonic
2.4.3 Osservazioni Lalgoritmo Deadline Monotonic estende lalgoritmo Rate Monotonic consentendo la schedulazione di task periodici con deadline non coincidente con la fine del periodo. Nel caso in cui la deadline assuma un valore coincidente con la fine del periodo i due algoritmi coincidono dando luogo alla stessa sequenza di schedulazione.
SCHEDULAZIONE DI PROCESSI SPORADICI HARD REAL TIME
Un processo sporadico un processo che esegue in modo aperiodico il proprio codice in quanto, ad esempio, va in esecuzione a seguito del verificarsi di particolari condizioni nel sistema. In genere i processi sporadici sono attivati da altri processi: ad esempio, un processo periodico pu attivare con un messaggio di allarme un particolare processo sporadico che deve intervenire al fine di gestire una situazione critica.
42
J1
begin begin
end if (error) { wakeup(J1); }
end
Figura 3.1 Attivazione di un processo sporadico Ogni processo sporadico hard real time sar caratterizzato dalle seguenti grandezze: computation time (C): tempo necessario al processore per eseguire completamente il task senza interruzioni; deadline (d): istante di tempo entro cui il task deve essere completato; minimum interarrival time (MIT): minimo tempo di interarrivo, che rappresenta lintervallo di tempo minimo che si presenta tra una richiesta di esecuzione del task e la richiesta successiva. Nella Figura 3.2 sono illustrate graficamente le grandezze che caratterizzano i processi sporadici.
43
arrivo MITi Ci
Di di
Figura 3.2 Esempio di processo sporadico Per poter garantire la schedulazione hard real time di un processo sporadico, necessario considerare tale processo come periodico di periodo pari al minimo tempo di interarrivo e con deadline relativa pari alla deadline del processo. Sotto queste ipotesi possibile schedulare insiemi misti di task periodici e task sporadici con uno qualsiasi degli algoritmi visti precedentemente. Ad esempio, nel caso si scelga di realizzare la schedulazione con lalgoritmo Rate Monotonic, ad ogni processo sporadico viene assegnata una priorit inversamente proporzionale al proprio periodo, in modo del tutto analogo a quanto avviene per i task periodici. Si noti che considerare il task sporadico come un task periodico di periodo pari al minimo tempo di interarrivo significa considerare il caso pessimo. Se il test di schedulabilit d esito positivo la schedulazione garantita anche quando il task sporadico si attiva ad intervalli esattamente pari al minimo tempo di interarrivo. Esempio 1. Schedulazione di un insieme misto di task. Si consideri linsieme di task =, dove ={1, 2} un insieme di task periodici con caratteristiche riportate in Tabella 3.1, e ={J1, J2} un insieme di task sporadici con caratteristiche riportate in Tabella 3.2. Arrival Time 0 0 Tempo di Calcolo 1 1 Tabella 3.1
Task 1 2
Periodo 4 8
44
Task J1 J2
Tempo di Calcolo 2 2
Minimo Tempo di Interarrivo 10 12
Deadline 10 12
Tabella 3.2 Decidendo di utilizzare per la schedulazione dellinsieme lalgoritmo Rate Monotonic, si pu che il fattore di utilizzazione calcolabile sommando il contributo dellinsieme dei task periodici e quello dellinsieme dei task sporadici .
U=
T + MIT
i J i
Ci
Ci
U=
1 1 2 2 89 RM + + + = = 0.74 < 0.76 = U lub ( n = 4) 4 8 10 12 120
Essendo il fattore di utilizzazione del processore inferiore al suo limite superiore minimo per quattro task, si pu concludere che linsieme schedulabile. In Figura 3.3 riportata la schedulazione dei task dellinsieme nellipotesi che i task sporadici si attivino ad intervalli pari al minimo tempo di interarrivo.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
2
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
J1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
J2
Figura 3.3 Schedulazione dellinsieme con Rate Monotonic
45
Se la deadline relativa del processo sporadico non coincide con il minimo tempo di interarrivo, lalgoritmo Rate Monotonic si rivela inadeguato. In questi casi necessario utilizzare lalgoritmo Deadline Monotonic e assegnare ad ogni processo periodico o sporadico, una priorit inversamente proporzionale alla propria deadline relativa.
SCHEDULAZIONE DI PROCESSI SOFT REAL TIME
In generale un sistema di elaborazione hard real time si pu pensare composto da un insieme di processi con diverse esigenze temporali. Accanto ai processi hard real time, che necessitano di una garanzia assoluta di esecuzione, necessario schedulare dei processi soft real time per i quali il rispetto delle deadline non deve necessariamente essere assoluto; possibile per questi processi pensare che la deadline sia una sorta di indicazione temporale per garantire una schedulazione di buona qualit. Consideriamo da questo punto in avanti processi soft real time di tipo sporadico. Questi processi sono caratterizzati da due deadline: Deadline relativa soft: valore limite che indica listante entro cui il processo dovrebbe preferibilmente terminare; il rispetto di questa deadline solo desiderabile, il processo soft real time e quindi accettabile anche il superamento della deadline. Deadline di validit: valore entro cui significativo eseguire il processo; se il processo esegue entro questo istante la sua elaborazione valida, in caso contrario il processo deve essere terminato. Si noti che la deadline di validit non una deadline hard, essa serve solo per indicare un limite oltre il quale perde significato lesecuzione del processo e questo indipendentemente dalla quantit di elaborazione che stata eseguita. Se il processo soft produce un risultato successivo alla deadline di validit, tale risultato ininfluente per il sistema e deve essere scartato. La deadline soft sempre minore o uguale alla deadline di validit e coincide con il minimo tempo di interarrivo del task. Nella Figura 4.1 sono illustrate le caratteristiche temporali di un task soft real time.
46
arrivo
t Dsoft Dvalidit
Figura 4.1 Caratteristiche temporali dei task soft real time La schedulazione dei processi soft real time non deve in alcun modo pregiudicare la schedulazione dei processi hard real time, quindi, riferendoci sempre a un contesto di schedulazione su base prioritaria, possiamo pensare che esista un range di priorit soft nel quale vengano tradotte le deadline soft che caratterizzano i processi soft real time. Affinch la schedulazione dei task hard real time non venga compromessa necessario che la massima priorit soft sia strettamente minore della minima priorit hard.
MAX_HARD_PRIORITY > Insieme dei task hard real time
> MIN_HARD_PRIORITY Mapping caratteristiche temporali priorit
>
MAX_SOFT_PRIORITY > Insieme dei task hard real time
> MIN_SOFT_PRIORITY
Figura 4.2 Priorit di esecuzione per i task hard real time e i task soft real time
47
Lassegnazione di un valore di priorit ad un processo soft real time avviene attraverso un meccanismo analogo a quello studiato per i processi hard real time. In particolare si pu adottare uno schema di schedulazione con priorit soft inversamente proporzionale alla deadline soft. Esempio 1. Assegnazione delle priorit. Si consideri linsieme di task =, dove ={1, 2, 3, 4, 5} un insieme di task periodici hard real time ordinati per deadline crescenti D1D2D3D4D5, e ={1, 2, 3} un insieme di task sporadici soft real time ordinati per deadline soft crescenti DS1DS2DS3. Supponendo di disporre di un sistema operativo che fornisca cento valori di priorit e che la priorit minima sia zero, lassegnazione delle priorit secondo lalgoritmo Deadline Monotonic riportata nella Tabella 4.1. Task 1 2 3 4 5 1 2 3 Priorit 7 6 5 4 3 2 1 0
Tabella 4.1 In linea generale una politica di schedulazione che pu soddisfare le esigenze dei processi soft real time la schedulazione di tipo best effort. Sostanzialmente si immagina di adottare una strategia di schedulazione a priorit fissa conoscendo a priori tutte le caratteristiche di tutti i task che si dovranno eseguire, inizialmente lo schedulatore analizza linsieme dei processi soft real time considerandoli a tutti gli effetti come processi hard real time (in pratica si considera linsieme dei processi hard real time come lunione dellinsieme dei processi hard real time originari con linsieme dei processi soft real time) ed esegue il test di schedulabilit. In caso di schedulazione fattibile il sistema esegue tutti i processi soft real time con garanzia temporale assoluta, cio considerandoli task hard real time a tutti gli effetti. Nel caso non sia possibile garantire in modo assoluto anche i soft
48
real time, lo schedulatore li esegue realizzando la migliore schedulazione possibile (best effort): i processi soft con deadline relativa pi breve avranno una priorit pi alta e quindi andranno in esecuzione prima di altri processi soft con necessit meno stringenti. Il diagramma di flusso della strategia di schedulazione appena esposta riportato nella Figura 4.3. Si osservi che rappresenta linsieme dei task hard real time, e linsieme dei task soft real time.
BEGIN
Test di schedulabilit per
NO Fattibile?
Schedulazione non fattibile
YES Test di schedulabilit per
YES Fattibile?
Schedulazione garantita per
NO Schedulazione garantita per e best effort per
END
Figura 4.3 Schedulazione di task hard real time e soft real time
49
Limplementazione del meccanismo di schedulazione di insiemi misti hard/soft real time con range di priorit disgiunti, pu essere realizzata immaginando di creare due ready queue distinte per processi hard e per processi soft real time. I processi presenti nelle due code sono ordinati per priorit crescente in modo che il primo task sia quello a priorit maggiore. La coda dei processi hard pi prioritaria della coda dei processi soft, in altre parole, un processo soft pu andare in esecuzione se e solo se la coda dei processi hard vuota. Ovviamente, i processi soft real time che possono essere garantiti sulla base del test di schedulabilit sono considerati dal sistema come processi hard real time e inseriti nella coda dei processi hard real time. La Figura 4.4 illustra lo schema concettuale del meccanismo appena considerato.
preemption
attivazione
Ready Queue Hard Real Time
terminazione CPU attivazione Ready Queue Soft Real Time preemption
Figura 4.4 Schedulazione di processi hard e soft real time
4.1
CONCLUSIONI
Il modello di schedulazione descritto sopra consente di estendere le indicazioni riguardanti i vincoli temporali anche ai processi soft real time. Questo possibile traducendo i vincoli temporali relativi alle deadline in priorit attraverso uno qualsiasi degli algoritmi visti in precedenza. Nel caso di task soft real time per le deadline non sono vincoli rigidi, ma semplici indicazioni riguardanti gli obiettivi della schedulazione: limpossibilit di garantire il rispetto di una deadline soft non fa fallire il test di schedulabilit. Lestensione del test di schedulabilit ai processi soft real time consente di trattare i processi soft real time garantiti come processi hard real time, e lutilizzo di intervalli diversi di priorit per i pro50
cessi hard e per quelli soft consente di garantire la schedulazione dei processi hard indipendentemente dal numero e dalle caratteristiche di quelli soft.
SCHEDULAZIONE DI PROCESSI ANYTIME
Un processo anytime un processo che raffina iterativamente la qualit della propria elaborazione. Si pu immaginare un processo anytime come un susseguirsi di istanze che operano sugli stessi dati producendo via via un risultato di qualit superiore. In generale, un processo anytime pu essere sia periodico che sporadico. Nel caso periodico literazione sul risultato prodotto limitata a ciascun periodo del task, e quindi ogni periodo caratterizzato da una serie di istanze del processo che elaborano lo stesso risultato. La Figura 5.1 illustra graficamente il comportamento di un generico processo anytime allinterno di un periodo.
T1
A0
A1
A2
A3
A4
A5
Indice di qualit dellelaborazione
Figura 5.1 Processo anytime La prima istanza di un processo anytime caratterizzata da un tempo di calcolo SI che comprende un tempo di setup dovuto al codice di inizializzazione. Il tempo di calcolo delle istanze successive indicato con I e in generale vale la seguente relazione:
SI I
Un possibile esempio di processo anytime presente in un sistema robotico il processo dedicato alla localizzazione attraverso matching di mappe topologiche: dopo una prima fase di generazione di ipotesi di localizzazione il processo procede migliorando il risultato con un approccio iterativo riconducibile a quello descritto sopra. 51
Definizione 1. Qualit limite. La qualit limite rappresenta la massima qualit dellelaborazione di un processo anytime che il sistema interessato a considerare. La qualit limite rappresenta il limite oltre cui non interessa raffinare il risultato in quanto il costo dellelaborazione superiore al miglioramento della qualit del risultato. In altre parole, quando un processo anytime ha raggiunto la qualit limite il sistema impedisce una sua ulteriore schedulazione allinterno del periodo corrente. Il valore della qualit limite dipende ovviamente dal tipo di attivit eseguita del processo considerato e dalla sua implementazione. Definizione 2. Qualit minima garantita. La qualit minima garantita rappresenta la minima qualit di elaborazione che deve essere garantita perch il sistema funzioni correttamente. Lesistenza di una qualit minima garantita obbliga il sistema a schedulare il processo anytime secondo una modalit mista: Le istanze necessarie per raggiungere la qualit di elaborazione devono essere schedulate in modo hard; Le istanze che raffinano il risultato oltre la qualit sono schedulate in modo soft.
La Figura 5.2 illustra graficamente le differenti modalit di schedulazione che caratterizzano un task anytime.
A0
A1
A-1
Aj
Istanze da schedulare in modalit hard real time per garantire la qualit
Possibilit di schedulazione soft real time di altre istanze
Figura 5.2 Schedulazione di un task anytime
52
I processi anytime sono spesso legati a processi periodici hard real time con vincoli di precedenza. Riprendendo lesempio precedente, il processo che realizza la localizzazione del robot deve essere eseguito prima di qualsiasi processo che utilizzi la posizione del robot durante la sua esecuzione. Definizione 3. Qualit minima richiesta. Si consideri un processo periodico hard real time vincolato al processo anytime , si definisce qualit minima richiesta dal processo al processo la qualit che deve essere raggiunta dallelaborazione del processo anytime prima che il processo possa andare in esecuzione. In altre parole, il processo non pu essere schedulato prima che il processo sia in grado di produrre un risultato di qualit . La Figura 5.3 illustra graficamente il legame tra i due processi.

A0
A1
A-1
Figura 5.3 Vincoli di precedenza tra processi Ai fini della schedulazione possibile considerare le prime istanze del processo come unestensione del processo , infatti esse devono necessariamente essere eseguite per 53
poter schedulare questultimo. Per poter eseguire correttamente il test di schedulabilit necessario sostituire il task con il task caratterizzato dai seguenti parametri: T C D T C + SI + (-1)I D
Il task un task aggregato che considera il tempo di elaborazione necessario per ottenere la qualit dallelaborazione del task anytime come richiesto dal processo . Quindi il periodo e la deadline del task sono identici a quelli del task , mentre il tempo di calcolo ottenuto sommando il tempo di calcolo del task con il tempo di elaborazione necessario per ottenere la qualit dal task . Ricordando che la prima istanza di un task anytime ha tempo computazione SI, mentre le successive hanno un tempo di calcolo I, immediato ricavare per il task aggregato : C = C + SI + ( 1) I Una volta eseguito il test di schedulabilit per garantire la qualit possibile verificare se il sistema in grado di garantire al task una migliore qualit del risultato elaborato dal task , assicurando comunque la schedulabilit dei task hard real time presenti nel sistema. A tal fine possibile eseguire iterativamente il test di schedulabilit aumentando ad ogni ciclo la qualit richiesta fino a raggiungere la qualit limite o la non schedulabilit dei task. Come risultato di questa analisi statica si pu ricavare una qualit garantita al task tale che:

Nella Figura 5.4 riportato il diagramma di flusso dellanalisi statica di qualit.
54
BEGIN
Test di schedulabilit con
NO Fattibile? YES
Non si pu garantire
= NO +1 Aggiornamento di
YES
Test di schedulabilit con
YES Fattibile? NO 1
Garantita qualit
END
Figura 5.4 Diagramma di flusso dellanalisi statica di qualit
55
Nel caso siano presenti pi task anytime con processi vincolati sufficiente ripetere lanalisi statica di qualit per ogni task vincolato ottenendo la qualit garantita a ciascuno di essi.
SCHEDULAZIONE DI PROCESSI NON REAL TIME
6.1
INTRODUZIONE
La caratteristica dei processi non real time quella di non richiedere alcuna garanzia di esecuzione. Quando, in un sistema real time, si definisce un processo non real time si accetta che questo venga eseguito solo quando nessun processo hard o soft real time pronto. Si osservi che la scelta di definire processi non real time deve essere fatta con grande cautela tenendo conto del carico del sistema. Infatti se il carico computazionale relativo ai processi real time elevato, il tempo residuo per lesecuzione di processi non real time pu essere scarso, arrivando a causare, in condizioni limite, un fenomeno di starvation. Si osservi che il carico computazionale del sistema pu essere facilmente valutato considerando il fattore di utilizzazione del processore U. Valori elevati di U implicano una notevole utilizzazione del processore da parte dei task real time e scarsa disponibilit di tempo di elaborazione per i task non real time. 6.2 SCHEDULAZIONE IN BACKGROUND
La tecnica pi semplice per schedulare processi non real time quella della schedulazione in background: il processore viene assegnato a un processo non real time solo quando libero (idle) e non ci sono processi hard o soft real time pronti. Nonostante la schedulazione in background sia piuttosto inefficiente, essa risulta di facile realizzazione. Limplementazione pu essere realizzata creando una ready queue per i processi real time e una per i processi non real time. La seconda coda viene servita solo quando la prima vuota, cio nessun task real time pronto. Si osservi che le strategie di gestione delle due code sono indipendenti.
56
Schedulazione Real Time preemption
attivazione
Ready Queue Real Time
terminazione CPU attivazione Ready Queue Background preemption
Figura 6.2.1 Schedulazione di processi real time e non real time La coda a bassa priorit pu essere gestita con un qualsiasi algoritmo di schedulazione per task non real time, tipo Shortest Job First, Round Robin, First Come First Served, ecc. In genere si preferisce adottare lalgoritmo Round Robin fissando un quanto di tempo sulla base delle caratteristiche dei task presenti nel sistema. Una soluzione particolarmente interessante pu essere quella di assegnare a ciascun processo un quanto temporale variabile dipendente dalle esigenze computazionali del processo. Note le caratteristiche temporali di tutti i processi real time possibile fornire una stima del tempo di idle time del processore e quindi del tempo a disposizione dei processi non real time. In particolare si possono calcolare due stime: una nel caso in cui tutti i processi sporadici real time non si attivino e una nel caso in cui si attivino. Questi due valori rappresentano il range in cui varia il tempo a disposizione per eseguire i processi non real time. Definizione 1. Iperperiodo. Nellipotesi che tutti i task periodici siano attivati simultaneamente allistante zero, il minimo comune multiplo tra i periodi dei task periodici H detto iperperiodo del sistema. Liperperiodo interessante in quanto la schedulazione dei task periodici si ripete ogni H unit di tempo. Infatti, negli istanti tk=kH, con k intero non negativo, le richieste dei task periodici sono tutte allineate tra loro. Definizione 2. Tempo di idle time massimo. Se U1 rappresenta il fattore di utilizzazione del processore e H1 liperperiodo nel caso in cui nessun task spora-
57
dico presente nel sistema sia attivo, il tempo di idle time massimo max definito come: max = (1 U1 ) H1
Definizione 3. Tempo di idle time massimo. Se U2 rappresenta il fattore di utilizzazione del processore e H2 liperperiodo nel caso in cui tutti i task sporadici presente nel sistema siano attivi, il tempo di idle time minimo min definito come: min = (1 U 2 ) H 2 Il tempo di idle time massimo e minimo possono essere utilizzati per valutare quanto tempo di elaborazione disponibile per i processi non real time in ogni iperperiodo. In particolare, sulla base delle caratteristiche temporali dei processi non real time presenti nel sistema, possibile stabilire se il tempo dedicato alla loro esecuzione sufficiente o meno. 6.3 SERVER
Il tempo di risposta medio dei processi non real time pu essere migliorato, rispetto alla tecnica della schedulazione in background, riservando un processo periodico (detto server) al servizio delle richieste non real time. Il processo server assimilabile ad un qualunque altro processo ed caratterizzato dai seguenti parametri: Periodo Ts; Tempo di calcolo Cs, detto capacit del server.
In generale, il processo server viene schedulato con lo stesso algoritmo utilizzato per gli altri task periodici e, una volta attivato, effettua il servizio delle richieste pendenti provenienti dai task non real time, entro i limiti della sua capacit. Lordine di servizio delle richieste indirizzate al server indipendente dallalgoritmo di schedulazione utilizzato per i task real time, e pu essere deciso in funzione delle caratteristiche dei task non real time presenti nel sistema. Si osservi che, dal punto di vista della garanzia, si richiede che lesecuzione dei task non real time non pregiudichi la schedulabilit dei task real time. In altre parole, il migliora-
58
mento delle prestazioni nel servizio delle richieste dei task non real time pu essere ottenuto ritardando lesecuzione dei processi real time, ma solo se la schedulabilit di questi ultimi comunque garantita. 6.3.1 Server a priorit statica I server a priorit statica sono meccanismi di server utilizzabili con lalgoritmo di schedulazione Rate Monotonic. Ci significa che tutti i task real time e il server stesso sono schedulati secondo le regole del Rate Monotonic, e quindi si vedono assegnata una priorit inversamente proporzionale al proprio periodo. Esistono diverse tipologie di server a priorit statica. Tra i pi importanti possiamo ricordare i seguenti: Polling Server; Deferrable Server; Priority Exchange; Sporadic Server.
Di seguito sono descritte sinteticamente le caratteristiche principali di ciascun server, per unanalisi pi approfondita si rimanda a [But 95]. Polling Server Lapproccio adottato da questa tecnica prevede la creazione di un processo periodico, detto polling server, dedicato al servizio delle richieste dei processi non real time. Il polling server caratterizzato da un periodo Ts e da una capacit di calcolo Cs. Allinizio di ogni periodo Ts, il processo server viene attivato per servire tutte le richieste di task non real time pendenti, alle quali viene dedicato un tempo massimo di esecuzione pari alla capacit del server. Se nellistante di attivazione periodica del server non presente alcuna richiesta, il server si sospende fino al periodo successivo, e la sua capacit non viene conservata. Si noti che una richiesta giunta allinterno di un periodo del server viene considerata durante il periodo successivo. Ai fini dellanalisi di schedulabilit dei processi real time, si pu osservare che nel peggiore dei casi, il polling server si comporta come un task periodico con tempo di calcolo pari a Cs e periodo Ts. Questo consente di valutare la schedulabilit dei task che compongono il sistema attraverso uno qualsiasi dei test di schedulabilit presentati per Rate Monotonic. 59
La tecnica del polling server migliora i tempi di risposta dei task non real time rispetto alla gestione in background. Essa consente inoltre di evitare il fenomeno della starvation in quanto, anche se il carico dei task real time elevato, ad ogni periodo Ts il server dedica allesecuzione dei task non real time un tempo Cs. Deferrable Server La tecnica del Deferrable Server stata introdotta da Lehoczky, Sha e Strosnider nel 1987 [Leh 87]. Essa consente di migliorare il tempo di risposta ottenibile attraverso la tecnica del polling. Lalgoritmo Deferrable Server prevede la creazione di un server periodico, di solito ad alta priorit, con il compito di servire le richieste provenienti dai task non real time. A differenza di quanto previsto nel Polling Server, il Deferrable Server conserva la propria capacit nel caso in cui, al momento della sua attivazione, non sia presente nessuna richiesta. Questo comportamento consente di servire immediatamente le richieste dei task e migliora il tempo di risposta complessivo. La capacit viene conservata per tutta la durata del periodo, cos che le richieste dei task non real time possano essere soddisfatte in ogni istante con la stessa priorit del server, purch la capacit non sia completamente esaurita. Ai fini dellanalisi di schedulabilit, il Deferrable Server non si comporta come un qualsiasi altro task. La presenza del server modifica il valore di Ulub, che va ricalcolato considerando il particolare comportamento di questo task anomalo. Per maggiori dettagli consultare [But 95] e [Leh 87]. Priority Exchange Si tratta di una tecnica alternativa al Deferrable Server e in grado di fornire prestazioni leggermente migliori. Lalgoritmo di Priority Exchange stato presentato da Lehoczky, Sha e Strosnider in [Leh 87]. Il Priority Exchange prevede la creazione di un server periodico, in genere ad alta priorit, per il servizio dei task non real time. Il server preserva la capacit di calcolo scambiandola con il tempo di esecuzione di un task periodico a priorit pi bassa. Allinizio di ogni periodo Ts viene ripristinata la capacit Cs del server. Se sono presenti delle richieste da arte di task non real time, queste vengono servite utilizzando la capacit Cs, altrimenti Cs viene scambiata con il tempo di esecuzione del task periodico attivo (Pi) a priorit pi alta inferiore a quella del server (Ps). Al verificarsi di uno scambio di priorit, il
60
task real time selezionato esegue alla stessa priorit del server, mentre questultimo accumula tempo di calcolo alla priorit Pi. Questo meccanismo consente di anticipare lesecuzione del task real time utilizzando la capacit non sfruttata del server, e di preservare il tempo di esecuzione del server a una priorit pi bassa. Se la capacit accumulata a una priorit Pi non viene sfruttata in tempo da qualche richiesta, essa viene ricorsivamente scambiata con il tempo di calcolo del successivo task real time attivo a priorit inferiore. Lunico caso in cui il server obbligato a sacrificare la propria capacit si ha quando il processore idle. La presenza del meccanismo sopra descritto modifica il calcolo del fattore Ulub per Rate Monotonic. Il calcolo di Ulub in presenza del Priority Exchange calcolato in [Leh 87]. Si pu osservare che il Priority Exchange caratterizzato da prestazioni migliori rispetto al Deferrable Server, ma anche pi complesso da implementare. Sporadic Server Il meccanismo di Sporadic Server consente di migliorare il tempo di risposta relativo alle richieste non real time senza degradare il limite superiore minimo del fattore di utilizzazione del processore. Diversamente dai meccanismi di server illustrati precedentemente, Sporadic Server non un vero e proprio task periodico, ma piuttosto un gestore di capacit, che viene consumata e ripristinata dinamicamente in funzione delle richieste provenienti dai task non real time. Nello Sporadic Server la capacit viene mantenuta fino allarrivo di una richiesta periodica. La differenza fondamentale tra Deferrable Server e Sporadic Server sta nel meccanismo con cui viene ripristinata la capacit del server. In particolare, in Sporadic Server la capacit viene ripristinata solo dopo che essa sia stata (parzialmente o totalmente) consumata da un richiesta. Per unanalisi dettagliata del funzionamento e delle caratteristiche di Sporadic Server si rimanda a [Spr 89] e [But 95]. 6.3.2 Server a priorit dinamica I server a priorit dinamica sono utilizzati in sistemi in cui la schedulazione dei processi real time realizzata con lalgoritmo Earliest Deadline First. Luso di algoritmo dinamici consente di raggiungere la piena utilizzazione del processore e quindi, a parit di carico, di gestire le attivit non real time con maggiore efficienza rispetto alle tecniche statiche.
61
I pi importanti meccanismi server a priorit dinamica sono i seguenti: Dynamic Priority Exchange; Dynamic Sporadic Server; Total Bandwidth Server; Earliest Deadline Late; Improved Priority Exchange.
Di seguito sono sinteticamente riportate le caratteristiche principali di ciascun server, per maggiori dettaglia si rimanda a [But 95]. Dynamic Priority Exchange Lalgoritmo Dynamic Priority Exchange [Spu 94] [Spu 95] una estensione dellalgoritmo Priority Exchange statico e prevede la creazione di un server con periodo Ts e capacit Cs. Lidea alla base dellalgoritmo che, in assenza di richieste da parte dei task non real time, la capacit del server non viene persa, ma viene scambiata con il tempo di esecuzione delle istanze real time a priorit pi bassa (ovvero con deadline pi lunga). Allarrivo di richieste non real time, tale capacit pu essere utilizzata al proprio livello di priorit per servire le richieste. Il server del Dynamic Priority Exchange si comporta come un qualsiasi altro task real time periodico. Lo scambio di tempo di esecuzione del server con quello dei task real time a priorit pi bassa non influenza la schedulabilit di questi ultimi. Il test di schedulabilit per lalgoritmo Earliest Deadline First non viene modificato dalla presenza del server che viene considerato nel fattore di utilizzazione come un normale task real time di periodo Ts e tempo di esecuzione Cs. Dynamic Sporadic Server La tecnica Dynamic Sporadic Server lestensione in un contesto dinamico della tecnica statica Sporadic Server. Dynamic Sporadic Server prevede la creazione di un server con periodo Ts e capacit Cs dedicato al servizio delle richieste provenienti da task non real time. Dynamic Sporadic Server prevede che la capacit del server non venga ripristinata al suo valore nominale allinizio di ogni nuovo periodo, ma solo dopo che stata consumata. Gli istanti di tempo in cui avviene il ripristino della capacit sono calcolati attraverso una regola di riempimento che consente di raggiungere la piena utilizzazione del processore.
62
La differenza principale tra Sporadic Server e Dynamic Sporadic Server consiste nellassegnazione della priorit al processo server che nel primo caso avviene staticamente secondo lalgoritmo Rate Monotonic, mentre nel secondo caso avviene dinamicamente sulla base dellalgoritmo Earliest Deadline First. Si pu dimostrare che Dynamic Sporadic Server si comporta, nel caso peggiore, come un task periodico con periodo Ts e tempo di calcolo Cs. Questo risultato consente di utilizzare il test di schedulabilit standard per lalgoritmo Earliest Deadline First. Per maggiori dettagli su Dynamic Sporadic Server consultare [Spu 94], [Gah 95] e [But 95]. Total Bandwidth Server Dalle caratteristiche del Dynamic Sporadic Server si pu dedurre che, se il periodo del server lungo, lesecuzione delle richieste provenienti dai task non real time pu essere notevolmente ritardata. Un primo modo di risolvere questo problema quello di definire un Dynamic Sporadic Server con periodo molto corto. Questa soluzione comporta per un aumento di overhead di sistema a causa della frammentazione della capacit che genera un numero maggiore di cambi di contesto essendo gli esaurimenti di capacit pi frequenti. Una seconda soluzione prevede di assegnare una deadline pi vicina ad ogni richiesta non real time. Lassegnazione deve essere tale da non pregiudicare la schedulabilit dei task real time e quindi deve mantenere il fattore di utilizzazione del carico non real time entro il valore massimo specificato Us. Su questa idea si fonda il Total Bandwidth Server [Spu 94] [Spu 95], il cui nome deriva dal fatto che ogni richiesta non real time che arriva nel sistema riceve immediatamente tutta la banda al momento disponibile. Lalgoritmo Total Bandwidth Server prevede per la kesima richiesta attivata al tempo rk lassegnazione della deadline dk:
d k = max{rk , d k 1 } +
Ck Us
dove Ck il tempo di esecuzione della richiesta non real time e Us il fattore di utilizzazione del server (ovvero la sua banda). Per definizione di pone d0=0. La banda assegnata alle richieste precedenti viene considerata attraverso la deadline dk-1.
63
Una volta assegnata la deadline, la richiesta non real time pu essere inserita nella coda pronti insieme agli altri task ed essere schedulata attraverso lalgoritmo Earliest Deadline First. Si pu dimostrare che Total Bandwidth Server si comporta nel peggiore dei casi come un task periodico il cui fattore di utilizzazione non supera mai il valore Us. Questo risultato consente di utilizzare il test di schedulabilit classico per Earliest Deadline First per verificare la schedulabilit di un sistema costituito da task real time e da un Total Bandwidth Server. Earliest Deadline Late Lalgoritmo Earliest Deadline Late prevede lordinamento dei task attivi secondo deadline crescenti come Earliest Deadline First, per i task sono schedulati il pi tardi possibile. Si pu dimostrare che Earliest Deadline Late garantisce in ogni intervallo [0, t] il massimo idle disponibile. Lidea alla base del server Earliest Deadline Late quella di utilizzare gli idle time ottenuti dalla schedulazione Earliest Deadline Late per eseguire le richieste non real time appena possibile. Si pu dimostrare che lalgoritmo ottimo ma risulta molto costoso in termini computazionali. Lanalisi di schedulabilit di un insieme di task periodici in presenza di un server Earliest Deadline Late molto semplice in quanto le richieste non real time sono servite durante gli idle time disponibili senza compromettere la schedulabilit dellinsieme periodico. Il test di schedulabilit da utilizzare quindi il test visto per lalgoritmo Earliest Deadline First. Per maggiori dettagli sulla tecnica Earliest Deadline Late consultare [Cht 91], [Spu 94], [Spu 95] e [But 95]. Improved Priority Exchange Lalgoritmo Improved Priority Exchange si comporta in modo simile a Earliest Deadline Late ed caratterizzato da una complessit computazionale inferiore. Improved Priority Exchange utilizza gli idle time caratteristici di una schedulazione Earliest Deadline Late (calcolati offline) per aggiornare la capacit di un server Dynamic Priority Exchange, ottenendo una strategia di riempimento pi efficiente rispetto a quella adattata dallalgoritmo Dynamic Priority Exchange. Inoltre il server Improved Priority
64
Exchange pu eseguire sempre alla massima priorit, in quanto esso non ha pi unattivazione periodica. Si noti che i casi in cui Improved Dynamic Priority si comporta peggio di Earliest Deadline Late sono rari. Simulazioni su insiemi di task generati casualmente dimostrano che le prestazioni di Improved Dynamic Priority sono molto simili a quelle di Earliest Deadline Late. Si dimostra che il server Improved Priority Exchange non influenza la schedulabilit dei task real time, infatti se Up il loro fattore di utilizzazione il server alloca automaticamente la banda (1-Up) alle richieste non real time. Quindi per verificare la schedulabilit di un sistema che comprende un server Improved Priority Exchange sufficiente utilizzare il test di schedulabilit per lalgoritmo Earliest Deadline First sullinsieme dei task real time.
INTRODUZIONE AI PROTOCOLLI DI ACCESSO A RISORSE CONDIVISE
7.1
INTRODUZIONE
In ogni sistema concorrente necessario realizzare dei meccanismi che proteggano risorse condivise tra pi processi. Lapplicazione diretta delle classiche primitive che garantiscono la sincronizzazione dei processi e laccesso protetto alle risorse (ad esempio semafori, monitor, ecc.) in un sistema real-time pu provocare il fenomeno noto con il nome di inversione di priorit. Si indica con inversione di priorit la situazione che si viene a creare quando un processo ad alta priorit viene bloccato da un processo a priorit pi bassa a causa della mutua esclusione su una risorsa condivisa. Laspetto critico dellinversione di priorit sta nel fatto che il bloccaggio avviene per un tempo indefinito, compromettendo cos la schedulabilit e la prevedibilit del sistema. Tipicamente questa situazione si verifica quando due processi tentano di accedere a una struttura dati condivisa. Al fine di preservare la consistenza dei dati memorizzati, gli accessi da parte dei processi dovranno essere serializzati. Nel caso in cui il processo a priorit pi alta guadagni per primo laccesso alla risorsa condivisa lordine prioritario di esecuzione sar rispettato. Se al contrario il processo a priorit pi bassa ad occupare per primo la risorsa, allora il processo ad alta priorit dovr attendere finch questo non liberer la struttura dati. Una occupazione prolungata della risorsa da parte del processo a bassa prio65
rit pu portare ad un timeoverflow anche in condizioni di bassa utilizzazione del processore. Nella Figura 7.1.1 illustrato un esempio di timeoverflow dovuto allinversione di priorit.
tentativo di accesso alla sezione critica SC
J1 SC t J2 SC a1 t1 SC t2 t
Figura 7.1.1 Timeoverflow dovuto allinversione di priorit Inoltre il bloccaggio non ha durata prevedibile; infatti mentre il processo a bassa priorit occupa la risorsa, processi a media priorit che non usano la risorsa in questione possono arrivare nel sistema ed essere eseguiti sospendendo il processo a bassa priorit. facile immaginare allora come il processo ad alta priorit possa essere ritardato anche per lungo tempo e in modo del tutto indipendente dal tempo che complessivamente il processo a bassa priorit esegue occupando la risorsa condivisa. Una prima semplice soluzione al fenomeno dellinversione di priorit quella di impedire la preemption su processi che si trovino allinterno di sezioni critiche. Questo approccio pu essere efficace solo nel caso di sezioni critiche molto corte, poich d luogo a bloccaggi inutili. Adottando questa tecnica nel caso di sezioni critiche molto lunghe si potrebbe presentare il caso di un bloccaggio di un processo ad alta priorit da parte di uno a bassa priorit, anche nel caso in cui il primo non usi risorse condivise. Una soluzione pi affidabile ed efficace quella di adottare opportuni protocolli per poter accedere alle sezioni critiche.
66
7.2
PROTOCOLLO DI PRIORITY INHERITANCE
7.2.1 Generalit Il protocollo di Priority Inheritance, definito in [Sha 90], consente di risolvere il problema dellinversione di priorit causato dallaccesso a strutture dati condivise. Alla base del protocollo c lidea di realizzare un cambiamento dinamico della priorit del processo che accede alla sezione critica e blocca un processo a pi alta priorit. Riassumiamo nei seguenti punti le ipotesi su cui si base il protocollo e la terminologia di cui faremo uso [But 95]: Diciamo che un processo bloccato nel caso in cui esso sia in attesa per lesecuzione di un processo a priorit pi bassa. I processi non si auto-sospendono. Ogni processo possiede una priorit nominale fissa, assegnata a priori da un algoritmo di schedulazione statica come ad esempio Deadline Monotonic. Processi con la stessa priorit sono serviti secondo una politica FCFS (First Come First Served). I processi J1, J2, , Jn sono ordinati secondo priorit nominali decrescenti. Le sezioni critiche usate da un processo possono essere annidate a condizione che una sezione critica sia contenuta interamente in unaltra. I semafori che proteggono ogni sezione critica sono binari, quindi luso della risorsa limitato a un solo processo alla volta.
7.2.2 Definizione del protocollo Tenendo conto delle ipotesi formulate nel paragrafo precedente, il protocollo di Priority Inheritance pu essere definito come segue [But 95]: Se il processo Ja si blocca allingresso di una sezione critica occupata da Jb, trasmette la sua priorit al processo Jb. Quindi Jb esegue la sezione critica con una priorit pari alla massima priorit dei processi da esso bloccati. Si dice che Jb eredita la priorit dei processi bloccati. Alluscita della sezione critica il processo J riacquista la priorit che aveva prima di entrarvi.
67
Lereditariet della priorit transitiva. Ad esempio se J3 blocca J2, che a sua volta blocca J1, allora J3 eredita la priorit di J1 attraverso J2.
Applicando questo protocollo un processo ad alta priorit pu essere bloccato da un processo a bassa priorit in due modi [But 95]: Definizione 1. Direct blocking. Si definisce direct blocking (bloccaggio diretto) la situazione di blocco dovuta alloccupazione della risorsa condivisa da parte di un processo a bassa priorit. Questa forma di bloccaggio necessaria per garantire la consistenza della risorsa.
Definizione 2. Pushthrough blocking. Si definisce pushthrough blocking (bloccaggio indiretto) la situazione di blocco di un processo a media priorit J M da parte di un processo a bassa priorit JL, che eredita la priorit da un processo ad alta priorit JH. Questa forma di bloccaggio necessaria per evitare che il processo a media priorit ritardi indirettamente quello ad alta.
7.2.3 Propriet del protocollo Per descrivere sinteticamente le propriet formali del protocollo introduciamo le seguenti notazioni [But 95]: pri e Ti sono rispettivamente la priorit e il periodo del processo Ji. P(Si) e V(Si) rappresentano rispettivamente le operazioni semaforiche wait e signal sul semaforo binario Si. Zi,j rappresenta la jesima sezione critica del processo Ji, cio il segmento di codice compreso tra la jesima operazione P e la corrispondente operazione V del processo Ji. di,j indica la durata della sezione critica Zi,j nel caso Ji sia lunico processo in esecuzione. Zi,j Zi,k indica che la sezione Zi,k interamente contenuta in Zi,j. i indica linsieme di tutte le sezioni critiche del processo Ji. i,j indica linsieme delle sezioni critiche del processo a bassa priorit Jj che possono bloccare il processo a pi alta priorit Ji: i,j = k j k<i.
68
*i,j indica linsieme delle sezioni critiche pi esterne del processo a bassa priorit Jj che possono bloccare il processo a pi alta priorit Ji: *i,j = {Zj,k | (Zj,ki,j) (~Zj,m | Zj,m Zj,k)}.
*i indica linsieme di tutte le sezioni critiche che possono bloccare il processo Ji: *i = j>i *i,j.
Si possono dimostrare i seguenti risultati [But 95]. Teorema 1. Un processo J0 pu essere bloccato al massimo su una sezione critica in ciascun insieme *0,i con 1in.
Teorema 2. Se m semafori possono bloccare un processo J0, allora J0 pu essere bloccato al massimo m volte.
Teorema 3. Un processo J pu essere bloccato al massimo per la durata di min(n,m) sezioni critiche, dove n il numero di processi a priorit pi bassa di J, ed m il numero di semafori che possono bloccare J. Il protocollo di Priority Inheritance risolve il problema dellinversione di priorit. Nonostante questo pregio, al fine di valutare lefficacia pratica del protocollo in un ambiente concorrente real-time, va osservato che il protocollo soffre di due problemi rilevanti: non previene lo stallo tra processi e non elimina la possibilit di bloccaggi a catena. Essendo il deadlock un evento critico per un qualunque sistema di elaborazione, e quindi in particolare per un sistema che esegua processi hard real-time, la capacit di assicurare leliminazione delle condizioni di stallo una propriet altamente desiderabile per un protocollo di accesso a risorse condivise. La possibilit che si verifichino bloccaggi a catena invece pu comportare un notevole allungamento della durata dellintervallo di bloccaggio di un processo ad alta priorit. Se si vuole risolvere questi due problemi il protocollo di Priority Inheritance non sufficiente e si devono prendere in considerazione altre tecniche.
69
7.3
PROTOCOLLO DI PRIORITY CEILING
7.3.1 Generalit Il protocollo di Priority Ceiling [Sha 90] consente di risolvere il fenomeno dellinversione di priorit e inoltre evita le condizioni di stallo e i bloccaggi a catena. Alla base di questo protocollo c lidea di assicurare che, quando un processo J effettua preemption su una sezione critica di un altro processo ed esegue la propria sezione critica Z, la priorit con cui esegue Z sia pi alta di tutte le priorit ereditabili dai processi correntemente sospesi in sezioni critiche. Se questa condizione non soddisfatta il protocollo impedisce a J di entrare nella sezione critica, e il processo che blocca J eredita la sua priorit. Per realizzare questo meccanismo viene assegnato a ciascun semaforo un tetto di priorit (priority ceiling) pari alla pi alta priorit dei processi che possono usare quel semaforo. Un processo J pu entrare in una sezione critica solo se la sua priorit strettamente maggiore di tutti i tetti di priorit associati ai semafori bloccati dai processi diversi da J. 7.3.2 Definizione del protocollo Formalmente la definizione del protocollo di Priority Ceiling pu essere descritta dai seguenti punti [But 95]: Sia J il processo a pi alta priorit tra i processi pronti, quindi J schedulato per lesecuzione. Sia S* il semaforo avente il pi alto tetto di priorit tra tutti i semafori occupati dai processi diversi da J, e sia c(S*) il suo ceiling. Per poter entrare in una sezione critica protetta dal semaforo S, il processo J deve avere priorit strettamente maggiore di c(S*); in caso contrario J viene bloccato e si dice che J bloccato sul semaforo S* da parte del processo che detiene S*. Se il processo J, entrando in una sezione critica, blocca processi a priorit pi elevata, eredita la priorit prh, corrispondente alla priorit pi alta dei processi bloccati da J stesso. Quando J esce dalla sezione critica, esso riacquista il livello di priorit precedente. Il meccanismo di ereditariet della priorit transitivo.
70
Il protocollo di Priority Ceiling introduce una nuova forma di bloccaggio denominata ceiling blocking, cio il blocco di un processo che tenta di accedere a una sezione critica libera avendo per una priorit non strettamente maggiore del ceiling massimo. Questo tipo di bloccaggio necessario per evitare catene di bloccaggi e situazioni di stallo. 7.3.3 Propriet del protocollo I seguenti teoremi mostrano due importanti propriet del protocollo di Priority Ceiling [But 95]. Teorema 1. Il protocollo di Priority Ceiling previene lo stallo.
Teorema 2. Un processo Ji pu essere bloccato al massimo per la durata di una sola sezione critica di *i. Come visto sopra il protocollo di Priority Ceiling introduce il ceiling blocking oltre ai tipi di bloccaggio caratteristici del Priority Inheritance. Tuttavia, il ceiling blocking consente di ottenere il notevole miglioramento di prestazioni che caratterizza Priority Ceiling evitando lo stallo e le catene di bloccaggi e migliorando la condizione peggiore di blocco. Infatti, con il protocollo in questione un processo pu essere bloccato al massimo per la durata di una sola sezione critica.
71
Bibliografia
[Aud 90] Audsley, N. C. 1990. Deadline Monotonic Scheduling, Technical Report YCS 146, Department of Computer Science, University of York. [Aud 91] Audsley, N. C., Burns, A., Richardson, M. F., Wellings, A. J. 1991. Hard Real Time Scheduling: The Deadline Monotonic Approach, in Eighth IEEE Workshop on Real Time Operating Systems and Software, pp. 133137. [Aud 93] Audsley, N. C., Burns, A., Richardson, M., Tindell, K., Wellings, A. 1993. Applying New Scheduling Theory to Static Priority Preemptive Scheduling, in Software Engineering Journal, 8(5): 284292. [Aud 95] Audsley, N. C., Burns, A., Davis, R. I., Tindell, K. W., Wellings, A. J. 1995. Fixed Priority Preemptive Scheduling: An Historical Perspective, in Real Time Systems, 8: 173198. [Bar 90] Baruah, S. K., Rosier, L. E., Howell, R. R. 1990. Algorithms and Complexity Concerning the Preemptive Scheduling of Periodic, Real Time Tasks on One Processor, in Real Time Systems, 3: 301324. [Bur 91] Burns, A., Wellings, A. J. 1991. Priority Inheritance and Message Passing Communication: A Formal Treatment, in The Journal of Real Time Systems, 3: 1944. [Bur 95] Burns, A., Wellings, A. J. 1995. Engineering a Hard Real Time System: From Theory to Practice, in Software Practice & Experience , 25(7): 705726. [But 95] Buttazzo, G. C. 1995. Sistemi in Tempo Reale.
72
[Chn 90]
Chen, M. I., Lin, K. J. 1990. Dynamic Priority Ceilings: A Concurrency Control Protocol for Real Time Systems, in Real Time Systems Journal, 2(4): 325346.
[Chg 87]
Cheng, S.C. 1987. Scheduling Algorithms for Hard Real Time Systems, in Hard Real Time Systems, IEEE Computer Society Press, pp. 150173.
[Cht 91]
Chetto, H., Chetto, M. 1991. An Adaptive Scheduling Algorithm for Fault Tolerant Real Time Systems, in Software Engineering Journal, May 1991.
[Fid 98]
Fidge, C. J. 1998. Real Time Schedulability Test for Preemptive Multitasking, in Real Time Systems, 14: 6193.
[Gah 95]
Ghazalie, T. M., Baker, T. P. 1995. Aperiodic Servers in a Deadline Scheduling Environment, in The Journal of Real Time Systems, 9(5): 3166.
[Gar 75]
Garey, M. R., Johnson, D. S. 1975. Complexity Results for Multiprocessor Scheduling Under Resource Constraints, in SIAM (Society for Industrial and Applied Mathematics) Journal of Computing.
[Jef 91]
Jeffay, K., Stanat, D. F., Martel, C.U. 1991. On Nonpreeemptive Scheduling of Periodic and Sporadic Tasks, in IEEE Real Time System Symposium (IEEE Press).
[Leh 87]
Lehoczky, J. P., Sha, L., Strosnider, J. K. 1987. Enhanced Aperiodic Responsiveness in Hard Real Time Environments, in Proceedings of the IEEE Real Time Systems Symposium, pp. 261270, San Jose, CA, December 1987.
[Leh 89]
Lehoczky, J. P., Sha, L., Ding, Y. 1989. The Rate Monotonic Scheduling Algorithm: Exact Characterization and Average Case Behaviour, in Proceedings of the IEEE Real Time Systems Symposium, pp. 166171.
73
[Leh 90]
Lehoczky, J. P. 1990. Fixed Priority Scheduling of Periodic Task Sets with Arbitrary Deadlines, in Proceedings of the IEEE Real Time Systems Symposium, IEEE Computer Society Press, pp. 201209.
[Leh 91]
Lehoczky, J. P., Sha, L., Strosnider, J. K., Tokuda, H. 1991. Fixed Priority Scheduling Theory for Hard Real Time Systems, in Foundations of Real Time Computing: Scheduling and Resource Management, Kluwer Academic Publisher, 130.
[Leu 80]
Leung, J. Y.T., Merrill, M. L. 1980. A Note on Preemptive Scheduling of Periodic, Real Time Tasks, in Information Processing Letters, 11: 115118.
[Leu 82]
Leung, J., Whitehead, J. 1982. On the Complexity of Fixed Priority Scheduling of Periodic Real Time Tasks, in Performance Evaluation, 2(4), pp. 237250.
[Liu 73]
Liu, C. L., Layland, J. W. 1973. Scheduling Algorithms for Multiprogramming in a Hard Real Time Environment, in Journal of the ACM, 20(1): 4061
[Man 98]
Manabe, Y., Aoyagi, S. 1998. A Feasibility Decision Algorithm for Rate Monotonic and Deadline Monotonic Scheduling, in Real Time Systems, 14: 171181.
[Rip 96]
Ripoll, I., Crespo, A., Mok, A. K. 1996. Improvement in Feasibility Testing for Real Time Tasks, in Real Time Systems, 11(1): 1939.
[Sha 90]
Sha, L., Rajkumar, R., Lehoczky, J. 1990. Priority Inheritance Protocols: An Approach To Real Time Synchronization, in IEEE Trans. on Computers, 39(9): 11751185.
[Sha 93]
Sha, L., Sathaye, S. S. 1993. A Systematic Approach to Designing Distributed Real Time Systems, in IEEE on Computers, 26:6878.
74
[Shi 94]
Shin, K. G., Ramanathan, P. 1994. Real Time Computing: A New Discipline of Computer Science and Engineering, in Proceedings of the IEEE, 82(1): 624.
[Spr 89]
Sprunt, B., Sha, L., Lehoczky, J. P. 1989. Aperiodic Task Scheduling for Hard Real Time System, in Journal of Real Time Systems, 1, pp. 27 60, June 1989.
[Spu 94A]
Spuri, M., Buttazzo, G. C. 1994. Efficient Aperiodic Service under Earliest Deadline Scheduling, in Proceedings of the 15th IEEE Real Time Systems Symposium, San Juan, Puerto Rico.
[Spu 94B]
Spuri, M., Stankovic, J. A. 1994. How to Integrate Precedence Constraints and Shared Resources in Real Time Scheduling, in IEEE Trans. on Computers, 43(12): 14071412.
[Spu 95]
Spuri, M., Buttazzo, G. C. 1995. Scheduling Aperiodic Task in Dynamic Priority Systems, in The Journal of Real Time Systems.
[Str 95]
Strosnider, J. K., Lehoczky, J. P., Sha, L. 1995. The Deferrable Server Algorithm for Enhanced Aperiodic Responsiveness in Hard Real Time Environments, in IEEE Trans. on Computers, (44)1:7391.
75

Schedulazione

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Schedulazione

Cargado por

Copyright:

Formatos disponibles

UNIVERSIT DEGLI STUDI DI GENOVA FACOLT DI INGEGNERIA

Schedulazione Real Time

Dipartimento di Informatica, Sistemistica e Telematica 2000

Schedulazione Real Time

Schedulazione Real Time

Figura 1.1.1 Schedulatore

Schedulazione Real Time

Schedulazione Real Time

VINCOLI SUI PROCESSI

Schedulazione Real Time

Schedulazione Real Time

Figura 1.3.2 Esempio di processo periodico

Schedulazione Real Time

Traduzione dei vincoli temporali in priorit

Schedulatore a base prioritaria

Schedulazione Real Time

Figura 1.3.4 Grafo di precedenza tra processi

Schedulazione Real Time

Schedulazione Real Time

Figura 1.3.6 Ciclo di vita di un processo

PROBLEMA GENERALE DELLO SCHEDULING

Schedulazione Real Time

Schedulazione Real Time

Schedulazione Real Time

Schedulazione Real Time

Schedulazione Real Time

SCHEDULAZIONE DI PROCESSI PERIODICI HARD REAL TIME

Schedulazione Real Time

Schedulazione Real Time

La Figura 2.1.2 illustra sinteticamente le grandezze sopra definite.

r(k) tempo di risposta

Figura 2.1.2 Istanza di un processo periodico

Schedulazione Real Time

Schedulazione Real Time

Schedulazione Real Time

Figura 2.2.1 Schedulazione dellinsieme A con Rate Monotonic

Schedulazione Real Time

Schedulazione Real Time

Schedulazione Real Time

Si = {Ti } {k Tj : j = 1,2,..., i 1; k = 1,2,..., floor (Ti Tj )}

Algoritmo 1. Scheduling Point Test.

Schedulazione Real Time

12. 13. 14. 15. 16.

1 tS1 2 3 L 2 = min L 2 ( t ) = tS2 4 7 L 3 = min L 3 ( t ) = tS3 8 L1 = min L1 ( t ) =

Schedulazione Real Time

t:=t; t:= SUM(m = 1 to i: C[m]t/T[m]); until(t=t); return(feasible);

Schedulazione Real Time

Schedulazione Real Time

Q(k, i) = Q ik U(k = j + 1 to i : Q(k, i)) =

Algoritmo 3. Reduced Scheduling Point Test.

return(feasible); rlist:={T[i]}; /* rlist = Q(i,i) */

Schedulazione Real Time

24. 25. 26. 27. 28. 29.

1 tR1 2 3 L2 = min L2 ( t ) = tR 2 4 7 L3 = min L3 ( t ) = tR 3 8 L1 = min L1 ( t ) =

Schedulazione Real Time

Schedulazione Real Time

Schedulazione Real Time

Il fattore di utilizzazione per linsieme A pu essere calcolato come segue:

Per quanto riguarda la schedulazione con RM si osserva che:

Schedulazione Real Time

Schedulazione Real Time

Schedulazione Real Time

Schedulazione Real Time