Organisation der Vorlesung, Einführung in Betriebssysteme. Betriebssysteme. Christoph Lindemann WS 2004/05

Transkript

1 Betriebssysteme WS 2004/05 Organisation der Vorlesung, Einführung in Betriebssysteme Christoph Lindemann Organisation der Übungen (1) Übungsgruppenorganisation Anmeldung 8 Übungsgruppen (8-20 Personen pro Übung) - 4 Übungsgruppen A-Woche - 4 Übungsgruppen B-Woche Ü-Gr. Termin/Woche Raum 1 / A Di A SG / B Di B SG / A Mi A SG / B Mi B SG / A Mi A SG / B Mi B SG / A Do A SG / B Do B SG 3-07 Mailinglisten etc. Durchführung der Übungsgruppen durch Herrn Hotzky und Herrn Mochalski des Lehrstuhls Rechnernetze und verteilte Systeme Universität Dortmund Rechnersysteme und Leistungsbewertung -2- Organisation der Übungen (2) Termine: Ausgabe Inhalt Übungen Woche Blatt 1: Strukturen von BS, Übung 1 zu Blatt 1 und Blatt 2:Prozesse und Threads A B Blatt 3: CPU Scheduling Übung 2 zu Blatt B A Blatt 4: Deadlocks, Übung 3 zu Blatt 4 und Blatt 5: Speicherverwaltung B A Blatt 6: Speicherverwaltung Übung 4 zu Blatt B A Blatt 7: Virtueller Speicher, Übung 5 zu Blatt 7 und Blatt 8: Dateiensystem B A Organisation der Übungen (3) Erste Übung: Für Übungsgruppen A-Woche in der 45. Kalenderwoche Für Übungsgruppen B-Woche in der 46. Kalenderwoche Erwerb des Übungsscheins: Test 70%, 30% Beteiligung in den Übungen Klausur: Datum wird noch bekannt gegeben Anwesenheitspflicht Universität Dortmund Rechnersysteme und Leistungsbewertung -3- Universität Dortmund Rechnersysteme und Leistungsbewertung -4-

2 Fahrplan Einleitung Organisation der Vorlesung, Einführung in Betriebssysteme Strukturen von Betriebssystemen Prozesse und Threads CPU Scheduling Synchronisation von Prozessen Keine Vorlesung Deadlocks Keine Vorlesung Speicherverwaltung (1) Speicherverwaltung (2) Virtueller Speicher Dateisystem Schnittstelle Strukturen von Rechnernetzen Verteilte Systemstrukturen Was ist ein Betriebssystem? Einfache Batch Systeme (Stapelverarbeitung) Multiprogramming Batched Systems Time-Sharing Systeme Personal-Computer Systeme Parallele Systeme Distributed Systems (verteilte Systeme) Real -Time Systems (Real-Zeit Systeme) Universität Dortmund Rechnersysteme und Leistungsbewertung -5- Universität Dortmund Rechnersysteme und Leistungsbewertung -6- Was ist ein Betriebssystem? dient als Mittler zwischen Rechnerhardware und dem Benutzer Ziele: Ausführung von Anwendungsprogrammen Vereinfachung von Lösungen der Probleme der Nutzer Komfortable Bedienung eines Rechnersystems effiziente Nutzung der Rechnerhardware Komponenten eines Rechenersystems Hardware stellt grundlegende Rechenressourcen zur Verfügung (Prozessor, Speicher, Ein- und Ausgabegeräte) Betriebssystem regelt und koordiniert den Gebrauch der Hardware unter den verschiedenen Anwendungsprogrammen der einzelnen Nutzer Anwendungsprogramm legt fest, wie die Systemressourcen benutzt werden um die Probleme der Anwender zu lösen (Compiler, Datenbanken, Computerspiele, Wirtschaftsprogramme) Nutzer (Menschen, Maschinen, weitere Rechner) Universität Dortmund Rechnersysteme und Leistungsbewertung -7- Universität Dortmund Rechnersysteme und Leistungsbewertung -8-

3 Zusammenspiel der Systemkomponenten Definition des Betriebssystem Ressourcenverwalter verwaltet und teilt Ressourcen zu Kontrollprogramm kontrolliert die Ausführung der Programme der Benutzern und kontrolliert den Betrieb der Ein- und Ausgabegeräte Kernel einziges Programm dass zu jeder Zeit läuft (alle weiteren Programme sind Anwendungsprogramme) Universität Dortmund Rechnersysteme und Leistungsbewertung -9- Universität Dortmund Rechnersysteme und Leistungsbewertung -10- Einfache Batch Systeme bedarf eines Operators Anwender Operator benötigt zusätzlich Kartenleser setup time wird reduziert, indem gleichartige Jobs zusammen abgearbeitet werden automatisches job sequencing automatische Übergabe der Kontrolle von einem Programm zum nächsten fi erstes rudimentäres Betriebssystem resident monitor besitzt anfangs die Kontrolle über das Rechnersystem Kontrolle wird an auszuführenden Job übergeben wenn Job beendet wird, erlangt Monitor Kontrolle zurück Speicherbelegung in einem Batch System Universität Dortmund Rechnersysteme und Leistungsbewertung -11- Universität Dortmund Rechnersysteme und Leistungsbewertung -12-

4 Kontrollkarten Problem 1. Woher erlangt der monitor Information über die Art des Jobs (z.b. Fortran gegenüber Assembler) oder woher weiss er welches Programm momentan auszuführen ist? 2. Wie unterscheidet der monitor Lösung a) unterschiedliche Jobs voneinander? b) Daten von Programmen? Einführung von Kontrollkarten Kontrollkarten (Forts.) spezielle Karten teilen monitor mit, welche Programme ausgeführt werden sollen: $JOB $FTN $RUN $DATA $END spezielle Zeichen unterscheiden Kontrollkarten von Programm- oder Datenkarten: $ in Spalte 1 // in Spalte 1 oder in Spalte 3 Universität Dortmund Rechnersysteme und Leistungsbewertung -13- Universität Dortmund Rechnersysteme und Leistungsbewertung -14- Kontrollkarten (Forts.) Bestandteile des monitor Interpreter für Kontrollkarten verantwortlich für das Auslesen der Karten und Ausführen der Anweisungen Lader (Loader) lädt System- und Anwendungsprogramme in den Speicher Gerätetreiber (device driver) kennt Charakteristiken und Eigenschaften eines jeden Ein- und Ausgabegerätes des Systems Problem: schlechtes Leistungsverhalten E/A und Berechnungen können nicht gleichzeitig ablaufen Lösung: off-line Betrieb verringert die Berechnungslaufzeiten indem Jobs von Magnetbändern in den Speicher geladen werden und das Auslesen der Karten sowie Ausgabe auf den Drucker off-line geschieht Universität Dortmund Rechnersysteme und Leistungsbewertung -15- Spooling zeitliche Überschneidung von E/A-Operationen eines Jobs mit der Berechnung eines anderen Jobs. Während ein Job ausgeführt wird, führt das Betriebssystem folgende Aufgaben durch: Einlesen des nächsten Jobs von dem Kartenleser in einen Speicherbereich auf der Festplate (job queue) Ausgabe des Ergebnisses des vorherigen Jobs von der Festplatte auf dem Drucker job pool Datenstruktur zur Auswahl des nächstenjobs zur Bearbeitung durch CPU um die Auslastung der CPU zu erhöhen Universität Dortmund Rechnersysteme und Leistungsbewertung -16-

5 Multiprogrammed Batch System mehrere Jobs befinden sich gleichzeitig im Hauptspeicher, und die CPU wird den einzelnen Jobs zu deren Bearbeitung zugeordnet: Voraussetzungen für Multiprogramming E/A-Routinen müssen durch das Betriebssystem bereitgestellt werden Memory Management das Betriebssystem muss den Speicher mehreren Jobs zuordnen CPU-Scheduling das Betriebssystem muss aus den zur Ausführung bereitstehenden Jobs einen zur Bearbeitung auswählen Zuordnung von sonstigen Ressourcen Universität Dortmund Rechnersysteme und Leistungsbewertung -17- Universität Dortmund Rechnersysteme und Leistungsbewertung -18- Time-Sharing Systems Interaktivive Systeme die CPU wird von mehreren Jobs genutzt, die sich entweder im Hauptspeicher oder auf Festplatte befinden (die CPU wird nur einem Job zugewiesen, falls er sich im Hauptspeicher befindet) ein Job wird von der Festplatte in den Speicher ein- bzw. ausgelagert Interaktivität zwischen Nutzer und System: nach Beendigung der Ausführung eines Befehls erwartet das System die nächste Anweisung nicht über einen Kartenleser sondern über die Tastatur des Nutzers es muss dem Nutzer eine Möglichkeit für den gewährt werden auf Daten und Code zu zugreifen Personal-Computer Systeme Personal Computer Rechnersystem genau für einen Benutzer bestimmt E/A-Geräte Tastatur, Maus, Monitor, Drucker hoher Bedienkomfort Übernahme von eigentlich für größere Systeme entwickelte Technologien möglich nicht unbedingt alle Eigenschaften größerer Systeme müssen realisiert werden (z.b. Sicherheitskomponenten) Universität Dortmund Rechnersysteme und Leistungsbewertung -19- Universität Dortmund Rechnersysteme und Leistungsbewertung -20-

6 Entwicklung der Betriebssysteme Parallele Systeme Multiprozessorsysteme mit mehr als einer CPU, die in enger Datenverbindung zueinander stehen Tightly coupled system Prozessoren teilen Speicher und Zeitgeber; Kommunikation untereinander geschieht durch geteilten Speicher Vorteile: erhöhter Durchsatz wirtschaftlich erhöhte Verlässlichkeit - graceful degradation - ausfallsichere Systeme Universität Dortmund Rechnersysteme und Leistungsbewertung -21- Universität Dortmund Rechnersysteme und Leistungsbewertung -22- Parallele Systeme (Forts.) SMP-Architektur Symmetric Multiprocessing (SMP) jeder Prozessor hält eine identische Kope des Betriebssystem vor mehrere Prozesse können gleichzeitig laufen ohne Leistungsrückgang die meisten Betriebssysteme unterstützen SMP Assymmetric Multiprocessing jedem Prozessor wird eine spezielle Aufgabe zugewiesen; master-prozessor übernimmt die Aufteilung und Zuordnung der Aufgaben an die slave-prozessoren gewöhnlich nur in extrem großen Systemen üblich Universität Dortmund Rechnersysteme und Leistungsbewertung -23- Universität Dortmund Rechnersysteme und Leistungsbewertung -24-

7 Real-Time Systeme oftmals eingesetzt als Kontrollgerät in ausgewählten Anwendungen ( Kontolle wissenschaftlicher Experimente, medizinische Bildverarbeitung, industrielle Anwendungen und Anzeigesysteme) wohl-definierte Zeitschranken Hard real-time Systeme Sekundärspeicher limitiert oder nicht vorhanden, Datenablage in Kurzzeitspeicher oder im ROM Konflikt mit time-sharing Systemen, keine Unterstützung durch general-purpose Betriebssysteme Soft real-time Systeme Einsatz bei Industrieanwendungen oder in der Robotik nützlich bei Anwendungen, die erweiterte Betriebssystemfunkionen bedürfen Universität Dortmund Rechnersysteme und Leistungsbewertung -25- Verteilte Systeme Verteilung der Berechnung auf mehrere physikalische Prozessoren Loosely coupled system jeder Prozessor besitzt seinen eigenen Speicher; Prozesse kommunizieren über unterschiedliche Kommunikationswege miteinander (Hochgeschwindigkeitsbusse) Vorteile Ressourcenteilung Erhöhung der Rechengeschwindigkeit Lastbalancierung Verlässlichkeit Kommunikation Universität Dortmund Rechnersysteme und Leistungsbewertung -26- Verteilte Systeme (Forts.) Network Operating System unterstützt file sharing unterstützt Kommunikationsschemata läuft unabhängig von anderen Rechnern im Netzwerk Distributed Operating System weniger Autonomie im Netzwerk scheinbar kontrolliert nur ein Betriebssystem das gesamte Netzwerk Universität Dortmund Rechnersysteme und Leistungsbewertung -27-