Multicore-Programmierung
Eingebettete Kerne
Fortsetzung des Artikels von Teil 1
Entwicklung für Multicore-Systeme
Wenn es um das Thema Multicore- Programmierung geht, heißt es oft, dass Multicore-Entwicklung von den Programmierern eine neue Denk- und Herangehensweise erfordere. Programme dürfen nicht sequenziell sein, sondern müssen parallelisiert werden, um die Ausführung sinnvoll zwischen den Kernen aufteilen zu können.
Interessanterweise ist gerade der verbreitete objektorientierte Entwicklungsansatz vom Konzept her bereits nebenläufig, also parallel angelegt. Objekte sind autonom ausführbare, gekapselte Einheiten, die im Gesamtsystem mit anderen Objekten kooperieren, um Aufgaben auszuführen. Die Kommunikation mit benachbarten Objekten erfolgt oftmals asynchron über Nachrichten.
Während die Autoren also in ihrem Lieblingscafé sitzen und diesen Artikel schreiben, bitten sie die Bedienung um Milchkaffee. Diese Bestellung ist vergleichbar mit einer asynchron gesendeten Nachricht an die Bedienung. Anschließend schreiben sie weiter, und die Bedienung kann im Anschluss an ihre aktuelle Tätigkeit – beispielsweise kassiert sie bei einem anderen Gast – die Kaffees zubereiten und an den Tisch bringen. Weder die Serviererin noch die Gäste müssen ihre aktuelle Tätigkeit unterbrechen, denn die Nachricht (die Bestellung) wird von der Bedienung aufgenommen, in eine Bearbeitungsreihenfolge einsortiert und entsprechend dieser Reihenfolge bearbeitet.
Die vollständige Abstraktion des objektorientierten Ansatzes spiegelt sich in der standardisierten Modellierungssprache UML (Unified Modeling Language) wieder. Sie ermöglicht es, in jeder Phase der Softwareentwicklung das zu realisierende Softwaresystem über verschiedene Diagrammformen grafisch zu beschreiben. Beispielsweise können mit Struktur- und Klassendiagrammen die statische Systemarchitektur, und mit Zustandsautomaten und Aktivitätsdiagrammen die dynamischen Systemeigenschaften beschrieben werden.
Bemerkenswert dabei ist, dass viele UML-Diagrammtypen von Haus aus Nebenläufigkeiten und Parallelitäten unterstützen und eine entsprechende Syntax zur Verfügung stellen. Die UML ist heute weltweit akzeptiert und kommt in der Entwicklung von Software und Systemen vielfach zum Einsatz. Man sollte also meinen, dass Softwareapplikationen, die mit Hilfe der UML entworfen wurden, ein gewisses Maß an Parallelität unterstützen und somit prädestiniert sind für die echte parallele Verarbeitung in einer Multicore-Umgebung.
Das ist allerdings nicht der Fall. Oftmals gibt es eine Diskrepanz zwischen dem eigentlichen objektorientierten Entwurf des Systems und seiner Umsetzung. Das Konzept der asynchronen Nachrichten erfordert vom Programmierer zusätzliches Verständnis und nicht unerheblichen Programmieraufwand. Bei der Implementierung von asynchronen Nachrichten benötigt man Mechanismen zum
- Senden (»Ich bestelle einen Kaffee«),
- Speichern (»Bedienung notiert Bestellung«),
- Verarbeiten (»Bedienung bereitet Kaffee zu«),
- Priorisieren (»Hat jemand anderes vor mir bestellt?«, »Brennt es in der Küche?«) und
- Synchronisieren (»Ich muss erst zahlen, bevor ich das Lokal verlassen kann«).
Dieser zusätzliche Aufwand, aber auch die Natur der textuellen Programmiersprachen, verleiten Programmierer dazu, ursprünglich objektorientierte Systementwürfe letztendlich sequenziell umzusetzen. Die Intention des Entwurfes und die tatsächliche Implementierung laufen auseinander. Hier bieten moderne UML-Werkzeuge Vorteile, die aus den grafischen UML-Modellen Code generieren und die Kommunikationsmechanismen transparent implementieren.
Jobangebote+ passend zum Thema
Zu dieser Kategorie an Tools gehört »Rhapsody« von IBM Rational. Ein Service-Layer, der auf dem Betriebssystem aufsetzt, stellt die oben genannten Mechanismen zur Verfügung. Der Entwickler kann sich damit auf den eigentlichen Entwurf, das Verhalten der Objekte und die Kommunikation zwischen den Objekten konzentrieren. Routinearbeiten und Implementierung der Basisdienste übernimmt das Tool. Zur Besonderheit gehört, dass das Laufzeitverhalten der Applikation grafisch auf UML-Ebene nachverfolgt und gesteuert werden kann. Hierbei handelt es sich nicht um eine Simulation, sondern um den tatsächlichen, sozusagen auf UML-Ebene visualisierten Code der Applikation (Bild 1).
Dieses »grafische « Debuggen der Applikation ist auch auf einer Target-Plattform möglich. Verhalten der Zustandsautomaten, Aktivitätsdiagramme, Objektinteraktion anhand von Sequenzdiagrammen, Lebenszyklus der Objekte, Variablenbelegung – all diese Aspekte sind in Rhapsody einsehbar, während die Applikation läuft. Das Systemverhalten lässt sich auf der grafischen Modellebene validieren und testen. Ein weiterer Vorteil dieser Herangehensweise ist die Möglichkeit, bereits früh Prototypen zu erzeugen. Dank eines OSAL (Operating System Abstraction Layer), der das darunterliegende Betriebssystem abstrahiert, kann die Applikation quasi per Knopfdruck für verschiedene Betriebssysteme übersetzt werden.
Die nötigen OSAL-Adapter für die gängigsten Embedded-Betriebssysteme sind Bestandteil des Lieferumfangs. Gerade in der Multicore- Entwicklung könnte dieses »Rapid Prototyping« eine bedeutende Schlüsselfunktion einnehmen, da es eine elegante Möglichkeit bietet, die Konfigurationsfragen frühzeitig zu beantworten:
- Nutze ich SMP oder AMP?
- Nehme ich eine homogene oder heterogene Betriebssystemstruktur?
- Wie partitioniere ich meine Applikation hinsichtlich einer effizienten Kommunikation zwischen den Cores?
- Ist die Applikation leistungsfähiger, wenn ich die Verteilung der Aufgaben auf die Cores dem Betriebssystem überlasse (Dynamic Load Balancing), oder definiere ich dies in der Applikation?
- Wie viele Cores sind nötig?
Frühes Prototyping versetzt die Entwickler in die Lage, das System bereits in einer möglichst frühen Entwurfsphase zu evaluieren, die richtige Konfiguration zu identifizieren und zu optimieren.
Die Autoren:
Frank Braun ist Rhapsody Program Manager.
Renate Stücka ist Senior Program Manager Geo Marketing bei IBM Rational.
- Eingebettete Kerne
- Entwicklung für Multicore-Systeme
Lesen Sie mehr zum Thema
