Кратко — определения, пример и практические способы обеспечить нужную семантику.
1) Модели памяти (кратко)
- Sequential consistency (SC): результат выполнения многопоточной программы должен быть эквивалентен некоторой последовательной интерполяции операций всех потоков, причём порядок операций каждого потока сохраняется. Формально: существует глобальное линейное упорядочение операций, согласующееся с программным порядком каждого потока.
- Weak consistency (слабая согласованность): разрешает переупорядочивания и кэш‑видимости между потоками, если нет явной синхронизации. Память делится на обычные операции и операции синхронизации; только синхронизация создаёт точки согласования. Без синхронизации поведение может отличаться от SC (возможны «сюрпризы»).
- Release consistency (релиз/аквайр): специальный тип слабой согласованности с двумя классами операций синхронизации — release и acquire. Запись с release гарантирует, что все предшествующие записи видимы до этой release; чтение с acquire гарантирует, что все последующие чтения/записи увидят эффекты предшествующих release, если acquire синхронизируется с соответствующим release. Это даёт «частичную» упорядоченность через синх‑переменные.
2) Пример программы (поведение зависит от модели)
(классический пример store buffering / message passing)
Исходно (без атомарности/барьеров):
int x = 0, y = 0;
int r1 = 0, r2 = 0;
/* поток A */
x = 1;
r1 = y;
/* поток B */
y = 1;
r2 = x;
Под SC результат $r_1=0\wedge r_2=0$ невозможен (нельзя, чтобы оба чтения увидели старые значения одновременно). Но в слабых моделях (и на архитектурах с буферизацией записей) возможно, что оба потока выполнили свои записи «локально» и прочитали ещё не видимые записи другого — следовательно $r_1=0\wedge r_2=0$ становится возможным.
3) Как гарантировать нужную семантику на практике
- В C++11 (и позже) — использовать std::atomic и подходящие memory_order.
- Чтобы получить поведение SC: использовать std::memory_order_seq_cst для всех операций (по умолчанию store/load атомиков). Тогда исходный запрет $r_1=0\wedge r_2=0$ будет сохранён.
- Либо применить release/acquire по назначению: если поток A делает store с release и поток B делает load с acquire по той же синхронизирующей переменной, то все записи до release станут видимы при acquire. Пример:
std::atomic x{0}, y{0};
int r1 = 0, r2 = 0;
/* поток A */
x.store(1, std::memory_order_release);
r1 = y.load(std::memory_order_acquire);
/* поток B */
y.store(1, std::memory_order_release);
r2 = x.load(std::memory_order_acquire);
При корректном использовании release/acquire исход результата $r_1=0\wedge r_2=0$ будет предотвращён (если acquire читается из соответствующего release по той же синхронизирующей переменной).
- Барьеры/фенсы:
- Можно использовать std::atomic_thread_fence(std::memory_order_seq_cst) или platform fences (например, __atomic_thread_fence) чтобы обеспечить глобальную синхронизацию и запретить переупорядочивание через барьер.
- Пример: выполнять store; затем atomic_thread_fence(seq_cst); затем другой поток делает fence + load — это гарантирует видимость.
- Нельзя полагаться на volatile или на отсутствие оптимизаций компилятора — volatile не даёт межпоточной согласованности на современных стандартах. Используйте std::atomic или платформенные атомарные/барьерные примитивы.
Короткие рекомендации:
- Для простоты и корректности — используйте std::atomic с memory_order_seq_cst.
- Для производительности и когда хватает локальных гарантий — применяйте release (для записей) и acquire (для чтений) на синхронизирующей переменной.
- При необходимости глобального упорядочения — используйте atomic_thread_fence(std::memory_order_seq_cst) или соответствующие платформенные инструкции.
Если нужно, могу показать полный компилируемый пример на C++ с потоками и демонстрацией возможного результата при relaxed и его устранения с помощью seq_cst или release/acquire.