Singleton Destruction Order

[monarch_dodra]

I've been upkeeping a mess of a code recently, that uses "pseudo" singletons. Basically, the current code has "Initialize_All" static functions that initializes all the singletons in a given order. At the end of the program, we call "Destroy_All", and destroy everything in the reverse order.

The code is actually heavilly dll'ed, and Initilize_All and Destory_All are referenced counted. We ask that any client who uses our code call Initialize_All first and then Destroy_All when they are finished. The first Initilize_All will initialize everything, and the last Destory_All will delete everything.

This is showing its limits.

----
I'd like to move us to a fully singleton design. The singleton pattern means we don't have to use an Initilize_All, and each singleton can manage construction dependencies by itself (we are mono-threaded).

Each singleton is "clean", so it is cleans itself up at dll destruction.

----
The big question is this one:
If there is a singleton dependency during destruction, eg: ~A requires an instance of singleton B (which is in another DLL), are we guaranteed proper behavior?

Or, is there an "Static de-initialization order fiasco"?

If yes, are there any design that can combat this fiasco, short of having each singletong register itself in a manager, that will destroy them in reverse order?

Thanks for your input.

[TomasRiker]

You should consider not using singletons at all.
If that's not an option, maybe every singleton could register its dependencies, so that you can build a dependency graph at runtime. When the program ends, you first destroy the singleton that no other singleton is depending on, and remove it from the graph. Repeat this until all singletons are destroyed.

[superbonzo]

If there is a singleton dependency during destruction, eg: ~A requires an instance of singleton B (which is in another DLL), are we guaranteed proper behavior?

Or, is there an "Static de-initialization order fiasco"?

if all singletons have a Meyers-like implementation with instance getters exposed in the import table with no cycle dependencies, then singleton dependencies are resolved by the loader guaranteeing the correct initialization and (reversed) destruction order.

that said, you shouldn't care of their de/initialization order as you should not invoke non trivial code when un/loading dll's ( I mean, AFAIK, statics de/initializations share the same caveats of code invoked during DLL_PROCESS_ATTACH ... ).

[Codeplug]

>> as you should not invoke non trivial code when un/loading dll's
+1

Whatever you decide, there should be no dependencies during DLL_PROCESS_ATTACH/DETACH. The code that runs during that time should be extremely trivial (zero our vars etc...). That then implies that the DLL should expose Init()/DeInit(), and put the burden of calling those on the client.

gg

[monarch_dodra]

What about in the case where the singletons are in the same dll? Any dangers there?

[superbonzo]

What about in the case where the singletons are in the same dll? Any dangers there?

essentially the same dangers ...

This is showing its limits.

can I ask you to which limits are you alluding to ?

IMHO, dlls should not "clean" themselves, they should just expose a c-style interface to be eventually wrapped into a c++ design at the client side. I think that if you need more sophisticated ways of componentizing software at the binary level then COM may give a better solution ...

[monarch_dodra]

...

The problem is that this isn't an explicit dll load. EG: we don't really know when the dll will be loaded. All we know is that we must call "Initialize" before calling any method in the DLL, and then call "Finalize" after the call to that method in the DLL.

Apparently, this is just because the called code has some static data that needs to be initialized...

We are trying to see with the clients if they can't do this on their side...

EDIT: I'm not looking for a solution here, It's just that I'm not entirely savvy with dlls, and wanted some info on singletons.