Dr. Peter Tröger / Prof. M. Werner

Transkript

1 Betriebssysteme Sommersemester 2017 Betriebssysteme 11. Kapitel Resümee Dr. Peter Tröger / Prof. M. Werner Professur Betriebssysteme

2 Was ist ein Betriebssystem? SoSe 2017 P. Tröger / M. Werner 2 / 31 osg.informatik.tu-chemnitz.de

3 Zwei Sichten 1. Virtuelle Maschine (Top-Down Sicht): Bietet dem Programmierer eine abstrakte Sicht auf die Hardware an Reale Eigenschaften der Hardware werden versteckt Beispiel: Festplatte/Dateisystem Reale Maschine (Hardware): Folge von Datenblöcken fester Größe Virtuelle Maschine (BS): Benannte Dateien variabler Größe SoSe 2017 P. Tröger / M. Werner 3 / 31 osg.informatik.tu-chemnitz.de

4 Zwei Sichten (Forts.) 2. Verwalter für Ressourcen (Bottom-Up Sicht): Koordiniert Zugriff auf Prozessoren, Speicher, Platten, Terminals,... Zeitliche Ressourcenverwaltung: Anwendungen greifen nacheinander auf Ressourcen zu (z. B. Drucker) Räumliche Ressourcenverwaltung: Anwendungen greifen auf unterschiedliche Bereiche einer Ressource zu (z. B. Speicher) SoSe 2017 P. Tröger / M. Werner 4 / 31 osg.informatik.tu-chemnitz.de

5 Stundenglas-Architektur Verschiedenartigste Anwendungen Diversität Betriebssystem- Programmierschnittstelle BS-Schnittstelle Verschiedenartigste Hardware Diversität Anwendungsneutralität: Eine stabile, universelle Programmierschnittstelle sollte bereitgestellt werden Betriebssysteme für Universalrechner sollten anwendungsneutral sein Spezielle Fähigkeiten so weit oben wie möglich platzieren SoSe 2017 P. Tröger / M. Werner 5 / 31 osg.informatik.tu-chemnitz.de

6 Dienste und Betriebsmittel Viele Anwendungen / Prozesse haben ähnliche Wünsche an die Infrastruktur Standardisierte Dienste des Betriebssystems Umsetzung des Stundenglas-Prinzips Anwendung(en) Dienste vereinheitlichter Zugriff spezifischer Zugriff Das Betriebssystem ist letztendlich nur ein Betriebsmittelverwalter Jeder Dienst bezieht sich deshalb auf bestimmte Betriebsmittel Beispiele: Dateien, Fenster, Netzwerk, Eingabe, Ausgabe,... SoSe 2017 P. Tröger / M. Werner 6 / 31 osg.informatik.tu-chemnitz.de

7 Arten von Betriebsmitteln Es ist (hier) wenig hilfreich, spezifische Dienste detailliert zu betrachten Art und Signatur hängen stark von der Betriebssystemversion ab Verwaltete Betriebsmittel bleiben hingegen immer ähnlich Selten kommen neue BM-Klassen hinzu (Beispiel: GPUs) Fokus auf Betriebsmittel, Dienste als Beispiel Logische Betriebsmittel Aus organisatorischen Gründen ausgedacht Vereinheitlichen und vereinfachen den Zugriff, Beispiel: Dateien, Fenster Werden durch reale Betriebsmittel realisiert Reale (physikalische) Betriebsmittel Real vorhanden, zum Anfassen Beispiele: Serielle Schnittstelle, Grafikkarte In modernen Betriebssystemen sind Dienste für reale Betriebsmittel die Ausnahme SoSe 2017 P. Tröger / M. Werner 7 / 31 osg.informatik.tu-chemnitz.de

8 Betriebssysteme Resümee Prozesse Meist hat man mehr Prozesse als Prozessoren Wettbewerb zwischen Prozessen Prozessumschaltung wechselt ständig zwischen laufenden Programmen, um Fairness zu erreichen Prozessor ist aktives Betriebsmittel, zieht den Prozess an sich Das Umschalten wird vor dem Benutzer versteckt P1 virtuelle CPU P2 Px virtuelle CPU P virtuelle CPU Transformation Jeder Prozess erhält somit einen virtuellen Prozessor: Folge von Nutzungsabschnitten realer Prozessoren Kann durch mehrere reale Prozessoren realisiert werden reale CPU SoSe 2017 P. Tröger / M. Werner 8 / 31 osg.informatik.tu-chemnitz.de

9 Prozesse (Forts.) Prozessumschaltung Beim automatischen Umschalten können die Programme unverändert bleiben Das Umschalten wird von außen ausgelöst und kann zu jedem beliebigen Zeitpunkt stattfinden (Unterbrechungen dürfen nicht abgeschaltet sein) Es kommt zu einer verzahnten Ausführung der Programme Kooperatives Umschalten. Präemptives Umschalten. Umschalten Umschalten SoSe 2017 P. Tröger / M. Werner 9 / 31 osg.informatik.tu-chemnitz.de

10 Prozesszustände existent aktiv Wartend (waiting, blocked) Deblockieren (deblock) Blockieren (block) Löschen (delete) Deaktivieren (deactivate) Aufgeben (relinquish) nicht existent nicht aktiv bereit (ready) laufend (running) Erzeugen (create) Aktivieren (activate) Zuordnen (assign) SoSe 2017 P. Tröger / M. Werner 10 / 31 osg.informatik.tu-chemnitz.de

11 Leichtgewichts- vs. Schwergewichtsprozesse code% data% files% code% data% files% registers% stack% registers% registers% registers% stack% stack% stack% Thread' Thread' Thread' Thread' SoSe 2017 P. Tröger / M. Werner 11 / 31 osg.informatik.tu-chemnitz.de

12 Scheduling Betriebssysteme Resümee Neuankömmling bzw. verdrängter Prozess Einordnen gemäß Strategie Prozessoren... nächster Prozess... SoSe 2017 P. Tröger / M. Werner 12 / 31 osg.informatik.tu-chemnitz.de

13 Bedienzeit vs. Antwortzeit Ankunft warten rechnen Ende Wartezeit (waiting time) Antwortzeit (response time) Bedienzeit (execution time) SoSe 2017 P. Tröger / M. Werner 13 / 31 osg.informatik.tu-chemnitz.de

14 Hauptspeicher Ausführung eines Programms: Instruktionen liegen im Hauptspeicher (bzw. Cache) vor CPU lädt diese und führt sie aus (program counter, Assembler) Instruktionen mit absoluter und relativer Adressierung Wie bei vielen Ressourcen wird auch bei Speicher zwischen physischer und logischer Ressource unterschieden Konzept des Adressraums In diesem Zusammenhang gibt es eine Reihe von Problembereichen: Zuordnung logischen zu physischen Adressraum Adressumsetzung Effektive Nutzung von Speicher Virtueller Speicher Speicherverwaltung innerhalb des logischen Adressraums SoSe 2017 P. Tröger / M. Werner 14 / 31 osg.informatik.tu-chemnitz.de

15 Adressumsetzung mit Kachelung / Paging Logische Adressen bestehen nun aus zwei Teilen: Seitennummer (page number) und Relativadresse (offset, displacement) innerhalb der Seite Seitentabelle pro laufenden Programm, ebenfalls im Hauptspeicher Prozessor braucht lediglich physische Basisadresse der Seitentabelle Im Register gespeichert, minimaler Aufwand bei Prozessumschaltung MMU ermittelt aus Seitennummer den passenden Tabelleneintrag Physische Basiadresse der Kachel und Offset werden addiert Tabellenbasisadresse Seitentabelle Speicher + Seite Byte Programm-/Datenadresse K SoSe 2017 P. Tröger / M. Werner 15 / 31 osg.informatik.tu-chemnitz.de

16 Verschnitt Betriebssysteme Resümee Variante 1: Physischer Adressraum wird in gleich lange Stücke aufgeteilt Speicheranforderung wird auf Vielfaches einer festen Größe aufgerundet Dadurch entsteht Speicherplatz, der als belegt gekennzeichnet ist, aber nicht benutzt wird interner Verschnitt f int (internal fragmentation) Variante 2: Physischer Adressraum wird in unterschiedlich lange Stücke aufgeteilt Speicheranforderung wird exakt bedient Durch die Dynamik des Belegens/Freigebens kann es vorkommen, dass eine Anforderung zwar von der Gesamtmenge des freien Speichers her erfüllbar wäre, durch die Zerstückelung jedoch kein hinreichend großes Stück gefunden werden kann externer Verschnitt f ext (external fragmentation) SoSe 2017 P. Tröger / M. Werner 16 / 31 osg.informatik.tu-chemnitz.de

17 Speicher schneller, teurer, kleiner Betriebssysteme Resümee Register Cache Hauptspeicher langsamer, billiger, größer Massenspeicher (Magnetplatte, Solid State Disk,...) Archiv (Band, CD-ROM,...) Hauptspeicher oberste Schicht, auf die vollständig wahlfrei zugegriffen wird SoSe 2017 P. Tröger / M. Werner 17 / 31 osg.informatik.tu-chemnitz.de

18 Lokalitätsprinzip Speicherhierarchie beruht auf dem Lokalitätsprinzip (Principle of locality) Programm greift in kleinen Zeitraum t nur auf kleinen Teil seines Adressraums A zu Prinzip der räumlichen Lokalität Wird auf eine Adresse a zugegriffen, so ist Zugriff auf eine Adresse in der Nähe von a wahrscheinlich. Prinzip der zeitlichen Lokalität Wird auf eine Adresse a zugegriffen, so ist erneuter Zugriff auf a in Kürze wahrscheinlich. SoSe 2017 P. Tröger / M. Werner 18 / 31 osg.informatik.tu-chemnitz.de

19 Speichervirtualisierung Häufig ist der Hauptspeicher nicht hinreichend für alle Prozesse Daher gibt es mehrere Ansätze, größeren Speicher aus der Speicherhierachie (Festplatte) zu nutzen: Swapping: Ein Prozess läuft nur, wenn er vollständig im Hauptspeicher ist; Prozesse werden wiederholt vollständig ein- und ausgelagert z.b. frühes UNIX Memory Overlay: Prozesse betreiben eigenes Speichermanagement und lagern Teile ihres Speichers in Dateien ein und aus z.b. häufig in MS-DOS Demand Paging: Prozesse laufen auch wenn nur ein Teil von ihnen im Hauptspeicher liegt fast alle modernen Betriebssysteme Demand Paging ist State of the Art SoSe 2017 P. Tröger / M. Werner 19 / 31 osg.informatik.tu-chemnitz.de

20 Demand Paging Seitenfehler leere Kachel verfügbar? Nein Ja Ausräumen Kachel zum Räumen auswählen Kachelinhalt (Seite) modifiziert? Ja Nein Seite auslagern auf Ersatzspeicher Neue Seite einlagern von Ersatzspeicher Einräumen Eintrag Kacheltabelle Eintrag Seitentabelle SoSe 2017 P. Tröger / M. Werner 20 / 31 osg.informatik.tu-chemnitz.de

21 Linearer Speicher / Heap Ein linearer Adressraum wird nicht als Ganzes genutzt Konzept von Allokation und Freigabe bestimmer Bereiche Vergleich mit der Idee der Prozesszustände: bereit (Allokation der CPU) vs. wartend (Freigabe der CPU) Seitentabellen unterstützen die Überprüfung, ob genutzte Speicherbereiche vorher alloziert wurden Bekannt aus C-Programmierung malloc() vs. free() Adressumsetzung und lineare Speicherverwaltung sind orthogonal Bsp.: Bare-Metal-Software Verwendet physische Adressierung, ohne Umsetzung Trotzdem C-Bibliothek für lineare Verwaltung verfügbar Speicherbereiche im Adressraum werden zu einer limitierten Ressource Grenzen für die Menge des allozierbaren Speichers Belegen und Freigeben muss koordiniert werden, auch bei Threading SoSe 2017 P. Tröger / M. Werner 21 / 31 osg.informatik.tu-chemnitz.de

22 Interaktion Prozesse A und B als Teil eines Programmsystems müssen interagieren: sich aufrufen (bzw. beauftragen) aufeinander warten oder gegenseitig fortsetzen sich abstimmen Informationen austauschen Unbewußte Interaktion: Gemeinsame Daten oder zeitliche Abstimmung im Kern Kernausschluss Indirekt bewußte Interaktion: Gemeinsame Daten oder zeitliche Abstimmung in der Implementierung Kooperation Direkt bewußte Interaktion: Explizite Datenübertragung in der Implementierung Kommunikation SoSe 2017 P. Tröger / M. Werner 22 / 31 osg.informatik.tu-chemnitz.de

23 Kommunikation vs. Kooperation Kommunikation (=expliziter Datentransport) P 1 P 2 Kooperation (=Zugriff auf gemeinsame Daten) P 1 P 2 gemeinsamer Teil D 1 D 2 Kopieren D 2 D 1 gerichtete Beziehung symmetrische Beziehung SoSe 2017 P. Tröger / M. Werner 23 / 31 osg.informatik.tu-chemnitz.de

24 Probleme Interaktion hat funktionalen Aspekt und zeitlichen Aspekt Prozesse einigen sich bzgl. gemeinsamer Daten Prozesse einigen sich bzgl. kritischer Abschnitte Prozesse einigen sich bzgl. Reihenfolge Letztendlich immer Zugriff auf geteiltes Betriebsmittel bzw. Ressource Unbewußte Interaktion: Nebenläufiger Zugriff im Kern Indirekt bewußte Interaktion: Nebenläufiger Zugriff auf gemeinsame Daten Direkt bewußte Interaktion: Nebenläufiger Zugriff auf Kommunikationskanal Was kann schief gehen? Verklemmung der beteiligten Prozesse Verhungern der beteiligten Prozesse SoSe 2017 P. Tröger / M. Werner 24 / 31 osg.informatik.tu-chemnitz.de

25 11.2 Noch nicht genug? 11.2 Noch nicht genug? Im der Grundveranstaltung Betriebssysteme gibt es eine Reihe von naheliegenden Themen, die nicht behandelt wurden: Bedienkonzepte und grafische Schnittstellen Programmierung von Treibern Schutz und Sicherheit Virtuelle Maschinen Betriebssysteme für verteilte Systeme Betriebssysteme für eingebettete Systeme Echtzeitverhalten... SoSe 2017 P. Tröger / M. Werner 25 / 31 osg.informatik.tu-chemnitz.de

26 11.2 Noch nicht genug? Vertiefungen Echzeitsysteme, eingebettete Systeme Entwurf von Software für eingebettete Systeme (Prof. Masrur) Wintersemester außerdem interessant: Hardware/Software Codesign (Prof. Hardt) Echtzeitsysteme (Prof. Werner, Sommersemester) Verlässliche Systeme (Prof. Werner, Wintersemester) SoSe 2017 P. Tröger / M. Werner 26 / 31 osg.informatik.tu-chemnitz.de

27 11.2 Noch nicht genug? Vertiefungen (Forts.) Verteiltheit Vorlesung Betriebssysteme für verteilte Systeme Wintersemester außerdem interessant: Parallele Programmierung (Prof. Rünger) Multicore Programmierung (Prof. Rünger) Sicherheit verteilter Systeme / Management Verteilter Systeme (Prof. Gaedke) SoSe 2017 P. Tröger / M. Werner 27 / 31 osg.informatik.tu-chemnitz.de

28 11.2 Noch nicht genug? Vertiefungen (Forts.) Modellierung Vorlesung Betriebssysteme 2: Modellierung und Analyse Sommersemester außerdem interessant: Diskrete Optimierung (Prof. Helmberg, Mathematik) z.t. Geschäftsprozessmodellierung und -management (Prof. Dinter, Wirtschaftsinformatik) SoSe 2017 P. Tröger / M. Werner 28 / 31 osg.informatik.tu-chemnitz.de

29 11.2 Noch nicht genug? Aktuelle Forschungsthemen An der Professur Betriebssysteme gibt es eine Anzahl interessanter Forschungsthemen, u.a.: Betriebssystemunterstützung für verteilte mobile Systeme Cyber-physical systems Bare-Metal Programmierung Verlässlichkeitsmodellierung Echtzeit-Scheduling In allen Bereichen gibt es Themen für studentische Arbeiten (Studien-, Bachelor- und Masterarbeiten) Details unter SoSe 2017 P. Tröger / M. Werner 29 / 31 osg.informatik.tu-chemnitz.de

30 Reflexion Betriebssysteme Resümee 11.2 Noch nicht genug? Was hatten Sie erwartet? Was war gut/schlecht? Was sollte unbedingt beibehalten/besser weggelassen werden? Was kann verbessert werden? Wie lässt sich die Lehrveranstaltung besser ins restliche Curriculum einbauen? SoSe 2017 P. Tröger / M. Werner 30 / 31 osg.informatik.tu-chemnitz.de

31 Viele Erfolg bei den Prüfungen! Gute Erholung in der vorlesungsfreien Zeit! SoSe 2017 P. Tröger / M. Werner 31 / 31 osg.informatik.tu-chemnitz.de