Здравствуйте, Максим Рогожин, Вы писали:
МР>Читаю статью на википедии про Блокировку с двойной проверкой. МР>Стоит им пользоваться или лучше не надо?
Всё просто: если есть сомнения, что полностью понимаешь проблему, про которую написано в википедийной статье (и в статьях на которую она ссылается), то значит пользоваться не надо.
Здравствуйте, _NN_, Вы писали:
_NN>Какую задачу решаем ?
Изучаю многопоточное программирование. Конкретно никакую задачу не решаю сейчас. Просто хочу уточнить как следует относиться к DCL — это подход который годится только для некоторых языков/платформ или это все же общепринятый паттерн многопоточного программирования?
многопоточное программирование начинается с прочтение книги
Энтони Уильямс Параллельное программирование на С++ в действии
сколько раз вы ее прочитали ?
прочитаете 100 раз, тогда и придете спрашивать
МР>Если работает не гарантированно, то значит все таки анти-паттерн, так?
Года до 2004 процессоры были одноядерные, и это было вообще безопасно.
Потом нахрен уперлись в лимит частоты и начали плодить ядра и производители процессоров начали делать агрессивные оптимизации внутри.
Паттерн постепенно перестал работать и стал антипаттерном.
МР>UPDATE: МР>Стоит им пользоваться или лучше не надо?
В современных реалих — не стоит. В стандартной библиотеке уже реализовано все.
Но разобраться почему так — я бы настоятельно порекомендовал (например тут https://stackoverflow.com/questions/2158804/handling-out-of-order-execution)
Здравствуйте, rm822, Вы писали:
МР>>Если работает не гарантированно, то значит все таки анти-паттерн, так? R>Года до 2004 процессоры были одноядерные, и это было вообще безопасно. R>Потом нахрен уперлись в лимит частоты и начали плодить ядра и производители процессоров начали делать агрессивные оптимизации внутри. R>Паттерн постепенно перестал работать и стал антипаттерном.
Глупости. Антипаттерном его называют не из-за того, что он не работает, а из-за того, что при его написании легко ошибиться и сделать реализацию, которая не работает.
И про ядра и внутрипроцессорные оптимизации тоже мимо. Классическая ошибочная реализация (например, которая в википедии тоже приводится как пример ошибочной) сбоит даже на одноядерном процессоре без суперскалярности. Там проблема вовсе не с тем, что код когда-то идеально работал, а потом перестал.
R> В стандартной библиотеке уже реализовано все.
Это дельное замечание, что не стоит делать свои велосипеды для примитивов, которые уже реализованы в стандартной библиотеке.
W>Глупости. Антипаттерном его называют не из-за того, что он не работает, а из-за того, что при его написании легко ошибиться и сделать реализацию, которая не работает.
А где тут на плюсах ошибаться-то? Volatile забыть поставить? W>Классическая ошибочная реализация (например, которая в википедии тоже приводится как пример ошибочной) сбоит даже на одноядерном процессоре без суперскалярности.
Там жаба-мракобесие, а у нас тут плюсы. На плюсах на старом одноядерном процессоре сломать сможешь?
Здравствуйте, rm822, Вы писали:
W>>Глупости. Антипаттерном его называют не из-за того, что он не работает, а из-за того, что при его написании легко ошибиться и сделать реализацию, которая не работает. R>А где тут на плюсах ошибаться-то? Volatile забыть поставить?
В том и дело, что куча людей думают "А где тут на плюсах ошибаться-то?". В результате, делают свою реализацию, но таки ошибаются в ней. В этом-то вся подлость этого паттерна и состоит
W>>Классическая ошибочная реализация (например, которая в википедии тоже приводится как пример ошибочной) сбоит даже на одноядерном процессоре без суперскалярности. R>Там жаба-мракобесие, а у нас тут плюсы.
Это не отменяет того, что есть баги общие для двух этих языков
Ну и там ссылка на годную статью с С++ спецификой указана.
R>На плюсах на старом одноядерном процессоре сломать сможешь?
Предлагаешь мне написать заведомо неработоспособную реализацию? То есть взять нормальную реализацию и добавить в неё баги? А смысл?
Здравствуйте, watchmaker, Вы писали:
W>В том и дело, что куча людей думают "А где тут на плюсах ошибаться-то?". В результате, делают свою реализацию, но таки ошибаются в ней. В этом-то вся подлость этого паттерна и состоит
Так реализация действительно простая. Но граблей там полно, можно легко сделать такую же простую, но неправильную. Вот хорошая тема, как с примером работающей реализации, так и с кучей предложенных "улучшений", которые ее ломают http://rsdn.org/forum/cpp/2549182
Здравствуйте, rm822, Вы писали:
W>>Глупости. Антипаттерном его называют не из-за того, что он не работает, а из-за того, что при его написании легко ошибиться и сделать реализацию, которая не работает. R>А где тут на плюсах ошибаться-то? Volatile забыть поставить?
Не удержусь от напоминания, что использование volatile в c/c++ для решения проблем многопоточности — антипаттерн.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Изучаю многопоточное программирование. Конкретно никакую задачу не решаю сейчас. Просто хочу уточнить как следует относиться к DCL — это подход который годится только для некоторых языков/платформ или это все же общепринятый паттерн многопоточного программирования?
Изучая многопоточное программирование, надо сразу понимать под какую архитектуру и железку это всё делается. Скажем, последние процы вообще внутри могут оказаться связкой NUMA-нодов, поэтому с конкурентным доступом к памяти может быть куда более нетривиально, чем обычно.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Изучаю многопоточное программирование. Конкретно никакую задачу не решаю сейчас. Просто хочу уточнить как следует относиться к DCL — это подход который годится только для некоторых языков/платформ или это все же общепринятый паттерн многопоточного программирования?
В области многопоточного программирования вообще любой подход годится только для некоторых языков/платформ.
С другой стороны, если ты столкнешься с экзотической платформой, на которой "общепринятые" методы в стиле windows или unix не работают, там будет предостаточно специфических особенностей и помимо того, что относится к многопоточному программированию
Здравствуйте, reversecode, Вы писали:
R>многопоточное программирование начинается с прочтение книги R>Энтони Уильямс Параллельное программирование на С++ в действии
А как сам Энтони Уильямс начинал? Ведь когда он начинал, то этой книги еще не было...
Здравствуйте, watchmaker, Вы писали:
R>> В стандартной библиотеке уже реализовано все. W>Это дельное замечание, что не стоит делать свои велосипеды для примитивов, которые уже реализованы в стандартной библиотеке.
Подскажите, а что является реализацией DCLP в стандартной библиотеке?
Здравствуйте, Максим Рогожин, Вы писали:
МР>Здравствуйте, watchmaker, Вы писали:
R>>> В стандартной библиотеке уже реализовано все. W>>Это дельное замечание, что не стоит делать свои велосипеды для примитивов, которые уже реализованы в стандартной библиотеке.
МР>Подскажите, а что является реализацией DCLP в стандартной библиотеке?
Этот вопрос плохой. Не библиотека реализует DCLP, а библиотека в своей реализации может использовать DCLP (а может использовать что-то другое).
И важны именно эти примитивы, которые предоставляет библиотека или язык. Их надо использовать в первую очередь. А уж реализованы они через DCLP или как-то по другому — это детали. (Ну вот я знаю, что на моей платформе инициализация локальной static переменной делается компилятором через DLCP. И что? Я же в коде просто объявляю переменную: и уверен, что мало кого должно заботить как компилятор это реализует.)
Здравствуйте, Ops, Вы писали:
Ops>Так реализация действительно простая. Но граблей там полно, можно легко сделать такую же простую, но неправильную. Вот хорошая тема, как с примером работающей реализации, так и с кучей предложенных "улучшений", которые ее ломают http://rsdn.org/forum/cpp/2549182
Здравствуйте, Alexander G, Вы писали:
AG>Эм, эта тема до появления std::atomic, начиная с C++11 всё проще.
Оно не проще, синхронизация вообще сложная вещь. А вот для конкретно этой задачи сейчас все просто и без атомиков, инициализация локальных статических переменных после C++11 потокобезопасна:
If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.
6.7
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.