On Sunday 26 August 2012 11:28:06 Julian Seward wrote: > On Sunday, August 26, 2012, David Faure wrote: > > Thiago expects that helgrind can't autodetect this case and that helgrind- > > macros markup is needed in Qt, I'm fine with adding that if you guys agree > > -- after you show me how by modifying the attached example :-) > > IIUC then, QBasicAtomicInt::{loadAcquire,storeRelease} just does normal > loads and stores of an int. Right?
Yep (on x86). This whole API exists so that other architectures can get another implementation. > What atomicity properties are you expecting onDemandNumber() to have? > Viz, how is onDemandNumber supposed to behave when you have multiple > threads doing it at the same time on the same location? static int onDemandNumber() { static QBasicAtomicInt sharedInt = { 0 }; if (!sharedInt.loadAcquire()) { // some calculation goes here sharedInt.storeRelease(42); } return sharedInt.loadAcquire(); } I think the point is that the first call to loadAcquire() should either return 0 or 42, but never some intermediate value due to a write in progress. Hmm, I see the point though. This *is* racy by design, since you don't know if you'll get 0 or 42, if another thread is running at the same time. The only thing is, we know it's fine to get either one, since we'll simply do the calculation twice if two threads get 0 at the same time. Overall this is more performant than using a mutex every single time this is called. I'm not sure what can be done then, to avoid a helgrind warning. I presume the only solution is to annotate onDemandNumber() itself, not QBasicAtomicInt. I.e. annotate all uses of QBasicAtomicInt where the overall logic makes it safe, in order to still be able to detect unsafe uses... (like load, increment, store). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users