|
From: Konstantin S. <kon...@gm...> - 2009-06-01 08:29:14
|
On Sun, May 31, 2009 at 11:14 PM, Bart Van Assche <bar...@gm...> wrote: > On Sat, May 30, 2009 at 9:12 PM, Bart Van Assche > <bar...@gm...> wrote: >> 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. >> >> Another remark: I suggest to remove the macro's >> ANNOTATE_CONDVAR_WAIT() and ANNOTATE_CONDVAR_SIGNAL() but to keep >> their aliases ANNOTATE_HAPPENS_BEFORE() and ANNOTATE_HAPPENS_AFTER(). >> The names of the first two macro's are really confusing: these two >> macro's are a.o. used to annotate ordering constraints between >> mutexes(!) in racecheck_unittest.cc. > > Please ignore the above comment -- I was misled by the statement > ANNOTATE_CONDVAR_SIGNAL(&mu) in racecheck_unittest.cc. By this time I > figured out that &mu is not the address of a mutex but the address of > a condition variable. The parameter of ANNOTATE_CONDVAR_ is any pointer. Since I introduced the HAPPENS_BEFORE/AFTER aliases, CONDVAR annotations are supposed to be used only with cond vars (which is only required in hybrid mode). The aliases are there just to avoid confusion. --kcc > > Bart. > |