Inspector strange data race warning

[Petros]

Hi,

I use the Inspector to see if my program has any data race conditions. I get a warning that I cannot interpret.

This is a segment of the code:

[fortran]!$omp parallel do default(none) & !$omp private(j) & !$omp shared(nb1,nb2, adf) & !$omp reduction(+:counter) & !$omp schedule(static,200) do j=1,nb1+nb2 ... counter=counter+1 CALL DGETRF(adf(j+1)-adf(j),adf(j+1)-adf(j),A(1,1,j),mxxinj,IPVT(1,j),info) ... endif[/fortran] It issues a "data race" on the DGETRF subrouting call. More specifically, the call stack goes: my_subroutine->libmkl_intel_lp64.so!DGETRF_->libmkl_core.so!mkl_serv_allocate for the Read description andmy_subroutine->libmkl_intel_lp64.so!DGETRF_->libmkl_core.so!mkl_serv_allocate->libmkl_core.so!mkl_serv_unlock for the write description on the same code line.

From the DGETRF call:

-A, IPVT and info are threadprivate

-adf is shared

-mxxinj is declared as a parameter (so, shared by default, I think).

I compile with:

[bash]-g -fno-alias -fpp -openmp -openmp-report -I$(MKLROOT)/include -align -zero -O3 -msse4 -simd -module $(OBJS_DIR) -c[/bash]

And link with:

[bash]-L$(MKLROOT)/lib/intel64 -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -liomp5 -lpthread -lm[/bash]

The results I get when compared to compiling without openmp (sequential run) are the same.

Any ideas welcome!

Thanks in advance,

Petros

[TimP]

You don't show whether you allowed for info to be private. That would be enough to produce a warning, even if all threads are returning the same value in your case.
Not all versions of Intel OpenMP work with the pre-f90" method for passing an array section by designating the first element, as you do with A(1,1,j) and IPVT(1,j), but your success shows that's not the issue here.

[Petros]

Quoting TimP (Intel)

You don't show whether you allowed for info to be private. That would be enough to produce a warning, even if all threads are returning the same value in your case.
Not all versions of Intel OpenMP work with the pre-f90" method for passing an array section by designating the first element, as you do with A(1,1,j) and IPVT(1,j), but your success shows that's not the issue here.

a better description of the code is:

[bash]module a1 use dimensions integer :: IPVT(M,nb1+nb2+nb3) double precision :: A(M,nb1+nb2+nb3) end module a1 subroutine simulator use a1 implicit none integer, save:: info integer :: adf(nb1+nb2+nb3) !$omp threadprivate(info,A,IPVT) ... !$omp parallel A=0.d0 info=0.d0 IPVT=0.d0 !$omp end parallel ... !$omp parallel do default(none) & !$omp private(j) & !$omp shared(nb1,nb2,nb3,adf) & !$omp reduction(+:counter) & !$omp schedule(static,200) do j=1,nb1+nb2+nb3 ... counter=counter+1 CALL DGETRF(adf(j+1)-adf(j),adf(j+1)-adf(j),A(1,1,j),mxxinj,IPVT(1,j),info) ... endif ... end subroutine simulator[/bash]

You think it might be the f77 way of calling lapack?

[TimP]

No, each call updates info, and you could get a failure which you never see reported because of another thread reporting success before you see the failure. You may not care, it's only a warning. It's unlikely to be a big performance hit relative to the work done in dgetrf.
If the "f77 array section" notation were biting you, you wouldn't have had a successful run. I don't know of it being a problem in a released OpenMP.

[Petros]

Quoting TimP (Intel)

No, each call updates info, and you could get a failure which you never see reported because of another thread reporting success before you see the failure. You may not care, it's only a warning. It's unlikely to be a big performance hit relative to the work done in dgetrf.
If the "f77 array section" notation were biting you, you wouldn't have had a successful run. I don't know of it being a problem in a released OpenMP.

"info" is threadprivate, so each thread has it's own info variable. dgetrf subroutines called by different threads update different info variables. I don't see how they could collide...

I will try changing for f95 lapack calls and see if inspector still complains.

Thanks for the effort!

Petros