C与Rust内存模型对比：从READ_ONCE到原子操作-代码聚汇网

C与Rust内存模型对比：从READ_ONCE到原子操作

金宇澄

1. 项目背景与核心概念

在并发编程领域，内存访问的原子性和可见性一直是开发者需要面对的核心挑战。最近我在研究Linux内核源码时，注意到一个有趣的现象：内核中广泛使用的READ_ONCE()和WRITE_ONCE()宏，在Rust语言中却找不到直接对应的实现。这引发了我对两种语言内存模型差异的深入思考。

READ_ONCE()和WRITE_ONCE()是Linux内核中用于保证单次读写原子性的关键宏。它们的主要作用是防止编译器对内存访问进行优化重排，确保每次访问都直接从内存加载或存储。在内核开发中，这种精确控制内存访问的行为至关重要，特别是在无锁数据结构和RCU（Read-Copy-Update）机制中。

注意：虽然这些宏看起来简单，但它们背后涉及编译器的优化行为、CPU的内存模型以及并发编程中的可见性问题，理解这些底层机制对写出正确的并发代码至关重要。

2. C语言中的内存访问控制

2.1 READ_ONCE()的实现原理

在Linux内核源码中，READ_ONCE()的定义大致如下（简化版）：

c复制#define READ_ONCE(x) ({ \
    typeof(x) __val; \
    __read_once_size(&(x), &__val, sizeof(__val)); \
    __val; \
})

这个宏的核心是__read_once_size函数，它通过内联汇编告诉编译器：这个读取操作必须精确执行一次，不能被优化掉或与其他操作重排序。这种保证在以下场景特别重要：

当共享变量可能被其他线程异步修改时
在无锁算法中需要精确控制内存访问顺序时
当变量的值可能被硬件设备修改时

2.2 WRITE_ONCE()的工作机制

对应的WRITE_ONCE()宏实现如下：

c复制#define WRITE_ONCE(x, val) ({ \
    typeof(x) __val = (val); \
    __write_once_size(&(x), &__val, sizeof(__val)); \
    __val; \
})

这个宏确保写入操作会实际发生到内存中，不会被编译器优化掉。考虑以下代码：

c复制int flag = 0;

void thread_A(void) {
    while (!flag) {
        // 等待flag变化
    }
    // 执行后续操作
}

void thread_B(void) {
    // 一些准备工作
    flag = 1;
}

如果没有WRITE_ONCE()，编译器可能会认为flag只在当前线程使用，从而将flag=1优化掉，或者将准备工作重排到flag=1之后，导致线程A看到不一致的状态。

3. Rust的内存模型与所有权机制

3.1 Rust为何不需要显式的READ_ONCE

Rust语言设计的一个核心理念就是通过所有权系统在编译期防止数据竞争。在Rust中，共享可变状态必须通过特定的同步原语（如Mutex、RwLock）或原子类型来访问。这些机制在语言层面就保证了内存访问的正确性。

Rust的原子类型（如AtomicBool、AtomicUsize）已经内置了类似READ_ONCE的语义。例如：

rust复制use std::sync::atomic::{AtomicBool, Ordering};

let flag = AtomicBool::new(false);

// 相当于READ_ONCE
let value = flag.load(Ordering::Relaxed);

Rust编译器知道原子操作的特殊性，不会对这些访问进行危险的优化。此外，Rust的所有权系统确保了对共享数据的访问总是通过正确的同步机制进行。

3.2 Ordering参数的作用

Rust原子操作中的Ordering参数（如Relaxed、Acquire、Release等）提供了比C语言更精细的内存顺序控制。这些ordering：

指定了原子操作之间的可见性保证
防止了编译器不期望的重排序
在不同架构上生成正确的内存屏障指令

例如，Acquire加载确保之后的操作不会被重排到加载之前，而Release存储确保之前的操作不会被重排到存储之后。这种明确的语义比C语言的volatile或READ_ONCE提供了更强的保证。

4. 实际场景对比分析

4.1 无锁链表的实现差异

在C语言中，实现无锁链表通常需要大量使用READ_ONCE和WRITE_ONCE来确保指针操作的原子性。例如：

c复制struct node {
    int value;
    struct node *next;
};

// 插入操作
void insert(struct node **head, struct node *new_node) {
    struct node *old_head;
    do {
        old_head = READ_ONCE(*head);
        new_node->next = old_head;
    } while (!try_cmpxchg(head, &old_head, new_node));
}

而在Rust中，相同的逻辑可以更安全地表达：

rust复制use std::sync::atomic::{AtomicPtr, Ordering};

struct Node {
    value: i32,
    next: AtomicPtr<Node>,
}

fn insert(head: &AtomicPtr<Node>, new_node: Box<Node>) {
    let mut old_head = head.load(Ordering::Relaxed);
    loop {
        new_node.next.store(old_head, Ordering::Relaxed);
        match head.compare_exchange_weak(
            old_head, 
            &*new_node as *const _ as *mut _,
            Ordering::Release,
            Ordering::Relaxed
        ) {
            Ok(_) => break,
            Err(x) => old_head = x,
        }
    }
}

Rust版本不仅更安全（避免了裸指针的误用），而且通过Ordering参数明确表达了内存顺序要求。

4.2 性能关键代码的优化

在极端性能敏感的场景下，C程序员可能会故意使用READ_ONCE配合宽松的内存顺序来获取最佳性能，但这需要开发者对内存模型有深刻理解。例如：

c复制// 低延迟交易系统中的标记位检查
while (READ_ONCE(market_data->ready_flag) == 0) {
    // 主动轮询，不引入内存屏障
    _mm_pause();
}

Rust中类似的代码需要使用特定的原子操作和ordering：

rust复制while market_data.ready_flag.load(Ordering::Relaxed) == 0 {
    std::hint::spin_loop();
}

虽然语义相似，但Rust版本通过类型系统和明确的ordering参数，大大降低了错误使用的可能性。

5. 为什么Rust不需要这些宏

5.1 语言设计哲学差异

C语言作为系统编程语言，给予开发者极大的自由和控制权，包括直接操作内存的能力。这种灵活性带来了性能优势，但也要求开发者自行处理并发安全问题。READ_ONCE和WRITE_ONCE就是在这种背景下出现的工具。

Rust则采用了不同的设计哲学：通过类型系统和所有权模型，在编译期就阻止了大多数并发错误。这种"编译时安全"的设计意味着：

共享可变状态必须显式声明（通过Mutex、RwLock等）
原子操作有明确的语义和顺序保证
数据竞争在编译期就被检测出来

5.2 编译器优化的不同处理

C/C++编译器会进行激进的优化，包括：

消除"冗余"的内存访问
重排没有明显依赖关系的操作
缓存变量值到寄存器

READ_ONCE和WRITE_ONCE实际上是告诉编译器："这个访问有特殊意义，不要优化它"。

Rust编译器对原子操作和同步原语有内置的理解，知道哪些优化是安全的。例如：

原子操作不会被消除
根据指定的Ordering保持正确的操作顺序
确保对共享内存的访问可见性

5.3 内存模型的内置支持

Rust的内存模型直接从C++20借鉴，比C语言有更正式和明确的定义。特别是：

所有原子操作都有明确的顺序语义
非原子访问的数据竞争是未定义行为（编译错误）
提供了从Relaxed到SeqCst的不同一致性保证

这使得Rust不需要像C那样依赖特殊宏来防止错误的优化，因为这些保证已经内置于语言中。

6. 从C迁移到Rust的注意事项

对于习惯C语言并发编程的开发者，转向Rust时需要注意：

不要尝试直接移植READ_ONCE/WRITE_ONCE：这些概念在Rust中有更安全的替代方案
理解Rust的所有权系统：共享可变状态需要同步原语或原子类型
掌握Ordering参数：不同的ordering对性能和正确性有重大影响
利用类型系统：让编译器帮你发现并发问题，而不是依赖运行时检查

例如，C中的双重检查锁定模式：

c复制struct object *get_shared_object(void) {
    struct object *tmp = READ_ONCE(shared_obj);
    if (!tmp) {
        lock();
        tmp = shared_obj;
        if (!tmp) {
            tmp = create_object();
            WRITE_ONCE(shared_obj, tmp);
        }
        unlock();
    }
    return tmp;
}

在Rust中应该这样实现：

rust复制fn get_shared_object() -> Arc<Data> {
    static SHARED: OnceLock<Arc<Data>> = OnceLock::new();
    SHARED.get_or_init(|| {
        Arc::new(create_data())
    }).clone()
}

Rust版本不仅更简洁，而且完全避免了常见的并发陷阱。

7. 性能对比与取舍

虽然Rust的安全特性带来了额外开销，但在实际应用中：

原子操作的性能与C相当，因为最终生成的机器码类似
在非性能关键路径上，使用Mutex等同步原语的可读性和安全性优势明显
Rust编译器能基于更丰富的语义信息进行优化

测量显示，在x86_64架构上，Rust的AtomicUsize::load(Relaxed)生成的汇编与C的READ_ONCE几乎相同：

asm复制; Rust版本
mov rax, [rdi]

; C版本
mov rax, [rdi]

但在弱一致性架构（如ARM）上，Rust编译器会根据指定的Ordering自动插入正确数量的内存屏障指令，而C版本可能需要手动添加屏障。

8. 最佳实践建议

根据实际项目经验，我总结了一些跨语言并发编程的建议：

在C/C++中：
- 对可能被并发访问的共享变量总是使用READ_ONCE/WRITE_ONCE
- 理解你使用的编译器和目标架构的内存模型
- 考虑使用更高级的同步原语（如RCU）而非自己实现
在Rust中：
- 优先使用标准库提供的同步原语（Mutex、RwLock等）
- 只有在极端性能敏感时使用原子操作，并谨慎选择Ordering
- 利用类型系统让非法状态不可表示
通用原则：
- 尽量减少共享可变状态
- 编写明确的并发文档
- 使用压力测试和静态分析工具验证并发正确性

例如，在实现跨线程计数器时：

rust复制// 好的实践：使用原子类型
use std::sync::atomic::{AtomicUsize, Ordering};

struct Counter {
    value: AtomicUsize,
}

impl Counter {
    fn increment(&self) {
        self.value.fetch_add(1, Ordering::Relaxed);
    }
}

// 不好的实践：使用不安全代码模拟C风格
struct UnsafeCounter {
    value: usize,
}

impl UnsafeCounter {
    unsafe fn increment(&mut self) {
        // 这可能在并发时导致数据竞争
        self.value += 1;
    }
}

Rust的类型系统会阻止第二个不安全实现的误用，而第一个版本既安全又高效。