2.1 Anforderungen
37
In der Regel können Threads untereinander über einen Zugriff auf gemeinsamen
Speicher kommunizieren.
Eine Präzisierung dieses Begriffs wird in der Definition 4.2 gegeben werden.
Das Modell nach von Neumann weist allerdings besonders für eingebettete Systeme eine Reihe schwerwiegender Probleme auf, wie z.B.:
– Es fehlen Möglichkeiten zur Beschreibung von Zeitverhalten.
– Berechnungen nach dem von-Neumann-Modell basieren implizit auf Zugriffen
auf globalen gemeinsamen Speicher (wie in Java). Dabei muss der exklusive
Zugriff auf die gemeinsam verwendeten Ressourcen sichergestellt sein. Ansonsten würden Anwendungen mit mehreren Threads, die zu beliebigen Zeiten
verdrängt werden können, ein nur schwer vorhersagbares Verhalten zur Folge
haben4. Die Verwendung von Funktionen, die exklusiven Zugriff ermöglichen, kann aber sehr schnell zu Verklemmungen (engl. Deadlocks) führen.
Diese sind nur schwer zu erkennen und können in einem System viele Jahre
lang unentdeckt bleiben.
Beispiel 2.2: Edward Lee [330] zeigt hierzu ein sehr drastisches Beispiel.
Er analysierte Implementierungen eines einfachen Observer Patterns in Java. Dieses erfordert, dass Änderungen eines Wertes von einem Erzeuger an
eine Menge an angemeldeten Beobachtern weitergeleitet werden. Dieses Verhalten kommt in eingebetteten Systemen sehr häufig vor, ist aber in einer
von-Neumann-basierten Umgebung mit mehreren verdrängbaren Threads nur
sehr schwer korrekt zu implementieren. Lee’s Code für eine möglichen Implementierung des Observer Patterns in Java in einer Umgebung mit mehreren
Threads sieht wie folgt aus:
pubbic synchronized void addListener((istener) {...}
pubbic synchronized void setVaaue(newvaaue) {
myvaaue=newvaaue;
for (int i=0; i
}
}
Die Methode addListener meldet neue Beobachter an, die Methode setVaaue
leitet neue Werte an angemeldete Beobachter weiter. In einer Umgebung mit
mehreren Threads können normalerweise Threads zu jedem beliebigen Zeitpunkt verdrängt werden, was eine nicht vorhersagbare Ausführungsreihenfolge der Threads zur Folge hat. Das Hinzufügen von Beobachtern, während
setVaaue gerade ausgeführt wird, kann zu Komplikationen führen, d.h. wir
würden nicht wissen, ob der neue Wert bereits den Beobachter erreicht hat.
Zudem stellt die Menge der Beobachter eine globale Datenstruktur dieser
Klasse dar. Daher sind diese Methoden synchronisiert, um zu vermeiden, dass
die Menge der Beobachter geändert wird, während bereits einige Werte weitergeleitet werden. So kann nur eine der beiden Methoden gleichzeitig aktiv
4 Beispiele dafür sind in den meisten Kursen zu Betriebssystemen zu finden.
37
In der Regel können Threads untereinander über einen Zugriff auf gemeinsamen
Speicher kommunizieren.
Eine Präzisierung dieses Begriffs wird in der Definition 4.2 gegeben werden.
Das Modell nach von Neumann weist allerdings besonders für eingebettete Systeme eine Reihe schwerwiegender Probleme auf, wie z.B.:
– Es fehlen Möglichkeiten zur Beschreibung von Zeitverhalten.
– Berechnungen nach dem von-Neumann-Modell basieren implizit auf Zugriffen
auf globalen gemeinsamen Speicher (wie in Java). Dabei muss der exklusive
Zugriff auf die gemeinsam verwendeten Ressourcen sichergestellt sein. Ansonsten würden Anwendungen mit mehreren Threads, die zu beliebigen Zeiten
verdrängt werden können, ein nur schwer vorhersagbares Verhalten zur Folge
haben4. Die Verwendung von Funktionen, die exklusiven Zugriff ermöglichen, kann aber sehr schnell zu Verklemmungen (engl. Deadlocks) führen.
Diese sind nur schwer zu erkennen und können in einem System viele Jahre
lang unentdeckt bleiben.
Beispiel 2.2: Edward Lee [330] zeigt hierzu ein sehr drastisches Beispiel.
Er analysierte Implementierungen eines einfachen Observer Patterns in Java. Dieses erfordert, dass Änderungen eines Wertes von einem Erzeuger an
eine Menge an angemeldeten Beobachtern weitergeleitet werden. Dieses Verhalten kommt in eingebetteten Systemen sehr häufig vor, ist aber in einer
von-Neumann-basierten Umgebung mit mehreren verdrängbaren Threads nur
sehr schwer korrekt zu implementieren. Lee’s Code für eine möglichen Implementierung des Observer Patterns in Java in einer Umgebung mit mehreren
Threads sieht wie folgt aus:
pubbic synchronized void addListener((istener) {...}
pubbic synchronized void setVaaue(newvaaue) {
myvaaue=newvaaue;
for (int i=0; i
}
}
Die Methode addListener meldet neue Beobachter an, die Methode setVaaue
leitet neue Werte an angemeldete Beobachter weiter. In einer Umgebung mit
mehreren Threads können normalerweise Threads zu jedem beliebigen Zeitpunkt verdrängt werden, was eine nicht vorhersagbare Ausführungsreihenfolge der Threads zur Folge hat. Das Hinzufügen von Beobachtern, während
setVaaue gerade ausgeführt wird, kann zu Komplikationen führen, d.h. wir
würden nicht wissen, ob der neue Wert bereits den Beobachter erreicht hat.
Zudem stellt die Menge der Beobachter eine globale Datenstruktur dieser
Klasse dar. Daher sind diese Methoden synchronisiert, um zu vermeiden, dass
die Menge der Beobachter geändert wird, während bereits einige Werte weitergeleitet werden. So kann nur eine der beiden Methoden gleichzeitig aktiv
4 Beispiele dafür sind in den meisten Kursen zu Betriebssystemen zu finden.