Щоб відповісти на ваше запитання про те, чому це не безпечно для потоків, це не тому, що перший дзвінок до 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)));
}
Отож ось простий для потоків безпечний Singleton (для Windows). Він використовує просту обгортку класу для об’єкта Windows CRITICAL_SECTION, щоб ми могли змусити компілятор автоматично ініціалізувати CRITICAL_SECTIONпопередній 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вони не можуть бути ініціалізовані.
- замок потрібно робити щоразу, коли запит екземпляра. Як я вже говорив, це проста безпечна реалізація потоку. Якщо вам потрібна краща (або ви хочете знати, чому такі речі, як техніка блокування подвійної перевірки, є хибними), дивіться документи, пов'язані з відповіддю Гроо .