Betriebssysteme Kap. 2: Prozessmanagement

Transkript

1 Betriebssysteme, WS 2016/17 wk Betriebssysteme Kap. 2: Prozessmanagement Winfried E. Kühnhauser Wintersemester 2016/17 Winfried E. Kühnhauser CSI Technische Universität Ilmenau

2 Roadmap Anwendungsebene GUI MatLab Office Safari Google Earth Firefox Anwendungsschnittstelle (Application Programmer s Interface, API) Betriebssystem Betriebssystem-Dienste Prozessmanagement Dateimanagement Netzwerkmanagement Prozessor- Ressourcen Ressourcenmanagement Kommunikations- Ressourcen Speicher- Ressourcen E/A Ressourcen Betriebssysteme, WS 2016/17 wk Prozessmanagement

3 Grundsätzliches Computer bearbeiten Aufgaben in wohldefinierten Arbeitsabläufen beschrieben durch Programme: Algorithmen, präzise definiert mittels formaler Programmiersprachen (C++, Java...) beim Ablauf von Programmen entstehen oft Wartesituationen Powerpoint wartet auf Tastatureingaben -Klient wartet auf eintreffende s Wartezeiten sind relativ zur Prozessorgeschwindigkeit gigantisch (1 Sek Prozessorzyklen) statt schlicht zu warten, lässt sich besseres tun parallele Ausführung mehrerer Aufgaben Was so läuft Betriebssysteme, WS 2016/17 wk Prozessmanagement

4 Parallelität geht nicht immer (duschen und abtrocknen ) Voraussetzung dazu: Nebenläufigkeit Begriffe 1. Aktivitäten heißen nebenläufig, wenn zwischen ihnen keine kausalen Abhängigkeiten bestehen (= kausal unabhängig ) 2. Aktivitäten heißen parallel, wenn sie zeitlich überlappend durchgeführt werden Nebenläufigkeit ist Voraussetzung für Parallelität Powerpoint und -Klient Powerpoint und Fileserver Betriebssysteme, WS 2016/17 wk Prozessmanagement

5 2.1 Prozesse ? ? ? ? Trotz kausaler Unabhängigkeit der Aufgaben: Paralleles Arbeiten auf kognitiver Ebene ist (für Menschen) schwierig Unser Umgang damit Wir sequenzialisieren 1. Zerlegung der Aufgabe in 4 (eigentlich parallel ausführbare) Aktivitäten 2. Sequenzielle Abarbeitung dieser 4 Aktivitäten Computer dagegen können parallel arbeiten Idee der Prozessmodelle von BSen Betriebssysteme, WS 2016/17 wk Prozesse

6 Definition Prozess (vorläufig, bis wir wissen, was Threads sind) Ein Prozess ist eine BS-Abstraktion zur vollständigen Beschreibung einer sequenziell ablaufenden Aktivität. Dazu gehört insbesondere das ausgeführte Programm und dessen Bearbeitungszustand die notwendigen Betriebsmittel (Prozessor/Speicher/Kommunikationsressourcen) die notwendigenrechte (Nutzung von Diensten, Dateien, Kommunikationsports) Parallele Aktivitäten werden repräsentiert durch parallele Prozesse: ? ? ? ? Betriebssysteme, WS 2016/17 wk Prozesse

7 2.1.1 Prozessmodelle In a Nutshell Prozess = BS-Abstraktion zur Ausführung von Programmen Prozessmodelle definieren konkrete Prozesseigenschaften ( BS-spezifisch) Prozessmanagement BS-Baustein, der das Prozessmodell eines BS implementiert Betriebssysteme, WS 2016/17 wk Prozessmodelle

8 Prozessmodelle Aufgabe präzise Definition der BS-Abstraktion Prozess definiert durch Semantik der Operationen auf Prozessen Erzeugen, Beenden, Anhalten, Fortsetzen, nichtfunktionale Eigenschaften von Prozessen Safety- und Securityeigenschaften Echtzeiteigenschaften implementiert durch Datenstrukturen Algorithmen des Prozessmanagements Betriebssysteme, WS 2016/17 wk Prozessmodelle

9 Prozessmanagement Anwendungsebene GUI MatLab Office Safari Google Earth Firefox Anwendungschnittstelle (Application Programmer s Interface, API) Betriebssystem-Dienste Betriebssystem Prozessmanagement Speichermanagement Kommunikationsmanagement Prozessor- Ressourcen Ressourcenmanagement Speicher- Ressourcen Kommunikations- Ressourcen div. E/A Ressourcen Betriebssysteme, WS 2016/17 wk Prozessmodelle

10 Prozessmanager seziert Prozessmanagement class ProcessManager {! public:!!createprocess(program)!!{!...!!}!!!terminateprocess(process)!!{!...!!}!!...! private:!!processdescriptortable...! }! Betriebssysteme, WS 2016/17 wk Prozessmodelle

11 2.1.2 Prozesserzeugung Prozesserzeugung: Erzeugen einer Programmablaufumgebung Anwendungsebene GUI CreateProcess()! Google Earth Anwendungsschnittstelle (Application Programmer s Interface, API) Betriebssystem-Dienste Betriebssystem Prozessmanagement Speichermanagement Kommunikationsmanagement Prozessor- Ressourcen Ressourcenmanagement Speicher- Ressourcen Kommunikations- Ressourcen div. E/A Ressourcen Betriebssysteme, WS 2016/17 wk Prozesserzeugung

12 Anwendersicht mittels GUIs: Mausklick auf ein Symbol Google Earth mittels textbasierter Kommandointerpreter ( Shell )!!kandooma> googleearth! was letztendlich immer geschieht: Systemaufruf!! if (fork() == 0 execve( /usr/bin/googleearth,...) Betriebssysteme, WS 2016/17 wk Prozesserzeugung

13 Resultierende Aktionen des Prozessmanagements Prüfen notwendiger Voraussetzungen Rechte, Ressourcenverfügbarkeit Namensvergabe und Stammbaumpflege Allokation von Ressourcen, z.b. Arbeitsspeicher, Prozessorzeit Anlegen von Managementdatenstrukturen Rechte, Ressourcen Laufzeitmanagement; u.a. Ablaufzustand, eingetretene Ereignisse Betriebssysteme, WS 2016/17 wk Prozesserzeugung

14 Notwendige Voraussetzungen (prozessmodellspezifisch) Rechte zur Ressourcennutzung Arbeitsspeicher, Rechenzeit, Kommunikation Sicherheit Authentizität und Integrität des auszuführenden Programms Prüfung digitaler Signaturen Echtzeit Erfüllbarkeit von Ressourcenanforderungen Einhaltung gegebener Garantien Basis: Lastbeschreibungen Fairness Quoten Robustheit/Überlastvermeidung Lastsituation Betriebssysteme, WS 2016/17 wk Prozesserzeugung

15 z.b. Unix/Windows Systemfamilien: Prozessidentifikation ist positive ganze Zahl Namensvergabe und Stammbaumpflege (prozessmodellspezifisch) Vergabealgorithmus variiert; z.b. zyklisch [0, 32000] kann nach Terminierung eines Prozesses erneut vergeben werden eindeutig zu einem Zeitpunkt bzgl. aller existierenden Prozesse nicht unbedingt eindeutig für zeitlich nicht überlappende Prozesse erst recht nicht eindeutig über Systemgrenzen hinweg Was so läuft Betriebssysteme, WS 2016/17 wk Prozesserzeugung

16 Abstammungsbeziehungen definieren Eltern/Kind-Hierarchie Prozess erzeugt weitere Prozesse: seine Kinder diese wiederum erzeugen weitere Prozesse usw. baumartige Abstammungshierarchie Nutzung: Rechte und Verantwortlichkeiten Ur- Prozess (erzeugt beim Systemstart ( launchd, init ) Betriebssysteme, WS 2016/17 wk Prozesserzeugung

17 Verwaiste Prozesse Adoption; Unix-Technik: durch Urprozess Ur- Prozess Ur- Prozess Betriebssysteme, WS 2016/17 wk Prozesserzeugung

18 Allokation von Ressourcen 1. Arbeitsspeicher wie viel Arbeitsspeicher benötigt der neue Prozess? Größe Zeitpunkt: zu welchem Zeitpunkt erhält er ihn? Echtzeiteigenschaften (Planbarkeit) Performanz (Proaktivität) Isolation: wie ist er (vor anderen Prozessen) geschützt? Robustheit, Sicherheit, Korrektheit Antworten sind prozessmodellspezifisch; Varianten: Speichermanagement, Kap. 3 High-End Betriebssysteme, Kap. 7 Betriebssysteme, WS 2016/17 wk Prozesserzeugung

19 Ein kurzer Ausflug Arbeitsspeicherallokation minimal beim Prozessablauf erforderlich Code des ausgeführten Programms Text Segment Speicher für Programmvariablen (Integers, Strings, Klasseninstanzen ) Datensegment Organisation des dynamischen Programmablaufs Heap Segment Stack Segment Arbeitsspeicher komplexer Prozesse (e.g. mit Threads, shared libraries) können solche Segmente vielfach enthalten Textsegment(e) Daten-(Heap-) Segment(e) Stacksegment(e) Betriebssysteme, WS 2016/17 wk

20 Repräsentation ausführbarer Programme Quellcode: C/C++/Java- Programm Textdatei Compiler Objekt- Code Bibliothek Linker ausführbares Programm z.b. im ELF-Format * ) Dateien auf persistentem Speicher (z.b. Festplatte) Magie (Formathinweise) Programmcode initialisierte Daten uninitialisierte Daten Startadresse (IP) Symboltabellen, z.b. firstint: #0! secondint: #4! grusstext: #8! h e l l o Kopf Infos zum Binden, Debuggen vom Compiler/ Linker erzeugter Programmcode vom Compiler initialisierte Daten * ) Executable and Link Format Betriebssysteme, WS 2016/17 wk Prozesserzeugung

21 Arbeitsspeicher-Initialisierung ausführbare Programmdatei Magie Programcode initialisierte Daten uninitialisierte Daten Startadresse Symboltabellen, z.b. firstint: #0! secondint: #4! grusstext: #8! h e l l o Speicherlayout Textsegment(e) Daten-(Heap-) Segment(e) Stacksegment(e) vmmap Betriebssysteme, WS 2016/17 wk Dabei hilft die Speicherverwaltung Kap Prozesserzeugung

22 Damit dies korrekt funktioniert: präzise Formatvereinbarungen zwischen Linker (Programmdatei-Produzent) und Prozessmanagement (Programmdatei-Lader) Das a.out-format ursprüngliches Unix-Format veraltet, z.b. keine dynamisch gebundenen Bibliotheken (DLLs) Das Common Object File Format (COFF) Nachfolger des a.out-formats verbreitet vor allem in der Windows Welt Das Executable and Link(age/able) Format (ELF) heutiger Linux-Standard siehe Übungen Betriebssysteme, WS 2016/17 wk erkennbar an magic number Prozesserzeugung

23 Das a.out-format Kopf Textsegment Datensegment magic number text segment size data segment size bss segment size symbol table size program entry point text reloc table size data text reloc table size! struct exec {!!unsigned long a_midmag;!!unsigned long a_text;!!unsigned long a_data;!!unsigned long a_bss;!!unsigned long a_syms;!!unsigned long a_entry;!!unsigned long a_trsize;!!unsigned long a_drsize;! }! Text-Relokationsinfo Daten-Relokationsinfo Symboltabelle Betriebssysteme, WS 2016/17 wk Prozesserzeugung

24 Allokation des Arbeitsspeichers bei der Prozesserzeugung /* read header! Header=FileSystem.ReadHeader(ProgramFile);! if (Header.midmag==ELFmag) then {!!ELFHeader=Header;!!/* create and init text segment!!textsegmentaddr=vmm.createtextsegment(elfheader.textsize);!!filesystem.read (!ProgramFile,!!!!ELFHeader.TextSegmentOffset,!!!!ELFHeader.TextSize,!!!!TextSegmentAddr);!!/* create and init data segment...!!/* create stack segment...!!...!!pcb.textsegmentaddr=textsegmentaddr;!!pcb.textsegmentsize=elfheader.textsize;!!...! } elsif (Header.midmag==COFFmag) then {...! Betriebssysteme, WS 2016/17 wk Prozesserzeugung

25 Aufgabe in Prozessmodellen echtzeitfähiger Systeme (planbar) Allokation von Ressourcen 2. Prozessorzeit Planung und Bereitstellung von Prozessorzeit für einen Prozess Parameter: Größe: wie viel Prozessorzeit benötigt der neue Prozess? Zeitpunkt: wann wird Prozessorzeit benötigt? in Prozessmodellen ohne diese Eigenschaften dynamisches ad-hoc-scheduling Strategien beeinflussen massiv die nichtfunktionalen BS-Eigenschaften Scheduling-Algorithmen in Kap. 2.3 Betriebssysteme, WS 2016/17 wk Prozesserzeugung

26 Management-Datenstrukturen Aufgabe Buchführung über sämtliche zum Management eines Prozesses notwendigen Informationen - Prozessidentifikation - Rechtemanagement - Speichermanagement (z.b. über Lage der Text/Daten/Stacksegmente) - Prozessormanagement (z.b. Lastprofil, Priorität, Ablaufzustand) Prozessdeskriptor (process control block, PCB) Prozessdeskriptortabelle: Prozessdeskriptoren sämtlicher Prozesse Man kann Prozessdeskriptoren ansehen Mac: Aktivitätsanzeige, ps -axl! Linux/Gnome GUI: Systemüberwachung, ps -axl Windows: Task Manager Betriebssysteme, WS 2016/17 wk Prozesserzeugung

27 Ein typischer Prozessdeskriptor Prozessormanagement Identifikationen Prozessidentifikation Prozessidentifikation des Erzeugers Scheduling Prozesszustand Priorität, Lastbeschreibung,... Prozessorkontext ( Lesezeichen ) Programmzähler ( IP ) Stack Pointer ( SP ) Prozessorstatusregister ( PSR ) allgemeine Prozessorregister Ereignismanagement anstehende Ereignisse eingeplante Reaktionen Handler-Vektor Aufweckzeit Accounting Startzeit verbrauchte Prozessorzeit Ein/Ausgabevolumen eindeutige Prozessbezeichnung, Einordnung in Hierarchie Informationen für Schedulingalgorithmen gesichert bei Verdrängung des Prozesses, restauriert bei Reaktivierung z.b. die Privilegierungsebene relevant auch bei schlafenden Prozessen zur Prioritätenbestimmung, Statistik, Kostenberechnung oder Quotenbestimmung Betriebssysteme, WS 2016/17 wk Prozesserzeugung

28 Speichermanagement Virtueller Adressraum Programm(Text-)segment(e) Datensegment(e) Stacksegment(e) Shared Memory Segment(e) Seitentabelle Kernel Stack Rechtemanagement User-Id des Eigentümers Gruppen-Id des Eigentümers Security Contex (Capabilities, Attribute) Allgemeines Ressourcenmanagement Arbeitsdirectory Root-Directory Filedeskriptoren E/A-Parameter, Schutzbit-Masken, etc. Beschreibung des Speicherlayouts Prozedurmanagement innerhalb des BS Filedeskriptoren, Socketdeskriptoren,... mit Zustandsinformationen je Ressource: erworbene Rechte, Dateipositionspointer,... Betriebssysteme, WS 2016/17 wk Prozesserzeugung

29 Zusammenfassung Prozesserzeugung Aktionen des Prozessmanagements Prüfen notwendiger Voraussetzungen Authentizität, Rechte, Ressourcen (Speicher, Prozessorzeit) Namensvergabe und Stammbaum Allokation von Ressourcen (dabei helfen andere BS-Komponenten); i.w. Arbeitsspeicher (Speichermanagement) Prozessorzeit (Scheduler) strategische Algorithmen bestimmen NFEs: Robustheit, Reaktivität, Echtzeitverhalten, Sicherheit Irgendwo müssen wir uns all dies merken : Anlegen von Managementdatenstrukturen ( Prozessdeskriptor ) Ressourcenmanagement; u.a. Speicher, evtl. Prozessorzeit Rechtemanagement; u.a. Eigentümer, Zugriffsrechte Laufzeitmanagement; u.a. Ablaufzustand, eingetretene Ereignisse Betriebssysteme, WS 2016/17 wk Prozesserzeugung

30 2.1.3 Prozessterminierung Ursachen Selbstmord Aufgabe erledigt GUI: Logout Compilerlauf: Übersetzung eines Programms abgeschlossen Fehler aufgetreten und Weitermachen sinnlos logischer Fehler (z.b. Compiler: Quellcodedatei nicht gefunden) arithmetischer Fehler (z.b. Division durch 0) Betriebsmittelmangel (z.b. virtueller Speicher (s.u.) erschöpft) Mord und Totschlag nicht mehr gebraucht (z.b. Fenster schließen alle Prozesse im Fenster) Todesstrafe wegen schlimmer Vergehen (z.b. Speicherschutzverletzungen) Verklemmungsauflösung (s.u.) Betriebssysteme, WS 2016/17 wk Prozessterminierung

31 Techniken Selbstmord: Systemaufruf ans Prozessmanagement z.b. Unix: exit() explizit an beliebiger Stelle in einem Programm implizit nach Beenden des Programms (durch Laufzeitsystem) Mord und Totschlag: durch Eigentümer: per GUI: Fenster schließen _ Was so per Admin-Software (z.b. Windows Task Manager, Mac läuft ) per Kommandointerpreter (z.b. Unix, Mac: kill -9 <eine PID> ) per Systemaufruf aus einem ablaufenden Programm (z.b. Unix: kill(<pid>,sigkill) ; kill(getpid(),9) exit()) durch Betriebssystem: Nachricht an das Prozessmanagement, z.b. durch Speichermanagement ALU/Arithmetik-Koprozessor (FPU) Verklemmungsüberwachung Betriebssysteme, WS 2016/17 wk Prozessterminierung

32 Was geschieht bei einer Prozessbeendigung? Freigabe der Ressourcen Name, Speicher- und Prozessorreservierungen, geöffnete Dateien, Kommunikationsverbindungen Benachrichtigung der Eltern Techniken: Signale (IPC, s.u.), rückkehrende Systemaufrufe (z.b. wait()) Adoption der Kinder Ur- Prozess Ur- Prozess Betriebssysteme, WS 2016/17 wk Prozessterminierung

33 2.1.4 Zusammenfassung Elementares Prozessmanagement Prozessmodelle Definition der BS-Abstraktion Prozess durch Semantik der Operationen auf Prozessen nichtfunktionale Eigenschaften von Prozessen implementiert durch Operationen, Datenstrukturen, Algorithmen des Prozessmanagements Prozesserzeugung Allokation von Ressourcen Prozessterminierung Freigabe der Ressourcen und dazwischen Ablaufmanagement: Management-Datenstrukturen Betriebssysteme, WS 2016/17 wk Zusammenfassung

34 2.2 Threads Motivation Viele Anwendungssysteme enthalten nebenläufige Aktivitäten Server (Web-, Mail-, Datenbank-) bedienen gleichzeitig viele Klienten Netzwerk Algorithmen zur Lösung komplexer Probleme Lösung von Differentialgleichungen (Wetter) Multiplikation großer Matrizen (Computergrafik) Simulationen (Simulacron 3) Betriebssysteme, WS 2016/17 wk Threads

35 Naive Lösung für jede nebenläufige Aktivität spendieren wir einen Prozess Jedoch Prozesse sind dafür uncool Kosten des Managements (Ressourcenallokation) Kosten der Isolation (virtuelle private Adressräume, s.u.) Kosten der Kommunikation (IPC, s.u.) Parallelität mittels vieler Prozesse ist teuer revidiertes Prozessmodell Gesucht also: kostengünstigeres Modell zur Parallelisierung nebenläufiger Aktivitäten Betriebssysteme, WS 2016/17 wk Threads

36 2.2.1 Das Threadmodell Ursachenforschung Das bisherige Prozessmodell ist kostspielig, weil zwei sachlich unabhängige Konzepte zusammengefasst sind: Prozesse sind hier gleichzeitig die elementare Einheit der Parallelität die elementare Einheit des Ressourcenmanagements und Schutzes Modell historisch, nicht sachlich begründet Korrektur Trennung dieser Funktionen eine Abstraktion zum Management von Ressourcen (teuer) eine Abstraktion zum Management von Parallelität (preiswert) enter Threads Betriebssysteme, WS 2016/17 wk Das Threadmodell

37 Anwendungsbeispiel Multi-threaded Webserver Prozess mit vielen parallelen Aktivitäten, die alle die gleichen Rechte haben (z.b. Zugriff auf Datenbank mit Webseiten) alle die gleichen Ressourcen besitzen und sich teilen (z.b. Arbeitsspeicher, Webseitencache, Kommunikationswege zu Dateisystem/Datenbank) jede einzeln für sich z.b. einen individuellen Klienten betreut Klient Web-Server Klient Betriebssysteme, WS 2016/17 wk Das Threadmodell

38 Revision des bisherigen Prozessmodells Definition Prozess Ein (multi-threaded) Prozess ist eine vollständige Beschreibung einer sequentiell ablaufenden Aktivität. Dazu gehört insbesondere das ablaufende Programm und dessen Bearbeitungszustand zugeordnete Betriebsmittel (Prozessor/Speicher/Kommunikation) Rechte prozessinterne parallele Aktivitäten (Threads) und ihre Bearbeitungszustände. Definition Thread Ein Thread ist eine sequenzielle Aktivität im Betriebsmittelkontext eines Prozesses. Parallele Aktivitäten innerhalb eines Prozesses werden durch parallele Threads repräsentiert. Betriebssysteme, WS 2016/17 wk Das Threadmodell

39 Anmerkungen Eigentümer von Ressourcen und Rechten sind nach wie vor Prozesse das Programm eines Prozesses kann nun Code für mehr als nur eine sequenzielle Aktivität enthalten Gegenstand der Prozessorzuteilung sind nun Threads das ursprüngliche Prozessmodell ist eine Spezialisierung dieses Modells: ein Prozess mit genau einem Thread ( single-threaded ) Web-Server Betriebssysteme, WS 2016/17 wk Das Threadmodell

40 Anmerkungen cont d ein Prozessdeskriptor (PCB) eines multi-threaded-prozessmodells enthält alle Informationen des PCBs eines single-threaded-prozessmodells plus Informationen über alle seine Threads (je Thread ein Threaddeskriptor (TCB, thread control block )) ein TCB enthält lediglich Ablaufkontext (Programmzähler, Stackpointer, Prozessorregister) Threadzustand (aktiv, bereit, blockiert,...) insbesondere keine Beschreibung der Ressourcen (Speicherlayout, Rechte) Threads werden daher oft auch als Leichtgewichtsprozesse bezeichnet Betriebssysteme, WS 2016/17 wk Das Threadmodell

41 Varianten komfortabel: integriert in Programmiersprachen zu Fuß: Thread-Bibliotheken / Betriebssystem-API Integriert in Programmiersprachen, z.b. Ada: TASK BODY AServerThread IS! BEGIN!!LOOP!!!AwaitClientRequest(...);!!!HandleClientRequest(...);!!!ReplyToClient(...);!!UNTIL client disconnects;! END;! Programmieren mit Threads Wie treten Threads gegenüber Programmierern auf? Aufgabe des Ada-Compilers Abbildung der TASKs auf das multi-threaded Prozessmodell des BS (KLTs, s.u.) alternativ hinzufügen eines Laufzeitsystems mit eigenem Thread-Management (ULTs, s.u.) Betriebssysteme, WS 2016/17 wk Das Threadmodell

42 Zu Fuß, z.b. in einem C-Programm, eine Thread-Bibliothek nutzend #include <pthread.h>! void AServerThread()! {!repeat!!{!awaitclientrequest(...);!!!handleclientrequest(...);!!!replytoclient(...);!!}!!until client disconnects;! }!! main()! {!...! }! durch Thread ausgeführtes Programm, syntaktisch als Prozedur formuliert!whenever new client connects: phread_create(...,aserverthread,...);!!...! Aufgabe der Thread-Bibliothek (dieselbe wie die des Compilers) Abbildung des Prozedurkonstrukts auf das Prozessmodell des BS (KLTs, s.u.) alternativ hinzufügen eines Laufzeitsystems mit einem Thread-Management (ULTs, s.u.) Betriebssysteme, WS 2016/17 wk Das Threadmodell

43 2.2.2 Thread-Implementierungen Alternativen Prozessmodell des Betriebssystems ist multi-threaded Realisierung durch Betriebssystem (Kernel Level Threads, KLTs) Web-Server DB-Server API Prozessmgmt PCB- und TCB-Tabellen Betriebssysteme, WS 2016/17 wk Thread-Implementierungen

44 Prozessmodell des Betriebssystems ist single-threaded Realisierung auf Anwendungsebene (User Level Threads, ULTs) Web-Server Thread- Bibliothek DB-Server Thread- Bibliothek TCB-Tabelle TCB-Tabelle API Prozessmgmt PCB-Tabelle Betriebssysteme, WS 2016/17 wk Thread-Implementierungen

45 Pros und Kontras der beiden Implementierungsformen Pro ULT Web-Server Thread- Bibliothek DB-Server Thread- Bibliothek TCB-Tabelle TCB-Tabelle API Prozessmgmt PCB-Tabelle Performanz Thread-Management ohne Systemaufrufe Thread-Umschaltung ohne BS-Mitwirkung keine Kosten durch Systemaufruf-Overhead Individualität anwendungsindividuelle Thread-Schedulingstrategien möglich Portabilität Betriebssysteme, WS 2016/17 wk Thread-Implementierungen

46 Pro KLT Web-Server DB-Server API Prozessmgmt PCB- und TCB-Tabellen Performanz: Parallelität Nutzung von Mehrprozessor/Multicorearchitekturen keine Blockade der gesamten Anwendung durch blockierende Systemaufrufe Betriebssysteme, WS 2016/17 wk Thread-Implementierungen

47 Problematisch: ein blockierender Systemaufruf (z.b. E/A-Operation) legt den Aufrufer still bei ULTs ist dies ein Prozess, und damit alle seine Threads Web-Server Thread- Bibliothek (mit Scheduler) DB-Server Thread- Bibliothek (mit Scheduler) TCB-Tabelle TCB-Tabelle API Prozesse PCB-Tabelle Betriebssysteme, WS 2016/17 wk Thread-Implementierungen

48 Es gibt Work-Arounds Alle gefährlichen (=potenziell blockierenden) Systemaufrufe einpacken; Paket: Test, ob sie blockieren würden, riefe man sie auf nein: tatsächlicher Aufruf ja: Eintrag des Aufrufer-Threads in Warteliste, Threadwechsel; später dann Neuversuch Folge rewriting sämtlicher derartiger Systemaufrufe sehr ineffizient sehr plump es gibt aber keine Alternativen Betriebssysteme, WS 2016/17 wk Thread-Implementierungen

49 Fazit: Wer die Wahl hat... Wahl zwischen ULT- vs. KLT-Modells hängt ab von Voraussetzungen: Prozessmodell des BS multi-threaded? Anwendungsprofil: E/A-Profil, Parallelität, Portabilität, Individualität Betriebssysteme, WS 2016/17 wk Thread-Implementierungen

50 Anwendungsprofile Typische Thread-Szenarien (Server mit vielen Klienten) benutzen blockierende E/A-Operationen sehr häufig spricht gegen ULTs relativiert den Management-Overhead (Systemaufrufe) der KLTs: Threads warten oft auf die Fertigstellung von E/A-Operationen dies tun sie innerhalb des Betriebssystems also fallen zusätzliche Kosten für einen eigens zum Thread-Scheduling notwendigen Systemaufruf oft gar nicht an die bei KLTs höheren Kosten für eine Threaderzeugung können durch Thread-Pools eliminiert werden nutzen die Parallelität von Multicore-Prozessoren Fazit Es spricht vieles für multi-threaded Prozessmodelle und KLTs Betriebssysteme, WS 2016/17 wk Thread-Implementierungen

51 2.2.3 Zusammenfassung Sie kennen nun den Grund für die Existenz von Threads multi-threaded Prozessmodelle ihre Vor- und Nachteile Performanz Sicherheit und Robustheit Implementierungsebenen für Threads user level Threads kernel level Threads Pros und Kons dieser Varianten Performanz Portabilität Individualität Betriebssysteme, WS 2016/17 wk Zusammenfassung

52 2.3 Scheduling Das Problem Anzahl der Aktivitäten >> Anzahl der Prozessoren nicht alle können gleichzeitig arbeiten eine Auswahl muss getroffen werden Auswahlstrategie: Schedulingstrategie, ~algorithmus die Betriebssystemkomponente: Scheduler Welche Threads erhalten wann wie lange einen Prozessor zugeteilt Betriebssysteme, WS 2016/17 wk Scheduling

53 2.3.1 Zustandsmodelle Ziel Effizientes Ressourcenmanagement Threads können z.b. aktiv sein besitzen einen Prozessor rechenbereit sein hätten gerne einen Prozessor kurzfristig warten (z.b. auf Daten von Speichermedien) benötigen gerade keinen Prozessor, aber in Kürze Arbeitsspeicher langfristig warten (z.b. Klientenauftrag, Timerablauf) benötigen keinen Prozessor / Arbeitsspeicher Folge Effizientes Ressourcenmanagement benötigt präzise Informationen über derartige Threadzustände Betriebssysteme, WS 2016/17 wk Zustandsmodelle

54 Aufgabe der Zustandsmodelle Beschreibung des Ablaufzustands von Threads (aktiv, bereit, kurz wartend,...) der möglichen Zustandsübergänge (z.b. bereit aktiv, aktiv kurz wartend,...) Nutzung jeder Thread ist zu jedem Zeitpunkt in genau einem dieser Zustände jeder Thread wechselt seinen Zustand gemäß der im Modell definierten Zustandsübergänge, hervorgerufen z.b. durch Zuteilung eines Prozessors (bereit aktiv) Eintritt von Wartegründen (aktiv wartend) Ressourcenmanagement nutzt Zustände als Informationsquelle für strategische Entscheidungen Betriebssysteme, WS 2016/17 wk Zustandsmodelle

55 Beschreibungsmittel Endliche deterministische Automaten a b ready! c d suspended! e f active! waiting! g Implementierung Automat ist implementiert im Prozessmanagement Threadzustand (ist Teil des Threaddeskriptors) Zustandsübergangsfunktion Betriebssysteme, WS 2016/17 wk Zustandsmodelle

56 Threadzustände im 3/5-Zustandsmodell bereit: kann aktiv werden, sobald Prozessor frei wird aktiv: besitzt einen Prozessor, arbeitet blockiert: wartet auf Ereignis (E/A, Timer-Ablauf,...) frisch: erzeugt, Betriebsmittel/Rechte zum Ablauf fehlen noch beendet: Betriebsmittel in der Freigabephase frisch Zulassung bereit Scheduler: - Zuteilung - Entzug aktiv Beendigung beendet Ereignis Warten blockiert Beendigung Betriebssysteme, WS 2016/17 wk Zustandsmodelle

57 Verfeinerung: 7-Zustandsmodell Differenzierung der Wartegründe Prozess ausgelagert (besitzt temporär keinen Arbeitsspeicher) Prozess (z.b. durch Benutzer) temporär stillgelegt (benötigt keinen Prozessor) (längerfristige) Suspendierung Zuteilung/Entzug Zulassung Beendigung frisch bereit aktiv beendet Suspendierung/ Desuspendierung Ereignis Warten bereit/ suspendiert blockiert Ereignis Suspendierung/ Desuspendierung blockiert/ suspendiert Betriebssysteme, WS 2016/17 wk Zustandsmodelle

58 Reale Modelle: Varianten dieser Grundmodelle Beispiel: Unix System 5, Release 4 9-Zustandsmodell created genug Speicher ready Scheduler kernel running exit() zoombi zu wenig Speicher swap out/in wakeup() sleep() Systemaufruf ready/ swapped asleep/ in memory user running wakeup() swap out preempt continue asleep/ swapped preempted Betriebssysteme, WS 2016/17 wk Zustandsmodelle

59 Messages Zustandsmodelle Präzise Informationen über Threadzustand befördern Effizienz und Ökonomie des Prozessormanagements welche Threads wollen rechnen (Kandidatenvorrat für Zuteilung) wie viele Threads wollen rechnen (Last) wie kurzfristig werden für einen gegebenen Thread Prozessorressourcen benötigt... Effizienz und Ökonomie des Speichermanagements welche Informationen müssen wo im Speicher liegen (Zuteilungskandidaten) wie groß ist der Gesamtspeicherbedarf aller rechenbereiten Prozesse (Last) wie kurzfristig werden welche Speicherressourcen benötigt... Betriebssysteme, WS 2016/17 wk Zustandsmodelle

60 2.3.2 Scheduler Welche Threads erhalten wann wie lange einen Prozessor zugeteilt Scheduler strategiegesteuerte(r) - Zuteilung - Entzug eines Prozessors bereit aktiv Ereignis Warten blockiert Betriebssysteme, WS 2016/17 wk Scheduler

61 Arbeitsweise eines Schedulers Scheduler- Aktivierung z.b. Blockierung eines aktiven Threads Bereitwerden eines blockierten/ suspendierten Threads wakeup! asleep Auswahlstrategie: m aus n Threads (bei m Prozessoren) Zuteilung und Entzug Sichern des Threadkontexts in TCB MMU-Kontext (Speicher-Layout) Stackkontext Registerkontext Privilegierungsebene Restaurieren des neuen Threadkontexts aus TCB (Implementierung architekturabhängig) bereit aktiv Ereignis Warten blockiert Betriebssysteme, WS 2016/17 wk Scheduler

62 2.3.3 Scheduleraktivierungen Wann wird die letzte Schedulingentscheidung überprüft? Prozess/Threaderzeugung neuer, rechenbereiter Thread Threadterminierung, Threadblockierung ein Prozessor wird frei Ereigniseintritt Thread wird rechenbereit (Wegfall von Wartegründen) Wechsel von Prioritäten in prioritätenbasierten Schedulingalgorithmen periodisch in zeitscheibenbasierten Schedulingalgorithmen Scheduler- Aktivierung asleep Auswahlstrategie: m aus n Threads (bei m Prozessoren) Zuteilung und Entzug bereit aktiv Ereignis Warten blockiert Betriebssysteme, WS 2016/17 wk Scheduleraktivierungen

63 Ein Kontextwechsel umfasst Zuteilung und Entzug: Kontextwechsel Software meets Hardware bei Wechsel zwischen Threads desselben Prozesses Stackkontext; enthält u.a. IP und PSR (ALU-Flags, Privilegierungsebene) Prozessorregister floating point unit (FPU)-Kontext; sehr groß hohe Kosten zusätzlich bei Wechsel zwischen Threads verschiedener Prozesse Speicherlayout Sofortkosten: Herstellen des Speicherlayouts Sekundärkosten: TLB- und Cache-refill sehr (!) hohe Kosten; s. nachfolgendes Kapitel Kosten der Kontextwechsel auswirkungsreich auf Gesamtperformanz Reaktivität Echtzeiteigenschaften Scheduler- Aktivierung bereit Ereignis asleep Auswahlstrategie: m aus n Threads (bei m Prozessoren) Zuteilung und Entzug blockiert aktiv Warten Betriebssysteme, WS 2016/17 wk Kontextwechsel

64 Kostenfaktor FPU Kopieren des FPU-Kontexts: sehr viele Register (IA-64: 2KByte) in TCB- Datenstrukturen (im Arbeitsspeicher!) Sofortkosten: Kopieroperationen Sekundärkosten: durch Cacheverschmutzung Realisierung: (da nicht jeder Thread die FPU benutzt:) faul, Hardware hilft: FPU-Protection besitzt / benutzt Thread A (aktiv) FPU Kontext A Thread A (passiv) besitzt FPU save Kontext A B Thread B (aktiv) benutzt restore Betriebssysteme, WS 2016/17 wk Kontextwechsel

65 Kostenfaktor FPU Kopieren des FPU-Kontexts: sehr viele Register (IA-64: 2KByte) in TCB- Datenstrukturen (im Arbeitsspeicher!) Sofortkosten: Kopieroperationen Sekundärkosten: durch Cacheverschmutzung Realisierung: (da nicht jeder Thread die FPU benutzt:) faul Hardware hilft: FPU-Protection Thread A (aktiv) Thread A (passiv) Thread B (aktiv) Auswirkung besitzt / benutzt FPU Kontext A nur ein Thread benutzt FPU: tatsächliches Sichern erfolgt nie wenige Threads benutzen FPU: tatsächliches Sichern minimiert Betriebssysteme, WS 2016/17 wk FPU Kontext A B besitzt / benutzt Kontextwechsel

66 Implementierung eines Threadwechsels Im Maschinenraum Für die Profis Z.B. in Linux auf einer Intel IA-64-Architektur (deren Intel-Implementierung: Itanium ) ia64_switch_to(struct task_struct *next)! Sichern des Ablaufkontexts des abzulösenden Threads in dessen TCB Restaurieren des Kontexts des neuen Threads aus dessen TCB hochperformante Implementierung: HW-architekturspezifisch, in Maschinencode Zum Nachlesen Mosberger, Eranian: IA-64 Linux Kernel Code: /usr/src/linux-<version>/arch/ia64/kernel/entry.s Betriebssysteme, WS 2016/17 wk Kontextwechsel

67 2.3.5 Schedulingstrategien Das Problem asleep Auswahlstrategie: m aus n Threads (bei m Prozessoren) Zuteilung und Entzug bereit aktiv Ereignis Warten blockiert Betriebssysteme, WS 2016/17 wk Schedulingstrategien

68 Strategische Ziele abhängig vom Einsatzumfeld 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: rechenbereite Threads bekommen ein faires Maß an Rechenzeit Lastbalancierung: alle Systemkomponenten (CPUs, Speicher, E/A- Peripherie) sind gleichmäßig ausgelastet Ausbalancierung mehrerer Ziele multikriterielle Optimierungsaufgabe, i.d.r. NP-vollständig heuristische Scheduling-Algorithmen Betriebssysteme, WS 2016/17 wk Schedulingstrategien

69 Lastmuster Typische Muster aktiver Threadphasen CPU-lastiger Thread z.b. mathematische Berechnungen, Bildcodierung, Verschlüsselung E/A - lastiger Thread z.b. interaktive Prozesse, Klienten, (wenig belastete) Serverthreads periodische Last P P P P z.b. Anlagensteuerung, Echtzeitverarbeitung von (Audio-, Video-, Sensor-) Datenströmen chaotische Last Server mit inhomogenen Diensten : Aktivphase Betriebssysteme, WS 2016/17 wk Schedulingstrategien

70 Differenzierte Schedulingstrategien nutzen Wissen über Lastmuster zur Optimierung; z.b. Minimierung der Thread/Prozesswechsel Frist Frist Frist Frist periodische Last (wichtig) periodische Last (weniger wichtig) prio-basierter Schedule multikriterieller Schedule 18 Pw. 13 Pw. Betriebssysteme, WS 2016/17 wk Schedulingstrategien

71 Schedulingstrategien für Batch-Systeme Ziele Auslastung teurer Betriebsmittel - i.d.r. Maximierung der CPU- Auslastung Minimierung der Scheduling-Kosten wenig Prozesswechsel kurze Laufzeit des Scheduling-Algorithmus Maximierung des Durchsatzes (erledigte Arbeit / Zeit) Algorithmen... gibt es sehr viele; zwei der bekannteren: First Come, First Served (FCFS) Shortest Remaining Time Next (SRTN) Betriebssysteme, WS 2016/17 wk Schedulingstrategien

72 First Come, First Served (FCFS, FIFO) Prozessorzuteilung in Reihenfolge, in der Threads rechenbereit werden Threads arbeiten, bis sie (auf ein Ereignis) warten müssen (z.b. E/A- Operation) extrem einfache Strategie einfach zu implementieren (1 Warteschlange) geringe Algorithmuskosten (O(1): FIFO-Warteschlange) schnelle Entscheidungen (O(1): Nr. 1 aus Warteschlange) nicht immer sehr klug; Beispiel: 1 periodischer Thread, Aktivphasendauer 1 Sekunde (CPU-intensiv) n E/A-intensive Threads Betriebssysteme, WS 2016/17 wk Schedulingstrategien

73 Wertung guter Durchsatz: minimale Zahl an Threadwechseln minimaler Scheduling-Overhead E/A-intensive Threads können durch CPU-intensive Threads extrem verzögert werden hohe Varianz der Bearbeitungszeiten für Threads mit unterschiedlichen Lastmerkmalen Betriebssysteme, WS 2016/17 wk Schedulingstrategien

74 Shortest Remaining Time Next (SRTN) Thread mit voraussichtlich kürzester Restrechenzeit erhält Prozessor preemptiv* ), d.h. Threads können von konkurrierenden Threads verdrängt werden (Schätzwert über) Restlaufzeit muss vorliegen einfache Strategie einfach zu implementieren (1 Warteschlange) geringe Algorithmuskosten (O(n): sortierte Warteschlange) schnelle Entscheidungen (O(1): Nr. 1 aus Warteschlange) * ) i. Ggs. zu kooperativ Betriebssysteme, WS 2016/17 wk Schedulingstrategien

75 Wertung bevorzugt kurze Prozesse Gefahr, dass längere Prozesse verhungern vergleichsweise mehr Threadwechsel größerer Scheduling-Overhead Betriebssysteme, WS 2016/17 wk Schedulingstrategien

76 Schedulingstrategien für interaktive Systeme Ziel Minimierung von Reaktionszeiten (subjektiver Eindruck von Performanz) Fairness (mehrere Benutzer/Klienten) Algorithmen... gibt es auch hier viele; oft verwendet: Round-Robin-Varianten einfacher Round Robin Round Robin plus Prioritäten Betriebssysteme, WS 2016/17 wk Schedulingstrategien

77 Round Robin Idee Jeder Thread bekommt ein gleich großes Teil des Kuchens: die Zeitscheibe rechenbereite Threads aktiver Thread tick einfach und effizient zu realisieren 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) Betriebssysteme, WS 2016/17 wk Schedulingstrategien

78 Round Robin Idee Jeder Thread bekommt ein gleich großes Teil des Kuchens: die Zeitscheibe rechenbereite Threads aktiver Thread tick Tuning-Rädchen: Größe einer Zeitscheibe große Zeitscheibe wenig Threadwechsel geringer Schedulingoverhead Reaktivität: 10 Server-Klienten erteilen gleichzeitig einen Auftrag... kleine Zeitscheibe hohe Reaktivität Overhead z.b. bei Zeitscheibe 4msek, Threadwechselzeit 1msek: 20% typischer Wert heute: 20-50msek Betriebssysteme, WS 2016/17 wk Schedulingstrategien

79 Einbeziehung von Prioritäten Ziel Ausdrucksmöglichkeit der Wichtigkeit von Threads niedrig: z.b. Dämonen (die z.b. im Hintergrund s abrufen) Putzarbeiten (Index-Erstellung, Defragmentierung) 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 jeder Thread erhält individuelle Priorität Threads der höchsten Prioritäten erhalten einen Prozessor zwischen Threads gleicher Priorität: Round-Robin Betriebssysteme, WS 2016/17 wk Schedulingstrategien

80 Realisierung Warteschlange Prio tick Warteschlange Prio Warteschlange Prio 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 Betriebssysteme, WS 2016/17 wk Schedulingstrategien

81 Realisierung Warteschlange Prio tick Warteschlange Prio Warteschlange Prio Beispiel aktueller Linux O(1) Scheduler Prios 1-140, je Core eine Warteschlangengruppe mit einer Warteschlange je Prio ( 8 Cores: bis zu 1120 Warteschlangen) Betriebssysteme, WS 2016/17 wk Schedulingstrategien

82 Schedulingstrategien in Echtzeitsystemen Beispiel 1: PC MPEG-Videostrom mplayer Bildfolge 25 Bilder/Sek Lastmuster: z.b. alle 40 msek für 15 msek msek Erzeugte Prozessorbelegung ohne Konkurrenz msek Frist für Bild 1 Bild 2 Bild 3 Bild 4 Betriebssysteme, WS 2016/17 wk Schedulingstrategien

83 Beispiel 2: Digitales Mischpult MPEG-Videostrom Bildfolge 30 Bilder/Sek MPEG-Videostrom Bildfolge 25 Bilder/Sek Lastmuster: z.b. alle 40 msek für 15 msek + alle 33 1 / 3 msek für 10 msek msek Erzeugte Prozessorbelegung mit Konkurrenz z.b. Frist für.. Bild 1 Bild 2 Bild 3 Bild 4 Bild msek Frist für Bild 1 Bild 2 Bild 3 Bild 4 Betriebssysteme, WS 2016/17 wk Schedulingstrategien

84 Schedulingziele in Echtzeitsystemen Finden einer ausführbaren Bearbeitungsreihenfolge (ein Schedule ), die Fristen einhält deren Berechnung ökonomisch ist (Algorithmuskosten) 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 RMS: Raten-monotones Scheduling (rate monotonic scheduling) für statische, periodische Lasten (z.b. Mischpult, DVD-Spieler, technische Prozesse) Betriebssysteme, WS 2016/17 wk Schedulingstrategien

85 Earliest Deadline First (EDF) Methode 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) Betriebssysteme, WS 2016/17 wk Schedulingstrategien

86 The Works Beispiellast (hier z.b. periodisch) Thread A: Periodendauer 30 msek, Aktivphase 10 msek Thread B: Periodendauer 40 msek, Aktivphase 15 msek Thread C: Periodendauer 50 msek, Aktivphase 5 msek Frist: Jeweils der Beginn der folgenden Aktivphase A B C C A B A A A A B B B C C EDF A B? C A? B C? A? B A? C? A B msek Anmerkungen bei Bereitwerden eines Threads werden Prioritäten neu berechnet bis zu einer Prozessorauslastung von 100% wird ein Schedule gefunden kausale oder zeitliche Abhängigkeiten? Betriebssysteme, WS 2016/17 wk Schedulingstrategien

87 2.3.6 Zusammenfassung Das Problem Anzahl der Threads >> Anzahl der Prozessoren nicht alle können gleichzeitig rechnen eine Auswahl muss getroffen werden Auswahlstrategie: Schedulingalgorithmen Welche Threads erhalten wann wie lange einen Prozessor zugeteilt Zulassung Scheduling Beendigung frisch bereit aktiv beendet Ereignis Warten blockiert Betriebssysteme, WS 2016/17 wk Zusammenfassung

88 Schedulingalgorithmen haben großen Einfluss auf Durchsatz, Reaktivität, E/A-Performanz, Echtzeitverhalten, sind daher spezialisiert auf konkrete Einsatzszenarien, z.b. Batch-Systeme, interaktive Systeme, Serversysteme, Echtzeitsysteme sind weiter differenziert bzgl. Annahmen über typische Lastmuster (Periodizität, Fristen) gegebene Garantien z.b. bzgl. der Fairness, Fristeneinhaltung, erzielbare Prozessorauslastung... Threadwechsel erfolgen zu wohldefinierten Zeitpunkten durch Sichern und Restaurieren von Thread/Prozesskontexten können mit erheblichen Kosten verbunden sein (Adressraumwechsel, FPU-Kontextwechsel) Betriebssysteme, WS 2016/17 wk Zusammenfassung

89 2.4 Privilegierungsebenen Situation Anwendungsprozesse und BS nutzen gemeinsame Ressourcen Raum BS AP AP BS AP AP Zeit Arbeitsspeicher Prozessor Problem Schutz vor fehlerbedingten oder bösartigen Wechselwirkungen Betriebssysteme, WS 2016/17 wk Privilegierungsebenen

90 Verhinderung räumlicher Interferenzen 2 Konzepte private Adressräume Zugriffsschutz auf Arbeitsspeicherbereiche Schutzmechanismen des VMM, implementiert durch MMU ( Kap. 3) Betriebssysteme, WS 2016/17 wk Privilegierungsebenen

91 Verhinderung zeitlicher Interferenzen Ursache Prozesse geben freiwillig keine Prozessoren auf Umgang damit periodische Scheduleraktivierungen (Uhr) Interruptsystem kritisch also: Operationen zum Abschalten von Uhr Interruptsystem weitere kritische Operationen z.b. sind Verändern kritischer Prozessorkontrollregister Zugriff auf E/A-Geräte Schutz kritischer Operationen des Instruktionssatzes Betriebssysteme, WS 2016/17 wk Privilegierungsebenen

92 Lösungskonzept Zugriffsschutzmechanismen des VMM (Kap. 3) Schutzmechanismen des Instruktionssatzes beruhen auf Privilegierungsebenen ablaufender Prozesse kernel mode user mode Ermöglichen Implementierung von Regeln: Nur ein im kernel mode ablaufender Prozess hat Zugriff auf... Privilegierungsebenen steuern Zugriff auf geschützte Arbeitsspeicherbereiche (VMM, Kap. 3) Ausführung privilegierter Instruktionen Betriebssysteme, WS 2016/17 wk Privilegierungsebenen

93 Privilegierungsebenen der Intel x86-architektur: Ringe Ring 0: höchste Privilegien, sämtliche Prozessorinstruktionen erlaubt Ebene der BS-Software; je nach BS-Architektur mehr oder weniger umfangreich Mikrokernarchitekturen: nur Mikrokern monolithische Architekturen: gesamte BS-Software Ring 3: keine privilegierten Prozessorinstruktionen erlaubt Ebene der Anwendungsprozesse Ring 1, 2: Auswahl privilegierter Prozessorinstruktionen erlaubt Mikrokernarchitekturen: E/A-Management: Zugriff auf E/A-Geräteregister (Maschinenraum) Speichermanagement: Zugriff auf MMU (VMM) monolithische Architekturen: selten genutzt Betriebssysteme, WS 2016/17 wk Privilegierungsebenen

94 Verwendungsbeispiele Linux, Windows Ring 3 Ring 2 Ring 1 Anwendungsprozesse unbenutzt unbenutzt Ring 0 BS Betriebssysteme, WS 2016/17 wk Privilegierungsebenen

95 Verwendungsbeispiele Virtualisierungen Ring 3 Ring 2 Ring 1 Ring 0 Anwendungsprozesse unbenutzt BS Hypervisor Betriebssysteme, WS 2016/17 wk Privilegierungsebenen

96 Verwendungsbeispiele Mikrokernarchitekturen Ring 3 Ring 2 Ring 1 Ring 0 BS-Komponenten, Anwendungsprozesse E/A-System vertrauenswürdige BS- Komponenten (z.b. VMM) Mikrokern Betriebssysteme, WS 2016/17 wk Privilegierungsebenen

97 HW-Unterstützung aktuelle Privilegierungsebene ist Teil des Prozessor-Statusregisters: Current Privilege Level (CPL) Grundlage der HW-Schutzmechanismen; permanente Überwachung der ausgeführten Instruktionen der Arbeitsspeicherzugriffe Modifikation des CPLs durch privilegierte Instruktionen bei Beginn und Abschluss des Aufrufs eines Systemdienstes ( 2.5.6) einer Unterbrechungsbehandlung ( 2.5.7) Betriebssysteme, WS 2016/17 wk Privilegierungsebenen

98 MSGs jeder auf Privilegierungsebene < 3 ablaufende Prozess hat Zugriff auf kritische Ressourcen jeder auf Privilegierungsebene 0 ablaufende Prozess hat Zugriff auf sämtliche Ressourcen eines Prozessors sämtliche Instruktionen (z.b. HALT) sämtliche Prozessorregister (z.b. PSR) MMU-Register zur Arbeitsspeicherkonfiguration (s. Kap. 3) sämtliche Register der E/A-Peripherie (s. Kap. 6) Betriebssysteme, WS 2016/17 wk Privilegierungsebenen

99 Sämtlicher Schutz von Anwendungsprozessen und Betriebssystem Anwendungsprozessen untereinander beruht elementar auf 2 Bits hardwareimplementierten Prozessor-Privilegierungsebenen hardwareimplementierten Speicherzugriffsschutzmechanismen Die Korrektheit der Implementierung und Nutzung dieser Mechanismen ist das Fundament! jeglicher Sicherheitseigenschaften von Betriebssystemen! Betriebssysteme, WS 2016/17 wk Privilegierungsebenen

100 Betriebssysteme, WS 2016/17 wk Kommunikation und Synchronisation 2.5 Kommunikation und Synchronisation Beispiel 1: Interaktionen zwischen BS-Komponenten GUI Office Google Earth MatLab ABS Firefox Anwendungsschnittstelle (Application Programmer s Interface, API) Betriebssystem-Dienste Prozessmanagement Dateimanagement Netzwerkmanagement Prozessor- Ressourcen Ressourcenmanagement Kommunikations- Ressourcen Speicher- Ressourcen E/A Ressourcen

101 Betriebssysteme, WS 2016/17 wk Kommunikation und Synchronisation Zugriff auf Dateien Anlegen von Prozessen Dateimanagement Datei- Dateisystem- management manager Arbeitsspeicher- Management (VMM) HDD.putJob( ) Gerätemanager-Interface HDD- Gerätemanager ( Treiber )

102 Betriebssysteme, WS 2016/17 wk Kommunikation und Synchronisation Beispiel 2: Interaktionen zwischen Anwendungsprozessen Codec, z.b. H.264 LiveStream Server API z.b. IEEE 1394 Firewire FWDD HDD NWDD z.b. WLAN FW-Karte Netzwerkkarte

103 Das Problem Codec forever do! {!!schreibe(bild)! }! LiveStream Server forever do! {!!lese(bild)! }! Austausch von Daten zwischen Prozessen Kommunikation (Inter-Prozess-Kommunikation, IPC) Abweichende Geschwindigkeiten von Sender und Empfänger Synchronisation Betriebssysteme, WS 2016/17 wk Kommunikation und Synchronisation

104 Naiver Versuch Codec LiveStream Server forever do! {!!pufferq.hinten Bild! }! forever do! {!!Bild pufferq.vorne;! }! Codec- Thread Server- Thread Ganz so einfach geht es leider nicht Puffer voll Puffer leer Pufferelement in Benutzung Betriebssysteme, WS 2016/17 wk Kommunikation und Synchronisation

105 Problemfelder gleichzeitiges Lesen und Schreiben des selben Pufferelements: Konsistenz des gelesenen Bildes? Codec- Thread Server- Thread Operationen auf gemeinsamen Variablen (Pufferelemente) sind kritische Abschnitte erfordern Synchronisation, z.b. durch wechselseitigen Ausschluss Betriebssysteme, WS 2016/17 wk Kommunikation und Synchronisation

106 Betriebssysteme, WS 2016/17 wk Kommunikation und Synchronisation unterschiedliche Geschwindigkeiten von Erzeuger und Verbraucher: Pufferüberlauf, Leere Codec- Thread Server- Thread Synchronisation relativer Geschwindigkeiten

107 Betriebssysteme, WS 2016/17 wk Kommunikation und Synchronisation Kritische Abschnitte und wechselseitiger Ausschluss Definition Es gibt Ressourcen, die als ganzes oder bzgl. einzelner Operationen nur exklusiv, d.h. zu einem Zeitpunkt nur durch einen einzigen Thread nutzbar sind. Eine Phase, in der ein Thread eine exklusive Operation auf einer Ressource ausführt, heißt kritischer Abschnitt. Kritische Abschnitte erfordern den wechselseitigen Ausschluss konkurrierender Threads.

108 Betriebssysteme, WS 2016/17 wk Kommunikation und Synchronisation Problemdefinition Annahmen konkurrierende Threads arbeiten asynchron, z.b. in einer unendlichen Schleife dabei betreten und verlassen sie irgendwann einen kritischen Abschnitt Betreten und Verlassen dieses Abschnitts wird durch Algorithmen organisiert, die den kritischen Abschnitt umgeben (Entry/Exit-Code) beliebiger beliebiger Code Code beliebiger Code Entry-Code Entry-Code Entry-Code kritischer Abschnitt Exit-Code Exit-Code Exit-Code beliebiger beliebiger Code Code beliebiger Code

109 Betriebssysteme, WS 2016/17 wk Kommunikation und Synchronisation Algorithmen zum wechselseitigen Ausschluss Grundsätzliche Anforderungen Korrektheit: In einem kritischen Abschnitt befindet sich zu jedem Zeitpunkt höchstens ein Thread (wechselseitiger Ausschluss) Lebendigkeit: Falls ein Thread einen kritischen Abschnitt betreten möchte, dann betritt (irgendwann) (irgend)ein Thread diesen Abschnitt Verhungerungsfreiheit: Kein Thread wartet für immer vor einem kritischen Abschnitt

110 Betriebssysteme, WS 2016/17 wk Kommunikation und Synchronisation Wechselseitiger Ausschluss - ein erster (naiver) Versuch Szenario Codec- Thread Server- Thread (Vereinfachung: Pufferkapazität = 1 Bild) 2 parallele Aktivitäten 1 exklusiv nutzbare Ressource, der Puffer kritische Abschnitte: schreiben und lesen des Puffers Idee während Benutzung des Puffers wird dieser als busy markiert bei Vorfinden eines so markierten Puffers wird gewartet