Your program might have bugs that are now being exposed during parallel execution because of changes in order, memory allocation, uninitialized memory contents, and so on.
Such bugs are debugged in the same way as a serial (single-threaded) application, with the following challenges:
The program does not run in exactly the same order each time. Possible causes include:
Locks may be acquired first by different threads.
Pointers returned by
may differ from one run to the next.
Random number sequences observed by a thread may differ from those observed in the serial version, and from run to run.
Items removed from a shared list by a thread may differ from run to run
The debugger can interact in strange manners with the threads.
Breakpoints can appear to be hit multiple times by a thread, even though the thread only make progress through the breakpoint on last hit of the series.
Thread local storage can be difficult to examine.
To determine whether you can reproduce the bug with a single thread, run the parallel version of your program as a serial program by limiting the number of threads to 1. Use such methods as setting an environment variable before you run your program or by using the
Intel® oneAPI Threading Building Blocks (oneTBB)
Before spending a significant amount of time debugging the parallel code, you should try running the parallel loops and other parallel constructs as serial code but in reverse order. This may expose the bugs caused by your program depending on the order of execution of these statements, without requiring you to debug a parallel program.
Debug the Remaining Sharing Problems
After your program works in serial mode, and in serial mode with the parallel constructs in reverse order, use the Intel® Inspector tool to find any remaining conflicts.