On 25/09/2018 05:44, John Perry wrote:
When run in helgrind, the C++ example programs aten.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 ([email protected]) http://compton.nu/ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
