Re: Am I or Alexandrescu wrong about singletons?
On Mar 21, 9:32 pm, Andy Venikov <swojchelo...@gmail.com> wrote:
Joshua Maurice wrote:
So is volatile sufficient - absolutely not. Portable? - hardly.
Is it necessary in certain cases - absolutely.
Perhaps I was a bit too strong in my statement. I did intent to say
"for portable uses".
However, for future reference, what compilers of what
versions on what platforms implement volatile with these
semantics? I would like to research these claims to be
better prepared in this discussion and future ones. Are any
of these implementations not x86? These implementations
really don't provide a sane threading interface and force
the use of the volatile keyword for threading? Weird.
I'm sorry if I wasn't clear in my previous post, but I was
talking about standard volatile behavior.
Which is practically entirely implementation defined.
The standard places a requirement on conforming
implementations that:
1.9.6
The observable behavior of the abstract machine is its
sequence of reads and writes to volatile data and calls to
library I/O functions
1.9.7
Accessing an object designated by a volatile lvalue (3.10),
modifying an object, calling a library I/O function, or
calling a function that does any of those operations are all
side effects, which are changes in the state of the execution
environment. Evaluation of an expression might produce side
effects. 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
1.9.11
The least requirements on a conforming implementation are:
At sequence points, volatile objects are stable in the sense
that previous evaluations are complete and subsequent
evaluations have not yet occurred.
It also fails to define what it means by an access (to a
volatile object) and what it means to be "stable". The C
standard addresses the first by saying that it's implementation
defined.
The C standard also mentions the one of the motivations behind
volatile: memory mapped I/O. Independantly of the standard,
from a QoI point of view, we can expect that it would at least
provide the necessary semantics to support this. Tough luck: it
isn't the case with g++ nor Sun CC (nor, as far as I can tell,
VC++, but I'm less familiar with the semantics of modern Intel
than I am of those of Sparc).
That to me sounds like a complete enough requirement that
compilers don't perform optimizations that produce
"surprising" results in so far as observable behavior in an
abstract (single-threaded) machine are concerned.
For single-threaded machines, volatile does have some defined
semantics. For example, in a signal handler, you can assign to
a variable of type sigatomic_t volatile (and that's about it, as
far as the C++ standard is concerned---Posix guarantees
considerably more, but still a lot less than is often assumed).
Volatile is significant with regards to communication between
signal handlers and the rest of the program.
This requirement happens to be very useful for multi-threaded
programs that can augment volatile with hardware fences to
produce meaningful results.
How do you specify a hardware fence in C++? Anything in the
respect is implementation defined. And all of the
implementations do the right thing, in one way or another:
whatever you do to specify a fence also inhibits (or can be made
to inhibit) code movement accross the fence.
--
James Kanze
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]