Teil 3: Scheduling

Transcription

Teil 3: Scheduling

Vorlesung Echtzeitsysteme
Thema 3: Scheduling
Robert Baumgartl
15. April 2015
1 / 103
Zielstellung
Finden einer Abbildung Ausführungseinheit→Prozessor, so
dass
I
alle notwendigen Ressourcen (Rechenzeit, Speicherplatz,
Geräte, . . . ) den Ausführungseinheiten zur Verfügung
stehen und
I
alle Zeitforderungen garantiert eingehalten werden.
Scheduling (Planen) = Entscheidung, welcher Prozess zu
welchem Zeitpunkt für welche Zeitspanne abgearbeitet wird.
Häufig werden in Echtzeitsystemen nicht nur der Prozessor
sondern auch andere Ressourcen geplant und zugeteilt (z.B.
Festplatten, Busse).
2 / 103
„Klassische“ Ziele der Prozessorzuteilung
1. Minimierung der (mittleren) Reaktionszeit: z.B. bei
interaktiven Systemen
2. Maximierung des Durchsatzes: z.B. bei Servern
3. Maximierung der Prozessorauslastung: z.B. bei
Supercomputern
4. Fairness: Gleichbehandlung aller Prozesse, Garantie des
Fortschritts
In Echtzeitsystemen:
5. Einhaltung der vorgegebenen Zeitschranken
Sekundärziele: 1.-4.
3 / 103
Klassifikation von Schedulingverfahren
Nach dem Zeitpunkt („Wann wird geplant?“)
On-Line (zur Laufzeit des Systems, implizite Planung)
I
bei Zustandsübergängen,
I
bei externen Ereignissen,
I
nach Verstreichen einer festen Zeitspanne,
I
bei Aufruf eines Systemrufs
Off-Line (vor Laufzeit des Systems, explizite Planung)
I
alle Prozessparameter vor Systemstart bekannt
I
geschlossene Prozessmengen
I
Umschaltung sehr schnell, da keine Planung zur Laufzeit
nötig
4 / 103
Nach der Unterbrechbarkeit („Kann einem Prozeß der Prozessor entzogen werden?“)
Kooperatives Scheduling
I
Prozess gibt freiwillig den Prozessor ab
I
Behandlung kritischen Abschnitte einfach
I
geringerer Aufwand
Präemptives Scheduling
I
Prozess kann von außen (durch das BS) unterbrochen
werden
I
Prioritätssteuerung möglich/einfacher
I
keine Beeinflussung der Prozesse untereinander
5 / 103
Nach dem Regime
Zeitgesteuertes Scheduling
I
on-line und off-line möglich
I
keine Interrupts, Interaktion ausschließlich durch Polling
Ereignisgesteuertes Scheduling
I
nur on-line möglich
I
Aktivierung von Prozessen in Folge externer Ereignisse
I
Interrupts erlaubt
6 / 103
Weitere Kriterien
I
Nutzung von Prioritäten (keine, fest, variabel)
I
nach Anzahl der Prozessoren, Möglichkeit der Migration
nach Taskmodell:
I
I
I
I
I
ausschliesslich periodische Tasks
Tasks in notwendige und wahlfreie Phase gesplittet
(Flexible Computations)
zusätzlich aperiodische Tasks erlaubt
Berücksichtigung von Prozess-Präzedenzen
(Abhängigkeiten)
7 / 103
Übersicht der zu behandelnden Verfahren
Echtzeit−Scheduling
off−line
Network Flows
on−line
keine Prio.
statische Prio.
dynamische Prio.
Round Robin
RMS
DMS
EDF
LST
8 / 103
Wichtige Begriffe und Parameter
Job Programmeinheit, die geplant und ausgeführt wird.
Task Menge an (zusammengehörigen) Jobs, die zusammen
eine Aufgabe lösen bzw. eine Funktion ausüben.
Ein Job wird durch eine aktive Ressource ausgeführt, z.B. CPU,
Festplatte(-ncontroller), Netz(-karte); d.h., ein Prozessor ist
erforderlich.
Deadline Zeitpunkt, bis zu dem Job bzw. Task ausgeführt sein
muss
Jitter (unerwünschtes) Schwanken der Ausführungszeiten
der Jobs einer Task
Schedule Plan, der die Abarbeitungsreihenfolge von Aktivitäten
festlegt
9 / 103
Zeitpunkte und Zeitspannen
Jobs werden zu einem bestimmten Zeitpunkt tr bereit, nämlich
wenn sie alle angeforderten Betriebsmittel erhalten haben. Von
nun an können sie potentiell abgearbeitet werden, was zu ts
beginnt. Die Abarbeitung endet zu tc . Es sollte tc ≤ td gelten,
ansonsten wird die Deadline und damit die Echtzeitbedingung
dieses Jobs verletzt.
Job ist aktiv
tr
ts
tc
td
t
te
tresp
10 / 103
Zeitpunkte und Zeitspannen
Zeitpunkte:
Release Time
tr
Starting Time
Completion Time
Deadline
ts
tc
td
Zeitspannen:
Execution Time
Response Time
Tardiness
te
tresp
ttard
Zeitpunkt, ab dem ein Job ausgeführt werden kann
Zeitpunkt des Starts eines Jobs
Zeitpunkt der Komplettierung eines Jobs
Zeitpunkt, bis zu dem ein Job beendet sein
muss
Ausführungszeit
Antwort-, Reaktionszeit
Verspätung
tc − ts
tc − tr
tc − td
Anmerkungen:
I
ts ≥ tr
I
ttard = 0, wenn tc < td (keine negative Verspätung)
I
td wird bezogen auf tr (relative Deadline)
Def
11 / 103
Prozesszustände (Wiederholung aus BS1)
aktiv Prozess wird abgearbeitet (besitzt alle zum Fortschritt
nötigen Ressourcen)
bereit Prozess besitzt alle zum Fortschritt nötigen
Ressourcen, wird jedoch gerade nicht abgearbeitet
wartend Prozess besitzt nicht alle zum Fortschritt nötigen
Ressourcen (diese sind an andere Prozesse vergeben)
oder Prozess wartet auf ein Ereignis.
(nicht existent) Prozess wurde beendet oder noch nicht gestartet.
(weitere Subzustände denkbar, hier nicht weiter betrachtet)
neuer Prozeß
bereit
aktiv
wartend
Abbildung: Mögliche Transitionen zwischen Prozesszuständen
12 / 103
Periodisches Taskmodell
I
einfach zu analysieren
I
liegt vielen Verarbeitungsaufgaben zugrunde (Beispiel:
multimediale Ströme)
I
periodische Aktivierung der Jobs einer Task
I
i. Allg. als Tupel Ji (tφ,i , tp,i , te,i , td,i ) notiert mit folgender
Parameterbedeutung:
Parameter
Phase
Periode
Ausführungszeit
(relative) Deadline
Anmerkungen
tφ
tp
te
td
default: 0
(pro Aktivierung)
default: tp
13 / 103
Periodisches Taskmodell
Anmerkungen
I
wenn tφ,i = 0, td,i = tp,i gilt, dann wird deren Angabe
fortgelassen
I
d. h. , der Job Ji wird nur durch seine Periode tp,i und seine
Ausführungszeit te,i beschrieben
I
In komplexeren Taskmodellen1 werden zusätzlich
aperiodische Jobs zugelassen.
1
Diese behandeln wir hier aber nicht.
14 / 103
Auslastung
I
nur für periodische Tasks bestimmbar
I
Ermittlung für Task i:
ui =
I
te,i
tp,i
Gesamtauslastung u eines periodischen Tasksets mit n
Tasks:
n
X
u=
ui
i=1
I
bei 1 Prozessor u < 1 nötig, sonst Überlast
15 / 103
Brauchbarkeit und Optimalität
Definition
Ein Plan (Schedule) einer Menge Jobs heißt brauchbar, wenn
jeder Job aus dieser Menge vor seiner individuellen Deadline
garantiert komplettiert ist.
Definition
Ein Schedulingalgorithmus heißt optimal, wenn der
Algorithmus zu einer gegebenen Menge an Jobs einen
brauchbaren Schedule erzeugt, sofern dieser existiert.
I
ein nicht-optimaler Algorithmus ist also u. U. nicht in der
Lage, einen brauchbaren Schedule zu erzeugen, obwohl
dieser existiert.
16 / 103
Präzedenz
Häufig unterliegen Jobs einer vorgeschriebenen Reihenfolge
(„J1 muss beendet sein, bevor J2 starten kann.“). Darstellung
durch gerichteten Graphen, den Präzedenzgraphen:
I
Knoten: Jobs (Tasks, Teil-Prozesse), bewertet mit Namen
und Ausführungsparametern
I
Kanten: Präzedenzrelationen zwischen Tasks, J1 → J2
bedeutet, daß J1 komplettiert sein muss, bevor J2 gestartet
werden darf
zusätzlich notwendige Informationen:
I
Bereit-Zeiten (tr )
I
Prioritäten, falls relevant
17 / 103
Präzedenzgraph
Beispiel
J ,3
1
J ,1
J ,2
J ,2
3
4
2
J ,2
5
J ,4
7
J ,4
6
J ,1
8
Abbildung: Beispiel für einen Präzedenzgraphen
18 / 103
Präzedenzgraph
Aufgabe
Generieren Sie einen gültigen Schedule sowohl für präemptives
als auch für nichtpräemptives Scheduling, wenn gilt:
I 2 Prozessoren, Migration möglich
I Prioritätsreihenfolge (J1 , J2 , . . . , J8 ) (d.h., J1 hat höchste
Priorität),
I alle Jobs sind zu t=0 bereit, außer J5 , welches erst zu t=4
bereit ist
Vorgehensweise:
1. Start zu t = 0
2. Bereitmenge B(t) der Jobs bilden (Präzedenz und
Bereitzeit beachten)
3. bei n Prozessoren: n höchstpriorisierte Jobs auswählen,
abarbeiten
I
I
präemptiv: t := t + 1
nichtpräemptiv: t bis zur Komplettierung des ersten der
aktiven Jobs inkrementieren
4. GOTO 2
19 / 103
Präzedenzgraph
Lösung der Aufgabe (präemptives Scheduling)
t
Ereignis
B(t)
ausgewählt
0
-
J1 , J2 , J7
J1 , J2
1
J2 beendet
J1 , J3 , J7
J1 , J3
3
J1 , J3 beendet
J4 , J7
J4 , J7
4
J5 bereit
J4 , J5 , J7
J4 , J5
5
J4 beendet
J5 , J7
J5 , J7
6
J5 beendet
J7
J7
8
J7 beendet
J6 , J8
J6 , J8
9
J8 beendet
J6
J6
12
J6 beendet
-
Ende
20 / 103
Präzedenzgraph
Lösung der Aufgabe (zugehörige Schedules)
P1
J1
0 1
P2 J 2 J 3
0 1
J4
J7
2 3 4 5
J6
6 7 8 9 10 11 12
J8
J7 J5
2 3 4 5
t
6 7 8 9 10 11 12
t
Abbildung: Schedule mit Prozessorentzug
P1
J1
0 1
2 3 4 5
P2 J 2 J 3
0 1
J6
J5
J4
J7
2 3 4 5
6 7 8 9 10 11 12
t
J8
6 7 8 9 10 11 12
t
Abbildung: Schedule ohne Prozessorentzug
21 / 103
Effektive Deadlines und Bereitzeiten
Individuelle Deadlines und Bereitzeiten können zu den
Präzedenzen inkonsistent sein:
a) Bereitzeit eines Jobs ist später als die seines Nachfolgers
(⇒ Bereitzeit des Nachfolgers anpassen)
J (8, 10)
2
J (4, 10)
3
b) Deadline eines Jobs ist kleiner als die seines Vorgängers
(⇒ Deadline des Vorgängers anpassen)
J (0, 10)
2
J (0, 4)
3
Legende: Ji (tr ,i , td,i )
22 / 103
Definitionen
Definition (Effektive Bereitzeit)
Die effektive Bereitzeit eines Jobs ohne Vorgänger ist seine
zugeordnete Bereitzeit. Die effektive Bereitzeit eines Jobs mit
Vorgängern ist gleich dem Maximum aus seiner zugeordneten
Bereitzeit und den effektiven Bereitzeiten aller seiner direkten
Vorgänger.
Definition (Effektive Deadline)
Die effektive Deadline eines Jobs ohne Nachfolger ist seine
zugeordnete Deadline. Die effektive Deadline eines Jobs mit
Nachfolgern ist gleich dem Minimum aus seiner zugeordneten
Deadline und den effektiven Deadlines aller seiner direkten
Nachfolger.
23 / 103
Beispiel
Ermitteln Sie die effektiven Bereitzeiten und Deadlines der Jobs
in folgendem Jobsystem (mit Ji (tr ,i , td,i )) :
J (2,10)
1
J (0,7)
2
J (1,12)
J (4,9)
3
4
J (1,8)
5
J (0,20)
6
J (6,21)
7
24 / 103
Scheduling-Anomalien
Beispiel
Frage: Wie ermittelt man die Gesamtabarbeitungszeit, wenn te
eines oder mehrerer Jobs variiert?
Beispiel: 4 Jobs, davon einer mit variabler Ausführungszeit
(J2 ):
Ji
tr ,i
te,i
td,i
J1
J2
J3
J4
0
0
4
0
5
2. . . 6
8
10
10
10
15
20
Keine Migration, 2 Prozessoren, absteigende Priorität (J1
höchste Priorität, J4 niedrigste), präemptive Prozessorvergabe.
25 / 103
Beispiel für Scheduling-Anomalie
Resultierende Schedules
J3
J1
P1
0 1
2 3 4 5
0 1
2 3 4 5
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
J2
P2
t
J4
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
t
Abbildung: Gültiger Schedule für te,2 = 6 (Maximum)
J1
P1
0 1
P2
J2
0 1
2 3 4 5
J4
2 3 4 5
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
J3
t
J4
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
t
Abbildung: Schedule für te,2 = 2 (Minimum)
Taskmenge ist offensichtlich stets planbar?! (Oder nicht?)
26 / 103
Beispiel für Scheduling-Anomalie
Simulation mit Maximum und Minimum von te,i ergibt gültige
Schedules.
Ist das ausreichend?
Antwort: Nein! Gesamtausführungszeit für den Schedule ist
mit te,2 = 3 gleich 21; J4 verpaßt seine Deadline:
J1
P1
0 1
2 3 4 5
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
t
Deadline
verpaßt!
J2
P2
0 1
J4
2 3 4 5
J3
J4
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
t
Abbildung: (ungültiger) Schedule für te,2 = 3
27 / 103
Beispiel für Scheduling-Anomalie; Schlußfolgerung
Für te,2 = 5 wird die Gesamtausführungszeit am kleinsten!
J1
P1
0 1
2 3 4 5
J2
P2
0 1
2 3 4 5
J3
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
t
J4
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
t
Es handelt sich um eine so genannte Scheduling-Anomalie,
d. h. ein unerwartetes Zeitverhalten (eines prioritätsgesteuerten
Systems).
Schlußfolgerung:
I
Validierung des Zeitverhaltens von Echtzeitsystemen mit
variablem Timing besonders aufwendig
I
konstante Ausführungszeiten erwünscht
28 / 103
Earliest Deadline First (EDF)
EDF auf einen Blick
Algorithmus: „Wähle unter den bereiten Job denjenigen zur
Bearbeitung aus, dessen Deadline am ehesten erreicht ist.“
(prioritätsbasiertes Verfahren)
EDF ist optimal, wenn
I
präemptive Prozessorvergabe,
I
1 Prozessor und
I
keine Konkurrenz um Ressourcen.
29 / 103
Beweis der Optimalität I – Ausgangspunkt
Idee: Jeder brauchbare Schedule läßt sich systematisch in
einen EDF-Schedule transformieren.
Ausgangspunkt:
I
2 Jobs Ji , Jk innerhalb eines brauchbaren Schedules, mit
td,i und td,k .
I
Es soll (o. B. d. A.) td,i > td,k gelten.
I
Ji ist im Intervall Ii geplant, Jk im Intervall Ik (siehe
Abbildung).
Ii
Ik
Ji
Jk
t
t d,k t d,i
30 / 103
Beweis der Optimalität II – Transformation in EDF-Schedule
2 Möglichkeiten:
a) tr ,k > Ii → beide Jobs sind bereits (zufällig) nach EDF
geplant,
b) tr ,k < Ii → Austausch von Ji und Jk nötig
Austausch mit Fallunterscheidung:
1. Ii < Ik → Teil von Jk in Ii abarbeiten, Rest in Ik , danach Ji
(vgl. Abbildung)
Jk
Jk
Ji
t
2. Ii > Ik → Jk und danach einen Teil von Ji in Ii abarbeiten,
Rest von Ji in Ik
→ Austausch ohne Verletzung der Gültigkeit des Schedule
immer möglich (sonst wäre Ausgangsschedule nicht gültig)
31 / 103
Beweis der Optimalität III – Generalisierung von 2 auf n Jobs
Das Verfahren kann man nun auf alle Jobpaare Jx , Jy des
Schedule anwenden.
Durch Vertauschung ist es möglich, dass der Prozessor nichts
abarbeitet, obwohl Jobs bereit sind (vgl. Abb.)
„Vorziehen“
notwendig:
Jk
Jk
Ji
t
Diese Verschiebung ist immer möglich.
Schlussfolgerung: Aus jedem brauchbaren Schedule kann ein
EDF-Schedule generiert werden. ⇒ EDF erzeugt stets einen
brauchbaren Schedule, sofern dieser überhaupt existiert.
32 / 103
EDF bei kooperativer Prozessorvergabe
Beispieltaskmenge T :
Ji
tr ,i
te,i
td,i
J1
J2
J3
0
2
4
3
6
4
10
14
12
Plan nach EDF bei kooperativer Prozessorvergabe:
J1
0 1
J2
2 3 4 5
J3
6 7 8 9 10 11 12 13 14
t
Deadline
verpaßt!
Frage: Gibt es überhaupt einen gültigen Schedule für T ?
33 / 103
EDF bei kooperativer Prozessorvergabe
Antwort: Klar!
J1
0 1
J3
2 3 4 5
J2
6 7 8 9 10 11 12 13 14
t
Abbildung: Gültiger Schedule für T bei kooperativer
Prozessorvergabe (nicht durch EDF generiert)
Folgerung: EDF ist nicht optimal bei kooperativer Vergabe des
Prozessors (es findet für bestimmte Taskmengen keinen
brauchbaren Plan, obwohl dieser existiert).
Immerhin: Kein prioritätsgesteuertes Verfahren kann den
gültigen Schedule erzeugen, da diese per definitionem niemals
den Prozessor leer lassen, wenn bereite Jobs existieren!
34 / 103
EDF auf Multiprozessorsystemen
Beispieltaskmenge U:
Ji
tr ,i
te,i
td,i
J1
J2
J3
0
0
0
1
1
5
1
2
5
Plan nach EDF für n = 2 Prozessoren (präemptiv):
P1 J 1
0 1
J3
2 3 4 5
P2 J 2
0 1
2 3 4 5
6 7
J 3verpaßt
Deadline!
6 7
t
t
Frage: Gibt es überhaupt einen gültigen Schedule für U?
35 / 103
EDF auf Multiprozessorsystemen
(Erneute) Antwort: Klar!
P1 J 1 J 2
0 1
2 3 4 5
6 7
t
J3
P2
0 1
2 3 4 5
6 7
t
Abbildung: Gültiger Schedule für U auf n = 2 Prozessoren,
präemptive Vergabe (nicht durch EDF generiert)
Folgerung: EDF ist nicht optimal2 für n > 1 Prozessoren.
2
Was hieß das nochmal?
36 / 103
Latest Release Time (LRT) oder “reverse EDF”
EDF: Jobs so früh wie möglich abgearbeitet; dies kann in
bestimmten Situationen unerwünscht sein.
Idee: Jobs spätestmöglich bearbeiten, zuvor nach Möglichkeit
andere (Nicht-Echtzeit-) Jobs einschieben (deren Reaktionszeit
damit minimiert wird).
Algorithmus LRT: Beginnend am Maximum aller Deadlines
wird der Schedule „rückwärts“ bis zum Startzeitpunkt
aufgebaut. Wenn mehrere Prozesse zu einem Zeitpunkt bereit
sind, wird stets derjenige mit der spätesten Bereitzeit
ausgewählt.
37 / 103
Beispiel
3 Jobs Ji te,i (tr ,i , td,i )
J 3(0, 6)
J 2(5, 8)
1
2
J 2(2, 7)
3
Resultierender Schedule nach LRT:
J1
0 1
J3
2 3 4 5
J2
6 7 8 9 10
t
38 / 103
Einschätzung
I
LRT ist optimal unter den gleichen Bedingungen wie EDF
(1 Prozessor, präemptive Vergabe, keine Konkurrenz um
Ressourcen)
I
LRT ist nicht prioritätsbasiert, da es u. U. den Prozessor
idle läßt, obwohl bereite Jobs existieren.
I
LRT kann nur offline genutzt werden.
39 / 103
Least Slack Time First (LST)
Parameter Slack Time tsl,i eines Jobs Ji :
tsl,i (t) = td,i − t − verbleibende te,i
(„Pufferzeit“; Wieviel Zeit ist noch, bis Job unbedingt begonnen
werden muss?)
Algorithmus: „Wähle den Job zur Abarbeitung aus, dessen
Slack Time am kleinsten ist.“
Beispiel: J1 3(0, 6) hat zum Zeitpunkt t = 0 die Slack Time
tsl,1 (0) = 6 − 3 − 0 = 3. Wird J1 abgearbeitet, so bleibt tsl,1
konstant; wenn nicht, so reduziert sich tsl,1 (wenn z. B. J1 bis zu
t = 2 nicht abgearbeitet wird, verringert sich die Slack Time
tsl,1 (2) = 6 − 3 − 2 = 1). Erreicht die Slack Time 0, so muss der
Job abgearbeitet werden, sonst verletzt er seine Deadline.
40 / 103
Least Slack Time First (LST)
Einschätzung
I
prioritätsbasiertes Verfahren
I
optimal für 1 Prozessor, präemptive Prozessorvergabe und
keine Konkurrenz um Ressourcen
I
Wissen über te notwendig → Nachteil! (Warum?)
I
aka Minimum Laxity First (MLF)
41 / 103
Prinzip des zeitgesteuerten Schedulings
I
Grundidee: Ermittlung des Schedule off-line, zur Laufzeit des
Systems wird der Schedule nur Position für Position abgearbeitet
I
periodisches Taskmodell nötig (sonst unendlicher Schedule,
nicht speicherbar)
I
Ermittlung des Schedule off-line → komplexe Algorithmen
nutzbar (hier: Netzwerkflüsse)
I
konstante Anzahl periodischer Echtzeit-Tasks Ti (tφ,i , tp,i , te,i , td,i ),
1 Prozessor
I
Schedule einer Menge aus n Tasks besteht aus
aneinandergereihten Segmenten der Länge
H = kgV(tp,i ) i = 1, 2, . . . , n
I
H wird Hyperperiode genannt
I
Tasks ohne Deadline konsumieren bei Bedarf verbleibende Zeit
42 / 103
Zeitgesteuertes Scheduling
Beispiel
Beispiel: 4 periodische unabhängige Tasks (Ti (tp,i , te,i ))
T1 (4, 1)
T2 (5, 1.8)
u=
T3 (20, 1)
T4 (20, 2).
1 1.8
1
2
+
+
+
= 0.76
4
5
20 20
H = 20
brauchbarer Schedule (ad hoc):
T1 T3 T2
0 1
I
I
T1
2 3 4 5
T4
T2 T1
T2 T1
T1
T2
T1
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
...
t
Intervalle, in denen keine periodische EZ-Task
abgearbeitet wird (z.B. [3.8, 4] oder [5, 6]) → für
aperiodische Jobs
aperiodische Jobs beim Eintreffen in Warteschlange (FIFO
bzw. priorisiert) eingeordnet
43 / 103
Struktur des Schedule
Datenstruktur zur Beschreibung des Schedule: Tabelle über 1
Hyperperiode mit Einträgen (tk , T (tk )) mit k = 0, 1, . . . , n − 1
tk
T (tk )
Schedulingzeitpunkte
assoziierte Tasks, bzw. „I“ für idle
Der Schedule für das Beispiel sähe also so aus:
(0, T1 )
(1, T3 )
(2, T2 )
(3.8, I)
(4, T1 )
(5, I)
(6, T4 )
..
.
(19.8, I)
44 / 103
Implementierung eines zeitgesteuerten Schedulers
(Cyclic Executive)
aktueller Tabelleneintrag k = 0
Timer konfigurieren, so dass Interrupt zu t0 ausgelöst wird
while (1) {
Timerinterrupt bestätigen
sichere Kontext des abgearbeiteten aperiodischen Jobs (falls
nötig)
aktuelle Task T := T[k]
nächster Tabelleneintrag k = ++k mod(N)
Timer auf nächsten Taskstart konfigurieren
if (T==’I’)
aperiodischen Job ausführen (falls vorhanden)
else
T ausführen
sleep
}
I
ungünstig: Aktivierung des Schedulers nach jedem Job (hoher
Overhead; besonders bei sehr kurzen Jobs)
45 / 103
Zur Struktur zyklischer Schedules
I
günstig, die Hyperperiode (Länge H) in gleichlange Frames zu
strukturieren
I
Verringerung der Anzahl der Aktivierungen des Schedulers: nur
noch am Anfang jedes Frames
I
Vereinfachung: Timer besitzt konstante Periode (keine
Reprogrammierung mehr nötig)
I
innerhalb des Frames werden Jobs einfach nacheinander
aufgerufen
I
minimiert zudem Anzahl vorzeitiger Beendigungen aperiodischer
Tasks
H
t
t+f
t+2f
t+3f
t+H
1 Frame
46 / 103
Überlegungen zur Framegröße
1.) keine vorzeitige Beendigung (preemption) an Framegrenze
Framegröße f mindestens so groß wie größte
Ausführungszeit eines Jobs
f ≥ max(te,i )
∀i : 1 ≤ i ≤ n
(1)
2.) Framegröße f ganzzahliger Teiler der Hyperperiode H,
sonst Schedule u. U. sehr lang (kgV(f , H)).
f |H
(2)
3.) Framegröße f so klein, daß zwischen tr und td jedes Jobs
mindestens ein kompletter Frame liegt (erleichtert
Scheduler die Entscheidung, ob jeder Job seine Deadline
einhält; Platzierung des Jobs in diesem Frame garantiert
Einhaltung aller Zeitbedingungen → erleichtertes
Scheduling).
47 / 103
Ableitung des dritten Frame Size Constraints I
Ein Job J werde in einem Frame k der Größe f zu tr bereit (mit
t ≤ tr ≤ t + f ), besitze eine relative Deadline von td und eine
Periode von tp .
Frame k
t
Frame k + 1
t +f
tr
Frame k + 2
t + 2f
a
t + 3f
td
tp
Damit wenigstens ein vollständiger Frame (nämlich Nr. k + 1)
zwischen tr und td liegt, muss der Abstand a zwischen tr und
der Framegrenze (t + f ) plus die Länge des (dazwischenliegenden) Frames k + 1 kleiner oder wenigstens gleich der
Deadline des Jobs sein:
a + f ≤ td
(3)
48 / 103
Ableitung des dritten Frame Size Constraints II
Für tp 6= f variiert der Abstand a. Er wird genau dann maximal,
wenn tr so nahe wie möglich hinter (aber nicht genau auf, denn
dann ist er 0) dem Framestart t liegt. Der minimale Abstand
zwischen Framestart t und tr wird durch das Verhältnis
zwischen tp und f bestimmt. Wenn tr irgendwann einmal
synchron zu einem Framestart lag, dann gilt:
tr − t ≥ ggT(f , tp )
Damit können wir für a formulieren:
a ≤ f − ggT(f , tp )
Dies setzen wir in Gleichung 3 ein und erhalten für t 6= tr :
f − ggT(f , tp ) + f ≤ td
(4)
49 / 103
Ableitung des dritten Frame Size Constraints III
Falls Framestart t und Bereitzeit tr synchron liegen (t = tr ),
dann ist offensichtlich f ≤ td hinreichend. Da stets
1 ≤ ggT(f , tp ) ≤ f gilt, ist diese Bedingung automatisch erfüllt,
wenn Gleichung 4 erfüllt ist; dieser Fall muss also nicht
gesondert betrachtet werden.
Somit kann die dritte Vorschrift für die Framegröße formuliert
werden zu:
2f − ggT f , tp,i ≤ td,i
∀i | 1 ≤ i ≤ n
(5)
Die Gleichungen 1, 2 und 5 werden Frame Size Constraints3
genannt. Ihre Einhaltung gestattet die Verwendung
leistungsfähiger Schedulingverfahren und einer verbesserten
Cyclic Executive.
3
Theodore P. Baker und Alan C. Shaw. “The Cyclic Executive Model and Ada”. In: Real-Time Systems Journal
1.1 (1989).
50 / 103
Beispiel zu Frame Size Constraints
Gegeben: 3 periodische Tasks Ti mit
i
tp,i
td,i
te,i
1
15
14
1
2
20
26
2
3
22
22
3
Gesucht: Hyperperiode H und günstige Framegrößen f
Lösung:
H = kgV(15, 20, 22) = 660
1.) f ≥ 3
2.) f ∈ {2, 3, 4, 5, 6, 10, 11, 12, 15, 20, 22, . . .}
3.) f ≤ 6
⇒ f ∈ {3, 4, 5, 6}
51 / 103
Job Slicing
Beispieltaskmenge: T1 (4, 1)
T2 (5, 2, 7)
T3 (20, 5).
H = 20, aber 1.) f ≥ 5 und 3.) f ≤ 4. Was tun?
Idee: Partitionierung langer Tasks in Subtasks, um Kriterium 1
leichter erfüllen zu können.
Nachteil: mehr Kontextwechsel nötig, da dekomponierte Task
vorzeitige Beendigungen benötigt
Dekomposition von T3 (20, 5) in T3,1 (20, 1), T3,2 (20, 3) und
T3,3 (20, 1); damit:
1.) f ≥ 3
2.) f ∈ {2, 4, 5, 10, 20}
3.) f ≤ 4
⇒ f = 4.
52 / 103
Struktur eines Schedule mit Job Slicing
T3,1
T1
0
T2
T3,3
T1
4
T3,2
T1
8
T2
T1
12
T2
T1
T2
16
H
T1
20 21
...
t
Abbildung: Struktur eines Schedule mit Job Slicing
53 / 103
Graphentheorie: Flüsse in Netzwerken
I
I
I
I
Eingabe ist Problembeschreibung in Form eines
gerichteten Graphen G = (V , E)
V : Knotenmenge, E: Kantenmenge
jeweils ein Knoten für Quelle Q und Senke S
jede Kante e ∈ E besitzt eine Kapazität c(e) und einen
aktuellen Fluss ϕ(e).
A
4
B
1
4
Quelle
1
Senke
2
2
3
5
C
2
D
Abbildung: Beispiel für Netzwerk (noch ohne Fluss)
54 / 103
Flüsse in Netzwerken (Network Flows)
Regeln
I
für alle Knoten außer Q und S muss die Summe der
Zuflüsse gleich der Summe der Abflüsse sein
(„Kirchhoff-Regel“)
I
Gesucht ist der maximale Durchfluß zwischen Quelle und
Senke unter Beachtung der Kantenkapazität
I
es existieren schnelle Lösungsalgorithmen mit
polynomialem Aufwand
I
(u.a.) für viele Scheduling-Probleme nutzbar
55 / 103
Der Algorithmus von Ford und Fulkerson (1956)
Definition des Restgraphen
Def. Gegeben sei ein Netzwerk G = (V , E) mit einem aktuellen
Fluss ϕ. Der zugehörige Restgraph RG = (V , Eϕ ) hat die
gleiche Knotenmenge V wie G. Für seine Kanten gilt:
I
∀e ∈ E mit ϕ(e) < c(e) gibt es eine Kante e in Eϕ mit
cϕ (e) = c(e) − ϕ(e)
(„Für jede Kante in G, deren aktueller Fluss kleiner ist als ihre
Kapazität, gibt es eine Kante gleicher Richtung in RG, deren
Kapazität die Differenz aus Kapazität und aktuellem Fluss in G
ist.“)
I
∀e ∈ E mit ϕ(e) > 0 gibt es eine umgekehrte Kante e0 mit
ϕ(e0 ) = ϕ(e)
(„Für jede Kante in G, durch die etwas fließt, gibt es eine Kante
in umgekehrter Richtung und gleichem Fluss in RG“)
56 / 103
Beispiel zum Restgraph
A
4,2
B
1,0
4,2
Quelle
1,0
Senke
2,0
2,2
3,0
5,2
C
2,0
D
Abbildung: Fluss in Netzwerk, Kantenbewertung: (c(e), ϕ(e))
2
A
2
B
2
1
2
Q
1
S
2
2
3
3
C
2
D
2
Abbildung: zugehöriger Restgraph
57 / 103
1. START, initialer Fluss ϕ = 0.
2. Markiere Q.
3. Markiere weitere Knoten nach folgender Regel: „Wenn x
markiert ist, und es gibt im RG eine Kante e = (x, y ), dann
markiere y , wenn dieser noch unmarkiert ist.“
4. S markiert?
nein → Maximaler Fluss erreicht; END.
5. Erhöhung des aktuellen Flusses ϕ durch Adaption des RG:
Kanten, die auf dem Weg von Q nach S liegen, seien ei . Ermittle
δ = min(cϕ (ei )). Adaption des Flusses entlang des neuen
Weges:
I
I
wenn ei ∈ E, dann ϕ(ei ) := ϕ(ei ) + δ
wenn rev(ei ) ∈ E, dann ϕ(ei ) := ϕ(ei ) − δ
6. Aufhebung aller Markierungen, GOTO 2.
58 / 103
I
einfachste Lösung des Problems
I
viele weitere Algorithmen existieren, die geringere
Zeitkomplexität aufweisen, aber schwieriger zu verstehen
sind, z. B. :
1969
Edmonds/Karp
O(n5 )
1970
Dinic
O(n4 )
1988
Goldberg/Tarjan
O(n3 )
59 / 103
Beispiel:
1.
A
4
B
4
Q
1
2
δ=2
3
5
2
C
3.
2
D
4.
4
1
4
1
2
neuer Weg: Q−A−B−D−S
δ=2
3
2
2
4
4
2
1
5.
neuer Weg: Q−C−D−S
S
2
3
2
2.
1
2
6.
2
60 / 103
2
Scheduling-Problem als Netzwerkfluss
Annahmen: Unterbrechung von Tasks immer möglich, Tasks
unabhängig, alle möglichen Framegrößen f ermittelt
Idee: Beginnend bei Maximum alle Framegrößen f testen, ob
Schedule möglich (je kleiner f , desto ungünstiger).
Konstruktion des Netzwerks
1. für jeden Job und jedes Frame einen Knoten, zusätzlich Quelle
Q und Senke S
2. von Q zu jedem Job Ji eine Kante mit Kapazität te,i
3. von jedem Frame zu S eine Kante mit Kapazität f (Framegröße)
4. von Job Ji zu Frame eine Kante mit Kapazität f gdw. Job gemäß
Timingconstraints in Frame abgearbeitet werden kann:
→ Ein Job Ji kann nur in den Frames geplant werden, deren
Startzeit größer oder gleich tφ,i ist und die nicht später enden als
td,i !
61 / 103
Scheduling-Problem als Netzwerkfluss
Ermittlung des maximalen Flusses von Jobs zu Frames mittels
geeignetem Verfahren.
P
Ist der maximale Fluss durch den Graphen ϕ größer als i te,i , dann
repräsentiert der Graph einen brauchbaren Schedule.
Anordnung der Jobs in den Frames ist bei Einhaltung der
Timingconstraints beliebig.
62 / 103
Beispiel: T1 (4, 3) und T2 (6, 1.5)
Bestimmung Framegröße und Jobparameter
2 periodische Tasks: T1 (4, 3) und T2 (6, 1.5)
I
H = 12, f = 4
3 Frames in Hyperperiode:
f1 [0, 4), f2 [4, 8), f3 [8, 12)
I
mehrere Aktivierungen der Tasks in H, d.h. individuelle
Jobs Jx (tφ , td , te ) mit verschiedenen Bereitzeiten und
Deadlines
I
T1 → J1,1 (0, 4, 3), J1,2 (4, 8, 3), J1,3 (8, 12, 3)
I
T2 → J2,1 (0, 6, 1.5), J2,2 (6, 12, 1.5)
63 / 103
Beispiel: T1 (4, 3) und T2 (6, 1.5)
Zugehöriger Netzflussgraph
Jobs
Frames
J1,1 (0,4,3)
4
f1 [0,4)
J1,2 (4,8,3)
3
4
Q
4
4
3
J1,3 (8,12,3)
3
4
S
f2 [4,8)
1.5
4
4
1.5
J2,1 (0,6,1.5)
4
f3 [8,12)
J2,2 (6,12,1.5)
Es gilt ϕ = 11 <
unmöglich.
P
i te,i
= 12, ein Schedule ist also für f = 4
64 / 103
Beispiel: T1 (4, 3) und T2 (6, 1.5)
Ausweg: Jobslicing; neue Jobparameter
Verkleinerung des Frames auf f = 2; somit
I
6 Frames:
f1 [0, 2), f2 [2, 4), f3 [4, 6), f4 [6, 8), f5 [8, 10), f6 [10, 12)
I
Dekomposition der Jobs von T1 :
alt
neu
J1,1 (0, 4, 3)
J1,2 (4, 8, 3)
J1,3 (8, 12, 3)
J111 (0, 4, 2)
J121 (4, 8, 2)
J131 (8, 12, 2)
J112 (2, 4, 1)
J122 (6, 8, 1)
J132 (10, 12, 1)
I
J2,1 und J2,2 bleiben unverändert
I
Anzahl Jobs erhöht sich von 5 auf 8
65 / 103
Beispiel: T1 (4, 3) und T2 (6, 1.5)
Netzwerk bei Jobslicing
Jobs
Frames
J111
2,2
2,2
0,2
J112
f1
0,2
1,2
1,1
2,2
f2
J121
1.5,2
2,2
1,2
2,2
1,1
J122
f3
1,2
Q
2,2
0.5,2
0.5,2
J131
S
2,2
f4
2,2
1,1
J132
1.5,1.5
1.5,1.5
2,2
2,2
0.5,2
1,2
f5
J21
2,2
0,2
0,2
J22
f6
1,2
66 / 103
Beispiel: T1 (4, 3) und T2 (6, 1.5)
Ergebnis
P
Für das neue Netzwerk gilt ϕ = 12 = i te,i , somit kann man
mit f = 2 einen gültigen Schedule ableiten:
J 21 J 121
J 111 J 111 J 112 J 21
0
2
J 121
4
J 22
J 122
6
J 131 J 131 J 132 J 22
8
10
...
12
t
Abbildung: Gültiger Schedule für Framegröße f = 2
67 / 103
Zusammenfassung: Off-Line-Scheduling
Die Frage, ob On-Line- oder Off-Line-Scheduling geeigneter für
Echtzeitsysteme ist, wird in der Fachwelt kontrovers diskutiert45 , und
ist nicht einfach zu beantworten.
Für On-Line-Scheduling sprechen einerseits:
I
Off-Line verfahren sind inhärent inflexibel (komplette
Neuberechnung nötig bei Modifikationen an der Taskmenge).
I
Es existieren On-line-Verfahren mit sehr geringem
Schedulingoverhead (RMS, DMS, EDF).
Andererseits sind On-Line-Verfahren wie RMS und DMS nicht
generell optimal, wie im folgenden Abschnitt gezeigt wird. Das
bedeutet, es gibt Taskmengen, die per Off-Line-Verfahren planbar
sind, per On-Line-Verfahren jedoch nicht geplant werden können.
4
N. Audsley, K. Tindell und A. Burns. “The End of the Line for Static Cyclic Scheduling?” In: Proceedings of the
Fifth Euromicro Workshop on Real-time Systems. Oulu, Finland: IEEE Computer Society Press, Juni 1993,
S. 36–41.
5
Jia Xu und David Lorge Parnas. “Priority Scheduling Versus Pre-Run-Time Scheduling”. In: International
Journal of Time-Critical Computing Systems 18 (2000), S. 7–23.
68 / 103
On-Line-Scheduling periodischer Tasks
Einführung
Modellannahmen: ein Prozessor, unabhängige Tasks, keine
aperiodischen und sporadischen Tasks
Unterscheidung:
1. feste (statische) Prioritäten: jeder Job einer Task hat die gleiche
Priorität
2. variable (dynamische) Prioritäten: Jeder Job erhält eine
individuelle Priorität
2.1 feste Job-Prioritäten (“task-level-dynamic, job-level-fixed”):
eine einem Job zugeordnete Priorität bleibt konstant
2.2 variable Job-Prioritäten (“job-level-dynamic”): die einem Job
zugeordnete Priorität kann sich ändern
Dynamische Verfahren sind flexibler und lasten den Prozessor
möglicherweise besser aus, aber das korrekte Systemverhalten
statischer Verfahren ist weitaus leichter zu garantieren!
69 / 103
Einplanungstests
On-Line-Schedulingverfahren treffen zur Laufzeit
Entscheidungen der Art
„Gegeben ist die Taskmenge T = {T1 , T2 , . . . , Tn } der
aktuell abgearbeiteten Tasks. Ist es möglich, eine
neue Task Tn+1 in die Abarbeitung aufzunehmen, so
daß alle Tasks ihre Deadlines einhalten?“
„Ja“ → T := T ∪ Tn+1
„Nein“ → Tn+1 wird abgewiesen
Diese Entscheidung, der Einplanungstest (schedulability test),
wird zur Laufzeit gefällt ⇒ einfaches Verfahren wichtig.
70 / 103
Ratenmonotones Scheduling (RMS)
Verfahren
Algorithmus: Die Priorität einer Task ergibt sich aus ihrer
Periode. Je höher die Rate einer Task (d.h., je kürzer ihre
Periode) desto höher ihre Priorität.
Beispiel: 3 (periodische) Tasks Ti (tp,i , te,i )
T1 (4, 1) T2 (5, 2)
da tp,1 < tp,2 < tp,3
T3 (20, 5)
⇒
Prio(T1 ) > Prio(T2 ) > Prio(T3 )
Bereitzeiten der individuellen Jobs:
tr ,1 = {0, 4, 8, 12, 16, 20, . . .}
tr ,2 = {0, 5, 10, 15, 20, . . .}
tr ,3 = {0, 20, 40 . . .}
I
Ältestes publiziertes Verfahren6 !
6
C. L. Liu und James W. Layland. “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time
Environment”. In: Journal of the ACM 20.1 (Jan. 1973), S. 46–61.
71 / 103
Aus Beispiel resultierender Plan
Plan für T1 (4, 1), T2 (5, 2), T3 (20, 5):
T3
...
T2
...
T1
...
RMS T1 T2
0
2
T3 T1 T2
4
6
T3 T1 T3 T2
8
10
T1 T3
12
14
T2 T1 T2
16
18
T1
20
...
t
Vorzeitiger Prozessorentzug zu t = 4, 8, 10 (T3 ) und t = 16 (T2 ).
72 / 103
Weiteres Beispiel
⇒
T1 (2, 0.9) T2 (5, 2.3)
Prio(T1 ) > Prio(T2 )
Bereitzeiten:
tr ,1 = {0, 2, 4, 6, 8, 10, . . .}, tr ,2 = {0, 5, 10, 15, . . .}
T1
0
0.9
0.9
0.9
0.9
0.9
J 1,1
J 1,2
J 1,3
J 1,4
J 1,5
1
T2
0
1
2
3
4
1.1
1.1
J 2,1
J 2,1
2
3
5
0.1
4
6
7
8
1.0
1.1
J 2,2
J 2,2
5
6
7
J 2,1
9
10
t
10
t
0.2
8
9
J 2,2
T2 wird „im Hintergrund“ von T1 ausgeführt.
Für die Auslastung gilt: u =
n
X
te,i
i=1
tp,i
= 0.91.
73 / 103
Eigenschaften
I
höchstpriorisierte Task wird nie „gestört“ (unterbrochen,
verzögert)
I
je größer Periode, desto mehr Unterbrechungen und
Verzögerungen (abhängig von Last)
I
leicht zu implementieren
I
Aufwand zur Laufzeit gering (viel geringer als EDF), da
statische Prioritäten
I
im Überlastfall gute Vorhersagbarkeit: von n Tasks werden
garantiert nur k (k < n) beeinflußt, die k
niedrigstpriorisierten (k ist bestimmbar)
Vorteil
gegenüber EDF!
I
Einplanbarkeitstest nicht so simpel wie bei EDF
(Sonderfall: einfach periodische Taskmengen)
74 / 103
Deadlinemonotones Scheduling (DMS)
Idee: Wenn relative Deadlines von den Perioden differieren,
müssen diese für die Priorisierung genutzt werden.
Algorithmus: Je näher die (relative) Deadline, desto größer
die Priorität.
Beispiel (DMS): 3 (periodische) Tasks Ti (tφ,i , tp,i , te,i , td,i )
T1 (50, 50, 25, 100)
u1 = 0.5
T2 (0, 62.5, 10, 20)
u2 = 0.16
T3 (0, 125, 25, 50)
u3 = 0.2
PrioDMS (T2 ) > PrioDMS (T3 ) > PrioDMS (T1 )
T1
J 1,2
0
50
62.5
85
100
125
150
185
225
250
t
200
250
t
200
250
t
200
J 2,3
T2
0
10
50
72.5
100
T3
135
150
197.5
J 3,2
0
35
50
100
160
150
75 / 103
Vergleich mit RMS
td = tp
DMS wird zu RMS
td 6= tp
DMS besser als RMS (d.h. generiert u. U. noch
einen brauchbaren Schedule, wenn RMS bereits nicht
mehr in der Lage dazu ist)
Beispiel: der per RMS generierte Schedule der Taskmenge
aus dem vorigen Beispiel:
T1 (50, 50, 25, 100), T2 (0, 62.5, 10, 20), T3 (0, 125, 25, 50)
I nun PrioRMS (T1 ) > PrioRMS (T2 ) > PrioRMS (T3 )
I
I
T1
...
0
50
75
100
125
150
175
225
250
t
200
250
t
200
250
t
200
T2
0
10
50
85
100
135
150
197.5
Deadline
verletzt!
T3
0
35
50
100
150
Deadline
verletzt!
76 / 103
Vergleich mit RMS
I
T2 verletzt seine (absolute) Deadline td = 82.5 (erst zu
t=85 beendet) und T3 verletzt seine (absolute) Deadline
td = 175 (erst zu t = 185 beendet).
I
Tasks mit kurzer relativer Deadline (hier T2 mit
tp = 62.5, td = 20) werden durch RMS benachteiligt.
Weiterführende Literatur: Neil C. Audsley. Deadline Monotonic
Scheduling. Techn. Ber. YCS 146. Department of Computer
Science, University of York, Sep. 1990
77 / 103
EDF mit periodischen Tasks
Beispiel: Taskpaar aus Beispiel 2 für RMS
Ti (tp,i , te,i ) = T1 (2, 0.9), T2 (5, 2.3)
0
1
2
3
0
1
5
2
3
6
7
4
5
8
9
J 2,2
J 2,2
J 2,1
J 2,1
T2
4
J 1,5
J 1,4
J 1,3
J 1,2
J 1,1
T1
6
7
...
10
t
...
8
9
10
I
t=0: td,1 = 2, td,2 = 5 ⇒ J1,1 abgearbeitet
I
I
I
d.h., im Intervall [0,4) hat T1 die höhere Priorität und im
Intervall [4,5) hat T2 die höhere Priorität
t
78 / 103
EDF mit periodischen Tasks
I
⇒ dynamische Priorität auf Task-Level (Priorität
individueller Jobs ist fest)
I
→ höherer Schedulingaufwand als R/DMS, da
Neuberechnung der Prioritäten nötig
Einplanungstest für EDF:
Gegeben: n unabhängige, periodische Tasks, 1 Prozessor
Das System ist nach EDF schedulbar, wenn gilt:
n
X
i=1
te,i
≤1
min(td,i , tp,i )
.
(6)
79 / 103
LST mit periodischen Tasks
Beispiel: T1 (2, 0.8) T2 (5, 1.5) T3 (5.1, 1.5)
t
0
1.2
3.5
3.6
ts,1
ts,2
ts,3
0.8
–
2.7
2.8
2
1.2
2.7
1.6
0.8
4
1.2
0.7
0.8
4.3
0.9
–
0.5
0.8
1
2
3
4
5
0
1
6
t
0.3
J 2,2
J 2,1
T2
5.4
–
3.1
3.3
J 1,3
J 2,1
1.2
4.6
0.6
–
–
0.8
J 1,2
T1 J 1,1
0
2.8
–
1.9
0.8
2
3
4
J 3,1 5
6
t
4
5
6
t
1.2
J 3,1
T3
0
1
2
3
80 / 103
LST mit periodischen Tasks
⇒ dynamische Priorität auf Task-Level und auf Job-Level! (z. B. J2,1
hat zu t = 0 mittlere, zu t = 2 niedrigste und zu t = 4 höchste
Priorität).
I
„nonstrict“ LST, da Berechnung der Slackzeiten nur, wenn
Zustandswechsel eines Jobs (komplettiert oder bereit)
I
eigentliches („strict“) LST müßte jedesmal, wenn eine Änderung
einer Slackzeit auftritt, die Prioritäten neu verteilen (Aufwand!)
Situation in letztem Beispiel zu t = 3.9:
ts,2 = td,2 − te,2 − t = 5 − 0.3 − 3.9
= 0.8
ts,3 = td,3 − te,3 − t = 5.1 − 0.4 − 3.9
= 0.8
(J2,1 „überholt“ J3,1 in der Priorität.)
Aufwandsproblem zur Laufzeit (“runtime overhead”): ständiges
Überwachen aller slack times nötig. Daher strict LST nicht
praktikabel.
81 / 103
Periodisches EDF und Überlast
Frage: Wie verhält sich EDF, wenn u > 1?
1. Beispiel: T1 (2, 1) T2 (5, 3)
u=
0
1
2
3
0
1
4
5
6
7
8
2
3
4
9
Deadline
verletzt!
J 2,2
J 2,1
J 2,1
T2
J 1,5
J 1,3 J 1,4
J 1,2
J 1,1
T1
1 3
11
+ =
= 1.1
2 5
10
5
6
7
8
9
10
t
Ein Job einer Task (J1,5 ) verpaßt seine Deadline zu t = 10.
82 / 103
2. Beispiel: T1 (2, 0.8)
u=
0.8
T2
0
0.8 3.5
11
+
=
= 1.1
2
5
10
0.8
0.8
1
2
3
4
1.2
2.3
J 2,1
J 2,1
1
2
0.8
J 1,3 J 1,4
J 1,2
T1 J 1,1
0
T2 (5, 3.5)
3
4
5
6
0.1
7
J 2,2
8
9
3.4
Deadline
verletzt!
J 2,2
5
6
7
8
9
10
t
Alle Jobs von T2 sowie J1,5 von T1 verpassen ihre Deadline.
83 / 103
Problem: Trotz gleicher Last unterschiedliches Verhalten. Es
gibt keinen (einfachen) Test für EDF, welche Jobs bei Überlast
ihre Deadline verpassen.
Schlußfolgerungen:
I
Bei EDF kann bei Überlast keine Aussage getroffen
werden, welcher Job (bzw. welche Task) seine Deadline
noch erreicht.
I
Die Verletzung einer Deadline bei EDF kann die Verletzung
weiterer Deadlines auch anderer Tasks bewirken (keine
“Erholung” von einer temporären Überlastung möglich)
I
⇒ EDF nur zum Scheduling von periodischen Tasks
geeignet, wenn u ≤ 1 garantiert.
84 / 103
Einplanbarkeitstests für RMS
Übersicht
I
I
viele verschiedene (unterschiedlicher Rechenaufwand und
Pessimismus)
behandeln:
1. Test für einfach periodische Taskmengen
2. Ratenmonotone Analyse (exakt, aufwändig)
3. Test nach Liu/Layland (pessimistisch, simpel)
I
weitere Tests in EZS2 (u.a. Hyperbolic Bound, Test von
Burchard), Grundlage für partitionierendes
Multiprozessor-Scheduling
85 / 103
RMS-Test für einfach periodische Taskmengen
Definition: Wenn innerhalb einer Taskmenge
T = {T1 , T2 , . . . , Tn } für jedes Taskpaar Ti , Tj ∈ T gilt:
tp,i < tp,j ⇒ tp,j = m · tp,i
m∈N
so nennt man T einfach periodisch.
Gegeben: n unabhängige, periodische Tasks, 1 Prozessor,
Taskmenge einfach periodisch
Das System ist nach RMS schedulbar, wenn gilt:
u=
n
X
i=1
te,i
≤1
min(td,i , tp,i )
.
(7)
86 / 103
Ratenmonotone Analyse
Voraussetzung: n periodische, unabhängige Tasks mit
beliebigen Perioden (keine einfach periodische Taskmenge)
Frage: Wann ist die Antwortzeit tresp,i = tc,i − tr ,i eines Jobs Ji
maximal, wenn nach RMS geschedult wird?
Vermutung: Wenn zu seiner Bereitzeit tr ,i alle
höherpriorisierten Jobs (d.h. Jobs mit kürzerer Periode)
ebenfalls bereit werden. Der Job wird dann maximal verzögert.
Dieser spezielle Zeitpunkt wird kritischer Zeitpunkt tcrit,i des
Jobs Ji genannt.
87 / 103
Veranschaulichung „Kritischer Zeitpunkt“
A)
T1
t
T2
t
tresp,2
B)
T1
t
T2
t
C)
tresp,2
T1
t
T2
t
tresp,2
88 / 103
Begriff des Kritischen Zeitpunkts
Jeweils 2 Tasks mit Prio(T1 ) > Prio(T2 ), 3 mögliche Fälle
A) tr ,1 = tr ,2
B) tr ,1 < tr ,2
Verzögerung von J2 geringer
C) tr ,1 > tr ,2
Verzögerung von J2 nicht größer als im Fall A)
⇒ Wird ein Job zu seinem kritischer Zeitpunkt bereit, so wird
seine Antwortzeit maximal.
Idee eines Einplanbarkeitstests für RMS:
„Wenn die maximale Antwortzeit einer Task kleiner ist
als ihre Periode (= Deadline), dann kann die Task
gefahrlos nach RMS eingeplant werden.“
Eine Menge an Tasks kann folglich nach RMS geschedult
werden, wenn diese Bedingung für alle Tasks aus der Menge
gilt.
89 / 103
Iteratives Verfahren
Voraussetzungen:
I
Tasks T1 , . . . , Ti−1 haben eine höhere Priorität und sind nach
dieser absteigend geordnet
I
Startwert der Iteration: t (0) = te,i
I
iteriert, bis eine der Abbruchbedingungen erfüllt
I
Iteration ist monoton wachsend, d.h., t (l+1) ≥ t (l)
∀l ∈N
Iterationsvorschrift:
t
(l+1)
= te,i +
i−1 (l) X
t
k =1
tp,k
· te,k
(8)
Abbruchbedingungen:
1. t (l) > tp,i
Task Ti kann nach RMS nicht geschedult werden, da
im worst case Verzögerung über Deadline hinaus,
Konvergenz; tmaxresp,i = t (l)
2. t (l+1) = t (l)
RMS geschedult werden.
Task Ti kann nach
90 / 103
Beispiel
Gegeben: T1 = (3, 1) T2 = (5, 1.5) T3 = (7, 1.25)
Frage: „Ist T3 nach RMS einplanbar?“
Iterationsgleichung:
t (l+1) = 1.25 +
(l) t (l)
t
· 1+
· 1.5
3
5
Iteration:
t (0)
t (1)
t (2)
t (3)
= te,3 = 1.25
1.25
1.25
= 1.25 +
+
· 1.5 = 3.75
3
5
3.75
3.75
= 1.25 +
+
· 1.5 = 4.75
3
5
4.75
4.75
= 1.25 +
+
· 1.5 = 4.75
3
5
t (3) = t (2) = 4.75 < tp,3 = 7
RMS schedulbar.
T3 zusammen mit T1 und T2 nach
91 / 103
Einplanungstext für RMS nach Liu/Layland
Satz: Für eine Menge von n unabhängigen periodischen Tasks
kann nach RMS ein brauchbarer Schedule erzeugt werden,
wenn die Auslastung u die folgende (hinreichende, nicht
notwendige) Bedingung erfüllt7 :
√
1
n
2−1
.
(9)
u ≤ uRM (n) = n 2 n − 1 = n
Bemerkungen:
I
I
Funktion fällt monoton mit steigendem n
lim uRM (n) = ln(2) ≈ 0.693
n→∞
I
pessimistisches Verfahren: falls Bedingung nicht erfüllt, ist
trotzdem noch gültiger Schedule möglich (Voraussetzung:
u < 1)
I
(viel) einfacher als ratenmonotone Analyse
7
C. L. Liu und James W. Layland. “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time
Environment”. In: Journal of the ACM 20.1 (Jan. 1973), S. 46–61.
92 / 103
Verlauf der Funktion uRM (n)
1
0.95
0.9
0.85
0.8
0.75
0.7
0.65
0.6
2
4
6
8
10
12
14
16
18
20
93 / 103
Beispiel
Beispiel: T1 = (3, 1)
T2 = (5, 1.5)
T3 = (7, 1.25)
1 1.5 1.25
+
+
≈ 0.812
3 5
7
√
3
uRM (3) = 3
2 − 1 ≈ 0.800
u =
u > uRM (3)
d.h., Einplanungstest 2 weist die Taskmenge als nicht planbar
zurück, es existiert jedoch ein Plan (vgl. vorangegangenes
Beispiel).
94 / 103
Optimalität von RMS
Satz: Unter den Verfahren mit fester Priorität ist RMS optimal.
Beweis: Bereits bewiesen: Antwortzeit einer Task maximal zu
ihrem kritischen Zeitpunkt.
Idee:
I
Betrachtung zweiter Tasks T1 , T2
I
zu zeigen: wenn es für das Taskpaar einen
nicht-RMS-basierten gültigen Schedule gibt, dann gibt es
für dieses Taskpaar auch stets einen gültigen Schedule
nach RMS.
I
danach Generalisierung auf n Tasks
95 / 103
Beweis, Teil II
I
T = {T1 , T2 } mit tp,1 < tp,2
I
wenn es einen gültigen (non-RMS-)-Schedule gibt, dann gilt
offenbar:
Prio(T1 ) < Prio(T2 )
te,1 + te,2 ≤ tp,1
te,2 ≤ tp,1 − te,1
Prio
T2
also
(10)
te,2
t
tp,2
te,1
T1
tp,1
2tp,1
3tp,1
t
(Im Worst Case muss in der Periode von T1 noch Platz sein für einen ganzen Job von T2 , da letzterer nach
Vereinbarung die höhere Priorität hat.)
96 / 103
Beweis, Teil II
I
Es gelte nun Prio(T1 ) > Prio(T2 ).
I
folgende Bedingung ist für Brauchbarkeit des Schedule
hinreichend:
tp,2
kte,1 + (tp,2 − ktp,1 ) + te,2 ≤ tp,2 mit k =
tp,1
Prio
T1
tp,2 − ktp,1
k -mal
te,1
te,1
te,1
tp,1
T2
0
te,2
(11)
2tp,1
3tp,1
t
00
te,2
tp,2
t
0
00
te,2 = te,2
+ te,2
97 / 103
Beweis, Teil III
Umgestellt nach te,2 ergibt sich:
te,2 ≤ k (tp,1 − te,1 )
Diese Bedingung folgt8 unmittelbar aus Ungleichung 10:
te,2 ≤ tp,1 − te,1 ≤ k (tp,1 − te,1 )
(12)
, da k ≥ 1 und tp,1 ≥ te,1 .
Damit ist gezeigt, dass, wenn zwei Tasks T1 , T2 nach einem
non-RMS-Verfahren planbar sind, diese auch stets nach RMS
planbar sind, also ihre Priorität ausgetauscht werden kann.
Bei einer Menge von mehr als 2 Tasks muss diese Vertauschung
entsprechend permutiert werden. RMS ist damit unter den Verfahren
mit fester Priorität optimal.
8
überraschenderweise!
98 / 103
Generelle Optimalität von RMS
Satz: Ratenmonotones Scheduling ist nicht generell optimal.
Beweisidee: Angabe einer Taskmenge, für die mittels RMS
kein brauchbarer Schedule erzeugt werden kann und
Konstruktion eines brauchbaren Schedules.
I
T = {T1 (8, 4), T2 (12, 5)}
I
Beide Einplanungstests schlagen fehl.
T1
DL
verletzt!
T2
0
2
4
6
8
10
12
14
16
18
20
22
24
t
Abbildung: (ungültiger) Schedule nach RMS
99 / 103
Generelle Optimalität von RMS
Durch Verzögerung von T1 kann jedoch einen brauchbarer
Schedule konstruiert werden.
Verzögerung
T1
T2
0
2
4
6
8
10
12
14
16
18
20
22
24
t
Abbildung: (gültiger) Schedule
⇒ RMS ist nicht optimal
Der konstruierte Schedule kann durch kein prioritätsbasiertes
Verfahren mit statischen Prioritäten erzeugt werden!
100 / 103
Was haben wir gelernt?
I
Klassifizierung von Schedulingverfahren (On-Line vs.
Off-Line, zeit- vs. ereignisgesteuert, statische vs.
dynamische Prioritäten, präemptiv vs. kooperativ)
I
Bsp. für Off-Line: Scheduling mittels Network Flows,
Algorithmus von Ford und Fulkerson
prioritätsbasiertes On-Line-Scheduling:
I
I
I
I
I
statische Prioritäten: RMS
dynamische Prioritäten (auf Taskebene): EDF
weniger wichtig: DMS, LST
3 verschiedene Einplanungstests für RMS
I
I
I
Für einfach periodische Taskmengen
Test nach Liu/Layland
101 / 103
Ausblick
Multiprozessorscheduling!
I
partitionierende vs. globale Verfahren
I
weitere Einplanungstests für RMS
102 / 103
Literaturempfehlungen
I
Jane W. S. Liu. Real-Time Systems. Prentice Hall, 2000,
Kapitel 5 und 6
I
Dirk Müller. “Schedulability Tests for Real-Time Uni- and
Multiprocessor Systems”. Habilitationsschrift. Chemnitz
University of Technology, 2013
103 / 103

Teil 3: Scheduling

Transcription

Documents pareils

The Green Dot for your packaging - Deutsch

Kein Job wie jeder andere: Busfahrer (w/m)

EMP: The Emotional Music Player

Ferienjobs – Tipps für Schüler/innen

Übung zur Vorlesung Echtzeitsysteme im WS11/12

markt.de hilft bei der Suche nach dem Ferienjob

cs243: Datenbanken FS 2014

Maurermeister/Fliesenleger sucht Job/Aushilfe. R 01 57

eXplorist XL

Cordless MouseMan Wheel (USB/PS2)Set-up - MA