内存屏障

编译器屏障 Compiler barrier

/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory") 
阻止编译器重排，保证编译程序时在优化屏障之前的指令不会在优化屏障之后执行。

 CPU屏障 CPU barrier
CPU级别内存屏障其作用有两个：
防止指令之间的重排序
保证数据的可见性
指令重排中Load和Store两种操作会有Load-Store、Store-Load、Load-Load、Store-Store这四种可能的乱序结果。

Intel为此提供三种内存屏障指令：

sfence ，实现Store Barrior 会将store buffer中缓存的修改刷入L1 cache中，使得其他cpu核可以观察到这些修改，而且之后的写操作不会被调度到之前，即sfence之前的写操作一定在sfence完成且全局可见；
lfence ，实现Load Barrior 会将invalidate queue失效，强制读取入L1 cache中，而且lfence之后的读操作不会被调度到之前，即lfence之前的读操作一定在lfence完成（并未规定全局可见性）；
mfence ，实现Full Barrior 同时刷新store buffer和invalidate queue，保证了mfence前后的读写操作的顺序，同时要求mfence之后写操作结果全局可见之前，mfence之前写操作结果全局可见；
lock 用来修饰当前指令操作的内存只能由当前CPU使用，若指令不操作内存仍然由用，因为这个修饰会让指令操作本身原子化，而且自带Full Barrior效果；还有指令比如IO操作的指令、exch等原子交换的指令，任何带有lock前缀的指令以及CPUID等指令都有内存屏障的作用。
X86-64下仅支持一种指令重排：Store-Load ，即读操作可能会重排到写操作前面，同时不同线程的写操作并没有保证全局可见，例子见《Intel® 64 and IA-32 Architectures Software Developer’s Manual》手册8.6.1、8.2.3.7节。要注意的是这个问题只能用mfence解决，不能靠组合sfence和lfence解决。（用sfence+lfence组合仅可以解决重排问题，但不能解决全局可见性问题，简单理解不如视为sfence和lfence本身也能乱序重拍）

X86-64一般情况根本不会需要使用lfence与sfence这两个指令，除非操作Write-Through内存或使用 non-temporal 指令（NT指令，属于SSE指令集），比如movntdq, movnti, maskmovq，这些指令也使用Write-Through内存策略，通常使用在图形学或视频处理，Linux编程里就需要使用GNC提供的专门的函数（例子见参考资料13：Memory part 5: What programmers can do）。

下面是GNU中的三种内存屏障定义方法，结合了编译器屏障和三种CPU屏障指令

#define lfence() __asm__ __volatile__("lfence": : :"memory") 
#define sfence() __asm__ __volatile__("sfence": : :"memory") 
#define mfence() __asm__ __volatile__("mfence": : :"memory") 
代码中仍然使用lfence()与sfence()这两个内存屏障应该也是一种长远的考虑。按照Interface写代码是最保险的，万一Intel以后出一个采用弱一致模型的CPU，遗留代码出问题就不好了。目前在X86下面视为编译器屏障即可。

GCC 4以后的版本也提供了Built-in的屏障函数__sync_synchronize()，这个屏障函数既是编译屏障又是内存屏障，代码插入这个函数的地方会被安插一条mfence指令。

GCC 内置__sync_synchronize函数：屏障（内置同步）将简单地转换为硬件屏障，如果您使用的是 x86，则可能是栅栏（mfence/sfence）操作，或者其他架构中的等效物。CPU 也可能在运行时做各种优化，最重要的是实际上是乱序执行操作——这条指令告诉它确保加载或存储不能通过这一点，必须在正确的一侧观察同步点。

C++11为内存屏障提供了专门的函数std::atomic_thread_fence，方便移植统一行为而且可以配合内存模型进行设置，比如实现Acquire-release语义：

#include <atomic>
std::atomic_thread_fence(std::memory_order_acquire);
std::atomic_thread_fence(std::memory_order_release);

std::atomic_thread_fence是C++中的一个原子操作，用于在多线程环境下提供内存序的同步。

以下是一个可运行的代码示例，展示了如何使用 std::atomic_thread_fence 来保证内存顺序：

#include <iostream>
#include <thread>
#include <atomic>
std::atomic<int> x(0);
std::atomic<int> y(0);
void thread1() {
    x.store(1, std::memory_order_relaxed);
    std::atomic_thread_fence(std::memory_order_release);
    int val = y.load(std::memory_order_acquire);
    std::cout << "Thread 1: y = " << val << std::endl;
}
void thread2() {
    y.store(1, std::memory_order_relaxed);
    std::atomic_thread_fence(std::memory_order_release);
    int val = x.load(std::memory_order_acquire);
    std::cout << "Thread 2: x = " << val << std::endl;
}
int main() {
    std::thread t1(thread1);
    std::thread t2(thread2);
    t1.join();
    t2.join();
    return 0;
}

 

以下两个例子来自于cppreference：

需要注意的是atomic_store_explicit、atomic_load_explicit等函数在c++20过时的，即不推荐使用了，c++26版已被移除。

// Global
std::string computation(int);
void print(std::string);
 
std::atomic<int> arr[3] = {-1, -1, -1};
std::string data[1000]; //non-atomic data
 
// Thread A, compute 3 values.
void ThreadA(int v0, int v1, int v2)
{
//  assert(0 <= v0, v1, v2 < 1000);
    data[v0] = computation(v0);
    data[v1] = computation(v1);
    data[v2] = computation(v2);
    std::atomic_thread_fence(std::memory_order_release);
    std::atomic_store_explicit(&arr[0], v0, std::memory_order_relaxed);
    std::atomic_store_explicit(&arr[1], v1, std::memory_order_relaxed);
    std::atomic_store_explicit(&arr[2], v2, std::memory_order_relaxed);
}
 
// Thread B, prints between 0 and 3 values already computed.
void ThreadB()
{
    int v0 = std::atomic_load_explicit(&arr[0], std::memory_order_relaxed);
    int v1 = std::atomic_load_explicit(&arr[1], std::memory_order_relaxed);
    int v2 = std::atomic_load_explicit(&arr[2], std::memory_order_relaxed);
    std::atomic_thread_fence(std::memory_order_acquire);
//  v0, v1, v2 might turn out to be -1, some or all of them.
//  Otherwise it is safe to read the non-atomic data because of the fences:
    if (v0 != -1)
        print(data[v0]);
    if (v1 != -1)
        print(data[v1]);
    if (v2 != -1)
        print(data[v2]);
}

 

const int num_mailboxes = 32;
std::atomic<int> mailbox_receiver[num_mailboxes];
std::string mailbox_data[num_mailboxes];
 
// The writer threads update non-atomic shared data 
// and then update mailbox_receiver[i] as follows:
mailbox_data[i] = ...;
std::atomic_store_explicit(&mailbox_receiver[i], receiver_id, std::memory_order_release);
 
// Reader thread needs to check all mailbox[i], but only needs to sync with one.
for (int i = 0; i < num_mailboxes; ++i)
    if (std::atomic_load_explicit(&mailbox_receiver[i],
        std::memory_order_relaxed) == my_id)
    {
        // synchronize with just one writer
        std::atomic_thread_fence(std::memory_order_acquire);
        // guaranteed to observe everything done in the writer thread
        // before the atomic_store_explicit()
        do_work(mailbox_data[i]);
    }

摘自：https://zhuanlan.zhihu.com/p/43526907，有删改。

参考：

1. C/C++ Volatile关键词深度剖析
2. java的并发关键字volatile
3. 指令重排序
4. 多处理器编程：从缓存一致性到内存模型
5. 聊聊原子变量、锁、内存屏障那点事
6. Why Memory Barriers？中文翻译（上）
7. LINUX内核内存屏障
8. Memory Model: 从多处理器到高级语言
9. 高并发编程--多处理器编程中的一致性问题(上)
10. 高并发编程--多处理器编程中的一致性问题(下)
11. 如何理解C++11中的六种内存模型
12. C/C++11 mappings to processors
13. When should I use _mm_sfence _mm_lfence and _mm_mfence
14. Why is (or isn't?) SFENCE + LFENCE equivalent to MFENCE?
15. Memory part 5: What programmers can do
16. Memory Reordering Caught in the Act
17. C++ and the Perils of Double-Checked Locking
18. 内存模型
19. UNIX多线程环境下屏障功能（barrier）浅析
20. std::atomic_thread_fence