Чтобы ответить на ваш вопрос о том, почему это не потокобезопасно, это не потому, что первый вызов instance()должен вызывать конструктор Singleton s. Чтобы быть потокобезопасным, это должно происходить в критической секции, но в стандарте нет требования, чтобы критическая секция была принята (стандарт на сегодняшний день полностью ничего не говорит о потоках). Компиляторы часто реализуют это с помощью простой проверки и приращения статического логического значения - но не в критической секции. Что-то вроде следующего псевдокода:
static Singleton& instance()
{
static bool initialized = false;
static char s[sizeof( Singleton)];
if (!initialized) {
initialized = true;
new( &s) Singleton(); // call placement new on s to construct it
}
return (*(reinterpret_cast<Singleton*>( &s)));
}
Итак, вот простой потокобезопасный синглтон (для Windows). Он использует простую оболочку класса для объекта Windows CRITICAL_SECTION, так что мы можем сделать так, чтобы компилятор автоматически инициализировал вызов CRITICAL_SECTIONbefore main(). В идеале должен использоваться настоящий класс критической секции RAII, который может иметь дело с исключениями, которые могут возникнуть при удержании критической секции, но это выходит за рамки этого ответа.
Основная операция заключается в том, что когда Singletonзапрашивается экземпляр , берется блокировка, при необходимости создается Singleton, затем блокировка освобождается и возвращается ссылка Singleton.
#include <windows.h>
class CritSection : public CRITICAL_SECTION
{
public:
CritSection() {
InitializeCriticalSection( this);
}
~CritSection() {
DeleteCriticalSection( this);
}
private:
// disable copy and assignment of CritSection
CritSection( CritSection const&);
CritSection& operator=( CritSection const&);
};
class Singleton
{
public:
static Singleton& instance();
private:
// don't allow public construct/destruct
Singleton();
~Singleton();
// disable copy & assignment
Singleton( Singleton const&);
Singleton& operator=( Singleton const&);
static CritSection instance_lock;
};
CritSection Singleton::instance_lock; // definition for Singleton's lock
// it's initialized before main() is called
Singleton::Singleton()
{
}
Singleton& Singleton::instance()
{
// check to see if we need to create the Singleton
EnterCriticalSection( &instance_lock);
static Singleton s;
LeaveCriticalSection( &instance_lock);
return s;
}
Человек - это много дерьма, чтобы «сделать мир лучше».
Основными недостатками этой реализации (если я не позволил некоторым ошибкам проскользнуть) является:
- если
new Singleton()бросает, замок не будет освобожден. Это можно исправить с помощью настоящего объекта блокировки RAII вместо простого, который у меня есть здесь. Это также может помочь сделать вещи переносимыми, если вы используете что-то вроде Boost для предоставления независимой от платформы оболочки для блокировки.
- это гарантирует безопасность потока, когда экземпляр Singleton запрашивается после
main()вызова - если вы вызываете его до этого (как в случае инициализации статического объекта), вещи могут не работать, потому что они CRITICAL_SECTIONмогут быть не инициализированы.
- блокировка должна быть взята каждый раз, когда запрашивается экземпляр. Как я уже сказал, это простая многопоточная реализация. Если вам нужен лучший (или вы хотите знать, почему такие вещи, как техника двойной проверки блокировки, ошибочны), см. Статьи, ссылки на которые есть в ответе Гроо .