Detektieren und Behandeln von Nebenläufigkeitsfehlern

Zur Bereitstellung von Anwendungen umfangreicher Funktionalität verwenden Entwickler die Leistungsfähigkeit von Multi-Prozessor-Systemen. Dies erhöht die Komplexität der Anwendungen und stellt Entwickler vor neue Qualitäts- und Sicherheits-Aufgaben. Diese Aufgaben haben sie in einer möglichst frühen Projektphase zu verstehen und zu löen. CodeSecure stellt fortschrittliche Analysen zur Auffindung von Fehlern in nebenläufigen Systemen bereit.

Fortschrittliche Entwicklung auf Multi-Prozessor-Systemen

Durch Fehler im Quelltext verursachte Nebenläufigkeitsfehler sind aufgrund ihres Nicht-Determinismus in Testumgebungen schwer oder gar nicht aufzufinden. Mit CodeSonar® werden durch Nebenläufigkeit verursachte Fehler wie Deadlocks, Livelocks, Verhungern von Prozessen und asynchrone Datenzugriffe erkannt.
Entwickler, welche zuständig sind für die Erstellung von zuverlässigen, effizienten Anwendungen entscheiden sich für CodeSonar®, um Nebenläufigkeitsfehler schon in frühen Projektphasen auszuräumen und damit hohe Nacharbeitungskosten zu vermeiden.
CodeSonar® beherrscht verschiedene Szenarien des fehlerhaften Einsatzes von Nebenläufigkeitsbibliotheken und prüft diese. Deadlocks und asynchrone Datenzugriffe sind sehr zeitaufwendig und teuer zu beheben, wenn sie in der Entwicklungsphase nicht erkannt werden. Sie verursachen eine unverhältnismäßige Menge an nichtdeterministischen Fehlern in der Zielanwendung.

Der Vorteil von CodeSecure

Es ist undurchführbar, jede mögliche Interaktion und Konfiguration eines komplexen, produktiven Systems zu ermitteln und zu testen. Aus diesem Grund ist es ineffizient, manuell nach Nebenläufigkeitsfehler zu suchen. An dieser Stelle zeigt sich die Effizienz der CodeSonar®-Analyse zur Erkennung von Nebenläufigkeitsfehlern. CodeSonar® sucht nach Ursachen für nebenläufiges Fehlverhalten und nicht nach Symptomen. Es extrahiert ein abstraktes Model der nebenläufigen Threads und ihrer Eigenschaften. Abhängigkeiten zwischen den Threads wie Locks und gemeinsame Daten werden automatisch nach Strukturen durchsucht, welche anfällig für problematisches Verhalten sind.
Die Nebenläufigkeitsprüfungen für C/C++ von CodeSonar® wurden im Zuge eines Forschungsprojektes der DARPA Defense Advanced Research Projects Agency entwickelt und kommerzialisiert. Zusätzlich findet CodeSonar® Fehler in Signal-Handlern von Multi-Threaded-Software.
Nebenläufigkeitsprüfungen in Java erfolgen durch TheadSafe™. Dies ist der fortschrittlichste Detektor für Nebenläufigkeitsfehler in Java. Er erkennt Fehler, welche kein anderes Werkzeug findet.
Zudem detektiert TheadSafe™ unvorhersehbare Ergebnisse, welche durch die unsachgemäße Verwendung der Bibliotheken von java.util.concurrent verursacht werden, schlechte Fehlerbehandlungen und inkorrekte Synchronisationen beim Zugriff auf nicht threadsichere Datentypen. TheadSafe™ hilft auch dabei Leistungsengpässe zu diagnostizieren, welche durch unsachgemäße Verwendungen der Programmierschnittstelle, redundante Synchronisationen und die unnötige Verwendung von Shared-Mutable-States verursacht werden.

Überprüfungen von Multi-Threaded- und Multi-Prozessor-Code

CodeSonar® deckt komplexe Nebenläufigkeitsprobleme in Multi-Threaded- und Multi-Prozessor-Code auf.
Dabei werden folgende Fehler angezeigt:

1. Data Race
   Mehrere Threads greifen in einer unsicheren Weise auf gemeinsam genutzte Daten zu (weitere Infos).
2. Deadlock
   Zwei oder mehr Threads hindern sich gegenseitig weil Prozesse auf ein Ereignis warten, welches nur ein anderer Prozess verursachen kann (weitere Infos).
3. Falsche Verwendung von Synchronisationsmethoden
   Lock/unlock Mismatches, Try-locks welche nie gelingen, lange unvollständige Operationen in kritischen Regionen und viele andere Probleme.

Data Races und Deadlocks werden im Folgenden detaillierter beschrieben.

Aufdecken von Data Races

Data Races verursachen eine unverhältnismäßig hohe Anzahl von Bugs, die von der CodeSonar® Data-Race-Detection sehr effektiv aufgedeckt werden. Ein Data Race tritt unter folgenden Umständen auf:

1. Mehrere Ausführungs-Threads greifen auf gemeinsame Daten zu
2. Die Werte der Daten werden durch mindestens einen Thread geändert
3. Der Zugriff ist nicht durch eine explizite Synchronisation getrennt.

Data Races können ein System in einen inkonsistenten Zustand bringen. Ein solcher Zustand kann zunächst unerkannt bleiben und erst unter ungewöhnlichen Umständen mit seltsamen Symptomen auftreten.

Die Schwierigkeit beim Aufdecken und Debuggen von Data Races (und Concurrency-Problemen im allgemeinen) mit herkömmlichen Testmethoden besteht darin, dass es eine enorme Anzahl verschiedener Ausführungsmöglichkeiten gibt. Das folgende Bild gibt hierfür ein Beispiel.

Es gibt sechs mögliche Überlappungen von zwei Threads mit je zwei Befehlen.Mit jeweils drei Anweisungen gibt es zwanzig mögliche Ausprägungen. Aufgrund der kombinatorischen Explosion ist es unmöglich, in realen Systmen jede Verschachtelung zu testen. Da Data Races nur unter bestimmten Bedingungen auftreten, ist deren Diagnose mit traditionellen Testmethoden schwierig. Data Races sind auch mit herkömmlichen Tools wie Debugger schwierig aufzudecken, da diese das Timing beeinflussen können, wodurch der Bug vorübergehend verschwindet.

CodeSonar® deckt Data Races auf, indem es sich auf die Ursachen und nicht auf die Symptome konzentriert. Das Tool überprüft den Code und erstellt ein abstraktes Modell, welches die einzelnen Locks für jeden Thread zeigen. Es berücksichtigt automatisch mögliche Überlappungen und überprüft Zugriffpatterns auf gemeinsame Speicherplätze. Sobald ein Data Race identifiziert worden ist, gibt CodeSonar® eine Warnung mit den entsprechenden Informationen aus.

Es ist eine weit verbreitete Annahme, dass einige Data-Race-Arten harmlos seien. Diese Annahme ist jedoch falsch. Auch wenn die Race-Bedingung im Quellcode unproblematisch aussieht, kann sie wegen der Umordnung von Anweisungen durch Kompileroptimierung doch Schaden anrichten.

Aufdecken von Deadlocks

Der häufigste Ansatz zur Vermeidung von Deadlocks ist eine partielle Reservierung der Ressourcen zu gewährleisten. Dieser Ansatz ist 1965 von Dijkstra als Lösung des so genannten Philosophenproblems vorgeschlagen worden. In großen Codebasen kann es schwierig sein durch manuelle Inspektion festzustellen, ob eine Software diese Regel beachtet. CodeSonar® führt eine automatische Analyse durch und gibt eine Warnung aus, sobald auf den gleichen Lock durch verschiedene Befehle von verschiedenen Threads zugegriffen werden kann.

CodeSonar® hat desweiteren einen "Nested-Locks-Check", um diese gefährliche Fehlerart zu vermeiden. Dieser Check gibt jedesmal eine Warnung aus, wenn ein Thread versucht zwei oder mehr Locks zu erhalten. Der "Nested-Locks-Check" kann je nach Anforderungen eingeschaltet oder unterdrückt werden.

Bei einem Deadlock warten zwei konkurrierende Aktionen jeweils auf die Beendigung der anderen Aktion, so dass diese nie zum Abschluss kommen.