Wir sind auch schon wieder am Ende der heutigen Vorlesungstunde und wir fassen mal den Stoff kurz zusammen.

Das Rüsemehje. Wir haben einleitend nochmal kurz die virtuellen Maschinen aufgegriffen und klargestellt,

inwiefern man das Betriebssystem eben als so eine Art virtuelle hybride Maschine denn verstehen kann.

Das ist im Wesentlichen durch die Teilinterpretation begründet, die eben die Grundlage dafür bietet,

dass wir überhaupt Maschinenprogramme ausführen können.

Ein wichtiger Punkt dabei ist, dass die Tatsache, dass Betriebssysteme durchaus im Rahmen dieser Teilinterpretation

wieder betreten werden könnten, dass so eine Art indirekte Rekursion von Betriebssystemfunktion möglich ist.

Und das bedeutet, dass eben Betriebssysteme, die sowas zulassen, dann eben Ablauf invariant sein müssen.

Sie müssen wieder eintrittsfähig überhaupt sein, damit das Gesamtrechensystem korrekt ablaufen würde.

Nun, das zentrale Mittel für diese Teilinterpretation ist die Ausnahme.

Zwei Arten Trepp und Interharp. Im Wesentlichen unterschieden dahingehend, dass Trepp synchron sind,

Interharp sind asynchron, Trepp sind vorhersagbar, Interharp sind unvorhersagbar, Trepp sind reproduzierbar

und Interharp sind nicht reproduzierbar. Die problematischen Art von Ausnahme sind damit eigentlich die Interharp,

wenn man da eher nie so genau sagen kann, wie sich denn eigentlich Programme, die denn unterbrochen werden,

die der Teil unter Interpretation darliegen, im weiteren Verlauf verhalten werden.

In beiden Fällen ist zu beachten, dass die Ausführung unterbrochene Programme natürlich verzögert wird.

Und wenn diese Verzögerung eben unvorhersagbar, asynchron geschieht, dann ist es gerade kritisch für zeitabhängige unterbrochene Programme,

weil dann keine klaren, einheitigen Aussagen mehr zum Zeitverhalten dieser Programme auf ihrer Ebene durchgeführt werden kann.

Ein wichtiger Punkt, gerade dann, wenn die Unterbrechung asynchron geschieht, ist, den Laufzeitkontext invariant zu halten.

Interrupts sind hier ein wesentlicher Moment dafür, dass wir von solchen invarianten Laufzeitkontexten sprechen müssen.

Das bedeutet, die Sicherung und Wiederherstellung von dem Prozessorstatus zu den passenden Zeitpunkten,

also bevor man überhaupt die Ausnahmebehandlung durchführt, muss die Sicherung erfolgen.

Bevor man dann zurückkehrt, am Ende der Unterbrechungsbehandlung,

muss der Prozessorstatus wiederhergestellt werden.

Das ist hier im Wesentlichen durch die Befehlsetzebene geleistet und durch das Betriebssystem.

Das sind die Standardsituationen, die wir haben.

Wir haben auch ein anderes Beispiel gehabt, wo man sieht, dass der Compiler und die Befehlsetzebene allein dafür verantwortlich sind.

Aber es bedeutet eben doch bestimmte spezielle Spracheigenschaften,

die man in der Programmiersprache wie auch umgesetzt durch den Compiler bekommen muss, was nicht der Stand der Kunst in der Realität ist.

Und dann haben wir in Zusammenhang mit den Interrupts eben gesehen,

dass es zu einer überlappenden und durchaus kritischen überlappenden Programmausführung kommen kann.

Diese Interrupts begründen nicht sequenzielle Programmafläufe.

Sie machen letztendlich ein Programm nicht sequenziell, wenn man davon ausgeht,

dass in diesem Programm selbst eine Interruptbehandlung letztendlich stattfindet.

Das ist typisch für ein Betriebssystem.

Jedes Betriebssystem führt eine Interruptbehandlung durch und eben auch normale Abläufe, die dort stattfinden, die sich jeweils überlappen können.

Und da muss man aufpassen, dass es nicht zu Wettlaufsituationen bei der Programmausführung auf dieser Ebene jeweils kommt.

Kommt es zu solchen Wettlaufsituationen, muss man diese Wettlaufsituationen auflösen.

Ein Mechanismus dafür haben wir kurz gesehen, ist diese kritischen Programmen, sagen wir mal Folgen, Anweisungsfolgen als einen sogenannten kritischen Abschnitt zu verstehen,

wo man sicherstellt, dass zu jedem Zeitpunkt immer nur ein einziger Prozess sich in diesem Abschnitt gerade befinden darf.

Wir werden diesen Aspekt später im weiteren Verlauf von SP A1 wie auch von SP 2 nochmal behandeln.

Generell kann man einfach sagen, dass Unterbrechungen nicht einfach sind.

Insbesondere Unterbrechungen, die dann asynchron auftreten können einfach deshalb, weil sie unvorhersehbar sind.

Und dazu führen, dass unterbrochene Programme, wenn auf dieser Ebene dieser Programme selbst die Behandlung durchgeführt werden muss,

dass diese Programme in einem Betriebssystem eben zu nicht sekundziellen Programmen werden.