Dynamische Adaption in heterogenen verteilten eingebetteten ...

4.4 Verweise auf Module
Abbildung 4.12: Verändern einer aktiven Funktion
Um eine dynamische Änderungsoperation durchzuführen, wird die aktuell ausgeführte Funktion unterbrochen. Ist
nun genau die unterbrochene Funktion Gegenstand der Änderung, so kann nicht gewährleistet werden, dass die
Rücksprungadresse noch sinnvoll ist. Das Fortfahren an der gespeicherten Rücksprungadresse kann zum Absturz oder
anderen unvorhersehbaren Folgen führen.
Im Detail ist es systemabhängig, ob und wie viele aktive Funktionen es geben kann. In reinen
ereignisgesteuerten Systemen, wie beispielsweise TinyOS [HSW + 00], die nur einen Aktivitätsträger
anbieten, können keine quasi-parallelen Kontrollflüsse entstehen. Nur eine Ereignisbearbeitung kann
den normalen Kontrollfluss unterbrechen. Reiht man Änderungsoperationen hier als normale Aufgaben
ein (siehe Abschnitt 4.5.7.2), so werden sie ausgeführt, wenn keine andere Aufgabe aktiv ist. Somit
ist nur die Nebenläufigkeit der Ereignisbearbeitung zu berücksichtigen. Bietet das System hingegen
ein Threadkonzept an, das die Unterbrechung der Aktivitätsträger erlaubt, so gibt es mehrere aktive
Funktionen, die man identifizieren muss, um festzustellen, ob sie von der Änderungsoperation betroffen
sind.
Zur Identifikation der aktiven Funktionen muss der Verwalter überprüfen, an welcher Stelle die
Ausführung auf dem verwalteten Gerät durch die Änderungsoperation unterbrochen wurde. Anhand der
Position kann die entsprechende Funktion bestimmt werden. Unterstützt das System mehrere Aktivitätsträger,
so muss der Verwalter die aktuellen Ausführungspositionen von allen Threads überprüfen und
erhält so die Menge der aktiven Funktionen. Da die Verweise auf eine aktive Funktion nicht verändert
werden können, liefert die Abhängigkeitsprüfung einen entsprechenden Fehlercode zurück, falls die
Abhängigkeiten von einer der aktiven Funktionen bestimmt werden sollen.
Lösungsansatz: auf Beendigung warten
Um eine solche Situation aufzulösen, bietet die Basisschicht einen einfachen Ansatz an. Der Grundgedanke
ist, dass eine aktive Funktion nur eine begrenzte Zeit lange aktiv ist und man nur eine kurze
Zeit warten muss, bis die Funktion nicht mehr aktiv ist. Das verwaltete System wird daher fortgesetzt,
um nach einem kurzen Moment erneut zu prüfen, ob ein günstigerer Systemzustand vorliegt. Die
Wahrscheinlichkeit, dass beim zweiten Versuch keine aktiven Funktionen betroffen sind, hängt vom
Aufbau der Software ab.
In dem von uns hauptsächlich betrachteten Szenario werden Dienste der Laufzeitumgebung ausgetauscht
oder verändert. Diese haben im Allgemeinen eine kurze Laufzeit und eine geringe Aufruffrequenz,
sodass die Wahrscheinlichkeit hoch ist, dass die Funktion zu einem späteren Zeitpunkt nicht
mehr aktiv ist und die Operation fortgesetzt werden kann.
Ist bei einem erneuten Versuch die Funktion immer noch oder schon wieder aktiv, so kann man das
Verfahren mehrmals wiederholen. Nach einer bestimmten Zeit oder nach einer festgelegten Anzahl von
Versuchen macht eine Wiederholung keinen Sinn mehr und die Abhängigkeitsprüfung schlägt endgültig
fehl. Das System kann in diesem Fall die aktive Funktion und den Aktivitätsträger angeben, in dem sie
69