Кратко и по делу.
Почему порядок операций может отличаться на разных ядрах
- Отсутствие единого глобального времени и наличие локальных кешей/буферов записи (store buffer) и аппаратного OoO (out‑of‑order) исполнения: ядро может сначала выполнить и/или видимо другим ядрам сохранить операции в другом порядке, чем в исходном программном порядке.
- Компилятор тоже может переставлять чтения/записи для оптимизации.
- Согласованность кеша (cache coherence) гарантирует, что одно­размерные записи распространяются, но не гарантирует глобальный порядок наблюдений без дополнительных механизмов.
Итог: без явных гарантий разные потоки могут наблюдать разные последовательности операций.
Модели памяти — основные понятия
- Последовательная согласованность (sequential consistency, SC): все операции выглядят как некоторый глобальный тотальный порядок, согласованный с порядком каждой программы. Это сильная модель.
- Слабые/релаксированные модели (x86 TSO, ARM/Power, C++11 relaxed и т.д.): допускают перестановки (store→load, load→load, store→store и т.п.) и видимости, оптимизируемые аппаратно/компилятором.
- Отношение happens‑before (${\to }_{hb}$) формализует когда одна операция гарантированно видима другой (например: release‑store → acquire‑load).
volatile / atomic / memory fence — как работают и что предотвращают
1) volatile
- В Java/C# volatile: обеспечивает атомарное чтение/запись и семантику acquire/release: запись volatile — release, чтение volatile — acquire. Это предотвращает перестановку операций вокруг volatile и делает видимыми предшествующие записи для последующих чтений другого потока, увидевшего volatile. Пример: producer пишет данные, потом volatile‑флаг; consumer читает флаг (acquire) и затем безопасно читает данные.
- В C/C++ volatile — только запрет на оптимизацию компилятора (не обеспечивает атомарности и порядок между потоками). Не использовать для синхронизации.
2) atomic (атомарные операции)
- C++11 std::atomic с memory_order:
- $memory\_order\_relaxed$ — атомарность без упорядочивания (предотвращает torn‑reads/torn‑writes и гонки при некоррелированных обновлениях, но не обеспечивает happens‑before).
- acquire (на load): не позволяет последующим чтениям/записям переместиться до этой загрузки.
- release (на store): не позволяет предыдущим операциям переместиться после этой записи.
- acquire+release вместе дают happens‑before.
- $memory\_order\_seq\_cst$ — последовательная согласованность для атомиков (глобальный тотальный порядок атомарных операций).
- Atomics предотвращают: torn‑access (частично записанные значения), потерянные обновления при использовании атомических RMW (fetch_add, compare_exchange), и гонки, если правильно применены.
3) memory fence (barrier)
- Аппаратные барьеры: full fence (x86 mfence / ARM dmb ish), acquire‑type (предотвращает перемещение последующих операций вверх), release‑type (предотвращает перемещение предыдущих операций вниз). Fences контролируют видимость операций между ядрами.
- Компиляторные барьеры (например, GCC asm("" ::: "memory") или std::atomic_thread_fence) запрещают перестановки компилятором и/или добавляют аппаратные инструкции.
- Примеры ошибок, которые устраняют:
- Reorder‑visibility bug: producer: data = $v$; flag = $1$; consumer: if (flag==$1$) use(data). Без release/acquire consumer может увидеть flag==$1$ но увидеть старое data. release on store flag + acquire on load flag предотвращают это.
- Lost updates: ++counter без атомика может потерять инкременты; atomic fetch_add или lock предотвращают это.
- Torn writes: запись 64‑бит значения неатомарно на 32‑бит машине может дать частично записанное значение — атомики предотвращают.
Короткие рекомендации практики
- Для синхронизации используйте атомики (C++ std::atomic) с нужным уровнем ordering; предпочитайте acquire/release или seq_cst где проще.
- В Java/C# для простых флагов используйте volatile; для сложной синхронизации — java.util.concurrent.
- Не рассчитывайте на volatile в C/C++ для межпоточной синхронизации.
- Барьеры нужны редко; правильнее использовать высокоуровневые примитивы (mutex, condition_variable, атомики) вместо ручных fence, если не уверены.
Пример (message passing)
- Producer:
data = $42$; // обычная запись
flag.store($1$, std::memory_order_release);
- Consumer:
if (flag.load(std::memory_order_acquire) == $1$) {
use(data); // гарантированно увидит data==$42$ }
Вывод: порядок видимости операций формируется сочетанием аппаратных буферов, оптимизаций и модели памяти; volatile/atomic/fence — разные инструменты для управления видимостью и атомарностью. Правильный выбор предотвращает stale reads, torn writes, lost updates и неверные межпоточные наблюдения.