>> но как быть с P5 и 486-386?

ПК>Эти процессоры не переупорядочивают запись, так что им memory barrier не нужен, достаточно атомарности изменений.

Верно, как то об этом не подумал. Тогда все ок, хотя фраза о том, что майкрософт гарантирует, что InterlockedXxxx для НЕ IA32 архитектур является memory barrier, все-таки настораживает...

> чтение тоже может быть переупорядочено. <...> Чтобы проблемы не было надо ставить acquire lock после atom_get, а InterlockedExchangeAdd, через который реализован atom_get этого не делает.

Если я правильно понял MSDN, то должен делать там, где это нужно...

> ПК>Это так называемый Double Checked Locking. В общем случае, без использования специфических для платформы средств для организации memory barrier, не работает. Немного подробнее: http://rsdn.ru/Forum/Message.aspx?mid=380025&amp;only=1

Автор: Павел Кузнецов
Дата: 10.09.03

>
> Как я понял из этой статьи надо сделать как-то так:
>
>

> template <class T>
> T* CSingleton<T>::Instance()
> {
>     if(!pinstance_)
>     {
>         . . .
>     }
>
>     return pinstance_;
> }
>

Нет, этого недостаточно: перед чтением pinstance_ должен быть memory barrier, которого здесь нет.

Здравствуйте, Павел Кузнецов, Вы писали:

>> чтение тоже может быть переупорядочено. <...> Чтобы проблемы не было надо ставить acquire lock после atom_get, а InterlockedExchangeAdd, через который реализован atom_get этого не делает.

ПК>Если я правильно понял MSDN, то должен делать там, где это нужно...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/interlockedexchange64.asp
Вроде ни слова про барьеры.

ПК>>Если я правильно понял MSDN, то должен делать там, где это нужно...

bw>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/interlockedexchange64.asp
bw>Вроде ни слова про барьеры.

А вы посмотрите код этих функций, и все станет понятно.

>>> чтение тоже может быть переупорядочено. <...> Чтобы проблемы не было надо ставить acquire lock после atom_get, а InterlockedExchangeAdd, через который реализован atom_get этого не делает.
>
> ПК>Если я правильно понял MSDN, то должен делать там, где это нужно...
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/interlockedexchange64.asp
> Вроде ни слова про барьеры.

Внизу странички ссылка: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/synchronization_and_multiprocessor_issues.asp

Processors can be instructed to force their memory caches to agree with main memory with special instructions. Such instructions ensure that previous read and write requests have completed and are made visible to other processors, and to ensure that that no subsequent read or write requests have started. Examples are:

Functions which enter or leave critical sections.

Functions which signal synchronization objects.

Wait functions.

Interlocked functions

<...>

The InterlockedExchange function ensures that the value of iValue is updated for all processors before the value of fValueHasBeenComputed is set to TRUE.

Это и есть неформальное описание memory barrier.

Здравствуйте, Andrew S, Вы писали:

ПК>>Один из вариантов — инициализировать критическую секцию/мьютекс заведомо до
ПК>>использования singleton.

AS>Верно. Например, в файле реализации синглетона, как это сделано у Александреску.
AS>Но тогда возможна ситуация вызова Instance с еще непроинициализированной критической секцией. В общем, за что боролись... Печально, Павел, неужели нет красивого выхода из этой ситауции?

ПК>>Если структура программы настолько аморфна, что ничего о времени использования
ПК>>тех или иных объектов сказать нельзя, возможно, стоит задуматься об архитектуре.
AS>Нет, меня вполне устраивает объявление объекта синглтона в файле реализации и я могу гарантировать, что Instance будет вызываться только после инициализации статических объектов. Но меня интересует не конкретный проект, а именно принцип.

Не могу понять. Если вы можете гарантировать, что Instance вызывается после входа в main, то какие проблемы с инициализацией критической секции? Никаких.
Если же у вас Instance вызывется до входа в main, то это значит, что нет отложенной инициализации и нет проблем с многопоточностью -- и синглетон вам не нужен тогда, а нужно решить проблему порядка конструирования статических объектов -- но это уже совсем другая проблема.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Andrew S, Вы писали:

ПК>>Один из вариантов — инициализировать критическую секцию/мьютекс заведомо до
ПК>>использования singleton.

AS>Верно. Например, в файле реализации синглетона, как это сделано у Александреску.
AS>Но тогда возможна ситуация вызова Instance с еще непроинициализированной критической секцией. В общем, за что боролись... Печально, Павел, неужели нет красивого выхода из этой ситауции?

Хотите хинт насчет критической секции? Есть критические секции с автоинициализацией. Т.е. для них не нужно вызывать конструктор -- достаточно статической инициализации членов структуры начальными значениями.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

ПК>>>Один из вариантов — инициализировать критическую секцию/мьютекс заведомо до
ПК>>>использования singleton.

AS>>Верно. Например, в файле реализации синглетона, как это сделано у Александреску.
AS>>Но тогда возможна ситуация вызова Instance с еще непроинициализированной критической секцией. В общем, за что боролись... Печально, Павел, неужели нет красивого выхода из этой ситауции?

Ш>Хотите хинт насчет критической секции? Есть критические секции с автоинициализацией. Т.е. для них не нужно вызывать конструктор -- достаточно статической инициализации членов структуры начальными значениями.

Какой конструктор? Вы про что? Я про win32 критические секции
А вообще — теме уже 300 лет, проблема (точнее, вопрос) давно решена...

ПК>>>Если структура программы настолько аморфна, что ничего о времени использования
ПК>>>тех или иных объектов сказать нельзя, возможно, стоит задуматься об архитектуре.
AS>>Нет, меня вполне устраивает объявление объекта синглтона в файле реализации и я могу гарантировать, что Instance будет вызываться только после инициализации статических объектов. Но меня интересует не конкретный проект, а именно принцип.

Ш>Не могу понять. Если вы можете гарантировать, что Instance вызывается после входа в main, то какие проблемы с инициализацией критической секции? Никаких.
Ш>Если же у вас Instance вызывется до входа в main, то это значит, что нет отложенной инициализации и нет проблем с многопоточностью -- и синглетон вам не нужен тогда, а нужно решить проблему порядка конструирования статических объектов -- но это уже совсем другая проблема.

Вы не то выделяете

AS>> Но меня интересует не конкретный проект, а именно принцип.

Здравствуйте, Andrew S, Вы писали:

ПК>>>Если я правильно понял MSDN, то должен делать там, где это нужно...

bw>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/interlockedexchange64.asp
bw>>Вроде ни слова про барьеры.

AS>А вы посмотрите код этих функций, и все станет понятно.

Будет возможность — помотрю и напишу о результатах.

Вполне возможно MS пошел на то,чтобы во всех Interlocked операциях добавить mb, хоть их и отговаривали
http://groups.google.com/groups?hl=en&amp;lr=&amp;ie=UTF-8&amp;frame=right&amp;rnum=171&amp;thl=1022546285,1023289076,1023286257,1023283857,1023276945,1023275247,1022994050,1022953118,1022946105,1022718570,1022701862,1022362731&amp;seekm=3F78BD48.63529E65%40xemaps.com#link179


Своей критикой предложенного синглтона, я просто хотел подчеркнуть, что сами по себе atomic-операции,
имеющиеся практически на любом процессоре, ничего не гарантируют. Вдруг кто захочет спортировать
этот синглетон не под Win — чтобы знали подводные камни

Здравствуйте, Andrew S, Вы писали:

AS>Всем доброго времени суток.
AS>Итак, как было выяснено здесь

Автор: Andrew S
Дата: 06.02.04

, синглтон Майерса не является потокобезопасным.

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

Здравствуйте, WolfHound, Вы писали:

...

Можно ли этот код сократить до такого?

WH>

...
WH>    static T &Instance()
WH>    {
WH>        static T* obj_ptr=0;//Статическая инициализация(потокобезопасно)
WH>        static LONG flag=0;//Аналогично
WH>        auto_lock lock(&flag);
WH>        ptr=(T*)atom_get((LONG*)&obj_ptr);
WH>        if(!ptr)
WH>        {
WH>            static T obj;//Создастся пи первом поподании сюда
WH>            ptr=&obj;
WH>            atom_set((LONG*)&obj_ptr, (LONG)ptr);
WH>        }
WH>        return *ptr;
WH>    }
...
WH>

Прежде всего, вопрос не о скорости, а о безопасности.

Здравствуйте, sergey_shandar, Вы писали:

_>Можно ли этот код сократить до такого?
хъ
_>Прежде всего, вопрос не о скорости, а о безопасности.
Вроде можно. А нужно?

Здравствуйте, WolfHound, Вы писали:

WH>struct auto_lock
WH>{
WH> auto_lock(LONG* ptr)
WH> :ptr_(ptr)
WH> {
WH> while(atom_set(ptr_, 1))
WH> Sleep(1);
WH> }

Тут недавно в boost.develop появилась забавная нитка, в которой один перец довольно убедительно утверждает, что спин-локи, вообще говоря, довольно хреновая вещь, если у них нет fallback'а на синхронизационные примитивы ОС (там шла дискуссия по поводу boost::lightweight_mutex).

Здравствуйте, WolfHound, Вы писали:

_>>Прежде всего, вопрос не о скорости, а о безопасности.
WH>Вроде можно. А нужно?

Спросил только для того что бы получше понять смысл написанного. Человек я простой, только простые вещи понимаю. Насколько я понимаю, все будет работать даже так:

...
WH>    static T &Instance()
WH>    {
WH>        static LONG flag=0;
WH>        auto_lock lock(&flag);
WH>        static T obj;
WH>        return obj;
WH>    }
...

Правильно?

Здравствуйте, sergey_shandar, Вы писали:

_>Спросил только для того что бы получше понять смысл написанного. Человек я простой, только простые вещи понимаю. Насколько я понимаю, все будет работать даже так:
хъ
_>Правильно?
А вот тут нет memory barrier(он встроен в InterlockedXXX функции). Так что теоритически могут быть проблемы.

Здравствуйте, Lexey, Вы писали:

L>Тут недавно в boost.develop появилась забавная нитка, в которой один перец довольно убедительно утверждает, что спин-локи, вообще говоря, довольно хреновая вещь, если у них нет fallback'а на синхронизационные примитивы ОС (там шла дискуссия по поводу boost::lightweight_mutex).
А можно ее сюда процитировать?

_>>Спросил только для того что бы получше понять смысл написанного. Человек я простой, только простые вещи понимаю. Насколько я понимаю, все будет работать даже так:
WH>хъ
_>>Правильно?
WH>А вот тут нет memory barrier(он встроен в InterlockedXXX функции). Так что теоритически могут быть проблемы.

Почему нет?

struct auto_lock
{
    auto_lock(LONG* ptr)
        :ptr_(ptr)
    {
        while(atom_set(ptr_, 1))
            Sleep(1);
    }
    ~auto_lock()
    {
        atom_set(ptr_, 0);
    }
    LONG* ptr_;
};

Имхо, просто этот код тормознее, поскольку возможны конфликты, и, соотв, попадание в sleep при одновременном входе из разных потоков... Двойная проверка как раз делается для того, чтобы быстрее было. А выше был приведен классический "медленный" вариант. Любоай auto_lock, предоставляемый средствами OS, должен являться memmory barrier.

Здравствуйте, WolfHound, Вы писали:

L>>Тут недавно в boost.develop появилась забавная нитка, в которой один перец довольно убедительно утверждает, что спин-локи, вообще говоря, довольно хреновая вещь, если у них нет fallback'а на синхронизационные примитивы ОС (там шла дискуссия по поводу boost::lightweight_mutex).
WH>А можно ее сюда процитировать?

Если только в понедельник. Дома я ее не читаю, а подписываться ради этого лень.