ЕМ>volatile должно гарантировать отсутствие буферизации, добавляемой компилятором. Если я, в свою очередь, гарантирую запись изменений в память параллельным потоком, то что может помешать считыванию измененных значений?

Volatile accesses cannot be optimized out or reordered ... This makes volatile objects suitable for communication with a signal handler, but not with another thread of execution, see std::memory_order.

https://en.cppreference.com/w/cpp/language/cv

Другими словами, можно ожидать, что компилятор просто так не выкинет volatile объекты, но нельзя расчитывать, что значения какой-то конкретной пременной в коде (например флага, котрый используется для остановки цикла) будут одинаковы для разных cpu.


ЕМ>Ну и не люблю я библиотечных конструкций в ядерном коде — они то реализованы "с особенностями", то тянут за собой лишний код из CRT, то не реализованы вообще.
Вы в ядре программируете? Там ведь свой набор примитивов синхронизации.

ЕМ>volatile должно гарантировать отсутствие буферизации, добавляемой компилятором. Если я, в свою очередь, гарантирую запись изменений в память параллельным потоком, то что может помешать считыванию измененных значений?

Volatile accesses cannot be optimized out or reordered ... This makes volatile objects suitable for communication with a signal handler, but not with another thread of execution, see std::memory_order.

https://en.cppreference.com/w/cpp/language/cv

Другими словами, можно ожидать, что компилятор просто так не выкинет volatile объекты, но нельзя расчитывать, что значения какой-то конкретной пременной в коде (например флага, котрый используется для остановки цикла) будут одинаковы для разных CPU.
Вот, кстати, неплохая статья с описанием того, где может пригодиться volatile https://habr.com/ru/company/abbyy/blog/161607/

ЕМ>Ну и не люблю я библиотечных конструкций в ядерном коде — они то реализованы "с особенностями", то тянут за собой лишний код из CRT, то не реализованы вообще.
Вы в ядре программируете? Там ведь свой набор примитивов синхронизации.