Paul E. McKenney 的 perfbook 实在太好看了，虽然我才肛开始读到第四章，但已经解决了好几个困扰我多年的技术问题了。

比如前两周我才和 codex 讨论了 go 里两个 goroutines 并发（并行）读写一个 u64 全局变量到底有什么危害，我之前以为最多就是并发写导致另一线程读到旧值，这种 bug 我是可以容忍的，于是省掉 atomic.Load 好了，毕竟原子操作性能也不好。

而书上 4.3.4.1 Shared-Variable Shenanigans 这一节列出来一大堆无保护并发读写共享变量的潜在危害，其中 Store tearing 引用的这个 2019 年很新(?)的内核讨论令我大吃一精： https://lore.kernel.org/lkml/20190821103200.kpufwtviqhpbuv2n@willie-the-truck/

void bar(u64 *x)
{
  *x = 0xabcdef10abcdef10;
}

上面的 bar 在某个历史版本 arm64 gcc -O2 编译出的结果是

bar:
  mov  w1, 61200
  movk  w1, 0xabcd, lsl 16
  stp  w1, w1, [x0]
  ret

而 arm64 在 v8.4a 之前 stp store pair 指令是非原子的，如果有无保护并发读，另一个线程可能会读到只修改了一半 32bits 的变量。

书上说这类问题用 volatile / WRITE_ONCE / READ_ONCE 就可以比较轻量级地解决，但 go 没有 volatile 只能用原子指令，令人忧愁。