Re: Confused about a thread-safe singleton example.
On Dec 5, 7:03 pm, "jason.cipri...@gmail.com"
<jason.cipri...@gmail.com> wrote:
On Dec 5, 12:05 pm, James Kanze <james.ka...@gmail.com> wrote:
[...]
[Re singletons]
And all those calls to instance() ARE a real pain in the neck.
The problem, IMO, is that it is supposed to limit the number
of instances on the type level. Yet, there is a price to be
paid at run- time for every usage of ::instance() call (albeit
small). On the other hand, accessing good old global variables
(or global references to abstract interfaces) has zero price
and seem to work quite well when I need one instance of
something and it does not require special syntax for accessing
that instance (less typing at the least).
It's not so much the runtime cost which bothers me, as the
clutter in the source files. Increased typing time, and also
increased reading time, and time necessary to find what you're
looking for. When it comes down to it, the function call is
noice.
I generally find that I'm rarely in a situation where I
frequently have to call instance(), and almost always have the
option of caching the instance pointer in some variable, e.g.
a local variable in a thread loop, a member of a class, even a
*local* static in a frequently called function.
So you have the clutter of an extra variable, rather than the
clutter of an extra function call. In the end, it comes out to
the same thing (although if I'm using the singleton more than
once or twice in a function, I'll use a local variable to hold
the reference).
It gets rid of the clutter and overhead, and caching it also
means you don't have to concentrate so much on making your
thread-safe implementation of instance() blazing fast (well,
of course, "blazing fast" being relative, e.g. a speedy 2.0
usec instead of a snail-like 2.3 usec with the overhead of
acquiring a mutex or something).
It can certainly be an optimization issue in the case of
multithreading, and the possibility is one of the reasons why
all these attempts of making double-checked locking work are
just intellectual masturbation.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34