Scheduling Kapitel
This commit is contained in:
parent
efa1f425b2
commit
ee6aaea71a
@ -172,7 +172,7 @@ Buchführung über sämtliche zum management notwendigen Informationen
|
|||||||
a. Prozessdeskriptor (process control block ~ PCB)
|
a. Prozessdeskriptor (process control block ~ PCB)
|
||||||
b. Prozessdeskriptortabelle: Deskriptioren sämtlicher Prozesse
|
b. Prozessdeskriptortabelle: Deskriptioren sämtlicher Prozesse
|
||||||
|
|
||||||
| Prozessormanagement | |
|
| Prozessormanagement (Prozessdeskriptor) | |
|
||||||
| Identifikation | eindeutige Prozessbezeichnung; einordnung in Abstammungshierarchie |
|
| Identifikation | eindeutige Prozessbezeichnung; einordnung in Abstammungshierarchie |
|
||||||
| Scheduling | Informationen für Schedulingalgorithmen |
|
| Scheduling | Informationen für Schedulingalgorithmen |
|
||||||
| Prozessorkontext | gesichert bei Verdrängung des Prozesses, restauriert bei Reaktivierung |
|
| Prozessorkontext | gesichert bei Verdrängung des Prozesses, restauriert bei Reaktivierung |
|
||||||
@ -252,7 +252,7 @@ Implementierungsebenen
|
|||||||
| | Individualität: anwendungsindividuelle Thread Schedulingstrategien möglich |
|
| | Individualität: anwendungsindividuelle Thread Schedulingstrategien möglich |
|
||||||
| | Portabilität |
|
| | Portabilität |
|
||||||
|
|
||||||
es gibt Work-Arounds: alle gefählrichen Systemaufrufe einpacken (in Pakete)
|
es gibt Work-Arounds: alle gefährlichen Systemaufrufe einpacken (in Pakete)
|
||||||
|
|
||||||
Wahl zwischen ULT- und KLT hängt ab von:
|
Wahl zwischen ULT- und KLT hängt ab von:
|
||||||
1. Vorraussetzung: Prozessmodell des Betriebssystems Multithread Modell?
|
1. Vorraussetzung: Prozessmodell des Betriebssystems Multithread Modell?
|
||||||
@ -273,6 +273,13 @@ Threads können
|
|||||||
- kurzfristig warten (Bsp. benötigt keinen Prozesoor aber Arbeitsspeicher)
|
- kurzfristig warten (Bsp. benötigt keinen Prozesoor aber Arbeitsspeicher)
|
||||||
- langfristig warten (Bsp. benötigt länger keinen Prozessor/Arbeitsspeicher)
|
- langfristig warten (Bsp. benötigt länger keinen Prozessor/Arbeitsspeicher)
|
||||||
|
|
||||||
|
Threadzustände im 3/5-Zustandsmodell
|
||||||
|
- bereit: kann aktiv werden, sobald Prozessor frei wird
|
||||||
|
- aktiv: besitzt einen Prozessor, arbeitet
|
||||||
|
- blockiert: wartet auf Ereignis (Timer Ablauf,...)
|
||||||
|
- frisch: erzeugt, Betriebsmittel/Rechte zum Ablauf fehlen noch
|
||||||
|
- beendet: Betriebsmittel in der Freigabephase
|
||||||
|
|
||||||
Folge: effizientes Ressourcenmanagement benötigt präzise Informationen über Threadzustände.
|
Folge: effizientes Ressourcenmanagement benötigt präzise Informationen über Threadzustände.
|
||||||
|
|
||||||
## Aufgabe der Zustandsmodelle
|
## Aufgabe der Zustandsmodelle
|
||||||
@ -288,3 +295,214 @@ Nutzung
|
|||||||
Beschreibungsmittel: endliche deterministische Automaten
|
Beschreibungsmittel: endliche deterministische Automaten
|
||||||
- Menge der annehmbaren Zustände ist endlich
|
- Menge der annehmbaren Zustände ist endlich
|
||||||
- Folgezustand ist immer eindeutig bestimmt
|
- Folgezustand ist immer eindeutig bestimmt
|
||||||
|
|
||||||
|
## Scheduleraktivierung
|
||||||
|
Wann wird die letzte Scheduling-Entscheidung überprüft?
|
||||||
|
1. Prozess/Thread erzeugung (neuer, rechenbereiter Thread)
|
||||||
|
2. Threadterminierung, Threadblockierung (ein Prozessor wird frei)
|
||||||
|
3. Ereigniseintritt (Thread wird rechenbereit)
|
||||||
|
4. Wechsel von Prioritäten (in prioritätenbastierten Schedulingalgorithmen)
|
||||||
|
5. periodisch (in zeitscheibenbasierten Schedulingalgorithmen)
|
||||||
|
|
||||||
|
Ein Kontextwechsel umfasst:
|
||||||
|
- bei Wechsel zwischen Threads desselben Prozesses
|
||||||
|
- Stackkontext
|
||||||
|
- Prozessorregister
|
||||||
|
- floating point unit (hohe Kosten)
|
||||||
|
- zusätzlicher Wechsel zwischen Threads verschiedener Prozesse
|
||||||
|
- Speicherlayout (sehr hohe Kosten)
|
||||||
|
- starke Auswirkungen auf
|
||||||
|
- Gesamtperformanz
|
||||||
|
- Reaktivität
|
||||||
|
- Echtzeiteigenschaften
|
||||||
|
|
||||||
|
Kostenfaktor FPU
|
||||||
|
- Kopieren des FPU-Kontexts: sehr viele Register (sofortkosten)
|
||||||
|
- Realisierung: "faul"
|
||||||
|
- Hardware hilft: FPU Protextion
|
||||||
|
- Auswirkung
|
||||||
|
- nur ein THread benutzt FPU: tatsächliches Sichern erfolgt nie
|
||||||
|
- wenige Threads benutzen FPU: tatsächliches Sichern minimiert
|
||||||
|
|
||||||
|
## Scheduling Strategien
|
||||||
|
Strategische Ziele
|
||||||
|
- abhängig vom Einsatzfeld eines Betriebssystems
|
||||||
|
- Echtzeitsysteme: Einhaltung von Fristen
|
||||||
|
- interaktive Systeme: Reaktivität
|
||||||
|
- Serversysteme: Reaktivität, E/A-Performanz
|
||||||
|
- Batch-Verarbeitungssysteme: Durchsatz
|
||||||
|
- ergänzt durch allgemeine Ziele
|
||||||
|
- Fairness: Threads bekommen einen fairen Anteil an Rechenzeit
|
||||||
|
- Lastbalancierung: alle Systemkomponenten (CPUs, Speicher, E/A-Peripherie) sind gleichmäßig ausgelastet
|
||||||
|
- Overhead: z.B. wenig Prozesswechsel
|
||||||
|
- Ausbalancierung mehrerer Ziele
|
||||||
|
- multikriterielle Optimierungsaufgabe, i.d.R. NP-vollständig
|
||||||
|
- heuristische Scheduling-Algorithmen
|
||||||
|
|
||||||
|
Typische Muster aktiver Threadphasen:
|
||||||
|
- CPU lastig (mathematische Berechnung, Verschlüsselung,...)
|
||||||
|
- E/A lastig (interaktiver Prozess, ...)
|
||||||
|
- periodische Last (Echtzeitvideoverarbeitung, ...)
|
||||||
|
- chaotische Last (server mit inhomogenen Diensten)
|
||||||
|
|
||||||
|
Differenzierte Scheduling-Strategien
|
||||||
|
- nutzen Wissen über Lastmuster zur Optimierung, z.B.
|
||||||
|
1. Einhaltung von Fristen
|
||||||
|
2. Minimierung der Thread/Prozesswechsel
|
||||||
|
|
||||||
|
### Batch-System („Stapelverarbeitungs“-System)
|
||||||
|
- Aufträge: in Gruppen („Stapel“) eingeteilt u. so verarbeitet
|
||||||
|
- Abarbeitung: ohne aktive Mitwirkung eines Benutzers (Gegensatz: interaktiv)
|
||||||
|
- ursprünglich: frühe Entwicklungsstufe von Betriebssystemen
|
||||||
|
|
||||||
|
Ziele hier
|
||||||
|
1. Auslastung teurer Betriebsmittel (i.d.R. Maximierung der CPU-Auslastung)
|
||||||
|
2. Minimierung der Scheduling-Kosten (wenig Prozesswechsel, kurze Laufzeit des Scheduling-Algorithmus)
|
||||||
|
3. Maximierung des Durchsatzes (erledigte Arbeit / Zeit)
|
||||||
|
|
||||||
|
zwei der bekannteren:
|
||||||
|
1. First Come, First Served (FCFS)
|
||||||
|
- in Reihenfolge, in der Threads rechenbereit werden
|
||||||
|
- extrem einfache Strategie, guter Durchsatz
|
||||||
|
- nicht immer sehr klug
|
||||||
|
2. Shortest Remaining Time Next (SRTN)
|
||||||
|
- Prozessor erhält Thread mit voraussichtlich kürzester Restrechenzeit
|
||||||
|
- preemptiv* ) , d.h. Threads können von konkurrierenden Threads verdrängt werden
|
||||||
|
- (Schätzwert über) Restlaufzeit muss vorliegen
|
||||||
|
|
||||||
|
### Interaktives System
|
||||||
|
- Benutzer: kann bei Programmabarbeitung in Aktivitäten des Computers eingreifen
|
||||||
|
- Abarbeitung: mit aktiver Mitwirkung eines Benutzers (Gegensatz: batch processing)
|
||||||
|
- fortgeschrittenere Betriebssystem-Technik
|
||||||
|
|
||||||
|
Ziele hier
|
||||||
|
1. Minimierung von Reaktionszeiten (subjektiver Eindruck von Performanz)
|
||||||
|
2. Fairness (mehrere Benutzer/Klienten)
|
||||||
|
|
||||||
|
Algorithmen: Round Robin Varianten
|
||||||
|
- jeder Thread: bekommt ein gleich großes Teil „des Kuchens“: die Zeitscheibe
|
||||||
|
- einfach zu implementieren (1 Warteschlange, Uhr)
|
||||||
|
- geringe Algorithmuskosten (O(1): FIFO-Warteschlange, Ring)
|
||||||
|
- schnelle Entscheidungen (O(1): Nr. 1 aus Warteschlange)
|
||||||
|
- notwendiges Wissen gering (CPU-Nutzungsdauer des aktiven Threads)
|
||||||
|
|
||||||
|
#### Einbeziehung von Prioritäten
|
||||||
|
Ziel: Ausdrucksmöglichkeit der Wichtigkeit von Threads
|
||||||
|
1. niedrig: z.B.
|
||||||
|
- Dämonen (die z.B. im Hintergrund Emails abrufen)
|
||||||
|
- Putzarbeiten (z.B. Defragmentierung)
|
||||||
|
2. hoch: z.B.
|
||||||
|
- auf Aufträge reagierende Threads (z.B. in Servern)
|
||||||
|
- auf Benutzereingaben reagierende Threads (z.B. aktives Fenster einer GUI)
|
||||||
|
- unter Echtzeitbedingungen arbeitende Threads (z.B. Motormanagement, DVD-Spieler)
|
||||||
|
|
||||||
|
Idee(n)
|
||||||
|
1. jeder Thread: erhält individuelle Priorität
|
||||||
|
2. Threads der höchsten Prioritäten: erhalten einen Prozessor
|
||||||
|
3. zwischen Threads gleicher Priorität: Round-Robin
|
||||||
|
|
||||||
|
viele Varianten dieses Schemas
|
||||||
|
- statische Prioritäten, z.B. in
|
||||||
|
- planbaren Echtzeitsystemen (Autoradio: Reaktion auf Stationswechseltaste hat Vorrang vor Senderfeldstärkenüberwachung)
|
||||||
|
- kommerziellen Rechenzentren (wer mehr zahlt, ist eher an der Reihe)
|
||||||
|
- dynamische Prioritäten, abhängig z.B. von
|
||||||
|
- verbrauchter CPU-Zeit (Verhinderung der Dominanz)
|
||||||
|
- E/A-Intensität
|
||||||
|
- Wartegrund
|
||||||
|
|
||||||
|
### Schedulingziele in Echtzeitsystemen
|
||||||
|
Finden einer Bearbeitungsreihenfolge (ein „Schedule“),
|
||||||
|
- die Fristen einhält
|
||||||
|
- deren Berechnung ökonomisch ist (Kosten des Scheduling-Algorithmus)
|
||||||
|
- die selbst ökonomisch ist (Minimierung der Threadwechsel)
|
||||||
|
- die sich (evtl.) an wechselnde Lastmuster anpasst
|
||||||
|
|
||||||
|
Verbreitete Algorithmen
|
||||||
|
- EDF: früheste Frist zuerst (earliest deadline first)
|
||||||
|
- für dynamische Lasten
|
||||||
|
- wird ein Thread rechenbereit, so „nennt“ er seine nächste Deadline (Frist)
|
||||||
|
- von allen bereiten Threads ist immer derjenige mit der frühesten Deadline aktiv (dringend=wichtig)
|
||||||
|
- Folglich
|
||||||
|
- arbeitet der Algorithmus mit dynamischen Prioritäten → adaptiv
|
||||||
|
- ist die Thread-Priorität um so höher, je näher dessen Frist liegt
|
||||||
|
- ist er preemptiv
|
||||||
|
- Voraussetzung: kausale und zeitliche Unabhängigkeit der Threads (keine wechselseitige Blockierung)
|
||||||
|
- RMS: Raten-monotones Scheduling (rate-monotonic scheduling)
|
||||||
|
- für periodische Lasten (z.B. Mischpult, DVD-Spieler, technische Prozesse)
|
||||||
|
- wird ein Thread rechenbereit, so „nennt“ er seine Periodendauer
|
||||||
|
- von allen bereiten Threads ist immer derjenige mit der kürzesten Periodendauer aktiv
|
||||||
|
- Folglich:
|
||||||
|
- arbeitet der Algorithmus mit statischen Prioritäten
|
||||||
|
- ist die Thread-Priorität um so höher, je kürzer die Periodendauer ist
|
||||||
|
- ist er preemptiv
|
||||||
|
- Voraussetzung: periodische Threads; kausale und zeitliche Unabhängigkeit der Threads
|
||||||
|
|
||||||
|
## Zusammenfassung
|
||||||
|
Anzahl der Threads >> Anzahl der Prozessoren
|
||||||
|
- nicht alle können gleichzeitig rechnen
|
||||||
|
- eine Auswahl muss getroffen werden
|
||||||
|
- → Auswahlstrategie: Schedulingalgorithmen
|
||||||
|
|
||||||
|
# Privilegierungsebenen
|
||||||
|
Problematik: Anwendungsprozesse und Betriebssystem nutzen gemeinsame (Hardware-)Ressourcen
|
||||||
|
|
||||||
|
Schutz vor fehlerbedingten oder bösartigen räumlichen/zeitlichen Wechselwirkungen
|
||||||
|
|
||||||
|
2 Konzepte
|
||||||
|
1. private Adressräume
|
||||||
|
2. Zugriffsschutz auf Arbeitsspeicherbereiche
|
||||||
|
|
||||||
|
Verhinderung zeitlicher Wechselwirkungen
|
||||||
|
- Ursache: Prozesse geben freiwillig keine Prozessoren auf
|
||||||
|
- Umgang damit
|
||||||
|
- periodische Aktivierungen preemptiver Scheduler (Uhr)
|
||||||
|
- Scheduler-Aktivierungen durch asynchrone Ereignisse
|
||||||
|
- kritisch also: Operationen zum Abschalten von
|
||||||
|
1. Uhr
|
||||||
|
2. Ereignismanagement (s. Kap. 5.4)
|
||||||
|
- weitere kritische Operationen
|
||||||
|
1. Veränderung des Speicherlayouts
|
||||||
|
2. Veränderung kritischer Prozessorkontrollregister
|
||||||
|
3. Zugriff auf E/A-Geräte
|
||||||
|
- notwendig: Schutz kritischer Operationen des Instruktionssatzes
|
||||||
|
|
||||||
|
Lösungskonzept: Privilegierungsebenen ablaufender Aktivitäten, z.B.
|
||||||
|
- „kernel mode“ (≈ Betriebssystem-Modus)
|
||||||
|
- „user mode“ (Nutzer-Modus)
|
||||||
|
- ermöglichen: Durchsetzung von Regeln:
|
||||||
|
- „Nur eine im „kernel mode“ ablaufende Aktivität hat Zugriff auf ...“
|
||||||
|
- Privilegierungsebenen steuern Rechte ...
|
||||||
|
1. zur Ausführung privilegierter Prozessorinstruktionen
|
||||||
|
2. zur Konfiguration des Arbeitsspeicher-Layouts
|
||||||
|
3. zum Zugriff auf Arbeitsspeicherbereiche
|
||||||
|
4. zum Zugriff auf E/A-Geräte
|
||||||
|
|
||||||
|
Realisierung: abhängig von Prozessorarchitektur
|
||||||
|
- in Ringen 0 (höchste Priorität) bis 3 (niedrigste Priorität)
|
||||||
|
|
||||||
|
Implementierung: Hardware-Unterstützung
|
||||||
|
- aktuelle Privilegierungsebene ist
|
||||||
|
- Teil des Prozessor-Statusregisters: „Current Privilege Level“ (CPL)
|
||||||
|
- Grundlage der Hardware-Schutzmechanismen; permanente Überwachung
|
||||||
|
- der ausgeführten Instruktionen
|
||||||
|
- der Arbeitsspeicherzugriffe
|
||||||
|
- der E/A-Peripheriezugriffe
|
||||||
|
- Modifikation des CPLs nur
|
||||||
|
1. durch privilegierte Instruktionen
|
||||||
|
2. bei Beginn und Abschluss
|
||||||
|
- des Aufrufs von Systemdiensten
|
||||||
|
- einer Ereignisbehandlung
|
||||||
|
|
||||||
|
Botschaften
|
||||||
|
- jede auf Privilegierungsebene < 3 ablaufende Aktivität hat Zugriff auf kritische Ressourcen
|
||||||
|
- jede auf Privilegierungsebene 0 ablaufende Aktivität hat Zugriff auf
|
||||||
|
1. sämtliche Ressourcen eines Prozessors
|
||||||
|
- sämtliche Instruktionen (z.B. HALT)
|
||||||
|
- sämtliche Prozessorregister (z.B. Prozessor-Status-Register (PSR) )
|
||||||
|
2. MMU-Register zur Arbeitsspeicherkonfiguration
|
||||||
|
3. sämtliche Register der E/A-Peripherie
|
||||||
|
|
||||||
|
Sämtliche Schutz- und Sicherheitsmechanismen von
|
||||||
|
- Anwendungsprozessen
|
||||||
|
- Betriebssystem
|
||||||
|
beruhen elementar auf 2 Bits: „Current Privilege Level“ (CPL) im Prozessor-Status-Register (PSR)
|
Loading…
Reference in New Issue
Block a user