Memory Consistency (下)

Memory Consistency

---

三、 弱序 Memory Model

3.1 Weak Memory Model

在实际的编程过程中，我们发现不相关的memory的访问的order，我们并不在意。真正在意的是，存在对内存读写访问冲突的情况。所以在weak memory model中，我们可以放松对consistency order的要求，而对访问冲突的情况进行严格限制。

如下是，比如常见的存在内存冲突的使用发布-等待同步的程序。

P0：					P1：
S1: datum = 5;			S3: while(!datumIsReady) {};
S2: dataumIsReady = 1;	S4: ... = datum;

在上一篇文章所讲的strong memory model和 sc memory model中，在S4执行时，一定是datumIsReady 已经为1，那么datum此时必然为最新值5。

然而在weak memory model中，是允许出现 S4→S1→S2→S3的次序的，所以这就会导致我们程序没有达到预期的发布-等待同步的效果。

此时如果使用的是X86架构，采用Strong Order Memory Order的处理器，是不需要显式的编写同步的程序。如果是我们使用的平台是weak memory model的arm，power pc等，就需要软件程序员显示的编写同步代码，来通知处理器同步的时刻。

P0：							P1：
S1:st &datum, #5				S3: L:	ld.SYNC R1, &datumIsReady
										sub R1,R1,#1
								    	bnz R1, L
S2:st.SYNC &datumIsReady, #1	S4: ld R2, &datum

注意到，这里显式的增加了SYNC这个同步点。 那么弱序的处理器如何支持这个功能呢？

• 所有在同步访问点之后存储器访问指令从流水线中清空或者不取进流水线
• 在同步点之前的所有load指令拿到了值，所有store指令发出了无效化副本请求后，同步点指令才能执行

这样我们就能保证不会出现 S4→S1→S2→S3的次序而拿到了错误的值。

3.2 Release Consistency Model

Release Consistency Model(释放一致性)相对于weak memory model，则弱的更加激进。

结合下图所示，在释放一致性memory model中，对顺序进行一下要求：

• 释放锁→获得锁 的顺序
• 释放锁之前的程序需要在释放锁之前完成
• 获得锁之后的程序需要在获得锁之后执行

然而，释放锁之后的程序是可以在释放锁之前执行的。获得锁之前的程序也可以在获得锁之后完成。

相对与weak memory model，释放一致性的平台对程序员要求的更高，在编程时需要显式的加入，在S3时的释放标志和S6时的获得标志，以通知处理器维护order。

此外，如果代码中，加入了多个锁，weak memory model 和 release memory model的表现也是不同的。

如下图所示，因为unlock之后的对存储器的访问可以提前执行，所以指令块2是可以提前到unlock(A)之前执行的，这样就可能造成了在外面看来lock(A)→lock(B)→unlock(A)→unlock(B)。

如果是weakly memory model，在同步点前后的指令都不能跨越同步点一步，因此指令流只能如下：

附图：常见处理器对Memory Order的支持

欢迎关注我的公众号《处理器与AI芯片》