Rust内存模型中的地址重用与happens-before关系

在Rust标准库的ReentrantLock实现中，我们发现了一个关于内存地址重用与并发同步的有趣问题。这个问题揭示了Rust内存模型中一个重要的语义细节：当内存地址被重用时，必须建立适当的内存顺序关系。

问题背景

ReentrantLock是一种可重入锁，它允许同一个线程多次获取锁而不会造成死锁。在实现中，它使用了一个巧妙的方法来检测当前线程是否已经持有锁：通过比较线程本地存储(TLS)变量的地址与锁中记录的地址。

具体来说，当一个线程首次获取锁时，它会将自己的TLS变量地址存储在锁中。当这个线程再次尝试获取锁时，它会检查当前TLS变量的地址是否与锁中记录的地址匹配。如果匹配，说明是同一个线程在尝试获取锁，此时只需增加锁计数即可。

问题重现

在多线程环境下，如果两个不同的线程恰好使用了相同的地址来存储它们的TLS变量，就可能出现并发问题。考虑以下场景：

1. 线程A获取锁，将自己的TLS地址存储在锁中
2. 线程A释放锁，TLS变量被销毁
3. 线程B创建TLS变量，恰好使用了与线程A相同的地址
4. 线程B尝试获取锁，发现地址匹配，认为自己已经持有锁
5. 线程B直接增加锁计数，但实际上它并没有真正持有锁

在Miri( Rust的内存检查工具)下运行这样的代码会触发未定义行为(UB)警告，因为它检测到了数据竞争。

内存模型分析

这个问题的核心在于内存地址重用时的同步语义。根据C11内存模型的规定，当内存被释放后又被重新分配时，必须满足以下条件：

1. 释放操作(free)必须使用Release顺序语义，确保释放前的所有写操作对其他线程可见
2. 分配操作(malloc)必须使用Acquire顺序语义，确保分配后的所有读操作能看到之前释放操作的结果

这种同步关系确保了地址重用不会导致数据竞争。具体来说，释放操作与后续的分配操作之间建立了happens-before关系，防止了内存访问的乱序。

Rust中的解决方案

在Rust中，我们需要确保：

1. 标准库的分配器实现必须遵守上述同步规则
2. 使用地址比较进行同步的代码(如ReentrantLock)必须正确处理地址重用的情况

对于ReentrantLock的具体实现，虽然它依赖地址比较，但由于线程本地存储的特性，这种使用是安全的：

• 当TLS变量地址被重用时，原线程必然已经终止
• 因此不会有两个线程同时持有相同的地址
• Sync不变式仍然保持，因为没有真正的并发共享访问

更一般的测试案例

为了更清楚地展示这个问题，我们可以构造一个不依赖ReentrantLock的测试案例：

static ADDR: AtomicUsize = AtomicUsize::new(0);
static VAL: SyncUnsafeCell<i32> = SyncUnsafeCell::new(0);

fn thread1() {
    unsafe { VAL.get().write(42); }
    let alloc = Box::new(42);
    ADDR.store(alloc.addr(), Relaxed);
}

fn thread2() -> bool {
    let alloc = Box::new(42);
    if alloc.addr() == ADDR.load(Relaxed) {
        // 如果地址相同，必须能看到之前的写入
        assert_eq!(unsafe { VAL.get().read() }, 42);
        true
    } else {
        false
    }
}

这个测试明确展示了地址重用时的同步要求：如果两个分配返回相同的地址，那么第二个分配必须能看到第一个分配线程的所有写入。

结论

内存地址重用是并发编程中一个微妙但重要的问题。Rust的内存模型需要明确规定地址重用时的同步语义，以确保程序的安全性和正确性。对于标准库和分配器实现者来说，必须确保：

1. 释放操作使用Release顺序
2. 分配操作使用Acquire顺序
3. 地址重用建立了适当的happens-before关系

这种保证不仅对ReentrantLock这样的特殊用例很重要，也是构建正确并发程序的基础。理解这些底层细节有助于我们编写更安全、更可靠的Rust代码。