32/64位处理器上8/16-bit atomics使用及实现问题咨询

标准层面的规定 #

C11和C++11引入标准原子库时，从来没强制要求任何宽度的原子类型必须采用无锁实现，8位、16位这类小宽度原子也不例外：

• 标准提供了明确的检查手段：C语言可通过ATOMIC_CHAR_LOCK_FREE、ATOMIC_SHORT_LOCK_FREE宏判断对应类型的无锁状态，C++可通过std::atomic<T>::is_always_lock_free静态成员、std::atomic_is_lock_free运行时接口检查。上述接口返回值为2代表编译期可确定永远无锁，返回1代表运行时才能确认无锁状态，返回0代表始终基于互斥锁实现。
• 标准仅默认约定：与平台原生指针位宽一致的原子类型（比如32位平台上的std::atomic<int32_t>、64位平台上的std::atomic<int64_t>）在通用实现上优先采用无锁设计，小宽度原子的实现完全由编译器和硬件平台决定。

主流32/64位CPU上的无锁实现现状 #

目前消费级、服务器级领域的主流通用CPU，只要是2005年之后量产的型号，对齐的8/16位原子操作均为原生无锁实现：

• x86/x86_64架构从80486开始就原生支持1、2、4、8字节的原子指令，通过lock指令前缀搭配xchg、cmpxchg、add等指令的字节/字版本（比如操作1字节的lock incb、操作2字节的lock cmpxchgw）直接实现，不需要任何软件模拟。
• ARMv6K及之后的32位ARM架构、所有AArch64架构，通过独占访问指令（32位下的ldrexb/strexb、ldrexh/strexh，64位下的ldarb/stllrb、ldarh/stllrh）原生支持1、2、4、8字节无锁原子操作。
• 带A原子扩展的RISC-V架构，明确原生支持1、2、4、8字节的原子内存操作，无需模拟。
  只有在老旧嵌入式MCU、无原子扩展的软核CPU、特殊仿真环境下，8/16位原子才会退化为基于隐藏全局互斥锁的实现。

与原生位宽原子的性能对比 #

原子操作的核心开销来自缓存一致性协议的同步成本，而非操作的数据宽度，因此在对齐前提下：

• x86/x86_64、AArch64、现代ARMv7、RISC-V平台上，8/16位原子操作的延迟、吞吐量和同平台原生位宽（32位/64位）原子操作几乎没有可感知的差异，二者触发缓存锁/缓存行失效的开销完全一致。
• 仅在部分早期32位MIPS、ARMv6之前的老旧架构上，因为硬件仅原生支持32位原子操作，小宽度原子需要通过32位ll/sc指令配合移位、位掩码操作模拟，会比原生32位原子多2~3个指令周期的开销，但这个开销依然比互斥锁实现低两个数量级。
  不要想当然觉得小宽度原子占的字节少就跑的更快——原子操作的大头开销是缓存一致性同步，只要操作的地址在同一个缓存行里，不管你改1个bit还是改64位，同步成本都是一样的。

常见使用陷阱 #

• 对齐问题：虽然编译器会为标准std::atomic/_Atomic类型自动设置正确的对齐，但如果你用C++20的std::atomic_ref、或者手动对任意内存地址执行编译器原子内置函数操作，一旦8/16位原子的地址没有按自身宽度自然对齐、甚至跨了缓存行边界，在ARM等弱内存序架构上会直接触发未定义行为（返回错误值、随机崩溃），在x86平台上虽然不会出错，但会触发总线锁，性能比对齐的原子操作慢几十上百倍。
• 同字/同缓存行冲突：因为8/16位变量占用空间小，很容易把多个独立更新的原子变量塞到同一个缓存行甚至同一个32位字内。部分老旧32位ARM实现的独占访问监控粒度是32位字，不是单个字节/半字，两个核心分别改同一个32位字里的两个不同字节原子变量时，会反复判定存储冲突，导致独占存储指令一直重试进入活锁；即使在新架构上，相邻变量的原子写也会频繁触发缓存行失效，导致性能比单独分布的原子变量差一个数量级以上。
• 无锁属性的想当然假设：不要默认所有平台上的8/16位原子都是无锁的，在嵌入式、特殊编译目标场景下，一定要提前检查对应的LOCK_FREE宏——如果小宽度原子被编译器实现为隐藏全局锁，在信号处理函数、中断上下文中调用会直接触发死锁。
• 网上流传的「小宽度原子写会覆盖相邻字节」是已经过时的错误说法：所有支持小宽度原子的现代CPU都带字节选通逻辑，写1字节时只会更新对应位置的8位数据，不会读改写整个字误伤相邻变量，不需要额外加锁保护周边内存。

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