Auf den ersten Blick hat sich in Stubs im Vergleich zur vorherigen Aufgabe nicht viel

geändert.

Unsere Anwendungsfäden incrementieren weiterhin fröhlich vor sich hin, vielleicht ein wenig

schneller als zuvor.

Die Ausgabe rechts oben ist neu, es wird die Zeit angezeigt, aber das ist optional.

Die eigentliche Änderung ist wieder nur unter der Haube zu sehen.

Unsere Anwendung sah in vorherigen Aufgaben in etwa so aus.

Nun verschwindet aber der kooperative Wechsel der Anwendungen mittels Scheduler Resume.

Dennoch werden alle Fäden bedient.

Dank einer regelmäßig auftretenden Unterbrechung, welche den Wechsel initiiert.

Während dieses präemptive Scheduling natürlich Anwendungsentwicklern das Leben vereinfacht,

muss Stubs selbst unter Umständen erst noch abgesichert werden, denn diese Unterbrechungen

können nun jederzeit, also an jeder Stelle des Codes geschehen.

Potential für viele interessante Fehler.

Was müssen wir dafür tun?

Für das präemptive Scheduling wollen wir den La-Pictimer verwenden, der dazu zuerst

konfiguriert und kalibriert werden muss.

Neben dem Umbau der Anwendung und den Schutz kritischer Abschnitte müssen nun in mp-stubs-kerne

unter Umständen bei bestimmten Ereignissen benachrichtigt werden.

Außerdem gibt es die Möglichkeit freiwillig weitere Timer einzubauen, wie die in der Musterlösung

gezeigte Real-Time Clock, welche die aktuelle Uhrzeit und Datum anzeigt.

Das wird dann über die Clock gesteuert.

Daneben gibt es noch die Watch, welche bei vom La-Pict ausgelösten Unterbrechungen den

Threadwechsel auslöst.

Sie stellt dabei folgende Methoden zur Verfügung.

Wind-Up stellt das gewünschte Unterbrechungsintervall ein, und zwar in Mikrosekunden.

Es ist für die Aufgabe außerordentlich hilfreich, Mikro- und Millisekunden nicht zu verwechseln

und im Zweifelsfall nochmals genau zu lesen.

Wenn die Uhr nun aufgezogen wurde, kann sie aktiviert werden, damit die Unterbrechungen

kommen.

Im Mehrkernbetrieb muss das nun auf jedem Kern gemacht werden, denn jeder hat einen

eigenen La-Pict.

Beim Wind-Up reicht jedoch ein einzelner Aufruf, da die A-Pict-Bus-Frequenz für alle Kerne

gleich ist.

Und da die Watch ein Gerät ist, muss sie auch einen Prolog und Epilog anbieten.

Dabei fordert der Prolog nur einen Epilog an und tätigt vielleicht zu Testzwecken mal

eine Ausgabe.

Sobald wir dann in der Epilog-Ebene sind, wird der Threadwechsel ausgeführt.

Der La-Pict-Timer hat nun leider jedoch keine uns bekannte Basisfrequenz, sondern nimmt

den A-Pict-Bus-Takt, welcher wiederum je nach Hardware komplett unterschiedlich sein kann.

Er entspricht entweder der Prozessor Core Clock, der Core Chrysler Clock oder auch etwas

ganz anderem.

Und ein Auslesen solcher Werte mittels CPU-ID und MSR ist auch keineswegs schön, wie man

am Beispiel des Timestamp-Counters sehen kann.

Wie können wir nun einfach die Frequenz feststellen, möglichst generisch, damit es auf jeder Hardware

läuft?

Nun, wir messen einfach die Zeit, wie lange ein Tick dauert, und zwar mit Hilfe eines

anderen Timers, welcher auf jeder Hardware vorhanden ist und dessen Frequenz wir kennen,

dem Programmable Interval Timer.

Dieser ist bereits in Stubs fertig implementiert.