|
From: Bart V. A. <bva...@ac...> - 2010-07-08 10:27:14
|
On Thu, Jul 8, 2010 at 12:20 AM, Dave Goodell <go...@mc...> wrote: > > I have some multithreaded code that signals object "completion" with a flag variable. Initially the flag value is non-zero (almost always 1) and one thread (A) will do some work to determine the values for various fields in the object. When thread A is finished with the object, it indicates that the object is complete by setting the flag to zero. This is a one-way transition, the object will be read exclusively by the (guaranteed) single consumer thread (B) and eventually destroyed by thread B. > > I have inserted memory barriers in both the producer's and consumer's code to provide store-release/load-acquire semantics with the flag variable. Well, in the example code at the bottom, I used full barriers, but I think that acquire/release is really all I need. > > These reads and writes are of course flagged by the various valgrind threading tools (helgrind/drd/tsan) as potential races. However I was surprised to find that I could not successfully annotate this sort of behavior in the same way as I would an atomic reference counting scheme. At the bottom of this mail is some example code that illustrates my scenario. The read itself is flagged as racy before the HAPPENS_AFTER annotation. In DRD and TSan, I can at least ANNOTATE_BENIGN_RACE as a last resort, but Helgrind doesn't support this annotation. > > Changing the unconditional write in the producer thread to an atomic decrement makes the annotations work again, as in refcounting. This may be what I use in the end to solve this problem, but I do still want to understand why I can't annotate it correctly. > > 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. Bart. |