А volatile переменные, они читаются/записываются также как atomic load/store или

чо ваще?

Нет.

Нет, почитайте про это

вопрос для супапро. но нет, в общем случае не так

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

да, ведь есть даже поговорка "volatile is multithreaded programmer's best friend" от одного из корифеев стандарта - Александреску (на самом деле нет, не слушайте меня)

:https://drdobbs.com/cpp/volatile-the-multithreaded-programmers-b/184403766 >By Andrei Alexandrescu, February 01, 2001 >Just like its better-known counterpart const, volatile is a type modifier. It's intended to be used in conjunction with variables that are accessed and modified in different threads. забавно, что в C++98 есть следующее примечание: [Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. See 1.9 for detailed semantics. In general, the semantics of volatile are intended to be the same in C++ as they are in C. ] при том, что в 1.9 Program execution volatile описывается как побочный эффект, что соответствует современным представлениям

проблема в том что в те времена это было implementation-defined

Кек в том, что обычно при упоминании atomic/volatile/Александреску в одном предложении и этой его статьи, люди напрочь игнорируют собсно текст этой статьи, а холиварят про "atomic ==/!= volatile зуб даю". А идея-то у него там очень интересная: он использует volatile исключительно как дополнительный квалификатор типа аналогично const (новый придумать не можем же, поэтому тупо используем существующий, но полностью меняем его смысл), и на этой основе он риальне реализует аналог borrow из Rust — если мы хотим использовать объект в разделяемой среде, мы обязаны его "подкрасить" с помощью volatile (фактически заборровить), и работать с подкрашенной ссылкой в критической секции, и возвращать владение в конце скоупа по RAII. А попытки некорректных доступов вне критических секций прямо выдают ошибки компиляции, о как.

спасибо за такой детальный обзор!

и вам за исторический бекграунд

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

ну, согласен, не совсем уж полностью. но если смотреть на текущий стандарт, разница между "запрещено оптимизировать и переставлять" и "использовать как независимый от const квалификатор и реализовать scope-based multithreaded guard" таки есть

Александреску ушел в D, где есть keyword "shared" именно с этим смыслом.. и года 2 назад отошел

и чем он занимается сейчас?

Какой смысл так делать, если это не работает? В сообществе сложился консенсус, что volatile и atomic понятия ортогональные.

Что не работает? Александреску привел конкретный пример, ВСЕ остальные что-то себе придумали, на фантазировали и теперь им кто-то виноват? Пример заключается что один поток читает, другой пишет bool флаг. Никакой гонки данных на модификации НЕТ, ибо потоков всего два. Если не поставить волотайл то при чтении будем вечно читать значение из регистра, при волотайле ВСЁ будет работать так как надо! Если вы про то что, возможна ситуация, что два потока работают идеально только в своих ядрах. и укаждого ядра есть свой L1. и так как нет барьера(и нет синхронизации L1) то волатайл да тут не сработает. Но ИМХО речь шла про Биг ОСь и там рано или поздно сама ОСь сделает синхронизацию. Про эмбедет там не было ни слова, и почему-то люди в 2001 это понимали, а сейчас перестали? ну может потому что стали давать первым языком Питон и Джаву, вместо Си?. Потом статья 2001 года до введения атомиков в язык еще ой как далеко. При этом он следом же рассматривает мьютекс и говорит, что имея модифиактор volatile мы его можем снять через каст, если мы работаем внутри критической секции ибо повысим (возможную) эффективность. при выходе из секции примитив все сам сделает по красоте. А то что подкрашивать методы через volatile ну так сейчас это вроде как запретили вешать этот модификатор для классов, методов и функций ибо не имеет никакого практического смысла. Volatile заставляет каждое чтение и запись делать всегда, тобишь не кэшировать переменную в регистре. Александреску говорит только об этом, ни об атомарности, ни барьерах речи не шло. Это додумали знатоки, которые потом начали кого-то обвинять.

Еще раз: сюда незачем это тащить, это а) не работает, б) из 2001 года. volatile модификатор и для структур тоже, там фокус с bool флагом не проходит. (заканчиваю дискуссию)

Притащили другие, у меня подгорает, когда люди не делают поправку на год статьи. И вместо того, чтобы пояснить человеку что имел ввиду Александреску, нет, мы побудим Дартаньяном. ИМХО в 2001 году у 99% людей были одноядерные процы. и там это злополучный пример работал! А Вы набрасываете на самого Александреску мол он идиот и это НЕ РАБОТАЕТ. Это работает в его примере и с поправками, которые люди понимали в 2001 году. А если вы набрасываете, так уточните, а не так мол волотайл != атомик и ВАШ Александреску идиот он не понимает разницу из-за чего пишет статьи в которых все не правда. Человек сюда пришел с вопросом, ему накидали даже такую древность. Вместо того, чтобы пояснить человеку, нет надо быть душным. PS оффтопик.

емнип в msvc volatile всегда работал как memory barrier, так что пример с bool будет работать а msvc и в наше время ( классически в double checked lock, например )

Может всё-таки речь про x86?

вот где вы такие нашли. еще с с++11 народ активно на всех конференциях говорит что volatile это о другом - для чтения регистров железяк

так вроде предлагают задепрекейтить volatile, вот доклад про это https://www.youtube.com/watch?v=KJW_DLaVXIY

https://learn.microsoft.com/en-us/cpp/build/reference/volatile-volatile-keyword-interpretation?view=msvc-170

Не надо. Он ставит на место компилятор, который пытается оптимизировать запись/чтение в железяку for (int i = begin; i <= end; ++i) { *(volatile int*)0xFF0008 = i; // if not "volatile", compiler does it only once }

Удалим volatile, введем новый стандартный атрибут! (я не смотрел доклад, я выдумываю)

volatile compound assignment уже успели и депрекейтнуть, и де-депрекейтнуть https://github.com/cplusplus/papers/issues/1023

Пусть сначала модель памяти приближённую к реальности завезут

к реальности на какой платформе?

Запретили как раз делать методы и вешать volatile куда не нужно. про шорт операции уже откатили в 23++.

На всех сразу, то что есть сейчас слишком далеко от реальности

а, было даже веселее 1) в 20 стандарте депрекейтнули все volatile compound assignments 2) потом в 23 стандарте в последний момент де-депрекейтнули побитовые volatile compound assignments 3) этот де-депрекейт попытались отменить через national body comment в процессе утверждения 23 стандарта (подозреваю, что авторы первоначального депрекейта). основной аргумент — непоследовательность 4) EWG вместо того, чтобы согласиться, разделилась примерно поровну, а это значит отсутствие консенсуса 5) и проголосовала за то, чтобы де-депрекейтнуть все остальные volatile compound assignment занавес https://github.com/cplusplus/nbballot/issues/488

@KoynovStas

да я даже пивка хлопнул, когда в 23++ откатили это.