Re: Sequencing dynamic initialization safely
Manfred von Willich ha scritto:
Ganesh wrote:
About as much complexity as the "const" qualifier??? That's VERY much,
then. Think about const-correctness... it's a revolution that haven't
been fully digested yet by a lot of programmers. I was expecting
something really simpler...
Well, it gives some indication. On the surface, const-qualification is
simple for the programmer (... except that certain counter-intuitive
examples keep popping up), and moderately simple for the compiler (...
except that the rules turned out to be more complex than most compiler
writers initially suspected). My suggestion is also simple on the
surface, and I hope the subterranean complexity does not grow as much.
I have read your proposal and although I have to admit that not
everything is clear to me, it looks very complex to implement to me. Of
course as I am not a compiler developer I can be wrong, but that's the
feeling I get.
I am going to start back-to-front, by giving two different sets of
defaults (to provide a context for thinking about how it will seem to
the programmer). Naturally, standardization will have to choose only
one default (i.e. what happens when no keywords are applied).
Default behaviour A: All dynamic initialization is ordered safely, at
the cost of some overhead. The programmer does not have to worry about
it until optimisation is needed. Consequence: most programmers will
remain unaware of the possibility of getting rid of most of this
overhead, but no new warnings will appear (convenient).
Unacceptable. It violates the C++ golden rule "don't pay for what you
don't use". Moreover, existing valid code recompiled with a new compiler
might have a decrease in performances and/or increase in code bloat.
That's not inherently a bad thing, but a lot (if not most) programmers
will just disable the feature in fear of the increased overhead, just as
they still do for EH and RTTI.
Default behaviour B: All dynamic initialization is done without added
overhead. When the compiler cannot determine whether use of the an
object is safe, it generates a warning/error. The programmer can then
go about inserting qualifying keywords to indicate what initialization
is safe, and when to add overhead to make it safe. When a warning-free
state is reached, the program is safe. If overhead had to be added,
the program could originally have generated undefined behaviour,
depending on the order of initialization of the translation units
determined by the linker. Consequence: programmers will become savvy
to the issue very quickly, coached by the warnings.
Issuing errors is not unacceptable, because it might break existing
code. You might argue that the code would have been buggy anyway, but
that depends on the accuracy of the detection algorithm. If there's even
one case that proves a false positive, then we can't follow this path.
Issuing warnings might be a better solution, although I'm not very fond
of it.
The approach is as follows:
<approach snipped>
I couldn't follow all of it. What bother me most is that this kind of
approach will tend to "creep" into everything. You say "A safe function
is disallowed from accessing any unsafe variable or function." What
about calling through a function pointer or a pointer to member function
or, even worst, through a tr1::function object? I'm not sure the
compiler could be able to track all this unless every piece of code you
write is made "safe-aware". Again, I could be wrong...
Multi-threading requires a mutex in the initialization routine (this is
easily proved - there has to be a mechanism to halt all but one thread
until initialization is complete). This in turn gives rise to the
issue of deadlocking, which I haven't thought through fully (though I
think it is only possible when multi-threaded applications have cyclic
guarded initialization, which will generate pathological behaviour on
every run (detection, stack overflow or deadlock). Note that the mutex
should only be used AFTER the flag is tested, which means that the
execution overhead is only a test-and-jump once the variable has been
fully initialized.
Ahhh! Multithreading. This issue is completely different. I'm sorry but
I don't want to enter this discussion. I did it in the past, you may
google for that if you want. Fact is that you may search the C++
standard for the word "thread" and it occurs only once in 15.1/2, a
context that is unrelated to parallel processing. The standard, as it is
now, does not mention multithreaded applications. Until it does, it
doesn't make any sense to speak about initialization of static variables
in such an environment.
A side note: How many people are aware that local static variables are
typically implemented as what I call variables with guarded dynamic
initialization?
The only thing that counts is that, with a few exceptions, static local
variables are initialized "the first time control passes through its
declaration". How that is accomplished is not important. However, I
remember I read about guarded initialization in at least two books.
Except that I t think that a mutex is typically not
used - certainly not by VC6.0. In this compiler, cyclic dependencies
lead to undefined behaviour, but no stack overflow (i.e. it is not
trivially diagnosed), and they are NOT thread safe. Unfortunate timing
of thread switching can lead to double initialization and to use of the
pre-initialized state. GCC fans: you might want to check whether GCC
uses a mutex. If not, local static variables are either unsafe in for
use in dynamic initialization or multi-threaded contexts (which depends
upon the "when" of initialization selected by the compiler).
A mutex is not used because the standard doesn't mandate it and that's
again because the C++ execution models does not consider multithreading.
Yes, initialization of local static variable is not thread-safe. The
issue has been brought up in this newsgroup and in
comp.lang.c++.moderated quite a few times. You may want to google the
archives.
Regards,
Ganesh
---
[ 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 ]