Re: Guarantee of side-effect free assignment

* Greg Herlihy:


Here the dependency "on the value returned by the new-expression" is, as
I understand it, really a dependency on the possible
not-returning-a-value by a throwing constructor, and otherwise the
dependency is only on the allocator function call (permitting the
reordering, your option (a) for that function call).

Assuming the above argument holds, then, the Meyers/Alexandrescu
assumption[1] also holds, that the reordering shown below is permitted
when the compiler can prove that the constructor doesn't throw.

   Singleton* Singleton::instance()
   {
       if (pInstance == 0)
       {
           Lock lock;
           if (pInstance == 0)
           {
               pInstance = // Step 3
               operator new(sizeof(Singleton)); // Step 1
               new (pInstance) Singleton; // Step 2
           }
       }
       return pInstance;
   }

   <quote>
   there are conditions under which this transformation is legitimate.
   Perhaps the simplest such condition is when a compiler can prove that
   the Singleton constructor cannot throw (e.g., via post-inlining flow
   analysis), but that is not the only condition. Some constructors that
   throw can also have their instructions reordered such that this
   problem arises.
   </quote>

I'm now quoting in full what the article actually says because earlier
in the thread I erred by paraphrasing the above quote, saying that it
stated that the rewrite can "only" occur when the constructor is
provably non-throwing, which is less permissive than the actual text.

So that seems to leave an interesting possibility of safe double-checked
locking pattern using a constructor that can't be proven by the compiler
to not throw -- which is easy enough to arrange, e.g. by dependency on
dynamic data, e.g. checking a global initialized from a main() argument.

   S::S()
   {
       // Some initialization here, then:
       if( strcmp( ::dynData, ::someUuid ) == 0 ){ throw "never"; } }
   }

Yet, the Meyers/Alexandrescu article states categorically that

   <quote>
   DCLP will work only if steps 1 and 2 are completed before step 3 is
   performed, but there is no way to express this constraint in C or
   C++.
   </quote>

"there is no way to express this constraint" -- i.e. not even the
S::S() constructor shown above is safe from willy-nilly assignment of
result pointer before the constructor body's execution has finished.