JP2014528116A - ポータブルコンピューティングデバイスにおける分散リソース管理 - Google Patents

Abstract

ノードベースのリソースアーキテクチャを有するポータブルコンピューティングデバイスにおいて、第1のプロセッサによって制御されるが、第2のプロセッサによって制御される第2のまたはネイティブノードに対応する第1のまたは分散ノードが使用されて、第2のノードのリソースに間接的にアクセスする。アーキテクチャを定義するリソースグラフにおいて、各ノードは、1つまたは複数のリソースの機能のカプセル化を表し、各端は、クライアント要求を表し、隣接ノードは、リソース従属性を表す。第1のグラフによって定義されるリソースは、第1のプロセッサによって制御されるが、第2のプロセッサによっては制御されず、第2のグラフによって定義されるリソースは、第2のプロセッサによって制御されるが、第1のプロセッサによっては制御されない。第1のプロセッサの制御下にあるクライアントから、第1のノードに対するクライアント要求が受信され得る。次いで、第1のノードに対するクライアント要求に応答して、第2のノードに対してクライアント要求が出され得る。

Description

ポータブルコンピューティングデバイス(「PCD」)はますます普及しつつある。これらのデバイスは、セルラー電話、携帯情報端末(「PDA」)、ポータブルゲームコンソール、ポータブルナビゲーションユニット、パームトップコンピュータ、および他のポータブル電子デバイスを含み得る。これらのデバイスの各々は主要機能を有し得る。たとえば、セルラー電話は一般に、電話を受けたりかけたりする主要機能を有する。

これらのデバイスの多くは主要機能に加えて、周辺機能を含む。たとえば、セルラー電話は、上述したようにセルラー電話をかけるという主要機能、およびスチールカメラ、ビデオカメラ、全地球測位システム(GPS)ナビゲーション、ウェブブラウジング、電子メールの送受信、テキストメッセージの送受信、およびプッシュツートーク機能などの周辺機能を含み得る。PCDの機能が増加するにつれて、そのような機能をサポートために必要な計算能力または処理能力も増大する。処理能力は、PCD内のプロセッサの数を増やすことによって増大し得る。計算能力およびプロセッサの数が増大するにつれて、プロセッサを効果的に管理する必要性が増す。

上述したような機能は、リソースと呼ばれ得る様々な対応するハードウェア要素およびソフトウェア要素で具現化され得る。プロセッサは、アプリケーションプログラムなどのソフトウェアの制御下で様々な時間に様々なリソースを要求し得る。マルチプロセッサPCDにおいて、第1のプロセッサは、第2のプロセッサによって制御されるリソースとは異なるリソースを制御し得る。しかしながら、第1のプロセッサが、第2のプロセッサによって制御されるリソースを要求することが可能であることが望ましい場合がある。

マルチプロセッサポータブルコンピューティングデバイスにおける分散リソースを管理するための方法およびシステムは、あるプロセッサが、別のプロセッサによって制御されるリソースに対するリソース要求を出すことを可能にする。ノードベースのソフトウェアアーキテクチャを有するポータブルコンピューティングデバイスにおいて、リソースがノードに含まれ得る。例示的な実施形態では、第1のプロセッサによって制御されるが、第2のプロセッサによって制御される第2のノードに対応する第1のノードが、インスタンス化され、その後使用されて、第2のノードのリソースに間接的にアクセスする。第1のノードを分散ノードと呼ぶことがあり、第2のノードをネイティブノードと呼ぶことがある。第1の複数のリソースは、第1のプロセッサによって制御されるが、第2のプロセッサによっては制御されない。第2の複数のリソースは、第2のプロセッサによって制御されるが、第1のプロセッサによっては制御されない。第1の複数のリソースは、第1の無閉路有向グラフによって定義されてよく、第2の複数のリソースは、第2の無閉路有向グラフによって定義されてよい。第1のグラフの各ノードまたはリソースは、第1のプロセッサによって制御される1つまたは複数のリソースの機能のカプセル化を表す。第1のグラフの各端は、クライアント要求を表す。第1のグラフの隣接ノードは、リソース従属性を表す。同様に、第2のグラフの各ノードは、第2のプロセッサによって制御される1つまたは複数のリソースの機能のカプセル化を表す。第2のグラフの各端は、クライアント要求を表す。第2のグラフの隣接ノードは、リソース従属性を表す。

例示的な方法によれば、第1のプロセッサの制御下にあるクライアントから、第1のノードに対するクライアント要求が受信され得る。次いで、第1のノードに対するクライアント要求に応答して、第2のノードに対してクライアント要求が出され得る。

図中、別段規定されていない限り、同様の参照番号は、様々な図の全体を通じて、同様の部分を指す。「102A」または「102B」のような文字指定を伴う参照番号について、文字指定は、同じ図に存在する2つの同様の部分または要素を区別し得る。参照番号の文字指定は、参照番号が、すべての図において同じ参照番号を有するすべての部分を包含することが意図される場合には、省略されることがある。

ポータブルコンピューティングデバイス(「PCD」)における分散リソース管理のためのシステムの例示的な要素を示す機能ブロック図である。 第1のプロセッサが第2のプロセッサによって制御されるリソースを要求する必要がある場合の一例を示す機能ブロック図である。 PCDのリソースを管理するノードアーキテクチャの第1の態様の図である。 PCDの例示的なリソースのグループに関する無閉路有向グラフである。 PCDのリソースを管理するノードアーキテクチャの第2の態様の一般的な図である。 PCDのリソースを管理するノードアーキテクチャの第2の態様の具体的な図である。 PCDのリソースを管理するためのノードアーキテクチャを作成するための方法を示すフローチャートである。 PCDのリソースを管理するためのノードアーキテクチャを作成するための方法を示す図7の続きのフローチャートである。 PCD向けのソフトウェアアーキテクチャにおけるノード構造データを受信するための図7〜図8のサブ方法またはルーチンを示すフローチャートである。 PCD向けのソフトウェアアーキテクチャにおけるノードを作成するための図7〜図8のサブ方法またはルーチンを示すフローチャートである。 PCDのソフトウェアアーキテクチャにおけるクライアントを作成するための図10のサブ方法またはルーチンを示すフローチャートである。 PCD向けのソフトウェアアーキテクチャにおけるリソースに対するクライアント要求を作成するための方法を示すフローチャートである。 各プロセッサがそれ自体のリソースグラフのリソースを制御する、2つのプロセッサ間の通信経路を示す図である。 一部が分散リソースであるPCDのリソースを管理するためのノードアーキテクチャを作成するための方法を示す別のフローチャートである。 PCD向けのソフトウェアアーキテクチャにおける分散リソースに対するクライアント要求を作成するための方法を示す別のフローチャートである。 PCD向けのソフトウェアアーキテクチャにおける非プロキシ型の(non-proxied)分散リソースに対する状態クエリを処理するための方法を示すフローチャートである。 PCD向けのソフトウェアアーキテクチャにおけるプロキシ型の分散リソースに対する状態クエリを処理するための方法の第1の部分を示すフローチャートである。 PCD向けのソフトウェアアーキテクチャにおけるプロキシ型の分散リソースに対する状態クエリを処理するための方法の第2の部分を示すフローチャートである。

「例示的な」という言葉は、「一例、実例または例として」を意味するように本明細書で使用される。「例示的な」ものとして本明細書で説明する態様は、必ずしも他の態様よりも好ましい、または有利であると解釈されるわけではない。

本明細書では、「アプリケーション」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能コンテンツを有するファイルを含むこともある。加えて、本明細書で言及する「アプリケーション」は、開封される必要があり得るドキュメント、またはアクセスされる必要がある他のデータファイルなど、本質的に実行可能ではないファイルを含むこともある。

「コンテンツ」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能コンテンツを有するファイルを含むこともある。加えて、本明細書で言及する「コンテンツ」は、開封される必要があり得るドキュメント、またはアクセスされる必要がある他のデータファイルなど、本質的に実行可能ではないファイルを含むこともある。

本明細書で使用される場合、「構成要素」、「データベース」、「モジュール」、「システム」などの用語は、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、実行中のソフトウェアを問わず、コンピュータ関連のエンティティを指すことが意図されている。たとえば構成要素は、プロセッサ上で作動しているプロセス、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラムおよび/またはコンピュータであってよいが、これらであることに限定されない。例を挙げると、コンピューティングデバイス上で作動しているアプリケーションとコンピューティングデバイスの両方が構成要素であり得る。1つまたは複数の構成要素は、プロセスおよび/または実行スレッドの中に存在してよく、1つの構成要素を1つのコンピュータに局在化すること、および/または2つ以上のコンピュータに分散することが可能である。加えて、これらの構成要素は、様々なデータ構造を記憶している様々なコンピュータ可読媒体から実行することができる。各構成要素は、1つまたは複数のデータパケット(たとえば、信号を介してローカルシステム、分散システムにおける別の構成要素と相互作用するある構成要素からのデータ、および/または信号を介してインターネットなどのネットワーク上で他のシステムと相互作用するある構成要素からのデータ)を有する信号に従うなどしてローカルプロセスおよび/またはリモートプロセスを介して通信することができる。

本明細書では、「通信デバイス」、「ワイヤレスデバイス」、「ワイヤレス電話」、「ワイヤレス通信デバイス」、および「ワイヤレスハンドセット」という用語は交換可能に用いられる。第3世代(「3G」)および第4世代(「4G」)ワイヤレス技術が出現したことによって、利用可能な帯域が拡大されたので、より多くのワイヤレス機能を備えたより携帯が容易なコンピューティングデバイスが利用可能になっている。

本明細書では、「ポータブルコンピューティングデバイス」(「PCD」)という用語は、バッテリーなど限られた容量の電源で動作する任意のデバイスを説明するために使用される。何十年もの間バッテリー式PCDが使用されてきたが、第3世代(「3G」)および第4世代(「4G」)ワイヤレス技術の出現とともにもたらされた充電式バッテリーの技術的進歩は、複数の機能を有する多数のPCDを可能にした。したがって、PCDは、とりわけ、セルラー電話、衛星電話、ページャ、携帯情報端末(「PDA」)、スマートフォン、ナビゲーションデバイス、スマートブックまたはリーダー、メディアプレーヤ、上述のデバイスの組合せ、およびワイヤレス接続を有するラップトップコンピュータであり得る。

図1は、ポータブルコンピューティングデバイスにおける分散リソース管理のための方法およびシステムを実施するための、ワイヤレス電話の形態のPCD100の、例示的で非限定的な態様の機能ブロック図である。図示のように、PCD100は、マルチコアである中央処理装置(「CPU」)110A、グラフィックスプロセッサ110B、およびアナログ信号プロセッサ126を有するオンチップシステム102を含む。これらのプロセッサ110A、110B、126は、当業者に知られているように、1つまたは複数のシステムバスまたは別の相互接続アーキテクチャで互いに結合され得る。

当業者によって理解されるように、CPU110Aは、第0のコア222、第1のコア224などから第Nのコア226までを含み得る。代替実施形態では、CPU110Aおよびグラフィックスプロセッサ110Bの代わりに、当業者によって理解されるように1つまたは複数のデジタル信号プロセッサ(「DSP」)を用いることもできる。さらに、代替実施形態では、2つ以上のマルチコアプロセッサが含まれ得る。

図1に示すように、ディスプレイコントローラ128およびタッチスクリーンコントローラ130が、マルチコアCPU110Aに結合される。オンチップシステム102の外部にあるタッチスクリーンディスプレイ132が、ディスプレイコントローラ128およびタッチスクリーンコントローラ130に結合される。また、PCD100には、マルチコア中央処理装置(「CPU」)110Aに結合された、ビデオコーダ/デコーダ(「コーデック」)134、たとえば位相反転線(「PAL」)エンコーダ、順次式カラーメモリ(「SECAM」)エンコーダ、全米テレビジョン方式委員会(「NTSC」)エンコーダ、または任意の他のタイプのビデオエンコーダ134も含まれる。ビデオ増幅器136が、ビデオエンコーダ134およびタッチスクリーンディスプレイ132に結合される。ビデオポート138がビデオ増幅器136に結合される。図2に示すように、ユニバーサルシリアルバス(「USB」)コントローラ140がCPU110Aに結合される。また、USBポート142がUSBコントローラ140に結合される。加入者識別モジュール(SIM)カード146も、CPU110Aに結合され得る。さらに、図1に示すように、デジタルカメラ148がCPU110Aに結合され得る。例示的な態様では、デジタルカメラ148は、電荷結合デバイス(「CCD」)カメラまたは相補型金属酸化膜半導体(「CMOS」)カメラである。

図1にさらに示されるように、ステレオオーディオコーデック150が、アナログ信号プロセッサ126に結合され得る。さらに、オーディオ増幅器152が、ステレオオーディオコーデック150に結合され得る。例示的な態様では、第1のステレオスピーカー154および第2のステレオスピーカー156が、オーディオ増幅器152に結合される。図1は、マイクロフォン増幅器158もステレオオーディオコーデック150に結合され得ることを示している。加えて、マイクロフォン160が、マイクロフォン増幅器158に結合され得る。特定の態様では、周波数変調(「FM」)無線チューナー162がステレオオーディオコーデック150に結合され得る。また、FMアンテナ164がFM無線チューナー162に結合される。さらに、ステレオヘッドフォン166がステレオオーディオコーデック150に結合され得る。

図1は、高周波(「RF」)トランシーバ168がアナログ信号プロセッサ126に結合され得ることをさらに示している。RFスイッチ170が、RFトランシーバ168およびRFアンテナ172に結合され得る。図1に示すように、キーパッド174がアナログ信号プロセッサ126に結合され得る。また、マイクロフォンを備えたモノヘッドセット176が、アナログ信号プロセッサ126に結合され得る。さらに、バイブレータデバイス178が、アナログ信号プロセッサ126に結合され得る。図1は、たとえばバッテリーなどの電源180がオンチップシステム102に結合されることも示している。特定の態様では、電源180は、充電式DCバッテリー、または交流(「AC」)電源に接続されたAC-DC変換器から導出されたDC電源を含む。

PCD100の上記の要素の中には、ハードウェアを含み得るものがある一方、ソフトウェアを含み得るものもあり、さらに、ハードウェアとソフトウェアの組合せを含み得るものもある。「リソース」という用語は、本明細書において、ハードウェアであるか、ソフトウェアであるか、それらの組合せであるかを問わず、プロセッサによって制御可能な任意のそのような要素を指すために使用される。リソースは、一態様において、そのような要素の機能のカプセル化として定義され得る。別途示される場合を除いて、「プロセッサ」という用語は、本明細書において、CPU110、グラフィックスプロセッサ110B、アナログ信号プロセッサ126のようなプロセッサを指すために、またはソフトウェア、ファームウェアまたは同様の制御論理の支配下で動作する任意の他のプロセッサ、コントローラまたは同様の要素を指すために使用される。

以下でさらに詳細に説明するように、リソースの一例は、プロセッサ上で実行するソフトウェア要素である。たとえば、実行アプリケーションプログラムに関係するスレッドなどのプロセッサ上での実行のスレッドが、リソースに対する「要求」を出させることによって、リソースにアクセスすることができる。以下で説明するように、リソース要求は、本開示において「フレームワーク」と呼ばれるソフトウェアベースのシステムを通じて処理される。「クライアント」という用語は、本開示において、リソースを要求する機能をもたらす要素を指すために広く使用される。したがって、これらの用語が本明細書で使用される中、スレッドはリソース要求を出す目的で、クライアントを作成または利用することができる。場合によっては、リソースは、別のリソースに対するリソース要求を出させることができるように、クライアントを作成または使用できることに留意されたい。以下でさらに詳細に説明するように、そのような他のリソースを、要求側リソースと被要求側リソースとの間の従属関係により、本明細書では「従属」リソースと呼ぶことがある。リソースおよびクライアントは、メモリにおいてデータ構造によって表され得る。

リソースはマルチプロセッサPCD100内の特定のプロセッサによって制御されるので、PCD100内のすべてのプロセッサがPCD100内のすべてのリソースにアクセスできるわけではない。図2は、PCD100内の第1のプロセッサ202が、PCD100内の第2のプロセッサ206によって制御されるリソース204に対するリソース要求203を出すのが望ましい場合の一例を示している。第1のプロセッサ202が複数のリソース205を制御することもできることに留意されたい。同様に、第2のプロセッサ206が複数の追加リソース207を制御することができることに留意されたい。

第1のプロセッサ202がたとえばビデオプレーヤアプリケーションプログラムに関係するスレッド208を実行している場合、スレッド208は、第1のプロセッサ202のパフォーマンスを高める第1のプロセッサ202の1つまたは複数の動作パラメータの調整を求めることがある。(明快にするために、スレッド208およびリソース204はそれらのそれぞれのプロセッサ202および206に常駐するものとして概念的に示されているが、当業者は、そのような要素が、十分に理解されているコンピューティング原理に従ってプロセッサのメモリスペースにおいてプロセッサによって実行されるか、あるいは動作することを理解する。)そのような動作パラメータは、たとえば、クロック速度およびバス速度を含み得る。たとえば、様々なプロセッサが、同じバスクロックを使用し得るが、プロセッサのうちのたった1つが、バスクロックの直接(ハードウェアレベル)制御を有し得る。ビデオの再生は一般に、いくつかの他のタスクよりも処理能力集中度の高いタスク(more processing power-intensive task)であるので、クロック速度を上げると、たとえばビデオプレーヤアプリケーションプログラムによるパフォーマンスが向上することがある。処理能力は一般に百万命令毎秒(「MIPS」)で表現されるので、スレッド208は、一定数のMIPSを求めることができる。電力マネージャリソース204は、指定された数のMIPSに対する要求に応答して、第1のプロセッサ202が要求されたMIPSレベルで動作するのを促進するクロック速度、バス速度または他のパラメータを表し得る信号210の変更をもたらすアルゴリズムを含み得る。

第1のプロセッサ202が第2のプロセッサ206と通信する場合の手段であるバスまたはプロトコルに固有のアプリケーションプログラムインターフェース(API)を通じて、スレッドが電力マネージャリソース204にアクセスすることが可能な場合がある。しかしながら、以下で説明するフレームワークは、リソース固有およびバス固有のAPIよりも均一なリソース要求処理方法を提供することができる。後述のように、フレームワークを介して、リソース要求が出され、要求がリソース要求の発信元プロセッサと同じプロセッサによって制御されるリソースに対するものであるか、それとも異なるプロセッサによって制御されるリソースに対するものであるかにかかわらず、均一に応じられる。リソース要求の発信元プロセッサと同じプロセッサによって制御されるリソースは「ネイティブ」リソースと呼ばれ得る。リソース要求の発信元プロセッサとは異なるプロセッサによって制御されるリソースは、本明細書において「リモートリソース」または「分散リソース」と呼ばれ得る。

図3は、PCD100のソフトウェアまたはハードウェア(または両方)を表す機能ブロックを含む図である。線「A」の左側のブロックは、CPU110Aによって制御されるPCD100のリソースを表す。そのようなリソースは、一般に第1のハードウェア要素(ハードウェア要素#1)とも呼ばれるCPU110A自体、一般に第2のハードウェア要素(ハードウェア要素#2)とも呼ばれるCPU110Aのクロック442、一般に第3のハードウェア要素(ハードウェア要素#3)とも呼ばれるバスアービタまたはスケジューラ422、一般に第1のソフトウェア要素(ソフトウェア要素#1)とも呼ばれるバスプログラムA-444A、一般に第2のソフトウェア要素(ソフトウェア要素#2)とも呼ばれるバスプログラムB-444B、一般に第3のソフトウェア要素(ソフトウェア要素#3)とも呼ばれるクロックプログラムAHB、および一般にキープレスとして示されるソフトウェア要素によって監視されるアクションまたは機能448を含み得る。CPU110Aは、上記のリソースを制御するか、または上記のリソースにアクセスすることができ、その理由は、それらのリソースがCPU110Aのメモリスペース内にあり、CPU110Aがそれらのリソースにアクセスするのを阻むセキュリティ上の制限などの他の制限が存在しないことにある。たとえば、CPU110Aは、それらのリソースのハードウェアレジスタを制御すること、または当該ハードウェアレジスタにアクセスすることが可能であり得る。PCD100は、上記のリソース以外のリソースを制御するか、または当該リソースにアクセスすることができる他のCPU110(たとえば、図2参照)を含み得ることに留意されたい。

フレームワーク管理プログラム440は、コンピュータ命令のライブラリを含むことができ、リソースの機能をカプセル化するノードを管理する。すなわち、リソースに間接的にアクセスするようにノードにアクセスすることができる。便宜上、本明細書では、リソースを含むもの、備えるもの、有するものなどとして、リソースの機能をカプセル化するノードに言及することがある。各ノードは、1つまたは複数のリソースを含み得る。ノードは、ソフトウェアコード、ファームウェア、または同様の媒体において定義されることがあり、データ構造として、たとえばメモリ112(図1)においてPCD100の動作中にインスタンス化され得る。ノード601は、起動、電源投入、初期化、立上げなどのシーケンス中、またはPCD100の動作中における任意の他の適切な時間にインスタンス化され得る。本明細書における、リソースをインスタンス化すること、リソースに対する要求を出すこと、または別のやり方でリソースと対話することへの言及は、そのリソースを含むノードと対話することを意味するものとして理解されるべきことに留意されたい。本開示の残りについては、一般的なノードまたは不特定のノードが、図5に関して以下で説明するように参照番号601により指定される。

ノード601は、たとえば、第1のハードウェア要素または中央処理装置110に概ね対応する単一のリソースを有する第1のノード602を含み得る。本開示で説明するソフトウェアアーキテクチャでは、ノード601の各リソースは、1つまたは複数の英数字文字を含む一意の名前を与えられ得る。図3に示す例示的な実施形態では、第1のノード602のリソースは、「/core/cpu」というリソース名を割り当てられている。この例示的なリソース名は、当業者に知られている従来型のファイル命名構造に概ね対応する。ただし、当業者が認識するように、英数字文字および/または記号の任意の他の組合せを含む他のタイプのリソース名も、本開示の範囲内に十分に入る。

ノード601は、たとえば、複数のリソースを有する第2のノード622をさらに含み得る。この例示的な実施形態では、第2のノード622は、バスアービタまたはスケジューラ422に対応する単一のハードウェア要素を含む第1のリソースを有する。第2のノード622の第2のリソースは、バスプログラムA 444Aの第1のソフトウェア要素に概ね対応するソフトウェア要素を含む。第2のノード622の第3のリソースは、バスプログラムB 444Bの第2のソフトウェア要素に概ね対応する別のソフトウェア要素を含む。当業者は、所与のノード601に関するリソースおよびリソースタイプの任意の組合せおよび任意の数が本開示の範囲内に十分に入ることを認識する。

図3はまた、2つのソフトウェア要素448、450のアクションまたは機能に概ね対応する第1のクライアント648を示している。図3に示す例示的な実施形態では、第1のクライアント648は、ポータブルコンピューティングデバイス100によってサポートされる特定のアプリケーションプログラムモジュール105内で生じ得るキープレスアクションに概ね対応する。ただし、キープレス以外のソフトウェア要素の他のアクションおよび/または機能が本開示の範囲内に十分に入ることを、当業者は認識する。クライアント648およびそれらのそれぞれの作成については、図11に関連して以下でさらに詳しく説明する。

図3はまた、特定のアーキテクチャの要素間の関係を示している。たとえば、図3は、クライアント648と第1のノード602との間の関係を示している。詳細には、第1のクライアント648は、破線で示されているクライアント要求675Aを生成することができ、この要求は、リソース「/core/cpu」を含む第1のノード602によって管理または処理される。一般に、所定のまたは決められた数のタイプのクライアント要求675がある。クライアント要求675については、図12に関連して以下でさらに詳しく説明する。

図3に表示されている他の関係は、破線で示されている従属性680を含む。従属性は、別のノード601のそれぞれのリソースの間の関係である。従属関係は通常、第1のリソース(A)に情報を提供するか、または何らかの行動を実施し得る第2のリソース(B)に第1のリソース(A)が依存していることを示す。この情報は、第2のリソース(B)によって実行された動作の結果である場合、またはそれは、第1のリソース(A)が必要とするステータス情報を含むにすぎない場合、またはそれらの任意の組合せである場合がある。第1のリソース(A)および第2のリソース(B)は、同じノード601の一部である場合、または異なるノード601の一部である場合がある。クライアント要求675が、上記のキープレスアクションの例のような実行のスレッドからだけではなく、他のノード601からも生じ得ることに留意されたい。従属ノード601から情報または行動を取得するために、ノード601は、クライアント要求675をその従属ノード601に出すことができる。したがって、従属性を示す破線680は、潜在的なクライアント要求675の方向を示すこともできる。

図3では、第1のノード602で始まり、第2のノード622まで延びている従属性矢印680Bによって示されるように、第1のノード602は第2のノード622に従属している。図3はまた、従属性矢印680Aによって示されるように、第1のノード602が第3のノード642にも従属していることを示している。図3はまた、従属性矢印680Cによって示されるように、第2のノード622が第4のノード646に従属していることを示している。当業者は、図3の破線矢印で示されている従属性680が本質的に例にすぎないこと、およびそれぞれのノード601間の従属性の他の組合せが本開示の範囲内にあることを認識する。

フレームワーク管理プログラム440は、限定はしないが、図3に示すクライアント要求675、および従属性680を含む上述の関係を維持することを担当する。従属性などのいくつかのそのような関係は、PCD起動時(すなわち、電源投入、初期化、立上げなど)に、ノードインスタンス化プロセスを開始するためにそのような起動時にフレームワーク管理プログラム440がアクセスするPCD100内のソフトウェアコードにおいてリソースおよびそれらのノード601が定義されている方法によって存在する。クライアント要求675などの他のそのような関係は、アプリケーションプログラムがリソースを呼び出すアプリケーションプログラムスレッドの実行中など、ノード601がインスタンス化された後に生じる。クライアント要求675がノード601以外のアプリケーションプログラムスレッドまたは同様の要素の実行から生じる(たとえば、クライアント要求675A)か、それともノード601から生じるかを問わず、クライアント要求675は、フレームワーク管理プログラム440を通じて方向付けられる。フレームワーク管理プログラム440は、ノード601間の情報の移転を方向付ける。概念的に、フレームワーク管理プログラム440は、複数のスレッドがノード601と本質的に同時に通信する場合の手段である行列として働く。スレッドによって伴うデータは異なることがあるが、同じフレームワーク管理プログラムソフトウェアコードが複数のスレッドに応じ得る。

以下でさらに詳しく説明するように、フレームワーク管理プログラム440はノード601を、そのノードの従属ノードがインスタンス化され次第、すなわち、任意の所与のノード601の従属性680が解決されたとき、インスタンス化することができる。フレームワーク管理プログラム440は、PCD100のソフトウェアアーキテクチャにおいて定義されているすべてのノード601をインスタンス化しようと試みる。従属性をサポートするリソースが、存在するか、従属性680に関係する情報を処理する準備ができた状態にあるときに、従属性680は完全になるか、または解決される。

たとえば、第1のノード602と第3のノード642との間に存在する従属関係680Aを理由に、単一のリソース「/clk/cpu」を含む第3のノード642がインスタンス化されていない場合には、単一のリソース「/core/cpu」を含む第1のノード602がフレームワーク管理プログラム440によってインスタンス化され得ない。第3のノード642がフレームワーク管理プログラム440によってインスタンス化されると、従属関係680Aを理由に、フレームワーク管理プログラム440は第1のノード602をインスタンス化することができる。

フレームワーク管理プログラム440が特定のノード601を、その従属性680のうちの1つまたは複数が不完全または未解決であるためにインスタンス化することができない場合、フレームワーク管理プログラム440は、うまくインスタンス化されたノード601に対応するステップを引き続き実行する。フレームワーク管理プログラム440は通常、従属リソースが作成されていない不完全な従属性のために存在し得ない特定のノード601に対するコールを飛ばし、不完全なステータスを反映する当該コールに対するメッセージを返信する。

図1に示すようなマルチコア環境では、フレームワーク管理プログラム440は、図1の第0のコア222、第1のコア224、および第Nのコア226のような別個のコアでノード601を作成またはインスタンス化することができる。ノード601は一般に、ノード601が互いに従属していない限り、かつ後述するように特定のノードの対応する従属性のすべてが完全である場合に、マルチコア環境において別個のコアで並行して作成され得る。マルチプロセッサ環境において、ノード601は、図1のCPU110A、グラフィックスプロセッサ110Bなどのような様々なプロセッサ上で作成またはインスタンス化され得る。すなわち、あるプロセッサのメモリスペース内に存在するノード601もあれば、別のプロセッサのメモリスペース内に存在するノード601もある。ただし、一方のプロセッサ上のノード601に、他方のプロセッサ上のノード601がフレームワーク管理プログラム440のみを介してアクセスすることは可能ではない場合があることに留意されたい。

上述の(メイン)フレームワーク管理プログラム440に類似した遠隔フレームワーク管理プログラム300が、フレームワーク管理プログラム440と並行して、かつフレームワーク管理プログラム440の延長として存在し得る。遠隔フレームワーク管理プログラム300は、フレームワーク管理プログラム440に協力するか、またはフレームワーク管理プログラム440と協働して、様々なプロセッサ上のノード601間のプロセッサ間情報転送を調整する。すなわち、遠隔フレームワーク管理プログラム300は、関係するノード601が様々なプロセッサ上に存在する場合に、フレームワーク管理プログラム440が従属性およびクライアント要求などの上述の関係を維持するのを助ける。したがって、フレームワーク管理プログラム440および300の複合効果によって、あるプロセッサ上のノード601に、別のプロセッサ上のノード601がアクセスすることはできないようになる。さらに、関係するノード601が同じプロセッサ上に存在するか、それとも異なるプロセッサ上に存在するかを問わず、フレームワーク管理プログラム440および300の組合せは、本開示においてフレームワーク管理プログラム440に起因する機能のすべてを実行することができる。そのようなマルチプロセッサの実施形態では、フレームワーク管理プログラム300および440が含むソフトウェアの個々のコピーは、プロセッサの各々のドメインに常駐し得る。したがって、各プロセッサは同じフレームワーク管理プログラムソフトウェアにアクセスできる。

図4は、上述のノード602、622、642、および646を無閉路有向グラフ(「DAG」)400の形式で好都合に再構成している。グラフ400は、上述のソフトウェアアーキテクチャを定義する別の方法である。グラフ理論の語彙では、グラフ400の頂点はノード601に対応し、グラフ400の端はクライアント要求675に対応し、隣接するノードまたは頂点はリソース従属性を表す。当業者は、グラフ400が従属性の結果として有向グラフであり、フレームワーク管理プログラム440が、リソースAがリソースBに従属し、リソースBがリソースAに従属する閉路が定義されるのを防止するので、無閉路であることを認識しよう。すなわち、フレームワーク管理プログラム440は、互いに従属するように(誤って)定義される2つのノード601をインスタンス化しない。以下で説明するように、各ノード601はアクセスされるときに(トランザクション処理の意味で)ロックされるので、グラフの無閉路特性は、デッドロックを防止するうえで重要である。第1のスレッドが2つのノード601のうちの一方にアクセスしロックするのと同時に第2のスレッドがこれら2つのノード601のうちの他方にアクセスしロックした場合に、これら2つのノード601が互いに従属するならば、両方のスレッドが立往生することになる。一方、ソフトウェア開発者またはソフトウェアアーキテクチャを定義することに関与する他のそのような人が、互いに従属する2つのリソースをソフトウェアアーキテクチャで定義するのが望ましいと考える比較的まれな場合には、2つの(またはそれよりも多い)リソースを互いに同じノード601に含めることができる。同じノードにおける2つのリソースは、同じロック状態を共有する。少なくとも部分的にはこの理由により、ソフトウェア開発者または他のそのような人は、ノード622などの複数リソースノードをアーキテクチャで定義することを選択し得る。

本開示は明快にするために、かつ便宜上、ノード601の「リソース」ではなく「ノード」601に言及しているが、クライアント要求はノードではなく特定のリソースに方向付けられ得ることを理解されたい。言い換えれば、ノード601は、上述のように、1つまたは複数のリソースの機能をカプセル化するデータ構造であってよく、クライアントまたはクライアント要求の他の要求側、たとえば別のノード601から見て透過であり得る。クライアントから見て、要求はノードではなくリソースに対して出される。同様に、クライアントから見て、状態クエリ、イベント、またはアーキテクチャの他の要素は、ノードではなくリソースに関連付けられる。

例示的なグラフ400などのリソースグラフは、図6〜図10に以下で関して説明するように、従属性に従ったノード601のインスタンス化を理解するうえで有用である。ノード642および646などのリーフノードは、リーフノードには従属性がないので、非リーフノードの前にインスタンス化される。一般に、ノード601は、それに従属するノードがインスタンス化され得る前にインスタンス化されなければならない。さらに、リソース要求に応じることは、無閉路有向グラフをトラバースすることに対応し、無閉路有向グラフでは頂点がノード601に対応し、端がクライアント要求675に対応し、隣接するノードまたは頂点がリソース従属性に対応することがわかる。

マルチプロセッサPCD100において、第1のプロセッサは第1のリソースグラフにおけるノード601の第1のセットにアクセスすることができ、当該セットを制御することが可能であり得る一方、第2のプロセッサは第2のリソースグラフにおけるノード601の第2のセットにアクセスすることができ、当該セットを制御することが可能であり得、この場合に第1のリソースグラフおよび第2のリソースグラフはいかなるリソースも共有しない、すなわち、これらは相互に排他的なリソースグラフである。すなわち、そのような環境では、各プロセッサは、他のプロセッサがアクセスできないリソースおよび他の要素の間の関係を定義するそれ自体のリソースグラフを有する。本開示の分散リソース管理は、2つ以上のプロセッサがそれぞれ、それら自体のリソースグラフにおけるリソースにアクセスでき、他のプロセッサのリソースグラフにおけるリソースにアクセスできない場合に、従属性およびクライアント要求などの上述の関係を維持することに関係する。

リソースへのアクセスに対する上記の制限は、いくつかの実施形態では、ハードウェア構成によって制限され得る。すなわち、プロセッサは、レジスタなどのハードウェアデバイスにプロセッサが影響を与え得る手段を有さないことがあり、その理由は、ハードウェアデバイスが別のプロセッサのメモリスペースによって、または当該メモリスペースにおいて制御されることにある。代替的に、または追加として、リソースへのアクセスに対する制限は、ソフトウェアで課せられ、その理由は、プロセッサをセキュリティリスク(たとえば、別のプロセッサに感染し得るウイルス)にさらすのを最小化することなどである。

図5は、図1のPCD100のリソースを管理するシステム向けのソフトウェアアーキテクチャの別の態様の一般的な図500B1である。この態様は、明快にするために、PCD100ならびに関係するすべてのリソースおよび他の要素が同じプロセッサによって制御される、すなわちそれらが同じリソースグラフに含まれるアーキテクチャの文脈で記述している。この一般的な図では、各ノード601の1つまたは複数のリソースは、一意の名前を与えられていない。図5のノードまたはリソースグラフ500B1は、アーキテクチャまたはフレームワーク管理プログラム440によってサポートされるノード601、クライアント648、イベント690、および照会機能695のみ含む。各ノード601は、卵形およびノード601内のリソース間のそれぞれの従属性を表す特定の方向を有する矢印680により示されている。

図5はまた、第1のノード601Aのクライアント648がどのようにしてクライアント要求675を第1のノード601Aに出し得るかを示している。これらのクライアント要求675が出された後、第2のノード601Bは、イベント690をトリガするか、応答を照会695に提供することができ、この場合、イベント690および照会695に対応するメッセージがクライアント648に還流する。

図6は、図1のPCD100のリソースを管理するシステム向けのソフトウェアアーキテクチャの前述の態様のより具体的な図500B2である。図6は、具体的でありながらも例示的なリソース名を有するノード601、ならびにクライアント648、イベント690、および照会機能695(図3のそれらに対応するもの)のみ含むノードまたはリソースグラフ500B2を示している。各ノード601は、卵形およびノード601内のリソース間のそれぞれの従属性を表す特定の方向を有する矢印680により示されている。

たとえば、第1のノード602は、第1のノード602が第2のノード622の3つのリソースに従属していることを示す従属性矢印680Bを有する。同様に、第2のソフトウェア要素444Bを含み、図11Cにおいて全体的に参照文字「C」で表される第3のリソース「/bus/ahb/sysB/」は、第3のリソース(C)が第4のノード646の単一の「/clk/sys/ahb」リソースに従属していることを示す従属性矢印680Cを有する。

図6はまた、1つまたは複数のイベント690または照会機能695を含み得るノード601からの出力データを示している。照会機能695は、イベント690と類似している。照会機能695は、固有であるか固有でない照会ハンドルを有し得る。照会機能は一般的に、外部では識別されず、一般的に照会機能は状態を有さない。照会機能695を使用して、ノード601の特定のリソースの状態を判断することができる。照会機能695およびイベント690は、既存クライアント648との関係を有することがあり、これらの関係は、それぞれのイベント690および照会機能695からの情報が特定のクライアント648に渡されることを示す方向矢印697によって表されている。

図5〜図6のノードまたはリソースグラフ500Bは、プロセッサの制御下のメモリに存在し、フレームワーク管理プログラム440によって管理される関係を表している。ノードまたはリソースグラフ500Bは、フレームワーク管理プログラム440によって管理されるそれぞれの要素間の関係を識別するための、およびソフトウェアチームによるトラブルシューティングのための有用なツールとして、フレームワーク管理プログラム440によって自動生成され得る。

図7は、PCD100のリソースを管理するためのソフトウェア構造を作成またはインスタンス化するための方法1000Aを示すフローチャートである。この方法は、明快にするために、関係するすべてのリソースおよび他の要素が同じプロセッサによって制御される、すなわちそれらが同じリソースグラフに含まれるアーキテクチャの文脈で記述している。ブロック1005は、PCD100のリソースを管理するための方法またはプロセス1000の第1のルーチンである。ブロック1005において、ノード構造データを受信するためにフレームワーク管理プログラム440によってルーチンが実行され得る。ノード構造データは、特定のノード601が他のノード601との間で有し得る従属性を略述する従属性配列を含むことができる。ノード構造データおよびこのルーチンまたはサブ方法705に関するさらなる詳細は、図9に関連して以下でより詳細に説明する。

次に、ブロック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が作成またはインスタンス化される。ルーチンブロック1025のさらなる詳細については、図9に関連して以下で説明する。次に、ブロック1030において、フレームワーク管理プログラム440は、新規作成されたノード601を、その一意のリソース名を使用して公開し、それにより他のノード601が、新規作成されたノード601に情報を送ること、または新規作成されたノード601から情報を受信することができるようになる。

次に図7の続きのフローチャートである図8を参照すると、ブロック1035において、フレームワーク管理プログラム440は、新規作成されたノード601に従属する他のノード601に対し、新規作成されたノード601がインスタンス化されており、情報を送受信する準備ができていることを通知する。例示的な一態様によれば、図5のノード601Bのような従属ノードが作成されたときにただちに通知が開始される、すなわち、通知が再帰的に実行される。したがって、図5のノード601Bが構築された場合、ノード601Aはただちに通知される。この通知により、(ノード601Bはノード601Aが最後に従属するものであったので)ノード601Aを構築することができる。ノード601Bの構築により他のノード601が通知される、といった状況が生じ得る。ノード601Bに従属する最後のリソースが完成するまで、ノード601Bは完成しない。

第2の、前記実装形態よりも若干複雑な実装形態では、通知のすべてを個別の通知キューに配置し、次いで一時点で開始するキューを通読する(run through)、すなわち、通知は反復的に実行される。したがって、図5のノード601Bが構築されたとき、ノード601Aに対する通知がリストに渡される。次いで、そのリストが実行され、ノード601Aが通知を受ける。これにより、(図5に示されていない、ノード601A以外の)他の追加ノード601に対する通知が同じリストに掲載され、次いでその通知は、ノード601Aに対する通知が送られた後に送られる。(ノード601Aに対する通知以外の)他のノード601に対する通知は、ノード601Bおよびノード601Aに関連する作業がすべて完了するまで生じない。

論理的には、これら2つの実装形態は同等であるが、実施されたときのメモリ消費特性が異なる。再帰的実現は単純であるが、恣意的なスタックスペース量を消費する可能性があり、スタック消費は従属性グラフの深さの関数である。反復的実装形態はこれよりも若干複雑になっており、これよりも若干多くのスタックメモリ(通知リスト)を必要とするが、図5に示すように従属性グラフの深さにかかわりなくスタック使用は一定である。

また、ブロック1035におけるノード作成の通知は他のノードに限定されない。これはエイリアス構築に内部使用できる。他のノードにとどまらず、システム500Ａにおける任意の恣意的な要素が同じ機構を使用して、ノードが利用可能になったときの通知を要求することができる。ノードと非ノードの両方が同じ通知機構を使用することができる。

決定ブロック1040において、フレームワーク管理プログラム440は、最新ノード601の作成に基づいて作成またはインスタンス化するために他のノード601またはソフトな従属性が現在解放されているか否かを判断する。作成またはインスタンス化を最近経験している最新ノードによっていくつかの従属関係680が満たされていることを理由にリソースが作成可能であるか否かを、決定ブロック1040は一般に判断している。

決定ブロック1040への照会が肯定である場合、「はい」の分枝はルーチンブロック1025に戻り、作成されたばかりのノード601による従属性の充足を理由に、解放されているノード601を現在作成またはインスタンス化することができる。

決定ブロック1040への照会が否定である場合、「いいえ」の分枝はブロック1045に至り、フレームワーク管理プログラム440は、図2に示すようにソフトウェアアーキテクチャの要素間の通信を管理することができる。次に、ブロック1050において、フレームワーク管理プログラム440は、特定のリソースに関連するリソース名を使用することによって、リソースによって行われるアクションを引き続きログ記録または記録することができる。フレームワーク管理プログラム440、またはリソース、ノード601、クライアント648、イベント690、および照会機能695のような、フレームワーク管理プログラム440によって管理される要素のうちのいずれかによって行われる任意のアクションの後、フレームワーク管理プログラム440によってブロック1045が実行され得る。ブロック1045は、ノードアーキテクチャの別の態様を示し、ここではフレームワーク管理プログラム440は、ノード601のリソースのような特定の要素を作成したオーサーによって提供される一意の識別子または名前に従って各要素によって実行されるアクションを列挙する活動の実行ログを維持することができる。

従来技術と比較して、システムの各リソースに割り当てられた一意の名前を列挙するブロック1050における活動のログ記録は固有のものであり、デバッギングおよび誤りトラブルシューティングで使用されるような、大きい利点をもたらすことができる。ノードアーキテクチャ500Ａの別の固有の態様は、別個のチームが互いに独立して異なるハードウェア要素および/またはソフトウェア要素に取り組めることであり、この場合、各チームは、他のチームおよび/または相手先商標製造会社(OEM)によって割り当てられたさほど有意義ではなく一般にまぎらわしいリソース名を翻訳するためのテーブルを作成する必要なく、一意で追跡しやすいリソース名を使用することができる。

次に、決定ブロック1055において、フレームワーク管理プログラム440は、フレームワーク管理プログラム440によって記録された活動のログが要求されているか否かを判断する。決定ブロック1055への照会が否定である場合、「いいえ」の分枝はプロセスの最後に至り、プロセスはルーチン1005に戻る。決定ブロック1055への照会が肯定である場合、「はい」の分枝はブロック1060に至り、フレームワーク管理プログラム440は、有意義なリソース名およびリソース名によって実行されるそれぞれの活動を含む活動ログを、プリンタまたはディスプレイスクリーンおよび/または両方などの出力デバイスに送る。次いで、プロセスは上述のルーチンブロック1005に戻る。

図9は、PCD100のソフトウェアアーキテクチャを定義するノード構造データを受信するための図7のサブ方法またはルーチン1005を示すフローチャートである。受信方法は、たとえば、PCD100の起動時または初期化時など、任意に適切な時間に生じ得る。そのような場合、アーキテクチャに従ってノード601をインスタンス化するのに備えてメモリから対応するソフトウェアコードをプロセッサが読み取るときに、ノード構造データが受信される。ブロック1105は、図7のサブ方法またはルーチン1005における第1のステップである。ブロック1105において、フレームワーク管理プログラム440は、図3のCPU110およびクロック442のようなソフトウェア要素またはハードウェア要素の一意の名前を受信することができる。前に説明したように、ノード601は少なくとも1つのリソースを参照しなければならない。各リソースはシステム500Aにおいて一意の名前を有する。システム500A内の各要素が一意の名前により識別され得る。各要素は、文字の観点から一意の名前を有する。言い換えれば、一般に、同じ名前を有する2つの要素はシステム500A内に存在しない。システムの例示的な態様によれば、ノード601のリソースは一般にシステム全体で一意の名前を有することができるが、クライアントまたはイベントの名前は、要望に応じて一意であってもよいが、一意である必要はない。

便宜上、限定はしないが、CPU110の「/core/cpu」およびクロック442の「/clk/cpu」のような、一意の名前を作成するための前スラッシュ「/」文字を用いる従来型のツリーファイル命名構造またはファイル命名「メタファー」を用いることができる。ただし、当業者が認識するように、英数字文字および/または記号の任意の他の組合せを含む他のタイプのリソース名も、本開示の範囲内に十分に入る。

次に、ブロック1110において、フレームワーク管理プログラム440は、作成されるノード601の1つまたは複数のリソースに関連する1つまたは複数のドライバ機能に関するデータを受信することができる。ドライバ機能は一般に、特定のノード601に関する1つまたは複数のリソースによって完了するアクションを含む。たとえば、図7A〜図7Bにおいて、ノード602のリソース/core/cpuに関するドライバ機能は、要求されている所要量の処理を提供するために必要とする量のバス帯域幅およびCPUクロック周波数を要求することができる。これらの要求は、ノード642およびノード622におけるリソースのクライアントを介して行われる。ノード642における/clk/cpuに関するドライバ機能は通常、ノード602の/core/cpuリソースから受信した要求に従って物理クロック周波数を実際に設定することを担当する。

ブロック1115において、フレームワーク管理プログラム440はノード属性データを受信することができる。ノード属性データは一般に、安全性(ユーザ空間アプリケーションを介してノードにアクセスできるか)、遠隔性(システムにおいて他のプロセッサからノードにアクセスできるか)およびアクセス可能性(リソースは複数の並列クライアントをサポートできるか)などのノードポリシーを定義するデータを含む。フレームワーク管理プログラム440はまた、要求評価またはログ記録ポリシーなど、リソースがデフォルトフレームワーク行動を無効にすることを許容する属性を定義することができる。

その後、ブロック1120において、フレームワーク管理プログラム440は、作成される特定のノード601に関するカスタマイズされたユーザデータを受信することができる。ユーザデータは、「C」プログラミング言語に関して当業者によって理解されている空の「スター(star)」フィールドを含むことができる。ユーザデータはまた、「トラストミー(trust me)」フィールドとして当業者に知られている。例示的なカスタマイズされたユーザデータは、限定はしないが、テーブル、たとえば周波数テーブル、レジスタマップなどを含むことができる。ブロック1120において受信されたユーザデータは、システム500Ａによって参照されないが、リソースのカスタマイズを、カスタマイズがフレームワーク管理プログラム440によって認識されていないか、十分にサポートされていない場合に許容する。このユーザデータ構造は、特別な使用または特定の使用のために拡張されることが意図された「C」プログラミング言語における基本クラスである。

当業者は、特定のクラスの特定の使用を拡張するための他の種類のデータ構造が、本開示の範囲内にあることを認識する。たとえば、プログラミング言語「C++」(C-プラス-プラス)において、同等の構造が、ノード601内のリソースの拡張機構になるキーワード「パブリック(public)」を含むことができる。

次に、ブロック1125において、フレームワーク管理プログラム440は従属性配列データを受信することができる。従属性配列データは、作成されるノード601が従属する1つまたは複数のリソース601の一意かつ特定の名前を含むことができる。たとえば、図6の第1のノード602が作成されている場合、このブロック1125において、従属性配列データは、第1のノード602が従属する第2のノード622の3つのリソースのリソース名および第3のノード642の単一のリソース名を含むことができる。

続いて、ブロック1130において、フレームワーク管理プログラム440はリソース配列データを受信することができる。リソース配列データは、作成される最新ノードに関するパラメータ、たとえば、図7B〜図7Cの第1のノード602が作成されている場合にこの第1のノード602に関連するパラメータを含むことができる。リソース配列データは、以下のデータのうちの1つまたは複数を含むことができる。他のリソースの名前、ユニット、最大値、リソース属性、プラグインデータ、およびブロック1120のカスタマイズユーザデータに類似した任意のカスタマイズされたリソースデータ。プラグインデータは、一般に、ソフトウェアライブラリから取り出された機能を識別し、通常、作成される特定のノードまたは複数のノードによってサポートされ得るクライアントタイプを列挙する。プラグインデータはまた、クライアントの作成および破壊のカスタマイズを可能にする。ブロック1130の後、プロセスは図7のブロック1010に戻る。

図9において、属性データブロック1115、カスタマイズされたユーザデータブロック1120、および従属性配列データブロック1125は、これらの特定のステップが随意であり、所与のノード601に必要なものではないことを示すために破線で示されている。一方、一意の名前ブロック1105、ドライバ機能ブロック1110、およびリソース配列データブロック1130は、ルーチン1005のこれらのステップがノード601を作成するために一般に重要であることを示すために実線で示されている。

図10は、PCD100向けのソフトウェアアーキテクチャにおけるノードを作成するための図7のサブ方法またはルーチン1025を示すフローチャートである。ルーチンブロック1205は、例示的な一実施形態によるノード601をインスタンス化または作成するためのサブ方法またはルーチン1025における第1のルーチンである。ルーチンブロック1205において、インスタンス化されているノード601に関連する1つまたは複数のクライアント648が、このステップで作成される。ルーチンブロック1205に関するさらなる詳細については、図11に関連して以下でさらに詳しく説明する。

ブロック1210において、フレームワーク管理プログラムは、ブロック705のノード構造データに対応する1つまたは複数のリソースを作成またはインスタンス化することができる。次に、ブロック1215において、フレームワーク管理プログラム440は、ルーチンブロック1005のルーチンブロック1110において受信されたドライバ機能をアクティブ化することができる。例示的な一態様によれば、ドライバ機能は、ルーチンブロック1005のリソース配列データブロック1130において受信された最大値を使用してアクティブ化され得る。別の好ましい例示的な態様によれば、各ドライバ機能は、ルーチン1005からノード構造データとともに渡された随意の初期値によりアクティブ化され得る。初期データが提供されない場合、ドライバ機能は最小値0に初期設定される。ドライバ機能はまた、通常は、初期設定されていることがわかるようにアクティブ化される。これによりリソースは、初期設定に固有であるが、通常動作またはルーチン動作中に実行される必要のない動作を実行することができる。そして、プロセスは図7のステップ1030に戻る。

図11は、PCD100のソフトウェアアーキテクチャにおけるクライアント648を作成する、または初期設定するための図10のサブ方法またはルーチン1205を示すフローチャートである。ブロック1305は、1つまたは複数のリソース601のクライアント648が作成されるルーチンブロック1205の第1のステップである。ブロック1305において、フレームワーク管理プログラム440は、作成されるクライアント648に割り当てられた名前を受信する。リソース名と同様に、クライアント648の名前は、任意のタイプの英数字および/または記号を含むことができる。

次に、ブロック1310において、作成されるこのクライアント648に関する特定のカスタマイズがある場合に、カスタマイズされたユーザデータがフレームワーク管理プログラム440によって受信され得る。ブロック1310は、このステップが随意であることを示すために破線で示されている。ブロック1310のカスタマイズされたユーザデータは、ノード601のリソースの作成に関連して上述したカスタマイズされたユーザデータに類似している。

ブロック1315において、フレームワーク管理プログラム440は、作成される特定のクライアントに割り当てられたクライアントタイプカテゴリーを受信する。本明細書執筆時点でクライアントタイプカテゴリーは、4つのタイプのうちの1つを含むことができる。(a)必須、(b)インパルス、(c)ベクトル、および(d)等時性。クライアントタイプカテゴリーのリストは、システム101によって管理されているリソースに応じて、またノード601のリソースに依存するアプリケーションプログラムに応じて、拡大し得る。

必須カテゴリーは、必須クライアント648から特定のリソース601に渡されるスカラー値の処理に概ね対応する。たとえば、必須要求は、数百万命令毎秒(MIPS)を含むことができる。一方、インパルスカテゴリーは、開始時間または停止時間の指定のない一定期間内に何らかの活動を完了させるよう求める要求の処理に概ね対応する。

等時性カテゴリーは、通常は再発しており、明確な開始時間および明確な終了時間を有するアクションに対する要求に概ね対応する。ベクトルカテゴリーは、直列または並列に要求される複数のアクションの一部であるのが普通であるデータの配列に概ね対応する。

続いて、ブロック1320において、フレームワーク管理プログラム440は、クライアント648が同期に指定されているか、それとも非同期に指定されているかを示すデータを受信する。同期クライアント648は、リソース601が同期クライアント648から要求されたタスクを完了したことを示すデータおよび指示をリソース601が返信するまで、ノード601のリソースをロックすることをフレームワーク管理プログラム440に対し通常要求するクライアントである。

一方、非同期クライアント648は、フレームワーク管理プログラム440によってアクセスされる1つまたは複数のスレッドによって並列に処理され得る。フレームワーク管理プログラム440は、スレッドに対するコールバックを作成することができ、コールバックがそれぞれのスレッドによって実行されているときに値を戻すことができる。当業者は、同期クライアント648のタスクが実行されているときに同期クライアント648がリソースをロックするように、非同期クライアント648がリソースをロックすることはないことを認識する。

ブロック1320の後、決定ブロック1325において、フレームワーク管理プログラム440は、クライアント648によって識別されるリソースが利用可能であるか否かを判断する。決定ブロック1325への照会が否定である場合、「いいえ」の分岐がブロック1330に至り、クライアント648をこの時点で作成できないことを示すヌル値またはメッセージがユーザに返信される。

決定ブロック1325への照会が肯定である場合、「はい」の分岐が決定ブロック1335に至り、フレームワーク管理プログラム440は、クライアント648によって識別される各リソースがブロック1315において提示されたクライアントタイプをサポートするか否かを判断する。決定ブロック1335への照会が否定である場合、「いいえ」の分岐がブロック1330に戻り、クライアント648をこの時点で作成できないことを示すヌル値またはメッセージが返信される。

決定ブロック1335への照会が肯定である場合、「はい」の分岐がブロック1340に至り、フレームワーク管理プログラム440はメモリ内にクライアント648を作成またはインスタンス化する。次に、ブロック1345において、随意の引数のような任意のカスタマイズされたユーザデータがブロック1310において受信された場合、これらの随意の引数が特定のノード601にそれぞれのリソースを使ってマップされ得る。次に、ブロック1350において、新規作成されたクライアント648が、アイドル状態において、または上記したように要求された状態において、その対応する1つまたは複数のリソースに結合される。そして、プロセスは図10のブロック1210に戻る。

図12は、PCD100向けのソフトウェアアーキテクチャにおけるリソース601に対するクライアント要求675を作成するための方法1400を示すフローチャートである。方法1400は一般に、図7〜図11に関連して上述したようにクライアント作成およびノード作成（初期化）の後、実行される。

ブロック1405は、リソース601に対するクライアント要求675を作成するための方法1400における第1のステップである。方法1400は、以下の3つのタイプのクライアント要求675がフレームワーク管理プログラム440によってどのように処理されるかを表している。(a)必須、(b)インパルス、および(c)ベクトル。第4のタイプの要求675、すなわち(d)等時性要求の処理については、図15に関連して後述する。前記の要求675の名前が示唆するように、クライアント要求675は、作成され、図14に関連して上述したクライアントタイプに概ね対応する。

ブロック1405において、フレームワーク管理プログラム440は、上述した3つ、すなわち(a)必須、(b)インパルス、および(c)ベクトルのうちの1つのような特定のクライアント要求675に関連するデータを受信することができる。必須要求に関連するデータは一般に、必須クライアント648から特定のリソース601に渡されるスカラー値を含む。たとえば、必須要求は、数百万命令毎秒(MIPS)を含むことができる。インパルス要求は、開始時間または停止時間の指定のない一定期間内に何らかの活動を完了させるよう求める要求を含む。ベクトル要求に関するデータは一般に、直列または並列に完了することが求められる複数のアクションの配列を含む。ベクトル要求は、値の任意の長さを含むことができる。ベクトル要求は通常、サイズ値および値の配列を有する。ノード601の各リソースは、ベクトル要求をサポートするためにポインタフィールドを有するように拡張され得る。「C」プログラミング言語では、ポインタフィールドは、当業者によって理解されているように、統合機能(union function)によってサポートされている。

次に、ブロック1410において、フレームワーク管理プログラム440は、図11に関連して上述した方法によって作成されたクライアント648を通じて要求を出す。続いて、ブロック1415において、フレームワーク管理プログラム440は、要求が必須タイプまたはベクトルタイプである場合に、クライアントを通じて渡されている要求データを二重バッファする。要求がインパルスタイプである場合、ブロック1415はフレームワーク管理プログラム440によって飛ばされる。

必須要求の場合、このブロック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のリソースに固有のドライバ機能を実行できるようにする。ドライバ機能は、更新機能によって計算される通りにリソース状態を適用する。これは、ハードウェア設定を更新すること、従属リソースに要求を出すこと、レガシー機能を呼び出すこと、または前記の何らかの組合せを伴うことがある。

前述の例では、更新機能は、要求されたバスクロック周波数を計算した。ドライバ機能は、その要求された周波数を受信することができ、クロック周波数制御ハードウェアを更新して、その周波数で作動させることができる。更新機能が計算した正確な要求された状態をドライバ機能が満たすことは不可能な場合もあることに留意されたい。この場合、ドライバ機能は、要求を最も満たす周波数を選択することができる。たとえば、バスクロックハードウェアは128MHzおよび160MHzでのみ作動できるが、要求された状態は150MHzである場合がある。この場合、ドライバ機能は、要求された状態を上回る160MHzで作動すべきである。

次に、ブロック1455において、フレームワーク管理プログラム440は、ブロック1450においてドライバ機能を実行したリソースから状態制御を受信する。続いて、ブロック1460において、リソースに対して定義されている場合、イベント690をトリガすることができ、それによりデータは、イベント690に対応するクライアント648に戻される。イベントは別のスレッドで処理され得る。これにより、ロックされたリソースで費やされる時間量を最小限に抑えることができ、図1に示したようなマルチコアシステムにおける並列的な動作が可能になる。本方法1400で説明するようにリソースに対して要求を定義できる方法と同様に、リソースに対して1つまたは複数のイベント690を定義することができる。言い換えれば、イベント作成プロセスは、クライアント作成プロセスに概ね匹敵する。イベントと異なる1点は、いくつかのしきい値を超えたときのみトリガされるイベントを定義することが可能である点である。

しきい値に基づいてのみトリガされるイベントのこの定義により、システムの過負荷状態を示す、リソースがオーバーサブスクライブされている(サポートできる数を超える同時ユーザを有する)時期、または他の物が断たれること、システムがオーバーサブスクライブされたときに無効になった機能を回復させることなどが可能になる、リソースが低水準/オフになる時期を通知することができる。イベント登録はしきい値により行うことができるので、システムがイベント通知に関して行わなければならない作業の量が減り、本当に必要なものがあるときのみイベント通知が生じるようになる。あらゆる状態変化に関するイベントを登録することも可能である。

次に、随意のブロック1465において、処理されている要求がベクトル要求である場合、この随意のブロック1465はたいてい実行される。随意のブロック1465は一般に、ベクトルポインタが依然として、ユーザがベクトルに渡した同じデータに位置付けられているか否かを査定するチェックまたは判断を含む。この随意のブロック1465への照会が肯定である場合、ポインタは依然として、ユーザによってベクトルに渡された同じデータを指していることを意味し、古いデータの参照が維持されないようにポインタが除去される。この随意のブロック1465は一般に、インパルス要求および必須要求と比較して、ベクトル要求が処理されているときに上述の二重バッファリングブロック1415を考慮して(account for)実行される。

続いて、ブロック1470において、フレームワーク管理プログラム440は、要求されたリソースのロックを解除し、それにより他のクライアント要求648は、特定のノード601の現在のものであるが今解放された要求されたリソースによって処理され得る。次いでプロセスは、次のクライアント要求を受信するために第1のブロック1405に戻る。

上記の方法およびデータ構造は本質的に、単一プロセッサPCD100に適用可能なように、マルチプロセッサPCD100にも適用可能である。ただし、遠隔フレームワーク300(図3)は、マルチプロセッサの実施形態における動作を向上させ得る追加の特徴を提供することができる。たとえば、遠隔フレームワーク300は有利なことに、プロセッサ間通信の詳細を、アプリケーションプログラマーまたは同様の人には透過にすることができる。それにより、アプリケーションプログラムは、たとえば、ターゲットリソースを制御するプロセッサドメインの任意の識別情報をクライアント定義に含める必要なしに、そのリソースに対する要求を出すクライアントを定義することができる。むしろ、遠隔フレームワーク300は、どのプロセッサがクライアントを制御するか、およびどのプロセッサがターゲットリソースを制御するかにかかわらず、要求がターゲットリソースに到着するようにする。さらに、遠隔フレームワーク300は、たとえば、アプリケーションプログラムがプロトコルまたはプロセッサ間の通信経路(たとえば、バス)の他の態様に関係するいかなる命令も含む必要がないように、プロセッサ間通信を管理する。さらに、プロセッサ間通信経路によって使用するプロトコルが異なり得るので、遠隔フレームワーク300は、リソース定義がリソースの他の態様とともにプロトコルを指定できるようにする。分散リソース管理に関係するこれらおよび他の特徴について、図13〜図17に関して以下で説明する。

図13は、第1のプロセッサ(図示せず)によって制御される第1のリソース1302が、第2のプロセッサ(図示せず)によって制御される第2のリソース1304に対応する分散リソースまたはリモートリソースとして働く例または場合を示している。「分散リソース」または「リモートリソース」という用語は、本開示において、あるプロセッサ上の、別のプロセッサ上の「ネイティブ」リソースに対応するリソースを指すために使用される。この例における第2のリソース1304は、第2のプロセッサに対するネイティブリソースとして働く。分散リソースは、対応するネイティブリソースにアクセスする手段として使用される。この例では、リソースがノードに含まれ得ることを理解すべきであり、「リソース」という用語は「ノード」という用語と互換的に使用され得る。

破線1301は、(線1301の左側の)第1のプロセッサによって制御されるリソースと(線1301の右側の)第2のプロセッサによって制御されるリソースとの間の区分を示している。第1のリソース1302は、第1のプロセッサによって制御される2つ以上のリソースのうちの1つである。1つのそのようなリソースは、第1のリソース1302が従属するプロトコルリソース1306であり得る。同様に、第2のリソース1304は、第2のプロセッサによって制御される2つ以上のリソースのうちの1つである。いくつかの実施形態では、分散リソースのみがプロトコルリソース従属し、ネイティブリソースはプロトコルリソースに従属しない。したがって、そのような実施形態では、第1の(分散)リソース1302のみがプロトコルリソース1306に従属する。ただし、他の実施形態では、どのリソースもプロトコルリソースに従属し得る。したがって、代替実施形態では、第2のリソース1304もプロトコルリソース(図示せず)に従属し得る。第1のリソース1302および第2のリソース1304は、全般的にリソースまたはノードに関して上述したのと同様に、追加リソースに従属することもあるが、そのような追加リソースは、明快にするために図13には示されていない。第1のプロセッサによって制御されるリソースが、第1のリソースグラフ(すなわち、無閉路有向グラフ)によって定義され、第2のプロセッサによって制御されるリソースが、第1のリソースグラフとリソースをまったく共有しない第2のリソースグラフによって定義されることに留意されたい。

第1のリソース1302および第2のリソース1304は、それらのそれぞれのプロセッサの制御下にあり、通信経路1303を介して情報を通信することが可能である。通信経路1303は、第1のプロセッサと第2のプロセッサとの間の物理媒体と、その媒体を介して通信するために使用されるトランスポートプロトコルの1つまたは複数の層との組合せを表す。したがって、第1のリソース1302と第2のリソース1304との間のいかなる通信も、そのプロトコルに準拠しなければならない。プロトコルリソース1306は、プロトコルを定義するか、またはライブラリ(図示せず)内のプロトコル定義を指し得る。遠隔フレームワーク300および(メイン)フレームワーク440は、互いに連携して動作して、リソースおよびリソース間の通信を管理する。以下で説明するように、クライアント1312は、第1のプロセッサの制御下にあり、第1のリソース1302に対する1つまたは複数のリソース要求を出すことができる。第1のリソース1302は、対応する第2のリソース1304の機能を使用して、リソース要求に応じる。

図14は、図13の第1のリソース1302などの分散リソースを作成またはインスタンス化するための方法1400を示すフローチャートである。図14のフローチャートは、図7〜図10に示す方法などのリソースをインスタンス化するための方法に関して上述した特徴に追加される、または当該特徴を増強する特徴を示すように意図されている。したがって、別途示される場合を除いて、図7〜図10におけるブロックのいずれかまたはすべては含まれ得るが、明快にするために図14には示されていない。

ブロック1402によって示されるように、フレームワーク管理プログラム300および440は、第1のリソース1302を含むノードなどのノードを定義するノード構造データを受信する。例示的な実施形態では、ブロック1406によって示されるように、プロトコルリソースが任意の時間にインスタンス化され得ることを除いて、従属性は図7〜図10に関して上記で説明したのと本質的に同じ方法で処理される。プロトコルリソースに従属するリソースは、そのプロトコルリソースがインスタンス化されるまで待つ必要がない。図7〜図10に関して上記で説明した方法による従属性のインスタンス化は、ブロック1408によって全般的に示されている。

インスタンス化は全般的に、図7〜図10に関して上記で説明した方法に従うが、分散リソースは、対応するネイティブリソースがインスタンス化されるまでインスタンス化できないことに留意されたい。したがって、従属リソースのインスタンス化が、それらに従属するリソースのインスタンス化を遅延させ得るのと同様に、ネイティブリソースのインスタンス化は、分散リソースのインスタンス化を遅延させ得る。通信経路1310を介して第1のプロセッサと第2のプロセッサとの間で通信されるネイティブリソースのインスタンス化の状態に関係するメッセージならびにフレームワーク管理プログラム300および440は全般的に指定プロトコルに準拠することにも留意されたい。たとえば、第1のプロセッサ上のプロトコルリソース1306がインスタンス化された後、遠隔フレームワーク管理プログラム300に従って動作している第1のプロセッサは、符号化されたか、または別のやり方でプロトコルに準拠する通知を求める要求を第2のプロセッサに送ることができる。第2のリソース1304がインスタンス化されたとき、遠隔フレームワーク管理プログラム300に従って動作している第2のプロセッサは、第2のリソース1304がインスタンス化されたことを示す応答を第1のプロセッサに送ることによって、通知を求める要求に応答することができる。遠隔フレームワーク管理プログラム300は、ソフトウェアアーキテクチャをインスタンス化するプロセスの一部として、そのような通信などを管理することができる。

第1のプロセッサ上のプロトコルリソース1306は、機能の中でも、図13に示すクライアント1312などのクライアントを作成し、実行のスレッドによって使用され得るハンドルをクライアントに返す機能を含むことができる。実行のスレッド(たとえば、アプリケーションプログラムまたは他のソフトウェア要素の実行の一部)は、そのようなクライアント1312を作成する機能を呼び出すことができる。スレッドは、リソース要求を出すためにクライアント1312を使用することができ、かつ全般的にクライアントに関して上述したのと同じ方法でクライアント1312を別途使用することができる。リソース要求はプロトコル固有であり、スレッドがプロトコルに関係する何らかの情報を提供する必要なしに、スレッドが第2のリソース1304にアクセスできるようにする。スレッドおよびそのクライアントから見て、プロトコルは無関係または透過であり得る。

ブロック1410によって示されるように、フレームワーク300および440は、受信されたノード構造データにおいてアグリゲーション方法が指定されているか否かを判断する。アグリゲーション方法が指定されていると判断された場合、ブロック1412によって示されるように、分散リソース(ノード)およびネイティブリソース(ノード)においてアグリゲーション方法が設定される。ローカルおよびプロキシという2つのアグリゲーションタイプがある。リソースを定義する際、2つのアグリゲーションタイプのうちの1つが選択され得る。したがって、リソース(ノード)をインスタンス化する際、リソースはローカルアグリゲーションまたはリモートアグリゲーションを実行するように設定される。

リソースは、リソースが「同時に」受信し得る複数のリソース要求にアルゴリズムを適用することによって、ローカルアグリゲーションを実行する。この文脈では、2つの(またはそれよりも多い)要求は、両方がアクティブであり続ける時間中、「同時」である。たとえば、第1のプロセッサは、リソースの速度を50MIPSに設定するよう求めるリソース要求を出すことができ、第1のプロセッサの要求が完了または別のやり方で終了する前に、第2のプロセッサは、リソースの速度を100MIPSに設定するよう求めるリソース要求を出すことができる。アグリゲーションは、複数の同時のリソース要求の各々の引数を追加するなどの方法に従って、すべての複数のリソース要求の引数のうちで最大引数を判断することによって、すべての複数のリソース要求の引数のうちで最小引数を判断することによって、または任意の他の適切な方法によって実行され得る。リソース(ノード)を定義するノード構造データにおいて、アグリゲーションタイプとともにアグリゲーション方法が指定または定義され得る。

ノード構造データは、ノードがプロキシ型のノードまたは非プロキシ型のノードとしてインスタンス化されることになることを示すことができる。この特徴が使用され得る方法については、図16〜図17に関して以下で説明する。ブロック1414によって示されるように、ノードタイプが、示されたタイプに設定される。非プロキシ型のノードの場合、クライアント要求はノード構造によって決定された方法でローカルにアグリゲートされ、ローカルにアグリゲートされた要求をネイティブリソースに送るドライバ機能が使用される。クエリおよびイベントが分散リソースによって処理される。プロキシ型のノードの場合、クライアント要求はアグリゲートされず、代わりに、ネイティブリソースに個別に送られる。さらに、すべてのクエリおよびイベントがネイティブリソースに転送される。

ブロック1416によって示されるように、インスタンス化プロセスにおける残りのステップが生じる。分散ノードをインスタンス化するそのような態様は、図7〜図10に関して上記で説明したのと本質的に同じであり得る。ブロック1418によって示されるように、追加ノードが定義された場合、本方法はそれらのノードのために反復または継続する。

図15は、クライアント要求に応じるための方法1500を示すフローチャートである。図15のフローチャートは、図12に示す方法などのクライアント要求に応じるための方法に関して上述した特徴に追加される、または当該特徴を増強する特徴を示すように意図されている。したがって、別途示される場合を除いて、図12におけるブロックのいずれかまたはすべては含まれ得るが、明快にするために図15には示されていない。

ブロック1502によって示されるように、図13における第1のノード1302の分散リソースなどの分散リソースは、クライアント要求を受信する。ブロック1504によって示されるように、被要求側リソースに関連するアグリゲーションタイプがローカルであるか、それともリモートであるかが判断される。アグリゲーションタイプがローカルである場合、ブロック1506によって示されるように、被要求側リソースは要求引数を、同じウィンドウ内で生じている他の要求引数とアグリゲートする。上述のように、アグリゲーションは同時のリソース要求を処理することに関係する。被要求側リソースに関連するアグリゲーションタイプがリモートである場合、要求を他の要求とアグリゲートすることは、図13における第2のリソース1304など、対応するネイティブリソースに委ねられる。

ローカルであるか、それともリモートであるかを問わず、アグリゲーションは、クライアント要求の3つの連続的な状態、すなわち、(1)要求発信(Request Issued)、(2)要求進行(Request in Progress)および(3)要求適用(Request Applied)を関係させる。クライアント要求が同時に出される場合、すなわち、2つのクライアント要求がそれぞれ、要求発信状態を実質的に同時に、または互いの上記のウィンドウ内で開始する場合、1番目に生じたクライアント要求は、被要求側リソースをロックさせ、2番目に生じたクライアント要求は、1番目に生じたクライアント要求の後、処理される。要求進行状態の間に、クライアント要求が処理されるか、または応じられる。クライアント要求が完了した後、クライアント要求は要求適用状態を割り当てられる。複数の同時のクライアント要求が要求適用状態に達した場合に、アグリゲーションは作用し始める。たとえば、リソースが上記の最大アグリゲーション方法を使用するものとして定義されていて、クライアント「A」が50MIPSを要求する一方で、おそらく数マイクロ秒後にクライアント「B」が100MIPSを要求する場合、これらの初期要求は直列化される。したがって、第1のクライアント要求が処理されるとき、リソースは第1のクライアント要求の引数すなわち50MIPSに設定される。次いで、第2のクライアント要求が処理されるとき、リソースは、最大アグリゲーション方法に従い、50および100の最大値が100であるので、100に設定される。その後、これらの初期クライアント要求の両方が要求適用状態にあるとき、クライアント「B」は25MIPを求める別のクライアント要求を出し得る。被要求側リソースは、最大アグリゲーション方法に従い、50および25の最大値が50であるので、50に設定される。

ブロック1508によって示されるように、被要求側リソースが図13におけるプロトコルリソース1306などのプロトコルリソースに従属しているか否かが判断される。被要求側リソースがプロトコルリソースに従属している場合、ブロック1510および1512によって示されるように、プロトコルリソースを呼び出し、使用して、プロトコルリソースが定義するプロトコルにリソース要求を準拠させる。ブロック1514によって示されるように、プロトコルに準拠して、アグリゲーション結果(ブロック1506の結果)を反映したリソース要求が図13における第2のリソース1304などのネイティブリソースに送られるか、またはリモートリソースがアグリゲーションを実行する場合には、リソース要求が当該ネイティブリソースに転送される。分散リソースのドライバ機能(図示せず)がプロトコルを呼び出す。

図15には示されていないが、分散リソースを伴うイベントは、図12に関して上記で説明したのと本質的に同じ方法で処理され得る。しきい値を越える値がないかを監視するタイプのイベントは、後述のように、プロキシ型のリソースとの組合せにおいて特に有用であり得る。

図16は、非プロキシタイプの分散リソースに対する状態クエリに応じるための方法1600を示すフローチャートである。状態クエリは、図5〜図6に関して上記で説明したようにフレームワーク440によって管理される。図16〜図17のフローチャートは、図5〜図6に関して上記で説明した特徴に追加される、または当該特徴を増強する特徴を示すように意図されている。したがって、別途示される場合を除いて、図5〜図6に関して上記で説明した特徴のいずれかまたはすべては含まれ得るが、明快にするために図16〜図17には示されていない。

ブロック1602によって示されるように、図13における第1のノード1302の分散リソースなどの分散リソースは、状態クエリを受信する。この例では、第1のノード1302は、非プロキシ型のノードまたはリソースを表す。ブロック1604によって示されるように、図13における第2のリソース1304などの対応するネイティブリソースに状態クエリが転送される。ブロック1606によって示されるように、状態クエリに応答して、分散リソースにネイティブリソースの状態が返信される。ブロック1608によって示されるように、次いで分散リソースは、ネイティブリソースの状態を表す状態指示をクエリ要求側(クライアント)に提供することができる。

図17Aは、プロキシタイプの分散リソースに対する状態クエリに応じるための方法1700の第1の部分を示すフローチャートである。ブロック1702によって示されるように、図13における第1のノード1302の分散リソースなどの分散リソースは、状態クエリを受信する。この例では、第1のノード1302は、プロキシ型のノードまたはリソースを表す。それぞれブロック1704および1706によって示されるように、分散リソースがネイティブリソースの状態の指示を受信するたびに、分散リソースはその状態を、ネイティブリソースの状態を反映するように更新する。ブロック1708によって示されるように、分散リソースはそれ自体の状態の指示をクエリ要求側(クライアント)に提供する。したがって、プロキシ型の分散リソースの場合、その状態は、状態の変化の通知を対応するネイティブリソースから受信したときに変化するだけである。

ブロックによって示されるように、図13における第2のリソース1304などの対応するネイティブリソースに状態クエリが転送される。ブロック1606によって示されるように、状態クエリに応答して、分散リソースにネイティブリソースの状態が返信される。

図17Bは、プロキシタイプの分散リソースに対する状態クエリに応じるための方法1700の第2の部分を示すフローチャートである。この第2の部分は、ネイティブリソースの視点を反映しており、非同期的に、かつ図17Aに示す第1の部分と並行して動作する。ブロック1710によって示されるように、図13の第2のノード1304などのネイティブリソースの状態が監視される。それぞれブロック1712および1714によって示されるように、ネイティブリソースの状態の変化が検出された場合、ネイティブリソースの状態の指示が、対応する分散リソースに送られる。

適切な場合におけるプロキシ型の分散リソースの使用は、ネイティブリソースの状態が変化したときにネイティブリソースのプロセッサから分散リソースのプロセッサに状態情報が送られるだけであるので、プロセッサ間トラフィックを最小化するという望ましい目標を促進し得る。対照的に、非プロキシ型のリソースの場合、分散リソースが状態クエリを受信するたびに状態クエリが送られ、状態情報が返信される。プロキシ型のリソースは、たとえば、第1のプロセッサの制御下で実行されるタスクに最も関係するのが分散リソースの状態であり、対応するネイティブリソースの状態ではない場合に使用され得る。

図5〜図6に関して上記で述べたように、イベントおよびクエリは、ソフトウェアアーキテクチャの関連態様である。しきい値を越える値がないかを監視するタイプのイベントは、プロキシ型のリソースとの組合せにおいて、ネイティブリソースの状態が変化するたびにではなく、ネイティブリソースの状態がしきい値を越えたときにプロセッサ間メッセージが送られるだけであるので、特に有用である。

上記の開示に鑑みて、当業者は、たとえば本明細書のフローチャートおよび関連する説明に基づいて、コンピュータコードを書くか、または適切なハードウェアおよび/または他の論理もしくは回路を特定して、分散リソース管理システムおよび方法を容易に実施することができる。したがって、特定の1組のプログラムコード命令または詳細なハードウェアデバイスの開示が、分散リソース管理システムおよび方法をどのように製作し使用すべきかについて適切に理解するうえで必要であるとは見なされない。コンピュータによって実施される特許請求されるプロセスの発明性のある機能が、上の説明において、および、様々なプロセスの流れを示し得る各図面に関連して、より詳細に説明される。さらに、プロセッサ110、126、202、206などは、メモリ112およびその中に記憶された命令との組合せにおいて、本明細書で説明する方法ステップのうちの1つまたは複数を実行するための手段として働き得る。

1つまたは複数の例示的な態様では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶され、または送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスすることができる任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の光記憶デバイスもしくは磁気記憶デバイス、あるいは、命令またはデータ構造の形式で所望のプログラムコードを搬送または記憶するために使用され得、かつコンピュータによってアクセスされ得る任意の他の媒体を備えることができる。「ディスク(disk)」または「ディスク(disc)」という用語は、本明細書で使用される場合、限定はしないが、コンパクトディスク(disc)(「CD」)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(「DVD」)、フレキシブルディスク(disk)およびブルーレイディスク(disc)を含む。上記の組合せもコンピュータ可読媒体の範囲の中に含まれるべきである。

選択された態様が詳細に示され説明されてきたが、以下の特許請求の範囲によって定義されるような本開示の趣旨および範囲から逸脱することなく、本明細書において様々な置換および改変を実施できることが理解されよう。

100 PCD
101 システム
102 オンチップシステム、リソース電力マネージャ、RPMノード、RPM
110A 中央処理装置(「CPU」)
126 アナログ信号プロセッサ、プロセッサ
132 タッチスクリーンディスプレイ
134 ビデオエンコーダ
136 ビデオ増幅器
138 ビデオポート
140 ユニバーサルシリアルバス(「USB」)コントローラ
142 USBポート
146 加入者識別モジュール(SIM)カード
148 デジタルカメラ
150 ステレオオーディオコーデック
152 オーディオ増幅器
154 第1のステレオスピーカー
156 第2のステレオスピーカー
158 マイクロフォン増幅器
160 マイクロフォン
162 周波数変調(「FM」)無線チューナー
164 FMアンテナ
166 ステレオヘッドフォン
168 高周波(「RF」)トランシーバ
170 RFスイッチ
172 RFアンテナ
174 キーパッド
176 マイクロフォンを備えたモノヘッドセット、モノヘッドセット
178 バイブレータデバイス
180 電源
202 第1のプロセッサ
203 リソース要求
204 電力マネージャリソース、リソース
205 リソース
206 第2のプロセッサ
207 追加リソース
208 スレッド
210 信号
300 遠隔フレームワーク管理プログラム
440 フレームワーク管理プログラム
422 バスアービタまたはスケジューラ
442 クロック
444A バスプログラムA
444B バスプログラムB
448 アクションまたは機能
601 ノード
601A 第1のノード
601B 第2のノード
602 ノード
622 ノード、第2のノード
642 ノード
646 ノード
648 クライアント
675 クライアント要求
675A クライアント要求
680A 従属性矢印
680B 従属性矢印
680C 従属性矢印
680D 従属性矢印
690 イベント
695 照会機能
697 方向矢印

Claims (28)

1. 第1のプロセッサによって制御される第1の複数のリソースおよび第2のプロセッサによって制御される第2の複数のリソースを有するポータブルコンピューティングデバイスにおける分散リソース管理のための方法であって、
   前記第1のプロセッサによって制御される第1のノードをインスタンス化するステップであって、前記第1のノードは、前記第2のプロセッサによって制御される第2のノードに対応し、前記第1の複数のリソースは、第1の無閉路有向グラフによって定義され、前記第2の複数のリソースは、前記第1の無閉路有向グラフとリソースをまったく共有しない第2の無閉路有向グラフによって定義され、前記第1の無閉路有向グラフの各ノードは、前記第1のプロセッサによって制御される1つまたは複数のリソースの機能のカプセル化を表し、前記第1の無閉路有向グラフの各端は、クライアント要求を表し、前記第1の無閉路有向グラフの隣接ノードは、リソース従属性を表し、前記第2の無閉路有向グラフの各ノードは、前記第2のプロセッサによって制御される1つまたは複数のリソースの機能のカプセル化を表し、前記第2の無閉路有向グラフの各端は、クライアント要求を表し、前記第2の無閉路有向グラフの隣接ノードは、リソース従属性を表す、前記インスタンス化するステップと、
   前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対するクライアント要求を受信するステップと、
   前記第1のノードに対する前記クライアント要求に応答して、前記第2のノードに対するクライアント要求を出すステップと
   を含む方法。
2. 前記第1のノードは、プロトコルリソースに従属し、前記第1のノードは、前記プロトコルリソースによって定義されるトランスポートプロトコルを呼び出すドライバを含むようにインスタンス化され、前記ドライバは、前記第2のノードに対する前記クライアント要求を前記トランスポートプロトコルに準拠させる、請求項1に記載の方法。
3. 前記第1のノードは、前記プロトコルリソースがインスタンス化され、前記第2のノードがインスタンス化されるまで、インスタンス化されない、請求項2に記載の方法。
4. 前記第1のノードに対する複数のクライアント要求を受信するステップと、
   前記第1のノードが、前記受信された複数のクライアント要求をアグリゲートして、アグリゲーション結果を提供するステップと
   をさらに含み、
   前記第2のノードに対するクライアント要求を出すステップは、前記アグリゲーション結果に関するクライアント要求を出すステップを含む、請求項1に記載の方法。
5. 前記第1のノードに対する複数のクライアント要求を受信するステップであって、前記第2のノードに対するクライアント要求を出すステップは、前記第1のノードに対して出された前記複数のクライアント要求に対応する前記第2のノードに対する複数のクライアント要求を出すステップを含む、前記複数のクライアント要求を受信するステップと、
   前記第2のノードが、前記第2のノードに対して出された前記複数のクライアント要求をアグリゲートして、アグリゲーション結果を提供するステップと
   をさらに含む、請求項1に記載の方法。
6. 前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対する第1の状態クエリを受信するステップと、
   前記第2のノードに対する第2の状態クエリを出して、前記第2のノードの状態の指示を取得するステップと、
   前記第1のノードが、前記第1の状態クエリに応答して、前記第2のノードの前記状態の前記指示を提供するステップと
   をさらに含む、請求項1に記載の方法。
7. 前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対する第1の状態クエリを受信するステップと、
   前記第1のノードが、前記第1の状態クエリに応答して、前記第1のノードの状態の指示を提供するステップと、
   前記第2のノードの状態の変化を検出するステップと、
   前記第2のノードの状態の変化の検出に応答して、前記第2のノードの前記状態の指示を前記第1のノードに提供するステップと
   をさらに含む、請求項1に記載の方法。
8. 第1のプロセッサによって制御される第1の複数のリソースおよび第2のプロセッサによって制御される第2の複数のリソースを有するポータブルコンピューティングデバイスにおける分散リソース管理のためのコンピュータシステムであって、
   プロセッサを含み、前記プロセッサは、
   前記第1のプロセッサによって制御される第1のノードをインスタンス化するステップであって、前記第1のノードは、前記第2のプロセッサによって制御される第2のノードに対応し、前記第1の複数のリソースは、第1の無閉路有向グラフによって定義され、前記第2の複数のリソースは、前記第1の無閉路有向グラフとリソースをまったく共有しない第2の無閉路有向グラフによって定義され、前記第1の無閉路有向グラフの各ノードは、前記第1のプロセッサによって制御される1つまたは複数のリソースの機能のカプセル化を表し、前記第1の無閉路有向グラフの各端は、クライアント要求を表し、前記第1の無閉路有向グラフの隣接ノードは、リソース従属性を表し、前記第2の無閉路有向グラフの各ノードは、前記第2のプロセッサによって制御される1つまたは複数のリソースの機能のカプセル化を表し、前記第2の無閉路有向グラフの各端は、クライアント要求を表し、前記第2の無閉路有向グラフの隣接ノードは、リソース従属性を表す、前記インスタンス化するステップと、
   前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対するクライアント要求を受信するステップと、
   前記第1のノードに対する前記クライアント要求に応答して、前記第2のノードに対するクライアント要求を出すステップと
   を行うように動作可能である、コンピュータシステム。
9. 前記第1のノードは、プロトコルリソースに従属し、前記第1のノードは、前記プロトコルリソースによって定義されるトランスポートプロトコルを呼び出すドライバを含むようにインスタンス化され、前記ドライバは、前記第2のノードに対する前記クライアント要求を前記トランスポートプロトコルに準拠させる、請求項8に記載のコンピュータシステム。
10. 前記第1のノードは、前記プロトコルリソースがインスタンス化され、前記第2のノードがインスタンス化されるまで、インスタンス化されない、請求項9に記載のコンピュータシステム。
11. 前記プロセッサは、
    前記第1のノードに対する複数のクライアント要求を受信するステップと、
    前記第1のノードが、前記受信された複数のクライアント要求をアグリゲートして、アグリゲーション結果を提供するステップと
    を行うようにさらに動作可能であり、
    前記第2のノードに対するクライアント要求を出すステップは、前記アグリゲーション結果に関するクライアント要求を出すステップを含む、請求項8に記載のコンピュータシステム。
12. 前記プロセッサは、
    前記第1のノードに対する複数のクライアント要求を受信するステップであって、前記第2のノードに対するクライアント要求を出すステップは、前記第1のノードに対して出された前記複数のクライアント要求に対応する前記第2のノードに対する複数のクライアント要求を出すステップを含む、前記複数のクライアント要求を受信するステップと、
    前記第2のノードが、前記第2のノードに対して出された前記複数のクライアント要求をアグリゲートして、アグリゲーション結果を提供するステップと
    を行うようにさらに動作可能である、請求項8に記載のコンピュータシステム。
13. 前記プロセッサは、
    前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対する第1の状態クエリを受信するステップと、
    前記第2のノードに対する第2の状態クエリを出して、前記第2のノードの状態の指示を取得するステップと、
    前記第1のノードが、前記第1の状態クエリに応答して、前記第2のノードの前記状態の前記指示を提供するステップと
    を行うようにさらに動作可能である、請求項8に記載のコンピュータシステム。
14. 前記プロセッサは、
    前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対する第1の状態クエリを受信するステップと、
    前記第1のノードが、前記第1の状態クエリに応答して、前記第1のノードの状態の指示を提供するステップと、
    前記第2のノードの状態の変化を検出するステップと、
    前記第2のノードの状態の変化の検出に応答して、前記第2のノードの前記状態の指示を前記第1のノードに提供するステップと
    を行うようにさらに動作可能である、請求項8に記載のコンピュータシステム。
15. 第1のプロセッサによって制御される第1の複数のリソースおよび第2のプロセッサによって制御される第2の複数のリソースを有するポータブルコンピューティングデバイスにおける分散リソース管理のためのコンピュータシステムであって、
    前記第1のプロセッサによって制御される第1のノードをインスタンス化するための手段であって、前記第1のノードは、前記第2のプロセッサによって制御される第2のノードに対応し、前記第1の複数のリソースは、第1の無閉路有向グラフによって定義され、前記第2の複数のリソースは、前記第1の無閉路有向グラフとリソースをまったく共有しない第2の無閉路有向グラフによって定義され、前記第1の無閉路有向グラフの各ノードは、前記第1のプロセッサによって制御される1つまたは複数のリソースの機能のカプセル化を表し、前記第1の無閉路有向グラフの各端は、クライアント要求を表し、前記第1の無閉路有向グラフの隣接ノードは、リソース従属性を表し、前記第2の無閉路有向グラフの各ノードは、前記第2のプロセッサによって制御される1つまたは複数のリソースの機能のカプセル化を表し、前記第2の無閉路有向グラフの各端は、クライアント要求を表し、前記第2の無閉路有向グラフの隣接ノードは、リソース従属性を表す、前記インスタンス化するための手段と、
    前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対するクライアント要求を受信するための手段と、
    前記第1のノードに対する前記クライアント要求に応答して、前記第2のノードに対するクライアント要求を出すための手段と
    を含むコンピュータシステム。
16. 前記第1のノードは、プロトコルリソースに従属し、前記第1のノードは、前記プロトコルリソースによって定義されるトランスポートプロトコルを呼び出すドライバを含むようにインスタンス化され、前記ドライバは、前記第2のノードに対する前記クライアント要求を前記トランスポートプロトコルに準拠させる、請求項15に記載のコンピュータシステム。
17. 前記第1のノードは、前記プロトコルリソースがインスタンス化され、前記第2のノードがインスタンス化されるまで、インスタンス化されない、請求項16に記載のコンピュータシステム。
18. 前記第1のノードに対する複数のクライアント要求を受信するための手段と、
    前記第1のノードが、前記受信された複数のクライアント要求をアグリゲートして、アグリゲーション結果を提供するための手段と
    をさらに含み、
    前記第2のノードに対するクライアント要求を出すステップは、前記アグリゲーション結果に関するクライアント要求を出すステップを含む、請求項15に記載のコンピュータシステム。
19. 前記第1のノードに対する複数のクライアント要求を受信するための手段であって、前記第2のノードに対するクライアント要求を出すステップは、前記第1のノードに対して出された前記複数のクライアント要求に対応する前記第2のノードに対する複数のクライアント要求を出すステップを含む、前記複数のクライアント要求を受信するための手段と、
    前記第2のノードが、前記第2のノードに対して出された前記複数のクライアント要求をアグリゲートして、アグリゲーション結果を提供するための手段と
    をさらに含む、請求項15に記載のコンピュータシステム。
20. 前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対する第1の状態クエリを受信するための手段と、
    前記第2のノードに対する第2の状態クエリを出して、前記第2のノードの状態の指示を取得するための手段と、
    前記第1のノードが、前記第1の状態クエリに応答して、前記第2のノードの前記状態の前記指示を提供するための手段と
    をさらに含む、請求項15に記載のコンピュータシステム。
21. 前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対する第1の状態クエリを受信するための手段と、
    前記第1のノードが、前記第1の状態クエリに応答して、前記第1のノードの状態の指示を提供するための手段と、
    前記第2のノードの状態の変化を検出するための手段と、
    前記第2のノードの状態の変化の検出に応答して、前記第2のノードの前記状態の指示を前記第1のノードに提供するための手段と
    をさらに含む、請求項15に記載のコンピュータシステム。
22. コンピュータ可読プログラムコードを含むコンピュータプログラムであって、前記コンピュータ可読プログラムコードは、ポータブルコンピューティングデバイスのリソースを管理するための方法を実施するために実行されるように適合され、前記方法は、
    第1のプロセッサによって制御される第1のノードをインスタンス化するステップであって、前記第1のノードは、第2のプロセッサによって制御される第2のノードに対応し、第1の複数のリソースは、第1の無閉路有向グラフによって定義され、第2の複数のリソースは、前記第1の無閉路有向グラフとリソースをまったく共有しない第2の無閉路有向グラフによって定義され、前記第1の無閉路有向グラフの各ノードは、前記第1のプロセッサによって制御される1つまたは複数のリソースの機能のカプセル化を表し、前記第1の無閉路有向グラフの各端は、クライアント要求を表し、前記第1の無閉路有向グラフの隣接ノードは、リソース従属性を表し、前記第2の無閉路有向グラフの各ノードは、前記第2のプロセッサによって制御される1つまたは複数のリソースの機能のカプセル化を表し、前記第2の無閉路有向グラフの各端は、クライアント要求を表し、前記第2の無閉路有向グラフの隣接ノードは、リソース従属性を表す、前記インスタンス化するステップと、
    前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対するクライアント要求を受信するステップと、
    前記第1のノードに対する前記クライアント要求に応答して、前記第2のノードに対するクライアント要求を出すステップと
    を含む、コンピュータプログラム。
23. 前記第1のノードは、プロトコルリソースに従属し、前記第1のノードは、前記プロトコルリソースによって定義されるトランスポートプロトコルを呼び出すドライバを含むようにインスタンス化され、前記ドライバは、前記第2のノードに対する前記クライアント要求を前記トランスポートプロトコルに準拠させる、請求項22に記載のコンピュータプログラム。
24. 前記第1のノードは、前記プロトコルリソースがインスタンス化され、前記第2のノードがインスタンス化されるまで、インスタンス化されない、請求項23に記載のコンピュータプログラム。
25. 前記方法は、
    前記第1のノードに対する複数のクライアント要求を受信するステップと、
    前記第1のノードが、前記受信された複数のクライアント要求をアグリゲートして、アグリゲーション結果を提供するステップと
    をさらに含み、
    前記第2のノードに対するクライアント要求を出すステップは、前記アグリゲーション結果に関するクライアント要求を出すステップを含む、請求項22に記載のコンピュータプログラム。
26. 前記方法は、
    前記第1のノードに対する複数のクライアント要求を受信するステップであって、前記第2のノードに対するクライアント要求を出すステップは、前記第1のノードに対して出された前記複数のクライアント要求に対応する前記第2のノードに対する複数のクライアント要求を出すステップを含む、前記複数のクライアント要求を受信するステップと、
    前記第2のノードが、前記第2のノードに対して出された前記複数のクライアント要求をアグリゲートして、アグリゲーション結果を提供するステップと
    をさらに含む、請求項22に記載のコンピュータプログラム。
27. 前記方法は、
    前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対する第1の状態クエリを受信するステップと、
    前記第2のノードに対する第2の状態クエリを出して、前記第2のノードの状態の指示を取得するステップと、
    前記第1のノードが、前記第1の状態クエリに応答して、前記第2のノードの前記状態の前記指示を提供するステップと
    をさらに含む、請求項22に記載のコンピュータプログラム。
28. 前記方法は、
    前記第1のプロセッサの制御下にあるクライアントから、前記第1のノードに対する第1の状態クエリを受信するステップと、
    前記第1のノードが、前記第1の状態クエリに応答して、前記第1のノードの状態の指示を提供するステップと、
    前記第2のノードの状態の変化を検出するステップと、
    前記第2のノードの状態の変化の検出に応答して、前記第2のノードの前記状態の指示を前記第1のノードに提供するステップと
    をさらに含む、請求項22に記載のコンピュータプログラム。

Images