这篇文章讨论了Linux内核中的READONCE()和WRITEONCE()宏在Rust语言中的适用性问题。这些宏用于确保内存访问的原子性和顺序性，但在Rust中由于语言本身的安全保证机制，可能不需要直接移植这些宏。文章探讨了Rust的内存模型与C的不同之处，以及在内核开发中如何处理这些差异。

标题：READONCE()与WRITEONCE()在Rust中的争议

文章主要讨论了Linux内核中广泛使用的READONCE()和WRITEONCE()宏是否应该引入Rust代码的争议。

核心内容： 1. 现状与背景 - 这两个宏在内核中有近8000处调用点，主要用于实现无锁算法和设备内存访问 - 功能说明：强制编译器对指定位置执行精确的单次读写操作，防止优化导致的读写合并或重排 - 保证原子性：确保并发读写时不会出现数据撕裂现象

2. Rust社区的提案与反对意见

• Alice Ryhl提出为Rust实现这两个宏的补丁
• 其他Rust开发者反对，认为应该使用内核Atomic模块的relaxed操作
• 反对理由：
  • 现有宏语义复杂（同时涉及原子性和数据竞争预防）
  • Rust的Atomic方案能更精确地表达操作意图
  • 现有宏是"创可贴"式的解决方案

3. 潜在影响

• 可能导致内核中C和Rust代码在并发数据访问上采用不同API
• 引发对C代码中类似问题的关注（如某些代码错误假设普通写入具有原子性）
• 历史上倾向于保持两种语言接口一致，但这次可能例外

4. 技术讨论延伸

• 关于volatile操作在Rust中线程安全性的讨论
• 不同架构下原子操作的实现差异
• C11原子模型与内核实际需求的差距

文章最后指出，这可能是内核中C和Rust代码采用不同并发处理方式的典型案例。

（注：原文中大量技术讨论和用户评论因过于专业或与主题关联性不强，已做适当精简）

这篇评论主要围绕Rust和C/C++在并发数据访问实现上的差异展开讨论，主要观点如下：

1. 关于内存顺序语义的技术争议

• gpderetta指出内核明确赋予readonce消费语义，降级为宽松操作是错误的 引用："the kernel explicitly gives consume semantics to readonce...technically lowering it to a relaxed operation is wrong"
• staticassertion认为Rust明确排序语义的做法更优 引用："it'll be far less challenging for the Rust code, which will actually define the ordering semantics explicitly"

2. 关于开发体验的分歧

• chrismsimpson担忧可能造成Linux开发的"双轨制"体验 引用："does this kind of thing create a two tier Linux development experience?"
• staticassertion预测Rust代码可能成为语义参考标准 引用："end up as the code where someone goes to read the actual semantics to determine what the C code should do"

3. 关于API命名的讨论

• epolanski询问对命名方式的看法 引用："What is your take on their names instead of 'atomicread' and 'atomicwrite'?"

4. 对文档现状的调侃

• bheadmaster幽默指出重要API却缺乏文档 引用："they are almost entirely absent from the kernel's documentation. Made me chuckle"

5. 关于编译器抽象的思考

• amelius用导弹发射的比喻说明编译器抽象可能导致的问题 引用："If reading twice would, say, launch missiles...a compiler would never replace a single read by two reads"