Java多线程--缓存一致性问题和缓存一致性协议MESI(二)

写缓冲器与无效化

背景:

MESI 协议解决了缓存一致性问题, 但是其自身也存在一个性能弱点——处理器执行写内存操作时,必须等待其他所有处理器将其高速缓存中的相应副本数据删除并接收到这些处理器所回复的 Invalidate Acknowledge/Read Response消息之后才能将数据写入高速缓 存。为了规避和减少这种等待造成的写操作的延迟 (Latency), 硬件设计者引入了写缓冲器和无效化队列,

写缓存器

写缓冲器 (Store Buffer, 也被称为 Write Buffer) 是处理器内部的一个容扯比高速缓 存还小的私有高速存储部件6. 每个处理器都有其写缓冲器, 写缓冲器内部可包含若干条 目 (Entry)。 一个处理器无法读取另外一个处理器上的写缓冲器中的内容。
在这里插入图片描述
引入写缓冲器之后,处理器在执行写操作时会做这样的处理:

如果相应的缓存条目状态为E或者M. 那么处理器可能会直接将数据写入相应的缓存行而无须发送任何消息飞 如果相应的缓存条目状态为 s. 那么处理器会先将写操作的相关数据(包括数据和待操作 的内存地址)存人写缓冲器的条目之中,并发送Invalidate消息;如果相应的缓存条目状态为I, 我们就称相应的写操作遇到了写未命中(WriteMiss), 那么此时处理韶会先将写 操作相关数据存人写缓冲器的条目之中,并发送ReadInvalidate消息。

由此可见, 写缓冲器的引入使得处理器在执行写操作的时候可以不等待 Invalidate Acknowledge消息, 从而减少了写操作的延时. 这使得写操作的执行处理器在其他处理器回复Invalidate Acknowledge/Read Response消息这段时间内能够执行其他指令,从而提高了处理器的指令执行效率。

引入无效化队列(Invalidate Queue) 之后, 处理器在接收到Invalidate消息之后并不删除消息中指定地址对应的副本数据, 而是将消息存入无效化队列之后就回复Invalidate Acknowledge消息,从而减少了写操作执行处理器所需的等待时间。有些处理器(比如x86)可能没有使用无效化队列。

写缓冲器和无效化队列的引入又会带来一些新的问题——内存重排序和可见性问题。

存储转发

这种处理器直接从写缓冲器中读取数据来实现内存读操作的技术被称为存储转发(Store Forwarding)。 存储转发使得写操作的执行处理器能够在不影响该处理器执行读操作的情 况下将 写操作的结果存入写缓冲器。

再探内存重排序

​ 写缓冲器和无效化队列都可能导致内存重排序。

-硬件层的内存屏障分为两种:Load Barrier 和 Store Barrier即读屏障和写屏障。
-处理器在一些特定条件下(比如写缓冲器满、I/0指令被执行)会将写缓冲器排空(Drain)或者冲刷(Flush), 即将写缓冲器中的内容写入高速缓存,但是从程序对一个或者一组变扯更新的角度来看,处理器本身并无法保证这种冲刷对程序来说是及时的。

为了保证一个处理器对共享变措所做的更新可以被其他处理器同步,编译器等底层系统需要借助一类被称为内存屏障的特殊指令。内存屏障中的存储屏障(Store
Barrier)可以使执行该指令的处理器冲刷其写缓冲器。

​ 然而,冲刷写缓冲器只是解决了可见性问题的一半。因为可见性问题的另一半是无效化队列导致的。无效化队列的引入本身也会导致新的问题一处理器在执行内存读取操作前如果没有根据无效化队列中的内容将该处理器上的高速缓存中的相关副本数据删除,那么就可能导致该处理器读到的数据是过时的旧数据,从而使得其他处理器所做的更新丢失。

​ 为了使一个处理器上运行的线程能够读取到另外一个处理器上运行的线程对共享变量所做的更新, 该处理器必须先根据无效化队列中存储的Invalidate消息删除其高速缓存中的相应副本数据,从而使其他处理器上运行的线程对共享变拯所做的更新在缓存一 致性协议的作用下能够被同步到该处理器的高速缓存之中。

​ 内存屏障中的加载屏障(Load Barrier)正是用来解决这个问题的。加载屏障会根据无效化队列内容所指定的内存地址, 将相应处理器上的高速缓存中相应的缓存条目的状态都标记为I’ 从而使该处理器后续执行针对相应地址(无效化队列内容中指定的地址)的读内存操作时必须发送Read消息.以将其他处理器对相关共享变量所做的更新同步到该处理器的高速缓存中。

​ 不同的处理器架构所支持(允许)的内存重排序各有不同。比如,现代处理器都会采 用写缓冲器, 而有的处理器(比如x86)会保障写操作的顺序, 即这些处理器不允许StoreStore 重排序的出现。

再探可见性

​ 我们说写缓冲器是可见性问题的硬件根源。

​ 处理器在一些特定条件下(比如写缓冲器满、I/0指令被执行)会将写缓冲器排空(Drain)或者冲刷(Flush), 即将写缓冲器中的内容写入高速缓存 ,但是从程序对一个或者一组变扯更新的角度来看,处理器本身并无法保证这种冲刷对程序来说是及时的。因此,为了保证一个处理器对共享变措所做的更新可以被其他处理器同步,编译器等底层系统需要借助一类被称为内存屏障的特殊指令。内存屏障中的存储屏障(Store Barrier)可以使执行该指令的处理器冲刷其写缓冲器。

​ 然而,冲刷写缓冲器只是解决了可见性问题的一半。因为可见性问题的另一半是无效化队列导致的。无效化队列的引入本身也会导致新的问题一处理器在执行内存读取操作前如果没有根据无效化队列中的内容将该处理器上的高速缓存中的相关副本数据删除,那么就可能导致该处理器读到的数据是过时的旧数据,从而使得其他处理器所做的更新丢失。因此,为了使一个处理器上运行的线程能够读取到另外一个处理器上运行的线程对共享变量所做的更新, 该处理器必须先根据无效化队列中存储的Invalidate消息删除其高速缓存中的相应副本数据,从而使其他处理器上运行的线程对共享变拯所做的更新在缓存一 致性协议的作用下能够被同步到该处理器的高速缓存之中。

​ 内存屏障中的加栽屏障(Load Barrier)正是用来解决这个问题的。加载屏障会根据无效化队列内容所指定的内存地址, 将相应处理器上的高速缓存中相应的缓存条目的状态都标记为I’ 从而使该处理器后续执行针对相应地址(无效化队列内容中指定的地址)的读内存操作时必须发送Read消息.以将其他处理器对相关共享变量所做的更新同步到该处理器的高速缓存中。

​ 因此, 解决可见性问题首先要使写线程对共享变量所做的更新能够到达(被存储到) 高速缓存,从而使该更新对其他处理器是可同步的。其次 , 读线程所在的处理器要将其无效化队列中的内容 ”应用” 到其高速缓存上, 这样才能够将其他处理器对共享变怔所做的 更新同步到该处理器的高速缓存中。

​ 而这两点是通过存储屏障与加载屏障的成对使用实现的:写线程的执行处理器所执行的存储屏障保障了该线程对共享变量所做的更新对读线程 来说是可同步的;读线程的执行处理器所执行的加载屏障将写线程对共享变扯所做的更新同步到该处理器的高速缓存之中。

​ 存储转发技术也可能导致可见性问题。

发布了136 篇原创文章 · 获赞 6 · 访问量 1495

猜你喜欢

转载自blog.csdn.net/weixin_42073629/article/details/104731403