Universit

`
a degli Studi di Padova
Dipartimento di Ingegneria dellInformazione
Corso di Laurea in Ingegneria Informatica
(Laurea Magistrale)
Relazione dei progetti per il corso
di
Sistemi in Tempo Reale
Studente: Francesco Carbone
Matricola: 1034752
Professore: Sergio Congiu
Michele Moro
Data: 2 Marzo 2012
Anno accademico 2011/2012
Capitolo 1
Progetto del primo tipo:
Programmazione in C/C++
1.1 Progetto 10 - simulazione di uno scheduler RM
Realizzare un algoritmo che, dati i parametri temporali di un insieme di task (periodici), ne produca una
schedulazione secondo la politica Rate Monotonic, dopo averne vericata la schedulabilit` a RM. Vericare
almeno le schedulazioni di gura 6-2 del testo. Proporre almeno un insieme di task la cui schedulazione
con RM non `e feasible. Se si usa (parte di) SCHEDSIM, la relazione deve indicare le parti utilizzate e
le modiche apportate.
1.2 Priority-Driven Scheduling per task periodici
Gli algoritmi a priorit`a (priority-driven) comprendono tutti quegli algoritmi che, per denizione, non
lasciano mai il processore inutilizzato volontariamente. In altri termini il processore rimane idle solo
se non ci sono job pronti per essere eseguiti. Come suggerisce il nome, in questo tipo di algoritmi, i task
vengono mandati in esecuzione secondo la loro priorit`a.
Vengono qui elencate le caratteristiche fondamentali di questa tipologia di algoritmi:
Sono algoritmi event-driven, ossia basati su eventi. Lo scheduler inteviene solo in corrispondenza
degli istanti di rilascio o di completamento dei job, per determinare il successivo job da mandare
in esecuzione.
Sono algoritmi greedy, poich`e tentano di fare decisioni localmente ottime. Infatti, lasciare il
processore inutilizzato mentre ci sono job in attesa di essere mandati in esecuzione non sarebbe
una scelta localmente ottima.
Sono algoritmi list-scheduling, poich`e possono essere implementati assegnando un livello di prio-
rit`a a ciascun job e mandando in esecuzione il job in testa alla coda, ordinata per priorit`a.
Sono algoritmi on-line, poich`e non predeterminano la schedulazione dei task, ma la calcolano
durante la loro esecuzione.
Gli algoritmi priority-driven possono essere:
a priorit`a ssa(xed-priority): la priorit`a di tutti i job di un task `e identica; di conseguenza, la
priorit` a `e in eetti assegnata a ciascun task e non cambia.
a priorit`a dinamica(dynamic-priority), in cui la priorit`a dei job di ciascun task pu`o cambiare.
A propria volta, gli algoritmi a priorit`a dinamica possono essere di due sottotipi:
dinamici a livello di task e statici a livello di job (task-level dynamic-priority): la
priorit`a di un job gi`a rilasciato e pronto per lesecuzione non cambia.
dinamici a livello di job (job-level dynamic-priority): la priorit`a di un job pu`o cambiare
dopo il suo rilascio.
2
1.3 Algoritmo Rate Monotonic
Lalgoritmo rate monotonic (RM) assegna la priorit`a di un task in modo proporzionale alla sua frequenza
(rate), denita come linverso del suo periodo.
Esso `e, dunque, un algoritmo priority-driven di tipo xed-priority.
Vengono di seguito considerate le seguenti assunzioni:
Modello di task periodici;
Numero di task pressato;
Singolo processore;
Task indipendenti: nessun vincolo di precedenza e nessuna risorsa condivisa;
Nessun job sporadico o aperiodico;
Presenza di preemption (un job pu`o venire temporaneamente interrotto);
Nessun job decide di sospendersi da solo;
Cambio di contesto istantaneo.
Valgono i seguenti teoremi di ottimalit`a:
Teorema 1: Un sistema T di task semplicemente periodici
1
, interrompibili ed indipendenti le cui sca-
denze relative sono non inferiori ai rispettivi periodi ha una schedulazione RM fattibile su un singolo
processore se e solo se U
T
1.
Teorema 2: Se un insieme di task con p
i
= D
i
pu`o essere schedulato in modo fattibile da un algoritmo
a priorit`a ssa, allora pu`o essere schedulato in modo fattibile dallalgoritmo RM.
1.4 Test di schedulabilit`a
La Time Demand Analysis (TDA) verica se un insieme di task `e eettivamente schedulabile o meno.
Prima di eettuare tale analisi `e opportuno vericare se il fattore di utilizzazione totale del processore
da parte dei task sia al massimo uguale a 1; se cos` non fosse infatti si potrebbe gi`a aermare che il
set di task non ammette una schedulazione valida. Il primo passo dunque consiste nel controllare se
U
TOT
=

i
u
i
=

i
e
i
p
i
1.
Bisogna qui distinguere tre situazioni in cui ci si pu`o trovare:
D
i
= p
i
i N
D
i
p
i
i N
i N : D
i
> p
i
Nel primo caso vale la seguente condizione di Liu-Layland (1973): Un sistema T di n task indipenden-
ti ed interrompibili con scadenze relative uguali ai rispettivi periodi (D
i
= p
i
) pu`o essere eettivamente
schedulato su un processore in accordo allalgoritmo RM se il suo fattore di utilizzazione U
TOT
`e minore
od uguale a U
RM
(n) = n(2
1
n
1). Nel caso in cui tale condizione non valga non si pu`o aermare con
certezza che la schedulazione non esiste per cui `e necessario procedere alla Time Demand Analysis.
Nel secondo caso si procede direttamente alla Time Demand Analysis.
Nel terzo caso, inne, bisogna eettuare un test di schedulabilit`a generale basato sulla Time Demand
Analysis.
1
per ogni coppia di task T
i
e T
k
con p
i
< p
k
, p
k
`e un multiplo intero di p
i
.
3
1.4.1 Time Demand Analysis
La TDA consiste essenzialmente nel controllare che a partire dallistante critico t = 0 nessun job manchi
la propria deadline a causa dei ritardi dovuti allesecuzione di job a priorit`a maggiore. A tal scopo, per
ogni task viene utilizzata la funzione time demand cos` denita:
w
J
i,1
(t) = w
i,1
(t) = e
i
+
i1

k=1
_
t
p
k
_
e
k
dove J
i,1
indica il primo job del task i-esimo ad essere eseguito a partire dallistante critico.
A partire dal task a maggiore priorit`a viene valutata la disequazione w
J
i,1
(t) t. Se `e vericata per
t = D
i
oppure almeno un t = jp
k
: k = 1, ..., i j = 1, ...,
_
D
i
p
k
_
il job J
i,1
`e schedulabile (e quindi anche il
task i-esimo) e la procedura pu`o essere iterata al task successivo; altrimenti il job J
i,1
non `e schedulabile
(e quindi anche il task i-esimo) e la TDA fallisce. Se il test non fallisce per nessun task linsieme di task
`e schedulabile e, quindi, si pu`o procedere con la sua schedulazione.
1.4.2 Time Demand Analysis Generale
Nel caso in cui esistano dei task con D
i
> p
i
lanalisi vista nella sezione 1.4.1 non `e applicabile poich`e
un task potrebbe avere pi` u job pronti in un certo istante di tempo. Per questo viene applicato un test di
schedulabilit`a generale che sfrutta, per`o, i risultati dellanalisi TDA.
Lidea di base `e quella di vericare che, per ogni task T
i
, il tempo di risposta di tutti i suoi job rilasciati
in un suo critical busy interval
2
non superino la loro deadline.
Il busy interval del task i-esimo viene calcolato risolvendo iterativamente la seguente equazione:
t =
i

k=1
_
t
p
k
_
e
k
from t
0
=
i

k=1
e
k
until t
h+1
= t
h
Mentre il tempo di risposta dei job del task i-esimo contenuti nel suo busy interval `e calcolato:
risolvendo iterativamente lequazione: t = je
i
+

i1
k=1
_
t
p
k
_
e
k
per trovare il tempo di completa-
mento t
c
i,j
> (j 1)p
i
del job J
i,j
,
usando t
c
i,j
per calcolare il suo tempo di risposta massimo w
i,j
= t
c
i,j
(j 1)p
i
.
1.5 Presentazione del software sviluppato
Il software sviluppato realizza lalgoritmo RM presentato in sezione 1.3. Lapplicazione in questione
dovr`a quindi, ricevuto in ingresso un insieme di task, assegnare loro la priorit`a, eettuare un test che
controlli se esiste una schedulazione RM valida e, in caso aermativo, procedere con la loro schedulazione.
Il software, realizzato in C++, `e suddiviso in 4 blocchi principali. Il primo `e composto dallinterfaccia
graca, attraverso la quale lutente pu`o interagire con lalgoritmo, ovvero pu`o fornire un insieme di
task periodici e richiederne una schedulazione prodotta attraverso lalgoritmo rate monotonic. Il secondo
blocco `e invece costituito dalla porzione di codice che esegue il test di schedulabilit`a discusso nella
sezione 1.4. Il terzo blocco `e rappresentato dalla classe Scheduler che, responsabile della schedulazione,
implementa al suo interno lalgoritmo RM. Il quarto blocco, inne, `e formato dalle classi che permettono
di visualizzare, attraverso il trace-viewer Kiwi, la schedulazione prodotta dal terzo blocco. Di seguito
ogniuno dei blocchi `e analizzato separatamente.
2
intervallo di tempo (t
0
, t
1
] tale che: (1) allistante t
0
tutti i job di T
i
rilasciati prima di t
0
sono stati completati, (2)
allistante t
0
un job di T
i
`e rilasciato, (3) listante t
1
`e il primo istante in cui tutti i job di T
i
rilasciati a partire da t
0
sono
stati completati.
4
1.5.1 Strutture dati
Il software ricorre a delle strutture dati, appositamente create, per modellare i concetti di task periodico,
di job e di intervallo temporale in cui un job (o parte di esso) `e in esecuzione.
PERIODIC TASK I parametri che caratterizzano i task sono la fase, il periodo, il tempo di esecu-
zione e la deadline relativa. Quindi un task `e espresso nella forma T
i
= (
i
, p
i
, e
i
, D
i
). A questo
scopo viene creata la struttura PERIODIC TASK denita da 5 variabili: taskID, phase, period,
executionTime e relativeDeadline. Il rate del task `e uguale a
1
p
poich`e viene utilizzato lalgoritmo
RM. Gli oggetti vengono allocati per comodit`a nellarray di supporto tasks[#task] (ordinati per
priorit` a decrescente) la cui dimensione `e ovviamente il numero di task inseriti.
JOB Questa struttura rappresenta un singolo job corrispondente ad un certo task.
`
E caratterizzata da 5
parametri: taskID, jobNumber, releaseTime, executionTime e absoluteDeadline. Anchessi vengono
allocati in un array di supporto jobs[#job].
NODE Questa struttura astrae il concetto di singolo slot temporale ed `e composta da 3 attributi:
taskID, startTime e endTime. La sequenza di slot temporali viene cos` rappresentata da una lista
concatenata di nodi; in gura 1.1 viene mostrato con un esempio tale concetto.
T
1
= (4, 2) T
2
= (6, 1.5) T
3
= (12, 1.5)
0 1 2 3 4 5 6 7 8 9 10 11 12
T
1
-0-2 T
1
-4-6 T
1
-8-10 T
2
-2-3.5 T
2
-6-7.5 T
3
-3.5-4 T
3
-7.5-8 T
3
-10-10.5
Figura 1.1: Esempio di rappresentazione della schedulazione mediante lista di slot temporali.
1.5.2 Interfaccia graca
Linterfaccia graca `e stata sviluppata interamente utilizzando le librerie Qt
3
.
Allavvio dellapplicazione appare la nestra principale caratterizzata, nella parte inferiore, da una ca-
sella di testo. Allinterno di questa sar`a reindirizzato lintero output prodotto dal secondo blocco. La
nestra dispone anche di un men` u, attraverso il quale `e possibile compiere diverse azioni. Una di queste
`e linserimento di un nuovo insieme di task per il quale creare una schedulazione RM.
Cliccando su File Nuovo Insieme di Task compare infatti una maschera nella quale `e possibile inserire,
uno dopo laltro, i task periodici del set da schedulare.
Figura 1.2: Maschera di inserimento.
3
http://qt.nokia.com/
5
La maschera (gura 1.2) permette di specicare, per ogni task: fase, periodo, tempo di esecuzione e dead-
line relativa. Linserimento di parametri errati (ad esempio di una deadline relativa minore del tempo
di esecuzione), o la mancanza di alcuni parametri strettamente necessari, `e segnalato da un opportuno
messaggio di errore. Una volta inseriti tutti i task, cliccando sul tasto Fine viene lanciata la schedulazione.
Qualora il software non individui una schedulazione valida per il set di task inserito, un opportuno
messaggio comunica la non schedulabilit`a del set.
`
E infatti importante ricordare che `e necessario esegui-
re un test di schedulabilit`a prima di procedere con lalgoritmo rate monotonic.
Qualora, invece, la schedulazione venga individuata, i parametri del sistema e la schedulazione sono
visualizzati in una nuova maschera (gura 1.3).
Figura 1.3: Maschera della schedulazione.
La parte sinistra della maschera visualizza i seguenti parametri: task da schedulare, iperperiodo e fattore
di utilizzazione. Sulla parte destra della maschera `e invece riportata la schedulazione prodotta dallalgo-
ritmo RM.
Attraverso il men` u, selezionando la voce Esempi, `e inoltre possibile avviare la schedulazione di 9 set di
task preinseriti.
6
1.5.3 Analisi di schedulabilit`a
Come visto in sezione 1.4 prima di procedere alla schedulazione del set di task inseriti dallutente `e
necessario eseguire un test di schedulabilit`a.
A tal ne verr`a, quindi, chiamato il metodo schedulabilityTest() le cui operazioni sono rappresentate nel
diagramma in gura 1.4.
U
TOT
> 1
return
FALSE
D
i
= p
i
iN
SI NO
D
i
p
i
iN
NO
U
RM
(n) U
TOT
SI
analisiTD()
SI
NO
return
TRUE
SI
analisiTD2()
NO
Figura 1.4: Funzionamento del metodo schedulabilityTest().
Il metodo schedulabilityTest() si appoggia alle due funzioni analisiTD() e analisiTD2() che eseguono la
TDA e la TDA generale descritta nella sezione 1.4.
1.5.4 Produzione della schedulazione
RM `e uno scheduler on-line: ci`o fa si che non utilizzi una tabella di schedulazione per assegnare il pro-
cessore ai task ma faccia le proprie scelte in base agli eventi che occorrono (ad esempio il rilascio di un
job prioritario o termine dellesecuzione di un job).
Il metodo che realizzer`a la schedulazione utilizza una variabile double t per indicare il tempo, men-
tre il singolo intervallo temporale in cui un job (o parte di esso) `e in esecuzione viene rappresentato dalla
variabile NODE n.
In RM gli istanti di tempo in cui un job pu`o subire preemption corrispondono ai tempi di rilascio dei job
a priorit`a maggiore.
Come struttura ausiliaria `e stato quindi creato larray di double releaseTime[#task] dove releaseTime[i]
contiene il release time del job corrente del task i-esimo. Quindi releaseTime[i] contiene listante di tempo
in cui i job a priorit`a minore di i potranno subire preemption dal job corrente del task i-esimo. Una volta
che il job corrente ha terminato, releaseTime[i] viene impostato al tempo di rilascio del job successivo.
`
E stata poi implementata un altra struttura di supporto il cui scopo `e quello di mantenere traccia
del tempo di esecuzione rimanente necessario al job corrente.
La struttura citata `e larray di double tRiman[#task]. In questo caso tRiman[i] contiene il tempo di
esecuzione rimanente del job corrente del task i-esimo. Quindi se il job corrente del task i-esimo non `e mai
stato eseguito tRiman[i] `e uguale al tempo di esecuzione totale di tale job, se invece `e gi`a stato eseguito
in parte ma ha subito preemption prima che potesse terminare tRiman[i] `e uguale al valore stesso meno
lintervallo di tempo in cui `e stato in esecuzione prima di subire preemption. Chiaramente quando un job
termina tRiman[i] deve essere reimpostato al valore del tempo di esecuzione del task al quale appartiene.
7
Lalgoritmo che simula il comportamento dello scheduler `e implementato nel metodo setSchedule() ed
ha il seguente pseudocodice:
1 t = 0; // tempo corrente
2 priorita_job_corrente = 0;
3
4 while(t < hp){ // finche il tempo corrente e minore delliperperiodo
5 min = 0;
6 cerca i job con release_time > t e imposta min alla priorita del job con la release_time
minore;
7
8 // se il job_corrente subisce preemption dal task con priorita min
9 if(t + tempo_esecuzione_rimanente_job_corrente > min_release_time){
10 viene creato un nuovo slot_temporale (priorita_job_corrente , t, min_release_time) e
viene aggiunto in coda alla lista;
11 tempo_esecuzione_rimanente_job_corrente = (min_release_time - t);
12 priorita_job_corrente = min;
13 t = min_release_time;
14 }//if
15
16 // se il job corrente puo teminare
17 else{
18 viene creato un nuovo slot_temporale (priorita_job_corrente , t, t +
tempo_esecuzione_rmanente_job_corrente) e viene aggiunto in coda alla lista;
19 tempo_esecuzione_rimanente_job_corrente = durata_job_corrente;
20 release_time_job_corrente += periodo_job_corrente;
21
22 cerca il prossimo job che deve essere assegnato al processore;
23 // a partire dal task con priorita massima cerca il primo job in attesa di
riprendere lesecuzione (in questo caso la priorita non potra essere inferiore
a priorita_job_corrente) o uno che deve partire IMMEDIATAMENTE; se non li trova
salva nella variabile min1 la priorita del job con release_time piu vicina.
24
25 if(trovato){
26 imposta priorita_job_corrente alla priorita del job trovato e aggiorna t;
27 }//if
28
29 else {
30 priorita_job_corrente = min1;
31 t = min1_release_time;
32 }//else
33
34 }//else
35 }//while
Listato 1.1: Pseudocodice del metodo setSchedule().
1.5.5 Rappresentazione graca della schedulazione
Il software ore la possibilit`a di salvare ogni schedulazione in un apposito le interpretabile dal trace
viewer Kiwi. Per ottenere tale le `e suciente selezionare nel menu della nestra principale
File Crea il File Kiwi.
Ogni le Kiwi presenta due sezioni: una prima, nella quale sono specicate le opzioni grache (dra-
wing options), e una seconda, costituita da una sequenza di istruzioni che specica la schedulazione da
visualizzare. Ogniuna delle precedenti istruzioni contiene al suo interno un istante temporale, e nel le
le istruzioni compaiono ordinate rispetto a tale istante.
La creazione del le avviene attraverso le classi KiwiCmd e Kiwi. La prima classe realizza tutte le
istruzioni della seconda sezione del le, mentre la seconda classe crea il le di testo da visualizzare.
In particolare la classe Kiwi crea un le vuoto e vi inserisce le drawing options. Poi traduce la schedu-
lazione nella sequenza di istruzioni per la seconda sezione del le. In questa fase per ogni istruzione `e
creato un oggetto KiwiCmd, il quale viene inserito in una lista. Successivamente la classe Kiwi ordiner`a
la lista secondo listante temporale ad essi associato. Inne attraverser`a la lista con un iteratore e per
ogni oggetto KiwiCmd incontrato trasferir`a la corrispondente istruzione nel le.
8
Di seguito viene riportato lo screenshot della schedulazione per i seguenti set di task:
T
1
= (4, 1) T
2
= (5, 2) T
3
= (20, 5)
Figura 1.5: Schedulazione del set di task dellEsempio 1.
T
1
= (2, 0.9, 1) T
2
= (5, 3, 4)
Figura 1.6: Schedulazione per un set di task non feasible.
1.6 Conclusioni
Il software sviluppato `e stato testato con diversi esempi, la maggior parte dei quali tratti dal libro, ed in
tutti questi casi ha esibito il comportamento previsto.
Gli esempi pi` u signicativi ed istruttivi che hanno comportato un attenta analisi nellimplementazione
dellalgoritmo sono qui riportati:
1. Schedulazione di job con valori decimali,
2. Schedulazione con preemption,
3. Schedulazione con job aventi lo stesso tempo di rilascio,
4. Schedulazione con job aventi la stessa deadline,
5. Schedulazione non feasible,
6. Schedulazione con job aventi deadline pari al periodo,
7. Schedulazione con job aventi deadline non superiore al periodo,
8. Schedulazione con job aventi deadline superiore al periodo,
9. Schedulazione con job aventi fase non nulla.
9
Capitolo 2
Progetto del terzo tipo:
Soluzione di esercizi
2.1 Esercizio 4.5 - preemption, multiprocessors
A system contains nine nonpreemptable jobs mamed J
i
, for i = 1, 2, ..., 9. Their execution times are 3,
2, 2, 2, 4, 4, 4, 4, and 9, respectively, their release times are equal to 0, and their deadlines are 12. J
1
is the immediate predecessor of J
9
, and J
4
is the immediate predecessor of J
5
, J
6
, J
7
, J
8
. There is no
other precedence constraints. For all the jobs, J
i
has a highter priority than J
k
if i < k.
1. Draw the precedence graph of the jobs.
2. Can the jobs meet their deadlines if they are scheduled on three processors? Explain your answer.
3. Can the jobs meet their deadlines if we make them preemptable and schedule them preemptively.
Explain your answer.
4. Can the jobs meet their deadlines if they are scheduled nonpreemptively on four processors? Explain
your answer.
5. Suppose that due to an improvement of the three processors, the excecution time of every job is
reduced by 1. Can the jobs meet their deadlines? Explain your answer.
2.1.1 Soluzione punto 1.
Il sistema `e formato da nove job. Per ciascuno di essi il problema fornisce il tempo di rilascio pari a 0
e la deadline pari a 12. I vincoli di precedenza specicati dalla consegna vengono mostrati nel seguente
grafo di precedenza
1
. Su ogni nodo vengono specicati il nome del job (J
i
) ed il relativo tempo di
esecuzione (e
i
). Dato che listante di rilascio e la deadline sono uguali per ogni job si `e scelto di non
riportare tali dati nel graco, onde evitare ridondanza nelle informazioni visualizzate.
Si pu`o osservare come i primi quattro job (J
1
, J
2
, J
3
, J
4
) siano indipendenti tra loro, i job J
5
, J
6
, J
7
, J
8
dipendano solo dal job J
4
e, inne, il job J
9
dipenda solo dal job J
1
.
1
Un grafo di precedenza `e un grafo diretto aciclico nel quale i nodi rappresentano attivit`a sequenziali e gli archi indicano
lordine in cui devono essere considerate le attivit`a. Ad esempio un arco dal nodo i al nodo k indica che il job J
i
deve essere
completato prima che il job J
k
possa partire.
10
J
1
(3)
J
2
(2)
J
3
(2)
J
4
(2)
J
9
(9)
J
5
(4)
J
6
(4)
J
7
(4)
J
8
(4)
Figura 2.1: Grafo di precedenza.
2.1.2 Soluzione punto 2.
Il sistema considerato `e formato da nove job nonpreemptable schedulati su tre processori
(P
1
, P
2
, P
3
). Una possibile schedulazione valida `e mostrata di seguito.
4 8 12
J1
J2
J3
J4 J5
J6
J9
J7
J8
P1
P2
P3
Width 13 s Grid 1 s
Figura 2.2: Schedulazione con tre processori (Senza preemption).
Viene ora descritta la schedulazione di gura 2.2, prendendo in considerazione gli istanti signicativi
(rilascio o terminazione di un job):
t = 0 : vengono rilasciati tutti e nove i job; lo scheduler assegna i job J
1
, J
2
, J
3
ai rispettivi tre
processori P
1
, P
2
, P
3
. Tali job sono i pi` u prioritari e privi di vincoli di precedenza;
t = 2 : i job J
2
e J
3
terminano la loro esecuzione; lo scheduler assegna il job J
4
al processore P
2
.
Nessun altro job dei rimanenti pu`o essere eseguito in quanto tutti dipendono o dal job J
4
o dal job
J
1
, entrambi in esecuzione; per questo motivo il processore P
3
non viene utilizzato;
t = 3 : il job J
1
termina la propria esecuzione; solo il job J
9
pu`o essere avviato e viene assegnato
al processore P
1
. I restanti job devono attendere il completamento del job J
4
, a causa dei vincoli
di precedenza;
t = 4 : grazie al completamento del job J
4
, iniziano la propria esecuzione i job J
5
e J
6
, poich`e i
pi` u prioritari;
t = 8 : in seguito al termine dei job J
5
e J
6
vengono ora schedulati i job J
7
e J
8
;
t = 12 : tutti i job terminano la loro esecuzione rispettando la propria deadline.
11
OSSERVAZIONE: Gli algoritmi EDF
2
e LST
3
non sono stati utilizzati in quanto, secondo le ipotesi
previste dal sistema, lassenza di soluzione non avrebbe garantito lassoluta inesistenza di una possibile
schedulazione.
2.1.3 Soluzione punto 3.
Viene qui modicato il sistema descritto al punto 2 mediante lintroduzione della possibilit`a di preemption
dei job. La gura 2.3 mostra che non tutti i job rispettano la propria deadline.
4 8 12 16
J1
J2
J3
J4
J9 J5
J6
J7
J8
J9 Deadline-missed
P1
P2
P3
Width 17 s Grid 1 s
Figura 2.3: Schedulazione con tre processori (Con preemption).
Fino allistante di tempo t = 3 la schedulazione resta invariata rispetto a quella ottenuta al punto
precedente. Vengono ora commentati gli istanti di tempo signicativi rimanenti:
t = 4 : il completamento del job J
4
rende possibile lesecuzione dei job J
5
, J
6
, J
7
, J
8
, pi` u prioritari
rispetto al job J
9
che subisce, dunque, preemption;
t = 8 : il job J
9
pu`o riprendere la sua esecuzione solo ora terminando, per`o, allistante 16,
mancando il rispetto della sua deadline.
Si noti come laver introdotto la possibilit`a di migrazione
4
da parte di un job non ha inuenzato il
risultato nale dellanalisi.
2.1.4 Soluzione punto 4.
Il sistema `e ora dotato di quattro processori e si vogliono eseguire gli stessi nove job nonpreemptable. La
gura 2.4 mostra che non viene trovata una schedulazione fattibile, poich`e il job J
9
non rispetta
la propria deadline.
Come osservabile dalla gura:
t = 0 : vengono schedulati i primi quattro job (J
1
, J
2
, J
3
, J
4
) prioritari e indipendenti tra loro;
t = 2 : essendo terminato il job J
4
possono iniziare lesecuzione i job J
5
, J
6
e J
7
;
t = 3 : viene schedulato il job J
8
, prioritario rispetto al job J
9
;
t = 6 : soltanto ora si pu`o eseguire il job J
9
; essendo il suo tempo di esecuzione pari a 9, tale job
termina allistante 16, ben oltre la sua deadline.
Lo stesso risultato sarebbe stato raggiunto introducendo la possibilit`a di preemption dei job.
2
Earlest Deadline First.
3
Least Slack Time.
4
Si parla di migrazione quando ad un job che ha subito preemption viene concessa lassegnazione di un processore diverso
da quello in cui era precedentemente in esecuzione.
12
4 8 12 16
J1
J2
J3
J4
J5
J6
J7
J8
J9 Deadline-missed
P1
P2
P3
P4
Width 16 s Grid 1 s
Figura 2.4: Schedulazione con quattro processori (Senza preemption).
2.1.5 Soluzione punto 5.
Il sistema, considerato in questo punto, ha ridotto il tempo di esecuzione di ogni job di un unit`a di tempo.
Tutte le restanti speciche iniziali rimangono inalterate. Si ottiene, nuovamente, una schedulazione
non valida, poich`e non viene rispettata la deadline da parte del job J
9
.
4 8 12
J2
J3
J1
J4
J5
J6
J7
J8
J9 Deadline-missed
P1
P2
P3
Width 14 s Grid 1 s
Figura 2.5: Schedulazione con tre processori e tempi di esecuzione ridotti (Senza preemption).
Dalla gura 2.5 si pu`o osservare come, diversamente dal punto 2, la schedulazione ottenuta non `e valida.
Questo mostra come un miglioramento del sistema non porta necessariamente ad un progresso nella
schedulazione; addirittura, come in questo caso, si `e ottenuto un peggioramento. Lo stesso risultato
sarebbe stato raggiunto introducendo la possibilit`a di preemption dei job.
13
2.2 Esercizio 5.1 - cyclic scheduling
Each of the following systems of periodic tasks is scheduled and executed according to a cyclic sche-
dule. For each system, choose an appropiate frame size. preemptions are allowed, but the number of
preemptions should be kept small.
1. (6, 1), (10, 2), and (18, 2).
2. (10, 1, 12), (15, 1.5, 11), (21, 12, 15), and (32, 4, 24).
2.2.1 Soluzione punto 1.
Vengono deniti: T
1
= (6, 1), T
2
= (10, 2), T
3
= (18, 2). I task periodici considerati sono rappresentati
nella forma T
i
= (p
i
, e
i
), dove p
i
`e il periodo e e
i
il tempo di esecuzione di ciascun job appartenente al
task i-esimo. In questo caso la fase
5

i
e la deadline relativa D
i
sono poste rispettivamente a 0 ed a p
i
.
Innanzitutto `e necessario calcolare il tempo di utilizzazione U:
U =

i
u
i
=

i
e
i
p
i
(2.1)
dove u
i
=
e
i
p
i
`e il tempo di utilizzazione del task T
i
.
Questo parametro indica la percentuale di tempo durante il quale il processore risulta impegnato nelle-
secuzione dellinsieme di job appartenenti ai task T
1
, T
2
e T
3
. Ne consegue che una condizione necessaria
anch`e il sistema di task sia schedulabile `e quella di avere un fattore di utilizzazione minore o uguale a
1 (U 1). infatti, se il fattore di utilizzazione `e maggiore di 1 (U > 1), il processore sarebbe occupato
per un valore superiore al 100%, impedendo cos` la completa esecuzione dei task; diversamente, con il
fattore di utilizzazione 0 U 1 si potrebbe ottenere una schedulazione valida.
Con questo task set si hanno i seguenti tempi di utilizzazione:
1. u
1
=
e
1
p
1
=
1
6
per il task T
1
= (6, 1)
2. u
2
=
e
2
p
2
=
2
10
=
1
5
per il task T
2
= (10, 2)
3. u
3
=
e
3
p
3
=
2
18
=
1
9
per il task T
3
= (18, 2)
Il fattore di utilizzazione dei tre task `e U =
1
6
+
1
5
+
1
9
=
43
90
= 0.47

= 47.8%, abbondantemente inferiore
al 100%; quindi la condizione `e vericata e si pu`o proseguire con lanalisi dellesercizio.
Liperperiodo, minimo comune multiplo tra i periodi dei task del set considerato, `e pari a H = mcm(p
1
, p
2
, p
3
) =
mcm(6, 10, 18) = 90.
Viene ora determinato il frame size f che deve soddisfare i seguenti tre vincoli (n = 3 task):
Ogni job di un determinato task deve iniziare e completare la propria esecuzione allinterno di un
singolo frame; allinterno di tale frame non avviene preemption:
f max
1in
(e
i
) (2.2a)
Per lesempio in considerazione si ha f max(1, 2, 2) = 2 f 2.
Per mantenere la schedulazione ciclica di ridotte dimensioni, f deve dividere esattamente la lun-
ghezza delliperperiodo; quindi f deve dividere almeno un p
i
, matematicamente
6
:
i [1, n] :
_
p
i
f
_

p
i
f
= 0 (2.2b)
5
La fase
i
di un task T
i
rappresenta il tempo di rilascio r
i,1
del primo job J
i,1
che lo compone.
6
Funzione oor denita come x = n : x R n Z n x n + 1.
14
Per il set di task dellesercizio si ha:
Per il task T
1
:
_
6
f
_

6
f
= 0 , f {1, 2, 3, 6} ;
Per il task T
2
:
_
10
f
_

10
f
= 0 , f {1, 2, 5, 10} ;
Per il task T
3
:
_
18
f
_

18
f
= 0 , f {1, 2, 3, 6, 9, 18} ;
Unendo i tre insiemi di divisori otteniamo il soddisfacimento del vincolo appena discusso per
f {1, 2, 3, 5, 6, 9, 10, 18}. Anch`e tale insieme soddis anche il vincolo 2.2a bisogna escludere
lelemento f = 1, ottenendo cos` f {2, 3, 5, 6, 9, 10, 18}.
Tra listante di rilascio e la deadline di ogni job deve essere contenuto almeno un intero frame:
2f MCD(p
i
, f) D
i
, i [1, n] (2.2c)
I valori dellinsieme soddisfacente i vincoli 2.2a e 2.2b sono i possibili candidati da vericare anch`e
anche questultimo vincolo sia soddisfatto.
Prima di proseguire `e utile osservare che f non deve superare la deadline relativa minore ossia
f min
1in
(D
i
) = min(6, 10, 18) = 6 f 6.
In questo modo possiamo ridurre linsieme dei candidati precedentemente individuati a {2, 3, 5, 6};
la seguente tabella riassume il controllo del vincolo 2.2c sugli elementi di tale insieme:
f T
1
= (6, 1) T
2
= (10, 2) T
3
= (18, 2) TEST
2 4 2 6 4 2 10 4 2 18

3 6 3 6 6 1 10 6 3 18

5 10 1 6 X
6 12 6 6 12 2 10 12 6 18

Tabella 2.1: Verica del soddisfacimento del vincolo 2.2c.
In conclusione, i valori di f che soddisfano tutti e tre i vincoli appartengono allinsieme {2, 3, 6}. La
scelta pi` u conveniente `e quella di prendere il maggiore dei tre, quindi f = 6; utilizzando tale valore una
possibile schedulazione
7
`e mostrata nella seguente gura:
8.00 16.00 24.00 32.00 40.00 48.00
FRAME 1
J1,1
J2,1
J3,1
FRAME 2
J1,2
FRAME 3
J1,3
J2,2
FRAME 4
J1,4
J3,2
FRAME 5
J1,5
J2,3
FRAME 6
J1,6
J2,4
FRAME 7
J1,7
J3,3
FRAME 8
J1,8
J2,5
T1
T2
T3
Width 48.00 s Grid 1.00 s
7
Poich`e il primo vincolo assicura lassenza di preemption `e possibile utilizzare qualsiasi algoritmo per trovare la
schedulazione.
15
56.00 64.00 72.00 80.00 88.00 96.00
FRAME 9
J1,9
FRAME 10
J1,10
J2,6
J3,4
FRAME 11
J1,11
J2,7
FRAME 12
J1,12
FRAME 13
J1,13
J2,8
J3,5
FRAME 14
J1,14
FRAME 15
J1,15
J2,9
T1
T2
T3
Width 48.00 s Grid 1.00 s
Figura 2.6: Schedulazione di un iperperiodo del primo set di task (f = 6).
Si vuole far notare la rappresentazione dei job in gura 2.6: ogni job `e indicato come J
t,j
dove lindice t
indica il numero del task al quale il job j-esimo appartiene.
2.2.2 Soluzione punto 2.
Il nuovo set di task `e cos` denito: T
1
= (10, 1, 12), T
2
= (15, 1.5, 11), T
3
= (21, 12, 15), T
4
= (32, 4, 24).
Diversamente dal punto precedente i task periodici sono specicati nella forma T
i
= (p
i
, e
i
, D
i
), dove
i primi due valori hanno il medesimo signicato di prima, mentre D
i
indica esplicitamente la deadline
relativa. Anche in questo caso tutti i task hanno fase nulla.
Bisogna prima di tutto assicurarsi che i task siano eettivamente schedulabili, controllando che il fattore
di utilizzazione non sia maggiore di 1: U =
1
10
+
1.5
15
+
12
21
+
4
32
=
251
280
= 0.8964 1; poich`e per tale
fattore di utilizzazione potrebbe esistere una schedulazione fattibile, si procede con lanalisi calcolando
liperperiodo: H = mcm(10, 15, 21, 32) = 3360.
Vengono ora analizzati i vincoli 2.2a, 2.2b e 2.2c per il task set in considerazione:
1. f max(1, 1.5, 12, 4) = 12 f 12.
2. Per il task T
1
:
_
10
f
_

10
f
= 0 , f {1, 2, 5, 10} ;
Per il task T
2
:
_
15
f
_

15
f
= 0 , f {1, 3, 5, 15} ;
Per il task T
3
:
_
21
f
_

21
f
= 0 , f {1, 3, 7, 21} ;
Per il task T
4
:
_
32
f
_

32
f
= 0 , f {1, 2, 4, 8, 16, 32} ;
Le quattro veriche restituiscono linsieme {1, 2, 3, 4, 5, 7, 8, 10, 15, 16, 21, 32}.
3. Considerando, come prima, che deve essere f min
1in
(D
i
) = min(12, 11, 15, 24) = 11 e le due
condizioni precedenti si ottiene che f .
Il problema `e dovuto alla condizione 2.2a; `e possibile spezzare uno o pi` u job, riducendone cos` i tempi di
esecuzione (ovviamente la possibilit`a di farlo realmente dipende dalla natura dei job troppo lunghi), in
modo da abbassare il lower bound imposto dal primo vincolo. La scelta delle dimensioni dei frammenti in
cui suddividere i job segue lesigenza di riempire il pi` u possibile i vari frame. Rilassando il primo vincolo
dallanalisi precedente si ottiene linsieme {1, 2, 3, 4, 5, 7, 8, 10} da sottoporre alla condizione 2.2c.
16
La seguente tabella riassume tale controllo:
f T
1
= (10, 1, 12) T
2
= (15, 1.5, 11) T
3
= (21, 12, 15) T
4
= (32, 4, 24) TEST
1 2 1 12 2 1 11 2 1 15 2 1 24

2 4 2 12 4 1 11 4 1 15 4 2 24

3 6 1 12 6 3 11 6 3 15 6 1 24

4 8 2 12 8 1 11 8 1 15 8 4 24

5 10 5 12 10 5 11 10 1 15 10 1 24

7 14 1 12 X
8 16 2 12 X
10 20 10 12 20 5 11 X
Tabella 2.2: Verica del soddisfacimento del vincolo 2.2c.
Come osservabile dalla tabella 2.2, anch`e siano soddisfatti il secondo ed il terzo vincolo, f deve appar-
tenere allinsieme {1, 2, 3, 4, 5}. Utilizzando iterativamente lINF algorithm
8
, sebbene non si abbia alcun
controllo sulla preemption, `e possibile determinare il valore ottimale di f. La dimensione del frame per
la quale lINF algorithm (in particolare il Ford-Fulkerson
9
per determinare la schedulazione) restituisce
una schedulazione fattibile, `e pari a 3.
8.00 16.00 24.00 32.00 40.00
FR. 1
J1,1
J2,1
J4,1,1
FR. 2
J3,1,1
FR. 3
J3,1,2
FR. 4
J3,1,3
FR. 5
J3,1,4
FR. 6
J4,1,2
FR. 7
J1,2
J4,1,3
FR. 8
J1,3
J2,2
J4,1,4
FR. 9
J3,2,1
FR. 10
J3,2,2
FR. 11
J3,2,3
FR. 12
J3,2,4
FR. 13
J1,4
J4,2,1
J2,3
FR. 14
J4,2,2J4,2,3
FR. 15
J3,3,1
T1
T2
T3
T4
Width 45.00 s Grid 1.00 s
53.00 61.00 69.00 77.00 85.00
FR. 16
J2,4
J4,2,4
J1,5
FR. 17
J3,3,2
FR. 18
J3,3,3
FR. 19
J3,3,4
FR. 20
J1,6
FR. 21
J2,5
FR. 22
J3,4,1
FR. 23
J3,4,2
FR. 24
J1,7
J4,3,1
J1,8
FR. 25
J3,4,3
FR. 26
J3,4,4
FR. 27
J2,6
J4,3,2
FR. 28
J4,3,3J4,3,4
FR. 29
J3,5,1
FR. 30
J3,5,2
T1
T2
T3
T4
Width 45.00 s Grid 1.00 s
Figura 2.7: Schedulazione dei primi 30 frame del secondo set di task (f = 3).
8
http://en.wikipedia.org/wiki/Flow_network.
9
http://en.wikipedia.org/wiki/FordFulkerson_algorithm.
17
I primi 30 frame di tale schedulazione vengono illustrati in gura 2.7. La notazione `e del tipo J
t,j,s
dove t e j hanno lo stesso signicato che avevano in gura 2.6 e s indica il numero dello slice
(frammento) di un determinato job; se questultimo fosse assente implica che il job in considerazione
non `e stato frammentato.
In seguito allanalisi il set di task iniziale diventa:
T
1
= (10, 1, 12)
T
2
= (15, 1.5, 11)
T
3,1
= (21, 3, 15) T
3,2
= (21, 3, 15) T
3,3
= (21, 3, 15) T
3,4
= (21, 3, 15)
T
4,1
= (32, 0.5, 24) T
4,2
= (32, 1, 24) T
4,3
= (32, 2, 24) T
4,4
= (32, 0.5, 24)
Si noti come i task T
3
e T
4
siano stati suddivisi in 4 slice ciascuno. Perci`o ogni job di tali task pu`o subire
preemption massimo 3 volte per una lunghezza pari al loro periodo; il numero massimo di preemption in
un iperperiodo `e pari a 2 3
_
H
p
3
+
H
p
4
_
= 1590. Questultima `e la stima nel caso peggiore.
OSSERVAZIONE: Linsieme di job frammentati non `e equivalente ai job di 10 task periodici del
tipo (10, 1, 12), (15, 1.5, 11), (21, 3, 15), (21, 3, 15), (21, 3, 15), (21, 3, 15),
(32, 0.5, 24), (32, 1, 24), (32, 2, 24), (32, 0.5, 24) in quanto esistono dei vincoli di precedenza tra i
frammenti associati allo stesso task.
18