Betriebssysteme Kap. 2: Nebenläufigkeit und Parallelität

Betriebssysteme, WS 2014/15 wk - 1 - Betriebssysteme Kap. 2: Nebenläufigkeit und Parallelität Winfried E. Kühnhauser Wintersemester 2014/15 Winfried E. Kühnhauser CSI Technische Universität Ilmenau www.tu-ilmenau.de

Roadmap Anwendungsebene GUI MatLab Office ABS 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 2014/15 wk - 2-2 Nebenläufigkeit und Parallelität

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

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 Email-Klient Powerpoint und Fileserver Betriebssysteme, WS 2014/15 wk - 4-2 Nebenläufigkeit und Parallelität

2.1 Prozesse 123 +456 +789? 246 +333 +543? 99 +110 +443? 42 +420 +211? Trotz kausaler Unabhängigkeit der Aufgaben: Paralleles Arbeiten auf kognitiver Ebene ist (für Menschen) schwierig Unser Umgang damit Wir sequenzialisieren Zerlegung der Aufgabe in 4 (eigentlich parallel ausführbare) Aktivitäten sequenzielle Abarbeitung dieser Aktivitäten Idee der Prozessmodelle von BSen Betriebssysteme, WS 2014/15 wk - 5-2.1 Prozesse

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 zugeordnete Betriebsmittel (Prozessor/Speicher/Kommunikationsressourcen) Rechte (Nutzung von Diensten, Dateien, Kommunikationsports) Parallele Aktivitäten werden repräsentiert durch parallele Prozesse. 123 +456 +789? 246 +333 +543? 99 +110 +443? 42 +420 +211? Betriebssysteme, WS 2014/15 wk - 6-2.1 Prozesse

2.1.1 Prozessmodelle In a Nutshell Prozess = BS-Abstraktion zur Ausführung von Programmen Prozessmodelle definieren konkrete Prozesseigenschaften ( BS-spezifisch) Prozessmanager BS-Komponente, die Prozessmodelle implementiert Betriebssysteme, WS 2014/15 wk - 7-2.1.1 Prozessmodelle

Prozessmodelle Aufgabe präzise Definition der BS-Abstraktion Prozess definiert durch Semantik der Operationen auf Prozessen ( the life and hard times...) Erzeugen, Beenden, Anhalten, Fortsetzen, nichtfunktionale Eigenschaften von Prozessen Isolation Ressourcenmanagement (Speicher, Rechenzeit) Rechtemanagement implementiert durch Datenstrukturen Algorithmen des Prozessmanagements Betriebssysteme, WS 2014/15 wk - 8-2.1.1 Prozessmodelle

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

Prozessmanager seziert class ProcessManager { public: CreateProcess(Program) {... } Prozessmanagement TerminateProcess(Process) {... }... private: ProcessDescriptorTable... } Betriebssysteme, WS 2014/15 wk - 10-2.1.1 Prozessmodelle

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

Anwendersicht mittels GUIs: Mausklick auf ein Symbol Google Earth mittels Kommandointerpreter/Shell kandooma> cc was letztendlich immer geschieht: per Systemaufruf aus ablaufendem Programm if (fork() == 0) execve( /usr/bin/cc, ) Betriebssysteme, WS 2014/15 wk - 12-2.1.2 Prozesserzeugung

Resultierende Aktionen des Prozessmanagements Prüfen notwendiger Voraussetzungen Rechte, Ressourcenverfügbarkeit (Speicher, evtl. Prozessorzeit) Namensvergabe Stammbaum Allokation von Ressourcen, z.b. Arbeitsspeicher ( Speichermanagement) Prozessorzeit ( Scheduler) Anlegen von Managementdatenstrukturen Rechtemanagement; u.a. Eigentümer, Zugriffsrechte Ressourcenmanagement; u.a. Speicher- und Prozessorbelegung Laufzeitmanagement; u.a. Ablaufzustand, eingetretene Ereignisse Betriebssysteme, WS 2014/15 wk - 13-2.1.2 Prozesserzeugung

Notwendige Voraussetzungen (prozessmodellspezifisch) Sicherheit Authentizitä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 2014/15 wk - 14-2.1.2 Prozesserzeugung

(prozessmodellspezifisch) z.b. Unix/Windows Systemfamilien: Prozessidentifikation ist positive ganze Zahl Vergabealgorithmus variiert; z.b. zyklisch [0, 32000] Namensvergabe 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 2014/15 wk - 15-2.1.2 Prozesserzeugung

Stammbaum 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 2014/15 wk - 16-2.1.2 Prozesserzeugung

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

(prozessmodellspezifisch) Allokation von Ressourcen Adressraum: wie viel Arbeitsspeicher erhält 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 Speichermanagement, Kap. 3 High-End Betriebssysteme, Kap. 7 1. Arbeitsspeicher Betriebssysteme, WS 2014/15 wk - 18-2.1.2 Prozesserzeugung

Betriebssysteme, WS 2014/15 wk - 19 - Ein kurzer Ausflug Arbeitsspeicherstruktur minimal erforderlich Code des ausgeführten Programms Text Segment 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)

Repräsentation ausführbarer Programme (z.b..exe -Files) 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 00 01 00 01 01 00 01 00 11 11 10 01 00 00 01 11 00 10 01 01 00 00 00 00 00 00 00 00 h e l l o 00 00 00 Kopf Infos zum Binden, Debuggen vom Compiler/ Linker erzeugter Programmcode vom Compiler initialisierte Daten * ) Executable and Link Format Betriebssysteme, WS 2014/15 wk - 20-2.1.2 Prozesserzeugung

Arbeitsspeicher-Initialisierung ausführbare Programmdatei Magie Programcode initialisierte Daten uninitialisierte Daten Startadresse Symboltabellen, z.b. firstint: #0 secondint: #4 grusstext: #8 00 01 00 01 01 00 01 00 11 11 10 01 00 00 01 11 00 10 01 01 00 00 00 00 00 00 00 00 h e l l o 00 00 00 Speicherlayout Textsegment(e) Daten-(Heap-) Segment(e) Stacksegment(e) Betriebssysteme, WS 2014/15 wk - 21 - Dabei hilft das VMM Kap. 3 2.1.2 Prozesserzeugung

Damit dies korrekt funktioniert: präzise Formatvereinbarungen zwischen dem Linker (Programmdatei-Produzent) dem 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 2014/15 wk - 22 - erkennbar an magic number 2.1.2 Prozesserzeugung

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 (Ende des Ausflugs) Betriebssysteme, WS 2014/15 wk - 23-2.1.2 Prozesserzeugung

Allokation des Arbeitsspeichers schematisch /* 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=ELFHeader.TextSize; } elsif (Header.midmag==COFFmag) then { Betriebssysteme, WS 2014/15 wk - 24-2.1.2 Prozesserzeugung

Aufgabe Allokation elementarer Ressourcen in Prozessmodellen echtzeitfähiger Systeme (planbar) Planung und Bereitstellung von Prozessorzeit für einen Prozess 2. Prozessorzeit Parameter: Größe: wie viel Prozessorzeit benötigt der neue Prozess? Zeitpunkt: zu welchem Zeitpunkt wird Prozessorzeit benötigt? Autonomie: in wie weit darf dies durch andere Prozesse beeinflusst werden? in Prozessmodellen ohne diese Eigenschaften (kaum planbar) dynamisches ad-hoc-scheduling Strategien beeinflussen massiv die NFEs Scheduling-Algorithmen in Kap. 2.3 Betriebssysteme, WS 2014/15 wk - 25-2.1.2 Prozesserzeugung

Zwischenstand Aktionen des Prozessmanagements Prüfen notwendiger Voraussetzungen Rechte, Ressourcenverfügbarkeit (Speicher, Prozessorzeit) Namensvergabe Stammbaum Allokation von Ressourcen (dabei helfen andere BS-Komponenten); i.w. Arbeitsspeicher (Speichermanagement) Prozessorzeit (Scheduler) Irgendwo müssen wir uns all dies merken : Anlegen von Managementdatenstrukturen ( Prozessdeskriptor ) Ressourcenmanagement; u.a. Speicher, Prozessorzeit Rechtemanagement; u.a. Eigentümer, Zugriffsrechte Laufzeitmanagement; u.a. Ablaufzustand, eingetretene Ereignisse Betriebssysteme, WS 2014/15 wk - 26-2.1.2 Prozesserzeugung

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 2014/15 wk - 27-2.1.2 Prozesserzeugung

Ein typischer Prozessdeskriptor Prozessormanagement Identifikationen Prozessidentifikation Prozessidentifikation des Erzeugers Scheduling Prozesszustand Priorität, Lastbeschreibung,... Prozessorkontext 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 2014/15 wk - 28-2.1.2 Prozesserzeugung

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 2014/15 wk - 29-2.1.2 Prozesserzeugung

Ein typischer Prozessdeskriptor ist sehr groß (mit Seitentabellen (s.u.) mehrere Megabyte) ist daher oft physisch zweigeteilt (damit in Passivphasen weniger Arbeitsspeicher belegt wird) Informationen, die während der gesamten Existenz benötigt werden, z.b. Ablaufzustand (rechenbereit, blockiert) Priorität zugesandte Ereignisse und eingeplante Reaktionen hierauf Informationen, die nur während einer Aktivphase benötigt werden, z.b. Rechte (Teile des) Speicherlayout(s) Betriebssysteme, WS 2014/15 wk - 30-2.1.2 Prozesserzeugung

Zusammenfassung Prozesserzeugung Prüfen notwendiger Voraussetzungen Rechte, Ressourcenverfügbarkeit Namensvergabe Stammbaum Allokation von Ressourcen Arbeitsspeicher, Prozessorzeit strategische Algorithmen bestimmen NFEs: Robustheit, Sicherheit, Performanz, Echtzeitanforderungen Managementdatenstrukturen Betriebssysteme, WS 2014/15 wk - 31-2.1.2 Prozesserzeugung

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 2014/15 wk - 32-2.1.3 Prozessterminierung

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 _ per Admin-Software (z.b. Windows Task Manager, Mac Was so 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 2014/15 wk - 33-2.1.3 Prozessterminierung

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 2014/15 wk - 34-2.1.3 Prozessterminierung

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 2014/15 wk - 35-2.1.4 Zusammenfassung

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 2014/15 wk - 36-2.2 Threads

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 2014/15 wk - 37-2.2 Threads

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 Entflechtung dieser Funktionen; wir möchten eine Abstraktion zum Management von Ressourcen (teuer) eine Abstraktion zum Management von Parallelität (preiswert) enter Threads Betriebssysteme, WS 2014/15 wk - 38-2.2.1 Das Threadmodell

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 2014/15 wk - 39-2.2.1 Das Threadmodell

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

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 2014/15 wk - 41-2.2.1 Das Threadmodell

Anmerkungen cont d ein Prozessdeskriptor 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 2014/15 wk - 42-2.2.1 Das Threadmodell

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 2014/15 wk - 43-2.2.1 Das Threadmodell

Zu Fuß, z.b. in einem C-Programm, eine Thread-Bibliothek nutzend #include <pthread.h> void AServerThread() { repeat { AwaitClientRequest(...); HandleClientRequest(...); ReplyToClient(...); } until client disconnects; } durch Thread ausgeführtes Programm, syntaktisch als Prozedur formuliert main() {... whenever new client connects: ThreadCreate(...,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 2014/15 wk - 44-2.2.1 Das Threadmodell

2.2.2 Thread-Implementierungen Alternativen 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 2014/15 wk - 45-2.2.2 Thread-Implementierungen

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 2014/15 wk - 46-2.2.2 Thread-Implementierungen

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 2014/15 wk - 47-2.2.2 Thread-Implementierungen

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 2014/15 wk - 48-2.2.2 Thread-Implementierungen

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 2014/15 wk - 49-2.2.2 Thread-Implementierungen

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 Neuversuch Folge rewriting sämtlicher derartiger Systemaufrufe sehr ineffizient sehr plump es gibt aber keine Alternativen Betriebssysteme, WS 2014/15 wk - 50-2.2.2 Thread-Implementierungen

Fazit: Wer die Wahl hat... Wahl des 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 2014/15 wk - 51-2.2.2 Thread-Implementierungen

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 ( kernel level ) 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 2014/15 wk - 52-2.2.2 Thread-Implementierungen

2.2.3 Zusammenfassung Sie kennen nun den Grund für die Existenz von Threads multi-threaded Prozessmodelle deren Pros und Kons Performanz Robustheit Sicherheit Implementierungsebenen für Threads user level Threads kernel level Threads Pros und Kons dieser Varianten Betriebssysteme, WS 2014/15 wk - 53-2.2.3 Zusammenfassung

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 2014/15 wk - 54-2.3 Scheduling

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 2014/15 wk - 55-2.3.1 Zustandsmodelle

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 2014/15 wk - 56-2.3.1 Zustandsmodelle

Beschreibungsmittel Endliche deterministische Automaten a got a a q 0 a b q t a, b b got b b Implementierung Automat ist implementiert im Prozessmanagement Threadzustand (ist Teil des Threaddeskriptors) Zustandsübergangsfunktion ( -Funktion) Betriebssysteme, WS 2014/15 wk - 57-2.3.1 Zustandsmodelle

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 2014/15 wk - 58-2.3.1 Zustandsmodelle

Verfeinerung: 7-Zustandsmodell Differenzierung (prozessexterner) 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 2014/15 wk - 59-2.3.1 Zustandsmodelle

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 2014/15 wk - 60-2.3.1 Zustandsmodelle

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 2014/15 wk - 61-2.3.1 Zustandsmodelle

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 2014/15 wk - 62-2.3.2 Scheduler

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 2014/15 wk - 63-2.3.2 Scheduler

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 2014/15 wk - 64-2.3.3 Scheduleraktivierungen

Ein Kontextwechsel umfasst 2.3.4 Zuteilung und Entzug: Kontextwechsel bei Wechsel zwischen Threads desselben Prozesses Scheduler- Aktivierung Software meets Hardware 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 bereit Ereignis asleep Auswahlstrategie: m aus n Threads (bei m Prozessoren) Zuteilung und Entzug blockiert aktiv Warten Betriebssysteme, WS 2014/15 wk - 65-2.3.4 Kontextwechsel

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 2014/15 wk - 66-2.3.4 Kontextwechsel

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 2014/15 wk - 67 - FPU Kontext A B besitzt / benutzt 2.3.4 Kontextwechsel

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 2014/15 wk - 68-2.3.4 Kontextwechsel

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 2014/15 wk - 69-2.3.5 Schedulingstrategien

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 2014/15 wk - 70-2.3.5 Schedulingstrategien

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 2014/15 wk - 71-2.3.5 Schedulingstrategien

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 2014/15 wk - 72-2.3.5 Schedulingstrategien

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 2014/15 wk - 73-2.3.5 Schedulingstrategien

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 2014/15 wk - 74-2.3.5 Schedulingstrategien

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 2014/15 wk - 75-2.3.5 Schedulingstrategien

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 2014/15 wk - 76-2.3.5 Schedulingstrategien

Wertung bevorzugt kurze Prozesse Gefahr, dass längere Prozesse verhungern vergleichsweise mehr Threadwechsel größerer Scheduling-Overhead Betriebssysteme, WS 2014/15 wk - 77-2.3.5 Schedulingstrategien

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 2014/15 wk - 78-2.3.5 Schedulingstrategien

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) schnelle Entscheidungen (O(1): Nr. 1 aus Warteschlange) notwendiges Wissen gering (CPU-Nutzungsdauer des aktiven Threads) Betriebssysteme, WS 2014/15 wk - 79-2.3.5 Schedulingstrategien

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 2014/15 wk - 80-2.3.5 Schedulingstrategien

Einbeziehung von Prioritäten Ziel Ausdrucksmöglichkeit der Wichtigkeit von Threads Idee niedrig: z.b. Dämonen (die z.b. im Hintergrund Emails 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) 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 2014/15 wk - 81-2.3.5 Schedulingstrategien

Realisierung Warteschlange Prio 2 2 2 2 2 2 2 Warteschlange Prio 1 Warteschlange Prio 0 1 1 1 0 0 0 0 Es gibt sehr 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 2014/15 wk - 82-2.3.5 Schedulingstrategien

Realisierung Warteschlange Prio 2 2 2 2 2 2 2 Warteschlange Prio 1 Warteschlange Prio 0 1 1 1 0 0 0 0 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 2014/15 wk - 83-2.3.5 Schedulingstrategien

Schedulingstrategien in Echtzeitsystemen Beispielszenario 1: PC MPEG-Videostrom mplayer Bildfolge 25 Bilder/Sek Lastmuster: z.b. alle 40 msek für 15 msek 1 2 3 4 5 0 40 80 120 160 msek Erzeugte Prozessorbelegung ohne Konkurrenz 1 2 3 4 5 0 40 80 120 160 msek Frist für Bild 1 Bild 2 Bild 3 Bild 4 Betriebssysteme, WS 2014/15 wk - 84-2.3.5 Schedulingstrategien

Beispielszenario 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 1 2 3 4 5 6 1 2 3 4 5 0 40 80 120 160 msek Erzeugte Prozessorbelegung mit Konkurrenz z.b. Frist für.. Bild 1 Bild 2 Bild 3 Bild 4 Bild 5 1 1 2 2 3 3 4 4 5 5 6 0 40 80 120 160 msek Frist für Bild 1 Bild 2 Bild 3 Bild 4 Betriebssysteme, WS 2014/15 wk - 85-2.3.5 Schedulingstrategien

Schedulingziele in Echtzeitsystemen Finden einer ausführbaren Bearbeitungsreihenfolge (ein Schedule ) die Fristen einhält deren Berechnung ökonomisch ist (Algorithmuskosten) die selbst ökonomisch ist (z.b. Minimierung der Threadwechsel) die sich (evtl.) an wechselnde Lastmuster anpasst Verbreitete Algorithmen EDF: früheste Frist zuerst (earliest deadline first) RMS: Raten-monotones Scheduling (rate monotonic scheduling) für periodische Lasten (z.b. Mischpult, DVD-Spieler, technische Prozesse) Betriebssysteme, WS 2014/15 wk - 86-2.3.5 Schedulingstrategien

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 Priorität um so höher, je näher seine Frist liegt ist er preemptiv Voraussetzung kausale und zeitliche Unabhängigkeit der Threads (keine wechselseitige Blockierung) Betriebssysteme, WS 2014/15 wk - 87-2.3.5 Schedulingstrategien

The Works Beispiellast (hier 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 0 20 40 60 80 100 120 140 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 2014/15 wk - 88-2.3.5 Schedulingstrategien

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 2014/15 wk - 89-2.3.6 Zusammenfassung

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 2014/15 wk - 90-2.3.6 Zusammenfassung

2.4 Privilegierungsebenen Situation Anwendungsprozesse und BS nutzen gemeinsame Ressourcen Raum BS AP AP BS AP AP Zeit Problem Schutz vor fehlerbedingten oder bösartigen Wechselwirkungen Lösung Isolation durch Speicherzugriffsschutzmechanismen Privilegierungsebenen Betriebssysteme, WS 2014/15 wk - 91 - Arbeitsspeicher Prozessor 2.4 Privilegierungsebenen

Schutz von Arbeitsspeicherbereichen Isolation (Code, Datenstrukturen) von Betriebssystem und Anwendungsprozessen Isolation von Anwendungsprozessen untereinander Schutzmechanismen des VMM, implementiert durch MMU ( Kap. 3) Schutz kritischer (privilegierter) Prozessorinstruktionen Definition des Arbeitsspeicher-Layouts (Zugriff auf MMU) Anhalten des Prozessors, Setzen von Interruptsperren Verändern kritischer Prozessorregister Zugriff auf E/A-Controller Schutzmechanismen implementiert durch Privilegierungsebenen Betriebssysteme, WS 2014/15 wk - 92-2.4 Privilegierungsebenen

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-Subsysteme: Zugriff auf E/A-Controller Speichermanagement: Zugriff auf MMU monolithische Architekturen: selten genutzt Betriebssysteme, WS 2014/15 wk - 93-2.4 Privilegierungsebenen

Verwendungsbeispiele Linux, Windows Ring 3 Ring 2 Ring 1 Anwendungsprozesse unbenutzt unbenutzt Ring 0 BS Betriebssysteme, WS 2014/15 wk - 94-2.4 Privilegierungsebenen

Verwendungsbeispiele Virtualisierungen Ring 3 Ring 2 Ring 1 Ring 0 Anwendungsprozesse unbenutzt BS Hypervisor Betriebssysteme, WS 2014/15 wk - 95-2.4 Privilegierungsebenen

Verwendungsbeispiele Mikrokernarchitekturen Ring 3 Ring 2 Ring 1 Ring 0 BS-Komponenten, Anwendungsprozesse E/A-System vertrauenswürdige BS-Komponenten Mikrokern Betriebssysteme, WS 2014/15 wk - 96-2.4 Privilegierungsebenen

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 2014/15 wk - 97-2.4 Privilegierungsebenen

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) sämtliche Register der E/A-Peripherie (s. Kap. 6) MMU-Register zur Adressraum-Konfiguration (s. Kap. 3) Betriebssysteme, WS 2014/15 wk - 98-2.4 Privilegierungsebenen

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 2014/15 wk - 99-2.4 Privilegierungsebenen

Betriebssysteme, WS 2014/15 wk - 100-2.5 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

Betriebssysteme, WS 2014/15 wk - 101-2.5 Kommunikation und Synchronisation Dateimanagement Datei- Dateisystem- management manager Arbeitsspeicher- Management (VMM) HDD.putJob( ) Gerätemanager-Interface HDD- Gerätemanager ( Treiber )

Betriebssysteme, WS 2014/15 wk - 102-2.5 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

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 2014/15 wk - 103-2.5 Kommunikation und Synchronisation

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 2014/15 wk - 104-2.5 Kommunikation und Synchronisation

Betriebssysteme, WS 2014/15 wk - 105-2.5 Kommunikation und Synchronisation 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 wechselseitigen Ausschluss

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

Betriebssysteme, WS 2014/15 wk - 107-2.5 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.

Betriebssysteme, WS 2014/15 wk - 108-2.5 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

Betriebssysteme, WS 2014/15 wk - 109-2.5 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

Betriebssysteme, WS 2014/15 wk - 110-2.5 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

Betriebssysteme, WS 2014/15 wk - 111-2.5 Kommunikation und Synchronisation Wechselseitiger Ausschluss - ein erster (naiver) Versuch Szenario Codec- Thread Server- Thread (Vereinfachung: Pufferkapazität = 1 Bild) also: Entry Code (Belegen des kritischen Abschnitts): loop until not bufferbusy; bufferbusy := true; Exit-Code (Freigeben des kritischen Abschnitts): bufferbusy := false; beliebiger Code Entry-Code kritischer Abschnitt Exit-Code beliebiger Code

Writer- Thread bufferbusy Reader- Thread Writer-Thread (Codec): Reader-Thread (Server): forever do { forever do { loop until not bufferbusy; codepicfromcamerastream(pic); bufferbusy := true; loop until not bufferbusy; read(buffer, pic); bufferbusy := true; bufferbusy := false; write(buffer, pic); sendtosomeclient(pic); bufferbusy := false; } } Korrektheit: parallele Ausführung der Threads bei ; Ursache: Race Conditions Lebendigkeit: viel zu sehr... Verhungern: z.b. bei Pseudoparallelität lediglich Problemverlagerung: kritischer Zugriff nun auf bufferbusy Betriebssysteme, WS 2014/15 wk - 112-2.5 Kommunikation und Synchronisation

Betriebssysteme, WS 2014/15 wk - 113-2.5 Kommunikation und Synchronisation Was tun? 2 Probleme dieses naiven Synchronisationsversuchs Korrektheit (wechselseitiger Ausschluss) Problemursache: zwischen Testen der Bedingung und Reaktion auf Ergebnis ändert paralleler Thread die Bedingung (race) Lösungsidee: Atomarität (Ununterbrechbarkeit) von Codesequenzen herstellen: loop until not bufferbusy; bufferbusy:=true Verhungern Problemursache: (mindestens) einer der beteiligten Threads kommt nicht zum Zuge Lösungsidee: explizit für Abwechslung sorgen Lösungen: Synchronisations- und Kommunikationsmechanismen

Betriebssysteme, WS 2014/15 wk - 114-2.5 Kommunikation und Synchronisation Synchronisations- und Kommunikationsmechanismen Semaphore Hoare sche Monitore Transaktionaler Speicher Botschaften Fernaufrufe Synchrnisationsmechanismen Interprozesskommunikationsmechanismen (IPC); siehe auch Vorlesung Kommunikationsmodelle

Betriebssysteme, WS 2014/15 wk - 115-2.5.1 Semaphore 2.5.1 (Binäre) Semaphore Dijkstra 1965 Idee: Flagge mit 2 Zuständen frei belegt mit 2 atomaren Operationen belegen: P(Semaphorname) ( Passeren ) freigeben: V(Semaphorname) ( Vriegeven ) Beispiel

Betriebssysteme, WS 2014/15 wk - 116-2.5.1 Semaphore (Binärer) Semaphor Abstrakter Datentyp mit 2 atomaren Operationen P, V belegen: P(Semaphorname) freigeben: V(Semaphorname) Zustand Anwendungsschnittstelle (Application Programmer s Interface, API) Betriebssystem-Dienste Prozessmanagement Dateimanagement Netzwerkmanagement Ressourcenmanagement Prozessor- Ressourcen Speicher- Ressourcen E/A Ressourcen E/A Ressourcen Kommunikations- Ressourcen Abstrakte Semantik P(semaphore s) wait until s.zustand = frei; s.zustand := belegt; V(semaphore s) s.zustand := frei;

Betriebssysteme, WS 2014/15 wk - 117-2.5.1 Semaphore Benutzung semaphore s; s=new(semaphore); P(s); <kritischer Abschnitt> V(s); } Regel dabei: sämtliche Nutzer des kritischen Abschnitts müssen dies tun

Nicht ganz einfach: Implementierung z.b. als Klasse, die Operationen P und V exportierend mit einer internen Aufruferthread-Warteschlange waitq zwei Operationen atomicbegin und atomicend, die Ununterbrechbarkeit und Exklusivität herstellen (s.u.) P(semaphore s) { } atomicbegin(); if (s.state==busy) { s.waitq.enter(caller); suspend(caller); } s.state=busy; atomicend(); V(semaphore s) { } atomicbegin(); s.state=not busy; continue(s.waitq.leave()); atomicend(); Betriebssysteme, WS 2014/15 wk - 118-2.5.1 Semaphore

Nutzung auf Anwendungsebene genutzt von multi-threaded Anwendungen (Webserver, PowerPoint, etc.) Quelle Senke implementiert durch Systemaufrufe und (Thread)Bibliotheken Nutzung auf BS-Ebene genutzt von allen nebenläufigen Komponenten Dateimanagement VMM implementiert durch BS selbst im Maschinenraum: atomicbegin(), atomicend() HDD- Gerätemanager Betriebssysteme, WS 2014/15 wk - 119-2.5.1 Semaphore

Unterstützung durch Hardware: die TSL-Operation Atomarität Ausschluss paralleler Ausführung Betriebssysteme, WS 2014/15 wk - 120 - Implementierung von atomicbegin/end TestAndSetLock ( TSL ) im Instruktionssatz eines Prozessors Im Maschinenraum testen des Inhalts einer Speicherzelle, ergebnisabhängig Wert hineinschreiben TSL busy, int if (busy==0) busy=int atomicbegin(s): TSL s.state, callingthread.id CMP s.state, callingthread.id JZE gotit CALL scheduler.yield JMP atomicbegin gotit: RET try to get lock did I get it? yes optional, mandatory in monocores: give up processor try again got it, may enter critical region Multicorearchitekturen Synchronisation von Threads mit gemeinsamen Adressraum Synchronisation von Threads ohne gemeinsamen Adressraum (Prozesse, MParchitekturen mit individuellem Speicher je Prozessor) allen Aufrufern gemeinsamer Speicher notwendig! 2.5.1 Semaphore

1. Problem: Konsistenz des gelesenen Bildes Benutzung von Semaphoren Zurück zu unserem Synchronisationsproblem Codec- Thread Semaphor bufferbusy Server- Thread Writer-Thread: forever do { codepicfromcamerastream(pic); P(bufferBusy); write(buffer,pic); V(bufferBusy); } Reader-Thread forever do { P(bufferBusy); read(buffer,pic); V(bufferBusy); sendtosomeclient(pic); } wechselseitiger Ausschluss ungelöst: Geschwindigkeitsdifferenz bei endlichem Puffer schneller Writer-Thread findet vollen Puffer vor schneller Reader-Thread liest aus noch leerem Puffer Betriebssysteme, WS 2014/15 wk - 121-2.5.1 Semaphore

2. Problem: Geschwindigkeitsdifferenz (bei einelementigem Puffer) Codec- Thread bufferbusy bufferfull buffermt Server- Thread wechselseitiger Ausschluss Writer-Thread: forever do { codepicfromcamerastream(pic); } P(bufferMt); P(bufferBusy); write(buffer,pic); V(bufferBusy); V(bufferFull); Reader-Thread forever do { } P(bufferFull); P(bufferBusy); read(buffer,pic); V(bufferBusy); V(bufferMt); sendtosomeclient(pic); Schutz vor Puffer- Über/Unterlauf Betriebssysteme, WS 2014/15 wk - 122-2.5.1 Semaphore

2. Problem: Geschwindigkeitsdifferenz (bei mehrelementigem Puffer) Codec- Thread bufferbusy bufferfull = 0 buffermt = 4 Server- Thread Writer-Thread: forever do { codepicfromcamerastream(pic); } Down(bufferMt); P(bufferBusy); write(buffer,pic); V(bufferBusy); Up(bufferFull); Reader-Thread forever do { } Down(bufferFull); P(bufferBusy); read(buffer,pic); V(bufferBusy); Up(bufferMt); sendtosomeclient(pic); Betriebssysteme, WS 2014/15 wk - 123-2.5.1 Semaphore

Betriebssysteme, WS 2014/15 wk - 124-2.5.1 Semaphore Zusammenfassung 2.5.1 Semaphore... lösen 2 elementare Synchronisationsprobleme paralleler Aktivitäten wechselseitiger Ausschluss unterschiedliche Geschwindigkeiten erreichen dies durch aktives Warten oder Suspendierung sind implementiert in den Tiefen des Ressourcenmanagements sind aber auch softwaretechnisch problematisch in größeren Systemen: Synchronisationsoperationen (P und V) stehen im Code dort, wo kritische Operationen (z.b. read/write) stehen also verteilt im Programmtext sämtlicher Threads insbesondere also getrennt von den synchronisierten Daten Korrektheitsproblem: die unabdingbare Vollständigkeit Symmetrie der P- und V-Operationen ist schwierig erreichbar und nachweisbar

Betriebssysteme, WS 2014/15 wk - 125-2.5.2 Hoare sche Monitore 2.5.2 Hoare sche Monitore Charles Antony Richard Hoare Die Idee Nutzung des Prinzips der Datenabstraktion Sie kennen dies bereits aus der Mathematik: Algebren = Assoziationen von Grundmengen darauf definierten Operationen aus Programmiersprachen: z.b. C++ - Klassen = Assoziationen von Daten darauf definierten Methoden

Betriebssysteme, WS 2014/15 wk - 126-2.5.2 Hoare sche Monitore Hoare sche Monitore legen noch eins drauf: Zusammenfassung von Daten darauf definierten Methoden Synchronisation zu einem abstrakten Datentyp, dessen Operationen jeweils kritische Abschnitte mit wechselseitigem Ausschluss darstellen Zugriff auf Daten ausschließlich über selbstständig synchronisierende Operationen

Betriebssysteme, WS 2014/15 wk - 127-2.5.2 Hoare sche Monitore & Also statt so... Writer-Thread Writer-Thread P(bufferBusy); P(bufferBusy); write(buffer,pic); write(buffer,pic); V(bufferBusy); V(bufferBusy); Reader-Thread P(bufferBusy); read(buffer,pic); V(bufferBusy); Variable buffer Semaphor bufferbusy

... so: Writer-Thread Writer-Thread Puffer.write(buffer,pic); Puffer.write(buffer,pic); Reader-Thread Puffer.read(buffer,pic); Monitor Puffer { buffer public: write(buffer,pic) read(buffer,pic) Betriebssysteme, WS 2014/15 wk - 128 - } Aufrufer muss nicht wissen ob Synchronisation nötig ist mit welchen Mechanismen dies erfolgen muss welche Regeln dabei gelten 2.5.2 Hoare sche Monitore

Betriebssysteme, WS 2014/15 wk - 129-2.5.2 Hoare sche Monitore Ziel der Regeln Monitor-Synchronisationsregeln Wechselseitiger Ausschlusses der Monitoroperationen zu jedem Zeitpunkt ist höchstens ein Thread in einem Monitor aktiv 1. Jede Monitoroperation ist am Eingang und an den Ausgängen durch einen Türsteher gesichert 2. Das Betreten des Monitors erfolgt nur mit dessen Zustimmung ( Anklopfen ) 3. Falls ein anderer Thread im Monitor aktiv ist, wird die Zustimmung verweigert und der anklopfende Thread suspendiert ( P-Operation) 4. Wenn ein Thread den Monitor verlässt, wird ein wartender Thread eingelassen (fortgesetzt, V-Operation) Teil 1

Betriebssysteme, WS 2014/15 wk - 130-2.5.2 Hoare sche Monitore Implementierung der Regeln basierend auf Konzepten geringeren Abstraktionsniveaus: Semaphore je Monitor ein Semaphor jede Operation eines Monitors enthält am Eingang eine P-Operation an jedem (!) Ausgang eine V-Operation auf diesen Semaphor

Betriebssysteme, WS 2014/15 wk - 131-2.5.2 Hoare sche Monitore Benutzung von Monitoren Komfortabel: integriert in Programmiersprache Programmiersprache kennt die Abstraktion Monitor Modula-2, Concurrent Pascal Monitor-Operationen werden automatisch durch P- und V-Operationen geklammert (Compiler) Vollständigkeit und Symmetrie der Synchronisationsoperationen durch Compiler garantiert CLASS Puffer = Monitor { } VAR buffer; PROCEDURE ENTRY write( ) BEGIN END;

Betriebssysteme, WS 2014/15 wk - 132-2.5.2 Hoare sche Monitore Benutzung von Monitoren Weniger komfortabel: schwache Integration: Java, class Monitor aus dem thread-package class Puffer extends Monitor { } manuelle Integration von enter()/leave()-operationen, fehleranfällig verwandt: synchronized-methoden (wechselseitiger Ausschluss) synchronized write(pic) { }

Betriebssysteme, WS 2014/15 wk - 133-2.5.2 Hoare sche Monitore Geschwindigkeitsdifferenz Bedingungsvariable ( Conditions ) Quelle (Writer): forever do { if Puffer voll warte auf (Puffer nicht voll); if Puffer leer signalisiere (Puffer nicht leer); schreibe Bild; } Senke (Reader): forever do { if Puffer leer warte auf (Puffer nicht leer); if Puffer voll signalisiere (Puffer nicht voll); lese Bild; } Bedingungsvariable Puffer nicht voll, Puffer nicht leer mit 2 Operationen: Warten auf das Vorliegen der Bedingung Signalisieren des Vorliegens der Bedingung Monitore mit Bedingungsvariablen (vgl. Semaphore: buffermt, bufferfull)

Betriebssysteme, WS 2014/15 wk - 134-2.5.2 Hoare sche Monitore Ziel Monitor-Synchronisationsregeln Wechselseitiger Ausschluss und Geschwindigkeitsanpassung 1. Jede Monitoroperation ist am Eingang und den Ausgängen durch einen Türsteher gesichert 2. Das Betreten des Monitors erfolgt nur mit dessen Zustimmung ( Anklopfen ) 3. Falls bereits ein anderer Thread im Monitor aktiv ist, wird die Zustimmung verweigert und der anklopfende Thread suspendiert ( P-Operation) 4. Wenn ein Thread den Monitor verlässt, wird ein wartender Thread eingelassen (fortgesetzt, V-Operation) 5. Gerät ein Thread innerhalb einer Monitoroperation in eine Wartesituation (warten auf Bedingungsvariable), so verlässt er den Monitor 6. Bevor ein auf eine Bedingung wartender Thread fortgesetzt wird, muss er wieder am Türsteher vorbei Teil 2

Betriebssysteme, WS 2014/15 wk - 135-2.5.2 Hoare sche Monitore Implementierung der Bedingungsvariablen je Bedingungsvariable ein Semaphor (mit seiner Warteschlange) wait-operation eines Monitors P-Operation des Semaphores signal-operation eines Monitors V-Operation des Semaphores

Betriebssysteme, WS 2014/15 wk - 136-2.5.2 Hoare sche Monitore Benutzung von Bedingungsvariablen Komfortabel: integriert in Programmiersprache Programmiersprache kennt den Typ Monitor den Typ Bedingungsvariable die Operationen wait und signal Datenstrukturen für Bedingungsvariablen durch Compiler automatisch generiert wait und signal im Laufzeitsystem der Sprache implementiert z.b. Java: class Condition mit Methoden await() und signal() class Puffer extends Monitor { } Condition nonfull = new Condition(); nonfull.await();

Betriebssysteme, WS 2014/15 wk - 137-2.5.2 Hoare sche Monitore Das allgemeine Erzeuger/Verbraucher-Problem Producer/Consumer, Reader/Writer, Bounded Buffer Erzeuger: forever do { erzeuge(i); buffer.write(i); }; Codec monitor class buffer { int count=0, n=10, buffer[1..n]; condition nonfull, nonmt; Server Verbraucher: forever do { i=buffer.read(); verbrauche(i); }; } void write(int i) { if (count == n) then wait(nonfull); if (count == 0) then signal(nonmt); count = count +1; buffer[count] = i; }; int read() { if (count == 0) then wait(nonmt); if (count == n) then signal(nonfull); count = count-1; return(buffer[count+1]); }

Betriebssysteme, WS 2014/15 wk - 138-2.5.2 Hoare sche Monitore Beispiel zeigt Lösung 2er Aspekte der Synchronisation wechselseitiger Ausschluss der Zugriffe auf gemeinsame Daten ( buffer ) durch wechselseitigen Ausschluss von Monitoroperationen kurzzeitiges Ausbremsen Anpassung unterschiedlicher Geschwindigkeiten von Erzeuger und Verbraucher durch Warten auf und Signalisieren von Bedingungen (nonfull, nonmt) längerfristiges Ausbremsen

Betriebssysteme, WS 2014/15 wk - 139-2.5.2 Hoare sche Monitore Anmerkungen zu Semaphoren und Hoare schen Monitoren Methoden und Techniken verwendbar für Threads und Prozesse innerhalb eines BS Threads innerhalb eines Anwendungsprozesses Anwendungsprozesse untereinander (cave! Gemeinsamer Speicher!) BSe implementieren derartige Synchronisationsmechanismen selber Anwendungsprozesse nutzen Bibliotheken oder BS-Dienste, z.b. Semaphore über Systemdienste (z.b. Unix): semop, semctl, semget Threadbibliotheken: pthread_mutex_lock, pthread_mutex_unlock, pthread_cond_wait, pthread_cond_signal Monitore Java-Klassenbibliotheken (thread-package) Systemimplementierungssprachen wie Concurrent Pascal, Modula

Betriebssysteme, WS 2014/15 wk - 140-2.5.3 Transaktionaler Speicher 2.5.3 Transaktionaler Speicher Problem Semaphore Hoare sche Monitore lösen das Problem wechselseitigen Ausschlusses durch Sperren Verhinderung paralleler Abläufe Damit haben wir heute vermehrt ein Problem: Performanz

Betriebssysteme, WS 2014/15 wk - 141-2.5.3 Transaktionaler Speicher Performanz Lange Zeit war Performanz sehr bequem wachsende Systemleistung durch wachsende CPU-Geschwindigkeit und interne Parallelität Erhöhung der Taktfrequenz Pipelining: Zerlegung und parallele Abarbeitung einzelner Maschineninstruktionen Hyperthreading: parallele Maschineninstruktions- und Datenstromverarbeitung spekulative Ausführung auf Maschineninstruktionsebene für Software weitgehend unsichtbar

Betriebssysteme, WS 2014/15 wk - 142-2.5.3 Transaktionaler Speicher Ära ist beendet physikalische Aspekte der Energieverteilung/Wärmeableitung auf Chip Limitierung der Steigerung der Taktfrequenz logische Aspekte der Instruktionsausführung Limitierung spekulativer Ausführung und Instruktionsparallelität Leistungssteigerung durch Paradigmenwechsel der Prozessorarchitektur: Multicores Paradigmenwechsel der Software notwendig: parallele/verteilte Algorithmen hochparallele, nicht sperrende Synchronisationsmodelle transaktionaler Speicher

Betriebssysteme, WS 2014/15 wk - 143-2.5.3 Transaktionaler Speicher Stand der Kunst: frisch Vorschläge zur Programmiermodellbildung zahlreiche prototypische HW (+ SW) -Implementierungen erste serienreife (...) Prozessoren (e.g. Intel Haswell, IBM) Interessant. Vielversprechend. aber:

Betriebssysteme, WS 2014/15 wk - 144-2.5.4 Botschaften 2.5.4 Botschaften Problem Semaphore Hoare sche Monitore TM erfordern zu ihrer Implementierung gemeinsamen Speicher der Beteiligten Gibt es nicht falls die Beteiligten auf unterschiedlichen Rechnern ablaufen in lose gekoppelten MP-Architekturen disjunkte Adressräume (s.u.) besitzen ein anderes Kommunikationsparadigma muss her

Betriebssysteme, WS 2014/15 wk - 145-2.5.4 Botschaften Die Idee Codec- Prozess Fileserver Betriebssystem

Die Idee Codec- Prozess Fileserver Betriebssystem Betriebssystem Codec-Prozess: forever do { codepicfromcamerastream(pic); send(fileserver, pic); } Fileserver: forever do { receive(pic); SomeFile.write(pic); } Betriebssysteme, WS 2014/15 wk - 146-2.5.4 Botschaften

Betriebssysteme, WS 2014/15 wk - 147-2.5.4 Botschaften Botschaftenbasierte Kommunikation 2 elementare Operationen Senden einer Botschaft an einen Empfänger send(in Empfänger, IN Botschaft) Empfangen einer Botschaft von einem Absender receive(out Absender, OUT Botschaft) zahleiche Varianten: Vorlesungen Kommunikationsmodelle, Telematik

Betriebssysteme, WS 2014/15 wk - 148-2.5.2 Hoare sche Monitore Anmerkungen genutzt für Kommunikation zwischen Prozessen innerhalb eines (Mikrokern-) BS Anwendungsprozesse untereinander (Klienten, Server) BSe implementieren send/receive-ipc Anwendungsprozesse nutzen Bibliotheken oder BS-Dienste, z.b. (Linux): msgsnd, msgrcv Sockets

Betriebssysteme, WS 2014/15 wk - 149-2.5.5 Fernaufrufe 2.5.5 Fernaufrufe (Remote Procedure Calls, RPCs) Problem Datenmodell des send/receive-modells: Zeichenfolge sehr primitiv gewohnte Datenmodelle z.b. aus Programmiersprachen (Prozedur) Signaturen (typisierte Parameterlisten) Idee: Adaption eines anwendungsnahen, unkomplizierten und vertrauten Kommunikationsmodells an die Eigenschaften verteilter Systeme Prozedurfernaufruf (Remote Procedure Call, RPC) Methodenfernaufruf (Remote Method Invocation, RMI) Kommunikationsmodelle, Kap. 3.6, funktionsaufrufbasierte Modelle

Betriebssysteme, WS 2014/15 wk - 150-2.5.5 Fernaufrufe Wo finden wir RPCs/RMIs? Kommunikation zwischen Computern mit Netzwerk-Betriebssystemen verteilte Dateisysteme (Sun Network File System (NFS)) Zeitserver (NTP) Namendienste (DNS) Kommunikation zwischen Betriebssystemkomponenten in Mikrokernarchitekturen Interaktionen von Prozess- und Dateimanagement aber auch: Kommunikation zwischen Komponenten verteilter Anwendungssysteme (CORBA, Java-VM) Finanz- und Versicherungswirtschaft (Sicherheitsinfrastrukturen) Telemetriesysteme (Raumfahrt) Telekommunikationssysteme (Vermittlungssysteme) Echtzeitsysteme (Produktionsanlagensteuerung) eingebettete Systeme (Fahrzeugsteuerung)

Betriebssysteme, WS 2014/15 wk - 151-2.5.5 Fernaufrufe Szenario Beispiel 1 Kommunikation zwischen Computern mit Netzwerk-Betriebssystemen Unix-Systemfamilie vernetzt mittels LAN verteiltes Dateisystem: Sun Network File System (NFS) Kommunikationsmechanismus: Sun RPC Das Szenario physisch Fileserver

Betriebssysteme, WS 2014/15 wk - 152-2.5.5 Fernaufrufe Das Szenario logisch Zusammenkleben zunächst unabhängiger Filesysteme Klebestellen : mount-punkte was geschieht an einem Klebepunkt?

Betriebssysteme, WS 2014/15 wk - 153-2.5.5 Fernaufrufe Softwarekomponenten des Szenarios Arbeitsplatzrechner- Betriebssystem Fileserver- Betriebssystem lokales Dateisystem NFS- Klient RPC NFS- Server home green Umlenkung mount blauserver.prakinf.tu-ilmenau.de:/home/blau /home mount grünserver.prakinf.tu-ilmenau.de:/grün /green...

Betriebssysteme, WS 2014/15 wk - 154-2.5.5 Fernaufrufe Beispiel 2 Betriebssysteme mit Kern-Architektur Grundidee dieser Architekturform elementare Betriebssystem-Funktionalität in sehr kleinem, hochprivilegiertem Betriebssystemkern ( Kern) typische Funktionen: Threads, Adressräume, IPC weniger elementare Aufgaben schwächer privilegiert ( reguläre Anwendungssysteme) API - Implementierung Prozess-Server Fileserver Prozessmanagement Netzwerkprotokolle VMM NetzwerkSvr Gerätetreiber Dateisystem VMM Kern: Threads, Adressräume, IPC Hardware monolithische Schichtenarchitektur Hardware Kern-Architektur

Betriebssysteme, WS 2014/15 wk - 155-2.5.5 Fernaufrufe Folgen Isolation der BS-Komponenten Adaptivität (Auf- und Abskalierung der Systemfunktionalität) Robustheit (Fehlerisolation) IT-Sicherheit (TCB-Größe) Korrektheit (Verifizierbarkeit) Kommunikationskosten API - Implementierung Prozess-Server Fileserver Prozessmanagement Netzwerkprotokolle VMM NetzwerkSvr Gerätetreiber Dateisystem VMM Kern: Threads, Adressräume, IPC Hardware monolithische Schichtenarchitektur Hardware Kern-Architektur

Betriebssysteme, WS 2014/15 wk - 156-2.5.5 Fernaufrufe Kommunikationskosten Prozeduraufruf monolithische Architektur: innerhalb eines Adressraums Prozedurfernaufruf Kern-Architektur: über Adressraumgrenzen hinweg API - Implementierung Prozess- Server Fileserver Prozessmanagement Netzwerkprotokolle VMM Netzwerk- Server Gerätetreiber Dateisystem VMM Kern Hardware Hardware

Betriebssysteme, WS 2014/15 wk - 157-2.5.5 Fernaufrufe Zahltag Das kostet! RPCs gibt es nicht umsonst: Parameter-Marshalling, Prozess/Addressraumwechsel Laufzeiten Zyklen 2300 754 730 800 464 7 125 75 PC Accent (1981) Mach (1986) V-Kernel (1986) Amoeba (1986) Taos (1990) Taos LRPC (1990) L4 (1997) leichtgewichtige RPC-Modelle, z.b. in Kern-Architekturen

Betriebssysteme, WS 2014/15 wk - 158-2.5.6 Systemaufrufe 2.5.6 Systemaufrufe Problem: Kommunikation Anwendungsprozess BS BS stellt zahlreiche Dienste bereit (Linux 250, Apple OS X 500); z.b. Prozesserzeugung (fork) Programmausführung (exec ) Dateimanagement (open, close, read, write) Kommunikation (msg, socket, shm ) In diesem Abschnitt: Aufrufmethoden und -mechanismen Ring 3 - Privilegien Prozeduraufruf++ Anwendungsprozess fork(),... Ring 0 - Privilegien BS-Dienste Betriebssystem-Schnittstelle (Application Programmer s Interface (API)) Prozessmgmt Dateisysteme Sockets...

Betriebssysteme, WS 2014/15 wk - 159-2.5.6 Systemaufrufe Methodische Überlegungen: geeignetes Aufrufmodell? Wünsche des Anwendungsentwicklers Bequemlichkeit Performanz (hohe Aufruffrequenz, tausende pro Sekunde) Wünsche des BS-Entwicklers Sicherheit Robustheit reguläre Prozeduraufrufe erfüllen Kriterien nicht (unterschiedliche Adressräume, Privilegien, Programmiersprachen) Prozedurfernaufruf: bequem, performant, sicher, robust teuer leichtgewichtiges RPC-Modell

Betriebssysteme, WS 2014/15 wk - 160-2.5.6 Systemaufrufe Ablauf eines Systemaufrufs Anwendungsebene Anwendungsprozess:... write(fd,buffer,nbytes);... libc: write(fd,buffer,nbytes) { push(nbytes); push(buffer); push(fd); push(write_c); TRAP; } Datensegment Codesegment write_c fd buffer nbytes User-SP Stacksegment Betriebssystem-Schnittstelle (Application Programmer s Interface (API)) Sys_write() { ParamArea=User-SP+8; // Verweis auf aufrufspezifische Parameter-struct fd=paramarea->fd; buffer=paramarea->buffer; nbytes=paramarea->nbytes; Betriebssystem struct { int fd; char* buffer; int nbytes } ParamArea; TRAP-Interruptbehandlung: switch User-SP-> case read_c: Sys_read() case write_c: Sys_write()

Betriebssysteme, WS 2014/15 wk - 161-2.5.6 Systemaufrufe Probleme hierbei und ihre Lösungen Problem: Unterschiedliche Programmiersprachen kein einheitliches Format der Aufrufparameter (Reihenfolge, Format) Lösung: normierte Parameterstruktur und Datentyprepräsentation zwischen Anwendungsprogramm und Betriebssystem definiert durch API-Spezifikation des BS implementiert durch zwischengeschaltete Bibliothek (z.b. libc; Stellvertreter-Prozeduren, Urform heutiger Middleware-Stubs) libc: write(fd,buffer,nbytes) { push(nbytes); push(buffer); push(fd); push(write_c); TRAP; } write_c fd buffer nbytes

Betriebssysteme, WS 2014/15 wk - 162-2.5.6 Systemaufrufe Problem: Separate Namensräume Sys_write liegt nicht im Namensraum des Anwendungsprozesses Einigung auf Namenskonventionen ( push(write_c) ) Anwendungsprozess:... write(fd,buffer,nbytes)... libc, Code für write: push(nbytes); push(buffer); push(fd); push(write_c); TRAP; write_c fd buffer nbytes Sys_write() { ParamArea=User-SP+8; fd=paramarea->fd; buffer=paramarea->buffer; nbytes=paramarea->nbytes; TRAP-Interruptbehandlung: PAR=User-SP+4; switch PAR-> case read_c: Sys_read() case write_c: Sys_write()

Betriebssysteme, WS 2014/15 wk - 163-2.5.6 Systemaufrufe Problem: Separate Adressräume kein direkter Zugriff auf Parameter seitens der aufgerufenen Prozedur Parameter-Datenstruktur; Alternativen dabei: in Registern, in gemeinsamen Speicherbereich (Stack) write_c fd buffer nbytes Sys_write() { ParamArea=User-SP+8; fd=paramarea->fd; buffer=paramarea->buffer; nbytes=paramarea->nbytes; TRAP-Interruptbehandlung: PAR=User-SP+4; switch PAR-> case read_c: Sys_read() case write_c: Sys_write()