C++11线程中std::mutex的内存可见性及CPU缓存相关问题

Awesome question—this is the kind of low-level, practical detail that separates surface-level concurrent programming knowledge from really understanding how things work under the hood. Let's break this down step by step, focusing directly on how CPU caches interact with C++11's thread APIs.

First, let's set a foundational truth: modern CPUs don't let caches operate in isolation. They use protocols like MESI (Modified, Exclusive, Shared, Invalid) to keep cache lines consistent across cores. When one core modifies a cache line, it marks that line as "Modified" and invalidates copies in other cores' caches. The problem isn't that caches aren't being cleared—it's that compiler/CPU instruction reordering and lazy cache synchronization can break visibility unless you explicitly enforce rules via C++11's memory model.

What Does std::mutex Actually Do to Caches? #

You're right to wonder about mutexes and cache behavior, but the key isn't "clearing cache"—it's memory fences and enforcing cache consistency:

• When you call lock(), it triggers an acquire fence:
  • This prevents any read operations after the fence from being reordered before it.
  • It also forces the current core to synchronize its cache: any cache lines marked invalid (because another core modified them) will be refreshed from the main memory or the core that holds the updated cache line.
• When you call unlock(), it triggers a release fence:
  • This prevents any write operations before the fence from being reordered after it.
  • It also flushes any modified cache lines in the current core to main memory (or syncs them to other cores via the cache consistency protocol).

Crucially, mutexes don't clear the entire cache—they only synchronize the cache lines that matter for the critical section. The fence ensures that all modifications made by a thread inside a mutex-protected block are visible to any thread that later locks the same mutex.

Read-Only Access: Can You Get Stale Cache Values? #

Absolutely. If Thread 1 is continuously writing to an object without any synchronization, other threads reading that object might see stale cache copies. Here's why:

• The CPU might cache the read-only value indefinitely (since it doesn't know the value is being modified elsewhere).
• Compiler optimizations could reorder reads or even cache the value in a register, never checking main memory again.

Even with no concurrent writes, this is a problem—C++'s standard defines this as a data race, which leads to undefined behavior. To fix it, you need a synchronization mechanism: either wrap the object in a std::atomic, use a mutex for both reads and writes, or use explicit fences to force cache synchronization.

Do Atomic Types Bypass the Cache? #

Nope—atomic types rely on CPU caches to perform efficiently. Bypassing the cache would be catastrophic for performance! Instead, they use:

• CPU atomic instructions: On x86, this might be a lock prefix (which locks the cache line for the duration of the operation, ensuring atomicity via the MESI protocol). On ARM, it's ldrex/strex (load-exclusive/store-exclusive) to detect concurrent modifications.
• Memory model constraints: The memory_order parameters (like memory_order_seq_cst, memory_order_acquire) tell the compiler and CPU how to handle reordering and cache synchronization.

For example, a std::atomic<int>::load(memory_order_acquire) ensures that:

• The read isn't reordered with subsequent operations.
• The CPU will refresh the cache line if it's invalid, so you get the latest value from any core that modified it.

Atomic operations also guarantee visibility for other memory locations based on the memory model: a memory_order_release write ensures that all prior writes by the thread are visible to any thread that performs an acquire read on the same atomic variable.

The Big Picture: How C++11's Memory Model Works With Caches #

C++11 doesn't give you direct control over CPU caches. Instead, it defines a set of rules (the memory model) that tells the compiler and CPU:

• Which operations can be reordered, and which can't.
• When cache synchronization must happen to ensure visibility between threads.

Mutexes, atomic types, and other synchronization primitives are just the user-facing tools to enforce these rules. Under the hood, they translate to the necessary memory fences and atomic instructions that make cache consistency work as expected.

内容的提问来源于stack exchange，提问作者john01dav