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

S>Ну да. Если ты намеренно не запрограммировал это на разных потоках, то барьер не нужен. Вообще, мне кажется, если программировать всё в одном потоке, то вообще можно не знать, что барьеры существуют. По крайней мере, в "обычных" языках и процессорах.

Безотносительно многопоточности, возможно переупорядочивание инструкций внутри одного ядра (АЛУ).

Погуглите
* cpu instruction reordering
* out of order execution

Если отдельно взятый поток/АЛУ решит, что заданные две инструкции можно исполнить в любом порядке (поскольку зависимостей между ними не наблюдает), то он выберет тот, который даст бОльшую эффективность по заданному policy: energy consumption, или memory throughput или idle cycle count, или что там сейчас считается важным.

Само собой, что возможны случаи, когда сделанное предположение об отсутствии зависимостей является неверным, и АЛУ тем самым вносит side-effect, который не ожидался автором программы — лезут плавающие баги. Особенно сложно правильно определять такие зависимости, когда имеем дело с managed-платформами, когда есть некоторый промежуточный уровень абстракции (рантайм C# или Java VM). Именно поэтому там вводится понятие "модели памяти" (memory model), чтобы хоть как-то очертить правила игры и дать базовые гарантии, работающие одинаково на всех поддерживаемых аппаратных платформах. Ну а если базовых гарантий недостаточно или мы хотим объехать их для какого-то выигрыша — тогда в бой идут явные задания барьеров памяти.