在无约束事务存储器UTM模式中处置操作系统OS转换.pdf

在一个实施例中，本发明包括一种方法，该方法用于在无约束事务存储器(UTM)事务的执行期间在内核模式中经由环转换从用户线程接收控制，更新与用户线程相关联的事务状态寄存器(TSR)的状态，并存储具有用户线程的上下文的TSR，以及以后在从内核模式到用户线程的转换期间还原上下文。这样，UTM事务可以在用户线程的重新开始上继续。描述并要求保护了其它实施例。

权利要求书一种方法，包括：
在第一用户线程中执行无约束事务存储器(UTM)事务期间，在内核模式中经由环转换从所述第一用户线程接收控制；
当在所述内核模式中时，清除所述UTM事务的至少一个UTM特性、更新与所述第一用户线程相关联的事务状态寄存器(TSR)的至少一个事件字段的状态以指示所述清除，并且存储具有所述第一用户线程的上下文的所述TSR；以及
还原包括所述TSR的所述第一用户线程上下文至处理器并且从所述内核模式转换至所述第一用户线程。
如权利要求1所述的方法，其中当控制被转换至所述内核模式时，所述第一用户线程不中止所述UTM事务。
如权利要求1所述的方法，还包括：在从所述内核模式至所述第一用户线程的所述转换之后，响应于所述TSR的所述至少一个事件字段的所更新的状态，在所述第一用户线程中执行弹出处理机。
如权利要求3所述的方法，还包括：基于所述TSR的所述至少一个事件字段的所述所更新的状态，实施所述弹出处理机中的多个恢复代码路径中的一个恢复代码路径。
如权利要求3所述的方法，还包括：在从所述第一用户线程转换至所述内核模式之前，挂起所述UTM事务和所述弹出处理机，所述挂起包括：更新所述TSR的至少一个状态指示符以及更新与所述第一用户线程相关联的事务控制寄存器(TCR)的控制指示符。
如权利要求1所述的方法，还包括：实施从所述第一用户线程至第二用户线程的第一上下文切换以及从所述第二用户线程返回至所述第一用户线程的第二上下文切换。
如权利要求6所述的方法，还包括：在执行所述第二用户线程中的应用期间，在所述内核模式中经由环转换从所述第二用户线程接收控制，并且当在所述内核模式中时，清除UTM事务的至少一个UTM特性，并且如果所述第二用户线程未执行UTM事务，则不更新与所述第二用户线程相关联的所述TSR的状态。
一种包括机器可读存储介质的制品，所述机器可读存储介质包括指令，所述指令当执行时引起系统执行如下操作：
在所述系统的用户模式的第一用户线程中执行无约束事务存储器(UTM)事务；
在执行所述UTM事务期间引发事件，所述事件引起从所述第一用户线程转换至内核模式；以及
在转换至所述内核模式之前挂起但不中止所述UTM事务。
如权利要求8所述的制品，其中所述事件包括异常并且还包括指令，所述指令引起所述系统更新与所述第一用户线程相关联的处理器的至少一个事务寄存器的至少一个状态字段。
如权利要求9所述的制品，还包括指令，所述指令引起所述系统在所述第一用户线程中经由转换从响应于所述异常执行的所述内核模式的异常处理机接收控制，并且在所述第一用户线程中继续执行所述UTM事务。
如权利要求9所述的制品，还包括指令，所述指令引起所述系统基于所述内核模式的所述异常处理机的执行而在所述用户模式中执行多个代码路径中的一个代码路径。
如权利要求11所述的制品，其中，所述多个代码路径包括用户操作系统(OS)运行时间系统的用户模式异常分派器、UTM运行时间系统的用户模式异常分派器以及所述UTM运行时间系统的弹出处理机。
如权利要求12所述的制品，还包括指令，所述指令引起所述系统基于所述至少一个事务寄存器的所述至少一个状态字段的所述所更新的状态，实施所述弹出处理机中的多个恢复代码路径中的一个恢复代码路径。
一种系统，包括：
处理器，所述处理器包括第一寄存器组，所述第一寄存器组包括：具有多个指示符的事务控制寄存器(TCR)，每个指示符用于控制无约束事务存储器(UTM)事务的方面；以及具有多个指示符的事务状态寄存器(TSR)，每个指示符用于指示所述UTM事务的状态；以及
存储介质，所述存储介质包括指令，所述指令使所述系统能够响应于用户模式的第一用户线程中的UTM事务期间引发的异常而在所述UTM事务的执行期间在内核模式中经由转换从所述第一用户线程接收控制；确定是否在所述内核模式中处置所述异常并且如果是，则在所述内核模式中处置所述异常，否则基于所述异常的类型和所述UTM事务的UTM模式来选择转换控制所在的所述用户模式的多个代码路径中的一个代码路径。
如权利要求14所述的系统，其中，所述指令还使所述系统能够在将所述控制转换至所述用户模式之前当在所述内核模式中时更新TSR的至少一个事件字段，以指示所述异常的发生。
如权利要求14所述的系统，其中，所述指令还使所述系统能够确定UTM运行时间系统是否包括用于为所述UTM模式处置所述异常的代码路径。
如权利要求16所述的系统，其中所述指令还使所述系统能够在所述UTM运行时间系统不包括所述代码路径的情况下选择所述UTM运行时间系统的弹出处理机作为所述代码路径。
如权利要求17所述的系统，其中，所述弹出处理机包括多个执行路径，每个执行路径与不同的事件相关联，并且另外，其中所述指令使所述系统能够基于对所述TCR和所述TSR至少之一中的信息的分析，执行所述弹出处理机中的所述执行路径中的一个执行路径。
如权利要求17所述的系统，其中，所述指令还使所述系统能够在至所述内核模式的所述转换之前挂起但不中止所述UTM事务。
如权利要求16所述的系统，其中，所述指令还使所述系统能够在所述内核模式中访问表，所述表包括多个条目，每个条目包括UTM模式、异常类型以及要基于所述UTM模式和所述异常类型执行的所述UTM运行时间系统的代码路径。

说明书在无约束事务存储器(UTM)模式中处置操作系统(OS)转换
背景技术
无约束事务存储器(UTM)通过使用硬件的硬件加速和软件的组合而使时间和存储占用上任意大的事务能够发生。运行和实现UTM事务通常要求特别编译的代码，用于实现具有UTM硬件加速接口的并发控制机制。因而，如果UTM编译代码的执行受到用户级异步事件以及随后对并非为了UTM执行而编译的用户运行时间代码的执行的干预，则UTM事务不能正确地操作。
用户级异步事件的一个主要原因是在用户级异常(或信号)处理机处处置硬件异常。异常是发生在程序执行期间的事件，该事件要求执行正常执行控制流以外被称为异常处理机的特殊代码路径。硬件异常情况由硬件检测到，并被报告给操作系统(OS)。硬件异常的示例包括除零运算，或者试图访问无效的存储地址位置。当此类异常发生时，通常将控制从用户级代码传递到OS。当OS接收到控制以处理此类异常事件的时侯，它通常试图将该异常分派到与提出该异常的程序相关联的合适异常处理机。
当检测到硬件异常并从用户模式程序提出硬件异常时，OS通常收集异常信息，将异常信息转移到用户堆栈，并转换回用户模式，以及将该异常分派到用户模式异常处理机。在很多现代操作系统(例如WINDOWS、UNIX和LINUX OS)中，提供默认的用户级运行时间代码来处置来自操作系统的、用于用户模式异常(信号)的分派请求，该用户级运行时间代码不是为UTM执行而编译的。因此，在UTM事务期间，对于涉及异常处置和用户级异常分派的异步调用以及处置代码，UTM应用及其运行时间系统面临重大技术难题。
例如，造成OS用户运行时间代码的异步执行的一个主要原因是为来自OS内核代码的异常分派请求提供服务，以支持信号编程(例如，UNIX操作系统中的信号)和用户级异常处置(例如，WINDOWS操作系统中的SEH)。用于接收来自OS内核的请求并将异常分派到目标异常处理机的这个用户模式服务例程是由操作系统提供的默认用户运行时间系统的一部分。现有的OS内核代码和OS用户运行时间代码不是UTM运行时间系统的一部分，并且具有有关UTM实现方案和各种UTM硬件操作模式的有限认识或者不具有有关UTM实现方案和各种UTM硬件操作模式的认识。
因而，在UTM事务期间到OS用户运行时间代码的异步分派以及随后对OS用户运行时间的执行可导致产生错误的操作和结果。一个简单的解决方案是，在UTM执行期间，当硬件异常发生时总是引起未决事务的中止，并允许UTM运行时间系统以没有UTM硬件加速的软件事务存储器(STM)模式重新启动该事务。然而，这个解决方案导致UTM线程的性能明显下降，特别是当该程序涉及频繁的异常处置(例如浮点异常过滤)时。因此UTM线程受到代价高昂的中止和重新启动操作的影响，并且不能为特定事务代码执行实现UTM硬件加速。
附图说明
图1是根据本发明的一个实施例的处理器的框图。
图2是根据本发明的一个实施例的处理器中保存用于数据项的元数据的框图。
图3是根据本发明的一实施例的软件架构的框图。
图4是根据本发明的一个实施例传送异步软件定义(UTM)事件的方法的流程图。
图5是根据本发明的一个实施例、用于在UTM事务期间处置异常或者控制到操作系统(OS)的其他传递的流程图。
图6是根据本发明的一个实施例、用于在用户线程中执行UTM事务代码和UTM运行时间系统代码的流程图。
图7是根据本发明的一实施例、用于处置上下文切换操作的方法的流程图。
图8是根据本发明的一实施例的系统的框图。
具体实施方式
在各个实施例中，处理器中硬件支持和与无约束事务存储器(UTM)运行时间系统相关联的代码、UTM用户级代码以及操作系统(OS)代码的组合可以使UTM事务的改进处置能够实现。具体而言，实施例可以使UTM事务期间可能发生的异常、中断等等的改进处置能够实现。这样，在发生异常或者来自UTM事务的控制的其他转移时，可以维持对于UTM事务承担的工作，而没有自动中止事务。如下面将进一步论述的，可以提供处置这种转换的不同机制。一般而言，当从在用户模式中执行的UTM线程退出到内核模式并且在内核模式中进行UTM‑了解的(UTM‑aware)处置时，这些机制可以使事务的挂起能够实现，以便在返回到用户级UTM线程的时候，重新开始该事务可以成为可能，而不必中止该事务。
虽然本发明的范围不限于在这个方面，但可以在提供对UTM操作的硬件支持的系统中实现实施例。现在提供这种硬件支持的背景来引入所用的概念和术语。然而，要理解的是，本发明的范围不限于这种硬件，而是可以在任何UTM系统中实现实施例。
本文所使用的“线程”可以指硬件线程(例如，逻辑处理器，其在处理器中包括状态存储装置)。“代理”是获得一致性存储器访问的线程或其他系统资源。存储器又可以在逻辑上划分为监视块(MBLK)。对于每个MBLK，每个线程具有私有监视器组，也就是软件可以读取和写入的读取监视器(RM)和写入监视器(WM)。RM和WM正交，并且一起对三个不同的MBLK监视模式进行编码：未监视(RM＝0，WM＝0)，其中没有对于其他代理的访问监视MBLK；读取监视器(RM＝1，WM＝0)，其中对于其他代理的写入以及对于监视损失监视MBLK；以及写入监视((RM＝0，WM＝1)和(RM＝1，WM＝1))，其中对于其他代理的访问以及对于监视损失监视MBLK。
当MBLK的监视器自发地重置为未监视状态时发生监视损失。从监视模式到未监视模式的转换生成监视损失事件。当一个代理访问已被另一个代理写入监视的MBLK时，或当一个代理写入已被另一个代理读取监视器的MBLK时，发生冲突访问。当另一个代理实施对已被线程监视的MBLK的冲突访问时，发生监视冲突，并且引起该MBLK的监视模式被重置为未监视。监视冲突不仅生成监视冲突事件而且生成监视损失事件。被监视的访问是在指令执行前测试监视或将监视设置为执行的一部分的访问。未监视访问是既不修改监视也不测试监视的访问(换句话说，行为和用于存储器访问的典型指令集架构(ISA)语义是相同的)。
存储器也可以在逻辑上划分为缓冲块(BBLK)。对于每个BBLK，每个线程都具有缓冲特性(BUF)的私有实例。可视(BUF＝0)意为全局地观察到对BBLK的存储范围的所有写入。缓冲(BUF＝1)意为通过对BBLK的存储范围的所有写入由发布这些写入的线程局部地观察到，而未由其他代理全局地观察到。软件可以为特定BBLK设置缓冲特性，或为所有BBLK重置缓冲特性。两个不同的动作可以引起该缓冲特性从1转换到0。BBLK‑丢弃(BBLK‑discard)丢弃了自从缓冲特性最后从0转换到1之后通过本地线程对该BBLK的存储器的任何写入，并且BBLK‑提交不可取消地使得此类写入可全局地观察到。当任何线程的任何缓冲特性自发地重置为0时，发生缓冲损失事件，从而实施BBLK‑丢弃。此外，写入监视损失意味着缓冲损失。在给定的线程上，当MBLK的写入监视损失发生时，MBLK地址范围内的所有BBLK都引发缓冲损失。
存储器也可以在逻辑上划分为用于不同用法上下文且具有不同大小的元数据块(MDBLK)组。MDBLK，或更具体地，MDBLK[CR][MDID]，可以通过压缩率(CR)以及通过元数据上下文IO(MDID)来参数化。对于每个MDBLK[CR][MDID]，每个线程具有元数据特性(META)的私有实例。
对于给定的CR，可以存在任何数量的不同MDID，每个MDID指明元数据的独特实例。给定CR和MDID的元数据不同于任何其他CR或MDID的元数据。给定的实现可以支持多个并发上下文，其中上下文的数量将取决于CR和有关于特定系统的某些配置信息，该处理器是该特定系统的一部分。在一个实施例中，对于未压缩元数据而言，对于每个四倍长字(QWORD)的物理数据，可以存在(QWORD)的元数据。元数据仅由软件解释。软件可以为特定MDBLK[CR][MDID]设置、重置或测试META，或为该线程的所有MDBLK[*][*]重置META，或为该线程的可以与给定的MBLK(addr)相交的所有MDBLK[CR][MDID]重置META。该线程的任何META特性可以自发地重置为0，从而生成元数据损失事件。
监视范围是通过基和广度(extent)确定的指定虚拟地址范围，其对应于单虚拟存储器页面。当启用该设施(facility)时，将范围读监视特性赋予具有该线程读取的范围中的地址的任何存储空间。类似地，将范围写入监视特性赋予具有该线程写入的范围中的地址的任何存储空间。这些特性可以通过该硬件自发地移除。如果另一个代理写入到该存储位置，则移除这两个特性。如果另一个线程读取具有范围写入监视特性的位置，则移除那个特性。无论何时移除范围监视特性，都生成损失范围监视事件。因此一般而言，UTM事务的硬件加速可以使用监视、缓冲以及元数据特性来实现。
UTM事件是可以由UTM硬件捕获并且随后可以引起该UTM硬件触发弹出(ejection)的事件，该弹出要调用UTM事件处理机。弹出是到弹出目标指令指针(IP)位置的异步控制转移，该位置由处理器的应用级事务弹出IP(TEJECTIP)寄存器指定。每个线程可以在弹出处理机内具有相关联的UTM事件处理机入口点。注意到，弹出处理机是在由TEJECTIP寄存器指定的指令指针(IP)位置处提供的代码。可以通过弹出处理机调用与那个线程相关联的UTM事件处理机。取决于UTM运行时间系统的实现，该UTM运行时间系统可以配置该TEJECTIP寄存器来直接地指向该UTM事件处理机或创建包含它的指针的表以便该弹出处理机可以通过查找这个表来调用该UBT事件处理机。响应于特定事件，可以设置某些状态寄存器事件跟踪位；并且响应于此，可以将控制转移给该处理机。注意，在各个实施例中，尽管当在处理机内执行时可能修改某些操作的解释，但这种转移不涉及特权级别的改变。可以通过用户级控制转移指令将控制返回到UTM应用的主线(mainline)，并且可以在程序的某定义的重新开始点重新开始UTM应用中的执行。
异步UTM事件是不归因于由该线程执行的任何特定指令的事件。异步事件可以相关于与该线程相关联的监视、缓冲以及元数据特性的改变。这些改变可以通过其他代理的动作触发或由硬件自发地触发。示例异步事件包括监视损失事件、读监视损失、写入监视损失、监视冲突事件、读监视冲突、写入监视冲突、缓冲损失事件、元数据损失事件以及范围监视损失事件。
同步事件是使正常指令执行流中断以致于当前指令设有引退(retire)的故障，并且同步UTM事件(SynchEvent)是作为执行(但并不一定引退)该线程中的特定指令和已知指令的副作用发生的事件。
在一个实施例中，可以存在读取‑写入事务控制寄存器(TCR)，该读取‑写入事务控制寄存器是与线程相关联的控制寄存器并且可以包括可以控制UTM操作的多个指示符(例如，位)，其包括当事件引起处理机调用时。事件只有当它的状态在事务状态寄存器(TSR)中被设置并且它的对应事件处理机使能在TCR中设置时才调用该处理机，该事务状态寄存器是与线程相关联的状态寄存器并且可以包括多个指示符。不管是否设置了对应的处理机使能，事件状态都可以继续在TSR中聚集。TCR的位也可以控制该特定同步事件是否适合在TSR中被捕获，以及是否可以在TSR中的对应同步事件状态下调用该处理机。一般而言，该TCR可以包括使能指示符来使能用于对应事件的处理机，例如在事务期间发生的损失事件或其他事件。
该TSR又提供UTM状态信息，该UTM状态信息包括最近UTM事件类型的聚集。例如，除了关于在事务期间各个UTM特性是否在使用的状态指示符之外，该TSR可以包括多个指示符，每个指示符指示事件(例如在事务期间发生的损失事件)的存在。这个寄存器持续地聚集所有异步UTM事件，加上适合的同步TM事件。在一个实施例中，进入通用寄存器(GPR)读取该TSR可以提供在那个时刻聚集的任何事件(异步或同步)的快照。除了同步UTM事件和异步UTM事件以外，实施例可以提供软件定义UTM事件，可以通过写入值到TSR的对应指示符或字段来注入该软件定义UTM事件。在此类实施例中，可以为软件定义事件预留TSR的一个或多个字段。当将非零值写入到TSR中的软件事件字段时，该硬件如UTM硬件事件一样对待这些更新，并且可以触发弹出。当弹出没有被挂起时，在TSR中的软件事件字段中具有非零值可以导致将控制自发转移到由TEJECTIP寄存器指定的弹出处理机。由UTM运行时间系统提供的弹出处理机可以检查TSR中的值，以找出弹出的一个或多个原因。
作为进一步的背景，查看根据本发明的一实施例的可以用于UTM事务的示例硬件是有益的。参照图1，示出了能够并发地执行多个线程的处理器的实施例。注意，处理器100可以包括对于硬件事务执行的硬件支持。或者连同硬件事务执行，或者单独地，处理器100也可以提供硬件支持用于STM的硬件加速、STM的单独执行或它们的组合，例如，根据本发明一实施例的UTM。处理器100可以是任何类型的处理器，例如微处理器、嵌入式处理器、数字信号处理器(DSP)、网络处理器、或执行代码的其他设备。如所示出的，处理器100包括多个处理元件。
如图1中所示出的，物理处理器100包括两个核，核101和102，它们共享对更高级高速缓存110的访问。尽管处理器100可以包括非对称核，即，具有不同配置、功能单元、和/或逻辑的核，但示出的是对称核。因而，将不详细讨论与核101示为相同的核102，以避免重复讨论。另外，核101包括两个硬件线程101a和101b，而核102包括两个硬件线程102a和102b。因此，例如操作系统的软件实体潜在地将处理器100视为四个单独的处理器，即，能够并发地执行四个软件线程的四个逻辑处理器或处理元件。
这里，第一线程与架构状态寄存器101a相关联，第二线程与架构状态寄存器101b相关联，第三线程与架构状态寄存器102a相关联，而第四线程与架构状态寄存器102b相关联。如所示出的，在架构状态寄存器101b中复制架构状态寄存器101a，因此能够存储各个架构状态/上下文用于逻辑处理器101a和逻辑处理器101b。在一个实施例中，该架构状态寄存器可以包括用于实现UTM事务的寄存器，例如，TSR、TCR、以及TEJECTIP寄存器。也可以复制其他更小的资源(例如指令指针和重命名分配逻辑130中的重命名逻辑)用于线程101a及101b。可以通过分区来共享一些资源(例如重排序/引退单元135中的重排序缓冲器、指令旁路转换缓冲器(ITLB)120、加载/存储缓冲器以及队列)。潜在地，完全共享其他资源(例如通用内部寄存器、页表基础寄存器、低级数据高速缓存和数据TLB 115、一个或多个执行单元140以及失序单元135的一部分)。
如所示出的，处理器100包括总线接口模块105，以与处理器100外部的设备(例如系统存储器175、芯片组、北桥或其他集成电路)通信。存储器175可以专用于处理器100或与系统中的其他设备共享存储器175。更高级的或更远离的高速缓存110要高速缓存最近从更高级高速缓存110获取的单元。注意到，更高级或更远离指代离执行单元距离增大或变得更远的高速缓存级。在一个实施例中，更高级高速缓存110是第二级数据高速缓存。然而，更高级高速缓存110不限于此，原因在于它可以与指令高速缓存相关联或包括指令高速缓存。踪迹高速缓存(trace cache)(即，一种类型的指令高速缓存)可以代替地耦合在译码器125之后，以存储最近译码的踪迹。模块120也潜在地包括用于预测将被执行/取用的分支的分支目标缓冲器和用于存储用于指令的地址转换条目的ITLLB。
译码模块125耦合到获取单元120，以对所获取的单元进行译码。在一个实施例中，处理器100与ISA相关联，该ISA定义/指定在处理器100上可执行的指令。这里，由ISA识别的机器代码指令经常包括被称为操作码的一部分指令，其引用/指定将要实施的指令或操作。
在一个示例中，分配器及重命名器块130包括预留资源(例如寄存器文件)以存储指令处理结果的分配器。然而，线程101a及101b潜在地能够失序执行，其中分配器及重命名器块130也预留其他资源(例如重排序缓冲器)来跟踪指令结果。单元130也可以包括寄存器重命名器来将程序/指令引用寄存器重命名成处理器100内部的其他寄存器。重排序/引退单元135包括组件(例如上文提及的重排序缓冲器、加载缓冲器以及存储缓冲器)，以支持失序执行以及失序执行的指令在以后的有序引退。
在一个实施例中，调度和执行单元块140包括调度单元，以调度在执行单元上的指令/操作。例如，将浮点指令调度到具有可用的浮点执行单元的执行单元的端口上。也包括了与执行单元相关联的寄存器文件来存储信息指令处理结果。示范执行单元包括浮点执行单元、整数执行单元、跳转执行单元、加载执行单元、存储执行单元以及其他已知执行单元。
较低级别数据高速缓存和数据转换缓冲器(D‑TLB)150耦合到一个或多个执行单元140。该数据高速缓存要存储最近所使用/操作的单元，例如数据操作数，潜在地以存储一致性状态保存最近所使用/操作的单元。该D‑TLB要存储最近的虚拟/线性到物理地址转换。作为特别的示例，处理器可以包括页表结构，以将物理存储器分拆为多个虚拟页面。
在一个实施例中，处理器100能够进行硬件事务执行、软件事务执行或它们的组合或混合。也可以称为代码的临界区或原子区的事务包括将作为原子组执行的指令、操作或微操作的群组。例如，指令或操作可以用于区别事务或临界区。在一个实施例中，这些指令是指令集的一部分，例如ISA，它们是可由处理器100的硬件(例如如上描述的译码器)识别的。通常，一旦这些指令从高级语言编译为硬件可识别的汇编语言，则这些指令包括译码器在译码阶段期间识别的操作代码(操作码)，或指令的其他部分。
典型地，在事务的执行期间，对存储器的更新在事务被提交之前不会成为全局可视的。作为示例，到某位置的事务写入对本地线程而言潜在地可视，但是，响应于来自另一个线程的读取，直到包括该事务写入的事务被提交后，才转发该写入数据。如下面更详细讨论的，当该事务仍未决时，跟踪从存储器内加载的数据项/单元以及写入到存储器内的数据项/单元。一旦该事务达到提交点，如果对于该事务还未检测到冲突，则提交该事务并且使该事务期间进行的更新成为全局可视。
然而，如果在事务的未决期间使该事务无效，则中止该事务并且潜在地重新启动该事务，而无需使该更新全局可视。因而，如本文所用的，事务的未决涉及已经开始执行并且还没有提交或中止的事务，即，未决。
在一个实施例中，处理器100能够利用硬件/逻辑执行事务，即，在硬件事务存储器(HTM)系统内。当实现HTM时，从架构角度和微架构角度看，存在很多具体的实现细节；本文没有讨论其中的大多数以避免不必要地模糊了本发明的实施例。然而，为了说明的目的公开了一些结构和实现。但是，应该注意到，并不要求这些结构和实现并且可以利用具有不同实现细节的其他结构来增强和/或替代这些结构和实现。
一般而言，处理器100可能够在UTM系统内执行事务，该UTM系统尝试利用STM系统和HTM系统两者的益处。例如，HTM对于执行小事务通常是快速且有效的，原因在于它不依赖软件来实施所有的访问跟踪、冲突检测、验证以及事务的提交。然而，HTM通常仅能够处置较小的事务，而STM能够处置大小无约束的事务。因此，在一个实施例中，UTM系统利用硬件来执行较小的事务并且利用软件来执行相对硬件来说过大的事务。如由下面讨论可以看见的，即使当软件正处置事务时，也可以利用硬件来辅助并且加速该软件。也可以利用相同的硬件来支持并加速纯粹的STM系统。
如上所述，事务包括由处理器100内的本地处理元件，以及潜在地由其他处理元件对数据项的事务存储器访问。在事务存储器系统中没有安全机制的情况下，这些访问中的一些访问将潜在地导致无效数据和执行，即，对数据的写入使读取无效，或无效数据的读取。因而，处理器100可以包括逻辑，该逻辑用于跟踪或监视去往以及来自数据项的存储器访问，以便识别潜在冲突，例如如下讨论的读取监视器和写入监视器。
在一个实施例中，处理器100包括检测或跟踪访问和潜在的随后的冲突的监视，其与数据项相关联。作为一个示例，处理器100的硬件相应地包括读取监视器和写入监视器以跟踪确定要监视的加载和存储。作为示例，硬件读取监视器器和写入监视器要以数据项的粒度监视数据项，而不管基础存储结构的粒度如何。在一个实施例中，通过以该存储结构的粒度相关联的跟踪机制来约束数据项，以确保至少适当地监视完整的数据项。
作为具体示出的示例，读取监视器和写入监视器包括与高速缓存位置(例如较低级数据高速缓存150内的位置)相关联的属性，以监视来自与那些位置相关联的地址的加载和到与那些位置相关联的地址的存储。这里，当对与该高速缓存位置相关联的地址的读取事件发生时，设置用于数据高速缓存150的高速缓存位置的读取属性，以监视对相同地址的潜在冲突写入。在这种情况下，对于写入事件，写入属性以类似方式操作，以监视对相同地址的潜在冲突读取和写入。为了有助于这个示例，相应地，硬件能够基于监听对高速缓存位置的读取和写入来检测冲突，其中读取和/或写入属性被设置以指示这些高速缓存位置被监视。相反，在一个实施例中，设置读取监视器和写入监视器或将高速缓存位置更新成缓冲状态引起监听，例如读取请求或对所有权请求的读取，其允许检测与其他高速缓存内被监视地址的冲突。
因此，基于该设计，高速缓存一致性请求和所监视的高速缓存行的一致性状态的不同组合导致潜在冲突，例如在共享读监视状态中保存数据项的高速缓存行和指示对该数据项的写入请求的监听。相反，保持数据项的高速缓存行(其处于缓冲写入状态)和指示对数据项的读取请求的外部监听可以潜在地被认为是冲突的。在一个实施例中，为了检测访问请求和属性状态的此类组合，监听逻辑被耦合到冲突检测/报告逻辑，例如用于冲突检测/报告的监视器和/或逻辑，以及状态寄存器，以报告这些冲突。
然而，可以将状况和情形的任何组合视为对于事务而言时无效的，这可以由指令(例如提交指令)定义。对于事务的未提交可以考虑的因素示例包括：检测到事务访问的存储位置的冲突、损失监视信息、损失缓冲的数据、损失与事务访问的数据项相关联的元数据以及检测其他无效事件，例如中断、环转换或明确用户指令(假定不能够继续重新开始的事务)。
在一个实施例中，处理器100的硬件要以缓冲的方式保存事务更新。如上所述，在事务的提交后才使事务写入成为全局可视。然而，与该事务写入相关联的本地软件线程能够访问该事务更新用于随后的事务访问。作为第一示例，在处理器100中提供单独缓冲器结构以保存所缓冲的更新，该缓冲器结构能够向本地线程提供更新，而不向其他外部线程提供更新。但是，包含单独缓冲器结构潜在地是昂贵且复杂的。
与此相反，作为另一个示例，当提供相同的事务功能性时，利用高速缓冲存储器(例如数据高速缓存150)来缓冲更新。这里，高速缓存150能够以缓冲一致性状态保存数据项；在一种情况下，新的缓冲一致性状态被添加到高速缓存一致性协议(例如修正排斥共享无效(MESI)协议)来形成MESIB协议。响应于对所缓冲的数据项(即以缓冲一致性状态保存的数据项)的本地请求，高速缓存150将数据项提供到该本地处理元件以确保内部事务顺序排序。然而，响应于外部访问请求，提供未命中响应以确保在提交之前不使该事务更新的数据项成为全局可视。此外，当以缓冲一致性状态保存高速缓存150的行并且选择高速缓存150的行用于逐出时，该缓冲的更新不被写回到更高级高速缓冲存储器中‑将不通过该存储系统扩散该缓冲的更新，即，直到提交后才使该缓冲的更新成为全局可视。当提交时，将所缓冲行转换到修正状态以使该数据项成为全局可视。
注意到，术语“内部”和“外部”通常与关联于执行共享高速缓存的事务或处理元件的线程的角度相关。例如，用于执行与事务执行相关联的软件线程的第一处理元件被称为本地线程。因此，在上面的讨论中，如果接收到到先前由第一线程写入的地址的存储或来自先前由第一线程写入的地址的加载(其引起以缓冲一致性状态保存地址的高速缓存行)，则由于第一线程是本地线程而将该高速缓存行的缓冲版本提供给第一线程。与此相反，第二线程可以在相同处理器内的另一个处理元件上执行，但是与负责以缓冲状态保存高速缓存行的事务的执行不相关联‑外部线程；因此，从第二线程到该地址的加载或存储未命中该高速缓存行的缓冲版本，并且利用正常高速缓存替换来从更高级存储器中检索高速缓存行的无缓冲版本。
这里，在相同的处理器上执行内部/本地线程和外部/远程线程，并且在一些实施例中，可以在共享对高速缓存的访问的处理器的相同核内的单独处理元件上执行内部/本地线程和外部/远程线程。然而，对这些术语的使用不限于此。如上所述，本地可以指共享对高速缓存的访问的多个线程，而不是特定于与该事务的执行相关联的单个线程，而外部或远程可以指不共享对该高速缓存的访问的线程。
如上面在最初参考图1时所述，处理器100的架构纯粹为讨论目的而示出。例如，在其他实施例中，可以实现UBT硬件，以用于具有简单得多的有序执行处理器设计的处理器，其可能不包括复杂的重命名/分配器单元和重排序器/引退单元。类似地，变换用于引用元数据的数据地址的特定示例也是示范性的，原因在于可以利用在相同的存储器的单独条目中将数据与元数据相关联的任何方法。
转到图2，示出了为处理器中的数据项保存元数据的实施例。如所描述的，用于数据项216的元数据217被本地地保存在存储器215中。元数据包括与数据项216相关联的任何特性或属性，例如有关数据项216的事务信息。下面包括了元数据的一些说明性示例；但是公开的元数据示例纯粹是说明性的。同样地，元数据位置217可以保存数据项216的信息和其他属性的任何组合。
作为第一示例，如果先前已经在事务内访问、缓冲和/或备份数据项216，则元数据217包括对于事务写入的数据项216的备份位置或缓冲位置的引用。这里，在一些实现中，数据项216的先前版本的备份拷贝被保存在不同的位置，并且因而，元数据217包括到备份位置的地址，或对备份位置的其他引用。备选地，元数据217自身可以充当数据项216的备份位置或缓冲位置。
作为另一个示例，元数据217包括过滤值，以加速对数据项216的重复事务访问。通常，在利用软件的事务执行期间，在事务存储器访问时实施访问障碍，以确保一致性和数据有效性。例如，在事务加载操作之前，执行读取障碍以实施读取障碍操作，如果数据项216未锁定，则此类测试确定该事务的当前读取集是否仍有效、更新过滤值以及对于事务在读取集中录入版本值，从而使以后的验证能够实现。然而，如果已经在该事务的执行期间实施对那个位置的读取，则相同的读取障碍操作是潜在地不必要的。
因而，一种解决方案包括利用读取过滤器来保存第一默认值以指示在该事务的执行期间还没有读取数据项216或为此的地址，以及保存第二访问值以指示已经在事务的未决期间访问数据项216，或为此的地址。本质上，该第二访问值指示是否应该加速该读取障碍。在这个实例中，如果接收到事务加载操作并且元数据位置217中的该读取过滤值指示已经读取数据项216，则在一个实施例中省略了该读取障碍‑没有执行该读取障碍‑以通过不实施非必要的、冗余的读取障碍操作来加速该事务执行。注意到，写入过滤值可以以关于写入操作的相同方式来操作。然而，各个过滤值纯粹是说明性的，这是因为在一个实施例中，利用单个过滤值来指示是否已经访问过地址‑而不管写入还是读取。这里，对于加载和存储两者检查用于216的元数据217的元数据访问操作利用了单个过滤值，其与上述示例大不相同，在上述示例中元数据217包括单独读取过滤值和写入过滤值。作为具体的说明性实施例，元数据217的四位被分配给读取过滤器，以指示是否要关于相关联的数据项加速读取障碍，被分配给写入过滤器以指示是否要关于相关联的数据项加速写入障碍，被分配给撤销过滤器以指示要加速撤销操作，以及被分配给混杂过滤器以便由软件以任何方式用作过滤值。
元数据的少数其他示例包括对如下项的指示、表示或引用：用于通用的或特定于与数据项216相关联的事务的处理机的地址、与数据项216相关联的事务的不可取消/顽固性质、数据项216的损失、用于数据项216的监视信息的损失、对于数据项216检测到冲突，读取集的地址或读取集内读取条目的地址(其与数据项216相关联)、数据项216的先前已录入版本、数据项216的当前版本、用于允许对数据项216进行访问的锁定、数据项216的版本值、用于与数据项216相关联的事务的事务描述符以及其他已知的事务相关描述信息。此外，如上所述，对元数据的使用不限于事务信息。由此可推论，元数据217也可以包括与数据项216相关联的信息、特性、属性或状态，其不涉及事务。
除了这个硬件回顾以外，对软件组织的安排进行回顾也是有益的。现在参考图3，示出了根据本发明的一实施例的软件架构的框图。如图3中所示，架构250包括用户模式代码260和内核模式代码280两者。一般而言，用户模式代码可以是与要在下层硬件上执行的各种应用相关联的代码(除了运行时间系统代码以外，其可以与具体应用以及操作系统相关联)。一般而言，内核模式代码可以被认为是操作系统代码自身和内核模式异常处置代码。
在UTM操作的实现中，用户模式代码260包括一个或多个UTM应用265。为了处置可能在该代码的执行期间发生的某些事件，用户模式代码还可以包括用户级UTM运行时间系统代码270，该用户级UTM运行时间系统代码270可以是支持UTM应用/环境的软件库的集合并且可以处置在UTM操作期间发生的各种异常或其他事件。在图3示出的示例中，此类代码可以包括弹出处理机。为了处置更多一般操作或可能发生的事件，在UTM应用期间或在另一个用户模式应用期间，用户级OS运行时间系统代码275也可以是支持用户模式应用/环境的软件库的集合。如将在下面所进一步讨论的，此类代码可以有能力为UTM操作期间发生的至少一些异常事件处置控制流。
参考OS代码280，除了用于引导和处置对下层架构(例如，存储器访问等)的各种抽象(abstractions)的常规OS代码285以外，OS代码还可包括内核模式异常处理机290。在各种实施例中，该内核模式代码可以是UTM‑了解的，以便基于对给定UTM模式和环境的认识以及引起到内核模式的转换的事件，该异常处理机可以将控制流指引到用户模式中的适当位置，例如，用户运行时间系统异常分派器处理机、UTM用户运行时间异常分派器(如果存在)和/或弹出处理机。虽然示出图3的实施例中的这个特殊实现，但本发明的范围并不限于此方面。
在相关的硬件、软件以及异常的这个背景讨论下，现在可以考虑当在UTM事务期间发生异常时的处置操作。当在用户级UTM线程中遭遇异常时，发生到内核模式的转换。由于该OS可能需要首先尝试解决该异常(例如当该异常为页面错误(#PF)时)，在决定通过软件定义的UTM事件将这个异常事件传达到该UTM运行时间系统之前，可以关于硬件异常运行该OS代码。也可以存在附加的优势，其在于硬件异常发生时运行该OS代码以及允许该OS代码决定是否生成该UTM软件事件。例如，在支持UTM的OS和运行时间实现中，对于OS来说支持具有多个执行路径(例如，一个用于非UTM代码而其它的用于UTM环境)的用户运行时间环境(包括该异常处理机分派支持)是可能的。这允许该OS根据中断的用户线程的状态选择适当的用户级异常分派器代码，并且对软件定义的事件的使用可以是不必要的。
软件定义的事件本质上允许该UTM运行时间系统代码通过该弹出目标处理机来截取特定异步事件，例如硬件异常。此类事件允许该UTM运行时间系统实现特定策略，以便处置事务执行的中间发生的异常(例如后退到STM方案)、重新启动事务以及通过默认用户运行时间异常分派流处置该异常。
如图4所示，方法300可以用于在用户线程(即线程A)中实施UTM事务，其可以是在用户模式中执行的UTM应用。该UTM事务可以开始于为该UTM的不同特性设置值，并开始执行该事务(块320)。在UTM事务的执行期间，可能生成硬件异常(块325)。例如，可能发生页面错误。
相应地，如图4中所看到的，可以发生至内核模式的环转换(块330)。这个环转换可以引起硬件挂起该UTM事务。此类挂起可以包括挂起用于用户线程的弹出机制。在一个实施例中，可以通过设置该TSR和/或TCR的一个或多个指示符(例如，位)来实现挂起。在挂起时，也可以挂起其他动作(例如隐式读取监视和隐式缓冲)。因此默认存储器读取和写入行为不再创建监视和缓冲UTM特性。相应地，控制被传递到内核模式中执行的OS代码(块340)。由于页面错误异常，该OS异常处理机可以将控制指引到可以被调用的页面错误处理机。在执行该处理机时，OS存储器管理器可以尝试修复该页面错误。如果这没有成功，则该OS可以将该异常抛回到用户模式，例如，由于无效地址。在将该异常发送回用户模式之前，该OS异常处理机可以检查现在的用户状态，其包括该事务状态寄存器。因为UTM事务在该环转换的时间正在处理中，所以这个TSR的分析指示对于线程A该UTM事务未决。相应地，该OS可以将非零值设置到TSR的一个或多个软件事件字段，以指示在UTM事务期间发生的硬件异常。最终，该OS执行中断返回指令(IRET)来将控制返回到线程A。
回到用户模式的该环转换(块350)引起硬件将该UTM事务解挂(desuspend)，例如，通过设置TSR和/或TCR中的一个或多个指示符。当重新开始该UTM事务时(块360)，由于TSR的一个或多个软件事件字段中存在非零值而可以触发弹出。相应地，当在用户模式时，将控制传递到弹出处理机(块370)。该弹出处理机可以包括用于检查TSR中的值并且基于该TSR中存在的软件事件字段实现特定服务操作的代码。具体而言，该弹出处理机可以包括多个代码路径，每条路径用于特定类型的UTM事件。基于TSR中存在的值，可以执行这些路径中的一个。例如，可以存在不同的路径以处置异步UTM事件、同步UTM事件以及软件UTM事件，但本发明的范围不限于这方面。每个此类路径可以包括实现用于处置给定类型事件的策略的代码。尽管在图4的实施例中示出这个特定的实现，但本发明的范围不限于这个方面。
即使上文已描述了用于识别UTM软件事件的发生的硬件实现，也可以实施对相同概念的软件仿真。为实现仿真，取代将非零值设置到TSR中的一个或多个软件事件字段，OS异常处理机可以人工地改变到该UTM服务处理机的返回IP地址并通过软件约定中定义的存储参数传递关于异常的调用原因的信息。
实施例也可以提供硬件支持以及OS算法增强，以最优地支持在UTM事务执行期间发生的信号和异常处置。因此，该OS及其默认运行时间系统可以实现到UTM程序的异常分派流。
在不同的实施例中，当处理器在内核环0OS代码中操作时，硬件机制可挂起该UTM操作模式。这允许OS内核代码(该OS内核代码可以(或可以不)被编译用于UTM硬件操作模式下的操作)正确地执行和操作，而未受用户UTM线程所配置的UTM硬件操作模式影响。当处理器在环0操作时，机制可挂起UTM事务而不引起中止并且动态地跟踪UTM特性的损失以及记录并聚集此类损失事件信息。这样，如果在OS内核代码执行期间没有记录UTM特性损失，则该用户UTM线程可以重新开始并且继续该UTM事务，而无需中止。这个机制也允许以后当OS内核代码返回到用户线程的执行时处置内核模式操作期间发生的UTM特性损失事件。
该UTM运行时间系统及UTM编译器使用由UTM硬件提供的各种UTM模式和操作并且实现UTM事务执行策略。每个UTM硬件操作模式使用为正确地运行UTM事务代码而生成的特定代码路径，以便于通过由UTM架构支持的线内(in‑line)的操作或外线(out‑of‑line)异步处理机调用(例如，弹出处理机)来处置特定UTM特性损失事件。因而，可以存在多个代码路径用于相同的程序流，每个代码路径对应于用于特定UTM操作模式的代码路径。UTM硬件提供多种UTM硬件操作模式，这些UTM硬件操作模式使UTM运行时间系统和UTM编译器能够实现UTM事务执行策略。如上所述，该UTM硬件提供UTM特性(包括监视、缓冲以及元数据)来实现包括事务存储器设计的宽范围在内的多种复杂算法。此类硬件也可以提供UTM事件的概念以及弹出(或其他用户级异步控制转移)机制以允许该UTM运行时间实现用于处置特定UTM特性上的损失事件的软件策略。
因此，内核模式OS异常处置代码可以通过检查该TCR和/或TSR考虑当前UTM事务模式，并且基于这个信息，关于以下项做出最终决定：它是否应该从生成异常的点重新开始，它是否应该将异常抛到默认OS用户模式运行时间代码或它是否应该将控制传递到弹出处理机。
现在参考图5，示出用于在UTM事务期间处置异常或者到OS的其他控制转换的事件的全部序列的流程图。如图5中所看到的，当在用户模式中发生异常时，挂起该事务并且将控制传递到内核模式，更具体地说，传递到内核模式异常处理机410的OS异常处置代码。例如，通过硬件检测到硬件异常状况(例如，除以0)并将硬件异常状况报告给OS内核代码。处理机410可截取该异常并收集异常信息。如所看到的，异常处理机410可以确定OS是否应该尝试解决引起异常的事件(菱形415)。如果该OS确定处置该异常，控制被传递到块420，其中可以执行用于给定类型的异常的OS服务处理机来尝试解决该问题。相应地，可以在菱形425确定是否已经解决该异常。如果是，则可以将控制传递回用户模式。具体而言，该内核可以执行中断返回指令(IRET)以从该IP位置重新开始，该IP位置对应于用户线程的、生成异常所在的点。
仍然参考图5，如果异常处理机选择不允许该OS尝试处置该异常或该异常未被修复，则将控制传递到块430，其中可以准备该异常以便抛回到用户模式。这个准备可以包括识别执行的类型并且收集在异常时间的处理器状态，以生成异常信息。相应地，将控制传递到菱形435，其中可以确定在转换的时间该UTM模式是否已在用户线程中启用。如果不是，则将控制传递到块440，其中可以更新该返回IP地址到默认用户异常分派器。相应地，在这个地址(IRET(B))处将控制传递回到用户模式。在该过程期间，在一个实施例中，该OS收集异常信息并将该异常信息转移到用户堆栈，转换到用户模式，并且将该异常分派到用户模式异常分派处理机。
在该OS处理机不具有UTM系统的更多认识的实现中，到用户模式的该返回同样可以用于UTM事务。然而，在OS处理机是UTM‑了解的实现中，可选地该内核模式代码可以支持从UTM运行时间系统提供的多个用户模式异常分派路径。这多个代码路径可以各对应于具有特定UTM硬件操作模式的不同UTM实现方案。该分派代码路径可以处置来自该OS内核的请求以分派异常到目标处理机，但具有特殊代码插装(code instrumentation)，以便以该UTM实现方案所使用的UTM硬件操作模式正确地操作，如现在所讨论的。
因此如果确定在异常的时间已启用UTM事务模式，则将控制传递到菱形445，其中可以确定当前UTM模式是否要求代码插装。也就是说，异常处理机可以基于它对当前UTM模式的认识以及异常的类型来确定是否需要特殊处理机代码来处置所指示的异常。因此该内核模式代码还可以通过检查TCR和/或TSR来检查当前UTM硬件事务模式，以确定将控制传递到该OS用户运行时间代码是否安全。如果是，则该OS用户运行时间中的该用户模式异常分派代码处置来自该OS内核的请求，以分派异常到该目标处理机。这支持应用程序执行环境中的语言级异常构造。如果不是，如上所述将控制传递到块440。
如果相反指示特殊处理机代码，则将控制传递到菱形450，其中可以确定该UTM运行时间系统是否为当前UTM模式提供代码路径。该确定可以至少部分地基于对OS可用的查找表的分析，其可以指示可用的UTM模式、可能的异常以及UTM运行时间系统中是否存在特殊代码路径用于处置给定异常。在一个实施例中，该表可以包括多个条目，每个条目具有UTM模式、异常类型以及对应的代码路径。基于UTM模式和异常类型的组合，可以选择该条目的代码路径。如果菱形450的确定是肯定的，则将控制传递到块455，其中可以将返回IP地址改变到对应于由UTM运行时间系统提供的用户异常分派代码路径的位置。相应地，在返回地址C(IRET(C))处将控制传递回用户模式。
另外，如果没有特殊UTM运行时间代码路径是可用的，则将控制传递到块460，其中可以更新返回IP，以对应于UTM弹出处理机的位置(块460)。相应地，将控制传递回用户模式(更具体地说经由IRET(D))。在各个实施例中，如将进一步讨论的，该UTM弹出处理机可以实现处置异常(例如后退到STM模式以及重新启动事务)的策略。虽然以这个具体实现示出了图5的实施例，但本发明的范围不限于这个方面。
当图5主要从OS异常处理机的观察点示出操作流时，图6示出了在用户线程中执行UTM事务并且引发到OS的异常时进一步的操作流。一般而言，可以通过使用UTM运行时间系统在用户模式中执行UTM事务(与UTM代码插装一起)。该UTM事务可以开始于对所选硬件操作模式编程(块505)，并开始执行事务(块510)。此类模式可以实现多种UTM实现方案中的其中一个。UTM实现方案的示例包括：高速缓存驻留TM(CRTM)，其中事务适合在高速缓存中；硬件加速STM(HASTM)，其中事务不适合在高速缓存中但是可以将硬件用于过滤和监视；积极硬件加速TM(HATM)，其中仅实施适合在高速缓存中的读取或写入并且其将硬件用于过滤及监视；以及STM，其中事务不使用硬件，而是仅使用软件方案来实现该事务。
仍参考图6，在执行事务期间，可能发生异常(块510)。这个异常可以是任何类型的异常，但是为讨论的目的假设该异常是硬件异常。相应地，将控制传递到块520，其中发生到内核模式的环转换。在该转换之前，硬件可以挂起该UTM事务，包括用于用户线程的弹出机制。接着将控制传递到内核模式，并且更具体地说传递到该内核模式的异常处理机(块530)。
如关于图5的上述讨论，该异常处理机可以解决该异常，或可以不解决该异常。如果该处理机确实解决该异常，则将控制传递回该UTM事务的主块(510)用于连续执行事务。在返回环转换期间(块535)，该硬件可以解挂该UTM事务。由于没有修改或清除UTM事务的特性，所以该事务在其返回点自由地继续操作。
如果相反该异常处理机530不能解决该异常，则可以提供至该用户模式的不同返回路径，例如上文关于图5讨论的。如所看到的，可以将控制传递到与OS用户运行时间相关联的用户异常分派器(块540)。相反，在OS异常处理机是UTM‑了解的实现中，返回可以是至该UTM运行时间系统提供的用户异常分派路径的(块550)。在UTM‑了解的异常处理机的又有的其他实现中，代替将控制传递至UTM用户异常分派路径，相反可以将控制传递至弹出处理机560。因此如所看到的，除了UTM模式的类型、异常类型以及UTM运行时间系统中不同执行路径的有效性以外，根据OS异常处理机的类型，可以将控制从异常处置传递回用户模式内许多不同代码路径中的一个代码路径。
因为在UTM的任意大事务(在时间和存储占用上)期间硬件异常和外部中断可能是不可避免的，因此实施例可以使操作系统能够尝试修复该硬件异常(例如页面错误)，而不会引起对UTM事务的很高昂的中止操作。同时，在该硬件异常不能通过操作系统来修复的情况下，该操作系统可以向该应用提供对异常处置编程的支持，例如，通过将软件定义的UTM事件传送至UTM运行时间系统。类似地，实施例可以使该操作系统能够处置外部中断而不会引起对UTM事务的高昂的中止操作，并且通过允许该操作系统在UTM事务期间通过软件定义的UTM事件将信号事件(signal incident)传递至该UTM运行时间系统，来对于应用允许该操作系统提供对信号编程(例如，UNIX信号)的支持。
如上文在各个实施例中所讨论的，UTM架构可以提供例如监视、缓冲以及元数据之类的硬件特性。这些特征提供软件方式来实现多种复杂算法，包括事务存储器设计的宽范围。可以通过扩展高速缓冲存储器的现存高速缓存协议或者分配专用硬件资源在硬件中实现每个特性。由于可以将这些UTM特性作为对线程而言私有的特性来处置和管理，实施例可以使OS上下文切换代码能够支持这些特性。
不像具有相对较小的固定少量资源的硬件寄存器状态，用于UTM线程的缓冲、监视以及元数据特性的大小是动态的，可以变化并且可以变得比寄存器状态大得多。因此，上下文切换操作的传统策略(其中该OS保存并且还原固定数量的硬件寄存器资源)可能不再工作或如果它为这些动态并且潜在地非常大尺寸的UTM特性而尝试这样做，则变得惊人的代价高昂。
为了避免当OS事件(包括外部中断、页面错误以及OS系统调用)发生时UTM事务的无条件中止以及此类硬件资源的丢弃，当OS上下文切换时，实施例提供机制，以有效地管理大量UTM特性。在不同实施例中，硬件支持可以在内核操作期间挂起该事务并且继续跟踪监视、缓冲和元数据的损失事件。同样地，在具有硬件和OS支持的情况下，可以明确地清除缓冲和监视并且为线程丢弃元数据，并且当在上下文切换后重新开始线程执行时可以生成适合的缓冲和监视损失事件。接着，可以使用硬件和UTM运行时间支持来从缓冲、监视以及元数据损失中恢复。可以提供硬件和软件机制用于处置UTM特性的损失并且该硬件和软件机制可以包括如果发生损失事件则将控制转移至UTM运行时间代码中的预指定IP地址。
代替当发生上下文切换时保存和还原UTM特性，该硬件可以提供用于动态地跟踪监视、缓冲以及元数据特性的损失并且记录以及聚集此类UTM特性损失事件信息的机制。用于记录这些事件的硬件实现的实例可以是TSR，该TSR可以具有位字段来反映已发生的损失事件。可以提供多个位字段，其中每个损失事件位对应于不同UTM特性的损失事件。在状态寄存器中的损失事件位可以根据UTM特性损失事件确定并且在通过软件实施明确的清除操作时才能够被清除。对这个状态寄存器的读取提供在那一时刻所聚集的任何UTM事件的快照。
在一些实施例中，可以通过到特定运行时间地址的异步控制转移或通过借助UTM软件对状态寄存器的明确轮询来处置UTM特性的损失。为了使该操作系统代码安全地实施上下文切换操作而没有意外异步控制转移操作，假定当代码在内核模式中操作时，提供异步控制转移操作的挂起机制。在一个实施例中，当UTM损失事件检测时，弹出机制使到TEJECTIP位置的异步控制转移能够实现。
在实施至新线程的线程切换之前，该操作系统代码实施UTM特性的清除操作。由这个操作引发的所有损失事件都被反映到状态寄存器。在一个实施例中，可以通过某些用户级指令的组合来提供这个操作，例如，事务清除(TCA)指令(清除具有聚集的缓冲和监视)以及清除元数据(CLMD)指令(清除所有元数据)。由这些操作引发的损失事件可以被反映到TSR寄存器中的对应的指示符(例如，状态位)。
当该操作系统代码在从内核模式返回到用户模式的时候重新开始执行UTM线程时，可以利用到UTM运行时间代码的特殊控制转移机制来触发可以是UTM运行时间特定的恢复策略代码的执行。备选地，该操作系统代码可以明确地改变该用户线程的返回IP地址来指向处置UTM特性的损失的特殊用户运行时间代码。当异步转移硬件机制不可用，并且改为软件负责人工地轮询该TSR寄存器以寻找损失事件以及在检查点上采取必要动作时，可以实现当上下文切换之后从内核返回时的这个备选的UTM运行时间转移机制。
因此，实施例提供机制以有效地管理大量按照线程的硬件事务状态(例如，UTM特性)并且因此允许UTM的硬件加速。
现在参考图7，示出了根据本发明的实施例的用于处置上下文切换操作的方法的流程图。如图7所示，方法600示出了用户模式中实施的各个操作(例如在用户模式中执行的不同线程，即执行UTM应用的第一线程(即，线程A))以及执行非UTM应用的第二线程(即，线程B)。另外，存在实施OS操作的内核模式，该OS操作包括对这些模式之间的线程切换进行处置。如在图7中所看到的，方法600可以开始于在第一线程中执行UTM应用(块610)。这个UTM事务可以开始并且可以为该事务创建各个UTM特性(例如缓冲、监视以及元数据)。在事务的过程期间，可能发生定时器中断。相应地，发生将控制传递到内核模式的环转换615。然而，取代中止该事务，该事务可以被挂起，例如，通过在TSR中设置一个或多个不同的指示符，包括挂起弹出处理机的执行。
相应地，控制传递到内核模式，其中该OS实施动作以便处置上下文切换(块620)。此类动作可以包括执行某些用户级或其他指令以清除这些UTM特性。另外，可以在TSR中设置用于这些操作的指示符(例如，特性损失指示符)。然后，该OS可以保存该第一线程的上下文。这个上下文可以包括UTM状态，其包括TSR寄存器。为了能够实现该上下文切换，该OS还将该第二线程的上下文还原至机器状态。相应地，控制传递到该第二线程用于执行它的应用(块625和630)。相应地，该线程可以继续，例如，直到它命中定时器或其他中断，这再一次引起环转换回到内核模式(块635)。现在，该OS实施操作以使上下文能够切换回该第一线程(块640)。这些操作可以反映出上文关于块620所讨论的那些。然而，注意，当清除UTM特性时，因为当第二线程执行非UTM应用时没有在第二线程中设置此类特性，所以没有为与第二线程相关联的TSR更新事件损失指示符。
仍然参考图7，在块645中，发生了另一个环转换以将控制返回到线程A。在块650处，线程A可以重新开始执行。在一个实施例中，当与这个线程相关联的TSR指示该损失事件时，这个重新开始的执行可以包括跳转到弹出处理机。相应地，该弹出器可以执行恢复代码，以便处置损失的事件。当本发明的范围不限于这个方面时，此类恢复代码可以包括重新启动事务，在另一个UTM模式中执行等等。尽管在图7的实施例中示出这个具体实现，但本发明的范围不限于这个方面。
可以在很多不同的系统类型中实现实施例。现在参考图8，示出了根据本发明一实施例的系统的框图。如图8中所示，多处理器系统700是点对点互连的系统，并且包括经由点对点互连750耦合的第一处理器770和第二处理器780。如图8中所示，处理器770和780中的每一个处理器可以是多核处理器，包括第一处理器核和第二处理器核(即，处理器核574a和774b以及处理器核784a和784b)，然而，在处理器中可以潜在地存在更多的核。这些处理器核可以执行不同UTM线程并且可以能够在控制方面转换到内核模式之后维持事务，潜在地避免了中止该事务的需要。
仍然参考图8，第一处理器770还包括存储器控制器集线器(MCH)772和点对点(P‑P)按口776和778。类似地，第二处理器780包括MCH 782和P‑P接口786和788。如图8中所示，MCH的772和782将处理器耦合到相应的存储器，即存储器732和存储器734，它们可以是本地地附连到相应处理器的主存储器(例如，动态随机存取存储器(DRAM))的一部分。第一处理器770和第二处理器780可以分别经由P‑P互连752和754耦合到芯片组790。如图8中所示，芯片组790包括P‑P接口794和798。
此外，芯片组790包括通过P‑P互连739将芯片组790与高性能图形引擎738耦合的接口792。芯片组790又可以经由接口796耦合到第一总线716。如图8中所示，各种输入/输出(I/O)设备714可以和总线桥718一起耦合到第一总线716，该总线桥718将第一总线716耦合到第二总线720。在一个实施例中，各种设备可以耦合到第二总线720，包括，例如，键盘/鼠标722、通信设备726以及数据存储单元728(例如可以包括代码730的磁盘驱动器或其他海量存储设备)。此外，音频I/O 724可以耦合到第二总线720。
可以用代码实现实施例并且可以存储在其上存储了指令的存储介质上，该指令可以用于对系统编程以便实施这些指令。该存储介质可以包括，但不限于，任何类型的盘(包括软盘、光盘、光盘、固态驱动器(SSD)、压缩盘只读存储器(CD‑ROM)、可重写压缩盘(CD‑RW)以及磁光盘)、半导体设备、例如只读存储器(ROM)、随机存取存储器(RAM)(例如动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM))、可擦除可编程只读存储器(EPROM)、闪速存储器、电可擦除可编程只读存储器(EEPROM)、磁卡或光卡、或适合存储电子指令的任何其他类型的介质。
尽管已经相对于有限数量的实施例描述了本发明，但本领域内的技术人员将由此认识到很多修改和变形。随附的权利要求书打算覆盖落入本发明实质精神和范围内的所有此类修改和变形。