基于内存屏障的C语言无锁缓冲区拷贝方案验证及疑问

问题背景 #

现有一段需同时兼容C/C++环境的代码（因此无法使用原子操作），功能是将输入数组拷贝到全局数组my_str，多个线程可能调用thread_func()。要求确保my_str仅在完全初始化完成后才被返回——已知缓冲区最后一个字节不可能为0，因此只需通过检查该字节是否非0来判断初始化状态。

由于编译器/CPU的指令重排序，可能出现最后一个字节先于前面字节被写入的情况，导致thread_func()返回部分初始化的缓冲区。希望用内存屏障解决该问题，互斥锁因开销过大不考虑。另外，所有线程传入的input_buf内容相同，因此即使多个线程重复调用init()也没问题，只要最终thread_func()返回有效的my_str，且初始化完成后的调用直接返回即可。

方案1：仅对最后一个字节执行__sync_bool_compare_and_swap #

#define STR_LEN 100
static uint8_t my_str[STR_LEN] = {0};

static void init(uint8_t input_buf[STR_LEN])
{
    for (int i = 0; i < STR_LEN - 1; ++i) {
        my_str[i] = input_buf[i];
    }
    __sync_bool_compare_and_swap(my_str, 0, input_buf[STR_LEN - 1]);
}

const char * thread_func(char input_buf[STR_LEN])
{
    if (my_str[STR_LEN - 1] == 0) {
        init(input_buf);
    }
    return my_str;
}

• 可行性：完全可行
• 你的理解正确：__sync_bool_compare_and_swap（CAS）是全内存屏障，它会禁止屏障之前的所有存储/加载操作与之后的操作发生重排序，约束的是全局内存操作顺序，而非仅针对传入的变量。此方案中，前99个字节的写入会全部在CAS操作前完成并对其他线程可见，当其他线程检测到最后一个字节非0时，整个数组已经初始化完成，不会拿到部分拷贝的缓冲区。
• 这是四个方案中效率最高的，仅引入一次全屏障开销。

方案2：对每个写入操作执行__sync_bool_compare_and_swap #

static void init(char input_buf[STR_LEN])
{
    for (int i = 0; i < STR_LEN; ++i) {
        __sync_bool_compare_and_swap(my_str + i, 0, input_buf[i]);
    }
}

• 可行性：可行，但完全没必要
• 每个CAS操作都是全屏障，确实能保证字节写入顺序与代码逻辑一致，不会出现重排序。但正如你判断的，这个方案性能极差——100次全屏障操作会带来大量CPU流水线停顿和缓存同步开销，远不如方案1高效。仅一次屏障就足以保证整体顺序，多次调用属于过度设计。

方案3：每个字节拷贝前执行__sync_synchronize #

static void init(char input_buf[STR_LEN])
{
    for (int i = 0; i < STR_LEN; ++i) {
        __sync_synchronize();
        my_str[i] = input_buf[i];
    }
}

• 可行性：不可行
• __sync_synchronize是全内存屏障，但你把它放在写入操作之前的逻辑完全错误：屏障的作用是确保屏障之前的所有内存操作完成后，才能执行屏障之后的操作。此方案中，每个循环的屏障只能保证当前写入之前的屏障操作完成，无法约束前一个字节的写入与当前字节写入的顺序——编译器/CPU仍然可能把后面的写入提前到前面的屏障之前，最后一个字节提前写入的问题依然存在。
• 退一步说，即使逻辑正确，100次全屏障的开销也远大于方案2，完全不可取。

方案4：条件性执行__sync_synchronize #

static void init(char input_buf[STR_LEN], bool use_sync)
{
    for (int i = 0; i < STR_LEN; ++i) {
        if (use_sync) {
            __sync_synchronize();
        }
        my_str[i] = input_buf[i];
    }
}

• 可行性：不可行，你的理解存在错误
  1. 编译器层面：即使use_sync是参数，编译器仍可能通过数据流分析确定其实际取值（比如调用方固定传值），从而进行重排序优化；即使无法确定，条件分支中的屏障也无法覆盖所有写入的顺序——当use_sync为false时，无任何屏障约束，重排序问题依然存在。
  2. 硬件层面：当use_sync为true时，循环中的屏障只能约束当前写入的前置操作，无法保证整个数组的写入顺序符合逻辑；当use_sync为false时，完全没有硬件屏障，最后一个字节提前写入的问题无法解决。
• 该方案既无法保证正确性，也不能带来有效性能提升，没有实用价值。

额外的内存屏障核心知识 #

• 软件屏障（编译器屏障）：仅阻止编译器对屏障前后的指令重排序，不影响CPU的指令重排序，比如asm volatile("" ::: "memory")。
• 硬件屏障：阻止CPU对屏障前后的内存操作重排序，不同CPU架构（x86、ARM、RISC-V）的重排序规则不同，硬件屏障分为LoadLoad、StoreStore、LoadStore、StoreLoad四种类型，作用范围各有差异。
• 全内存屏障：同时禁止所有类型的内存操作重排序，__sync_synchronize和__sync_bool_compare_and_swap都属于此类，开销最大但能提供最严格的内存顺序保证。
• 在多线程一次性初始化场景中，后置单全屏障（如方案1）是最优选择：既保证所有初始化写入在标记位写入前完成，又只引入一次屏障开销，避免不必要的性能损耗。

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