Debuggen parallelisierter Programme

Mit Hilfe des CXdb kann man auch parallelisierte Programme debuggen. Natürlich sind die Schwierigkeiten, die beim Debuggen vektorisierter Programme auftreten, hier genauso vorhanden. Zusätzlich kann man sich nun die Aufteilung des Programmablaufs auf einzelne Threads ansehen und sie einzeln oder zusammen steuern.
Um reproduzierbare Ergebnisse zu bekommen, sollte man als erstes das automatische Verteilen der Threads abschalten und vor dem Starten eines Prozesses im CXdb auf ''fixed scheduling'' gehen mit

        set default fixed sched .

Dadurch stehen innerhalb einer zugeteilten Zeitscheibe immer alle CPUs zur Verfügung, so daß jedem Thread auch wirklich ein Prozessor entspricht.
Läßt man das Programm bis in einen parallelen Bereich hineinlaufen und dann anhalten (durch Breakpoints oder schrittweise), kann man Kommandos in einzelnen Threads ausführen, sie einzeln durchsteppen oder ihre eigenen Variablen ansehen, indem man vor die entsprechenden CXdb-Kommandos die Thread-Nummer (bei uns 0, 1, 2, 3) angibt in der Form

        :tNR CXdb-Kommando,

z.B. '':t1 step'', oder '':t1,3 step'' für Threads 1 und 3 auf einmal. Im Source-Fenster wird durch Voranstellen der Threadnummer in der Form ''$1>$'' vor einer Zeile angezeigt, wo die einzelnen Threads stehen. Befinden sich mehrere Threads an der gleichen Stelle, erscheint dort stattdessen nur die Zahl der Threads (als n@).
Weitere Informationen über die einzelnen Threads erhält man mit

        info threads .

Schließlich gibt es die speziellen Eventpoints

        event spawn  bzw.  event join ,

die die Programm-Ausführung anhalten sollen, wenn Threads erzeugt bzw. beendet werden.