本地用户级线程数据的数据结构和管理技术的制作方法

专利名称：本地用户级线程数据的数据结构和管理技术的制作方法
技术领域：
本公开总体上涉及信息处理系统，并且更具体地涉及多定序器 (multi-sequencer)多线程系统中的本地用户级线程数据。
背景技术：
为了提高诸如那些包括微处理器的信息处理系统的性能，已经采用 了硬件和软件的多线程技术。多线程逐渐得到硬件上的支持。例如，在一 种方式中，多处理器系统(例如单芯片多处理器("CMP")系统)中的处理器每 个都可以并发地运行多个软件线程中的一个。在被称为同时多线程 (simultaneous multi-threading, "SMT")的另一种方式中，对于操作系统和用户 程序而言，单个物理处理器看起来像是多个逻辑处理器。对于SMT，在单 个处理器上，多个软件线程可以同时是活动的并可以同时执行而无需切换。 也就是说，每个逻辑处理器保持完整的一组架构状态，但是该物理处理器 的许多其它资源(例如高速缓存、执行单元、分支预测器、控制逻辑和总线) 都是共享的高速缓存。因此，对于SMT来说，来自多个软件线程的指令可 以并发地在每个逻辑处理器上执行。对于诸如SMT和/或CMP系统这样的支持多个软件线程的并发执行 的系统而言，操作系统应用程序可以控制(多个)线程执行资源上的软件线程 的调度和执行。然而，不受操作系统控制的其它线程执行资源对于程序员 来说也可以是可用的，并且可以由用户级代码来控制。普通操作系统并未 提供数据结构来保持用于可在这些资源上执行的用户级线程的本地数据。


参考下列附图，可以理解本发明的实施例，在附图中相似的元件用 相似的数字标明。这些附图并非限制性的，而是用来对用于管理多定序器 多线程系统中的本地用户级线程数据的数据结构和技术的选定实施例进行说明。图1的方框图说明了多定序器系统的各种实施例；图2的方框图展示了用于多定序器系统的一般并行编程方法的图形 表不；图3的方框图说明了用于用户级多线程的至少一个实施例的线程和 用户级线程中的共享存储器和状态；图4的块数据流图说明了用来在多线程系统中保持线程专用的本地 数据的机制的至少一个实施例；图5的方框图说明了结构化异常处理所利用的数据结构的至少一个 实施例；图6的方框图说明了用来为包括一个或多个分离的定序器的多线程 系统保持shred专用的本地数据的机制；图7的方框图说明了在使用直接存储器指针的多线程系统中保持 shred专用的本地数据的机制的至少一个实施例；图8的方框图说明了在使用段寄存器的多线程系统中保持shred专用 的本地数据的机制的至少一个备选实施例；图9的块数据流图说明了用于保持上下文切换过程中的shred环境块 的状态的机制的至少一个实施例的数据组织和流；图10的流程图说明了用于保持上下文切换过程中的shred环境块的 状态的方法的至少一个第一实施例；图11的流程图说明了用于保持上下文切换过程中的shred环境块的 状态的方法的至少一个第二实施例；图12的块数据流图说明了用于保持AMS-OMS-AMS上下文切换过 程中的shred环境块的状态的方法；以及图13的方框图说明了能够执行公开的技术的系统的至少一个实施 例。
具体实施例方式下面的论述说明了方法、系统、数据结构、装置和机制的选定实施 例，用于管理既非由操作系统创建也非由其管理、而是由用户级代码创建和管理的用户级线程的本地数据。这样的用户级线程(在这里有时被称作"shred")是程序员可以基于用 户级代码中的指令而使其执行的指令序列。关联于同一个线程的多个shred 可以并发地执行。对于至少一个实施例而言，(例如，通过软件库中或者存 在于用户空间中的调度程序(scheduler))调度shred运行在可用的硬件资源 上，而无需操作系统的干预。在此所述的实施例可以被用于单核或多核的 多线程系统。如这里所使用的，线程单元(在此还可互换地被称作硬件线程上下文 (context)或"定序器")可以是能够执行线程或shred的任何物理或逻辑单元。
在下列说明中，阐述了诸如处理器类型、多线程环境、系统配置、 数据结构以及特定操作处理之类的大量具体细节，以便于更加充分地理解 本发明的实施例。然而，本领域技术人员将意识到，本发明可以在没有这 些具体细节的情况下实施。另外，没有详细示出一些公知的结构、电路等， 以免不必要地使本发明变得晦涩。图1的方框图说明了支持线程的用户级控制的多定序器系统的实施 例310、 350的选定硬件特征。图1说明了单核多定序器多线程环境310的 选定硬件特征。图1还说明了多核多线程环境350的选定硬件特征，在该 环境中每个定序器是单独的物理处理器核心。在单核多线程环境310中，在操作系统和用户程序看来，单个物理 处理器304显现为多个逻辑处理器(未示出)，在此被称作LPl-LPn。逻辑处 理器LPl-LPn中的每一个分别保持完整的一组架构状态ASl-ASn。对于至 少一个实施例而言，架构状态312a、 312b可以包括数据寄存器、段寄存器、 控制寄存器、调试寄存器和大多数模型专用的寄存器。
逻辑处理器LPl-LPn共享物理处理器304的大多数其它资源，诸如 高速缓存、执行单元、分支预测器、控制逻辑和总线等。虽然可以共享这 些特性，但是多线程环境310中的每个线程上下文能够独立生成下一个指 令地址(并且例如从指令高速缓存、执行指令高速缓存或轨迹高速缓存中进 行提取(fetch))。因此，处理器304包括用于每个线程上下文的逻辑上独立的下一指 令指针和提取逻辑320，即使在单个物理提取/解码单元322中可以实现多
9个逻辑定序器也是如此。下一指令指针和提取逻辑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可以是单线程的处理 器核心或多线程的处理器核心。芯片封装360在图1中由虚线表示，用以 指示所说明的多核系统350的单芯片实施例仅仅是示例性的。对于其它实 施例而言，多核系统的多个处理器核心可以存在于多个单独的芯片上。也 就是说，所述多核系统可以是多插槽(multi-socket)对称多处理系统。
为了便于论述，以下论述着重于多核系统350的实施例。然而，该 着重点不应当被看作是限制性的，这是因为以下所述的机制可以在多核多 定序器环境或单核多定序器环境中执行。图2的方框图说明了多定序器多线程系统上的并行编程方法的图形 表示。共享存储器的多处理范例可以被用在被称作并行编程的方法中。根 据该方法，应用程序程序员可以通过要并发运行的多个线程而在软件程序 (有时被称作"应用程序"或"进程")中表现并行性。同一软件程序("进程")的 所有线程共享公共的存储器逻辑示图。图2说明了对于操作系统("OS") 140可见的进程100、 103、 120。这 些进程100、 103、 120可以是不同的软件应用程序，例如字处理程序、图 形程序和电子邮件管理程序。 一般来说，每个进程运行在不同的虚拟地址 空间中。操作系统("OS")140 —般负责管理进程的用户定义任务。虽然每个进 程具有至少一个任务(例如，见由附图标记100和103分别表示的进程0和 进程2)，但其它进程可以具有一个以上的任务(例如，由附图标记120表示 的进程1)。图2所示的进程数目以及每个进程的用户定义任务的数目不应 当被看作是限制性的。这样的说明仅仅是出于解释的目的。
图2说明的是:关联于进程120的每个用户定义任务的不同线程125、 126可以由操作系统140来创建，并且操作系统140可以将线程125、 126 映射到线程执行资源。类似地，关联于进程103的用户定义任务的线程127可以由操作系统140来创建；以及关联于进程O (IOO)的用户定义任务的线 程124也可以由操作系统140来创建。 OS 140—般负责对这些线程124、 125... 126、 127进行调度以在执行 资源上执行。关联于同一进程的线程具有相同的虚拟存储器地址空间。
由于OS140负责创建、映射和调度线程，所以线程124、 125...126、 127对于OS 140是"可见的"。另夕卜，本发明的实施例包括对OS 140不可见 的附加的用户级线程130-139。也就是说，OS140并不创建、管理或另外控 制这些附加的用户级线程130-139。这些附加线程不由OS 140创建或控制，并且可以被调度以彼此并发 执行，所述附加线程在这里有时被称作"shred" 130-139，以便将它们与OS 可见线程进行区别，并且进一步将它们与针对同一个OS可见线程的不能彼 此并发执行的其它用户级线程进行区别。也就是说，与同一个OS可见线程 相关联的多个shred可以彼此并发执行。 shred由用户级程序(被称作"shred化程序(shredded program)")创建和 管理，并且可以被调度以在与操作系统分离的定序器上运行。例如，图2 所示的OS管理的线程125可以在对于OS可见的一个定序器(未示出)上执 行，而每个活动的shred 130-132可以在其它与OS分离的定序器(例如，分 别见图3的"seql"-"s叫4")上执行。对于与OS分离的定序器而言，由用户 级调度程序来调度指令流以便执行。由此，与OS分离的定序器由用户级应 用程序而不是OS来管理，因此在此被称作"应用程序管理的定序器"或 "AMS"。图2说明了与一个受OS调度的线程127相关联的一个进程103，还 说明了与两个或更多线程125-126相关联的另一个进程120。另外，每个进 程103、 120还可以额外地分别与一个或多个shred 137-139、 130-136相关 联。图2中使用虚点线和省略号来表示可选的附加shred。
进程l (120)的两个线程125、 126和四个shred 130-136的表示以及 进程2 (103)的一个线程127和两个shred 137、 139的表示仅仅是说明性的， 而不应当被看作是限制性的。本发明的实施例无需为与一个进程相关联的 线程或shred数目施加上限或下限。至于线程的下限，图2说明了在给定时 间运行的每个进程与至少一个线程相关联。
然而，线程根本无需与任何shred相关联。因此，没有为shred施加 下限。例如，图2中所示的进程0 (100)被示出为在图2所示的特定时间上 运行时，具有一个线程124，但没有任何shred。至于上限，与一个进程相关联的OS可见线程的数目可以由OS程序 来限定。然而，对于至少一个实施例而言，与一个进程相关联的shred的累 积数目的上限仅由在执行期间特定时间上可用的shred执行资源的数目(例 如，定序器的数目)来限定。图2说明的是与第一线程125相比，关联于进程120的第二线程 126可以具有与其相关联的不同数目(n)的shred。附加的shred的可选特性 在图2中由省略号和虚线来表示。这里，可以将与程序或进程的所有线程相关联的存储器的公共逻辑 示图称作"应用图像"。对于本发明的实施例而言，该应用程序图像也由与一 个进程相关联的shred所共享。图3的方框图说明了在进程、线程和shred之间的共享存储器状态的 一个例子。图3示出了图2所示的进程120、线程124、 125、 126和shred 130-132的图形表示。参照图2，下面论述图3。图3说明的是存储器的特定逻辑视图200由与特定进程120相关 联的所有线程125、 126共享。与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的至少 一个实施例是通过用户级软件"原语 (primitWe)"生成的，所述用户级软件"原语"调用一种独立于OS的机制，其 用于生成和调度OS不知道的shred。因此，可以响应于用户级软件调用来 生成shred。对于至少一个实施例而言，用户级软件原语可以包括用户级 (ring-3)指令，所述用户级指令调用硬件或固件来创建shred。这样创建的 shred可以由硬件和/或固件和/或用户级软件来调度。所述独立于OS的机制 可以是位于用户空间(比如软件库)中的软件代码。因此，取代依赖操作系统 来管理线程单元硬件和shred之间的映射的是，用户空间中的调度程序逻辑 可以管理所述映射。可以在标题为"A Mechanism For Instructions Set-Based Thread Execution on a Plurality of Instruction Sequencers"的共同未决专禾伸 请美国专利序列号No. 11/173326中找到用户级shredding指令的进一步论 述。应当注意的是，能够执行这里所公开的技术的实施例的系统的定序 器无需是对称的。定序器可以在任意方式上有所不同，包括影响计算质量 的那些方面。例如，所述定序器可以在功耗、计算执行的速度、功能特征 等方面有所不同。在以下部分中，给出了关于公共线程处理的背景信息，以便为本发 明的所选实施例提供上下文。这些部分提供了关于OS管理的线程的线程环境块、线程本地存储、描述符表、以及结构化异常处理的背景。其后给出
了根据本发明的shred环境块的结构和管理的所选实施例。 「00541 OS管理的线程的线程环境块。图4的方框图说明了运行在OS管理 的定序器上的OS管理的线程的现有技术数据管理机制。OS管理的定序器 430在此被称作"OMS"。图4说明了线程环境块或"TEB"545，其是由操作系统(例如，见图2 的140)创建和保持的用于多线程应用程序中的数据结构。对于特定系统而 言，TEB545也可以被称作其它名称，例如线程信息块或线程控制块。为了 便于论述，结构545在这里被称作TEB，但是本领域技术人员将认识到， 结构545的表示旨在包含任何相似结构，而不管特定系统的命名方式。
对于至少一些公共系统而言，诸如线程本地存储和结构化异常处理 这样的关键操作系统服务依赖于每个线程的TEB数据结构545的存在。 「00571线程本地存储。许多公共系统中的TEB 545的主要功能在于保持和 支持私有(也称作"本地")的线程数据。为了保持本地线程数据，操作系统可以在创建每个线程之后保留 TEB 545的专用实例。OS管理的线程的私有数据可以保持在该线程的线程 本地存储("TLS")区域460a、460b中。TLS区域460可以保持在TEB段540a、 540b内的主存储器502中，或者它可以由TEB段540内含有的地址指针来 引用。也就是说，TEB段540可以包含指向TLS区域460的指针，而不是 包括为TLS区域460所保留的实际存储区域。每个线程本地变量的值被存储在TEB数据结构545的TLS区域460 内。每个线程本地变量的值可以通过每个可变的键来访问。例如，编译器 可以在TLS区域460内的偏移为3处存储线程本地变量foo。每个线程访问 foo从各自的TLS区域460的内部的索引3处读取。因为TLS区域460包 括在TEB结构545内，所以将对线程本地数据变量的每个访问转换为对存 储器中的TLS区域460的直接访问。对于至少一个实施例而言，可以利用寄存器440来指示当前TEB 545 的基地址。对于第一实施例而言，寄存器440可以保持指向TEB结构545 的直接存储器指针。例如，对于基于IA-64架构的实施例而言，可以将指向 用于正确的线程的TEB结构545的直接存储器指针保持在寄存器440中。
15对于该实施例，寄存器440可以是诸如R13等的通用寄存器，而不是专用 的段寄存器。对于利用直接存储器指针的实施例的而言，管理经由上下文切换的 线程本地数据可以如下进行。依据上下文切换490，操作系统(参见，例如 图2的140)可以利用指向新线程的TEB 504b的直接存储器指针来更新寄存 器440。然而，提供对其它平台(例如，IA-32平台)上的TEB结构545的访问 更加复杂。对于至少一个备选实施例而言，寄存器440可以被实现为段寄 存器。定序器430的段寄存器440可以包含一个用于指示当前执行线程的 TEB段540a的值。依据上下文切换490，操作系统(参见，例如图2的140) 可以经由到全局描述符表550(下面立即描述)的索引来更新段寄存器440中 的值，以指示第二线程的TEB段540b。描述符表。对于使用段寄存器方法的实施例而言，段寄存器440中 的值可以是到描述符表550的索引，而不是直接存储器指针。对于这样的 实施例而言，TEB结构545保持在操作系统(参见，例如图2的140)所限定 的存储器540的段中。段描述符551描述了存储器的这个段。段是存储器 块，其起始于固定的基地址并且具有设定的长度。每个存储器参考包括段 值和偏移值。该偏移值是相对于该段的基地址的位置。
图4说明的是将用于描述TEB 545a、 545b的每个段540的段描述 符551a、 55 lb存储在全局描述符表550中。全局描述符表(GDT)550是可 以存储在主存储器502中的描述符的表。存储在GDT 550中的每个描述符 551包含与段有关的完整信息。段描述符可以包括(除了其它信息)段的起始 地址、段的长度和该段的访问权限。将到全局描述符表550中的索引保持在定序器430的寄存器440之 一中，其中该索引访问当前线程的TEB 540的段的描述符551。对于基于 IA-32架构的实施例而言，寄存器440可以是段寄存器(例如，在IA-32架构 上，Windows OS使用FS段寄存器，而Linux OS使用GS段寄存器)。
例如，图4说明的是可以将线程1的TEB 545a的段540a的描述 符551a保持在全局描述符表550中，并且将到描述符551a 540a的GBT 550 的索引存储在段寄存器440中，而线程1在OMS 430上是活动的。
为了直接访问TEB数据结构545，因此程序员可以指定到TEB段540 的索弓l 。例如，对于在IA-32平台上运行的WINDOWS操作系统，"mov eax， FS: [O]"可以将第一个字从当前线程的TEB段540载入EAX寄存器中。
图4说明的是对于OMS 430上的从线程1到线程2的上下文切换 490，可以更新段寄存器440的内容。也就是说，可以将到GDT550的索引 载入段寄存器440中，该索引访问用于保持线程2的TEB 545b的段540b 的描述符551b。对于至少一些系统而言，在存储器502中，存在至少两个主要的表， 它们存储段描述符。(涉及中断的第三类型的描述符表不在本论述范围之 内)。描述符表的第一类型是上述的GDT550。该描述符表550可以由所有 进程均等访问。全局描述符表包含有一般可用于系统中的所有任务的描述 符。通常，这些是操作系统所使用的任务。另外，可以针对给定进程的任务创建描述符表。这些表称作本地描 述符表(LDT)，并且将在下面结合图8对其进行进一步的详细论述。
结构化异常处理除了支持线程本地数据之外，TEB 545还可以支持结构化异常处理 ("SEH")。 SEH是OS提供的服务，补充以来自编译器的支持，用于处理在 程序执行期间发生的异常事件。这些异常事件可以例如包括除0错误、 特权扰乱等。图5说明了运行在OMS 430上的OS管理的线程(例如，"T")的结构 化异常处理记录的至少一个普通实施例。应用程序程序员可以在代码中采 用结构化异常处理，来促进用户提供的对于在用户模式中执行所述代码时 发生的某些异常事件的处理，而不是依靠操作系统140运行默认处理程序 (handler)来处理所述异常。通常，为了调用结构化异常处理，应用程序程序员可以在代码中包
括指令，所述代码向OS 140注册了一个回调函数。继而，OS140在所述代
码的执行期间在遇到用户模式中的异常时执行所述回调，从而允许用户模
式应用程序自身来处理在该应用程序执行时发生的异常。图5说明的是，TEB 545的多个字段之一可以是指向一个或多个异常
注册记录1050的指针1045。所述异常注册记录可以是单个记录，或者可以是多个记录1055a、 1055b...1055n的结构(表格、阵列、链表)。对于至少一 个实施例而言，注册记录1050可以是记录的链表1060，每个记录指向一个 异常处理例程。
编译器可以使用try/except语法来将异常处理程序插入或"注册"到由 TEB 545所指向的链表1060。由try/except语法所指定的该注册处理被变换 为直接从TEB 545读取以及向其写入。当发生异常时，OS140的SEH服务 搜索用户提供的异常处理程序的链表1060，以便确定下一个动作过程。
因此图5所示的结构化异常处理机制510是OS支持的动态机制，其 允许注册一回调处理例程，该例程将被调用以将控制从操作系统140转移 到用户级异常处理程序，从而处理某些指定的用户模式异常。然而，由于 OS 140并不为在与OS分离的定序器460上运行的shred提供TEB 545，所 以图5所示的机制510不支持用于shred的SEH。
也就是说，图5所示的TEB 545已经被操作系统140分配用于主线 程T。然而，图5还说明了，操作系统140没有为在分离的定序器460 (分 别是"Seq l"和"Seq 2")上运行的两个shred (SI和S2)中的任何一个分配 TEB，这是因为它们对于OS 140是不可见的。
Shred环境块。现在参考图6，它是说明用于多shredding系统410 中的shred本地数据的数据管理机制的至少一个实施例的方框图。图6所示 的多shredding系统410的实施例包括一个或多个OMS定序器430,它们对 于操作系统140是可见的并且由操作系统140控制。
图6说明的是，多shredding系统410还包括一个或多个与操作系统 140分离的定序器(S叫1、 Seq2)。分离的定序器(Seql、 Seq 2)在图6中被 统称为应用程序管理的定序器("AMS") 460。
因此，系统410可以包括可由应用程序开发人员的代码所管理的多 个定序器460,其处于操作系统控制之外。开发人员可以在其代码中采用以 下指令，该指令能够导致在分离的定序器460上并发执行指令流或"shred"。 运行在与OS分离的定序器460上的shred —般不能访问有效的TEB实例 545，这是因为操作系统140典型地仅在创建原生线程(native thread)时保存 TEB 545的实例，但是对于shred并非如此。
对于至少一个实施例而言，图6所示的定序器430、 460在功能上可以有所不同。图6所示的功能不对称的示例示出，至少一个定序器430对 于OS 140可以是可见的，并且由此能够执行"ringO"操作，例如执行系统调 用、为页错误提供服务等。
在另一方面， 一个或多个其它定序器460可以与OS140分离，并且 由此不能够执行ringO操作。然而，这仅仅是功能不对称的一个示例。多定 序器系统410中的定序器430、 460还可以以任何其它的方式有所不同，例 如尺寸、字和/或数据路径大小、拓扑、存储器、功耗、功能单元数目、通 信架构(多点(multi-drop)总线对点对点互连)、或者与功能、性能、占地面积 等相关的任何其他的度量。
对于图6所示的示例性实施例而言，每个分离的定序器460已经被 初始化为能够执行与一个线程相关联的shred (例如，Sl和S2)。图6所示 的示例示出了已经由运行在OS可见的定序器430上的线程T所生成的两个 shred Sl和S2。调度shred Sl和S2，以分别在分离的定序器Seq 1和Seq 2 上执行。
因为图6所示的系统410允许程序员管理shred Sl和S2在操作系统 140控制之外的AMS定序器Seql、 S叫2上的执行，所以系统410包括一 种机制，其创建和管理数据结构442来保持用于shredSl、 S2的shred本地 数据。这样的数据结构在此被称作shred环境块("SEB，，) 442(1)、 442(2)。
对于shred环境块442的结构、组织和管理，存在许多选择。对于在 此所述的实施例，带有某些特定目标地设计所述结构、组织和管理。
第一个目标在于以支持简化编程以及应用程序(对于传统线程环境 而言，将所述应用程序写入多shredding环境中)的相对无缝的端口的方式， 为shred本地数据提供支持。这样，SEB442结构的动机之一在于无缝地为 代码提供便利，该代码包含对TEB数据结构的显性访问和/或隐性访问。通 过使用所提出的SEB结构，具有显性和/或隐性TEB访问的代码可以在OS 管理的定序器(OMS)430和应用程序管理的定序器(AMS)460两者上执行， 而不必进行源代码转换，或者甚至不必对现有二进制进行重新编译。例如， 通过针对线程本地数据的编译器指令隐性地访问TLS区域460的代码可以 在不修改的情况下在OMS和AMS两者上执行；在没有SEB结构442的情 况下，需要修改代码以便能够在AMS上执行。
第二个目标由如下所述的机制实现，以便在OMS和AMS之间迁移 代码时同步SEB和TEB状态。另外，该机制还在AMS上将上下文从一个 shred切换到另一个shred时提供同步状态。
SEB和shred本地存储。
关于第一目标，已经设计了这里所述的SEB 442的实施例的结构， 以便模仿公知的TEB 545结构的设计。利用这种方式，熟悉TEB 545的程 序员无需大量的额外努力就可以理解SEB 442的结构。因此，SEB 442中 每个字段的位置均模仿TEB 545中这些字段的组织。
图7的方框图示出了用于在多shredded系统中保持shred专用的本地 数据的数据结构的至少一个实施例，图7示出了 SEB结构442。图7说明 的是可以将shred的私有数据保持在SEB结构442内的shred本地存储 ("SLS")区域462中。
SEB结构内的数据的组织可以例如基于线程环境块545的结构。例 如，SEB 442的数据的组织可以基于众所周知的针对运行WINDOWS操作 系统(被称为Win32)的32位应用程序的实现方式。例如，Win32环境的TEB 结构545中的第三个字保持了线程堆桟的起始地址。相应地，SEB 442结构 的第三个字保持了 shred的堆桟的起始地址。换言之，堆桟地址保持在SEB 442中的偏移处，其中该偏移与程序员针对TEB 545所使用的偏移相同。
除了 SEB 442内的数据的组织以外，期望的是以用户熟悉的方式来 访问SEB 442的数据。
对于在寄存器443中提供了直接存储器指针的实施例而言，提供对 SEB 442结构的访问是直接了当的；系统仅仅需要在AMS 460上的线程指 针寄存器443中保持指向SEB 442的指针。例如，在IA-64架构上，软件 约定将使用寄存器R13来包含指向TEB的指针。
现在讨论图8，图8是备选实施例的方框图，该备选实施例包括一种 用于访问IA-32平台上的SEB 442结构的机制。图8说明的是对于该实 施例而言，SEB 442的SLS区域462可以保持在SEB段640内的主存储器 502中。
在基于IA-32的平台上，为了与普通的TEB方案一致，SEB 442包 含在由FS/GS(Win32/Linux32)段寄存器443所引用的存储器502的段内。存储器的这个段在这里被称作shred本地段640。
图8示出了本地描述符表("LDT" )750。该本地描述符表750包含 与给定任务相关联的段描述符。LDT 750可以任选地在每个任务的基础上 定义，并且可以用来对任务的可寻址范围进行划分。LDT表750提供了一 种用于将给定任务的代码和数据段与操作系统的剩余部分或其它任务相分 离的机制。
图8所示机制的至少一个实施例提供了对SEB结构442的段640的 定义。对于AMS 460，图8示出了单个SEB段640。如下所述，可以定义 多个SEB段640，以使用每个AMS 460。但现在参照每个AMS—个SEB 来论述图8。
段640的描述符751在本地描述符表(LDT)750中创建。对于至少一 个实施例而言，该段640和它的相应描述符751可以通过操作系统提供的 服务来创建。该操作系统服务可以由shredded代码中的系统调用来请求。
Shred本地段640的描述符751的LDT索引709被存储在AMS 460 的段寄存器443中。于是，将SEB442保持在存储器502的本地段640中。 利用这种方式，在AMS 460上访问shred本地段640的偏移将从SEB 442 读取数据，反之，在OMS430上访问线程本地段540中的同一偏移将访问 原生线程的TEB 545。因为将相同的字段/偏移分别保持在TEB结构545和 SEB结构442中，因此访问TEB 545的代码现在将对SEB 442起作用，而 不需要代码修改。
总之，对于图7和图8两者所示的实施例，应该看到，TEB 545经由 OMS 430的寄存器440来引用，而SEB 442经由AMS 460的寄存器443来 引用。对于这两个实施例，shred本地数据存储在shred本地存储(SLS)区域 462中，或者可由shred本地存储(SLS)区域462引用。SLS 462可以类似于 设置在一些现有系统中的线程本地存储(TLS)区域460。
对于图8的实施例，将SEB 442中的SLS区域462与TLS区域460 保持在相同的段偏移处。SLS区域462与TLS区域460保持在相同的相对 偏移处将允许例如通过用于TLS存储的编译器指令对TLS区域460进行隐 性访问，以便正常工作，而无论代码是在AMS 460还是在OMS 430上运行。 对于基于Win32平台的实施例而言，可以采用这种方法，但是本领域技术人员应该意识到，这里论述的实施例没有被如此限制。例如，对于运行在IA-32平台上的LINUX操作系统以及运行在IA-64平台上的LINUX和/或 WINDOWS操作系统而言，可以采用图7和图8所示机制的各种实施例。 「01031 SEB和结构化异常处理。图7和图8说明的是SEB结构442可以 包括一个字段，以便以与上面结合图5所论述的类似方式来支持结构化异 常处理。SEB结构442在一个偏移与TEB结构545中的偏移相同的字段中 可以包括指向一个或多个异常注册记录765的指针745。编译器向应用程序 提供了 try/except语法，以便将异常处理程序插入或"注册"到由SEB 442 中的指针745所指向的记录765中。
由try/except语法所指定的该注册处理被变换为直接从SEB 442读取 以及向其写入。当发生异常时，OS140的SEH服务搜索用户提供的异常处 理程序的链表来确定下一个动作过程。利用这种方式，对于shred，可以支 持结构化异常处理。r01051 SEB和上下文切换。SEB 442管理机制的设计的第二个目标是促进 上下文切换过程中的正确代码操作。上下文切换可以具有几个不同的原型 (origin),其中将在下文论述其中的一些原型。
例如， 一种类型的用户级上下文切换可以发生在OMS定序器430从 OS可见的任务切换到用户级任务时。例如，在OMS 430可用于执行shred 时，可以发生这种上下文切换。在这种情况下，用户级上下文切换可以发 生，从而使得OMS 430开始运行用户级shred。这种上下文切换可以被看作 shred到OMS 430的"迁移"。对于至少一个这种实施例，操作系统不会调 度OMS 430来运行shredded应用程序。作为代替，用户级调度程序可以重 定向OMS 430以拾取一个shred。
如果操作系统在OMS 430已经完成shred的执行之前获得并且调度 OMS 430上的工作，那么发生另一个上下文切换，以将shred从OMS 430 上迁移下来。相应地，这里论述的至少一些实施例提供了 SEB442的管理， 以便在OMS 430和AMS 460之间迁移代码时同步SEB和TEB状态(参见， 下文对图12的论述)。
除了涉及OMS 430的shred迁移之外，SEB 442管理机制的实施例 还可以在单个AMS 460上将上下文从一个shred切换到另一个shred时或者从一个AMS 460切换到另一个AMS 460时提供同步状态。单个AMS 460 的上下文切换例如可以发生在系统上，该系统提供了在AMS 460上调度 shred的循环法或其它共享方法。这种调度方法例如可以在支持shred(M)的 数量多于可用AMS(N)的数量的系统中采用。
也就是说，更像现代操作系统可以管理多于可用定序器的数量的线 程的方式，支持用户级shred的系统可以通过M: N用户空间调度程序来管 理比可用AMS(N)多的shred(M)。例如，在标题为"Mechanism To Schedule Threads On OS-Sequestered Sequencers Without Operating System Intervention"的序列号为11/027,445的共同待决的专利申请中，描述了这种 调度程序的至少一个实施例。
每次将新的shred切入到AMS 460中并且将当前执行的shred切出 时，这种调度方法都产生一个用户级上下文切换。相应地，这里论述的至 少一些实施例提供对多个SEB 442的管理，以便在AMS 460上将上下文从 一个shred切换到另一个shred时同步状态(参见下文对图9的论述)。
上面的段落说明了多shredding系统应该以在涉及shred的上下文切 换中提供正确操作的方式来管理SEB 442的一般建议的几个具体示例。为 了实现这个目标，提出了多个用于创建和保持SEB 442的方法。
图9是块数据流图，其示出了用于创建和保持SEB结构442a-442n 的一种方法，其中为n个shred的每一个定义SEB 442。图9的示例假设方 案沿图8所示的线，每个SEB442存在于本地段640中。
对于假设方案沿图7所示的线的备选实施例而言，图9所示的寄存 器443不是段寄存器，取而代之的是将其设计成用于存储指向当前SEB结 构442的直接存储器指针。图9的余下论述集中在443是段寄存器的实施 例上。然而，本领域技术人员应该理解，类似的SEB保持方案可以被用于 例如图7所示的实施例，该实施例被设计成用于将直接存储器指针存储在 寄存器443中。
图9将结合图10来论述，图10的流程图示出了 SEB管理方法1010 的至少一个实施例，其数据流在图9中示出。图10的方法1010可以由调 度shred的用户级调度程序来执行。
图10说明的是操作系统进行调用以便创建本地段640a-640n，这代表了图10所示方法1010的初始操作1012。这样，分别为每一个SEB 442a-442n创建shred装入段640a-640n。然后，处理进行到方框1014。
在方框1014，判断是否需要在AMS460上进行上下文切换。为了论 述图9所述的示例，出于论述的目的，假设在方框1014需要进行上下文切 换909，以将shred 1从AMS460切出，而切入shredn。相应地，处理从方 框1014进行到方框1016(如果不需要进行上下文切换，则处理将在方框1015 结束)。
对于上下文切换909，在方框1016，将当前shred的本地段寄存器 443的内容保存到存储位置。对于图9所示的示例，段寄存器443的初始值 是与shred本地段640a的描述符751a相关联的索引，其中shred本地段640a 关联于shredl。在方框1016，可以以将寄存器443的内容与适当任务关联 的方式将该寄存器443的内容保存。然后，处理进行到方框1018。
在方框1018，将索引912载入段寄存器443，该索引912用于识别 被切入的新shred的段640n的描述符751n。对于图9所示的示例，在方框 1018，将与shred本地段640n的描述符751n相关联的索引载入段寄存器 443 ，其中shred本地段640n关联于shred n。
稍后进行的将shred 1切换到AMS 460上的上下文切换再次触发了操作1016和1018，使得shred 1的存储值被返回到段寄存器443。
然后，方法1010的处理在方框1015结束。如通过上面的论述所示出的那样，针对每个shred创建SEB442的结果在于仅为上下文切换保存/恢复所述寄存器443的内容，但是shred专用的SEB 442的内容不需要为上下文切换保存和恢复。这是因为每个shred具有它自己的SEB实例442a-442n。
备选方法将仅为每个AMS 460定义一个SEB 442。在图7中一般性 示出了这种方法，图7是使用寄存器443中的直接存储器指针的实施例。 类似地，在图8中一般性示出了这种方法，图8是采用寄存器443作为段 寄存器的实施例。对于这样的实施例，每当发生shred上下文切换时，shred 上下文切换涉及保存和恢复每个shred的SEB结构442的内容。
图11的流程图示出了用于管理系统的AMS上下文切换(例如图7和 图8所示的那些)的shred本地数据的方法1110的至少一个实施例，其为每个AMS 460创建仅一个SEB 442。图11将结合图7和图8来论述。对于至 少一个实施例而言，该方法1110可以由用户级shred调度程序来执行。
图11说明了方法1110开始于方框1102，并且进行到方框1104。 如果在方框1104检测到上下文切换，那么处理进行到方框1106。否贝l」，处 理在方框1105结束。
在方框1106，可以将被切出的shred的SEB结构442的当前内容保 存在存储区域中，例如备份存储装置中。然后，处理进行到方框1108。在 方框1108，引入的shred的SEB结构的内容可以从存储区域载入SEB结构 442中。
稍后进行的将初始shred切换到AMS 460上的上下文切换再次触发 了操作1106和1108，使得shred 1 shred环境块的存储状态可以返回到SEB 结构442。然后，处理在方框1115结束。
代替仅涉及AMS资源的上下文切换，如果上下文切换是从AMS到 OMS的迁移情况或者从OMS到AMS的迁移情况，那么SEB结构442的内容的管理可以包括附加的考虑因素。我们转到图12来进一步论述这些考 虑因素。
图12说明的是对于从AMS到OMS和从OMS到AMS的特定数 据的迁移，以便促进这些类型的上下文切换过程中的适当操作。图12示出 了用于第一上下文切换的数据流1020，其代表shred迁移到OMS 430。图 12还示出了第二上下文切换的数据流1030，其代表shred从OMS 430迁移 回AMS 460。
对于第一上下文切换，当前线程的TEB结构545的数据被复制出(例 如，被复制到备份存储装置)。然后，在数据迁移1020， SEB442状态的一 个子集包括有线程状态，并且被写入1020到TEB 545。 SEB 442状态的这 个子集中的至少一些可以被写入到TEB 545的线程本地存储区域460。
对于第二上下文切换，当前TEB结构545状态的一个子集包括有 shred状态，并且被写入1030到SEB 442。当前TEB 545状态的这个子集的 至少一部分可以被写入到shred本地存储区域462。然后，可以将TEB结构 545的原始数据从备份存储装置中恢复。
图11所示的数据迁移1020、 1030可适用于采用寄存器440和443中的直接存储器指针的系统，并且同样地适用于采用寄存器440、 443作为 段寄存器的系统。
图13说明了能够执行所公开的技术的计算系统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指令流， 同时共享主线程的逻辑执行环境。
对于至少一个实施例而言，指令1310还可以包括处理例程1360来 调度shred在定序器上执行。调度例程1360可以包括分别执行图10和图11 所示方法1010、 lllO中的至少一个的指令，以进行上下文切换。调度例程 1360还可以包括用于执行图12所示的数据迁移1020、 1030的逻辑1066。
处理器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 操作系统，但是例如也可以使用其它操作系统和图形用户界面。
尽管己经示出和描述了本发明的特定实施例，但是对于本领域技术 人员来说显而易见的是，可以进行许多变化和修改，而不会背离所附权利 要求的范围。例如，虽然以上将寄存器440和443作为用于存储与shred环 境块相关的指针或索引的装置来论述，但是本领域技术人员应当理解，包 括锁存器、存储器位置或其它存储机制在内的任何存储装置都可以取代寄 存器来使用。
同样，例如，已经叙述了各种应用程序编程接口和平台，包括32位 和64位WINDOWS平台以及32位和64位LINUX平台。然而，本领域技术人员应该意识到，这里所述的实施例的特征可以适用于其它环境，而不 会背离所附权利要求的保护范围。
因此，本领域技术人员将认识到，可以进行许多变化和修改，而不 会在较宽方面上背离本发明。所附权利要求旨在将落入本发明的真正范围 内的所有这些变化和修改都包含在其范围之内。
权利要求
1、一种方法，包括生成本地数据的存储区域，以便用户级线程(“shred”)在不受操作系统(“OS”)管理的线程单元上运行；以及在上下文切换过程中，将状态保持在所述存储区域中。
2、 如权利要求l所述的方法，其中，所述生成步骤还包括 生成所述存储区域，作为shred环境块的一部分。
3、 如权利要求l所述的方法，其中，所述保持步骤还包括根据线程环境块的组织结构，将数据保持在所述存储区域中。
4、 如权利要求2所述的方法，其中所述shred环境块还包括用于保持指向结构化异常处理的记录的指针 的字段。
5、 如权利要求l所述的方法， 当活动的shred变得不活动时，
6、 如权利要求5所述的方法， 当所述shred再次变得活动时，其中，保持状态还包括 保存所述存储区域的内容。其中，所述保持还包括-恢复所述存储区域的所述保存的内容。
7、 如权利要求6所述的方法，其中将所述保存的内容保存到备份存储装置，并且从所述备份存储装置恢 复所述保存的内容。
8、 如权利要求6所述的方法，其中将所述保存的内容保存到与另一线程单元相关联的存储区域，并且从 与所述另一线程单元相关联的所述存储区域恢复所述保存的内容。
9、 如权利要求l所述的方法，其中，所述生成步骤还包括 执行系统调用。
10、 如权利要求l所述的方法，其中，所述保持步骤还包括 保持用于指示所述存储区域的寄存器值。
11、 如权利要求10所述的方法，其中，所述保持步骤还包括 当发生上下文切换时，更新所述寄存器值，以便指示不同的存储区域。
12、 如权利要求IO所述的方法，其中 所述寄存器值是到描述符表的索引。
13、 一种包括有形的机器可访问介质的制品，所述机器可访问介质具 有多个机器可访问指令，其中，当处理器执行所述指令时，所述指令用于生成本地数据的存储区域，以便用户级线程("shred")在不受操作系统 ("OS")管理的线程单元上运行；以及在上下文切换过程中，将状态保持在所述存储区域中。
14、 如权利要求13所述的制品，其中，用于生成步骤的所述指令还包 括在被处理器执行时用于进行下列步骤的指令生成所述存储区域，作为shred环境块的一部分。
15、 如权利要求13所述的制品，其中，用于保持状态的所述指令还包 括在被处理器执行时用于进行下列步骤的指令根据线程环境块的组织结构，将数据保持在所述存储区域中。
16、 如权利要求14所述的制品，其中所述shred环境块还包括用于保持指向结构化异常处理的记录的指针 的字段。
17、 如权利要求13所述的制品，其中，用于保持状态的所述指令还包括在被处理器执行时用于进行下列步骤的指令当活动的shred变得不活动时，保存所述存储区域的内容。
18、 如权利要求17所述的制品，其中，用于保持状态的所述指令还包 括在被处理器执行时用于进行下列步骤的指令当所述shred再次变得活动时，恢复所述存储区域的所述保存的内容。
19、 如权利要求18所述的制品，其中，用于保持状态的所述指令还包 括在被处理器执行时用于进行下列步骤的指令将所述内容保存到备份存储装置，并且从所述备份存储装置恢复所述 保存的内容。
20、 如权利要求18所述的制品，其中，用于保持状态的所述指令还包括在被处理器执行时用于进行下列步骤的指令将所述内容保存到与另一线程单元相关联的存储区域，并且从与所述 另一线程单元相关联的所述存储区域恢复所述保存的内容。
21、 如权利要求13所述的制品，其中，用于生成步骤的所述指令还包 括在被处理器执行时用于进行下列步骤的指令执行系统调用。
22、 如权利要求13所述的制品，其中，用于保持状态的所述指令还包 括在被处理器执行时用于进行下列步骤的指令保持用于指示所述存储区域的寄存器值。
23、 如权利要求22所述的制品，其中，用于保持状态的所述指令还包 括在被处理器执行时用于进行下列步骤的指令当发生上下文切换时，更新所述寄存器值，以便指示不同的存储区域。
24、 如权利要求22所述的制品，其中 所述寄存器值是到描述符表的索引。
25、 一种系统，包括存储器系统，用于存储用户级线程("shred")的用户级调度程序；以及 能够并发执行shred的多个线程单元；其中，所述用户级调度程序用于在涉及每个shred的上下文切换的过程 中为所述shred保持本地数据。
26、 如权利要求25所述的系统，其中所述用户级调度程序还用于将每个shred的本地数据保持在shred专用 的存储区域中。
27、 如权利要求25所述的系统，其中所述用户级调度程序还用于将数据保存到与线程单元相关联的单个 shred专用的存储区域，以及从与线程单元相关联的所述单个shred专用的 存储区域恢复所述数据。
28、 如权利要求26所述的系统，还包括包括在每个线程单元中的寄存器，所述寄存器保持一个值，用于指示 当前活动的shred的所述shred专用的存储区域的存储器地址。
29、 如权利要求28所述的系统，其中，所述用户级调度程序还包括 用于更新作为上下文切换结果的所述寄存器值的逻辑。
30、 如权利要求27所述的系统，还包括包括在每个线程单元中的段寄存器，所述段寄存器用于保持到描述符 表的索引，所述索引用于指示针对shred专用的存储区域的段的描述符。
31、 如权利要求30所述的系统，其中，所述用户级调度程序还包括用于更新作为上下文切换结果的所述段寄存器值的逻辑。
32、如权利要求25所述的系统，其中，所述系统存储器还包括: DRAM。
全文摘要
本发明提供了本地用户级线程数据的数据结构创建、组织和管理技术。还描述和声明了其它实施例。
文档编号G06F9/46GK101317155SQ200680044279
公开日2008年12月3日 申请日期2006年12月12日 优先权日2005年12月27日
发明者B·V·帕特尔, D·K·波尔森, G·N·金雅, H·王, J·P·舍恩, R·A·汉金斯, S·M·沙阿, S·奥德赫 申请人:英特尔公司