Scheduling - Professur Betriebssysteme

Transcription

Scheduling - Professur Betriebssysteme
Echtzeitsysteme – Scheduling
3.1 Einführung
Echtzeitsysteme
Sommersemester 2016
3.1 Einführung
Scheduling
Echtzeitsysteme
Scheduling
Aufteilung von Ressourcen an konkurrierende Verbraucher“.
”
3. Kapitel
▸
Scheduling
▸
Wichtigste Ressource: CPU
Andere mögliche Ressourcen:
▸
Prof. Matthias Werner
▸
Professur Betriebssysteme
▸
▸
Speicher
Festplatte
Busse
...
SoSe 2016 ⋅ M. Werner
Echtzeitsysteme – Scheduling
3.1 Einführung
2 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.1 Einführung
P2
P3
...
P1
...
Noch Wiederholung: Prozess als virtueller Prozessor
...
Wiederholung: Prozessesbegriff
▸
Sequenz von Anweisungen
▸
Benötigt Betriebsmittel (Ressourcen), z.B. Speicher, Geräte, Dateien usw.
Besitzt Zustand
▸
virtuelle
CPU
Px
Mikrozustand: Gesamtheit aller dem Prozess gehörenden Betriebsmittel(zustände)
(inkl. Prozessorzustand)
Makrozustand: M ∈ {bereit, aktiv, wartend}
Transformation
...
▸
...
Identifikator
...
virtuelle
CPU
▸
▸
virtuelle
CPU
...
Abstraktion: Programm in Abarbeitung“
”
▸
...
Prozess
Mehrere Prozesse können gleichzeitig existieren á parallele oder nebenläufige
Prozesse
reale
CPU
SoSe 2016 ⋅ M. Werner
3 / 64
osg.informatik.tu-chemnitz.de
SoSe 2016 ⋅ M. Werner
4 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.1 Einführung
Echtzeitsysteme – Scheduling
3.1 Einführung
Noch Wiederholung: Prozesszustände
Ziele
▸
aktiv Prozess wird abgearbeitet (besitzt alle zum Fortschritt nötigen
Ressourcen)
Klassische Scheduling-Ziele sind:
▸
▸
▸
bereit Prozess besitzt alle zum Fortschritt nötigen (passiven) 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
▸
▸
▸
Ziele können sich widersprechen!
▸
Typische Scheduling-Strategien (Nicht-Echtzeit):
(nicht existent) Prozess wurde beendet oder noch nicht gestartet
▸
▸
▸
(weitere Subzustände denkbar, hier nicht weiter betrachtet)
▸
▸
SoSe 2016 ⋅ M. Werner
5 / 64
6 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.1 Einführung
Ziele in Echtzeitsystemen
Task und Job
In Echtzeitsystemen: Berücksichtigung von Zeitbedingungen:
▸
▸
▸
▸
▸
First come first serve (FCFS)
Shortest job first (SJF)
Round robin (RR)
Smallest response ratio (SRR)
...
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.1 Einführung
▸
Hohe Auslastung des Systems
Fairness
Kein Verhungern (lang anhaltende Verdrängung einzelner Tasks)
Antwortverhalten (kurze Reaktionszeit)
Hoher Durchsatz (abgearbeitete Prozesse pro Zeiteinheit)
Minimierung der Anzahl verpasster Deadlines
Minimierung der maximalen Verzögerung
Maximierung der Kostenfunktionen
...
▸
Es wird zwischen Tasks und Jobs unterschieden:
Job: Schedulingsicht á Einheit, die geplant und ausgeführt wird
Task: Programmierersicht á Einheit, die eine Aufgabe löst bzw. eine Funktion
ausübt; kann eine Menge von Jobs erzeugen
▸
Im periodischen Taskmodell (Erklärung folgt) werden Jobs i.d.R. als
Taskinstanzen aufgefasst
▸
Fall eine Task genau einem Job entspricht, werden die Begriffe synonym
gebraucht
Wieder können sich Ziele widersprechen
T1
D2
D1
T3
T2
D1
SoSe 2016 ⋅ M. Werner
T3
T2
T4
T4
D3
T5
T5
D2
D3
7 / 64
D5
D4
T1
D4
D5
osg.informatik.tu-chemnitz.de
SoSe 2016 ⋅ M. Werner
8 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.1 Einführung
Echtzeitsysteme – Scheduling
3.1 Einführung
Problem des Echtzeitschedulings
Aspekte
▸
▸
▸
Konkretisieren das Ziel:
▸
▸
Gegeben sei eine Menge von Jobs
Gesucht wird ein Ausführungsplan (Schedule), der es ermöglicht, dass alle Jobs
immer ihre Zeitbedingungen (meist: Deadline) einhalten
á Schedule ist ausführbar (auch: brauchbar, feasible)
▸
▸
▸
Allgemein: Problem ist N P
▸
▸
Unter bestimmten Einschränkungen gibt es jedoch einfache Algorithmen, die das
Problem lösen
▸
▸
▸
SoSe 2016 ⋅ M. Werner
9 / 64
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.1 Einführung
10 / 64
Echtzeit-Scheduling
Allgemeine Parameter eines Jobs
▸
release time tr oder r: Zeitpunkt, ab dem ein Job ausgeführt werden kann
▸
starting time ts : Zeitpunkt des Starts eines Jobs
▸
completion time tc : Zeitpunkt der Komplettierung eines Jobs
▸
deadline td oder D: Zeitpunkt, bis zu dem ein Job beendet sein muss (absolut oder relativ)
Job ist aktiv
tr
on-line
ts
Timeline
ohne Prio.
Round Robin
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.1 Einführung
Häufige Schedulingverfahren in Echtzeitscheduling
off-line
Zeitpunkt des Schedulings ( Wann wird geplant?“)
”
á on-line oder off-line
Unterbrechbarkeit ( Kann einem Prozess der Prozessor entzogen werden?“)
”
á Wir nehmen i.d.R. an, dass Prozesse unterbrochen werden können
Zeit- oder ereignissgesteuert
á betrachten beides
Nutzung von Prioritäten (keine, fest, variabel)
á betrachten alle Varianten
Anzahl der Prozessoren
á 1 (bis auf weiters)
Migration
á keine
Taskmodell
á periodisches Taskmodell
Berücksichtigung von Abhängigkeiten
á nächstes Kapitel
statische Prio.
RMS
DMS
tc
td
te
dynamische Prio.
EDF
LST
tresp
Zeitspannen
deutsche Bezeichnung
Symbol
execution time
response time
laxity1
Ausführungszeit
Antwortzeit
Zeitfenster
te oder e
tresp
ttard
= tc − tr
= td − tc
1 auch: slack time oder (insbesondere wenn negativ): Verspätung (tardiness)
SoSe 2016 ⋅ M. Werner
11 / 64
osg.informatik.tu-chemnitz.de
SoSe 2016 ⋅ M. Werner
12 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.1 Einführung
Echtzeitsysteme – Scheduling
3.1 Einführung
Scheduling für periodische Tasks
▸
Modell:
▸
▸
▸
Scheduling für periodische Tasks (Forts.)
Standardzyklus: Sensor lesen – Wert verarbeiten – Effektor steuern (á Kapitel 2)
Mehrere Standardzyklen sind durch einen Prozessor zu bedienen
▸
Annahmen (Standardannahmen):
▸
▸
▸
▸
▸
Es werden meist drei verschiedene Arten von Tasks unterschieden:
▸
Alle Tasks treten periodisch auf (Jobs á Taskinstanzen)
Jeder Job ist stets unterbrechbar, und die Unterbrechungskosten sind
vernachlässigbar
Jobs sind voneinander unabhängig, alle Ressourcen sind hinreichend vorhanden
Nur ein Prozessor
Deadline = Periodenlänge
▸
▸
periodisch: periodische Aktivierung der Jobs einer Task
aperiodisch: nichtperiodische Aktivierung der Jobs einer Task; die
Zwischenankunftszeit zweier Jobs ist nicht nach unten beschränkt
sporadisch: nichtperiodische Aktivierung der Jobs einer Task; maximale
Ankunftsrate der Jobs ist beschränkt
Merke
Die Standardannahmen sind keine Annahmen über das Schedulingverfahren.
SoSe 2016 ⋅ M. Werner
13 / 64
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.1 Einführung
Last
Periodische Tasks werden häufig als Tupel notiert:
▸
▸
▸
Tasks erzeugen auf einen Prozessor eine gewisse Last (load, utilization)
Lastbegriff ist schwierig im Nicht-Echtzeit-Bereich
Unter Standardannahmen einfache Definition:
Ti (φi , Pi , ei , Di )
▸
Bedeutung der Parameter, jeweils der i. Task:
▸
▸
▸
▸
φi : Phase (um versetzte Startzeiten zu erlauben)
Pi : Periode
ei : Bedienzeit
Di : Deadline
▸
Da meist φi = 0 und Di = Pi wird deren Angabe häufig fortgelassen
▸
Jobs erben“ Parameter ihrer Task
”
Analoge Beschreibung für sporadische Tasks, aber PeriodePi ist minimale
Zwischenankunftszeit (minimal interarrival time) der Jobs
SoSe 2016 ⋅ M. Werner
15 / 64
ei
Pi
Last einer Task:
Ui =
Gesamtlast einer Taskmenge:
U = ∑ Ui = ∑ Peii
i
▸
▸
▸
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.1 Einführung
Beschreibung periodischer Tasks
▸
14 / 64
osg.informatik.tu-chemnitz.de
i
ei : Ausführungszeit
Pi : Periode
▸
Unter Standardannahmen: Pi = Di
▸
Eine Last von 1 bedeutet, dass der Prozessor niemals unbeschäftigt (idle) ist
▸
Merke: Lasten > 1 sind nicht ausführbar
SoSe 2016 ⋅ M. Werner
16 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.1 Einführung
Echtzeitsysteme – Scheduling
3.1 Einführung
Konzept: Kritischer Zeitpunkt und kritisches Intervall
▸
Ein kritischer Zeitpunkt ist die Ankunftszeit eines Jobs, bei dem er die längste
Antwortzeit hat
▸
Ein kritisches Intervall ist die Zeit wischen dem kritischen Zeitpunkt eines Jobs
und der Beendigung der entsprechenden Jobausführung
Konzept: Schwere Planbarkeit
Eine Menge T ist von einem Schedulingverfahren S schwer zu planen ((most)
difficult/hard to schedule), wenn jede Vergrößerung der Rechenzeit irgendeiner Task
dazu führt, dass T nicht mehr ausführbar ist
▸
▸
Merke
Für die gleiche Taskmenge kann der gleiche Job bei verschiedenen
Schedulingverfahren unterschiedliche kritische Zeitpunkte und Intervalle haben
SoSe 2016 ⋅ M. Werner
17 / 64
▸
Auch in der Literatur: Taskmenge lastet Processor vollständig aus“ (fully utilize)
”
Eine volle Auslastung bedeutet nicht, dass der Prozessor niemals unbeschäftigt
(idle) ist, oder dass die Last 1 ist
Merke: Wenn eine Taskmenge T für ein Schedulingverfahren S schwer planbar
ist, muss dies nicht für T bei einem anderen Schedulingverfahren S gelten
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
18 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
3.2 Einfache prioritätsbasierte Verfahren
Prioritätsbasierte Verfahren
Einprozessorsysteme
Klassische Verfahren für Einprozessorsysteme, die Prioritäten nutzen, sind u.a.:
▸
Rate Monotonic Scheduling (RMS) (LIU und LAYLAND)
▸
Earliest Deadline First (EDF) ( LIU und LAYLAND)
▸
Least Slack-Time First (LST, auch Minimum Laxity First, MLF) (LEUNG und
WHITEHEAD / MOK)
Alle prioritätsbasierten Verfahren haben gemeinsam, dass jedem Job eine Prioriät
zugewiesen wird
Es werden zwei Klassen von prioritätenbasierten Schedulingverfahren unterschieden:
▸
Verfahren mit festen Prioritäten (fixed priority scheduling) á Prioritäten werden a
priori festgelegt, für jeden Job einer Task stets gleich
▸
Verfahren mit variablen Prioritäten (variable priority scheduling) á Prioritäten der
Jobs können sich ändern
Verfahren mit festen Prioritäten sind leichter zu implementieren
Bei den genannten Verfahren wird immer der Job mit der augenblicklich höchsten
Prioriät ausgeführt
SoSe 2016 ⋅ M. Werner
19 / 64
osg.informatik.tu-chemnitz.de
SoSe 2016 ⋅ M. Werner
20 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Earliest Deadline First (EDF)
Beispiel
▸
2 (periodische) Tasks T1 (2, 0.9) und T2 (5, 2.3)
▸
(Notation: Ti (tp,i , te,i ))
J1,1
J1,2
J1,3
J1,4
J1,5
...
▸
EDF arbeitet mit variablen Prioritäten
▸
Jeder Job erhält eine Priorität entsprechend ihrer Deadline: Ein Job mit einer
kürzeren Deadline hat stets eine höhere Priorität als ein Job mit einer längeren
Deadline
T2
Eine laufbereiter Job mit höherer Priorität unterbricht stets einen Job niederer
Priorität
▸
t=0: td,1 = 2, td,2 = 5 ⇒ J1,1 abgearbeitet
▸
t=2: td,1 = 4, td,2 = 5 ⇒ J1,2 abgearbeitet
▸
t=4: td,1 = 6, td,2 = 5 ⇒ J2,1 abgearbeitet
▸
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
▸
SoSe 2016 ⋅ M. Werner
21 / 64
T1
0
1
2
3
J2,1a
0
1
4
J2,1b
2
3
Echtzeitsysteme – Scheduling
3.2 Prioritäten
6
7
J2,2a
4
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
5
5
8
9
7
8
22 / 64
t
...
J2,2b
6
10
9
10
t
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Optimalität von EDF
Beweisskizze für Theorem 3.1
Überführung eines Nicht-EDF-Schedules in ein EDF-Schedule
▸
Austausch der Tasks innerhalb ihrer bisherigen Timeslots (nur Zeitanteile nach
der Taskankunft von Ti )
Theorem 3.1 (Optimalität von EDF)
Tk
Ti
Unter den Standardannahmen kann EDF für die Taskmenge T genau dann einen
ausführbaren Schedule erzeugen, wenn irgendein ausführbarer Schedule für T existiert.
rk
Anders gesagt: Wenn irgendein Schedulingverfahren S unter den
Standardbedingungen für T einen ausführbaren Schedule erzeugen kann, dann kann
EDF das auch
Dk Di
Tk
▸
Wiederholen für alle Tasks
▸
Verschieben der Idle-Zeiten
Tk
Tk
Tk
SoSe 2016 ⋅ M. Werner
23 / 64
osg.informatik.tu-chemnitz.de
SoSe 2016 ⋅ M. Werner
24 / 64
Ti
Ti
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Schedulingkriterium für EDF
Rate Monotonic Scheduling (RMS)
Problem: Gibt es ein Kriterium, welches feststellt, ob eine Taskmenge T unter EDF
ausführbar ist, ohne dass das Verfahren vollzogen wird?
Hinreichende und notwendige Schedulingbedingung für EDF:
▸
RMS arbeitet mit festen Prioritäten
Theorem 3.2 (EDF-Schedulingbedingung)
▸
Ein Menge T von n Tasks ist mit EDF unter den Standardannahmen genau dann
ausführbar, wenn
n
ei
UT = ∑
≤1
P
i=1 i
Task (alle Jobs) erhält eine Priorität reziprok zu ihrer Periode (Deadline) á
(Ankunfts-)Rate
▸
Ein Job (laufbereite Tasksinstanz) mit höherer Priorität unterbricht stets ein Job
niederer Priorität
Mit anderen Worten: EDF ist immer erfolgreich, wenn die Last der Taskmenge
kleiner/gleich 1 ist
SoSe 2016 ⋅ M. Werner
25 / 64
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
RMS vs. EDF
▸
Taskset: T1 (4, 1), T2 (5, 2), T3 (20, 5)
▸
T3
...
T2
...
T1
...
J11
0
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Beispiel
▸
26 / 64
J21
J31 J12
J22
2
4
6
SoSe 2016 ⋅ M. Werner
J32 J13 J33
8
J23
10
27 / 64
J14
12
J34
14
J24 J15 J25
16
18
′
J11
20
▸
▸
Task 1: P1 = 6, e1 = 3
Task 2: P2 = 10, e2 = 5
Task 1 hat höhere RMS-Priorität
Ausführbar mit EDF
M
...
t
osg.informatik.tu-chemnitz.de
SoSe 2016 ⋅ M. Werner
28 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Optimalität von RMS
Beweis von Theorem 3.3
▸
M sei Fixed-Priority-Verfahren, das ein Taskmenge T ausführbar plant; der
entstehende Schedule sei S
▸
Überführung von S
▸
In S gelte pj = pi + 1 bei Pj > Pi (px bezeichne Prioritäten)
Austausch von pi und pj lässt den Schedule ausführbar:
Theorem 3.3 (Optimalität von RMS)
Unter den Standardannahmen kann RMS für die Taskmenge T genau dann einen
ausführbaren Schedule erzeugen, wenn irgendein anderes Fixed-prioriy-Verfahren einen
ausführbaren Schedule für T findet.
▸
▸
Insgesamt ist RMS nicht optimal, da es Taskmengen geben kann, die mit RMS nicht
ausführbar sind, wohl aber mit anderen Schedulingverfahren M
▸
Aber: M kann kein Fixed-Priority-Verfahren sein
SoSe 2016 ⋅ M. Werner
29 / 64
▸
Fall 2: J1 wird nicht zu r2 ausgeführt, d.h. 0 < r1 ≤ P2 − e2
Der kritische Augenblick ist für jeden Job in RMS, wenn er zeitgleich mit allen
höherpriorisierten Jobs ankommt.
Beweis für zwei Tasks.
Sei r2 = 0
osg.informatik.tu-chemnitz.de
Kritischer Zeitpunkt bei RMS (Forts.)
Theorem 3.4 (Kritischer Zeitpunkt bei RMS)
▸
30 / 64
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Kritischer Zeitpunkt bei RMS
Sei T: T1 , T2 mit P1 < P2 .
Wiederholen, bis S zum RMS-Schedule geworden ist
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
▸
Nur Stellen interessant, an denen Ji von Jj an Ausführung gehindert wird.
Da Deadline von Jj offensichtlich nach Deadline von Ji , können Taskstückchen
vertauscht werden
▸
1
Dann ist tc,2 = e2 + ⌈ Pe21−r
⌉ e1
−e1
▸
Alles außer r1 ist konstant
▸
tc,2 ist am größten, wenn r1 am kleinsten ist
▸
⇒ r1 = 0.
Ähnliche Argumentation bei mehr als 2 Jobs.
Fall 1: J1 wird zu r2 = 0 ausgeführt, d.h., −e1 < r1 ≤ 0.
▸
2
Dann ist tc,2 = e2 + (e1 − ∣r1 ∣) + (⌈ P1e−e
⌉ − 1) e1
1
▸
Alles außer r1 ist konstant: tc,2 = C − ∣r1 ∣
▸
Dies ist am größten, wenn ∣r1 ∣ am kleinsten ist ⇒ r1 = 0.
SoSe 2016 ⋅ M. Werner
31 / 64
Verallgemeinerung
Für Festprioritätsverfahren genügt den Fall zu betrachten, wenn alle Jobs aller Tasks
gleichzeitig ankommen.
osg.informatik.tu-chemnitz.de
SoSe 2016 ⋅ M. Werner
32 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Schedulingkriterium für RMS
▸
Grenzwert für Lastschranke
Wieder: Gibt es ein Kriterium, welches feststellt, ob eine Taskmenge T unter RMS
ausführbar ist, ohne dass das Verfahren vollzogen wird?
1
U∞
Theorem 3.5 (Schedulingkriterium für RMS)
=
lim n(2 n − 1)
n→∞
1
Ein Menge T von n Tasks ist mit RMS unter den Standardbedingungen immer dann
ausführbar, wenn
=
lim
2n − 1
1
n
n→∞
1
n
=
U ≤ n(2 − 1)
1
d
(2 n − 1)
dn
lim
d 1
n→∞
( )
dn n
1
▸
▸
Untere Schranke der obere Grenze
Hinreichend, aber nicht notwendig
n
U
1
1, 0
2
0, 828
SoSe 2016 ⋅ M. Werner
=
= ln 2
5
0, 743
10
0, 718
50
0, 698
33 / 64
U∞
100
0, 695
▸
Tatsächliche Grenze liegt meist viel besser
Statistischer Mittelwert liegt etwa bei 0,88
▸
Genauerer Schedulingtests mit Analyse der Zeitanforderungen (Time-Demand
Analysis)
▸
Time-Demand Analysis (TDA) wurde von LEHOCZKY, SHA und DING 1989
[LSD89]
vorgestellt:
TDA kann als Test für alle Fixed-Priority-Schedulingverfahren für periodische
Taskmengen angewandt werden, wenn die Deadline nicht größer als die Periode
ist.
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Zeitanforderungsfunktion
Die Zeitanforderungsfunktion (time demand function wi (t)) gibt die angeforderte
CPU-Zeit der Jobs einer Task Ti bis zum Zeitpunkt t an
▸
▸
34 / 64
Echtzeitsysteme – Scheduling
3.2 Prioritäten
RMS-Theorem (Theorem 3.5) gibt nur eine Schranke an
▸
≈ 0, 693
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Zeitforderungsanalyse
▸
− n12
n→∞
Echtzeitsysteme – Scheduling
3.2 Prioritäten
▸
lim
2 n ⋅ ln 2 ⋅ − n12
35 / 64
osg.informatik.tu-chemnitz.de
▸
Dabei wird die Verdrängung durch höherpriore Tasks berücksichtigt
wi (t) ist wie folgt definiert:
i−1
wi (t) = ei + ∑ ⌈
k=1
▸
t
⌉ ⋅ ek
Pk
Tasks sind nach Prioritäten geordnet, T1 hat die höchste Priorität
SoSe 2016 ⋅ M. Werner
36 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Schedulingbedingung nach TDA
Iterationsverfahren
▸
Im Theorem 3.6 kommt in der Ungleichung wi (t) ≤ t auf beiden Seiten t vor
á Weg zur Bestimmung von t gesucht.
▸ Lösung über ein Iterationsverfahren
Theorem 3.6 (TDA-Theorem)
Eine Menge T von unterbrechbaren, periodischen und unabhängigen Tasks ist mit einem
Fixed-Priority-Verfahren S ausführbar, wenn
▸
∀i, ∃t, 0 < t ≤ min(Di , Pi ), wi (t) ≤ t
Mit anderen Worten: Für jede Task muss es einen Zeitpunkt in seiner Periode oder
Deadline geben, zu dem die ihre Zeitanforderung nicht höher ist, als die verstrichene
Zeit.
▸
(0)
Startwert: ti
▸
Iteration:
▸
Abbruch bei:
(l)
▸
ti
▸
ti
= ei
(l+1)
ti
(l)
= w(ti )
> Pi á Task ist nicht ausführbar
(l+1)
= ti
(l)
≤ Pi á Task ist ausführbar
Anmerkungen
i
▸
▸
Der Startwert ist egal, aber der kleinste sinnvolle Wert ist ∑ ej (Tasks sind nach
▸
Prioritäten geordnet)
Im der Originalveröffentlichung [LSD89] werden zuerst die Änderungspunkte für
wi (t) berechnet und dort einzeln die Ungleichung geprüft
j=1
Unter den Standardannahmen gilt: Di = Pi á keine Minimumbildung nötig
SoSe 2016 ⋅ M. Werner
37 / 64
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Graphische Lösung
▸
3 Tasks: T1 = (3, 1)
▸
Iteration für T3 :
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Beispiel für Iterationsverfahren
▸
38 / 64
Statt des Iterationsverfahrens kann die Analyse auch grafisch erfolgen
440
T2 = (5, 1.5)
T3 = (7, 1.25)
wi(t)
420
400
380
360
(0)
t3
= te,3 = 1.25
1.25
1.25
⌉+⌈
⌉ ⋅ 1.5 = 3.75
t(1) = 1.25 + ⌈
3
5
3.75
3.75
(2)
t3 = 1.25 + ⌈
⌉+⌈
⌉ ⋅ 1.5 = 4.75
3
5
4.75
4.75
(3)
t3 = 1.25 + ⌈
⌉+⌈
⌉ ⋅ 1.5 = 4.75
3
5
(3)
▸ t
3
=
(2)
t3
340
320
T1
T2
T3
T4
ei
20
30
80
100
Pi
100
150
210
400
300
280
T4
260
240
220
200
180
T3
160
140
120
100
= 4.75 < P3 = 7 á T3 ist ausführbar
T2
80
60
40
20
T1
t
0
50
SoSe 2016 ⋅ M. Werner
39 / 64
osg.informatik.tu-chemnitz.de
SoSe 2016 ⋅ M. Werner
100
40 / 64
150
200
250
300
350
400
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Variationen von RMS
Harmonisches RMS
▸
Idee: Einschränkung – nicht mehr alle Taskmengen sind zugelassen
▸
RMS ist eines der am häufigsten genutzten Schedulingverfahren
Definition 3.7 (Harmonische Taskmengen)
▸
Es existieren Variationen, die die Leistungsfähigkeit (in unterschiedlichen
Parametern) verbessern
Betrachten hier:
Eine Menge von Tasks T nennt man einfach periodisch oder harmonisch, wenn für
jedes Paar von Tasks Ti und Tj mit Pi ≤ Pj gilt, dass Pj ein ganzzahliges Vielfache
von Pi ist, also
Pj
= k, k ∈ G
∀i, j, Pj ≥ Pi ,
Pi
▸
▸
▸
Harmonisches RMS
DMS: Deadline Monotonic Scheduling
▸
SoSe 2016 ⋅ M. Werner
41 / 64
Ein RMS, das ausschließlich mit einfach periodischen Taskmengen benutzt wird,
nennt man harmonisches RMS
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Theorem 3.8
Eine harmonische Taskmenge T ist unter RMS genau dann ausführbar, wenn
U =∑
T
ei
≤1
Pi
Deadline Monotonic Scheduling
▸
Idee: Erweiterung – Deadline ist nicht immer Periode
▸
Deadline Monotonic Scheduling: Prioritäten reziprok zu periodischer relativer
Deadline [Aud+93]
▸
∀i, Di = Pi á DMS wird zu RMS
▸
Hinreichend und notwendig
▸
Beweis folgt aus TDA á Übung
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Schedulebarkeit von harmonischen Taskmengen
▸
42 / 64
▸
▸
43 / 64
osg.informatik.tu-chemnitz.de
Hinreichend: ∀i, Di = c ⋅ Pi , c = const
∃i, Di ≠ Pi á DMS ist besser als RMS
D.h. DMS findet u.U. ausführbaren Schedule, wenn RMS dies nicht kann
SoSe 2016 ⋅ M. Werner
44 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.2 Prioritäten
Echtzeitsysteme – Scheduling
3.2 Prioritäten
RMS vs. DMS: Beispiel
▸
Least Slacktime First
3 Tasks,
Ti (tφ,i , Pi , ei , Di ) ∶ T1 (50, 50, 25, 100), T2 (0, 62.5, 10, 20), T3 (0, 125, 25, 50)
▸
J1,2
T1
0
▸
▸
50
62,5
85
▸
125
100
0
72.5
50
135
100
185
150
J2,3
DMS: T2
10
Es gibt noch eine Reihe weiterer prioritätsbasierter Verfahren
Beispiel: Least Slacktime First (LSF)
200
225
250
t
▸
▸
197.5
150
250
200
Auch genannt: minimum laxity first (MLF)
Dynamisch, kürzere Slacktime = höhere Priorität
(Unter Standardbedingungen) gleichfähig wie EDF
t
Slacktime
Bedienzeit
J2,3
T3
35
0
50
160
100
150
200
250
t
Task T
▸
250
...
t
200
250
t
200
250
t
RMS: T1
0
50
75
100
125
150
175
200
225
t
Startzeit
Ankunftszeit
T2
0
10
50
85
100
135
197.5
150
Deadline verletzt!
T3
0
35
50
100
SoSe 2016 ⋅ M. Werner
150
Deadline verletzt!
45 / 64
▸
Deadline
Unpraktisch (warum?) und deshalb hier nicht relevant
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
46 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
3.3 Zeitgesteuerte Verfahren
Ad-hoc-Beispiel
Timeline Scheduling
▸
4 periodische Tasks Ti (Pi , ei ):
▸
▸
Bisher waren alle Verfahren online-Verfahren
▸
Häufig kommen auch offline-Verfahren vor
▸
Betrachten hier: Timeline Scheduling (häufig auch einfach Cyclic Scheduling oder
Cyclic Executive Scheduling genannt)
Grundsätzliche Idee:
▸
▸
▸
▸
▸
▸
▸
Periodisches Taskmodell, Taskmenge T = {T1 , . . . , Tn }
Schedule einer Menge T mit n Task besteht aus aneinandergereihten Segmenten der
Länge H = kgV(Pi ), i = 1, 2, . . . n
H wird Hyperperiode genannt
SoSe 2016 ⋅ M. Werner
47 / 64
osg.informatik.tu-chemnitz.de
T1 (4, 1)
T2 (5, 1.8)
T3 (20, 1)
T4 (20, 2)
1
4
1.8
5
1
20
▸
Last: U =
▸
Ausführbarer Schedule:
+
T1 T3 T2
+
T1
+
2
20
T4
= 0.76
T2 T1
T2 T1
T1
T2
T1 ...
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 t
▸
Die Schedulingzeitpunkte können in einer Tabelle abgelegt werden
▸
Durch Scheduling von Idlezeiten können ggf. Nichtechtzeit-Jobs eingefügt werden
SoSe 2016 ⋅ M. Werner
48 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
Implementierung
▸
▸
Minor Cycles
Tabelleneinträge: (0, T1 ) (1, T3 ) (2, T2 ) (4, T1 ) (6, T4 ) . . .
Initialisierung:
▸
Idee: Unterteilung des Schedules in gleichlange Frames (auch: minor cycles)
▸
▸
▸
1
2
3
4
5
6
7
8
Timerinterrupt auf t0 gesetzt
k=0
▸
▸
Innerhalb vom Frames werden Jobs nacheinander ausgeführt
Scheduler wird nur am Frameanfang aufgerufen á weniger Overhead
Timer mit konstanter Periode á keine Reprogrammierung
while ( true ) {
acknowledge Timerinterrupt ;
T := T[k ];
k := ++k mod(N); /* nächster Tabelleneintrag */
set Timer to nä chster Taskstart ;
execute T;
sleep ;
}
▸
H
t
49 / 64
t + 2f
t + 3f
t+H
1 Frame
Aktivierung des Schedulers nach jedem Job á ungünstig, insbesondere bei sehr
kurzen Jobs
SoSe 2016 ⋅ M. Werner
t+f
▸
Ist Jobüberlauf möglich, muss er an Framegrenze erkannt werden
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
50 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
Framegröße
Bedingung 3
▸
Job wird laufbereit a Zeiteinheiten vor dem nächsten Frame
Frame k
▸
Frage: Wie groß soll dann Framelänge f sein?
▸
Es gibt mehrere Aspekte bei von f (frame size constraints)
t+f
t
tr
1. Keine Überschreitung der Framegrenze bei Jobausführung
á f ≥ max(ei )
i
Frame k + 1
t + 2f
a
Für Pi ≠ f á a variiert
3. f sollte so klein sein, dass zwischen tr und td jedes Jobs mindestens ein kompletter
Frame liegt
á nähere Betrachtung
folglich:
Minimaler Abstand tr − t (falls irgendwann tr = t galt):
51 / 64
osg.informatik.tu-chemnitz.de
a+f ≤D
(1)
tr − t ≥ ggT(f, P )
(2)
f − ggT(f, P ) + f ≤ D
eingesetzt in (1):
SoSe 2016 ⋅ M. Werner
tr + P
a ≤ f − ggT(f, P )
2f − ggT (f, Pi ) ≤ td,i
SoSe 2016 ⋅ M. Werner
t + 3f
tr + D
Es muss gelten:
2. Minimierung der Schedullänge
á f sollte ganzzahliger Teiler der Hyperperiode H sein, H = kgV(Pi )
Frame k + 2
52 / 64
∀i, 1 ≤ i ≤ n
(3)
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
Beispiel
▸
Job Slicing
3 Periodische Tasks:
i
1
2
3
▸
Pi
15
20
22
Di
14
26
22
ei
1
2
3
▸
Betrachten folgendes Beispiel: T1 (1, 4), T2 (2, 5) und T (5, 20)
▸
Laut Constraint 1: f ≥ 5, aber laut Constraint 3: f ≤ 4
á Problem
▸
Lösung: Zerlegung von T3 in J3,1 (1, 20), J3,2 (3, 20) und J3,3 (1, 20) á
Jobslicing (manchmal auch: Time Slicing)
▸
Constraints:
1. f ≥ 3
2. f ∈ {2, 4, 5, 10, 20}
3. f ≤ 4
J3,1
Welches sind geeignete Framegrößen?
▸
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
▸
0
▸
53 / 64
osg.informatik.tu-chemnitz.de
▸
▸
▸
▸
▸
12
T1 T2
16
T1 ...
20 21 t
SoSe 2016 ⋅ M. Werner
54 / 64
osg.informatik.tu-chemnitz.de
1. Konstruktion des Graphen
Händisch (scharfes Hinsehen )
Round-Robin (funktioniert nur bedingt)
Branch-and-Bound (z.B. [XP90] )
Andere Suchverfahren
Rückführung auf Flussproblem in Graphen (nach [Bla87] )
▸
▸
▸
▸
für jeden Job und jedes Frame einen Knoten, zusätzlich Quelle Q und Senke S
von Q zu jedem Job Ji eine Kante mit Kapazität ei
von jedem Frame zu S eine Kante mit Kapazität f (Framegröße)
von Job zu Frame eine Kante mit Kapazität f gdw. Job in Frame abgearbeitet werden
kann (Timingconstraints)
2. Ermittlung des maximalen Flusses Φ (z.B. nach FORD UND FULKERSON)
3. Wenn Φ ≥ ∑ ei á Schedule entspricht der Abbildung von Flüssen auf Frames
Wir betrachten letzteren Ansatz:
Idee
i
Ein Job Ji kann nur in den Frames geplant werden, deren Startzeit größer oder gleich
tr,i ist und die nicht später enden als td,i .
SoSe 2016 ⋅ M. Werner
8
T1 T2
Scheduling als Fluss
Wie werden nur Jobs auf die Frames verteilt?
Verschiedene Verfahren:
▸
J3,2
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
Scheduleerstellung
▸
4
T1
Nachteil: (wieder) mehr Kontextwechsel
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
▸
J3,3
H
T1 T2
T1 T2
á f ∈ {3, 4, 5, 6}
SoSe 2016 ⋅ M. Werner
⎫
⎪
⎪
⎪
⎬ ⇒ f =4
⎪
⎪
⎪
⎭
55 / 64
osg.informatik.tu-chemnitz.de
Sonst: Kein Schedule möglich
SoSe 2016 ⋅ M. Werner
56 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
Beispiel
Beispiel (Forts.)
Frames
Jobs
▸ Zwei Tasks:
T1 (4, 3) und T2 (6, 1.5)
▸ H = 12, f = 4
á 3 Frames pro Hyperperiode
▸ Jobs in H:
▸
Jobs
J111
f1 [0, 2), f2 [2, 4), f3 [4, 6), f4 [6, 8),
f5 [8, 10), f6 [10, 12)
Dekomposition:
Frames
f1
2; 2
▸
J1,1 (0, 4, 3)
4; 3
J1,2 (4, 8, 3)
T1 → J1,1 (0, 4, 3), J1,2 (4, 8, 3)
J1,3 (8, 12, 3)
T2 → J2,1 (0, 6, 1.5),
J2,2 (6, 12, 1.5)
▸
▸ Lösung: Jobslicing, f = 2
▸ 6 Frames:
f1 [0, 4)
J1,3 (8, 12, 3)
3; 3
4; 3
f2 [4, 8)
3; 3
▸ max Fluss: Φ = 11
aber: ∑ ei = 12
4; 4
S
4; 3
1.5; 1
1.5; 1
J2,1 (0, 6, 1.5)
á Φ < ∑ ei
i
4; 3
J132 (10, 12, 1)
J121
2; 2
2; 0
2; 1
1; 1
2; 2
Q
▸ J2,1 und J2,2 bleiben unverändert
J122
f3
2; 1.5
J2,2 (6, 12, 1.5)
2; 2
2; 0.5
2; 2
1; 1
2; 2
2; 1
f4
J131
S
2; 2
2; 0.5
2; 2
J132
▸ max Fluss: Φ = 12 und ∑ ei = 12
i
f3 [8, 12)
4; 1
▸ Mit f = 4 kein Schedule möglich
▸ J1,3 (8, 12, 3) → J132 (8, 12, 2),
f2
1; 1
4; 4
i
2; 2
▸ J1,2 (4, 8, 3) → J121 (4, 8, 2), J122 (6, 8, 1)
4; 1
2; 0
2; 1
▸ J1,2 (0, 4, 3) → J111 (0, 4, 2), J112 (2, 4, 1)
3; 3
Q
J112
2; 2
2; 0.5
2; 0
1.5; 1.5
á Scheduling erfolgreich
f5
2; 2
2; 1
▸ Die Flüsse zu den Frames geben Schedule an
1.5; 1.5
J21
2; 0
2; 1
J22
SoSe 2016 ⋅ M. Werner
57 / 64
osg.informatik.tu-chemnitz.de
SoSe 2016 ⋅ M. Werner
Echtzeitsysteme – Scheduling
3.3 Zeitsteuerung
Beispiel (Forts.)
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
Anhang A: Literatur
Anhang A: Literatur
Frames
Jobs
Ergebnis:
58 / 64
f6
f1
J111
2; 2
J112
2; 0
f2
2; 1
J121
2; 2
2; 2
2; 0
2; 1
1; 1
Q
2; 1.5
J122
2; 2
1; 1
2; 2
2; 1
f4
S
2; 2
2; 0.5
1; 1
[Lui00]
Jane W. S. Lui. Real-Time Systems. Prentice Hall, 2000, Kapitel 3 – 6
[But05]
Giorgio C. Buttazzo. Hard Real-Time Computing Systems. Springer, 2005, Kapitel 4
[KS97]
C. M. Krishna und Kang G. Shin. Real-Time Systems. McGraw-Hill, 1997, Abschnitte 3.2.1
und 3.2.2
[LL73]
Chung Laung Liu und James Layland. Scheduling Algorithms for Multiprogramming in a
”
Hard Real-Time Environment“. In: Journal of ACM 20.1 (1973), S. 46–61
2; 2
2; 0.5
J131
2; 2
f3
2; 2
J132
f5
2; 2
2; 0
1.5; 1.5
2; 0.5
2; 2
2; 1
1.5; 1.5
J21
2; 0
2; 1
J22
J111
0
f1
J112 J21
2
SoSe 2016 ⋅ M. Werner
f2
f6
J21 J121 J22
J121
4
f3
J122
6
59 / 64
f4
J131
8
J132 J22 ...
f5 10
f6
12 t
osg.informatik.tu-chemnitz.de
SoSe 2016 ⋅ M. Werner
60 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
Anhang A: Literatur
Echtzeitsysteme – Scheduling
Anhang B: Flußproblem
Anhang B: Flußproblem
Literatur (Forts.)
Algorithmus von FORD und FULKERSON
[LSD89]
John P. Lehoczky, Lui Sha und Y. Ding. The Rate Monotonic Scheduling Algorithm: Exact
”
Characterization and Average Case Behavior“. In: IEEE Real-Time Systems Symposium.
1989, S. 166–171
[Aud+93]
N. Audsley u. a. Applying New Scheduling Theory to Static Priority Pre-Emptive
”
Scheduling“. In: Software Engineering Journal 8 (1993), S. 284–292
[Bla87]
Jacek Blazewicz. Selected Topics in Scheduling Theory“. In: Annals of Discrete
”
Mathematics 31 (1987), S. 1–60
SoSe 2016 ⋅ M. Werner
61 / 64
Anhang: Algorithmus von FORD und FULKERSON
▸
Nach LESTER RANDOLPH FORD JR und DELBERT RAY FULKERSON, 1956
▸
Gegeben sei ein Graph N = (V, E, q, s, c) ohne Mehrfachkanten
▸ Knoten (V ),
▸ Kanten (E),
▸ einer Quelle q ∈ V ,
▸ einer Senke s ∈ V und
▸ einer Kapazitätsfunktion c ∶ E → R+ , die jeder Kante (u, v) eine nicht-negative
reelle Zahl c(u, v) als Kapazität zuordnet
SoSe 2016 ⋅ M. Werner
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
Anhang B: Flußproblem
62 / 64
osg.informatik.tu-chemnitz.de
Echtzeitsysteme – Scheduling
Anhang B: Flußproblem
Algorithmus von FORD und FULKERSON (Forts.)
Algorithmus von FORD und FULKERSON (Forts.)
Algorithmus
1. Initialisierung
Beispiel (aus Wikipedia)
▸
▸
u
Für jeden e = (u, v) füge ein e = (v, u) ein
Flussfunktion: ∀e′ , ϕ(e′ ) = 0
q
2
3
v
u
4
Falls kein solcher P existiert á Ende
q
3. Sei m = min(c(e)). Modifiziere N :
2
▸
6
1
4. Weiter mit 2.
SoSe 2016 ⋅ M. Werner
e′ ∈(s,vi )
ϕ(e′ )
1
63 / 64
s
3
2
q
osg.informatik.tu-chemnitz.de
3
1
1
3
3
s
3
1
s
3
SoSe 2016 ⋅ M. Werner
q
1
4
1
3
q
3
1
3
3
v
u
1
3
1 2
q
1
3
1
1
s
3
v
u
1
2
v
u
3
2
u
1
1 2
v
u
v
u
q
∑
1
v
∀e = (u, v) ∈ P, c(e) ∶= c(e) − m
∀e = (u, v) ∈ P, ϕ(e′ ) = ϕ((v, u)) ∶= ϕ((v, u)) + m
Maximaler Fluss: Φ =
1
3
e∈P
▸
s
6
2. Finde gerichteten Pfad P von q nach s mit ∀e ∈ P, c(e) > 0
▸
1
4
′
s
4
q
1
4
1
3
u
1
2
v
64 / 64
s
3
s
4
4
q
2
3
1
1
v
s
5
osg.informatik.tu-chemnitz.de