Scheduling Kapitel

This commit is contained in:
Robert Jeutter 2020-11-10 09:05:57 +01:00
parent efa1f425b2
commit ee6aaea71a

View File

@ -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)