专利名称：用于资源管理的方法和系统的制作方法
技术领域：
本发明一般涉及计算设备中的资源，尤其涉及管理计算设备中的资源。
背景技术：
操作系统采用资源管理方案来限制应用程序之间的干扰，实现优先级划分和控制资源分配的策略，且一般管理运行许多独立软件应用程序的系统的总体行为。
现有资源管理方案大部分都是先到先服务的。诸如在数字VAX/VMS、BSD/UNIX和Windows NT操作系统等中使用的基于计数器的资源管理方案试图维护由一个或多个进程使用的资源的绝对计数。例如，计数器可跟踪内核存储器使用、中央处理器单元(CPU)使用、或输入/输出(I/O)数据传输。
基于计数器的资源管理方案的一个问题是确定限制是什么以及达到或超出这一限制的后果。限制通常在达到该限制时被提高。在Windows操作系统的上下文中，对某些资源的使用设置限制一般是通过诸如作业对象、内核配额、CPU亲缘性和各种特别的资源专用限制等机制来实现的。资源使用也可当例如存储器管理器基于如何使用内核虚拟地址空间来对其使用设上限时沿功能线来设上限。另一示例是当传输控制协议/网际协议(TCP/IP)对内核池的使用基于当前所发送的数据包的类型被动态设上限时，例如，表示语音数据的数据包对于内核池的使用可能具有比并不确保有质量的语音传输的数据包具有更高的上限。
在某些情况下，资源管理方案基于设置竞争资源的处理的相对优先级，以协助对资源竞争做出仲裁，如当前在调度CPU资源时所完成的。另外，资源管理方案可以基于特权，即要求进程具有执行某些操作的特权来实现资源分配，如当前通过要求资源具有锁定存储器中的物理页的特权而完成的。
对于现有的资源管理方案有若干问题。由于大多数资源都是系统级的，因此在先来先服务的基础上管理资源可能会导致拒绝服务的问题。这是由于资源可能遭受其它应用程序、其它用户或网络可见服务的无限制的消耗。对现有机制的依赖造成了这样一种不可预测的环境，其中由于错误的、自私的或恶意的应用程序已经占用资源，因此应用程序通常无法获得运行所需的资源。该问题在大型终端服务机器中尤为尖锐。
基于优先级的资源管理方案只不过使竞争更加恶化。由于应用程序无法独立地建立其相对于其它应用程序的优先级，因此一般不可能设置公平地共享资源的优先级。在大多数情况下，甚至不可能公平地定义优先级。在CPU资源的情况下，这通常导致应用程序人工地提升其优先级以确保访问，而不管别处所存在的需求。最终后果是应用程序竞争被提高到不正常程度的优先级，从而使优先级方案原本预期实现的公平性策略无效。
如果没有对资源竞争的限制，很难向特定应用程序提供预先定义的服务级别。管理员或服务提供者一般无法为应用程序指定最小或最大的资源量。这造成了服务器整合情形中的问题，且迫使管理员和服务提供者通过例如动态地调整优先级来管理特定应用程序的CPU使用来支持整合。
某些系统试图通过使用资源保证来克服资源管理中固有的某些问题。并非仅仅设置限制或优先级，而是应用程序可对之前隐式分配的资源建立契约。保证通过在请求资源和实际使用资源之间添加间接层消除了对资源的瞬时竞争。通过以先到先服务的方式显式地保留资源，客户机获得关于对资源的未来使用的契约(例如，保证的I/O延时)，而不论任何其它未完成的保证如何。带宽是其中资源保证对于多媒体应用程序的实现尤其重要的一个示例。然而，保证本身是资源，且保证的分配可能失败。
当个人计算机移至起居室并担当多种新的角色时，资源管理变得更重要，尤其是在管理资源使用中的冲突的时候。另外，服务器计算机需要更有效地管理资源以提供更可预测的可操作环境。
发明内容
现有技术的上述问题通过本发明的原理得以克服，本发明针对用于管理计算设备中的资源的方法、系统、计算机程序产品和数据结构。本发明还针对用于管理计算设备中的资源以便于在设备上操作的竞争进程或线程之间的资源分配的方法、系统、计算机程序产品以及数据结构。
依照本发明的一方面，预算为一个或多个客户机对资源需求和限定进行编码。代表客户机执行的任意数量的进程、线程或其组合可以与单个预算相关联。特定的进程或线程也可以与多个预算相关联，但在任何时刻仅服从一个预算。进程和线程基于在活动预算中编码的需求和限定以及其它考虑事项来竞争资源。
依照本发明的另一方面，用于特定进程或线程的活动预算可至少部分地取决于该进程或线程正作为其代表来执行的客户机，在其生存期期间可以多次改变。在一组当前执行的线程上为一个或多个客户机执行服务的服务进程的情况下，该进程或线程当前正作为其代表来执行的客户机可以使用资源-客户机身份模拟来确定。资源-客户机身份模拟通过假定客户机要定位的资源身份并临时将其附加到客户机的活动预算，临时将进程或线程与客户机相关联。通常，这是通过检查当前客户机线程的活动预算来实现的。
依照本发明的又一方面，预算至少部分地通过为客户机所支持的每一资源维护三种数量中的一种或多种，对与该预算相关联的客户机(或多个客户机)的需求和限定进行编码，这三种数量指示了限制“L”、保留“R”和提交“C”。
依照本发明一方面，预算限制“L”表示与该预算相关联的客户机能够从所支持的资源的提供者，即资源提供者获得的资源量的最大值。限制可以是硬限制或软限制，它是当达到阈值时支配适当的行为的区别。如果限制是硬限制，则它是绝对最大值，且可以通过采取诸如使分配资源的请求失败或采用速率控制等一个或多个动作来强制实施。然而，如果限制是软限制，则限制仅担当对于相关的资源提供者在决定是否要满足客户机的分配资源请求时的建议。通常，资源提供者基于资源利用级别以及当需要时是否能以最小的性能额外开销来回收资源来确定是否提供软资源分配。
依照本发明的另一方面，预算保留“R”表示资源的预分配，它确保代表客户机对多达保留量“R”的未来资源分配请求很可能成功，此处也被成为保证。预算保留“R”是由预算限制“L”来约束的，而无论该限制是硬限制还是软限制。预算保留“R”还可表示跨越多个分配的足够的资源量，每一分配从预算保留中划分出一部分。
依照本发明的又一方面，预算提交“C”表示资源提供者至今为止已分配给与预算相关联的客户机的资源量。与保留值一样，预算提交“C”是由预算限制“L”来约束的，而无论该限制是硬限制还是软限制。另外，预算提交“C”可超出保留值“R”。
依照本发明的再一方面，预算分层结构将单独的预算中编码的资源需求和限定链接在一起。预算分层结构中的预算是以n元树格式来组织的，其中每一预算对象最多具有一个父对象以及无限数量的子对象。由此，预算分层结构可以被认为具有单个根预算，它没有父预算。在预算分层结构中与子预算相关联的客户机也服从父预算(包括根预算)的资源限制“L”。父预算可担当默认的活动预算，除非未明确创建子预算。对客户机施加的限制进一步限定了在子和父预算中维护的限制，此处被成为有效资源限制。
依照本发明的另外一个方面，预算分层结构可以是外部或内部的。外部预算分层结构可以基于策略考虑事项在其使用之前显式地构造。内部预算分层结构可以由试图自管理代表其执行的线程和进程的资源消耗的客户机动态地构造。如果客户机具有足够的特权例如以使应用程序服从除当前预算中编码的策略之外的策略，则可允许客户机脱离其当前活动预算作为其一部分的预算分层结构。需要限制对新进程可用的资源的应用程序可创建子预算来限制可能的恶意或危险的行为。
依照本发明的一个其它方面，可在预算中或在别处编码附加限制，以基于客户机如何使用资源来动态地改变施加在客户机上的资源限定。客户机对资源的使用可以随时间变化，取决于操作模式等等。客户机按照使用类型定义附加限制，并通过指示活动特色(active flavor)来传递当前的资源使用。活动特色是表示可使用资源的各种方式的多个特色之一。以此方式，客户机可在由其相关联的预算施加的约束内基于使用类型来划分其资源使用。通常，活动特色可以例如通过将其作为参数传递给资源分配API来显式地传递给资源管理器，或通过将活动特色设置到客户机的用户模式和/或内核模式存储器状态中来隐式地传递。
依照本发明的另一个其它方面，可以在预算中支持的资源包括离散的、基于速率的、以及受保证的资源。离散资源是分配给客户机以供代表其执行的进程或线程排它地使用的资源。离散资源包括由操作系统上的实际物理限制所约束的资源，或由操作系统的设计所施加的人工限制所约束的资源。基于速率的资源包括任何离散资源相对于时间的使用模式，诸如CPU消耗速率、I/O或网络带宽等等。受保证的资源可以与离散资源或基于速率的资源或这两者相关联。受保证的资源担当资源的未来可用性达指定量的担保者。
依照本发明的又一个其它方面，可为其管理资源的客户机可包括应用程序或应用程序组。客户机可任选地担当具有代表其它客户机在预算中编码资源需求和策略规则的特权的预算管理器。
依照本发明的再一个其它方面，资源管理器集中了资源的管理，包括实现预算、监视可用资源、以及从资源分配失败中恢复。资源管理器还可提供指定预算约束以及与资源提供者通信的接口。资源管理器可依照动态策略状态代表客户机确认从资源提供者转发的资源分配请求。动态策略状态表示资源管理策略的当前状态，包括当前正在执行的进程和线程的标识、其相对重要性，它们可由例如优先级以及其当前的活动预算来指示。资源管理器还依照为在动态策略状态中代表目标客户机执行的进程和线程指定的允许动作集对请求客户机和目标客户机之间的冲突做出仲裁。允许动作集的范围从目标客户机的被动动作到自愿放弃资源以重新分配给请求客户机、强制从目标客户机回收资源的抢先动作、以及导致终止从其回收资源的目标客户机的侵略性动作。资源管理器可任选地代表资源提供者强制实施资源的速率控制。
依照本发明的一个其它方面，资源提供者与资源管理器的确认和仲裁确定分离但依照该确认和确定向请求客户机分配资源，并从目标客户机回收资源。当资源被分配和回收时，资源提供者还与资源管理器合作直接或间接地与客户机的预算交互，以记录所支持的资源的消耗和释放。
依照本发明的另一个其它方面，提供了资源通知服务以便于从资源提供者和资源管理器向请求客户机和目标客户机做出关于资源的通知。通知包括涉及资源仲裁的通知以及资源使用达到或超过阈值的通知等等。
依照本发明的又一个其它方面，提供了一种用于管理计算设备中的资源的计算机可访问介质，包括用于储存数据结构的介质以及用于创建、维护和查询预算、保留和管理资源、记录资源消耗以及对资源冲突做出仲裁的计算机可执行组件。该数据结构以一般与上述系统和方法一致的方式定义了资源和资源提供者、预算以及其它策略数据。同样，包括资源管理器和对预算和资源提供者的资源管理器接口的计算机可执行组件能够执行一般与上述系统和方法一致的动作。
当结合附图参考以下详细描述时，可以更容易明白和更好地理解本发明的上述方面和许多附加优点，附图中图1是依照本发明的一个示例性资源管理系统以及其中可管理资源的一个合适的操作环境；图2是更详细地描述了图1中所示的用于实现本发明的一个实施例的预算的某些组件的安排的框图；图3A-3B是依照本发明的一个实施例形成的示例性预算分层结构的图示。
图4是更详细地描述了图1中所示的用于实现本发明的一个实施例的预算的某些组件的安排的框图；图5是更详细地描述了图1中所示的用于实现本发明的一个实施例的资源通知服务的某些组件的安排的框图；图6是更详细地描述了图1中所示的用于实现本发明的一个实施例的资源仲裁器的某些组件的安排的框图；图7是更详细地描述了图1中所示的用于实现本发明的一个实施例的策略模块的某些组件的安排的框图；图8是更详细地描述了图1中所示的资源管理系统的资源提供者和某些组件之间的交互，以依照本发明的一个实施例来分配资源的框图；图9是示出依照本发明的一个实施例为管理资源执行的逻辑的流程图；以及图10是依照本发明的一个实施例形成的示例资源管理器预算接口的框图综述。
具体实施例方式
为在计算设备上成功地运行应用程序，设备的操作系统必须向应用程序提供各种资源。依照本发明的各实施例适用于实现用于管理资源以便于其有效的分配和使用的改进方法的计算系统在以下讨论中详细描述。
一般而言，可在本发明的一个实施例中管理的资源包括任何可计量的资源，分配该可计量资源的全部或部分以供应用程序或操作系统在资源可能临时或永久被耗尽或不可用的情况下使用是有意义的。可被管理的资源的某些示例在下文中详细描述。资源通常是在设备上操作的竞争进程或线程之中分配的。竞争进程或线程可以代表一个或多个应用程序或操作系统执行。
在本发明的一个实施例中，可被管理的最熟悉的资源是基于真实和虚拟化的硬件物理存储器页、磁盘存储块、外围设备、虚拟地址空间、分页文件空间、CPU时间、对象名字空间等。这些资源中的某一些是隐式地分配的。例如，调度CPU分配了CPU时间，请求I/O操作消耗了整个I/O系统的带宽，以及访问无效地址生成分页错误。
在大多数系统中，仅有若干基础(或基本)资源是值得注意的典型的示例包括磁盘(存储)、I/O、CPU、内核虚拟地址空间(KVA)、用户虚拟地址空间(UVA)、以及物理页帧。大多数其它资源通常是从这些基础基本类型合成的。尽管KVA和UVA是构建在物理存储器之上的抽象，但它们表示了基本资源，因为KVA和UVA空间的量是由逻辑地址引脚的数量和操作系统的设计来限制的，而非由底层物理存储器的量来限制。
可在Microsoft Windows NT系统中实现的本发明的一个实施例中管理的资源的示例包括，但不限于，非分页和分页的池、用于从KVA划分出的虚拟页的系统页表条目(PTE)、分页文件空间、分页速率、以及AWE存储器。这些资源中的每一个无论是基本的还是合成的，都可由从起源于操作系统中存在的人工因素和/或设计决策或需求的某一组特征来定义。这些特征的列表如下有限(绝对)资源在许多情况下，特定资源的可用性可以由操作系统所施加的人工限制来约束。例如，由于某一表中的固定数量的槽，由操作系统使用的数据结构可以是有限的。另一方面，可以计数的任何东西(分页错误的总数、传输的I/O字节、上下文切换、CPU时间等)在与人工限制组合时可以被认为是资源。落入“计数的”类别中的大多数资源通常是由需要该资源的应用程序隐式地分配的。在典型的环境中，操作系统也可例如通过限制它并发地支持的活动网络连接数来限制同时资源消耗。
基于速率的可分配资源的速率也可以是资源。例如，调度的CPU时间、I/O、分页错误以及上下文切换都可以由它们发生的速率来限制。这些限制可以是人工(由操作系统施加)或实际的限制(例如，最大的可承受可能I/O速率)。有限资源与基于速率的资源可在以下方面进行区分有限资源是基于绝对数量(例如，消耗的总CPU时间、导致的总分页错误、或分配的总非分页池)来说明和限制的。基于速率的资源也可与其它类型的资源在以下方面进行区分基于速率的资源通常是在当在某一持续时间段上缺少资源使用的情况下自动补充的。
保证在大多数分配的资源的情况下，操作系统必须瞬时地为资源可用性做出仲裁。取决于其它客户机的资源使用状态，操作系统在一段延长的时间内可能无法满意地解决资源请求。例如，低优先级线程在操作系统提升其优先级或者所有较高优先级线程停止处于就绪/可运行状态之前可能始终处于饥饿状态。为减轻这一困难，尤其是对限制了支持服务质量(QoS)级别所必需的延时要求的客户机而言，系统可提供关于资源可用性的保证。示例包括保证在每秒提供100毫秒(ms)的CPU时间，或每秒传输2兆字节的I/O数据，或每秒服务多达80个硬分页错误。这些保证仅仅由于系统稍后将实现它们而是有意义的；由此，对于系统可以并发地做出的这些保证的数量有必要有某一限定。在这一点上，保证本身可被认为是资源。
可以在本发明的一个实施例中管理的资源可以是可再生和不可再生资源。资源可基于如何补充它们而被分类为可再生和不可再生资源。可再生资源是在分配给应用程序时消耗的，但是随着时间的推移自动补充。诸如CPU速率、I/O带宽以及分页错误速率等大多数隐式的基于速率的资源都是可再生的。不可再生资源是在应用程序返回分配时补充的。存储器块、设备、计数的限制以及数据结构限制都是不可再生资源的示例。大多数资源都是不可再生的。
可在本发明的一个实施例中管理的资源也可包括可回收资源。可回收资源是系统可在不需要应用程序的协作的情况下从应用程序中收回的资源。收回的最严格形式是只需终止应用程序，使得所有其资源都被释放给系统。然而，各个资源可以在许多情况下收回，其对应用程序的效果可从降低的性能到减少的功能，以及可能到异常退出变化。回收的示例包括解除存储器资源的映射、解除应用程序的调度、使句柄无效、以及停止兑现保证。当然，某些资源无法在此处所描述的意义中回收；通常这些资源在数量上是无限的，但是分配给客户机的任何部分被“消耗”且不能被返回给系统。示例包括单调递增的数量，诸如消耗的总CPU时间以及导致的总分页错误。
图1示出了一个示例性资源管理系统100以及其中可依照本发明管理如上所述的资源的一个合适的操作环境。如图所示，资源管理器108结合资源提供者112和客户机102操作，以依照动态策略状态管理资源提供者108对客户机102的资源分配。资源提供者112控制资源的实际分配，而资源管理器108集中资源的管理。以此方式，资源管理系统100的体系结构将资源分配与管理资源的功能解除耦合。
在一个典型的环境中，资源管理器108是在内核模式组件中实现的，但是也可在别处实现，而不脱离本发明的原理。资源提供者112通常被实现为用户或内核模式组件。示例包括存储器管理器以及CPU保留和IO分类机制。在一个实施例中，用户模式资源提供者112使用内核模式资源提供者作为代理，与内核模式资源管理器108交互。
如上所述，资源管理器108结合资源提供者112和客户机102操作，以依照动态策略状态管理资源提供者108对客户机102的资源分配。动态策略状态至少部分地包含在依照策略模块114形成的一个或多个预算104A、104B、104C中。在一个实施例中，策略模块114可包括一个或多个策略管理器116和策略数据库118。一般而言，策略模块114用于在策略数据库1108中编码诸如特定客户机102的优先级以及其它静态(或相对静态)策略数据等某些首选项。另一方面，预算104A、104B、104C一般对一个特定客户机或一组客户机的动态资源需求和限定进行编码。在资源管理中对策略模块114的使用将参考图7更详细描述。
预算104A、104B、104C可以是活动或非活动的。活动预算是当前与客户机102相关联的预算。非活动预算是通常预先为一个或多个客户机创建以表示策略考虑事项，但由于若干原因当前未与客户机102相关联的预算。在一个典型的实施例中，预算是在预算对象中实现的。预算对象与当前代表客户机102执行的一个或多个进程或线程相关联。资源管理器108使用活动预算来确定在给定的时间点相关联的进程或线程可以使用多少以及什么资源等等。在一个实施例中，预算可以动态地创建和/或激活，且与相关应用程序102A、无关应用程序102B以及预算管理器102C的组中的一个或多个相关联。相关应用程序102A、无关应用程序102B以及预算管理器102C的组共同构成了为其管理资源的客户机102。使用预算来管理资源将参考图2-4来更详细描述。
在一个实施例中，资源管理器108的功能包括强制实施预算104A、104B、104C等，包括管理对资源和带宽保证的提前保留请求、监视可用资源以及对资源竞争做出仲裁。资源管理器108的功能还可包括添加和移除可由第三方资源提供者控制或不可由其控制的动态资源。
在一个实施例中，对竞争客户机102之间的资源竞争做出仲裁的功能可以包含在资源仲裁器模块122中。在一个典型的实施例中，仲裁是在资源提供者112的请求下执行的。在一个实施例中，资源仲裁器122确定是否应从对一个客户机，即目标客户机的未完成的分配中回收资源，以满足来自另一客户机，即请求客户机对资源的未决请求。资源仲裁器122结合动态策略状态，即当前预算对象和其它策略数据来做出这一仲裁决定，这些将在下文中参考图6进一步描述。
在一个实施例中，还向资源管理器108提供资源管理器接口106，以便于与客户机102、资源提供者112和资源管理系统100的其它组件通信。具体地，资源管理器接口106可用于控制资源管理器108和预算104A、104B和104C之间，以及资源管理器108和策略模块114的组件之间的交互。在一个实施例中，资源管理器接口106还可控制资源管理器108和资源通知服务124之间的交互。资源管理器108可任选地使用资源通知服务124来向关注的客户机102通知资源的可用性和管理。在接收到通知之后，客户机102可以进而与资源管理器108协作以释放供应短缺的资源以便于有效的资源管理。在某些情况下，客户机与通知的协作可有助于避免必须在稍后对资源竞争做出仲裁。
在一个实施例中，资源管理器108还可包括资源速率控制器120，以代表资源提供者112强制实施资源的速率控制，即控制一个或多个客户机102在每一时间单位内对资源的消耗。
在一个典型的操作环境中，资源提供者112可通过一个或多个资源提供者接口110控制资源提供者112、客户机102和资源管理器108之间的交互。
图2是更详细地描述了图1所示的用于实现本发明的一个实施例的预算的某些组件的安排的框图。预算104可以被实现为与代表客户机102执行的一个或多个进程202和/或线程204相关联的预算对象200。预算104以协助资源管理器108和资源提供者112提供服务质量(QoS)级别、资源保留以及客户机隔离(客户机的资源使用的节流)的方式封装了与其相关联的客户机102的资源需求。
预算在内部为每一支持的资源206跟踪三个数量限制(L)208、保留(R)210和提交值(C)212。在以下的讨论中，与预算104相关联的线程、进程等被称为预算的客户机，而客户机一般指的是线程或进程作为其代表执行的客户机102。为易于讨论，对线程204的引用包括代表客户机102执行的进程202或任何逻辑，除非另外指明。在任何时刻，执行线程的资源使用服从单个预算104，即活动预算对象200。同时，活动对象200可与代表同一或不同客户机102执行的多个线程相关联。预算的参数和表示预算104的实际预算对象200可以随时间改变，这是由于由资源管理器108实现的策略决策或由于与其相关联的多个线程204和/或进程202的操纵。此外，预算104可以是分层相关的，以表达线程204作为其代表执行的不同客户机102之间的关系，使得一个客户机的资源使用可被绑定到与同一预算分层结构中的预算相关联的其它客户机的资源使用。
限制值(L)208表示预算可保留以供预算的客户机将来使用的最大资源量。尽管限制通常在预算创建之后保持恒定，但是具有足够特权的系统组件随后可修改这些限制。限制可以是两种类型硬限制或软限制。硬限制是对可在普通的服务级别分配给预算的资源量的绝对限制。如果限制是软限制，则超出限制值L 208的资源分配以足够降低的服务级别被支付给请求客户机，使得系统满足正常资源请求的能力未被削弱。这一较低的服务级别资源支付允许客户机利用以其它方式可能无法利用的资源。
保留值(R)210表示预算的客户机能够保留的最大预算资源量，且总是被限制L 208界定，而无论L是硬限制还是软限制。由此，保留值R 210对预算的客户机能够实际上在不需要资源仲裁的情况下在正常服务级别分配的资源数量施加了最大值。由于保留的资源实际上不可用于其它客户机的保留，因此所有保留通常都是保守的，以最小化资源利用不足和不必要的资源竞争。
提交值(C)212记录了资源提供者112已向预算的客户机102分配的实际资源量。由于作为软限制的限制L 208标记了在正常服务级别停止分配资源的阈值，因此提交值C 212可以被写成以下两个值的和正常提交(Cn)和超额提交(Ce)。直到限制L的所有分配都被认为是Cn类型的，这表明资源提供者在正常服务级别向客户机分配了Cn的资源。Ce表示在降低的服务级别授予应用程序，且如果L是软限制且Cn＝L，即当资源提供者已分配了完全的软限制量时，仅授予一个应用程序的提交的比例。由此，当L是硬限制时，Ce必须为0。
限制L 208本身担当可被保留的资源量R 210的松散上界。R 210是由客户机预算分层结构中存在的其它保留以及系统中别处的保留约束的，这将在下文参考图3描述。由于被分类为超额提交Ce的资源分配是可回收的，因此客户机102通常使用超额资源分配来执行可任选或非时间紧要的处理(例如，提供附加的Mp3视频显式效果等)。
软限制的目的是确保系统中的资源不会利用不足，尤其是在没有竞争的情况下。例如，对于空闲的资源，资源提供者112将该资源分类为超额且允许它被分配给需要的客户机一般是安全的。对于可在提交之前显式地保留的资源，即与基于速率的资源相反的有限资源，资源提供者112可对所保留但未提交的资源中的哪些部分不可能在不久的将来使用做出推测。资源提供者112然后可将这些资源支付给请求客户机102，但是必须确保该资源可被快速、有效且可能地回收，而无需客户机102的明确协助。否则，资源提供者112可在回收必需的资源时使做出提前保留的客户机102遭受不合理的延时。由此，仅存在少数使资源管理器108实现软限制是有意义且实用的资源。
在软限制的一个示例实现中，假定在时刻a，C的值是Ca，且在时刻b，C的值是Cb，使得a＜b，做出单个分配C′＝Cb-Ca，且Ca＜R＜Cb。在这一情况下，Cn的一部分(R-Ca)总是保证是在不需要资源仲裁的情况下做出的。这一要求并不阻碍资源提供者从授予另一客户机的Ce分配回收资源数量(R-Ca)并使用它来满足该请求，只要资源提供者能够在近似等于从可用(未使用)资源池中分配资源所需的时间的时间跨度内执行这一动作。注意，如果资源不能以分段的方式(例如，如同物理页一样)来分配，则可能对整个分配C′而非仅仅(Cb-R)需要仲裁。
对软限制的一个典型的使用是避免CPU的利用不足。当预算104具有对CPU消耗的某一百分比的限制L 208，且对CPU没有竞争时，通常限制预算的客户机没有任何理由无法消耗所有的CPU(否则，CPU将完全未使用)。仅仅向所述的客户机支付可用的CPU的难点是万一任何其它客户机(未绑定到限制的预算)变为就绪，必须能够容易地撤回该支付。如果CPU不能被容易地回收并支付给合法的客户机，则将阻碍限制预算中设置的软限制L 208的有用性。尽管达到零回收成本是难以实现的，但是它能在某些情况下极大地最小化。例如，在CPU的情况下，一旦超出了限制L 208，被限制的线程的优先级可在允许它们继续执行之前被大幅地降低。由此，在没有CPU竞争的情况下，被限制的线程在CPU上调度，且其操纵继续不受阻碍。万一任何其它未限制的线程(不与预算相关联)变得就绪，或万一发生了对CPU的竞争，则降低的优先级确保受限制的线程不会干扰不受限制的线程的合法活动。当补充了资源时，受限制的线程的优先级被恢复到其先前的级别。
通常，资源提供者基于其中可实现回收的时间量，确定是否提供超额的资源分配，即是否施加软限制而非硬限制。以此方式，假定资源在其它预算中被约束在Ce分配，则可使用回收时间来界定合法的正常资源分配Cn可遇到的等待时间。注意，一般如上所述，回收时间仅对Cn分配中少于R的部分界定；R的其它部分在最坏的情况下被延迟达从给予其它客户机的Cn分配中回收资源所需的时间。
通过允许软限制，预算104的客户机102可以部分地补偿由于系统中的其它客户机做出的未使用保留而在其保留请求上设置的人工限制。应当注意，软限制可能看似抵消预算104在约束资源使用中的效力，因为它们准许提交的使用是无界的。然而，超出软限制的分配通常被限于否则将会利用不足的资源。并非所有的资源提供者112都可支持软限制。例如，使用软限制来避免利用不足在目标是提供一致性能(与最优性能相反)时是不合需要的。由此，并非预算104中所有支持的资源206都可服从软限制L 208。
软限制提供了可用于对抗资源利用不足的手段，但是不提供关注方用于接收关于特定的预算所跟踪的资源使用超过某一阈值的提前通知的手段。为解决这一遗漏，资源预算104通过可任选地包括预算标记值214来支持对资源使用的“标记”或警告的概念。对预算标记214的值的唯一限定是它们小于或等于预算104中设置的当前资源限制L 208(如果资源限制L收缩为小于标记值的值，则使该标记无效)。标记值对于所述资源的当前正常提交(Cn)或保留值R没有任何先后关系。当特定资源的当前正常提交Cn值超过标记值214时，可例如通过使用下文参考图5详细描述的通知服务124来通知其它客户机102。在接收到这一通知之后，客户机102可在它觉得合适的时候做出反应(例如，通过调整资源使用、修改资源限制等)。在一个典型的实施例中，为避免滞后情况下(其中当前正常提交Cn的值跨预算标记214的值来回振荡)的严重性能降低，标记通知是一次性事件一旦发出了通知，标记保持不活动，直到例如客户机102或系统管理员等关注的监听者明确地重新激活它。
预算104可以是预算分层结构的一部分，如以下参考图3A-3B更详细讨论的。为以下讨论的简明性起见，假定限制是硬限制，使得Ce＝0，且因此C＝Cn。对于一般化的讨论，Cn可以在以下代替C。当作为分层结构中除上述L 208、R 210、C 212和预算标记214值之外的一部分，每一预算104可包括累积的保留216值，其中维护了所有分层相关的预算中低于当前预算104的级别的资源保留R 210的累积的量，也称为子树保留。累积的保留216值便于为作为预算分层结构一部分的预算强制实施预算限定，如将在下文参考图3A-3B详细描述的。
图3A-3B是依照本发明的一个实施例形成的示例性预算分层结构的图示。预算分层结构提供了一种表达关于属于该分层结构的预算的资源需求和限定的规则的机制以及其它用途。如图3A所示，示例性预算分层结构300以n元树的形式将形成预算分层结构300的预算302、304A-C以及306A-E中所表达的资源需求和限定，即限制L 208、保留R 210和提交C 212链接在一起。
预算分层结构300通常包括根预算302以及一个或多个子预算304A、304B和304C。子预算进而可包括其它子预算306A、306B、306C、306D、306E和306F。资源管理器108使用根级预算302来施加批准或拒绝由预算分层结构300中的一个预算的客户机102发起的资源保留请求的最终限制。任何这样的保留请求必须满足分层结构300中发起者的预算和根之间的每一级处存在的预算约束。由此，由预算306F的客户机发起的请求不仅必须满足预算306F的约束，还必须满足预算304C以及根预算302的约束。
在一个实施例中，一旦资源管理器108依照预算分层结构300中的预算批准了资源请求，则请求一般由适当的资源提供者112进一步审阅以确认鉴于未决的保留和分配批准该保留请求是否是可行的。注意，可被批准的请求在由预算分层结构300中的预算指定的约束下可能被资源管理器108抢先拒绝。
在一个典型的实施例中，为提高向上遍历预算分层结构300的性能，资源管理器108可在预算分层结构300中的子树的根预算处高速缓存在该子树中做出的保留的总累积量。以此方式，由非根预算(此处也称为派生预算)的客户机发起的资源保留只需对照请求者的预算以及分层结构中在其之上的所有预算来检查。在所示的示例中，由子预算306F的客户机发起的请求对照请求者的预算，即子预算306F本身，以及分层结构300中在通往根预算302的直接路径上且非子树预算304A、304B或同一级别的预算(子预算306A-306E)的所有预算来检查。
注意，派生预算不必具有小于任何其祖先中指定的限制的限制(L)208。这是由于外部策略可响应于客户机102启动应用程序将预定义的预算104链接到预算分层结构300中。在其中局部限制，即子预算的限制大于祖先中的限制的情况下，仍能够实现正确的结果，因为请求将在该树中的更高层中被阻断。
在一个典型的实施例中，根预算302不是系统资源的一个绝对分区，除非跨所有根级预算302的L值208的和恰好等于系统中的总可用资源。由于限制L 208可以在预算创建之后调整且导致资源的过度预定，因此资源分区相反通常是通过请求资源保证(例如，CPU带宽保证)的保留来实现的。
如上所述，预算分层结构300提供了一种表达关于属于该分层结构的预算的资源需求和限定的规则的机制。预算分层结构以及在该分层结构中表达的规则的一个示例308在图3B中示出。在示例308中，系统管理员希望将客户机{A，B，C，D}312以及客户机{X，Y，Z}318对CPU的累计使用约束在不多于系统中可用CPU的80％。然而，客户机{A，B，C，D}可能使用多达50％的CPU，如在累计使用规则322中所示的，而客户机{X，Y，Z}被限于仅40％，如在累计使用规则324中所示的。使用单个独立的预算来表达这一类型的规则被证明是困难的，尤其是因为个别的限制50％和40％合计超过了所期望的有效限制80％，如在累计使用规则320中所陈述的(L2+L3＞＝L1，例如，50+40＝90＞＝80)。然而，系统管理员可通过创建依照本发明的一个实施例形成的所示的预算分层结构308来实现这一期望的结果。
如图所示，所示的预算分层结构示例308是由预算B2314(具有50％的限制L2)以及B3316(具有40％的限制L3)构成的，其每一个是从根预算B1310(具有80％的限制L1)派生的。客户机{A，B，C，D}312与预算B2314相关联，而客户机{X，Y，Z}与预算B3316相关联。资源管理器108通过将提交的资源量分别限于预算B2314和预算B3316中的限制L2和L3，来强制实施示例预算分层结构308中的限制，如在累计使用规则322(提交的B2＜＝50，∑B2.C＜＝L2)以及324(提交的B3＜＝50，∑B3.C＜＝L3)中所示的。资源管理器108还通过将提交的资源量限于预算B1310中表达的有效限制L1，来强制实施示例预算分层结构308中的限制，如在累计使用规则326(∑B2.C+∑B3.C＜＝L1)中所示的。
如在所示的示例预算分层结构308中所示的，预算分层结构300一般提供了一种将资源限制L 208分配给客户机102以封装其各自的资源使用，同时施加有效限制的手段，该有效限制等于客户机的局部预算，即子预算或派生预算中指定的限制以及在预算中沿通往对应的根预算的路径编码的限制的最大限制性。
一般而言，对于任何预算分层结构300都保持以下不变性。对于任何预算的限制L 308可以是硬限制或软限制。另外，限制L 208通常大于或等于保留R 210，且也大于或等于正常提交Cn 212。如果限制L 208的值是软限制，则超额提交Ce可以大于或等于0，且一般是由系统中可用的空闲资源来界定的。如果限制L 208是硬限制，则通常不允许任何超额提交值，即Ce通常是零，这是通常由资源管理器108强制实施的要求。对任何预算104的保留R的量不仅由预算的限制值L 208限定，而且也由在预算分层结构300中别处设置的保留和限制来限定。由此，限制208通常仅担当可以做出的保留R 210的量的松散的上界。最后，正常提交值Cn可以总是到达R的值，即使这要求资源管理器108与资源提供者112合作来回收可能已向其它客户机102保留或分配的任何超额提交的资源Ce。正常提交值Cn中小于R 210的任一部分也可获得性能益处，因为由于预算中的R值先前已对照分层结构中的限制来确认，从而避免了对分层结构的遍历来找出限制考虑事项。再一次，正常提交值Cn可具有的最大值是由L 208来界定的，但是由于分层结构限定以及资源的过度预定，它可能永远都不会达到该值。
图4是更详细地描述图1所示的用于实现本发明的一个实施例的预算的某些组件的安排的框图。如上所述，特定进程202或线程204的活动预算104可在其生存期期间多次改变，这至少部分地取决于该进程或线程作为其代表执行的客户机102。在某些情况下，为资源记账目的临时与特定的预算相关联是有益的。例如，在为一个或多个客户机在一组并发执行的线程上执行服务的服务进程的情况下，可能期望基于该进程或线程当前正作为其代表来执行的特定客户机来强制实施预算限定并记录消耗。示例包括驱动程序和服务，它们通常代表客户机来执行工作(并消耗资源)。
在资源管理系统100的一个典型实施例中，这一预算强制实施和消耗记录可以通过使用客户机资源-身份模拟400来实现，对其的概括综述在图4中示出。客户机资源-身份模拟400通过允许进程或线程假定客户机的资源-身份410来定位并临时附加412到客户机的活动预算104，临时将进程或线程202、204与客户机102相关联。资源管理器108然后能够正确地强制实施活动预算的限定，并记录进程或线程202、204代表客户机102使用的资源408的消耗。在一个典型的实施例中，客户机的资源-身份410可以从应用程序ID 402或诸如当前令牌等系统为客户机102维护的其它标识信息中派生。
在一个典型的实施例中，客户机资源-身份模拟400在服务，即代表服务操作的进程或线程202、204都分配且补充了资源，同时临时附加到客户机的活动预算104的情况下是适当的。如果服务分配了超出模拟时段仍持久存在的资源，诸如用于本地高速缓存的对象(句柄)或存储器，则这不应当被计入客户机中，因为这些资源通常是由服务来维护的，以便于不同客户机的其它未来请求。由此，在一个典型的实施例中，在接收到客户机请求之后，服务首先在给定实现客户机的任务所需的资源的特性和生存期的情况下，确定资源客户机模拟是否是适当的。即使服务确定模拟是动作的适当过程，服务也必须具有足够的特权来定位并将其本身附加到客户机的预算104。如果服务没有足够的特权来实现资源客户机模拟，或者确定这一模拟是不适当的，则服务可如下所述采取替换的动作来限制资源的使用。
由于代表服务操作的进程或线程204、202可以向任意数量的客户机提供服务，但是可响应于特定的客户机请求(诸如句柄)来分配持久资源，因此进程(或线程)可能期望以每一客户机的方式对这一使用施加某种类型的限制。由此，服务进程或线程204、202可采取以下两种方法中的一种来以每一客户机的方式限制其自己的资源消耗要么限制给定客户机102能够调用服务的速率，要么划分其自己的预算来反映其客户机。
在第一种情况下，服务可通过使用由资源管理器108提供的速率控制器120功能，限制客户机可调用服务的速率，来控制特定客户机迫使服务耗尽其自己的资源的速率。这可缓和特定客户机的请求可能对服务解决系统中所有客户机的需求的能力所产生的效应。为避免用对每一服务的速率限制来分配每一客户机预算的额外开销，默认地通常在任何预算104中不存在任何这样的限制。相反，对施加这一限制感兴趣的服务可动态地将限制414插入到客户机的预算104中，这是通常要求适当的访问权限的操作。例如，资源提供者112可基于当试图计入特定的资源时返回的失败代码来自动尝试动态限制插入。资源管理器108然后可在强制实施客户机的活动预算104时使用资源速率控制器120来强制实施该限制。由于与预算104相关联的任何客户机102可导致附加的每一服务限制被插入到预算中，因此资源管理器108可在速率补充期间周期性地清除最近最少使用的预算条目。
在第二种情况下，服务向感兴趣的每一客户机分配特色404，并将与该特色相关联的期望的资源限制406动态地插入(416)到其自己的活动预算418中。这允许服务以每一客户机的方式定量分配其自己的资源使用。注意，在这一情况下，跟踪哪一特色对应于哪一客户机的负担落在服务而非资源管理器108上，而在第一种情况下，一旦限制被插入到客户机预算104中，资源管理器108将自动强制实施对其的遵守。
注意，对第二种情况下所示的特色的使用也可以用类似于希望基于使用类型管理其自己的资源使用的客户机102的方式来应用。在该情况下，客户机维护其自己的特色404以及对应的特色资源限制406，并根据它们当前如何使用特定资源动态地将这些限制插入到其活动预算104中。
驱动程序可以用类似于服务的方式来限制资源。然而，一般而言，正确的模拟可能变得困难，因为驱动程序可能不必要地响应于客户机请求而非响应于外部事件来执行代码。由此，驱动程序在它执行资源分配时可能不在适当的上下文中。如果驱动程序希望采用模拟方法，则它可自己维护对适当的预算的引用，并适当地管理其使用。再一次，这一方法使得客户机预算易受驱动程序资源泄漏和/或错误资源使用的影响。此外，当考虑由驱动程序分配但计入客户机预算的持久内核状态时，会引发公平性问题。在一个典型的实施例中，驱动程序可通过使用如上所述每一客户机的特色404以及特色资源限制406划分其自己的预算来避免这些问题，并相应地分配资源。然而，由于驱动程序不在单个客户机的上下文中执行，因此活动特色可作为参数或通过传递对实际预算的引用而被显式地指定到资源分配API，或者可在驱动程序执行的持续时间中隐式地与当前客户机(或当前处理器)相关联。
图5是更详细描述图1所示的用于实现本发明的一个实施例的资源通知服务124的某些组件的安排的框图。资源管理能够在与为其管理资源的客户机102的协作下最好地工作。因此，资源管理系统的一个典型实施例包括通知服务组件500。在所示的实施例中，通知服务500必须向客户机102传递(508)资源通知502，以使资源管理系统100能够请求这些客户机的协作来实现降低的资源消耗或临时挂起，或向客户机102通知可能影响它们或它们可能感兴趣的资源可用性改变。通知502的目的是给予客户机102与资源管理器108协作的机会，但是系统100必须在即使客户机出错的情况下也能够继续尽其所能地运作。
通知服务500向所关注的客户机102提供了一种可靠且轻量级的事件通知机制。客户机102可选择期望的传递方法，该传递方法具有各种级别的传递保证。在一个典型的实施例中，通知502由表示已发生的一组事件的位掩码504构成。另外，与通知502相关联的辅助通知参数506可以通常通过使用带外应用程序编程接口(API)在客户机102和通知提供者(例如资源管理器108或资源提供者112)之间可任选地传递。
在一个实施例中，通知服务500使用一种拉式系统来管理事件传递，这给予客户机102决定何时(如果有的话)检索完整的通知位掩码504的自由。客户机感兴趣的集合(通知提供者支持的位掩码的某些客户机指定的子集)中事件的首次发生触发了由客户机指定的传递技术，而随后同一类型或不同类型的事件被批处理到储存的位掩码中。由此，特定事件的重复发生将丢失，直到客户机决定检索位掩码504，此时批处理的位掩码被复位(即，清零)。取决于所选择的传递方法，该方法给予客户机102以其自己的意志处理通知502的自由。资源通知服务124的示例使用将参考以下图6中的资源仲裁来描述。
图6是更详细描述图1所示的用于执行依照本发明的一个实施例的资源仲裁600的资源管理系统100的某些组件的安排的框图。在操作中，资源提供者112从请求客户机102D接收资源分配请求。如果资源提供者112由于没有足够的资源可用而不是仅仅由于请求客户机102D超出了预算资源限制而无法满足该资源分配，则资源提供者可请求资源管理器108使用资源仲裁器122的工具来执行资源仲裁。
在一个典型的实施例中，资源提供者112向资源管理器108提供了确定是否应从某些未决的分配中回收资源以满足请求客户机的请求所需的信息。资源管理器108进而结合包含在策略模块114中的动态策略状态来做出这一决定。如上参考图1所描述的，策略模块114包括客户机优先级以及由诸如策略管理器116或预算管理器102C等更高级实体填充的用户首选项的策略数据库118，以及其它组件。策略模块114的细节将参考图7来进一步描述。
作为一个示例，策略数据库118可指示用户向请求客户机102分配了最高首选项。动态策略状态可指示潜在的回收目标客户机102E，以及可对该目标采取以回收资源的一组允许的动作。取决于在动态策略状态中反映的当前策略，资源管理器108可通过指示提供者通过使用必需的任何手段来满足请求客户机的分配请求，来响应调用资源提供者112的仲裁请求，这些手段包括依照在为该目标设置的允许动作中指定的动作回收可能已分配给一个或多个目标客户机102E的资源。
在试图回收资源以供请求客户机102D使用时，资源提供者112选择可从其中回收资源的潜在的目标客户机102E。如果资源管理器108没有建议用于回收的目标(如在动态策略状态中所指示的)，则资源提供者112可选择它认为适当的其资源的客户机。一旦资源提供者112选择了目标，资源管理器可使用资源通知服务124发出资源通知502，以试图请求一个或多个目标的合作来释放所述资源。作为替代，或除此之外，资源提供者112可通过发出其自己的资源通知502(同样使用资源通知服务124)和/或使用从动态策略状态中指示的一组动作中选择一个或多个动作来进行资源的回收。该组动作的范围可从被动的(联系目标客户机102E并请求它自愿放弃一定量的资源，例如，发出通知502)，到抢先的(强制回收资源)，到侵略性的(终止目标)。在一个实施例中，编写良好的客户机可通过遵守由资源管理器108以及各种资源提供者112发出的关于资源状态改变的各种通知来无缝地与被动动作协作。示例通知502可包括“释放资源X的单元”或可能是“冻结状态以供稍后的恢复”。
当客户机102诸如通过忽略所发出的通知不与通知502协作时，或者当目标客户机102E是先于资源管理的遗留应用程序或者选择不参与资源管理或不响应时，资源提供者112可逐步增强其尝试以使用抢先或侵略性动作来释放资源。
如上所述，可回收资源是可从应用程序中安全地收回而无需应用程序的协作的资源。资源总是能够从应用程序中透明地回收，但是对目标客户机102E的潜在效应可从降低的性能、减少的功能到异常终止变化。回收仅在对目标行为的效应是可预测的且不会导致非预期的终止的限度内对于更具侵略性的动作(例如，终止应用程序)才是较佳的。例如，回收方法可包括停止兑现带宽保证、解除应用程序的调度、使句柄无效、以及解除存储器资源的映射。在这一实例中，回收仅在前两个情况下才被认为是合理的，因为它在后两种情况下可能具有非确定性的效应。
应当注意，如上所述不能被回收的资源，诸如消耗的总CPU事件以及导致的总分页错误一般不服从资源仲裁。这是由于对不能被回收的资源的分配失败一般仅由于资源管理器108强制实施的人工预算的限制L 208而引起，在这一情况下，资源仲裁是不必要的。
图7是更详细地描述图1所示的用于实现本发明的一个实施例的策略模块114的某些组件的安排的框图。如图所示，策略模块114包括策略数据库118以及一个或多个策略管理器116，以及其它组件。策略在静态部分702和动态部分704的至少一个中表达，它们共同构成了资源管理器108和资源提供者112在做出其批准或拒绝保留和分配资源的确定时所使用的动态策略数据库状态706。静态部分702一般表示在策略数据库118中记录的信息，而动态部分704一般表示在创建进程或线程时生成的信息，诸如在活动预算对象700中维护的限制L 208、保留R 210以及提交的资源C 212。
如在图7所示的实施例中所示的，动态策略数据库状态706可以包括由唯一的<应用程序ID，用户ID>(<A，U>)元组标识的策略数据库条目。当创建或启动进程或线程202、204时，它们被映射到<A，U>元组。每一<A，U>元组可包括相对优先级的指示以及对映射的进程和线程的允许动作集。数据条目也可标识可主动与映射到<A，U>元组的进程和线程相关联的一个或多个预算104。
在一个典型的实施例中，允许动作集描述了在对资源冲突做出仲裁期间被认为是可接受的一组动作。对于不是最高优先级的任何<A，U>元组，必需指定至少一个这样的动作。如上所述，允许的动作的范围可以从被动的、到抢先的、到侵略性的。示例动作包括(以超时)请求客户机102放弃资源，透明地回收保留的资源，回收分配的资源，请求客户机102保存状态并移至静止状态，或强制终止客户机以回收竞争的资源。如果在允许动作集中没有指定任何动作，则映射到对应的任何<A，U>元组的任何进程或线程对于所有资源仲裁动作是不受影响的，且被认为具有无限的优先级。
动态策略数据库状态706协助资源管理器108解决可能作为分配失败的结果的任何冲突以及来自资源提供者112的后续仲裁请求，以及其它用途。在向资源提供者112建议可能的做法时，动态策略数据库状态706有利地使得资源管理器108能够在Windows和其它操作系统的当代版本中找到的先到先服务的分配策略上有显著的改进。
策略模块114的另一方面是将事先描述特定客户机102的资源需求或限制的信息储存在策略数据库118中。在一个实施例中，操作系统可查询并利用该储存的信息以确保代表客户机102执行的进程或线程202、204遵照适当的预算104或预算分层结构300中包含的相关资源需求和限定来开始其存在。该需求和限定在进程创建时应用来防止进程或线程202、204在策略模块114中所指定的需求和限定之外执行。策略管理器116可利用该特征来隔离潜在欺诈的应用程序(客户机)或确保某些客户机仅在操作系统可事先保留一组需要的资源时才启动等等。
图8是更详细描述图1所示资源提供者和的资源管理系统的某些组件之间的交互，以依照本发明的一个实施例来分配资源800的框图。如图所示，客户机资源请求802被发到负责的资源提供者112，后者进而确定它是否能满足该请求并执行请求客户机资源分配808，或者是否通过经由资源管理器108生成对客户机资源请求802的确认请求810来参与资源管理系统100。作为替代，或除此之外，在其中资源提供者112由于资源竞争而无法满足客户机资源请求802的情况下，资源提供者可通过从资源管理器108生成对仲裁的请求810，并随后依照仲裁请求810的结果来执行目标客户机资源回收812，来进一步参与资源管理系统100。
在一个典型的实施例中，对确认和仲裁的请求810可以用指定对应于发出资源请求802的客户机的<A，U>元组的查询804的形式来实现。查询804被应用于动态策略数据库状态706，且返回包含其对应的<A，U>元组的优先级小于指定的<A，U>元组的优先级的进程或线程的列表806。在一个典型的实施例中，资源提供者112可任选地向查询804提供当前使用所述资源的进程(或线程)的列表，使得从动态策略数据库状态706检索的结果列表806可以被适当地修整为合理数量的条目。
图9是示出用于依照本发明的一个实施例管理资源的资源管理工作流900的流程图。资源管理工作流900将参考资源管理系统100的各种组件的以上描述来描述，这些组件包括资源管理器108、资源提供者112、预算104以及预算分层结构300及其各自的预算值、以及策略模块114等等。
工作流900包括在分配资源之前将控制从资源提供者122转移到资源管理器118的过程902，之后是资源管理器108从资源提供者112接收确认客户机的资源保留或分配请求的过程904。资源管理器108在判别框908开始确认，此时资源管理器108咨询与分配请求相关联的活动预算906，即与发起该请求的进程或线程202、204相关联的活动预算104。如参考图3A-3B所描述的，资源管理器108强制实施活动预算104以及该活动预算为其一部分的任何预算分层结构300中的当前预算限制L 208、保留R 210以及提交C 212值。由此，万一请求超出预算的值，资源管理器108可拒绝请求。在该情况下，在过程910，如果资源提供者112请求了速率控制，则资源管理器108可强制实施速率控制，或者可在过程框912将控制返回给资源提供者112，后者在过程920进而将控制返回给客户机，从而拒绝了客户机的资源保留或分配请求。
如果请求落入预算的值之内，则资源管理器108可批准该请求。在过程框914，资源管理器108可进一步向资源提供者112通知客户机的分配请求中可从客户机的预先保留的池中满足的部分。控制在过程框916被返回给资源提供者112，之后资源提供者112可试图分配请求客户机所需的资源。在判别框918，如果分配成功，则在过程920，控制可被返回给请求客户机。否则，如果分配失败，则发生资源竞争。此时，在过程框922，资源提供者112可任选地向资源管理器108咨询资源仲裁，并在可能时依照先前参考图6所描述的这一仲裁来回收资源。一旦回收了足够的资源，资源管理工作流900可在过程框916恢复，以用如上所述的同一方式重试分配请求。
图10是可用于实现本发明的一个实施例的示例资源管理器预算接口1000的框图综述。下表1总结了接口及其预期的受众。对每一接口的简要讨论见表后。
表1在一个实施例中，创建预算接口1002可由策略管理器116和客户机102用于创建和操纵预算104和预算分层结构300。在一个典型的实施例中，预算104被创建为预算对象200，如先前参考图2所描述的。接口1002的默认行为可将新创建的预算对象200自动链接到调用者当前的活动预算，以形成预算分层结构300的一部分。在一个实施例中，调用者可通过可任选地指定指示“脱离”当前分层结构的期望的参数来覆盖默认行为。通过脱离当前分层结构，预算104有效地成为其自己的根预算。这一处理可从当前预算分层结构中存在于别处的约束中释放预算。
在大多数情况下，客户机102不管理其自己的预算104的创建，因为手动完成这一过程是困难、易于出错且繁重的。相反，预算创建的任务留给担当管理员的、具有使用策略管理器116来正确执行该任务的知识和授权的人或软件服务。在该情况下，策略管理器116可使用创建预算接口1002以在与预算相关联的进程或线程202、204被创建的同时创建预算。用于生成预算的数据(例如，应当使用什么参数来填充预算限制L 208，事先执行什么保留等等)可以从策略数据库118或从使用试探法来调整系统行为的自动化的管理软件中储存。在一个典型的实施例中，策略数据库118可以在考虑了资源的可用性、客户机的特性以用户首选项的情况下事先填充。
一般而言，当最初使用创建预算接口1002创建预算104时，不在该预算中提交或保留任何资源。因此，需要预填充(以实现机器分区和隔离)的预算通常首先由策略管理器116使用创建预算接口1002创建，然后被传递到保留资源接口1004以实现必要的保留，如下文所描述的。
预算104可以在创建进程时动态地与进程组、进程或(可能地与)线程相关联。例如，在一个实施例中，一旦使用了创建预算接口1002创建，预算104可作为形参被传递到处理进程(或线程)创建的例程，使得新进程(或线程)自动与预算中指定的资源限定相关联，并因此服从该限制。
创建预算接口1002可用于通过在创建预算时指定指示一个或多个特色的参数来外部地划分资源使用。在缺少这一指示的情况下，创建预算接口1002的默认行为可以是创建具有单个中性特色的预算，可对照该特色来掌控所有的资源使用。作为替代，或除此之外，可在创建预算之后将一个或多个特色动态地插入到其中，如在下文中参考插入特色接口1016所描述的。这补充客户机对特色的使用，以内部地划分资源使用，例如用于限制特定任务对资源的耗尽或保留资源以供从出错中恢复使用。
在一个实施例中，保留资源接口1004可由客户机102用于保留一个或多个资源以供将来使用。以此方式，对客户机102施加了获取资源的事务手段，以避免涉及资源获取的顺序的死锁情况。然而，这主要是对客户机102的协助；如果客户机如此期望，则接口1004可以被调用多次以独立地或随时间的推移保留资源。由于保留资源一般使得该数量的资源在系统级不可用，因此保留通常在本质上是保守的。可使用软限制来改善对保留的过度使用的可能性，以及避免资源的利用不足。
在一个典型的实施例中，一旦成功地做出了保留，就更新保留值R 210以反映该保留，且客户机102可提交多达预算的提交值C 212中所表示的数量的资源，而无需资源仲裁；它可在正常的服务级别提交多达限制L 208的资源。当预算的限制L 208是软限制时，客户机102可在降低的服务级别提交超过限制L的资源，使得系统可在将来有效地回收它以供其它Cn分配使用。
在一个实施例中，保留资源1004接口提供了一种在当前活动的预算以及适用的预算分层结构300(如果有的话)的上下文中确认保留资源，即批准或拒绝保留请求的手段。对应资源的实际保留通常是由资源提供者112本身单独处理的。以此方式，对资源请求强制实施了两个级别的控制，一个级别由资源管理器108依照当前活动的预算和预算分层结构(如果有的话)实施，而另一个级别由资源提供者112实施。由此，可在当前活动预算和预算分层结构的方面批准的保留请求可能在被呈现给适当的资源提供者112时失败，同样，被资源提供者112认为可接受的保留请求可能被资源管理器108抢先拒绝。
一旦使用了保留资源接口1004在适用的预算分层结构300的上下文中确认了特定的保留请求，给定所有的未决保留，确定实际的资源保留是否可被满足(即，分配)的责任就落在资源提供者112上。因此，可提供注册批准回叫1006接口，使得资源管理器108可确认客户机的保留请求是被资源提供者112授权还是不授权。被授权的保留请求可使得资源的该部分不可用于其它客户机102的正常提交Cn使用。因此，当该请求被授权时，资源管理器108更新预算分层结构300中适当的一个或多个预算，以准确地反映未决资源保留的当前状态。
在一个实施例中，查询预算接口1008可由客户机102用于检查其预算104中维护的特定限定和需求。例如，查询预算的能力可以对继承预算或具有外部分配的预算的客户机102尤其有用。通过检查其预算的当前状态，客户机可做出关于如何调整其资源使用以停留在其预算之内的明智决策。例如，在查询其预算之后，客户机102可能希望向资源管理器108和资源提供者112注册以接收期望的资源变得可用的通知等等。作为另一示例，并非等待接收通知，而是客户机102可决定在它们认为所必需的时候修改其预算，以试图更快速地获得它们所需的资源(假定它们具有足够的授权来这样做)。作为又一示例，资源管理器108可使用通知来请求协作的客户机通过减少其高速缓存的信息的大小或改变用于对空间和时间或时间和空间进行权衡这种的算法集来减少其资源消耗。资源管理器还可调整预算中的限制，以防止系统经历资源短缺。
可向资源提供者112提供记录消耗接口1010以跟踪随时间推移的资源消耗。在一个实施例中，参与资源管理系统100的每一资源提供者112负责在向客户机102分配了支持的资源之后，即在提交了资源之后调用记录消耗1010接口。资源管理器108然后可跟踪提交的资源值(Cn)，以便于以回收资源为目标的任何可能的未来资源管理器决策。相反，跟踪和管理所提交的资源中的哪一部分可被分类为超额提交Ce通常留给资源提供者112，如下文参考余量所描述的。
在一个典型的实施例中，使用记录消耗接口1010来跟踪资源的消耗不要求例如通过使用保留资源接口1004来事先保留该数量。当资源可用时，它可默认地在它被分配给客户机102时隐式地“保留”。万一强制实施当前活动的预算禁止资源管理器108批准完整数量的所记录消耗作为正常提交Cn的一部分，则记录消耗接口1010可将余量报告回资源提供者112。在这一情况下，假定客户机102指示超额提交Ce资源是可接受的，支持软限制的资源提供者112可任选地将余量分配给客户机作为超额提交Ce。由于超额提交Ce资源可以比正常提交Cn更容易地回收，因此某些客户机可能宁愿放弃超额提交，而等待可在正常提交中分配的资源可用。在大多数隐式消耗的资源的情况下，相关联的资源提供者112通常在管理资源的超额提交Ce分配时具有相当大的灵活性。
在一个典型实施例中，资源提供者112在记录消耗接口1010中指定所掌控的资源的身份。以此方式，资源管理器108能够掌控对正确资源的消耗。此外，资源管理器108也可确定是否需要使用插入限制接口1014将动态限制插入到预算中，如在下文进一步描述的某些动态引入的资源的情况下。
可向策略管理器116、客户机102和服务提供设置标记接口1012以注册对特定预算104跟踪的正常提交Cn值何时超过预算的标记值214的一次性通知。如果期望附加的通知，则策略管理器116和客户机102可以显式地使用设置标记接口1012重新注册。在一个实施例中，注册者可指定通知传递的期望方法，这至少包括资源管理器108所支持的所有通知机制，如参考图5概括描述的。作为一个示例，基于标记的通知可用于在一旦资源消耗超过预算的标记值时改变资源记账模型。
可向策略管理器116提供插入限制接口1014以将限制L 208动态地插入到预算104中。例如，当资源由如参考图4所描述的代表客户机操作的服务消耗时，服务可通过使用插入限制接口1014将限制插入到客户机的活动预算中，以控制客户机可迫使服务耗尽后者的资源的速率。在随后的调用时，客户机102将服从该动态插入的限制。在一个典型的实施例中，仅可信策略管理器116和服务可拥有必需的特权来将动态限制插入到目标预算中，因为恶意地将低限制插入到客户机的预算中将构成拒绝服务攻击。
可向客户机102，包括代表客户机操作的服务和驱动程序提供插入特色接口1016，以如先前参考图4所描述的动态地将特色插入到预算104中。在一个实施例中，客户机102可使用插入特色接口1016来将特色插入到其自己的当前活动的预算中。将特色动态地插入到属于不同客户机的预算中可使特色的目的失效，特色一般旨在向客户机提供一种在由其自己的预算施加的约束内管理其自己的资源使用的手段。为避免该困难，使用特色的内部和外部资源划分必须依赖于不同的特色集。
在图4所介绍的示例中，服务可使用插入特色接口1016来基于它正作为其代表操作的特定客户机102的标识描绘其预算的特色(划分)。在客户机102和特色之间建立映射完全留给服务进行。可由希望基于正作为其代表消耗资源的特定客户机来定量分配其资源使用的驱动程序采用类似的情形。由此，特色管理的负担落在选择使用插入特色接口1016来动态地插入它们的服务或驱动程序上。
作为替代，或除此之外，在无需动态特色的情况下，诸如网络驱动程序希望在一组预定义的静态数据包类型之间划分其允许的存储器使用，则无需使用插入特色接口1016来动态地指定特色。相反，期望的特色可在使用创建预算接口1002时创建预算时指定，这可能会产生性能益处。
特色也可用于实现出错恢复和提高软件健壮性和可靠性。通过以仅用于从系统中的低资源情况中恢复的特色来保留资源，软件仍能够充足地运作来恢复。例如，客户机需要足够的可用资源来响应于它应当通过收缩高速缓存来减少资源消耗的资源管理器108通知。
最后，可向服务和其它组件提供设置预算接口1016来临时将代表客户机102执行的进程或线程202、204附加到特定的预算104以及其它用途，如参考图4中的客户机资源-身份模拟情形所描述的。对于附加操作的持续时间，服务的所有资源使用可被计入指定的预算中。在进行附加的时间段中保留、分配并释放资源的情况下，设置预算接口1016为服务提供了一种直接代表请求客户机执行操作以对照客户机的预算而非其自己的预算来掌控资源消耗的方法。
以上讨论旨在提供对适用于实现本发明的各种特征的计算系统的简要概括描述。尽管是在可在分布式计算环境中使用的个人计算机的通用上下文中描述的，在分布式计算环境中，补充任务可由通过通信网络链接的远程计算设备来执行，但本领域的技术人员可以理解，本发明也可以用其它计算机系统配置来实施。例如，本发明可以用在独立的环境中操作的个人计算机，或用多处理器系统、小型机、大型计算机等来实施。另外，本领域的技术人员可以认识到，本发明可以在其它类型的计算设备上实施，包括膝上型计算机、平板计算机、个人数字助理(PDA)、蜂窝电话、游戏控制台、个人媒体设备或可在其上安装计算机软件或其它数字内容的任何其它设备。
为方便起见，对适用于实现本发明的各种特征的计算系统的某些描述包括对Windows操作系统的引用。然而，本领域的技术人员将认识到，这些引用仅是说明性的，并不用于局限本发明的一般应用。例如，本发明可以在诸如LINUX或UNIX操作系统等其它操作系统的上下文中实施。
本发明的某些方面是按照由操作系统结合个人计算机执行或访问的程序来描述的。然而，本领域的技术人员将认识到，这些方面也可结合各种其它类型的程序模块或数据结构来实现。一般而言，程序模块和数据结构包括执行特定任务或实现特定抽象数据类型的例程、子例程、程序、子程序、方法、接口、进程、过程、功能、组件、架构等等。
权利要求
1.一种便于在计算机系统中有效地管理资源的方法，所述方法包括跟踪第一预算中涉及至少一个客户机对资源的使用的值，所述值包括表示可被分配给客户机的最大资源量的第一限制，以及表示已经被分配给客户机的资源量的第一提交；接收资源提供者确认向所述至少一个客户机分配资源量的客户机请求的请求；以及如果将所述第一提交增加所请求的量不会导致所述第一提交超过所述第一限制，则确认所述客户机请求。
2.如权利要求1所述的方法，其特征在于，还包括从所述资源提供者接收对所请求的量已被分配给所述至少一个客户机的确认；以及将所述第一提交增加所请求的量。
3.如权利要求2所述的方法，其特征在于，所述第一限制是软限制；且其中，将所述第一提交增加所请求的量包括将正常提交增加到所述第一限制；且所述方法还包括将超过所述第一限制的余量作为超额提交报告给所述资源提供者，其中，所述正常提交表示可在正常的服务级别分配给所述至少一个客户机的量，且所述超额提交表示可在降低的服务级别分配给所述至少一个客户机的量。
4.如权利要求1所述的方法，其特征在于，所述值还包括表示可被预分配给所述客户机的最大资源量的第一保留，所述第一保留是由所述第一限制界定的；接收所述资源提供者确认向所述至少一个客户机预分配资源量的客户机请求的请求；以及如果将所述第一提交增加所请求的量不会导致所述第一提交超过所述第一保留，则确认所述客户机请求。
5.如权利要求4所述的方法，其特征在于，还包括从所述资源提供者接收对所请求的量已被预分配给所述至少一个客户机的确认；以及将所述第一提交增加所请求的量。
6.如权利要求1所述的方法，其特征在于，还包括跟踪第二预算中涉及至少一个其它客户机对同一资源的使用的值，所述值包括表示可被分配给所述其它客户机的最大资源量的第二限制，以及表示已被分配给所述其它客户机的资源量的第二提交；分层地将所述第一和第二预算相关，作为具有表示可被分配给所述第一和第二预算的所有客户机的最大资源量的有效限制的值的公共根预算的子预算；接收所述资源提供者确认向所述至少一个其它客户机分配资源量的客户机请求的请求；累计所述第一和第二提交；以及如果将所累计的提交增加所请求的量不会导致所累计的提交超过所述有效限制，则确认所述客户机请求。
7.如权利要求1所述的方法，其特征在于，所述资源使用还服从特色限制，所述特色限制基于所述资源使用的类型；且其中，如果所述客户机请求不导致所述客户机的资源使用超过对所述资源使用类型的特色限制，则确认所述客户机请求。
8.如权利要求1所述的方法，其特征在于，还包括接收所述资源提供者仲裁对所述资源的客户机请求的请求；为当前向其分配资源的目标客户机确定相对优先级以及至少一个允许的动作；以及当基于所述相对优先级和所述至少一个允许的动作可从所述目标客户机回收资源时，赞同所述请求客户机做出仲裁。
9.如权利要求8所述的方法，其特征在于，为所述目标客户机确定相对优先级以及至少一个允许的动作包括生成对策略数据库的查询。
10.如权利要求8所述的方法，其特征在于，还包括通知可从其中回收资源的所述目标客户机自愿放弃所述资源。
11.如权利要求8所述的方法，其特征在于，所述至少一个允许的动作是被动动作、抢先动作和侵略性动作之一。
12.一种用于管理计算设备中的资源的系统，所述系统包括编码了对资源的限定的预算分层结构；代表与所述预算分层结构中的预算相关联的客户机操作的进程；基于所述预算分层结构中编码的限定确认对资源量的客户机请求的资源管理器，所述限定包括表示可由资源提供者分配给所述客户机的最大资源量的限制；以及响应于所确认的客户机请求将所请求的资源量分配给所述进程的资源提供者。
13.如权利要求12所述的系统，其特征在于，如果将所请求的资源量分配给所述进程不会导致所述客户机超过其资源的预算限制，则所述资源管理器确认所述请求，且如果将所请求的资源量分配给所述进程将导致所述客户机超过其资源的预算限制，则使所述请求无效。
14.如权利要求12所述的系统，其特征在于，所述限定还包括表示已分配给所述客户机的资源量的提交，所述提交包括表示在所述限制内分配的量的正常提交，以及在超出所述限制分配的量的超额提交，其中，如果添加到所述正常提交的所请求的量在其资源的预算限制之内，则所述资源管理器确认所述客户机请求。
15.如权利要求14所述的系统，其特征在于，所述限定还包括表示可由资源提供者预分配给客户机的最大资源量的保留，所述保留是由所述限制约束的，且其中，如果将所请求的资源量预分配给所述进程不会导致所述客户机超出其资源的预算保留，则所述资源管理器确认所述客户机请求，且如果将所请求的资源量预分配给所述进程将导致所述客户机超过其资源的预算保留，则使所述请求无效。
16.如权利要求14所述的系统，其特征在于，所述预算分层结构中的限定沿所述分层结构向上累计，以提供可被分配给所述预算分层结构中的子树内的预算的所有客户机的最大资源量，该最大资源量还服从可被分配给所述预算分层结构内的所有预算的所有客户机的最大资源量。
17.如权利要求13所述的系统，其特征在于，还包括为当前向其分配资源的目标客户机提供相对优先级和允许的动作中的至少一个的策略模块；以及其中，所述资源管理器通过基于所述相对优先级和允许的动作中的至少一个，在可从当前向其分配资源的至少一个目标客户机回收资源时赞同请求客户机做出仲裁，来仲裁所述客户机请求。
18.如权利要求17所述的系统，其特征在于，所述允许的动作是被动动作、抢先动作以及侵略性动作之一。
19.一种具有用于管理计算设备中的资源的指令的计算机可访问介质，所述指令包括对向组织成预算分层结构的预算中的客户机分配资源的限制进行编码，所述限制表示可分配给所述客户机的最大资源量；获得与做出对限制的资源的请求的客户机相关联的活动预算，所述活动预算处于所述预算分层结构的一层上；如果向所述客户机分配所述资源不会导致所述客户机超出所述活动预算以及所述预算分层结构内与所述活动预算处于同一或更高层的任何预算中的预算限制，则批准所述请求。
20.如权利要求19所述的计算机可访问介质，其特征在于，所述指令还包括标识当前向其分配所述资源的目标客户机；获取与所标识的目标客户机的每一个相关联的相对优先级以及允许动作集；以及通过依照所述相关联的相对优先级和允许动作集从所述目标客户机的至少一个中回收资源，来仲裁所述客户机请求。
全文摘要
本发明管理计算设备中的资源以便于在设备上操作的竞争客户机之间分配资源。构造预算分层结构以对由资源提供者分配给一个或多个客户机的资源的累计使用的限制进行编码。资源管理器依照构成分层结构的预算确认并仲裁由资源提供者向一个或多个客户机分配资源的请求。资源管理器向客户机通知资源的可用性和短缺，以提升对分层结构的预算中编码的限制的依从性。
文档编号G06F9/50GK1825289SQ20061000691
公开日2006年8月30日 申请日期2006年1月23日 优先权日2005年2月22日
发明者A·吉杉, D·B·普罗伯特 申请人:微软公司