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

[C Bergström via Openmp-dev]

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

On Tue, May 24, 2016 at 10:41 PM, 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
>
>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>