I see. Thank you. So you are saying that although the GCC atomic operations are compatible with Helgrind, the fact that I use boost threads drive Helgrind crazy, correct?
Regards, Panagiotis 2011/5/16 Julian Seward <[email protected]>: > >> 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
