原子变量和内存顺序

翻译来源

https://vorner.github.io/2018/03/25/Atomics.html

内容

使用多线程很困难,不仅是因为很多事情同时发生,还因为你代码中所写的并不一定是CPU中所发生的。为了获得更好的性能表现,编译器在认为没有监视限制的情况下就会cheat(优化代码),他会对指令重新排序,或者忽略一些它认为无用的指令。硬件方面同样会这样做,同一时刻同一内存地址能够存在于不同的缓存中,但某一缓存的修改并不会被立刻更新到其他缓存中。如果不小心处理,会导致未定义行为。除了传统的同步原语(mutexes, barriers, …),一些语言提供了原子类型(C++Rust),这很酷,它允许实现传统的原语和一些快速的多线程数据结构(例如crossbeam)。不幸的是,他们比起在mutex后面放一些代码要难用,部分是因为他们神奇的内存ordering parameter,直接影响了他们的内存同步。

大多数的文档从保证性、因果性和预见性进行说明,它们擅长形式说明,但使用中项像教一个会计学集合论,并不实用。我能找到的最接近实用的文档是在nomicon,但是我决定自己重新陈述一下,希望没有错误。

原子变量究竟是什么?

正如其他类型一样,原子类型一样它存在普通RAM中,它并不比其他非原子变量多使用内存,他们在二进制形式上是相同的,只是编译器生成不同的指令来处理它(避免优化)。理论上一个变量有时可以当作是原子变量使用,有时可以不当作原子变量,但实际中意义不大。
然而,编译器和处理器都希望cheat(你也希望他们cheat,加速执行速度)。 ordering parameter则是说明了什么样的cheat是被允许的。这也是原子变量比mutex要快的原因–它从更细的层面上控制了cheat(另一个原因是mutex 进入了内核态挂起其他线程,直到解锁,这很耗时)。

一些手册推荐当你不确定时,使用顺序一致(Sequentially Consistent)的顺序,但我人我这不是好建议——并不仅仅是从性能方面。如果你不知道你需要的内存顺序,你就无法确定该使用原子变量还是mutex ,还是其他的更耗时的东西。原子变量学习的重点并不是原子变量的工作原理,而是在于他的平行研究,他会影响其他内存位置的同步,其次才是速度。

Relaxed order ‒ sanity just for me

只有当从不同线程中同时访问变量而不引起未定义操作,此时原子变量才称得上稳健如果你从0开始,每次增1,执行10次,你会获得从0到10 的数字,最终也会得到10.线程会将对于一个原子变量的操作看成是顺序操作(原子变量达到10 ,我的线程会看见它,除非有减操作否则不会回到5)。

let mut threads = Vec::new();
for _ in 0..5 {
    threads.push(thread::spawn(|| {
        let first = a.fetch_add(1, Ordering::Relaxed);
        let second = a.fetch_add(1, Ordering::Relaxed);
        assert!(first < second);
    }));
}
for t in threads {
    t.join().unwrap();
}
assert_eq!(10, a.load(Ordering::Relaxed));

除此之外, relaxed order 不保证其他任何东西。无法保证原子变量之间的顺序(当递增原子变量A和B,某一个线程看到的是先递增A后递增B,另一个线程可能看到的是相反的顺序),是的不同的线程看到的是不同的顺序(不要过分在意,感觉有点精神分裂)。如果有多个变量会产生相当怪异的结果。
适用情况:

  • 生成唯一ID
  • 控制其他线程(停止其他线程)
  • 统计或在程序末尾获得某个数
  • 出于性能考虑,

并不是所有的架构都有这个顺序,没有的话就会采用限制更强的东西。

Release & Acquire ‒ sending data from one thread to another

除了relaxed order 所提供的,它提供了两个线程间的契约,若一个线程release 某个原子变量,另一个线程同时acquire原子变量。前一个线程在release 之前对原子变量的写都会被另一个线程所acquire。这对操作是移交内存的交会点。
适用情况:
- 写互斥量,自旋锁,管道,或其他有趣的数据结构。这种成对的操作保证了原始线能程更新RAM和其他线程获取所有相关内存,(这是这是对实际发生的事情的一种简化,存在cache coherence,不必将数据送入RAM)
- 创建双向同步(mutex 以原子变量的形式获得锁,获得当前的内存,修改后释放它)。创建单向同步(写者通过释放操作立刻放弃管道,读者获得写者的内容,从而节约带宽)。

let spinlock = AtomicBool::new(false); // not locked
...
while spinlock.compare_and_swap(false, true, Ordering::Acquire) {}
// It's locked here
spinlock.store(false, Ordering::Release); 

注意:

  • 并不保证与其他线程的同步
  • 并不保证在发布操作之后,第一个线程不会改变内存。
  • 不同原子变量的操作没有联系
  • 正确的同步方式是:在release之后第一个线程停止写。
  • 只有当 release 操作出现在写(store)中,acquire 操作出现在读中才(load)才起作用。相反则无效。

同样存在AcqRel顺序,它同时可以acquire and release,load-store,(像fetch_add操作)。

Sequentially consistent

它与AcqRel类似(load 时Acquire,store时Release ),但是它同步了其它原子变量,准确来说是SeqCst 操作贯穿整个程序,每个线程都有一个单一的操作时间线。较弱的操作仍有可能得到希望的结果。

Other synchronization points

正如AcqRel操作不同线程中同一原子变量的更新,也存在其他情况,可能隐藏着一些原子操作。

  • thread/memory模型中需要强制传播更新: Locking/unlocking 一个mutex,产生临界区。
  • 用管道发送数据。
  • Spawning 或 joining 其他的线程

总结

Relaxed:放轻松,不要担诸如事物的顺序或其他的内存等细节。
Release:告知你在内存中改变了什么。
Acquire:获得所有更新。
SeqCst:确保所有事物的一致性。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值