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

AG>...
AG>С volatile тоже не будет, нужны ещё барьеры. Которые implamantation-specific.

На x86/x64 (MSVC) — будет. В частности, из-за определенных гарантий, которые
обеспечиваются платформой и компилятором.

AG>Так, в Visual Studio у компилятора есть ключ для управления семантикой volatile, который по умолчанию "как atomic" для x86-64, и "без гарантий" на ARM.

И все-таки, как можно было бы переписать код выше "правильно", без "антипаттернов" (при условии, что это чистый C, не C++)?

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

O>И все-таки, как можно было бы переписать код выше "правильно", без "антипаттернов" (при условии, что это чистый C, не C++)?

В С11 тоже есть атомики, с memory order гарантиями.
ключевое слово _Atomic, заголовок <stdatomic.h>

В старых С и С++ без антипаттерна не обойтись в этом случае.

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

O>На x86/x64 (MSVC) — будет. В частности, из-за определенных гарантий, которые обеспечиваются платформой и компилятором.

O>И все-таки, как можно было бы переписать код выше "правильно", без "антипаттернов" (при условии, что это чистый C, не C++)?

Странный ты В одном сообщении одновременно требуешь от собеседника решения на чистом языке. А сам ссылаешься на решение, которое завязано на особенности работы конкретного компилятора под конкретную платформу с конкретными его настройками. Как-то непоследовательно

Как бы известно, что volatile не даёт ни атомарности, ни барьеров, и вообще его роль в языке далека от задач многопоточности (на что как бы даже намекает тот факт, что volatile появился в языке как обязательная часть задолго до этой самой многопоточности).

А то, что некоторые компиляторы содержат расширения, которые меняют поведение некоторых языковых конструкций, — так это особенности этих компиляторов.

Здравствуйте, Alexander G, Вы писали:
AG>В старых С и С++ без антипаттерна не обойтись в этом случае.
Видимо дело в том, что старые c/c++ не знали про многопоточность вообще. И жаловаться в этом случае на отсутствие атомиков — несколько странно. Как и пытаться впихнуть вместо них volatile.
Решение — использовать внешние костыли: interlocked под win, расширения gcc под лин, рукописные (как правило на асме) велосипеды под экзотику.

R>>На плюсах на старом одноядерном процессоре сломать сможешь?
W> Предлагаешь мне написать заведомо неработоспособную реализацию? То есть взять нормальную реализацию и добавить в неё баги?
Я тебе предлагаю доказать свое смелое утверждение. Показать как классическая реализация DLC на плюсах с volatile будет сбоить "даже на одноядерном процессоре без суперскалярности".

Здравствуйте, rm822, Вы писали:
R>Я тебе предлагаю доказать свое смелое утверждение. Показать как классическая реализация DLC на плюсах с volatile будет сбоить "даже на одноядерном процессоре без суперскалярности".
Зачем, когда все уже давно сделано: http://www.drdobbs.com/cpp/c-and-the-perils-of-double-checked-locki/184405772
В двух словах: даже если с помощью волатилов удастся защитить указатель — не удастся гарантировать, что поток, пришедший за синглтоном вторым, получит до конца собранный объект.
И да, проблема там рассматривается с точки зрения абстрактной c++ машины, т.е. нет суперскалярности, да и про многоядерность только в заключении.

n.b.
я надеюсь, ты не подразумеваешь под классической реализацией DCLP мерзость из примера 11 в статье