Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Petros
Beginner
45 Views

Inspector strange data race warning

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
0 Kudos
4 Replies
TimP
Black Belt
45 Views

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
Beginner
45 Views

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
Black Belt
45 Views

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
Beginner
45 Views

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
Reply