阅读 84

理解 Java 内存模型的因果性约束

理解 Java 内存模型的因果性约束

欢迎讨论

欢迎加入技术交流群186233599讨论交流,也欢迎关注笔者公众号:风火说。

规范理解

这部分的内容比较抽象,首先是一开始的定义,如下

image-20200229131229165

红色下划线的内容应该是理解的关键。首先,E 是一个特定的执行序列,其由指令集合 A 以及用于对集合 A 内部存在的 PO,SO,SW,HB 排序构成。Ci 是被 E 包含的一个子集,也就是说 Ci 中的指令全部都在执行 E 的指令集合 A 中存在。

来看第二,第三和第四个红线(忽略A是无限集合的情况,无限集合意味着线程出现了死循环,永不终止,这并不是一个合理的程序),这三者合在一起理解,可以认为是 Ci 增加一个指令,就构成了 Ci+1,也就形成了新的 Ai+1 。而新的 Ai+1 结合 PO,SO,SW,HB 关系就成为了新的 Ei+1

接着来看后续的定义

这 5 个约束合在一起实际上是说明如何构成一个 C 集合。简单而言,Ci 是 Ai的一个子集,并且这个子集和执行轨迹Ei 拥有相同的 HB,SO 关系,且 Ci 中写入操作的写入值和 Ei 中相同,Ci 中对写入值的观察结果和 Ei 中相同。而 Ei 是逐步构成 E 的第 i 步骤,最终 E~n~ 等同于 E 。这实际上约束了 C 是如何构成的,它并不是凭空而来,而是不断的将 E 中的指令添加到 C 之中,并且这些添加的指令都和 E 拥有相关的观察效果,写入值,以及偏序关系。通过确保一系列的 Ei 都是合法的,最终确定 E 是合法的。

再来剩下的两条规则

image-20200229140913252

第 6 条规则定义了要往集合 C 中添加读取指令时,该指令的观察结果。换句话说集合 C~i-1~ 中的写入操作产生的效果,能被任意未添加到该集合中的写入操作观察到。

第 7 条规则和上面的 5 条规则相同,也是在明确在集合 C 中产生的观察效果在执行轨迹 E 中也是存在的。

7个规则都在描述在集合 C 中的写入值,读取结果,指令排列顺序都是和 E 等同,因此通过不断的构建 Ci ,最终 C~n~ 等同于 A~n~ ,再加上在 C~n~ 中的写入值,读取结果,指令排列顺序,就构成了最终的 E 。而如果这一系列的 Ci 都是“合法”的话,则最终的执行轨迹 E 也是合法的。

当我们需要向集合新增一个读取指令时,其读取到的值只能在该集合中的写入值。提交指令到集合中时,如果存在HB 关系 或依赖关系的语句阻止其提交,则提交不能成功。

例子练习

例子1

首先来看一段代码,如下

nonvolatile global int a = 0, b = 0;
ThreadA()
{
    int aL = a;
    if(aL == 1) b = 1;
}
ThreadB()
{
    int bL = b;
    if(bL == 1) a = 1;
}
复制代码

对于内存模型而言,其只关注操作内存的指令,在执行轨迹 E 的 A 集合的内容是

int aL = a;
b = 1;
bL = b;
a = 1;
复制代码

由于int aL = a;a = 1;不存在 HB 关系,因此可以通过数据竞争的方式读取到该写入值,也就是aL的值是 1 。bL = b;b = 1;不存在 HB 关系,因此可以通过数据竞争的方式读取到该写入值,也就是bL的值是 1 。

一个读取操作可以读取的到值或者是通过 HB 关系得到,或者是通过数据竞争得到。也就是说,在没有 HB 关系阻止该读取结果时,该读取结果是允许的,这被称之为 HB 一致性。显然,上面的输出结果aL==bL==1是符合 HB 一致性的。

然而从顺序一致性执行的角度而言,这种输出结果就好像是因为aL读取到线程 B 写入的值,产生了b=1的结果,而这个结果导致了bL==1的结果,而这个结果导致了a=1的结果,而a==1导致了aL=1。形成了一个循环,显然这是违背直觉的。而 JMM 中因果性的要求就是用来判定这种执行轨迹是否合法的依据。

再用因果性分析这个执行之前,我们先看另外一个更简单一些的例子,代码如下

0: x == y == 0
 
Thread 1:
1: r1 = x;
2: y = 1;
 
Thread 2:
3: r2 = y;
4: x = r2;
复制代码

这个例子反复出现,显然我们知道r1==r2==1是一个合法的输出结果。因为重排序的原因,y=1被执行,而后r2=y观察到这个写入,x=r2同样得到值 1,r1=x观察到这个写入。下面我们使用因果性来分析这个执行轨迹。

首先我们将集合 C 中添加指令 2 。与指令 2 存在 HB 关系的是指令 0 和 1 。他们都不会阻止指令 2 的发生,因此指令 2 被允许添加到集合 C 中,此时有 C1

我们用 W(variable,value) 来表达对一个变量 variable 写入 value 的值,用 R(variable,value) 表达从变量 variable 中读取到 value 的值。

因此目前我们有 C0= {W(x,0),W(y,0)} 的初始状态。而 C1=C0 U {W(y,1)} 。然后我们添加指令 3 到 C1 中,按照 HB 关系,指令观察到的值应该是指令 0 写入的。但是同时,它也允许观察到提交集合中已经写入的值,也就是存在于提交集合中指令 2 的写入值。因此我们有 C2=C1 U {R(y,1)} 。

接着我们提交指令 4 ,显然此时有 C3=C2 U {W(x,1)} 。

最后我们提交指令 1,按照 HB 关系,此时允许的观察值由指令 0 写入,也就是 0 。与上述相同,允许其观察到在提交集合中的写入值,因此 C4=C3 U {R(x,1)} 。

C4=A4,C4 中的写入值,读取值,排列顺序都与 E4 相同,也与 E 相同。因此判定该执行轨迹是合法的,其表现是符合 JMM 要求的。

接下来我们回到最开始的例子,如果我们要得到bL==1的结果,意味着我们需要执行b=1这个指令。而要执行该指令,我们需要执行int aL = a;指令并且读取到值 1 。注意,因果性的判断是需要考虑条件判断因素的,而 HB 一致性则不考虑,它仅仅是提取所有的可能执行指令并且假定其执行。

从提交集合的角度出发,我们需要提交int aL = a;实际上是想提交 R(a,1) 。但是 C0={W(x,0),W(y,0)} ,C1 中的读取操作的读取值只能由 C0 中的写入造成,因此 R(a,1) 无法被提交到 C1 中。这就意味着达成a==b==1的提交集合不合法,因此对应的执行轨迹也是非法的。所以这种结果不被 JMM 允许。

例子2

int /* non-volatile */ a;
int /* non-volatile */ b;
ThreadA()
{
    int tmp = a;
    b = tmp;
}
ThreadB()
{
    int tmp = b;
    a = tmp;
}
复制代码

对于上面的代码,a==b==1的结果是符合 HB 一致性的。看起来这个比例子 1 中出现的情况更费解一些,因为 1 这个值似乎是无中生有的。但是我们首先假设int tmp = a;读取到了 1 ,此时b = tmp;将会写入 1 。而int tmp = b;又读取到了该值,这会导致a = tmp;写入值 1 ,恰恰满足了int tmp = a;读取到 1 的需要。HB 一致性中,如果没有 HB 关系阻止一个值被读取,则该读取都是被允许的,也就是可以认为int tmp = a;通过数据竞争的方式读取到了未来的写入值。按照这种方式考虑,这个例子实际上类似于例子1中的第二个示例。

但是显然,这个结果是违反直觉的,其结果也被 JMM 禁止。我们使用因果性的方式进行分析。

首先,显然我们有 C0={W(a,0),W(b,0)} 。接着我们提交int tmp = a;(不能先提交b = tmp;是因为int tmp = a;与其存在依赖关系,且有 HB 关系)。根据 C0 的内容,显然此时只允许提交 R(a,0) 或 R(b,0) 。通过因果性分析,我们得到这个例子的合法输出只能是a==b==0

总结

非正式的说,可以认为通过结合 HB 一致性和因果性要求得到 JMM 。这两个约束结合在一起,才有了 JMM 对程序员的保证:如果一个程序是正确同步的,其程序表现为顺序一致性。

关注下面的标签,发现更多相似文章
评论