Rust 并发编程 - Memory Ordering

在并发编程领域,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 就成。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 148,637评论 1 318
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 63,443评论 1 266
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 99,164评论 0 218
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,075评论 0 188
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,080评论 1 266
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,365评论 1 184
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 30,901评论 2 283
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,649评论 0 176
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,122评论 0 223
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,734评论 2 225
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,093评论 1 236
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,548评论 2 222
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,028评论 3 216
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,765评论 0 9
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,291评论 0 178
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,162评论 2 239
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,293评论 2 242

推荐阅读更多精彩内容

  • 目录:1.数据依赖性2.程序顺序规则3.重排序对多线程的影响4.编译器重排序5.指令集并行的重排序6.内存系统的重...
    西部小笼包阅读 16,106评论 9 25
  • C++ 11 atomic 简介 Atomic类型是c++11里面引入的一种类型,它规定了当程序的多个线程同时访问...
    EFlql阅读 7,613评论 1 0
  • 参考cppreference参考The C++ Memory Model and Modern Hardware ...
    王侦阅读 3,037评论 0 3
  • 我们在前面讲atomic时,每一个原子操作都有一个std::memory_order参数。这个参数就是C++11的...
    许了阅读 9,024评论 1 12
  • 1.Java内存模型的基础 ①并发编程模型的两个关键问题 线程之间如何通信、线程之间如何同步 通信是指线程之间以何...
    加夕阅读 673评论 0 1