12

The following is a well known implementation of singleton pattern in C++.
However, I'm not entirely sure whether its thread-safe.
Based upon answers to similar question asked here previously, it seems it is thread safe.
Is that so?

//Curiously Recurring Template Pattern    
//Separates a class from its Singleton-ness (almost).    
#include <iostream>  
using namespace std;

template<class T> class Singleton {
  Singleton(const Singleton&);
  Singleton& operator=(const Singleton&);
protected:
  Singleton() {}
  virtual ~Singleton() {}
public:
  static T& instance() {
    static T theInstance;
    return theInstance;
  }
};

// A sample class to be made into a Singleton
class MyClass : public Singleton<MyClass> {
 int x;
protected:
  friend class Singleton<MyClass>;
  MyClass() { x = 0; }
public:
 void setValue(int n) { x = n; }
  int getValue() const { return x; }
};
Ankur
  • 11,239
  • 22
  • 63
  • 66
  • Why did you make this a WIKI? It's a completely valid question. – JaredPar Jun 27 '09 at 12:09
  • you didn't give any reasons why *you* think the pattern implementation isn't thread safe. Please do. – gogole Jun 27 '09 at 12:12
  • what is the aim of the friend class here? can someone answer? – Ahmed Jun 27 '09 at 12:17
  • Oh shoot! Should have checked faqs to see what it means, rather than assuming it to be something. – Ankur Jun 27 '09 at 12:19
  • @Ankur I think you can edit your question and uncheck community WIKI. – JaredPar Jun 27 '09 at 12:27
  • @Jared, Edit doesn't has any option to uncheck Wiki :( – Ankur Jun 27 '09 at 12:45
  • 1
    @Ahmed. It is there for the statement, "static T theInstance" to compile. As you might see, MyClass has protected constructor so we need the friend specifier so that Singleton class (Singleton, to be precise) can declare a local static of type MyClass. – Ankur Jun 27 '09 at 12:56

4 Answers4

13

No, this is not thread safe because the static local is not guarded in any way. By default a static local is not thread safe. This means you could run into the following issues

  • Constructor for the singleton runs more than once
  • The assignment to the static is not guaranteed to be atomic hence you could see a partial assignment in multi-threaded scenarios
  • Probably a few more that I'm missing.

Here is a detailed blog entry by Raymond Chen on why C++ statics are not thread safe by default.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • so basically this means that it is not possible to do a OS agnostic singleton using C++ ? i.e. you always need some critical section or similar to do one? – AndersK Jun 27 '09 at 16:05
1

IT IS NOT THREAD SAFE. To become thread safe you should add a check before the lock (semaphore lock) and an other check after the lock. And then you are sure that even in simultaneous call from different threads you provide one instance.

0

It's not threadsafe, unless you configure your compiler to generate threadsafe code for static accesses.

However, it's better that the code be self contained, so I'd add a mutex here and there.

Rhythmic Fistman
  • 34,352
  • 5
  • 87
  • 159
0

If you're still interest on this topic and if you're using a C++ 11 standard compiler you can find here a proposal of the singleton pattern in a multithreaded environment.

Silviu
  • 103
  • 1
  • 7