|
From: Bart V. A. <bva...@ac...> - 2010-07-08 16:22:44
|
On Thu, Jul 8, 2010 at 5:56 PM, Dave Goodell <go...@mc...> wrote: > On Jul 8, 2010, at 5:27 AM CDT, Bart Van Assche wrote: > >> On Thu, Jul 8, 2010 at 12:20 AM, Dave Goodell <go...@mc...> wrote: > [...] >>> >>> Q1: I know it's potentially error prone in terms of usage and implementation, but I'm attempting something that is basically sane, right? >>> >>> Q2: Is there a way to correctly annotate the store/load pair, ideally across all three tools? Or for helgrind am I stuck with suppressions? >> >> Please check whether the issue described in the following bug report >> affects your test program: >> https://bugs.kde.org/show_bug.cgi?id=243935. > > I can reproduce #243935 on my machine (@r11206). I did not realize that the DRD and Helgrind HB/HA annotations were supposed to be binary compatible, which seems to be what this ticket is saying. I only assumed source level compatibility and rebuilt with different headers between different tool runs. DRD should understand all Helgrind annotations implemented via client requests, but not the other way around. > At the bottom of this email is the result of a run of DRD with USE_DRD defined instead of USE_HELGRIND. It also warns about the "flag" variable, so I don't think I'm being hit by #243935. If you modify your test program such that more than one thread is waiting for the value of the variable "flag" becoming zero, I expect that you will be hit by #243935. > The HB/HA annotations do work for shared_data, but not for the flag variable. This makes sense to me, because I'm only indicating the HA point after the "racy" read. However I don't understand the correct way to annotate this without just telling the tool to ignore races on this memory location. I feel like what I need is an "atomic load" that will be treated the same way as a more complicated atomic operation like CAS or fetch_and_add. The various tools don't seem to have a problem with those operations (undef'ing USE_PLAIN_STORE in the test code makes DRD happy again). There are two ways to get rid of the race report on the flag variable, both which were already mentioned by Konstantin: * Adding an ANNOTATE_BENIGN_RACE() annotation. * Replacing the assignment "flag = 0" by an atomic instruction that sets "flag" to zero. Bart. |