在便携式计算装置中将资源请求分批成事务及使此事务分叉

摘要

在具有基于节点的资源架构的便携式计算装置中，分批或以其它方式事务处理资源请求以帮助最小化处理实体间的消息传递或其它消息传递，或提供其它益处。在定义架构的资源图中，所述图的每一节点或资源表示由处理器或其它处理实体控制的一或多个资源的功能性的封装，每一边缘表示客户端请求，且所述图的邻近节点表示资源依赖性。使针对所述资源中的两者或两者以上提供的资源请求的单个事务分叉以使得实现发出所述单个事务的客户端与处理所述单个事务的所述请求的所述资源之间的并行处理。

说明书

优先权及相关申请案声明

本申请案依据35U.S.C.§119(e)主张2011年12月7日申请的标题为“在便携式计算装置中分批及分叉资源请求(BATCHING AND FORKING RESOURCE REQUESTS INA PORTABLE COMPUTING DEVICE)”的第61/567,963号美国临时专利申请案的优先权，所述申请案的全部内容特此以引用的方式并入。

另外，本申请案为2010年9月15日申请的标题为“用于管理便携式计算装置的资源的系统及方法(SYSTEM AND METHOD FOR MANAGING RESOURCES OF APORTABLE COMPUTING DEVICE)”的第12/882,395号美国专利申请案的部分接续申请案，所述申请案的内容以引用的方式并入本文中。

背景技术

便携式计算装置(“PCD”)正逐渐流行。这些装置可包含蜂窝式电话、便携式/个人数字助理(“PDA”)、便携式游戏控制台、便携式导航单元、掌上型计算机及其它便携式电子装置。这些装置中的每一者可具有主功能。举例来说，蜂窝式电话通常具有接收及发射电话呼叫的主功能。

除了这些装置的主功能之外，许多装置包含外围功能。举例来说，蜂窝式电话可包含进行如上文所描述的蜂窝式电话呼叫的主功能，及静态相机、摄像机、全球定位系统(“GPS”)导航、网络浏览、发送及接收电子邮件、发送及接收文字消息及一键通能力等外围功能。随着PCD的功能性增加，支持所述功能性所需要的计算或处理能力也增加。可通过增加PCD中的处理器的数目来增加处理能力。随着处理器的计算能力及数目增加，对有效地管理处理器存在更大的需求。

例如上文所描述的功能等功能可体现于可被称作资源的各种对应硬件及软件元件中。处理器可在例如应用程序等软件的控制下在各种时间请求各种资源。在多处理器PCD中，第一处理器可控制不同于由第二处理器控制的资源的资源。然而，第一处理器可需要能够请求由第二处理器控制的资源。

发明内容

用于在具有多个资源的便携式计算装置中分批或以其它方式事务处理资源请求的方法及系统可帮助最小化处理器间消息传递或其它消息传递，或提供其它益处。在具有基于节点的软件架构的便携式计算装置中，资源可包含于节点中。在示范性方法中，实例化多个节点。节点的多个资源可由有向非循环图来定义。所述图的每一节点或资源表示由处理器或其它处理实体控制的一或多个资源的功能性的封装。所述图的每一边缘表示客户端请求。所述图的邻近节点表示资源依赖性。根据示范性方法，可提供对资源中的两者或两者以上的资源请求的单个事务。

另外，可使资源请求的此单个事务分叉以使得可能发生并行处理。举例来说，在分叉事务的情况下，发出资源请求的单个事务的客户端可继续运行，发出其它请求或执行一些其它处理，而不要等待事务完成，即等待由资源服务的事务内所发出的请求。接收及负责事务中的请求的资源可与客户端继续运行并行地处理这些请求，如上文所描述。

附图说明

在图中，各图中相同参考数字始终指代相同部分，除非另有指示。对于具有例如“102A”或“102B”等字母字符标记的参考数字，字母字符标记可以区分同一图中存在的两个相同部分或元件。当意欲参考数字包含在所有图中具有相同参考数字的所有部分时，可省略参考数字的字母字符标记。

图1为说明用于便携式计算装置(“PCD”)中的分布式资源管理的系统的示范性元件的功能框图；

图2为说明第一处理器需要请求由第二处理器控制的资源的情况的实例的功能框图；

图3为管理PCD的资源的节点架构的第一方面的图；

图4为用于PCD的示范性资源的群组的有向非循环资源图；

图5为管理PCD的资源的节点架构的第二方面的总图；

图6为管理PCD的资源的节点架构的第二方面的具体图；

图7为说明用于创建用于管理PCD的资源的节点架构的方法的流程图；

图8为说明用于创建用于管理PCD的资源的节点架构的方法的图7的延续流程图；

图9为说明用于接收PCD的软件架构中的节点结构数据的图7到8的子方法或例程的流程图；

图10为说明用于创建PCD的软件架构中的节点的图7到8的子方法或例程的流程图；

图11为说明用于创建PCD的软件架构中的客户端的图10的子方法或例程的流程图；

图12为说明用于创建对PCD的软件架构中的资源的客户端请求的方法的流程图；

图13说明两个处理器之间的通信路径，所述两个处理器各自控制其自身资源图的资源；

图14为说明用于创建用于管理PCD的资源的节点架构的方法的另一流程图，其中资源中的一些为分布式资源；

图15为说明用于创建对PCD的软件架构中的分布式资源的客户端请求的方法的另一流程图；

图16为说明用于处理对PCD的软件架构中的非代理分布式资源的状态查询的方法的流程图；

图17A为说明用于处理对PCD的软件架构中的非代理分布式资源的状态查询的方法的第一部分的流程图；

图17B为说明用于处理对PCD的软件架构中的非代理分布式资源的状态查询的方法的第二部分的流程图。

图18为说明用于分批或事务处理多个资源请求的方法的流程图。

图19为示范性资源图，其中图拓扑排除死锁条件。

图20为另一示范性资源图，其中图拓扑不排除死锁条件。

图21为说明发生死锁的情况的示范性事件时间线。

图22为说明保守式锁定方法防止死锁的情况的另一示范性事件时间线。

图23为说明资源用来处理可为资源请求事务的部分的资源请求的方法的流程图。

图24为展示用于管理便携式计算装置中的分批及分叉资源请求的方法及系统的实施例的操作的时间线图。

具体实施方式

词“示范性”在本文中用以意谓“充当实例、例项或说明”。本文中描述为“示范性”的任何方面不一定要解释为相比其它方面优选或有利。

在此描述中，术语“应用程序”还可包含具有可执行内容的文件，例如：目标代码、脚本、字节代码、标记语言文件及补丁。另外，本文中所指代的“应用程序”还可包括本质上不可执行的文件，例如可能需要打开的文档或其它需要存取的数据文件。

术语“内容”还可包含具有可执行内容的文件，例如：目标代码、脚本、字节代码、标记语言文件及补丁。另外，本文中所提到的“内容”还可包括本质上不可执行的文件，例如可能需要打开的文档或其它需要存取的数据文件。

如此描述中所使用，术语“组件”、“数据库”、“模块”、“系统”等等意欲指计算机相关实体，即硬件、固件、硬件与软件的组合、软件或执行软件。举例来说，组件可为(但不限于为)在处理器上运行的进程、处理器、对象、可执行程序、执行线程、程序及/或计算机。作为说明，运行于计算装置上的应用程序及计算装置两者可为组件。一个或一个以上组件可驻存在进程和/或执行线程内，且组件可位于一个计算机上且/或分布在两个或两个以上计算机之间。另外，这些组件可从各种计算机可读媒体处执行，所述计算机可读媒体具有存储于其上的各种数据结构。所述组件可例如根据具有一个或一个以上数据包的信号(例如，来自借助于所述信号与局域系统、分布式系统中的另一组件交互及/或跨越例如因特网等网络而与其它系统交互的一个组件的数据)借助于本地及/或远程处理而通信。

在此描述中，可互换地使用术语“通信装置”、“无线装置”、“无线电话”、“无线通信装置”及“无线手持机”。随着第三代(“3G”)及第四代(“4G”)无线技术的到来，更大带宽可用性使得更多便携式计算装置能够具有更多种类的无线能力。

在此描述中，术语“便携式计算装置”(“PCD”)用以描述操作于有限容量电力供应器(例如，电池)上的任何装置。尽管电池操作PCD已使用了数十年，但可再充电电池的技术进展加上第三代(“3G”)及第四代(“4G”)无线技术的到来使得众多PCD能够具有多种能力。因此，PCD可为蜂窝式电话、卫星电话、寻呼机、个人数字助理(“PDA”)、智能手机、导航装置、智能本或阅读器、媒体播放器、前述装置的组合及具有无线连接的膝上型计算机等等。

图1为用于实施用于便携式计算装置中的分布式资源管理的方法及系统的呈无线电话形式的PCD100的示范性非限制方面的功能框图。如图所示，PCD100包含芯片上系统102，其具有多核心中央处理单元(“CPU”)110A、图形处理器110B及模拟信号处理器126。这些处理器110A、110B、126可在一或多个系统总线或另一互连架构上耦合在一起，如所属领域的一般技术人员所知的。

CPU110A可包括第零核心222、第一核心224等到第N核心226，如所属领域的一般技术人员所理解。在替代实施例中，替代CPU110A及图形处理器110B，还可使用一或多个数字信号处理器(“DSP”)，如所属领域的一般技术人员所理解。另外，在替代实施例中，可包含两个或两个以上多核心处理器。

如图1中所说明，显示控制器128及触摸屏控制器130耦合到多核心CPU110A。在芯片上系统102外部的触摸屏显示器132耦合到显示控制器128及触摸屏控制器130。PCD100中也包含视频译码器/解码器(“编解码器”)134，例如逐行倒相(“PAL”)编码器、顺序与存储彩色电视系统(“SECAM”)编码器、国家电视系统委员会(“NTSC”)编码器或耦合到多核心中央处理单元(“CPU”)110A的任何其它类型的视频编码器134。视频放大器136耦合到视频编码器134及触摸屏显示器132。视频端口138耦合到视频放大器136。如图2中所描绘，通用串行总线(“USB”)控制器140耦合到CPU110A。而且，USB端口142耦合到USB控制器140。订户身份模块(SIM)卡146还可耦合到CPU110A。另外，如图1中所示，数码相机148可耦合到CPU110A。在示范性方面中，数码相机148为电荷耦合装置(“CCD”)相机或互补金属氧化物半导体(“CMOS”)相机。

如图1中进一步说明，立体声音频CODEC150可耦合到模拟信号处理器126。此外，音频放大器152可耦合到立体声音频CODEC150。在示范性方面中，第一立体声扬声器154及第二立体声扬声器156耦合到音频放大器152。图1展示麦克风放大器158也可耦合到立体声音频CODEC150。另外，麦克风160可耦合到麦克风放大器158。在特定方面中，调频(“FM”)收音机调谐器162可耦合到立体声音频CODEC150。而且，FM天线164耦合到FM收音机调谐器162。另外，立体声头戴受话器166可耦合到立体声音频CODEC150。

图1进一步指示射频(“RF”)收发器168可耦合到模拟信号处理器126。RF开关170可耦合到RF收发器168及RF天线172。如图1中所示，小键盘174可耦合到模拟信号处理器126。而且，具有麦克风的单声道头戴耳机176可耦合到模拟信号处理器126。另外，振动器装置178可耦合到模拟信号处理器126。图1还展示耦合到芯片上系统102的电力供应器180，例如电池。在特定方面中，电力供应器180包含从连接到AC电源的交流(“AC”)到DC变压器导出的可再充电电池或直流(“DC”)电力供应器。

PCD100的上文所描述的元件中的一些可包括硬件，而另一些可包括软件，且又一些可包括硬件与软件的组合。术语“资源”在本文中用以指可由处理器控制的任何此类元件，不论是硬件、软件还是其组合。资源可在一方面中经定义为此元件的功能性的封装。除了可以其它方式指示术语“处理器”情况之外，所述术语“处理器”在本文中用以指例如CPU110、图形处理器110B、模拟信号处理器126等处理器或指在软件、固件或类似控制逻辑的控制之下操作的任何其它处理器、控制器或类似元件。对两个或两个以上“处理实体”的参考包含在不同芯片上的处理器、同一处理器芯片的不同处理核心、同一核心上的执行线程或其间可存在数据传送损失或效率不高的任何其它处理实体。

如下文更详细所描述，资源的实例为执行于处理器上的软件元件。处理器上的执行线程(例如，与执行应用程序相关的线程)可通过致使在资源上发出“请求”来存取资源。如下文所描述，经由在本发明中被称作“框架”的基于软件的系统来处理资源请求。术语“客户端”在本发明中宽泛地用以指影响请求资源的功能的元件。因此，在本文中使用所述术语时，线程可出于发出资源请求的目的创建或利用客户端。在一些情况下，应注意资源可创建或使用客户端，以使得资源可致使发出对另一资源的资源请求。如下文更详细所描述，所述其它资源可在本文中被称作“依赖”资源，这是归因于请求资源与被请求资源之间的依赖性关系。资源及客户端可由存储器中的数据结构表示。

因为资源是由多处理器PCD100中的特定处理器控制的，所以并非PCD100中的每一处理器能存取PCD100中的每一资源。图2说明PCD100中的第一处理器202可需要发出对由PCD100中的第二处理器206控制的资源204的资源请求203的情况的实例。应注意，第一处理器202也可控制多个资源205。同样，第二处理器206可控制多个额外资源207。

在第一处理器202正执行与例如视频播放器应用程序有关的线程208的情况下，线程208可需要调整第一处理器202的一或多个操作参数，这增强了第一处理器202的性能。(尽管线程208及资源204概念上出于清楚的目的被说明成驻存在其相应资源202及206中，但所属领域的一般技术人员会理解此些元件由处理器的存储器空间中的处理器根据充分理解的计算原理执行或以其它方式操作。)此些操作参数可包含例如时钟速度及总线速度。举例来说，各种处理器可使用相同总线时钟，但处理器中的仅一者可直接(硬件级)控制总线时钟。增加时钟速度可导致例如视频播放器应用程序的较佳性能，这是因为视频的播放通常为比一些其它任务更处理能力密集的任务。因为处理能力通常表达成每秒百万指令(“MIPS”)，所以线程208可发出对特定数目的MIPS的呼叫。资源电力管理器204可包含算法，其响应于对指定数目的MIPS的请求而导致信号210改变，所述信号可表示时钟速度、总线速度或促使第一处理器202在请求的MIPS级处操作的其它参数。

线程可有可能经由总线或协议所特有的应用程序编程接口(API)存取资源电力管理器204，第一处理器202可经由所述总线或接口与第二处理器206通信。然而，下文所描述的框架可提供比资源特定及总线特定API更统一的方式来处理资源请求。如下文所描述，经由框架以统一方式来发出及服务资源请求，而不考虑请求是针对由发出资源请求的相同处理器控制的资源还是针对由不同处理器控制的资源。由发出资源请求的相同处理器控制的资源可被称作“本地”资源。由除了发出资源请求的处理器之外的处理器控制的资源可在本文中被称作“远程资源”或“分布式资源”。

另外，发出对远程资源的请求会招致呈时间延迟或时延形式的处理开销。即，与处理器之间待发送的资源请求有关的一或多个消息需要特定的时间量。在一些情况下，单个资源请求可产生多个处理器间消息。本说明书中所描述的资源请求分批特征可在一些情况下帮助最小化处理器间消息的数目。

图3为包括表示PCD100的软件或硬件(或两者)的功能框的图。线“A”左边的框表示由CPU110A控制的PCD100的资源。此些资源可包含：CPU110A自身，其通常也被称作第一硬件元件(硬件元件#1)；CPU110A的时钟442，其通常也被称作第二硬件元件(硬件元件#2)；总线仲裁器或调度器422，其通常也被称作第三硬件元件(硬件元件#3)；总线程序A-444A，其通常也被称作第一软件元件(软件元件#1)；总线程序B-444B，其通常也被称作第二软件元件(软件元件#2)；时钟程序AHB，其通常也被称作第三软件元件(软件元件#3)；及由软件元件监视的动作或功能，其通常被指示为按键448。CPU110A控制或存取上文所参考的资源，因为资源在CPU110A的存储器空间内，且不存在将禁止CPU110A存取所述资源的其它限制，例如安全限制。举例来说，CPU110A可能够控制或存取所述资源的硬件寄存器。应注意，PCD100可包含控制或存取除了上文所参考的资源之外的资源的其它CPU110(见例如图2)。

可包括计算机指令库的框架管理器440管理封装资源的功能性的节点。即，可存取节点以间接地存取资源。为了便利起见，封装资源的功能性的节点可在本文中被称作包含、包括、具有(等)资源。每一节点可包含一或多个资源。节点可以软件代码、固件或类似媒体来定义，且在PCD100的操作期间实例化为例如存储器112(图1)中的数据结构。节点601可在启动、加电、初始化、开机等序列期间或在PCD100的操作期间的任何其它合适时间实例化。应注意，本文中对实例化、发出请求或以其它方式与资源交互的参考应理解为意谓与包含所述资源的节点交互。对于本发明的剩余部分，一般或非特定节点将用参考数字601来表示，如下文参看图5所描述。

举例来说，节点601可包含具有通常对应于第一硬件元件或中央处理单元110的单个资源的第一节点602。在本发明中所描述的软件架构的情况下，节点601的每一资源可具备包括一或多个字母数字字符的独特名称。在图3中所说明的示范性实施例中，将资源名称“/core/cpu”指派给第一节点602的资源。此示范性资源名称通常对应于所属领域的一般技术人员所已知的常规文件命名结构。然而，如所属领域的一般技术人员所认识到，含有字母数字字符及/或符号的任何其它组合的其它类型的资源名称恰当地在本发明的范围内。

举例来说，节点601可进一步包含具有多个资源的第二节点622。在此示范性实施例中，第二节点622具有包括对应于总线仲裁器或调度器422的单个硬件元件的第一资源。第二节点622的第二资源包括通常对应于总线程序A444A的第一软件元件的软件元件。第二节点622的第三资源包括通常对应于总线程序B444B的第二软件元件的另一软件元件。所属领域的一般技术人员认识到给定节点601的资源及资源类型的任何组合及任何数目恰当地在本发明的范围内。

图3还说明通常对应于两个软件元件448、450的动作或功能的第一客户端648。在图3中所说明的示范性实施例中，第一客户端648通常对应于按键动作，所述按键动作可在由便携式计算装置100支持的特定应用程序模块105内发生。然而，所属领域的一般技术人员认识到，软件元件的除了按键之外的其它动作及/或功能恰当地在本发明的范围内。下文将结合图11来描述关于客户端请求648及其相应创建的其它细节。

图3还说明特定架构元件之间的关系。举例来说，图3说明客户端648与第一节点602之间的关系。特定来说，第一客户端648可产生用虚线说明的客户端请求675A，所述客户端请求由包括资源“/core/cpu”的第一节点602管理或处理。通常，存在预定或设定数目个类型的客户端请求675。下文将结合图11更详细描述客户端请求675。

图3中所显示的其它关系包含用虚线680说明的依赖性。依赖性为另一节点601的相应资源之间的关系。依赖性关系通常指示第一资源(A)依赖于可将信息提供给第一资源(A)或实施某一行为的第二资源(B)。此信息可为由第二资源(B)执行的操作的结果，或所述信息可仅包括由第一资源(A)所需要的状态信息，或其任何组合。第一资源(A)及第二资源(B)可为相同节点601的部分，或其可为不同节点601的部分。应注意，客户端请求675可不仅源于执行线程(例如在上文所描述的按键动作的实例中)，而且源于其它节点601。为了从依赖节点601获得信息或行为，节点601可将客户端请求675发出到其依赖节点601。因此，指示依赖性的虚线680还可指示潜在客户端请求675的方向。

在图3中，第一节点602依赖于第二节点622，如由依赖性箭头680B所指示，所述依赖性箭头源起第一节点602且伸展到第二节点622。图3还说明第一节点602还依赖于第三节点642，如依赖性箭头680A所说明。图3还说明第二节点622依赖于第四节点646，如依赖性箭头680C所说明。所属领域的一般技术人员认识到，用图3的虚线箭头说明的依赖性680本质上仅为示范性的，且相应节点601之间的依赖性的其它组合在本发明的范围内。

框架管理器440负责维持上文所描述的关系，其包含，但不限于，图3中所说明的客户端请求675及依赖性680。例如依赖性等一些此类关系借助于资源及其节点601已被定义于PCD100中的软件代码中的方式在PCD启动时间(即，加电、初始化、开机等)处存在，框架管理器440在所述启动时间处存取所述软件代码以开始节点实例化过程。例如客户端请求675等其它此类关系在已实例化节点601之后(例如在应用程序调用资源的应用程序线程的执行期间)出现。不管客户端请求675是源自除了节点601之外的执行应用程序线程或类似元件(例如，客户端请求675A)还是源自节点601，皆经由框架管理器440引导客户端请求675。框架管理器440引导节点601之间的信息的传送。概念上，框架管理器440充当矩阵，经由所述矩阵多个线程可基本上与节点601并发通信。尽管不同线程可涉及不同数据，但相同框架管理器软件代码可服务不同线程。

如下文更详细所描述，节点601的依赖节点一经实例化(即，当已解决任何给定节点601的依赖性680时)，框架管理器440就可实例化所述节点。框架管理器440试图实例化已定义于PCD100的软件架构中的所有节点601。当支持依赖性的资源存在或处于用于处理与依赖性680有关的信息的准备状态时完成或解决依赖性680。

举例来说，如果尚未实例化包括单个资源“/clk/cpu”的第三节点642，那么包括单个资源“/core/cpu”的第一节点602可不由框架管理器440实例化，这是由于第一节点602与第三节点642之间存在的依赖性关系680A。一旦第三节点642已由框架管理器440实例化，那么框架管理器440可实例化第二节点602，这是由于依赖性关系680A。

如果框架管理器440不能够实例化特定节点601(因为其依赖性680中的一或多者不完成或未被解决)，那么框架管理器440将继续运行或执行对应于成功实例化的所述节点601的步骤。框架管理器440通常将跳过对特定节点601的呼叫(其可能归因于尚未创建依赖资源的不完整依赖性而不存在)，且将反映所述不完整状态的消息传回到所述呼叫。

在例如图1中所说明的多核心环境中，框架管理器440可在单独核心(例如，图1的第0、第一及第N核心222、224及226)上创建或实例化节点601。只要节点601不依赖于彼此且如果如下文所描述的特定节点的对应依赖性全部完成，那么通常可在多核心环境中在单独核心上且并行地创建节点601。在多处理器环境中，可在各种处理器(例如，图1的CPU110A、图形处理器110B等)上创建或实例化节点601。即，一些节点601可存在于一个处理器的存储器空间中，而另一些节点601可存在于另一处理器的存储器空间中。然而，应注意仅经由框架管理器440，一个处理器上的节点601可不由另一处理器上的节点601存取。

类似于上文所描述(主要)框架管理器440的远程框架管理器300可与框架管理器440并列存在，且作为对框架管理器440的扩展。远程框架管理器300与框架管理器440协作或合作以协调不同处理器上的节点601之间的处理器间信息传送。即，在所涉及的节点601存在于不同处理器上的情况下，远程框架管理器300帮助框架管理器440维持上文所描述的关系(例如，依赖性及客户端请求)。因此，经由框架管理器440及300的组合效果，一个处理器上的节点601可不呈现为可由另一处理器上的节点601存取。此外，框架管理器440及300的组合可执行在本文中归结于框架管理器440的所有功能，不管所涉及的节点601是存在于相同处理器上还是不同处理器上。在所述多处理器实施例中，框架管理器300及440所包括的软件的个别复本可驻存在处理器中的每一者的域中。因此，每一处理器能存取相同框架管理器软件。

图4方便地以有向非循环图(“DAG”)400的形式重新组织上文所描述的节点602、622、642及646。图400为定义上文所描述的软件架构的另一方式。在图论的词典中，图400的顶点对应于节点601，图400的边缘对应于客户端请求675，且邻近节点或顶点表示资源依赖性。所属领域的一般技术人员将认识到，图400由于依赖性而为有向图且为非循环的，这是因为框架管理器440防止定义资源A依赖于资源B且资源B依赖于资源A的循环。即，框架管理器440将不实例化经(错误地)定义为依赖于彼此的两个节点601。图的非循环性质对防止死锁来说是重要的，这是因为(如下文所描述)每一节点601在其被存取时被锁定(从事务处理的意义上说)。如果两个节点601将依赖于彼此(在第二线程将存取及锁定这些两个节点601中的一者的同时第一线程将存取及锁定这些两个节点601中的另一者的情况下)，那么两个线程将挂断。然而，在软件开发者或在定义软件架构中所涉及的其它这样的人认为需要在软件架构中定义依赖于彼此的两个资源的相当稀少情况下，两个(或两个以上)资源可包含于彼此相同的节点601中。相同节点中的两个资源将共享相同锁定状态。至少部分出于此原因，软件开发者或其它这样的人可选择在架构中定义复数资源节点，例如节点622。

尽管本发明可出于清楚及方便的目的参考“节点”601而非节点601的“资源”，但应理解客户端请求可被引导到指定资源而非节点。换句话说，从客户端或客户端请求的其它发布人(例如，另一节点601)的角度来看，如上文所描述可为封装一或多个资源的功能性的数据结构的节点601可为透明的。从客户端的角度来看，发出对资源而非对节点的请求。同样，从客户端的角度来看，架构的状态查询、事件或其它元素与资源而非节点相关联。

例如示范图400等资源图用于理解根据下文关于图6到10所描述的依赖性的节点601的实例化。例如节点642及646等叶节点在非叶节点之前实例化，因为叶节点不具有依赖性。一般来说，节点601必须在依赖于其的节点可经实例化之前实例化。此外，可看到服务资源请求对应于遍历有向非循环图，其中顶点对应于节点601，边缘对应于客户端请求675，且邻近节点或顶点表示资源依赖性。

在多处理器PCD100中，第一处理器可存取或能够控制第一资源图中的节点601的第一集合，而第二处理器可存取或能够控制第二资源图中的节点601的第二集合，其中第一及第二资源图不共享任何资源，即其为互斥的资源图。即，在所述环境中，每一处理器具有其自身的资源图，所述资源图定义资源及不可由其它处理器存取的其它元件之间的关系。本发明的分布式资源管理涉及在两个或两个以上处理器各自存取其自身资源图中的资源且不存取其它处理器的资源图中的资源的情况下，维持上文所描述的关系(例如，依赖性及客户端请求)。

在一些实施例中，在存取资源时上文所参考的限制可由硬件配置来限制。即，处理器可不具有其可影响硬件装置(例如，寄存器)的手段，这是因为硬件装置是由另一处理器控制或在另一处理器的存储器空间中。或者，或另外，在存取资源时的限制可施加于软件中，原因例如最小化处理器到安全风险(例如，可感染另一处理器的病毒)的暴露。

图5为管理图1的PCD100的资源的系统的软件架构500B1的另一方面的总图。在PCD100及所涉及的所有资源及其它元件由相同处理器控制(即，所有资源及其它元件包含于相同资源图中)的架构的上下文中，出于清楚的目的描述此方面。在此总图中，每一节点601的一或多个资源并不具备独特名称。图5的节点或资源图500B1仅包括由架构或框架管理器440支持的节点601、客户端648、事件690及查询功能695。用椭圆形及箭头680来说明每一节点601，其中特定方向表示节点601内的资源之间的相应依赖性。

图5还说明第一节点601A的客户端648可如何将客户端请求675发出到第一节点601A。在发出这些客户端请求675之后，第二节点601B可触发事件690，或提供对查询695的响应，其中对应于事件690及查询695的消息流回到客户端648。

图6为管理图1的PCD100的资源的系统的软件架构500B2的上文所描述的方面的更具体图。图6说明节点或资源图500B2，其仅包括具有特定但还是示范性的资源名称的节点601，以及对应于图3的客户端648、事件690及查询功能695。用椭圆形及箭头680来说明每一节点601，其中特定方向表示节点601内的资源之间的相应依赖性。

举例来说，第一节点602具有依赖性箭头680B来指示第一节点602依赖于第二节点622的三个资源。类似地，包括第二软件元件444B且在图11C中通常用于参考字母“C”表示的第三资源“/bus/ahb/sysB/”具有依赖性箭头680C，其指示此第三资源(C)依赖于第四节点646的单个“/clk/sys/ahb”资源。

图6还说明来自节点601的输出数据，所述输出数据可包括一或多个事件690或查询功能695。查询功能695类似于事件690。查询功能695可具有可或可不为独特的查询处理。查询功能通常不是外部识别的，且其通常不具有状态。查询功能695可用以确定节点601的特定资源的状态。查询功能695及事件690可与建立的客户端648具有关系，且这些关系由方向箭头697表示以指示来自相应事件690及查询功能695的信息被传递到特定客户端648。

图5到6的节点或资源图500B表示在处理器的控制之下存在于存储器中且由框架管理器440管理的关系。节点或资源图500B可由框架管理器440自动产生，作为用于识别由框架管理器440管理的相应元件之间的关系及用于由软件小组进行故障检测的有用工具。

图7为说明用于创建或实例化用于管理PCD100的资源的软件结构的方法1000A的流程图。在所涉及的所有资源及其它元件由相同处理器控制(即，所有资源及其它元件包含于相同资源图中)的架构的上下文中，出于清楚的目的描述此方法。框1005为用于管理PCD100的资源的方法或过程1000的第一例程。在框1005中，例程可由框架管理器440执行或运行以用于接收节点结构数据。节点结构数据可包括依赖性阵列，其概述了特定节点601可具有的与其它节点601的依赖性。下文将结合图9更详细描述关于节点结构数据及此例程或子方法705的其它细节。

接下来，在框1010中，框架管理器440可复查依赖性数据，所述依赖性数据为框1005中所接收的节点结构数据的部分。在决策框1015中，框架管理器440可确定节点结构数据是否定义叶节点601。叶节点601通常意谓待基于节点结构数据创建的节点不具有任何依赖性，例如图3到4中的节点642及646。如果决策框1015的询问为肯定的，意谓用于创建当前节点的节点结构数据不具有任何依赖性，那么框架管理器440继续到例程框1025。

如果决策框1015的询问为否定的，那么跟着“否”分支到决策框1020，其中框架管理器确定节点结构数据内的所有硬依赖性是否存在。硬依赖性可包括资源在没有硬依赖性的情况下无法存在的情况。同时，软依赖性可包括资源可使用依赖资源作为可选步骤的情况。软依赖性意谓即使在软依赖性不存在时仍可在节点架构内创建或实例化具有软依赖性的节点601或节点601的资源。

软依赖性的实例可包括优化特征，所述优化特征对于含有多个资源的面向资源的节点601的操作来说并不关键。对于未创建的具有软依赖性的所述节点或资源，即使在软依赖性不存在时，框架管理器440仍可针对存在的所有硬依赖性创建或实例化节点或资源。回调特征可用以参考软依赖性，以使得当软依赖性变得可用于框架管理器440时，框架管理器440将通知参考软依赖性的每一回调，软依赖性现在可用了。

如果决策框1020的询问为否定，那么跟着“否”分支到框1027，其中节点结构数据由框架管理器440存储于暂时存储装置(例如，存储器)中，且框架管理器440创建与此未实例化节点相关联的回调特征。

如果决策框1015的询问为肯定的，那么跟着“是”分支到例程1025，其中基于例程框1005中所接收的节点结构数据创建或实例化节点601。下文将结合图9描述例程框1025的其它细节。接下来，在框1030中，框架管理器440使用其独特资源名称发布新创建的节点601，使得其它节点601可将信息发送到新创建的节点601或从新创建的节点601接收信息。

现参看图8(其为图7的延续流程图)，在框1035中，框架管理器440通知依赖于新创建的节点601的其它节点601新创建的节点601已被实例化且准备接收或发射信息。根据一个示范性方面，当创建类似图5的节点601B的依赖节点时立即触发通知，即递归地执行通知。因此，如果构造了图5的节点601B，那么立即通知节点601A。此通知可允许构造节点601A(因为节点601B为节点601A的最终依赖性)。节点601B的构造可致使通知其它节点601等等。节点601B直到依赖于节点601B的最终资源完成为止方才完成。

第二稍微复杂的实施方案为将所有通知置于单独通知队列中，且接着在单个时间点处开始穿过队列，即反复地执行通知。因此当构造图5的节点601B时，将到节点601A的通知推到列表上。接着，执行所述列表且通知节点601A。这致使将到其它额外节点601(除了节点601A之外，图5中未说明)的通知置于相同列表上，且接着在发送到节点601A的通知之后发送那个通知。到其它节点601的通知(除了到节点601A的通知之外)直到与节点601B及节点601A相关联的工作已完成之后方才发生。

逻辑上，这两个实施方案为等效的，但其在实施时具有不同的存储器消耗性质。递归实现为简单的，但可消耗任意量的堆叠空间，其中堆叠消耗是依赖性图的深度的函数。反复实施稍微复杂且需要多一点静态存储器(通知列表)，但堆叠使用为恒定的而不管依赖性图的深度如何(例如图5中所说明)。

而且，框1035中的节点创建的通知不限于其它节点。其还可在内部用于别名构造。系统500A中的任何任意元件可在节点变得可用(不仅仅是其它节点)时使用相同机制来请求通知。节点及非节点两者可使用相同的通知机制。

在决策框1040中，框架管理器440基于当前节点601的创建确定现在是否释放其它节点601或软依赖性以用于创建或实例化。决策框1040通常确定是否可创建资源，因为某些依赖性关系680已被最近已经历创建或实例化的当前节点实现了。

如果决策框1040的询问是肯定的，那么跟着“是”分支返回到例程框1025，其中现可创建或实例化释放的节点601，因为由刚创建的节点601实现了依赖性。

如果决策框1040的询问是否定的，那么跟着“否”分支到框1045，其中框架管理器440可管理如图2中所说明的软件架构的元件之间的通信。接下来，在框1050中，框架管理器440可继续通过使用与特定资源相关联的资源名称而日志记录或记录由资源采取的动作。在由框架管理器440或由框架管理器440所管理的元件(例如，资源、节点601、客户端648、事件695及查询功能697)中的任一者采取的任何动作之后，框1045可由框架管理器440执行。框1045展示节点架构的另一方面，其中框架管理器440可维持活动的运行日志，其根据其由创建特定元件(例如，节点601的资源)的创造者提供的独特识别符或名称列出了由每一元件执行的动作。

与现有技术相比较，列出经指派给系统的每一资源的独特名称的在框1050中的活动的此日志记录为独特的，且可提供例如用于除错及错误故障检测中的显著优点。节点架构500A的另一独特方面在于单独小组可在彼此独立的不同硬件及/或软件元件上工作，其中每一小组将能够使用独特且容易跟踪的资源名称，而不需要创建表来转译由其它小组及/或原始设备制造者(OEM)指派的意义不大且常常混淆的资源名称。

接下来，在决策框1055中，框架管理器440确定是否已请求由框架管理器440记录的动作的日志。如果决策框1055的询问是否定的，那么跟着“否”分支到过程的末尾，其中过程返回到例程1005。如果决策框1055的询问是肯定的，那么跟着“是”分支到框1060，其中框架管理器440将包括有意义的资源名称及由资源名称执行的相应动作的活动日志发送到输出装置，例如打印机或显示屏及/或两者。过程接着返回到上文所描述的例程框1005。

图9为说明用于接收定义PCD100的软件架构的节点结构数据的图7的子方法或例程1005的流程图。接收方法可在任何合适时间发生，例如当启动或初始化PCD100时。在所述情况下，在处理器从存储器读取对应软件代码时接收节点结构数据，以准备根据架构实例化节点601。框1105为图7的子方法或例程1005中的第一步骤。在框1105中，框架管理器440可接收软件或硬件元件(例如，图7的CPU110及时钟442)的独特名称。如先前所论述，节点601必须参考至少一个资源。每一资源在系统500A中具有独特名称。系统500A内的每一元件可用独特名称来识别。从字符的角度来看，每一元件具有独特名称。换句话说，通常在系统500A内不存在具有相同名称的两个元件。根据系统的示范性方面，节点601的资源通常可具有跨越系统的独特名称，但客户端或事件名称并不需要为独特的，但其可在需要时为独特的。

为了便利起见，使用斜杠“/”字符以用于创建独特名称的常规树文件命名结构或文件命名“隐喻”可被使用，例如，但不限于，用于CPU110的“/core/cpu”及用于时钟442的“/clk/cpu”。然而，如所属领域的一般技术人员所认识到，含有字母数字字符及/或符号的任何其它组合的其它类型的资源名称恰当地在本发明的范围内。

接下来，在框1110中，框架管理器440可接收与创建的节点601的一或多个资源相关联的一或多个驱动函数的数据。驱动函数通常包括待由特定节点601的一或多个资源完成的动作。举例来说，在图7A到7B中，节点602的资源/core/cpu的驱动函数可请求总线带宽的量及其所需要的CPU时钟频率，以便提供已被请求的请求的处理量。这些请求将通过节点642及节点622中的资源的客户端来进行。节点642中的/clk/cpu的驱动函数通常将负责实际上根据其从节点602的/core/cpu资源接收的请求来设定物理时钟频率。

在框1115中，框架管理器440可接收节点属性数据。节点属性数据通常包括定义例如安全性(节点可经由用户空间应用程序存取)、远程能力(节点可从系统中的其它处理器存取)及可存取性(资源可支持多个并发客户端)等节点策略的数据。框架管理器440还可定义允许资源越权默认框架行为(例如，请求评估或日志记录策略)的属性。

随后，在框1120中，框架管理器440可接收创建的特定节点601的定制用户数据。用户数据可包括空“星号”域，如所属领域的一般技术人员关于“C”编程语言所理解。对于所属领域的一般技术人员来说，用户数据也被称作“相信我”域。示范性定制用户数据可包含，但不限于，例如频率表、寄存器映射等表。框1120中所接收的用户数据不由系统500A参考，但允许在不由框架管理器440辨识或完全支持定制的情况下定制资源。此用户数据结构为意欲扩展以供特定或具体用途的在“C”编程语言中的基本类。

所属领域的一般技术人员认识到用于扩展特定类的具体用途的其它种类的数据结构在本发明的范围内。举例来说，在“C++”(C加加)编程语言中，等效结构可包括关键字“公用”，其将变为节点601内的资源的扩展机制。

接下来，在框1125中，框架管理器440可接收依赖性阵列数据。依赖性阵列数据可包括创建的节点601所依赖的一或多个资源601的独特及具体名称。举例来说，如果创建图6的第一节点602，那么在此框1125中，依赖性阵列数据可包括第二节点622的三个资源的资源名称及第一节点602所依赖的第三节点642的单个资源名称。

随后，在框1130中，框架管理器440可接收资源阵列数据。资源阵列数据可包括用于创建的当前节点的参数，例如与图7B到7C的第一节点602有关的参数(如果创建了此第一节点602的话)。资源阵列数据可包括以下数据中的一或多者：其它资源的名称；单位；最大值；资源属性；外挂数据；及类似于框1120的定制用户数据的任何定制资源数据。外挂数据通常识别从软件库检索的功能，且通常列出可由创建的特定节点或多个节点支持的客户端类型。外挂数据还允许定制客户端创建及毁灭。在框1130之后，过程返回到图7的框1010。

在图9中，属性数据框1115、定制用户数据框1120及依赖性阵列数据框1125已用虚线来说明，以指示这些特定步骤为可选的且对于任何给定节点601来说并非需要的。同时，独特名称框1105、驱动函数框1110及资源阵列数据框1130已用实线来说明，以指示例程1005的这些步骤对于创建节点601来说通常是重要的。

图10为说明用于创建PCD100的软件架构中的节点的图7的子方法或例程1025的流程图。例程框1205为用于根据一个示范性实施例实例化或创建节点601的子方法或例程1025中的第一例程。在例程框1205中，在此步骤中创建与经实例化的节点601相关联的一或多个客户端648。下文将结合图11更详细描述关于例程框1205的其它细节。

在框1210中，框架管理器可创建或实例化对应于框705的节点结构数据的一或多个资源。接下来，在框1215中，框架管理器440可激活在例程框1005的例程框1110中接收的驱动函数。根据一个示范性方面，可使用例程框1005的资源阵列数据框1130中接收的最大值来激活驱动函数。根据另一优选示范性方面，可用与节点结构数据一起从例程1005传递的可选初始值来激活每一驱动函数。如果不提供初始数据，那么驱动函数初始化为0，最小值。通常还以已知驱动函数被初始化的方式来激活驱动函数。这使得资源能够执行初始化所特有的任何操作，但不需要在正常或例程操作期间执行。过程接着返回到图7的步骤1030。

图11为说明用于创建或实例化PCD100的软件架构中的客户端648的图10的子方法或例程1205的流程图。框1305为例程框1205的第一步骤，其中创建了一或多个资源601的客户端648。在框1205中，框架管理器440接收经指派给创建的客户端648的名称。类似于资源名称，客户端648的名称可包括任何类型的字母数字及/或符号。

接下来，在框1310中，如果存在用于创建的此客户端648的任何特定定制，那么定制用户数据可由框架管理器440接收。框1310已用虚线来说明以指示步骤为可选的。框1310的定制用户数据类似于上文结合节点601的资源的创建论述的定制用户数据。

在框1315中，框架管理器440接收经指派给创建的特定客户端的客户端类型分类。关于此写入的客户端类型分类可包括四个类型中的一者：(a)需要、(b)脉冲、(c)向量及(d)等时。客户端类型分类列表可取决于由系统101管理的资源及取决于依赖于节点601的资源的应用程序而扩展。

所需要的分类通常对应于从需要的客户端648传递到特定资源601的标量值的处理。举例来说，需要的请求可包括特定数目的每秒百万指令(MIPs)。同时，脉冲类别通常对应于请求的处理以在某一时间段内完成某一活动而无开始时间或停止时间的任何标记。

等时类别通常对应于通常重新出现且具有良好定义的开始时间及良好定义的结束时间的动作的请求。向量类别通常对应于通常为需要为串联或并联的多个动作的部分的数据阵列。

随后，在框1320中，框架管理器440接收指示是否将可获得648表示为同步或非同步的数据。同步客户端648为通常需要框架管理器440锁定节点601的资源直到资源601从同步客户端648传回数据及资源601已完成请求的任务的指示为止的客户端。

另一方面，非同步客户端648可由一或多个线程并行地处理，所述线程由框架管理器440存取。框架440可创建到线程的回调，且可在已由相应线程执行回调时传回值。所属领域的一般技术人员认识到，在执行同步客户端648的任务时，非同步客户端648并不像同步客户端648一样将资源锁上。

在框1320之后，在决策框1325中，框架管理器440确定由客户端645识别的资源是否可用。如果决策框1325的询问是否定的，那么跟着“否”分支到框1330，其中将空值或消息传回到用户，其指示在此时无法创建客户端648。

如果决策框1325的询问是肯定的，那么跟着“是”分支到决策框1335，其中框架管理器440确定由客户端648识别的每一资源是否支持框1310中提供的客户端类型。如果决策框1335的询问是否定的，那么跟着“否”分支回到框1330，其中传回空值或消息，其指示在此时无法创建客户端648。

如果决策框1335的询问是肯定的，那么跟着“是”分支到框1340，其中框架管理器440在存储器中创建或实例化客户端648。接下来，在框1345中，如果在框1310中接收任何定制用户数据(例如，可选变元)，那么这些可选变元可与其相应资源一起映射到特定节点601。接下来，在框1350中，新创建的客户端645在闲置状态中或在请求状态上耦合到其对应一或多个资源，如上文所描述。过程接着返回到图10的框1210。

图12为说明用于创建对PCD100的软件架构中的资源601的客户端请求675的方法1400的流程图。通常在如上文结合图7到11所描述的客户端及节点创建(实例化)之后执行方法1400。

框1405为用于创建对资源601的客户端请求675的方法1400中的第一步骤。此方法1400将描述框架管理器440如何处理以下三个类型的客户端请求675：(a)需要、(b)脉冲及(c)向量。正如上文所提及的请求675的名称所建议，客户端请求675通常对应于上文创建及描述的客户端类型。

在框1405中，框架管理器440可接收与特定客户端请求675相关联的数据，所述客户端请求例如上文所提及的三者中的一者：(a)需要、(b)脉冲及(c)向量。与所需要的请求相关联的数据通常包括从需要的客户端648传递到特定资源601的标量值。举例来说，需要的请求可包括特定数目的每秒百万指令(MIPs)。脉冲请求包括在特定时间段内完成某一活动而无开始时间或停止时间的任何标记的请求。用于向量请求的数据通常包括需要串联或并联完成的多个动作的阵列。向量请求可包括任意长度的值。向量请求通常具有大小值及值的阵列。可扩展节点601的每一资源以具有指针域以便支持向量请求。在“C”编程语言中，指针域由联集函数支持，如所属领域的一般技术人员所理解。

接下来，在框1410中，框架管理器440经由上文结合图11所描述的方法所创建的客户端648发出请求。随后，在框1415中，如果请求为需要的类型或向量类型，那么框架管理器440双缓冲穿过客户端的请求数据。如果请求为脉冲类型，那么框架管理器440跳过框1415。

对于需要的请求，在框1415中，在存储器中维持来自先前请求的值，以使得框架管理器440可确定在请求的值的当前集合中的先前请求的值之间是否存在任何差异。对于向量请求，先前请求通常不维持于存储器中，但节点601的资源可在特定实施方案需要时维持所述先前请求。因此，对于向量类型的请求，框1415是可选的。

在框1420中，框架管理器440计算请求的值的当前集合中的请求的值的先前集合之间的增量或差异。在决策框1425中，框架管理器确定请求的值的当前集合是否等同于请求的值的先前集合。换句话说，框架管理器440确定请求的值的当前集合与请求的值的先前集合之间是否存在差异。如果请求的值的当前集合与先前集合之间不存在差异，那么跟着“是”分支(其跳过框1430到框1470)到框1475，其中过程结束。

如果决策框1425的询问是否定的，意谓相对于先前请求的值的集合，请求的值的集合是不同的，那么跟着“否”分支到决策框1430。

在决策框1430中，框架管理器440确定当前请求是否为非同步请求。如果决策框1430的询问是否定的，那么跟着“否”分支到框1440，其中对应于客户端请求675的资源601由框架管理器440锁定。如果决策框1430的询问是肯定的，意谓当前请求为非同步请求类型，那么跟着“是”分支到框1435，其中如果多核心系统(类似图1的系统)当前由框架管理器440管理，那么请求可被推入到另一线程上，且可由另一核心执行。框1435已用虚线来说明以指示如果PCD100为单核心中央处理系统，那么此步骤可为可选的。

随后，在框1440中，对应于请求675的资源601由框架管理器440锁定。接下来，在框1445中，资源601执行更新功能，其通常对应于图9的框1130中所接收的资源阵列数据的外挂数据。更新功能通常包括根据新客户端请求负责新资源状态的功能。更新功能将其先前状态与客户端请求中的请求状态相比较。如果请求状态大于先前状态，那么更新功能将执行客户端请求。然而，如果请求状态等于或小于资源正操作处于的当前状态，那么将不执行客户端请求以便增加效率，因为旧状态实现了或满足了请求状态。更新功能从客户端进行新的请求，且将其与所有其它作用中请求聚合以确定资源的新状态。

作为实例，多个客户端可正请求总线时钟频率。总线时钟的更新功能通常将最大地进行所有客户端请求，且使用其作为总线时钟的新的所要状态。其并不是所有资源将使用相同更新功能的状况，但存在将由多个资源使用的一些更新功能。一些常见更新功能为进行最大的客户端请求，进行最小的客户端请求及合计客户端请求。或者如果其资源需要以某一独特方式聚合请求，那么资源可定义其自身的定制更新功能。

接下来，在框1450中，框架管理器440将数据传递到对应于客户端648的资源，以使得资源可执行节点601的资源所特有的驱动函数。驱动函数应用如由更新功能计算的资源状态。这可需要更新硬件设定，将请求发出到依赖性资源，呼叫旧式功能或上文的某一组合。

在先前实例中，更新功能计算请求的总线时钟频率。驱动函数可接收所述请求的频率且其可更新时钟频率控制HW以在所述频率处运行。应注意驱动函数有时并不可以满足更新功能所计算的精确请求状态。在此状况下，驱动函数可选择最佳地满足请求的频率。举例来说，总线时钟HW可仅能够在128MHz及160MHz处运行，但请求状态可为150MHz。在此状况下，驱动函数应在160MHz(其超过请求状态)处运行。

接下来，在框1455中，框架440从已在框1450中执行驱动函数的资源接收状态控制。随后，在框1460中，如果是针对资源来定义的，那么可触发事件690以使得将数据传递回到对应于事件690的客户端648。可在另一线程中处理事件。这可最小化锁定资源所花费的时间量，且允许如图1中所说明的多核心系统中的并行操作。可定义对资源的一或多个事件690，定义的方式类似于可定义对资源的请求的方式，如此方法1400中所描述。换句话说，事件创建过程可很大程度上与客户端创建过程是并行的。不同于事件的一件事在于有可能定义仅在越过某些阈值时触发的事件。

仅基于阈值触发的事件的此定义允许通知何时超额订购资源(其具有比其所支持的用户多的并发用户)，其指示系统过载条件或当资源变低/停止使用(其可允许关闭其它事物)时恢复在超额订购系统时停用的功能性等。因为可对阈值进行事件注册，所以其可减少系统需要对事件通知进行的工作量，以仅在存在真的必要的事件时才发生。也有可能在每一状态改变时注册事件。

接下来，在可选框1465中，如果经处理的请求为向量请求，那么通常执行此可选框1465。可选框1465通常包括检查或确定以评估向量指针是否仍定位于用户传递到向量中的相同数据上。如果此可选框1465的询问是肯定的，意谓指针仍指向由用户传递到向量中的相同数据，那么清除指针以使得不维持对旧数据的参考。当处理向量请求时，与脉冲请求及需要的请求相比较，通常执行此可选框1465以考虑到上文所描述的双缓冲框1415。

随后，在框1470中，框架440解锁被请求资源以使得其它客户端请求648可由特定节点601的当前但现释放的被请求资源来处理。过程接着返回到第一框1405以用于接收下一个客户端请求。

上文所描述的方法及数据结构基本上与其适用于单处理器PCD100一样适用于多处理器PCD100。然而，远程框架300(图3)可提供可增强多处理器实施例中的操作的额外特征。举例来说，远程框架300可有利地呈现对应用程序员或类似人员透明的处理器间通信的细节。因此，例如应用程序可定义对目标资源发出请求而不需要在客户端定义中包含控制所述资源的处理器域的任何识别。而是，远程框架300确保请求将到达目标资源而不管哪一处理器控制客户端及哪一处理器控制目标资源。另外，远程框架300管理处理器间通信以使得例如应用程序不需要包含与处理器之间的通信路径(例如，总线)的协议或其它方面有关的任何指令。此外，因为不同处理器间通信路径可使用不同协议，所以远程框架300允许资源定义指定协议以及资源的其它方面。下文关于图13到23描述与分布式资源管理有关的这些及其它特征。

图13说明由第一处理器(未图示)控制的第一资源1302充当对应于由第二处理器(未图示)控制的第二资源1304的分布式或远程资源的实例或情况。术语“分布式资源”或“远程资源”在本发明中用以指一个处理器上的对应于另一处理器上的“本地”资源的资源。第二资源1304在此实例中充当第二处理器的本地资源。分布式资源用作存取对应本地资源的工具。在此实例中，术语“资源”可与术语“节点”互换地使用，因为应理解资源可包含于节点中。

折线1301说明由第一处理器控制的资源(在线1301左边)与由第二处理器控制的资源(在线1301右边)之间的分界。第一资源1302为由第一处理器控制的两个或两个以上资源中的一者。一个此资源可为第一资源1302所依赖的协议资源1306。同样，第二资源1304为由第二处理器控制的两个或两个以上资源中的一者。在一些实施例中，仅分布式资源而非本地资源依赖于协议资源。因此，在所述实施例中，仅第一(分布式)资源1302依赖于协议资源1306。然而，在其它实施例中，任何资源可依赖于协议资源。因此，在替代实施例中，第二资源1304还可依赖于协议资源(未图示)。第一及第二资源1302及1306还可以如上文一般关于资源或节点所描述的相同方式依赖于额外资源，但所述额外资源出于清楚起见在图13中并未展示。应注意，由第一处理器控制的资源由第一资源图(即，有向非循环图)定义，且由第二处理器控制的资源由第二此类资源图(其并不与第一资源图共享任何资源)定义。

第一及第二资源1302及1304在其相应处理器的控制之下能够经由通信路径1303传达信息。通信路径1303表示第一及第二处理器之间的物理媒体与用以经由所述媒体通信的传送协议的一或多个层的组合。因此，第一资源1302与第二资源1304之间的任何通信必须遵照协议。协议资源1306及1308定义协议或可指向库中的协议定义(未图示)。远程框架300及(主)框架440彼此相结合地操作以管理资源及其间的通信。如下文所描述，客户端1312在第一处理器的控制之下可对第一资源1302发出一或多个资源请求。第一资源1302使用对应第二资源1304的功能性来服务资源请求。

图14为说明用于创建或实例化分布式资源(例如，图13的第一资源1302)的方法1400的流程图。图14的流程图意欲说明除了上文关于用于实例化资源的方法(例如，图7到10所说明的方法)所描述的特征之外或扩增所述特征的特征。因此，除了可以其它方式指示的情况之外，可包含图7到10中的框中的任一者或全部，但其出于清楚起见而在图14中未被展示。

如由框1402所指示，框架管理器300及440接收定义节点(例如，含有第一资源1302的节点)的节点结构数据。在示范性实施例中，以基本上与上文关于图7到10所描述的方式相同的方式来处理依赖性，除了可在任何时间实例化协议资源之外，如由框1406所指示。依赖于协议资源的资源不需要等待直到其协议资源经实例化为止。以上文关于图7到10所描述的方式的依赖性的实例化通常由框1408说明。

尽管实例化通常遵循上文关于图7到10所描述的方法，但应注意到，无法实例化分布式资源直到已实例化其所对应的本地资源为止。因此，本地资源的实例化可以与依赖资源的实例化可延迟依赖于其的资源的实例化相同的方式延迟分布式资源的实例化。还应注意，经由通信路径1303及框架管理器300及440在第一及第二处理器之间传达的与本地资源的实例化的状态有关的消息通常遵照指定协议。举例来说，在实例化第一处理器上的协议资源1306之后，根据远程框架管理器300操作的第一过程可将经编码或以其它方式遵照协议的用于通知的请求发送到第二处理器。当已实例化第二资源1304时，根据远程框架管理器300操作的第二处理器可通过将指示已实例化第二资源1304的响应发送到第一处理器来对用于通知的请求作出响应。远程框架管理器300可管理所述通信及其它通信，作为实例化软件架构的过程的部分。

第一处理器上的协议资源1306除了其它功能之外还可包含创建客户端(例如，图13中所示的客户端1312)及将可由执行线程使用的处理传回到客户端的功能。执行线程(例如，应用程序或其它软件元件的执行的部分)可调用功能来创建所述客户端1312。线程可使用客户端1312以如上文一般关于客户端所描述的方式来发出资源请求及以其它方式使用客户端1312。资源请求是协议特定的，且允许线程存取第二资源1304而不需要线程提供与协议有关的任何信息。从线程及其客户端的角度来看，协议可为不相关的或透明的。

如由框1410所指示，框架300及440确定在接收的节点结构数据中是否指定聚合方法。如果确定指定聚合方法，那么在分布式及本地资源(节点)中设定聚合方法，如由框1412所指示。存在两种聚合类型：局部及代理。在定义资源时，可选择两个聚合类型中的一者。因此，在实例化资源(节点)时，设定资源以执行局部聚合或远程聚合。

资源通过将算法应用于其可“并发”接收的多个资源请求来执行局部聚合。在此上下文中，两个(或两个以上)请求在其皆保持在作用中时是“并发的”。举例来说，第一处理器可发出资源请求以将其速度设定为50MIPS，且在已完成或以其它方式终止第一处理器的请求之前，第二处理器可发出资源请求以将其速度设定为100MIPS。聚合可根据例如添加多个并发资源请求中的每一者的变元(通过从所有多个资源请求中的所述变元当中确定最大变元，通过从所有多个资源请求中的所述变元当中确定最小变元，或通过任何其它方法)等方法来执行。聚合方法可与定义资源(节点)的节点结构数据中的聚合类型一起指定或定义。

节点结构数据可指示节点将实例化为代理节点或非代理节点。下文关于图16到17描述可使用此特征的方式。如由框1414所指示，节点类型设定为所指示的类型。在非代理节点的状况下，以由节点结构确定的方式局部地聚合客户端请求，且使用将局部聚合请求发送到本地资源的驱动函数。由分布式资源处理查询及事件。在代理节点的状况下，客户端请求未被聚合而是替代地个别地发送到本地资源。另外，将所有查询及事件转发到本地资源。

如由框1416所指示，发生实例化过程中的任何剩余步骤。实例化分布式节点的所述方面可基本上与上文关于图7到10所描述的方面相同。如由框1418所指示，如果定义额外节点，那么对于所述节点重复或继续所述方法。

图15为说明用于服务客户端请求的方法1500的流程图。图15的流程图意欲说明除了上文关于用于服务客户端请求的方法(例如，图12中所说明的方法)所描述的特征之外或扩增所述特征的特征。因此，除了可以其它方式指示的情况之外，可包含图12中的框中的任一者或全部，但其出于清楚起见而在图15中未被展示。

如由框1502所指示，例如图13中的第一节点1302的所述资源等分布式资源接收客户端请求。如由框1504所指示，确定与被请求资源相关联的聚合类型为局部的还是远程的。如果聚合类型是局部的，那么被请求资源将请求变元与相同窗内发生的其它变元聚合，如由框1506所指示。如上文所描述，聚合与处理并发资源请求有关。如果与被请求资源相关联的聚合类型为远程，那么其将被留给对应本地资源(例如，图13中的第二资源1304)以将所述请求与其它请求聚合。

不管是局部的还是远程的，聚合涉及客户端请求的三个连续状态：(1)发出请求、(2)进展中请求及(3)应用请求。在并发地发出客户端请求的情况下(即，两个客户端请求各自在实际上彼此同时或在上文所参考的窗内开始发出请求状态)，首先出现的客户端请求使得锁定被请求资源，且在首先出现的客户端请求之后处理第二次出现的客户端请求。在进展中请求状态期间处理或服务客户端请求。在已完成客户端请求之后，客户端请求经指派应用请求状态。聚合在多个并发客户端请求已到达应用请求状态的情况下开始活动。举例来说，如果资源已被定义为使用上文所参考的最大聚合方法，且客户端“A”请求50MIPS同时(可能是几微秒之后)，客户端“B”请求100MIPS，那么将串行化这些初始请求。因此，当处理第一客户端请求时，资源将被设定为第一客户端请求的变元或50MIPS。接着，当处理第二客户端请求时，根据最大聚合方法，资源将被设定为100，因为100为50及100间的最大值。其后，当这些初始客户端请求中的两者处于应用请求状态下时，客户端“B”可发出另一客户端请求达25MIPS。根据最大聚合方法，被请求资源将被设定为50，因为50为50及25间的最大值。

如由框1508所指示，确定被请求资源依赖于协议资源，例如图13中的协议资源1306。如果被请求资源依赖于协议资源，那么协议资源经调用且用以使资源请求遵照协议资源所定义的协议，如由框1510及1512所分别指示。如由框1514所指示，遵照协议，发送反映聚合结果(框1506的结果)的资源请求，或如果远程资源将执行聚合，那么将资源请求转发到本地资源，例如图13中的第二资源1304。分布式资源的驱动函数(未图示)调用协议。

尽管图15中未图示，但可以基本上与上文关于图12所描述的方式相同的方式来处理涉及分布式资源的事件。监视横跨阈值的值的类型的事件可在与代理资源组合时尤其有用，如下文所描述。

图16为说明用于服务对非代理类型的分布式资源的状态查询的方法1600的流程图。由如上文关于图5到6所描述的框架440管理状态查询。图16到17的流程图意欲说明除了上文关于图5到6所描述的特征或扩增所述特征的特征。因此，除了可以其它方式指示的情况之外，可包含上文关于图5到6所描述的特征中的任一者或全部，但其出于清楚起见而在图16到17中未被展示。

如由框1602所指示，例如图13中的第一节点1302的所述资源等分布式资源接收状态查询。在此实例中，第一节点1302表示非代理节点或资源。如由框1604所指示，将状态查询转发到对应本地资源，例如图13中的第二资源1304。如由框1606所指示，响应于状态查询将本地资源的状态发送回到分布式资源。如由框1608所指示，分布式资源接着可提供表示本地资源的状态的状态指示到查询请求者(客户端)。

图17A为说明用于服务对代理类型的分布式资源的状态查询的方法1700的第一部分的流程图。如由框1702所指示，例如图13中的第一节点1302的所述资源等分布式资源接收状态查询。在此实例中，第一节点1302表示代理节点或资源。如由框1704及1706分别指示，每次分布式资源接收到本地资源的状态的指示，分布式资源更新其状态以反映本地资源的状态。如由框1608所指示，分布式资源将其自身状态的指示提供到查询请求者(客户端)。因此，在代理分布式资源的状况下，其状态仅在其从对应本地资源接收到状态改变的通知时改变。

如由框所指示，将状态查询转发到对应本地资源，例如图13中的第二资源1304。如由框1606所指示，响应于状态查询将本地资源的状态发送回到分布式资源。

图17B为说明用于服务对代理类型的分布式资源的状态查询的方法1700的第二部分的流程图。此第二部分反映了本地资源的角度，且非同步及与图17A中所说明的第一部分并行地操作。如由框1710所指示，监视本地资源(例如，图13的第二节点1304)的状态。如由框1712及1714分别指示，如果检测到本地资源的状态的改变，那么将本地资源的状态的指示发送到对应分布式资源。

在适当情况下的代理分布式资源的使用可促进最小化处理器间流通量的所要目标，因为状态信息仅在本地资源的状态改变时从本地资源的处理器发送到分布式资源的处理器。相对比地，在非代理资源的状况下，发送状态查询，且每次分布式资源接收状态查询时传回状态信息。在例如分布式资源而非对应本地资源的状态与待在第一处理器的控制之下执行的任务最相关的情况下，可使用代理资源。

如上文关于图5到6所注明，事件及查询是软件架构的相关方面。监视超越阈值的值的类型的事件可在与代理资源组合时尤其有用，因为仅在本地资源的状态超越阈值时而非每当本地资源的状态改变时发送处理器间消息。

在一些情况下，可需要在单个“资源请求事务”中一起分组或“分批”数个单独资源请求。在其中多个资源请求针对由彼此相同的处理器控制的远程或封闭式资源的情况下，事务处理资源请求可帮助最小化经由通信路径1303(图13)在第一及第二处理器之间发射的消息的数目。如所属领域的一般技术人员充分理解，“事务”是根据通常由首字母缩略词ACID所指的性质(原子性、一致性、隔离及耐久性)而发生的动作。原子性意谓执行或皆不执行事务的构成步骤中的全部，以便避免与部分执行的事务相关联的问题。一致性意谓事务将使系统从一个连续/连贯状态到另一状态。隔离意谓其它操作无法存取在尚未完成的事务期间修改的数据。锁定对数据的存取通常用以确保事务的隔离性质。如上文所描述，资源在响应于资源请求而存取所述资源时被锁定，且在资源请求完成时解锁。耐久性与从系统故障恢复有关。术语“事务”在本说明书中用以指至少根据原子性及隔离的性质而一起执行的资源请求的群组。用于资源请求事务的框架或编程接口在其设计中支持一致性，但系统在事务之后是否到达连续状态取决于个别事务处理的资源请求的动作，且因此不一定是框架或编程接口的性质。

提供资源请求事务可涉及两个方面。在一个方面中，可定义资源请求事务。在定义资源请求事务时，资源请求事务被指派独特名称或识别符，指定锁定类型，且列出了在资源请求事务中可涉及的资源。定义资源请求事务的结果可为可由实体参考以便发出资源请求事务(或创建其实例)的句柄。

提供资源请求事务的第二方面涉及发出或创建经定义资源请求事务的实例。资源请求事务可由资源发出(例如，作为到其所依赖的其它资源的一批资源请求)，或由除了资源之外的实体(例如由执行线程或由由PCD100的上文所描述的资源图所定义的资源中的一者中所不包括的装置驱动程序)发出。与其它资源请求一样，资源请求事务是一种类型的客户端请求。能够以上文所描述的方式发出客户端请求(或在“拥有”客户端的常见计算机科学用于中)的任何实体可发出资源请求事务。

为了发出资源请求事务，资源、线程或其它此类实体执行“开始”或设定先前定义的资源请求事务的软件代码，将资源请求发出到经定义为资源请求事务的部分的各种资源，及接着结束资源请求事务，初始化分批请求的处理及结束资源请求事务。结束资源请求事务的过程可涉及将这一批请求从第一处理实体发射到第二处理实体，在第二处理实体处处理分批请求，在第一处理实体处等待处理完成的通知，及接着在接收到通知时在第一处理实体处执行对局部资源代理或注册的回调的任何更新。

图18为说明用于发出资源请求事务的方法1800的流程图。下文参考示范性伪代码来描述方法1800。下文为通常表示由发出资源请求事务的实体执行的代码的伪代码的实例：

如图18中的框1802所指示，提供事件序列的指示。举例来说，可通过执行由上文伪代码表示的代码来提供事件序列。所指示的事件序列包含资源请求事务的开始的指示(由“BEGIN_TRANSACTION(HANDLE)”在示范性伪代码中表示)；资源请求事务的结束的指示(由“END_TRANSACTION”在示范性伪代码中表示)；及将作为事务的部分(即在事务的开始与事务的结束之间)出现的两个或两个以上资源请求的指示。伪代码“BEGIN_TRANSACTION(HANDLE)”表示以上文所描述的方式定义的处理上的资源请求事务的设定。因为发出资源请求事务的过程横跨这些许多步骤，所以处理上的任何资源请求事务将根据与所述处理相关联的锁定类型及与定义资源请求事务之时与所述处理相关联的资源来执行。

尽管出于清楚起见未在上文的伪代码中反映，但注意到资源请求事务可包含条件逻辑是有用的。举例来说，表示资源请求事务的代码可包含具有形式“IF(condition)THEN(issue resource request)”的逻辑或在响应于输入条件而评估时导致将在资源请求事务的定义中所定义的请求提供到资源的子集的类似逻辑。换句话说，可定义资源请求事务，其仅在指定条件在发出资源请求事务时(即，在执行表示资源请求事务的代码时)得到满足的情况下包含某一资源请求。举例来说，资源请求事务可定义为涉及资源A、B、C及D，但给定情况中的条件逻辑的评估可仅提供对资源A、B及C的资源请求的指示。即，作为在资源请求事务的此示范性情况中的条件逻辑的评估的结果，针对资源D的资源请求可不包含于实际资源请求事务中。在所有情况下可需要并非定义为资源请求事务中潜在地涉及的所有资源。出于清楚的目的，上文示范性伪代码仅展示在给定情况下指示的资源请求且不展示任何条件逻辑。然而，应理解资源请求事务可包含任何数目个资源请求及可确定哪些资源请求包含于给定情况中的任何合适的条件逻辑。

如框1803所指示，设定资源请求事务中所涉及的对资源请求的查询。如由框1804所指示，资源请求事务中所涉及的每一资源锁定达资源请求事务的持续时间。如下文所描述，可根据不同锁定类型(例如，下文被称作“保守式锁定”的第一锁定类型或下文被称作“懒惰锁定”的第二锁定类型)来锁定资源。如上文所描述，当定义资源请求事务时定义锁定类型。因此，当发出资源请求事务时，资源请求事务将根据保守式锁定方法还是根据懒惰锁定方法执行将在发出之时预定。取决于锁定方法，资源请求事务中涉及的资源可在不同时间锁定，如下文更详细所描述。而且，取决于锁定类型，锁定经定义为资源请求事务的部分的全部资源，或者仅锁定作为事务的部分而发出请求的这些资源的子集(懒惰锁定)。

在另一实施例中，当与资源请求事务相关联的锁定类型为“懒惰”(如下文进一步描述)时，在资源请求事务的定义方面期间，定义及发出资源请求事务的实体不需要约束为必须定义或列出可为事务的部分的所有资源。通过在事务的上下文中发出到这些资源的一或多个请求，为(或在一些状况下，变为)事务的部分的资源完全有可能动态地包含于事务中。作为实例，在上文的伪代码中，如果其与事务相关联的锁定类型为“懒惰”，那么发出事务的实体不需要在定义方面期间定义A、B及C为事务的部分。其可开始事务且接着将请求发出到A、B及C中的两者或两者以上。这些资源接着隐式地变为资源请求事务的部分，且到其的请求仅进行分批且不会立即进行处理。因此，在此实施例中，在开始事务之后，在可将任何数目个资源添加到事务的意义上，有可能构造“动态”或“运行时间定义”事务，而不需要全部在前面定义所述事务。如从下文对锁定类型的进一步描述将显而易见，此“动态”或“运行时间定义”资源请求事务无法为“保守式”锁定类型。

如由框1806所指示，将与资源请求事务中所包含的资源请求中的每一者相关联的信息添加到队列。参考上文的伪代码，在“REQUEST(A)”表示针对资源A的请求(达例如50MIPS的处理吞吐量)的情况下，资源A(或在资源A由除了发出资源请求事务的处理器之外的处理器控制的情况下其分布式对应物)可将值50添加到队列。同样，在执行对应代码(例如，由伪代码“REQUEST(B)”表示的代码)时将与其它资源请求(其为资源请求事务的部分)相关联的任何合适的参数添加到队列。出于清楚的目的，上文的伪代码并不反映可包含于资源请求中的所有参数，例如在此实例中表示“50”的参数。

应注意，分别由框1804及1806指示的锁定及添加到队列步骤可按任何次序执行且涉及一或多个子步骤。举例来说，如下文所描述，在已定义为保守式锁定类型的资源请求事务中，在将与资源请求相关联的任何信息添加到队列之前锁定资源请求事务的定义中所指示的所有资源。然而，在已定义为懒惰锁定类型的资源请求事务中，每一资源请求又导致锁定被请求资源，且将仅与所述资源请求相关联的信息添加到队列。换句话说，在资源请求事务中，锁定及添加到队列步骤可按彼此交替的方式来执行。下文更详细描述了保守式及懒惰锁定。

如由框1808所指示，响应于事务结束的指示而将队列发射到接收者。接收者可为例如另一处理器。接收者可为例如另一处理器，即除了发出资源请求事务的处理器之外的处理器。在所述情况下，队列代替与多个资源请求相关联的多个消息，所述资源请求将在资源请求尚未按上文所描述的方式来事务处理的情况下发出。在发出实体时，阻塞执行线程，直到存在来自接收者的已处理请求队列的通知为止。接着，完成在发出实体处的任何残余处理(此可涉及对局部资源代理的任何更新或执行任何注册的回调)，且事务被视为完成。所有此情形由上文的伪代码中的“END_TRANSACTION(HANDLE)”表示。

如由框1810所指示，在事务结束(如由上文的伪代码中的“END_TRANSACTION”所表示)之后解锁资源请求事务中所指示的所有资源。因此，在发射队列及处理分批请求之后解锁资源。

应注意，虽然此文字将在资源请求事务内发出的资源请求称作添加到队列，但“队列”不需要拥有标准队列的性质中的任一者，例如按先进先出方式排序元素。这并不是说在特定实施方案中标准队列无法用以分批请求。虽然可很好地使用此队列，但在其它实施方案中，可将请求添加到可不时地接收一或多个元素且存储其直到最终发射或处理为止的任何种类的容器或缓冲器。在所述状况下，“队列”可被视为一袋或一桶资源请求。

图19说明包含对资源A、B及C的资源请求的示范性资源请求事务的示范性资源图1900。举例来说，图19中的资源A、B及C可为对应于上文的示范性伪代码中的“REQUEST(A)”、“REQUEST(B)”及“REQUEST(C)”的资源。

在已将资源请求事务定义为懒惰锁定类型的情况下，响应于对资源A的第一资源请求1902，资源A变为锁定，且将与第一资源请求1902相关联的信息添加到上文所参考的队列。资源A接着发出对资源B的第二资源请求1904，因为资源A依赖于资源B。响应于第二资源请求1904，资源B变为锁定的，且将与第二资源请求1904相关联的信息添加到队列。资源A接着发出对资源C的第三资源请求1906，因为资源C依赖于资源B。响应于第三资源请求1906，资源C变为锁定的，且将与第三资源请求1906相关联的信息添加到队列。参考上文的伪代码：在执行由伪代码“REQUEST(A)”表示的代码时锁定资源A；在执行由伪代码“REQUEST(B)”表示的代码时锁定资源B；及在执行由伪代码“REQUEST(C)”表示的代码时锁定资源C。

如果定义资源请求事务中所涉及的资源的集合的资源图的性质排除死锁条件的可能性，那么懒惰锁定方法可令人满意。图20说明类似于资源图1900的示范性资源图2000，但其并未排除死锁条件的可能性。进一步参考图21的事件时间线2100，在示范性情况下，第一线程及第二线程各自请求由资源图2000(图20)所指示的资源。第一线程发出对资源A的第一(事务处理)资源请求2002(图20)，所述第一资源请求锁定资源A。因为资源A依赖于资源B，所以资源A接着发出对资源B的第二资源请求2004，借此锁定资源B。因为资源B依赖于资源D，所以资源B接着发出对资源D的第三资源请求2006，借此锁定资源D。接着，第二线程发出对资源C的第四资源请求2008，借此锁定资源C。因为资源C依赖于资源D，所以资源C接着发出对资源D的第五资源请求2010。然而，因为资源D已经由于资源请求2006而锁定，所以资源请求2010被“阻塞”，且因此无法完成直到资源D被解锁为止。但由于资源A对资源C的依赖性在第一线程的上下文中发出的对资源C第六资源请求2012还将被阻塞，因为资源C由于资源请求2008而被第二线程锁定。在此情况下，存在死锁条件，因为第一线程无法完成其资源请求2002直到资源A所依赖的资源被解锁，而第二线程无法完成其资源请求2008直到资源C所依赖的资源被解锁。

为了避免在此情况下的死锁条件的可能性，资源请求事务可定义为保守式锁定类型而非懒惰锁定类型。在保守式锁定类型的资源请求事务中，在个别资源请求的任何指示之前(或在发出任何个别资源请求之前)，响应于事务开始的指示而锁定资源请求事务中所指示的所有资源。因此，参考上文的伪代码及图20及22，响应于由“BEGIN_TRANSACTION”表示的代码的执行而全部锁定资源A、B及C。可按由资源图的拓扑排序所指示的次序锁定资源。因为拓扑排序有向非循环图的方法由所属领域的一般技术人员充分理解，所以其在本说明书中并未更详细描述。可使用任何合适的拓扑排序方法。在由图22的事件时间线2200表示的示范性情况下，资源图2000(图20)的拓扑排序的结果可为例如：A、B、C、D。因此，响应于对资源A的资源请求事务开始的指示：在锁定资源A之后锁定资源B；接着在锁定资源B之后锁定资源C；及最后在锁定资源C之后锁定资源D。在锁定全部资源A、B、C及D之后，指定的资源请求可继续针对资源B、C及D。在另一实施例(或实施方案)中，可按由拓扑排序所指示的次序来锁定资源，作为伪代码中由“BEGIN_TRANSACTION”表示的资源请求事务的设定的部分。

图23为说明用于资源对资源请求作出响应的方法2300的流程图。关于方法2300所涉及的资源可为例如上文的伪代码中所参考的资源A、B及C中的任一者。如由框2302所指示，资源接收资源请求。举例来说，资源A可响应于上文的伪代码中由“REQUEST(A)”所表示的代码的执行而接收请求。如果懒惰锁定类型的资源请求事务中涉及资源，那么在此时锁定资源。然而，图23中并未展示锁定，因为方法2300表示发出资源请求的资源的角度，且资源可由不为资源的部分的控制实体来锁定及解锁。举例来说，包含于框架管理器440中的实体可控制锁定及解锁资源，及可作为到及来自资源的路由消息中所涉及的控制功能的部分而出现的任何死锁的处理。

如由框2304所指示，资源确定资源请求事务中是否涉及所述资源。状态指示器可包含于每一资源中，所述资源可在资源请求事务开始处设定为指示资源包含于资源请求事务中。在另一实施例(或实施方案)中，状态指示器可在其执行由“BEGIN_TRANSACTION”表示的伪代码之后在线程中设定，指示当前线程已开始资源请求事务。如果资源确定在资源请求事务中不涉及所述资源，那么资源以由框2306所指示的正常方式执行资源请求。即，资源可以上文关于图12及15所描述的正常方式执行及完成资源请求。源装置，如上文关于图12所描述，在(未经事务处理)资源请求的执行开始处，锁定资源，且在资源请求的完成处，解锁资源。

如果资源确定资源请求事务中涉及所述资源，那么资源确定是否已创建上文所参考的队列(由例如另一资源或由“BEGIN_TRANSACTION”所表示的伪代码)，如由框2308所指示。如果资源确定不存在队列，那么资源创建队列，如由框2310所指示。如由框2312所指示，资源请求事务中所涉及的资源接着将与对其的请求相关联的信息添加到队列。应注意，在将信息添加到队列之前，由于懒惰锁定方法或者替代保守式锁定方法，资源处于锁定状态。在资源将信息添加到队列之后不移除锁定。而是，如上文所描述，仅在事务结束的指示及发射队列到另一处理器或其它接收者及随后在另一处理器或其它接收者处处理这一批请求之后移除锁定。

图24为展示用于管理便携式计算装置中的分批及分叉资源请求的方法及系统的实施例的操作的时间线图。如从上文所描述的图2到6所说明的系统的描述所理解，调制解调器202及资源电力管理器(“RPM”)204为图24中所说明的两个处理实体。如由所属领域的一般技术人员所理解，如图24中所说明的系统101的示范性实施例可利用除了调制解调器202及RPM204之外的其它处理实体。

图24中所说明的两个代理资源RES0 207A及RES1 207B的拥有者为也在图2中说明的资源电力管理器(“RPM”)204。作为两个代理资源RES0 207A及RES1 207B的拥有者，如图24中所说明的RPM204实现了在事务中发出到这些两个代理资源的请求中的任一者。

图24中所说明的RES0 207A及RES1 207B为代理。代理是实际资源的逻辑表示，如由所属领域的一般技术人员所理解。其为可由例如调制解调器202等逻辑处理实体经由RPM204存取的远程定位硬件或软件的存储器中的表示。RPM204控制实际资源，与调制解调器202相关地远程定位所述实际资源。

RES0 207A及RES1 207B的这些两个代理可为框架管理器440的部分。在一些实施例中，两个代理资源207A、207B可管理如下文所描述的分批请求的队列115(且其早先结合图18的框1803描述)。在存在框架管理器440的其它实施例中，框架管理器440可管理如下文所描述的队列115。

如上文所提及，由RPM204管理且位于更靠近RPM204处(且出于简洁起见并未说明)的实际资源含于或驻存在RPM204内。同时，这些代理207A、207B以软件管理且由调制解调器202存储于存储器中，如所属领域的一般技术人员所理解。代理可接收请求且接着将这些请求传递到位于RPM204邻近或RPM204内的实际资源。

例如第一客户端208等客户端应用程序是调制解调器202(其为此示范性实施例中的第一处理实体)的拥有者。客户端应用程序208通常将请求发出到由RPM204管理的两个代理资源RES0 207A及RES0 207B。

因为第一客户端208需要针对特定事务及出于最优化起见存取两个代理资源207A、207B，所以第一客户端208可决定将其到这些两个单独代理资源207A、207B的请求一起分批成在图24中所说明的时间线中的位置305处的事务。在图24的时间线位置305处，提醒两个代理资源207A、207B关于传入的分批请求。

上文结合图15到23论述可如何将请求一起分批成事务的其它细节。在位置307处，代理资源207A、207B已经由框架管理器440确认由第一客户端208制定的分批请求的起始。

在位置310处，第一客户端208将第一请求发出到第一代理资源RES0 207A。不由第一代理资源207A服务第一请求。替代地，第一代理资源207A从存取第一代理资源207A的其它客户端锁定。在位置311处，第一代理资源207A将接收的第一请求转发到队列115。

队列115可或可不具有关于其中含有的信息的任何特定排序。其可或可不具有管控其数据结构的任何标准队列要求。换句话说，队列115可包括任何类型的逻辑桶，如所属领域的一般技术人员所理解。在位置312处的第一代理资源207A将确认或回拨发出回到第一客户端208。

在位置315处，第一客户端208将第二请求发出到第二代理资源207B。类似于第一代理资源207A，第二代理资源207B从存取第二代理资源207B的其它客户端锁定。在位置316处，第二代理资源207B将接收的第一请求转发到批次队列115。且第二代理资源207B将确认或回拨发出回到位置317处的第一客户端208。

在位置252处，分叉事务呼叫已由第一客户端208初始化。位置252还标记时间的瞬间，其中规则批次事务呼叫将结束，如上文结合图15到23所描述。在两个状况下，此处分批请求将被发射到RPM204。

由第一代理资源207A及第二代理资源207B表示的实际资源(此图中并未说明)将在分批事务期间被锁定，且其将完成其在位置252处的分批事务的经指派请求。在完成分批事务之后，接着实际资源经由其代理207A、207B将接着将确认传回到第一客户端208。

第一及第二代理资源207A、207B接着将在图15到23中所说明的正常分批事务情形下解锁。替代初始化/开始位置252处的正常分批事务的执行，如图24中所说明的本发明系统101初始化位置252处的分叉事务。

在分叉事务中，分裂任务及/或操作以使得可并行地执行任务及/或操作。从经指派给虚线的时间线位置255，以非同步方式且在不等待来自RPM204的任何响应的情况下，由框架管理器440将分批事务发射到RPM204。

在就在含有来自位置255的分批请求的非同步呼叫之后的位置258处，框架管理器440解锁第一代理资源207A及第二代理资源207B。第一及第二代理资源207A、207B被解锁，且因此可接受但不处理任何后续请求，如由所属领域的一般技术人员所理解。

在位置257处，呼叫返回到第一客户端208且指示代理资源207A及207B解锁。第一及第二代理资源207A、207B在此阶段处于不连贯状态。这些两个代理资源207A、207B已接受请求，但请求尚未在此阶段被处理。

时间线位置260已特征化为潜在第一并行处理框。在位置260处，第一客户端208可继续发出其它请求及/或执行其它任务，同时不等待将请求发出到在RPM204的控制下完成的第一及第二代理资源207A、207B。在常规系统中，第一客户端208将在位置260处被阻塞。

对应于位置260的位置256可特征化为第二并行处理框。位置256处的此第二并行处理框与由第一及第二资源代理207A、207B(其由实际资源(未图示)执行且在RPM204的控制之下)中继的两个请求的处理有关。

虽然这些两个并行处理框256及260已说明为在单独处理器上发生，但有可能此并行处理可在多核心系统中的不同核心之间或在单核心系统中的两个不同处理线程当中的芯片上的相同系统内发生，如由所属领域的一般技术人员所理解。

接下来，在时间线位置262处，第一客户端208可将第三请求发出到第一代理资源207A。在位置262处，有可能另一客户端(未说明)可将此第三请求发出到第一代理资源207A。此第三请求为单个请求或另一事务的部分。

框架管理器440或代理资源207A将监视发出的此第三请求，因为框架管理器440或代理资源207A已接收到由第一客户端208发出的先前两个请求已从事务分叉(标记为分叉请求)以用于并行处理的通知。

框架管理器440或第一代理资源207A紧紧抓住第三请求且等待直到其从RPM204接收到位置269及270处的通知：第一请求及第二请求(构成批次请求)已完成且由第一代理资源207A服务。

位置269及270处的消息由从RPM204接收到完成通知的中断服务例程(“ISR”)299产生。ISR299为消息媒介物或消息媒体，其中RPM204可用信号通知由局部代理表示的发出实体，已服务及完成分叉分批请求。ISR299仅为可以此方式利用的方便常规机制。系统101不限于用于在RPM204与第一客户端208之间中继通信的ISR299，且可使用其它机制以用于发送消息以指示已完成分叉分批请求。

可使用除了ISR299之外的用于在两个处理实体之间中继消息的任何其它通信媒体，如由所属领域的一般技术人员所理解。用于中继通信的ISR299的一个优点在于可非同步地中继两个处理实体之间的通信，因为调制解调器202不需要寻找来自RPM204的分叉分批请求完成信号。

使用ISR299，RPM204可将分叉分批请求完成信号发送到调制解调器204。在另一例示性实施例中，替代使用ISR299，调制解调器202可经设计以轮询RPM204且搜索待由RPM204发出的分叉分批请求完成信号。传达分叉分批请求完成信号的所述替代例由所属领域的一般技术人员所理解。

如果包括第一及第二请求的分叉分批请求已经在位置262处或在位置262之前(发出第三请求的时间)完成，那么框架管理器或代理第一代理资源207A将不等待且紧紧抓住第三请求，但替代地立即开始处理由第一客户端208发出的第三请求。

随后，在位置272处，第一代理资源207A将第三请求转发到RPM204。在已由对应于第一资源207A的实际资源(未进行说明)服务第三请求之后，RPM204发出位置274处的与第一代理资源207A有关的第三请求完成信号。

后退一步且看图24的整体，在时间线位置258处，此位置可特征化为第一代理资源207A及第二代理资源207B的分叉点。这是第一代理资源207A及第二代理资源207B已由于其为分叉事务的部分而分叉的情况。隐式地分叉这些两个代理资源207A、207B因为其为分叉事务的部分。

这意谓图24的分批事务为分叉的，而两个代理资源207A、207B也分叉。换句话说，三个单独逻辑实体或表示已在分叉点258处分叉：事务自身、第一代理资源207A及第二代理资源207B。在分叉点252处，第一及第二代理资源207A、207B进入到不连贯状态中，意谓其无法服务新的请求直到其在接合点处接合为止，如下文将描述。

在此不连贯状态中，第一及第二代理资源207A、207B无法服务新的请求直到已完成分叉请求且已局部地完成所有相关清除任务。在此情形中，若干接连点可为可能的。现将如下描述接合点。

在图24中所说明的示范性实施例中，在批次请求完成信号在时间线位置270处与第一代理资源207A相交的情况下存在接合点280。此接合点280可特征化为第一代理资源207A的接合点280，及包括批次请求的事务。

在接合点280处，尽管事务含有两个请求(第一请求目的地是第一代理资源207A且第二请求目的地是第二代理资源207B)的事实，仅第一代理资源207A在接合点280处接合。因为第一代理资源207A仅为第一客户端208与第三请求有关的实体，所以可继续推迟接合第二代理资源207B所需要的任何清除工作。清除工作可是指将第二资源(由第二代理资源207B表示)引入到第二资源可服务另一请求的连贯状态所需要的额外任务或工作。

即使第一代理资源207A及第二代理资源207B在接合点280处可接合，仅第一代理资源207A在接合点280处接合，因为第三请求仅需要第一代理资源207A。第二代理资源207B可特征化为在接合点280处于不连贯状态。第二代理资源207B可在此阶段接合，但因为其不由第三请求需要，所以其可保持处于其不连贯状态。

例如此示范性实施例中的第二代理资源207B等分叉资源不接合直到其由另一请求需要为止。在处于此不连贯状态时，如果另一实体不需要来自第二代理资源的服务，那么第二代理资源207B不需要完成与分叉请求相关联的任何清除工作或清除任务。这允许在稍后时间完成清除工作或清除任务。在稍后时间推迟清除工作或清除任务节省处理电力：其允许清除工作直到绝对必要为止(当可需要来自可处于不连贯状态的资源的服务时)。

在需要来自(处于不连贯状态)的资源的服务时的所述时间点，与例如从第一客户端208或某一其它客户端发出的稍后第四请求(未说明)等第二资源(由图24中所说明的第二代理资源207B所表示)一样，接着此清除工作或清除任务可由第二实际资源(由第二代理资源207B表示)在处理或处置发出到当前处于不连贯状态的此第二资源的第四请求之前完成。

因此，在接收到请求之后，与第四请求一样，基于先前分叉请求处于不连贯状态的资源可执行清除工作且当其从例如第一客户端208等实体接收到正式请求时再次进入到连贯状态中。

不管何时对用于服务事务的任何一个资源作出请求，事务接合或进入到连贯状态中。多个连接点可在对为事务的部分资源中的每一者进行单独请求时存在，但事务实体被认为在所执行的第一接合点处接合，即在第一后续请求在事务中的资源中的任一者处到达时或在显式地接合事务自身时，如下文进一步所描述。

因此如果由第一客户端208对第二代理资源207B发出第四请求，那么例如第二接合点(未说明)可在相对于第一接合点280及针对第二代理资源207B的稍晚位置处发生。可提供机制以显式地接合事务。此机制将接合事务以及为事务的部分的每一单个资源。

用于接合事务的此机制可特征化为阻塞呼叫，因为其经设计成使系统等待直到已完成事务的所有请求。因此例如实体(例如，第一客户端208)进行接合事务的显式呼叫，接合事务呼叫将阻塞客户端直到第一请求及第二请求由实际第一及第二资源在RPM204的控制下完成为止。

一旦接合事务呼叫接收到已完成第一及第二请求的通知(如由位置269及270所指示)，那么接合事务呼叫将会将第一及第二代理资源207A、207B接合在一起，因为第一及第二代理资源207A、207B为事务的部分。接合事务呼叫接着将发送通知(呼叫)回到请求实体(例如，第一客户端208)，其指示第一及第二代理资源207A、207B返回到准备好在无不适当的延迟的情况下处理任何其它请求的连贯状态。如果这些代理资源207A、207B碰巧处于缺少接合事务呼叫的不连贯状态，那么将归因于清楚而存在延迟。

将利用接合事务呼叫的示范性情形如下：可在需要一组请求及/或任务的显式同步或门控时利用接合事务。因此例如假设需要对RPM204发出请求以便接通一些电力轨。到每一电力轨的个别请求可捆扎或分批成事务。

在将请求发出到电力轨的此情形中，虽然RPM204接通到各种类型的资源207A、207B的一些电力轨，但假设客户端需要将请求发出到局部资源，所述局部资源需要在其可处理所述请求之前将所述轨接通。

此处可利用显式接合呼叫以使得系统客户端等待直到已在发出/服务局部请求之前加电轨为止。与显式接合呼叫相反的是可特征化为“懒惰呼叫”或“发射后自寻”呼叫。懒惰接合呼叫需要将资源207A、207B引入回到连贯状态，但在仅对这些资源进行后续请求时或在某一预定时间周期之后。

系统允许将所有资源207A、207B引入回到事务接合自身的点处的连贯性(到连贯状态中)。位置262处的第三发出的请求可容易将所有事物(事务自身以及两个代理资源207A、207B)引入回到连贯状态，如由所属领域的一般技术人员所理解。如上文所论述，出于最优化上文所论述的图24的特定实施例起见，并不将所有代理资源207A、207B引入回到连贯状态中。在上文所描述的实施例中，推迟关于一些资源的清除工作是有利的，这意谓所有资源在接合事务之后不处于连贯状态。

如上文所描述，客户端208可指定代理资源207A、207B可分叉以及事务包括多个请求。客户端208还可指定代理资源207A、207B或事务可不分叉(在否定上下文中)。

资源可分叉自身，即使可不由客户端208表示的事务已分叉或可分叉。举例来说，假设第二资源207B为局部资源且不为代理。同时，如图24中所说明的第一资源207A保留代理且在RPM204的控制下。在第二资源207B为关于调制解调器202的局部资源的此情形下，第二资源207B将不在RPM204的控制下。

如果客户端208发出包括对第一及第二资源207A、207B的批次请求的事务，且即使客户端可不表示可分叉的事务，那么第二资源207B可自己从事务分叉且与由第一资源207A处理的请求独立地处理其请求，所述第一资源又为相对于新表示的第二局部资源207B的代理。这是第二局部资源207B已从事务分叉自身的实例，即使事务可不由客户端208表示为可分叉的。

根据上文事务，所属领域的一般技术人员将认识到可嵌套多个事务。在嵌套的多个事务情形中，嵌套的局部事务的内部事务需要同时结束，而外部事务需要变为可分叉的。在所述情形中，嵌套的多个事务的外部事务控制事务的嵌套群组的行为。因此在刚刚描述的情形中，如果外部事务需要为可分叉的，那么内部事务将准许所述分叉。

上文描述的系统101还支持接合回调。接合回调仅为有条件地且在结合事务之后执行的路径。接合回调可结合需要改变CPU的时钟设定的特定实例来解释。在所述情形中，可对局部管理的资源以及远程资源(例如图24中所说明的可在RPM204的控制下的资源)进行呼叫及请求。

时钟可需要系统在某一电压下运行或操作以维持某一处理速度。因此例如如果想要将时钟速度从200MHz改变到400MHz，那么可需要电压改变。电压可由RPM204控制，即可需要对远程资源调度一或多个请求，以便增加CPU的操作电压。

因此为了效率起见，应创建事务以捆扎远程请求的集合。另外，可使事务分叉以使得客户端可继续进行其它任务同时电压的改变由RPM204实现。然而，在电压不处于新时钟速度的所需电平的情形下，将需要在时钟速度升高之前使电压升高。

如果在新电压升高之前增加时钟，那么一些硬件可受到不合需要的损坏。在此情形中，有可能资源将分叉事务发出到RPM204以改变电压且接着绑定到所述请求(接合回调)的完成，且所述回调将会将请求发出到局部时钟。

含有逻辑以增加局部时钟频率(通过将请求发出到所述时钟资源)的接合回调因此可用以确保仅在必要的依赖性(即，电压)处于适当位置之后处理此请求。假设第一客户端208希望接通由RPM204控制的两个轨。而且假设第一客户端208需要接通局部时钟。此局部时钟可不设定为特定值直到接通这些两个轨为止。

因为第一客户端208需要用RPM204接通多个轨，所以第一客户端208可将其对这些两个轨的请求分批成单个事务。仅当此单个事务完成时，第一客户端208可请求发生对局部时钟的改变。

在分叉事务中，第一客户端208并不精确地知道何时服务请求，且在此特定情形中，第一客户端208将不知道何时已由RPM204接通第一及第二轨。因此第一客户端208可将其含有用于两个轨的两个请求的事务附接到局部时钟作为接合回调。在此示范性实施例中，接合回调将在位置270处发生，如图1中所说明。在位置270之后，接着可调整局部时钟，因为回调将指示已由RPM204接通第一及第二轨。接合回调特征为在已完成请求或事务之后资源或事务达成连贯性的过程的部分

分叉事务可在多个点处接合。这些多个接合点通过使用被称作接合令牌的构造来管理。接合令牌具有用以确保仅通过对事务中的资源中的一者的第一后续请求或通过用以接合事务的显式客户端呼叫接合事务一次的状态信息。

分叉的技术性细节(实现其的方式)由被称作附接到事务的扩展的构造确定。在RPM的状况下，例如如图24中所说明，扩展将为RPM传送协议的实施方案(如何将来自调制解调器202的请求传达到RPM204及所接收的响应)。

设计还提供客户端202可指定分叉偏好的机制。此情形由扩展在决定是使事务分叉还是同时完成所述事务时使用。在事务的情况下，正如资源207，用以使事务分叉的呼叫为请求。如果扩展不能够使事务分叉，那么其将同时地完成事务且接着调用注册的接合回调。

还注意，事务的设计允许客户端202在呼叫题为begin_transaction的函数之后发出对局部资源的请求(其在图24中并未说明，包含不由RPM204服务的请求)。虽然表面上为事务的部分，但这些请求不包含于批次中。然而，相关联的资源与事务中的其它资源锁定及解锁。

在分叉/接合的状况下，在局部请求在服务期间自身分叉的状况下，此情形变为重要的。为了适应此情形，对事务的接合令牌的参考不同于资源的自身接合令牌。此方法允许资源自身分叉及作为事务的部分分叉。

分叉事务可由应用程序编程接口(“API”)支持。将扩展每一事务API以包含以下功能：fork_transaction为用以使此事务分叉的请求且被呼叫以代替end_transaction。其接受将在事务稍后接合时调用的回调。如果扩展不使事务分叉，那么将同时呼叫此回调。

虽然事务在后续请求到达于事务中的资源中的任一者时隐式地接合，但可存在客户端希望强加接合而不进行新请求的状况。

join_transaction函数将显式地接合事务。可实施此函数以使得其与事务自身并排地接合事务中所涉及的所有资源，或其可仅接合事务实体，同时允许资源稍后在处理后续请求时变为连贯的。

可使用transaction_get/set_fork_pref API查询或设定分叉偏好(FORK_ALLOWED/DISALLOWED/DEFAULT)函数。扩展调用mark_transaction_forkedAPI以获得接合令牌且实际上使事务分叉。

可提供例如attach_client_to_transaction及attach_resource_to_transaction函数等额外API以使得能够将任意资源附接到事务，以使得对所述资源的后续请求也将致使事务接合。此情形在事务开始且从“父”资源的驱动函数内发出请求的状况下为有用的。父可将自身附接到事务(尽管不是其部分)，以使得对其的后续请求将致使分叉事务接合。

根据上文的发明，所属领域的一般技术人员能够写入计算机代码或识别适当硬件及/或其它逻辑或电路以基于例如流程图及本说明书中相关联的描述实施分布式资源管理系统及方法，而无些许困难。因此，程序代码指令的特定集合或详细硬件装置的揭示内容对于适当理解如何进行及使用分布式资源管理系统及方法来说并不被视为必要的。所主张计算机实施的过程的本发明功能性在上文描述中且结合可说明各种工艺流程的图式更详细地解释。此外，处理器110、126、202、206等与存储器112及存储于其中的指令组合可充当用于执行本文中所描述的方法步骤中的一或多者。

在一个或一个以上示范性方面中，可以硬件、软件、固件或其任何组合来实施所述的功能。如果实施于软件中，则可将功能作为计算机可读媒体上的一个或一个以上指令或码而加以存储或传输。计算机可读媒体包括计算机存储媒体与包括促进计算机程序从一处传递到另一处的任何媒体的通信媒体两者。存储媒体可为可由计算机存取的任何可用媒体。作为实例而非限制，此计算机可读媒体可包含RAM、ROM、EEPROM、CD-ROM或其它光盘存储装置、磁盘存储装置或其它磁性存储装置，或可用以运载或存储呈指令或数据结构形式的所要程序代码且可通过计算机存取的任何其它媒体。如本文中所使用的术语“磁盘”或“光盘”包含，但不限于，压缩光盘(“CD”)、激光光盘、光学光盘、数字多功能光盘(“DVD”)、软盘及蓝光光盘。上文的组合也应包含在计算机可读媒体的范围内。

虽然已详细说明及描述了选定方面，但将了解，在不偏离所附权利要求书界定的本发明的精神及范围的情况下，可在其中进行各种替换及变动。