Re: Is this reordering valid?
pongba@gmail.com wrote:
In "C++ and the Perils of Double-Checked Locking", Scott Meyers and
Andrei Alexandrescu brought up a good point on how it is impossible to
avoid the reorder problem.
But I think there might be something that I would disagree. Look at the
code below:
C* pc = new C();
It involves three steps:
1. allocation of raw memory
2. construction of C
3. assignment
The question is, is it really allowed by the standard that 2 and 3
could be reordered?
In this case, definitely. More generally, however, there are
really two separate issues: is the ordering guaranteed in the
abstract machine, and if it is, does it affect observable
behavior?
I don't think that the standard is really clear about the first.
Any modification of state (writes) in the constructor of C are
side effects, which are guaranteed to occur before the next
sequence point---in this case, at least before returning from
the constructor. On the other hand, calling the constructor
itself is a side effect, and there is no sequence point between
this and the initialization of the pointer. In the absence of a
sequence point, the only thing which can impose order is
dependancy: is the value being assigned dependant on the results
of the call to the constructor. And I think this is arguable
both ways.
In practice, it really doesn't affect the issue raised by Scott
and Andrei. Because there is enough latitude under the as if
rule to allow reordering even if the abstract machine guarantees
the order. The only cases where there might be restrictions is
if 1) the pointer being initialized has static lifetime (and
thus is guaranteed to be null before initialization), and the
constructor (or the initialization expression in general)
accesses it, and 2) the result of the new expression is used in
an assignment (and not an initialization), and the constructor
throws.
Don't forget, too, that the reordering isn't just a compiler
issue. Modern hardware can reorder the accesses as well.
Typically (i.e. I don't know of any exceptions), it will
guarantee full ordering within a single processor, but not
between processors (or "cores" of a multi-core architecture).
Before you start to judge, let me show you this little chunk of code:
struct C{
C()
{
throw std::runtime_exception("...");
}
};
C* pc = 0;
int main(){
try{
pc = new C();
}
catch(...)
{
if(pc) some_library_IO_func(); // observable behavior
}
}
Here, whether step 2 and step 3 are reordered have an definite effect
on the observable behavior.
So, are they still allowed to be reordered?
Open question. Not really relevant to Scott's and Andrei's
point, however:
-- The compiler is presumably capable in many cases of
determining that the constructor cannot throw.
-- The compiler needs to handle roll-back anyway, if the
constructor throws (e.g. call operator delete, etc.), and
could reset the pointer to its original value in such cases.
-- Most importantly, their example concerned multithreaded
code; the other thread could be running on a different
processor, and thus see the writes in a different order than
the compiler issued them.
Preventing the latter in the general case could result in code
running several times slower, and isn't being considered.
(Basically, you'd need to insert fence or membar instructions
around every memory access.)
If this isn't enough, how about qualifying pc with volatile?
Doesn't change anything. At most, qualifying pc with volatile
places constraints on the write to pc; it places absolutely no
constraints on writes to other variables. For volatile to have
any effect on the ordering, you'd have to ensure that all of the
writes in the constructor were through volatile qualified lvalue
expressions as well (and remember, this is *never* volatile
qualified in a constructor---volatile and const do not take
effect until after construction). In addition, the exact
meaning of volatile is implementation defined, and most
implementations (VC++, g++, Sun CC) don't define it to do
anything useful in this respect. (Microsoft has proposed that
it be defined to ensure the correct ordering semantics, but at
present, that is just a proposal before the committee, which
hasn't been accepted, and it isn't what VC++ 8.0 implements,
either.)
--
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
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]