7.2 Nebenläufigkeit von Tasks
389
Task-Graphen können verschmolzen werden, wenn eine Task τ i unmittelbare
Vorgängerin einer Task τ j ist und τ j keine andere direkte Vorgängerin besitzt (siehe
Abb. 7.8 mit τ i = τ 3 und τ j = τ 4 ). Diese Umwandlung kann einen geringeren
Abb. 7.8 Verschmelzen
von Tasks
∗
τ
τ
τ
τ
τ
τ
τ
τ
τ
1
2
3
4
5
1
2
5
3
Aufwand für die Kontextumschaltung zwischen Prozessen zur Folge haben, wenn
der Knoten in Software implementiert ist. Allgemein kann hierdurch ein größeres
Optimierungspotential entstehen.
Weiterhin kann das Aufteilen von Tasks vorteilhaft sein. Beispielsweise können
Tasks Ressourcen belegen (wie z.B. große Mengen an Speicher), während sie auf
Eingaben warten. Um die Verwendung dieser Ressourcen zu maximieren, kann es
sinnvoll sein, die Verwendung der Ressourcen nur in den Zeitintervallen zu erlauben,
in denen sie tatsächlich benötigt werden.
Beispiel 7.6: Abb. 7.9 geht davon aus, dass die Task τ 2 eine Eingabe während ihrer
Ausführung benötigt. In der ursprünglichen Variante kann die Ausführung von Task
Abb. 7.9 Aufteilen
von Tasks
*
**
τ
τ
τ
τ
τ
τ
τ
τ
τ
τ
τ
2
5
4
2
1
2
5
4
3
1
3
τ 2 nur dann beginnen, wenn diese Eingabe verfügbar ist. Wir können diesen Knoten
nun in τ ∗
2 und τ ∗∗
2 aufteilen, so dass die Eingabe nur für die Ausführung von τ ∗∗
2
erforderlich ist. Damit kann nun τ ∗
2 früher starten, wodurch das System einen größeren Freiraum für Scheduling-Entscheidungen erhält. Diese größere Freiheit beim
Scheduling kann die Auslastung von Ressourcen verbessern und es sogar ermöglichen, eine bestimmte Deadline einzuhalten. Zudem kann sie einen Einfluss auf den
benötigten Speicherplatz haben, da τ ∗
2 einen Teil seines Speichers freigeben könnte,
bevor die Task sich beendet. Dieser Speicher könnte dann wiederum von anderen
Tasks verwendet werden, während τ ∗∗
2 auf Eingaben wartet.
∇
Man könnte nun argumentieren, dass Tasks solche Ressourcen – wie große Mengen Speicher – sowieso freigeben sollten, bevor sie auf Eingaben warten. Wenn man
solche Details der Implementierung aber bereits in einer frühen Spezifikationsphase berücksichtigen würde, könnte die Lesbarkeit der ursprünglichen Spezifikation
darunter leiden.
389
Task-Graphen können verschmolzen werden, wenn eine Task τ i unmittelbare
Vorgängerin einer Task τ j ist und τ j keine andere direkte Vorgängerin besitzt (siehe
Abb. 7.8 mit τ i = τ 3 und τ j = τ 4 ). Diese Umwandlung kann einen geringeren
Abb. 7.8 Verschmelzen
von Tasks
∗
τ
τ
τ
τ
τ
τ
τ
τ
τ
1
2
3
4
5
1
2
5
3
Aufwand für die Kontextumschaltung zwischen Prozessen zur Folge haben, wenn
der Knoten in Software implementiert ist. Allgemein kann hierdurch ein größeres
Optimierungspotential entstehen.
Weiterhin kann das Aufteilen von Tasks vorteilhaft sein. Beispielsweise können
Tasks Ressourcen belegen (wie z.B. große Mengen an Speicher), während sie auf
Eingaben warten. Um die Verwendung dieser Ressourcen zu maximieren, kann es
sinnvoll sein, die Verwendung der Ressourcen nur in den Zeitintervallen zu erlauben,
in denen sie tatsächlich benötigt werden.
Beispiel 7.6: Abb. 7.9 geht davon aus, dass die Task τ 2 eine Eingabe während ihrer
Ausführung benötigt. In der ursprünglichen Variante kann die Ausführung von Task
Abb. 7.9 Aufteilen
von Tasks
*
**
τ
τ
τ
τ
τ
τ
τ
τ
τ
τ
τ
2
5
4
2
1
2
5
4
3
1
3
τ 2 nur dann beginnen, wenn diese Eingabe verfügbar ist. Wir können diesen Knoten
nun in τ ∗
2 und τ ∗∗
2 aufteilen, so dass die Eingabe nur für die Ausführung von τ ∗∗
2
erforderlich ist. Damit kann nun τ ∗
2 früher starten, wodurch das System einen größeren Freiraum für Scheduling-Entscheidungen erhält. Diese größere Freiheit beim
Scheduling kann die Auslastung von Ressourcen verbessern und es sogar ermöglichen, eine bestimmte Deadline einzuhalten. Zudem kann sie einen Einfluss auf den
benötigten Speicherplatz haben, da τ ∗
2 einen Teil seines Speichers freigeben könnte,
bevor die Task sich beendet. Dieser Speicher könnte dann wiederum von anderen
Tasks verwendet werden, während τ ∗∗
2 auf Eingaben wartet.
∇
Man könnte nun argumentieren, dass Tasks solche Ressourcen – wie große Mengen Speicher – sowieso freigeben sollten, bevor sie auf Eingaben warten. Wenn man
solche Details der Implementierung aber bereits in einer frühen Spezifikationsphase berücksichtigen würde, könnte die Lesbarkeit der ursprünglichen Spezifikation
darunter leiden.