3 ms·

Interesting. This appears to solve a more general problem, which is: how to create a barrier against inter-procedural optimization and dead code elimination. I

Interesting. This appears to solve a more general problem, which is: how to create a barrier against inter-procedural optimization and dead code elimination. I wonder if this trick could also be used to solve the double-checked locking problem. From the quintessential DCLP paper (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf): Consider again the line that initializes pInstance: pInstance = new Singleton; This statement causes three things to happen: Step 1: Allocate memory to hold a Singleton object. Step 2: Construct a Singleton object in the allocated memory. Step 3: Make pInstance point to the allocated memory. [...] 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++*. But Colin's pattern here seems to be a way of indeed guaranteeing this. The volatile function pointer is a barrier against inter-procedural optimization: if the function must be called, then step 3 cannot possibly be performed before steps 1 and 2. (There might still be necessary hardware barriers that are missing, and the lack of a memory model for pre-C11/C++11 probably makes it all technically undefined behavior anyway. But the key sequential ordering constraint that was claimed inexpressible in C and C++ appears to indeed be expressible with this trick, if indeed the trick works for guaranteeing a call to memset).

nitrogen 12y ago
if the function must be called, then step 3 cannot possibly be performed before steps 1 and 2. So just to clarify, there's no way the compiler could do "1, 3, 2" instead of "1, 2, 3"? It seems a naive implementation of a compiler could store the pointer to the allocated memory in the pInstance variable before calling the constructor, rather than using a temporary location for the pointer (e.g. a register). Does C++11 and later specify otherwise?
- haberman 12y ago
  I should have been more specific. To use Colin's trick with this pattern, you would need to write a separate function (like InitializeSingleton()) that calls the constructor and returns the pointer. If InitializeSingleton() is impossible to inline/optimize, which is the goal of Colin's trick, then 1 and 2 must happen before 3, because 3 cannot happen until the function has been called and returns, and the function does steps 1 and 2.

nitrogen 12y ago

if the function must be called, then step 3 cannot possibly be performed before steps 1 and 2. So just to clarify, there's no way the compiler could do "1, 3, 2" instead of "1, 2, 3"? It seems a naive implementation of a compiler could store the pointer to the allocated memory in the pInstance variable before calling the constructor, rather than using a temporary location for the pointer (e.g. a register). Does C++11 and later specify otherwise?

haberman 12y ago
I should have been more specific. To use Colin's trick with this pattern, you would need to write a separate function (like InitializeSingleton()) that calls the constructor and returns the pointer. If InitializeSingleton() is impossible to inline/optimize, which is the goal of Colin's trick, then 1 and 2 must happen before 3, because 3 cannot happen until the function has been called and returns, and the function does steps 1 and 2.