Universit

`
a degli Studi di Padova
Dipartimento di Ingegneria dell’Informazione
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 verificata la schedulabilit` a RM. Verificare
almeno le schedulazioni di figura 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 modifiche apportate.
1.2 Priority-Driven Scheduling per task periodici
Gli algoritmi a priorit`a (priority-driven) comprendono tutti quegli algoritmi che, per definizione, 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 fissa(fixed-priority): la priorit`a di tutti i job di un task `e identica; di conseguenza, la
priorit` a `e in effetti 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 l’esecuzione 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
L’algoritmo rate monotonic (RM) assegna la priorit`a di un task in modo proporzionale alla sua frequenza
(rate), definita come l’inverso del suo periodo.
Esso `e, dunque, un algoritmo priority-driven di tipo fixed-priority.
Vengono di seguito considerate le seguenti assunzioni:
• Modello di task periodici;
• Numero di task prefissato;
• 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 fissa, allora pu`o essere schedulato in modo fattibile dall’algoritmo RM.
1.4 Test di schedulabilit`a
La Time Demand Analysis (TDA) verifica se un insieme di task `e effettivamente schedulabile o meno.
Prima di effettuare tale analisi `e opportuno verificare 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 affermare 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 effettivamente
schedulato su un processore in accordo all’algoritmo 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 affermare 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, infine, bisogna effettuare 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 dall’istante critico t = 0 nessun job manchi
la propria deadline a causa dei ritardi dovuti all’esecuzione di job a priorit`a maggiore. A tal scopo, per
ogni task viene utilizzata la funzione time demand cos`ı definita:
w
J
i,1
(t) = w
i,1
(t) = e
i
+
i−1

k=1
_
t
p
k
_
e
k
dove J
i,1
indica il primo job del task i-esimo ad essere eseguito a partire dall’istante critico.
A partire dal task a maggiore priorit`a viene valutata la disequazione w
J
i,1
(t) ≤ t. Se `e verificata 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 l’insieme 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
l’analisi 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 dell’analisi TDA.
L’idea di base `e quella di verificare 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 l’equazione: t = je
i
+

i−1
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 l’algoritmo RM presentato in sezione 1.3. L’applicazione in questione
dovr`a quindi, ricevuto in ingresso un insieme di task, assegnare loro la priorit`a, effettuare un test che
controlli se esiste una schedulazione RM valida e, in caso affermativo, procedere con la loro schedulazione.
Il software, realizzato in C++, `e suddiviso in 4 blocchi principali. Il primo `e composto dall’interfaccia
grafica, attraverso la quale l’utente pu`o “interagire con l’algoritmo”, ovvero pu`o fornire un insieme di
task periodici e richiederne una schedulazione prodotta attraverso l’algoritmo 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 l’algoritmo RM. Il quarto blocco, infine, `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) all’istante t
0
tutti i job di T
i
rilasciati prima di t
0
sono stati completati, (2)
all’istante t
0
un job di T
i
`e rilasciato, (3) l’istante 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 definita da 5 variabili: taskID, phase, period,
executionTime e relativeDeadline. Il rate del task `e uguale a
1
p
poich`e viene utilizzato l’algoritmo
RM. Gli oggetti vengono allocati per comodit`a nell’array 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. Anch’essi 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 figura 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 grafica
L’interfaccia grafica `e stata sviluppata interamente utilizzando le librerie Qt
3
.
All’avvio dell’applicazione appare la finestra principale caratterizzata, nella parte inferiore, da una ca-
sella di testo. All’interno di questa sar`a reindirizzato l’intero output prodotto dal secondo blocco. La
finestra dispone anche di un men` u, attraverso il quale `e possibile compiere diverse azioni. Una di queste
`e l’inserimento 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 l’altro, i task periodici del set da schedulare.
Figura 1.2: Maschera di inserimento.
3
http://qt.nokia.com/
5
La maschera (figura 1.2) permette di specificare, per ogni task: fase, periodo, tempo di esecuzione e dead-
line relativa. L’inserimento 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 l’algoritmo rate monotonic.
Qualora, invece, la schedulazione venga individuata, i parametri del sistema e la schedulazione sono
visualizzati in una nuova maschera (figura 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 dall’algo-
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 dall’utente `e
necessario eseguire un test di schedulabilit`a.
A tal fine verr`a, quindi, chiamato il metodo schedulabilityTest() le cui operazioni sono rappresentate nel
diagramma in figura 1.4.
U
TOT
> 1
return
FALSE
D
i
= p
i
∀i∈N
SI NO
D
i ≤
p
i
∀i∈N
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 dell’esecuzione 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 l’array di double releaseTime[#task] dove releaseTime[i]
contiene il release time del job corrente del task i-esimo. Quindi releaseTime[i] contiene l’istante 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 l’array 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
l’intervallo 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
L’algoritmo 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 dell’iperperiodo
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 l’esecuzione (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 grafica della schedulazione
Il software offre la possibilit`a di salvare ogni schedulazione in un apposito file interpretabile dal trace
viewer Kiwi. Per ottenere tale file `e sufficiente selezionare nel menu della finestra principale
File → Crea il File Kiwi.
Ogni file Kiwi presenta due sezioni: una prima, nella quale sono specificate le opzioni grafiche (dra-
wing options), e una seconda, costituita da una sequenza di istruzioni che specifica la schedulazione da
visualizzare. Ogniuna delle precedenti istruzioni contiene al suo interno un istante temporale, e nel file
le istruzioni compaiono ordinate rispetto a tale istante.
La creazione del file avviene attraverso le classi KiwiCmd e Kiwi. La prima classe realizza tutte le
istruzioni della seconda sezione del file, mentre la seconda classe crea il file di testo da visualizzare.
In particolare la classe Kiwi crea un file vuoto e vi inserisce le drawing options. Poi traduce la schedu-
lazione nella sequenza di istruzioni per la seconda sezione del file. 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 l’istante temporale ad essi associato. Infine attraverser`a la lista con un iteratore e per
ogni oggetto KiwiCmd incontrato trasferir`a la corrispondente istruzione nel file.
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 dell’Esempio 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 significativi ed istruttivi che hanno comportato un attenta analisi nell’implementazione
dell’algoritmo 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 specificati dalla consegna vengono mostrati nel seguente
grafo di precedenza
1
. Su ogni nodo vengono specificati il nome del job (J
i
) ed il relativo tempo di
esecuzione (e
i
). Dato che l’istante di rilascio e la deadline sono uguali per ogni job si `e scelto di non
riportare tali dati nel grafico, 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, infine, 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
l’ordine 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 figura 2.2, prendendo in considerazione gli istanti significativi
(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, l’assenza di soluzione non avrebbe garantito l’assoluta inesistenza di una possibile
schedulazione.
2.1.3 Soluzione punto 3.
Viene qui modificato il sistema descritto al punto 2 mediante l’introduzione della possibilit`a di preemption
dei job. La figura 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 all’istante di tempo t = 3 la schedulazione resta invariata rispetto a quella ottenuta al punto
precedente. Vengono ora commentati gli istanti di tempo significativi rimanenti:
• t = 4 : il completamento del job J
4
rende possibile l’esecuzione 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, all’istante 16,
mancando il rispetto della sua deadline.
Si noti come l’aver introdotto la possibilit`a di migrazione
4
da parte di un job non ha influenzato il
risultato finale dell’analisi.
2.1.4 Soluzione punto 4.
Il sistema `e ora dotato di quattro processori e si vogliono eseguire gli stessi nove job nonpreemptable. La
figura 2.4 mostra che non viene trovata una schedulazione fattibile, poich`e il job J
9
non rispetta
la propria deadline.
Come osservabile dalla figura:
• 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 l’esecuzione 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 all’istante 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 l’assegnazione 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 specifiche 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 figura 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 definiti: 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 nell’e-
secuzione dell’insieme di job appartenenti ai task T
1
, T
2
e T
3
. Ne consegue che una condizione necessaria
affinch`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 verificata e si pu`o proseguire con l’analisi dell’esercizio.
L’iperperiodo, 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 all’interno di un
singolo frame; all’interno di tale frame non avviene preemption:
f ≥ max
1≤i≤n
(e
i
) (2.2a)
Per l’esempio 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 dell’iperperiodo; 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 floor definita come x = n : x ∈ R ∧ n ∈ Z ∧ n ≤ x ≤ n + 1.
14
Per il set di task dell’esercizio 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}. Affinch`e tale insieme soddisfi anche il vincolo 2.2a bisogna escludere
l’elemento f = 1, ottenendo cos`ı f ∈ {2, 3, 5, 6, 9, 10, 18}.
• Tra l’istante 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 dell’insieme soddisfacente i vincoli 2.2a e 2.2b sono i possibili candidati da verificare affinch`e
anche quest’ultimo vincolo sia soddisfatto.
Prima di proseguire `e utile osservare che f non deve superare la deadline relativa minore ossia
f ≤ min
1≤i≤n
(D
i
) = min(6, 10, 18) = 6 → f ≤ 6.
In questo modo possiamo ridurre l’insieme 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: Verifica del soddisfacimento del vincolo 2.2c.
In conclusione, i valori di f che soddisfano tutti e tre i vincoli appartengono all’insieme {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 figura:
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 l’assenza 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 figura 2.6: ogni job `e indicato come J
t,j
dove l’indice 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`ı definito: 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 specificati nella forma T
i
= (p
i
, e
i
, D
i
), dove
i primi due valori hanno il medesimo significato 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 effettivamente 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 l’analisi calcolando
l’iperperiodo: 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 verifiche restituiscono l’insieme {1, 2, 3, 4, 5, 7, 8, 10, 15, 16, 21, 32}.
3. Considerando, come prima, che deve essere f ≤ min
1≤i≤n
(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 l’esigenza di riempire il pi` u possibile i vari frame. Rilassando il primo vincolo
dall’analisi precedente si ottiene l’insieme {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: Verifica del soddisfacimento del vincolo 2.2c.
Come osservabile dalla tabella 2.2, affinch`e siano soddisfatti il secondo ed il terzo vincolo, f deve appar-
tenere all’insieme {1, 2, 3, 4, 5}. Utilizzando iterativamente l’INF 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 l’INF 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 figura 2.7. La notazione `e del tipo J
t,j,s
dove t e j hanno lo stesso significato che avevano in figura 2.6 e s indica il numero dello slice
(frammento) di un determinato job; se quest’ultimo fosse assente implica che il job in considerazione
non `e stato frammentato.
In seguito all’analisi 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. Quest’ultima `e la stima nel caso peggiore.
OSSERVAZIONE: L’insieme 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

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.