Re: Singleton_pattern and Thread Safety
On 10/12/2010 20:39, Ian Collins wrote:
On 12/11/10 09:21 AM, Leigh Johnston wrote:
On 10/12/2010 20:06, Ian Collins wrote:
On 12/11/10 02:16 AM, Leigh Johnston wrote:
On 10/12/2010 09:52, James Kanze wrote:
Note that the above still risks order of destruction issues;
it's more common to not destruct the singleton ever, with
something like:
namespace {
Singleton* ourInstance =&Singleton::instance();
Singleton&
Singleton::instance()
{
if (ourInstance == NULL)
ourInstance = new Singleton;
return *ourInstance;
}
}
(This solves both problems at once: initializing the variable
with a call to Singleton::instance and ensuring that the
singleton is never destructed.)
James "Cowboy" Kanze's OO designs includes objects that are never
destructed but leak instead? Interesting. What utter laziness
typical of
somebody who probably overuses (abuses) the singleton pattern.
Singleton
can be considered harmful (use rarely not routinely).
What James describes is a very common idiom (to avoid order of
destruction issues) and it's certainly one I've often used.
Not considering object destruction when designing *new* classes is bad
practice IMO. Obviously there may be problems when working with
pre-existing designs which were created with a lack of such
consideration.
A programmer seldom has the benefit of a green field design. Even when
he or she does, there are still the dark and scary corners of the
language where undefined behaviour lurks. Order of destruction issues is
one such corner, especially when static objects exist in multiple
compilation units.
I am well aware of the unspecified construction/destruction order
associated with globals in multiple TUs and that is primary reason why
this method of James's should be avoided. The order of destruction of
"Meyers Singleton" objects *is* well defined for example although making
the "Meyers Singleton" method thread safe is not completely trivial.
By the way, the leak example you posted differers in one significant
point from James' example above: the location of the allocation. James'
allocation takes place before main. I agree with my debugger in
categorising that as a "block in use" rather than a leek.
It is a leak pure and simple; as I said else-thread if you use the
pattern in a DLL and load and unload the DLL multiple times the leak
will become apparent. What some debugger chooses to name an allocation
is mostly irrelevant; it *is* an allocation without a paired deallocation.
/Leigh