Re: Am I or Alexandrescu wrong about singletons?
On Mar 29, 7:46 am, Herb Sutter <herb.sut...@gmail.com> wrote:
On Sun, 28 Mar 2010 15:25:46 CST, James Kanze <james.ka...@gmail.com>
On Mar 26, 12:33 am, Herb Sutter <herb.sut...@gmail.com> wrote:
Please remember this: Standard ISO C/C++ volatile is useless
for multithreaded programming. No argument otherwise holds
water; at best the code may appear to work on some
compilers/platforms, including all attempted counterexamples
I've seen on this thread.
I agree with you in principle, but do be careful as to how
you formulate this. Standard ISO C/C++ is useless for
multithreaded programming, at least today. With or without
volatile. And in Standard ISO C/C++, volatile is useless for
just about anything;
All of the above is still true in draft C++0x and C1x, both of
which have concurrency memory models, threads, and mutexes.
Huh? "Standard ISO C/C++" is useless for multithreaded
programming today because as far as the standard is concerned,
as soon as there's more than one thread, you have undefined
behavior. Unless things changed a lot while I wasn't looking
(I've not been able to follow things too closely lately), C++0x
will define threading, and offer some very useful primitives for
multithreaded code. Considerably more than boost::thread, which
was already very, very useful.
it was always intended to be mainly a hook for implementation
defined behavior, i.e. to allow things like memory-mapped IO
while not imposing excessive loss of optimizing posibilities
Right. And is therefore (still) deliberately underspecified.
As it should be.
In theory, an implementation could define volatile in a way that
would make it useful in multithreading---I think Microsoft once
proposed doing so in the standard.
Yes, back in 2006 I briefly agreed with that before realizing
why it was wrong (earlier in this thread you correctly said I
supported it and then stopped doing so).
In my opinion, this sort of violates the original intention
behind volation, which was that volatile is applied to a
single object, and doesn't affect other objects in the code.
But it's certainly something you could argue both ways.
No, it's definitely wrong.
Well, I basically agree with you there. But there are degrees
of wrong: it's not wrong in the same sense as claiming that an
mfence instruction doesn't affect cache synchronization on an
Intel is wrong.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]