Inspector strange data race warning

Inspector strange data race warning

p3tris's picture
p3tris
Mon, 04/02/2012 - 08:23

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: 

!$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
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: 
-g -fno-alias -fpp -openmp -openmp-report -I$(MKLROOT)/include -align -zero -O3 -msse4 -simd -module $(OBJS_DIR) -c
And link with: 

-L$(MKLROOT)/lib/intel64 -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -liomp5 -lpthread -lm
The results I get when compared to compiling without openmp (sequential run) are the same. Any ideas welcome! Thanks in advance, Petros

RSS Top
5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
TimP (Intel)'s picture
TimP (Intel)
Fri, 04/06/2012 - 04:32

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.

Top
p3tris's picture
p3tris
Fri, 04/06/2012 - 06:22
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: 

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
You think it might be the f77 way of calling lapack?

Top
TimP (Intel)'s picture
TimP (Intel)
Fri, 04/06/2012 - 09:08

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.

Top
p3tris's picture
p3tris
Fri, 04/06/2012 - 15:31
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

Top

Login to leave a comment.