Безопасна ли реализация Мейерсом потока шаблона Singleton?

Question

Является ли следующая реализация с использованием отложенной инициализации Singleton (Meyers' Singleton) поток безопасен?

static Singleton& instance()
{
     static Singleton s;
     return s;
}

Если нет, то почему и как сделать это потокобезопасным?

Answer 1

В C++ 11 это потокобезопасно. Согласно стандарту, §6.7 [stmt.dcl] p4:

Если элемент управления вводит объявление одновременно во время инициализации переменной, параллельное выполнение должно ожидать завершения инициализации.

GCC и VS поддерживают эту функцию ( динамическая инициализация и уничтожение с параллелизмом, также известная как Magic Statics на MSDN):

• Visual Studio: поддерживается с Visual Studio 2015
• GCC: поддерживается с GCC 4.3

Спасибо @Mankarse и @olen_gam за их комментарии.

---

В C++ 03 этот код не был потокобезопасным. Есть статья Мейерса под названием "C++ и опасности двойной проверки блокировки", в которой обсуждаются поточно-ориентированные реализации шаблона, и делается вывод, более или менее, что (в C++03) полная блокировка вокруг экземпляра метода в основном это самый простой способ обеспечения надлежащего параллелизма на всех платформах, в то время как большинство форм с двойной проверкой вариантов шаблона блокировки могут страдать от состояния гонки на определенных архитектурах, если инструкции не чередуются со стратегически размещаемыми барьерами памяти.

Answer 2

Чтобы ответить на ваш вопрос о том, почему это не потокобезопасно, это не потому, что первый вызов 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_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 не может быть инициализирован.
• блокировка должна быть взята каждый раз, когда запрашивается экземпляр. Как я уже сказал, это простая многопоточная реализация. Если вам нужен лучший (или вы хотите знать, почему такие вещи, как техника двойной проверки блокировки, неверны), см. Статьи, ссылки на которые есть в ответе Гроо.

Answer 3

Рассматривая следующий стандарт (раздел 6.7.4), он объясняет, насколько статическая локальная инициализация является поточно-ориентированной. Поэтому, как только этот раздел стандарта будет широко внедрен, предпочтение отдается Мейеру Синглтону.

Я не согласен со многими ответами уже. Большинство компиляторов уже реализуют статическую инициализацию таким образом. Единственное заметное исключение - Microsoft Visual Studio.

Answer 4

Правильный ответ зависит от вашего компилятора. Он может решить сделать его потокобезопасным; это не "естественно" потокобезопасно.

Answer 5

Безопасна ли следующая реализация [...] для потока?

На большинстве платформ это не является потокобезопасным. (Добавьте обычный отказ от ответственности, пояснив, что стандарт C++ не знает о потоках, поэтому по закону он не говорит, является ли он или нет.)

Если нет, то почему [...]?

Причина этого не в том, что ничто не мешает более чем одному потоку одновременно выполнять sконструктор.

как сделать это потокобезопасным?

"C++ и опасности двойной проверки блокировки" Скотта Мейерса и Андрея Александреску - довольно хороший трактат на тему поточно-ориентированных синглетонов.

Answer 6

Как сказал MSalters: это зависит от используемой вами реализации C++. Проверьте документацию. Что касается другого вопроса: "Если нет, то почему?" - Стандарт C++ пока ничего не упоминает о потоках. Но следующая версия C++ знает о потоках и явно заявляет, что инициализация статических локальных объектов является поточно-ориентированной. Если два потока вызывают такую ​​функцию, один поток выполнит инициализацию, в то время как другой заблокирует и будет ждать ее завершения.