topic Inspector strange data race warning in Intel® Moderncode for Parallel Architectures

Inspector strange data race warning

Petros — Mon, 02 Apr 2012 15:23:57 GMT

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

Inspector strange data race warning

TimP — Fri, 06 Apr 2012 11:32:08 GMT

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.

Inspector strange data race warning

Petros — Fri, 06 Apr 2012 13:22:16 GMT

Quoting TimP (Intel)

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?

Inspector strange data race warning

TimP — Fri, 06 Apr 2012 16:08:31 GMT

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.

Inspector strange data race warning

Petros — Fri, 06 Apr 2012 22:31:13 GMT

Quoting TimP (Intel)

"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