BS 1

Die Architektur eines Computersystems ist ein Schichtenmodell: z.B. liegt das Betriebs-system liegt zwischen den Anwendungsprogrammen und der Hardware.

Ein System besteht aus verbundenen Komponenten mit einem erwarteten Verhalten und wechselwirkt über Schnittstellen mit der Umgebung.

Eine Schnittstelle besteht aus einer Menge von Operationen.

Komponenten:

1. Hardware: CPU, Hauptspeicher, Ein/Ausgabe

2. Betriebssystem: zur Trennung der Anwendungen von der Hardware

3. Anwendungsprogramme: für die Interaktionen zwischen Benutzern und Computersystem

Kommunikation:

1. Eine Schicht kann nur mit der direkt untergeordneten Schicht über deren Schnittstelle     kommunizieren.

2. Das Betriebssystem bietet den Anwendungen Systemaufrufe als Schnittstelle an. Die      Anwendungen kommunizieren mit dem Betriebssystem durch Verwendung der Sys-     temaufrufe.

3. Die Hardware bietet dem Betriebssystem die Schnittstelle ISA (Instruction Set     Architecture) an, die aus einer Menge von Maschinenfehlen besteht.

Organisation: Die Komponenten werden in einem Schichtenmodell angeordnet.

Die Grundidee des Computers ist es durch ihn eine universelle Maschine für Berechnungen und Informationsverarbeitung zur Verfügung zu stellen. Dabei können gemäß der Grundidee der „Universalmaschine“ Programme in den Computerspeicher geladen und ausgeführt werden. Durch verwenden der sog. „Von Neumann-Architektur“ müssen die Programme nicht mehr fest verdrahtet bzw. mit der Hardware verbunden sein. Um die Bedienung eines Computers zu erleichtern kann die Computer-Hardware durch spezielle Programme, sog. Betriebssysteme, abstrahiert werden.

1. Prozessor (Central Processor Unit) evtl. mit Cache,

2. Hauptspeicher RAM (random access memory), Sekundärspeicher (Festplatte oder SSD  (solid state drive)) (Hierarchie: Register, Cache, Hauptspeicher, Sekundär- und  Tertiärspeicher)  und

3. Ein-/Ausgabegeräte: z.B. Bildschirm (monitor), Maus (mouse) und Tastatur (keyboard),   zusammen auch Terminal genannt, externe Festplatten, Ethernet-Controller oder WLAN-   Controller, Drucker, Kamera, Mikrofon, …

4. Tertiärspeicher: für Sicherungen bzw. Backups

1. Hardware ist preiswert und schnell, 

2. neue Möglichkeiten durch Vernetzung,

3.   einfach zu bedienende Betriebssysteme (ein BS verwaltet die HW)

 Das Betriebsystem verwaltet die Computer-Hardware. Das Betriebssystem bildet eine Schicht zwischen der Rechner-Hardware, wie z.B. CPU, Speicher und Ein-/Ausgabegeräten und dem Anwender/-programm. Das Betriebssystem trennt also die Anwendungen von der Hardware, ermöglicht es ihnen aber auch, in kontrollierter Weise mit der Hardware (über die Benutzerschnittstelle bzw. die Programmierschnittstelle) zu interagieren. Dieses Konzept der Abstraktion von Hardware bildete eine wesentliche Voraussetzung für die Entstehung z.B. des Personalcomputers, da die Anwenderprogramme nicht mehr unmittelbar an einen festen Hardware-Typ gebunden sind. Des weiteren wird durch diese Abstraktion eine Zugriffsrechte-Verwaltung erst möglich.

Aufgaben: Planung der CPU-Zeit, Verwaltung des Hauptspeichers und die Steuerung der Ein-/Ausgabegeräte.

Eine Programmierschnittstelle für die Kommunikation der Programme mit dem Betriebssystem und eine Benutzerschnittstelle für die Kommunikation der Benutzer mit dem Betriebssystem in Form von Systemprogrammen wie z. B. Shell, Compiler und Editor. Das Programmiermodell bzw. ISA (instruction set architecture) bildet eine weitere (tiefer gelegene) Schnittstelle zwischen Betriebssystem und Hardware.

Anwendungsprogramme (Tools: Shell, Compiler, Utilities: Dienstprogramme), mittlere Schicht: Betriebssystem unten: Hardware

dazwischen liegen Schnittstellen: oben: Programmierschnittstellen und Benutzerschnittstellen, unten: ISA (instruction set architecture)

Die Standardbibliothek vereinheitlicht die Systemaufrufen für die Anwendungen.

Die Anwendungsprogramme, das Betriebssystem und die Hardware bilden zusammen über die Benutzerschnittstelle eine Maschine für die Benutzer.

Die Hardware wie z. B. CPU, Speicher und Ein-/Ausgabegeräte so zu steuern und zu verwalten, daß die Ausführung von Anwendungsprogrammen möglich wird, die Anwenderprogramme also von den Hardware-Details abzuschirmen und auch umgekehrt:

1. die Hardware von direkten Zugriffen der Anwenderprogramme abzuschirmen

2. die Planung und Aufteilung der CPU-Zeit für Prozesse mittels des CPU-Schedulers

3. die Verwaltung und Zuteilung des Hauptspeichers und des virtuellen Speichers

4. die Steuerung der Ein-/Ausgabegeräte und die Organisation von Dateisystemen

Stichworte zu 2. und 3. Virtualisierung und Prozess-Synchronisation

Das auszuführende Programm ist nicht mehr ein fester Bestandteil des Rechners, es wird vielmehr, genau wie die benötigten Daten, vor dem Programmlauf in den Haupt-speicher (Random Access Memory) des Rechners geladen und hinterher wieder entfernt. Der gemeinsame Hauptspeicher enthält also sowohl das Programm als auch die Programm-daten.

Fest in den Rechner einbauen muß man nur noch die Fähigkeit, ein beliebiges im Hauptspeicher befindliches Programm ausführen zu können und hieran braucht man dann idealerweise nie wieder etwas zu verändern. Dieses entspricht der Vorstellung vom Computer als eine universelle Maschine zur Ausführung von Programmen.

Ein Algorithmus ist eine Beschreibung einer Lösung zu einem Problem (Problemspezifikation via Lastenheft). Ein Programm ist eine Abbildung eines Algorithmus auf eine Programmiersprache. Ein Programm im Hauptspeicher ist eine Folge von Befehlen. Ein Prozess ist ein Programm in Ausführung.

Alle eigentlichen Berechnungen eines Computers finden in seinem Prozessor statt, genauer gesagt im Rechenwerk, das manchmal auch als ALU (arithmetic logic unit) bezeichnet wird. Der Prozessor greift auf die Programme und die Daten zu, die sich zur Laufzeit im Hauptspeicher befinden. Der Befehlszähler enthält die Speicheradresse des nächsten auszuführenden Befehls. Das Befehlsregister speichert den momentan auszuführenden Befehl und das Programmstatuswort (PSW) enthält z.B. den Benutzer/Systemmodus (supervisor mode), Interrupt-Masken-Level, und ALU-Ergebnis-Bits.

Instruktionszyklus: Eine Befehlsausführung kann in zwei Phasen aufgeteilt werden:

1. In der Holphase (fetch stage) wird das Speicheradressregister mit dem Wert des Befehlszählers belegt und die Adresse an den Adressbus weitergegeben. Der Inhalt der Speicherzelle mit dieser Adresse wird aus dem Cache/Hauptspeicher in das Befehlsregister geladen. Zum Abschluss wird in dieser Phase der Befehlszähler um Eins erhöht.

2. In der Ausführungsphase (execution stage) wird der in das Befehlsregister geladene Befehl ausgeführt. In dieser Phase können auch weitere Daten oder Adressen von Speicherzellen geholt werden.

3. Unterbrechungsphase: der Prozessor testet, ob eine Unterbrechung vorliegt.

Die Abarbeitung erfolgt getaktet.

Holphase (fetch phase): Programmzähler (Befehlszählerregister) => Speicheradressreg.   => Adressbus, Datenbus => Hauptspeicher  (Bus-Zugriffszeit) => Befehlsregister

Ausführungsphase (execution stage): Befehlsregister => Steuerwerk => Daten => Akkumulator.  Indexregister: (Register L/Register H) für „Indirekte Adressierung“, (zur Laufzeit berechnete Adressen). Ein Sprungbefehl setzt den Befehlszähler.

Der Programmzähler/Befehlszähler (program counter, PC) enthält die Adresse der-jenigen Speicherzelle/wort, in der der als nächstes auszuführende Befehl steht.

Das Speicheradressregister (memory address register MAR) enthält die Adresse derjenigen Speicherzelle, die (als nächstes?) gelesen oder beschrieben werden soll.

Das Befehlsregister (instruction register IR) speichert den aktuellen Befehl, der gerade verarbeitet bzw. ausgeführt wird.

Das Programmstatuswortregister (program status word PSW) enthält verschiedene Bits, die zeigen, ob das gerade ausgeführte Programm privilegierte Befehle benutzen darf oder ob die CPU eine Unterbrechung bearbeiten will: Carry, Overflow, Zero, Negative, Interrupt,Supv. Der Akkumulator ist eines von mehreren Datenregistern und speichert ein Zwischen-ergebnis einer Berechnung. Es folgt als letztes noch die Unterbrechungs(test-)phase.

Der Cache kann wegen der temporalen und räumlichen Lokalität des Programm-Codes und auch der Daten wiederholte Hauptspeicherzugriffe vermeiden, was die Bearbeitungszeit von Befehlen verkürzt, da der Cachezugriff deutlich schneller ist, als der Hauptspeicherzugriff. Cache-Zeitvorteil: Zugriffe 80%Cache zu 20%HS => Faktor 3, falls der Cache neunmal schneller ist.

1. Cache-Management: Wenn Daten im Cache abgelegt werden sollen und dort kein freier Platz mehr vorhanden ist, müssen alte Daten überschrieben werden. Welche Daten soll man dafür opfern?

2. Cache-Konsistenz: Angenommen, der Wert einer Variablen soll verändert werden. Wenn diese Änderung nur an der Kopie im Cache vollzogen wird, so besteht anschließend ein Unterschied zwischen dem Original im Hauptspeicher und der Kopie im Cache. Das Betriebssystem muß dafür sorgen, daß sich hieraus keine Fehler ergeben.

Häufig benutzte Daten werden vorübergehend vom Hauptspeicher in den Cache kopiert. Wenn Daten benötigt werden, schaut man zunächst im Cache nach. Findet man dort eine Kopie der gesuchten Daten, so verwendet man sie und braucht keinen Hauptspeicherzugriff auszuführen. Wird man aber im Cache nicht fündig, ist ein Zugriff auf den Hauptspeicher unvermeidlich; in diesem Fall legt man eine Kopie der Daten im Cache ab, weil man davon ausgeht, daß diese Daten bald noch einmal benötigt werden.

Dieser ist als eine lange Folge von gleich breiten flüchtigen Speicherzellen organisiert, die einzeln adressiert werden können. Das Speicheradressregister der CPU enthält die Adresse, also die Binärdarstellung des Index, von derjenigen Speicherzelle, in der das adressierte Wort steht. Der Hauptspeicher hat die Eigenschaft des wahlfreien Zugriffs. Der englische Begriff („random access“) meint, daß die Zugriffsreihenfolge nicht im voraus bekannt ist und jede Speicherzelle mit ihrer Adresse direkt angesprochen werden kann.

Was ist ein Sekundärspeicher?

Die Aufgabe für die dauerhafte Speicherung (Festspeicher) übernimmt ein Sekundär-speicher (secondary memory). Die gebräuchlichsten Typen von Sekundärspeicher sind zur Zeit die Magnetplatte (Festplatte) und der Flash-Speicher (SSD solid state drive).

Ein Flash-Chip (Electronically Erasable PROM) besteht aus einer Anzahl von sogenannten Erase Blocks. Jeder Block hat die Größe 128 KByte oder 256 KByte. Bei NOR besteht ein Block aus Daten-Bits, die einzeln gelesen und geschrieben werden können, d. h. jedes Daten-Bit kann einzeln von 1 auf 0 gesetzt werden. Bei NAND besteht ein Block aus einer Anzahl von sogenannten Seiten. Eine Seite enthält nicht nur Daten-Bits, sondern auch einen Out-Of-Band-Bereich (OOB) für die Fehlerbehandlung und die Kennzeichnung einer Beschädigung der Seite. Die Daten in einem Block können hier nur seitenweise gelesen und geschrieben werden. Die Löschen-Operation muß bei beiden Flash-Arten auf einem kompletten Block ausgeführt werden. Nach ungefähr 100000 Block-Lösch-Zyklen ist ein Block abgenutzt (wear out).

HDD zur Dauersicherung und als „externes“ Medium, wahlfreier Zugriff („random access“, weil Zugriffe im allgemeinen nicht vorhersehbar sind). Schreib/Lesekopf, Spuren, Sektoren, Blöcke, Zylinder, Positionierungszeit, Latenzzeit (bis Sektor gelesen), Übertragungszeit (bis Pufferspeicher im Controller). Zugriffszeit = Positionierungszeit + Latenzzeit + Übertragungszeit. Parity-Bits für Fehlererkennung/Behebung. Platten-Cache.

1. zusammengehörige Daten lokal zusammenfassen

2. bei gleichzeitigen konkurrierenden Aufträgen die Bearbeitungsreihenfolge via „Disk-      Scheduling“-Strategien ausführen

- FCFS (first-come, first-served) bearbeitet die Aufträge in der Reihenfolge ihres Eingangs. - SSTF (shortest-seek-time-first (greedy-Algorithmus)) bearbeitet jeweils denjenigen Auf-   trag als nächstes, dessen Spur der momentanen Position des Schreib-/Lesekopfs am   nächsten liegt. Um Auftrags-„Starvation“ zu vermeiden sollten die Aufträge zusätzlich prio-   risiert werden. Wartezeitabhängige Prioritätsanpassung wird auch als „aging“ bezeichnet.

- SCAN bewegt den Kopf abwechselnd von außen nach innen und von innen nach außen   über die gesamte Platte und führt dabei die Aufträge aus, deren Spuren gerade überquert   werden.

Jede „prozessorkernnähere“ schnellere Schicht arbeitet wie ein „Cache“ für die nächsttiefere „pheriphere“ billigere Schicht (billiger pro Bit); z.B. erhält der Sekundärspeicher eine (möglicherweise aktuellere) Kopie von Teilen der Information des Tertiärspeichers. Folgende Schichten gibt es:

1. Prozessor(CPU)-Register: (schnell aber sehr teuer)

2. Cache: (temporale und räumliche Lokalität des Programm-Codes und auch der Daten   (Havard-Architektur aufgrund von Pipelining))

  Cache-Management: Auslagerungsalgorithmus, Cache-Konsistenz: Unterschied    zwischen dem Original im Hauptspeicher und der Kopie im Cache ist unvermeidbar.    Cache-Zeitvorteil: Zugriffe 80%Cache/20%HS => Faktor 3, falls d.Cache 9mal schneller ist.

3. Hauptspeicher: (flüchtig und evtl. auch knapp)

4. Sekundärspeicher: HDD(Festplatte, secondary memory) oder SSD (solid state disk)

5. Tertiärspeicher: (Magnetband (nur sequentieller Zugriff), CD-ROM, DVD, Diskette, USB,     externe Festplatte zur Dauersich./Backups, billiger, lagerbar („juke box“), transportierbar)

CPU, Hauptspeicher und mehrere Geräte-Controller (Device-Controller) sind über einen Bus (Datenbus, Adressbus mit Protokoll welches „Bus-Nachrichten“ definiert) verbunden. Die Geräte-Controller steuern jeweils die eigentliche Geräte-Hardware an. Die Controller und die CPU arbeiten parallel, aber zu einem gegebenen Zeitpunkt kann immer nur einer den Bus (als Bus-Master) benutzen. Ein Device-Controller hat typischerweise vier Register-Typen: Kontrollregister, Statusregister, Dateneingangsregister/puffer und Daten-ausgangsregister/puffer. Betriebssystemseitig wird ein Device-Controller, bzw. seine Register, durch einen jeweils zugeschnittenen Gerätetreiber (device driver) von der CPU über den Bus angesprochen. Dieses erfolgt je nach CPU-Architekturmodell (Instruction-SetArchitecture) entweder über spezielle CPU-Port-Befehle oder einfach speicherabgebildet „memory-mapped“. Dieses „verschwendet“ Adressraum, macht aber die Verwendung höherer Programmiersprachen erst möglich.

Dabei werden die Register des Geräte-Controllers als Teil des Hauptspeichers adressiert. Der auf der CPU laufende Gerätetreiber kann dann einfach durch direkte Adressierung den Bus für den Datenaustausch mit den Controller-Registern verwenden.

Durch die Konzepte Abstraktion, Kapselung und Schichtenmodellierung kann ein physikalisches Gerät und seine Wirkung in eine vereinfachte Form gebracht werden, so daß es relativ einfach durch ein Programm angesprochen werden kann. Daher spricht man hierbei auch vom Modell eines „virtuellen Gerätes“. Hierbei besteht ein virtuelles Gerät aus den drei Schichten Geräte-Mechanik, Controller-Elektronik und Betriebssystem-Gerätetreiber. Die eigentliche am Bus angeschlossene Geräte-Hardware besteht nur aus den beiden erstgenannten unteren Schichten (Mechanik und Controller).

Die Implementierung einer einzelnen Schicht ist verhältnismäßig einfach, weil nur die beiden Schnittstellen zur nächst höheren und zur nächst tieferen Schicht realisiert bzw. bedient werden müssen und weil im Innern der Schicht nur eine klar umrissene Teilaufgabe gelöst werden muß (Kapselung bzw. Geheimnisprinzip und Abstraktion durch eine Schicht). Änderungen sind leichter durchführbar, da Verantwortlichkeiten klar abgegrenzt sind und die falsche bzw. missbräuchliche Anwendung der tiefer gelegenen Schichten wird eingeschränkt.

Geräte-Mechanik: realisiert die „Physik“ des Gerätes

Controller: Übernimmt die Steuerung des nackten Geräts bzw. der elektromechanischen Hardware.

Treiber: Das Betriebssystem hat die Aufgabe, die Geräte zu steuern; dazu kommuniziert es mit den Controllern. Weil sich die Controller sehr voneinander unterscheiden, ist für jeden Controller ein eigener Teil des BS zuständig: ein Gerätetreiber. Die Anwendungsprogramme und andere Teile des BS können nur über den Gerätetreiber auf das Gerät zugreifen.

Die Entlastung der CPU und die Vereinfachung des Gerätezugriffs durch Abstraktion, Kapselung und Schichtenmodellierung. Jede Schicht hat dabei eine klar umrissene Teilaufgabe, wodurch auch der Entwurf eines Treibers oder z.B. auch eines Kommunikations-Stacks vereinfacht wird. Die Kapselung bietet dabei Zugriffsschutz und modulare Geräte(typ)-Austauschbarkeit.

Ein-/Ausgabe-Software hat ein Schichtenmodell mit drei Schichten:

1. Geräteunabhängige SW-Anteile: Puffer im Hauptspeicher reservieren, Gerätenamen auf Nummern abbilden, Fehler behandeln, exklusive Benutzung von Geräten synchronisieren.

2. Geräteabhängiger Gerätetreiber,  3. Unterbrechungsroutinen

Generell ist die Implementierung von Funktionen in Hardware effizienter als eine Softwarelösung, und sie dient der Abstraktion, weil die Details in der Hardware verborgen werden. Eine Implementierung in Software macht dagegen oft weniger Arbeit und läßt sich leichter ändern.

Der Treiber hinterlegt über den Bus einen entsprechenden Kommando-Befehl im Kontrollregister des Controllers. Nachdem der Controller den Auftrag auf der Hardware durchgeführt hat (es können dann z.B. frisch gelesene Daten im Datenausgangs-register/puffer des Controllers liegen), muß dieses Fertigstellungs-Ereignis gegenüber dem Treiber noch „signalisiert“ werden. Dieses kann z.B. durch periodisches Abfragen (sog. „Polling“ „Abfragebetrieb“ bei Prozessen sog. „busy waiting“) des Controller-Statusregisters durch die CPU erfolgen. Dieser Abfragebetrieb ist aber besonders bei Multi-Tasking-Systemen wegen dem Prozesskontext-Wechsel-Aufwand sehr ineffizient. Mit entsprechender Hardware-Unterstützung kann der Geräte-Controller nach Fertigstellung auch eine Unterbrechung an die CPU während ihrer augenblicklichen Arbeit anfordern, damit diese dann zeitnah auf das Fertigstellungs-Ereignis reagieren und dieses be-handeln kann.

Dieses ist eine meist nichtdeterministische Unterbrechungsanforderung (Ausnahme hierbei: absichtlich ausgelöste „software traps“, sog. „system calls“, für beabsichtigte Betriebs-systemaufrufe zur Kontrollübergabe an das BS). Unvorhergesehen ausgelöste Software-Unterbrechungen („software interrupts“) wie z.B. die „Division durch Null“ oder ein „Page Fault“ werden als „exceptions“ oder als „Ausnahme“ bezeichnet. Des weiteren gibt es noch die klassischen „hardware interrupts“, welche nicht vom aktuell ausgeführten Programm, sondern von externen Ereignissen außerhalb der CPU ausgelöst werden. Die entsprechenden elektrischen Anforderungssignale dieser externen Ereignisse werden mit Hilfe einer zwischengeschalteten Hardware-Einheit, genannt „Interrupt-Controller“ priorisiert und bei bedarf an den Unterbrechungseingang der CPU weitergeleitet. Im speziellen können Interrupts auch zur Realisierung vom präemptiven (im Sinne von präventiv) Multitasking, also zum Erzwingen von Prozesskontext-Wechseln (um Kontrolle des BS zu erhalten) verwendet werden (Auch in einem Präemptiven-Multitasking-System sollten sich die Prozesse z.B. durch freiwilliges periodisches Wechseln von „rechnend“ nach „bereit“ kooperativ verhalten). Speziell bei Single-Core-Prozessoren können sogenannte „atomare Abschnitte“ durch idealerweise sehr kurz dauerndes Interrupt-Sperren (Maskierung) realisiert werden. Bevorzugt werden sollten jedoch spezielle atomare CPU-Instruktionen.

Der Interrupt-Controller ist dazu sowohl mit den verschiedenen Geräte-Controllern verbunden als auch über mehrere Leitungen mit der CPU: Eine Leitung ist mit dem Unterbrechungseingang der CPU verbunden, eine Leitung dient zur Unterbrechungs-bestätigung durch die CPU und ein paar Leitungen dienen der Übertragung der sogenannten Unterbrechungsnummer, die den betreffenden Geräte-Controller bzw. das Ereignis, welches den Unterbrechungswunsch signalisiert hat, eindeutig identifiziert.

Über CPU-Eingänge bzw. über Register mit der Unterbrechungsnummer, alternativ: einmaliges Abfragen der externen Controller-Statusregister in der InterruptServiceRoutine.

Für die Behandlung von externen Ereignissen via Controller-Anfragen (Hardware-Interrupts), bei CPU-internen SW-Fehlern (Software-Exceptions) und für die Realisierung des Konzepts der „Programmierschnittstelle“ via „system call“-SW-Trap-Interrupts („für wiederholte Reaktivierung der Kontrolle des BS“) in Form von Anwender-Funktions-aufrufen. Auch für die Ermöglichung des „präemptives Scheduling“ via Hardware-Timer-Interrupts. Neben Speicherschutzmechanismen, Privilegierten Befehlen und Zeitgebern sind die Interrupts eine wichtige Hardware-Anforderung damit das Betriebssystem die Kontrolle über das Gesamtsystem behalten kann. Der Unterbrechungsbetrieb bildet somit eine wichtige Grundlage für die Arbeitsweise moderner Computersysteme.

Über beabsichtigt im Programmablauf aufgerufene bzw. ausgelöste „software traps“ läßt sich eine Kontrollübergabe an das Betriebssystem realisieren. Die aufgerufene Betriebssystem-Interrupt-Routine läuft dann temporär im System-Modus ab. Die Gesamtheit aller Systemaufrufe realisiert die Programmierschnittstelle des Betriebsystems (und ermöglicht (damit) auch die Funktionalität der Systemprogramme (z.B. die des Kommandointerpreters (shell)) welche die Benutzerschnittstelle des Systems bilden).

Es wird die passenden (identifiziert durch einen Aufruf-ID-Parameter) Unterbrechungsroutine im Systemmodus, d.h. im Kernel des Betriebssystems aufgerufen (system call). Aktiviert wird hierbei die wiederholte Rückgewinnung der Kontrolle des Betriebssystems. Interrupts sind (neben Speicherschutzmechanismen, Privilegierten Befehlen und Zeitgebern) ein wichtiger Mechanismus für das Betriebssystem um die Kontrolle über das Gesamtsystem beizubehalten.

Wann immer ein Programm Dienste des Betriebssystems in Anspruch nehmen will, führt es einen Systemaufruf (system call) durch. Die verfügbaren Systemaufrufe bilden zusammen die Programmierschnittstelle zwischen den Anwenderprogrammen und dem Betriebssystem. Solch ein Systemaufruf hat die Form eines Funktionsaufrufs. Insbesondere können dabei auch Parameter übergeben werden, entweder auf dem Prozess-Stapel, direkt in Registern der CPU oder indirekt in Registern durch Angabe der Anfangsadresse des zu übergebenden Datenbereichs im Hauptspeicher. Wenn der Systemaufruf seine Parameter für die Übergabe vorbereitet hat, führt er eine besondere Instruktion, „trap“, aus, die die eigentliche Unterbrechung und damit den Wechsel in den Systemmodus auslöst. Diese Instruktion ist bei allen Systemaufrufen dieselbe; der durch einen der Parameter bezeichnete gewünschte spezielle Systemdienst wird dann von der allgemeinen trap-spezifischen Unterbrechungsroutine aus aufgerufen. Nach der Unterbrechung läuft der ursprüngliche Prozess wieder in seinem ursprünglichen Modus (im Benutzermodus oder im Systemmodus). Die Gesamtheit aller Systemaufrufe realisiert die Programmierschnittstelle des Betriebsystems.

Mit dieser Kopie kann später der Kontext bzw. Zustand vor der Unterbrechung wieder hergestellt werden (Programmzähler und Status wie z.B. der ursprüngliche Modus).

Die CPU könnte nachdem sie einen Auftrag an einen Controller gegeben hat, immer wieder das Statusregister des Controllers abfragen, um festzustellen, ob der Auftrag schon erledigt ist. Diesen Abfragebetrieb bezeichnet man als „Polling“. Bei Multitasking-Systemen wäre man außerdem auf ein kooperatives Verhalten aller beteiligten Prozesse angewiesen.

Eine solche periodische Abfrage eines Controller-Statusregisters läßt sich zwar recht schnell erledigen, aber wenn sie immer wieder erfolglos bleibt, wird insgesamt viel CPU-Zeit damit verbraucht. Während des Pollings kann entweder kein anderer Prozess rechnen oder man löst im Negativfall immer wieder freiwillig einen Kontextwechel aus (sich schlafen legen), was aber auch Rechenleistung kostet und zu einer unregelmäßigen Polling-Rate führt.

Schutz von Speicher und Geräten. Bestimmte privilegierte Maschinenbefehle können nur im Systemmodus ausgeführt werden.

Der Interrupt-Controller signalisiert der CPU über ihren Unterbrechungseingang eine Unterbrechungsanforderung und über weitere Leitungen die (höchstpriore) Quelle des anliegenden Ereignisses (Unterbrechungsnummer). Bei SW-Traps fungiert ein Parameter als Unterbrechungsnummer. Nach Abarbeitung des aktuellen Befehls wird dann ein minimaler Prozessorkontext bestehend aus Programmzähler und Statusregister (mit Modus-Bit) und ggf. einigen Daten-Registern auf den Stapel gerettet und über eine Sprungvektortabelle eine dedizierte (gemäß Unterbrechungsnummer) Interrupt-Routine (Interrupt Service Routine, ISR) aufgerufen (Die Vektor-Adresse wird dabei in das Befehlszählregister der CPU geladen und damit in diese ISR gesprungen). Dieses kann durch Hardware oder über den Umweg über eine allgemeine Unterbrechungsroutine geschehen. Die im Systemmodus (d.h. im Kernel des Betriebssystems) arbeitende quellspezifische Interrupt-Routine kann nun mit Hilfe des anfragenden Geräte-Controllers evtl. noch weitere benötigte Register vorher retten und die Anfrage nun abarbeiten. Am Ende der Behandlung wird über einen Return-from-Interrupt-Befehl der Prozess-Kontext wieder vom Stapel geholt und die Abarbeitung des unterbrochenen Programms im ursprünglichen (Benutzer- oder System-)Modus fortgesetzt.

Der Interrupt kann entweder während der Abarbeitung gesperrt werden (interrupt disabled) (dies kann auch zur Realisierung kritischer Abschnitte bei Single-Core-CPUs genutzt werden) oder die Anfragen können untereinander ggf. hardwareunterstützt (festverdrahtet oder konfigurierbar) priorisiert werden (Im Falle einer allgemeinen Unterbrechungsroutine müsste diese ggf. reentrant sein). Unterbrechungen niederer Priorität können dann von solchen mit höherer Priorität unterbrochen werden.

Hardware-Unterbrechung: nicht reproduzierbar, nicht deterministisch, vom externen Gerät ausgelöst. Software-Unterbrechung: wird von dem gerade ausgeführten Programm verursacht, (in gewisser weise) reproduzierbar.

Bei der unterbrechungsgesteuerten Ein-/Ausgabe enthält der Datenpuffer des Controllers im Extremfall jeweils nur ein Daten-Wort und löst für dessen Abholung eigens eine Unter-brechung aus. Das Umkopieren der Daten aus dem Controller-Puffer in den Hauptspeicher erfolgt dann in der InterruptServiceRoutine „programmatisch“ durch die CPU, wodurch insgesamt viel CPU-Rechenzeit verbraucht wird. Beim DMA-Datentransfer „Direkter Speicher-zugriff“ (direct memory access = DMA) übernimmt ein eigens auf Datentransfer optimierter Contro-ller das ereignisbasierte Kopieren von Daten aus z.B. einem Fest-platten-Controller in den Haupt-speicher oder umgekehrt. Der DMA-Controller kopiert also selbständig über den Bus Daten in den Hauptspeicher. Somit wird die CPU nicht mit dem eigentlichen Datentransport und auch nicht mit den für den Transport ggf. häufiger benötigten Interrupt-Behandlungen belastet. Jedoch sind CPU-Zugriffe auf den Bus während einer DMA-(Teilblock-)Übertragung nicht möglich. Außerdem muß z.B. der Festplatten-Controller mit dem DMA-Controller kompatibel sein, da beide über zpezielle Handshake-Leitungen miteinander verbunden sind. Zu Beginn eines z.B. Lese-Auftrages von der Festplatte teilt der Gerätetreiber dem Geräte-Controller über dessen Register die Nummer des zu lesenden Blocks mit und dem DMA-Controller die Anfangsadresse des Hauptspeicherbereichs, in den die Daten übertragen werden sollen. Danach kann sich die CPU anderen Aufgaben widmen. Liegen nun Daten im Platten-Controller vor, so wird dieses dem DMA-Controller signalisiert und dieser beginnt sofort mit dem Transfer der Daten in den Hauptspeicher, wobei die Hauptspeicheradressen jeweils entsprechend erhöht werden. Der Transfer kann in mehreren/vielen Blöcken erfolgen. Erst nach Beendigung des letzten Transfers, löst der DMA-Controller eine Unterbrechung für die CPU aus.

Zur Entlastung der CPU.

Weil der DMA-Controller den Bus nutzt und die CPU in dieser Zeit bei einem Speicherzugriff warten muß.

1. Der Treiber übergibt dem DMA-Controller die Startadresse des Speicherbereichs, die Anzahl der zu schreibenden oder zu lesenden Worte, die Portnummer des Gerätes, die Operation read oder write.

2. Die CPU gibt dem Festplatten-Controller z. B. einen Lese-Befehl, um einen Block zu lesen. Der Controller der Festplatte liest die Daten in den Puffer.

3. Der Festplatten-Controller sendet ein Bestätigungssignal an den DMA-Controller.

4. Der DMA-Controller veranlasst nun den Festplatten-Controller, das nächste Wort aus dem Puffer über den PCI-Bus zum DMA zu senden.

5. Der DMA-Controller schreibt das nächste Wort in den Hauptspeicher mit der Zieldresse. Dann inkrementiert er die Zieladresse um Eins und dekrementiert die Anzahl der Worte um Eins. Die Schritte 4 bis 5 werden solange wiederholt, bis die Anzahl der Worte 0 wird.

6. Wenn die Anzahl der Worte 0 ist, erzeugt der DMA-Controller eine Unterbrechung und teilt der CPU so mit, daß die Daten jetzt im Hauptspeicher vorliegen.

1. Ein Register für die Adresse im Hauptspeicher, die zeigt, von wo die Daten gelesen oder wohin die Daten geschrieben werden.

2. Ein Register für die Gerätnummer, die identifiziert, welches Gerät die Leseoperation oder Schreiboperation ausführt.

3. Ein Register für den Zähler, der speichert, wie viele Worte noch gelesen oder geschrieben werden müssen.

4. Ein Register für die Operation, die zeigt, ob eine Leseoperation oder eine Schreiboperation ausgeführt wird.

5. Ein Kontroll-Register zum Starten des konfigurierten DMA-Transfers.

1. Programmgesteuerte Eingabe/Ausgabe durch Polling. Die CPU führt „busy waiting“ aus. 2. Unterbrechungsgesteuerte E/A: effizienter, aber immer noch SW-lastig

3. DMA: DMA-Controller-HW übernimmt das Kopieren großer Blöcke. Die CPU kann wäh-     renddessen nicht auf den Bus zugreifen.

Wenn eine Unterbrechung auftritt, insbesondere wenn ein Benutzerprogramm einen System-aufruf auslöst, schaltet die Hardware vor dem Aufruf einer privilegierten BS-Prozedur zur Unterbrechungsbehandlung den Prozessor in den Systemmodus. Diese ruft dann die entsprechende Unterbrechungsroutine auf. Sie ist Teil des Betriebssystems und deshalb vertrauenswürdig. Bevor die Unterbrechungsroutine terminiert, schaltet sie in den ursprünglichen Prozessmodus zurück. Es ist also nicht der aufrufende Prozess der die Privilegien bekommt, sondern die aufgerufene Betriebssystem-Routine.

Ein Prozess soll nicht auf beliebige physikalische Adressen außerhalb seines Hauptspeicher-Bereiches (seines Adress-raums) zugreifen dürfen. Zugriffe auf Bus-Adressen außer-halb eines zusammenhängenden physikalischen Adress-raums lassen sich mit einer speziellen Hardware, die zwischen CPU-Kern (Speicheradressregister) und Adress-bus liegt, verhindern. Im Basisregister (base register) steht die niedrigste physikalische Adresse des „erlaubten“ Speicherbereichs, also sozusagen die physikalische Startadresse des Programms. Das Grenzregister (limit register) enthält die Länge des zusammenhängenden Programm-Adressbereichs. Die Inhalte von Basis- und Grenzregister können nur mit speziellen privilegierten Maschinenbefehlen verändert werden. Über das Grenzregister kann eine Überschreitung des erlaubten Adressbereichs erkannt und ggf. über ausgelöste Interrupts behandelt werden. Mit dem Basisregister erfolgt eine Umsetzung von segmentbezogenen „relativen Adressen“ auf physikalische absolute Bus-Adressen. Das Programm selbst ist also nicht direkt bezüglich seiner momentanen physikalische absoluten Adresse compiliert bzw. assembliert bzw. gebunden worden (welche zur Compile-Zeit auch noch nicht bekannt war), sondern relativ zur Adresse Null (Das Programm könnte also ohne die Schutzhardware im Adressbereich von Adresse Null direkt laufen, falls dort nicht schon z.B. die Interrupt-Tabelle liegen würde). Durch den „relativen“ Bezug zur Adresse Null werden derart compilierte bzw. gebundene Programme in Kombination mit dem Basisregister (dynamisch) „relokierbar“; d.h. den ausführbaren Programmcode kann der Loader in einen beliebigen Hauptspeicher-bereich platzieren, welcher gerade frei ist. Mithilfe der hardwaremäßigen Adressumsetzung „absolute physikalische“ BusAdresse = SegmentStartadresse (Basisregister) + relative Adresse (Speicheradressregister) liegt immer die passende absolute Adresse auf dem Adressbus. Für diese Flexibilität (Relokierbarkeit) muß man ggf. mit Performance (theoretisch bis Faktor 2) bezahlen, d.h. z.B. eine Schutz-Hardware (MMU) muß vorhanden sein, welche die Übersetzung der relativen Adresse in die absolute umsetzt.

Eine Adresse relativ zum Basisregister-Inhalt bzw. zur Startadresse eines Adressraums. Die relative Adresse wird durch den „Binder“ zur „Compile/Link-Zeit“ vergeben. Mit der  Verwendung relativer Adressen und deren Abbildung zur Laufzeit erreicht man die „Relokierbarkeit“ des Programms (Die oberen Adressbits einer relativen Adresse geben meist die Segmentnummer bzw. die Nummer der Speicherschutz-Einheit an: z.B: RAM-Daten-, Stack-, Programm- und konst.-Daten-Segment). „Relative Adressen“ bedeuten also in diesem Kontext nicht die sogenannte „Relativen Adressierung“ innerhalb des Assembler-Befehlssatzes (ISA).

Die physische Adresse auf dem Adressbus: absolute Adresse (physikalische Busadresse) = Startadr.(Basisregister) + relative Adresse. Die Speicherschutz- bzw. Segmentierungs-Hardware führt diese Umrechnung zur Laufzeit automatisch durch und erspart so eine explizite Umrechnung des Programms vor dessen Ausführung (Sowohl die in diesem Kontext genannte „relative Adressierung“ als auch die „absolute Adressierung“ betreffen aus Assembler-Befehlssatz- bzw. Instr.SetArchitekture-Sicht beide eher die „Assembler-Absolute Adressierung“.).

1. Privilegierte Befehle (System/User-Benutzer-Modi) zur Ausführung im Systemmodus

2. Speicherschutz (z.B. via Basis- und Grenzregister), Seitenrahmen/Paging 3. Unterbrechungen (Interrupts) zur „Aktivierung“ des Betriebsystems

4. Zeitgeber (HW-Timer) z.B. zur Aufteilung der CPU-Zeit bei preemptivem Scheduling

Die Mechanismen 1. bis 4. sind notwendig dafür, daß das Betriebssystem die Kontrolle über das ganze System behalten kann. Bus für Geräte-Controller-Anbindung und ggf. DMA, s. hardwarenahe Treiber

Die Programme können zusammen mit ihren Adressbereichen beliebig im Hauptspeicher verschoben werden => relokierbare Programme (relocatable code) => dynam. Allokierung.

Der Ur-Lader wird beim Einschalten des Rechners automatisch ausgeführt und lädt zunächst den eigentlichen Lader von der Festplatte. Der Lader wird nun gestartet und lädt das Betriebssystem, zumindest seine wesentlichen Teile, in den Hauptspeicher. Dieser Vorgang wird als hochfahren (booting) bezeichnet.

Ein Algorithmus ist eine Beschreibung einer Lösung zu einem Problem (Problem-spezifikation erfolgt via Lastenheft). Ein Programm ist eine Abbildung eines Algorithmus auf eine Programmiersprache. Ein Programm im Hauptspeicher ist eine Folge von Befehlen (welche zu Laufzeit auf Daten arbeiten). Ein Prozess ist ein Programm in Ausführung.

Prozesse sind die elementaren Arbeitseinheiten eines moderne Betreibsystems. Ein Programm, das sich gerade in Ausführung befindet, heißt Prozess. Zum Prozess gehört aber nicht nur ein Programm sondern auch der Prozesskontext, Programm- und Datensegment und der Prozess-Stack. Der Prozesskontext ist im Prozess-Kontrollblock (process control block PCB) abgelegt. Er dient auch zur regulären Zustands-Sicherung falls der Prozess gerade nicht rechnet. Er besteht aus:

1. Registerinhalte, insbesondere Befehlszähler und Staus-Register mit S/U-Modus     (im Systemmodus- oder im Benutzermodus), Prozess-Stackpointer

2. Grenzen des Adressraums (Basis-/Grenzregister bzw. Segment- oder Seitentabelle)    Beim „forken“ eines schwergewichtigen Prozesses wird der Speicherbereich nicht vererbt.

3. Prozessnummer

4. Prozess-Scheduling-Priorität

5. Prozesszustand

6. belegte Ressourcen (z.B. geöffnete Dateien)

Die Prozesstabelle (mit Verweisen auf die Prozess-PCBs) wird vom Betreibsystem verwaltet. Welcher der bereiten Prozesse als nächster rechnen darf, entscheidet der CPU-Scheduler anhand seiner Scheduling-Strategie.

Bei den Einprozessorsystemen, wie sie in diesem Kurs betrachtet werden, ist zu jedem Zeitpunkt genau ein Prozess im Zustand rechnend; nämlich der Prozess, dessen Programm gerade von der CPU ausgeführt wird. Jeder andere existierende Prozess ist entweder bereit und bewirbt sich mit den übrigen bereiten Prozessen um die Zuteilung der CPU, oder er ist blockiert und wartet darauf, daß z.B. seine Ein-Ausgabeanforderung erledigt wird oder ein bestimmtes Ereignis eintritt bzw. signalisiert wird. Der Begriff „Unterbrechung“ im Bild steht für die freiwillige kooperative CPU-Abgabe (via SW-Trap) oder die erzwungene präemptive CPU-Abgabe (via HW-Int.) oder für einen Geräte-Interrupt welcher einen anderen blockierten Prozess ggf. aufweckt. Blockierte Prozesse gehen immer über „bereit“ und nicht direkt nach „rechnend“, weil sonst die Kontrolle des Schedulers eingeschränkt werden könnte. Der Übergang von „blockiert“ nach „bereit“ erfolgt über die „Signalisierung“ eines Ereignisses. Das Signal wird z.B. von einem anderen Prozess erzeugt.

Häufige Ein/Ausgaben im Prozess bzw. in vielen Prozessen könnten dann zum effektiven Kontrollverlust des Schedulers und somit zum Aufweichen der verwendeten Scheduling-Strategie führen.

Nein, da er sich dann ein unendliches Zeitquantum oder Systemrechte geben könnte.

1. CPU wird zugeteilt / entzogen (präemptiv via Unterbrechung)

2. Unterbrechung tritt ein (freiwillig oder präemptiv, Geräte-Interrupt)

3. Ein-/Ausgabeanforderung: Warten auf Ereignis bzw. auf ein Signal

4. Ein-/Ausgabeanforderung: E/A-Ereignis oder Signalisierung eingetreten

5. Prozess zugelassen/beendet

1. Sichern: Die Unterbrechungsroutine veranlasst den Dispatcher alle Registerinhalte des unterbrochenen Prozesses auf den systemeigenen Stapel oder im PCB des Prozesses zu speichern.

2. Einfügen: des PCB in die entsprechende Warteschlange (bereit, blockiert).

3. Behandeln der Unterbrechung: Die Unterbrechungsroutine ruft ggf. den Ein/Ausgabeteil      des Betriebssystems auf.

4. Auswählen: Der Scheduler wählt aus den „bereiten“ Prozessen den nächsten    „rechnenden“ aus und teilt ein Zeitquantum zu.

5. Wiederherstellen: Der Dispatcher stellt alle Registerinhalte des ausgewählten Prozesses wieder her und setzt den Timer auf das Zeitquantum für den späteren Interrupt (bei präemptivem Scheduling). Mit dem Befehl Return From Interrupt (RTI) erfolgt der Rücksprung in den neuen Kontext (und Wiederherstellung User/System-Modus).

Scheduler: Der Scheduler setzt die Strategie für die Rechenzeitvergabe um. Er wählt aus den bereiten Prozessen denjenigen aus, der als nächster den Prozessor erhält und teilt ein Zeitquantum zu.

Dispatcher: Der Dispatcher führt den eigentlichen Kontextwechsel durch. Er sichert Prozesse bzw. deren Kontexte, stellt sie wieder her und setzt bei präemptiven Sytemen den Timer, welcher nach einer gewissen Zeit einen Interrupt zwecks Prozesswechsel auslöst.

präemptiv: Das System entzieht per HW-Timer-Interrupt einem Prozess die CPU (falls der Prozess sich nicht kooperativ verhält und vorher die CPU freiwillig abgibt. Auch in einem präemptiven Multitasking-System sollten sich die Prozesse z.B. durch freiwilliges periodisches Wechseln von „rechnend“ nach „bereit“ kooperativ verhalten. Ansonsten sind häufige präemptive CPU-Entzüge eher ein Indiz für eine System-Überlastung).

nicht präemptiv: Das System hat keine Möglichkeiten zum CPU-Entzug. Die Prozesse müssen sich in einem solchen System freiwillig kooperativ verhalten.

1. Bei einem nicht präemptiven System blockiert ein Prozess die CPU solange, bis er sie     freiwillig abgibt. Die Prozesse müssen sich hier also ausnahmslos kooperativ verhalten.

2. Bei einem präemptiven System wird einem Prozess die CPU (notfalls) via Zeitscheiben-Interrupt entzogen. Die meisten modernen Systeme sind präemptive Systeme.

3. Ein E/A-Gerätezugriffs-Interrupt, welcher ein Ereignis signalisieren kann, tritt auf.

Der Eindruck von Parallelität bzw. Gleichzeitigkeit (im sog. Time-Sharing-Betrieb) entsteht dadurch, daß der Scheduler im schnellen Wechsel jedem bereiten Prozess ein gewisses Quantum an Rechenzeit zukommen läßt.

für nicht präemptive (kooperative) Systeme (1.-3.):

1. FCFS: FirstComeFirstServed: fair aber ungeeignet für interaktive Prozesse

2. SJF: Shortest Job First: Minimiert die Gesamtwartezeit, gut für Batch-Betrieb,jedoch unfair

3. Prioritäts-Scheduiling: geeignet für interaktive Prozesse, aber unfair (starvation)

4. Round Robin (ist eine verbreitete Strategie für präemptive Systeme)

Round Robin und Priorität-Scheduling lassen sich kombinieren: interaktive Prozesse erhalten dynamisch höhere Priorität aber kleinere Zeitscheiben und rechenlastige Prozesse erhalten niedrige Priorität aber größere Zeitscheiben.

Hier werden die Prozesse im Zustand „bereit“ in der Reihenfolge des aufsteigenden Rechenzeitbedarfs bearbeitet: die kurzen zuerst.

Ein früh eintreffender Prozess mit hohem Rechenzeitbedarf oder einer Endlosschleife hält alle späteren Prozesse nicht auf. SJF hat jedoch das Starvation-Problem, was jedoch mit zusätzlicher Prioritätsanpassung (aging) gemildert werden kann.

Beweis zu Minimierung der Gesamtwartezeit:

Betrachten wir eine Ausführungsreihenfolge, bei der ein langer Prozess L vor einem kurzen Prozess K an die Reihe kommt. Wenn wir die beiden miteinander vertauschen, brauchen alle dazwischen liegenden Prozesse nicht mehr so lange zu warten. Für L verlängert sich bei diesem Tausch zwar die Wartezeit, aber die Verkürzung der Wartezeit von K ist größer! Alle übrigen Prozesse sind von diesem Tausch nicht betroffen. Also verkürzt solch ein Tausch die Gesamtwartezeit. Jede von SJF verschiedene Ausführungsreihenfolge lässt sich also noch verbessern; folglich ist SJF optimal.

Das Verfahren SJF eignet sich besonders gut für den Stapel- oder Batch-Betrieb, bei dem der Rechner gleich einen ganzen Schub von Aufträgen (jobs) erhält, die keine Interaktion mit dem Benutzer erfordern und regelmäßig auszuführen sind, so daß man ihre Laufzeiten in etwa kennt.

Ja, der Scheduler weist jedem Prozess sein Quantum der Zeitscheibe zu. Nach Ablauf der Zeitscheibe löst jeweils ein HW-Timer den Interrupt aus und die Unterbrechungsroutine veranlasst den Dispatcher mit der Prozesskontextsicherung zu beginnen.

1. Ein sehr einfaches Verfahren namens Round Robin ist weit verbreitet, bei dem jeder     Prozess im Zustand bereit vom Scheduler eine Zeitscheibe (time slice) derselben Länge     an Rechenzeit zugewiesen bekommt und die Prozesse im Zustand bereit reihum bedient     werden. Interaktive Proz. leiden hierbei jedoch unter rechenintensiven Prozessen.

2. Eine Verbesserung von Round Robin ist, daß der Scheduler einem Prozess die Länge der     Zeitscheibe in Abhängigkeit von der Priorität des Prozesses oder davon, wieviel     Rechenzeit der Prozess insgesamt schon verbraucht hat, dynamisch zuweist.

3. Die Priorität eines Prozesses kann sogar nach seinem Verhalten dynamisch vergeben      werden (IO-Anfragen bekommen dynamisch hohe Prioritäten, weil sie die CPU eh nur      kurz benötigen).

1. Effizienz: Prozessor gut auslasten

2. Minimale Antwortzeit: interaktive Prozesse vor rechenlastigen Proz. bevorzugen

3. Fairness: kein Prozess darf verhungern, weil sich andere wiederholt vordrängeln

4. Minimale Durchlaufzeit, Maximaler Durchsatz, Zeitscheibe ausgewogen wählen (Verwal-      tungsaufwand gegen Interaktivität)

Interaktive Prozesse mit großem Ein-/Ausgabebedarf können sehr darunter leiden, wenn sie rechenzeitintensive Prozesse vor sich haben, die ihre langen Zeitscheiben voll ausnutzen. Darum sind zu lange Zeitscheiben nicht wünschenswert. Zu kurze Zeitscheiben sind ineffizient: Die CPU verbringt dann einen zu großen Teil ihrer Zeit mit unproduktiven Kontextwechseln, diese Zeit fehlt für die Ausführung von Prozessen und verlangsamt diese entsprechend. Prozesse mit großem Ein-/Ausgabebedarf können von extrem langen Zeitscheiben nicht profitieren: Meist blockieren sie lange bevor ihre Zeitscheibe abgelaufen ist, etwa um auf die nächste Benutzereingabe zu warten.

Etwas größer, als die gewöhnliche Interaktionszeit des Prozesses.

Im Time-Sharing-Betrieb kann es vorkommen, daß viele Prozesse kurz nacheinander auf ein Gerät zugreifen wollen. Deshalb wird zu jedem Speichergerät eine eigene Geräte-Warteschlange (device queue) eingerichtet, an die der Ein-/Ausgabeteil des Betriebs-systems Aufträge anhängen kann; jeder Auftrag wird mit der Nummer des Prozesses versehen, der ihn erteilt hat. Der Gerätetreiber holt die Aufträge einzeln aus der Warteschlange ab und führt sie dem Controller zu. Dabei ist der Treiber nicht an die Reihenfolge in der Warteschlange gebunden; er kann vielmehr versuchen, durch geschickte Wahl des nächsten Auftrags die Zugriffszeit des Geräts zu minimieren. Wie funktioniert es mit dem Drucken? Beim Drucker muß man anders vorgehen. Wenn nämlich mehrere Prozesse ihre Ausgabe zeilen- oder absatzweise zum Drucker schicken und sich dabei gegenseitig unterbrechen, entsteht auf dem Papier ein Durcheinander. Deshalb werden die Ausgaben zunächst nach Prozessen getrennt in einer Spooler-Datei gesammelt, die erst dann gedruckt wird, wenn der Prozess seine Druckausgabe abgeschlossen hat.

Der Dispatcher. Dieser führt den Prozess-Kontextwechsel durch.

Ein HW-Zeitgeber löst eine Unterbrechung der CPU aus. Der rechnende Prozess wird unterbrochen und wieder in die Menge der bereiten Prozesse eingereiht. Nun kommt i.a. ein anderer Prozess an die Reihe. Das Betriebssystem ist auch ein Programm (oder mehrere Programme) und kann daher ohne Hardware-Unterstützung (durch einen Timer-Interrupt) nicht einen gerade laufenden Prozess stoppen.

Timer = Zeitgeber

Er „wacht“ darüber, daß ein Prozess seine Zeitscheibe nicht überschreitet.

Wie funktioniert der Zugriff auf eine Festplatte? Was macht ein Programm, wenn es einen Block auf der Festplatte lesen möchte? Wie kommen die Daten aus dem Puffer des Gerätes in den Hauptspeicher?

Schon bei der Übersetzung des Programms wird der Hochsprachen-Befehl read durch einen entsprechenden Systemaufruf ersetzt, der den Ein-/Ausgabeteil des Betriebssystems startet. Wie wird eine read-Operation ausgeführt? (Am besten zeichnet man die Schichten des virtuellen Geräts, dann merkt man leicht die Schritte und die Aufgaben der einzelnen Schichten: Treiber, Controller, Gerät):

1. Eine Software-Unterbrechung (Trap) wird ausgelöst; der Kontext von P wird zunächst      gerettet, dann wird der geräteunabhängige Ein-/Ausgabeteil des Betriebssystems      aufgerufen.

2. Dieser prüft zunächst, ob die Parameter zulässig sind und ob die benötigten      Daten schon im Cache im Hauptspeicher stehen; in diesem Fall werden sie in den      Adressraum von P kopiert, und nach der Rückkehr von der Software-Unterbrechung      kann der Prozess P weiter rechnen.

3. Stehen die Daten nicht im Cache, ist ein Plattenzugriff erforderlich. Der Prozess P wird      deshalb in den Zustand blockiert versetzt. Der Leseauftrag wird an die Geräte-      Warteschlange des Plattenlaufwerks angehängt und der Gerätetreiber benachrichtigt.

4. Sobald der Gerätetreiberprozess rechnend wird, entnimmt er den Auftrag der Geräte-      Warteschlange. Der Gerätetreiber reserviert im betriebssystemeigenen Bereich     Speicherplatz für die zu lesenden Daten, bestimmt die gerätespezifische     Datenblockadresse etc. und überträgt einen Lesebefehl an den Gerätecontroller. Der     Treiber kann nun andere Aufgaben ausführen, er wird später informiert, wenn der     Lesebefehl ausgeführt worden ist, siehe Schritt 6.

5. Der Gerätecontroller bestimmt zuerst die physische Adresse, dann führt er den     Leseauftrag aus und überträgt zusammen mit dem DMA-Controller die Daten in den     reservierten Bereich im systemeigenen Speicher (der Adressraum eines inzwischen evtl.     ausgelagerten Prozesses steht nicht zur Verfügung). Währenddessen können auf der     CPU beliebige andere Prozesse rechnen. Nach dem Kopieren der Daten wird eine     DMA-Ende-Unterbrechung ausgelöst.

6. Bei der Unterbrechungsverarbeitung wird mittels des Unterbrechungsvektors die DMA-     Ausführungsende-Unterbrechungsroutine gestartet. Sie informiert den Gerätetreiber,     daß der Lesebefehl ausgeführt worden ist.

7. Sobald der Gerätetreiber diese Information empfängt, sieht er in der Gerätewarteschlange      nach, von welchem Prozess der Leseauftrag zu dieser Information stammt, und      informiert den geräteunabhängigen Ein-/Ausgabeteil des Betriebssystems.

8. Sobald der geräteunabhängige Ein-/Ausgabeteil des Betriebssystems die Information      empfängt kopiert er die Daten aus dem systemeigenen Speicher in den Adressraum      des Prozesses P und versetzt P in den Zustand bereit (z.B. via Signalisierung). Der      Systemaufruf ist damit erfolgreich bearbeitet worden.

9. Sobald der Prozess P wieder rechnen darf setzt er seine Arbeit hinter dem read fort.

Zwischen dem Compilieren und dem Ausführen eines Programms kann ein längerer Zeitraum liegen, in dem die Datenstruktur bzw. Programmstartadresse verändert wird. Deshalb kann man logische Adressen erst zur Laufzeit auf physische Adressen abbilden.

Wollte man die gelesenen Daten sofort in den Adressraum des Prozesses P übertragen, der sie angefordert hat, so müssten zwei Anforderungen erfüllt werden, die die effiziente Verwaltung des Hauptspeichers behindern würden.

Anforderung 1 - Zieladresse: die Zieladresse müsste vom Betriebssystem über den Treiber an den Controller weitergegeben werden.

Anforderung 2 - Nicht bewegen: der Adressraum von Prozess P im Hauptspeicher dürfte nicht bewegt werden, bis der Lesevorgang abgeschlossen ist. Bei inzwischen ausgelagerten Prozessen steht der Adressraum überhaupt nicht zur Verfügung.

Kapselung/Aufgabenteilung: Es widerspricht den Prinzipien von Kapselung und Aufgabenteilung (separation of concerns), dem Controller die Zieladresse mitzuteilen. Blockierte Prozesse nicht bewegen oder auf die Magnetplatte auslagern zu können, würde die effiziente Verwaltung des Hauptspeichers behindern.

Gerätetreiber: read(logische Blocknummer, Pufferadresse, Länge) Geräte-Controller: read(Zylinder, Platten, Sektorennummer, Pufferadresse, Länge)

1. Parallelrechner: Mehrprozessor, Parallelisierung, Kosteneinsparung bei Mehrkern-Pro-zessoren, fehlertolerante Systeme (fault tolerant systems), bus- oder schalterwerkbasiert (z.B. Switches/Multiplexer).

2. Verteilte Systeme (Hypercube) und 3. Realzeitsysteme.

Beim Versand von Nachrichten gibt es zwei Varianten: Den verbindungslosen (connectionless) Datenaustausch, z.B. „shared Memory“-Briefkasten (mail box), die BS-Signale, oder z.B. UDP und den verbindungsorientierten (connection-oriented) Datenaustausch, z.B. pipes oder TCP/IP.