Software für Multicore-Systeme entwickeln

Multiprozess-Applikationen haben kürzere Reaktionszeiten und be- wältigen komplexere Aufgaben. Was bedeutet das für die Entwicklung und die Architektur von Embedded-Systemen?

Multiprozessorsysteme sind konzeptionell auf die parallele Verarbeitung ausgelegt. Dabei teilen sich die Prozessoren, und somit die verschiedenen Kerne oder Cores, gemeinsame Ressourcen. Das können im Detail Speicher, Peripheriegeräte und Interrupt Controller sein.

Je nach Architektur und Hersteller nutzen heutige Multicore-Prozessoren gemeinsam einen Bus zur Kommunikation mit dem Hauptspeicher und der Peripherie. Speziell wenn verschiedene Betriebssysteme auf den Cores laufen sollen, ist das konfliktfreie Management der gemeinsamen Ressourcen also bereits die erste Herausforderung.

Die beiden unterschiedlichen Betriebsmodi bei Multicore

Es gibt zwei unterschiedliche Betriebsarten für Multicore-Systeme. Beim symmetrischen Multiprocessing, kurz SMP, kontrolliert ein Betriebssystem alle Cores. Beim asymmetrischen Multiprocessing, kurz AMP, läuft hingegen auf jedem Core eine eigene Betriebssysteminstanz. Hier unterscheidet man noch in homogenes AMP, wenn auf allen Cores das gleiche Betriebssystem läuft oder in heterogenes AMP, wenn auf jedem Core ein anderes Betriebssystem installiert ist.

Der AMP-Modus bietet sich an, wenn die Applikation bereits, ähnlich wie bei einem Multiprozessorsystem, partitioniert ist oder leicht partitioniert werden kann. Auch sollte der Datenaustausch zwischen beiden Partitionen gering und gut definiert sein.

Allerdings benötigt ein System im AMP-Betrieb mehr Speicher. Auch ist das Aufsetzen der Kommunikation zwischen den Cores schwieriger, besonders wenn unterschiedliche Betriebssysteme auf den Cores zum Einsatz kommen.

Zugriff auf gemeinsame Hardware-Ressourcen

Im SMP-Modus ist der Zugriff auf gemeinsame Ressourcen wie Bus und Speicher vereinheitlicht. Aus Entwicklerperspektive setzt die Applikation nur auf einem Betriebssystem auf, welches die Aufgaben gleichmäßig auf die Cores verteilt, man spricht von Dynamic Load Balancing. Daten können relativ einfach und schnell zwischen den Cores ausgetauscht werden. Allerdings muss das Betriebssystem die Cores verwalten und synchronisieren. Das hat wiederum Auswirkungen auf die Verarbeitungsgeschwindigkeit des Betriebssystems.

Multicore-Programmierung erfordert von den Programmierern darüber hinaus eine neue Herangehensweise. Programme müssen parallelisiert werden, damit die Ausführung sinnvoll von den Kernen geteilt werden kann. Ein objektorientierter Entwicklungsansatz kann hier helfen, da hier die parallele Vorgehensweise bereits im Konzept verankert ist.

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 den Austausch von Nachrichten.

Die standardisierte Modellierungssprache Unified Modeling Language, auch als UML bekannt, beschreibt grafisch das zu realisierende Softwaresystem über verschiedene Diagrammformen in jeder Phase der Softwareentwicklung.

Zustandsautomaten und Aktivitätsdiagramme

Bild 1: Parallelität ist integraler Bestandteil der UML und wird von verschiedenen Diagrammen unterstützt, so auch von diesem Zustandsdiagramm

Beispielsweise können die Entwickler die dynamischen Systemeigenschaften beschreiben, indem sie mit Struktur- und Klassendiagrammen die statische Systemarchitektur zusammen mit den Zustandsautomaten und Aktivitätsdiagrammen verwenden. 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.

In der Praxis gibt es jedoch oft eine Diskrepanz zwischen dem eigentlichen objektorientierten Entwurf des Systems und seiner Umsetzung im ausführbaren Code, weil die Implementierung paralleler Aktivitäten zu höherem Aufwand für den Austausch von Nachrichten und die Synchronisation führen kann.