thread checker problem

[roddur]

below is my makefile that i have used to use with threadchecker. i have a core2duo machine and i generally run my openmp-fortran code with number of thread set to 2. in my application, when i ran the code using theck_cl , it was running as if it is ordered. is that ok or i have missed some point?

i have sourced tcheckvars.sh aswell. plz suggestme what to do and how i can catch how to catch datarace condition

[cpp]
FC=ifort
LDFLAG=-lpthread
TCFLAG = -tcheck
ITT_BASE =/matsc/students/Rudra/intel/itt
LPATH = $(ITT_BASE)/tcheck/bin/32
ifeq ($(FC),gfortran)
CC=gcc
FFLAG = -O0#-lpthread -tcheck
FPAR=-fopenmp
LFFLAG=-O0
CFLAG =-O0

else
CC=icc
FFLAG =-g -O3
LFFLAG=-g -O3
FPAR=-openmp
CFLAG =#-O3
endif

LP=lp -d ccprint -o sides=two-sided-long-edge

objs =cptimer.o 
kind.o param.o 
mmat.o newfit.o 
hop.o pardos.o 
dos.o fermi.o 
band.o ldos.o 
cgreen.o main.o #eigen.o

irun : $(objs)
#$(FC) $(LFFLAG) $(FPAR) $(objs) -o irun
$(FC) $(LFFLAG) $(FPAR) -L$(LPATH) $(TCFLAG) $(objs) -o irun

kind.o : kind.f90
$(FC) $(FFLAG) -c kind.f90
param.o:param.f90
$(FC) $(FFLAG) -c param.f90
newfit.o: newfit.f90 param.o kind.o
$(FC) $(FFLAG) -c newfit.f90
cptimer.o:lib/cptimer.c
$(CC) -c lib/cptimer.c
mmat.o: mmat.f90 param.o kind.o
$(FC) $(FFLAG) -c mmat.f90
hop.o: hop.f90 param.o kind.o
$(FC) $(FFLAG) -c hop.f90
cgreen.o:cgreen.f90 param.o
$(FC) $(FFLAG) -c cgreen.f90
dos.o:dos.f90 param.o kind.o
$(FC) $(FFLAG) -c dos.f90
fermi.o:fermi.f90 param.o kind.o
$(FC) $(FFLAG) -c fermi.f90
ldos.o:ldos.f90 param.o kind.o
$(FC) $(FFLAG) -c ldos.f90
band.o:band.f90 kind.o param.o
$(FC) $(FFLAG) -c band.f90
pardos.o:pardos.f90 param.o
$(FC) $(FFLAG) -c pardos.f90
main.o : main.f90 ldos.o fermi.o band.o dos.o newfit.o mmat.o hop.o param.o kind.o
#$(FC) $(FFLAG) $(FPAR) -c main.f90
$(FC) $(FFLAG) $(FPAR) $(TCFLAG) -L$(LPATH) $(LDFLAGS) -c main.f90[/cpp]

Regards,

Rudra

[TimP · Accepted solution]

This looks OK. I guess you are running on a 32-bit operating system; you didn't say. If you are running on a 64-bit linux, with a 64-bit ifort and gcc, you will need the thread checker psths with 32e instead of 32. My colleagues have been asking for a uniform directory naming system for at least a year now, apparently with little success.

When you have compiled and linked with -tcheck set, and have the shared library paths set according to tcheckvars and ifortvars, you can run your application normally. Don't use tcheck_cl yet. Your application should write the file threadchecker.thr; then you can run 'tcheck_cl threadchecker.thr' to display any warnings.

Thread checker runs aren't affected by the number of threads whiich are set, unless your program explicitly chooses execution paths according to that setting. I should say, I have experience with thread checker only with OpenMP threading.

When you run, if you get a message that it was unable to link libomp_dbg, it means the version of ifort you are using doesn't support thread checker (or you didn't set the ifort LD_LIBRARY_PATH). It looks like ifort 11.0 should have fully corrected this problem in the latest version (11.0/074).

It looks like you didn't attempt to thread check the objects which were built with gcc. I believe you have done this correctly; it seems that thread checker can handle correctly only the objects built with the same compiler used to compile the main program and link.

[roddur]

Quoting - tim18

When you have compiled and linked with -tcheck set, and have the shared library paths set according to tcheckvars and ifortvars, you can run your application normally. Don't use tcheck_cl yet. Your application should write the file threadchecker.thr; then you can run 'tcheck_cl threadchecker.thr' to display any warnings.

hmmm..thanks!i was making the same mistake with running the executable directly using tcheck_cl. and it was horribly slow.now using the same make, i am just running the irun(my executable) firest and then i will , according to your advice, run the tcheck_cl.

but i think this point should be made clearer in the userguide itself.

thanks

[TimP]

Quoting - roddur

hmmm..thanks!i was making the same mistake with running the executable directly using tcheck_cl. and it was horribly slow.now using the same make, i am just running the irun(my executable) firest and then i will , according to your advice, run the tcheck_cl.

but i think this point should be made clearer in the userguide itself.

Running under tcheck is slow no matter how you do it. In large applications I deal with, it is sufficient to run drastically shortened cases.

For simple advertising demonstrations, I believe there was a goal of making tcheck_cl capable of checking a basic build made without -tcheck. In principle, this would permit checking pre-built libraries of unknown thread-safeness. Particularly when running under 32-bit OS, the size of test cases would be extremely limited.

For practical purposes, I have not been able to use tcheck under either the ia64 or the 32-bit OS. If you have built successfully, you have passed the first limitation, which is that code size may grow under -tcheck (which implies -O0 -g) to the extent where it is impossible to link.