Кратко — по сути и с примерами.
1) Последовательная консистентность (sequential consistency, SC)
- Определение: результат выполнения многопоточной программы эквивалентен какому‑то линейному чередованию операций всех потоков, сохраняющему порядок операций внутри каждого потока.
- Запрещает любые переупорядочивания, которые изменяют видимую глобальную последовательность.
- Последствие для кода: если все обращения к разделяемым данным выполняются в SC‑семантике (например, через атомарные операции с seq_cst), то простые программные рассуждения «по порядку в коде» корректны.
- Пример (нельзя получить одновременно нулевые чтения): пусть
$\text{T0: store}x=1;\text{load}r1=y$ $\text{T1: store}y=1;\text{load}r2=x$.
Под SC невозможно одновременно $r1=0$ и $r2=0$.
2) Слабая (weak/release) консистентность — общее понятие
- Общая идея: аппаратная/языковая модель допускает переупорядочивания памяти для производительности; гарантии порядка даются только вокруг специальных синхронизирующих операций (флаги, lock, барьеры).
- Варианты: release/acquire consistency, weak ordering и т.д. Важно: без явной синхронизации значения чтений/записей могут наблюдаться в «неинтуитивном» порядке.
- Последствие: программист обязан ставить синхронизацию (locks, acquire/release, барьеры) чтобы получить нужный порядок.
3) Модель x86 (TSO — Total Store Order)
- Ключевая разрешённая перестановка: Store → Load может выглядеть переупорядоченным из‑за буферизации записей (store buffering). То есть последующая в программе загрузка может выполниться раньше, чем предыдущая запись станет видна другим CPU.
- Что сохраняется: порядок всех записей между собой (Store→Store), порядок чтений (Load→Load), и порядок Load→Store. Процессор видит свои записи сразу (store forwarding).
- Последствие: классический пример (из пункта 1) может дать $r1=0$ и $r2=0$ на TSO (потоки могут «перескочить» свои записи).
- Примитивы на x86:
- полный барьер: $\mathtt{MFENCE}$;
- частичные: $\mathtt{LFENCE}$ (для чтений), $\mathtt{SFENCE}$ (для записей);
- атомарные операции с префиксом $\mathtt{LOCK}$ дают полную барьерную семантику и используются компиляторами для реализации сильных атомарных операций.
- Рекомендация: на x86 простые atomic seq_cst/lock‑инструкции обычно дают достаточную семантику; для предотвращения Store→Load‑аномалий можно вставлять $\mathtt{MFENCE}$ или использовать seq_cst атомики.
4) Модель ARM (ARMv7/ARMv8) — более слабая
- ARM традиционно более слабая: допускает многие переупорядочивания: Load↔Load, Load↔Store, Store↔Store и т.д.; точные правила зависят от версии (ARMv8 стал жестче, но всё ещё слабее TSO).
- Есть несколько способов обеспечить порядок: DMB (Data Memory Barrier — полный барьер), DSB (Data Synchronization Barrier), ISB (Instruction SB). Также есть инструкции/интринсики для acquire/release и атомики (LDAXR/STLXR, LDAR/STLR, атомарные операции со семантикой acquire/release).
- ARM дополняет модель зависимостями (address/data/control) — иногда зависимость адреса/значения даёт частичный порядок без барьера.
- Последствие: без барьеров практически любой оптимизации достаточно, чтобы нарушить интуитивные ожидания — нужно использовать acquire/release или DMB/DSB там, где требуется видимая упорядоченность.
5) Как это влияет на корректный многопоточный код — практические правила
- Никогда не полагайтесь на «естественный» порядок выполнения на аппаратуре: гонки данных (data races) дают неопределённое поведение.
- Используйте высокоуровневые примитивы:
- мьютексы/локи — дают полную синхронизацию (в C++: lock_guard и т.п.);
- атомарные операции с нужной семантикой: acquire/release для производительности, seq_cst если требуется сильная модель.
- Для lock‑free кода: явно указывайте memory_order (в C++): $memory\_order\_acquire$, $memory\_order\_release$, $memory\_order\_seq\_cst$.
- На x86 часто достаточно обычных атомиков; но если смешиваете обычные неатомарные записи и атомики — требуется осторожность (используйте атомики или барьеры).
- На ARM: используйте acquire/release атомики или DMB вокруг критических последовательностей; не полагайтесь на «адресные зависимости» без понимания модели.
6) Типичные примитивы/барьеры и когда применять
- Полный барьер (сильный): $\mathtt{MFENCE}$ (x86), $\mathtt{DMB}/\mathtt{DSB}$ (ARM) — гарантирует порядок всех предыдущих и последующих операций.
- Acquire (чтение‑барьер): на чтении предотвращает подтолкивание позже стоящих операций перед чтением; в C++: $memory\_order\_acquire$.
- Release (запись‑барьер): на записи предотвращает перемещение ранее стоящих операций после записи; в C++: $memory\_order\_release$.
- Seq_cst: глобальная строгая упорядоченность атомиков — проще рассуждать, но дороже.
- Атомарные RMW/LOCK инструкции: дают синхронизацию и часто выступают как полный барьер.
7) Короткие рекомендации
- Если не пишете низкоуровневый lock‑free код — используйте mutex/locks.
- Для lock‑free алгоритмов — используйте атомики с acquire/release; применяйте seq_cst только при явной необходимости.
- На x86 помните про Store→Load проблему (используйте seq_cst/механизмы барьеров при необходимости).
- На ARM всегда явно ставьте acquire/release или DMB, так как разрешены дополнительные переупорядочивания.
Если нужны конкретные примеры кода (C++ atomics, вставки барьеров для x86/ARM) — могу привести несколько компактных шаблонов.