Потокобезопасная ленивая конструкция синглтона в C++

к сожалению, ответ Мэтта имеет то, что называется двойная проверка блокировки который не поддерживается моделью памяти C / C++. (Он поддерживается Java 1.5 и позже - и я думаю, что .NET-модель памяти.) Это означает, что между временем, когда pObj == NULL проверка происходит, и когда блокировка (мьютекс) приобретается, pObj возможно, уже назначен в другом потоке. Переключение потоков происходит всякий раз, когда ОС этого хочет, а не между "строками" программы (которая не имеют значения post-compilation на большинстве языков).

кроме того, как признает Мэтт, он использует int как блокировка, а не примитив ОС. Не делай этого. Правильные блокировки требуют использования инструкций барьера памяти, потенциально кэш-линий и т. д.; Используйте примитивы вашей операционной системы для блокировки. Это особенно важно, потому что используемые примитивы могут меняться между отдельными линиями ЦП, на которых работает ваша операционная система; что работает на ЦП Foo может не работать на CPU Foo2. Большинство операционных систем либо изначально поддерживают потоки POSIX (pthreads), либо предлагают их в качестве оболочки для пакета потоков ОС, поэтому часто лучше всего иллюстрировать примеры их использования.

если ваша операционная система предлагает соответствующие примитивы, и если вам это абсолютно необходимо для производительности, вместо этого типа блокировки / инициализации вы можете использовать atomic сравнить и поменять операция инициализации общей глобальной переменной. По сути, то, что вы напишете, будет выглядеть так:

MySingleton *MySingleton::GetSingleton() {
    if (pObj == NULL) {
        // create a temporary instance of the singleton
        MySingleton *temp = new MySingleton();
        if (OSAtomicCompareAndSwapPtrBarrier(NULL, temp, &pObj) == false) {
            // if the swap didn't take place, delete the temporary instance
            delete temp;
        }
    }

    return pObj;
}

это работает только в том случае, если безопасно создавать несколько экземпляров вашего синглтона (по одному на поток, который одновременно вызывает GetSingleton ()), а затем выбрасывать дополнительные функции. The OSAtomicCompareAndSwapPtrBarrier функция, предоставляемая в Mac OS X-большинство операционных систем предоставляют аналогичный примитив-проверяет, является ли pObj и NULL и только фактически устанавливает его в temp это если он есть. Это использует аппаратную поддержку действительно, буквально только выполните обмен после и скажите, произошло ли это.

еще одно средство для использования, если ваша ОС предлагает его, что между этими двумя крайностями является pthread_once. Это позволяет настроить функцию, которая запускается только один раз-в основном, выполняя все блокировки / барьеры / и т. д. обман для вас - независимо от того, сколько раз он вызывается или на сколько потоков он вызывается.

вот очень простой лениво построенный одноэлементный геттер:

Singleton *Singleton::self() {
    static Singleton instance;
    return &instance;
}

это лениво, и следующий стандарт C++ (C++0x) требует, чтобы он был потокобезопасным. На самом деле, я считаю, что по крайней мере g++ реализует это потокобезопасным способом. Итак, если это ваш целевой компилятор или если вы используете компилятор, который также реализует это потокобезопасным образом (возможно, более новые компиляторы Visual Studio? Я не знаю), то это может быть все, что вам нужно.

Также см. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2513.html по этой теме.

вы не можете сделать это без каких-либо статических переменных, однако, если вы готовы терпеть один, вы можете использовать импульс.Нить для этой цели. Дополнительные сведения см. В разделе "одноразовая инициализация".

затем в функции одноэлементного доступа используйте boost::call_once построить объект и вернуть его.

для gcc это довольно просто:

LazyType* GetMyLazyGlobal() {
    static const LazyType* instance = new LazyType();
    return instance;
}

GCC удостоверится, что инициализация является атомной. для VC++, это не так. :-(

одной из основных проблем с этим механизмом является отсутствие тестируемости: если вам нужно сбросить LazyType на новый между тестами или хотите изменить LazyType* на MockLazyType*, вы не сможете. Учитывая это, обычно лучше использовать статический мьютекс + статический указатель.

также, возможно, в стороне: лучше всегда избегать статических типов без стручка. (Указатели на стручки в порядке.) Причин для этого много: как вы упомянули, порядок инициализации не определен - как и порядок, в котором вызываются деструкторы. Из-за этого программы будут в конечном итоге сбой, когда они пытаются выйти; часто не большое дело, но иногда showstopper, когда профилировщик вы пытаетесь использовать требует чистого выхода.

хотя на этот вопрос уже был дан ответ, я думаю, что есть некоторые другие моменты, чтобы упомянуть:

• Если вы хотите ленивый экземпляр синглтона при использовании указателя на динамически выделенный экземпляр, вам нужно будет убедиться, что вы очистите его в нужной точке.
• вы можете использовать решение Мэтта, но вам нужно будет использовать правильный мьютекс/критический Раздел для блокировки и проверить "pObj == NULL" как до, так и после блокировки. Конечно, pobj по должна быть static ;) . Мьютекс был бы излишне тяжелым в этом случае, вам лучше пойти с критическим разделом.

но, как уже говорилось, Вы не можете гарантировать threadsafe ленивую инициализацию без использования хотя бы одного примитива синхронизации.

Edit: да, Дерек, ты прав. Моя ошибка. :)

вы можете использовать решение Мэтта, но вам нужно будет использовать правильный мьютекс/критический Раздел для блокировки и проверить "pObj == NULL" как до, так и после блокировки. Конечно, pObj также должен быть статичным ;). Мьютекс был бы излишне тяжелым в этом случае, вам лучше пойти с критическим разделом.

OJ, это не работает. Как отметил Крис, это двойная проверка блокировки, которая не гарантируется для работы в текущем стандарте C++. Видеть: C++ и опасности двойной проверки блокировки

Edit: нет проблем, OJ. Это очень хорошо в языках, где это работает. Я ожидаю, что он будет работать в C++0x (хотя я не уверен), потому что это такая удобная идиома.

1. чтение на слабой модели памяти. Оно может сломать дважды проверенные замки и spinlocks. Intel-сильная модель памяти (пока), поэтому на Intel это проще

2. осторожно используйте "volatile", чтобы избежать кэширования частей объекта в регистрах, иначе вы инициализируете указатель объекта, но не сам объект, и другой поток будет аварийно

3. порядок инициализации статических переменных по сравнению с общей загрузки кода иногда нетривиально. Я видел случаи, когда код для уничтожения объекта уже был выгружен, поэтому программа разбилась при выходе

4. такие объекты трудно уничтожить должным образом

В общем синглеты трудно сделать правильно и трудно отлаживать. Лучше вообще их избегать.

Я полагаю, говоря не делать этого, потому что это небезопасно и, вероятно, сломается чаще, чем просто инициализация этого материала в main() не будет настолько популярным.

(и да, я знаю, что это означает, что вы не должны пытаться делать интересные вещи в конструкторах глобальных объектов. В том-то и дело.)