{"id":7757,"date":"2025-11-29T05:27:25","date_gmt":"2025-11-29T04:27:25","guid":{"rendered":"https:\/\/web-dev-weissblau.de\/microconsult\/?p=7757"},"modified":"2026-02-14T08:17:51","modified_gmt":"2026-02-14T07:17:51","slug":"software-development-for-multicore-systems","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/software-entwicklung-fuer-multicore-systeme\/","title":{"rendered":"Software development for multicore systems"},"content":{"rendered":"

Was gibt es Neues, und wo geht die Reise hin?<\/h2>\n

Autor: Andr\u00e9 Schmitz, Green Hills Software<\/p>\n

Beitrag – Embedded Software Engineering Kongress 2018<\/h3>\n

Viele Embedded Systeme verwenden bereits heute Multicore-Prozessoren, und dieser Anteil steigt stetig. Die Entwicklung und Software-Migration auf diese Architekturen wird immer leichter, und es gibt bereits sehr ausgereifte Technolo\u00adgien zur Entwicklung von Software f\u00fcr Multicore-Systeme. Dieser Beitrag wirft einen Blick auf die Technologien im Bereich Code-Generierung, Echtzeit\u00adbetriebssysteme und Debugging, die die Entwicklung von Multicore-Software erleichtern. Au\u00dferdem wird ein Blick in die Zukunft gewagt und gefragt, wie diese Technologien mit der zu erwartenden steigenden Anzahl von Cores skalieren.<\/strong><\/p>\n

Warum Multicore?<\/h2>\n

Es gibt verschiedene Gr\u00fcnde f\u00fcr den Umstieg auf Multicore-Systeme. Meist ist das Ziel, mithilfe einer Multicore-CPU eine h\u00f6here Performance zu erreichen, eine Performance, die man in vergleichbarer Weise nicht durch Erh\u00f6hung der Taktrate eines Cores erreichen k\u00f6nnte. Denn im Vergleich zu einem hoch getakteten Singlecore-System braucht zum Beispiel ein heruntergetaktetes Dualcore-System deutlich weniger Strom und bietet dabei aber mehr Rechenleistung. Ein weiterer Grund f\u00fcr den Einsatz von Multicore k\u00f6nnte der Wunsch sein, mehrere Betriebssysteme auf einer CPU laufen zu lassen. Auf einem Dual-Core k\u00f6nnte ein Core mit Linux und ein Core mit einem RTOS laufen. Heutzutage spricht man in diesem Zusammenhang oft von Virtualisierung, fr\u00fcher wurde hier auch von „Asymmetric Multicore Processing“ (AMP) gesprochen (siehe unten).<\/p>\n

Es gibt auch Anwendungsf\u00e4lle, in denen Multicore zur Erreichung von Funktionaler Sicherheit eingesetzt wird. Eine typische Konfiguration ist das Lockstep-Prinzip, bei dem zwei \u00e4hnliche Cores die gleichen Algorithmen ausf\u00fchren und am Ende gepr\u00fcft wird, ob das Ergebnis beider Berechnungen identisch ist [1]. Dies erh\u00f6ht die Hardware-Fehlertoleranz. Manchmal wird auch versucht, zwei Software-Komponenten auf verschiedenen Cores laufen zu lassen und argumentiert dann, dass diese dadurch wechselwirkungsfrei liefen. Dies ist nat\u00fcrlich nur dann der Fall, wenn diese Cores keine gemeinsam genutzten Ressourcen haben (Caches, Bus etc.), was in den meisten Multicore-Hardwaresystemen aber nicht der Fall ist (siehe locker vs. eng gekoppelte Systeme weiter unten).<\/p>\n

Multicore-Hardware<\/h2>\n

In der Regel kann zwischen heterogenen Systemen mit unterschiedlichen Cores und homogenen Systemen mit gleichen Cores unterschieden werden. Heterogene Systeme werden vorwiegend f\u00fcr in sich asymmetrische Aufgaben verwendet, bei denen zum Beispiel ein General Purpose Prozessor (z.B. ARM) die Benutzerschnittstelle und die Steuerung des Systems \u00fcbernimmt, w\u00e4hrend ein Rechenprozessor (z.B. DSP oder NPU) die effiziente und schnelle Datenverarbeitung und Ein-\/Ausgabe sicherstellt. Gerne wird dabei der Zugriff auf bestimmte Peripherie nur einzelnen Cores gew\u00e4hrt. Bei heterogenen Systemen liegt also der Vorteil in der zweckgebundenen Leistungsf\u00e4higkeit der Cores. Homogene Systeme hingegen bieten eine elegante und energiesparende L\u00f6sung zur Vergr\u00f6\u00dferung der Rechenleistung eines Systems.<\/p>\n

Betrachtet man die Anbindung der Cores an den Speicher, so unterscheidet man hier zwischen eng gekoppelten Systemen, bei denen alle Cores auf den gleichen Speicherzugriff haben, und locker gekoppelten Systemen, bei denen jeder Core seinen eigenen Speicher hat. Bei Letzteren findet die Kommunikation in der Regel nicht direkt \u00fcber „Shared Memory“, sondern \u00fcber andere Kan\u00e4le statt. Bei eng gekoppelten Systemen skaliert wiederum die Leistung nicht proportional mit der Anzahl der Prozessoren, da der Bus hier meist zu einem Engpass wird und die Cache-Koh\u00e4renz sichergestellt werden muss.<\/p>\n

Dieser Performance-Engpass kann mithilfe spezieller Hardwarearchitekturen verbessert werden. Eine m\u00f6gliche Architektur ist die Non-Uniform Memory Architecture (NUMA), bei der jeder Core lokalen, schnellen Speicher hat, dessen Zugriffe nicht durch Bus-Arbitrierung gebremst werden. Der Zugriff auf den Speicher der anderen Cores ist \u00fcber eine High-Speed Verbindung realisiert, die zwar Cache-koh\u00e4rent ist, jedoch deutlich langsamer als der Zugriff auf den lokalen Speicher.<\/p>\n

Programmierung von Multicore-Systemen<\/h2>\n

Bei der Softwareentwicklung f\u00fcr Multicore-Systeme ist es erforderlich, die zu erledigenden Aufgaben sinnvoll auf die Cores zu verteilen. Bei heterogenen Systemen ist diese Verteilung deutlich offensichtlicher und muss vom Entwickler manuell vorgenommen werden. Die Programmierung dieser Systeme ist aber eher aufw\u00e4ndig, da man oft unterschiedliche Tools (Compiler und Debugger) f\u00fcr die unterschiedlichen Cores ben\u00f6tigt und die Interprozessor-Kommunikation in der Regel Hardware spezifisch realisiert werden muss. Falls Betriebssysteme zum Einsatz kommen, sind diese meist auf den beteiligten Cores unterschiedlich, was einen weiteren Schwierigkeitsgrad hinzuf\u00fcgt, wenn es um die Interoperabilit\u00e4t geht.<\/p>\n

Betriebssystem-L\u00f6sungen<\/h2>\n

Bei homogenen Multicore-Systemen findet man meist zwei unterschiedliche Ans\u00e4tze, die Aufgaben auf die Cores zu verteilen (AMP und SMP), welche nachfolgend beschrieben werden.<\/p>\n

AMP<\/h3>\n

Schaut man sich die Fachliteratur an, so findet man teilweise ganz unterschiedliche Auffassungen davon, was Asymmetrisches Multi-Processing (AMP) wirklich bedeutet. Manche verwenden den Begriff AMP f\u00fcr heterogene Hardware-Architekturen, in denen nicht alle Cores Zugriff auf die gleichen Ressourcen haben [2]. Andere betrachten es als reine Software-\u00dcberlegung bei homogenen Hardware Architekturen [3]. Ich verwende AMP hier jetzt nur immer als Software-Aspekt auf ansonsten homogener Multicore-Hardware. Letztlich entscheidet aber bei allen Formen von AMP der Entwickler \u00fcber die Partitio\u00adnierung und Aufteilung der Funktionen zwischen den Cores. Auf jedem Core l\u00e4uft eine eigenst\u00e4ndige und unabh\u00e4ngige Software, die mit oder ohne Betriebssystem realisiert sein kann. Falls Betriebssysteme verwendet werden, m\u00fcssen diese nicht notwendigerweise auf allen Cores identisch sein. Letzteres wird heute auch gerne Virtualisierung genannt, wenngleich man unter Virtualisierung wiederum auch etwas ganz anderes verstehen kann.<\/p>\n

Ein AMP-Software-Ansatz kann hilfreich sein, wenn man f\u00fcr bestimmte Aufgaben Rechenzeit garantieren m\u00f6chte, wenngleich diese Garantien aufgrund der unter Umst\u00e4nden geteilten Ressourcen nicht wirklich gegeben sind. Leider sind Anwendungen auf AMP-Systemen aber meist weniger portabel und es besteht keine M\u00f6glichkeit zur Laufzeit eine dynamische Lastverteilung zu erreichen. \u00c4hnlich wie bei heterogenen Systemen ben\u00f6tigt man auch hier einen fehlertoleranten Nachrichten\u00adaustausch zwischen den Cores.<\/p>\n

SMP<\/h3>\n

Symmetrisches Multi-Processing (SMP) ist nur m\u00f6glich auf homogenen, eng gekoppelten Systemen unter Verwendung eines SMP-f\u00e4higen Betriebssystems (OS). Eine Instanz des Betriebssystems l\u00e4uft auf allen Cores und \u00fcbernimmt die Aufgabe der Verteilung von Threads auf die Cores. Dadurch ist es prinzipiell m\u00f6glich, eine existierende Multithreaded-Anwendung, die bisher auf einem Singe-Core l\u00e4uft, aber bereits auf einem SMP-f\u00e4higen OS implementiert wurde, ohne weiteres mit deutlichem Performancegewinn auf einem Multicore-System auszuf\u00fchren. Das OS verteilt Threads automatisch zwischen den Cores, und alle Ressourcen und internen Abl\u00e4ufe werden transparent vom OS \u00fcberwacht [4]. Nat\u00fcrlich gibt es hier einige Fallstricke, die es zu beachten gibt.<\/p>\n

Als weitere St\u00e4rke von SMP-Systemen z\u00e4hlt die Teilung von Ressourcen. Diese erm\u00f6glicht ein hohes Ma\u00df an Flexibilit\u00e4t, kann aber durch die echte Nebenl\u00e4ufigkeit von Threads auch zum Problem der Ressourcen-Konkurrenz f\u00fchren. In SMP-Systemen k\u00f6nnen Threads mit unterschiedlicher Priorit\u00e4t echt gleichzeitig ausgef\u00fchrt werden. Ist also jemand bei der Entwicklung der Singlecore-Anwendung bisher davon ausgegangen, dass ein niedrig priorisierter Thread nur dann laufen kann, wenn kein h\u00f6her priorisierter l\u00e4uft, dann k\u00f6nnte er bei einem SMP-System pl\u00f6tzlich \u00dcberraschungen erleben. Es ist ratsam, ein SMP-OS mit Memory Management Unit (MMU)-Unterst\u00fctzung zu nutzen, um damit die Granulierung der Software direkt auf Prozess-Ebene realisieren zu k\u00f6nnen und nicht auf Thread-Ebene. Damit werden \u00e4rgerliche Fehler vermieden, die beim Multithreading gerne auftreten. Man verwendet dann die MMU zur Isolation vom OS-Komponenten und definiert saubere Schnittstellen zwischen den Komponenten.<\/p>\n

M\u00f6chte man Echtzeit-Verhalten realisieren, bedarf es auch auf dem Multicore-System eines Echtzeitbetriebssystems (RTOS). Dieses sollte sinnvollerweise eine kleine, deterministische Interrupt-Latenz haben und den Determinismus einer Applikation beim Umstieg auf Multicore beibehalten. Neben dem Determinismus sollte das OS auch gut skalieren, wenn weitere Cores hinzugef\u00fcgt werden. Diese beiden Eigenschaften h\u00e4ngen meist von der Art der Kernel-Parallelisierung ab, also welche Art von „Locks“ zum Schutz der kritischen Bereiche des Kernels implementiert sind. Es gibt hier sehr gut skalierende Ans\u00e4tze, wie zum Beispiel die des Linux-Kernels, die aber vergleichsweise undeterministisch sind. Die bessere Echtzeitf\u00e4higkeit und Zuverl\u00e4ssigkeit eines RTOSs wird hingegen manchmal auf Kosten der Skalierbarkeit erreicht.
\n<\/strong><\/p>\n

Scheduling und Core-Affinit\u00e4t<\/h2>\n

Nicht zuletzt wird, wie bereits erw\u00e4hnt, mit steigender Zahl der Cores der Speicher-Bus zum Flaschenhals. Um wenigstens die Caches der Cores effektiv zu nutzen, macht es Sinn, die Threads an bestimmte Cores zu binden (Affinit\u00e4t). Hier kann man z.B. \u00fcber Betriebssystemaufrufe Threads statisch an Cores binden (benutzerdefinierte Affinit\u00e4t). Dies reduziert zwar die Flexibilit\u00e4t der Lastverteilung zur Laufzeit, kann aber zum Beispiel bei der Verarbeitung von Interrupts helfen, indem der vom Interrupt aufgeweckte Thread auf den Core gelegt wird, der auch den Interrupt behandelt. In diesem Fall wird zum einen die Performance durch eine effizientere Nutzung des Caches verbessert, zum anderen kann auf einen Inter-Prozessor-Interrupt (IPI) verzichtet werden.<\/p>\n

Ein SMP-OS kann dar\u00fcber hinaus versuchen, Threads automatisch immer auf dem gleichen Core auszuf\u00fchren, falls das m\u00f6glich ist („Nat\u00fcrliche Affinit\u00e4t“). Hierbei wird bei Beibehaltung der Flexibilit\u00e4t und der Priorit\u00e4tsgarantien zur Laufzeit die Cachenutzung verbessert und damit die Performance erh\u00f6ht. Letztlich kann man mit der Core-Affinit\u00e4t ein SMP-System zum Teil in die Richtung Software-AMP konfigurieren, und das kann man dann als Bound Multicore Processing (BMP) bezeichnen.<\/p>\n

Automatische Parallelisierung<\/h2>\n

Es gibt dar\u00fcber hinaus auch Ans\u00e4tze zur automatisierten Parallelisierung von Code mithilfe von Bibliotheken. In diesem Bereich hat sich in den letzten Jahren einiges getan. Diese sind zwar meist einfach zu nutzen und skalieren gut, gehen aber alle mit gewissen Einschr\u00e4nkungen einher. Einige funktionieren nur sinnvoll auf gro\u00dfen Schleifen (z.B. bei Verwendung von OpenMP) oder erfordern ein explizites Design mit Hilfe von C++ Klassen (Parallelization objects) [5]. Nat\u00fcrlich helfen auch die neueren C++ Versionen (C++11 und neuer), um Threading auf SMP zu realisieren. Es gibt mehr und mehr Tools, die helfen sollen, existierenden, seriellen Code vollst\u00e4ndig automatisch zu parallelisieren. F\u00fcr Sprachen wie Fortran scheint das ganz gut zu funktionieren, weil Fortran strengere Garantien bzgl. Speicher \u00dcberlappung (Aliasing) aufweist als die Sprachen C oder C++. Letztere erlauben indirekte Adressierung, Rekursionen und viele andere dynamische Aspekte, die es einem Parallelisierungstool schwer machen, vollkommen automatisch zu parallelisieren. Die existierenden L\u00f6sungen am Markt erfordernd meist eine Unterst\u00fctzung des Entwicklers oder k\u00f6nnen eben nur ganz bestimmte Aspekte eines Programmes parallelisieren, wie die besagten Schleifen [6].<\/p>\n

Speichermodelle<\/h2>\n

Das Verhalten von Speicherzugriffen auf Multicore-Systemen muss auch im speziellen betrachtet werden. Neben der offensichtlichen Notwendigkeit zum Schutz geteilter Ressourcen vor nebenl\u00e4ufigem Zugriff (Thread Safety), z.B. mithilfe von Atomaren Operationen oder Mutexen, muss man insbesondere beachten, wie sich der Zugriff auf Speicher von verschiedenen Cores zueinander verh\u00e4lt. Die Reihenfolge, in der ein Core auf Speicher schreibt, kann v\u00f6llig anders sein als die Reihenfolge, in der ein anderer Core diese Zugriffe im Speicher sieht. Hier geht es nicht um das m\u00f6glicherweise stattfindende Umsortieren von Instruktionen eines Compilers zur Optimierung der Ausf\u00fchrungsgeschwindigkeit, sondern es geht um die Optimierung der Hardware beim Zugriff auf den Speicher. Um Probleme aufgrund dieses Umsortierens zu vermeiden, bieten die Instruktionssatz-Architekturen spezielle Barrier-Instruktionen an, die es erlauben, verschiedene Arten von Speicherzugriffen vor der Barrier garantiert auszuf\u00fchren zu lassen, bevor andere Arten von Speicherzugriffen nach der Barrier stattfinden. Auch hier gibt es dann auch wieder Unterst\u00fctzung von den neuen C++ Varianten. Der Software Entwickler sollte also auf jeden Fall die Probleme im Zusammenhang mit Speichermodellen kennen. [7]<\/p>\n

Entwicklungswerkzeuge<\/h2>\n

Eine weitere Herausforderung in Umgang mit Multicore-Systemen ist die Vermeidung von Softwarefehlern, die Suche nach den nicht vermeidbaren Fehlern und die Optimierung des Codes. Aus meiner Sicht ist die Suche nach Softwarefehlern immer noch eine der gr\u00f6\u00dften Herausforderungen w\u00e4hrend der Softwareentwicklung. Ein Multicore-System macht die Sache dann aufgrund der h\u00f6heren Komplexit\u00e4t nicht wirklich einfacher. Umso mehr ist hier also ein strukturierter Entwicklungsprozess wichtig, der hilft, Fehler von vornherein zu vermeiden oder so einfach und fr\u00fch wie m\u00f6glich zu finden. Bereits bei Singlecore-Systemen kennt man die Probleme beim Umgang mit virtueller Nebenl\u00e4ufigkeit (z.B. Race Conditions), und diese werden nicht einfacher, wenn man mit echter Nebenl\u00e4ufigkeit zu tun hat. Daher ist es essentiell, die passenden Entwicklungswerkzeuge zu haben, die die Softwareentwicklung f\u00fcr Multicore-Systeme effizient unterst\u00fctzen.<\/p>\n

F\u00fcr die Treiber-Entwicklung sind zum Beispiel solche Hilfsmittel optimal, die eine synchrone Laufzeitsteuerung (Stop-Mode) aller Cores des Systems erm\u00f6glichen, um mehrere Cores gleichzeitig zu starten und anzuhalten. Falls ein Betriebssystem verwendet wird, ist dar\u00fcber hinaus die M\u00f6glichkeit zum Anwendungs-Debugging (Run-Mode) n\u00fctzlich, bei dem auf Thread-Level zur Laufzeit Programmfehler gesucht werden k\u00f6nnen, ohne den Rest des Systems anhalten zu m\u00fcssen. Zum besseren Verst\u00e4ndnis des Laufzeitverhaltens der nebenl\u00e4ufigen Prozesse ist ein Werkzeug zur Analyse der Betriebssystem-Events sowohl bei AMP- als auch bei SMP-Systemen unerl\u00e4sslich. Soll eine nicht-intrusive Analyse des Programmablaufes durchgef\u00fchrt werden, die eine einfache M\u00f6glichkeit zur Suche von versteckten oder schwer reproduzierbaren Softwarefehlern bietet, sind Werkzeuge zur Multicore-Trace-Erfassung und Trace-Analyse n\u00f6tig [6]. Optimal ist es nat\u00fcrlich, Fehler automatisiert zu finden. Dies erreicht man entweder durch statische Source-Codeanalyse oder beim Ausf\u00fchren des Programms durch automatische Laufzeit-Fehlersuche.<\/p>\n

Ausblick<\/h2>\n

Der Trend zu mehr Multicore, speziell im Embedded Bereich, wird sicherlich weitergehen, alleine um die Gier nach Performance bei gleichzeitig geringer Leistungsaufnahme stillen zu k\u00f6nnen, und wir m\u00fcssen uns \u00fcberlegen, wie wir die damit verbundenen Heraus\u00adforderungen meistern werden. Bzgl.\u00a0 Hardware wird es vermutlich vorwiegend Weiterentwicklungen in drei Richtungen geben<\/p>\n