Dynamische Adaption in heterogenen verteilten eingebetteten ...

5.4 Eine JVM als Baukasten
lassen sich durch den Abhängigkeitsgraphen der Basisschicht feststellen. Wie auch schon bei der
Threaderzeugung kann die Threadsteuerung nachträglich notwendig werden, wenn Code nachgeladen
wird.
Wie bereits in Abschnitt 5.2.2 geschildert, können die Verwaltungsstrukturen auf die Anzahl der
vorhandenen Aktivitätsträger angepasst werden. Um dabei die Flexibilität zu erhalten, muss der
Verwalter über die Erzeugung neuer Threads informiert werden, um gegebenenfalls die Threadsteuerung
austauschen zu können.
5.4.4.3 Scheduler
Sind mehrere lauffähige Aktivitätsträger im System vorhanden, muss vor jeder Threadumschaltung
ausgewählt werden, welcher der möglichen Kandidaten nun tatsächlich als nächstes die CPU verwenden
darf. Diese Einplanung der Aktivitätsträger wird vom Scheduler vorgenommen, der somit die Strategie
zur Auswahl des nächsten Threads darstellt.
Abbildung 5.10: Abhängigkeiten des Schedulers
Der Scheduler wird vor jeder Threadaktivierung beziehungsweise -umschaltung aktiviert. Dies ist
notwendig, wenn der aktuelle Aktivitätsträger zum Beispiel blockiert, durch ein Zeitscheibenereignis
verdrängt wird oder den Prozessor freiwillig abgibt (Thread.yield()). Der Scheduler wird somit
nie direkt durch die Anwendung aktiviert, sondern immer nur indirekt über die Threadsteuerung.
Je nachdem, wie viele Aktivitätsträger im System sind, lassen sich optimierte Varianten des Schedulers
erstellen. Ist nur ein Thread vorhanden, wird gar keine Einplanungsstrategie benötigt, da es keine
Wahlmöglichkeit gibt. Die Komplexität der Einplanungsstrategie nimmt mit zunehmender Threadanzahl
zu. Bei nur zwei Aktivitätsträgern kann immer der jeweils andere ausgewählt werden, bei deutlich
mehr Threads kann eine komplexe Strategie oder sogar ein generischer Scheduler mit austauschbarer
Strategie eingesetzt werden. Ist die Anzahl der vorhandenen Threads konstant oder die maximale
Anzahl bekannt, so kann man eine optimierte Implementierung verwenden, die im Gegensatz zu
einer generischen Implementierung, weniger Overhead mit sich bringt, dafür aber nicht beliebig viele
Threads verwalten kann.
Um automatisch eine Optimierung auswählen zu können, muss die Anzahl der vorhandenen Threads
festgestellt werden. Einige spezielle Fälle können zur Kompilierzeit festgestellt werden. Beispielsweise
kann eine Codeanalyse feststellen, dass in der Anwendung kein Thread-Objekt erstellt wird. Somit ist
nur ein Aktivitätsträger vorhanden. Wird jedoch Code zur Erstellung eines Thread-Objekts gefunden,
so ist es nicht immer möglich zu sagen, wie oft er durchlaufen wird.
Erfolgversprechender ist, zur Laufzeit festzustellen, wie viele Threads aktuell existieren und anhand
dieser Information die optimale Threadverwaltung auszuwählen. Dazu meldet der verwaltete Knoten
dem Verwalter, sobald sich die Anzahl der existierenden Threads verändert. Dieser kann dann einen
Scheduler installieren, der optimal auf die entsprechende Threadanzahl abgestimmt ist.
Die Auslagerung des Schedulers als externer Dienst ist nur sinnvoll, wenn die Bestimmung des
nächsten Threads sehr aufwendig ist. Oft ist die eingesetzte Strategie jedoch relativ einfach.
115