Objektorientierte Daten- und Zeitmodelle für die Echtzeit ...

14 KAPITEL 1. EINFÜHRUNG
Eine weitere Parallelisierungsebene ergibt sich aus der möglichen Nebenläufigkeit verschiedener,
voneinander weitestgehend unabhängiger Teilaufgaben. Eine solche Aufgabenparallelität
kann auf Operatorebene und auf Programmebene auftreten. In [Lüc00] werden auch hierfür
Ansätze für die automatische, agentenbasierte Parallelisierung untersucht.
Als dritte Möglichkeit für eine Parallelisierung kann das Pipelining-Konzept genutzt werden,
das insbesondere für die Bildfolgenverarbeitung auf Spezialhardware eingesetzt wird. Jeder
Prozessor ist dabei für eine bestimmte Teilaufgabe zuständig, wobei die verschiedenen Prozessoren
auf unterschiedlichen, nacheinander aufgenommenen Bildern arbeiten. Konzepte für
eine automatische Programmierung von Bildauswertungsgeräte, die nach dem Pipelining-Prinzip
arbeiten, werden in [Mel95] beschrieben.
Selbstverständlich kann ein System auch gleichzeitig in mehreren dieser Ebenen parallelisiert
werden. Für den Anwendungsentwickler sind vor allem die Ansätze interessant, die sich
auf Standardhardware effizient umsetzen lassen, problemlos in der verwendeten Programmiersprache
ausgedrückt werden können und die keinen oder nur wenig zusätzlichen Programmieraufwand
erfordern. Das trifft insbesondere für die auf Operatorebene durchgeführte Datenund
Aufgabenparallelisierung zu, wenn sie durch die verwendeten Bildverarbeitungsoperatoren
gekapselt wird.
Des weiteren läßt sich Aufgabenparallelität auch auf Programmebene nutzen, vorausgesetzt
das Betriebssystem stellt entsprechende Mechanismen und Hilfsmittel bereit, und die einzelnen
Aufgaben können als unabhängige Programmzweige implementiert werden. Die erste Forderung
wird von allen modernen Betriebssystemen durch Prozesse, Threads und Semaphore
unterstützt. Das Betriebssystem übernimmt dabei die Aufgabe, die einzelnen Zweige eines
Programms auf die vorhandenen Prozessoren aufzuteilen. Ein großer Vorteil dieser Form der
Parallelisierung ist, daß die geforderte Hardwareunabhängigkeit prinzipiell erhalten bleibt, da
die Programmaufteilung unabhängig von den tatsächlich zur Verfügung stehenden Prozessoren
ist. Stehen allerdings nur sehr wenige Prozessoren zur Verfügung führt eine zu starke Unterteilung
in konkurrierende Programmzweige aufgrund des Overheads beim Prozeßwechsel zu
Performanzverlusten.
Die zweite grundlegende Voraussetzung für die Aufgabenparallelität ist die Aufteilung der
Programme in entsprechend viele Bearbeitungszweige. Dies stellt im allgemeinen keine triviale
Aufgabe dar und bedeutet einen zusätzlichen Aufwand, etwa für die Absicherung kritischer
Bereiche oder das Verhindern von Verklemmungen. Darüber hinaus ist die Verwendung rein
sequentieller, imperativer Programmiertechniken nur bedingt für die Implementierung nebenläufiger
Teilaufgaben geeignet. Neben dem hohen Programmieraufwand bringt eine explizite
Spezifikation den Nachteil mit sich, daß sie aufgrund des Overheads nur für eine bestimmte
Hardwarekonfiguration optimal ausgelegt werden kann. Ändert sich diese, ist i.d.R. eine erneute
Spezifikation notwendig.
Funktionale Sprachen und Datenflußgraphen, sind aufgrund ihrer parallelen Struktur prinzipiell
besser geeignet für die Darstellung paralleler Kontrollflüsse. Im Zusammenhang mit Bildverarbeitungssystemen
wurden sie bisher jedoch in erster Linie als Grundlage für graphische
Programmierwerkzeuge [PL94, KR94, MG95] und zur graphischen Darstellung der Beziehungen
zwischen Daten und Operatoren beim Programmentwurf [PH95, Mel95] untersucht. Ist
die Anzahl der Operatoren nicht zu groß, bieten derartige Systeme einen guten Überblick über
die Funktionen und bestehenden Abhängigkeiten eines Bildverarbeitungsmoduls. Graphische