Develop a methodology for the debugging & testing phase of the development cycle. In most situations, the debug and testing stages of threading go hand in hand.
Run the code (binaries that are of Release build with debug symbols included) underVTune™ Performance AnalyzerandIntel® Thread Checker. Test to reveal inconsistencies between the threaded-version run and the serial-version run, and debug those inconsistencies. Repeat the process until the results obtained are verified to be consistent with the serial-application run. The following figure shows the proposed methodology to follow while debugging a large application:
By starting with a release build, the debug run will have shorter run times, in addition to the benefit of not having to compile the application with source instrumentation. This is particularly useful for applications that take many hours to build. Once the memory conflicts have been identified, the methodology proposes source instrumentation of only the affected source modules that are reported by Intel Thread Checker.
With the use of /Qtcheck option, source instrumentation enables the extraction of information about the variables that cause these conflicts. This drill-down methodology saves a considerable amount of time in the debug process. The following figure shows a sample screen shot of Intel Thread Checker that shows memory conflicts occurring in an application:
Double clicking on each error allows the developer to identify the source line that caused it. Testing an application involves verifying the correctness of the result with that of the serial run. If no errors are reported by Intel Thread Checker at this stage, it can be safely assumed that most of the runtime race conditions have been identified and fixed. If the results of the threaded run match those of the serial run, then the application is consistent.
A prevalent issue in the debugging and testing phase is covered in a separate item,
"How to Test DLLs for Thread Safety."