Re: Singleton_pattern and Thread Safety
On Dec 12, 12:30 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Dec 11, 11:57 am, "Chris M. Thomasson" <cris...@charter.net> wrote:
"Leigh Johnston" <le...@i42.co.uk> wrote in message
news:aI-dnTRysdoEVJ7QnZ2dnUVZ7sSdnZ2d@giganews.com...
On 11/12/2010 18:47, Chris M. Thomasson wrote:
[...]
Thanks for the info. At the moment I am only concerned
with IA-32/VC++ implementation which should be safe.
FWIW, an atomic store on IA-32 has implied release memory
barrier semantics. Also, an atomic load has implied acquire
semantics. All LOCK'ed atomic RMW operations basically have
implied full memory barrier semantics:
http://www.intel.com/Assets/PDF/manual/253668.pdf
(read chapter 8)
Also, latest VC++ provides acquire/release for volatile load/store
respectively:
http://msdn.microsoft.com/en-us/library/12a04hfd(v=VS.100).aspx
(read all)
So, even if you port over to VC++ for X-BOX (e.g., PowerPC),
you will get correct behavior as well.
Therefore, I don't think you even need the second lock at
all. If you are using VC++ you can get away with marking the
global instance pointer variable as being volatile. This
will give release semantics when you store to it, and
acquire when you load from it on Windows or X-BOX,
Itanium...
Or, you know, you could just do it "the right way" the first time and
put in all of the correct memory barriers to avoid undefined behavior
according to the C++ standard in order to well, avoid, undefined
behavior.
Until C++0x becomes reality, there is no "right way" in C++.
One reasonably portable way of getting memory barriers is to use
explicit locks; this will have a run-time impact. (Chris and
I have discussed this in the past.) Whether that run-time
impact is significant is another question---roughly speaking
(IIRC), Chris has developed a solution that will use one less
barrier than a classical mutex lock (which requires a barrier
when acquiring the lock, and another when freeing it). In the
absolute, a barrier is "expensive" (the equivalent of 10 or more
normal instructions?), but a lot depends on what else you're
doing; I think that in most cases, the difference will be lost
in the noise.
It's not like it will actually put in a useless no-op when
using the appropriate C++0x atomics as a normal load on that
architecture apparently has all of the desired semantics. Why write
unportable code which you have to read arch manuals to prove its
correctness when you can write portable code which you can prove its
correctness from the much simpler C++0x standard?
Moreover, are you ready to say that you can foresee all possible
compiler, linker, hardware, etc., optimizations in the future which
might not exist yet, and you know that they won't break the code?
Sure, the resultant assembly output is correct at the moment according
to the x86 assembly docs, but that is no guarantee that the C++
compiler will produce that correct assembly in the future. It could
implement cool optimizations that would break the /already broken/ C++
code. This is why you write to the appropriate standard. When in C++
land, write to the C++ standard.
I strongly disagree with your implications Chris that Leigh is using
good practice with his threading nonsense non-portable hacks,
especially if/when C++0x comes out and is well supported.
If/when C++0x comes out, obviously, you'd want to use it. Until
then, if you really do have a performance problem, you may have
to live with non-portable constructs. (At present, anything
involving threading is non-portable.) Leigh, of course,
disingenuously didn't mention non-portability in his initial
presentation of the algorithm (which contained other problems as
well); Chris is generally very explicit about such issues.
PS: If you are implementing a portable threading library, then
eventually someone has to use the non-portable hardware specifics.
However, only that person / library should have to, not the writer of
what should be portable general purpose code.
PPS: volatile has no place in portable code as a threading primitive
in C or C++. None. It never has. Please stop perpetuating this myth.
Microsoft has extended the meaning of volatile (starting with
VS 2010?) so that it can be used. This is a Microsoft specific
extension (and on the web page Chris sites, they explicitly
present it as such---this isn't the old Microsoft, trying to
lock you in without your realizing it). C++0x will provide
alternatives which should be portable, but until then...
--
James Kanze