x86 CPU是否存在指令重排序？是否无需使用内存屏障？

Great question—this is a super common point of confusion when diving into multi-threaded development across CPU architectures. Let’s break this down clearly.

Do x86 CPUs perform instruction reordering? #

Short answer: Yes, but with strict constraints compared to weaker memory models (like ARM or PowerPC). x86 uses a Total Store Order (TSO) memory model, which only allows specific types of reordering:

• Load → Store: A read operation followed by a write operation can be reordered (the CPU might execute the write first, as long as there’s no data dependency between them).
• Store → Load: A write operation followed by a read operation can be reordered (this is the most common type of reordering you’ll encounter on x86).

Crucially, x86 hardware forbids these reordering types entirely:

• Store → Store: Two write operations will always execute in the order they appear in your code.
• Load → Load: Two read operations will also follow your program’s written order.

If x86 has strict ordering, do I still need memory barriers? #

Absolutely—don’t assume you can skip memory barriers entirely on x86. Here are key scenarios where they’re necessary:

1. Fixing Store→Load reordering bugs
   Let’s say you have a scenario where a thread needs to ensure a write completes before a subsequent read. For example:

   // Thread A
   std::atomic<bool> flag = false;
   int data = 0;
   int some_other_shared_var = 0;
   
   void set_data() {
       data = 42;
       flag.store(true, std::memory_order_relaxed);
       // Without a barrier, x86 might reorder this read to run before the store!
       int temp = some_other_shared_var;
   }
   
   // Thread B
   void update_shared_var() {
       some_other_shared_var = 100;
   }
   

   Here, x86 could reorder Thread A’s read of some_other_shared_var to happen before setting flag to true. If Thread B writes to that variable in the meantime, Thread A might get a stale value. To prevent this, you’d use a memory barrier like mfence or leverage atomic operations with stronger memory ordering (like std::memory_order_release).

2. Stopping compiler-level reordering
   Even if x86 hardware won’t reorder certain instructions, your compiler (like GCC or Clang) might rearrange your code during optimization to improve performance. Memory barriers (or atomic memory order annotations) tell the compiler not to reorder instructions around that point.

3. Cross-platform compatibility
   If your code needs to run on both x86 and weaker memory model architectures (like ARM), you’ll need to follow the stricter rules required by those systems. Adding the necessary memory barriers ensures your code behaves correctly everywhere, not just on x86.

4. Interacting with I/O or memory-mapped hardware
   When working with hardware devices (like network cards or GPIO), you can’t let the CPU reorder read/write operations. Memory barriers force the CPU to execute I/O instructions in the exact order you specify, which is critical for device communication.

Quick recap #

x86 does reorder instructions, but only in limited ways. While its TSO model eliminates many of the reordering issues you’d face on other CPUs, memory barriers are still essential for specific synchronization scenarios, compiler optimization control, cross-platform code, and hardware interactions.

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