Re: Am I or Alexandrescu wrong about singletons?
On Mar 25, 6:20 am, Andy Venikov <swojchelo...@gmail.com> wrote:
Joshua Maurice wrote:
On Mar 21, 2:32 pm, Andy Venikov <swojchelo...@gmail.com> wrote:
<snip>
Here's a brief example that I hope will put this issue to rest:
It does, but not in the way you seem to think:-).
volatile int n;
n = 5;
n = 6;
volatile guarantees (note: no interpretation here, it's just
what it says) that the compiler will issue two store
instructions in the correct order (5 then 6).
Since we're splitting hairs, technically, that's not what the
standard says. What the standard says is that the accesses
implied by the assignment statements will occur in the given
order. For some implementation defined meaning of "access".
(I'll also add my usual complaint. In the standard,
"implementation defined" means that is must be documented. I've
yet to find such documentation, however, for any of the
compilers I've used.)
And that is a very useful quality for multi-threaded programs
that chose not to use synchronization primitives like mutexes
and such.
No it's not. It's quite frequent, in fact, that in the above
scenario, the 5 never makes it to main memory, or even out of
the write pipeline.
Of course it doesn't mean that the processor executes them in
that order, that's why we'd use memory fences. But to stop the
compiler from messing around with these sequences, the
volatile is necessary.
Show me how you use the memory fences, and I'll show you why the
compiler can't move the accesses accross them. There's no way
of getting a memory fence in standard C++, so you've moved the
problem to additional guarantees by the implementation. An
implementation either understands all of the code between the
two assignments (including inline assembler, calls to functions
written in assembler, etc.), and will see the fence and behave
accordingly, or it doesn't (and most don't try), and so it
cannot move the assignments, since it must assume that the code
it doesn't see or understand accesses n.
[...]
Concerning volatile...
Necessary in certain conditions - absolutely."
It is certainly necessary in certain conditions. Both the C
standard and Posix, for example, require it when a variable is
accessed from both the main program and a signal handler. And
if it worked as intended (not the case with the compilers I
know), it would be necessary for memory mapped IO (which on the
compilers I know requires assembler in order to guarantee
correct behavior). It's just never never necessary for
communications between threads.
--
James Kanze
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]