CN105683906B - 用于利用锁省略和锁定的选择进行数据共享的自适应处理 - Google Patents

Abstract

在硬件锁省略(HLE)环境中，提供了预测性地确定HLE事务是否应实际获取锁并且非事务性地执行。包括：基于遇到HLE锁获取指令，基于HLE预测器，确定是省略锁并且作为HLE事务继续还是获取锁并且作为非事务继续；基于HLE预测器预测为省略，将锁的地址设定为事务的读取集，并且抑制锁获取指令对锁的任何写入，并且在HLE事务性执行模式中继续，直到遇到xrelease指令或者HLE事务遇到事务性冲突为止，其中，xrelease指令释放锁；以及基于HLE预测器预测为不省略，将HLE锁获取指令视为非HLE锁获取指令且在非事务性模式中继续。

Description

用于利用锁省略和锁定的选择进行数据共享的自适应处理

技术领域

本公开内容一般涉及事务存储器***，并且更具体地涉及用于通过利用锁省略和锁定的选择自适应地共享数据的方法、计算机程序和计算机***。

背景技术

芯片上的中央处理单元(CPU)核的数量和与共享存储器连接的CPU核的数量不断显著增长，以支持增长的工作负载容量要求。协作以处理相同的工作负载的不断增加的CPU数量对软件可伸缩性造成显著的负担；例如，通过传统的信号量保护的共享队列或数据结构变为热点并且导致子线性n路伸缩曲线。传统地，通过在软件中实现更精细粒度的锁定来应对这一点。实现更精细粒度的锁定以提高软件可伸缩性可能是非常复杂且易于出错的，并且按照当今的CPU频率，硬件互连的延迟时间受限于芯片和***的物理尺寸以及光速。

已引入了硬件事务存储器(HTM，或者在本讨论文本中，简称为TM)的实现，其中，在其它中央处理单元(CPU)和I/O子***看来，一组指令——称为事务——在存储器中的数据结构上以原子的方式操作(在其它文献中，原子操作也称为“块并发”或“串行化”)。事务在不获得锁的情况下乐观地执行，但是，如果在存储器位置上的正在执行的事务的操作与同一存储器位置上的另一操作冲突，那么可能需要中止和重试事务性执行。以前，提出了软件事务存储器实现以支持软件事务存储器(TM)。但是，与软件TM相比，硬件TM可提供改进的性能方面和使用便利性。

在2002年8月28日提交的发明名称为“Method and apparatus for thesynchronization of distributed caches”美国专利申请公开No2004/0044850教导了用于分布缓存同步的方法和装置，该专利申请公开的内容通过引用并入本文。具体而言，给出的实施例涉及缓存存储器***，并且更特别地涉及适于与分布缓存一起使用的分层缓存协议，包含在缓存输入/输出(I/O)集线器内使用。

在1994年3月24日提交的发明名称为“Partial cache line write transactionsin a computing system with a write back cache”的美国专利5586297教导了提出了一种包含存储器、输入/输出适配器和处理器的计算***，该专利的内容通过引用并入本文。处理器包含其中可存储脏数据的写回缓存。当执行从输入/输出适配器到存储器的一致写入时，数据块从输入/输出适配器被写入到存储器内的存储器位置。数据块包含的数据比写回缓存中的全缓存行少。搜索写回缓存以确定写回缓存是否包含该存储器位置的数据。当搜索确定写回缓存包含该存储器位置的数据时，包含该存储器位置的数据的全缓存行被清除。

发明内容

提供一种硬件锁省略(HLE)环境中的用于预测性地确定HLE事务是否应实际获取锁并且非事务性地执行的方法。根据本公开内容的实施例，方法可包括：基于遇到HLE锁获取指令，基于HLE预测器，确定是省略锁并且作为HLE事务继续还是获取锁并且作为非事务继续；基于HLE预测器预测为省略，将锁的地址设定为HLE事务的读取集，并且抑制由锁获取指令对锁的任何写入，并且在HLE事务性执行模式下继续，直到遇到xrelease指令(其中，xrelease指令释放锁)或者HLE事务遇到事务性冲突为止；以及基于HLE预测器预测不省略，将HLE锁获取指令视为非HLE锁获取指令且在非事务性模式中继续。

在本公开内容的另一实施例中，可提供硬件锁省略(HLE)环境中的用于预测性地确定HLE事务是否应实际获取锁并且非事务性地执行的计算机程序产品。该计算机程序产品可包含：可通过处理电路读取并且存储供处理电路执行以用于执行包括以下步骤的方法的指令的计算机可读存储介质：基于遇到HLE锁获取指令，基于HLE预测器，确定是省略锁并且作为HLE事务继续还是获取锁并且作为非事务继续；基于HLE预测器预测为省略，将锁的地址设定为事务的读取集，并且抑制由锁获取指令对锁的任何写入，并且在HLE事务性执行模式中继续，直到遇到xrelease指令(其中，xrelease指令释放锁)或者HLE事务遇到事务性冲突为止；以及基于HLE预测器预测不省略，将HLE锁获取指令视为非HLE锁获取指令且在非事务性模式中继续。

在本公开内容的另一实施例中，提供硬件锁省略(HLE)环境中的用于预测性地确定HLE事务是否应实际获取锁并且非事务性地执行的计算机***。该计算机***可包含：存储器；和与存储器通信的处理器，其中，计算机***被配置为执行包括以下步骤的方法：基于遇到HLE锁获取指令，基于HLE预测器，确定是省略锁并且作为HLE事务继续还是获取锁并且作为非事务继续；基于HLE预测器预测为省略，将锁的地址设定为事务的读取集，并且抑制由锁获取指令对锁的任何写入，并且在HLE事务性执行模式中继续，直到遇到xrelease指令(其中，xrelease指令释放锁)或者HLE事务遇到事务性冲突为止；以及基于HLE预测器预测为不省略，将HLE锁获取指令视为非HLE锁获取指令且在非事务性模式中继续。

附图说明

根据要结合附图阅读的本公开内容的解释性的实施例的以下详细描述，这里公开的实施例的特征和优点将变得明显。附图的各种特征没有按比例，因为示图为了阐明，以有利于本领域技术人员结合具体描述理解本公开内容。在附图中：

图1和图2示出根据本公开内容的实施例的示例多核事务存储器环境；

图3示出根据本公开内容的实施例的示例CPU的示例部件；

图4示出根据示例性硬件或软件实施例的用于利用在锁省略与锁定之间的选择来自适应地共享数据的方法的流程图；

图5示出在存在HLE支持的环境中实现也称为HLE预测器或硬件锁虚拟器的冲突预测器的流程图；

图6示出根据不存在附加的硬件能力的示例性实施例的用于通过利用在锁省略与锁定之间的选择来自适应地共享数据的方法的流程图；

图7示出根据具有硬件锁监视的示例性实施例的用于通过利用在锁省略与锁定之间的选择来自适应地共享数据的方法的流程图；

图8～9示出自适应地共享数据的示例性流程；和

图10是根据图4～7的方法的至少一个示例性实施例的计算机环境的硬件和软件的示意性框图。

具体实施方式

在历史上，计算机***或处理器仅具有单个处理器(aka处理单元或中央处理单元)。处理器包含指令处理单元(IPU)、分支单元和存储器控制单元等。这种处理器能够一次执行程序的单个线程。开发了操作***，该操作***可通过分配程序在处理器上执行一时间周期，并然后分配另一程序在处理器上执行另一时间周期来时间共享服务器。随着技术演变，常常向处理器以及包含转换后援缓冲器(TLB)的复杂动态地址转换添加存储器子***缓存。IPU自身常被称为处理器。随着技术继续发展，整个处理器可被封装为单个半导体芯片或裸片，这种处理器被称为微处理器。然后，开发了加入多个IPU的处理器，这种处理器也常被称为多处理器。多处理器计算机***(处理器)的每个这种处理器可包含单独的或共享的缓存、存储器接口、***总线和地址转换机构等。虚拟机和指令集体系架构(ISA)仿真器向处理器添加软件层，这通过时间切片使用单个硬件处理器中的单个IPU来向虚拟机提供多个“虚拟处理器”(aka处理器)。随着技术进一步发展，开发了多线程处理器，从而使得具有单个多线程IPU的单个硬件处理器能够提供同时执行不同程序的线程的能力，由此，多线程处理器的各线程对操作***表现为处理器。随着技术进一步发展，能够在单个半导体芯片或裸片上放置多个处理器(每个具有IPU)。这些处理器被称为处理器核或者仅仅被称为核。因此，例如，诸如处理器、中央处理单元、处理单元、多处理器核、核、处理器核、处理器线程和线程的术语常被交换使用。在不背离本文的教导的情况下，可通过包含上述的那些的任何或所有处理器来实施本文的实施例的多个方面。其中，在本文使用术语“线程”或“处理器线程”，期望可在处理器线程实现中具有实施例的特定优点。

基于的实施例中的事务性执行

在通过引用整体并入本文的“ Architecture Instruction SetExtensions Programming Reference”319433-012A,February 2012中，第8章部分地教导多线程应用可利用越来越多的CPU核实现更高的性能。但是，多线程应用的写入要求程序员理解并且考虑多个线程之中的数据共享。对共享数据的访问一般需要同步机制。常常通过使用由锁保护的关键区段，这些同步机制被用于确保多个线程通过施加到共享数据上的串行化操作来更新共享数据。由于串行化限制并发性，因此，程序员尝试限制由于同步导致的开销。

事务性同步扩展( TSX)允许处理器动态确定是否需要通过锁保护的关键区段来串行化线程并且仅当需要时执行该串行化。这允许处理器暴露和利用由于在动态上不必要的同步而隐藏于应用中的并发性。

利用 TSX，事务性地执行程序员规定的代码区域(也称为“事务性区域”或仅仅称为“事务”)。如果成功完成事务性执行，那么，当从其它处理器观看时，在事务性区域内执行的所有存储器操作将看起来瞬时出现。只有当出现成功的提交时，即，当事务成功完成执行时，处理器使被执行事务的在事务性区域内被执行的存储器操作对其它处理器可见。该处理也常被称为原子提交。

TSX提供两个软件接口以规定用于事务性执行的代码区域。硬件锁省略(HLE)是规定事务性区域的传统兼容指令集扩展(包含XACQUIRE和XRELEASE前缀)。受约束的事务存储器(RTM)是程序员用于以可能比HLE更灵活的方式限定事务性区域的新指令集接口(包含XBEGIN、XEND和XABORT指令)。HLE用于偏好常规的互斥编程模型的向后兼容性并且愿意在传统硬件上运行HLE启用软件并且还愿意在具有HLE支持的硬件上利用新锁省略能力的程序员。RTM用于偏好事务性执行硬件的灵活接口的程序员。另外， TSX还提供XTEST指令。该指令允许软件询问逻辑处理器是否正在由HLE或RTM识别的事务性区域内事务性地执行。

由于成功的事务性执行确保原子提交，因此，处理器在没有明确的同步的情况下乐观地执行代码区域。如果对特定执行来说同步是不必要的，那么执行可在没有任何跨线程串行化的情况下提交。如果处理器不能原子地提交，那么乐观执行失败。当这种情况发生时，处理器将回滚(roll back)该执行，这是称为事务性中止的处理。在事务性中止时，处理器将舍弃在由事务使用的存储器区域中执行的所有更新，将体系结构状态恢复到看起来似乎没有出现过乐观的执行，并且以非事务的方式重新开始执行。

处理器可出于许多原因执行事务性中止。中止事务的主要原因是由于事务性地执行的逻辑处理器与另一逻辑处理器之间的冲突存储器访问。这种冲突存储器访问会妨碍成功的事务性执行。从事务性区域内读取的存储器地址构成事务性区域的读取集，并且写入到事务性区域内的地址构成事务性区域的写入集。 TSX以缓存线的粒度保持读取集和写入集。如果另一逻辑处理器读取一位置(该位置是事务性区域的写入集的一部分)或者写入一位置(该位置是事务性区域的读取集或写入集的一部分)，则会出现冲突存储器访问。冲突访问一般意味着需要对该代码区域的串行化。由于 TSX以缓存线的粒度检测数据冲突，那么放在同一缓存线中的无关数据位置将被检测为冲突，这导致事务性中止。事务性中止也可能由于事务资源有限而出现。例如，在区域中被访问的数据的量可能超过特定于实现方式的容量。另外，一些指令和***事件会导致事务性中止。频繁的事务性中止导致循环浪费和效率更加低下。

硬件锁省略

硬件锁省略(HLE)提供供程序员使用事务性执行的传统兼容指令集接口。HLE提供两个新的指令前缀提示：XACQUIRE和XRELEASE。

利用HLE，程序员向用于获取保护关键区段的锁的指令的前面添加XACQUIRE前缀。处理器将该前缀视为省略与锁获取操作相关的写入的提示。尽管锁获取具有对锁的相关联的写入操作，但处理器不向事务性区域的写入集添加锁的地址，也不向锁发出任何写入请求。而是，锁的地址被添加到读取集。逻辑处理器进入事务性执行。如果锁在以XACQUIRE为前缀的指令之前是可用的，那么所有其它处理器将继续将锁视为在之后是可用的。由于事务性执行逻辑处理器既不向其写入集添加锁的地址，也不对锁执行外部可见的写入操作，因此，其它逻辑处理器可在不导致数据冲突的情况下读取锁。这允许其它逻辑处理器也进入并且并发地执行由锁保护的关键区段。处理器自动检测在事务性执行期间出现的任何数据冲突，并且如果必要的话，将执行事务性中止。

尽管省略处理器不对锁执行任何外部写入操作，但硬件确保对锁的操作的程序次序。如果省略处理器自身读取关键区段中的锁的值，那么将看起来如同处理器已获取锁，即该读取将返回非省略的值。该行为允许HLE执行在功能上等同于没有HLE前缀的执行。

可在用于释放保护关键区段的锁的指令前面添加XRELEASE前缀。释放锁包含对锁的写入。如果指令是将锁的值恢复到锁在同一锁上的以XACQUIRE为前缀的锁获取操作之前具有的值，那么处理器省略与锁的释放相关联的外部写入请求，并且不向写入集添加锁的地址。处理器然后尝试提交事务性执行。

通过HLE，如果多个线程执行由同一锁保护的关键区段但它们不在彼此的数据上执行任何冲突操作，那么线程可并发地、在没有串行化的情况下执行。尽管软件在共用的锁上使用锁获取操作，但硬件识别这一点、省略锁并且在不需要任何通过锁的通信的情况下在两个线程上执行关键区段——如果这种通信在动态上是不必要的。

如果处理器不能事务性地执行区域，那么处理器将非事务性地并且没有省略地执行区域。HLE启用软件具有与下层的基于非HLE锁的执行相同的前向进展保证。为了成功的HLE执行，锁和关键区段代码必须遵循某些指导方针。这些指导方针仅影响性能；并且不遵循这些指导方针将不会导致功能失败。没有HLE支持的硬件将忽略XACQUIRE和XRELEASE前缀提示，并且将不执行任何省略，原因是这些前缀与在XACQUIRE和XRELEASE有效的指令上被忽略的REPNE/REPE IA-32前缀对应。重要的是，HLE与基于现有锁的编程模型兼容。不适当地使用提示不会导致功能漏洞，但它可暴露已经在代码中的延迟漏洞。

受约束的事务存储器(RTM)对事务性执行提供灵活的软件接口。RTM提供三个新的指令——XBEGIN、XEND和XABORT——供程序员开始、提交和中止事务性执行。

程序员使用XBEGIN指令规定事务性代码区域的开始并且使用XEND指令规定事务性代码区域的结束。如果RTM区域不能事务性地被成功执行，那么XBEGIN指令取得提供到回退指令地址的相对偏移的操作数。

处理器可能出于许多原因中止RTM事务性执行。在许多情况下，硬件自动检测事务性中止条件并且从回退指令地址重新开始执行，其中体系结构状态与存在于XBEGIN指令的开始处的体系结构状态对应，并且EAX寄存器被更新为描述中止状态。

XABORT指令允许程序员明确地中止RTM区域的执行。XABORT指令取得加载到EAX寄存器中并且由此对RTM中止之后的软件可用的8位直接自变量。RTM指令不具有与它们相关联的任何数据存储器位置。虽然硬件不关于RTM区域是否曾经成功事务性地提交提供保证，但遵循推荐的指导方针的大多数事务有望成功事务性地提交。但是，程序员必须总是在回滚路径中提供替代性的代码序列以保证前向进展。这可能与获取锁并且非事务性地执行规定代码区域一样简单。并且，总是在给定的实现方式上中止的事务可在将来的实现方式上事务性地完成。因此，程序员必须保证用于事务性区域的代码路径和替代性的代码序列被成功测试。

HLE支持的检测

如果CPUID.07H.EBX.HLE[位4]＝1，那么处理器支持HLE执行。但是，应用可在不检查处理器是否支持HLE的情况下使用HLE前缀(XACQUIRE和XRELEASE)。没有HLE支持的处理器忽略这些前缀并且将在不进入事务性执行的情况下执行代码。

RTM支持的检测

如果CPUID.07H.EBX.RTM[位11]＝1，那么处理器支持RTM执行。应用必须在处理器使用RTM指令(XBEGIN、XEND、XABORT)之前检查处理器是否支持RTM。这些指令当在不支持RTM的处理器上被使用时将产生#UD异常。

XTEST指令的检测

如果处理器支持HLE或RTM，那么处理器就支持XTEST指令。应用必须在使用XTEST指令之前检查这些特征标记中的任一个。该指令当在不支持HLE或RTM的处理器上被使用时将产生#UD异常。

询问事务性执行状态

XTEST指令可被用于确定由HLE或RTM规定的事务性区域的事务状态。注意，虽然HLE前缀在不支持HLE的处理器上被忽略，但XTEST指令当在不支持HLE或RTM的处理器上被使用时将产生#UD异常。

对HLE锁的要求

对于成功事务性地提交的HLE执行，锁必须满足某些特性并且对锁的访问必须遵循某些指导方针。

以XRELEASE为前缀的指令必须将被省略的锁的值恢复到它在锁获取之前具有的值。这允许硬件通过不向写入集添加锁来安全地省略这些锁。锁释放(以XRELEASE为前缀)指令的数据尺寸和数据地址必须匹配锁获取(以XACQUIRE为前缀)的数据尺寸和数据地址，并且锁不得与缓存线边界相交。

软件不应通过除以XRELEASE为前缀的指令以外的任何指令写入到事务性HLE区域内的被省略的锁，否则这种写入会导致事务性中止。另外，递归锁(线程多次获取同一锁，而不是先释放锁)也会导致事务性中止。注意，软件可观察在关键区段内获取的被省略的锁的结果。这种读取操作将向锁返回写入的值。

处理器自动检测对这些指针方针的违反，并且安全地过渡到没有省略的非事务性执行。由于 TSX在缓存线上的粒度上检测冲突，因此，对与被省略的锁共同位于相同的缓存线上的数据的写入可被省略同一锁的其它逻辑处理器检测为数据冲突。

事务嵌套

HLE和RTM二者都支持嵌套事务性区域。但是，事务性中止将状态恢复到开始事务性执行的操作：最外的以XACQUIRE为前缀的HLE合法指令或最外的XBEGIN指令。处理器将所有嵌套的事务视为一个事务。

HLE嵌套和省略

程序员可嵌套HLE区域，直到MAX_HLE_NEST_COUNT的特定于实现方式的深度为止。各逻辑处理器在内部跟踪嵌套计数，但该计数对软件是不可用的。以XACQUIRE为前缀的HLE合法指令递增嵌套计数，并且以XRELEASE为前缀的HLE合法指令递减它。逻辑处理器在嵌套计数从0变为1时进入事务性执行。仅当嵌套计数变为0时，逻辑处理器尝试提交。如果嵌套计数超过MAX_HLE_NEST_COUNT，那么事务性中止可出现。

除了支持嵌套的HLE区域以外，处理器也可省略多个嵌套锁。处理器跟踪锁，以用于以对于该锁的以XACQUIRE为前缀的HLE合法指令开始并且以对于同一锁的以XRELEASE为前缀的HLE合法指令结束的省略。处理器可在任何一个时间跟踪高达MAX_HLE_ELIDED_LOCKS数量的锁。例如，如果实现方式支持为2的MAX_HLE_ELIDED_LOCKS值并且如果程序员嵌套三个HLE识别的关键区段(通过在三个相异的锁上执行以XACQUIRE为前缀的HLE合法指令，而不在锁中的任一个上执行介入的以XRELEASE为前缀的HLE合法指令)，那么前两个锁将被省略，但第三个不会被省略(而将被添加到事务写入集)。但是，执行仍将事务性地继续。一旦遇到用于两个被省略的锁中的一个的XRELEASE，那么通过以XACQUIRE为前缀的HLE合法指令获取的随后的锁将被省略。

当所有被省略的XACQUIRE和XRELEASE对已经匹配、嵌套计数变为0且锁满足要求时，处理器尝试提交HLE执行。如果执行不能原子地提交，那么执行在没有省略的情况下过渡到非事务性执行，如同第一指令不具有XACQUIRE前缀。

RTM嵌套

程序员可嵌套RTM区域，直到特定于实现方式的MAX_RTM_NEST_COUNT为止。逻辑处理器在内部跟踪嵌套计数，但该计数对软件不可用。XBEGIN指令递增嵌套计数，并且，XEND指令递减嵌套计数。只有嵌套计数变为0，逻辑处理器才尝试提交。如果嵌套计数超过MAX_RTM_NEST_COUNT，那么出现事务性中止。

嵌套HLE和RTM

HLE和RTM对共用事务性执行能力提供两种替代性软件接口。当HLE和RTM被嵌套在一起时，例如，当HLE处于RTM内或者RTM处于HLE内时，事务性处理行为是特定于实现方式的。但是，在所有情况下，实现方式将保持HLE和RTM语义。实现方式可当在RTM区域内被使用时选择忽略HLE提示，并且，当RTM指令在HLE区域内被使用时，可导致事务性中止。在后一种情况下，无缝地出现从事务性执行到非事务性执行的过渡，原因是处理器将在不实际进行省略的情况下重新执行HLE区域，并然后执行RTM指令。

中止状态定义

RTM使用EAX寄存器以将中止状态传送到软件。在RTM中止之后，EAX寄存器具有以下的定义。

表1

RTM的EAX中止状态仅提供中止的原因。它不通过自身对是否对RTM区域出现中止或提交进行编码。EAX的值可在RTM中止之后为0。例如，当在RTM区域内时使用的CPUID指令导致事务性中止，并且不能满足用于设定EAX位中的任一个的要求。这会导致EAX值为0。

RTM存储器排序

成功的RTM提交导致RTM区域中的所有存储器操作看起来原子地执行。包含后跟XEND的XBEGIN的成功提交RTM区域，甚至在RTM区域中没有存储器操作时，具有与以LOCK为前缀的指令相同的排序语义。

XBEGIN指令不具有防护(fencing)语义。但是，如果RTM执行中止，那么来自RTM区域内的所有存储器更新被舍弃并且不对任何其它逻辑处理器可见。

RTM启用调试器支持

缺省地，RTM区域内的任何调试异常将导致事务性中止，并且将使得控制流程重定向到回退指令地址，同时体系结构状态被恢复并且EAX中的位4被设定。但是，为了允许软件调试器拦截调试异常上的执行，RTM体系结构提供附加的能力。

如果DR7的位11和IA32_DEBUGCTL_MSR的位15均为1且由于调试异常(#DB)或断点异常(#BP)导致的任何RTM中止导致执行回滚并且从XBEGIN指令而不是回退地址重新开始。在该方案中，EAX寄存器也将被恢复到XBEGIN指令的点。

编程考虑

一般的程序员识别区域有望成功地事务性执行和提交。但是， TSX不提供任何这种保证。事务性执行可出于许多原因中止。为了充分利用事务能力，程序员应遵循某些指导方针以增加其事务性执行成功提交的概率。

本节讨论可导致事务性中止的各种事件。体系结构确保在随后中止执行的事务内执行的更新将决不会变得可见。仅有提交的事务性执行启动对体系结构状态的更新。事务性中止从不导致功能失败并且仅影响性能。

基于指令的考虑

程序员可在事务(HLE或RTM)内安全地使用任何指令并且可在任何特权水平上使用事务。但是，一些指令将总是中止事务性执行并且导致执行无缝且安全地过渡到非事务性路径。

TSX允许大多数共用指令在不导致中止的情况下被用于事务内。事务内的以下操作一般不导致中止：

·指令指针寄存器、通用寄存器(GPR)和状态标记(CF、OF、SF、PF、AF和ZF)上的操作；和

·XMM和YMM寄存器和MXCSR寄存器上的操作。

但是，当在事务性区域内混合SSE和AVX操作时，程序员必须仔细。混合访问XMM寄存器的SSE指令和访问YMM寄存器的AVX指令会导致事务中止。程序员可使用事务内的以REP/REPNE为前缀的串操作。但是，长串会导致中止。并且，如果CLD和STD指令的使用改变DF标记的值的话，则CLD和STD指令的使用会导致中止。但是，如果DF为1，那么STD指令将不导致中止。类似，如果DF为0，那么CLD指令将不导致中止。

因为当在事务内使用时导致中止而没有在这里列举的指令一般不导致事务中止(示例包含但不限于MFENCE、LFENCE、SFENCE、RDTSC、RDTSCP等)。

以下的指令将不在任何实现方式上中止事务性执行：

·XABORT

·CPUID

·PAUSE

另外，在一些实现方式中，以下的指令会总是导致事务性中止。不期望这些指令常用于一般的事务性区域内。但是，程序员不得依赖于这些指令以强制事务性中止，因为它们是否导致事务性中止是依赖于实现方式的。

·X87和MMX体系结构状态上的操作。这包括所有MMX和X87指令，包含FXRSTOR和FXSAVE指令。

·对EFLAGS的非状态部分CLI、STI、POPFD、POPFQ、CLTS的更新。

·更新区段寄存器、调试寄存器和/或控制寄存器的指令：MOV to DS/ES/FS/GS/SS、POP DS/ES/FS/GS/SS、LDS、LES、LFS、LGS、LSS、SWAPGS、WRFSBASE、WRGSBASE、LGDT、SGDT、LIDT、SIDT、LLDT、SLDT、LTR、STR、Far CALL、Far JMP、Far RET、IRET、MOV to DRx、MOV toCR0/CR2/CR3/CR4/CR8和LMSW。

·环过渡:SYSENTER、SYSCALL、SYSEXIT和SYSRET。

·TLB和可缓存性控制：CLFLUSH、INVD、WBINVD、INVLPG、INVPCID和具有非时间提示的存储器指令(MOVNTDQA、MOVNTDQ、MOVNTI、MOVNTPD、MOVNTPS和MOVNTQ)。

·处理器状态保存:XSAVE、XSAVEOPT和XRSTOR。

·中断：INTn、INTO。

·IO:IN、INS、REP INS、OUT、OUTS、REP OUTS和它们的变量。

·VMX：VMPTRLD、VMPTRST、VMCLEAR、VMREAD、VMWRITE、VMCALL、VMLAUNCH、VMRESUME、VMXOFF、VMXON、INVEPT和INVVPID。

·SMX：GETSEC。

·UD2、RSM、RDMSR、WRMSR、HLT、MONITOR、MWAIT、XSETBV、VZEROUPPER、MASKMOVQ和V/MASKMOVDQU。

运行时考虑

除了基于指令的考虑以外，运行时事件可导致事务性执行中止。它们可能是由于数据访问模式或微体系结构实现方式特征。以下的列表不是所有中止原因的综合讨论。

事务中的必须暴露给软件的任何故障或陷阱将被抑制。事务性执行将中止并且执行将过渡到非事务性执行，如同故障或陷阱没有出现过。如果异常没有被掩盖，那么未掩盖的异常将导致事务性中止并且状态将表现为如同异常没有出现过。

在事务性执行期间出现的同步异常事件(#DE、#OF、#NP、#SS、#GP、#BR、#UD、#AC、#XF、#PF、#NM、#TS、#MF、#DB、#BP/INT3)可导致执行不事务性地提交，并且需要非事务性执行。这些事件被抑制，如同它们没有出现过。在HLE的情况下，由于非事务代码路径与事务代码路径相同，因此，当导致异常的指令非事务性地被重新执行时，这些事件一般重新出现，从而导致在非事务性执行中适当地传递相关联的同步事件。在事务性执行期间出现的同步事件(NMI、SMI、INTR、IPI、PMI等)可导致事务性执行中止并且过渡到非事务性执行。同步事件将未决(pended)并且将在事务性中止被处理之后被处理。

事务仅支持写回可缓存存储器类型操作。如果事务包含任何其它存储器类型上的操作，那么事务会总是中止。这包括对UC存储器类型的指令获取。

事务性区域内的存储器访问可要求处理器设定基准页表条目的访问和脏标记。处理器如何处理它的行为是特定于实现方式的。一些实现方式可允许对这些标记的更新即便事务性区域随后中止也变得外部可见。一些 TSX实现方式可选择在这些标记需要被更新时中止事务性执行。并且，处理器的页表运行(walk)可产生对其自己的事务性写入但未提交的状态的访问。一些 TSX实现方式可选择在这种情况下中止事务性区域的执行。不管怎样，该体系结构确保，如果事务性区域中止，则将不通过诸如HLE的结构的行为使得事务性写入的状态在体系结构上可见。

事务性执行自修改代码也可导致事务性中止。即使当使用HLE和RTM时，程序员也必须继续遵循用于写入自修改和互修改代码的Intel推荐指导方针。虽然RTM和HLE的实现方式一般将提供用于执行共用事务性区域的足够资源，但事务性区域的实现方式约束和过大尺寸会导致事务性执行中止并且过渡到非事务性执行。体系结构不保证可用于进行事务性执行的资源量并且不保证事务性执行将成功。

对在事务性区域内访问的缓存线的冲突请求可阻止事务成功执行。例如，如果逻辑处理器P0读取事务性区域中的线A且另一逻辑处理器P1写入线A(处于事务性区域内或者外)，那么如果逻辑处理器P1的写入干扰处理器P0事务性执行的能力，则逻辑处理器P0会中止。

类似地，如果P0写入事务性区域中的线A且P1读取或写入线A(处于事务性区域内或者外)，那么如果P1对线A的访问干扰P0事务性执行的能力，则P0会中止。另外，其它相干通信量会间或表现为冲突请求并且会导致中止。虽然会发生这些错误冲突，但它们有望不常见。在以上的方案中用于确定P0或P1是否中止的冲突解决策略是特定于实现方式的。

通用事务性执行实施例：

根据Austen McDonald在2009年6月在部分地完成哲学博士学位要求时提交给斯坦福大学计算机科学系和研究生委员会的论文“ARCHITECTURES FOR TRANSACTIONALMEMORY”，存在实现原子和隔离的事务性区域所需要的三种机制：版本控制、冲突检测和竞争管理，在这里通过引用加入该论文的全部内容。

为了使得事务性代码区域看起来原子性，由该事务性代码区域执行的所有修改必须被存储并且保持与其它事务隔离，直到提交时间为止。***通过实现版本控制策略完成这一点。存在两个版本控制样式：渴望和懒惰。渴望版本控制***将新产生的事务性值存储到位并且将先前的存储器值存储器于边上，在所谓撤消日志中。懒惰版本控制***暂时存储新值在所谓的写入缓冲器中，仅在提交时将它们拷贝到存储器。在任一***中，缓存被用于优化新版本的存储。

为了确保事务看起来被原子地执行，冲突必须被检测和解决。这两个***，即渴望和懒惰版本控制***，通过实现乐观或悲观的冲突检测策略来检测冲突。乐观***并行执行事务，仅在事务提交时检查冲突。悲观***在每个加载并存储处检查冲突。与版本控制类似，冲突检测也使用缓存，从而将各线标示为读取集的一部分或者写入集的一部分或者这两者。这两个***通过实现竞争管理策略解决冲突。存在许多竞争管理策略，一些更适合于乐观冲突检测并且一些更适合于悲观冲突检测。下面描述一些示例策略。

由于各事务存储器(TM)***需要版本控制检测和冲突检测，因此这些选项会产生四种不同的TM设计：渴望悲观(EP)、渴望乐观(EO)、懒惰悲观(LP)和懒惰乐观(LO)。表2简要地描述所有四个不同的TM设计。

图1和2示出多核TM环境的示例。图1示出在互连控制120a、120b的管理下与互连122连接的一个裸片100上的许多TM启用CPU(CPU1 114a和CPU2 114b等)。各CPU 114a、114b(也称为处理器)可具有分离的缓存，该分离的缓存包含用于缓存要执行的来自存储器的指令的指令缓存116a、116b和具有用于缓存要由CPU 114a、114b操作的存储器位置的数据(操作数)的TM支持的数据缓存118a、118b。在实现方式中，多个裸片100的缓存被互连以支持多个裸片100的缓存之间的缓存相干性。在实现方式中，使用单个缓存而不是分离的缓存来保持指令和数据二者。在实现方式中，CPU缓存是在层级缓存结构中的一个级别的缓存。例如，各裸片100可使用在裸片100上的所有CPU 114a、114b之中共享的共享缓存124。在另一实现方式中，各裸片100可访问在所有裸片100的所有处理器之中共享的共享缓存124。

图2表示示例事务性CPU 114的细节，包含支持TM的添加。事务性CPU 114(处理器)可包含用于支持寄存器检查点126和特殊TM寄存器128的硬件。事务性CPU缓存可具有常规缓存的MESI位130、标签140和数据142，但是也具有例如，表示在执行事务的同时线被CPU114读取的R位132以及表示在执行事务的同时线被CPU 114写入的W位138。

在任何TM***中对程序员而言的关键细节是，非事务性访问如何与事务进行交互。通过设计，使用以上的机制相互筛选事务性访问。但是，仍必须考虑规则、非事务性加载与包含该地址的新值的事务之间的交互。另外，也必须探讨非事务性存储与已经读取该地址的事务之间的交互。这些是数据库概念隔离的问题。

当每个非事务性加载并存储表现为类似于原子事务时，TM***被认为实现强隔离，有时也被称为强原子性。因此，非事务性加载不能看到未提交的数据并且非事务性存储在已读取该地址的任何事务中导致原子性违反。不是这种情况的***被认为实现弱隔离，有时也被称为弱原子性。

强隔离往往比弱隔离更为理想，原因是强隔离相对容易概念化和实现。此外，如果程序员已经忘记用事务围绕一些共享的存储器基准从而导致漏洞，那么通过强隔离，程序员将常常使用简单的调试接口检测该疏忽，因为程序员将看到引起原子性违反的非事务性区域。此外，在一个模型中写入的程序可能在另一模型上以不同的方式工作。

并且，与弱隔离相比，强隔离往往更容易硬件内TM。利用强隔离，由于相干协议已经管理处理器之间的加载并存储传送，因此事务可以检测到非事务性加载并存储，并采取适当的行动。为了在软件事务存储器(TM)中实现强隔离，非事务性代码必须被修改，以包括读障碍和写障碍；从而潜在地削弱性能。尽管已付出巨大的努力以去除许多不需要的障碍，但这种技术往往是复杂的并且性能一般远低于HTM的性能。

表2

表2示出事务存储器(版本控制和冲突检测)的基本设计空间。

渴望-悲观(EP)

以下描述的该第一TM设计被称为渴望-悲观。EP***将其写入集中存储“到位”(因此得名“渴望”)，并且在“撤消日志”中存储重写线的旧值以支持回滚。处理器使用W 138和R132缓存位，以跟踪读取集和写入集，并在接收窃听加载请求时检测冲突。已知文献中的EP***的最值得注意的示例可能是LogTM和UTM。

在EP***中开始事务很像开始其他***中的事务：tm_begin()取得寄存器检查点，并初始化任何状态寄存器。EP***也需要初始化撤消日志，其细节取决于日志格式，但常包含将日志基本指针初始化到预分配的区域、线程专用存储器并且清除日志边界寄存器。

版本控制：在EP中，由于渴望版本控制被设计为起作用的方式，MESI 130状态过渡(与修改、独占、共享和无效代码状态对应的缓存线指示器)保持大部分不变。在事务之外，MESI 130状态过渡保持完全不变。当读取事务内的线时，标准相干过渡适用(S(共享)→S，I(无效)→S或I→E(独占))，根据需要发出记载错失，但R位132也被设定。类似地，写入线施加标准过渡(S→M，E→I，I→M)，根据需要发出错失，但也设定W(写入)位138。当线被第一次写入时，整个线的旧版本被加载并然后被写入到撤销日志以在万一当前事务中止时保留它。在旧数据上，新写入的数据然后被存储“到位”。

冲突检测：悲观冲突检测使用关于错失、升级被交换的相干消息，以寻找事务之间的冲突。当在事务内出现读取错失时，其它处理器接收加载请求；但是，如果它们不具有所需要的线，则它们忽略请求。如果其它处理器非推测性地具有所需要的线或者具有线R 132(读取)，那么它们将线降级到S，并且在某些情况下，如果它们具有MESI的M或E状态中的线，则发出缓存到缓存传送。但是，如果缓存具有线W 138，则在两个事务之间检测到冲突，并且必须采取附加的行动。

类似地，当(在第一写入时)事务寻求将线从共享升级到修改时，事务发出也用于检测冲突的独占加载请求。如果接收的缓存非推测性地具有线，那么该线被无效，并且，在某些情况下，发出缓存到缓存传送(M或E状态)。但是，如果线是R 132或W 138，则检测到冲突。

验证：由于仅在每个加载时执行冲突检测，因此事务总是具有对其自身的写入集的独占访问。因此，验证不要求任何额外的工作。

提交：由于渴望版本控制将数据项的新版本存储到位，因此提交过程简单地清除W138和R 132位并舍弃撤消日志。

中止：当事务回滚时，撤消日志中的各缓存线的原始版本必须被恢复，这是称为“展开”或“应用”日志的过程。这在tm_discard()期间完成，并且必须相对于其他事务是原子性的。具体来说，写入集必须仍然用于检测冲突：该事务仅在其撤消日志中具有线的正确版本，并且，请求事务必须等待从该日志恢复正确的版本。可通过使用硬件状态机或软件中止处理器施加这种日志。

渴望-悲观具有这样的特性：提交是简单的，并且，因为它到位，因此速度非常快。类似地，验证是空操作。悲观冲突检测很早地检测冲突，由此减少“注定失败”事务的数量。例如，如果两个事务涉及到写后读依赖性中，则该依赖性在悲观冲突检测中立即被检测。但是，在乐观冲突检测中，这种冲突在写入者提交之前不被检测到。

渴望-悲观还具有这样的特性：如上所述，在缓存线被第一次写入时，旧值必须被写入到日志，从而产生额外的缓存访问。中止是昂贵的，原因是它们需要撤消日志。对于日志中的各缓存线，必须发出加载，可能在继续到下一线之前远至主存储器。悲观冲突检测也防止存在某些可串行化的调度。

另外，由于冲突在它们出现时被处理，因此，存在活锁的可能性，并且，必须使用小心的竞争管理机制以保证前向进展。

懒惰-乐观(LO)

另一种流行的TM设计是懒惰-乐观(LO)，它在“写入缓冲器”或“重做日志”中存储其写入集并且在提交时间检测冲突(仍使用R和W位)。

版本控制：正如在EP***中一样，LO设计的MESI协议在事务外面被强制实施。一旦处于事务内，读取线就引起标准MESI过渡，但也设定R位132。类似地，写入线设定线的W位138，但是处理LO设计的MESI过渡与EP设计不同。首先，通过懒惰版本控制，写入数据的新版本被存储在缓存层次结构中，直到提交为止，而其他事务能够访问在存储器或其它缓存中可用的旧版本。为了使得旧版本可用，必须在首先通过事务读取时逐出脏线(M线)。其次，由于乐观冲突检测特征，因此不需要升级错失：如果事务具有S状态中的线，那么它可简单地写入到线并且将该线升级到M状态，而不与其它的事务传送这些变化，因为冲突检测在提交时间完成。

冲突检测和验证：为了验证事务和检测冲突，LO仅当它准备提交时将推测性修改的线的地址传送到其它事务。在验证时，处理器发送包含写入集中的所有地址的一个潜在大的网络包。数据不被发送，而是留在提交器的缓存中并且被标示为脏(M)。为了在不对标为W的线搜索缓存的情况下构建该包，使用称为“存储缓冲器”的简单的位矢量，其中每个缓存线的一个位跟踪这些推测性修改的线。其它事务使用该地址包以检测冲突：如果在缓存中找到地址并且设定R 132和/或W 138位，那么冲突被初始化。如果找到线但没有设定R132和W 138，那么线被简单地无效化，这与处理独占加载类似。

为了支持事务原子性，这些地址包必须被原子地操作，即，没有两个地址包可利用相同的地址一次性存在。在LO***中，可通过在发送地址包之前简单地获取全局提交令牌来实现这一点。但是，可通过首先送出地址包、收集响应、强制实施排序协议(可能首先是最旧事务)来使用二阶段提交方案，并且一次性提交所有响应是令人满意的。

提交：一旦出现验证，提交就不需要特殊的处理：简单地清除W 138位和R 132位以及存储缓冲器。事务的写入已在缓存中被标示为脏，并且这些线的其它缓存的拷贝已经由地址包被无效化。其它处理器可然后通过正常的相干协议访问所提交的数据。

中止：回滚也同样很简单：因为写入集包含于本地缓存内，因此这些线可被无效化，然后清除W 138位和R 132位以及存储缓冲器。存储缓冲器可允许发现W线无效，而不需要搜索缓存。

懒惰-乐观具有这样的特性：中止是非常快的，从而不需要附加的加载或存储，并且仅进行局部变化。可存在比在EP中发现的更多的串行化调度，这允许LO***更积极推测事务是独立的，这可产生更高的性能。最后，冲突的晚期检测可增加向前进展的可能性。

懒惰-乐观还具有这样的特性：验证需要与写入集的尺寸成比例的全局传送时间。由于仅在提交时间检测冲突，因此，注定失败的事务可能会浪费工作。

懒惰-悲观(LP)

懒惰-悲观(LP)表示第三TM设计选项，从而处于EP和LO之间的某处：在写入缓冲器中存储新写入的线，但在每个访问的基础上检测冲突。

版本控制：版本控制与LO的版本控制类似但不相同：读取线设定其R位132，写入线设定其W位138，并且，存储缓冲器被用于跟踪缓存中的W线。并且，正如在LO中那样，脏(M)当首先被事务写入时必须被逐出。但是，由于冲突检测是悲观的，因此加载独占必须在从I，S→M升级事务线时被执行，这与LO不同。

冲突检测：LP的冲突检测的操作与EP的相同：使用相干消息以寻找事务之间的冲突。

验证：如在EP中，悲观冲突检测确保在任何点上运行的事务不与任何其它运行的事务具有冲突，因此验证是空操作。

提交：提交不需要特殊的处理：如在LO中那样，简单地清除W 138位和R 132位和存储缓冲器。

中止：回滚也与LO的回滚类似：简单地通过使用存储缓冲器将写入集无效化并且清除W 138位和R 132位和存储缓冲器。

渴望-乐观(EO)

该LP具有这样的特性：与LO类似，中止非常快。与EP类似，使用悲观冲突检测减少“注定失败”事务的数量。与EP类似，一些串行化调度不被允许，并且，必须在各缓存错失上执行冲突检测。

版本控制和冲突检测的最终组合是渴望-乐观(EO)。EO对HTM***来说可能不是最佳选择：由于新事务性版本被写入到位，因此，其它事务没有选择，而只能在冲突出现时(即，当缓存错失出现时)通知冲突。但是，由于EO等待直到提交时间为止才检测冲突，因此这些事务变成“僵尸”，它们继续执行，浪费资源，但是“注定”要中止。

EO已经被证明在STM中是有用的并且由Bartok-STM和McRT实现。懒惰版本控制STM需要在各读取时检查其写入缓冲器以确保它正在读取最近的值。由于写入缓冲器不是硬件结构，因此它是昂贵的，从而偏好写入到位渴望版本控制。另外，由于对冲突的检查在STM中也是昂贵的，因此乐观冲突检测提供批量执行此操作的优点。

竞争管理

已经在上面描述了一旦***已经决定中止事务时该事务如何回滚；但由于冲突涉及两个事务，因此应中止哪个事务、应该如何初始化该中止以及应在什么时候重新尝试被中止的事务的话题需要探讨。这些是竞争管理(CM)要解决的话题，该竞争管理是事务存储器的关键部件。下面描述关于***如何初始化中止的策略以及管理哪些事务应在冲突中中止的各种成熟方法。

竞争管理策略

竞争管理(CM)策略是确定在冲突中涉及的哪个事务应中止以及应在什么时候重新尝试被中止的事务的机制。例如，情况常常是立即重新尝试中止不导致最佳的性能。相反，使用延迟对被中止的事务的重新尝试的退避机制可产生更好的性能。STM首先着手找到最好的竞争管理策略，并且，以下列举的策略中的许多最初是对STM开发的。

CM策略采取大量的措施以做出决定，包括事务的年龄，读取集和写入集的尺寸、先前中止的数量等。做出这样的决定的措施的组合是无穷无尽，但以下大致按增加的复杂性的次序描述某些组合

为了建立一些专门名称，首先注意在冲突中有两个方面：攻击者和防御者。攻击者是请求访问共享存储器位置的事务。在悲观冲突检测中，攻击者是发出加载或加载独占的事务。在乐观冲突检测中，攻击者是尝试验证的事务。两种情况下的防御者都是接收攻击者的请求的事务。

积极的CM策略立即总是重新尝试攻击者或防御者。在LO中，积极意味着攻击者总是赢，所以积极有时被称为提交者赢。这种策略被用于最早的LO***。在EP的情况下，积极可以为防御者赢或攻击者赢。

重新开始立即经历另一冲突的冲突事务必然浪费工作——即互连带宽回填缓存错失。礼貌CM策略在重新开始冲突之前使用指数退避(但也可使用线性)。为了防止饥饿(即处理不具有由调度器分配给它的资源的情况)，指数退避在某些n次重新尝试之后大大增加事务成功的几率。

冲突解决的另一种方法是，随机中止攻击者或防御者(称为随机化的策略)。这种策略可以与随机退避方案结合，以避免不必要的竞争。

但是，进行选择随机，当选择要中止的事务时，可导致中止已完成“大量工作”的事务，这可能浪费资源。为了避免这种浪费，可在确定要中止哪个事务时考虑在事务上已完成的工作量。工作的一个测量可以是事务的年龄。其它方法包括最老、批量TM、尺寸考量、Karma和Polka。最老是中止冲突中的最年轻事务的简单时间戳方法。批量TM使用该方案。尺寸考量与最老类似，但不是使用事务年龄，而是使用读取/写入词语的数量作为优先级，从而在固定次数的中止之后回到最老。Karma是类似的，使用写入集的尺寸作为优先级。然后回滚在退避固定时间量之后继续。被中止的事务在被中止之后保持它们的优先级(由此称为Karma)。Polka类似于Karma工作，但是，作为退避预定时间量的替代，它每次呈指数地补偿更多。

由于中止浪费工作，因此认为拖延攻击者直到防御者完成其事务为止会导致更好的性能是符合逻辑的。不幸的是，这种简单方案很容易导致死锁。

可以使用死锁避免技术来解决这个问题。贪婪使用两个规则来避免死锁。第一条规则是，如果第一事务T1具有比第二事务T0低的优先级或者如果T1等待另一事务，那么T1在与T0冲突时中止。第二条规则是，如果T1具有比T0高的优先级并且不在等待，那么T0等待直到T0提交、中止或者开始等待为止(在这种情况下，第一条规则适用)。贪婪提供关于用于执行一组事务的时间界限的一些保证。一个EP设计(LogTM)使用类似于贪婪的CM策略以利用保守的死锁避免来实现拖延。

示例MESI相干性规则提供多处理器缓存***的缓存线可驻留的四种可能的状态：M、E、S和I，其被定义如下：

修改(M)：缓存线仅存在于当前缓存中并且是脏的；它已从主存储器中的值被修改。在允许主存储器状态(不再有效)的任何其它读取之前，缓存需要在将来的某些时间将数据写回到主存储器。写回将线变为独占状态。

独占(E)：缓存线仅存在于当前缓存中，但是是干净的；它匹配主存储器。它可在任何时间响应于读取请求而变为共享状态。作为替代方案，它可在写入它时变为修改状态。

共享(S)：指示该缓存线可存储于机器的其它缓存中并且是“干净的”；它匹配主存储器。该线可在任何时间被舍弃(变为无效状态)。

无效(I)：指示该缓存线是无效的(未使用)。

除了MESI相干性位以外或者在MESI相干性位中编码，可对各缓存线提供TM相干性状态指示器(R 132、W 138)。R 132指示器指示已从缓存线的数据中读取当前事务，并且W138指示器指示当前事务已被写入到缓存线的数据。

在TM设计的另一方面中，通过使用事务性存储缓冲器设计***。在2000年3月31日提交并且在这里通过引用加入其全部内容的名称为“Methods and Apparatus forReordering and Renaming Memory References in a Multiprocessor ComputerSystem”的美国专利No.6349361教导用于在至少具有第一和第二处理器的多处理器计算机***中将存储器基准重新排序和重新命名的方法。第一处理器具有第一私有缓存和第一缓冲器，并且第二处理器具有第二私有缓存和第二缓冲器。方法包括对由第一处理器接收的用于存储器数据的多个选通存储请求中的每一个独占地获取通过第一私有缓存包含数据的缓存线和在第一缓冲器中存储数据的步骤。在第一缓冲器从第一处理器接收加载请求以加载特定数据时，特定数据基于加载并存储操作的按次序的序列从存储于第一缓冲器中的数据中被提供给第一处理器。在第一缓存从第二缓存接收对于给定数据的加载请求时，指示错误状况，并且，当对于给定数据的加载请求与存储于第一缓冲器中的数据对应时，处理器中的至少一个的当前状态被复位到更早状态。

一个这种事务存储器设施的主要实现部件是用于保持预事务GR(通用寄存器)内容的事务备份寄存器文件、用于跟踪在事务期间访问的缓存线的缓存目录、用于缓冲存储直到事务结束为止的存储缓存和用于执行各种复杂功能的固件例程。在本部分中，描述详细的实现方式。

IBM zEnterprise EC12企业服务器实施例

IBM zEnterprise EC12企业服务器在事务存储器中引入事务性执行(TX)，并且部分地在可从IEEE计算机协会会议发行服务(CPS)得到、2012年12月1日至5日在加拿大英属哥伦比亚温哥华的MICRO-45上演讲的论文集第25-36页的文章“Transactional MemoryArchitecture and Implementation for IBM System z”中被描述，在这里通过引用加入其全部内容。

表3表示示例事务。不确保从TBEGIN开始的事务曾经用TEND成功完成，因为它们可在每次尝试执行时经历中止条件，例如，由于重复与其它的CPU的冲突。这要求程序支持回退路径以例如通过使用常规的锁定方案来非事务性地执行同一操作。该给编程或软件验证团队带来显著的负担，特别是在不通过可靠的编译器自动产生回退路径的情况下。

表3

为已中止的事务性执行(TX)事务提供回退路径的要求可能是繁重的。在共享数据结构上操作的许多事务有望较短，仅接触几个不同的存储器位置，并且只使用简单的指令。对于那些事务，IBM zEnterprise EC12引入受约束的事务的概念；在正常条件下，CPU 114保证受约束的事务最终成功地结束，即使在不对必要的重试次数给出严格限制的情况下。受约束的事务以TBEGINC指令开始并且以正常的TEND结束。将任务实现为受约束或不受约束的事务一般导致相当可比较的性能，但是受约束的事务通过去除对回退路径的需求来简化软件开发。在由IBM在2012年9月公开的z/Architecture,Principles of Operation,Tenth Edition,SA22-7832-09中进一步描述了IBM的事务性执行架构，在这里通过引用加入其全部内容。

受约束的事务以TBEGINC指令开始。以TBEGINC启动的事务必须遵循一系列的编程约束；否则程序采取不可过滤的约束违反中断。示例性约束可包括但不限于：事务可以执行最多32个指令，所有的指令文本必须在存储器的256个连续字节内；事务只包含指向前的相对分支(即没有循环和子例程调用)；事务可以访问最多4个对齐的八字(八字(octoword)为32字节)的存储器；对指令集的限制排除如小数或浮点运算那样的复杂指令。约束被选择，以使得可以执行诸如双链列表***/删除运算的许多常见运算，包括针对高达4个对齐的八字的原子比较和交换的非常强大的概念。同时，约束被保守选择，使得未来的CPU实现方式可以保证事务的成功，而无需调整约束，因为否则将导致软件不兼容。

除了不存在浮点寄存器(FPR)控制和程序中断过滤字段且控制被视为零以外，TBEGINC的行为非常类似于 TSX中的TBEGIN或IBM的zEC12服务器上的TBEGIN。在事务性中止时，指令地址被直接设定回TBEGINC，而不是后面的指令，从而反映对于受约束的事务的立即重试和中止路径的缺失。

在受约束的事务内不允许嵌套事务，但是如果在不受约束的事务内出现TBEGINC，那么它被视为打开新的不受约束的嵌套级别，正如TBEGIN会这样做。例如，如果不受约束的事务调用在内部使用受约束的事务的子例程，那么这可能出现。

由于中断过滤隐式关闭，因此受约束的事务期间的所有异常导致到操作***(OS)中的中断。事务的最终的成功完成依赖于OS页入被任何受约束的事务接触的最多4页的能力。OS必须也确保时间切片足够长以允许事务完成。

表4

假定受约束的事务不与其它基于锁定的代码交互，表4表示表3中的代码的受约束的事务性实现方式。因此未示出锁试验，但是，如果混合受约束的事务和基于锁的代码，则可能添加锁试验。

当重复出现失败时，通过使用作为***固件的一部分的毫代码来执行软件仿真。有利的是，由于从程序员去除的负担，因此受约束的事务具有希望的特性。

IBM zEnterprise EC12处理器引入了事务性执行设施。该处理器可按每个时钟循环解码3个指令；简单的指令被分派为单个微操作，并且更复杂的指令被裂解为多个微操作232b。微操作(Uop 232b，在图3中示出)被写入到统一的发出队列216，从那里它们可被乱序发出。最多两个固定点、一个浮点、两个加载/存储和两个分支指令可以执行每一个周期。全局完成表(GCT)232保持每个微操作和事务嵌套深度(TND)232a。GCT 232在解码时间被按次序写入，跟踪每个微操作的执行状态，并且当最老的指令组的所有微操作232b已经被成功执行时完成指令。

1级(L1)数据缓存240(图3)是具有256字节缓存线和4循环使用延迟的96KB(千字节)6路关联缓存，它与专用1MB(兆字节)8路关联第2级(L2)数据缓存268(图3)耦合，其中对1L错失具有7循环使用延迟代价。L1缓存240(图3)是最接近处理器的缓存，并且，Ln缓存是处于第n级缓存上的缓存。L1 240(图3)和L2 268(图3)缓存均是贯穿存储。每个中央处理器(CP)芯片上的六个核共享48MB第3级内部存储缓存，并且，六个CP核与芯片外384MB第4级缓存连接，该六个CP芯片被一起封装于玻璃陶瓷多芯片模块(MCM)上。最多4个多芯片模块(MCM)可与具有高达144个核的相干对称多处理器(SMP)***连接(不是所有的核可用于运行顾客工作负载)。

通过MESI协议的变体管理相干性。缓存线可以只读(共享)地被拥有或者是独占的；L1 240(图3)和L2 268(图3)是贯穿存储，并且因此不包含脏线。L3和L4缓存是内部存储并且跟踪脏状态。各缓存包含所有其连接的更低级别的缓存。

相干性请求被称为“交叉询问”(XI)，并且按层级从更高级别缓存向更低级别缓存发送，并且在L4之间被发送。当一个核错失L1 240(图3)和L2 268(图3)并且从其本地L3请求缓存线时，L3检查它是否拥有线，并且在它将缓存线返回到请求者之前，如果必要则在该L3下将XI发送到当前拥有的L2 268(图3)/L1 240(图3)以确保相干性。如果请求还错失L3，那么L3将请求发送到L4，该L4通过将XI发送给该L4下的所有必要L3以及发送给相邻的L4来强制实施相干性。然后，L4对做出请求的L3进行响应，该L3将响应转送到L2 268(图3)/L1240(图3)。

注意，由于缓存层级的包含规则，由于在更高级别缓存上由从请求到其它缓存线的关联性溢出导致的逐出，有时缓存线从下级缓存被XI。这些XI可被称为“LRU XI”，这里，LUR代表最少最近使用。

参照另一类型的XI请求，降级-XI将缓存所有权从独占转变成只读状态，并且，独占-XI将缓存所有权从独占转变成无效状态。降级-XI和独占-XI需要回到XI发送器的响应。目标缓存可“接收”XI，或者，如果它在接收XI之前首先需要逐出脏数据，则发送“拒绝”响应。L1 240(图3)/L2 268(图3)缓存是贯穿存储，但是，如果它们在使独占状态降级之前在需要被发送到L3的存储队列中具有存储，则可拒绝降级-XI和独占-XI。被拒绝的XI将由发送器重复。只读XI被发送到拥有线只读的缓存；对于这种XI不需要响应，因为它们不能被拒绝。SMP协议的细节与P.Mak、C.Walters和G.Strait在2009年IBM研究和开发期刊第53:1卷中的“IBM System z10 processor cache subsystem microarchitecture”对IBM z10描述的那些类似，在这里通过引用加入其全部内容。

事务性指令执行

图3描绘示例CPU的示例部件。指令解码单元(IDU)208保持跟踪当前事务嵌套深度(TND)212。当IDU 208接收TBEGIN指令时，嵌套深度递增，并且在TEND指令时相反地递减。对于每个被分配的指令，嵌套深度被写入到GCT 232中。当TBEGIN或TEND在以后被清除的推测性路径上被解码时，从不被清除的最年轻的GCT 232刷新IDU 208的嵌套深度。事务状态也被写入发出队列216中以供执行单元使用，主要是供加载/存储单元(LSU)280使用。假定事务在到达TEND指令之前中止，TBEGIN指令可规定用于记录状态信息的事务诊断块(TDB)。

与嵌套深度类似，IDU 208/GCT 232通过事务嵌套协作地跟踪访问寄存器/浮点寄存器(AR/FPR)修改掩膜；当AR/FPR修改指令被解码并且修改掩膜阻挡它时，IDU 208可将中止请求放入到GCT 232中。当指令变成下一个完成时，完成被阻挡并且事务中止。其它的受限指令被类似地处理，包括在处于受约束的事务期间如果被解码或者超过最大嵌套深度的TBEGIN。

最外面的TBEGIN根据Gr-保存-掩膜破裂成多个微操作；各微操作将由两个固定点单元(FXU)202中的一个执行，以将一对GR 228保存于特殊的事务备份寄存器文件224中，该事务备份寄存器文件224用于在以后在事务中止的情况下恢复GR 228内容。并且，如果一个TDB被规定，那么TBEGIN引起微操作226b执行TDB的可访问试验；地址被保存于特殊目标寄存器中，供以后用于中止情况下。在最外面的TBEGIN的解码上，指令地址和TBEGIN的指令文本也被保存于特殊目标寄存器中，以供以后的潜在的中止处理。

TEND和NTSTG是单微操作232b指令；除了在发出队列中被标示为非事务以使得LSU280可适当地处理它以外，NTSTG(非事务存储)与正常的存储类似地被处理。TEND在执行时为非操作，当完成TEND时执行事务的结束。

如上所述，处于事务内的指令在发出队列216中被照这样标示，但是否则几乎不变地执行；LSU 280执行在下一部分中描述的隔离跟踪。

由于解码是按次序的，并且由于IDU 208保持跟踪当前事务状态并且将其连同来自事务的每个指令写入发出队列216中，因此，事务之前、之内和之后的TBEGIN、TEND和指令的执行可被乱序执行。有效地址计算器236被包含于LSU 280中。甚至能够(虽然不太可能)TEND被首先执行，然后是整个事务并且最后TBEGIN执行。在完成时间通过GCT 232恢复程序次序。事务的长度不受GCT 232的尺寸限制，因为可从备份寄存器文件224恢复通用寄存器(GR)228。

在执行期间，基于事件抑制控制过滤程序事件记录(PER)事件，并且，PER TEND事件如果被启用则被检测。类似地，当处于事务性模式中时，伪随机发生器可导致通过事务诊断控制启用的随机中止。

用于事务隔离的跟踪

加载/存储单元跟踪在事务性执行期间访问的缓存线，并且，如果来自另一CPU(或LUR-XI)的XI与印迹(footprint)冲突，那么触发中止。如果冲突的XI是独占的或者降级的XI，那么LSU怀着在L3重复XI之前完成事务的希望拒绝XI回到L3。该“僵持”在高度竞争的事务中是非常有效的。为了在两个CPU相互僵持时防止挂起，实现XI拒绝计数器，该XI拒绝计数器将在满足阈值时触发事务中止。

L1缓存目录240在常规上由静态随机存取存储器(SRAM)实现。对于事务存储器实现方式，该目录的有效位244(64行×6列)已经被移动到正常逻辑锁存器中，并每缓存线补充两个更多的位：TX读取248位和TX脏252位。

当新的最外面TBEGIN被解码时(它与之前仍然悬而未决的事务互锁)，TX读取248位被复位。TX读取248位由在发出队列中标为“事务”的每个加载指令在执行时间被设定。注意，如果例如在错误预测的分支路径上执行推测性的加载，那么这可导致过度标示。在加载完成时间设定TX读取位的替代方案对于硅区域来说太昂贵，因为多个加载可同时完成，从而在加载队列上需要许多读取端口。

存储以与非事务性模式相同的方式执行，但是事务标示被放在存储指令的存储队列(STQ)260条目中。在写回时间，当来自STQ 260的数据被写入到L1 240中时，对写入的缓存线设定L1目录256中的TX脏252位。仅在完成存储指令之后出现将存储写回到L1 240中，并且，每个循环写回至多一个存储。在完成和写回之前，加载可通过存储转发从STQ 260访问数据；在写回之后，CPU 114(图2)可访问L1 240中的推测性更新数据。如果事务成功结束，那么所有缓存线的TX脏位252被清除，并且还没有写入的存储的TX标示在STQ 260中被清除，从而有效地将悬而未决的存储变为正常的存储。

在事务中止时，所有悬而未决的事务性存储从STQ 260中被无效化，即使是已完成的那些。通过L1 240中的事务修改(即，使得TX脏位252打开)的所有缓存线使它们的有效位关断，从而有效地即刻从L1 240去除它们。

架构要求在完成新的指令之前保持事务读取集和写入集的隔离。通过在XI悬而未决时在适当的时间拖延指令完成来确保该隔离；允许推测性失序执行，从而乐观假定悬而未决的XI要到不同的地址并且不实际导致事务冲突。该设计非常自然地与在现有***上实现的XI-完成互锁适应，以确保架构需要的强的存储器排序。

当L1 240接收XI时，L1 240访问目录以检查L1 240中的被XI的地址的有效性，并且，如果TX读取位248在被XI的线上活动并且XI不被拒绝，那么LSU 280触发中止。当具有活动的TX读取位248的缓存线从L1 240被LRU时，特殊LRU扩展矢量对L1 240的64个行中的每一个记得在该行上存在TX读取线。由于对LRU扩展不存在精确的地址跟踪，因此命中LSU280的有效扩展行的任何未被拒绝的XI触发中止。假定针对非精确LRU扩展跟踪没有与其它CPU 114(图2)的冲突导致中止，那么提供LRU扩展有效地增加从L1尺寸到L2尺寸的读取印迹能力和关联性。

存储器印迹由存储缓存尺寸(存储缓存在后面更详细地讨论)限制并且由此隐含地由L2尺寸和关联性限制。当TX脏缓存线从L1被LRU时，不需要执行LRU扩展行动。

存储缓存

在现有***中，由于L1 240和L2 268是贯穿存储缓存，因此每个存储指令导致L3存储访问；利用现在的每L3的6个核以及各核的进一步提高的性能，对于L3(以及在更低的程度上对于L2)的存储率对于某些工作负载变为问题。为了避免存储排队延迟，必须添加收集存储缓存，该收集存储缓存在向L3发送存储之前组合存储与相邻的地址。

对于事务存储器性能，在事务中止时使来自L1 240的每个TX脏缓存线无效化是可接受的，因为L2缓存268非常接近(7循环L1错失代价)于带回干净线。但是，对于性能(和用于跟踪的硅区域)来说，使得事务性存储在事务结束之前写入L2 268并然后在中止时使所有脏L2缓存线无效化是不可接受的(或者在共享的L3上更差)。

可利用收集存储缓存264解决存储带宽和事务存储器存储处理的两个问题。缓存264是具有64个条目的圆形队列，每个条目保持具有字节精确有效位的数据的128个字节。在非事务操作中，当从LSU 280接收存储时，存储缓存264检查是否对同一地址存在条目，并且，如果是则将新存储收集到现有的条目中。如果不存在条目，那么新条目被写入到队列中，并且，如果自由条目的数量低于阈值，那么最旧的条目被写回到L2 268和L3缓存中。

当开始新的最外面的事务时，存储缓存264中的所有现有条目被标示为关闭，使得没有新的存储可被收集到这些条目中，并且，开始这些条目向L2 268和L3的逐出。从该点起，从LSU 280STQ 260出来的事务性存储分配新的条目或者收集到现有的事务性条目中。将这些存储写回到L2 268和L3中被阻挡，直到事务成功结束为止；在该点，随后的(后事务)存储可继续收集到现有条目中，直到下一事务再次关闭这些条目为止。

存储缓存264在每个独占或降级XI时被询问，并且如果XI与任何活动条目比较则导致XI拒绝。如果核在继续拒绝XI的同时不完成进一步的指令，那么事务在某些阈值上被中止以避免挂起。

当存储缓存溢出时，LSU 280请求事务中止。LSU 280在其尝试发送不能合并到现有条目中的新存储时检测该条件，并且，整个存储缓存264被填充来自当前事务的存储。存储缓存264作为L2 268的子集被管理：虽然可从L1 240逐出事务脏线，它们必须在整个事务中保持驻留于L2 268中。最大存储印迹由此被限于64×128字节的存储缓存尺寸，但是它也由L2 268的关联性限制。由于L2 268是8路关联的并且具有512个行，因此它一般足够大以便不导致事务中止。

如果事务性中止，那么存储缓存被通知并且保持事务性数据的所有条目被无效化。存储缓存也按每个双字(8字节)具有关于条目是否通过NTSTG指令被写入的标示——这些双字跨着事务中止保持有效。

毫代码实现的功能

常规上，IBM主机服务器处理器包含称为毫代码的固件层，该固件层执行像某些CISC指令执行、中断处理、***同步和RAS的复杂功能。与应用程序和操作***(OS)的指令类似，毫代码包含机器依赖指令以及从存储器取得和执行的指令集架构(ISA)的指令。固件驻留于顾客程序不能访问的主存储器的受限区域中。当硬件检测到需要调用毫代码的情况时，指令取得单元204切换到“毫代码模式”并且开始在毫代码存储器区域中的适当位置处取得。毫代码可通过与指令集架构(ISA)的指令相同的方式被取得和执行，并且可包含ISA指令。

对于事务存储器，在各种复杂情况下涉及毫代码。每个事务中止调用专用毫代码子例程以执行必要的中止操作。事务中止毫代码通过读取保持硬件内部中止原因、潜在异常原因和被中止的指令地址的专用寄存器(SPR)开始，然后如果一个TDB被指定则毫代码使用该专用寄存器来存储TDB。TBEGIN指令文本从SPR被加载以获得GR保存掩膜，这对毫代码获知恢复哪些GR 228是需要的。

CPU 114(图2)支持特殊的仅毫代码指令以读出备份GR并且将它们拷贝到主GR中。TBEGIN指令地址也从SPR被加载以设定PSW中的新指令地址，以在毫代码中止子例程完成时在TBEGIN之后继续执行。在中止由非过滤的程序中断导致的情况下，该PSW可在以后被保存为程序旧PSW。

TABORT指令可以是毫代码实现的；当IDU 208解码TABORT时，它指示指令取得单元分支到TABORT的毫代码中，毫代码从中分支到共用中止子例程中。

提取事务嵌套深度(ETND)指令也可被毫代码化，因为它不是对性能关键的；毫代码加载来自特殊硬件寄存器中的当前嵌套深度并且将其放入到GR 228中。PPA指令被毫代码化；它基于由软件作为操作数提供给PPA的当前中止计数并且也基于其它的硬件内部状态执行最佳延迟。

对于受约束的事务，毫代码可保持跟踪中止的数量。计数器在成功TEND完成时或者如果出现进入到OS中的中断(因为是否或者何时OS将返回到程序不是已知的)被复位为0。根据当前中止计数，毫代码可调用某些机制以提高随后事务重试的成功机会。该机制包括例如连续增加重试之间的随机延迟和减少推测性执行的量，以避免遇到由对事务实际不使用的数据的推测性访问导致的中止。作为最后的对策，在释放其它CPU以继续正常处理之前，毫代码可被广播到其它CPU以停止所有冲突工作，重试本地事务。多个CPU必须被协调以不导致死锁，因此，需要不同CPU上的毫代码实例之间的一些串行化。

现在参照图4，附图标记400一般示出可在硬件或软件中实现用于自适应地共享数据的方法的示例性实施例。

在当前的实现方式中，可通常实施基于锁使数据访问同步的两个方法。在也称为锁定或真实锁定的数据结构锁定中，在代码的关键区段中，程序可能希望被保证对也称为共享数据的存储器区域的独占访问。在这种情况下，程序可通过锁保护共享数据，其作用类似于对共享数据在该时间不可用的竞争性程序的标记。但是，锁定机构可严格地控制对共享数据的访问。在轻度竞争存储器区域中，竞争性程序可能不必要地等待，从而不利地影响性能。例如，在以下的代码样例中，当线程1在结构hash_tbl上保持锁的同时，线程2等待执行(尽管两个线程正在更新结构的不同部分)并且可并行地执行。

表5

上述的HLE允许被写入以使用传统锁定代码的程序具有利用实现事务性执行的硬件的机会。但是，在重度竞争性存储器区域中，如果出现冲突，那么处理器可中止事务并且通过使用悲观锁定行为重新执行关键区段。在一个实施例中，与缓存线相交的任何锁不被省略并且将在没有HLE的情况下自动触发重新执行。因此，在已知关键区段作为事务不断地失败的情况下，缺省到事务性执行并随后通过使用锁来成功重新开始会使性能劣化。

在410中，当处理器即CPU 114(图2)启动代码序列以访问存储器区域时，CPU 114(图2)调用可在硬件或软件中实现的冲突预测器(即，HLE预测器或硬件锁虚拟化器)，以尝试预测是否锁省略可能成功或者是否应替代性使用锁定。在操作中，如后面讨论的那样，冲突预测器可在各种硬件和软件环境中操作。但是，在冲突预测器参照HLE环境内的冲突预测的实施例的情况下，冲突预测器也可被称为HLE预测器。在一个实施例中，例如在硬件寄存器中或者在基于每个线程或者对所有线程共享的存储器位置中，保持成功事务执行的简单计数。在传递表示成功事务执行的计数的阈值时，在410处，冲突预测器可预测事务性执行路径，即锁省略可比455处的非事务性(即锁定)路径更有效，因为干扰是不可能的。在至少一个实施例中，在优选对应于基于锁省略的事务性执行的至少一个实施例中，计数器被初始化以起初偏好更有效的执行路径。在另一实施例中，在硬件中或者通过嵌入程序流中的指令，执行事务相对获得并通过锁执行的估计相对成本可被计算。基于计算的相对成本，冲突预测器可预测事务性路径还是非事务路径更有效，因为例如所预测的路径执行起来成本更低或者更不可能遇到干扰。在另一实施例中，编译器可隐含地将行为提示***到冲突预测器中，以在410处选择420处的事务性执行路径或455处的锁定路径。CPU 114(图2)可开始将关键区段作为420处的事务来执行，从而在425处根据需要更新数据。在430处的事务结束时但在提交结果之前，在435处CPU 114(图2)可确定是否检测到会导致事务中止的干扰(即，在同一数据上并行操作的两个或更多个代码序列)。当没有检测到干扰时，那么在440处，事务可成功地提交结果，这可随后被其它事务使用。但是，如果在435处CPU 114(图2)检测到干扰，那么在455处，通过使用锁定来重新开始执行。在460处，关键区段必须显式地获得保护要被访问的存储器区域的锁。但是，锁请求器可被强制等待，直到在称为旋转的动作中通过竞争性处理释放锁为止。在最后在460处获得锁时，关键区段可继续处理。当由锁保护的数据在470处被更新时，则关键区段完成并且可在475处释放锁。

参照图5，附图标记500一般示出在存在HLE支持的环境中实现冲突预测器(即，硬件锁虚拟化器)的示例性实施例。如上所述，HLE是传统兼容指令集扩展，包括XACQUIRE和XRELEASE，该指令集扩展允许被写入以使用传统锁定代码的程序具有利用实现事务性执行的硬件的机会而不必大幅修改代码。在本实施例中，HLE预测器是 HLE的特定示例。

在505处，CPU 114(图2)执行 XACQUIRE前缀指令以利用相关联的锁获取事务启动HLE序列。在一个实施例中，该序列可由后跟锁获取事务的XACQUIRE表示。在一些实现方式中，XACQUIRE前缀可被忽略。在其它的实现方式中，可选择性地执行XACQUIRE序列。在开始HLE起始序列之后，冲突预测器(即HLE预测器)在510处被调用。基于预测，可以执行锁省略，或者可以获取锁。当在锁省略与获取锁之间预测时，处理可以与在图4的420～475处描述的基本上类似地继续。

参照图6，附图标记600一般示出根据不存在附加的硬件能力的示例性实施例的、用于利用锁省略与锁定之间的选择来自适应地共享数据的方法的流程图。在本示例性实施例中，可例如通过操作***在应用程序的代码流内或者通过硬件提供对冲突预测器的提示。例如，在一个实施例中，程序员可显式***一个或更多个指令，或者编译器可隐含地***对冲突预测器的行为提示。冲突预测器可保持历史矢量或计数，以在诸如例如1秒的某个时间段上跟踪成功预测和不成功预测(即错误预测)二者的数量。然后，在610处，冲突预测器可在该时间窗口期间比较错误预测的计数与失败的阈值数量。当在时间窗口期间错误预测超过失败的阈值数量时，冲突预测器可对时间窗口的剩余部分缺省到使用锁(即非事务性模式)的执行。在该时间窗口期间，由于当多个事务同时更新冲突数据时的工作特性，存储器区域可以是高度竞争的。通过将锁定暂时选择为缺省，冲突预测器可避免必须重新开始失败的事务的可能性，并且通过避免事务中止来提高吞吐量。但是，一旦时间窗口到期，对存储器区域的竞争就可变得轻松，并且冲突预测器可再次尝试事务性执行。在实施例中，冲突预测器以软件被实现，其中要由软件实现的算法做出的执行锁省略还是锁定的决定将控制传递到代码实现的锁省略的第一版本或者代码实现的锁获取的第二版本。在其它实施例中，基于干扰的历史，响应于通过软件的对要更新的特定条目的指示，并且反映与作为更新事务的目标的字段相关的期望干扰或非干扰等，通过使用替代性试验实现决定610。

在655处，关键区段必须显式获得保护被访问的存储器区域的锁。但是，锁请求器可被强制等待，直到锁在被称为旋转的动作中被竞争性程序释放为止。当在660处最终获得锁时，关键区段可继续处理。当由锁保护的数据在670处被更新时，然后在675处完成关键区段，并且锁可被释放。在680处，CPU 114(图2)可检查时间窗口的到期。如果时间窗口没有到期，那么在680处处理结束。但是，如果时间窗口到期，那么在685处，失败事务执行和成功事务执行的计数可被复位，从而有效地将时间窗口复位并且开始冲突预测器的重新训练。

在错误预测在时间窗口期间不超过失败的阈值数量的情况下，在610处，冲突预测器可选择锁省略，即HLE事务或与显式读取锁字而不是获取锁联合起来实现锁省略的事务。当选择作为HLE事务执行(或者作为与通过执行在其读取集中包含锁字的事务来执行锁省略的软件事务联合起来实现锁省略的事务)时，在615处，CPU 114(图2)可递增成功事务执行的计数。620处的HLE事务可在625处根据需要更新数据。在630处的事务结束时但在635处的提交结果之前，CPU 114(图2)可确定是否检测到会导致事务中止的干扰(即，在同一数据上并行操作的两个或更多个代码序列)。在没有检测到干扰时，在640处，HLE事务(或实现锁省略的其它事务)可成功提交结果，这些结果可随后被其它的处理使用。但是，如果在635处CPU 114(图2)检测到干扰，那么在650处，递增失败事务执行的计数，因为失败事务算作错误预测并且可被用于训练冲突预测器以进行更精确的将来预测。在655和660处，CPU 114(图2)现在可尝试在存储器区域上获得锁并且非事务性地(即使用锁)重新开始关键区段。当由锁保护的数据最终在670处被更新时，则关键区段的处理完成，并且在675处锁可被释放。在680处，CPU 114(图2)可检查时间窗口的到期。如果时间窗口没有到期，那么在680处处理结束。但是，当时间窗口到期时，那么在685处，失败事务执行和成功事务执行的计数可被复位，从而有效地开始冲突预测器的重新训练。

现在参照图7，附图标记700一般示出用于自适应地共享数据的方法可包括在执行锁时监视硬件中的设施的示例性实施例的流程图。在图7中，HLE事务的处理(即710到750)基本上与图6的实施例如何处理HLE事务(即610到650)类似。但是，图7为关键区段正在非事务性地执行的路径引入硬件锁监视设施。在本实施例中，在允许关键区段在被锁定的存储器区域内执行的同时，硬件锁监视设施尝试通过预测结果来最小化错误预测，如同关键区段实际执行为HLE事务一样。一旦在760和765处成功获得锁，硬件锁监视设施就可开始在770处监视锁的状况。775处的关键区段更新被锁定的存储器区域中的数据并且在780处通过释放锁来完成执行。但是，在执行期间，如果在785处硬件锁监视设施检测到另一处理检查锁标记的状态，那么假如该关键区段执行为事务而不是非事务性地，由其它处理的尝试处理会导致干扰和事务失败。在一个实施例中，仅监视锁。在另一实施例中，作为被锁定的区域的一部分被更新的数据被监视。作为结果，在790处，硬件锁监视设施可递增失败事务执行的计数。

在另一实施例中，硬件锁监视设施可监视被锁定的存储器区域内的所有尝试数据访问。如果另一处理尝试访问该区域中的数据，那么在790处，硬件锁监视设施可将其计数为干扰和潜在事务失败。因此，冲突预测器可学习以更精确地预测事务性执行还是非事务性执行更可能成功。

在另一实施例中，可在递增事务执行失败的计数时在750处设定重新开始标记。然后，当成功事务执行的计数被递增时，可在755处复位该重新开始标记。重新开始标记可通过防止失败事务执行的计数递增两次(即在750处作为HLE事务的失败时一次，并且在使用锁在755处重新开始一次)来提高预测准确性。

现在参照图8，在实施例中，在硬件锁省略(HLE)环境中，预测性地确定HLE事务是否应实际获取锁并且非事务性地执行810包括：基于遇到HLE锁获取指令，基于HLE预测器，确定是省略锁并且作为HLE事务继续还是获取锁并且作为非事务继续820；基于HLE预测器预测为省略，将锁的地址设定为HLE事务的读取集，并且抑制由锁获取指令对锁的任何写入，并且在HLE事务性执行模式中继续，直到遇到xrelease指令或者HLE事务遇到事务性冲突830为止，其中，xrelease指令释放锁；及基于HLE预测器预测不省略，将HLE锁获取指令视为非HLE锁获取指令且在非事务性模式中继续840。

现在参照图9，在实施例中，基于HLE事务的预测成功更新HLE预测器。基于第一次遇到具有锁地址的HLE事务，将与锁地址相关联的成功HLE事务执行的计数初始化为零；基于完成具有锁地址的任何随后HLE事务，递增HLE预测器中的与HLE事务的锁地址相关联的失败HLE事务执行的计数，其中，高的计数指示可能中止920。在非事务性模式中，监视由另一处理对锁的尝试访问；以及当由另一处理的尝试访问被检测时，递增失败HLE事务执行的计数950。跟踪时间窗口内的成功HLE事务执行的计数和失败HLE事务执行的计数；以及基于失败HLE事务执行的计数超过失败的阈值数量，将时间窗口的剩余部分缺省到非事务模式970。基于时间窗口到期，将成功HLE事务执行的计数和失败HLE事务执行的计数复位为零960。

现在参照图10，计算设备1000可包括各组的内部部件800和外部部件900。内部部件800的组中的每一个包括：一个或更多个处理器820；一个或更多个计算机可读RAM 822；一个或更多个总线826上的一个或更多个计算机可读ROM 824；一个或更多个操作***828；执行图5～7的方法的一个或更多个软件应用；和一个或更多个计算机可读有形存储设备830。一个或更多个操作***存储于各计算机可读有形存储设备830中的一个或更多个上，以经由各RAM 822(一般包含缓存存储器)中的一个或更多个由各处理器820中的一个或更多个执行。在图10所示的实施例中，计算机可读有形存储设备830中的每一个是内部硬盘驱动的磁盘存储设备。作为替代方案，计算机可读有形存储设备830中的每一个是诸如ROM824、EPROM、快擦写存储器的半导体存储设备或者可存储计算机程序和数字信息的任何其它计算机可读有形存储设备。

每一组内部部件800还包括用于从一个或更多个计算机可读有形存储设备936读取和向其写入的R/W驱动或接口832，其中该一个或更多个计算机可读有形存储设备936诸如薄供应存储器设备、CD-ROM、DVD、SSD、存储器棒、磁带、磁盘、光盘或半导体存储设备。R/W驱动或接口832可被用于将设备驱动程序840固件、软件或微代码加载到有形存储设备936以有利于与计算设备100的部件的通信。

每一组内部部件800还可包括诸如TCP/IP适配器卡、无线Wi-Fi接口卡或者3G或4G无线接口卡或者其它有线或无线通信链路的网络适配器(或者开关端口卡)或接口836。与计算设备1000相关联的操作***828可经由网络(例如，因特网、局域网或广域网)和各网络适配器或接口386从外部计算(例如，服务器)被下载到计算设备1000。从网络适配器(或开关端口适配器)或接口836，与计算设备1000相关联的操作***828被加载到各硬盘驱动830和网络适配器836。网络可包含铜线、光纤、无线传送、路由器、防火墙、开关、网关计算机和/或边缘服务器。

外部部件900的组中的每一个可包括计算机显示监视器920、键盘930和计算机鼠标934。外部部件900还可包括触摸屏、虚拟键盘、触摸板、指向设备和其它人类接口设备。内部部件800的组中的每一个还包括与计算机显示监视器920、键盘930和计算机鼠标934对接的设备驱动器840。设备驱动器840、R/W驱动或接口832和网络适配器或网络836包括硬件和软件(存储于存储设备830和/或ROM 824)中。

本公开内容的各种实施例可在适于存储器和/或执行程序代码的数据处理***中被实现，该数据处理***包含通过***总线直接或间接与存储器元件耦合的至少一个处理器。存储器元件包括例如在程序代码的实际执行中使用的本地存储器、大容量存储器和为了减少在执行过程中必须从大容量存储器检索代码的次数而提供至少一些程序代码的暂时存储的缓存存储器。

输入/输出或I/O设备(包含但不限于键盘、显示器、指向设备、DASD、带、CD、DVD、U盘驱动和其它存储器介质等)可直接或者通过介入的I/O控制器与***耦合。网络适配器也可与***耦合以使得数据处理***通过介入的专用或公用网络变得与其它数据处理***或远程打印机或存储设备耦合。调制解调器、电缆调制解调器和以太网卡仅是可用类型的网络适配器中的一些。

本发明可以是***、方法和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于使处理器实现本发明的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本发明操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Java,Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本发明的各个方面。

这里参照根据本发明实施例的方法、装置(***)和计算机程序产品的流程图和/或框图描述了本发明的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本发明的多个实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

虽然本文详细描绘和描述了优选实施例，但对本领域技术人员来说，很显然，可在不背离本公开内容的精神的情况下进行各种修改、添加和替代等，并且因此，这些被视为处于在以下的权利要求内限定的本公开内容的范围内。

Claims (20)

1.一种硬件锁省略HLE环境中的方法，所述方法用于预测性地确定HLE事务是否应实际获取锁并且非事务性地执行，所述方法包括：

基于遇到HLE锁获取指令，基于HLE预测器，确定是省略锁并且作为HLE事务继续还是获取锁并且作为非事务继续；

比较失败HLE事务执行的计数与失败的阈值数量；

基于失败HLE事务执行的计数不超过失败的阈值数量，在HLE事务性执行模式中继续，直到遇到xrelease指令或者检测到干扰为止，其中，xrelease指令释放锁，响应于检测到干扰，递增失败HLE事务执行的计数；以及

基于失败HLE事务执行的计数超过失败的阈值数量，将HLE锁获取指令视为非HLE锁获取指令且在非事务性模式中继续。

2.根据权利要求1所述的方法，还包括：

基于对HLE事务的预测的成功来更新HLE预测器，其中HLE预测器预测HLE事务是否可能中止。

3.根据权利要求1所述的方法，还包括：

基于第一次遇到具有锁地址的HLE事务，将与锁地址相关联的成功HLE事务执行的计数初始化为零；

基于中止具有锁地址的任何随后HLE事务，递增预测器中与HLE事务的锁地址相关联的失败HLE事务执行的计数；

基于完成具有锁地址的任何随后HLE事务，递增HLE预测器中与HLE事务的锁地址相关联的成功HLE事务执行的计数。

4.根据权利要求1所述的方法，还包括：

在非事务性模式中监视另一处理对锁的尝试访问；和

当检测到所述另一处理的尝试访问时，递增失败HLE事务执行的计数。

5.根据权利要求1所述的方法，还包括：

跟踪时间窗口内的成功HLE事务执行的计数和失败HLE事务执行的计数；

比较在所述时间窗口期间的失败HLE事务执行的计数与失败的阈值数量；以及

基于失败HLE事务执行的计数超过所述失败的阈值数量，将所述时间窗口的剩余部分缺省到非事务性模式。

6.根据权利要求5所述的方法，还包括：

基于所述时间窗口到期，将成功HLE事务执行的计数和失败HLE事务执行的计数复位为零。

7.一种计算机可读存储介质，所述计算机可读存储介质能通过处理电路读取，并且存储由处理电路执行以用于执行包括以下步骤的方法的指令：

基于遇到HLE锁获取指令，基于HLE预测器，确定是省略锁并且作为HLE事务继续还是获取锁并且作为非事务继续；

比较失败HLE事务执行的计数与失败的阈值数量；

基于失败HLE事务执行的计数不超过失败的阈值数量，在HLE事务性执行模式中继续，直到遇到xrelease指令或者检测到干扰为止，其中，xrelease指令释放锁，响应于检测到干扰，递增失败HLE事务执行的计数；和

基于失败HLE事务执行的计数超过失败的阈值数量，将HLE锁获取指令视为非HLE锁获取指令并且在非事务性模式中继续。

8.根据权利要求7所述的计算机可读存储介质，其中由处理电路执行指令以用于执行的方法还包括：

基于对HLE事务的预测的成功来更新HLE预测器，其中HLE预测器预测HLE是否可能中止。

9.根据权利要求7所述的计算机可读存储介质，其中由处理电路执行指令以用于执行的方法还包括：

在非事务性模式中监视另一处理对锁的尝试访问；和

当检测到所述另一处理的尝试访问时，递增失败HLE事务执行的计数。

10.根据权利要求7所述的计算机可读存储介质，其中由处理电路执行指令以用于执行的方法还包括：

在非事务性模式中监视另一处理对由锁保护的存储器区域的尝试访问；和

当检测到所述另一处理的尝试访问时，递增失败HLE事务执行的计数。

11.根据权利要求7所述的计算机可读存储介质，其中由处理电路执行指令以用于执行的方法还包括：

基于第一次遇到具有锁地址的HLE事务，将与锁地址相关联的计数初始化为零；

基于中止具有锁地址的任何随后HLE事务，递增预测器中与HLE事务的锁地址相关联的失败HLE事务执行的计数；

基于完成具有锁地址的任何随后HLE事务，递增预测器中与HLE事务的锁地址相关联的成功HLE事务执行的计数。

12.根据权利要求7所述的计算机可读存储介质，其中由处理电路执行指令以用于执行的方法还包括：

跟踪时间窗口内的成功HLE事务执行的计数和失败HLE事务执行的计数；

比较在所述时间窗口期间的失败HLE事务执行的计数与失败的阈值数量；和

基于失败HLE事务执行的计数超过所述失败的阈值数量，将所述时间窗口的剩余部分缺省到非事务性模式。

13.根据权利要求12所述的计算机可读存储介质，其中由处理电路执行指令以用于执行的方法还包括：

基于所述时间窗口到期，将成功HLE事务执行的计数和失败HLE事务执行的计数复位为零。

14.一种硬件锁省略HLE环境中的计算机***，所述计算机***用于预测性地确定HLE事务是否应实际获取锁并且非事务性地执行，所述计算机***包含：

存储器；和

与所述存储器通信的处理器，其中，计算机***被配置为执行一种方法，所述方法包括：

基于遇到HLE锁获取指令，基于HLE预测器，确定是省略锁并且作为HLE事务继续还是获取锁并且作为非事务继续；

比较失败HLE事务执行的计数与失败的阈值数量；

基于失败HLE事务执行的计数不超过失败的阈值数量，在HLE事务性执行模式中继续，直到遇到xrelease指令或者检测到干扰为止，其中，xrelease指令释放锁，响应于检测到干扰，递增失败HLE事务执行的计数；以及

基于失败HLE事务执行的计数超过失败的阈值数量，将HLE锁获取指令视为非HLE锁获取指令并且在非事务性模式中继续。

15.根据权利要求14所述的计算机***，其中由计算机***执行的方法还包括：

基于对HLE事务的预测的成功来更新HLE预测器，其中HLE预测器预测HLE是否可能中止。

16.根据权利要求14所述的计算机***，其中由计算机***执行的方法还包括：

在非事务性模式中监视另一处理对锁的尝试访问；以及

当检测到所述另一处理的尝试访问时，递增失败HLE事务执行的计数。

17.根据权利要求14所述的计算机***，其中由计算机***执行的方法还包括：

在非事务性模式中监视另一处理对由锁保护的存储器区域的尝试访问；以及

当检测到所述另一处理的尝试访问时，递增失败HLE事务执行的计数。

18.根据权利要求14所述的计算机***，其中由计算机***执行的方法还包括：

基于第一次遇到具有锁地址的HLE事务，将与锁地址相关联的计数初始化为零；

基于中止具有锁地址的任何随后HLE事务，递增预测器中与HLE事务的锁地址相关联的失败HLE事务执行的计数；

基于完成具有锁地址的任何随后HLE事务，递增预测器中与HLE事务的锁地址相关联的成功HLE事务执行的计数。

19.根据权利要求14所述的计算机***，其中由计算机***执行的方法还包括：

跟踪时间窗口内的成功HLE事务执行的计数和失败HLE事务执行的计数；

比较在所述时间窗口期间的失败HLE事务执行的计数与失败的阈值数量；以及

基于失败HLE事务执行的计数超过所述失败的阈值数量，将所述时间窗口的剩余部分缺省到非事务性模式。

20.根据权利要求19所述的计算机***，其中由计算机***执行的方法还包括：

基于所述时间窗口到期，将成功HLE事务执行的计数和失败HLE事务执行的计数复位为零。