|
From: Panagiotis F. <paf...@gm...> - 2011-05-16 17:09:15
|
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 <js...@ac...>: > >> 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 > |