Singleton C++ Class - How to avoid mem leak in multi threading

This is a discussion on Singleton C++ Class - How to avoid mem leak in multi threading within the C++ Programming forums, part of the General Programming Boards category; Hello,
got a C++ doubt..
normally Singleton class is written like
Sing.h
==========
class Sing{
private:
Sing();
static Sing* instance;
...

That's a bit over-simplistic, Ancient: it is still necessary to create/initialise the critical section or mutex before calling the getInstance() function. Which brings up the same problem: the critical section or mutex is (as far as the program is concerned) a singleton....

A better strategy is to explicitly create the object instance and the critical section to protect it before launching any threads. If no threads are launched, the program is single-threaded, so the initialisation (creating the object and whatever synchronises access to it) doesn't have to be protected.

One thing to remember is that protecting the process of creating the object does not protect accesses to it. For example, it does not protect calls to member functions if they are invoked simultaneously by multiple threads.

Well, my doubt was that why does the creation of static var in getInstance func() & returning it not be used for multi threading, In this way the destructor need not be called.
Whereas if i use the static member var, then i need to allocate using new(), but the destructor never gets called!

I do agree that locking & unlocking the critical section is required in multi threading.

That's a bit over-simplistic, Ancient: it is still necessary to create/initialise the critical section or mutex before calling the getInstance() function. Which brings up the same problem: the critical section or mutex is (as far as the program is concerned) a singleton.....

well, my intent was not to spoon-feed his every action and is why I provided a link. Afterall, he needs to do some reasearch on his own.

This is just one of many possibilities with two threads. There are a large number of variations, as none of the operations (eg comparing instance with zero, invoking operator new, invoking the constructor of Sing, assigning the address to instance, returning the value of instance, etc) are atomic: several of those operations can be interrupted (or preempted, if the operating system forces it to happen) by another thread at any time. And things get even more complex with more than two threads trying the same stuff.....

Unfortunately, the second form:

Code:

Sing* Sing::getInstance()
{
static Sing instance;
return &instance;
}

does not solve the problem either. The reason here is that the time the static variable is created is also compiler dependent. All the C++ standard requires is that instance will be constructed at some time before the first call of getInstance(). If you get lucky (and you do with some compilers) static variables are created at program startup. If you get unlucky (and you do with some compilers, and you definitely do if the static variable is within a dynamically loaded link library [eg a windows DLL]) static variables are created just before the first call to getInstance(), and the problems are like those of using operator new --- the creation process can be invoked on multiple threads, and preempting can occur, giving similar problems as your first example.

The long and short of it is that, when doing multithreading, you (the programmer) needs to exercise explicit control over any operation (creating, manipulating, destroying) to any objects that are accessed from multiple threads. One strategy is to only do certain operations (eg creating and destroying the object) when it is guaranteed only one thread is executing (eg before threads are launched, and after they are terminated), so it is not necessary to synchronise those operations. Another strategy is to ensure all operations are synchronised.

well, my intent was not to spoon-feed his every action and is why I provided a link. Afterall, he needs to do some reasearch on his own.

Yeah, but the link does not provide the information needed either.

I'm all in favour of telling fibs when teaching, to ensure that someone learns something which works reliably, even if it isn't 100% accurate (eg some details are left out, but those omissions won't get people into trouble, and they can be corrected later).

But I don't believe in telling fibs which, if followed precisely, actually encourage someone towards practices that get them in trouble.

Unfortunately, in this case, the simple answer you gave can get a beginner into trouble, and they wouldn't know it for quite a while --- the information is out there, but not exactly easy to find.