|
From: Bart V. A. <bva...@ac...> - 2010-07-05 17:00:17
|
On Mon, Jul 5, 2010 at 12:20 PM, Konstantin Serebryany <kon...@gm...> wrote: > > On Mon, Jul 5, 2010 at 2:13 PM, Bart Van Assche <bva...@ac...> wrote: > > On Mon, Jul 5, 2010 at 11:32 AM, Konstantin Serebryany > > <kon...@gm...> wrote: > >> > >> +da...@go... > >> Julian, Bart, > >> > >> I've prepared a (draft) message to libstdc++. > >> Please review it. You are welcome to edit it directly too. > >> http://code.google.com/p/data-race-test/wiki/AtomicReferenceCounting > > > > While I welcome such an initiative, I have a few comments: > > - Asking the libstdc++ maintainers to use ANNOTATE_HAPPENS_BEFORE() > > and ANNOTATE_HAPPENS_AFTER() is not an option as long as there exist > > three different implementations of these macros (one in > > ThreadSanitizer, one in Helgrind and one in DRD). > > Agree. Shall we do something with this? I see three possible approaches: (a) Create a new shared library that contains at least a function for atomically decrementing a reference counter and kindly ask all authors of libraries that use reference-counted objects to use that new library for manipulating reference counts. That way data-race detection tools can recognize reference counters and the ordering imposed by decrementing reference counters by intercepting a single function. (b) Ask all authors of libraries that use reference-counted objects to add and export a function that does nothing else than decrementing a reference count. Also agree with these authors about a naming scheme for such a function such that all such functions can be intercepted via a single wildcard pattern in Valgrind. (c) Ask library authors to insert a Valgrind client request before each reference counter decrement and after each reference counter decrement that set the reference count equal to zero. We should also consider wherever reference counts are decremented in inline functions in public header files, to make the above behavior configurable via preprocessor symbol. Certain behavior of libstdc++ is already configurable via preprocessor symbols, e.g. via the preprocessor symbol GLIBCXX_FORCE_NEW. We can either try to agree upon one of the above three approaches or ask the libstdc++ authors for their opinion. Note: as is documented in the header file <valgrind/valgrind.h>, the preprocessor symbol NVALGRIND controls whether or not Valgrind client requests are inserted in the output code. Bart. |