Reihen oberflächlich betrachtet ist bei der Musterlösung zur Aufgabe 3 kein Unterschied zur vorherigen Aufgabe erkennbar.

Unterbrechungen werden wie gewohnt im Round-Robin-Verfahren von den Kernen abgearbeitet.

Aber unter der Haube steckt eine Änderung, die es in sich hat.

Bisher haben wir lediglich Interrupt-Sperren verwendet, um kritische Abschnitte in Stubs zu schützen.

Stattdessen kommt nun das Prolog-Epilog-Modell zum Einsatz.

Das bedeutet nun nicht, dass wir gänzlich ohne Client-Sti auskommen.

Vereinzelt werden diese weiterhin noch gebraucht, um sehr kurze Abschnitte zu sichern.

Aber in Anwendungen nutzen wir nun stattdessen den Epilog,

wessen Funktionen Enter, Leave und Relay in Guard implementiert werden.

Die Treiberschnittstelle Gate bietet statt Trigger nun Prolog und Epilog an.

Entsprechend müssen auch die Treiber sowie die Unterbrechungsbehandlung angepasst werden.

Da Epilog auch verzögert werden können, stellt Gate-Q eine Epilog-Warteschlange

mit den elementaren Funktionen Enqueue und Dequeue zur Verfügung.

Während in OO-Stubs insgesamt eine verkettete Liste ausreicht,

braucht in MP-Stubs jeder Kern eine eigene Warteschlange.

Dadurch stellen wir sicher, dass der Epilog auch auf derselben CPU wie der Prolog ausgeführt wird.

Dabei darf in einer Warteschlange derselbe Epilog nicht mehrfach vorkommen.

Also beispielsweise wenn wir auf einer CPU-Lange in Ebene 1,5 sind

und dort bereits zwei Tastaturunterbrechungen und Prologe hatten,

dann ist dennoch nur ein Tastatur-Epilog in dieser Warteschlange.

Diese Design-Entscheidung macht uns das Leben einfacher,

da wir dem Verkettungszeiger, den Next-Pointer, für die Epilog-Warteschlange einfach als Klassenattribut in Gate anlegen können.

Wie der Epilog im Beispiel der beiden Tastaturprologe das behandeln soll, bleibt euch überlassen.

Eine Möglichkeit ist hierfür ein Ringpuffer, um mehrere Tasten speichern zu können.

Oder aber nur eine Taste wird gespeichert und die andere verworfen,

was konzeptionell kein großer Unterschied ist, nur ein Puffer der Länge 1.

Bei Ampestops kann es nun aber durchaus vorkommen, dass derselbe Epilog in unterschiedlichen Epilog-Warteschlangen,

also beispielsweise auf CPU 1 und 3, gleichzeitig eingereiht ist.

Für die Tastatur ist das nun noch nicht wichtig,

jedoch brauchen wir dieses Verhalten in späteren Aufgaben noch für Timer- und Interprozessor-Interrupts.

Und im Mehrkernbetrieb ist außerdem darauf zu achten,

dass zu keinem Zeitpunkt mehr als ein Kern auf der Epilog-Ebene arbeitet.

Dies lässt sich mit einem sogenannten Bikern-Log bewerkstelligen,

einer Umlaufsperre, welche dafür sorgt, dass andere Kerne, welche in die Epilog-Ebene wollen,

aktiv warten, wenn diese Ebene gerade belegt ist.

Für die Implementierung muss hier der Ticket-Log verwendet werden.

Er ist nicht nur fairer, sondern aufgrund von Catch-Effekten bei unserer Test-Hardware,

Stichwort Hyper-Threading, kann es bei einem Spin-Log vorkommen, dass zwei Kerne komplett verhungern.

Und obwohl es nur um wenige Code-Zeilen geht, sollte man auch die Reihenfolge von Sperraufrufe genau durchdenken.

Das gewünschte Verhalten von MPStubs vertiefen wir an ein Beispiel mit zwei Kernen.

Zuerst wechselt CPU0 mit Enter auf die Epilog-Ebene.

Danach führt CPU1 ebenfalls ein Enter aus, jedoch ist die Ebene belegt und sie muss warten.

Sobald CPU0 dann fertig ist und wieder auf die Anwendungsebene wechselt,

kann CPU1 den kritischen Abschnitt betreten.

Nun wird CPU0 durch ein Ereignis unterbrochen, wechselt auf die Interrupt-Ebene und führt den Prolog aus.

Im Anschluss wird Relay ausgeführt.

Und da diese CPU zum Zeitpunkt der Unterbrechung nicht in der Epilog-Ebene war,

wird nun versucht in die Ebene ein halb zu wechseln und dort den Epilog auszuführen.

Allerdings ist diese Ebene gerade von CPU1 belegt, also muss aktiv gewartet werden, bis diese wieder frei wird.

Währenddessen wird die CPU1 unterbrochen.