硬件原子指令 on Dorkytiger 的小屋

总线锁（Lock Asserted）与缓存锁（Cache Locking）

Mon, 01 Jan 0001 00:00:00 +0000

这个问题问到了并发编程的根基，也是理解无锁编程（Lock-Free）和内存模型（Memory Model）的前提。为了让你直观理解，我们先从“为什么冲突”说起，再深入到硬件是如何“劝架”的。

1. 为什么多核 CPU 同时改一个内存会冲突？

先看一个C++经典场景：两个线程分别在不同核心上执行 global_var++（读-改-写操作）。

冲突的本质不是“同时写入”，而是“基于过期数据的写入”。

为了提速，每个CPU核心都有自己的L1/L2缓存。核心操作数据时，先在缓存里改，之后再同步回主存。

时刻1：核心A和核心B都读取 global_var = 10 到各自的缓存。
时刻2：核心A计算 10+1=11，将 11 写回主存。
时刻3：核心B依然拿着过期的10，计算 10+1=11，将 11 写回主存。

结果：明明加了两次，结果却是11（应该是12）。这就是经典的缓存一致性问题。如果不加锁，最终结果取决于谁最后写（丢失了A的写入）。

2. 硬件如何“锁住”？—— 总线锁（Lock Asserted）

在最早期的多核CPU（或者访问未缓存的内存地址）中，硬件使用粗暴但有效的办法。

原理：CPU在执行特定指令时，会在其前端总线（FSB）上拉高一个名为 LOCK# 的引脚信号（即断言Lock Asserted）。

演示图（概念）：

[ 核心A ] ----( 请求锁总线 )---> [ 总线仲裁器 ]
[ 核心B ] ----( 等待... )------> [ 总线仲裁器 ]
              |
              v
        +--------------+
        |  LOCK# 信号  |  <--- 只有持有者能访问主存
        +--------------+
              |
[ 核心A ] ----> 执行 read-modify-write (原子性) ----> 释放 LOCK#
[ 核心B ] <---- 获得总线使用权 <---- 继续执行

特点：

x86 架构下的核心兵器：`LOCK` 前缀指令

Mon, 01 Jan 0001 00:00:00 +0000

LOCK前缀就像给指令挂上了“原子手雷”，而cmpxchg和xadd则是两种不同战术的手雷。

我们先拆解硬件行为，再看汇编形态，最后看C++如何映射。

1. 灵魂拷问：`LOCK` 前缀到底对CPU做了什么？

当你在汇编指令前加上 LOCK，CPU会执行以下硬件契约：

断言总线锁或缓存锁（我们上节课讲的，优先缓存锁）。
内存屏障（Memory Barrier）：LOCK 隐式包含全屏障（Full Barrier），它会强制：
- 将CPU核心的写缓冲区（Store Buffer） 全部冲刷到缓存。
- 确保这条指令之前的所有读写操作都全局可见，之后的操作不会提前。
原子性保证：在读-改-写期间，不允许其他核心/硬件设备（如DMA）访问该内存地址。

关键点：LOCK 不是“锁住变量”，而是锁住对那个内存地址的访问路径，保证读-改-写是一个不可分割的硬件事务。

2. 核心兵器一：`xadd` —— 原子自增/自减的“特快专列”

汇编原型

lock xadd [mem], reg   ; 等价于：先交换，再相加
; 功能：将 [mem] 的值 与 reg 的值交换，然后将两者之和存回 [mem]
; 返回值（旧值） 存放在 reg 中

执行过程（3步原子完成）

初始: [mem] = 10, reg (eax) = 1
1. 硬件原子性读取 [mem] 的值（10）到内部临时寄存器
2. 将 reg（1）写入 [mem]（此时 [mem]=1，但这是内部中间态）
3. 计算 10 + 1 = 11，写回 [mem]
最终: [mem]=11, reg=10  (reg 拿到了旧值)

典型应用场景

高性能统计计数器（网络包计数、QPS统计）。
无锁栈的 pop 操作（减少引用计数）。

C++ 映射（你几乎不会直接写汇编，但要知道底层）

#include <atomic>

std::atomic<int> counter{0};

// C++ 的 fetch_add 在 x86 上编译为 lock xadd
int old_value = counter.fetch_add(1, std::memory_order_acq_rel);
// old_value 拿到增加前的值，counter 原子 +1

反汇编查看（GCC/Clang）：

ARM 架构下的核心兵器：LL/SC (Link-Load / Store-Conditional)

Mon, 01 Jan 0001 00:00:00 +0000

这个问题切中了移动端和服务器端底层设计的根本分歧。很多从x86转到ARM的开发者，第一反应就是：“为什么ARM没有lock cmpxchg？"。

答案很哲学：x86是复杂（CISC）的"霸道总裁”，而ARM是精简（RISC）的"优雅绅士"。前者直接给你原子指令，后者给你两条指令让你自己组合，以此换取极致的灵活性。

1. 为什么手机芯片（ARM）不直接用 CAS？

直接原因：CAS（Compare-And-Swap）是一个"读-改-写"三合一的巨无霸指令。 在RISC哲学里，一条指令只做一件事。如果强行在ARM里塞入cmpxchg，会：

增加晶体管开销：需要复杂的微码控制器。
破坏多核扩展性：未来的ARM可能几百个核，硬件的CAS逻辑会变成瓶颈。
功耗太高：手机对功耗极其敏感，cmpxchg需要持续锁住总线等待结果，而ARM的LL/SC允许在失败时提前释放。

根本区别在于：

x86的CAS：你告诉CPU “你要么成功，要么失败”，CPU内部硬扛所有冲突。
ARM的LL/SC：CPU告诉你 “我给你做个标记，你试着改，如果我发现有人动过，我就让你重试”——把"判断冲突"的主动权交给软件。

2. 核心兵器拆解：LL（Load-Link）与 SC（Store-Conditional）

这是ARM体系（以及RISC-V、PowerPC）的原子操作基石。

指令原型（ARMv8 示例）

; 假设我们要实现原子自增: *ptr += 1

1.  LL  x0, [x1]      ; Load-Link: 将 x1 地址的值读入 x0，并打上"独占标记"
2.  ADD x0, x0, #1    ; 普通加法（此时还没写回）
3.  SC  x0, [x1]      ; Store-Conditional: 尝试把 x0 写入 x1
                       ; 如果成功，x0=0；如果失败（独占标记丢失），x0=1
4.  CBNZ x0, retry    ; 如果 x0 != 0，跳回重试

硬件执行流程（独占监视器机制）

[ 核心A ]                           [ 核心B ]                    [ 全局监视器 ]
    |                                    |                              |
    |--- 1. LL (读取地址P) -------------->| ---------------------------> | 记录: 核心A 正在监视 地址P
    |   (核心A: 拿到数据10)              |                              | (Exclusive Monitor 置位)
    |                                    |                              |
    |   (此时核心A做加法,但没写)          |--- 对同一地址P 执行写操作 --> | 检测到冲突!
    |                                    | (核心B: 写入11)             | 标记: 核心A 的监视失效
    |                                    |                              |
    |--- 3. SC (尝试写回11) ------------->| ---------------------------> | 检查: 核心A 的监视还在吗?
    |   (返回失败: x0=1)                 |                              | 回复: 不在 (已失效)
    |                                    |                              |
    |--- 4. 检测失败 -> 跳转重试        |                              |

3. 硬件独占监视器（Exclusive Monitor）的工作原理

这是LL/SC的灵魂。它不是锁，而是一个监听状态的触发器。分为两级：

硬件层面的ABA问题

Mon, 01 Jan 0001 00:00:00 +0000

这个问题触及了无锁编程最隐蔽的陷阱。很多人以为ABA只是理论概念，但在内存复用的场景下，它会导致内存损坏甚至安全漏洞。

我们先从硬件视角看为什么CPU会被骗，再深入实际崩溃场景。

1. 硬件层面的"失忆症"

场景重现（用 `cmpxchg`）

初始状态: 共享指针 ptr 指向 内存块A (地址 0x1000)

[时刻1] 线程1 读取 ptr → 0x1000 (期望值)
[时刻2] 线程2 执行:
          ptr 从 0x1000 → 0x2000 (释放A)
          ptr 从 0x2000 → 0x1000 (重新分配，又指向A)
[时刻3] 线程1 执行 lock cmpxchg:
          比较: 当前 ptr (0x1000) == 期望值 (0x1000) → ✅ 相等!
          硬件认为"没人动过"，允许写入新值 0x3000

硬件视角：地址0x1000确实没变，CAS成功。

现实视角：0x1000指向的内存内容可能已经被完全改写（线程2在复用期间修改了A的内容），但CAS毫不知情。

2. 为什么传统锁不会遇到ABA？

// 使用互斥锁 (Mutex)
std::mutex mtx;
{
    std::lock_guard<std::mutex> lock(mtx);
    // 临界区: 执行过程中，其他线程无法进入
    // 所以不可能出现"A→B→A"的中间态
}

关键差异：锁是排他性阻塞，而CAS是乐观重试。锁期间其他线程根本动不了数据，自然不会有ABA。

硬件原子指令 on Dorkytiger 的小屋

总线锁（Lock Asserted）与 缓存锁（Cache Locking）

1. 为什么多核 CPU 同时改一个内存会冲突？

2. 硬件如何“锁住”？—— 总线锁（Lock Asserted）

x86 架构下的核心兵器：`LOCK` 前缀指令

1. 灵魂拷问：LOCK 前缀到底对CPU做了什么？

2. 核心兵器一：xadd —— 原子自增/自减的“特快专列”

汇编原型

执行过程（3步原子完成）

典型应用场景

C++ 映射（你几乎不会直接写汇编，但要知道底层）

ARM 架构下的核心兵器：LL/SC (Link-Load / Store-Conditional)

1. 为什么手机芯片（ARM）不直接用 CAS？

2. 核心兵器拆解：LL（Load-Link）与 SC（Store-Conditional）

指令原型（ARMv8 示例）

硬件执行流程（独占监视器机制）

3. 硬件独占监视器（Exclusive Monitor）的工作原理

硬件层面的ABA问题

1. 硬件层面的"失忆症"

场景重现（用 cmpxchg）

2. 为什么传统锁不会遇到ABA？

总线锁（Lock Asserted）与缓存锁（Cache Locking）

1. 灵魂拷问：`LOCK` 前缀到底对CPU做了什么？

2. 核心兵器一：`xadd` —— 原子自增/自减的“特快专列”

场景重现（用 `cmpxchg`）