Re: Singleton_pattern and Thread Safety
On Dec 11, 7:57 pm, "Chris M. Thomasson" <cris...@charter.net> wrote:
"Leigh Johnston" <le...@i42.co.uk> wrote in message
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
Could you cite a statement from Intel in support of that?
Also, an atomic load has implied acquire semantics. All
LOCK'ed atomic RMW operations basically have implied full
memory barrier semantics:
(read chapter 8)
In particular, =A18.104.22.168, which specifically states that "Loads
may be reordered with earliers storead to different locations".
Which seems to say just the opposite of what you are claiming.
Also, latest VC++ provides acquire/release for volatile load/store
So, even if you port over to VC++ for X-BOX (e.g., PowerPC), you will get
correct behavior as well.
Provided he uses volatile on the pointer (and uses the classical
double checked locking pattern, rather than his modified
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...
IIUC, these guarantees were first implemented in VS 2010.
(They're certainly not present in the generated code of the
versions of VC++ I use, mainly 2005.)
I'm also wondering about their perenity. I know that Herb
Sutter presented them to the C++ committee with the suggestion
that the committee adopt them. After some discussion, he more
or less accepted the view of the other members of the committee,
that it wasn't a good idea. (I hope I'm not misrepresenting his
position---I was present during some of the discussions, but
I wasn't taking notes.) Given the dates, I rather imagine that
the feature set of 2010 was already fixed, and 2010 definitly
implements the ideas that Herb presented. To what degree
Microsoft will feel bound to these, once the standard is
officially adopted with a different solution, I don't know (and
I suspect that no one really knows, even at Microsoft).