Dynamische Adaption in heterogenen verteilten eingebetteten ...

5 Kontroll- und Verwaltungsschicht
5.4.4.4 Dispatcher
Der Dispatcher ist für die tatsächliche Umschaltung zwischen verschiedenen Aktivitätsträgern zuständig.
Seine Aufgabe ist das Wiederherstellen eines Threadkontexts und gegebenenfalls das Sichern des
aktuellen Threadzustands. Diese Aufgabe ist stark architekturabhängig, da hier Registerinhalte gesichert
und restauriert werden müssen.
Abbildung 5.11: Abhängigkeiten des Dispatchers
Vor der Einlastung von Threads muss erst bestimmt werden, welcher Thread aktiviert werden soll.
Daher wird der Dispatcher nur vom Scheduler aufgerufen, wenn dieser eine Umschaltung auf einen
anderen Aktivitätsträger entscheidet.
Ist nur ein Thread im System und wird zur Behandlung von Unterbrechungen kein manueller
Kontextwechsel benötigt, so kann auf einen Dispatcher verzichtet werden. Falls ein Dispatcher benötigt
wird, muss er jedoch lokal vorhanden sein. Die Auslagerung ist nicht möglich, da zur Einlastung
eines Threads lokale, hardwarespezifische Operationen notwendig sind, die nicht entfernt durchgeführt
werden können.
Für einige Prozessoren können jedoch verschiedene Varianten eines Dispatchers angeboten werden,
welche beispielsweise einige Spezialregister nur unter bestimmten Bedingungen sichern. So müssen die
Register der Fließkommaeinheit bei einem Kontextwechsel nicht gesichert werden, wenn keine Thread
Fließkommaoperationen durchführt. Sobald sich das jedoch ändert, muss der Dispatcher ausgetauscht
werden.
5.4.5 Koordinierungsmechanismen
Zur Koordinierung nebenläufiger Vorgänge in einer Anwendung steht in Java ein Monitor Konzept
[Han72] zur Verfügung, welches in Form eines synchronized Blocks um einen kritischen
Abschnitt angewandt werden kann. Neben dem Schutz eines kritischen Abschnitts bietet
das Monitor Konzept auch die Möglichkeit einer Benachrichtigung mittels Object.wait() und
Object.notify(), um aktives Warten vermeiden zu können.
Zur Unterstützung dieser Koordinierungsdirektiven muss die virtuelle Maschine entsprechende
Mechanismen anbieten. Neben einer Schlossvariablen, die angibt, ob der Monitor gerade besetzt ist,
wird für jeden gesperrten Monitor eine Warteschlange benötigt, in die Threads eingereiht werden,
die darauf warten, den Monitor betreten zu können. Gibt ein Thread, bei der Blockierung an einem
Monitor, die CPU auf, so wird der Zustand mithilfe der Threadsteuerung entsprechend geändert.
Bei Reaktivierung eines Threads sieht die Java-Spezifikation keine spezielle Abstimmung mit der
Einplanungsstrategie von Threads vor; es wird ausdrücklich betont, dass ein zufälliger Thread aktiviert
wird [LY99].
Abbildung 5.12: Abhängigkeiten der Koordinierungsmechanismen
116