Hello from Toulouse, France, so please excuse my sometimes poor or hesitant English; I want to parallelize a fortran tool that post-processes finite elements stress results, and it does not yet work correctly; I already posted a message on this list, under the same title : [fortran OpenMP hangs in the last subroutine]. The serial version of the tool is Ok, but a run lasts five days, and the machine should be able to reduce that to half a day with OpenMP.
The problem is that the program enters an endless loop while ran on several processors, even with as few as a twentieth of the full data set that it should finally process. But it behaves perfectly well with an even smaller set of data.
I suspect a race condition on one of the variables used by that subroutine, because it never enters that endless loop at the same step within this last subroutine.
So, I would like to check before any assignation of any variable, if it would not use a memory location which would be already used elsewhere in a previous subroutine.
Would it be better to scan every already used variable, whith the following logical function which checks if two pointers do have the same target : C_ASSOCIATED(C_PTR_1, C_PTR_2) with C_PTR_1 aiming at the variable to test, and C_PTR_2 aiming in a loop at all previously used variables.
Or, I also imagine to create a C-function which would recieve a pointer to the new variable, and return its real memory location obtained by the “&” unary C-operator, and I could later check that memory location against all those that would have been already used.
I hope this is clear enough for somebody to give me an advice,
Thank you,
David
Sorry, but you should probably file a support ticket with your
compiler vendor or whoever supports your tools environment.
This list is meant for support for openmp-llvm project. I understand
you may be using the Intel compiler, but don't think anyone around
here can help you.
Alternatively if this isn't a bug, but you're looking for general help
on OpenMP - stackoverflow.com or maybe another resource is more
suitable.
Good luck
My advice is to compile it -g with symbols for debugging, attach a debugger to the hanging process (gdb —pid the_pid_of_your_process), run the command “info thread” to see where each of your threads are, and look at the call stack for each thread to see what it is doing. Either all threads are doing something that causes them to loop infinitely, or most threads are at a barrier while one or more threads is computing infinitely or waiting for a condition that will never be satisfied.
Using a debugger to examine the problem in action and then speculating about the root causes is much better than speculating blind.
Hello again and thank’s a lot for this advice that sounds wise; I’m gonna hide myself at the bottom end of the universe now, because somebody else answered thar this list was for bug suport which I’m not looking for, so good bye and thank’s to have given me something to test tomorrow at work.
David
-------- Message initial --------