|
From: Reyko S. <re...@gm...> - 2011-01-27 12:30:37
Attachments:
noiseAmp_valgrind_helgrind.log
|
Dear users,
I have some questions regarding my code and checking it with helgrind.
I'm using valgrind-3.5.0, g++ (SUSE Linux) 4.4.1 [gcc-4_4-branch
revision 150839] on openSuse 11.2 (x86_64).
here is some piece of code I tested with helgrind:
unsigned const nSH_min = lMin*lMin;
// ... some code ...
292:#pragma omp parallel for shared(noiseAmpSH,noiseAmpxyz,positions,
norm, coord),private(l,m, nSH,result, p, vesh)
293: for (unsigned n=0; n<numRows; n++){
294: nSH=n+nSH_min;
295: l=static_cast<unsigned>(floor(sqrt(nSH)));
296: m=nSH-l*(l+1);
297: // Create vector spherical harmonic object.
298: vesh = new VectorExteriorSphericalHarmonics(l,m,6371.2);
299: vesh->normalize(norm, 1.0);
300:
301: for (unsigned j=0; j<numPos; j++){
302: p = (*positions)[j];
303: // calculate Gradient
304: vesh->evaluate(p, coord, result);
305: result = (*noiseAmpSH)[n]*result;
306:#pragma omp critical
307: {
308: ((*noiseAmpxyz)[j])[0]+=result[0];
309: ((*noiseAmpxyz)[j])[1]+=result[1];
310: ((*noiseAmpxyz)[j])[2]+=result[2];
311: } // omp critical
312: } // for (j...)
313:
314: delete vesh;
315: } // for (n...)
I attached the complete logfile but there are two major questions I
want to ask and point to the corresponding log-output:
1)
==29368== Possible data race during write of size 8 at 0x7feffddc0 by thread #2
==29368== at 0x4C289B9: ??? (in
/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==29368== by 0x6D1965C: start_thread (in /lib64/libpthread-2.10.1.so)
==29368== by 0x6FFFECC: clone (in /lib64/libc-2.10.1.so)
==29368== This conflicts with a previous read of size 8 by thread #1
==29368== at 0x4C288AD: ??? (in
/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==29368== by 0x4C2893C: pthread_create@* (in
/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==29368== by 0x68F6C69: ??? (in /usr/lib64/libgomp.so.1.0.0)
==29368== by 0x406CBC: main (cmpNoiseAmp.cpp:292)
==29368==
How can there be a data race when the parallel region is opened? What
happens in line 292 that can create such thing?
2)
==29368== Possible data race during read of size 8 at 0x749bfb8 by thread #1
==29368== at 0x403574: main.omp_fn.0 (cmpNoiseAmp.cpp:308)
==29368== by 0x406CC4: main (cmpNoiseAmp.cpp:292)
==29368== This conflicts with a previous write of size 8 by thread #2
==29368== at 0x40357F: main.omp_fn.0 (cmpNoiseAmp.cpp:308)
==29368== by 0x68F6871: ??? (in /usr/lib64/libgomp.so.1.0.0)
==29368== by 0x4C289C5: ??? (in
/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==29368== by 0x6D1965C: start_thread (in /lib64/libpthread-2.10.1.so)
==29368== by 0x6FFFECC: clone (in /lib64/libc-2.10.1.so)
==29368==
I put the write-statement in line 308-310 in a critical section. How
can there be a data race? The variable noiseAmpxyz is the only shared
avriable that is written to (as far as I can see it).
I appreciate any comments and suggestions.
Kind regards,
Reyko Schachtschneider
--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
|