On Tuesday 08 October 2013 19:34:03 Phil Longstaff wrote:
I don't see any command line options which limit helgrind to ignoring
read/write or write/read conflicts and only displaying write/write
conflicts. Would that be hard to add?
We have situations where we think only 1 thread updates some counter, and
periodically, another thread reads the value for display. If there's a
conflict, we don't really care whether the display shows the before or the
after value. However, we are interested in knowing if some other code path
tries to update the value i.e. we care about write/write conflicts.
A read-write conflict is still a race condition, which leads to undefined
behavior according to the C++11 standard. On some non-x86 platforms, you could
end up with the displayed value always being 0, for instance, if the CPU
running that thread keeps getting it from its outdated cache. Without mutexes
or atomic operations, there's no guarantee that cache will ever get updated.
My advice is to use std::atomic_int -- which provides exactly the behavior
you're hoping to get (we don't care whether the display shows the before or
the after value).
This being said, helgrind might be missing suppressions for atomic_int (the
same way I'm using suppressions for Qt's QAtomicInt) - since on the special
case of x86, the two can't be distinguished by helgrind.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
