Rust 并发编程 - Memory Ordering

96
siddontang 595a1b60 08f6 4beb 998f 2bf55e230555
5.4 2019.02.04 13:54 字数 1586

在并发编程领域,Rust 提供了完善的机制来保证并发编程的安全,我们可以非常方便的使用 Mutex,Arc,Channel 等库来处理我们的并发逻辑。 但在有些时候,为了更高效的性能,我们可能会去写一些 lock-free 的数据结构,而 Rust 自身也提供了 atomic 的支持。

对于每个 atomic 操作,都需要显示的指定 Ordering,Rust 提供了 Relaxed,Release,Acquire,AcqRel,以及 SeqCst 这些 Ordering 的支持,使用不同的 Ordering 会让编译器或者 CPU 对某些指令进行重新排序执行,所以为了更正确的写出 lock-free 的代码,了解这些 Ordering 是如何工作的,就显得非常重要了。

Keywords

在开始介绍 Rust 的 memory ordering 之前,我们需要知道两个常用的用来描述atomic 操作之间关系的概念,synchronizes-with 和 happens-before:

Synchronizes-with - 简单来说,两个线程 A 和 B,以及一个支持原子操作的变量 x,如果 A 线程对 x 写入了一个新的值(store),而 B 线程在 x 上面读取到了这个新的值(load),我们就可以认为,A 的 store 就是 synchronizes-with B 的 load 的。

Happens-before - 这应该算是一个更基础的概念。如果一个操作 B 能看到之前操作 A 产生的结果,那么 A 就是 happens-before B 的。譬如在单线程里面,如果一个操作 A 的语句在操作 B 的前面执行,通常叫做 sequenced-before,那么 A 就是 happens-before B 的,譬如这样:

vec.push(1);  // A
ready = true; // B

而对于跨线程(inter-thread) 的情况,要判断 happens-before,就需要借助于前面提到的 synchronizes-with 了。如果操作 A 是 synchronizes-with 另一个线程的操作 B 的,那么 A 就是 happens-before B 的。Happens-before 也具有传递性,如果 B 是 happens-before C 的,那么 A 也是 happens-before C。

如果 A 是 sequenced-before B,而 B 是 inter-thread happens-before C 的,那么 A 也是 inter-thread happens-before C。同理,如果 A inter-thread happens-before B,而 B sequenced-before C,那么 A 也是 inter-thread happens-before C。

可以看到,要写出正确的 atomic 代码,尤其是在多线程环境下面,关键就是要弄清楚两个 atomic 操作的 syncrhonizes-with 关系。而这个不同的 Ordering 是不一样的。

Relaxed ordering

Relaxed ordering 只能保证原子操作,在同一个线程里面,对同一个变量的操作会满足 happens-before 关系,但对于 inter-thread 来说,它不能提供 synchronizes-with 支持,并不保证任何顺序。

下面是一个简单的例子:

fn write_x_then_y() {
    X.store(true, Ordering::Relaxed);
    Y.store(true, Ordering::Relaxed);
}

fn read_y_then_x() {
    while !Y.load(Ordering::Relaxed) {}
    if X.load(Ordering::Relaxed) {
        Z.fetch_add(1, Ordering::SeqCst);
    }
}

fn main() {
    let t1 = thread::spawn(move || {
        write_x_then_y();
    });

    let t2 = thread::spawn(move || {
        read_y_then_x();
    });

    t1.join().unwrap();
    t2.join().unwrap();

    assert_ne!(Z.load(Ordering::SeqCst), 0);
}

上面 assert 可能会失败,也就是 Z 的值在最后可能为 1。在函数 write_x_then_y 里面即使 store X happens-before store Y,即使在 read_y_then_x 里面 load Y 返回了 true,X 的值仍然可能是 false。因为对 X 和 Y 的两个操作都是 relaxed 的,虽然对于不同的线程,两个 load 或者两个 store 都可能满足 happens-before,但在 store 和 load 之间,并没有相关的约束,也就是意味着 load 可能看到乱序的 store。

通常来说,relaxed 适用的场景就是需要对某个变量进行原子操作,而且不需要考虑多个线程同步的情况,譬如 reference counter,其它时候需要考虑有更强约束的其他 ordering。

Acquire-Release ordering

Acquire 和 Release 通常都是需要成对使用的,当对 store 使用 Release ordering 之后,后续任何的 Acquire ordering 的 load 操作,都会看到之前 store 的值。也就是说,通过 Acquire-Release,我们能支持 synchronizes-with。

fn write_x_then_y() {
    X.store(true, Ordering::Relaxed);
    Y.store(true, Ordering::Release);
}

fn read_y_then_x() {
    while !Y.load(Ordering::Acquire) {}
    if X.load(Ordering::Relaxed) {
        Z.fetch_add(1, Ordering::SeqCst);
    }
}

fn main() {
    let t1 = thread::spawn(move || {
        write_x_then_y();
    });

    let t2 = thread::spawn(move || {
        read_y_then_x();
    });

    t1.join().unwrap();
    t2.join().unwrap();

    assert_ne!(Z.load(Ordering::SeqCst), 0);
}

不同于之前的 relaxed,这里我们对 Y 使用了 Acquire 和 Release,那么最后 Z 就一定不可能为 0 了。主要是因为 store Y 是 synchronizes-with load Y 的,也就是 store Y happens before load Y,因为 store X 是 sequenced-before store Y,那么 store X 就是 happens-before load X 的。

通常,我们还可以使用 AcqRel ordering,它其实就是组合了 Acquire 和 Release,对于 load 使用 Acquire,而对于 store 则是使用 Release。

Sequence ordering

Sequence ordering 不光提供了 Acquire,Release 的 ordering 支持,同时也确保所有线程会看到完全一致的原子操作顺序。

fn write_x() {
    X.store(true, Ordering::SeqCst);    // 1
}

fn write_y() {
    Y.store(true, Ordering::SeqCst);    // 2
}

fn read_x_then_y() {
    while !X.load(Ordering::SeqCst) {}
    if Y.load(Ordering::SeqCst) {       // 3
        Z.fetch_add(1, Ordering::SeqCst);  
    }
}

fn read_y_then_x() {
    while !Y.load(Ordering::SeqCst) {}
    if X.load(Ordering::SeqCst) {       // 4
        Z.fetch_add(1, Ordering::SeqCst); 
    }
}

fn main() {
        let t1 = thread::spawn(move || {
        write_x();
    });

    let t2 = thread::spawn(move || {
        write_y();
    });

    let t3 = thread::spawn(move || {
        read_x_then_y();
    });

    let t4 = thread::spawn(move || {
        read_y_then_x();
    });

    t1.join().unwrap();
    t2.join().unwrap();
    t3.join().unwrap();
    t4.join().unwrap();

    assert_ne!(Z.load(Ordering::SeqCst), 0);
}

上面的例子,只有使用 SeqCst ordering,才能保证 Z 最后的值不为 0,任何其他的 ordering,都不能保证,我们来具体分析一下。因为两个 read 函数都是有 while 循环,退出之前一定能确保 write 函数被调用了。因为使用 SeqCst 能保证所有线程看到一致的操作顺序,假设 3 返回了 false,表明 X 为 true,而 Y 为 false,这时候一定能保证 store Y 还没调用,一定能保证 store X 在 store Y 之前发生,4 就一定会返回 true。

如果这里我们对 load 使用 Acquire,而对 store 使用 Release,read_x_then_yread_y_then_x 可能看到完全相反的对 X 和 Y 的操作顺序。

SeqCst 在有些时候,可能会有性能瓶颈,因为它需要确保操作在所有线程之前全局同步,但是它其实又是最直观的一种使用方式, 所以通常,当我们不知道用什么 ordering 的时候,用 SeqCst 就对了。

Memory fence

出了使用不同的 ordering,我们还可以使用 memory fence 来支持 synchronizes-with,如下:

fn write_x_then_y() {
    X.store(true, Ordering::Relaxed); // 1
    fence(Ordering::Release);         // 2
    Y.store(true, Ordering::Relaxed); // 3   
}

fn read_y_then_x() {
    while !Y.load(Ordering::Relaxed) {}  // 4
    fence(Ordering::Acquire);            // 5
    if X.load(Ordering::Relaxed) {       // 6
        Z.fetch_add(1, Ordering::SeqCst);
    }
}

fn main() {
    let t1 = thread::spawn(move || {
        write_x_then_y();
    });

    let t2 = thread::spawn(move || {
        read_y_then_x();
    });

    t1.join().unwrap();
    t2.join().unwrap();

    assert_ne!(Z.load(Ordering::SeqCst), 0);
}

在上面的例子中,2 Release fence 是 synchronizes-with 5 Acquire fence 的,而4 load Y 的时候一定会读取到 3 store Y 的值,加上 1 store X 是 sequenced-before 3 的,那么自然能确定 1 是 happens-before 6 的。也就是 Z 一定不会等于 0。

Epilogue

可以看到,要弄清楚 memory ordering,其实并不是一件容易的事情,不过多数时候,为了不出错,使用 SeqCst 就成。

编程之路
编程之路
22.0万字 · 49.2万阅读 · 316人关注
Gupao