CODEWITHSUNDEEP
c++thread-safetystatic-members
Naveen
Naveen

Reputation: 73493

Is this way of creating static instance thread safe?

I have the following sample C++ code:

class Factory
{
public:
    static Factory& createInstance()
    {
        static Factory fac;
        return fac;
    }

private:
    Factory() 
    {
        //Does something non-trivial
    }
};

Let's assume that createInstance is called by two threads at the same time. So will the resulting object be created properly? What happens if the second thread enters the createInstance call when the first thread is in the constructor of Factory?

Upvotes: 6

Views: 1713

Answers (4)

Matthieu M.
Matthieu M.

Reputation: 300199

C++11 and above: local static creation is thread-safe.

The standard guarantees that:

  • The creation is synchronized.
  • Should the creation throws an exception, the next time the flow of execution passes the variable definition point, creation will be attempted again.

It is generally implemented with double-checking:

  • first a thread-local flag is checked, and if set, then the variable is accessed.
  • if not yet set, then a more expensive synchronized path is taken, and if the variable is created afterward, the thread-local flag is set.

C++03 and C++98: the standard knows no thread.

There are no threads as far as the Standard is concerned, and therefore there is no provision in the Standard regarding synchronization across threads.

However some compilers implement more than the standard mandates, either in the form of extensions or by giving stronger guarantees, so check out for the compilers you're interested in. If they are good quality ones, chances are that they will guarantee it.

Finally, it might not be necessary for it to be thread-safe. If you call this method before creating any thread, then you ensures that it will be correctly initialized before the real multi-threading comes into play, and you'll neatly side-step the issue.

Upvotes: 8

kfmfe04
kfmfe04

Reputation: 15337

The instantiation (first call) itself is threadsafe.

However, subsequent access will not be, in general. For instance, suppose after instantiation, one thread calls a mutable Factory method and another calls some accessor method in Factory, then you will be in trouble.

For example, if your factory keeps a count of the number of instances created, you will be in trouble without some kind of mutex around that variable.

However, if Factory is truly a class with no state (no member variables), then you will be okay.

Upvotes: 0

Yttrill
Yttrill

Reputation: 4931

Of course it's thread safe! Unless you are a complete lunatic and spawn threads from constructors of static objects, you won't have any threads until after main() is called, and the createInstance method is just returning a reference to an already constructed object, there's no way this can fail. ISO C++ guarantees that the object will be constructed before the first use after main() is called: there's no assurance that will be before main is called, but is has to be before the first use, and so all systems will perform the initialisation before main() is called. Of course ISO C++ doesn't define behaviour in the presence of threads or dynamic loading, but all compilers for host level machines provide this support and will try to preserve the semantics specified for singly threaded statically linked code where possible.

Upvotes: 0

user541686
user541686

Reputation: 210745

Looking at this page, I'd say that this is not thread-safe, because the constructor could get called multiple times before the variable is finally assigned. An InterlockedCompareExchange() might be needed, where you create a local copy of the variable, then atomically assign the pointer to a static field via the interlocked function, if the static variable is null.

Upvotes: 2

Related Questions