Re: Threadsafe singletons
Chris Thomasson wrote:
"David Barrett-Lennard" <firstname.lastname@example.org> wrote in message
There have been extensive discussions on
comp.lang.c++.moderated and comp.programming.threads about
the problem of writing a threadsafe singleton. Most of this
centers around the double checked idiom, known to be broken.
I assume you actually mean that there are a lot of existing
implementations' out there that happen to be "completely"
I think he means that any implementation written purely in C++
The actual pattern itself it perfectly fine IMO, and can be
successfully implemented with assembly language and externally
assembled into a library with a coherent ABI and portable C
interface; no doubt about it...
Or by inserting a few, critical asm parts in code that is
otherwise written in C++.
IMHO, most of the problems that are generally associated with
double checked locking seem to be related to compiler
reordering, and of course, the "apparent" widespread lack of
knowledge wrt memory barrier functionality...
The problem is not so much compiler reordering, although
admittedly, about 90% of the implementations I've seen have that
problem as well. The problem is that on most systems, you can't
get the memory barriers without either assembler or system
BTW, I think I heard Herb Sutter mention something about a
Microsoft compiler that can implement a DCL pattern without
the use of an external assembler... I believe they have
assigned acquire/release semantics to the volatile keyword;
load.acquire, store.release... Humm... Does anybody know fore
sure if Microsoft compilers, for any Itanium architecture,
actually guard accesses to volatile variables with "explicit"
memory barrier instructions?
That is, apparently, the case. Microsoft has given a useful
definition to volatile (in the case of multithreading). There
has been some discussion of making this standard. I'm not
really convinced as yet: volatile serves a very useful purpose
today, in embedded systems, precisely because it is so vaguely
defined. While I'm not against extending its semantics to be
useful for threading---arguably, this was intended as well
behind the vague wording that is now there---I don't want to see
it so rigorously defined that it looses its usefulness for
The following approach avoids the problem entirely.
Yes. If your rules are followed, it will work... Thread
creation provides the necessarily #LoadStore|#StoreStore
barrier, ie release semantics...
Under Posix compliant systems, it does. Presumably under others
as well, but I've yet to find a specification.
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]