Parallel Programming: what tools do you use?

[Gian Franco]

Dear Sergey,

What tools do you recommend to facilitate the specific
issues parallel programming brings with it?

Kind regards,

Gian

[Sergey Babkin]

I myself mostly do it the old-fashionable way: gdb, debugging printfs, and as a more recent thing valgrind. :-) Some debugging techniques are mentioned in the book, such as the versions of libraries with deadlock detections, lock hierarchies and such.

Another technique that I've found useful when the debugging printouts are too slow and alter the program execution logic a lot is to have in-memory buffers where the debugging information can be written fast, without upsetting the timing, and then read later after the problem has occured. A sort of a "black box" trace for the program that can be used to restore the sequence of events. And for debugging it gets useful to add the artificial delays in the suspicious places, and then hammering the program with a stress test.

I haven't looked that much at the static analyzers, and what I've seen did not make a particularly big impression.

[Vadym Ustymenko]

What tools do you recommend to facilitate the specific
issues parallel programming brings with it?

Your best tools would be local variables, method parameters and return values. You can read about thread-safe programming practices to avoid issues that parallel programming brings in the first place.