Community
cancel
Showing results for 
Search instead for 
Did you mean: 
roddur
Beginner
97 Views

thread checker problem

Jump to solution

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

0 Kudos
1 Solution
TimP
Black Belt
97 Views

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.

View solution in original post

3 Replies
TimP
Black Belt
98 Views

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.

View solution in original post

roddur
Beginner
97 Views
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
Black Belt
97 Views
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.

Reply