On Aug 19, 2014 11:58 PM, "Philippe Waroquiers" < philippe.waroqui...@skynet.be> wrote: > > On Tue, 2014-08-19 at 21:44 +0200, David Faure wrote: > > On Tuesday 19 August 2014 21:00:58 Philippe Waroquiers wrote: > > > On Tue, 2014-08-19 at 16:46 +0200, Roland Mainz wrote: > > > > > ThreadSanitizer won't comprehend the fence instructions inserted by > > > > > urcu. > > > > > I believe even Helgrind won't, because these instructions do not imply > > > > > any happens-before relation. > > > > > > > > Is there any opensource or commercial tool which might help in such > > > > situations (e.g. problems with memory barriers) ? > > > > > > helgrind or drd or ThreadSanitizer could still be used for race > > > condition detection but you would have to annotate either the rcu > > > library or the calling code to describe the happens before > > > relationships. > > > > Are such annotations documented somewhere? > http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.client-requests > gives a list of such annotations, and points to helgrind.h for more > information. > > > I'm still trying to find a way to annotate threadsafe-statics so that helgrind > > doesn't complain about them. > What is a threadsafe-static ? That's a local static that is guarded by __cxa_guard_acquire/__cxa_guard_release to ensure it's initialized only once. Prior to C++11 GCC used to emit those by default, whereas MSVC didn't support them. C++11 mandates that static initialization must be thread-safe. >From the data race detector's point of view the guard object is essentially a lock. > Is that using __thread in something like: > void fun(void) > { > static __thread int no_race_on_this_var_is_possible; > .... > } > > If that is the case, I am just finishing a change that should avoid > false positive in __thread variables. > > Humph, replace rather 'change' by kludge: > The user will have to add the option > --sim-hints=no-nptl-pthread-stackcache > and that uses a nasty kludge to disable the nptl pthread stack&tls > cache, as helgrind does not understand that the memory for e.g. > tls __thread variables is "safely" re-usable by another thread once the > thread is finished. > > Philippe > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users
------------------------------------------------------------------------------
_______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
