atomic operations 与原子操作
这页讲的是：有些共享状态更新小到不值得为它套一整层大锁，但又绝不能让“读到一半、改到一半”的结果泄露出去。学这页的重点，是理解 atomic operation 的核心不是“更快”，而是“把某个最小读改写动作变成不可被拆开的整体”。
这块是什么
atomic operations 与原子操作，讲的是 Linux 怎样对某些很小、很基础的共享变量更新，提供“要么整个完成，要么别人看不到中间态”的语义。它关注的是把某个最小状态变化做成不可分割的单位，而不是保护一个很长的临界区。
可以把它理解成：你要把电梯楼层数字从 7 改成 8，别人不能看到一半擦掉、还没写完的中间状态。这个动作虽然很小，但必须整体发生。
它负责什么
保证最小更新不可分割
- 某些计数、标志位和状态跳变只涉及很小的变量
- 但这些更新仍然不能被并发打碎
- 原子操作把单次读改写变成整体动作
- 避免别人看见半完成结果
减少为小状态引入重型锁
- 不是所有共享访问都值得套一层大临界区
- 有些场景只想安全地改一个小值
- 原子操作能给这类最小共享提供更合身的工具
- 让小同步问题不用总升级成大锁问题
给更高层协议提供积木
- 很多锁、计数、引用和无锁技巧背后都依赖原子语义
- 它本身不总是完整解决方案
- 却常是更大并发协议的基础零件
- 把“最小一致动作”正式标准化
为什么它不是“可以替代锁的小技巧”
| 如果想得太简单 | 会怎样 | 真正关键在哪 |
|---|
| 觉得原子操作比锁高级所以都能替代 | 会忽略它通常只能保护很小的状态变更，而不是整段复杂协议。 | 原子操作解决的是最小动作，不是所有协作关系。 |
| 把“原子”理解成天然有完整顺序 | 会漏掉可见性和先后顺序仍可能需要额外约束。 | 不可分割不等于所有 CPU 自动按你想的顺序观察。 |
| 只看单次加减 | 会低估它在标志切换、引用管理和状态机入口上的基础作用。 | 它是很多并发协议的底层砖块。 |
| 觉得用了原子变量就不再需要设计 | 会把本来更大的并发协议问题误缩成一个变量操作问题。 | 很多难点仍在“什么时候改、别人怎么看到”。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| atomic operation | 某个最小读改写动作以不可分割方式完成，外界看不到中间态。 |
| 读改写 | 先读旧值、再基于它生成新值并写回，这一整步要么整体发生。 |
| 计数 / 标志 | 原子操作最常出现的对象往往是小型共享状态，而不是大块结构。 |
| 不可分割 | 别的执行者不能在这个最小动作中途插进来看或改出半成品。 |
| 基础积木 | 很多更复杂同步原语都会依赖这类最小原子语义。 |
为什么重要
- 它解释了为什么并发控制不总是“要么上大锁，要么完全无保护”。
- 很多共享计数、状态位和轻量协作路径，都离不开这种最小原子动作。
- 理解这层后，你会更容易把引用计数、锁实现和更底层并发语义串起来。
- 它让你看到：有时系统真正想保护的，只是一个很小但绝不能裂开的状态跳变。
常见误解
- 误解一：原子操作总比锁更好。实际上很多复杂对象关系根本不是单个原子变量能说清。
- 误解二：原子就等于全局顺序一致。实际上可见性和排序仍常要额外考虑。
- 误解三：它只是性能优化细节。实际上很多正确性本身就建立在最小原子动作上。
它不负责什么
- 它不适合保护较长临界区或多步对象协议。
- 它不自动解决跨多个变量的整体一致性问题。
- 它不等于内存屏障；动作原子化和观察顺序约束不是一回事。
和其他模块的关系
| 相关模块 | 关系 |
|---|
| spinlock / mutex | 锁更擅长保护较完整的临界区，原子操作更像保护最小共享动作。 |
| kref 与引用计数 | 很多引用计数语义都依赖原子加减这类基础能力。 |
| memory barriers | 原子动作保证不可分割，但别人何时按什么顺序看到，常要再看屏障语义。 |
| 状态机与标志位 | 很多轻量协作入口都是先靠原子标志切换，再接更大流程。 |
读完这页后，你应该能回答
- 为什么原子操作真正保护的是“最小状态跳变”，而不是整段复杂逻辑？
- 为什么“原子”并不自动等于“大家都按同一顺序看到所有事情”？
- 为什么很多更高层同步原语都把原子语义当成地基，而不是终点？
后面适合继续问：atomic_t 和 refcount/kref 最容易混在哪？什么时候一个计数器该用原子操作，什么时候反而该上锁？如果多个变量必须一起保持关系，为什么单靠原子加减通常不够？