Re: Guarantee of side-effect free assignment
On Oct 8, 9:26 pm, "Alf P. Steinbach" <al...@start.no> 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).
I think that there is really only one issue: is calling the
constructor a side effect, or is it necessary to determine the
"value" of the expression. While my gut feeling is that this is
very much like something like ++i, where the "value" is
independent of the write, some argument could be made that the
"value" is a pointer to a fully constructed object, and so
doesn't exist until the constructor has finished. There's also
James Dennett's arguments, that (roughly speaking), the standard
doesn't really mean what it says when it says that side effects
can be re-ordered; that this is really a consequence of the fact
that no legal C++ code can detect the reordering, *except* here,
and so the freedom to re-order---a consequence of the "as-if"
rule---doesn't apply here.
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'd be very cautious about bringing the Meyers/Alexandrescu
discussion in here. They were interested solely with threading
issues.
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.
What they're interested in, in that article, is the order of
operations as seen from another thread. Even if the compiler
doesn't reorder, another thread is not guaranteed to see the
writes in the same order as they occur in the thread making
them. That's a whole different can of worms, which the
standards committee is currently addressing.
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>
Which really only applies to multithreaded code, sort of. The
point is that the analysis the compiler does to check whether
the as-if rule applies only concerns the single thread, and---if
the compiler is Posix compliant as well as C++ compliant---the
threading primitives specified in the Posix standard.
The other point, of course, is that if the compiler is to
guarantee the order writes will be seen by other threads, it
must issue additional instructions: membar or fence or whatever.
Which slow execution down considerably---to my knowledge, none
do (even when volatile is used, which means that volatile
doesn't give the expected guarantees in a multi-threaded
environment either).
Anyway, I don't think there arguments are relevant 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.
And the acknowledgments for the article include quite a few well-known
people as reviewers, presumably catching a fundamental mistake like
that, if it was a mistake: "Pre-publication drafts of this article were
reviewed by Doug Lea, Kevlin Henney, Doug Schmidt, Chuck Allison, Petru
Marginean, Hendrik Schober, David Brownell, Arch Robison, Bruce Leasure,
and James Kanze. Their comments, insights, and explanations greatly
improved the presentation of the paper and led us to our current
understanding of DCLP, multithreading, instruction ordering, and
compiler optimizations. After publication, we incorporated comments by
Fedor Pikus, Al Stevens, Herb Sutter, and John Hicken."
It depends:-). The article concerned a particular idiom for use
in multithreaded code. Scott asked me to review it because of
the multithreaded issues (particularly the problems related to
processor reordering of reads and writes), and that's what I
concentrated on. I imagine that this is true for most of the
other reviewers as well.
In particular, there was no real consideration (on my part, at
least) as to what might happen if the constructor threw an
exception. The rewrite discussed above concerned the
application of the "as-if" rule by a perfectly clairvoyant
compiler, and apply regardless of the answer to this thread.
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. ;-)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
---
[ 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 ]