Just to add my 2 euro-cents (basically Bart said it all already, tho) My impressions are that:
1. Double checked locking is fundamentally broken: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html 2. Even if you verify by hand the resulting machine code, you still need to deal with the fact that, in general, CPU implementations may reorder appearance of stores on other CPUs: if CPU 1 writes location A and then location B, it may be that CPU 2 observes the write to B before it observes the write to A. 3. Proving that your application's correctness is not affected, and continues not to be affected in future changes, by (2), is a big correctness and maintenance burden 4. If you stick to x86/x86_64 CPUs then you might not have to grapple with (2), since AIUI they do not allow such store-reordering I'm pretty sure that double checked locking falls into the "undefined semantics; implementation can do whatever it likes" department w.r.t. the recently ratified C++ new revision (C++11 ?) One good thing about the new standard is that it has something to say about these kinds of racy code fragments, so at least we can reason about them instead of getting bogged down in "well, it seems to work" style discussions. J ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
