Thread: making a class only get constructed once

Originally Posted by Bubba

Case in point. What happens in this section of code if two threads pass the if conditional?

That is multi-threaded issues, and these issues affects everything you make, so it's hardly fair to say that it's a design flaw for this specific piece of code. It wasn't made to be thread safe. Can it be done? Sure. But at a cost. If you don't need it to be thread-safe, or if you want the caller to make it thread-safe, then why implement such a protection at all when all it does is add overhead?

Originally Posted by medievalelks

A single instance of a non-singleton still has to have its creation managed somewhere in the program, and is subject to the same synchronization issues in a MT environment, no?

Of course all data access from different threads
must be serialized properly to avoid races. In many cases the designer can hide the thread safety code from the client. And if still something goes wrong: nearly every programmer will know how to help you securing your data access (much fewer know how to compute data in parallel using techniques which scale, but that doesn't count here)

But the issue with singleton instantiation is worse:

Code:

class C :public Singleton{};
...
void f1() {
C::instance(); }
...
void f2() {
C::instance(); }

How many objects do you have if this is a single threaded program? One.
How many objects does your mate who re-uses your object produce in his multithreaded multi-module program? You as the class designer can't know. If he doesn't know about the singleton problems he probably thinks one, because the code worked inside your program for years.
But some access to his singleton objects doesn't seem to go right although he secured every data access...
Now post this vague problem to a forum and better prepare some cans of coffee for the next few nights of code review...

Originally Posted by medievalelks

Cannot the same problem occur (more easily perhaps) with a single object passed by reference? What's to stop a programmer from constructing one where he thinks he needs it?

Unfortunately nothing.
The singleton problems are not about programmers doing something wrong. Rather it is about things which looks right but break during the costumer demo.

For one thing this lazy instantiation is a bit of a problem. If you create a single instance normally or through Elysia's factory before other threads start, you won't have this problem.

Using the singleton in multiple threads might be quite problematic though.

Originally Posted by medievalelks

How is any of that mitigated with a class that you intend, but don't enforce, to have only one instance?

You can't enforce singularity (if you consider re-usability - At least I don't know a method which is guaranteed to work under all circumstances. And if you search the net you will see I'm not alone). So what is left?
-Method a (singleton) which promises things it can't hold
-Method b - the standard method everybody knows to use

What of both would you put into your companies code base?

I think that it also tends to be more difficult to design unit tests involving singletons.

Seems like thread-safety could be enforced by a simple spinlock during object construction.

Code:

void SpinLock(int &lock);
void SpinUnlock(int &lock);

class TheSingleton
{
    static int mSpinLock;
    static bool mInstantiated;

public:
    static void DoInstantiate();

    static void Instantiate()
    {
        SpinLock(mSpinLock);
        if(!mInstantiated)
        {
            DoInstantiate();
            mInstantiated = true;
        }
        SpinUnlock(mSpinLock);
};

int TheSingleton::mSpinLock = 0;
bool TheSingleton::mInstantiated = false;

Sure, if two threads try to instantiate at the same time, one of them will spin for a while -- but it will only happen once, and ONLY if two threads try to instantiate at the same time.

There are no blocking waits, no OS dependencies.