|
From: Bart V. A. <bar...@gm...> - 2009-05-30 11:35:41
|
On Fri, May 29, 2009 at 12:58 PM, Konstantin Serebryany <kon...@gm...> wrote: > Do you plan to support annotations (aka client requests) in Helgrind > and DRD in a compatible way (and possibly, in a way compatible with > ThreadSanitizer)? > Something like http://code.google.com/p/google-perftools/source/browse/trunk/src/base/dynamic_annotations.h, > or completely different. > Our experience shows that even a pure-happens-before race detector is > completely useless w/o annotations if your code has lock-less > synchronization and hundreds of benign races. A few remarks about the semantics of the ANNOTATE_* macro's: * I do not really like ANNOTATE_PUBLISH_MEMORY_RANGE. The comment above this macro says more or less that any other thread may access the published memory range safely after it has been published. However, no matter which synchronization instructions have been issued by the publishing thread, a consumer thread may only access the published memory safely after proper synchronization with the publishing thread. So my proposal is to remove this annotation and to use ANNOTATE_MUTEX_IS_USED_AS_CONDVAR instead. * Are the ANNOTATE_PCQ_* macro's really needed ? I could not find any test code for these annotations inside ThreadSanitizer. * A size argument is missing for the ANNOTATE_BENIGN_RACE*(), ANNOTATE_EXPECT_RACE() and ANNOTATE_TRACE_MEMORY() macro's. Do these macro's apply to a single address, a range of four bytes or a range of eight bytes ? Choosing any of these three range sizes for all these macro's won't give the expected semantics for at least one of these macro's. Bart. |