Problem 500

Summary:	Flaw in Singleton implementations
Product:	Geant4	Reporter:	Christian.Theis
Component:	run	Assignee:	Makoto.Asai
Status:	RESOLVED WONTFIX
Severity:	major	CC:	asai
Priority:	P2
Version:	5.1
Hardware:	All
OS:	All

Description Christian.Theis 2003-06-07 11:29:26 CEST

Many classes like G4RunManager use a singleton approach which has a major flaw
because the copy ctor is neither provided nor is the compiler inhibited from
synthesizing one. For example the following code would produce a second
instance of G4RunManager:

G4RunManager SneakyCopy( *G4RunManager::GetRunManager() );

As soon as SneakyCopy goes out of scope the whole system will go down the drain
as all the objects to which the original G4RunManager has any pointers, will be
deleted.

Proposal: Why not impose the usage of a templated generic singleton
implementation which takes care of these problems automatically?

Comment 1 Gabriele Cosmo 2003-06-24 05:48:59 CEST

Thank you for making notice this issue now also rather well documented in the
literature. Please, notice the following: several classes in Geant4 (included
G4RunManager and most of the singletons) have been developed in 1995. At that
time, the support of most compilers for templates was very poor or totally
non-existent, similarly for what concerns the implementation of the singletons
where some compilers could not digest a totally 'privatisation' of constructors.
G4RunManager in particular is a rather peculiar kind of singleton, since
originally it was not meant to be subclassed, and if you read the class
specification you'll see that there's a note/warning concerning the
possibility of having multiple istances of it...
Your proposal is certainly a viable solution, however special care must be
given in backward compatibility of the software, since Geant4 is now used in
production by many experiments.
A redesign for a modular run-manager is foreseen for the December release,
where also some of these topics may be considered.