Re: [Valgrind-users] Limiting helgrind to finding only write-write conflicts

[David F. <fa...@kd...>]

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...@kd..., http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5