|
From: Julian S. <js...@ac...> - 2011-05-16 11:20:16
|
> 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 |