Re: [Valgrind-users] helgrind and c++ atomic_flag

[Tom H. <to...@co...>]

On 25/09/2018 05:44, John Perry wrote:

> When run in helgrind, the C++ example programs at
> 
>      en.cppreference.com/w/cpp/atomic/atomic_flag
> 
> and
> 
>      www.cplusplus.com/reference/atomic/atomic_flag/
> 
> report a bunch of possible data races. For instance,
> 
>      ==24483== Possible data race during read of size 1 at 0x6051F1 by
>      thread #3
>      ==24483== Locks held: none
>      ==24483==    at 0x400E8F: test_and_set (atomic_base.h:176)
>      ==24483==    by 0x400E8F: f(int) (helgrind_spinlock2.cpp:11)
>      ...
>      ==24483== This conflicts with a previous write of size 1 by thread
>      #2
>      ==24483== Locks held: none
>      ==24483==    at 0x400EE6: clear (atomic_base.h:193)
>      ==24483==    by 0x400EE6: f(int) (helgrind_spinlock2.cpp:14)
> 
> Is it correct to conclude that these are false positives? I found a
> lot of discussion in the mailing list on atomic operations but nothing
> "recent" seemed to address the C++ standard library.

I don't believe helgrind makes any attempt to observe atomic
operations so it is entirely unaware of them and of any effect
they might have on the thread correctness of a program.

It would be hard to do because where the compiler is able to
generate direction instructions for the atomic there will be no
function call to intercept, and as there won't necessarily be a
one-one mapping from atomic operations to CPU instructions it
is hard to determine what the original operation was by
observing the instruction stream.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/