Comments 6
Когда я впервые изучал модели памяти, я мало что понял, и спустя месяц забыл про это. Потом прочитал еще раз, но, к сожалению, тоже хватило ненадолго.
То есть на практике эта теория вам совершенно не нужна и вы ее не разу не применяли на практике, но беретесь всех научить. Удивительно!
По-моему есть какой-то общий недостаток, что сначала объясняют барьеры памяти. И потом на основе барьеров объясняют модели памяти (например, для того же C++). Может их разделить: барьеры это одно, модели - это другое?
--
В чём проблема описания через барьеры? Модели памяти - они описаны в стандарте в терминах: случится раньше, видится-невидится и т.д. Т.е. в прямую там барьеры не указываются (хотя всё и похоже).
Как результат, могут быть всякие синхронизации: например, когда одни поток1 делает релиз; поток2 делает к этому захват и потом релиз (может и чего-то другого); потом поток3 делает захват. И если рассматривать такую схему с точки барьеров, то поток3 видит всё, что сделал поток1. С точки же зрения моделей памяти (в C++) это необязательно и может трактоваться как UB. И это может потом "выстрелить": процессоры со временем меняются, язык же гарантирует некоторую модель памяти (и барьеры его не интересуют).
--
Примечание: почему всё не заканчивается на атомиках?:
Бывают ситуации, когда данных много, они жирные и не хочется всё заталкивать в атомики. Тогда с использованием моделей памяти и одного атомика (или других синхронизаций) можно сделать, что изменения пачки переменных в одном потоке корректно увидятся в другом (без жирных затрат процессора).
Вот в этой статье https://habr.com/ru/articles/195948/ достаточно подробно разжевывается, каким способом реализуются основополагающие CAS-операции на примере команд процессоров x86/64 и ARM. Можно ли похожим образом указать в какой ассемблерный код транслируются операции упорядочивания памяти Sequential Consistency, Release/Acquire на примере тех же популярных архитектур процессоров?
Почти всегда нам достаточно дефолтного SeqCst
В литературе по многопоточному программированию тоже пишут, что SeqCst заставит код безопасно работать так, как мы себе его представляем. Но видимо реальность такова, что последующие главы в книгах посвящены способам оптимизации производительности с подходящим указанием семантики упорядочивания памяти)
Можно ли похожим образом указать в какой ассемблерный код транслируются операции упорядочивания памяти Sequential Consistency, Release/Acquire на примере тех же популярных архитектур процессоров?
Попробовал посмотреть ассемблер, у меня явно инструкции не показывает почему-то. Но должны быть MFENCE какие-нибудь, наверняка (просто, видимо, в разных местах, в зависимости от указанной модели памяти).
Барьеры и модели памяти – explained