Paralleltesten mit Visual Studio: Parallel Debugger Extension
Klar, Microsofts Visual Studio bietet eine erprobte Debugging-Umgebung, mit der sich Anwendungen auf mögliche Fehler untersuchen lassen. Allerdings gilt dies nur für sequentiell programmierte Software, potenziellen Multithread-Problemen kommt man mit diesem Tool nicht auf die Schliche. Hierfür bietet sich ein Tool an, das Teil des Parallel Studio ist und sich Parallel Composer nennt. Teil des Composers wiederum ist die Parallel Debugger Extension, die sich als Erweiterung in die Debugger-Umgebung von Visual Studio “einklinkt”.
Die Parallel Debugger Extension weist folgende Hauptmerkmale auf:
- Das Aufspüren von Data Sharing, also der gemeinsame Datenzugriff mehrerer Threads auf eine identische Speicherzelle. Hierfür sind die Schalter /debug:parallel und /Qopenmp am Anfang des Quellcodes notwendig, die dem Compiler mitteilen, den Sourcecode entsprechend zu kompilieren.
- Mit der Funktion Re-entrant Function Call Detection lässt sich die Anwendung anhalten, sobald zwei Threads gleichzeitig auf ein und dieselbe Funktion zugreifen.
- Der direkte Zugriff auf sämtliche SSE-Register führt zu einem verbesserten Verständnis, was bei der Programmausführung auf Prozessorebene stattfindet.
- Falls beim Kompilieren des Quellcodes der Schalter /Qopenmp gesetzt wurde, hat man per Debugger Extension Zugriff auf sämtliche Datenstrukturen wie Tasks, wartende Tasks, Task-Locks etc.
- Eine mithilfe von OpenMP-Pragmas parallelisierte Anwendung lässt sich mit wenigen Mausklicks als sequentielles Programm ausführen und debuggen, was die Fehlersuche eindeutiger macht: Haben sich die Bugs beim Parallelisieren eingeschlichen oder basieren sie auf grundsätzlichen Schwächen im Programmdesign?
Dies ist übrigens nur einer kleiner Auschnitt der Funktionsvielfalt der Parallel Debugger Extension. Falls ihr mehr dazu wissen wollt, empfehle ich den Download des 29-seitigen PDF-Dokuments, das sehr detailliert auf die Debugger-Erweiterung des Parallel Composer eingeht.
Vergleich: Intel Thread Checker versus Parallel Inspector
Auf dem Intel Software Network habe ich eine interessante Gegenüberstellung gefunden, die auf einen Blick zeigt, worin sich die Tools Intel Thread Checker und Intel Parallel Inspector unterscheiden. Daraus ergeben sich interessante Aspekte:
- Intel Parallel Inspector ist aus dem Thread Checker entstanden und jetzt ein Teil der Entwicklersuite Parallel Studio. Damit ist klar, dass sich Parallel Inspector nur in Verbindung mit Visual Studio 2005 oder 2008 unter Windows nutzen lässt. Thread Checker hingegen ist ein Stand-Alone-Tool, das man sowohl unter Windows als auch mit Linux einsetzen kann.
- Beide Werkzeuge eignen sich für das Aufspüren von möglichen Data Races und Dead Locks, vor allem für parallel programmierte Anwendungen. Darüber hinaus spürt Parallel Inspector mögliche Speicherprobleme auf.
- Parallel Inspector hat natürlich von den Fehlern des Thread Checkers gelernt, ist daher schneller einsetzbar, generiert bei der Analyse der Anwendung weniger Overhead und sorgt für skalierbare Tests, ohne dass die Anwendung vorher serialisiert werden muss.
- Thread Checker basiert auf einem Lizenzmodell, das den Einsatz des Tools auf mehreren Rechnern erlaubt, aber immer nur auf einem PC zur selben Zeit. Zudem bietet Intel für den Checker unbegrenzten Premier-Support und für die Dauer eines Jahres kostenlose Produkt-Updates.
Linux-Debugger für C++ und Fortran mit grafischer Oberfläche
Es soll ja Leute geben, die (a) nicht viel von grafisch basierten Oberflächen halten und (b) nicht wissen, dass die Intel-Linux-Compiler für C/C++ und Fortran einen solchen GUI-Debugger mitbringen. Dieselben konnte ich mir vorletzte Woche während meines Besuchs bei Intel in Ulm ansehen und mir ein Bild von ihren Fähigkeiten machen. Und das kam dabei heraus (mehr dazu folgt noch diese Woche mit weiteren Details und ein paar interessanten Bildern).
Das absolute Highlight des GUI-basierten Linux-Debuggers von Intel ist die Möglichkeit, einzelne Breakpoints zu setzen, zu speichern und bei Bedarf das so markierte Projekt wieder aufzurufen. Das ist vor allem dann hilfreich, wenn sich die Umgebungsentwicklung mal verabschieden sollte oder man andere Dinge zwischendurch zu tun hat, bevor man sich wieder dem Debuggen zuwendet. Ein Breakpoint wird dank der grafischen Bedieneroberfläche per doppeltem Mausklick erzeugt – und genauso schnell wieder entfernt. Das macht das Testen von C/C++ und Fortran-Projekten wirklich sehr komfortabel.
Aber auch das Testen parallel programmierter Projekte unter Linux geschieht mit dem Debugger von Intel recht überzeugend. So kann man in Echtzeit eine komplette Anwendung (oder Teile davon) auf mögliche Data Races hin untersuchen. Genau genommen identifiziert der Debugger Szenarien, in denen es zu gemeinsamen Datenzugriffen kommen kann, was vor allem das konkurrierende Speichern zweier Threads betrifft. Der Programmierer oder Entwickler muss dann selbst entscheiden, ob dieser parallele Schreibzugriff gewollt ist oder im schlimmsten Fall einen Absturz der Anwendung zur Folge haben kann.
Fehler im Multithread-Code aufspüren: Thread Checker
Beim Erstellen von parallel programmiertem Quellcode treten im Gegensatz zu seriellem Sourcecode zwei mögliche Probleme sehr viel häufiger auf: Race Conditions und Dead Locks. Beide sind mit herkömmlichen Mitteln nicht aufspürbar, so dass ein spezielles Tool erforderlich ist, dass diese Aufgaben erledigen kann. Dieses Software-Werkzeug nennt sich Thread Checker und ist Bestandteil des VTune Performance Analyzer, der sich wiederum vollständig in Visual Studio integrieren lässt.
Damit steht der Thread Checker in der bekannten Entwicklungsumgebung zur Verfügung. Eine Einschränkung gibt es allerdings: Es lassen sich nur nativ programmierte Anwendungen mit dem Thread Checker überprüfen, also nur C++ und Visual Fortran. .NET-Entwickler bleiben derzeit leider außen vor. Dies wird sich allerdings mit Visual Studio 2010 ändern, das ja Ende nächsten Jahres auf den Markt kommen soll.
Exkurs: Race Conditions und Dead Locks
Race Conditions treten vor allem dann auf, wenn ein parallel programmiertes Programm zur Laufzeit zwei Thread generiert, die beide auf ein gemeinsames Datum zugreifen und davon nichts wissen. So erzeugt Thread A beispielsweise ein Datum X und speichert es, was Thread B genauso tut, ohne darüber Bescheid zu wissen, dass Thread A das Datum X gerade geändert. Dies kann natürlich zu unvorhergesehenen Problemen und Fehlern im weiteren Programmablauf führen.
