On Tuesday, August 28, 2012, Patrick J. LoPresti wrote: > On Sun, Aug 26, 2012 at 2:06 AM, David Faure <fa...@kde.org> wrote: > > Marc Mutz said " > > The standard says it's racy, but the implementation of > > std::atomic::load(memory_order_acquire) won't look different. Simple > > reads and writes on x86 are already sequentially consistent. > > I do not think this is true. Loads on x86 do have acquire semantics, > and stores do have release semantics, but that is not the same as > sequential consistency. If loads and stores on x86 were "already > sequentially consistent", there would be no need for the mfence > instruction...
On re-reading this, I am wondering now if Marc meant "x86 TSO (total store order)" when he said "sequential consistency". IIRC from Hennessy and Patterson, no real processor provides sequential consistency because to do so precludes the use of per-processor store queues, and without those a high performance memory system is more or less impossible. x86 does provide TSO, a guarantee that stores by one processor appear to other processors in the same order. But that's a weaker guarantee than sequential consistency. > Out of curiosity, is Helgrind expected to generate errors for > correctly-implemented lock-free algorithms? (That is, algorithms with > correct memory barriers and no mutexes?) It will generate false errors in cases where it can't "see" all of the happens-before relationships between threads. By default it ships with intercepts that correctly detect those relationships for POSIX pthreads (by intercepting pthread_mutex_lock, unlock, etc). However, if you create your own locking primitives or do synchronisation some other way, there's a flexible set of client requests for marking up code, so it can indeed be checked. I did this just the other day for home-rolled spinlocks. J ------------------------------------------------------------------------------ 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
