I have started running an OMP application with 2 threads (on a dual-core machine). I have tested pretty extensively the thing that goes inside the do-loop (a subprogram that solves a complicated fixed-point problem) and I have never had this solver die. But now that I am running in two, sometimes the program just stops - one thread reports having completed its process, so it waits for the other; but the other just never comes out - not for hours. Yet it says nothing. Is this a known problem? The weird thing is that my process-meter shows that my program is still using one core fully. ... but what it's doing I don't know. (Paging file usage is totally flat, which is uncharacteristic for the subprogram).
You might start looking by pressing the Pause tool bar button in the Debugger. Then see where the busy thread is tied up.
You may have issues relating to code optimizations removing memory references (read once into register the re-use register) for shared variables. Dumb example
intdone=0;// other thread sets to 1 when done
Most compilers will read done once then stay in that loop forever. What you want to do is:
volatileintdone=0;// other thread sets to 1
Note, I am not suggesting that you program waits like this.
The important point is to be careful of shared variables that get registerized and are thread to thread communication variables. Consider using volatile on these variables.
For thread to thread communication (shared variables that get modified) take a look at the
series of functions.
It doesn't sound like the thread is dying, just spinning forever. This could be something like a dependency relation in the parallel loop that wouldn't bother a single-threaded execution but plays havok once there's multiple threads trying to execute the same code.
How are you dividing the work of the solver between multiple threads? You mention OMP but it's not clear how you use it in relation to the solver loop.