浅析内存屏障:内存一致性模型

前言

现代计算机为了提升处理性能,在硬件层面加入了各种优化等,最终导致了内存乱序访问的问题。由于不同处理器架构在硬件层面的优化程度不同,导致可能产生的内存乱序访问的行为也存在很大的差异。内存一致性模型描述了这些可能产生的乱序访问行为的规则以及约束,以便软件开发人员在不清楚硬件实现细节的情况下,能够理解硬件的行为并正确编写并发代码。

内存一致性模型

内存一致性模型(Memory Consistency Model)就是用来描述多线程对共享存储器的访问行为,在不同的内存一致性模型里,多线程对共享存储器的访问行为有非常大的差别。这些差别会严重影响程序的执行逻辑,甚至会造成软件逻辑问题。

内存一致性模型分类

内存一致性关注对内存的读写操作访问,由此可得到4种不同的指令组合,依次为Store-Load、Store-Store、Load-Store、Load-Load,通过允许调整这些指令组合执行的顺序,可以获得不同的内存一致性模型。目前有多种内存一致性模型,从上到下模型的限制由强到弱,依次为:

  • 顺序一致性(Sequential Consistency,简写SC)模型;
  • 完全存储定序(Total Store Order,简写TSO)模型;
  • 部分存储定序(Part Store Order,简写PSO)模型;
  • 宽松存储(Relax Memory Order,简写RMO)模型。

SC模型

SC模型,也称为强定序模型。CPU按照程序代码的指令次序来执行所有的Store与Load指令,并且从其它CPU和内存的角度来看,感知到的数据变化也完全是按照指令执行的次序。在这种模型下,程序不需要使用任何内存屏障,但就是性能会比较差。为了提升系统的性能,不同处理器架构或多或少对这种强一致性模型进行了放松,允许对某些指令组合进行重排序。

TSO模型

TSO模型允许对Store-Load指令组合进行重排序,即如果第一条指令是Store指令,第二条指令是Load指令,那么在程序执行是,Load指令可能先于Store指令执行。TSO模型的硬件实现,通常是在CPU和Cache之间引入了Store Buffer,如下图:
在这里插入图片描述
Store Buffer只有Store指令会使用到,并且Store Buffer以FIFO(先入先出)的方式处理写入的数据。这种情况下,Store-Store指令组合仍能按照顺序执行,但Load指令则可能会先于Store指令完成执行。x86架构采用的就是TSO模型。

TSO模型示例

以如下代码为例:
在这里插入图片描述
TSO模型中,由于Store Buffer的存在,CPU0在执行S1时,将数据放到Store Buffer后就返回执行L1指令;CPU1也是这样进行处理。最终,当L1和L2指令都执行完成时,S1和S2指令的数据还未从Store Buffer刷新到内存中。于是程序的执行结果就可能会出现下列的情况(备注:这里我们限定代码的执行时序,不考虑并发执行会产生的其它时序):
在这里插入图片描述

TSO模型与内存屏障

为了保证TSO模型下,程序执行的正确性,我们在代码中增加内存屏障指令:
在这里插入图片描述
重新执行程序,可以看到,在所有Load指令执行前,内存屏障会保证所有的数据从Store Buffer刷入到内存中,后续再执行Load指令时,程序可以获得正确的数据。
在这里插入图片描述

PSO模型

PSO模型是在TSO模型的基础上,进一步允许了对Store-Store指令组合进行重排序。从硬件实现的角度来看,就是允许了Store Buffer以非FIFO的方式处理。

PSO模型示例

分析下面的代码:
在这里插入图片描述
在PSO模型中,一种可能出现的执行结果如下图:
在这里插入图片描述
CPU0在执行S1时,将数据放到Store Buffer后就返回,继续执行S2,S2写入的数据也会放到Store Buffer中。但由于此时Store Buffer是以非FIFO的方式处理的,因此S2的数据则可能会先S1写入到内存中。于是CPU1在执行判断OK后,继续执行L2,但发现L2指令读取的数据并不是最新的。

PSO模型与内存屏障

要解决这个问题,同样需要依赖内存屏障机制来保证S1与S2的内存可见性是有序的。
在这里插入图片描述
加入屏障后,程序执行的结果如下:
在这里插入图片描述

RMO模型

RMO模型是最为宽松的内存一致性模型,它在PSO模型的基础上进一步放宽了访存指令的执行限制,其不仅允许Store-Load、Store-Store指令组合重排序,还进一步允许Load-Load、Load-Store指令组合重排序。Aarch64架构采用的就是RMO模型。

内存屏障与一致性

硬件设计人员为了尽可能的榨取CPU的性能,引入了乱序的内存一致性模型,并提供内存屏障机制用以解决在这些一致性模型上可能出现的内存乱序访问问题,内存屏障的最根本的作用就是提供一个机制,要求CPU在这个时候必须以顺序存储一致性模型的方式来处理Store与Load指令,这样才不会出现内存访问不一致的情况。

相关参考

  • 《A Primer on Memory Consistency and Cache Coherence》
  • 1
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
ThreadLocal 是 Java 中的一个类,它提供了一种线程局部变量的机制。线程局部变量是指每个线程都有自己的变量副本,每个线程对该变量的访问都是独立的,互不影响。 ThreadLocal 主要用于解决多线程并发访问共享变量时的线程安全问题。在多线程环境下,如果多个线程共同访问同一个变量,可能会出现竞争条件,导致数据不一致或者出现线程安全问题。通过使用 ThreadLocal,可以为每个线程提供独立的副本,从而避免了线程安全问题。 ThreadLocal 的工作原理是,每个 Thread 对象内部都维护了一个 ThreadLocalMap 对象,ThreadLocalMap 是一个 key-value 结构,其中 key 是 ThreadLocal 对象,value 是该线程对应的变量副本。当访问 ThreadLocal 的 get() 方法时,会根据当前线程获取到对应的 ThreadLocalMap 对象,并从中查找到与 ThreadLocal 对象对应的值。如果当前线程尚未设置该 ThreadLocal 对象的值,则会通过 initialValue() 方法初始化一个值,并将其存入 ThreadLocalMap 中。当访问 ThreadLocal 的 set() 方法时,会将指定的值存入当前线程对应的 ThreadLocalMap 中。 需要注意的是,ThreadLocal 并不能解决共享资源的并发访问问题,它只是提供了一种线程内部的隔离机制。在使用 ThreadLocal 时,需要注意合理地使用,避免出现内存泄漏或者数据不一致的情况。另外,由于 ThreadLocal 使用了线程的 ThreadLocalMap,因此在使用完 ThreadLocal 后,需要手动调用 remove() 方法清理对应的变量副本,以防止内存泄漏。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值