Re: A few questions about singletons...
On Sep 29, 4:21 am, Michael Doubez <michael.dou...@free.fr> wrote:
On 25 sep, 20:45, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Sep 25, 1:05 am, Michael Doubez <michael.dou...@free.fr> wrote:
You can use a Meyer singleton which solve the initialisation order
issue:
static CSingleton& GetInstance()
{
CSingleton static_instance;
return static_instance;
}
And the cleanup is made at termination. The cleanup of a singleton is
delicate because you don't known how is currently using it (it is eve=
n
worse when in a DLL); you should let the system decide when it is no
longer needed.
Suffice to say, actually suggesting the simplest Meyer's singleton is
bad advice. Frankly, I've made so many mistakes on this topic recently
that I'll just point you to the thread where someone more
knowledgeable than me suggests more correct ways to do this.
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/bca..=
..
1- Your singleton may cause static deinit issues. If you can leak it,
just leak it. Otherwise, it'll work correctly if all other statics
call getSingleton in their constructors. This will guarantee correct
destruction order, Last In First Out.
You mean if a static gets latter on (after its initialisation) a
reference on the singleton ?
Yes.
This is not limited to singleton but to
every storage management; have seen some case where the singleton is
resetable causing that kind of problem but it is more related to the
logic of the program(er).
Betting on a singleton with the longest lifetime does guarantee your
program doesn't crash for this reason but it is IMHO at best a patch.
Agreed.
2- It's not thread-safe. There's the simple ways to do this correctly
which come with the caveat that "No nontrivial threads during static
init".
That is alas true. The next standard does provide atomic operations
which will ease that pain (I hope).
IIRC: Even better: all initializors of namespace-scope variables and
static-local variables will have pthread_once semantics. It'll also
give basic atomic operations as well.
Alternatively, use the more complex designs of Chris M.
Thomasson, which just guarantee single correct construction with
minimal overhead. There are several, depending on platform, and
exactly what guarantees you want.
I have seen the code mentioned and it supposes that initialisation of
the mutex is atomic.
If I replace in the header:
typedef HANDLE pthread_mutex_t;
#define PTHREAD_MUTEX_INITIALIZER CreateMutex(/* params */)
You see the problem with:
static pthread_mutex_t g_mutex = PTHREAD_MUTEX_INITIALIZER;
In fact, it is possible that two mutex will be created and the mutex
is then useless.
In practice, IIRC it does work with the usual libpthread.
I got this very wrong in the aforementioned thread. Chris does a good
job correcting me there. You are right that PTHREAD_MUTEX_INITIALIZER
has no (easy) windows equivalent. Check out the code Chris posted in
the aforementioned link. He covers this case as well.
Although, honestly, at this point I would just strongly suggest using
Boost's pthread_once wrapper, which basically uses Chris's windows
implementation for windows IIRC.