Re: Am I or Alexandrescu wrong about singletons?
Leigh Johnston wrote:
"Joshua Maurice" <joshuamaurice@gmail.com> wrote in message
news:900580c6-c55c-46ec-b5bc-1a9a2f0d76f5@w9g2000prb.googlegroups.com...
Obviously the volatile keyword may not cause a memory barrier
instruction to be emitted but this is a side issue. The combination
of a memory barrier and volatile makes multi-threaded code work.
No. Memory barriers when properly used (without the volatile keyword)
are sufficient.
No. Memory barriers are not sufficient if your optimizing compiler is
caching the value in a register: the CPU is not aware that the register is
referring to data being revealed by the memory barrier.
Actually, memory barriers in my understanding go both ways. One is to tell
the CPU that it must not cache/optimise/reorder memory accesses. The other
is to tell the compiler that it must not do so either. You can add the
former via libraries to an existing compiler, but you can't do the latter
without compiler support. That said, volatile often had the same effect as
part 2 of the puzzle in legacy compilers, so smart hackers simply used
that.
I never said volatile was a panacea but is something that is probably
required when using an optimizing compiler. If your C++ compiler has
memory barrier intrinsics it might be able to ensure volatile is not
required but this is also non-standard.
If your compiler is aware of multithreading, you don't need volatile. If it
isn't, even volatile doesn't guarantee you that it will work. At the very
best, using volatile for the compiler and some other instructions for the
CPU works as a workaround to get a not thread-aware compiler to play nice.
Uli
--
Sator Laser GmbH
Gesch??ftsf??hrer: Thorsten F??cking, Amtsgericht Hamburg HR B62 932
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]