> 1) Suppose that there is a global array named 'global_array'. Image the > scenario where Thread1 does *global_array[0]*=value1 and Thread2 does * > global_array[1]*=value2 without any protection. Clearly, that scenario does > not cause any inconsistency problems. Is it possible that helgrind reports > that scenario as a "Possible race"?
No. Since the addresses don't overlap, there is no race. > 2) I have a C++ boost-threaded application. Threads read and write shared > resources via GCC's atomic built-in operations, such as > __sync_compare_and_swap, __sync_fetch_and_add and so forth. I would like to > ask, whether or not helgrind is compatible with these kind of operations. Yes it is. > Should I trust the races reported? I am asking because the exact same > application was also written using pthreads for synchronization and > helgrind reported no races at all in that (POSIX) implementation... That normally means that Helgrind doesn't "see" the synchronisation events in the Boost library properly; see http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use point (1). I don't know whether Boost has options to be race-detector friendly. J ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
