C语言中任意大小的_Atomic结构体赋值是否具备原子性？

问题背景 #

根据C标准规定，除明确禁止的类型外，任何类型都可以用_Atomic限定。比如定义一个包含4KB数组的原子结构体：

struct S {
    char a[4096];
};

_Atomic struct S s1, s2;

执行赋值操作s1 = s2;时，会生成包含__atomic_load和__atomic_store调用的x86-64汇编。由此引出几个核心疑问：

• 这类大尺寸结构体的赋值是否具备真正的原子性？比如复制4KB数组时，其他线程是否完全无法访问？
• 如果并非硬件级原子操作，为什么编译器不发出警告？
• 允许_Atomic修饰这类大结构体的实际用途是什么？
• 此前认知中只有sizeof(T) <= 16的小对象才能原子化，这个结论是否准确？

C标准依据 #

C11标准明确了_Atomic的禁用类型：

§6.7.2.4¶3：原子类型说明符中的类型名不得指代数组类型、函数类型、原子类型或限定类型。

§6.7.3¶3：被_Atomic限定符修饰的类型不得是数组类型或函数类型。

也就是说，只要不是上述禁用类型，都可以用_Atomic修饰。GCC和Clang编译此类代码均无报错，符合标准要求。

如果对结构体内部的数组有顾虑，也可以参考如下纯多成员结构体的示例，编译后同样会生成__atomic_load/__atomic_store调用：

struct S2 {
    int a1, a2, a3, a4, a5, a6, a7, a8, a9, a10;
    int a11, a12, a13, a14, a15, a16, a17, a18, a19, a20;
    // 扩展更多成员使结构体尺寸超过16字节
};

_Atomic struct S2 s3, s4;

核心问题解答 #

1. 大尺寸原子结构体的赋值是否具备原子性？ #

不具备硬件级的原子性，但能保证代码层面的原子语义。

• __atomic_load和__atomic_store是编译器提供的库函数，内部通过隐式锁（比如pthread互斥锁）实现同步，不是单条硬件原子指令。
• 复制过程中，其他线程访问该原子对象时会被阻塞，不会看到半复制的中间状态——这保证了操作的线程安全与整体不可分割性，但和硬件原子操作（不可中断的单步指令）的实现机制不同。

2. 为什么编译器不发出警告？ #

因为这种用法完全符合C标准：

• 标准仅禁止直接修饰数组、函数等类型，结构体（无论内部成员尺寸多大）属于允许的范畴。
• 编译器用锁实现大尺寸原子对象的操作，是标准允许的“替代实现”，只要能保证原子语义即可，因此无需警告。

3. 允许_Atomic修饰大结构体的用途是什么？ #

• 简化线程安全代码：无需手动加锁解锁，编译器自动处理同步逻辑，避免漏加锁、死锁等人为错误。
• 保证状态的完整性：确保其他线程看到的结构体要么是完整的旧值，要么是完整的新值，不会出现部分更新的中间状态。
• 支持内存序控制：可以配合atomic_store_explicit等API指定内存序（如memory_order_relaxed、memory_order_acq_rel），比手动锁+内存屏障更简洁规范。

4. 关于sizeof(T) <= 16的认知 #

这个结论仅针对硬件级原子操作：

• x86-64平台上，16字节以内的原子对象可以通过cmpxchg16b等单条硬件指令实现原子操作，无需锁。
• 超过16字节的对象，编译器会自动 fallback 到锁实现的库函数，虽然不是硬件原子，但代码层面的原子语义依然得到保证。

内容的提问来源于stack exchange，提问作者Paul J. Lucas