用于受应用管理的线程单元的结构化异常处理

摘要

提供了用于在多线程系统中对用户级线程进行结构化异常处理的方法、数据结构、指令和技术。可以将已注册过滤例程分派到不受操作系统(OS)管理的线程单元。可以通过使受OS管理的线程单元(代理)代表隔离的线程单元来调用由OS提供的结构化异常处理服务(包括分派程序)而发生所述分派。作为选择，受OS管理的线程单元可以包括分派代码，并且可以无需OS干预就将过滤例程分派到隔离的线程单元。还描述和声明了其它实施例。

说明书

技术领域

本公开总体上涉及信息处理系统，更具体地，涉及用于多线程系 统中用户级线程的结构化异常处理。

背景技术

为了提高诸如那些包括微处理器的信息处理系统的性能，已经采 用了硬件和软件的多线程技术。多线程逐渐得到硬件上的支持。例如， 在一种方式中，多处理器系统(诸如单芯片多处理器(“CMP”)系统) 中的处理器每个都可以并发地运行多个软件线程中的一个。在被称为 并发多线程(“SMT”)的另一种方式中，对于操作系统和用户程序而 言，单个物理处理器看起来像是多个逻辑处理器。对于SMT，在单 个处理器上，多个软件线程可以同时是活动的并可以同时执行，而无 需切换。也就是，每个逻辑处理器维护完整的一组架构状态，但是该 物理处理器的许多其它资源都是共享的，比如高速缓存、执行单元、 分支预测器、控制逻辑和总线。因此，对于SMT来说，来自多个软 件线程的指令并发地在每个逻辑处理器上执行。

对于诸如SMT和/或CMP系统这样的支持多个软件线程的并发 执行的系统而言，操作系统应用程序可以控制(多个)线程执行资源上 软件线程的调度和执行。然而，不受操作系统控制的其它线程执行资 源对于程序员来说也可以是可用的并且可以由用户级代码来控制。普 通操作系统并未提供数据结构来维护用于可在这些资源上执行的用 户级线程的本地数据。

附图说明

参考下列附图，可以理解本发明的实施例，在附图中相似的单元 用相似的数字标明。这些附图并不是要进行限制，而是用来说明用于 多线程系统中的用户级线程的结构化异常处理的数据结构和技术的 选定实施例。

图1是说明多定序器(multi-sequencer)系统的各种实施例的框图。

图2是展示用于多定序器系统的一般并行编程方法的图形表示 的框图。

图3是说明对于用户级多线程的至少一个实施例，在线程和用户 级线程之间的共享存储器和状态的框图。

图4是说明用来在多线程系统中维护线程特有的本地数据的机 制的至少一个实施例的块数据流程图。

图5是说明结构化异常处理所利用的数据结构的至少一个实施 例的框图。

图6是说明用来为包括一个或多个隔离的定序器的多线程系统 维护shred特有的本地数据的机制的框图。

图7是说明结构化异常处理的方法的至少一个实施例的数据流 程图，对于在与操作系统隔离的线程单元上发生的异常，该方法绕过 了该操作系统。

图8是说明结构化异常处理的第一种方法的至少一个实施例的 数据流程图，其中，一个线程单元作为代理来调用系统资源，以用于 在与操作系统隔离的线程单元上发生的异常。

图9是说明能够执行所公开的技术的系统的至少一个实施例的 框图。

具体实施方式

以下论述描述了对于既非由操作系统创建也非由其进行管理、而 是由用户级代码创建和管理的用户级线程，提供结构化异常处理的方 法、系统、数据结构、装置和机制的选定实施例。

这样的用户级线程(在这里有时被称作共享资源线程(shared resource thread)或“shred”)是程序员可以基于用户级代码中的指令而 使其执行的指令序列。多个shred可以与同一个由OS生成的或“原 生的(native)”线程相关联并且可以并发地执行。对于至少一个实施例 而言，shred被进行调度以运行在可用的硬件资源上(例如，通过软件 库中的或存在于用户空间中的调度程序(scheduler)来进行)，而无需操 作系统的干预。在此所述的实施例可以被用于单核或多核的多线程系 统。

如这里所使用的，线程单元(在此还可互换地被称作硬件线程上 下文(context)或“定序器”)可以是能够执行线程或shred的任何物理 或逻辑单元。

在以下说明中，阐述了诸如处理器类型、多线程环境、系统配置、 数据结构以及特定操作系统和结构化异常处理过程这样的大量具体 细节，以提供对于本发明的实施例更为彻底的理解。然而，本领域技 术人员将意识到，本发明可以无需这些具体细节来实现。另外，没有 详细示出一些公知的结构、电路等，以免不必要地使本发明变得晦涩。

图1是说明支持线程的用户级控制的多定序器系统的实施例 310、350的选定硬件特征的框图。图1说明了单核多定序器多线程 环境310的选定硬件特征。图1还说明了多核多线程环境350的选定 硬件特征，在该环境中每个定序器是单独的物理处理器核心。

在单核多线程环境310中，对于操作系统和用户程序来说，单个 物理处理器304被看作是多个逻辑处理器(未示出)，在此被称作LP₁至LP_n。每个逻辑处理器LP₁至LP_n分别维护完整的一组架构状态 AS₁-AS_n。对于至少一个实施例而言，架构状态312a、312b可以包括 数据寄存器、段寄存器、控制寄存器、调试寄存器和大多数模型特有 的寄存器。

逻辑处理器LP₁-LP_n共享物理处理器304的大多数其它资源，诸 如高速缓存、执行单元、分支预测器、控制逻辑和总线。虽然可以共 享这些特性，但是多线程环境310中的每个线程上下文能够独立生成 下一个指令地址(并且例如从指令高速缓存、执行指令高速缓存或轨 迹高速缓存中进行读取(fetch))。

因此，处理器304包括用于每个线程上下文的逻辑上独立的下一 指令指针和读取逻辑320，即使在单个物理读取/解码单元322中可以 实现多个逻辑定序器也是如此。下一指令指针和读取逻辑320用于确 定对于给定线程或shred的要执行的下一个指令。

对于单核实施例，定序器因而可以是逻辑线程单元。在此情况下， 术语“定序器”至少包括用于一个线程上下文的下一指令指针和读取 逻辑320、以及用于该线程上下文的至少一些相关架构状态AS 312。 应当注意的是，单核多线程系统310的定序器不需要是对称的。例如， 用于同一个物理核心304的两个逻辑定序器在它们每个所维护的架 构状态信息量上可以是不同的。

单核多线程系统能够实施任意多线程方案，包括并发多线程 (SMT)、事件切换多线程(SoeMT)和/或时间复用多线程(TMUX)。当 来自多于一个硬件线程上下文(或逻辑处理器)的指令在任意特定时 间点上在处理器中并发运行时，称作SMT。否则，单核多线程系统 可以实施SoeMT，其中在多个硬件线程上下文之间复用处理器管道， 但是在任意给定时间，仅有来自一个硬件线程上下文的指令可以在所 述管道中执行。对于SoeMT而言，如果线程切换事件是基于时间的， 则其为TMUX。

因此，对于至少一个实施例而言，多定序器系统310是支持并发 多线程的单核处理器304。对于这样的实施例而言，虽然单个处理器 核心304的相同执行资源可以在并发执行的线程之间共享，从而同一 个核心304执行并发线程的所有指令，但是每个定序器是一个逻辑处 理器，其具有自己的下一指令指针和读取逻辑320以及自己的架构状 态信息312。

图1还说明了多核多线程系统350的至少一个实施例。这样的系 统350包括两个或更多单独的物理处理器304a-304n，其每个都能够 执行不同的线程/shred，以使得可以同时进行不同线程/shred的至少部 分的执行。每个处理器304a到304n均包括物理独立的读取单元322， 用来读取其各自的线程或shred的指令信息。对于其中每个处理器 304a-304n执行单个线程/shred的实施例而言，读取/解码单元322实 现了单个下一指令指针和读取逻辑320。

然而，对于至少一个实施例而言，每个处理器304a-304n支持多 个线程上下文；也就是说，每个处理器304a-304n可以是如实施例 310中所示的多线程单核处理器。对于这样的实施例而言，系统350 中的每个核心304的读取/解码单元322对于每个所支持的线程上下 文，实现了不同的下一指令指针和读取逻辑320，并且每个线程上下 文维护架构状态(AS)的单独拷贝。多处理器环境350中附加的下一指 令指针和读取逻辑320以及架构状态的附加拷贝的可选特性由图1中 的虚线所表示。

对于图1所示的多核系统350的至少一个实施例而言，每个定序 器可以是一个处理器核心304，而在单芯片封装360中存在多个核心 304a-304n。如以上刚刚所述的，每个核心304a-304n可以是单线程 或多线程的处理器核心。在图1中由虚线表示的芯片封装360指示出， 所说明的多核系统350的单芯片实施例仅仅是说明性的。对于其它实 施例而言，多核系统的处理器核心可以存在于分离的芯片上。也就是 说，所述多核系统可以是多插槽(multi-socket)对称多处理系统。

为了便于讨论，以下讨论聚焦于多核系统350的实施例。然而， 该聚焦不应当被看作是限制性的，其中以下所述的机制可以在多核或 单核多定序器环境中执行。

图2是说明多定序器多线程系统上的并行编程方法的图形表示 的框图。共享存储器的多处理范例可以被用在被称作并行编程的方法 中。根据该方法，应用程序员可以通过要并发运行的多个线程而在软 件程序(有时被称作“应用”或“进程”)中表现并行性。同一软件程 序(“进程”)的所有线程共享公共的存储器逻辑示图。

图2说明了对于操作系统(“OS”)140可见的进程100、103、 120。这些进程100、103、120可以是不同的软件应用程序，例如字 处理程序、图形程序和电子邮件管理程序。一般来说，每个进程运行 在不同的虚拟地址空间中。

操作系统(“OS”)140一般负责管理一个进程的用户定义任务。 虽然每个进程具有至少一个任务(例如，见由附图标记100和103分 别表示的进程0和进程2)，而其它进程可以具有多于一个的任务(例 如，由附图标记120表示的进程1)。图2所示的进程数目以及每个进 程的用户定义任务的数目不应当被看作是限制性的。这样的说明仅仅 是出于解释的目的。

图2说明了可以由操作系统140来创建用于与进程120相关联的 每个用户定义任务的不同线程125、126，并且操作系统140可以将 线程125、126映射到线程执行资源。类似地，可以由操作系统140 来创建用于与进程103相关联的用户定义任务的线程127；以及用于 与进程0(100)相关联的用户定义任务的线程124。

OS 140一般负责对这些线程124、125...126、127进行调度以在 执行资源上执行。与同一进程相关联的线程具有相同的虚拟存储器地 址空间。

由于OS 140负责创建、映射和调度线程，所以线程124、 125...126、127对于OS 140是“可见的”。此外，本发明的实施例包 括对OS 140不可见的附加的用户级线程130-139。也就是说，OS 140 并不创建、管理或另外控制这些附加的用户级线程130-139。

不由OS 140创建和控制、并且可以被调度以便彼此并发执行的 这些附加线程在这里有时被称作“shred”130-139，以将它们与OS 可见线程进行区别，并且进一步将它们与针对同一个OS可见线程的 不能彼此并发执行的其它用户级线程进行区别。也就是说，与同一个 OS可见线程相关联的多个shred可以彼此并发执行。

shred由用户级程序(被称作“shred化程序(shredded program)”) 创建和管理，并且可以被调度以在与操作系统隔离的定序器上运行。 隔离的定序器不由操作系统来管理，而是由用户级应用代码来管理。 例如，图2所示的受OS管理的线程125可以在对于OS可见的一个 定序器(未示出)上执行，而每个活动shred 130-132可以在其它的、与 OS隔离的、不受OS管理的定序器(例如，分别见图3的“seq 1”- “seq 4”)上执行。对于与OS隔离的定序器而言，由用户级调度程 序来调度指令流以用于执行。由此，与OS隔离的定序器由用户级应 用而不是OS来管理，因此在此被称作“受应用管理的定序器”或 “AMS”。

图2说明了与一个受OS调度的线程127相关联的一个进程103， 还说明了与两个或更多线程125-126相关联的另一个进程120。此外， 每个进程103、120还可以分别与一个或多个shred 137-139、130-136 额外相关联。图2中使用虚点线和省略号来表示可选的附加shred。

进程1(120)的两个线程125、126和四个shred130-136的表示以 及进程2(103)的一个线程127和两个shred 137、139的表示仅仅是说 明性的，而不应当被看作是限制性的。本发明的实施例无需为与一个 进程相关联的线程或shred数目施加上限或下限。至于线程的下限， 图2说明了在给定时间运行的每个进程与至少一个线程相关联。

然而，线程根本无需与任何shred相关联。因此，没有为shred 施加下限。例如，图2中所示的进程0(100)被示出为在图2所示的 特定时间上运行时，有一个线程124，而没有任何shred。

至于上限，与一个进程相关联的OS可见线程的数目可以由OS 程序来限定。然而，对于至少一个实施例而言，与一个进程相关联的 shred的累积数目的上限仅由在执行期间特定时间上可用的shred执 行资源的数目(例如，定序器的数目)来限定。

图2说明了与进程120相关联的第二线程126可以具有与其相关 联的、与第一线程125不同数目(n)的shred。附加的shred的可选特 性在图2中由省略号和虚线来表示。

与程序或进程的所有线程相关联的存储器公共逻辑示图可以在 此被称作“应用图像”。对于本发明的实施例而言，该应用图像也由 与一个进程相关联的shred所共享。

图3是说明了在进程、线程和shred之间的共享存储器状态的一 个例子的框图。图3示出了图2所示的进程120、线程124、125、126， 和shred 130-132的图形表示。同样参照图2，在下面讨论图3。

图3说明了，由与特定进程120相关联的所有线程125、126共 享存储器的特定逻辑视图200。与OS隔离的定序器维护与OS可见 的定序器上一样的一组ring 0状态。典型地，这些共享的ring-0架构 状态负责支持在OS可见的定序器和与OS隔离的定序器之间的公共 的共享存储器地址空间。例如，对于基于IA-32架构的实施例而言， CR0、CR2、CR3和CR4是这些共享的ring-0架构状态中的一些。因 此，shred共享为与同一个进程相关联的线程创建的同样的执行环境 (虚拟地址映射)。

图3说明了，每个线程125、126分别具有其自己的应用和系统 状态202a、202b。图3说明了，线程125、126的应用和系统状态202 由与该特定线程相关联的所有shred(例如，shred 130-132)所共享。 例如，对于至少一个实施例而言，与特定shred相关联的所有shred 可以共享ring 0状态以及至少部分与特定线程相关联的应用状态。

因此图3说明，用于本发明至少一个实施例的系统可以支持OS 可见线程(例如线程125)和与该线程相关联的shred 130-132(其对于 OS不可见)之间的一对多关系。程序员(而非OS)可以采用用户级技术 来创建、同步以及另外管理和控制shred的操作，就这方面而言，这 些shred对于OS(见140，图2)是不“可见的”。虽然OS 140知道并 管理一个或多个线程125...126，但是OS 140不知道并且不管理或控 制这些shred。如这里所使用的，术语“线程”和“shred”至少包括 这样的概念，即其为要与一个进程的其它线程和/或shred并发执行的 一组指令。如这里所使用的，线程(其是受OS控制的)与shred(其对 于操作系统是不可见的并且由用户所控制)均为指令流，它们之间的 区别点在于在如何管理各自的线程和shred指令流的调度和执行上的 不同。响应于对OS的系统调用而生成线程。OS生成该线程并且分 配资源来运行该线程。为线程分配的这些资源可以包括操作系统用来 控制和调度所述线程的数据结构。

相比之下，shred的至少一个实施例是通过用户级软件“原语 (primitive)”所生成的，所述用户级软件“原语”调用一种独立于OS 的机制，其用于生成和调度OS不知道的shred。因此，可以响应于 用户级软件调用而生成shred。对于至少一个实施例而言，用户级软 件原语可以包括用户级(ring-3)指令，所述用户级指令调用硬件或固件 来创建shred。这些指令可以被定义为处理器的指令集架构(ISA)的一 部分。

这样所创建的shred可以由硬件和/或固件和/或用户级软件来调 度。所述独立于OS的机制可以是位于用户空间(比如软件库)中的软 件代码。因此，无需依赖操作系统来管理线程单元硬件和shred之间 的映射，用户空间中的调度程序逻辑可以管理所述映射。可以在名为 “A Mechanism For Instructions Set-Based Thread Execution on a Plurality of Instruction Sequencers”的共同未决专利申请美国专利序列 号No.11/173326中找到用户级shred指令的进一步讨论。

应当注意的是，能够执行这里所公开的技术的实施例的系统的定 序器无需是对称的。定序器可以以任意方式而不同，包括影响计算质 量的那些方面。例如，所述定序器可以在功耗、计算执行速度、功能 特征等方面有所不同。

在以下部分给出了关于受OS管理的线程的结构化异常处理的背 景信息。其后给出根据本发明的用于shred的结构化异常处理的所选 实施例。

图4是说明现有技术的对运行在受OS管理的定序器上的受OS 管理的线程的数据管理机制的框图。受OS管理的定序器430在此被 称作“OMS”。

图4说明了线程环境块或“TEB”545a、545b，其是由操作系统 (例如，见图2的140)所创建和维护的数据结构，用于多线程应用中。 对于特定系统而言，TEB 545a、545b可以被称作其它名称，例如线 程信息块或线程控制块。为了便于讨论，结构545a、545b在这里被 称作TEB，但是本领域技术人员将认识到，结构545a、545b的表示 旨在包含任何相似结构，而不管特定系统的命名方式。

对于至少一些普通系统而言，诸如结构化异常处理这样的关键操 作系统服务依赖于每个线程的TEB数据结构545a、545b的存在。

结构化异常处理(SEH)是OS提供的服务，补充以来自编译器的 支持，用于处理在程序执行期间发生的异常事件。控制被反映回到其 中发生异常事件的应用，以使得由所述应用而不是OS对异常进行处 理。例如，这些异常事件可以包括：在非特权模式中时试图执行特权 指令(一般保护故障)、除0错误、空指针访问(页面故障)等。应用可 以依靠结构化异常处理工具以帮助调试在执行期间发生的致命事件， 以在未预料到的终止事件中清理重要数据结构，并且适当地从故障状 况中恢复以继续执行。此外，一些应用甚至可以将SHE工具用作正 常操作的一部分；例如，Java虚拟机可以使用SHE工具对客户应用 的字节代码进行动态优化。

图5说明了用于运行在OMS 430上的受OS管理的线程(例如， “T”)的结构化异常处理记录的至少一个普通实施例。如上所述，应 用程序员可以在代码中利用结构化异常处理，来促进用户提供的对于 在用户模式中执行所述代码时发生的某些异常事件的处理，而不是依 靠操作系统140运行默认处理程序(handler)来处理所述异常。

通常，为了调用结构化异常处理，应用程序员可以在代码中包括 指令，所述指令向OS 140注册了一个过滤例程。继而，OS 140在所 述代码的执行期间遇到用户模式中的异常时分派(dispatch)所述过滤 例程，从而允许用户模式应用自己来处理在该应用执行时发生的异 常。应用可以通过注册和注销不同过滤例程，选择处理或“捕获 (catch)”在执行过程期间的不同异常。用于管理这些异常的准确机 制依赖于操作系统140和编译器(未示出)的特定实现。一种处理这些 异常的普通实现方式是由微软的WINDOWS操作系统所提供的结构 化异常处理工具。虽然以下的讨论基于微软WINDOWS SEH工具， 但是本领域技术人员将认识到，以下所讨论的机制还可以被应用于其 它的用户级异常处理机制。

图5说明了，TEB 545的字段之一可以是指向一个或多个异常注 册记录1050的指针1045。所述异常注册记录可以是单个记录，或多 个记录1055a、1055b...1055n的结构(表格、阵列、链表)。对于至少 一个实施例而言，注册记录1050可以是记录1055的链表1060，每 个记录1055指向一个异常处理例程。多个记录1055a、1055b...1055n 中的每一个可以包括指向一个异常过滤例程的指针580和下一记录 指针585，以及一些附加的元数据575。

操作系统140提供基本的SEH工具，但是依赖于应用程序和编 译器来定义和注册过滤例程。所述编译器可以提供语法(syntax)，所 述语法可以由应用程序员使用来注册与“被看护的(guarded)”代码块 相关联的异常过滤例程。例如，一些编译器提供“_try{}”子句来描 绘可能引起异常的代码块，并且提供对应的“_except{}”子句来关联 在所描绘的代码内发生异常时应当执行的用户级异常处理程序。应用 程序员可以使用编译器的try/except语法将异常过滤程序(filter)插入 或“注册”到由TEB 545所指向的链表1060中。

一旦遇到异常，操作系统调用其所有注册的过滤程序的列表中的 第一个异常过滤程序。该异常过滤程序使应用具有第一个机会来校正 所述异常的起因、或者开始清理重要的数据结构。从异常过滤程序的 返回将OS指向以下三个路径之一：在故障/陷阱处继续执行，继续在 你的列表中查找适合的异常过滤程序，或执行异常处理程序。

由try/except语法所指定的该注册处理被变换为直接从TEB 545 读取以及向其写入。一旦遇到异常，OS 140的SEH服务就搜索用户 提供的异常处理程序的链表1060，来确定下一个动作过程。

因此，应用和系统库可以协作来维护用于每个线程的异常注册记 录1055的列表1060。编译器140可以将应用的try和except语句翻 译为向/从列表1060插入/去除异常注册记录1055的代码。线程的异 常注册记录列表1060的表头(head)(见1055a)涉及当前活跃的记录， 并且被所述线程的TEB 545所指向(见1045)。

将新的异常注册记录1055插入列表1060包括，将新记录的下一 记录指针585指向列表1060的表头(1055a)，将新记录1055添加到堆 栈(未示出)，并接着将TEB 545中的列表1045的表头更新为指向新 记录1055。

从列表1060中去除异常注册记录1055包括，将TEB 545中的列 表(1045)的表头更新为指向列表1060中的下一记录(1055b)。

其实，异常记录1055的列表1060表示嵌套的(nested)过滤例程， 其中列表1060的表头涉及当前活跃的异常注册记录1055，而每个后 续记录1055是前一个记录的父记录(parent)。为了简单，术语“异常 注册记录”和“注册记录”在此可互换使用。

简要地回到图4，其示出了在计算系统的至少一些实施例上操作 系统140如何管理TEB数据结构545。图4示出分别为每个原生线程 (线程1和线程2)创建唯一的TEB结构545a、545b。处理器的一个寄 存器440指向当前执行的线程的TEB结构545。例如图4所示，假设 线程1是当前执行的线程。一旦发生上下文切换，490，OS(见140， 图5)令寄存器440指向第二个线程的TEB 545b。图4还示出了指针 1045，其指向用于每个线程(线程1和线程2)的SEH异常注册记录列 表1060的表头；该指针包含在TEB数据结构内。

现在回到图5。由此，图5所示的结构化异常处理机制510是 OS支持的动态机制，其允许注册一过滤处理例程，该例程要被调用 以将控制从操作系统140转移到用户级异常处理程序。然而，由于 OS 140并不为在与OS隔离的定序器460上运行的shred提供TEB 545，所以图5所示的机制510不支持用于shred的SEH。

也就是说，图5所示的TEB 545已经被操作系统140分配用于主 线程T。然而，图5还说明了，操作系统140没有为在隔离的定序器 460(分别是“Seq 1”和“Seq 2”)上运行的两个shred(S1和S2)中的 任何一个分配TEB，原因在于它们对于OS 140是不可见的。

现在参考图6，它是说明用于多shred系统410中的shred本地数 据的数据管理机制的至少一个实施例的框图。图6所示的多shredding 系统410的实施例包括一个或多个OMS定序器430，它们对于操作 系统140是可见的并且由操作系统140所控制。

图6说明了，多shredding系统410还包括一个或多个与操作系 统140隔离的定序器(Seq 1、Seq 2)。隔离的定序器(Seq 1、Seq 2)在 图6中被统称作受应用管理的定序器(“AMS”)460。

因此，系统410可以包括可由应用开发人员的软件代码管理的多 个定序器460，其处于操作系统控制之外。开发人员可以在其代码指 令中进行利用，所述代码指令能够导致在隔离的定序器460上创建和 并发执行指令流或“shred”。运行在与OS隔离的定序器460上的shred 一般不能访问有效的TEB实例545，原因在于操作系统140典型地仅 在创建原生线程时保存TEB 545的实例，但是对于shred并不如此。

对于至少一个实施例而言，图6所示的定序器430、460在功能 上可以有所不同。图6所示的功能不对称的示例示出，至少一个定序 器430对于OS 140可以是可见的，并且由此能够执行“ring 0”操作， 例如执行系统调用、为页面故障提供服务等。

在另一方面，一个或多个其它定序器460可以与OS 140隔离， 并且由此不能够执行ring 0操作。然而，这仅仅是功能不对称的一个 示例。多定序器系统410中的定序器430、460还可以以任何其它的 方式有所不同，例如尺寸、字和/或数据路径大小、拓扑、存储器、 功耗、功能单元数目、通信架构(多点总线vs.点对点互连)、或者任 何其他关于功能性、性能、覆盖区(footprint)的度量等。

对于图6所示的示例实施例而言，每个隔离的定序器460被初始 化为能够执行与一个线程相关联的shred(例如，S1和S2)。图6所示 的示例示出了已经由运行在OS可见的定序器430上的线程T所生成 的两个shred S1和S2。shred S1和S2已经被调度，以分别在隔离的 定序器Seq 1和Seq 2上执行。

因为图6所示的系统410允许程序员管理shred S1和S2在操作 系统140控制之外的AMS定序器Seq 1、Seq 2上的执行，所以系统 410包括一种机制，其创建和管理数据结构442来维护用于shred S1、 S2的shred本地数据。这样的数据结构在此被称作shred环境块 (“SEB”)442(1)、442(2)。

对于shred环境块442的结构、组织和管理有许多选择。对于在 此所述的实施例，设计所述结构、组织和管理，带有所关注的一些特 定目标。

第一个目标是，设计了在此所述的SEB 442的实施例的结构，以 便模仿公知的TEB 545结构的设计。以这种方式，熟悉TEB 545的 程序员无需大量的额外努力就可以理解SEB 442的结构。因此，SEB 442中每个字段的位置均模仿TEB 545中这些字段的组织。

第二个目标是，设计了在此所述的SEB 442的实施例，以便支持 对用户级shred的结构化异常处理。图6说明了，SEB结构442可以 包括一个字段，以便以与上面结合图5所讨论的相类似的方式来支持 结构化异常处理。SEB结构442在一个具有与TEB结构545中相同 偏移的字段中可以包括指向用于该shred的一个或多个异常注册记录 765的指针745。应用程序可以直接从SEB 442读取以及向其写入， 来维护注册记录的列表。如前所述，编译器所提供的try/except语法 还可以被程序用来将异常处理程序插入或“注册”到由SEB 442中的 指针745所指向的记录765。由try/except语法所指定的该注册处理 被变换为直接从SEB 442读取以及向其写入。

当发生异常时，OS 140的SEH服务144搜索用户提供的异常处 理程序的链表来确定下一个动作过程。{应当注意的是，对于至少一 个实施例而言，OS 140的SEH服务144运行于用户级的特权级别， 例如ring 3}。以这种方式，SE B 442维护可以被用来支持用于用户 级shred的结构化异常处理的数据。

以下部分所公开的是可以被用来支持用于shred的SEH的两种不 同方法的实施例。以下所讨论的第一种方法绕过OS并且完全在用户 空间中执行用于shred的SEH。以下所讨论的第二种方法利用了代理 执行，以调用OS从而代表与该OS隔离的AMS来执行特定的SEH 处理。

图7是说明方法700的至少一个实施例的流程图，所述方法用于 对在隔离的AMS上发生的异常调用结构化异常处理，其中所述处理 完全绕过操作系统。图7进一步说明了用于处理用户级异常的方法 780。对于至少一个实施例而言，调用方法700可以由运行在受应用 管理的定序器(AMS)上的应用来执行，处理方法780可以由运行在受 OS管理的定序器(OMS)上的处理例程790来执行。

图7说明了，用于调用基于应用的结构化异常处理的方法700可 以开始于框701，并进行到框702。在框702，执行运行在AMS上的 shred的下一指令。

如果所述指令将导致从用户特权级别(例如ring 3)转变到受限特 权级别(例如ring 0)，则在框704，可以检测到可能的转变。ring级别 的转变仅仅是可以触发结构化异常处理的事件类型的一个示例，并且 不应当被认为是限制性的。其执行会触发异常的任何指令均可以导致 框704的判定框被评价为“是”。

对于至少一个实施例而言，在框702执行指令会导致可能满足一 个场景(scenario，以下解释)的处理器状态，其继而会触发将控制异步 转移到处理程序代码790。如果在框704检测到可能的特权级别转变 或其它异常，则处理进行至框706，在那里控制被转移(见转移“1”) 到用于所检测的特定场景状况的适当处理程序代码790。如果满足特 定的状况(场景)集合，则可以响应于一个或多个实现控制转移的指令 来转移这样的控制。如果没有，则处理返回框702，并且方法700继 续，直至到达shred的末尾。

关于“场景”，假定对于至少一个实施例而言，执行方法700的 AMS支持用户级的异步信号通知。这样的信号通知机制的特定实施 例进一步在共同未决的申请序列号11/395884，“A Programmable Event-Driven Yield Mechanism”以及11/134687，“A Programmable Event Driven Yield Mechanism Which May Activate Service Threads”由 描述。

用户级异步硬件机制可以直接向运行在微处理器上的用户级线 程报告特定的事件或状态、或者事件或状态的组合(在这里被称作“场 景”)，而无需传统的由操作系统进行干预。(见框704的用户级线程 的事件检测)。

这样的用户级中断或用户级异常基于一种硬件机制，所述硬件机 制保存关于线程的当前状态的充分信息并且使所述线程改变为执行 “处理程序”代码790的预定块来响应事件。(见框706)。作为处理 程序代码790的一部分，所述线程能够执行其希望进行的任何工作并 且接着返回其在事件之前所在的执行路径(见控制788的返回)。作为 选择，所述处理程序代码可以选择不返回所述执行路径，而是继续进 行完全不同的任务集合。

这样，图7说明了在框706，在检测到异常704时控制被转移(见 转变“1”)到处理程序代码790，所述异常包括执行需要ring转变的 指令。处理程序代码790对应于在框704所检测的特定异常。对于至 少一个实施例而言，处理程序代码790可以存在于不同的定序器上， 而不是存在于调用该处理程序的那个定序器上。

图7说明了，在处理程序代码790中提供结构化异常处理的方法 780的处理过程开始于框712，其被归为处理程序代码指令的一部分， 在此被称作处理程序代码790的开场部分(prologue)710。在框712， 处理程序代码790开始执行处理，所述处理也可能由用于一些普通系 统的OS来执行。

在框712，处理程序代码790保存OMS的状态。处理过程从框 712进行到框714。

在框714，处理程序代码790执行操作(EREAD)来确定故障信息， 并且还确定AMS在异常点的状态信息。对于至少一个实施例而言， 在框714执行的操作可以是执行一架构指令(EREAD)，所述指令用于 读取通道寄存器的内容以便确定AMS的状态信息以及确定故障信 息。

作为框714的结果而返回的AMS状态可以接着被处理程序代码 790保存到系统定义的数据结构中，以由异常过滤程序所使用。在框 714，处理程序代码790还可以保存其它的OS提供的关于异常的元 数据。处理过程从框714进行到框716。

在框716，处理程序代码790通过第一次调用异常分派程序 (dispatcher)逻辑来启动异常处理。所述异常分派程序是游历异常注册 记录链表并决定下一步走到哪里的逻辑。对于图7所示的方法780的 至少一个实施例而言，异常分派和过滤逻辑由AMS在框717a执行。 如以下所解释的，作为选择，异常分派和过滤逻辑可以部分或全部由 OMS在框717b执行。因此，在图7中利用虚线来指示由OMS进行 的分派执行717b的可选特性。

对于这样的实施例而言，分派逻辑因此由AMS在框717a执行。 AMS因此对异常进行分派以便于结构化异常处理，这与OS将会(在 许多普通系统中)调用的异常分派例程非常类似。对于至少一个实施 例而言，在框716a执行的分派代码匹配由OS提供的分派例程的语 义，包括遍历注册记录列表以搜索适当的处理程序，以及一旦找到适 当的处理程序则展开(unwinding)注册记录列表，并且恢复在异常过滤 例程中可能已经改变的AMS上下文。

对于这样的实施例而言，在框716，通过在异常分派程序逻辑的 第一个指令重新开始AMS，而将控制转移到AMS(见转变“2”)。 接着，AMS执行所分派的处理例程(框708)。[请注意，对于这样的 实施例而言，不执行可选框717b]。在框708执行所分派的处理例程 之后，AMS将控制流程返回到异常生成前其所执行的指令流(见回到 框702的转变“3”)。

对于以上刚刚讨论的框716的处理的至少一个可选实施例而言， 应当理解的是，所述异常分派逻辑可以部分或全部在OMS上执行， 而不是在AMS上执行。对于这样的实施例而言，在发生异常时通知 OMS(转变1)，但是OMS在框716启动异常分派逻辑的执行。在异 常处理之前的任何点或其完成时，OMS将控制转移(见转变“2”)回 到AMS。对于这样的实施例而言，任何剩余的分派或过滤处理717a 在AMS上发生。如上所述，在框708，处理过程在AMS上进行。

从框716，处理过程在OMS上进行到处理程序代码790的一组 指令，其在此被称作收尾部分(epilogue)720。在收尾部分720期间， 在框724，处理程序代码790恢复在框712所保存的上下文。

处理过程从框724进行到框726。在框726，执行返回函数以使 得OMS返回到执行在调用处理程序代码790前其所执行的任何代 码。

这样，图7说明了，异常处理程序代码790可以直接从处理程序 代码790本身启动异常分派处理，而不是调用OS的结构化异常处理 例程。以这种方式，可以完全在该应用内处理异常，而绕过OS控制 以及系统提供的用于管理结构化异常处理的部分或全部例程。

图8说明了用于为发生在隔离的受应用管理的定序器(“AMS”) 上的异常提供结构化异常处理的机制的替代实施例。对于图8所示的 实施例而言，利用代理执行机制来使得现有的由OS提供的SEH构 架为隔离的AMS定序器提供结构化异常处理。对于图8所示方法的 至少一个实施例而言，假设OMS和AMS均采用一种机制，其在定 序器之间进行控制的用户级异步转移。

图8所示的方法利用了这样的事实，即有助于SEH的大多数OS 代码几乎完全在用户空间(在图8中示为“ring 3”)中执行。图8说明 了，可以执行三种方法800、850和880，以便经由现有的OS支持的 SEH构架为AMS提供结构化异常处理。用于在检测到异常时调用结 构化异常处理的方法800可由AMS执行。代理执行850可以由OMS 执行，以便代表AMS调用操作系统功能。最后，OMS的OS可以执 行方法880来分派适当的处理程序。这些方法800、850、880中的每 一个均在下面作进一步详细讨论。

图8说明了，用于从AMS调用结构化异常处理的方法800开始 于框801并进行到框802。在框802，执行在AMS上运行的shred的 下一指令。如果所述指令会导致异常，则可以在框804检测到所述异 常。对于至少一个实施例而言，在框804检测到的异常的类型包括从 用户特权级别(例如，ring 3)转变到受限特权级别(例如，ring 0)。如上 所述，所述异常可以导致出现一处理器状态，该状态满足定义了特权 转变的场景，其可以继而触发将控制异步转移到处理程序代码890。 如果在框804检测到异常，则处理进行到框806，在那里控制被异步 转移到用于所检测的特定故障或状况的适当处理程序代码890(见图 8的转变“1”)。如果没有，则处理返回框802，并且方法800继续 直至到达所述shred的末尾。

用于在处理程序代码890中执行代理执行的方法850的处理开始 于框812，其处于处理程序代码890的被称作开场部分810的部分中。 对于至少一个实施例而言，响应于控制的异步用户级转移(见框806 和转变“1”)而在OMS上执行处理程序代码890。

在开场部分810中，在框812和814，沿前面结合图7所讨论的 开场部分处理过程712和714的路线执行初始处理。通常，在框812， 保存OMS的状态，以及在框814，确定AMS状态信息以及故障信息。

处理过程从框814进行到框816。在框816，OMS再次执行指令， 该指令之前在框802执行于AMS上时生成异常(例如，见指令执行 802和转变检测804)。所述指令的该再次执行816生成调用OS的异 常830(见图8的转变“2”)。也就是说，因为现在是在对OS可见的 OMS上发生异常，所以由于异常830而调用所述OS。

这样，处理过程进行到框882，这是由OS为了启动用于结构化 异常处理的异常分派处理而执行的方法880的第一个所示框。

在框882，OS取得OMS的当前状态的快照(snapshot)并且将当前 的OMS上下文保存到特定的数据结构(CONTEXT)中。接着所述OS 调用由系统提供的异常分派例程。对于至少一个实施例而言，所述分 派例程可以存在于用户空间库中。

因此，图8说明了，来自OS的分派(见转变“3”)导致控制转移 到框822，这是在此被称作“收尾部分”820的一组指令的第一个所 示处理框，所述收尾部分是OMS处理，该处理过程是在其作为代理 调用OS异常处理之后发生的。收尾部分820的指令的执行可以构成 由OMS所执行的方法850的附加处理。

因为OMS不是实际执行所分派的处理程序代码的定序器，所以 在框822，该OMS使得控制转移到AMS(见转移“4”)。对于至少 一个实施例而言，作为执行用户级的、同步的、架构定义的(例如， 部分ISA)控制转移指令的结果而执行该转变，所述控制转移指令诸 如shred转移(“SXFR”)指令。对于至少一个实施例而言，在框822， OMS在其执行控制转移之前将当前OMS上下文返回到AMS。

OMS处理接着进行到框824，在那里处理程序代码890恢复在 框812所保存的OMS上下文。

处理过程从框824进行到框826。在框826，执行返回函数以使 得所述OMS返回到执行在处理程序代码被调用之前所执行的任何代 码。

图8说明了，在框808，响应于由OMS在框822所引发的控制 转移(见转变“4”)，AMS开始执行分派逻辑。由于几乎所有的异常 处理逻辑都在用户级(Ring 3)执行，所以AMS现在可以通过系统的正 常控制流程对异常进行处理。在分派的处理程序代码的终点，控制返 回(见转变“5”)到所述AMS在发生异常前所执行的指令流的下一指 令。

图8说明了收尾部分820中的可选处理框，框821。因为允许操 作系统改变OMS的段寄存器值，所以在CONTEXT数据结构(由OS 生成并且被传送到异常过滤程序)中保存的这些值可能变得与原AMS 的段寄存器值不一致。为了正确性，所述OMS可以可选地对 CONTEXT数据结构中所包含的段寄存器的值进行校正，所述 CONTEXT数据结构是由于在OMS上发生异常而保存的(见830)。图 8说明了，可以在导致异常之后从OS返回时，在框821执行所述段 寄存器值的该可选校正。对于不执行该可选步骤处理的实施例而言， AMS处理并未受消极影响，原因在于AMS维护着正确的段寄存器 值。

这样，图8说明了，异常处理程序代码890作为一个代理，代表 对于OS不可见的AMS来调用所述OS的结构化异常处理例程。以 这种方式，尽管AMS对于操作系统是不可见的，但是AMS可以执 行需要系统资源的代码。本领域技术人员将认识到，在控制在822返 回AMS之前，可以在OMS而不是AMS上执行部分或全部的异常分 派和过滤逻辑808。

图9说明了能够执行所公开的技术的计算系统1300的至少一个 示例实施例。计算系统1300包括n个处理器核心1304a-1304n以及 存储器系统1340。存储器系统1340可以包括较大而相对较慢的存储 装置502，以及一个或多个较小而相对快的高速缓存，例如指令高速 缓存1344和/或数据高速缓存1342。虽然没有单独示出，但是每个核 心1304a-1304n可以具有其自己的指令高速缓存1344和/或数据高速 缓存1342。

存储器系统1340意指存储器的一般化表示，并且可以包括多种 形式的存储器，例如硬盘驱动器、CD-ROM、随机存取存储器(RAM)、 动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM)、闪速 存储器以及相关电路。存储器系统1340可以存储可由处理器1304执 行的、由数据信号所表示的指令1310和/或数据1312。指令1310和/ 或数据1312可以包括用于执行任何或全部这里所论述的技术的代码 和/或数据。

指令1310可以包括主线程代码1350。主线程代码1350可以包 括用于初始化一个或多个OS不可见的shred的指令。在由定序器执 行时，主线程代码1350的初始化指令可以使得OS不可见的定序器 执行shred指令流，同时共享主(原生)线程的逻辑执行环境。

指令也可以包括操作系统(OS)代码1361。此外，对于至少一个 实施例而言，指令1310还可以包括一个或多个处理例程1360来使得 一个定序器(未隔离的)分派要由隔离的定序器所执行的已注册过滤 例程。处理例程1360可以包括分别执行图7和8所示的方法780、 850中的至少一个的指令，以支持用于隔离的定序器的结构化异常处 理。

对于至少一个实施例而言，指令1310可以包括一个或多个用于 通知特权转变的指令，所述特权转变如前面结合图7的框704和706 以及图8的框804和806所讨论的。也就是说，指令1310可以包括 ISA指令，其响应特权转变或其它异常而触发将控制异步转移到处理 程序代码。

处理器1304a-1304n无需是对称的，但是其中每一个可以包括向 执行核心1330供应指令信息的前端1320。所取出的指令信息可以被 缓存在高速缓存225中，以等待由执行核心1330执行。前端1320可 以以程序顺序向执行核心1330供应指令信息。对于至少一个实施例 而言，前端1320包括确定将要执行的下一指令的读取/解码单元322。 对于系统1300的至少一个实施例而言，读取/解码单元322可以包括 单个的下一指令指针和读取逻辑320。然而，在其中每个处理器 1304a-1304n支持多个线程上下文的实施例中，该读取/解码单元322 为每个所支持的线程上下文实现了不同的下一指令指针和读取逻辑 320。多处理器环境中额外的下一指令指针和读取逻辑320的可选特 性在图13中以虚线来表示。

这里所述的方法的实施例可以用硬件、硬件仿真软件或其它软 件、固件、或这样的实现方式的组合来实现。可以为一个可编程系统 实现本发明的实施例，该系统包括至少一个处理器、数据存储系统(包 括易失性和非易失性存储器和/或存储元件)、至少一个输入设备、以 及至少一个输出设备。为了该应用，处理系统包括具有处理器的任意 系统，所述处理器例如数字信号处理器(DSP)、微控制器、专用集成 电路(ASIC)、或微处理器。

程序可以被存储在通用或专用可编程处理系统可读的存储介质 或设备(例如，硬盘驱动器、软盘驱动器、只读存储器(ROM)、CD-ROM 设备、闪速存储器设备、数字多用盘(DVD)、或其它存储设备)上。 当处理系统读取存储介质或设备时，可由该处理系统中的处理器访问 的指令用于配置和运行该处理系统，以执行这里所述的过程。本发明 的实施例也可以被认为是被实现为有形的机器可读存储介质，其被配 置为与处理系统一起使用，其中这样配置的存储介质使得该处理系统 以特定和预定方式操作以执行这里所述的功能。

示例系统1300代表基于英特尔公司提供的Pentium、Pentium Pro、PentiumII、PentiumIII、Pentium4和Itanium以及 Itanium2微处理器的处理系统，但是也可以使用其它系统(包括具 有其它微处理器的个人计算机(PC)、工程工作站、个人数字助理和其 它手持设备、机顶盒等)。对于一个实施例，示例系统可以执行微软 公司提供的一个版本的Windows^TM操作系统，但是例如也可以使用 其它操作系统和图形用户界面。

尽管已经示出和描述了本发明的特定实施例，但是对于本领域技 术人员来说显而易见的是，可以进行许多变化和修改，而不会背离所 附权利要求的范围。例如，虽然以上将寄存器440和443作为用于存 储与shred环境块相关的指针或索引的装置来论述，但是本领域技术 人员应当理解，包括锁存器、存储单元或其它存储机制在内的任何存 储装置都可以取代寄存器来使用。

因此，本领域技术人员将认识到，可以进行许多变化和修改，而 不会在较宽方面上背离本发明。由此，本领域技术人员将认识到，在 此所描述的实施例的特征可以被应用到其它环境，而不会背离以下所 附权利要求的范围。所附权利要求旨在将落入本发明的真正范围内的 所有这些变化和修改都包含在其范围之内。