[Openmp-dev] [fortran OpenMP hangs in the last subroutine] Race condition ?

[David Van Aelst via Openmp-dev]

  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 --------
De: John Mellor-Crummey <johnmc at rice.edu>
À: David Van Aelst <david.van-aelst at orange.fr>
Cc: John Mellor-Crummey <johnmc at rice.edu>, openmp-dev at lists.llvm.org
Sujet: Re: [Openmp-dev] [fortran OpenMP hangs in the last subroutine]
Race condition ?
Date: Tue, 24 May 2016 10:02:27 -0500

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.
--
John Mellor-Crummey         Professor
Dept of Computer Science    Rice University
email: johnmc at rice.edu      phone: 713-348-5179


> On May 24, 2016, at 9:41 AM, David Van Aelst via Openmp-dev
> <openmp-dev at lists.llvm.org> wrote:
> 
> 
> 
> 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
> 
> !DSPAM:8504,574467d8149701257476417!
> 
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
> 
> !DSPAM:8504,574467d8149701257476417!
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20160524/8c878b0a/attachment-0001.html>