Dynamische Adaption in heterogenen verteilten eingebetteten ...

5.5 Anwendungsbeispiel KESO
wird mithilfe des KESO-Compilers neuer Anwendungscode erzeugt, der die neue Klasse enthält und
berücksichtigt. Anschließend untersucht der Verwalter, welche Teile des Codes sich verändert haben.
Dann wird der alte Code durch den neuen ausgetauscht. Der Zustand des Systems bleibt dabei zunächst
erhalten und wird in einem zweiten Schritt angepasst.
Durch den statischen Ansatz sind viele Datenstrukturen des Systems konstant und werden wie Code
ausgetauscht. Um Veränderungen an der Objektstruktur festzustellen, wird der Aufbau der Datentypen
untersucht. Hat sich die Struktur der Objekte verändert, so werden alle Objekte angepasst. Für die
Anpassung der Objektstruktur muss eine spezielle Konvertierungsfunktion am Verwalter vorhanden
sein, in der spezifisches Wissen über die Vorgehensweise des KESO-Systems enthalten ist.
Neben solchen grundlegenden Änderungen kann das System auch um Dienste erweitert werden, die
KESO nicht anbietet. Beispielsweise bietet KESO keine Möglichkeit an, Informationen über die Typen
zur Laufzeit abzufragen. Ein Laufzeittypsystem lässt sich jedoch gut als externer Dienst bereitstellen.
Da nicht alle benötigten Klassendaten explizit im erzeugten C-Code vorhanden sind, kann der KESO-
Compiler zusätzliche Tabellen mit den vollständigen Klasseninformationen erstellen. Auf dieser Basis
können Anfragen über den Aufbau der Typen vom Verwalter beantwortet werden.
Anpassen existierender Funktionen
Am KESO-System kann auch das dynamische Austauschen von Bausteinen vorgestellt werden. Als
Beispiel dient hierbei der Scheduler, der von der zugrunde gelegten Betriebssystembibliothek bereitgestellt
wird. Zur Demonstration wurde die Betriebssystembibliothek JOSEK betrachtet, die Teil des
KESO-Projekts ist und als Anpassungsschicht an andere Betriebssysteme dient. Diese Schicht enthält
einen generischen, prioritätengesteuerten Scheduler, zu dem als Alternative ein spezialisierter Scheduler
erstellt wurde, welcher nur zwei Threads unterstützt. Durch die Optimierung kann die Verwaltung der
Prioritäten stark eingeschränkt werden, da die beiden Threads immer nur abwechselnd laufen können.
Daher wurde auch die Threadsteuerung entsprechend vereinfacht. Der Verwalter integriert nun bei der
Erstellung des initialen Abbildes eine Unterstützungsfunktion, die ihn benachrichtigt, sobald ein dritter
Task aktiviert wird. Zu diesem Zeitpunkt wird die spezialisierte Version gegen die generische Version
ausgetauscht. Bei der Installation des generischen Schedulers muss darauf geachtet werden, dass die
Datenstrukturen mit dem aktuellen Zustand initialisiert werden. Dazu wurde eine spezielle Funktion
am Verwalter implementiert, welche die Bedeutung der Datenfelder kennt und ihren Wert entsprechend
dem aktuellen Zustand setzt. Tabelle 5.3 zeigt den Speicherbedarf des ursprünglichen Schedulers und
der Spezialversion.
KESO Scheduler .text .rodata .data .bss Total
für zwei Threads optimiert 780 280 61 0 1121 Byte
generisch, prioritätengesteuert 1402 392 62 20 1876 Byte
Tabelle 5.3: Speicherbedarf von verschiedenen Threadverwaltungen für KESO
Die Tabelle zeigt die Größen des Schedulers und der Threadsteuerung für KESO in zwei Varianten. Die Werte wurden
an einer x86-Version von KESO ermittelt, da sich die Version für AVR-Mikrocontroller zum Zeitpunkt der Messungen
(Mai 2008) noch im Aufbau befindet.
Ein weiteres Beispiel ist die Speicherbereinigung. KESO bietet zwei Varianten an. Einen einfachen
“mark-and-sweep” Garbage Collector, der exklusiv laufen muss und eine inkrementelle Version, die
mithilfe von Schreibbarrieren ein konsistentes Bild des Objektgraphen aufbaut. In Tabelle 5.4 sind die
Größen der beiden Varianten aufgezeigt.
127