Update sync2.md

避免理解的歧义
pull/911/head
tu6ge 2 years ago committed by GitHub
parent 1f29898152
commit 0355da2638
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -175,7 +175,7 @@ X = 2; }
- **Relaxed** 这是最宽松的规则,它对编译器和 CPU 不做任何限制,可以乱序 - **Relaxed** 这是最宽松的规则,它对编译器和 CPU 不做任何限制,可以乱序
- **Release 释放**,设定内存屏障(Memory barrier),保证它之前的操作永远在它之前,但是它后面的操作可能被重排到它前面 - **Release 释放**,设定内存屏障(Memory barrier),保证它之前的操作永远在它之前,但是它后面的操作可能被重排到它前面
- **Acquire 获取**, 设定内存屏障,保证在它之后的访问永远在它之后,但是它之前的操作却有可能被重排到它后面,往往和`Release`在不同线程中联合使用 - **Acquire 获取**, 设定内存屏障,保证在它之后的访问永远在它之后,但是它之前的操作却有可能被重排到它后面,往往和`Release`在不同线程中联合使用
- **AcqRel**, **Acquire**和**Release**的结合,同时拥有它们俩提供的保证。比如你要对一个 `atomic` 自增 1同时希望该操作之前和之后的读取或写入操作不会被重新排序 - **AcqRel**, *Acquire**Release* 的结合,同时拥有它们俩提供的保证。比如你要对一个 `atomic` 自增 1同时希望该操作之前和之后的读取或写入操作不会被重新排序
- **SeqCst 顺序一致性** `SeqCst`就像是`AcqRel`的加强版,它不管原子操作是属于读取还是写入的操作,只要某个线程有用到`SeqCst`的原子操作,线程中该`SeqCst`操作前的数据操作绝对不会被重新排在该`SeqCst`操作之后,且该`SeqCst`操作后的数据操作也绝对不会被重新排在`SeqCst`操作前。 - **SeqCst 顺序一致性** `SeqCst`就像是`AcqRel`的加强版,它不管原子操作是属于读取还是写入的操作,只要某个线程有用到`SeqCst`的原子操作,线程中该`SeqCst`操作前的数据操作绝对不会被重新排在该`SeqCst`操作之后,且该`SeqCst`操作后的数据操作也绝对不会被重新排在`SeqCst`操作前。
这些规则由于是系统提供的,因此其它语言提供的相应规则也大同小异,大家如果不明白可以看看其它语言的相关解释。 这些规则由于是系统提供的,因此其它语言提供的相应规则也大同小异,大家如果不明白可以看看其它语言的相关解释。

Loading…
Cancel
Save