Software-Parallelisierung für Multicore-Prozessoren, Teil 1: Race Conditions

Anbieter zum Thema

emmtrix Technologies

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Race Conditions treten auf, wenn Ergebnisse von Berechnungen oder Operationen von der Fertigstellung anderer Operationen abhängen. Was Softwareentwickler darüber wissen sollten, zeigt dieser erste Beitrag einer dreiteiligen Multicore-Serie.

Bereits seit Jahren geht der Trend bei der Weiterentwicklung von eingebetteten Systemen dahin, dass Prozessoren immer weitere Kerne und sogar Beschleuniger für bestimmte Berechnungen bekommen, um sowohl die Performanz als auch die Leistungsaufnahme zu verbessern. Beispielhaft soll die Infineon-AURIX-Prozessor-Serie erwähnt werden. Hatte die erste Generation noch bis zu drei Kerne, ging die zweite Generation auf sechs Kerne über und die kommende Generation wird einen digitalen Signalprozessor zur Beschleunigung von Vektoroperationen mitbringen.

Der Einsatz dieser modernen Prozessoren erlaubt es, rechenintensive Anwendungen wie neuronale Netze, Datenverarbeitung oder komplexe Steuerungen zu realisieren. Die Programmierung dieser parallelen Architekturen bringt jedoch einige Herausforderungen mit sich, die bei der rein sequentiellen Programmierung nicht auftreten. Innerhalb dieser dreiteiligen Artikelserie sollen nun die größten Fallstricke bei der Parallelisierung vorgestellt werden und wie sie bei der Entwicklung umgangen werden können.

Der richtige Umgang mit Race Conditions

Den Anfang machen in diesem Artikel die so genannten „Race Conditions“, zu Deutsch „Wettlauf-Situationen“. Sie treten auf, wenn das Ergebnis einer Berechnung oder Operation von der Fertigstellung einer anderen Operation abhängt. Häufig entstehen sie im Zusammenspiel mit gemeinsam genutzten Ressourcen wie Speicher.

Als Beispiel kann die Operation in der gezeigten Tabelle genommen werden. Die angedachte Operation ist das Erhöhen einer gemeinsam genutzten Variablen von zwei Kernen aus. Dazu führt jeder Prozessor die drei Einzelschritte „lesen“, „addieren“ und „schreiben“ aus. Hat die Variable zu Beginn den Wert 0, wird sie von Kern 1 auf 1 erhöht und anschließend von Kern 2 auf 2 erhöht.

Bei paralleler Ausführung kann es passieren, dass die Befehle der beiden Kerne überlappend ausgeführt werden. Kern 2 liest beispielsweise nur leicht versetzt mit dem ersten Kern die gemeinsame Variable. Da Kern 1 den Wert noch nicht erhöht hat, liest auch Kern 2 den Anfangswert von 0, beide Kerne erhöhen die Variable um 1 und schreiben ihr jeweiliges Ergebnis zurück.

Da Kern 2 nicht die Änderung durch Kern 1 betrachtet hat, wird der Wert am Ende nur um eins erhöht und das falsche Ergebnis steht in der Variablen. Auch wenn der Fall auf den ersten Blick sehr trivial erscheint, wird er in ähnlicher Form häufig als einfache Möglichkeit zur Synchronisation von Zugriffen auf gemeinsam genutzte Ressourcen verwendet.

Wird dabei nicht beachtet, dass die Operation aus mehreren Einzelschritten bestehen kann und deshalb über mehrere Taktzyklen hinweg abgearbeitet wird, kann sie demnach durch eine parallele Verarbeitung eines anderen Kerns verfälscht werden. Das Verhalten der Anwendung wird dadurch unvorhersehbar.

Bei mehreren Ausführungen kann es von geringsten kleinen zeitlichen Schwankungen, die z.B. durch das Betriebssystem erzeugt werden, abhängen, ob das Programm korrekt arbeitet oder nicht. Aufgrund der deutlich aufwendigeren Reproduzierbarkeit des Fehlers und der damit einhergehenden zeitraubenden Fehlersuche, wird eine nachträgliche Fehlerbehebung sehr kostspielig.

Wie kann dieses Verhalten nun verhindert werden? Die parallele Ausführung muss klar synchronisiert werden, wobei auf die Verwendung so genannter „atomic instructions“ geachtet werden sollte. Dies sind Instruktionen, die während ihrer Abarbeitung nicht unterbrochen werden können und dabei exklusiven Zugriff auf den Speicher haben. Auf diese Weise wird verhindert, dass ein anderer Kern parallel Daten verändert und die tatsächliche Abarbeitungsreihenfolge Einfluss auf das Ergebnis der Operation hat.

Auf diese Art umgesetzte Synchronisation sorgt dafür, dass nur noch klar definierte Teile von Anwendungen parallel ausgeführt werden und dass problematische, gleichzeitige Zugriffe nicht durchgeführt werden. Es gilt aber zu beachten, dass die Verwendung der passenden Funktionen noch nicht ausreicht, sondern der korrekte Einsatz ebenfalls sichergestellt sein muss. Dies sollte am besten direkt der Dokumentation der API entnommen werden. Eine solche Vorgehensweise muss lückenlos und systematisch sein und kann bei komplexen Anforderungen zu erheblichem Kostenmehraufwand führen.

Software-Werkzeuge wie beispielsweise „emmtrix Parallel Studio“ unterstützen den Entwickler bei der korrekten Synchronisation, indem sie programmatisch die Synchronisationspunkte in Anwendungen ermitteln und entsprechende Instruktionen so einfügen, dass Race Conditions gar nicht entstehen können. Erst durch den Einsatz einer solchen weitestgehend automatisierten Lösung mit einem „correct-by-design“, also inhärent fehlerfreien Ansatz, ist eine komplexe Verteilung der Anwendung auf die einzelnen Kerne technisch machbar und wirtschaftlich durchführbar.

Teil 2 dieser Multicore-Artikelserie beschäftigt sich mit den so genannten Deadlocks. Im dritten und letzten Teil der Serie wird die Performanz-Aschätzung von parallelen Anwendungen behandeln.

Software-Parallelisierung für Multicore-Prozessoren, Teil 2: Deadlocks

Multicore: Automatische Parallelisierung eines modellbasierten Designs

Software für Multicore-Systeme entwickeln

* Oliver Oey ist Senior Engineer und Mitbegründer der emmtrix Technologies GmbH in Karlsruhe.

(ID:46399294)