Wenn Geräte uns unterbrechen, dann tun sie das oft nicht grundlos.

Eine Tastatur möchte uns beispielsweise auf einen neuen Tastendruck hinweisen, den wir

abholen und verarbeiten können.

Aber damit verändern wir auch den Zustand des Systems.

Bleiben wir beim Beispiel Tastatur.

Die Unterbrechungsbehandlung legt neue Tasten in einem Puffer, führt also ein Produce aus.

Unser Hauptprogramm entnimmt in eine Endlosschleife aus diesem Puffer, also ein Consume.

Wenn wir unser System damit starten, wird Main ausgeführt und in der Schleife Consume aufgerufen.

Wenn nun eine Unterbrechung, ein Tastendruck kommt, dann wird der Ablauf unterbrochen und die Unterbrechungsbehandlung führt das Produce aus.

Danach wird die Ausführung des Hauptprogramms fortgesetzt.

Was ist, wenn wir einfach naiv einen Puffer, wie hier im Beispiel, implementieren?

Nun, die Variable pos wird von beiden verwendet.

Wenn Consume ungünstig bei –pos unterbrochen wird, kann es ein Lost Update geben.

Ein bewährtes Hausmittel gegen das Erzeuger-Verbraucher-Problem ist der gegenseitige Ausschluss.

Einfach die kritischen Abschhinde im Qualtics mit einem Utick schützen und es verklemmt sich.

Wenn Main gerade in Consume Log aufgerufen hat und dann Produce in der Unterbrechungsbehandlung ebenfalls Log versucht aufzurufen.

Mit viel Überlegung und atomaren Operationen wie Compare and Swap können wir ein logfreies Consume und Produce entwickeln.

Was auch wunderbar funktioniert.

Dieser Ansatz kann sehr effizient sein, stellt jedoch keine generische Lösung dar.

Schlimmer noch, bei komplexeren Datenstrukturen kann eine derartige weiche Synchronisation sehr schnell kompliziert und damit auch fehleranfällig werden.

Wenn wir nun jedoch ein erfolgreiches Betriebssystem schreiben wollen, müssen wir den Treiber- und Anwendungsentwicklern entgegenkommen

und ihnen einfache Werkzeuge für solche Synchronisationsprobleme in die Hand geben.

Denn sonst wird unser Betriebssystem nicht genutzt.

Ein derart einfaches Werkzeug ist die harte Synchronisation.

Dabei sperren wir mittels Klee erst die Interrupts, bevor wir Consume aufrufen.

Sollte nun eine Unterbrechung ankommen, so wird diese verzögert, bis wir die Interrupts mit Stee wieder freigeben.

Erst danach wird die Unterbrechungsbehandlung aufgerufen und das Produce ausgeführt.

Unsere einfache, naive Implementierung vom Anfang ist also ausreichend.

Aber was, wenn eine weitere Unterbrechung kommt?

Nun, diese geht dann verloren.

Wir haben mit der harten Synchronisation nun eine einfache und wartbare Variante,

welche aber hohe Latenzen verursacht und im schlimmsten Fall sogar Unterbrechungsanfragen verliert.

Ideal wäre ein Hybrid, welcher die Vorteile von weicher und harter Synchronisation vereint,

aus dem optimistischen und pessimistischen Ansatz einen realistischen macht.

Was auch die Idee hinter dem Prologue-Epilog-Modell ist.

Hierbei erledigt der Prologue das Nötigste auf der Ebene 1 mit gesperrten Interrupts.

Der Epilog arbeitet auf einer neuen Zwischenebene, der Ebene 1 ½, bei welchem jedoch Unterbrechungen wieder erlaubt sind.

Analog zu den Operationen für die Interrupt-Ebene 1 aus der harten Synchronisation definieren wir Operationen für die Ebene 1 ½.

Mit CLEE wird Ebene 1 betreten und mit Stee verlassen, bei Ebene 1 ½ sind das Enter und Leave.

Das Äquivalent der Interrupt-Leitung bei Ebene 1 ist die Funktion Relay bei Ebene ½.

Beim Programmablauf wechseln wir vor einem kritischen Abschnitt mit Enter auf die Ebene ½.

Nach dem Abschnitt können wir diese mit Leave wieder verlassen.

Bei einem Interrupt wird direkt auf die Interrupt-Ebene 1 gewechselt und dort der Prolog ausgeführt,

welcher die nötigsten Arbeiten erledigt, beispielsweise die Daten vom Gerät abholt.

Anschließend wechselt er mit Relay auf die Ebene ½ und führt dort den Epilog aus,

welcher die weitere Verarbeitung der abgeholten Daten übernimmt.

Danach wird mit Leave auch diese Ebene verlassen und die Anwendung auf der Ebene 0 weiter ausgeführt.

Dieser Ansatz gibt den Treiber- und Anwendungsentwicklern ein einfaches Programmiermodell zur Hand,

bedeutet aber allerdings einen gewissen Mehraufwand für uns.

Ebenfalls stellt auch die neue Ebene einen gewissen zusätzlichen Aufwand zur Laufzeit dar,