Re: Guarantee of side-effect free assignment
Alf P. Steinbach wrote:
* Greg Herlihy:
The program reaches plenty of sequence points between the evaluation
of the new-expression and the completion of the assignment operation.
As the Standard itself points out, a new expression makes a function
call (actually, several of them). And a C++ program arrives at a
sequence point whenever a called function is entered - and arrives at
another upon exit. So, based on the Standard's definition of a
sequence point:
"At certain specified points in the execution sequence called sequence
points, all side effects of previous evaluations shall be complete and
no side effects of subsequent evaluations shall have taken place."
intro.execution/7]
we can conclude that - at the point when the new-expression makes its
function call - the assignment to p must a) either be over or b) must
have not yet begun. Well, since the value assigned to "p" is dependent
on the value returned by the new-expression, the only possibility is
that the assignment to "p" must fall in the evaluations "not-yet-
started" category. Therefore we are assured that when the function
call is made, p will still have its last-assigned value (the null
pointer constant).
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>
I think one of the problems with your solution with a randomly throwing
constructor could be a compiler can still rewrite it like this:
Singleton* Singleton::instance()
{
if (pInstance == 0)
{
Lock lock;
if (pInstance == 0)
{
// we know pInstance is 0 here
pInstance = // Step 3
operator new(sizeof(Singleton)); // Step 1
try {
new (pInstance) Singleton; // Step 2
} catch(...) {
delete (void*)pInstance;
pInstance=0;
throw;
}
}
}
return pInstance;
}
And this transformation is legal (at least I think) as long as
Singleton::Singleton() (even in case of an exception) doesn't call
Singleton::instance() (and the allocation and deallocation function
likewise). You could only see the pointer to the non-constructed from an
async signal (but that's OK, because even the pointer is not sig_atomic_t,
so can be anything in an async signal) or from a different thread, but the
standard doesn't say anything about threads.
Even if you somehow forced your compiler not to rewrite the code in any
malicious way, you'd still need some memory barrier after the constructor,
but before the assignment takes place, otherwise other threads might see
the object, which was initialised, but the stores that initialised it are
somewhere lagging in the hardware. You need something like
Singleton* Singleton::instance() {
if (pInstance == 0) { // 1st test
Lock lock;
if (pInstance == 0) { // 2nd test
Singleton* tmp=new Singleton;
/* memory barrier */ volatile __asm ("mfence\n");
pInstance = tmp;
}
}
return pInstance;
}
This way, pInstance, if not null, points always to a fully constructed
object (and because of the barrier, everybody on the bus sees it), is never
assigned twice (because of the lock) and unless construction fails, every
call to instance() returns a valid (and the only one) object. However,
that's nonstandard, but the standard doesn't say anything about threads so
we're stuck here.
"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.
[snip]
So, I'm at a loss, since I now find your argument, that the assignment
to result pointer has to happen after the constructor body's execution
if the constructor can throw, quite convincing: I started writing a
rebuttal but had to delete and write this instead. ;-)
I don't think that's true - certainly, the compiler has only to ensure the
execution goes as-if the assignment appeared after the construction. Which
means you could not see the unconstructed object in your original example -
the one where you called p->foo() - partly because the result of
new-expression is a pointer to a constructed object, and if construction
fails (constructor throws), the object is deleted, therefore there is no
pointer to it which could be assigned to p. However, if the compiler
reorders the assignment and you just cannot see it from inside of the
program, you cannot prevent that.
Jiri Palecek
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]