这篇讨论围绕 Linux 内核的 rseq(2)（restartable sequences，重启序列接口），一种让用户态短临界区在被抢占时从头重试的机制。它常被拿来和 mutex、atomics 以及 STM（Software Transactional Memory，软件事务内存）比较，因为它试图在 CPU 本地数据上减少同步成本。评论里还提到 librseq（rseq 的辅助库）和更早的 Sun 研究论文，说明这套思路既有现成工具链，也有较早的学术前身。原文用 AMD Threadripper（高核心数桌面处理器）和昂贵工作站做示例，并带着明显的讽刺语气，所以技术讨论很快和对作者表达方式的争论混在了一起。
评论者把 rseq 解释成 Linux 内核提供的一种短临界区机制：代码要么一口气跑完，要么在被抢占或中断时跳到预设的 abort/retry vector 从头重启。它不是把已经执行过的写操作回滚，所以开发者必须把真正的提交放在最后，并让中途状态无害。有人强调，内核与用户态之间通过 shared memory 交换状态，这让它像一个极小的数据库事务；也有人提到后续还想加入尽量让临界区先跑完再打断的时间片扩展，但在 preemptive multitasking 里不可能给出绝对不被打断的承诺。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
有人补充说，rseq 不一定要手写 assembly，librseq 已经为 counters、linked lists 等常见模式提供了辅助封装。这样大多数应用可以直接调用库，而不是自己拼接那几条关键指令。另一条评论则指出，Sun 早年的论文已经提前讨论过类似思路，说明这套方法并非最近才冒出来。
另一条主线在争论 CPU 的内部 mutex 到底是不是比用户态 mutex 更差。评论把这个说法改写成 cache coherency 问题：CPU 以 cache line 为单位同步，多个 core 如果碰到同一条 64-byte cache line，就会因为 false sharing 产生巨额开销。有人指出，是否比锁更慢完全取决于 workload；把数据分片、把计数器对齐到不同 cache line，往往比单纯争论硬件实现更有意义。
很多评论并不是在认真争 rseq，而是在吐槽文章开头那句没有 2 万美元工作站就会被淘汰的夸张语气。有人把它理解成明显的讽刺，也有人认为这种写法不专业，尤其当文中还精确列出昂贵硬件价格、甚至把 AWS 租机和折扣 workstation 拿来对比时；还有人顺手拿 512 GB RAM 从 2,776 美元涨到 18,299 美元的例子继续放大这种吐槽。讨论随后延伸到作者本人的 donation 请求、买房和私人飞机的说法，以及 plagiarism 和 attribution 风波，使得不少人对文章的动机和可信度更加警惕。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14]
还有人对通过 shared memory 和 kernel 双向通信这点本能地表示不安，觉得这种设计听起来就像把复杂的同步问题塞进共享状态里。评论本身没有展开细节反驳，但这种语气反映出对 correctness 和调试复杂度的直觉担忧。尤其当机制要依赖 kernel 记住用户态临界区的状态时，很多人第一反应就是这能靠谱吗。
restartable sequences (rseq): Linux 内核提供的接口，让用户态短临界区在被打断后可以从头重试，用来减少锁和原子操作开销。
false sharing: 不同线程/核心写同一条 cache line 上的不同变量，导致 cache coherency 争用和性能暴跌。
cache line: CPU cache coherency 的基本同步粒度，常见为 64 bytes。
STM (Software Transactional Memory): 用事务、提交和回滚来管理并发访问共享数据的软件并发模型。
librseq: rseq 的辅助库，封装了 counters、linked lists 等常见用法，减少手写 assembly 的需求。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。