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)
|
||||
b. Prozessdeskriptortabelle: Deskriptioren sämtlicher Prozesse
|
||||
|
||||
| Prozessormanagement | |
|
||||
| Prozessormanagement (Prozessdeskriptor) | |
|
||||
| Identifikation | eindeutige Prozessbezeichnung; einordnung in Abstammungshierarchie |
|
||||
| Scheduling | Informationen für Schedulingalgorithmen |
|
||||
| Prozessorkontext | gesichert bei Verdrängung des Prozesses, restauriert bei Reaktivierung |
|
||||
@ -252,7 +252,7 @@ Implementierungsebenen
|
||||
| | Individualität: anwendungsindividuelle Thread Schedulingstrategien möglich |
|
||||
| | 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:
|
||||
1. Vorraussetzung: Prozessmodell des Betriebssystems Multithread Modell?
|
||||
@ -273,6 +273,13 @@ Threads können
|
||||
- kurzfristig warten (Bsp. benötigt keinen Prozesoor aber 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.
|
||||
|
||||
## Aufgabe der Zustandsmodelle
|
||||
@ -288,3 +295,214 @@ Nutzung
|
||||
Beschreibungsmittel: endliche deterministische Automaten
|
||||
- Menge der annehmbaren Zustände ist endlich
|
||||
- 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