Re: [Valgrind-users] helgrind and c++ atomic_flag
On mardi 25 septembre 2018 16:17:48 CEST John Perry wrote: > > On Sep 25, 2018, at 7:02 AM, Tom Hughes wrote: > > > > 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. > > Thank you! This comes as a huge relief, because I first noticed the issue in > a program I was writing where I used that approach and worried I was doing > something very, very bad. Now I can rest easy. Or at least easier. You want to use TSAN (thread-sanitizer) instead (preferably with clang and libc++, in my experience), which supports atomic operations. Sorry for advertising a competing solution on the valgrind mailing-list ;-) I admit I'm much less of a helgrind fan since tsan started to work well. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind and c++ atomic_flag
> On Sep 25, 2018, at 7:02 AM, Tom Hughes wrote: > > 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. Thank you! This comes as a huge relief, because I first noticed the issue in a program I was writing where I used that approach and worried I was doing something very, very bad. Now I can rest easy. Or at least easier. regards john perry -- John Edward Perry, III Associate Professor, Dept of Mathematics, University of Southern Mississippi Undergraduate Program Lead, Mathematics BS john.pe...@usm.edu A man with no regrets has either no past or no conscience. ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] helgrind and c++ atomic_flag
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 (t...@compton.nu) http://compton.nu/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
