steamclient.exe最近电脑上老出现这个进程占用很高很高的cpu，有人知道这是啥吗？_百度知道
steamclient.exe最近电脑上老出现这个进程占用很高很高的cpu，有人知道这是啥吗？
打开文件位置，会发现再windows目录下有个min文件夹，好多应用程序。把进程结束之后，文件夹删掉，过段时间又会出现，而且有四五台机子出现这问题？有人知道是咋回事吗
我有更好的答案
这个程序是Steam的客户端引起的问题，检查是否安装了Steam客户端，删除就不会有这样的问题了。
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。请完成以下验证码
查看: 13907|回复: 15
趋势的这个进程是做什么的？CPU占用一直很高。
本帖最后由 lszl 于
23:57 编辑
趋势的这个进程是做什么的？CPU占用一直很高，导致风扇狂转。
之前是繁体中文，前两天在官网下载的简体中文全功能增强版重新安装的，还是这样。
就这个：Trend Micro Anti-Malware Solution Platform
fjhf.JPG (82.34 KB, 下载次数: 1)
23:49 上传
程序位置：
rth.JPG (90.19 KB, 下载次数: 1)
23:55 上传
回答此问题无力！！！
这是趋势个人版嘛？。。。。
实时监控 目测应该和什么软件冲突
实时监控的进程 正在扫文件呢。
这是趋势个人版嘛？。。。。
是的，因为有platinum user session agent，判断为8.0个人版。
而这个进程是趋势科技反恶意软件通用架构进程，用于实时扫描
楼主，请你把你控制面板中的程序列表全部截图发给我。
顺便告诉我当时你有登QQ吗？还是正在退出QQ的过程中？
楼主，请你把你控制面板中的程序列表全部截图发给我。
顺便告诉我当时你有登QQ吗？还是正在退出QQ的过程中 ...
好的，今天暂时还没出现症状，出现后截图上来。
我来一个相关问题，趋势科技的官网提供了许许多多的引擎下载，这些引擎是否已经安装于最新版，如果没有，个人用户下载后是否可以提升简中查杀率，会影响误报么
Johnkay.Young
我来一个相关问题，趋势科技的官网提供了许许多多的引擎下载，这些引擎是否已经安装于最新版，如果没有，个 ...
同问，如果没有下载最新版，那么以前的版本能否升级到最新版本。
Copyright & KaFan &KaFan.cn All Rights Reserved.
Powered by Discuz! X3.4( 苏ICP备号 ) GMT+8,论文发表、论文指导
周一至周五
9：00&22：00
面向多核处理器的内存竞争记录研究综述
　　摘 要： 共享内存多线程编程是挖掘多核处理器并行性的重要方法，然而，共享内存的多线程程序在运行时存在不确定性，线程间的内存竞争是导致不确定性的主要来源。内存竞争信息量大，记录时带来的开销大，实现内存竞争记录是确定性重演共享内存多线程程序的关键。分别概括了现有软件实现的内存竞争记录机制和硬件实现的内存竞争记录机制，并对内存竞争记录的研究现状进行了总结，指出了当前内存竞争记录技术面临的挑战。 中国论文网 /8/view-4364507.htm　　关键词： 多核处理器； 多线程程序； 确定性重演； 内存冲突； 内存竞争记录 　　中图分类号： TP303 文献标识码： A 文章编号：（3-07 　　Study on Memory Race Recording for Multi-core Processors 　　ZHU Suxia1， JI Zhenzhou1， LI Dong2 　　（1 School of Computer Science and Technology， Harbin Institute of Technology， Harbin 150001， China； 　　2 School of software， Harbin Institute of Technology， Harbin 150001， China） 　　Abstract： Writing shared-memory multithreaded programs become an important means to explore the parallel performance of multi-core processor systems. However， multithreaded programs are nondeterministic at run. Inter-thread memory race is the main source of this nondeterminism. Memory races are large and cost overhead. Memory race recording becomes the key technology to achieve deterministic replay of multithreaded programs. This paper summarizes the existing software memory race recording mechanisms and hardware memory race recording mechanisms. And the challenges for memory race recording are also pointed out. 　　Key words： Multi-core Processor； Multithreaded Program； Deterministic Replay； Memory Conflict； Memory Race Recording 　　0 引 言 　　自2005年Intel发布了基于x86的桌面版双核处理器后，多核处理器成为应用的主流，编写共享内存的多线程程序也随之成为挖掘多核处理器系统并行性的重要技术策略。然而，共享内存的多线程程序在执行时存在着不确定性，即在相同输入下，同一程序在同一台处理器系统上运行多次，运行的结果却可能出现不同。这种执行时的不确定性给多线程程序的编写、调试、应用等都带来了相应的实施难度和阻力。 　　划分为记录和重放两个阶段的确定性重演机制是解决共享内存多线程程序执行不确定性的有效手段[1]。确定性重演机制通过在记录阶段记录程序运行时存在的不确定性信息，在重放阶段使用所记录的不确定性信息操控程序再现原始的执行结果。不确定的信息多种多样，如输入信息、检查点信息、内存竞争等。由于当今处理器系统均提供高效的核间通信机制，使得共享内存的多线程程序在运行时内存竞争频发，记录的内存竞争信息量也在增加。同样，对于较长的大型程序，必须精简记录文件，因为记录的信息和要执行的并发程序共用内外存空间，且随着目标程序运行记录信息日渐增多，很大程度上会影响并发程序本身的执行，加重系统的运行负担。内存竞争记录目标就是在保证重演和原始执行一致的前提下，尽可能地减少记录的信息以控制时空消耗。内存竞争记录是实现共享内存多线程程序确定性重演的关键，已成为近年来计算机领域的研究热点。 　　1 内存竞争 　　在共享内存的多线程程序中，如果两个或多个线程访问了同一个内存地址，并且至少有一个是写操作，则会引发内存冲突。内存冲突共有3种类型：写后读（WAR—write after read）、读后写（RAW—read after write）、写后又写（WAW—write after write）。图1（a）展示了一个包含2个线程的共享内存多线程程序的部分指令执行序列，2个线程都对共享内存x进行了读写操作，线程i先写，线程j后读，则发生了写后读（WAR）内存冲突。 　　在编写多线程程序时，程序员通常使用同步操作来协同线程间内存冲突双方指令的执行顺序，使多个线程能够以确定顺序来访问共享内存。如果使用了正确的同步操作，线程间内存冲突的顺序是确定的，否则，线程间内存冲突的顺序是不确定的。这种不确定顺序的访问可能会引起内存竞争。程序执行的结果最终将依赖于竞争的结果。 　　内存竞争是共享内存型多线程程序中最常见的错误之一，是多线程程序执行不确定性的根源所在。内存竞争有一般性竞争（general race）和数据竞争（data race）之分[2]。一般性竞争指多线程程序执行过程中所表现出来的不确定性。具体地说，在多线程程序执行过程中，不同线程对共享内存（无论是否由共同的锁进行同步保护）执行顺序的差别，都可以归类为一般性竞争。数据竞争表现为不同的线程访问同一个共享内存，而对共享内存操作没有使用同一个锁变量进行保护，即临界区域违反了原子性执行，这是导致多线程程序出现并发错误的主要原因。用图示解说这两种竞争的发生过程，如图1所示。
　　图1 内存竞争示例 　　Fig.1 Example of memory race第3期 朱素霞，等：面向多核处理器的内存竞争记录研究综述 智能计算机与应用 第3卷 　　如图1（a）中，x作为共享内存，因为线程i、j都没有添加同步操作实现对x的互斥操作，使得两线程可能会同时执行对x的操作，因而会引发数据竞争，导致程序运行结果不确定。程序执行的结果，最终取决于谁“赢得”竞争。竞争的结果往往取决于机器的配置和初始状态（例如，缓存替换策略和缓存的初始内容）。在图1（b）中，线程i、j都在共享内存x操作前后添加了同步操作语句，加锁（lock）和解锁（unlock）操作，可以实现两线程互斥的访问x，不会引发数据竞争。然而，没有数据竞争同样会使得程序存在不确定性。因为这种互斥的访问并没有明确排定两线程间对x的操作顺序，有可能线程i先写x，也可能线程j先读x，从而可能会引发一般性竞争，可能会导致程序多次运行得到不同的执行结果。 　　所有的内存竞争都属于内存冲突，反之，则不成立，只有内存冲突双方对应的内存操作的执行顺序不确定时才会引发内存竞争。 　　2 内存竞争记录 　　内存竞争记录是实现共享内存多线程程序确定性重演的关键技术，已成为近年来计算机领域的研究热点。截至目前为止，内存竞争记录的研究已经取得了丰硕成果。下面概括论述国内外内存竞争记录相关的研究进展。 　　2.1 软件实现的内存竞争记录机制 　　目前已有不少的软件系统实现了多线程程序中内存竞争的记录及重演，有的系统采用基于值的方法实现，有的采用顺序的方法实现，有的记录线程间同步操作的顺序，有的记录线程间内存交互的顺序，还有记录操作系统调度的顺序，等等方式不一而足。系统的实现方式不同，应用的场合也有所不同。下面对其进行概略性介绍。 　　Recap[3]在编译时对每个共享内存读操作进行插桩，在程序运行时记录每个共享内存读操作的值。这种方式记录了内存竞争的结果，能够确定性地重演多线程程序，但是却不能提供线程间共享内存操作的顺序。同时，追踪每个共享内存读操作的值，将造成性能开销增加、记录的日志庞大。 　　Instant replay[4]则不记录共享内存读操作的值，而是将线程间的交互看做是对共享对象的操作，记录线程中共享对象读或写的顺序。Instant replay为每个共享内存对象添加一个版本号，每个线程都将访问共享对象时的版本号信息记录到日志文件中。通过这种方式，程序在重演时，就能够确保所有线程访问到与其原始执行时相同的版本号，从而可以确定性地重演多线程程序。在这种方式下，用户要对共享对象及同步操作进行标记，以一种较粗的粒度记录对共享内存操作的顺序。Instant replay因为要跟踪所有内存的读写操作，将带来不小的开销，而且只能适用于没有数据竞争的场合。 　　SMP-Revirt[5]是Instant Replay对共享对象的一种概括，可记录共享内存页的状态。在记录日志阶段，一个给定的内存页只能处于并发读或互斥写的状态，这些访问控制通过改变一个线程的页的权限来实现。SMP-Revirt同样也是采用了较粗的粒度来记录操作的顺序，只能适用于没有数据竞争的场合。因为SMP-ReVirt的插桩操作和对基于页级粒度的共享内存的保护，存在伪共享和页竞争。尤其是随着处理器数目的增加，其开销也越来越大。在配置4个CPU的情况下，SMP-ReVirt中一个应用开启记录功能后的运行时间就能够达到正常运行时间的9倍之多。 　　RecPlay[6]通过记录同步操作的顺序，间接地记录线程间交互的顺序。同步操作的顺序用一个标量Lamport时戳[7]来识认，在重演时，可以通过重建Lamport时戳实现确定性的重放。同时为了减少存储的时戳信息，RecPlay只记录时戳的增量，而非实际的时戳。但RecPlay只能够重演不包含数据竞争的程序，而且也不能提供线程间内存操作的顺序。 　　Russinovich[8]通过记录线程调度顺序间接记录内存竞争，可以实现多线程程序的重演。假设多线程程序运行在一个单核处理器上，则指令执行的顺序是由调度器决定的，Russinovich记录器通过记录调度器发出的调度日志就可以记录多线程执行的顺序。采用相同的调度顺序重放程序，就可以再现竞争，实现程序的确定性的重演。然而，为了支持多线程能在单处理器上运行，Russinovich记录的调度器调度的顺序，10%的运行时间开销在记录阶段，其中一半用于追踪软件的指令计数器，而另一半则来自记录模块。而且，随着处理器数目的增加，开销则会大幅度上涨。 　　JaRec[9]和DejaVu[10]是在java虚拟机上实现的记录器。Jarec使用一个同RecPlay相似的方式，有效记录了JVM上共享内存操作间的顺序，但却也同样不能重演具有数据竞争的多线程程序。DejaVu则借鉴与Russinovich相近的思想，通过记录线程运行时的关键事件，为多线程创建了逻辑上的调度。DejaVu独立于系统底层的调度器，能实现与同java虚拟机的物理调度器分离，具有更好的可移植性。JaRec和DejaVu还同样都会带来较大开销。JaRec可使得宏测试用例的运行速度减缓80%，Dejavu则使得综合测试用例的运行速度减缓70%，同时使得SPLASH内核的运行速度也相应减缓了35%。 　　Kendo[11]通过确保同样于原始执行时获取锁的顺序而间接记录内存竞争来重演多线程程序。Kendo要求程序实现正确的同步，但却不能提供线程间内存操作的顺序，另外也不支持包含数据竞争的程序。 　　Netzer[12]采用点到点记录方式，为每个线程记录一个由冲突双方的指令计数值IC表示的依赖关系组成的日志。Netzer为每个线程提供一个指令计数器IC。IC标记了一个线程内指令执行的顺序。而内存冲突则用线程间的一对IC值来表示。Netzer内存竞争记录器不需要记录线程内指令执行的顺序，而只是记录线程间指令的Happen-before关系[7]，即由冲突双方IC值表示的依赖关系。重演时，线程内的指令按照IC值的大小重放，线程间的指令执行顺序则按照记录的偏序重放，这样就可以重演多线程程序。冲突和程序的执行顺序构成一个有向图，两者之间还可以进行传递性的约减（Transitive Reduction），从而使得有些冲突不需要记录。这种传递性约减在Netzer中可证明是正确的，再次执行程序的过程与没有约减时执行的过程是一致的。只是运行时间开销较大，因为要跟踪所有的内存读写操作，使得重演的速度牺牲了至少1个数量级。
　　PinPlay[13]基于流行的动态插桩工具Pin[14]，实现了一个通过易于使用的框架来捕获程序执行 信息、确定性重演程序以及在合理的时间和空间消耗范围内分析大型程序的执行过程。PinPlay主要应用于程序调试，而且只支持离线的重演。 　　ODR[15]记录同步操作顺序等信息，使用一种称为DRI的技术，搜索能够产生相同结果的运行空间，并推断得出竞争的结果。ODR 减少了记录阶段的信息量及开销，同时确保原始执行时的所有错误在执行时都是可见的。但是，在重放阶段，需要搜索可确定性执行的空间，由此导致了重放阶段的消耗大幅度增加，速度大尺度下降，且只能实现离线的重演。 　　Respec[16]支持运行在商业多核处理器上的共享内存多线程程序的确定性重演，能够实现在线的重演，即记录和重演可以并发执行。Respec采用两种策略来减少开销：可推测的日志记录和外部重演。可推测的日志记录只存留更少的能够确保重演的线程间交互信息，在重放时，如果重放过程偏离记录过程，则尝试再次重放，两次执行必须确保执行的结果和最终的状态达到一致。这两种策略可以确保不包含数据竞争的程序段记录和重放时有较低的开销，也能够确保带数据竞争的程序段的正确重放。只是重放时的速度将大大地放缓。 　　PRES[17]本着放宽以重现错误为第一重演目标的思想，通过只记录部分程序执行过程中的信息（PRES称为“草图”），并借助额外的诊断时间智能搜索未记录的不确定性空间来重现错误。PRES降低了记录阶段的开销，但因为在重演时搜索不确定的空间，增加了重演阶段的消耗，重演的速度为之急剧降低。而且只支持离线的重演。 　　DoublePlay[18]提供了一种能够确保在商业多核处理器上的重演手段，通过将线程划分为并行的epoch，在记录阶段只记录同步操作等少量的信息，在重演时使用这些信息指导程序实现epoch级并发执行。DoublePlay保证了带或不带数据竞争的程序的确定重演，但却需要一个额外的处理器核，可扩展性不好，并且只支持离线的重演。 　　2.2 硬件实现的内存竞争记录机制 　　针对软件实现内存竞争记录带来的巨大性能开销，对原有系统性能影响重大，而且软件的实现速度也不具备现实可接受性，而与之相对，硬件却只会带来很小的、几乎可以忽略的性能开销。因此，研究者纷纷提出了硬件支持的内存竞争记录器。 　　Goldstein[19]是第一个基于硬件的内存竞争记录器，在基于监听总线的多核处理器系统上实现，监听并记录总线上的所有事务。每次总线操作，对应指令的IC值则送往记录器，此记录器便为多线程记录了一个总线操作的全序，也就是既记录了线程间共享内存操作的偏序关系，又记录了线程内对共享内存操作的顺序。为实现这个全序记录器，Goldstein需要添加一个内存页状态表、一个指令计数器表和一个日志缓存。因为内存间交互的记录由专门硬件设计实现，对程序执行的速度影响小，但Goldstein需要追踪每一个内存访问，需要记录大约50%总线操作，记录的日志超大，内存开销也为之加大。同时，又由于其实现是基于监听总线的多处理器系统下，可扩展性较差。 　　ReEnact[20]使用线程级推测机制来记录和重演多线程程序。每个处理器核需要添加版本cache和支持回滚能力硬件部件。每当检测到同步操作时，结束一个chunk，而同步操作结束后，再开启一个新的chunk。通过记录固定数目的chunk，可以确定性地重演至发生内存竞争的位置。但ReEnact的硬件实现结构复杂，且只能实现离线的重演。 　　CORD[21]使用Lamport时钟来标记内存竞争的顺序，但是以cache块为粒度，为每个cache块添加一个时戳，并对原有的cache结构进行了修改。同时，每个处理器添加两个寄存器用于保留下一个可用内存的物理地址以及chunk结束时对应内存的物理地址。相比ReEnact，CORD硬件实现复杂度降低，但却牺牲了内存竞争检测的精度。 　　BugNet[22]实现了用户级的确定性重演，在记录内存竞争时，与Recap一样，记录共享内存读操作的值，但不记录所有共享内存读操作的值，而是只记录第一次读某个共享内存地址时的值。一个共享内存的值如果为外部事件所修改，其后读取这个地址的值也将得到同样的记录。BugNet实现了多线程程序的重演，记录了更小的日志，但却同样需要追踪每个共享内存读操作，因而带来较大的性能开销。 　　FDR[23]是一个硬件实现的全系统记录器，在进行内存竞争时，记录共享内存操作间的偏序关系，并实现了Netzer[12]提出的传递性约减算法，所记录的日志格式如图2所示。 　　图2 FDR内存竞争记录格式 　　Fig.2 Memory race logging style in FDR 　　FDR采用点到点的记录方式记录由冲突双方指令IC构成的偏序关系，需要保存每个内存操作的时戳到cache中，利用原有的cache一致性协议进行内存竞争检测。与Goldstein不同的是，FDR只记录一致性操作中很少的一部分事件，将记录信息添加到cache一致性部件中，大大降低了硬件资源消耗。而且，FDR是一种基于目录cache一致性协议的分布实现方式，具有良好的可扩展性。图3给出了FDR的硬件实现结构。FDR为系统中的每个核增加一个指令计数器，记录本线程已执行的指令数；为每个cache行增加了一个cache指令计数器（CIC），存储访问这个cache行的最后一次读指令或写指令对应的指令计数器值。当一个处理器核收到来自其他核的针对某个cache行的远程一致性请求时，就将此cache行对应的CIC和核ID号附加到与之相配的应答消息中。发出请求的处理器核记录下通过由应答方送来的ID和CIC值以及请求方ID与当前的IC形成的依赖关系。为了实现传递性优化算法，FDR还需要为每个核增加一个向量指令计数器，追踪每个核收到的最新的CIC。FDR实现了线程间的内存竞争的记录，可以实现程序的快速重演，但却因之带来了较大的硬件资源消耗。
　　图3 FDR内存竞争记录实现结构 　　Fig.3 Hardware implementation in FDR 　　RTR[24]是FDR的改进版本，已不再记录确切的冲突happens-before关系，而是为冲突创建一种优化的人工顺序。这种人工顺序能够获得比Netzer’TR算法性能更佳的优化，创建了更加紧凑的日志，如图4所示。与FDR相同，RTR也需要保存内存操作的时戳。但是，RTR为了减少对原有cache的影响，采用了分离的cache结构。而且，RTR也将该内存竞争机制应用在TSO存储模型中。虽然，RTR记录了更小的日志，但却因为需要为每个内存操作保存时戳，并与FDR同样地，带来了较大的硬件消耗。 　　图4 FDR内存竞争记录格式 　　Fig.4 Memory race logging style in FDR 　　Rerun[25]首先提出了chunk记录方式。chunk是指程序运行时相互独立的内存指令的集合。在chunk记录方式下，硬件资源消耗低，由此其后很多内存竞争记录研究成果中也都纷纷采用了chunk记录方式。 　　在Rerun中，chunk可称为episode，如图5所示。Rerun为每个处理器核增加一个读、写签名，分别用来记录此核 　　图5 Rerun中的episode 　　Fig.5 Episode in Rerun 　　当前chunk中内存块的读写地址；添加一个全局的Lamport时钟，用于标记chunk的时戳，如图6所示。当cache收到一个远程请求时，就查找签名来检测冲突。如果检测到冲突，结束当前chunk，并且清空读写签名，记录刚才结束的chunk长度和时戳至内存竞争日志中，同时更新时戳值。处理器核则会将更新后的时戳附加到一致性协议的应答消息中，确保每个处理器核的chunk的顺序。这种记录方式大幅降低了硬件资源消耗，还在较弱的程度上压缩了所记录的日志，并且记录的日志容量还有良好的可扩展性，不会随着处理器数目的增加而成倍上升。然而，Rerun在重演时只能按照chunk时戳的大小顺序进行重放，重演速度则大为降低。 　　图6 Rerun内存竞争记录实现结构 　　Fig.6 Hardware implementation in Rerun 　　与Rerun相同，DeLorean[26]也使用签名实现内存竞争检测，但却只能运行在另一个不同的多处理器执行环境BulkSC[27]下。在这个环境中，处理器核不断地执行由检查点寄存器彼此分隔的chunk，在能提交一个chunk之前，其所对应的签名就要同其他chunk的签名进行比较来检测冲突。如果一个chunk检测到冲突，对应签名就会清空，chunk弹回并重新执行。虽然已经证实Delorean表现良好，但由于其只能应用在一款不同的多处理器下，执行的环境并不标准，而且还需要硬件扩展，且同硬件支持的事务内存较为类似[28]，因此很难得到大范围的应用。 　　文献[29]在Rerun的基础上实现了基于监听总线的多核系统下chunk的记录，而且提出了并发chunk域来提高重演速度。IMMR在一个chunk结束时，会发出广播信息，使所有线程的chunk结束，具有相同时戳的chunk将构成并发chunk域。采用这种并发chunk域，重演时的速度可以提高几个数量级，但却需要记录更大的内存竞争日志。 　　Timetraveler[30]通过挖掘Rerun中记录的循环chunk，记录了一个无循环的内存竞争日志。Timetraveler为cache一致性部件添加了一个Time-delay缓冲区，并在二级cache中添加一个过期时戳，以检测循环的chunk。Timetraveler最大限度地减少了记录的内存竞争日志，但却改变了cache系统的结构，也没有提及如何提高重演的速度。 　　Karma[31]对 Rerun进行了扩展，通过将chunk记录到一个有向无循环图DAG中来标记chunk执行的先后顺序，而不再记录Lamport时戳。在每次检测到冲突后，Karma就在DAG中添加一个指向后续chunk的边，这个边由前驱chunk和后继chunk的相关信息组成。Karma这种DAG图的记录方式提高了重演的并行性，加快了重演的速度，但重演的速度性相比前面介绍的点到点的记录方式，即FDR和RTR，还有待进一步提升。 　　Strata[32]采用向量时钟表示访存操作间的happens-before关系，由于向量时间戳可以间接地表示多个happens-before关系，所以可以减少记录信息的数目。Strata在发生一个内存冲突时，记录一个Stratum，Stratum就将包含这一时刻的所有线程时戳。一个Stratum可以将记录内存冲突发生前和记录内存冲突后的内存操作做以有效区别，通过分析两个相邻的Stratum就可以捕获内存冲突。采用这种记录方式可以不用记录读后写类型的冲突，减小了内存竞争日志。但若要想知道共享内存间的依赖关系究竟为如何，就需要进行离线的分析。同时，随着处理器数目的增加，记录的日志会增加太多，可扩展性较差[22]。 　　Rainbow[33]同Strata一样，用向量时钟表示访存操作间的happens-before关系[7]，但其通过建立精确的happens-before关系，有效地减小了记录信息，并采用逻辑向量时钟描述冲突访存操作间的happens-before关系，而与采用标量时钟相比，则可以避免happens-before关系的误识，同时降低重放执行过程中并行度的损失。在4核处理器上，Rainbow与Strata相对照，在记录条数上平均减少了17%。但Rainbow的可扩展性却同Strata一样，均属表现较差。 　　LReplay[34]提出了一种简洁的硬件辅助机制实现确定性重演。LReplay不记录内存交互的顺序，而是记录指令或指令块的延迟时间信息，虽然硬件资源消耗少，记录的日志也小，但却只能应用于一款特殊的体系结构Godson-3[35]。
　　现有的绝大多数的内存竞争记录器只考虑了顺序一致性模型，RTR，Karma虽然提供了对TSO储存模型的支持，但却都需要修改cache子系统的结构或cache一致性协议，这将很难在商用处理器中得到圆满实施。文献[36]给出了一个高效、低复杂度的处理器方案，支持TSO存储模型下的记录和重演，记录初始的寄存器状态和cache未命中的数据。使用这些信息，每个线程在重演时，使用离线算法推导得出线程间共享内存的TSO兼容的因果顺序。同时，这一方案也讨论了限定搜索空间的方法及降低离线分析时间的优化方法。但该记录机制只能支持离线的重演，且重演时则因为要搜索空间，重演速度也较低。 　　CoreRacer[37]是一个针对x86 TSO处理器核、基于chunk的内存竞争记录器，而且不需要修改cache系统和一致性协议。通过利用一个特殊x86体系结构特征—不变的时间戳，CoreRacer无需向高速缓存一致性的消息中添加消息就可以维护chunk间的顺序。CoreRacer通过记录chunk结束时写缓冲中等待提交的写操作的数目来处理TSO存储模型。另外，CoreRacer还利用所记录的信息仿真了写缓冲，但同文献[33]一样的是，只能实现离线的重演。 　　3 内存竞争记录面临的挑战 　　现有软件实现的内存竞争机制带来了较大的性能开销，虽然有些系统通过一系列举措来减小记录的开销，如RecPlay等通过减小所需记录的程序的范围来降低开销，PRES和ODR通过放松对确定性重演的定义来降低开销，DoublePlay通过转换工作从记录阶段到离线重演阶段来降低开销等等。但相比硬件实现，开销仍显巨大。而且，硬件在价格不断下降的同时，性能却在持续增强，因此，硬件实现的内存竞争记录更具发展前景，同时为越发复杂的软件系统提供内存竞争记录的技术支持也显得尤为必要。但硬件的实现的内存竞争记录机制却仍然在如下方面存在艰巨挑战，需要正视和应对。 　　（1）日志大小 　　现在的计算机支持快速的通讯机制，内存竞争频发，虽然FDR、RTR采用传递性递减方法在一定程度上减小了内存竞争日志，但如果是长时间地运行程序，仍会造成记录的日志过大。Timetraveler虽然努力减小了内存竞争日志，但却带来了一定的设计复杂度，并且其重演速度同Rerun一样也要受限。Karma虽然可以通过调节chunk的长短来减小内存竞争日志，但这种调节又会反过来影响重演速度。而实际应用中，如果长期开启内存竞争记录功能，不仅会产生大量的内存竞争日志，还会消耗大量的内存，对重演速度也会发生高度影响。LReplay显著减小了内存竞争日志，但也只能适用于特殊结果的处理器。 　　（2）带宽开销 　　除Delorean外，所有的内存竞争记录器必须附加cache一致性消息来维护系统中时间的顺序。例如，在FDR中，当前的指令计数值CIC就附加到cache一致性应答消息中，用以记录不同进程两指令间点对点的依赖关系。Rerun中的时戳则附加到每个一致性应答中，用于维护块间的因果关系。FDR和Rerun在功能仿真中会带来10%的带宽开销，并因其带宽带来了一定压力而损伤了性能。其他硬件实现的内存竞争记录机制同样存在带宽开销大的弱点，而对于一直都要开启确定性重演功能的系统来说，带宽的消耗更是不可估量。 　　（3）重演性能 　　很多应用都能得益于确定性重演，如容错、长时间间隔的调试等应用，因此需要开发实用技术来提高重演速度。Delorean、FDR和RTR均能以程序原始执行时的速度来重演一个程序。在Delorean中，通过并行的、而且以在原始执行过程中记录的提交顺序为依据地重新同步程序块才得以完成重演。FDR、RTR可以并行重演，只有在原始执行过程中记录的点到点的依赖关系处重新同步来实现重演。然而FDR、RTR和Delorean都不可能成为现实中内存竞争记录器的实际选择，因为FDR和RTR都需要增加较多的硬件资源，而硬件复杂度却是当代多核处理器的一大设计难关，而Delorean的执行环境又极不标准。Rerun中按照chunk时戳增长的顺序进行重演，几乎是串行的，因此，Rerun不能满足内存竞争记录应用对重演速度的需求，如容错处理。作为一个替代的重演方案，文献[29]提出了一种称为并发chunk域的重演策略，一定程度上提高了重演速度，但却是在牺牲日志尺寸情况下获得的速度提升。Karma采用DAG图记录chunk，脱却了全局时钟的限制，但其重演的速度相对点到点记录方式仍然有待改进。而文献[36]和CoreRacer只支持离线的重演。 　　（4）支持非顺序存储模型 　　目前提出的内存竞争记录机制，只有很少的一部分能够支持非SC存储模型，这对商用处理器来说，是一大挑战。文献[36]和CoreRacer虽然针对TSO存储模型，但只支持离线的重演。为了开拓内存竞争记录的应用场合，早日进入实际应用中，就需要开展针对非SC存储模型的内存竞争记录机制的进一步研究。 　　4 结束语 　　随着多核处理器的流行，共享内存多线程程序的应用也日益广泛。然而，共享内存多线程程序在执行时却存在着不确定性。线程在执行时内存竞争频发，是导致多线程程序执行不确定性的主要原因。要实现共享内存多线程程序的确定性重演，最大难点就在于高效实现内存竞争的记录及重演。本文对内存竞争记录的国内外研究现状进行了概括，比较和论述了现有软件实现的内存竞争记录机制和硬件实现的内存竞争记录机制，指出硬件实现的内存竞争记录更具竞争前途，并且分析了当前硬件实现的内存竞争记录在内存竞争日志大小、带宽开销、重演性能及是支持非顺序存储模型4个方面存在的挑战。 　　参考文献： 　　[1]PERONA P， MALIK J. Scale-space and edge detection using anisotropic diffusion [J]. IEEE Transactions on Pattern Analysis and Machine Intelligence， 1990， 12（7）： 629-639.
　　[2]NETZER R H B， MILLER B P. What are race conditions？ some issues and formalizations [J]. Journal ACM Letters on Programming Languages and Systems （LOPLAS）， 1992， 1（1）： 74-88. 　　[3]PAN D Z， LINTON M A. Supporting reverse execution for parallel programs [C]//Proceedings of the 1988 ACM SIGPLAN/SIGOPS Workshop on Parallel and Distributed Debugging， 1988： 124-129. 　　[4]LEBLANC T， MELOR-CRUMMEY J. Debugging parallel programs with instant replay [J]. IEEE Transactions on Computers， 1987， 36（4）： 471-482. 　　[5]DUNLAP G W， LUCCHETTI D G， et al. Execution replay of multiprocessor virtual machines [C]∥ Proceeding VEE’08 Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments， 2008： 121-130. 　　[6]RONSSE M，De BOSSCH-ERE K . RecPlay： a fully integrated practical record/replay system [J]. ACM Transactions on Computer Systems， 1999， 17（2）： 133–152. 　　[7]LAMPORT L. Time， clocks and the ordering of events in a distributed system [J]. Communications of the ACM， 1978， 21（7）： 558–565. 　　[8]RUSSINOVICH M， COGSWELL B. Replay for concurrent non-deterministic shared-memory applications [C]// Proceedings of the ACM SIGPLAN Conference on Programming language Design and Implementation， 6. 　　[9]GEORGES A， CHRISTIAENS M， et al. Jarec： a portable record/replay environment for multi-threaded java applications [J]. Software： Practice and Experience， 2004， 34（6）： 523–547. 　　[10]CHOI J， SRINIVASAN H. Deterministic replay of Java multithreaded applications [J]. Proceedings of the SIGMETRICS Symposium on Parallel and Distributed Tools， . 　　[11]OLSZEWSKI M， ANSEL J， AMARASINGHE S. Kendo： efficient deterministic multithreading in software [C]//Proceedings of the 14th International Conference on Architectural Support for Programming Languages and Operating Systems， . 　　[12]NETZER R H B. Optimal tracing and replay for debugging shared memory parallel programs [C]// Proceedings of the ACM/ONR Workshop on Parallel and Distributed Debugging （PADD）， . 　　[13]PATIL H， PEREIRA C， et al. PinPlay： a framework for deterministic replay and reproducible analysis of parallel programs [C]//Proceeding CGO’10 Proceedings of the 8th annual IEEE/ACM international symposium on Code generation and optimization， . 　　[14]CHI-KEUNG ， COHN L R， et.al. Pin： building customized program analysis tools with dynamic instrumentation [C]//Proceeding PLDI’05 Proceedings of the ACM SIGPLAN conference on Programming language design and implementation， 0.
　　[15]ALTEKAR G， STOICA I. ODR： output-deterministic replay for multicore debugging [C]//Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles， 6. 　　[16]LEED， WESTER B， et.al. Respec： efficient online multiprocessor replay via speculation and external determinism [C]//Proceeding ASPLOS XV Proceedings of the fifteenth edition of ASPLOS on Architectural support for programming languages and operating systems， . 　　[17]PARK S，ZHOU Yuanyuan， et.al. PRES： probabilistic replay with execution sketching on multiprocessors [C]//Proceeding SOSP’09 Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles， 2. 　　[18]VEERARAGHVAN K， LEE Dongyoon， et al. DoublePlay： parallelizing sequential logging and replay [C]//Proceeding ASPLOS XVI Proceedings of the sixteenth international conference on Architectural support for programming languages and operating systems， . 　　[19]BACON D F， GOLDSTEIN S C. Hardware-assisted replay of multiprocessor programs [C]//Proceedings of the ACM/ONR Workshop on Parallel and Distributed Debugging， published in ACM SIGPLAN Notices， 6. 　　[20]PRULOVIC M， TORRELLAS J. ReEnact： using thread-level speculation mechanisms to debug data races in multithreaded codes [C]//Proceedings of the 30th annual international symposium on Computer architecture， May 2003， 31（2）： 110-121. 　　[21]PRVULOVIC M， et al. CORD： cost-effective （and nearly overhead-free） order recording and data race detection [C]//Proceeding of the 12th IEEE symposium on high-performance computer architecture. Feb 2006， 232-243. 　　[22]NARAYNASAMY S， POKAM G， CALDER B. BugNet： recording application level execution for deterministic replay debugging [J]. Micro， IEEE， 2006， 26（1）： 100-109. 　　[23]XU M， BODIK R， HILL M. A flight data recorder for enabling full-system multiprocessor deterministic replay [C]//Proceedings of the International Symposium on Computer Architecture， 5. 　　[24]XU M， BOD’IK R， HILL M D. A regulated transitive reduction （RTR） for longer memory race recording [C]//Proceedings of the International Conference on Architectural Support for Programming Languages and Operating Systems， . 　　[25]HOWER D， HILL M. Rerun： exploiting episodes for lightweight memory race recording [C]//Proceedings of the International Symposium on Computer Architecture， 6. 　　[26]MONTESINOS P， CEZE L， TORRELLAS J. DeLorean： recording and deterministically replaying shared-memory multiprocessor execution efficiently [C]//Proceedings of the International Symposium on Computer Architecture， 0.
　　[27]CEZE L， TUCK J， MONTESINOS P， et al. BulkSC： bulk enforcement of sequential consistency [C]∥ Proc. of the 34th Annual Intnl. Symp. on Computer Architecture， 2007-06： 278-289. 　　[28]LARUS J， RAJWAR R. Transactional Memory[M]. Morgan & Claypool， 2006. 　　[29]POKAM G， PEREIRA C， DANNE K， et al . Architecting a chunk-based memory race recorder in modern CMPs [C]//Proceedings of the International Symposium on Microarchitecture， 5. 　　[30]VOSKUILEN G ， AHMAD F， VIJAYKUMAR T N. Timetraveler： exploiting acyclic races for optimizing memory race recording [C]//Proceedings of the 37th annual international symposium on computer architecture. Jun 9. 　　[31]BASU A， BOBBA J， HILL M D. Karma： scalable deterministic record-replay， University of Wisconsin Computer Sciences technical report CS-TR-， Oct. 2010. 　　[32]NARAYANASAMY S， PEREIRA C， CALDER B. Recording shared memory dependencies using strata [C]//Proceedings of the International Conference on Architectural Support for Programming Languages and Operating Systems， 2006： 229-240. 　　[33]刘磊， 黄河， 唐志敏. 支持多核并行程序确定性重放的高效访存冲突记录方法[J]. 计算机研究与发展， 2012， 49（1）： 64-75. 　　[34]CHEN Yunji， HU Weiwu， WU Ruiyang. LReplay： a pending period based deterministic replay scheme [C]//Proceeding ISCA’10 Proceedings of the 37th annual international symposium on Computer architecture， 2010： 187-197. 　　[35]GAO X， CHEN YJ， WANG HD. System architecture of godson-3 multi-core processors [J]. Journal of computer science and technology， 2010， 25（2）： 181–191. 　　[36]LEEY D， SAIDZ M， NARAYANASAMYY S， YANGZ Z. Offine symbolic analysis to infer total store order [C]∥ High Performance Computer Architecture （HPCA）， 2011 IEEE 17th International Symposium on Date of Conference， - 358. 　　[37]POKAM G， PEREIRA C， et al. CoreRacer： a practical memory race recorder for multicore x86 TSO processors [C]//Proceeding MICRO-44’11 Proceedings of the 44th Annual IEEE/ACM International Symposium on Microarchitecture， 2011： 216-225.
转载请注明来源。原文地址：
【xzbu】郑重声明：本网站资源、信息来源于网络，完全免费共享，仅供学习和研究使用，版权和著作权归原作者所有，如有不愿意被转载的情况，请通知我们删除已转载的信息。
xzbu发布此信息目的在于传播更多信息，与本网站立场无关。xzbu不保证该信息（包括但不限于文字、数据及图表）准确性、真实性、完整性等。