Software für Multicore-Systeme entwickeln

| Autor / Redakteur: Frank Braun und Renate Stücka * / Hendrik Härter

Multiprozess- und Multicore-Systeme: Dank der parallelen Verarbeitung lassen sich komplexe Aufgaben schneller erledigen
Multiprozess- und Multicore-Systeme: Dank der parallelen Verarbeitung lassen sich komplexe Aufgaben schneller erledigen (Bild: Clipdealer)

Multiprozess-Applikationen haben kürzere Reaktionszeiten und bewä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
Bild 1: Parallelität ist integraler Bestandteil der UML und wird von verschiedenen Diagrammen unterstützt, so auch von diesem Zustandsdiagramm (Bild: IBM)

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.

Entwickler, die moderne UML-Werkzeuge einsetzen, die aus den grafischen UML-Modellen Codes generieren und die Kommunikationsmechanismen frei Haus und transparent implementieren, sind hier im Vorteil. IBM Rational Rhapsody gehört zu dieser Kategorie von Tools.

Ein Service Layer, der auf dem Betriebssystem aufsetzt (Bild 1), stellt die für parallele Ausführung erforderlichen Mechanismen zur Verfügung, und der Entwickler kann sich auf den eigentlichen Entwurf, das Verhalten der Objekte und die Kommunikation zwischen den Objekten konzentrieren. Das Tool übernimmt Routinearbeiten und die Implementierung der Basisdienste.

Applikationscode auf der UML-Ebene

Bild 2: Visuelles Debuggen auf UML-Ebene. Laufzeitverhalten wie Objektverhalten und Objektkommunikation sind über animierte Sequence-Diagramme und Zustandsautomat nachvollziehbar.
Bild 2: Visuelles Debuggen auf UML-Ebene. Laufzeitverhalten wie Objektverhalten und Objektkommunikation sind über animierte Sequence-Diagramme und Zustandsautomat nachvollziehbar. (Bild: IBM)

Das Laufzeitverhalten der Applikation kann grafisch auf UML-Ebene nachverfolgt und gesteuert werden. Hierbei handelt es sich nicht etwa um eine Simulation, sondern um den tatsächlichen, sozusagen auf UML-Ebene visualisierten, Code der Applikation.

Dieses „grafische Debuggen“ der Applikation ist auch auf einer Target-Plattform möglich. Alle Aspekte wie Verhalten der Zustandsautomaten, Aktivitätendiagramme, Objektinteraktion anhand von Sequenzdiagrammen, Lebenszyklus der Objekte, Variablenbelegung in Rhapsody einsehbar, während die Applikation ausgeführt wird. Der Entwickler kann das Systemverhalten auf der grafischen Modellebene validieren und dann auch testen. Die Herangehensweise hat noch einen weiteren Vorteil: Man kann bereits zu einem frühen Zeitpunkt Prototypen erzeugen.

Dank eines Operating System Abstraction Layers, kurz OSAL, der das darunterliegende Betriebssystem abstrahiert, kann die Applikation per Mausklick für verschiedene Betriebssysteme übersetzt werden. Die nötigen OSAL-Adapter für die gängigsten Embedded Betriebssysteme auf dem Markt sind im Lieferumfang von Rhapsody enthalten.

In der Multicore-Entwicklung bietet dieses Rapid-Prototyping eine elegante Möglichkeit, die Konfigurationsfragen frühzeitig zu beantworten. Dabei lassen sich folgenden Frage stellen: Nutze ich SMP, AMP? Ist eine homogene oder heterogene Betriebssystemstruktur besser geeignet? Wie partitioniere ich meine Applikation hinsichtlich einer effizienten Kommunikation zwischen den Cores? Ist die Applikation performanter, 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 werden benötigt?

Mehr Prozessorleistung bei gleichem Energieverbrauch

Bild 3: RapidPrototype-Unterstützung dank Service Layer und OSAL - Das Service Layer realisiert Basisdienste wie beispielsweise Objektkommunikation, das OSAL abstrahiert das darunterliegende Betriebssystem.
Bild 3: RapidPrototype-Unterstützung dank Service Layer und OSAL - Das Service Layer realisiert Basisdienste wie beispielsweise Objektkommunikation, das OSAL abstrahiert das darunterliegende Betriebssystem. (Bild: IBM)

Das frühe 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. Aber auch für den eigentlichen Entwicklungsprozess ist Rapid Prototyping hilfreich: So ist beispielsweise das Debuggen eines Systems in einer heterogenen AMP-Umgebung sehr komplex, da sich Systemanforderungen auch noch während der Entwicklung ändern können.

Durch Multicore-Technologie kann man die Leistungsfähigkeit von Prozessoren bei unverändertem Energieverbrauch steigern oder den Energieverbrauch ohne Leistungseinbußen senken. Das lässt sich aber nur verwirklichen, wenn die Applikationen so ausgelegt sind, dass die Vorteile tatsächlich auch nutzbar gemacht werden. Dies wiederum erfordert eine völlig neue Sichtweise auf den Systementwurf: Neben den vielfältigen, neuen Konfigurationsmöglichkeiten, die Multicore bietet, müssen sich die Entwickler auch primär die Frage stellen, welche Aufgaben parallel bearbeitet werden können und wo es Synchronisationspunkte zwischen den verschiedenen Bearbeitungspfaden gibt.

Ergänzendes zum Thema
 
Mehr Leistung bei weniger Energie

Applikationen gezielt für Multicore-Systeme entwickeln

Objektorientierte Entwicklung mit Hilfe von UML-Modellen und Werkzeugen wie IBM Rational Rhapsody helfen die inhärente Parallelität der UML-Modelle in tatsächlich parallel ausführbare und plattformunabhängige Programme zu transformieren.

Sie versetzen Entwickler dadurch in die Lage, Applikationen gezielt für Multicore-Systeme zu entwickeln oder zu optimieren. So lässt sich der theoretische Vorteil der Multicore-Technologie im Bereich der Embedded-Systeme wirtschaftlich sinnvoll in die Realität umsetzen.

* * Frank Braun ist Rhapsody Program Manager bei IBM Rational und Renate Stücka ist Senior Market Manager Rational der IBM Software Group in München.

Kommentar zu diesem Artikel abgeben
OSAL (Operating System Abstraction Layer) ist ein Design Pattern und abstrahiert das...  lesen
posted am 11.05.2011 um 23:06 von Unregistriert

OSAL: gibt es das bereits am markt zu kaufen. -> gibt es mehr information dazu.  lesen
posted am 28.04.2011 um 08:02 von Cmathis


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 26658110 / Mikrocontroller & Prozessoren)