Re: Am I or Alexandrescu wrong about singletons?

On Mar 23, 7:05 am, "Leigh Johnston" <le...@i42.co.uk> wrote:


No. You must use proper synchronization to guarantee a "happens-
before" relationship, and volatile does not do that portably. Without
the proper synchronization, the write to a variable in one thread,
even a volatile write, may never become visible to another thread,
even by a volatile read, on some real world systems.

"Common sense" would be to listen to the people who wrote the
compilers, such as Intel and gcc, to listen to the writers of the
standard who influence the compiler writers, such as the C++ standards
committee and their website, to listen to well respected experts who
have studied these things in far greater detail than you and I, to
read old papers and correspondence to understand the intention of
volatile (which does not include threading), etc. It is not "common
sense" to blithely ignore all of this and read into an ambiguous
definition in an unrelated standard to get your desired properties (C+
+03 standard does not mention threads so it's not the relevant
standard to look at); it's actually quite unreasonable to do so.

Let me put it like this. Either you're writing on a thread-aware
compiler or you are not. On a thread-aware compiler, you can use the
standardized threading library, which will probably look a lot like
POSIX, WIN32, Java, and C++0x. It will include mutexes and condition
variables (or some rough equivalent, stupid WIN32), and possibly
atomic increments, atomic test and swap, etc. It will define a memory
model roughly compatible with the rest and include a strong equivalent
of Java's "happens-before" relationship. In which case, volatile has
no use (for threading) because the compiler is aware of the
abstractions and will honor them, including the optimizer. In the
other case, when you're using threads on a not-threads-aware compiler,
you're FUBAR. There are so many little things to get right to produce
correct assembly for threads that if the compiler is not aware of it,
even the most innocuous optimization, or even register allocation, may
entirely break your code. volatile may produce the desired result, and
it may not. This is entirely system dependent as you are not coding to
any standard, and thus not portable by any reasonable definition of
portable.

Also note that your (incorrect) reading of the C and C++ standards
makes no mention of a guarantee about reorderings between non-volatile
and volatile, so if thread B in your example changed shared state,
these writes may be moved after the write to "finished", so thread A
could see the write to "finished" but not see the changes to the
shared state, or perhaps only a random portion of the writes to the
shared state, a inconsistent shared state, which is begging for a
crash. So, you could fully volatile qualify all of the shared state,
leading to a huge performance hit, or you could just use the
standardized abstractions which are guaranteed to work, which will
actually work, which will run much faster, and which are portable.

There seems to persist this "romanticized" ideal of "volatile" as
somehow telling the compiler to "shut up" and "just do it", a
sentiment noted by Andrei and Scott in "C++ And The Perils Of Double-
Checked Locking". Please, go read the paper and its cited sources.
They explain it so much better than I could. I'll link to it again
here:
   http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]