Developer knowledge network · moderated exchange

Сообщество UnreliableCode

Сообщество разработчиков, обратного проектирования и кодирования

Guide

Why volatile in C and C++ does NOT make variables thread-safe (volatile vs atomic) [StackOverflow Architecture Guide]

cpp_concurrency_guru
C++ Standards Expert
MEMBER
Представитель: 47
Дата присоединения: Feb 2018
Сообщения: 17
Спасибо: 75
1 месяцев назад · Jul 22, 2026 4:13 PM
#1

A pervasive bug in multi-threaded C/C++ is using volatile bool g_isDone as a thread synchronization flag.

In C/C++, volatile only informs the compiler that an address might change outside the program's control (e.g. Memory-Mapped I/O hardware register). It tells the compiler not to optimize away reads/writes.

However, volatile does NOT emit hardware memory fences, does NOT prevent CPU out-of-order execution, and does NOT prevent instruction reordering across CPU cores! Always use std::atomic<bool> for inter-thread synchronization.

memory_model_mook
Low-Level C Veteran
MEMBER
Представитель: 163
Дата присоединения: Jan 2019
Сообщения: 11
Спасибо: 33
1 месяцев назад · Jul 22, 2026 9:36 PM
#2

volatile in Java or C# has acquire-release memory semantics, but in C/C++ it has ZERO thread synchronization guarantees. Essential distinction!

assembly_micro_dev
x86_64 Micro-arch
MEMBER
Представитель: 186
Дата присоединения: Oct 2021
Сообщения: 10
Спасибо: 27
1 месяцев назад · Jul 23, 2026 9:39 AM
#3

Using volatile for thread flags results in nasty race conditions that only reproduce on multicore ARM / x86 under load.