Re: [Valgrind-users] helgrind and double checked initialization

[Julian S. <js...@ac...>]

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