Re: Singleton_pattern and Thread Safety

From:

Leigh Johnston <leigh@i42.co.uk>

Newsgroups:

comp.lang.c++

Date:

Mon, 13 Dec 2010 19:30:18 +0000

Message-ID:

<Ca-dnXL3btTe6ZvQnZ2dnUVZ8tqdnZ2d@giganews.com>

On 13/12/2010 18:47, Leigh Johnston wrote:

On 13/12/2010 18:40, James Kanze wrote:

On Dec 13, 6:17 pm, Leigh Johnston<le...@i42.co.uk> wrote:

On 13/12/2010 11:45, James Kanze wrote:

[...]

You are not listening. If you have multiple singletons using
Mr Kanze's method that "you all" agree with it is unspecified
as to the order of construction of these singletons across
multiple TUs; i.e. the method suffers the same problem as
ordinary global variables; it is no better than using ordinary
global variables modulo the lack of object destruction (which
is shite).

I'd suggest you read the code I posted first. It addresses
the order of initialization issues fully. (But of course,
you're not one to let actual facts bother you.)

The code you posted results in unspecified construction order
of your leaking singletons even though they are dynamically
allocated if they are defined in multiple TUs.

I'd suggest you read it carefully, because it guarantees that
the singleton is constructed before first use.

Unspecified construction order is anathema to
maintainability as the order could change as TUs are added
or removed from a project.

Unspecified constructor order of variables at namespace scope is
a fact of life in C++. That's why we use the singleton pattern
(which doesn't put the actual variable at namespace scope, but
allocates it dynamically).

A fact of life you seem to be ignoring; the order of construction of the
following is specified within a single TU but unspecified in relation to
globals defined in other TUs:

namespace
{
foo global1;
foo* global2 = new foo();
foo global3; // global2 has been fully constructed (dynamically
allocated) before reaching here

}

Certainly. Who ever said the contrary? And what relationship
does this have to any of the singleton implementations we've
been discussing.

Unspecified destructor order of variables with static lifetime
(namespace scope or not) is also a fact of life in C++. That's
why we don't destruct the variable we dynamically allocated.

Dynamic allocation is irrelevant here; construction order is
unspecified as you are initializing a global pointer with the
result of a dynamic allocation

So you wrap your initialization in a function, and make sure
that the only way to access the pointer is through that
function. The classical (pre-Meyers) singleton pattern, in
fact.

It's called defensive programming. Or simply sound software
engineering. It's called avoiding undefined behavior, if you
prefer.

As you are doing it wrong it is neither defensive programming
nor sound engineering.

Again, I'd suggest you read my code very, very carefully. (I'll
admit that it's not immediately obvious as to why it works. But
it's been reviewed several times by leading experts, and never
found wanting.)

You are doing it wrong. I say again if you have more than one of your
leaking singletons defined in more than one TU the construction order of
your leaking singletons is unspecified.

This is your code:

namespace {

Singleton* ourInstance = &Singleton::instance();

Singleton&
Singleton::instance()
{
if (ourInstance == NULL)
ourInstance = new Singleton;
return *ourInstance;
}
}

The ourInstance *pointer* is a global object (albeit with internal
linkage) which you are initializing with a dynamic allocation wrapped in
a function. If you have more than such initialization in more than one
TU the order of the initializations is unspecified.

/Leigh

Just as confirmation that what I am saying is correct I created two
singletons using your method in the files a.cpp and b.cpp and here is
the result:

leigh@leigh-VirtualBox:~/dev/singleton$ g++ a.cpp b.cpp
leigh@leigh-VirtualBox:~/dev/singleton$ ./a.out
singleton B constructed
singleton A constructed
leigh@leigh-VirtualBox:~/dev/singleton$ g++ b.cpp a.cpp
leigh@leigh-VirtualBox:~/dev/singleton$ ./a.out
singleton A constructed
singleton B constructed
leigh@leigh-VirtualBox:~/dev/singleton$ g++ a.cpp b.cpp
leigh@leigh-VirtualBox:~/dev/singleton$ ./a.out
singleton B constructed
singleton A constructed
leigh@leigh-VirtualBox:~/dev/singleton$

/Leigh