4.3 aufbau von echtzeitbetriebssystemen
Post on 16-Jan-2016
23 Views
Preview:
DESCRIPTION
TRANSCRIPT
1Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.3 Aufbau von Echtzeitbetriebssystemen
Aufgaben eines Standardbetriebssystems:
• Taskverwaltung: Steuerung und Organisation der durchzuführenden Verarbeitungsprogramme (Tasks) Zuteilung des Prozessors an Tasks.
• Betriebsmittelverwaltung: Zuteilung von Betriebsmittel an Tasks:
– Speicherverwaltung: Zuteilung von Speicher– IO-Verwaltung: Zuteilung von IO-Geräten
• Interprozesskommunikation: Die Kommunikation zwischen den Tasks
• Synchronisation: Zeitliche Koordination der Tasks • Schutzmaßnahmen: Der Schutz der Betriebsmittel vor
unberechtigten Zugriffen
Zusätzliche Aufgaben eines Echtzeitbetriebssystems:
• Wahrung der Rechtzeitigkeit und Gleichzeitigkeit • Wahrung der Verfügbarkeit
2Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.3 Aufbau von Echtzeitbetriebssystemen
Realer Prozessor
Schicht 1
Schicht 2
Schicht n-1
Schicht n
M0
M1
M2
Mn-1
Mn
. . .
Anwendung
Funktionalität des Realen Prozessors
Abstrakte Maschinen Funktionalität von Mn setzt auf Funktionalität (Dienste) von Mn-1 auf
Ein Schichtenmodell für informationsverarbeitende Systeme
3Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.3 Aufbau von Echtzeitbetriebssystemen
Realer Prozessor
Gerätetreiber
Ein-/Ausgabesteuerung
Betriebsmittelverwaltung
M0
M1
M2
M4
M6
Anwendung
Speicher-verwaltung
Ein-/Ausgabe-verwaltung
M3
APIKommando-Interpreter
Taskverwaltung M5
Be
trie
bssy
ste
mke
rn
Zuteilung des Prozessors an die Tasks
Logische E/A Steuerung
API (Application Program Interface)
Betriebssystemkern im Kernelmode, Usermode für Anwendung
Zuteilung von Ressourcen an die Tasks
Schichtenmodell eines Makrokernbetriebssystems
4Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.3 Aufbau von Echtzeitbetriebssystemen
Realer Prozessor
Gerätetreiber
Ein-/Ausgabesteuerung
Betriebsmittelverwaltung
M0
M2
M3
M5
M7
Anwendung
Speicher-verwaltung
Ein-/Ausgabe-verwaltung
M4
API Kommando-Interpreter
Taskverwaltung M6
Erw
eite
run
gsm
od
ule
im U
serm
od
e
Mikrokern M1
• die Interprozesskommunikation• die Synchronisation• die elementaren Funktionen zur
Taskverwaltung, dies sind i.A.- das Einrichten einer Task,- das Beenden einer Task,- das Aktivieren einer Task, und- das Blockieren einer Task
Vorteile Mikrokern:
• sehr gut anpassbar an Aufgabe• Hohe Skalierbarkeit durch Erwei-
terungsmodule• Einfache Portierbarkeit• Preemptiver Kern• Kurze kritische Bereiche
Schichtenmodell eines Mikrokernbetriebssystems
5Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.3 Aufbau von Echtzeitbetriebssystemen
API
Betriebsmittel-verwaltung
Ein-/Ausgabe-verwaltung
Gerätetreiber
Festplatte
Anwendung
Usermode
Kernelmode
API Betriebsmittel-verwaltung
Gerätetreiber
Festplatte Anwendung
Usermode
Kernelmode
Mikrokern
a: Makrokernbetriebsystem
b: Mikrokernbetriebsystem
„Öffne Datei“
„Öffne Datei“
Ein-/Ausgabe-steuerung
Ein-/Ausgabe-verwaltung
Ein-/Ausgabe-steuerung
Usermode- und Kernelmode-Wechsel bei Makro- und
Mikrokernbetriebssystem
6Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.3 Aufbau von Echtzeitbetriebssystemen
Aus Sicht der Betriebszustände, der Zeitparameter, des Schedulings und der Synchronisation sind Thread und Task gleich.
Anwendung
Task 1
Thread 1 Thread i
. . .
Task n
Thread 1 Thread j
. . . . . .
Taskverwaltung: Tasks und Threads
7Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.3 Aufbau von Echtzeitbetriebssystemen
Task (schwergewichtiger Prozess)
• eigene Variablen und Betriebsmittel
• von den anderen Tasks abgeschirmt
• Eigener Adressraum
• Kommunikation nur über Interprozesskommunikation
• Task-Umschaltung bis zu mehrere 1000 Prozessortakte
Thread (leichtgewichtiger Prozess)
• innerhalb einer Task. Benutzt Variablen und Betriebsmittel der
Task
• Gemeinsamer Adressraum aller Threads innerhalb einer Task
• Kommunikation über beliebige globale Variable.
• Sehr schnelle Kommunikation und Thread-Umschaltung
(wenige Takte).
• Wenig Schutz zwischen Threads.
8Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.3 Aufbau von Echtzeitbetriebssystemen
• Ruhend (dormant)Die Task ist im System vorhanden, aber momentan nicht ablaufbereit, da Zeitbedin-gungen oder andere Voraussetzungen (noch) nicht erfüllt sind.
• Ablaufwillig (runnable)Die Task ist bereit, alle Zeitbedingungen oder andere Voraussetzungen zum Ablauf sind erfüllt, die Betriebsmittel sind zugeteilt, lediglich die Zuteilung des Prozessors durch die Taskverwaltung steht noch aus.
• Laufend (running)Die Task wird auf dem Prozessor ausgeführt. Bei einem Einprozessorsystem kann nur eine Task in diesem Zustand sein, bei einem Mehrprozessorsystem kann dieser Zustand von mehreren Tasks gleich-zeitig angenommen werden.
• Blockiert (suspended, blocked)Die Task wartet auf das Eintreffen eines Ereignisses (z.B. einen Eingabewert, eine Interprozesskommunikation) oder das Frei-werden eines Betriebsmittels (Synchronisa-tion).
ruhend ablauf-willig
laufend
blockiert
Einrichten
der Task
Entfernen
Taskzustände/Threadzustände
9Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.3 Aufbau von Echtzeitbetriebssystemen
T
> 2T
Kollisionswarnung
6T
Kollisionswarnung
> T
< 2T
Ruhe
Kameradaten-verarbeitung
Motor-steuerung
8T T 2T 3T 4T 5T 7T
Laserscanner-datenverarbeitung (1. Prior.)
Transponder-datenverarbeitung (2. Prior.)
LandmarkePeriodendauer Kameradatenverarbeitung: TPeriodendauer Motorsteuerung: 2T
Beispiel: zeitlicher Ablauf der FTS-Steuerung
10Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.3 Aufbau von Echtzeitbetriebssystemen
Kollisionswarnung
6T
Kollisionswarnung
ruhend
ablaufwillig
laufend
8T T 2T 3T 4T 5T 7T
blockiert
Landmarke
Zustände der Task Kameradatenverarbeitung
11Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.3 Aufbau von Echtzeitbetriebssystemen
ri si ciai di
pi
ruhend
lieiji
t
eri
ablaufwillig
laufend
blockiert Task i
ai: Ankunftszeit (Arrival Time)
ri: Anforderungszeit (Request Time)
si: Startzeit (Start Time)
ji: Reaktionszeit (Reaction Time, Release Jitter)
ei: Ausführungszeit (Execution Time)
eri: Restausführungszeit (Remaining Execution Time)
ci: Beendigungszeit (Completion Time)
di: Zeitschranke (Deadline)
pi: Periode (Period)
li: Spielraum (Laxity, li = di – (t + eri) )t: aktueller Zeitpunkt
Wesentliche Zeitparameter einer Echtzeittask
12Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Aufgabe eines Echtzeitschedulers
Aufteilung des Prozessors zwischen allen ablaufwilligen Tasks derart, dass – sofern möglich – alle Zeitbedingungen eingehalten werden.
Fragen zur Beurteilung eines Echtzeitschedulingverfahrens• Existiert für ein gegebenes Taskset überhaupt ein
Schedule, das alle Zeitbedingungen einhält? • Findet das verwendete Schedulingverfahren diesen
Schedule?• Kann dieser Schedule in endlicher Zeit berechnet werden?Ein Schedulingverfahren heißt optimal, wenn es einen Schedule findet, sofern dieser existiert
13Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Prozessorauslastung (Processor Demand).
Prozessorauslastung auf einem Einprozessorsystem für ein Taskset aus n periodischen Tasks mit Zeitschranke = Periode:
Analyse des Echtzeitverhaltens (Scheduling Analysis, Feasibility Analysis)
H > 100%: kein ScheduleH ≤ 100%: Schedule existiert
(wird jedoch je nach verwendetem Echtzeitschedulingverfahren nicht unbedingt gefunden)
i Task von uerPeriodenda :p szeit,Ausführung :e mit p
e H ii
i
in
i
1
eitProzessorz Verfügbare
eitProzessorz Benötigte H
14Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Scheduling-Verfahren
Statisches Scheduling Dynamisches Scheduling
Nicht-preemptives Scheduling
PreemptivesScheduling
Nicht-preemptivesScheduling
PreemptivesScheduling
StatischePrioritäten
Dynamische Prioritäten
Nicht prioritäts-basiert
StatischePrioritäten
DynamischePrioritäten
Nicht prioritäts-basiert
Klassifizierungsmerkmale von Scheduling-Verfahren
15Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Task 2 (weniger wichtig)
Task 1 (wichtig)
Ereignisfür Task 1
Ruhe
Ereignisfür Task 2
Preemption
Task 1 fertig
Ereignisfür Task 1
Task 1 fertig
Ereignisfür Task 2
a) Preemptives Scheduling b) Nicht-preemptives Scheduling
Preemptives und nicht-preemptives Scheduling
16Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Task 2
Task 1
Ereignis für Task 2
Ruhe
Ereignis für Task 1
Erste Ausführung Task 2 fertig
0 5 10 15 20 msec
Ereignis für Task 2
Zeitschranke für erste
Ausführung von Task 2 verpasst
4.4.1 FIFO-Scheduling
First In First Out Prinzip: wer zuerst kommt, erhält zuerst den Prozessor
Dynamisch, nichtpreemptiv, ohne Prioriäten
Wenig geeignet für Echtzeit, da keinerlei Zeitbedingungen eingehen
Beispiel.: Task 1: Periode p1 = 150 msec Task 2: Periode p2 = 10 msec
Ausführungszeit e1 = 15 msec Ausführungszeit e2 = 1 msec
H = 15 msec / 150 msec + 1 msec / 10 msec = 0,2 = 20%
17Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
4.4.2 Fixed-Priority-Scheduling
Jede Task erhält eine feste Priorität
Dynamisches Scheduling, statische Prioritäten
2 Varianten:
• Fixed-Priority-Preemptive-Scheduling (FPP)• Fixed Priority-Non-Preemptive Scheduling (FPN)
Zuordnung der Prioritäten zu den Tasks ist entscheidend für das Echtzeitverhalten
18Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Rate-Monotonic-Scheduling (RMS)
Gibt eine Regel der Prioritätenzuordnung für periodische Tasks an:
Es werden den periodisch auszuführenden Tasks Prioritäten umgekehrt
proportional zu ihren Periodendauern zugewiesen:
PRi ~ 1 / pi mit pi: Periodendauer der Task i, PRi: Priorität der Task i
• es wird preemptives Scheduling verwendet,
• die Periodendauer pi ist konstant,
• die Zeitschranke di ist gleich der Periodendauer pi,
• die Ausführungszeit ei ist konstant und bekannt, und
• die Tasks sind voneinander unabhängig, d.h. sie blockieren sich nicht gegenseitig z.B. durch Synchronisation
• Als Deadlines werden die Periodendauer angenommen
19Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Task 2
Task 1
Ereignis für Task 2
Ruhe
Ereignis für Task 1
Preemption
0 5 10 15 20 msec
Ereignis für Task 2
Preemption
Fixed-Priority-Preemptive-Scheduling und Prioritätenverteilung gemäß dem Rate-Monotonic-Prinzip
Task 1: Periode p1 = 150 msec => niedere PrioritätAusführungszeit e1 = 15 msec
Task 2: Periode p2 = 10 msec => hohe PrioritätAusführungszeit e2 = 1 msec
Deadlines sind die Periodendauern, H = 20%
Beispiel: RMS bei nicht gleichzeitigem Auftreten der Ereignisse
20Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Task 2
Task 1
Ereignis für Task 2
Ruhe
Ereignis für Task 1
und 2
0 5 10 15 20 msec
Ereignis für Task 2
Task 1: p1 = 150 msec, e1 = 15 msec => niedere PrioritätTask 2: p2 = 10 msec, e2 = 1 msec => hohe Priorität
Zuteilung der Prioritäten gemäß dem Rate-Monotonic-Prinzip sind essentiell. Würde man keine Preemption zulassen oder die Prioritäten anders herum verteilen, so würde im obigen Beispiel Task 2 ihre Zeitschranken verletzen.
Beispiel: RMS bei gleichzeitigem Auftreten der Ereignisse
21Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Behauptung:
Rate-Monotonic-Scheduling liefert bei festen Prioritäten und Preemption für periodische Tasks, bei denen die Zeitschranke identisch zur Periode ist, eine optimale Prioritätenverteilung.
RMS = Optimale Prioritätenverteilung?
22Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Task 2
Task 1
p1
Ruhe
0
e2
e1
. . .
p2
Task 2
Task 1
Ruhe
e2
e1
p10 p2
. . .
Prinzip des Beweises am Beispiel zweier Tasks, p2 > p1:
Prioritätenverteilung 1 (entgegen RMS)
Taskset ausführbar, wenn gilt: e1 + e2 ≤ p1
Anderenfalls verpasst Task T 1 ihre Zeitschranke
Prioritätenverteilung 2 (gemäß RMS)
Aus e1 + e2 ≤ p1 folgt: T 1 wie auch T 2 terminiertvor oder spätestens zum Zeitpunkt p1
Daraus folgt: Task 1 hält ihre ZeitschrankeAus p2 > p1 folgt: Task 2 terminiert vor p2
Daraus folgt: Task 2 hält ihre Zeitschranke
23Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Dies gilt auch für alle späteren Aufrufe, da beim ersten Aufruf
durch gleichzeitige Aktivierung von Task 1 und Task 2 der
schlimmste Fall bereits abgedeckt ist.
Schlussfolgerung: ist Taskset mit 2 Tasks unter einer
Prioritätenverteilung entgegen dem Rate-Monotonic-Prinzip
(Variante 1) ausführbar, so ist es immer auch mit dem Rate-
Monotonic-Prinzip (Variante 2) ausführbar.
Für 2 Tasks ist Rate-Monotonic-Scheduling also eine optimale
Prioritäten-zuteilung für feste Prioritäten.
Die Beweisführung lässt sich leicht von zwei auf eine beliebige
Anzahl Tasks erweitern ([Liu Layland 1973])
24Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Laserscanner-Datenverarbeitung
Kamera-Datenverarbeitung
Transponder-Erkennung
Funk-Kommunikation
Motorsteuerung und -regelung
FTS
FTS Beispiel mit drei Aufgaben
25Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Prod 1
Prod 2
FTS
Lager
T1: Kameradatenverarbeitung, p1 = d1 = 10 msec, e1 = 1 msec T2: Motorsteuerung, p2 = d2 = 10 msec, e2 = 5 msecT3: Transpondererkennung, d3 = 1 cm : 0,65 m/sec = 15,4 msec, e3 = 5,5 msec
Fahrgeschwindigkeit: 0,65 m/sec, Positionsgenauigkeit 1 cm
Daten aus industriellem FTS mit aufgeklebter Fahrspur und Landmarken
26Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Prioritätenvergabe gemäß RMS:
T1 (Kameradatenverarbeitung): hohe PrioritätT2 (Motorsteuerung): mittlere Priorität.T3 (Transpondererkennung): niedrige Priorität
oder:
T1 (Kameradatenverarbeitung): mittlere Priorität.T2 (Motorsteuerung): hohe PrioritätT3 (Transponderdatenerkennung): niedrige Priorität
H = e1 / p1 + e2 / p2 + e3 / p3 = = 1 msec/10 msec + 5 msec/10 msec + 5,5 msec/15,4 msec = = 95,71%
(aperiodisches Transponderereignis als schlimmster Fall mit seiner Zeitschranke periodisiert)
Prozessorauslastung
27Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Motorsteuerung(T2)
Kameradatenverarbeitung (T1)
Ereignisfür T1und T2
Ruhe
Ereignisfür T1, T2 und T3
Preemption
0 5 10 15 20 msec
Zeitschranke T3
Transponder-Erkennung (T3)
1 msec
5 msec
4 msec
1 msec
5 msec
1,5 msec
Zeitschranke T1&T2 um 2,1 msec verpasst
Ablauf des FTS Beispiels mit Priorität T1 > T2 > T3
28Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Motorsteuerung (T2)
Kameradaten-verarbeitung (T1)
Ereignisfür T1 und T2
Ruhe
Ereignisfür T1, T2 und T3
Preemption
0 5 10 15 20 msec
Zeitschranke T3
Transponder-Erkennung (T3)
1 msec
5 msec
4 msec
1 msec
5 msec
1,5 msec
Zeitschranke T1& T2 um 2,1 msec verpasst
Ablauf des FTS Beispiels mit Priorität T2 > T1 > T3
29Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Daraus folgt:
Feste Prioritäten mit Preemption ist kein optimales Schedulingverfahren.
Obergrenze der Prozessorauslastung ist mathematisch ermittelbar, bis zu der immer ein ausführbarer Schedule für Rate-Monotonic-Scheduling mit Preemption gefunden wird.
Hmax = n(21/n – 1), n = Anzahl der Tasks
Bsp.: Hmax = 3 (21/3 -1) = 0,78 = 78%
30Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
4.4.3 EDF-Scheduling
Bei Earliest-Deadline-First-Scheduling (EDF) erhält diejenige Task den Prozessor zugeteilt, die am nächsten an ihrer Zeitschranke (Deadline) ist.
=> Prioritäten ergeben sich automatisch und dynamisch aus den Zeitschranken.
Dynamisches Scheduling, dynamische Prioritäten, preemptiv oder nicht-preemptiv
Preemptives EDF-Scheduling auf Einprozessorsystemen liefert optimales Scheduling
Hmax = 100%
EDF findet für periodische Tasks mit di = pi einen Schedule, wenn gilt:
ei / pi ≤ 1
n
i 1
31Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Motorsteuerung(T2)
Kameradaten-verarbeitung (T1)
Ereignisfür T1 und T2
Ruhe
Ereignisfür T1, T2 und T3
0 5 10 15 20 msec
Zeitschranke T3
Transponder-Erkennung (T3)
1 msec
5 msec
5,5 msec
1 msec
5 msec
Zeitschranke T1&T2 Zeitschranke T1&T2
Ereignisfür T1 und T2
Ablauf des FTS-Beispiels mit EDF-Scheduling
32Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
4.4.4 LLF-Scheduling
Bei Least-Laxity-First-Scheduling (LLF) erhält diejenige Task den Prozessor zugeteilt, die den geringsten Spielraum (Laxity) hat.
Dynamisches Scheduling, dynamische Prioritäten, preemptiv oder nicht-preemptiv
Preemptives LLF ist wie EDF ein optimales Schedulingverfahren auf Einprozessorsystemen,
Hmax = 100%.
Für den Spielraum gilt li = di – (t + eri)
LLF erzeugt eine drastisch höhere Anzahl an Taskwechseln als EDF
Aber besseres Verhalten als EDF bei Überlast
33Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Ablauf des FTS Beispiels mitLLF-Scheduling
34Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Task 1,ablaufwillig,
Zeitscheibe 1
Task 2,nicht ablaufwillig,
Zeitscheibe 2
Task 3,ablaufwillig,
Zeitscheibe 3
Task n,ablaufwillig,
Zeitscheibe n. . .
4.4.5 Time-Slice-Scheduling
Time-Slice-Scheduling (Zeitscheibenverfahren) ordnet jeder Task eine feste Zeitscheibe (Time Slice) zu.
Die Reihenfolge der Taskausführung entspricht hierbei der Reihenfolge der ablaufwilligen Tasks in der Taskverwaltungsliste des Betriebssystems.
Die Dauer der Zeitscheibe für eine Task kann individuell festgelegt werden.
Preemptives dynamisches Scheduling ohne Prioritäten.
Einfaches Verfahren, bei feinkörnigen Zeitscheiben nahe an der Optimalität, aber Periodendauer abhängig von der Anzahl der Tasks
35Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Motorsteuerung(T2)
Kameradaten-verarbeitung (T1)
Ereignisfür T1 und T2
Ruhe
Ereignisfür T1, T2 und T3
0 5 10 15 20 msec
Zeitschranke T3
Transponder-erkennung (T3)
0,5 msec
2,5 msec
1,8 msec
Zeitschranke T1&T2 Zeitschranke T1&T2
Ereignisfür T1 und T2
0,5 msec 0,5 msec 0,5 msec
2,5 msec 2,5 msec 2,5 msec
1,8 msec 1,8 msec 0,1 msec
Slice T1 = 0,5 msec
T3 fertig
T2 fertig
Slice T2 = 2,5 msec
Slice T3 = 1,8 msec
T1 fertig
T2 fertig
T1 fertig
T1: H1 = e1 / p1 = 1 msec / 10 msec = 10%T2: H2 = e2 / p2 = 5 msec / 10 msec = 50%T3: H3 = e3 / p3 = 5,5 msec / 15,4 msec = 36% (35,714%)Die Zeitscheiben wurden auf der Proportionalitätsbasis 1% ≡ 0,05 msec wie folgt gewählt:T1: Zeitscheibe 0,5 msec (~ 10%) T2: Zeitscheibe 2,5 msec (~ 50%) T3: Zeitscheibe 1,8 msec (~ 36%)
Ablauf des FTS-Beispiels mit Time-Slice-Scheduling
36Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
4.4.6 Guaranteed Percentage Scheduling
Guaranteed Percentage Scheduling (GP) ordnet jeder Task einen festen Prozentsatz der verfügbaren Prozessorleistung innerhalb einer Periode zu(virtueller Prozessor pro Task)
Preemptives dynamisches Schedulingverfahren ohne Prioritäten
Periodendauer unabhängig von der Anzahl der Tasks
Auf Einprozessorsystemen ein optimales Schedulingverfahren: Hmax = 100%
Bei periodischen Tasks werden die Zeitschranken erfüllt, wenn gilt: ei / pi ≤ 1
Viele Taskwechsel wie bei LLF
Für mehrfädige Prozessoren geeignet.
n
i 1
37Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Thread A, 30%
Thread B, 20%
Thread C, 40%
Thread A30 Taktzyklen
Thread B20 Taktzyklen
Thread C40 Taktzyklen
Thread A30 Taktzyklen
Thread B20 Taktzyklen
Thread C40 Taktzyklen
. . .. . .
100 Taktzyklen 100 Taktzyklen
Beispiel Komodo-Mikrocontroller, GP Periode 100 Taktzyklen (vgl. Abschnitt 2.6)
38Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.4 Echtzeitscheduling
Motorsteuerung(T2)
Kameradaten-verarbeitung (T1)
Ereignisfür T1 und T2
Ruhe
Ereignisfür T1, T2 und T3
0 5 10 15 20 msec
Zeitschranke T3
Transponder-erkennung (T3)
Zeitschranke T1&T2 Zeitschranke T1&T2
Ereignisfür T1 und T2
fertig
T3 fertig
T1 und T2
fertig T1 und T2
T1: H1 = e1 / p1 = 1 msec / 10 msec = 10%T2: H2 = e2 / p2 = 5 msec / 10 msec = 50%T3: H3 = e3 / p3 = 5,5 msec / 15,4 msec = 36% (35,714 %)Hierdurch ergibt sich für jede Task eine Ausführungszeit, die ihrer Periode und damit ihrer Zeitschranke entspricht:T1: Ausführungszeit: 1 msec in 10 msec (10%) T2: Ausführungszeit: 5 msec in 10 msec (50% ) T3: Ausführungszeit: 5,5 msec in 15,3 msec (36%)
Ablauf des FTS-Beispiels mit
Guaranteed Percentage Scheduling
39Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Temperatur-Sensoren auslesen
Temperatur-Verteilung in Temperatur-
Tabelle ablegen
Temperatur-Tabelle lesen
Temperatur-Verteilung
ausdrucken
KonkurrierenderZugriff
Task 1 Task 2
Gemeinsame Betriebsmittel• Daten • Geräte • Programme
Beispiel: gemeinsam genutzte „Temperatur-
Tabelle“
4.5.1 Synchronisation gemeinsamer Betriebsmittel
40Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Synchronisation – Variante 1
• Die Sperrsynchronisation Temperatur
Sensoren auslesen
Temperatur-Tabelle ablegen
TemperaturTabelle lesen
Temperatur-Verteilung
ausdrucken
Task 1 Task 2
Mutex für Temperatur-
Tabelle belegen
Mutex fürTemperatur
Tabelle belegen
Mutex fürTemperatur-
Tabelle freigeben
Mutex fürTemperatur-
Tabelle freigeben
Sperr-synchronisation
kritischerBereich
41Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Temperatur-Sensoren auslesen
Temperatur-Verteilung in Temperatur-
Tabelle ablegen
Temperatur-Tabelle lesen
Temperatur-Verteilung
ausdrucken
Task 1 Task 2
Reihenfolgen-synchronisation
Taskblockiert
Taskblockiert
Synchronisation – Variante 2
• Die Reihenfolgensynchronisation
42Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Ein Semaphore besteht aus: einer Zählvariablen zwei nicht unterbrechbaren Operationen P (Passieren) und V
(Verlassen)
eine blockierte Task bereit machen
Zähler := Zähler + 1
Zähler<1 ?
V
Task blockieren
Zähler := Zähler - 1
Zähler<0 ?
P
ja
nein
ja
nein
Bei Standardbetriebssystemen: Bereitmachen einer beliebigen wartenden Task bei VBei Echtzeitbetriebssystemen: Bereitmachen der höchstprioren wartenden Task bei V
43Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
InitialisiereSemaphore S1= 1
Passiere(S1)
Verlasse(S1)
Zugriff aufgeschützte
Betriebsmittel
Passiere(S1)
Verlasse(S1)
Task 1 Task 2
Task 2blockiert
Task 2 freigegeben
Zugriff aufgeschützte
Betriebsmittel
Sperrsynchronisation mit einem Semaphore
Diese Form des Semaphore-Einsatzes heißt auch Mutex (Mutual Exclude)
44Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Initialisiere Semaphore S1=0
Task 1 Task 2
Task 1blockiert
Task 1 freigegeben
Aktivität Task 2
Aktivität Task 1
Aktivität Task 2
Task 2blockiert
Task 1blockiert
Task 2 freigegeben
Task 1 freigegeben
Initialisiere Semaphore S2=1
Passiere(S1) Passiere(S2)
Verlasse(S1)
Verlasse(S2)
Passiere(S2)
Passiere(S1)
Verlasse(S1)
Reihenfolgen-synchronisation mit zwei Semaphoren
45Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
InitialisiereSemaphore
Leerungen = n
Passiere(Leerungen)
Task "Erzeuger" Task "Verbraucher"
Erzeuge Objekt
Verlasse(Füllungen)
InitialisiereSemaphore
Füllungen = 0
Passiere(Füllungen)
Verbrauche Objekt
Verlasse(Leerungen)
Leerungen: Freie Plätze für Objekte des Erzeugers, Füllungen: erzeugte Objekte für Verbraucher
Erzeuger-/Verbraucher-Synchronisation mit zwei Semaphoren
46Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Temperatur- und Druck- Sensoren
auslesen
Temperatur-Verteilung in Temperatur-
Tabelle ablegen
Task 1 Task 2
Mutex fürTemperatur-
Tabelle belegen
Mutex für Temperatur-
Tabelle freigeben
kreuzweiseBetriebsmittel-
belegungMutex für Druck-Tabelle belegen
Druck-VerteilungIn Druck-Tabelle
ablegen
Mutex für Druck-Tabelle freigeben
Mutex für Temperatur-
Tabelle belegen
Mutex für Druck-Tabelle belegen
Temperatur-Tabelle lesen
Druck-Tabelle lesen
Mutex für Druck-Tabelle freigeben
Mutex für Temperatur-
Tabelle freigeben
Temperatur- und Druck- Verteilung
ausdrucken
Verklemmungen
Deadlock (Blockierung, Deadly Embrace): mehrere Tasks warten auf die Freigabe von Betriebsmitteln, die sich gegenseitig blockieren.
Beispiel: kreuzweise Betriebsmittelbelegung
Gegenmaßnahmen:• Abhängigkeitsanalyse• Vergabe der Betriebsmittel in
gleicher
Reihenfolge• Timeout
47Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Initialisiere
Semaphore S1 = 1
Zugriff auf geschützte
Betriebsmittel
Task 1 Task 2
Passiere(S1)
Verlasse(S1)Passiere(S1)
Passiere(S1)
Zugriff auf geschützte
Betriebsmittel
Ein Deadlock durch Programmierfehler
Gegenmaßnahme:
• höhere Synchronisationskonstrukte (z.B. Monitore)
48Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Verklemmungen
Livelock (Starvation, Aushungern): eine Task wird durch andere Tasks ständig an der Ausführung gehindert.
Beispiel: eine hochpriore Task verhindert ständig die Ausführung einer niederprioren Task
Auch hochpriore Tasks können „Opfer“ von Livelocks werden, Problem Prioritäteninversion
49Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Task 1hohe
Priorität
Task 2niedere Priorität
Mutex
Task 2
Task 1
Ereignisfür Task 1
Ruhe
Ereignisfür Task 2
Zeit
Task 2 belegtMutex
Task 1 versucht, Mutex zu belegen,
wird blockiert
Task 2 gibt Mutex frei
Prioritäteninversion
Prioritäteninversion
50Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Task 2
Task 1
Ereignisfür Task 1
Ruhe
Ereignisfür Task 2
Zeit
Livelock, Task 1 ist längerfristig blockiert
Task 3
Ereignisfür Task 3
Task 2 belegtMutex
Task 1 versucht, Mutex zu belegen,
wird blockiert
Mutex Task 1hohe
Priorität
Task 2niedere Priorität
Task 3mittlere Priorität
Ein Livelock durch Prioritäten-inversion
51Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Task 2
Task 1
Ereignisfür Task 1
Ruhe
Ereignisfür Task 2
Zeit
Prioritätenvererbung, Task 2 erhält die
Priorität von Task 1(daher keine Unter-
brechung durch Task 3)
Task 3
Ereignisfür Task 3
Task 1 ist fertig
Task 2 belegtMutex
Task 1 versucht, Mutex zu belegen,
wird blockiert
Task 2 gibt Mutex frei
Mutex mit Prioritäten-vererbung
Task 1hohe
Priorität
Task 2niedere Priorität
Task 3mittlere Priorität
Vermeidung des Livelocks durch einen Mutex mit Prioritäten-vererbung
52Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Zwei grundlegende Varianten der Task-Kommunikation: • Gemeinsamer Speicher (schneller)• Nachrichten
Task 1,Priorität n
Task 2,Priorität n
Kommunikation Priorität n
Bei Echtzeitbetriebssystemen: Wahrung der End-zu-End-Prioritäten durch prioritäts-basierte Kommunikation (hochprioreNachrichten überholen niederpriore,keine Bockierung)
4.5.2 Task-Kommunikation
53Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Weiteres Unterscheidungsmerkmal
• zeitliche Koordination - Synchrone Kommunikation- Asynchrone Kommunikation
Task 1
Sende_Nachricht
Warte_auf_Nachricht
Task 2 blockiert
Task 2 Task 1
Sende_Nachricht
Prüfe_ob_Nachricht_vorhanden
Task 2
Prüfe_ob_Nachricht_vorhandenHole_Nachricht
a) synchrone Kommunikation b) asynchrone Kommunikation
Hole_Nachricht
54Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Für asynchrone Kommunikation: der Kommunikationskanal muss Botschaften puffernKonzepte:
• Briefkasten: individuelle Botschaftenwarteschlange zwischen Sender und Empfänger
• Port: spezielle Form des Briefkastens, bei der mehrere Sender Daten mit einem Empfänger austauschen können
Empfange(Verbrau-cher, Port, Priorität,
Leerbotschaft)
Task "Erzeuger" Task "Verbraucher"
Erzeuge Objekt Vollbotschaft
for i:= 1 to n do
Sende(Erzeuger, Port,Priorität, Leerbotschaft)
Sende(Verbraucher, Port, Priorität, Vollbotschaft)
Empfange(Erzeuger, Port, Priorität, Vollbotschaft)
Vollbotschaft Verbrauche Objekt
Sende(Erzeuger, Port,Priorität, Leerbotschaft)
Beispiel nachrichtenbasierter Kommunikation: Botschaftenaustausch
55Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.5 Synchronisation und Kommunikation
Ausgangsrechner
Task Stellvertreter(Stub)
1
6
Zielrechner
ProzedurStellvertreter
(Skeleton)
3
4
Netzwerk, Feldbus, ...
2
5
(1), (3), (4), (6) - Prozeduraufrufe(2), (5), - Botschaftentransfer
Entfernter Prozeduraufruf mittels Botschaftenaustausch
56Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
4.6.1 Speicherverwaltung
Die Speicherverwaltung teilt den verfügbaren Speicher mittels einerSpeicherabbildungsfunktion M zu:
M: logische Adresse → physikalische Adresse
Logische Adresse: Speicheradresse innerhalb einer TaskPhysikalische Adresse: wirkliche Arbeitsspeicheradresse
Modelle der Speicherverwaltung: Speicherzuteilung:
• Statische Speicherzuteilung• Dynamische Speicherzuteilung• Nichtverdrängende Speicherzuteilung• Verdrängende Speicherzuteilung
Adressbildung und Adressierung:
• Reelle Adressierung • Virtuelle Adressierung • Lineare Adressbildung • Streuende Adressbildung
57Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Segment 1 (log. Adressraum
Task 1)
Segment 2 (log. Adressraum
Task 2)
Segment 3 (log. Adressraum
Task 3)
unbenutzt
phys
ikal
isch
er A
dres
srau
m
Vorteile:
•Tasks im Speicher verschiebbar•Tasks gegeneinander geschützt•Zeitverhalten sehr gut vorhersagbar
Nachteile:
•Speicherschema starr, nicht online änderbar
•Für jede Task maximaler Speicher•Bei variierender Anzahl von Tasks muss
für alle Tasks Speicher reserviert werden,
kein Teilen von Speicher zwischen Tasks
Lineare Adressbildung durch Segmente, statische Zuteilung, reelle Adressierung, keine Verdrängung
Bevorzugte Lösung für eingebettete Systeme mit einfachen Mikrocontrollern
58Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Segment 1 Task 1
32 kBytes
Segment 2 Task 2
48 kBytes
unbenutzt, 48 kBytes
phys
ikal
isch
er A
dres
srau
m
Segment 1 Task 1
32 kBytes
Segment 3 Task 3
30 kBytes unbenutzt 18 kBytes
Task 3 30 kBytes
wirdablaufwillig
Task 2 48 kBytes
wirdbeendet
Segment 1 Task 1
32 kBytes
Segment 3 Task 3
30 kBytes unbenutzt 18 kBytes
unbenutzt 48 kBytes
Segment 1 Task 1
32 kBytes
Segment 4 Task 4
20 kBytes
Segment 3 Task 3
30 kBytes unbenutzt 18 kBytes
Task 4 20 kBytes
wirdablaufwillig
unbenutzt 18 kBytes
Segment 2 Task 2
48 kBytes
Tasks können sich phys. Speicher teilen, so lange keine Verdrängung ist die Zugriffszeit konstant.Speicherbereinigung wegen löchrigem Speicher.
Lineare Adressbildung durch Segmente, dynamische Zuteilung, reelle Adressierung, keine Verdrängung
59Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
p
hys
ika
lisch
er
Ad
ress
rau
m
Task 5 32 kBytes
wirdablaufwillig
Segment 1Task 1
32 kBytes
Segment 4Task 4
20 kBytes
Segment 3Task 3
30 kBytesunbenutzt18 kBytes
unbenutzt18 kBytes
Segment 1Task 1
32 kBytes
Segment 4Task 4
20 kBytesSegment 3
Task 330 kBytes
unbenutzt36 kBytes
Segment 1Task 1
32 kBytes
Segment 4Task 4
20 kBytesSegment 3
Task 330 kBytes
4 kBytes
Segment 5Task 5
32 kBytes
kom
pakt
ifizi
eren
Wegen Segmentverschiebungen für Echtzeit problematisch.
Lineare Adressbildung mit Speicherbereinigung
60Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
physikalischer Adressraum
Segment 1
Segment 4
unbenutzt
logischer Adressraum
Segment 1
Segment 4
Segment 2
Segment 3
Peripherie-speicher
ausgelagert(verdrängt)
eingelagert
Task 1
Task 2
Task 3
Task 4
Verdrängungsstrategien (auslagern):
• FIFO (First In First Out), am längsten im Sp.• LRU (Least Recently Used), a. l. nicht mehr ben.• LFU (Least Frequently Used), am seltensten ben.• LRD (Least Reference Density), ger. Zugriffsdichte
Zuteilungsstrategien (einlagern, wohin):
• First Fit (erstes)• Best Fit (kleinstes)• Worst Fit (größtes)
Nachschubstrategien (wann einlagern):
• Verlangend (Demand Fetch)• Vorausschauend (Anticipatory Fetch)
Echtzeitbetriebsysteme: Verriegeln von einzelnen Tasks, d.h. keine Verdrängung
Lineare Adressbildung mit virtueller Adressierung und Verdrängung
61Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
ruhend laufend
blockiert
Einrichten
der Task
Entfernen
ablauf-willig,
verdrängt
ablauf-willig,
eingelagert
Taskzustände bei verdrängender Speicherverwaltung
62Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
m Bit
Segmentadresse Offsetadresse
+
in der Segmentdeskriptor-Tabelle im Arbeitsspeicher
virtuelle Adresse
physikalische Adresse
v Bit p Bit
m Bitm Bit
n Bit
Segmentdeskriptor
Segmenttypphysikalische Segment-StartadresseSegmentlängeZugriffsrechteSegment verdrängt
...
phys. Deskriptor-Tabellen-Startadresse +
m Bit
Realisierung der linearen Adressbildung mit Segmenten
63Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Task 1
unbenutzt
Task 1Seite 1
Seite 2
Seite 3
Task 1 Seite 4
Seite 5
Seite 6
Task 1 Seite 7
Seite 8
Seite 9
Task 1 Seite 10
Seite 11
Seite 12
Task 2
Task 3
Streuende Adressbildung: Aufteilung der Tasks auf Seiten
64Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Task 1
unbenutzt
Task 1 Seite 1
Seite 2
Seite 3
Task 1 Seite 4
Seite 5
Seite 6
Task 1 Seite 7
Seite 8
Seite 9
Task 1 Seite 10
Seite 11
Seite 12
Task 2
Task 3
Task 1
unbenutzt
Kachel 1
Kachel 2
Kachel 3
Task 1 Kachel 4
Kachel 5
Kachel 6
Task 1 Kachel 7
Kachel 8
Kachel 9
Task 1 Kachel 10
Kachel 11
Kachel 12
unbenutzt
Kachel 13
Kachel 14
Task 1 Kachel 15
Kachel 16
Kachel 17
unbenutzt
Kachel 18
Kachel 19
Task 1 Kachel 20
Kachel 21
Kachel 22
logischer Adressraum
Physik. Adressraum
. . .
Die Zuordnung von Seiten zu Kacheln erfolgt in der Regel ohne Beachtung der sequentiellen Reihenfolge der Seiten
Vorteile:• einfache Zuweisung, keine Zuteilungsstrategie• dynamische Taskgrößenänd. einfacher und zeitlich besser vorhersagbar• keine Speicherbereinigung• Virtuelle Adressierung benötigt nur Verdrängung- und Nachschubsstrategie
Nachteile:• letzte Seite nur teilweise voll• höherer Seitenverwaltungsaufwand• durch kleine Seiten mehr Datentransfers zwischen Haupt- und Peripheriespeicher
Streuende Adressbildung: Zuordnung von Seiten zu Kacheln
65Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Seitentabelle im Arbeitsspeicher
Seitenadresse Offsetadresse
k
logische Adresse
physikalische Adresse
v Bit p Bit
m Bitm-p Bit
n Bit
Startadresse der phys. Seitentabelle
+m Bit
k = Konkatenationm Bit
Kachelnummer der Seite
Realisierung der streuenden Adressbildung mit Seiten
66Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Seitenverzeichnis-adresse
Seitenadresse Offsetadresse
Seiten-tabellen-
verzeichnis
Seiten-tabelle
k
k
logische Adresse
physikalische Adresse
Hierarchischer Aufbau der Seitentabellen
67Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Segmentadresse Seitenadresse Offsetadresse
logische Adresse
Kombination der Vorteile
Kombination von linearer und streuender Adressbildung
68Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
4.6.2 IO-Verwaltung
Aufgaben der IO-Verwaltung: Zuteilen und Freigeben von Geräten Benutzen von Geräten
Die angeschlossenen Geräte unterscheiden sich hierbei stark in Geschwindigkeit und Datenformat
=> das Betriebssystem muss dem Anwender- programm die Schwierigkeiten der Kommunikation abnehmen und einfache, transparente Schnittstellen zur Verfügung stellen
Tasks
Ein-/Ausgabesteuerung
Gerätetreiber(hardwareabhängig)
Hardware(Geräte)
Ein-/Ausgabe-verwaltung
Architektur der Ein-/Ausgabeverwaltung
69Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Die wichtigsten Teilfunktionen der Ein/Ausgabe-
steuerungsschicht sind:
• Symbolische Namensgebung
• Annahme von Ein-/Ausgabeanforderungen
• Vergabe und Zuteilung von Geräten
• Synchronisation
• Schutz der Geräte
• Kommunikation mit den Gerätetreibern
• Pufferung
• Einheitliches Datenformat
70Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Eingaberegister
Eingaberegister
Eingaberegister
Adressbus
Datenregister
Steuerregister
Statusregister
Schnittstellenbaustein
Prozessor, Bus Gerät
Ein/Ausgabe-Daten
Steuer-Signale
Ste
ueru
ng
Datenbus
Steuerbus
Synchronisationsmechanismen
71Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Statusregisterlesen
Gerät bereit ?
Datenregisterlesen
Datumverarbeiten
Gerätinitialisieren:
Steuerregister schreiben
Datum insDatenregister
übertragen
Gerät nimmtTätigkeit auf
Task Schnittstellenbaustein Gerät
nein
ja
bereit
Einfach, hohe Übertragungsleistung bei einem
Gerät
Prozessor ständig aktiv, keine Nebenaktivitäten
Synchronisation durch Polling
72Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Gerät 1 bereit ?
Gerät 1behandeln
Gerät 2 bereit ?
Gerät 2behandeln
Gerät n bereit ?
Gerät nbehandeln
. . .
ja
ja
ja
nein
nein
nein
Verlangsamte Reaktionszeit bei
mehreren Geräten
Polling von mehreren Geräten innerhalb einer Task
73Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Statusregisterlesen
Gerät bereit ?
Datenregister lesen
Datum verarbeiten
Gerät initialisieren:Steuerregister
schreiben
Datum insDatenregister
übertragen
Gerät nimmt Tätigkeit auf
Task Schnittstellenbaustein Gerät
nein
ja
Kurze Aktivitätdurchführen
bereit
Nebenaktivitäten möglich
Verlangsamte Reaktionszeit, Nebenaktivität muss in kleine Teilschritte aufgeteilt werden
Synchronisation durch Busy Waiting
74Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Datenregister lesen
Datumverarbeiten
Gerätinitialisieren:
Steuerregister schreiben
Datum insDatenregister
übertragen
Gerät nimmtTätigkeit auf
Task Schnittstellenbaustein Gerät
Unterbrechungs-behandlung
Rückkehr zurUnterbrochenen
Task
. . .
Unterbrechung
Beliebige Nebenaktivitäten, schnelle Reaktionszeit
Verringerte Übertragungsraten
Synchronisation durch Unterbrechung
75Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Task Schnittstellenbaustein Gerät
nein
ja
Warte auf Bestätigung
Handshake
Gerätinitialisieren:
Steuerregister schreiben
Datum insDatenregister
übertragen
Gerät nimmtTätigkeit auf
Statusregisterlesen
Gerät bereit ?
Datenregister lesen
Datum verarbeiten
Bestätigung
bereit
Wenn Gerät Daten schneller liefert als die Task sie entgegennehmen kann
Synchronisation durch Polling mit Handshake
76Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Task Schnittstellenbaustein Gerät
Unterbrechungs-behandlung
Rückkehr zurunterbrochenen
Task
. . .
Handshake
Warte auf Bestätigung
Gerätinitialisieren:
Steuerregister schreiben
Datum insDatenregister
übertragen
Gerät nimmtTätigkeit auf
Datenregister lesen
Datum verarbeiten
Unterbrechung
Bestätigung
Wenn Gerät Daten schneller liefert als die Task sie entgegennehmen kann
Synchronisation durch Unterbrechung mit Handshake
77Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.6 Speicher- und IO-Verwaltung
Task 2
Task 1
Unterbrechung
Unterbrechungs-Behandlungs-programm
Zeit
Task 3
Task-Schedulerdes Echtzeitbetriebs-system
Unterbrechungs-system des Prozessors
Task 2
Task 1
Unterbrechung
Unterbrechungs-Behandlungs-programm
-
-
Zeit
Task 3
Task 4 (Unterbrechungs-behandlung)
a) Unterbrechung der Taskverarbeitung
b) Integration der Unterbrechung in die Taskverarbeitung
Task-Schedulerdes Echtzeitbetriebs-system
Unterbrechungs-system des Prozessors
Unterbrechungsbehandlung in Echtzeitbetriebssystemen
78Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
Threads
Tasks
Semaphore
Komm
.über DPRAM, FIFO
Nachrichten
Scheduler
SpeicherverwaltungPhysikal. Adr.
SpeicherverwaltungVirtuelle Adr.
Ein/Ausgabe Verw.Einfache E/A Treiber
Komfortable E/A Treiber, Netzwerke
Filesystem
Minimales Echtzeitbetriebssystem (MEBS) x x x x x x
Controller System (CS) x x x x x x xDediziertes System (DS) x x x x x x xBetriebssystemaufsatz (BA) x x x x x x x x xAllgemeines Echtzeitbetriebssystem (EBS) x x x x x x x x x
79Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
1. Entwicklungs- und Zielumgebung• Programmiersprache• Zielsystem (ZE)- Crossentwicklungsumgebung (CE)
- Ladezeiten bei Crossentwicklung - Debug-Möglichkeiten (CE): Quellcode-Debugging (C, C++,
Java), Zeitverfälschung bei CE-Debugging- EBS und EU vom selben Hersteller
2. Modularität und Kerngröße• Konfigurierbarkeit auf Anwendung• Minimaler Mikrokern für eingebettete Systeme
Auswahlkriterien für Echtzeitbetriebssysteme
80Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
3. Anpassbarkeit an verschiedene Zielumgebungen• Ist EBS an Mikrocontroller/Signalprozessor mit spezieller
Peripherie anpassbar?• ROM-Fähigkeit für Code mit RAM für Daten• Feldbusse verfügbar
4. Allgemeine Eigenschaften• Bedieneroberfläche (Grafik, Kommandos, keine)• Bibliotheken (Mathem., Graph., Textverarbeitung, …)• Werkzeug für GUI-Echtzeitanwendungen• Werkzeuge zur Versionsverwaltung, Datenhaltung oder
zur Programmentwicklung
81Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
5. Leistungsdaten• maximale Taskanzahl (Tasks, Threads)• Welche Scheduling-Strategien• Anzahl unterschiedlicher Prioritätsebenen (64-256)• Taskwechselzeiten (Threads schneller als Tasks)• Latenzzeiten bei Unterbrechungen• Behandlung von Unterbrechungen (direkt – indirekt)• EBS-Klasse für harte, feste, weiche Echtzeitanwendungen
82Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
Produkt QNX POSIX.4 RT-Linux VxWorks OS-9 CMX Windows CE
Her-steller
QNX Software Systems
Ltd.
Posix GPL (GNU Public
License)
Wind River
Microware CMX Systems
Microsoft
Typ DS, EBS Standard für EBS,
BA
BA EBS EBS MEBS EBS
Ziel-system
IA32 IA32, IA64,
PowerPC
IA32, PowerPC,
ARM
IA32, PowerPC, 680XX,
div. Mikro-
controller
IA32, PowerPC,
680XX
Diverse Mikro-
controller
IA32, Power-
PC, MIPS, ARM
Sprachen C, C++ C, C++, Java, Ada
C, C++, Java
C, C++, Java
C, C++, Java
C C, C++, Java
Datei-system
Unix, Windows
Unix Unix, Windows
Unix, Windows
Windows - Windows
GUI X-Win X-Win X-Win X-Win X-Win - Windows Netz-werk
TCP/IP TCP/IP, UDP
TCP/IP, UDP
TCP/IP TCP/IP - TCP/IP
Feldbus - - - CAN, ProfiBus
CAN, ProfiBus, Interbus S
- -
Schedu-ling
FPP, FPN, Timeslice,
FIFO
FPP, FPN, Timeslice, Benutzer-definiert
FPP, FPN, Timeslice
FPP, FPN, Timeslice
FPP, FPN, Timeslice
FPP, FPN, Timeslice
FPP, FPN
Industrielle Echtzeit-betriebssysteme
83Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
Inter-Taskkom-munikation
Netzwerk-Schnittstelle
Unterbre-chungs-
behandlung Scheduler
Mikrokern
Netzwerk-Manager
Prozess-Manager
Geräte-Manager
Dateisystem-Manager
weitereSystemtasks Systemtasks
Prozessor,Speicher, Geräte
Hardware
Unter-brechungen
AnwendertasksTask 1 Task n. . . Task 2
QN
X
4.7.1 QNX
Architektur von QNX
84Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
POSIX.1 Grundlegende Betriebssystemschnittstelle POSIX.2 Kommando-Interpreter POSIX.3 Test-Methoden POSIX.4 Echtzeiterweiterungen POSIX.5 ADA Anbindung an POSIX.1 POSIX.6 Sicherheitserweiterungen POSIX.7 Systemverwaltung POSIX.8 Transparenter Dateizugriff POSIX.9 FORTRAN-77 Anbindung an POSIX.1 POSIX.10 Supercomputer Profile POSIX.11 Transaktionsverwaltung POSIX.12 Protokollunabhängige Kommunikation POSIX.13 Echtzeitprofile POSIX.14 Multiprozessorprofile POSIX.15 Supercomputererweiterungen POSIX.16 Sprachunabhängiges POSIX.1 POSIX.17 Verzeichnis- und Namensdienste POSIX.18 Grundlegendes POSIX Systemprofil POSIX.19 FORTRAN-90 Anbindung an POSIX.1 POSIX.20 ADA Anbindung an POSIX.4 POSIX.21 Verteilte Echtzeiterweiterungen
4.7.2 Posix
POSIX-Standards
85Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
POSIX.4
POSIX.4a Threads
POSIX.4b Echtzeitscheduling Zeitgeber Asynchrone Ein-/Ausgabe Priorisierte Ein-/Ausgabe Synchronisierte Ein-/Ausgabe Hauptspeicherdateien Speicherverriegelung Echtzeitsignale Nachrichtenaustausch Semaphore Gemeinsamer Speicher Speicherschutz
zwingend optional
POSIX.4:Echtzeit-erweiterungen
86Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
Echtzeitkern
Hardware
Unterbrechungen
Linux-Kern
Echtzeit-Task 1
. . .
Linuxtask 1
Linuxtask m
. . .
Echtzeit-FIFO
Kom
mun
ikat
ion Echtzeit-
Task n
4.7.3 RTLinux
Architektur vonRTLinux
87Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
Anwendung
Nicht-Echtzeittasks
BenutzerschnittstelleGrafikDatenhaltung,Datenaufbereitung,....
Echtzeittasks(Module)
Aufgaben mithartenEchtzeitanforderungen
Aufteilung der eingebetteten Anwendung in Nicht-Echtzeit und Echtzeittasks
88Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
Bei RT-Linux wird eine Task als Prozess bezeichnet
Ein Prozess enthält einem Thread und kann weitere zur Laufzeit erzeugen
Ein RT-Prozess wird über ein Kernel-Modul definiert:insmod "Prozessname"
Der Linux-Befehl insmod lädt das Kernel-Modul "Prozessname" und startet die Funktion init_module zur Initialisierung.
Innerhalb init_module können weitere Threads angelegt werden
RT-Prozesse unter RTLinux
89Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
Erzeugen eines RT-Threads:
int pthread_create(pthread_t *thread, pthread_attr_t *attr, void *(*start_routine)(void *), void *arg);
Erzeugt einen Thread thread mit den Attributen attr (z.B. Stack-Größe) und startet ihn durch Aufruf der Funktion start_routine(arg). start_routine(arg) ist die Funktion, welche die Thread-Aufgaben realisiert.
Beenden eines RT-Threads:
int pthread_delete_np(pthread_t thread);
RT-Thread periodisch definieren:
int pthread_make_periodic_np(pthread_t thread, hrtime_t start_time, hrtime_t period);
Der Thread thread wird zum Zeitpunkt start_time gestartet und in durch period (in Nanosekunden) gegebenen Intervallen aufgerufen
Funktionen zur Verwaltung von RT-Prozessen
90Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
Suspendieren eines RT-Threads:
int pthread_suspend_np(pthread_t thread);Thread wird angehalten. Entspricht Blockiert-Zustand.
Aufwecken eines RT-Threads:
int pthread_wakeup_np(pthread_t thread);Thread kann fortgesetzt werden. Entspricht Zustandsübergang Blockiert nach Bereit.
Periodischen Thread bis zur nächsten Periode suspendieren:
int pthread_wait_np(void);Thread gibt Kontrolle an Scheduler bis zum nächsten periodischen Aufruf ab.
91Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
pthread_t thread; /* Datenstruktur für Threads */
int init_module(void)/* wird beim Laden des RT-Moduls aufgerufen */{
/* Erzeugen eines Threads mit Funktion start_routine */ return pthread_create (&thread, NULL, start_routine, 0);}
void cleanup_module(void) /* wird beim Entfernen des RT-Moduls aufgerufen */{ pthread_delete_np (thread); /* Entfernen (Löschen) des Threads */}
Beispiel: RT-Modul
92Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte
4.7 Klassifizierung und Beispiele von Echtzeitbetriebssystemen
void *start_routine(void *arg) /* Implementierung der Thread-Funktion */{ struct sched_param p; /* Datenstruktur für Thread-Eigenschaften */ p . sched_priority = 1; /* Thread-Priorität in Datenstruktur eintragen */
/* Funktion zum Setzen der Thread-Parameter aufrufen */ /* SCHED_RR: Round Robin Scheduling (auch möglich: SCHED_FIFO) */
pthread_setschedparam (pthread_self(), SCHED_RR, &p);
/* Periodischer Aufruf des Threads: Periode ist 0,5 sec, starte sofort */ pthread_make_periodic_np (pthread_self(), gethrtime(), 500000000);
while (1) { pthread_wait_np (); /* bis zur nächsten Periode warten */ rtl_printf("Hello, I'm here!\n"); /* Thread-Funktion: Text-Ausgabe */ } return 0;}
top related