Re: Am I or Alexandrescu wrong about singletons?
"Chris Vine" <chris@cvine--nospam--.freeserve.co.uk> wrote in message
news:ceum77-go6.ln1@cvinex--nospam--x.freeserve.co.uk...
On Tue, 23 Mar 2010 08:05:28 CST
"Leigh Johnston" <leigh@i42.co.uk> wrote:
[snip]
Sometimes you have to use common sense:
thread A:
finished = false;
spawn_thread_B();
while(!finished)
{
/* do work */
}
thread B:
/* do work */
finished = true;
If finished is not volatile and compiler optimizations are enabled
thread A may loop forever.
The behaviour of optimizing compilers in the real world can make
volatile necessary to get correct behaviour in multi-threaded
designs. You don't always have to use a memory barriers or a mutexes
when performing an atomic read of some state shared by more than one
thread.
It is never "necessary" to use the volatile keyword "in the real world"
to get correct behaviour because of "the behaviour of optimising
compilers". If it is, then the compiler does not conform to the
particular standard you are writing to. For example, all compilers
intended for POSIX platforms which support pthreads have a
configuration flag (usually "-pthread") which causes the locking
primitives to act also as compiler barriers, and the compiler would be
non-conforming if it did not both provide this facility and honour it.
Of course, there are circumstances when you can get away with the
volatile keyword, such as the rather contrived example you have given,
but in that case it is pretty well pointless because making the
variable volatile as opposed to using normal synchronisation objects
will not improve efficiency. In fact, it will hinder efficiency if
Thread A has run work before thread B, because thread A will depend on a
random future event on multi-processor systems, namely when the caches
happen to synchronise to achieve memory visibility, in order to proceed.
Chris
It is not a contrived example, I have the following code in my codebase
which is similar:
.....
lock();
while (iSockets.empty() && is_running())
{
unlock();
Sleep(100);
if (!is_running())
return;
lock();
}
.....
is_running() is an inline member function which returns the value of a
volatile member variable and shouldn't require a lock to query as it is
atomic on the platform I target (x86). It makes sense for this platform and
compiler (VC++) that I use volatile. Admittedly I could use an event/wait
primitive instead but that doesn't make the above code wrong for the
particular use-case in question. I agree that for other platforms and
compilers this might be different. From what I understand and I agree with
the advent of C++0x should see such volatiles disappear in favour of
std::atomic<>. Not everyone in the real world is using C++0x as the
standard has not even been published yet.
/Leigh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]