- 论坛徽章:
- 4
|
我很是怀疑学这些东西有没有用,好久不看这些了,不过既然说起这些,就勉为作答:
“在 CPU 0 上, wmb 保证 b = 2 定然在 p = &b 之前完成, 我对完成的理解是相应的值更新到 CPU 0 本地缓存”
问题就在上边这句话里。
这个wmb的含义是:CPU1~N都是先收到invalidate b的请求,再收到invalidate p的请求,创造了若能感知到p,则必能感知到b的先决条件。
CPU收到invalidate的请求后,并不是马上作废相应的cache line,而是将这个invalidate请求挂入一个queue,然后就回应invalidate的应答。
故在CPU1~N的queue中,都是先挂入invalidate b的request,再挂入invalidate p的request。
1)若这个queue中的各个请求永不重排序,则CPU1~N若真正执行了invalidate p的request,则必已真正执行了invalidate b的request. 这时CPU1~N不需要rmb。这个是最简单的模型,仅仅是一些文档上的模型。
2)若这个queue中的各个请求可以一定程度重排序,这个一定程度指的是invalidate request和read reply都挂在一个queue中,可以重排序各invalidate request,但应将read reply视做边界。即:
reply1,invalidate1,invalidate2,reply2可以重拍序为
reply1,invalidate2,invalidate1,reply2,但绝不能重排序为
invalidate1,reply1,invalidate2,reply2。
这样的话,CPU1~N即使将invalidate p的request重排序在了invalidate b的request前边,但read p的reply也在invalidate b的request后边, 必然是先真正执行了invalidate b的request,然后才能读到p。这时CPU1~N不需要rmb,这个不仅仅是模型,而是很多实际情况如此。
3)若不止一个queue,而是alpha那种多个queue的,则根本没办法做到一定程度的重排序。多个queue之间各个请求和replay的先后,完全没法判断。这时只能:
CPU0创造先决条件,通过wmb,先发完invalidate b的request,再发出去invalidate p的request.
CPU1相应的,收到read p的reply后,通过rmb,强制的真正执行queue中所有invalidate request。 |
评分
-
查看全部评分
|