Im Zuge meiner kleinen Serie zu den häufigsten Code-Pannen der Parallel-Programmierer habe ich bereits über Deadlocks und Livelocks geschrieben. Jetzt geht es um Data Races – ein sehr häufiges Programmierproblem, das zwar auch Programmhänger oder –abstürze verursacht, vor allem aber zu falschen Berechnungen führen kann, wodurch die eigene App dann im Zuge bestimmter Prozesse unberechenbar reagiert.
Aber der Reihe nach: Data Races (auch: “Dataraces”) gehören zur Klasse der Race Conditions. Der Begriff „race“ deutet bereits an, dass es sich hierbei um einen Wettlauf handelt: Eine Gesamtprozess soll das Endergebnis zweier oder mehrerer Teilprozesse darstellen, wobei die Teilprozesse aufeinander aufbauen, fälschlicherweise aber parallel gestartet werden und somit zu einem falschen Resultat führen.
Eine kleine Analogie, die das verdeutlicht: Bei einem Staffellauf übergibt Läufer 1 das Hölzchen an Läufer 2 und so fort. So ergibt sich eine funktionale Kette, wobei ein Läufer erst dann starten darf, wenn er den Stab vom heraneilenden Partner erhalten hat. Diese funktionale Kette würde unterbrochen, wenn Läufer 2 nicht wartet, sondern sich ein eigenes Hölzchen schnappt und – warum auch immer – vor dem vereinbarten Kommando losläuft. Dann würde Läufer 3 von 2 Teamkollegen und 2 Hölzern bedient. Das führt in der Leichtathletik zur Disqualifikation.
Nun etwas technischer: Bei Data Races beschreibt beispielsweise ein Thread einen Speicherbereich, während ein zweiter Thread auf einen überlappenden Bereich zugreift. Bislang war die Analyse dieser Fehler sehr aufwändig, weil die Auswirkungen nicht immer sofort sichtbar sind oder keine klaren Rückschlüsse auf einzelne Code-Phrasen zulassen.
Ist die Ursache aber gefunden, lässt sich die Panne über eine neue Anordnung korrigieren: der erste Thread muss exklusiven Zugriff auf Ressourcen (etwa den Speicherbereich) erhalten und diesen Zugriff erst nach Abschluss seiner Aufgabe zugunsten des zweiten Threads lösen – also eine sequentielle Abfolge der Threads. Praktisch wird das meist über Semaphore erledigt. Semaphore sind Datenstrukturen, die – vereinfacht ausgedrückt – dazu dienen, bei der parallelen Ausführung die Threads in eine sinnvolle Reihenfolge zu bringen.
Das klingt kompliziert – und das ist es auch. Aber nur, wenn Sie auf den Einsatz des Intel Inspector XE 2011 verzichten. Der kümmert sich selbstständig um das Fixing. Zunächst aber prüft das Tool gewissenhaft die Threads und die Speicherbelegung. Dafür können Sie übrigens anhand der integrierten Tutorials vorgehen. Memoryleaks werden dabei sofort aufgespürt und im Quellcode lokalisiert. Das gilt auch für Data Races, die Sie in einem Zug gemeinsam mit Deadlocks ermitteln.
Wie einfach und hilfreich das mitunter in der Praxis ist, schildert dieses sehr gute Video mit Anwendungsbeispielen aus der Parallelprogrammierung:
