TIMI: Technische Informatik für Medieninformatiker Bachelor-Studiengang Digitale Medien Medieninformatik SS 2005 Niels Pollem <np@tzi.de> Arbeitsgruppe Rechnernetze (Prof. Dr.-Ing. Ute Bormann) Aufgaben eines Betriebssystems Abstraktion von (komplexen) Geräteeigenschaften uniforme Schnittstelle(n) zu Geräten Bereitstellung einer virtuellen Maschine Unterstützung eines Mehrbenutzerbetriebs Ressourcenverwaltung (Prozessor, Speicher,...) Schutzmechanismen (Safety + Security) denn: CPU sieht einfach nur ein Programm
Geschichtlicher Überblick: Stufen 1940: ENIAC und Konsorten hart programmiert 1955: einfacher Stapelbetrieb, z.b. mit Lochkarten nur ein Programm im Rechner vorhanden Ergebnis erst nach vollständigem Durchlauf 1962: Mehrfachstapelbetrieb Ressourcenausnutzung 1965: Dialogbetrieb ( Timesharing ), z.b. via Terminal verhältnismäßig interaktiver Zugang zum Rechner zwar noch nicht bunt, aber keine Wartezeiten mehr Die signifikanten Erweiterungen Zentrale OS-Konzepte: Der Prozeß 1985: Netzwerkbetriebssysteme (Achtung: Rechnernetz) Rechnernetz wird im Systemkern berücksichtigt kooperierende Knoten, z.b. Client/Server-Systeme 1985: verteilte Betriebssysteme Multiprozessorsysteme transparente Verteilung der Prozesse auf Prozessoren Echtzeitbetriebssysteme Realzeit-Anwendungen spezifische Anforderungen ein Prozeß ist ein Programm in Ausführung bekannt: System mit einem Prozeß mehrere Programme in Ausführung Verwaltungsbedarf Identifikation Verarbeitungszustand Ressourcen Schutzmechanismen Aufgabe des Betriebssystems, transparent für Programme
Zentrale OS-Konzepte: Die Datei eine Datei ist ein langlebiges Datenobjekt (persistent) über eindeutigen (Pfad-)Namen referenzierbar von Prozessen zugreifbar und ggf. modifizierbar Strukturierung über hierarchische Verzeichnisse für den Nutzer ergibt sich Baum-artige Struktur UNIX: Alles ist eine Datei. auch Geräte usw. im Dateisystem abgebildet dadurch einheitliche Schnittstelle für viele Vorgänge Zentrale OS-Konzepte: Der Shell Prozeßverwaltung Scheduling der Shell ist der primäre Kommandointerpreter in UNIX Benutzungsschnittstelle Absetzen von Aufträgen $ date Tue Apr 30 02:55:38 MEST 2002 Shell ist ebenfalls ein Prozeß, startet Kind-Prozesse graphische Oberflächen setzen jeweils auf Shell auf analog bei Windows: MS-DOS war noch lange Basis bash: komfortabel ausgebauter, programmierbarer Shell die Ressource CPU sinnvoll an Prozesse verteilen Anforderungen an den ausführenden Scheduler: fair ( jeder kommt hinreichend dran ) ggf. Prioritäten berücksichtigen interaktive Vorgänge einbeziehen Verfahren selbst darf nicht aufwendig sein grundlegende Ansätze: Batch und Timesharing
Scheduling: First In, First Out Scheduling: Shortest Job First FIFO: zuerst eingereihter Prozeß kommt auch zuerst dran wird abgearbeitet, bis sein Ende erreicht ist z.b. bei einfacher Stapelverarbeitung das Ergebnis liegt jeweils gleichbleibend schnell vor FIFO kann auch kurze Aufträge nicht mal eben ausführen Shortest Job First sortiert nach Ausführungsdauer bei vordefinieren Abläufen durchaus grob bekannt bei Einreihung neuer Prozesse ggf. erneut sortieren z.b. im Mehrfachstapelbetrieb verbesserter Durchsatz Scheduling: Timesharing-Ansatz Timesharing: mehrere Prozesse mehrere Prozesse sowie Betriebssystem im Hauptspeicher Aufteilung für Prozesse transparent interne Betrachtung Speicherverwaltung Prozesse nutzen Betriebssystem unterschiedliche Berechtigungen
Scheduling: Timesharing-Problem Interrupt: externe Unterbrechung mehrere Prozesse sollen nebenläufig im Rechner arbeiten nur so ist sinnvolles interaktives Arbeiten herzustellen und: nicht immer alle aktiv Ressourcenausnutzung Durchführbarkeit unklar, da Prozeß zu unterbrechen wäre freiwillige Abgabe durch Prozeß bricht Transparenz andererseits gibt ein Prozeß die CPU nicht zufällig ab folglich Mechanismus in Hardware erforderlich Interrupt Interrupt: externe Unterbrechung Clock-Interrupt Realzeit-Uhr Gerät triggert Interrupt-Controller Interrupt Prozessor meist zeitkritisch, umgehende Bearbeitung geboten unterschiedliche Prioritäten können sich daher wiederum gegenseitig unterbrechen alternativ müßten Geräte von der CPU abgefragt werden insofern deutliche Entkopplung möglich ( Aufträge ) für Scheduling offensichtlich interessant: Clock-Interrupt hierüber Aufteilung der CPU in Zeitscheiben möglich Taktung und Zeit für geordnete Abarbeitung erforderlich Taktsignal für Prozessor, Chipsatz, Systembus Realzeit-Uhr (auf dem Mainboard) Clock-Tick z.b. 100 mal in der Sekunde Zeitscheibe interne Darstellung der Realzeit sehr unterschiedlich UNIX: Sekunden seit GMT 00:00:00, January 1, 1970 Zeit endet GMT 03:14:07, Tuesday, January 19, 2038 übrigens: Realzeit-Uhr sollte niemals zurückgestellt werden
Prozessor: Unterbrechungsablauf Trap: eine interne Unterbrechung den Registersatz, PC usw. für spätere Bearbeitung speichern PC auf den Interrupt-Handler ändern in den Systemkern Interrupt-Handler ruft erforderliche Funktionen auf ggf. werden Ereignisse notiert Kontext wird wieder hergestellt der laufende Prozeß bekommt von allem schlicht nichts mit ein Prozeß verursacht selbst eine Unterbrechung Trap z.b. Division durch Null, illegaler Speicherzugriff unsichere Folgezustände Handlungsbedarf Prozeß wird ggf. vom Betriebssystem abgebrochen der eine gewollte Trap: Betriebssystemaufruf einziger Weg von innen in den Kernel-Mode Bearbeitung analog Unterbrechung durch Interrupt Kernel nur durch Trap (und Interrupt) zu betreten Safety Prozessor: Kernel- vs. User-Mode Prozessor: Kernel- vs. User-Mode Zugriff auf Ressourcen muß sicher und geordnet erfolgen Prozesse müssen diesbzgl. reglementiert werden Zugriffe nur über Betriebssystem ( Kernel ) zulassen freundliche Worte helfen nicht Hardware-Mechanismus Prozessor im Kernel-Mode: alle Zugriffe sind erlaubt User-Mode hingegen: Prozesse kennen nur sich selbst Betriebssystemaufruf: geordneter Zutritt zum Systemkern z.b. Bibliotheksaufrufe: open(), read(), write(),... auch Kommunikation zwischen Prozessen über Kernel
Scheduling: einfacher Round-Robin Round-Robin: mehrere Prioritäten Zeitscheiben-basiertes, konstantes Scheduling-Verfahren lauffähige Prozesse hängen in einer Warteschlange erster bekommt die CPU für eine Zeitscheibe zugeteilt wird dann am Ende der Warteschlange eingereiht Clock-Interrupt erforderlich, um Prozeß zu unterbrechen statt konstantem Scheduling oftmals Prioritäten erforderlich einfache Nachbildung über Länge der Zeitscheiben Prozeß mehrfach oder wiederholt in Warteschlange starre Warteschlange dennoch zumeist eher ungeeignet Interaktivität kurze, aber häufige CPU-Nutzung auch bisherige Laufzeit ist in Priorität einzubeziehen schlecht abzubilden Abkehr vom reinen Round-Robin besser: Prozeß mit jeweils höchster Priorität auswählen Round-Robin: Prioritäten-Aspekte Round-Robin: Prozeß-Kontostand einige Prozesse sollen grundsätzlich bevorzugt werden Basiswert je Prozeß: nice, um nett zu sein gibt bei ähnlichen Voraussetzungen den Ausschlag auch verbrauchte Laufzeit ist in Priorität einzubeziehen anderen CPU überlassen, nachdem selbst viel dran zwischen jungen und alten Prozessen ausgleichen auch hier: Interaktivität ist geeignet zu berücksichtigen Priorität kleine (ganzzahlige) numerische Repräsentation abhängig von bisheriger CPU-Nutzung + Basiswert CPU-Konto für jeden Prozeß Bilanz CPU-Nutzung nach jeder Zeitscheibe (prozentualen) Anteil addieren dann halbieren, um den Kontostand zu normalisieren sonst langlebige Prozesse sehr schnell benachteiligt ausreichend gutes, aber dennoch schlankes Verfahren findet in den meisten aktuellen Systemen Verwendung
Prioritäten: Beispiel Interaktivität: meist kurze Nutzung zwei lauffähige Prozesse A: Basiswert 0 B: Basiswert 60 Priorität Vergabe Zeitscheibe Kontostand + Basiswert niedriger besser ggf. entscheidet Basiswert Erwartung: A kommt öfter dran A: B: Scheduling: Warten auf Ereignis Prozeß: drei häufigste Zustände nicht alle Prozesse stets lauffähig Warten auf Ereignis z.b. Eingabe von der Tastatur, Daten von der Platte auf ein Ereignis wartender Prozeß blockiert auf diesem wird in Sleep-Queue (vs. Run-Queue ) eingereiht gibt die CPU ggf. gar während seiner Zeitscheibe ab Betriebssystem sorgt geeignet für s spätere Aufwecken Prozeß verbraucht keine CPU-Zeit durch ständige Abfrage wird ggf. durch Interrupthandler in Run-Queue gehängt