JP5065566B2 - リソースマネージャアーキテクチャ - Google Patents

Description

【０００１】
(技術分野)
本発明はコンピュータに関し、より詳細には、コンピュータのリソースを管理するためのシステムおよび方法に関する。
【０００２】
(発明の背景)
コンピュータは、その従来のデスクトップルーツをはるかに超えて進化している。今日のパーソナルコンピュータ(PC)には、従来のデスクトップアプリケーション(例えばワードプロセッシング、表計算、電子メールなど)に加えて、オーディオビデオファイルの再生、音楽CD(コンパクトディスク)の再生、ブロードキャスト番組の受信および表示などが求められている。この進化の多くの部分は、計算、インターネット、テレフォニー、および娯楽の技術が不断に収束することによって促進されている。
【０００３】
この結果、コンピュータのルック、フィール、および機能は、様々な消費者環境および動作環境に向けて進化し続けている。例えば、家庭娯楽向けに設計されるコンピュータは、ブラウザソフトウェア、１つ以上のチューナ、EPG(電子番組ガイド)ソフトウェア、種々のオーディオ/ビデオドライバ、ゲーミングソフトウェアを搭載した、セットトップボックスまたはゲームコンソールとして実現することができる。オフィス向けに設計されるコンピュータは、従来のデスクトップPCに似た外観とすることができるが、より向上したコンピューティング体験を提供するために、ブロードキャストチューナ、DVD(ディジタルビデオディスク)ドライバ、サラウンドサウンド付きステレオスピーカなどが付属したものとすることができる。携帯型コンピュータの多様性および機能は、移動ユーザの需要が増加するのに伴って一層広い範囲に及んでいる。
【０００４】
より多様なタスクを実行することがコンピュータに求められている中で、ユーザが複数タスクの同時実施を期待するのは珍しいことではない。このユーザ需要の増加により、様々なタスクに対処するために既存のリソースに対してより多くの需要が生じている。残念ながら、このことにより、すべてのタスクを同時に達成するのに十分なリソースを要求時にコンピュータが備えていない可能性がより高くなる。
【０００５】
このリソース不足はおそらく、家庭娯楽環境向けに設計されたコンピュータの場合に最も明白である。このようなコンピュータは、複数の機能を同時に実施できなければならないだけでなく、異なる複数のユーザの要求も満たさなければならない。例えば、あるユーザは、娯楽コンピュータが指定時間にある番組を録画するように要求し、別のユーザは、コンピュータが同じ時間に異なる番組に合わせるように要求する。コンピュータにチューナが1つしかない場合、両方のタスクを同時に達成することはどうしてもできないので、これは問題である。
【０００６】
このような状況では、コンピュータは、どのタスクを実施すべきであってどのタスクを実施すべきでないかの識別に窮する。今日、アプリケーションは、先着順または遅い順にリソースを得る。したがってアプリケーションは、ユーザの希望に関係なくリソース割振りを制御する。先の例で、テレビジョンアプリケーションがレコーダアプリケーションに勝ってチューナ制御権を握った場合、ユーザが第2の番組を見ることよりも第1の番組を録画することの方にずっと興味があるかもしれなくても、テレビジョンアプリケーションがリソース(すなわちチューナ)を制御することになる。アプリケーションがリソースを得ると、リソースは、アプリケーションが明示的に明け渡すまでアプリケーションによって保持される。
【０００７】
したがって、リソースに対する需要が増加し続けるのに伴い、リソースと、異なるユーザ/アプリケーションへのリソース割振りとを管理する技術に対する必要がより高まっている。
【０００８】
(発明の概要)
リソースを管理するためにコンピュータシステム中で実現されるリソース管理アーキテクチャについて述べる。
【０００９】
説明する実装形態では、一般的なアーキテクチャは、リソースマネージャと、システムコンポーネントやアプリケーションなどの１つ以上のリソースコンシューマをサポートする複数のリソースプロバイダとを含む。各プロバイダは1つのリソースに関連し、リソースマネージャとインタフェースしているときにこのリソースのためのマネージャとして行動する。リソースマネージャは、コンシューマのために、リソースプロバイダから提供されるリソースへのアクセスを調停する。
【００１０】
このアーキテクチャには、リソースマネージャがリソースを割り振るのに使用する様々なポリシーを設定するためのポリシーマネージャを任意選択で含めることができる。リソースマネージャが使用することのできるポリシーの1つは、どのアプリケーションおよび/またはユーザが他を制してリソース使用の優先度を有するかを決定するための、優先度に基づくポリシーである。
【００１１】
説明する実施形態では、各リソースプロバイダはリソースマネージャに登録する。リソースコンシューマは、リソースマネージャに「アクティビティ」を生み出し、アクティビティを実施するのに必要な様々なリソースセットを記述する１つ以上の「構成」を構築する。アクティビティは、構成を保持するコンテナデータ構造（container data structure）として実装され、各構成は、リソースの識別を含むデータ構造として実装される。リソースマネージャは、アクティビティおよび構成を維持する。
【００１２】
説明する実施形態では、各リソースコンシューマは、各アクティビティにつき１つ以上の構成を指定することができる。複数の構成を指定する場合、リソースコンシューマは、好ましさ（preference）に従ってこれらをランク付けすることができる。これにより、動作条件の変化に応じて、リソースコンシューマをある構成から別の構成に動的に変更することができる。一態様では、優先度のより高いリソースコンシューマがどこかで必要としているリソースがある場合に、現在のリソースコンシューマに、より好ましくない構成を使用するように求めるか、あるいはそのリソース構成をすべて放棄するか必要とされる特定のリソースを放棄するように求めることにより、このリソースを確保することができる。後でこれらのリソースが再び利用可能になったときは、リソースマネージャはリソースコンシューマに通知することができ、したがってリソースコンシューマは、好ましい構成にアップグレードするように要求することができる。
【００１３】
一実施形態では、リソースマネージャは、一組のアプリケーションプログラムインタフェース(API)を公開する。リソースコンシューマおよびリソースプロバイダは、APIを使用して、リソースマネージャと通信し、リソースの登録、アクティビティの生成、構成の構築などの機能を実施する。
【００１４】
一実施形態では、リソースコンシューマは、リソースのうち、リソースコンシューマがタスクを実施するのに必要なリソースのサブセット(したがってそれらのリソースプロバイダ)だけしか意識しない。これらのリソースは、タスクを実施するためにリソースコンシューマの知らない他のリソースに依拠することもある。リソースプロバイダは、呼出しを受け取って構成を構築するように構成されている。リソースコンシューマが知っているリソースプロバイダは、リソースコンシューマから直接呼び出される。リソースコンシューマが知らないリソースプロバイダは、それらのリソースを使用するリソースプロバイダから呼び出される。
【００１５】
一実施形態では、リソースプロバイダが呼び出されたとき、リソースプロバイダは、リソースマネージャが１つ以上の構成を管理することを可能にする情報をリソースマネージャに提供する。ある特定の実装形態は、種々のリソースプロバイダ間のリソース従属関係を記述する階層ツリー構成である。この構成は階層的な性質を有するので、リソース予約およびリソースコンシューマへのエラー報告が容易である。
【００１６】
一実施形態では、リソース予約が失敗したとき、またはプリエンプト(preemption)が行われたとき、エラー通知が生成される。この構成は階層的な性質を有するので、リソースコンシューマに知られているリソースプロバイダが見つかるまで各従属リソースプロバイダの親を辿っていくことにより、エラー報告はより効率的になる。次いで、この知られているリソースプロバイダは、リソースコンシューマに理解される用語で、エラーをリソースコンシューマに明確に伝えることができる。報告は様々な形をとることができる。例えば、報告は、要求された既知のリソースが利用不可能であることを知らせる単純な通知としてもよい。報告はまた、リソースコンシューマに種々のオプション(例えばタスクを実施するのに使用する代替リソース設定)を提示するものとしてもよい。
【００１７】
説明する実施形態の一態様は、リソースコンシューマにエラーを報告するのではなく、リソースプロバイダのレベルでエラーを修復することを試みる、トラブルシューティング機能を提供する。
【００１８】
一実施形態では、どのリソースが必要かをリソースコンシューマが知らなくてもいいようにリソースコンシューマのためにリソースマネージャとインタフェースするための、インテリジェントインタフェースコンポーネントが提供される。このインタフェースコンポーネントは、あるアクティビティにどのリソースが必要かを理解するように設計されている。インテリジェントインタフェースコンポーネントは、リソースコンシューマからの呼出しを受け取って特定の構成を構築することのできるプロキシリソースコンシューマとして行動する。この場合、インテリジェントインタフェースコンポーネントは、構成を構築してリソースの予約を要求するために、リソースマネージャと対話する。
【００１９】
一実施形態では、いわゆる「ステートレス」プロバイダを採用する。ステートレスプロバイダは、そのプロバイダが管理するリソースについてさえ、リソース割振りまたは所有権の情報を維持しないように設計されている。具体的には、かつ述べる実施形態では、ステートレスプロバイダは時間の概念、すなわち今要求されているのか将来要求されるのかについての概念を有さず、所与の要求があった時にどのリソースがどれだけ使用されているかについての概念しか有さない。別個のスケジューリングコンポーネントが、「もしも」シナリオを実行して、将来の選択された時にリソースが利用可能になるどうかを決定する。
【００２０】
各図面を通して、同じ要素および機構を参照するのには同じ番号を使用する。
【００２１】
(好ましい実施形態の簡単な説明)
本開示は、コンピュータシステム中のリソースを管理するためのリソース管理アーキテクチャについて述べるものである。リソースは、様々なタスクまたは機能を実施するために利用される、コンピュータシステム中の限りある量のコンピューティングコンポーネントである。リソースの例には、ハードウェアデバイス、ポート、CPU処理、メモリ、USB帯域幅、ネットワーク帯域幅、ソフトウェアモジュールなどが含まれる。リソースは、物理的ハードウェア量(例えばCPU、USB帯域幅、ネットワーク帯域幅)である場合もあり、抽象的な量(例えば仮想メモリ、オーディオ音量)である場合もある。
【００２２】
より多くのタスクを同時にかつ複数ユーザに対して実施することがコンピュータシステムに求められるのに伴い、限られたリソースの管理はますます重要になっている。例えば、単一のTVチューナを有するTV対応コンピューティングシステム(例えばブロードキャストPC、セットトップボックスなど)を考えてみる。処理を行うためにTVチューナを使用することの必要なプロセスが複数ある場合がある。例えば、TVビューアアプリケーションは、モニタ上に表示するビデオストリームをTVチューナから提供してもらう必要がある。TVレコーダアプリケーションもまた、後で再生する目的でエンコードしてハードディスクに録画するビデオストリームをTVチューナから提供してもらう必要がある。残念ながら、TVチューナは一度に1つのTVチャネルにしか合わせることができない。システム中にTVチューナが1つしかない場合、システムは、ショーの視聴とショーの録画との両方を同時に行うことができないので(両方のアプリケーションが同じTVチャネルに合わせたいのでない限り)、これらの間で選択を迫られる。
【００２３】
別の状況では、おそらく複数のアプリケーションがユニバーサルシリアルバス(USB)上の帯域幅を同時に必要とする。あるアプリケーションは、存在するUSB帯域幅の20%を消費する帯域幅要件を指定し、別のアプリケーションは15%を消費する帯域幅を指定することがある。さらに、すべての要件が満たされるとすると、合わせた帯域幅が、利用可能なUSB帯域幅を超過することになると仮定する。このシナリオでは、１つ以上のアプリケーションは、USBリソースへのアクセスを得ることができない恐れがあり、かつ/または要求した量よりも少ない量が割り振られる恐れがある。
【００２４】
本明細書で説明するリソース管理アーキテクチャの様々な実施形態は、特徴の中でもとりわけ、以下のような特性を有する。
【００２５】
・相対的な優先度に基づいて(最終的にはエンドユーザ定義のポリシーによって設定されたように)リソースを割り振る。
・リソースの割振りおよび割振り解除を動的に行う。
・優先度のより高いリソースコンシューマに再割当てすることを優先して、優先度のより低いコンシューマにリソースの返還を要求することができるようにする。
・追加のリソースが利用可能になったときにコンシューマに自動通知を提供する。
・リソースを動的に追加(登録)および除去(登録解除)できるようにする。
・リソース競合を詳細に報告するための機構を提供する。
・複数のリソースを自動的に獲得できるようにする。
・アクティビティの優先度を動的に変更できるようにする。
・リソース構成のランク付けを動的に変更できるようにする。
・リソースが公開されるように任意の第三者がリソースを登録することのできるフレームワークを提供する。
・コンシューマとリソースの任意の対がそれらに固有のプロパティを交渉することのできるリソース不可知フレームワークを提供する。
・リソース使用に実際に必要になる前にリソース割振りを行うことができるようにする(リソーススケジューリング)。
・コンシューマが最初にリソースを予約せずにリソースを使用することができないようにする機構を提供する。
・コンシューマがある範囲の構成を指定し、それらを最も望ましいものから最も望ましくないものまでランク付けすることができるようにする。
・プロセスがリソースを保持しながら異常終了したときにリソースを自動的に解放し、それによってリソースリークを防止するための機構を提供する。
・レガシーアプリケーションがリソース管理アーキテクチャと共存できるようにする。
【００２６】
このリソース管理アーキテクチャは、多くの様々な環境およびコンピューティングコンテキストで実現することができる。考察のために、このアーキテクチャは、ブロードキャスト対応パーソナルコンピュータ、セットトップボックス(STB)、ゲームコンソールなどの形をとる場合のある、消費者娯楽環境向けのコンピューティングシステムのコンテキストで述べる。リソースマネージャアーキテクチャを実現するのに適したシステムの1つについて述べた後、「一般的なリソース管理アーキテクチャ」の項目で、図2を参照しながらこのアーキテクチャについてより詳細に探求する。
【００２７】
（例示的なシステム）
図1に、コンピューティングユニット22と、コンピューティングユニット22と接続するか他の方法でインタフェースする複数の周辺コンポーネントとを有する娯楽コンピューティングシステム20を示す。コンピューティングユニット22は、１つ以上のプロセッサ24(1)、24(2)、...、24(P)、揮発性メモリ26(例えばRAM)、および不揮発性メモリ28(例えばROM、フラッシュ、ハードディスク、CD ROMなど)を有する。
【００２８】
不揮発性メモリ28には、オペレーティングシステム30が記憶されている。オペレーティングシステム30はマルチタスキングオペレーティングシステムであり、揮発性メモリ26にロードされて１つ以上のプロセッサ24上で実行されるとき、複数のアプリケーション32(1)、32(2)、...、32(A)の同時実行をサポートする。好ましいオペレーティングシステムの1つは、本出願人から発売されているWindows(登録商標)ブランドのオペレーティングシステムである。ただし、他のオペレーティングシステムを採用してもよいことに留意されたい。
【００２９】
アプリケーション32(1)-32(A)は、娯楽コンピューティングシステム20上で実行することのできる多くの様々なタイプのアプリケーションプログラムを表す。例として、EPG(電子番組ガイド)プログラム、ブラウザ、チャネルナビゲーション、オーディオビデオプレーヤ、オーディオ/ビデオ記録プログラム、ステレオプログラム、ゲーム、オーディオ/ビデオ遠隔会議などが含まれる。図では、ソフトウェアデコーダ34(例えばMPEGソフトウェアデコーダ)およびその他のソフトウェアリソース36も不揮発性メモリ28に記憶されている。
【００３０】
オペレーティングシステム30は、アプリケーション32(1)-32(A)に割り振るために娯楽コンピューティングシステム20のリソースを管理するリソース管理システム40を有する。リソース管理システム40は、オペレーティングシステム30とは別に実装することもできるが、オペレーティングシステム内に統合されたものとして示す。リソース管理システム40については、後で図2を参照しながらより詳細に述べる。
【００３１】
オペレーティングシステム30はまた、コンピューティングシステム20中の関連する様々な周辺コンポーネントのための複数のソフトウェアドライバ42(1)、...、42(D)も有する。１つ以上のCOM(通信)ポート44もまた、オペレーティングシステム30の一部として示されている。コンピューティングユニット22を囲んで、周辺コンポーネントの代表的な集合が示されている。娯楽コンピューティングシステム20は、テレビジョン番組などのブロードキャストデータを受信するための１つ以上の受信機50を有する。受信機50は、アナログテレビジョン受信機、ディジタルテレビジョン受信機(例えば衛星放送受信アンテナやケーブルモデム)、RF受信機などとすることができる。受信機50は、データを搬送する搬送波信号の周波数に同調する１つ以上のチューナ52(1)-52(T)に結合される。
【００３２】
コンピューティングユニット22には、USBバス54が接続されて、多くの様々な種類のUSB適合周辺コンポーネントをインタフェースする。このようなコンポーネントの例には、モデム56、スピーカ58、スチルカメラまたはビデオカメラ60、およびその他のUSBデバイス62が含まれる。
【００３３】
コンピューティングユニット22には、１つ以上のハードウェアデコーダ64(1)、64(2)、...、64(H)が結合されて、様々なタイプのデータストリームをデコードする。例示的なデコーダには、MPEG-1、MPEG-2、MPEG-4、H.261、H.263などの規格を用いるビデオデコーダや、オーディオデコーダが含まれる。
【００３４】
コンピューティングユニット22は、ネットワーク66に結合されて、他のコンピュータとインタフェースする。ネットワーク66は、LAN、WAN、インターネット、イントラネット、無線ネットワークを含めた、多くの様々なタイプのネットワークを表す。リソース管理システム40によって管理されるリソースの1つは、所与の時にネットワーク66から提供される帯域幅である。
【００３５】
コンピューティングユニット22には、1394シリアルバス68が接続されて、多くの様々な種類の1394適合周辺コンポーネントをインタフェースする。このようなコンポーネントの例には、メモリドライブ70(例えばディスクドライブ、テープドライブ、CD ROMドライブなど)、モデム72、スピーカ74、CPU(中央処理装置)76、およびその他の1394デバイス78が含まれる。この例示的なシステム中にはUSBバスおよび1394バスを示すが、SCSI、ISA(Industry Standard Architecture)、PCI(Peripheral Component Interconnect)バスなど、他のバスアーキテクチャを追加でまたは代替で使用することもできることに留意されたい。
【００３６】
娯楽コンピューティングシステム20は、表示装置80を有するが、これはテレビジョンセットまたはコンピュータモニタとすることができる。表示装置は、１つ以上の表示インタフェース82(1)、82(2)、...、82(C)を介してコンピューティングユニット22とインタフェースされる。これらの表示インタフェースは、ビデオポート、オーバーレイ、およびビデオメモリを表す。
【００３７】
コンピューティングデバイス22に結合されるその他の例示的な周辺デバイスには、DVDプレーヤ84、EPGデータベース86、およびビデオレコーダ88が含まれる。EPGデータベース86は、EPGユーザインタフェース(UI)のタイルを埋める番組情報を保持する。番組情報は、番組タイトル、開始時間、継続時間、男優/女優、要約記述などの項目を含む。EPG情報は、通常の手段を介して(例えばケーブルモデムを介して、または垂直帰線消去期間内に埋め込まれて)受信され、EPGデータベース86に記憶される。コンピューティングユニット22は、EPGデータベースに対して照会を実行して、ショーまたはその他の番組コンテンツを突き止め、この情報をグラフィカルUI中でユーザに提示する。
【００３８】
ビデオレコーダ88は、ビデオカセットレコーダやディスクベースのレコーダなどの形とすることができる。コンピューティングユニット22は、チューナ52またはネットワーク66を介して受信された様々な番組を録画するようにビデオレコーダ88に指示することができる。
【００３９】
さらに、娯楽に焦点を合わせた前述のコンポーネントに加えて、コンピューティングシステム20は、コンピュータになじみの深い通常のデスクトップアプリケーションを実施できる完全に機能するコンピュータとして構成することができることにも留意されたい。システム上では、ワードプロセッシングアプリケーション、表計算アプリケーション、データベースアプリケーション、スケジューリングアプリケーション、財務アプリケーション、教育アプリケーションなど、様々なアプリケーションをロードして実行することができる。
【００４０】
図1に示すコンポーネントの集合は、リソース管理システム40によって管理される例示的なリソースのタイプを示している。これらの中には、ポート、チューナ、デコーダ、USBバス上のUSB帯域幅およびUSBデバイス、ネットワーク帯域幅、1394デバイス、表示インタフェース、レコーダ、メモリドライブなどがある。その他の多くのコンポーネントをシステムに追加することもでき、図示のコンポーネントの１つ以上を除去することもできる。
【００４１】
（一般的なリソース管理アーキテクチャ）
図2に、図1の娯楽コンピューティングシステム20によって実現される例示的なリソース管理アーキテクチャ100を示す。アーキテクチャ100はソフトウェア中で実現され、この例では、ユーザレベルのコンポーネントならびにカーネルレベルのコンポーネントを含む。
【００４２】
アーキテクチャ100は、リソースマネージャ102および複数のプロバイダ104(1)、104(2)、104(3)、...、104(P)を有し、プロバイダは１つ以上のリソースコンシューマをサポートする。リソースコンシューマの例には、アプリケーション32(1)、32(2)、...、32(A)などユーザレベルのリソースコンシューマと、リソースコンシューマ35などカーネルレベルのリソースコンシューマが含まれる。各プロバイダ104(1)-104(P)は、1つのリソースに関連し、リソースの可用性を追跡している。前述のようにリソースは、様々なタスクまたは機能を実施するのに利用される、コンピュータシステム中の限りある量のコンピューティングコンポーネントである。したがって、リソースプロバイダの例には、ハードウェアデバイスを所有するドライバ(例えばTVチューナのためのドライバ、バス上の帯域幅を所有するUSBドライバ、CPUタイムリソースのためのCPUスケジューラなど)、ハードウェアコンポーネント(例えばデコーダ)、およびソフトウェアモジュール(例えばソフトウェアデコーダ)が含まれる。さらに、単一のドライバが複数のリソースを提供する場合があることにも留意されたい。この場合、リソースマネージャ102はこのドライバを複数のプロバイダと見なす。リソースプロバイダをカーネルレベルに示すが、１つ以上のリソースプロバイダをユーザレベルに実装することもできる。
【００４３】
各プロバイダ104は、リソースマネージャ102による割振りに利用可能なリソースの量を決定するリソース定量化部（resource quantifier）106を有する。リソース定量化部106は、所与のリソースの量がどのように測定されるかに応じて、種々の方式で可用性を計算するように構成される。ある方式は、有限のカウントを維持するものである。例えば、同調リソースのプロバイダに対するリソース定量化部106は、いくつのチューナが使用可能状態かを識別するカウンタとして実装することができる。
【００４４】
リソース可用性を計算するための別の方式は、パーセンテージとして計算するものである。ネットワークリソースのプロバイダに対するリソース定量化部106は、現在利用可能な帯域幅のパーセンテージを計算するように実装することができる。時間ベースのメトリックを使用してリソース可用性を計算することもできる。このメトリックの例は、CPUが現在どれだけの処理時間を提供できるかを識別する、CPUに対するリソース定量化部である。所与のリソースの可用性を計算するための他の方式を用いることも、当然可能である。
【００４５】
各リソースプロバイダ104はリソースマネージャ102に登録し、リソースマネージャ102が情報を得るのに使用するコールバックのセットを供給する。例えば、あるコールバックはリソース計算を実施するのに使用され、別のコールバックは予約の成功をプロバイダに通知するのに使用される。
【００４６】
リソースマネージャ102は、リソースプロバイダ104から提供されるリソース(ローカルまたはリモート)へのアクセスを調停する。アプリケーション32などのリソースコンシューマは、プロバイダ104から提供される１つ以上のリソースのセットを要求し、リソースマネージャ102は、どのアプリケーションがプロバイダのどのリソースを使用することになるかを決定する。リソースマネージャ102は、所定の競合解決機構に基づいてリソース割振り決定を行う。一実装形態では、競合解決機構は優先度ベースであり、したがってリソースマネージャ102は、優先度に基づいてリソースへのアクセスを調停する。別の実装形態では、競合解決機構は、所与の時に続行できるアクティビティの数を最大限にするように試みる負荷平衡に基づくものとすることができる。
【００４７】
別個かつ独立のポリシーマネージャ108を任意選択で実装して、リソースマネージャによって使用される競合解決機構に関するポリシーを設定することができる。例えば、リソースマネージャが優先度ベースの解決を採用している場合、ポリシーマネージャ108は、すべてのタスクにそれらのリソースを割り振ることができないような競合があるときに、どのタスクがリソースへのアクセスを得るべきかをリソースマネージャが決定できるように、ユーザまたはシステムによって与えられる相対的な重要度に従ってタスクをプリオリ（priori）にランク付けする。その他の実行可能なポリシーには、先着予約順、一番最近の予約順、リソースの「公平」共用、どれがどれに勝つかをユーザが選ぶポリシーなどが含まれる。多くの様々なポリシーが可能である。
【００４８】
システムまたはユーザがポリシー110を設定し、ポリシーマネージャ108がこれらを絶対的な優先度に変換する。リソースマネージャ108は、ユーザレベルとカーネルレベルの両方のコンポーネントによって実装することができる。
【００４９】
概して言えば、リソースコンシューマは、タスクを実施するためにリソースを必要とする任意のエンティティである。前述のように、アプリケーション32はリソースコンシューマの一例である。別の例として、リソースプロバイダ自体が他のリソースのコンシューマである場合もある。考察のために、アプリケーションを1次コンシューマとし、したがってこの記述では、アプリケーション32がリソースを要求および消費するものとして参照する。ただし、他のタイプのコンシューマを利用することもできるので、このことはこのアーキテクチャを限定するものと考えるべきではない。
【００５０】
リソースマネージャ102は、アーキテクチャ中の他のモジュールと対話するために、定義済みのAPI(アプリケーションプログラムインタフェース)120を公開する。API120は、プロバイダ104によって使用されるプロバイダAPI呼出しのセットと、アプリケーション32(1)-32(A)または他のリソースコンシューマからのリソース要求を受け入れるためのコンシューマAPI呼出しのセットとを含む。後の「リソースマネージャAPI」の項目で、APIの1つについて詳細に述べる。
【００５１】
アプリケーション32がタスクを実施したいとき、アプリケーション32は、API120を使用してリソースマネージャ102にアクティビティ122を生み出し、このアクティビティを実施するのに必要な様々なリソースセットを記述する１つ以上の構成124を構築する。アクティビティは、システム中で実施されるタスクに関連するデータ構造である。実施されるタスク1つにつき1つのアクティビティが存在する。図2では、リソースマネージャ102にアクティビティ122(1)、...、122(N)が示されている。リソースマネージャ102は、限られたリソースのプールからどのアクティビティを完全に満たすことができるかを決定し、満たすことのできるアクティビティを有するアプリケーションが要求のリソースにアクセスできるようにする。
【００５２】
構成は、システム中でタスクを実施するのに必要な対応するリソースに関する１つ以上のリソース記述子126の集合を保持するデータ構造である。アクティビティデータ構造は、１つ以上の構成を保持するコンテナである。図2では、第1のアクティビティ122(1)内に2つの構成124(1)および124(2)が示されている。第1の構成124(1)は、タスクを実施するのに必要なリソースを制御する対応するリソースプロバイダを識別するとともにこれらの必要なリソースの量を指定するための、4つの記述子R₁、R₂、R₃、R₄を含む。第2の構成124(2)は、タスクを実施するのに必要なリソースを制御する対応するリソースプロバイダを識別するとともにこれらの必要なリソースの量を指定するための、3つの記述子R₂、R₄、R₅を含む。アクティビティ122(1)は、構成124のいずれか一方を使用して、そのタスクを首尾よく完了することができる。
【００５３】
各リソース記述子126は、リソースコンシューマがタスクを実施するのに必要とするリソースのインスタンスを表す。リソース記述子は次の情報を含む。すなわち、(1)リソースを所有するリソースプロバイダ104の識別を保持するための識別フィールド128、(2)その構成に必要なリソースの量を保持するためのオプションの量フィールド130、および(3)１つ以上のリソース属性をリストするための属性フィールド132である。フィールド130に保持される量は、リソースマネージャには不明瞭であり、プロバイダおよびコンシューマだけに理解されればよい値である。同様に、属性も、プロバイダおよびコンシューマだけは理解するがリソースマネージャには不明瞭な、他のデータである。例えばチューナのコンテキストでは、リソース属性は、リソースコンシューマが欲するチューナ周波数とすることができる。
【００５４】
アクティビティ122(1)に対する2つの構成124(1)および124(2)で示すように、各アプリケーションは、各アクティビティにつき１つ以上の構成を指定する場合がある。構成は、アクティビティにリソースが予約されているかどうかに関わらず、いつでもアクティビティに追加することができる。複数の構成を指定する場合、アプリケーションは、好ましさまたは望ましさのレベルに従ってこれらをランク付けし、リソースマネージャ102は、最も望ましい構成を満たそうと試みる。ここで、第1の構成124(1)は、「H」で示すように、より好ましいか、望ましさがより高いものとして識別されている。第2の構成124(2)は、「L」で示すように、より好ましくないか、望ましさがより低いものとして識別されている。
【００５５】
複数の構成があることにより、リソースマネージャ102は、動作条件の変化に伴い、アプリケーションについてある構成から別の構成にフレキシブルかつ動的に変更することができる。例えば、リソースが優先度のより高いアプリケーションによってどこかで必要とされている場合、現在のアプリケーションに、より好ましくないまたは「フォールバック」構成を使用するように求めることができ、それにより、必要とされるリソースを優先度のより高いアプリケーションに再割振りすることができる。後でこれらのリソースが再び利用可能になったときは、リソースマネージャ102はアプリケーションに通知することができ、したがってアプリケーションは、好ましい構成にアップグレードするように要求することができる。動的にフォールバック構成に変更し、より優先的な構成にアップグレードすることについては、後で「フォールバック構成」および「アップグレード通知」の項目でより詳細に述べる。
【００５６】
リソース記述子126は、ツリーに編成して、リソース間に内在する任意の依存を表すことができる。すなわち、リソースプロバイダもまた、他のプロバイダからのリソースを消費する。例えばUSBカメラドライバは、カメラリソースのプロバイダであり、USBバスドライバから提供される帯域幅のコンシューマである。このような関係を、リソース記述子のツリーとして表す。
【００５７】
ツリーの比喩では、構成124を記述子ツリーのルートと考えることができる。図2では、ツリーに編成された4つのリソース記述子126が第1の構成124(1)中にある。ツリーは、並んだ2つの兄弟ノードR₂およびR₄を含み、対応するリソースプロバイダから提供されるリソースが両方とも要求のタスクの実施に必要であることを表す。記述子R₄から子ノードR₃が分岐し、R₄で参照されるプロバイダが記述子R₃で参照されるリソースのコンシューマであることを示す。同様に、記述子R₃からノードR₁が分岐し、R₃で参照されるプロバイダが記述子R₁で参照されるリソースのコンシューマであることを示す。
【００５８】
（一般的な動作）
図3に、述べた実施形態によるリソース管理アーキテクチャ100の一般的な動作を示す。このプロセスはソフトウェア中で実施されるものであり、このプロセスについて図2をさらに参照しながら述べる。
【００５９】
ステップ300で、各リソースプロバイダ104(1)-104(P)は、それが管理するリソースをリソースマネージャ102に登録する。登録(および登録解除)はいつでも行うことができる。各リソースプロバイダ104は、リソースマネージャAPI120中の関数呼出し「RmRegisterResource」を使用して、そのリソースをリソースマネージャ102に登録する。各リソースには、リソースのタイプを識別するためのタイプ特有GUID(Globally Unique IDentifier)が関連し、このGUIDが関数呼出しの一部として渡される。単一のプロバイダ104が複数のタイプを登録することができる。同様に、複数のプロバイダが同じリソースタイプに登録することもできる。
【００６０】
登録プロセスの一部として、リソースプロバイダ104は、リソースマネージャ102がコンシューマのためにリソースを予約および解放するのに使用することになるコールバックのセットを指定する。RmRegisterResourceプロセスは、リソースマネージャへの他の呼出しで使用されることになるハンドルを返す。
【００６１】
アーキテクチャ100によれば、コンシューマは、リソースを予約および解放するためだけにリソースマネージャ102を経由する。他の場合は、コンシューマはリソースプロバイダ104に直接アクセスして、適切なリソース記述子を構成に追加し、リソースが予約されればそれらのリソースを使用する。これについては後でより詳細に述べる。
【００６２】
ステップ302で、リソースコンシューマは、１つ以上の関連するタスクを実施するために１つ以上のアクティビティを生み出す。例として、アプリケーション32(1)がアクティビティ122(1)をリソースマネージャ102中に生み出すものとする。アプリケーション32(1)は、関数呼出し「RmCreateActivity」を使用してアクティビティをリソースマネージャ102に登録する。このプロセスは、アクティビティ122(1)を形成するコンテナデータ構造を生み出し、アクティビティ122(1)についてのアクティビティハンドルを生成する。
【００６３】
ステップ304で、リソースコンシューマは、各アクティビティ内に１つ以上の構成を構築する。複数の構成を指定する場合、リソースコンシューマは、アクティビティ内の各構成を、このアクティビティの範囲内で望ましさからみてランク付けする。図2の例では、アプリケーション32(1)は、関数呼出し「RmCreateConfiguration」を使用して、第1のアクティビティ122(1)内に少なくとも2つの構成124(1)および124(2)を構築する。このプロセスは、構成構造124(1)および124(2)へのハンドルを生成する。
【００６４】
構成124を生み出すと、リソースコンシューマは、関連するプロバイダを介してリソース記述子を構成に加えることを開始する(図3のステップ306)。例えば図2では、アプリケーション32(1)は、対応するリソースプロバイダ104を使用してR₂やR₄などの記述子を第1の構成124(1)に加えることを開始する。プロバイダ104は、リソースマネージャAPIからの関数呼出し「RmAddResourceToConfiguration」を利用して、記述子を構成に加える。記述子126を加えるとき、それらに対応するリソースプロバイダ104は、他のプロバイダ(通常はスタック中のより低いプロバイダ)を呼び出して、従属するリソース記述子を加えることができる。ここでは、記述子R₄で識別されるリソースプロバイダが、記述子R₃で識別されるリソースプロバイダを呼び出し、この記述子R₃で識別されるリソースプロバイダは、記述子R₁で識別されるリソースプロバイダを呼び出す。
【００６５】
ステップ308で、コンシューマはリソースマネージャと接触して、アクティビティのためのリソースを予約する。リソースマネージャは、リソースプロバイダと接触し、リソースが利用可能ならコンシューマのためにリソースを予約する。リソースマネージャは、記述子構成ツリー内で識別されるあらゆるリソースを予約することを試みる。リソースが利用可能でない場合、リソースマネージャはアクティビティ間で調停し、どのコンシューマにリソースへのアクセスを与えるかについての競合を解決する。コンシューマは、割り振られた量のリソースを、自発的に放棄するまで、またはリソースマネージャによってプリエンプトされるまで利用することができる。
【００６６】
予約および調停ステップ308の一実装形態を、サブステップ320-330に示す。ステップ320で、コンシューマが、アクティビティ122内のどの構成124を予約するかを指定する。構成を指定しない場合、リソースマネージャ102は、望ましい順に構成の予約を試みる。引き続き用いる例では、アプリケーション32(1)は、関数呼出し「RmReserveResources」を使用して、好ましい構成124(1)内で指定されるリソースを予約するようにリソースマネージャ102に指示する。この構成124(1)は、記述子R₁、R₂、R₃、R₄で識別されるプロバイダからのリソースを必要とする。
【００６７】
ステップ322で、リソースマネージャ102は、構成内の各リソース記述子126につき、対応するリソースプロバイダ104を識別し、システム中で現在そのリソースプロバイダからのリソースを使用しているアクティビティ122すべてのリストを作成する。予約することになるアクティビティ122(1)も、このリストに加える。リソースマネージャ102は、プロバイダから供給された「リソース割振り」関数を使用して、リストしたアクティビティ内のすべての記述子にリソースを割り当てる(ステップ324)。優先度ベースの手法では、リスト中のアクティビティには優先度が関連し、リソースマネージャ102は、リソースを割り当てる際、優先度の最も高いアクティビティから始める。リソースマネージャ102は、終わりに達するまで、またはプロバイダのリソースが尽きるまで、アクティビティのリストの中を反復する。例示的なリソース計算についてのより詳細な記述を、次のセクションの「例示的なリソース予約計算」という項目で提供する。
【００６８】
構成内のリソース記述子がすべて予約されているとき、この構成は予約されているという。リソース記述子にリソースが割り当てられているとき、このリソース記述子は予約されているという。ステップ322および324は、構成内のあらゆるリソース/リソースプロバイダに対して繰り返す(ステップ326)。
【００６９】
ステップ328で、リソースマネージャ102は、すべての要求されたリソースが利用可能であるという点で各予約が成功したかどうかを決定する。予約が成功した場合は、リソースマネージャ102は、リソースプロバイダ104がコンシューマのリソース使用要求を妥当性検査することができるように、予約をリソースプロバイダ104に通知する(ステップ330)。このようにすることで、プロバイダ104は、最初に予約せずにリソースを使用しようとする不正なコンシューマならびに正当なコンシューマを捕えることができる。例えば、正当なプログラムが、CPUリソースを最初に予約せずに使用しようとする場合がある。同様に、USBマウスが、USB帯域幅を最初に予約していないのに使用しようとする。このような状況で、CPUおよびUSP帯域幅に関連するプロバイダは、プログラムまたはUSBマウスがまだリソースを予約していないと識別することができる。
【００７０】
予約が失敗した場合(要求されたリソースのすべてが利用可能ではないことを意味する)、リソースマネージャ102は、予約失敗をリソースプロバイダ104に通知する(ステップ332)。次いでリソースマネージャ102は、次のタスクの一方または両方を実施する。すなわち、(1)より好ましくない構成が利用可能であって、予約すべき構成をコンシューマが指定していなかった場合は、より好ましくない構成を試みる(ステップ334)、かつ/または(2)要求元のコンシューマにエラーを報告する。
【００７１】
（例示的なリソース予約計算）
図4に、図3の予約および調停ステップ308(より具体的にはステップ322-326)の一部として採用される例示的なリソース予約プロセスを示す。図3のステップ308で、リソースマネージャ102は、アプリケーション32などのコンシューマのためにリソースを予約する。図4には、3つのアクティビティA1、A2、A3が示してあり、これらを番号400(1)、400(2)、400(3)で一般的に参照する。これらのアクティビティは、リソースマネージャ102で構築され、リソースマネージャ102にある。各アクティビティには優先度が関連し、したがって、第1のアクティビティA1は最高優先度を有し、第2のアクティビティA2は中間優先度を有し、第3のアクティビティA3は最低優先度を有する(すなわちA1＞A2＞A3)。
【００７２】
アクティビティの「優先度」は、ユーザまたはシステムの好ましさを示す。これは、従来のスレッド優先度またはプロセス優先度の意味で用いるものではない。具体的には、アクティビティ優先度は、同じリソースを求めて争うコンシューマ間の調停ポリシーを規定するものである。述べた実装形態では、ポリシーマネージャ108が各アクティビティに優先度を割り当てる。優先度は、個々のリソースとは対照的に、アクティビティに割り当てることに留意されたい。このようにすることで、リソースマネージャは、優先度のより低いアクティビティにリソースの返還を要求して、優先度のより高いアクティビティの予約要求を満たすことができる。
【００７３】
この例では、各アクティビティ400(1)-400(3)は、ただ1つの構成402(1)-402(3)を有する。記述子R₁およびR₂は、リソースマネージャに登録している対応するリソースプロバイダを表す。アクティビティA1およびA2は両方とも記述子R₁およびR₂を有するが、アクティビティA3は記述子R₁しか有さない。この例で、最高優先度のアクティビティおよび最低優先度のアクティビティA1およびA3が予約されており、リソースマネージャが、中間優先度のアクティビティA2を予約する要求を受けると仮定する。リソースマネージャは、以下の5つのステップを実施してA2を予約する。
【００７４】
ステップ 1：リソースマネージャは、その内部状態を調べ、予約されているすべてのアクティビティのアクティビティリストを作成する(すなわち図3のステップ322)。この時点では、リストは予約済みのアクティビティA1およびA3を含む。次いでリソースマネージャは、アクティビティA2をリストに加え、得られたリストを優先度の高い順にソートする。この結果、最高優先度のアクティビティA1、次いで中間優先度のアクティビティA2、次いで最低優先度のアクティビティA3を順に含むアクティビティリストが得られる。
【００７５】
図5に、3つのアクティビティを優先度の順に表すアクティビティリスト500を示す。アクティビティリスト500はリソースマネージャによって維持される。
【００７６】
ステップ 2：アクティビティA2内の各リソース記述子につき、リソースマネージャは、要求を満たすのに十分なリソースがあり、したがってリソースマネージャがそのリソース記述子をこのアクティビティのために予約することが可能であるかどうかを決定する。これはまず、アクティビティリスト500中のすべてのアクティビティにおける、予約すべきリソース記述子で参照されるプロバイダと同じプロバイダを使用するリソース記述子のリストを作成することによって行う。例えば、A2-R₁(すなわちアプリケーションA2内の記述子R₁)を予約するために、リソースマネージャは、アクティビティリスト500中にリストされているアクティビティ内のすべてのリソース記述子R₁に関する別個のリソース記述子リストを構築する。このリストもまた、優先度の高い順である。
【００７７】
図5に、2つの記述子リスト502(1)および502(2)を示す。第1のリスト502(1)は、アクティビティリスト500中にリストされているアクティビティA1-A3内のすべてのリソース記述子R₁を、優先度の高い順に含む。したがって、A1-R₁-1、A1-R₁-2(すなわちアクティビティA1内におけるプロバイダR₁の第2の使用)、A2-R₁、A3-R₁の順である。第2のリスト502(2)は、アクティビティリスト500中にリストされているアクティビティA1-A3内のすべてのリソース記述子R₂を、優先度の高い順に含む。したがって、A1-R₂、A2-R₂-1、A2-R₂-2の順である。記述子リスト502は、リソースマネージャによって維持される。
【００７８】
ステップ 3：記述子リスト502が完成した後、リソースマネージャは、様々なアクティビティに割り振られるリソースの量の継続的な増加を表す累積値506を保持するバッファ504を生み出す。リソースマネージャは、R₁記述子リスト502(1)中の各要素につき、リソースプロバイダR₁の「アキュムレータ追加」関数を呼び出し、リソース記述子(すなわちA1-R₁-1、A1-R₁-2など)、アキュムレータバッファ504、およびリソースプロバイダのリソース定量化部106(図2)を渡す。リソースマネージャは、R₂記述子リスト502(2)中の各要素についても同様の呼出しを行う。
【００７９】
アキュムレータ追加関数は、リソース記述子に必要なリソース量を決定し、それをアキュムレータバッファ504の内容に加える。バッファ504中の新しい値がリソースプロバイダR₁におけるリソースの最大量を超える場合は、アキュムレータ追加関数はエラーを返し、プロバイダがリソース不足によりこの割振りを満たすことができないことを示す。リソースマネージャは、このようなリソース記述子に関連するアクティビティを「犠牲者」としてタグ付けする。例えば、リソース記述子A3-R₁に対する計算が失敗した場合、アクティビティA3は犠牲者としてタグ付けされる。予約されるアクティビティA2が犠牲者としてマークされた場合は、リソースマネージャは図3のステップ332に出て、アクティビティA2内の構成を予約することが不可能であることを通知する。
【００８０】
ステップ 4：リソースマネージャは、ステップ2で構築したリソース記述子リスト中のすべてのリソース記述子を処理した後、犠牲者アクティビティがあるかどうか評価する。犠牲者アクティビティがない場合、リソースマネージャはアクティビティA2の予約を成功させることができた。A2内のすべてのリソース記述子のプロバイダに、新しい予約が通知される。これによりプロバイダは、コンシューマのリソースアクセス要求を妥当性検査することができ、また逆に、予約なしでリソースを使用しようとする不正コンシューマを捕えることができる。
【００８１】
ステップ 5：一方、ステップ3の最後で犠牲者アクティビティがある場合は、リソースマネージャは、リソースを解放するようにこれらのアクティビティに通知する。リソースが解放されると、リソースマネージャは、元々要求を出したアクティビティ(この場合はA2)にこれらのリソースを割り当てる。例えば、ステップ3でアクティビティA3が犠牲者としてタグ付けされたとする。リソースマネージャは、アクティビティA3にそのリソースを解放するように通知し、それらを要求元のアクティビティA2に再割振りする。これは、アクティビティA2がアクティビティA3よりも高い優先度を有し、したがって限られたリソースを優先度のより低いアクティビティA3からより高いアクティビティA2に移すべきなので、理にかなっている。
【００８２】
（優先度ベースのプリエンプトを用いたリソース割振り）
図2に示すリソース管理アーキテクチャ100は、種々のタイプの戦略を採用して、リソースコンシューマから要求される様々なアクティビティ間でリソースを割り振ることができる。例えばある戦略は、できるだけ多くのアクティビティ間でリソースを最適化するものである。別の戦略は、何らかの優先度基準に従ってリソースを割り振るものである。この後者の戦略が、このセクションにおける関心の対象である。
【００８３】
優先度ベースの戦略では、どのアプリケーションおよび/またはユーザが他を制してリソース使用の優先度を有するかに基づいてリソースを割り振る。繰り返すが、用語「優先度」は、従来のスレッド優先度やプロセス優先度の意味では用いず、同じリソースを求めて争うコンシューマ間の調停ポリシーのコンテキストで用いる。優先度は、個々のリソースとは対照的に、アクティビティに割り当てる。
【００８４】
優先度ベースの戦略では、アクティビティを重要度によってランク付けすることができる。例えば、ユーザにとってより「重要な」アクティビティを、より高い優先度に指定することができる。これによってリソース管理アーキテクチャは、所望の、ただし限られたリソースを、より重要でないアクティビティから取り去ってより重要なアクティビティに移行することができる。何が「より重要な」ものおよび「より重要でない」ものを構成するかを決定することが、ポリシーマネージャ108およびポリシー110の場であり、これについては後で「ポリシーマネージャ」の項目でより詳細に述べる。しかし、プリエンプトに関するここでの考察では、他のアクティビティに対する相対的な重要度など、何らかの方式でアクティビティをランク付けする何らかの優先度等級があるものとする。例として、ポリシーマネージャ108がない場合、アクティビティ優先度は先着順で割り当てることができる。
【００８５】
優先度ベースのプリエンプトにより、リソースマネージャは効果的に、リソースを現在使用している優先度のより低いアクティビティを「プリエンプト」し、優先度のより高いアクティビティにリソースを動的に移動する。リソースマネージャは、優先度のより低いアクティビティに、そのリソース使用権が一時停止されることを通知する。これにより、この優先度のより低いアクティビティには、制御されたクリーンな方式でリソースの使用を停止する機会が与えられるか、または、これに反応して、場合によっては代替方式でその処理を完了するチャンスが与えられる。
【００８６】
リソースマネージャは、リソースの返還を要求する対象のアプリケーションと連携して、プリエンプトプロセスを達成する。図2に示すように、リソースマネージャ102は、優先度が割り当てられた１つ以上のアクティビティ構造122をシステム内で維持する。各アクティビティは１つ以上の構成構造124を有し、構成構造124は、アクティビティがそのタスクを達成するのに必要なリソースのセットを指定する。リソースマネージャ102はまた、どのアクティビティにその構成のためのリソースが与えられているかを追跡し、各リソースプロバイダ104との必要な通信と、各リソースプロバイダに関する必要な状態とを維持して、各リソースプロバイダの提供するリソースが現在どれだけ利用可能かを追跡する。
【００８７】
図6に、優先度ベースのプリエンプトを用いたリソース割振りプロセスを示す。各ステップは、リソースマネージャおよびリソースプロバイダによって(図示のように)、ソフトウェア中で実施されるものであり、これらのステップについて図2をさらに参照しながら述べる。
【００８８】
ステップ600で、リソースマネージャ102は、あるタスクを実施するためのアクティビティ122を生み出すことを求める要求をコンシューマ(例えばアプリケーション)から受け取る。アクティビティの一部として、１つ以上の構成124が指定される。次いで、コンシューマは構成を予約する。リソースマネージャ102は、構成124内で識別される登録済みの各リソースプロバイダ104に、そのリソースをアクティビティ122に割り振ることができるかどうか尋ねる(ステップ602)。
【００８９】
新しい構成を満たすのに十分なリソースをプロバイダ104が有する場合、リソースマネージャは、リソースをアクティビティに割り振る(すなわちステップ604からの「yes」ブランチおよびステップ606)。そうではなく、いずれかのプロバイダ104に構成を満たすのに十分なリソースが残っていない場合は、このプロバイダ104は、リソースの不足をリソースマネージャ102に通知する(すなわちステップ604からの「no」ブランチおよびステップ608)。
【００９０】
リソースマネージャ102は、リソースを現在要求しているアクティビティよりも優先度の低いすべてのアクティビティ122のすべての構成124をチェックして、優先度のより低いアクティビティのいずれかが、優先度のより高い新しいアクティビティに割り振ればその構成を満たすことになるリソースを現在使用しているかどうかを決定する(ステップ610)。このような優先度のより低いアクティビティまたはその組合せが存在しない場合は(すなわちステップ612からの「no」ブランチ)、リソースマネージャ102は、優先度のより高いアクティビティに、そのリソース構成を現在満たすことができないことを通知する(ステップ614)。
【００９１】
一方、リソースを取り去ることのできる優先度のより低いアクティビティが存在する場合は(すなわちステップ612からの「yes」ブランチ)、リソースマネージャ102は、この優先度のより低いアクティビティ内で現在予約されているリソースを含めて、優先度のより高い新しいアクティビティ内のリソースすべてを予約できるかどうかを決定する(ステップ616)。予約できない場合は(すなわちステップ616からの「no」ブランチ)、リソースマネージャ102は、優先度のより高いアクティビティに、そのリソース構成を現在満たすことができないことを通知する(ステップ614)。反対に、リソースを予約できる場合は、リソースマネージャ102は、優先度のより低い各アクティビティに、そのリソースを放棄するように知らせるプリエンプト通知を送る(ステップ618)。この場合、優先度のより低いアクティビティには、制御された方式でそのリソース予約を減らして、優先度のより高いアクティビティに再割振りされるようにリソースを解放する機会が与えられるか、または、これに反応して、場合によっては代替方式でその処理を完了するチャンスが与えられる(ステップ620)。優先度のより低いすべてのアクティビティが現在使用しているリソースをすべて解放したとき、リソースマネージャ102は、優先度のより高い新しいアクティビティに、その必要とするリソースの割振りに進むことができることを通知する(ステップ622)。このようにして、優先度のより低いプロセスは、優先度のより高いリソースによって必要とされるその限られたリソースの使用をプリエンプトされる。
【００９２】
優先度のより低いプロセスが、リソースマネージャからプリエンプト通知を受け取ったときにそのリソースを快く放棄しない場合は、リソースマネージャは、そのアクティビティの予約を取り消して、かつ/または優先度のより低いアクティビティに関連するプロセスを終了して、強制的にそのリソースの返還を要求することができることに留意されたい。
【００９３】
図7-10に、優先度ベースのプリエンプトを用いたリソース割振りを例示するための種々のシナリオを示す。各図は、リソースマネージャ102に存在する１つ以上のアクティビティと、アクティビティをもう1つ追加する試みとを示す。既存のアクティビティおよび新しいアクティビティにはそれぞれ、優先度が関連する。考察しやすいように、各アクティビティは構成を1つだけ有するものとする。
【００９４】
図7には、2つのアクティビティが同じリソースを利用したいと思っているが、残念ながら2つのアクティビティのうちの一方にしかリソースを割り振ることができない場合を示す。例えば、リソースがチューナであり、システムがチューナを1つしか有さないと仮定する。2つのアクティビティA1およびA2(番号700(1)および700(2)で一般的に参照する)は、対応する構成702(1)-702(2)を有し、各構成は、対応する同じリソースプロバイダを表す同一の記述子を含む。
【００９５】
図7の場合、既存のアクティビティA1は最高優先度を有し、追加が求められる新しいアクティビティA2は最低優先度を有する(すなわちA1＞A2)。図6の優先度ベースのプリエンプトプロセスに従って、リソースマネージャは、まず記述子R₁で識別されるリソースプロバイダと接触することにより、A1に対して「リソース計算」を実行する。先に「リソース計算」方法の中で述べたように、プロバイダは、この記述子によって必要とされるリソース量をアキュムレータに加える。アキュムレータの新しい値は1になる。プロバイダは、アキュムレータの値を、それが有するリソースの総量(この場合は1)と比較し、この量を満たすことができることをリソースマネージャに示す。リソースマネージャは、「アキュムレータ」を1に初期化した状態で、アクティビティA2に対してこれと同じ手順を繰り返す。プロバイダは、アクティビティA2に必要なリソースの量をアキュムレータの内容に加え(図6のステップ602)、これがプロバイダの有するリソースの総量を超えることに気付く。リソースプロバイダは、現在の割振りでは要求を満たすことができない旨の通知を返す(ステップ604および608)。次いでリソースマネージャは、要求されるリソースを現在使用している優先度のより低いアクティビティがあるかどうか評価する(ステップ610)。この場合、このリソースの現ユーザは既存のアクティビティA1であり、アクティビティA1は、新しいアクティビティA2よりも優先度が高い。したがってリソースマネージャは、新しいアクティビティに、今回はその構成を満たすことができないことを通知する(ステップ612および614)。
【００９６】
図8に、図7と同様だが、例外として新しいアクティビティの方が既存のアクティビティよりも高い優先度を有する場合を示す。2つのアクティビティA1およびA2(番号800(1)および800(2)で一般的に参照する)は、対応する構成802(1)-802(2)を有し、各構成は、対応するリソースプロバイダを表す記述子を含む。この場合、既存のアクティビティA1の方が新しいアクティビティA2よりも低い優先度を有する(すなわちA1＜A2)。
【００９７】
図6の優先度ベースのプリエンプトプロセスに従って、リソースマネージャは、記述子R₁で識別されるリソースプロバイダに尋ねて、新しいアクティビティA2にリソースを割り振ることができるかどうかを決定する(図6のステップ602)。リソースプロバイダは、現在の割振りでは要求を満たすことができない旨の通知を返す(ステップ604および608)。
【００９８】
次いでリソースマネージャは、要求されるリソースを現在使用している優先度のより低いアクティビティがあるかどうか評価する(ステップ610)。この場合、このリソースの現ユーザは既存のアクティビティA1であり、アクティビティA1は、新しいアクティビティA2よりも優先度が低い。したがってリソースマネージャは、優先度のより低いアクティビティA1にプリエンプト通知を送り(ステップ616)、優先度のより低いアクティビティが停止または完了できるようにする(ステップ618)。リソースマネージャは、優先度のより高い新しいアクティビティA2に、その要求するリソースが割り振られることを知らせる(ステップ620)。したがって、図8は、リソースマネージャが既存のアクティビティから新しいアクティビティに動的に移行し、それによって優先度のより高い新しいアクティビティのために既存のアクティビティを犠牲にする場合を表す。
【００９９】
図9に、犠牲者アクティビティがそのリソース使用を解放するか減らすように求められる場合を示す。この場合、犠牲者アクティビティは現在、他のリソースR₁、R₂、R₄も予約しており、これらのリソースはリソースマネージャから要求されていない。このような場合、アクティビティを所有するコンシューマは、すべてのリソースを解放するか、リソースマネージャから要求されるリソースのすべてを解放するか、リソースマネージャから要求されるリソースの一部を開放するかを決定することができる。考察のために、リソースR₃がCPUリソースに関係し、アクティビティA1に関連するコンシューマが、CPUの50%を求めるアクティビティA2からの要求に応答して、そのCPU使用を40%使用に減らしたいと思っていると仮定する。
【０１００】
図9では、既存の低優先度のアクティビティA1(番号900(1)として一般的に参照する)が、対応する構成902(1)を有し、この構成は、記述子R₁-R₄で表される4つのリソースを含む。新しい高優先度のアクティビティA2(番号900(2)として一般的に参照する)が、対応する構成902(2)を有し、この構成は1つのリソースR₃しか含まない。リソースマネージャは、高優先度のアクティビティA2が、記述子R₃で識別されるリソースに対する権利を有すると決定し、アクティビティA1をプリエンプトする。この場合、犠牲者アクティビティA1は、記述子R₃で識別されるリソースの使用を減らすことを選択し、記述子R₁、R₂、R₄で識別される残りのリソースの制御は、少なくとも当面は維持する。
【０１０１】
図10に、リソースマネージャが、既存の低優先度のアクティビティをプリエンプトする行程に乗り出す前に、新しい構成の構成全体を満たすことができるかどうかを考慮する場合を示す。図10には、既存の低優先度のアクティビティA1(すなわち1000(1))を示すが、このアクティビティA1は、単一の記述子R₁をリストする構成1002(1)を有する。別の既存のアクティビティだが高優先度のアクティビティA2(すなわち1000(2))は、単一の記述子R₂をリストする構成1002(2)を有する。中間優先度の第3のアクティビティA3(すなわち1000(3))が、追加されるように要求する。第3のアクティビティA3は、2つの記述子R₁およびR₂をリストする構成1002(3)を有する。
【０１０２】
この場合、リソースマネージャは、新しいアクティビティA3の要求を満たすために、2つの記述子R₁およびR₂で識別されるリソースを割り振らなければならない。リソースマネージャは、低優先度のアクティビティA1をプリエンプトして、記述子R₁で識別されるリソースを中間優先度のアクティビティA3に再割振りするのを可能にすることもできるが、これは1つのリソースを満たすだけである。リソースマネージャはさらに、他方のリソースR₂の現ユーザが高優先度のアクティビティA2であると決定する。したがってリソースマネージャは、中間優先度のアクティビティA3のために高優先度のアクティビティA2をプリエンプトすることはしない。リソースマネージャは新しいアクティビティA3の構成全体を満たすことはできないので、低優先度のアクティビティA1をプリエンプトしないことを選択し、その代わり、新しいアクティビティA3に関連するコンシューマに、その要求を満たすことができないことを通知する。
【０１０３】
（フォールバック構成）
前のセクションで述べた各シナリオでは、アクティビティが構成を1つだけ有すると仮定した。しかし、図2の一般的なリソース管理アーキテクチャに示すように、各アクティビティが複数の構成を指定することもある。複数の構成がある場合、アクティビティがリソース使用をプリエンプトされてもなお、プリエンプトされたリソースを必要としない別の構成を使用して処理を継続することができる状況があり得る。したがって、フレキシブルな適合プロセスが、代替リソースセットを使用して、何らかの代替方式でそのタスクを完了することができる場合がある。例えば、アクティビティは、ハードウェアビデオデコーダ(優先度のより高いアクティビティに再割振りされるリソース)を使用する代わりに、ソフトウェアビデオデコーダを使用するアルゴリズムを別法として採用することができる。
【０１０４】
代替構成は、競合しないであろう異なるリソース、または単により少ないリソースを利用するものとすることができる。通常、代替構成を使用することは、アプリケーションによって生み出される結果の品質を落とすことにつながる。この状況では、アクティビティがより好ましい構成からより好ましくない別の構成に「フォールバック(後退)」するという。例えば、アクティビティが、ハードウェアビデオデコーダを有する好ましい構成からソフトウェアビデオデコーダを有するフォールバック構成に動的に変更するとき、フォールバック構成は、全画面サイズの画像をデコードすることができない。したがって、アプリケーションの出力の品質が落ち、モニタ上のビデオ画像のサイズが縮小する。
【０１０５】
図2を参照するが、リソースマネージャアーキテクチャ100は、リソース割振りが変更されたときにアクティビティ122がフレキシブルに適合することを容易にする。各アクティビティ122は、複数の構成124(1)、124(2)などを含むことができ、各構成は、プロセスが構成内のすべてのリソースを有する場合にプロセスが進行できるような、許容されるリソースセットを表す。構成124は、アプリケーションまたはコンシューマプロセスによって好ましさの順にランク付けされる。リソースマネージャ102がアクティビティをプリエンプトするとき、アクティビティは、そのリソース使用を解放するか減らす必要がある。リソースが解放された後は、いくつかの動作進行が考えられる。ある手法では、プリエンプトされたアクティビティに関連するコンシューマは、別の構成のリソースを予約するようにリソースマネージャに頼むことができる。別の手法では、リソースマネージャ102は自動的に、次に高いランクのフォールバック構成内のリソースを予約することを試みる。リソースマネージャは、(1)現在利用可能なリソースで満たすことのできる構成を見つけるまで、または(2)満たすことのできるフォールバック構成がないとわかるまで、各フォールバック構成に連続して進む。
【０１０６】
図11に、動作条件の変化に伴ってより好ましい構成からより好ましくない構成に動的にダウングレードするプロセスを示す。このような変更は、例えば、リソースマネージャ102が高優先度のアクティビティにリソースを再割振りするために低優先度のアクティビティをプリエンプトする、優先度ベースのポリシーの結果として引き起こされることがある。図11の各ステップは、リソースマネージャ102によって実施されるものであり、これらのステップについて図2をさらに参照しながら述べる。図示のプロセスでは、リソースマネージャ102が、例えば図6に示したリソース割振りプロセスの結果として、アクティビティによる１つ以上のリソースの使用をプリエンプトしたと仮定する。このため、犠牲者アクティビティには、もはやその好ましい構成が利用可能ではない。
【０１０７】
ステップ1100で、リソースマネージャ102がアクティビティをプリエンプトしたとき、リソースマネージャ102は、犠牲者アクティビティ122が別の構成124を有するかどうかを決定する。アクティビティコンテナ122内で他の構成が指定されていない場合は(すなわちステップ1100からの「no」ブランチ)、リソースマネージャは、代替構成が指定されていないことをコンシューマ(例えばアプリケーション32)に通知し、フォールバックリソースセットを記述する新しい構成をアクティビティ内に生み出してこの新しい構成の予約を要求する機会をコンシューマに与える(ステップ1102)。構成の生成については、図3に関して先に述べてある。
【０１０８】
あるいは、１つ以上の他の構成がアクティビティ内に示されている場合は(すなわちステップ1100からの「yes」ブランチ)、リソースマネージャ102は、アクティビティ122内のすべてのフォールバック構成124の中を進む(ステップ1104)。リソースマネージャ102は、満たすことのできるフォールバック構成があるかどうか決定する(ステップ1106)。満たすことのできる構成がない場合は(すなわちステップ1106からの「no」ブランチ)、リソースマネージャはコンシューマに通知し、新しい構成をアクティビティ内に生み出す機会をコンシューマに与える(ステップ1102)。
【０１０９】
反対に、少なくとも1つのフォールバック構成を満たすことができる場合は(すなわちステップ1106からの「yes」ブランチ)、リソースマネージャ102はこの構成内のリソースを予約する(ステップ1108)。リソースマネージャ102はまた、フォールバック構成を満たすことができることをコンシューマに通知する(ステップ1110)。通知は、プリエンプトされていないリソースが現在の構成とフォールバック構成の両方にある場合に、またはプリエンプトされたリソースが現在の構成とフォールバック構成の両方にあって、フォールバック構成の方が現在の構成よりも少ない量のプリエンプトリソースを使用する場合に、プロセスがそのリソースを解放せずに構成を切り替えることができるような形で行う。
【０１１０】
図11のフォールバックプロセスは、異なる3つの手法をサポートする。ある手法では、コンシューマの現在の構成がプリエンプトされることがコンシューマに通知されるまで、代替構成を生み出さなくてもよい。これは、図11のステップ1102によって例示するものである。この時点でコンシューマ(例えばアプリケーション32)は、競合リソースを含まない新しい構成を生み出し、リソースマネージャ102に、代替構成をアクティビティに加えて代替構成を予約するように伝える。代替構成の構築にはいくらか時間がかかることがあり、リソースマネージャとの通信(およびプロバイダとの間接的な通信)にも時間がかかることがある。この時間遅延は品質に影響を及ぼすことがある。
【０１１１】
フォールバック構成内のすべてのリソースが利用可能な場合、リソースマネージャ102は、フォールバックリソースを予約し、コンシューマが望むなら元のリソースを解放する。あるいは、コンシューマは、2つの構成の結合を一時的に保有し、後で元のリソースを明示的に解放することもできる。フォールバック構成を満たすことができない場合は、元の構成内のリソースは解放されず、したがって、プロセスは別のフォールバック構成を用いて再び試みる。最終的に、許容されるフォールバック構成を生み出すことができない場合は、コンシューマは処理を停止し、リソースを別のアクティビティに割り振られるように解放する。次いでコンシューマは、リソースが再び利用可能になるまで待機する。
【０１１２】
この第1の手法の変形は、コンシューマが、その通知を受け取ったときに、プリエンプトされたリソースを解放できることをリソースマネージャに明示的に通知するものである。このようにすると、コンシューマがフォールバック構成を構築できるまで待機するよりも少し早くリソースを解放することができる。
【０１１３】
別の手法では、代替構成はリソースコンシューマによって事前に生み出される。これは、図11のステップ1100からの「yes」ブランチと、図2のアクティビティの1つ122(1)内の複数の構成124(1)および124(2)によって示すものである。プリエンプトの一部として、リソースマネージャ102は単に、プリエンプトされるコンシューマに、アクティビティ内のその現在構成を失うことになり所与のフォールバック構成に切り替えなければならないことを通知する。リソースマネージャは、この通知の前にフォールバック構成内のリソースを予約し、したがって、コンシューマは一時的に2つの構成の結合を保有する。コンシューマは次いで競合するリソースを解放し、代替のリソース集合をサポートするための必要な変更を行う。次いでリソースマネージャ102は、元の構成内にあってフォールバック構成内にはない争われたリソースを解放し、それによってこれらのリソースが他のアクティビティに割り振られるようにする。
【０１１４】
フォールバック構成はまた、最初にリソースを予約する間に使用することもできることに留意されたい。例えば、アプリケーション32が価値でランク付けした複数の構成124をアクティビティ122内に供給するとき、リソースマネージャ102は、リソースマネージャ102が満たすことのできる最もランクの高い構成を選び、これらのリソースを予約し、どの構成が満たされたかをプロセスに通知する。
【０１１５】
図12に、より好ましくない構成にダウングレードするプロセスにおけるシナリオの1つを示す。図12には、リソースマネージャ102にある、既存のアクティビティA1(番号1200(1)として参照する)および新しいアクティビティA2(番号1200(2)として参照する)を示す。新しいアクティビティA2は、既存のアクティビティA1よりも優先度が高い。
【０１１６】
既存のアクティビティA1は、2つの構成を有する。すなわち、好ましい構成C1(番号1202として参照し、より高くランクされていることを示すための文字「H」を付けてある)と、フォールバック構成C2(番号1204として参照し、より低くランクされていることを示すための文字「L」を付けてある)である。好ましい構成C1は、アクティビティを実施するのに必要な対応するリソースを識別するためのリソース記述子セットR₁、R₂、R₃を含む。フォールバック構成C2は、アクティビティを実施するのに必要な対応するリソースを識別するための異なるリソース記述子セットR₁およびR₄を含む。新しいアクティビティA2は、1つの構成C1(番号1206として参照する)を有し、この構成C1は、対応するリソースを識別するための1つの記述子R₃を含む。
【０１１７】
この図示の例では、リソース記述子R₃は、番号104として参照するリソースプロバイダR₃を識別する。リソースプロバイダR₃は、チューナなど、一度しか割り振ることのできないリソースを制御するものとする。さらに、リソースプロバイダR₃によって維持されるカウンタ1208は、唯一のチューナが現在、優先度のより低いアクティビティA1の既存の構成C1に割り振られていることを示すものとする。
【０１１８】
リソースマネージャ102が、新しいアクティビティA2を生み出したコンシューマから予約要求を受け取ったとき、リソースマネージャ102は、リソースプロバイダ104がもはや他方のアクティビティA1にリソースを割り振ることができないことを知る。したがってリソースマネージャは、優先度のより低いアクティビティA1をプリエンプトして、記述子R₃に関連するリソースを優先度のより高いアクティビティA2に移行すべきであると決定する。
【０１１９】
リソースマネージャは、優先度のより低いアクティビティA1が代替構成を有するかどうかを決定する(すなわち図11のステップ1100)。この場合、アクティビティA1は、プロバイダR₃によって制御されるプリエンプト対象のリソースを必要としないフォールバック構成C2を有する。したがってリソースマネージャ102は、フォールバック構成C2内のリソース(すなわちプロバイダR₁およびR₄から提供されるリソース)を予約し、アクティビティA1に関連するコンシューマに、プリエンプトされることおよびフォールバック構成C2に切り替える必要があることを通知する(すなわち図11のステップ1108および1110)。
【０１２０】
アクティビティA1は、矢印1212で表すように、フォールバック構成C2の使用に移行する。リソースマネージャ102は、矢印1210で表すように、プロバイダR₃のリソースをアクティビティA1から新しいアクティビティA2に再割振りする。
【０１２１】
アクティビティA1に関連するコンシューマへの影響が小さく、かつフォールバック構成C2への変換から生じる分断なしにプロセスが連続できることが望ましい。例えば、ハードウェアビデオデコーダがなくなるがソフトウェアデコーダで置き換えることができる前述の状況を考えてみる。アプリケーションは、ソフトウェアビデオデコーダをロードおよび初期化してから、ビデオストリームが中断しないような形でこれをビデオストリーム中に統合する方式をとることができる。
【０１２２】
アクティビティ内の構成間の違いは、非常に様々である場合がある。元の構成と代替構成が、必要なリソースの点でかなり共通することもある。実際この違いは、競合するリソースが代替構成から除去されている点だけにあることがある。あるいは、構成は大きく異なることもある。
【０１２３】
（アップグレード通知）
前のセクションでは、システム中のコンシューマは、プリエンプトされた場合に、より望ましい構成からより望ましくない構成に移行することが必要な場合がある。アップグレード通知は、リソースが再び利用可能になったときにコンシューマがより望ましい構成にアップグレードできるようにすることによる、帰路に関係するものである。
【０１２４】
図13に、動作条件の変化に伴ってより好ましくない構成からより好ましい構成に動的にアップグレードするプロセスを示す。このプロセスはリソースマネージャで実施されるものであり、このプロセスについて図2を参照しながら述べる。図示のプロセスでは、アプリケーションが、(1)リソースの予約を最初に要求したときに、その最高ランクの構成内の所望のリソースをすべて予約することができなかったため、または、(2)前にプリエンプトされてより低いランクの構成に移行したために、より望ましくない構成で稼動しているものとする。
【０１２５】
ステップ1300および1302で、リソースマネージャ102は、既存のアクティビティを監視し、アクティビティが完了してそのリソースを解放したときを検出する。リソースが解放されたとき、リソースマネージャ102は、構成が現在予約されていないアクティビティおよび最良ではない構成が予約されているアクティビティを含め、すべてのアクティビティを調べて、より好ましいいずれかの構成にアップグレードすることができるかどうかを決定する(ステップ1304)。アップグレードできる場合は、リソースマネージャ102は、それらのアクティビティに関連するコンシューマにアップグレード通知を送る(ステップ1306)。アップグレード通知は、コンシューマのアクティビティ内のより望ましい(すなわちより高くランクされた)構成を現在利用可能なリソースで満たせることをコンシューマに知らせる。
【０１２６】
コンシューマは、現在使用している構成よりも望ましい構成が利用可能になったときにアップグレード通知を受け取るように、リソースマネージャに登録する。ただし、アップグレード通知はオプションであり、コンシューマはこれらを受け取るように登録しなくてもよい。
【０１２７】
コンシューマがアップグレード通知を受け取ると、コンシューマは、アップグレード要求をリソースマネージャに提出して、新しい構成のためのリソースを予約するように頼むことができる。リソースマネージャは、アップグレード要求を受け取ると、新しい構成の予約を試みる(ステップ1308)。一実装形態では、リソースマネージャは本質的に図3と同じプロセスを採用するが、例外として、アップグレードされるコンシューマは、2つの構成、すなわち現在所有している構成と新しい構成とを短時間だけ予約していることが許容される。2つの構成の予約を可能にすることにより、古い構成から新しい構成にスムーズに移行することができる。コンシューマは、新しい構成に移行した後で、古い構成を解放する。別の実装形態では、アップグレードされるコンシューマアプリケーションは、まず古い構成による処理をシャットダウンし、次いで処理を再開する前に新しい構成を予約することが必要な場合もある。
【０１２８】
ただし、コンシューマが新しい構成の予約に成功する保証はない。例えば、優先度のより高い他のアクティビティもまた同じリソースを請求している場合がある。リソースマネージャは、コンシューマがより望ましい構成にアップグレードしようとして失敗した場合に、既存の構成を維持することを保証する。
【０１２９】
より高ランクの構成とより低ランクの構成を含めて、構成は、アクティビティが予約済みのリソースを有するかどうかにかかわらずいつでもアクティビティに加えることができることに留意されたい。現在予約されているリソースを有するアクティビティに構成を追加する場合であって、この構成が現在の構成よりも高いランクにあり、このより高ランクの構成を満たすことができる場合は、リソースマネージャは、このより高ランクの構成が可能であることをコンシューマに知らせる即時のアップグレード通知を送ることになる。
【０１３０】
図14に、より望ましい構成にアップグレードするプロセスにおけるシナリオの1つを示す。図14には、リソースマネージャ102にある、既存のアクティビティA1(番号1400(1)として参照する)、待機中のアクティビティA2(番号1400(2)として参照する)、および終了するアクティビティA3(番号1400(3)として参照する)を示す。終了するアクティビティA3の優先度が最も高く、その次に待機中のアクティビティA2、その次に既存のアクティビティA1の順である。終了するアクティビティA3は、そのタスクを完了し、記述子R₁およびR₂で示すそのリソースを解放しているところである。
【０１３１】
中間優先度のアクティビティA2は、記述子R₂で示すリソースを必要とする単一の構成C1を有する。中間優先度のアクティビティA2は、前に、優先度のより高いアクティビティA3に割り振られたこのリソースへのアクセスを得ることができなかったので、待機中である。
【０１３２】
既存のアクティビティA1は、記述子R₁を含む好ましい構成C1と、記述子R₄を含むフォールバック構成C2とを有する。現在、記述子R₁で示すリソースが優先度のより高いアクティビティA3によって拘束されているので、既存のアクティビティは現在、フォールバック構成C2を使用している。
【０１３３】
高優先度のアクティビティA3が終了し、記述子R₁およびR₂に関連するリソースを解放したとき、リソースマネージャ102は、既存のアクティビティが新たに解放されたリソースの利益を得ることができるかどうかを決定する(すなわち図13のステップ1304および1308)。この場合、アクティビティA1とA2の両方が利益を得ることができる。したがってリソースマネージャ102は、アクティビティA1およびA2にそれぞれ関連するアプリケーション32(1)および32(2)にアップグレード通知を送る(すなわちステップ1306)。アプリケーションは、アップグレードすることを選択した場合はアップグレード要求を返す。この例では、リソースマネージャ102はアクティビティA1の構成を、より好ましくない構成C2から、記述子R₁で示す解放されたリソースを利用する、より好ましい構成C1にアップグレードする。これは矢印1402で表される。リソースマネージャはまた、アクティビティA2のために記述子R₂に関連するリソースの予約も行う。
【０１３４】
（構成の構築）
前述のように、リソースまたはリソースプロバイダは、リソースを提供することに加えて、それ自体で、他のリソースプロバイダによって管理される他のリソースのコンシューマになることもある。例えば、USBカメラリソースは、USBドライバから提供される帯域幅のコンシューマである。したがって、USBドライバは、USBカメラリソースを親に持つ従属リソースプロバイダである。これにもかかわらず、アプリケーションは、USBカメラを要求するとき、カメラがUSBドライバのサービスを利用する必要があることを意識していないことがある。すなわち、アプリケーションなどのリソースコンシューマの中には、タスクを実施するのに必要な従属リソースのすべてを意識しているか知っているわけではないものもある。これらのタイプのリソースコンシューマは、そのタスクを実施するのに必要な「トップレベル」のリソースだけしか意識していないことがある。このタイプのリソースコンシューマの例として、後に開発される技術に先立って書かれるアプリケーションを考えてみる。具体的には、チューナリソースプロバイダからの「チューナリソース」だけを要求するようにテレビジョンアプリケーションを書く。チューナ技術における後の開発により、テレビジョンアプリケーションが元々書かれたときには利用可能でなかった追加のチューナが利用可能になる。これらの新しいチューナは、それ自体もアプリケーションが書かれた後に開発または改良されたものであるかもしれないリソースのコンシューマであることがある。それでもなお、テレビジョンアプリケーションが「チューナリソース」を要求するときは、より古いアプリケーションがより新しいチューナを使用することができるように、新しいチューナリソースおよびその従属リソースを１つ以上の構成内に組み込む方式が必要である。有利にも、述べた実施形態の態様では、各リソースプロバイダがそれ自体のリソースニーズを意識しているような形で、これを行うことができる。したがって、構成の構築段階の間にリソースプロバイダが呼び出されたとき、リソースプロバイダは、適当なすべてのステップを踏んで、構築された構成内でその従属リソースが適切に表されるようにすることができる。
【０１３５】
図15に、リソースコンシューマの知らないリソースであるにもかかわらずリソースが構築中の構成内に表される方式の、ほんの1つを例示するアーキテクチャを示す。以下に提供する記述は、リソースコンシューマがタスクの実施に必要な従属リソースを意識していないという特定の場合に合わせたものであることを理解されたい。リソースコンシューマが、従属リソースプロバイダの1つまたはすべてを知っていることもあり得る。その場合、以下に述べる構成は、例えばリソースコンシューマからリソースプロバイダへのいくつかの直接呼出しを介して構築されることになる。しかしこの考察では、そのような場合ではないものとする。
【０１３６】
以下に述べる処理は、１つ以上の構成が生み出された後で実施され、ステップ306(図3)に対応する。ここでは、1つのアクティビティ122(1)内に1つの構成124(1)だけを示す。１つ以上のアクティビティ内に複数の構成を構築することもできることは明らかなはずである。この時点では、構成はポピュレートされていない。構成がポピュレートされるとき、アクティビティが関連している特定のタスクを実施するためのリソースに寄与する各リソースプロバイダにより、１つ以上のリソース記述子が構成に加えられる。各リソース記述子は、そのリソースプロバイダを識別し、特定の構成に必要な関連するリソースの量を示す。この具体例では、1つのリソースコンシューマだけが利用され、アプリケーション32(1)を構成する。
【０１３７】
図示の例では、アプリケーション32(1)は、そのタスクを実施するためにそれに必要なリソースのサブセット(したがってそれらに関連するリソースプロバイダ)だけしか意識していないかわかっていない。ここで、アプリケーション32(1)は、リソースプロバイダ104(1)および104(2)を含む第1のリソースプロバイダのセットを意識している。アプリケーション32(1)は、第2のリソースプロバイダのセット(すなわちリソースプロバイダ104(3)および104(4))は意識しておらず、わかっていない。これらのリソースプロバイダは、リソースプロバイダ104(2)によって使用され、リソースプロバイダ104(2)がタスクを実施するのを補助する。各リソースプロバイダ104(1)-104(4)は、構成124(1)がポピュレートされているときに他のリソースプロバイダを呼び出すように構成される。アプリケーション32(1)は、いくつかのリソースプロバイダは意識しているので、それに応じてそれらのリソースプロバイダだけを呼び出し、したがってそれらのリソースプロバイダは、それらに関連するリソース記述子で構成124(1)をポピュレートするのを可能にする情報を提供することができる。アプリケーション32(1)が意識していないリソースプロバイダは、それらのリソースを使用する他のリソースプロバイダによって呼び出される。
【０１３８】
例えば図15では、アプリケーションは、リソースプロバイダ104(1)および104(2)を意識している。したがってアプリケーションは、構成をポピュレートまたは構築しようとするとき、これらのリソースプロバイダを直接呼び出す(矢印1501および1502で示す)。述べる実施形態では、リソースプロバイダに対して関数呼出しを行い、アクティビティを(例えばアクティビティIDまたはハンドルによって)識別し、ポピュレートされている構成を(例えば構成ハンドルまたはIDによって)識別する。これらの関数呼出しを受け取るのに応答して、各リソースプロバイダは、リソースマネージャ102に対して関数呼出しを行い、関連するリソースに関する情報を提供する。次いでリソースマネージャ102は、この情報を使用して構成を維持する。図示の例では、このような情報は、関連するリソース記述子の形で提供される。この例では、各リソースプロバイダ104(1)および104(2)は、それぞれリソース記述子R₂およびR₄を構築するのに必要な情報をリソースマネージャ102に提供する。これを、それぞれのリソースプロバイダから発してリソースマネージャ102で終わる矢印1503および1504で示す。しかし、アプリケーションはリソースプロバイダ104(3)および104(4)を意識していないので、これらは直接呼び出さない。そうではなくこの例では、これらのリソースを利用する親リソースプロバイダがこれらを呼び出す。したがって、リソースプロバイダ104(2)がリソースプロバイダ104(3)を呼び出し(矢印1506)、ポピュレートされている構成内のそのリソース記述子に関するアクティビティハンドルおよびリソース識別子をそれに渡す。この呼出しに応答して、リソースプロバイダ104(3)は、リソースマネージャが構成を維持するのに必要な情報によって、リソースマネージャ102を呼び出す(矢印1508)(R₃で示す通信矢印で示すように)。この情報は、リソースプロバイダ104(2)に関するいわゆる関係情報を含む。この例では、関係情報は、リソースプロバイダ104(3)がリソースプロバイダ104(2)と有する子/親の関係を記述する。同様に、リソースプロバイダ104(3)はリソースプロバイダ104(4)に関連するリソースを使用するので、リソースプロバイダ104(3)は、ポピュレートされている構成内におけるそのリソース記述子に関するアクティビティハンドルおよびリソース識別子によって、リソースプロバイダ104(4)を呼び出す(矢印1510)。リソースプロバイダ104(4)は、リソースマネージャが構成を維持できるように、情報(その親を記述する関係情報を含む)によってリソースマネージャを呼び出す(矢印1512)。この通信を、R₁で示す通信矢印で示す。
【０１３９】
この例では、親/子の関係の性質が、いくつかのリソースの従属関係を記述する階層ツリーに編成されてこれを構成する記述子126で示されている。述べる構成は階層ツリーの形をとるが、必ずしも階層ツリーの形ではない構成を含めた他の構成を用いることもでき、例えば、平面構成や直線構成、またはリソース従属関係を記述しない構成を用いることができる。しかし、特定条件が発生する場合には、階層構造を利用するのが有利である。これらの特定条件の例には、リソース予約の失敗、またはリソースのプリエンプトの失敗が含まれる。これらのそれぞれについては、後でより詳細に論じる。
【０１４０】
図16に、前述した実施形態による例示的なリソース管理方法におけるステップを示す。ステップ1600で、リソースプロバイダを呼び出す。図示の例では、この呼出しは、リソースプロバイダによってサポートされるインタフェースに対して行い、１つ以上の構成を構築またはポピュレートすることを望むときに使用する。リソースプロバイダに対する呼出しは、リソースコンシューマ(アプリケーションやシステムコンポーネントなど)から来る可能性もあり、別のリソースプロバイダから来る可能性もある。ステップ1602で呼出しを受け取り、これに応答して、リソースプロバイダはそのリソースに関する情報を供給する。この情報は、ポピュレートされている構成を維持するのに使用される。ステップ1606で、タスクを実施するためにリソースプロバイダがいずれか他のリソースプロバイダに依存しているかどうかを決定する。リソースコンシューマが従属リソースプロバイダを意識していないシステムでは、この決定は個々のリソースプロバイダによって行われる。リソースコンシューマが従属リソースプロバイダを意識しているシステムでは、この決定は、リソースコンシューマと個々のリソースプロバイダのいずれかによって行うことができる。図15の例では、リソースプロバイダ104(1)についての決定は否定となり、したがってステップ1608で、他のリソースプロバイダに対する追加の呼出しがあるかどうかを決定する。追加の呼出しがある場合は、ステップ1608はステップ1602に分岐し、前述のように継続する。特定の構成について追加の呼出しがこれ以上行われない場合は、ステップ1610で、次の構成またはアクティビティを得て前述のように処理を繰り返すか、または終了する。ステップ1606で１つ以上の従属リソースプロバイダがあると決定された場合は、ステップ1612で従属リソースプロバイダを呼び出す。したがって、リソースプロバイダが呼び出されたとき、リソースプロバイダは、他のどのリソースプロバイダを呼び出すかがわかるようにプログラムされる。図15の例では、アプリケーションがリソースプロバイダ104(2)を呼び出したとき、このリソースプロバイダは、リソースプロバイダ104(3)を呼び出すことがわかる(ステップ1606)。したがって、リソースプロバイダ104(3)を呼び出し、ポピュレートされている構成内のそのリソース記述子に関するアクティビティハンドルおよびリソース識別子を渡す。この呼出しを受け取るのに応答して、リソースプロバイダ104(3)は、構成を構築またはポピュレートするのに使用されるそのリソースに関する追加の情報を供給する(ステップ1616)。次いでステップ1616はステップ1606に分岐し、追加の従属リソースがあるかどうか決定する。このステップは、リソースプロバイダ104(2)によって実施される可能性もあり(１つ以上のリソースプロバイダに依存する場合)、またはリソースプロバイダ104(3)によって実施される可能性もある(1つのリソースプロバイダに依存する場合)。この特定の例では、リソースプロバイダ104(2)は1つのリソースプロバイダだけに依存するので、このステップはリソースプロバイダ104(3)によって行われる。この特定の場合、リソースプロバイダ104(3)はリソースプロバイダ104(4)に依存するので、処理はステップ1612-1616の中を進み、追加の呼出しがあるかどうかに応じてステップ1602または1610に進むことになる。
【０１４１】
図示の例では、異なる複数のリソースプロバイダから情報を受け取り、階層ツリーからなる構成の構築に利用する。ツリーはリソースマネージャ102によって維持され、予約およびエラー通知の発布に利用される。
【０１４２】
（エラー通知）
１つ以上のアクティビティに対して１つ以上の構成が構築された後、リソースマネージャ102は、これらのアクティビティのための構成を予約することを試みることができる。これを行うための例示的なプロセスについては、先に詳述してある。構成を予約しようとする途中で、１つ以上のリソースを予約することができないこともあり得る。この場合、予約は失敗し、リソースは利用不可能である。このことが生じたときは、予約失敗をリソースコンシューマに通知することが望ましい。この理由の1つは、リソースコンシューマが、通知を受けた後で代替構成の構築または予約を試みることができるからである。もう1つの理由は、そのタスクを実施することを可能にする様々なオプション、すなわち他のリソース設定をリソースコンシューマに提示することができるからである。
【０１４３】
しかし、失敗したまたはプリエンプトされた従属リソースをリソースコンシューマが意識しない実施形態では、通知はいくらかの困難を呈する。例えば、また図15に関しては、リソースプロバイダ104(4)に関連するリソースを予約しようとする途中で予約が失敗した場合、リソースプロバイダ104(4)によって生成されるエラーメッセージは通常、リソースコンシューマには理解されない独自の用語を含むことになる。このため、理解可能な形でリソースコンシューマに明確に失敗を伝える方式が必要である。階層ツリー構造を利用する実施形態では、エラー報告は単に、リソースコンシューマが認識するリソースプロバイダが見つかるまでリソース従属関係の連鎖を辿ることによって達成される。次いで、認識されるリソースプロバイダを介してリソースコンシューマにエラーを報告する。このプロセスの間、最初に従属リソースプロバイダによって発布されたエラーメッセージは、その独自の形式でその親リソースプロバイダによって受け取られ、次の順番のリソースプロバイダに理解される形式に変換され、しかるべく転送される。最終的に、リソースコンシューマには、リソースコンシューマに理解される用語で表されたエラー通知が届く。
【０１４４】
例として、次の場合を考えてみる。アプリケーションが、30フレーム/秒で再生できるようにUSBカメラリソースを予約しようとする。カメラリソースは利用可能かもしれないが、30フレーム/秒に対応するのに十分なUSB帯域幅がないと仮定する。生成される失敗は、USB帯域幅リソースプロバイダによって生成され、アプリケーションに理解されない独自の用語で定義される。このため、USB帯域幅プロバイダからの失敗は、その親すなわちUSBカメラリソースプロバイダに報告される。USBカメラリソースプロバイダは、失敗を、アプリケーションに報告される形に変換する。
【０１４５】
リソースコンシューマへのエラー報告は、様々な形をとることができる。例えば、エラー報告は単に、知られているリソース、例えばカメラリソースが現在利用可能でないことを報告するものであることがある。あるいは、エラー報告は、失敗の場合にリソースコンシューマに１つ以上のオプションを提示することもできる。例えば、USB帯域幅の不足のせいでUSBカメラリソースが失敗した場合、USB帯域幅リソースプロバイダは、それが有する利用可能な帯域幅をUSBカメラプロバイダに提供することができる。次いでUSBカメラリソースプロバイダは、この情報をアプリケーションに理解される形式に変換し、フレームレート低下(例えば5フレーム/秒)またはウィンドウサイズ縮小のオプションをアプリケーションに提供することができる。この例では、リソースの割当てが異なっていても、タスクはまだ実行できるであろう。以上の例は予約失敗に関して提供したものだが、リソースが別のアクティビティによる使用のためにプリエンプトされるときにも、同じエラー報告の例があてはまる。
【０１４６】
ただし、エラー報告は別の影響を有することもある。具体的には、リソースプロバイダの中には、発生して失敗を引き起こす恐れのある特定の問題に対して修復またはトラブルシューティングを試みるようにプログラムすることができるものもある。この場合、エラーをリソースコンシューマに報告する必要はない。トラブルシューティングは、従属関係の連鎖の中のどの地点でも行うことができる。例えば、ハードウェアデバイスを管理するリソースプロバイダを考えてみる。このハードウェアデバイスは、プリエンプトされたせいで利用可能でないと仮定する。リソースプロバイダは、エラー報告をリソースコンシューマに発布するのではなく、リソースコンシューマには実際のハードウェアデバイスであるかのように見える「仮想デバイス」を提供することができる。リソースコンシューマはこの場合、実際のハードウェアデバイスが利用可能になるまで、そうとは知らずに仮想デバイスを使用することになる。このようにすれば、リソースコンシューマにエラーは報告されず、タスクは依然として実施することができる。
【０１４７】
階層ツリー構成は暗黙的に順序付けを含むので、階層ツリー構成を用いることにより、エラー報告は、平面構成や線形構成よりもずっと効率的になる。平面構成や線形構成を用いることも可能だが、望ましさは劣る。
【０１４８】
図17に、述べた実施形態によるエラー報告方法におけるステップを記述する。ステップ1700で、リソースを階層ツリー構造として表す。これをどのように行うことができるかについての具体的な例および例示的な構造は、先に「構成の構築」のセクションで挙げたものである。ステップ1702で、特定のリソースに関連する特定条件を検出する。この例では、特定条件はエラー条件であり、リソースマネージャ102は、予約失敗またはプリエンプトがあるときがわかるようにプログラムされているので、ステップ1702はリソースマネージャ102(図15)によって行うことができる。これは、リソースマネージャがリソース計算を実行し、リソース競合を決定するからである。次いでステップ1704で、リソースに関連するリソースプロバイダに通知する。これを行うために、リソースマネージャは各プロバイダにコールバックする(すなわちプロバイダは登録時にコールバックを設定する)。リソースマネージャは現エラーパケット(最初は空)をプロバイダに与え、次いで、変換されたパケットをプロバイダから反対に受け取る。次いで、この変換されたパケットを連鎖の中の次のプロバイダに渡し、以下同様にする。プロバイダのうちの1つがそれ自体でエラーを修復する場合もあり、この場合は、それ以上連鎖を上ってパケットを転送する必要はない。
【０１４９】
（ポリシーマネージャ）
ポリシーマネージャは、リソースマネージャと共に、複数のアプリケーションが同じリソースを求めて争うときにどのアプリケーションが限られたリソースにアクセスして使用することができるかを決定する。アプリケーション自体が自発的にリソースを開始および利用することはなく、アプリケーションがリソースによって管理されるアクティビティの優先度を制御することもない。そうではなく、リソースは、ポリシーマネージャにおいて確立されたポリシーに基づいてリソースマネージャによって割り振られる。
【０１５０】
ポリシーには様々なタイプが考えられる。例えばあるポリシーセットは、どのアプリケーションおよび/またはユーザが他を制してリソース使用の優先度を有するかに基づいてリソース割振りを決定する優先度ベースの競合解決と共に使用することができる。用語「優先度」は、従来のスレッド優先度やプロセス優先度の意味では用いず、同じリソースを求めて争うコンシューマ間の調停ポリシーのコンテキストで用いる。優先度は、個々のリソースに割り当てられるのではなく、アプリケーションがリソースマネージャに確立したアクティビティに割り当てられる。
【０１５１】
ポリシーは、どのアクティビティが他のアクティビティと比較して何らかの形で「より重要」かまたは「より重要でない」かを(例えばユーザにとって「より重要」)決定する。これによってリソース管理アーキテクチャは、所望の、ただし限られたリソースを、より重要でないアクティビティからより重要なアクティビティに移行することができる。
【０１５２】
別の実行可能なポリシーは、「先着予約順」である。このポリシーに従うことにより、リソースマネージャは、アクティビティのためのリソースを先着順で予約することになる。
【０１５３】
別の可能なポリシーは、「一番最近の予約順」である。このポリシーを使用すると、リソースマネージャは、一番最近に予約を求めたアクティビティのためのリソースを予約することを試みる。
【０１５４】
別の可能なポリシーには、何らかのタイプのバランスガイドラインまたは提携ガイドラインを達成するためのリソース共用や、ユーザがより重要なアクティビティを選ぶユーザ指定勝利者などが含まれる。
【０１５５】
図2に示すリソース管理アーキテクチャ100は、別個かつ独立のポリシーマネージャ108によって確立されたポリシーに基づいてリソース割振り決定を行うリソースマネージャ102を実装する。ポリシーマネージャ108は、すべてのアクティビティにリソースを割り振ることができないような競合があるときにどのアクティビティがリソースへのアクセスを得るべきかを、アプリケーションから独立して決定する。システムまたはユーザがポリシー110を設定し、ポリシーマネージャ108がこれらを絶対的な優先度に変換する。
【０１５６】
図18に、ポリシーマネージャ108をリソース管理アーキテクチャ100と共に利用する場合を示す例示的なポリシー管理アーキテクチャ1800を示す。リソースマネージャ102は、定義済みのAPI(アプリケーションプログラムインタフェース)120を公開して、リソースを求める要求をアプリケーション32(1)-32(A)から受け入れる。後の「リソースマネージャAPI」の項目で、APIの1つについて詳細に述べる。アプリケーション32は、タスクを実施したいとき、API120を使用してリソースマネージャ102にアクティビティ122を生み出す。アクティビティは、システム中で実施されるタスクに関連するデータ構造である。実施されるタスク1つにつき1つのアクティビティが存在する。図では、リソースマネージャ102は、アプリケーション32(1)-32(A)によって生み出されたアクティビティ122(1)-122(N)を含む。
【０１５７】
ポリシー管理アーキテクチャ1800はソフトウェアによって実現され、この例では、ユーザレベルとカーネルレベルの両方のコンポーネントを有するポリシーマネージャ108を含む。ポリシーマネージャ108は、ユーザコンポーネント1802、カーネルコンポーネント1804、および対話バッファコンポーネント1806を有する。ポリシーマネージャ対話バッファ1806は、ポリシーマネージャカーネルコンポーネント1804とポリシーマネージャユーザコンポーネント1802との間の通知を保持する。
【０１５８】
ポリシーマネージャユーザインタフェース1808がユーザレベルにあるが、これはポリシーマネージャ108の外部にある。ポリシーは、最初にシステム内で生み出されるが、フレキシブルに設計され、したがってユーザは、ポリシーをカスタマイズすることにより、かつポリシーがポリシーマネージャ108によってどのように解釈されて使用されるかを調整することにより、システムを最適化することができる。ユーザはユーザインタフェース1808を介して、ポリシーを規定することができ、また、同じリソースを求めて争うアプリケーション間のリソース予約競合を解決するためにポリシーを適用する際の順番を確立することができる。
【０１５９】
ポリシーマネージャカーネルコンポーネント1804は、アクティビティ優先度および優先度修正を制御するための、ポリシーマネージャ108とリソースマネージャ102との間のインタフェースである。ポリシーマネージャカーネルコンポーネント1804は、リソース管理によって定義されたコールバックオブジェクトを開き、コールバックルーチンを登録する。リソースマネージャ102は、コールバックオブジェクトを使用して、リソースマネージャ102におけるアクティビティイベントをポリシーマネージャ108に通知する。
【０１６０】
ポリシーマネージャユーザコンポーネント1802は、3つのコンポーネントによって実現される。すなわち、(1)前述のポリシーコンポーネント110、(2)ポリシーマネージャディスパッチエンジン1810、および(3)アクティビティリスト1812である。ポリシーコンポーネント110は、リソース割振り決定を行うのに使用されるポリシーと、リソース割振り競合を解決するのに使用されるポリシーとを維持する。ポリシーコンポーネント110中で維持されるポリシーには、固定優先度ポリシー1814、フォーカスベースのポリシー1816、およびユーザ解決ポリシー1818が含まれる。ポリシーは、リソース競合を解決するために、ポリシー列挙数字(1)-(3)で示す順で適用する。すなわち、(1)として列挙した固定優先度ポリシー1814を使用してリソース競合を解決することができない場合は、次いでポリシー(2)のフォーカスベースのポリシー1816を適用し、以下同様にする。
【０１６１】
ポリシーは、アプリケーション32が提供するアクティビティ特有の情報を利用して、システムアクティビティの優先度を決定する。アプリケーション32は、アクティビティに関するポリシー属性を設定することにより、この情報を提供する。この情報は、ポリシー属性を生成、削除、修正、検索するAPIセットを介して提供する。このAPIセットは、後で「リソースマネージャAPI」の項目で詳細に述べるRMU APIを拡張したものである。具体的なAPIセットについては、後で「RMU APIの拡張」の項目で述べる。
【０１６２】
リソースマネージャ102は、アクティビティ122が生成または破壊されたとき、およびリソースがアクティビティ構成のために予約または予約解除されたとき、アクティビティイベントをポリシーマネージャ108に通知する。ポリシーマネージャ108はまた、アクティビティ間にリソース予約競合があるとき、およびユーザ対話式アプリケーションのプロセスがシステムフォーカスを得たときにも通知を受ける。
【０１６３】
ポリシーマネージャディスパッチエンジン1810は、リソースマネージャ102からポリシーマネージャカーネルコンポーネント1804および対話バッファコンポーネント1806を介してアクティビティイベント通知を受け取り、次いでこれらの通知を、次の操作のためにポリシー110にディスパッチする。ポリシー110によってアクティビティが「格付け」された後で、ポリシーマネージャディスパッチエンジン1810は、絶対的なアクティビティ優先度を決定する。ポリシーマネージャディスパッチエンジン1810はまた、すべてのポリシーのリスト、ならびに、各アクティビティの優先度を関連させたアクティビティリスト1812も維持する。
【０１６４】
より具体的には、ポリシーマネージャディスパッチエンジン1810は、アプリケーションがメソッドRMCreateActivity、RMDestroyActivity、RMReserveResources、RMUnreserveResourcesを呼び出したとき、リソースマネージャ102からアクティビティイベント通知を受け取る。イベント通知を受け取ると、ポリシーマネージャディスパッチエンジン1810は、アクティビティリスト1812を更新し、ポリシー110に通知を送る。ポリシー110は、システム中の現アクティビティの相対的な重要度順序付けに従ってアクティビティリストの優先度が再決定されるように、アクティビティデータ構造の優先度の再決定をトリガすることができる。
【０１６５】
アクティビティリスト1812は、現アクティビティのリストをポリシー110に渡してアクティビティの優先度が順序付けされるようにするために、ポリシーマネージャディスパッチエンジン1810によって使用されるオブジェクトである。アクティビティリスト1812は、すべてのアクティビティ122を含むアクティビティ情報オブジェクトの集合として渡される。ポリシー110は、アクティビティ情報オブジェクトの集合を、優先度順のアクティビティサブセットに修正する。ポリシー110がアクティビティ122の格付けを完了した後でポリシーマネージャディスパッチエンジン1810が絶対的なアクティビティ優先度を決定するとき、同じサブセット中のアクティビティは、同じ絶対的な優先度を受け取る。
【０１６６】
固定優先度ポリシー1814は、アクティビティ範疇に関するユーザ定義の重要度順序付けに基づいてアクティビティ優先度を決定する。例えば、ユーザは、特定の重要度順序を有するものとして以下のアクティビティ範疇を定義することができる。
【０１６７】

【０１６８】
アクティビティA1-A3は、リソースマネージャ102に存在している。新しいアクティビティA4が生み出されたとき、リソースマネージャ102は、アクティビティイベントをポリシーマネージャ108に通知する。ポリシーマネージャディスパッチエンジン1810は、アクティビティリスト1812を更新し、アクティビティ122の優先度が順序付けされるように現アクティビティ122のリストをポリシー110に渡す。固定優先度ポリシー1814は、アクティビティリスト1812を、優先度順にアクティビティのサブセットに修正する。
【０１６９】

【０１７０】
フォーカスベースのポリシー1816は、リソース管理アクティビティ122を生み出したプロセスのフォーカス履歴に基づいてアクティビティ優先度を決定する。ユーザ対話式アプリケーションだけが、フォーカス履歴を維持するためにフォーカスベースを必要とする。したがって、フォーカスベースのポリシー1816は、ユーザ対話式アプリケーションによって生み出されたアクティビティ122の優先度を決定する。ユーザ対話式アプリケーションのプロセスがフォーカスを得たとき、このプロセスのアクティビティは最初にフォーカス履歴中で識別される。
【０１７１】
以上の例から、ユーザは、アクティビティA1-A4を特定の重要度順序を有するものとして定義し、その結果、固定優先度ポリシー1814は、各アクティビティがどの優先度セットに属するかを決定した。ユーザがTVの視聴(アクティビティA2、優先度2)を開始し、その後、録画(アクティビティA4、優先度2)を行うことが予定された場合、リソースマネージャ102は、システムの唯一のチューナリソースをどちらのアクティビティに割り振るべきかを決定しなければならない。フォーカスベースのポリシー1816は、ユーザがTVの視聴を開始したとき、TVからの画像を表示するプロセスを、フォーカス履歴中の最初のものとして識別することになる。したがって以下のように、アクティビティA2が、優先度セット2でフォーカス優先度を有することになる。
【０１７２】
【表１】

【０１７３】
ユーザ解決ポリシー1818は、リソースマネージャ102が現在のアクティビティ優先度に基づいて競合を解決することができないときに、リソース予約競合を解決する。例えば、ユーザは以下のように、同時に開始する異なる2つのチャネルを録画するために、予定された2つの録画アクティビティを有する場合がある。
【０１７４】

【０１７５】
最初に、固定優先度ポリシー1814がアクティビティ優先度を決定し、ポリシー110が、アクティビティリスト1812をアクティビティの優先度サブセットに修正することになる。
【０１７６】

【０１７７】
アクティビティA1とA2が両方ともユーザにとって同じ優先度を有すると仮定すると、リソースマネージャ102がシステムの唯一のチューナリソースをどちらのアクティビティに割り振るべきか決定しなければならないときに、リソース競合が発生する。録画Aと録画Bはいずれもシステムフォーカスを得たプロセスではないので、フォーカスベースのポリシー1816はこの競合を解決することはできない。
【０１７８】
ユーザ解決ポリシー1818は、アクティビティA1とA2の間で競合が存在するという情報をポリシーマネージャディスパッチエンジン1810から受け取ると、競合を解決するためにポリシーマネージャユーザインタフェース1808を介してユーザと通信する。ユーザがアクティビティの優先度を再決定すると、ポリシーマネージャのポリシー110は、ユーザの解決選択を反映するようにアクティビティリスト1812を修正する。ユーザ解決ポリシー1818はまた、リソース競合を解決するためのユーザ対話の必要を減らすために、すべてのアクティビティについてそれらの存続期間にわたるユーザ解決履歴も維持する。
【０１７９】
図19に、リソースマネージャ102において生み出されたアクティビティのポリシー管理の方法におけるステップを示す。ステップ1900で、ポリシーマネージャディスパッチエンジン1810は、リソースマネージャ102からアクティビティ通知を受け取る。ポリシーマネージャ108は、アクティビティ生成、アクティビティ破壊、アクティビティ予約、アクティビティ予約解除、およびリソース予約競合に関して通知を受ける。
【０１８０】
アクティビティ通知を受け取ると、ポリシーマネージャディスパッチエンジン1810は、アクティビティリスト1812を更新する(ステップ1902)。次いでポリシーマネージャディスパッチエンジン1810は、アクティビティ通知をポリシー110に転送する(ステップ1904)。
【０１８１】
ステップ1906で、ポリシー110は、アクティビティ通知(ステップ1900)が2つ以上のアクティビティ間のリソース予約競合に関するものであったかどうかを決定する。ポリシーが競合を解決する必要がある場合は(すなわちステップ1906からの「yes」ブランチ)、ポリシーは、競合するアクティビティの相対的な重要度を決定する(ステップ1908)。これは、前述のように、ユーザ解決ポリシー1818を介してユーザと相談することを含む場合がある。
【０１８２】
競合するアクティビティの相対的な重要度を決定した後は(ステップ1908)、またはポリシーが競合を解決する必要がない場合は(すなわちステップ1906からの「no」ブランチ)、ポリシーは、アクティビティの優先度の再決定が必要かどうかを決定する(ステップ1910)。通常、アクティビティ生成およびアクティビティ予約の場合は、アクティビティの優先度の再決定が必要である。アクティビティ破壊またはアクティビティ予約解除の場合は、通常はアクティビティの優先度の再決定は必要ない。
【０１８３】
アクティビティの優先度の再決定が必要ない場合は(すなわちステップ1910からの「no」ブランチ)、ポリシーマネージャ108は、リソースマネージャ102のアクティビティ優先度を更新する必要はなく、方法は終了する(ステップ1912)。アクティビティの優先度の再決定が必要な場合は(すなわちステップ1910からの「yes」ブランチ)、ポリシー110はアクティビティの優先度を再決定する(ステップ1914)。アクティビティの優先度が再決定された後、ポリシーマネージャディスパッチエンジン1810は、アクティビティの絶対的な優先度を決定する(ステップ1916)。次いでポリシーマネージャディスパッチエンジン1810は、リソースマネージャ102のアクティビティ優先度を更新する(ステップ1918)。
【０１８４】
以上の例では、ポリシーが優先度ベースの競合解決と協働すると仮定している。しかし他の状況では、リソースコンシューマ間に優先度がないこともある。すなわち、アプリケーションに関連する各アクティビティが同一の優先度を有するか、優先度を全く有さないことがある。
【０１８５】
以下のシナリオを考えてみる。アクティビティA1は、2つの構成C1およびC2を有する。最も好ましい構成C1は、2つのリソースR₁およびR₂を必要とする。より好ましくない構成C2は、1つのリソースR₁だけを利用する。アクティビティA2は、2つの構成、すなわち(1)2つのリソースR₁およびR₂を利用する最も好ましい構成C1、および(2)1つのリソースR₂だけを利用するより好ましくない構成C2を有する。
【０１８６】
アクティビティA1とA2の好ましい構成を同時に実行しようとすると、競合が生じる。この状況では、リソースマネージャは、両方のアクティビティについて第2の構成を実行することを選択することができ、それにより2つのアクティビティを同時に継続することができる。アクティビティA1とA2の間には優先度の差がないので、一方を犠牲にして他方を実行する必要はない。
【０１８７】
別のポリシーセットは、より少ないアクティビティをそれらの最も好ましい構成で実行するのではなく、できるだけ多くのアクティビティを、各アクティビティがより好ましくない構成を使用する形で実行することに関するものとすることができる。例えば、前述のシナリオで、アクティビティA1がアクティビティA2よりも優先度が高いとしても、ポリシーマネージャは、アクティビティA1だけをその最良の構成で実施するのではなく、両方のアクティビティをそれらの第2の構成で実行する方を好む。
【０１８８】
以下は、ポリシー管理アーキテクチャと共に利用する例示的なメソッドである。
【０１８９】
（CPOLICYMANAGERクラス中のメソッド）
1.void Reprioritize()
a)説明
このメソッドは、ポリシーがアクティビティの優先度の再決定をトリガすることができるように、主ポリシーマネージャディスパッチエンジン(CPolicyManager)によって公開される。例えば、リソースマネージャ中にアクティビティを生み出したアプリケーションにフォーカスが変化したときは、フォーカスポリシーがこのメソッドを使用して、アクティビティの優先度の再決定をトリガする。このメソッドは、ポリシーマネージャディスパッチエンジン中に通知をポストしてから戻る。この通知の結果、ポリシーマネージャディスパッチエンジンはCPolicyManager::CalculatePriorities()を呼び出し、これは、優先度の再決定のためにアクティビティリストをポリシーに渡す。
b)戻り値
なし。
2.HRESULT CalculatePriorities()
a)説明
このメソッドは、システム中のすべてのアクティビティについて優先度を計算するのに使用する。このメソッドはCPolicy::CalculatePriorities()を呼び出す。得られるコンパートメント化されたアクティビティリストは、次いでアクティビティの絶対的な優先度を計算するのに使用され、次に、この絶対的な優先度がリソースマネージャ中に設定される。
b)戻り値
S_OK 成功の場合。
E_FAIL そうでない場合。
3.CActivityList*GetActivityList()
a)説明
このメソッドは、ポリシーがシステム中の現アクティビティのリストを得るのに使用する。例えば、フォーカスベースのポリシーが、関連するリソースマネージャアクティビティを有するプロセスについてのフォーカス履歴を維持するのを開始することができるように、初期化してシステム中の現在のアクティビティリストを得るときに使用する。
b)戻り値
システム中のアクティビティを列挙できるようなメソッドを公開するCActivityListオブジェクトへのポインタ。
4.void OnNewActivity(PRM_ACTIVITY Activity)
a)説明
このメソッドは、ポリシーマネージャディスパッチエンジンが、新しいアクティビティが生み出されたことの通知をリソースマネージャから受け取ったときに、ポリシーマネージャディスパッチエンジンによって呼び出される。このメソッドは、リソースマネージャ中に生み出されたアクティビティを反映する新しいCActivityオブジェクトを生み出し、次いでこの通知を、CPolicy::OnNewActivity()を呼び出すことによってすべてのポリシーに通知する。次いでポリシーは、この通知を処理し、必要なら優先度の再決定をトリガすることができる。
b)パラメータ
Activity-付録に定義するPRM_ACTIVITYタイプの構造体。この構造体は、アクティビティハンドルおよび所有プロセスIDを含む。
c)戻り値
なし。
5.void OnDestroyActivity(PRM_ACTIVITY Activity)
a)説明
このメソッドは、ポリシーマネージャディスパッチエンジンが、アクティビティが破壊されたことの通知をリソースマネージャから受け取ったときに、ポリシーマネージャディスパッチエンジンによって呼び出される。この通知は、CPolicy::OnDestroyActivity()を使用してすべてのポリシーに渡される。アクティビティはこれを使用して、それらの非公開情報をクリーンアップするか、必要なら優先度の再決定をトリガすることができる。
b)パラメータ
Activity-付録に定義するPRM_ACTIVITYタイプの構造体。この構造体は、アクティビティハンドルおよび所有プロセスIDを含む。
c)戻り値
なし。
6.void OnReserve(PRM_ACTIVITY Activity)
a)説明
このメソッドは、ポリシーマネージャディスパッチエンジンが、アクティビティ構成についての予約が完了したことの通知をリソースマネージャから受け取ったときに、ポリシーマネージャディスパッチエンジンによって呼び出される。この通知は、CPolicy::OnReserve()を使用してすべてのポリシーに渡される。
b)パラメータ
Activity-付録に定義するPRM_ACTIVITYタイプの構造体。この構造体は、アクティビティハンドルおよび所有プロセスIDを含む。
c)戻り値
なし。
7.void OnUnreserve(PRM_ACTIVITY Activity)
a)説明
このメソッドは、ポリシーマネージャディスパッチエンジンが、アクティビティ構成についての予約解除が完了したことの通知をリソースマネージャから受け取ったときに、ポリシーマネージャディスパッチエンジンによって呼び出される。この通知は、CPolicy::OnUnreserve()を使用してすべてのポリシーに渡される。
b)パラメータ
Activity-付録に定義するPRM_ACTIVITYタイプの構造体。この構造体は、アクティビティハンドルおよび所有プロセスIDを含む。
c)戻り値
なし。
8.HRESULT OnConflict(PRM_ACTIVITY conflictingActivity, PRM_ACTIVITY*victimArray, ULONG ulNumVictims)
a)説明
これは、リソースマネージャが現在のアクティビティ優先度を用いてリソース競合を解決することができないときに呼び出される。次いでこのメソッドは、CconflictPolicy::OnConflict()を呼び出して、競合に対する解決を得る。競合が解決されると、ポリシーマネージャディスパッチエンジンによって新しいアクティビティ優先度がリソースマネージャ中に設定される。
b)パラメータ
conflictingActivity-これは、予約時にリソース競合を引き起こしたアクティビティである。これは、付録に定義するPRM_ACTIVITYタイプの構造体である。この構造体は、アクティビティハンドルおよび所有プロセスIDを含む。
VictimArray-犠牲者アクティビティであるPRM_ACTIVITY構造体の配列。
UINumVictims-犠牲者アクティビティの数。
c)戻り値
S_OK ポリシーによって競合が解決される場合。
E_FAIL そうでない場合。
【０１９０】
（CBASEPOLICYクラス中のメソッド）
1.virtual HRESULT GetPolicyName(LPTSTR*pBuffer, ULONG*pBufSize)=0
a)説明
ポリシーについての名前を得る。
b)パラメータ
PBuffer-ulBufSizeで指定されたサイズの、名前のコピー先であるバッファへのポインタ。
pBufSize-バッファのサイズ。ポリシー名のサイズがここにコピーされる。
c)戻り値
S_OK 成功の場合。
E_OUTOFMEMORY 十分なメモリが利用可能でない場合。この場合、必要とされるサイズがpBufSizeにコピーされる。
E_FAIL その他の場合。
2.virtual void OnNewActivity(CActivity*pActivity)
virtual void OnDestroyActivity(CActivity*pActivity)
virtual void OnRserveActivity(CActivity*pActivity)
virtual void OnUnreserveActivity(CActivity*pActivity)
a)説明
これらは、ポリシーマネージャディスパッチエンジン(CPolicyManager)がリソースマネージャから通知を受け取ったときに、ポリシーマネージャディスパッチエンジンによって呼び出される通知メソッドである。ポリシーは、これらの通知を受け取ると、CPolicyManager::Reprioritizeを呼び出すことによって優先度の再決定をトリガすることができる。ポリシーはまた、これらの通知を使用して非公開情報を更新することもできる。例えば、フォーカスポリシーは、そのOnNewActivity()が呼び出されたときに、そのフォーカス履歴追跡に新しいアクティビティを追加する。
b)パラメータ
PActivity:アクティビティハンドルと、所有プロセスIDと、その他のアクティビティ特有情報とを含むCActivityオブジェクトへのポインタ。
c)戻り値
なし。
【０１９１】
（CPOLICYクラス中のメソッド(CBasePolicy中のメソッドに加えて)）
1.virtual HRESULT CalculatePriorities(CBucketList*pBucketList)=0
a)説明
このメソッドは、ポリシーマネージャディスパッチエンジン(CPolicyManager)がシステム中のアクティビティについて優先度を計算するために呼び出す。バケットリストは、最初、このメソッドが第1のポリシーに対して呼び出されたときのシステム中のアクティビティすべてが入った単一のバケットを含む。次いでポリシーは、このバケットリストをコンパートメント化する。次いで、コンパートメント化されたバケットリストは、次の処理のためにポリシーマネージャディスパッチエンジンによって他のポリシーに渡される。
b)パラメータ
PBucketList:アクティビティオブジェクトを含むバケットのリストであるCBucketListオブジェクトへのポインタ。
c)戻り値
S_OK 成功の場合。
E_FAIL そうでない場合。
【０１９２】
（CCONFLICTPOLICYクラス中のメソッド(CBasePolicy中のメソッドに加えて)）
1.virtual BOOL OnConflict(CActivity*pConflictingActivity, CAcitivityList*victimActivityList)=0
a)説明
このメソッドは、リソースマネージャが現在のアクティビティ優先度で競合を解決することができないときに、ポリシーマネージャディスパッチエンジン(CPolicyManager)によって呼び出される。このメソッドは、競合するアクティビティが犠牲者リスト中のすべてのアクティビティよりも重要か、またはそうでないかを決定することによって、競合を解決する。
b)パラメータ
PConflictingActivity-予約中に競合を引き起こすアクティビティ。
VictimActivityList-競合アクティビティによる予約を満たすためにリソースを放棄する必要のある犠牲者アクティビティのリスト。
c)戻り値
TRUE PConflictingActivityが犠牲者リスト中のすべてのアクティビティよりも重要である場合。
FALSE そうでない場合。
【０１９３】
（リソースマネージャAPIの拡張）
1.HRESULT SetPolicyAttribute(IN HANDLE hActivity,
IN LPTSTR pAttrName,
IN DWORD dwType,
IN LPBYTE pData,
IN DWORD cbData)
a)説明
ポリシーデータベースにポリシー属性を追加するのに使用するメソッド。アプリケーションは、RMCreateActivity()から受け取ったアクティビティへのハンドルを使用して、ポリシー属性を指定することができる。
b)パラメータ
hActivity-RMCreateActivity()によって返されるアクティビティへのハンドル。
pAttrName-終了ヌル文字を含めたポリシー属性の名前を含むバッファへのポインタ。
dwType-指定の値に記憶されたデータタイプを示すDWORDコード。可能なタイプコードのリストについては、プラットフォームSDK文書中の「レジストリ値のタイプ」を参照されたい。
pData-指定の値についてのデータを含むバッファへのポインタ。
cbData-pDataバッファのサイズ。
2.HRESULT GetPolicyAttribute(IN HANDLE hActivity,
IN LPTSTR pAttrName,
OUT LPDWORD lpType,
OUT LPBYTE pData,
OUT LPDWORD lpcbData)
a)説明
ポリシーデータベースに対してポリシー属性を取り出すのに使用するメソッド。
b)パラメータ
hActivity-RMCreateActivity()によって返されるアクティビティへのハンドル。
pAttrName-終了ヌル文字を含めたポリシー属性の名前を含むバッファへのポインタ。
lpType-指定の値に記憶されたデータタイプを示すコードを受け取る変数へのポインタ。
pData-指定の値についてのデータを受け取るバッファへのポインタ。
lpcbData-返されるpDataバッファのサイズ。
【０１９４】
（インテリジェントインタフェースコンポーネントを備えたアーキテクチャ）
図2に示すリソース管理アーキテクチャ100では、アプリケーション32が、タスクを完了するのに必要なリソースを要求できるほど十分にインテリジェントであると仮定している。しかし、アプリケーションが、それらに必要なリソースの完全なまたはいくらかの知識を有さないことが望ましい場合もある。さらに、リソース管理アーキテクチャ100は、レガシーアプリケーションのある環境に実装される場合もある。このような状況では、レガシーアプリケーションが、リソース管理アーキテクチャの存在を知らなくてもこのようなアーキテクチャを利用できることが望ましい。
【０１９５】
図20に、リソース管理アーキテクチャ2000を示す。このアーキテクチャは図2と同様だが、アプリケーションとの間に入ってリソースを要求するインテリジェントインタフェースコンポーネント2002を備える。インテリジェントインタフェースコンポーネント2002は、カーネルレベルのコンポーネントでもよく(図示のように)、ユーザレベルのコンポーネントでもよい。
【０１９６】
インテリジェントインタフェースコンポーネント2002があると、アプリケーション32は、タスクを完了するのにどのリソースが必要かを知らなくてもよい。例えば、アプリケーション32(1)がTVアプリケーションであるとする。TVアプリケーションは、ストリーミングコンテンツをどのように表示装置上に表示するかについては関係があるが、ストリーミングコンテンツがそもそもどのように受信されて表示されるかについてはほとんど関心がない場合がある。すなわち、TVアプリケーションは、TV番組を受信して表示するために特定のチューナ、デコーダ、およびフィルタが必要であることを完全には意識していないことがある。
【０１９７】
このような場合、インタフェースコンポーネント2002は、テレビジョンの表示など一般レベルのアクティビティにどのリソースが必要かを理解するように設計される。したがって、アプリケーション32(1)が起動されたとき、アプリケーション32(1)は、インタフェースコンポーネント2002を呼び出してTV番組の表示を要求する。インタフェースコンポーネント2002は、リソースマネージャ102と対話して、アクティビティを生み出し、番組を表示するのに必要な同調リソース、デコードリソース、およびフィルタリングリソースの構成を構築する。この時点で、インタフェースコンポーネント2002は本質的に、リソースの予約を要求するためにリソースマネージャに対処する際、図3のプロセスに関して先に述べたようにコンシューマとして振舞う。
【０１９８】
（スケジュールおよびステートレスプロバイダを備えたアーキテクチャ）
図2に示すリソース管理アーキテクチャ100では、リソースプロバイダ104は、それがどのアクティビティに割り振られているか、割り振られたリソースの量、ならびに今割り振られているという概念について、何らかの認識を有することができる。しかし、必ずしもそうである必要はない。そうではなく、リソースプロバイダは、所有アプリケーションまたは割り振られたリソース量を知らないように構成することもできる。この情報は、リソースプロバイダ104のためにリソースマネージャ102によって維持される。この構成では、リソースプロバイダは「ステートレス」であるという。ステートレスなリソースプロバイダの使用が有益である理由の1つは、将来要求されるかもしれないあり得る構成をアーキテクチャが評価できるからである。
【０１９９】
図21にリソース管理アーキテクチャ2100を示すが、このアーキテクチャは、リソースプロバイダ2102(1)、2102(2)、...、2102(P)がステートレスである点で図2のアーキテクチャとは異なる。ステートレスなリソースプロバイダは、時間の概念なしで構成され、したがって、今要求されているのか将来要求されるのかについての認識を有さない。リソースプロバイダ2102は、所与の要求があった時にどのリソースがどれだけ使用されているかだけに関係し、この情報はリソースマネージャからリソースプロバイダに供給される。
【０２００】
アーキテクチャ2100はまた、後の時点におけるリソースセットの割振りを予定するためのスケジューラ2104も備える。スケジューラ2104は、日時を追跡するためのカレンダーを備える。スケジューラ2104は、「もしも」シナリオを実行して、ステートレスリソースプロバイダ2102によって制御されるリソースが選択時に利用可能になるかどうかを決定するように構成される。例えば、スケジューラ2104が、午後8時などのプライムタイムのシステム使用を表す１つ以上のリソース構成のモックアップを作ると仮定する。スケジューラ2104は次いで、これらの構成にリソースを割り振ることができるかどうかリソースプロバイダ2102に尋ねる。プロバイダは時間の概念を有さず、その決定の根拠とすべきステートデータはリソースマネージャから渡されるので、プロバイダは単に、このような構成の集合を満たすことができるかどうかを示すだけである。
【０２０１】
（リソースマネージャAPI）
以下は、リソースマネージャについての例示的なAPIである。以下に述べるAPI呼出しは、カーネルモードで利用可能である。リソースマネージャAPIは、プロバイダインタフェース(セクションA)およびコンシューマインタフェース(セクションB)を含む。
【０２０２】
（A.プロバイダインタフェース）
プロバイダAPI呼出し
1.RmRegisterResource
a)プロトタイプ
NTSTATUS
RmRegisterResource (
IN LPCGUID ResourceType,
IN PUNICODE_STRING ResourceName,
IN PVOID ProviderContext,
IN ULONG AccumulatorSize,
IN RM_PROVIDER_CALLBACK CallbackTable,
OUT PRM_HANDLE ResourceHandle
);
b)説明
リソースプロバイダは、この関数を使用してリソースを登録する。各プロバイダは、サポートする各リソースタイプにつき1度、この関数を呼び出すべきである。
c)パラメータ
ResourceType:リソースのタイプを記述するリソースタイプGUIDへのポインタ。
ResourceName:リソースについてのユーザ可読の名前を指定するユニコードストリング。
ProviderContext:プロバイダコンテキストへのポインタ。このコンテキストポインタは、リソースマネージャからのすべてのコールバック中でプロバイダに返される。
AccumulatorSize:バイトで表したリソースアキュムレータバッファのサイズ。リソースマネージャがリソースアキュムレータを生み出す必要があるときは、リソースマネージャがリソースプロバイダのためにこのメモリ量を割り当てる。
CallbackTable:リソースマネージャがプロバイダにコールバックする際に使用するコールバック関数へのポインタを含む構造体へのポインタ。この構造体は以下のように定義される。
typedef struct_RM_PROVIDER_CALLBACK {
USHORT Version;
USHORT Size;
PRM_PROVIDER_ACCUMULATOR_ADD AccumulatorAdd;
PRM_PROVIDER_ACCUMULATOR_INIT AccumulatorInit;
PRM_PROVIDER_ACCUMULATOR_FREE AccumulatorFree;
PRM_PROVIDER_ACCUMULATOR_COPY AccumulatorCopy;
PRM_PROVIDER_RESERVE_NOTIFY NotifyOnReserve;
PRM_PROVIDER_UNRESERVE_NOTIFY NotifyOnUnreserve;
PRM_PROVIDER_REMOVE_NOTIFY NotifyOnRemove;
} RM_PROVIDER_CALLBACK, *PRM_PROVIDER_CALLBACK;
このコールバック構造体のフィールドは以下のとおりである。
Version:インタフェースのバージョン。プロバイダは、RmRegisterResourceを呼び出す前にこれをRM_VERSION_NUMに設定しなければならない。
Size:構造体のサイズ。プロバイダは、RmRegisterResourceを呼び出す前にこれを(RM_PROVIDER_CALLBACK)のサイズに設定しなければならない。
AccumulatorAdd:リソース属性をリソースアキュムレータに追加するために呼び出す、プロバイダへのコールバック。追加によってリソース割振り超過が生じない場合は、AccumulatorAddはアキュムレータを更新してSTATUS SUCCESSを返すべきである。追加によってリソース割振り超過が生じる場合は、プロバイダは、STATUS_RESOURCE_UNAVAILABLEを返し、バッファを未決定状態にしておくべきである。他のエラーがあれば、そのエラーは適切なエラーコードを返すべきである。
AccumulatorAdd関数についてのプロトタイプは、以下のとおりである。
NTSTATUS
AccumulatorAdd (
IN PVOID ProviderContext,
IN PVOID AttributeBuffer,
IN OUT PVOID Accumulator
);
AccumulatorInit:リソースアキュムレータバッファを初期化するために呼び出す、プロバイダへのコールバック。NULLの場合は、リソースマネージャはバッファを0に初期化する。このコールバックは、リソースアキュムレータバッファが使用される前にリソースアキュムレータバッファに何らかの特別な初期化処理を施す機会をリソースプロバイダに与える。
AccumulatorInit関数についてのプロトタイプは、以下のとおりである。
NTSTATUS
AccumulatorInit (
IN PVOID ProviderContext,
IN OUT PVOID Accumulator
);
AccumulatorFree:リソースマネージャがアキュムレータバッファを開放する前に呼び出す、プロバイダへのコールバック。NULLの場合は、リソースマネージャはアキュムレータバッファを開放するときに何の特別な操作も行わない。このコールバックは、アキュムレータバッファ内のフィールドでポイントされるメモリを解放するかそうでない場合に割振り解除する機会を、リソースプロバイダに与える。リソースプロバイダは、リソースアキュムレータバッファを開放しようとすべきではない。
AccumulatorFree関数についてのプロトタイプは、以下のとおりである。
NTSTATUS
AccumulatorFree (
IN PVOID ProviderContext,
IN OUT PVOID Accumulator
);
AccumulatorCopy:あるリソースアキュムレータバッファを別のリソースアキュムレータバッファにコピーするために呼び出す、プロバイダへのコールバック。NULLの場合は、リソースマネージャは単にバッファを直接コピーするだけである(例えばmemcpyを使用して)。このコールバックは、アキュムレータバッファ内のフィールドでポイントされるメモリをコピーする機会をリソースプロバイダに与える。
AccumulatorCopy関数についてのプロトタイプは、以下のとおりである。
NTSTATUS
AccumulatorCopy (
IN PVOID ProviderContext,
IN PVOID SrcAccumulator,
IN OUT PVOID DestAccumulator
);
プロバイダは、DestAccumulatorを初期化されていないメモリとみなすべきである。具体的には、DestAccumulatorバッファは、AccumulatorCopy関数に渡される前にはどんなAccumulatorInit関数にも渡されない。
NotifyOnReserve:リソースが予約されたことをプロバイダに知らせるための、プロバイダへのコールバック。
NotifyOnReserve関数についてのプロトタイプは、以下のとおりである。
NTSTATUS
NotifyOnReserve (
IN PVOID ProviderContext,
IN PVOID AttributeBuffer,
);
プロバイダは、STATUS_RESOURCE_UNAVAILABLEを返すことにより、この呼出しに対して失敗することがある。例えば、デバイスが故障し、プロバイダがリソースを登録解除できる前にこの通知を受けた場合である。この場合、RMは予約をロールバックする。最も早い機会で、プロバイダはリソースカウントを更新する。
NotifyOnUnReserve:前に予約されたリソース量が未予約であることをプロバイダに知らせるための、プロバイダへのコールバック。
NotifyOnReserve関数についてのプロトタイプは、以下のとおりである。
NTSTATUS
NotifyOnReserve (
IN PVOID ProviderContext,
IN PVOID AttributeBuffer,
);
NotifyOnRemove:アクティビティ内のエラーのせいで、またはツリー中のより高レベルのリソースが除去されたせいで、またはプロバイダがRmRemoveResourceFromConfigurationを呼び出したせいで、前に追加されたリソースが除去されることをプロバイダに知らせるための、プロバイダへのコールバック。
NotifyOnRemove関数についてのプロトタイプは、以下のとおりである。
NTSTATUS
NotifyOnRemove (
IN PVOID ProviderContext,
IN PVOID AttributeBuffer,
);
プロバイダは、このコールバックを使用して、このリソースに関連するどんなデータ構造も解放すべきである。
注1:リソースマネージャは、NotifyOnRemove関数をRMRemoveResourceFromConfiguration内から呼び出すことになる。したがってプロバイダは、RMRemoveResourceFromConfigurationから戻った後は、この予約に関連するどんなデータ構造も解放しようとすべきではない。
注2:リソースマネージャは、NotifyOnRemove関数をRmAddResournceToConfiguration内の失敗の副作用として呼び出すことはない。したがって、何らかの理由でRmAddResourceToConfigurationが失敗した場合は、プロバイダは、このエラーの処理の一部としていかなるデータ構造のクリーンアップをも処理すべきである。
ResourceHandle:リソースマネージャへの他の呼出しで使用する、RmRegisterResourceから返されたハンドル。
d)戻り値
STATUS_SUCCESS:リソースの登録が成功した場合。
他の戻り値はどれもエラーを示す。
2.RmUnregisterResource
a)プロトタイプ
NTSTATUS
RmUnregisterResource (
IN RM_HANDLE ResourceHandle
);
b)説明
リソースプロバイダは、そのリソースをリソースマネージャから登録解除する必要があるときに、この関数を呼び出すべきである。プロバイダは、この呼出しを行う前に、未処理のリソースがあればRmRemoveResourceFromConfigurationを使用してすべての構成から除去すべきである。プロバイダがこれを行わない場合、RMは、あたかもプロバイダがRmRemoveResourceFromConfigurationを呼び出したかのように自動的にすべてのリソースをプロバイダからパージする。
c)パラメータ
ResourceHandle:RmRegisterResourceから元々返されたハンドル。
d)戻り値
STATUS_SUCCESS:リソースの登録解除が成功した。
3.RmLockResource
NTSTATUS
RmLockResource (
IN RM_HANDLE ResourceHandle,
);
a)説明
リソースプロバイダは、プロバイダが表すリソースの量が変化したときなどに、いずれかの内部状態を修正する前にこの関数を呼び出すべきである。これにより、リソースマネージャは、プロバイダのいかなる内部状態の変化とも同期することができる。
b)パラメータ
ResourceHandle:RmRegisterResourceから元々返されたハンドル。
c)戻り値
STATUS_SUCCESS:リソースのロックが成功した。
4.RmUnlockResource
NTSTATUS
RmUnlockResource (
IN RM_HANDLE ResourceHandle,
IN BOOL Update
);
a)説明
リソースプロバイダは、プロバイダが表すリソースの量が変化したときなどに、いずれかの内部状態の修正を完了する前にこの関数を呼び出すべきである。これにより、リソースマネージャは、リソース可用性の変化に応答してシステム中のアクティビティすべてのリソース使用を再計算することができる。
b)パラメータ
ResourceHandle:RmRegisterResourceから元々返されたハンドル。
Update:リソースの量が変化した場合、このパラメータをTRUEに設定すべきである。これは、システムのリソース使用を再計算するようにリソースマネージャに伝えることになる。
c)戻り値
STATUS_SUCCESS:リソースのロック解除が成功した。
5.RmAddResourceToConfiguration
a)プロトタイプ
NTSTATUS
RmAddResourceToConfiguration (
IN PRM_ACTIVITY Activity,
IN PVOID Tag OPTIONAL,
IN RM_HANDLE ParentId,
IN RM_RESOURCE ResourceHandle,
IN PVOID AttributeBuffer OPTIONAL,
IN ULONG AttributeBufferSize,
OUT PRM_HANDLE ResourceId
);
b)説明
構成にリソースを追加する。
c)パラメータ
Activity:前に生み出されたアクティビティオブジェクト。
Tag:追加されつつある子を一意に識別/タグ付けするために親から供給されるポインタ。
ParentId:追加されつつあるリソースの親のリソースハンドル。
ResourceHandle:RmRegisterResourceから返されたハンドル。
AttributeBuffer:プロバイダだけに理解されるデータ(例えばリソース量)を含むバッファへのポインタ。AttribributeBufferSizeが0の場合、これはNULLになるはずである。
リソースマネージャは将来のコールバック関数すべてについてこのバッファの内部コピーを作成することに留意されたい。したがって、リソースプロバイダがこのバッファをそれ自体のスタック上に生み出すこと、および/またはRmAddResourceToConfigurationから戻った後でそれを廃棄することは許容される。しかしリソースマネージャは、この構造体のいずれかの内部フィールドにポイントされたデータをコピーすることはない。このようなデータはプロバイダによって維持されなければならず、いかなるプロセスコンテキスト内でもアクセス可能でなければならない。
AttributeBufferSize:バイトで表したAttributeBufferのサイズ。バッファにデータがない場合は0であるべきである。
ResourceId:このリソース割振りを表すためにこの呼出しによって返されるハンドル。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
6.RmRemoveResourceFromConfiguration
a)プロトタイプ
NTSTATUS
RmRemoveResourceFromConfiguration (
IN PRM_ACTIVITY Activity,
IN RM_HANDLE ResourceId
);
b)説明
構成からリソース割振りを除去する。リソースがプロバイダに割り当てられている場合は、自動的に解放される。
c)パラメータ
Activity:前に生み出されたアクティビティオブジェクト。
ResourceId:RmAddResourceToConfigurationから返されたハンドル。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
7.RmSetResourceAttributes
a)プロトタイプ
NTSTATUS
RmSetResourceAttributes (
IN PRM_ACTIVITY Activity,
IN RM_HANDLE ResourceID,
IN PVOID AttributeBuffer OPTIONAL,
IN ULONG AttributeBufferSize
);
b)説明
リソースに関する属性を変更する。
c)パラメータ
Activity:前に生み出されたアクティビティオブジェクト。
ResourceID:RmAddResourceToConfigurationから返されたハンドル。
AttributeBuffer:新しい属性を含むバッファへのポインタ。AttributeBufferSizeが0の場合は、NULLになるはずである。
AttributeBufferSize:バイトで表したバッファサイズ。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
8.RmgGetDefaultActivityAndConfiguration
a)プロトタイプ
NTSTATUS
RmGetDefaultActivityAndConfiguration (
OUT PRM_ACTIVITY *Activity,
OUT PRM_HANDLE ConfigId
);
b)説明
デフォルトのアクティビティおよび構成を返す。プロバイダは、レガシークライアントの場合など、リソースを追加すべきアクティビティおよび構成がわからない場合に、この呼出しを使用することができる。
c)パラメータ
Activity:デフォルトのアクティビティを返す。
ConfigId:デフォルトの構成を返す。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
9.RmGetAttributeBuffer
a)プロトタイプ
NTSTATUS
RmGetAttributeBuffer (
IN PRM_ACTIVITY Activity,
IN RM_HANDLE ResourceId,
IN PVOID *Buffer
);
b)説明
リソース記述子に関連する属性バッファを得る。
c)パラメータ
Activity:前に生み出されたアクティビティへのポインタ。
ResourceID:上の引数によるアクティビティ内のリソース記述子へのハンドル。
Buffer:属性バッファへのポインタを受け取る変数。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
【０２０３】
（B.コンシューマインタフェース）
コンシューマAPI呼出し
1.RmCreateActivity
a)プロトタイプ
NTSTATUS
RmCreateActivity (
OUT PRM_ACTIVITY ActivityObject,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL,
IN REFGUID TypeGuid
);
b)説明
この関数は新しいアクティビティオブジェクトを生み出す。
c)パラメータ
ActivityObject:生み出されるアクティビティオブジェクトへのポインタがここに返される。
DesiredAccess:アクセス権。例えばACTIVITY_QUERY_STATEやACTIVITY_MODIFY_STATE。
ObjectAttributes:名前やセキュリティなどの標準的なオブジェクト属性を供給する。
TypeGuid:アクティビティのタイプ。事前定義済みタイプのセットのうちの1つ。アクティビティタイプを使用して、他のアクティビティに対する相対的なアクティビティの優先度を決定するのを補助することができる。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
e)注
単一のリソースコンシューマが複数のアクティビティを生み出すことができる。
2.RmReserveResources
a)プロトタイプ
NTSTATUS
RmReserveResources (
IN PRM_ACTIVITY Activity,
IN OUT PRM_ACTIVITY_STATUS ActivityStatus,
IN PKEVENT Event,
IN RM_HANDLE DesiredConfigId,
);
b)説明
RMは、アクティビティ内の構成のためのリソースを予約する。選択される構成は、リソースの可用性およびアクティビティの相対的な優先度に基づく。呼出し元は、任意選択で有効なConfigIdを供給することができ、その場合、RMはその構成を予約することを試みるだけであり、そうでない場合は失敗する。入力時にアクティビティがすでに十分な構成を有する場合(すなわちリソースが構成に割り当てられている場合)、RMはこれを、より望ましい構成が利用可能かどうか調べる要求であると解釈する。RMは、少なくとも既存の構成がリターン時にまだ利用可能であることを保証する(優先度のより高いアクティビティがリソースを必要としているなど、他の理由で既存の構成が立ち退かされていないと仮定して)。
この呼出しは非同期である。ActivityStatusおよびEventのパラメータを使用することにより、この呼出し元は、要求を満たすことができるかどうかをRMが決定するまで待機することができる。
c)パラメータ
Activity:前に生み出されたアクティビティのハンドル。
ActivityStatus:この構造体は、要求が完了した後でRMが要求の状態を返すのに使用する。この構造体は以下のように定義される。
typedef struct_RM_ACTIVITY_STATUS
{
NTSTATUS Status;
ULONG Information;
} RM_ACTIVITY_STATUS, *PRM_ACTIVITY_STATUS;
RmReserveResourcesと共に使用されるとき、Statusフィールドは、操作結果を保持するのに使用され、Informationフィールドは、RMが満たした構成IDを受け取る。Informationフィールドは、Statusの値がSTATUS_SUCCESSである場合のみ有効である。
Event:RMがすぐに予約を完了することができない場合、呼出し元はこのイベントを待機して、操作が完了したときを決定すべきである。
DesiredConfigId:呼出し元は、このパラメータを具体的な構成IDで初期化することにより、そのIDの予約を選択することができる。そうでない場合は0で初期化すべきである。
d)戻り値
STATUS_SUCCESS:RMがアクティビティ内のいずれかの構成を満たすことができる場合。
STATUS_RESOURCE_UNAVAILABLE:優先度のより高い他のアクティビティにリソースが割り当てられているので、現在どの構成も満たすことができない。
STATUS_PENDING:RMがまだ操作を完了することができない場合。この場合、呼出し元は、操作が完了するまでEventハンドルを待機すべきである。
3.RmUnreserveResources
a)プロトタイプ
NTSTATUS
RmUnreserveResources (
IN PRM_ACTIVITY Activity
);
b)説明
アクティビティ内の構成に関連するリソースを予約解除する。
c)パラメータ
Activity:前に生み出されたアクティビティのハンドル。
d)戻り値
STATUS_SUCCESSまたはエラーコード。
4.RmGetActivityStatus
a)プロトタイプ
NTSTATUS
RmGetActivityStatus (
IN PRM_ACTIVITY Activity,
IN OUT PRM_ACTIVITY_STATUS ActivityStatus,
IN PKEVENT Event
);
b)説明
アクティビティの状態の変化に関する情報を返す。この呼出しは非同期である。ActivityStatusおよびEventのパラメータを使用することにより、この呼出し元は、アクティビティの状態が変化したとRMが決定するまで待機することができる。
c)パラメータ
Activity:前に生み出されたアクティビティのハンドル。
ActivityStatus:この構造体は、要求が完了した後でRMが要求の状態を返すのに使用する。この構造体は以下のように定義される。
typedef struct_RM_ACTIVITY_STATUS
{
NTSTATUS Status;
ULONG Information;
} RM_ACTIVITY_STATUS, *PRM_ACTIVITY_STATUS;
RmGetActivityStatusと共に使用されるとき、Statusフィールドは、操作結果を保持するのに使用され、Informationフィールドは理由を受け取る。例として、RM_RELEASE_CONFIGURATIONやRM_BETTER_CONFIGURATIONなどが挙げられる。Informationフィールドは、Statusの値がSTATUS_SUCCESSである場合のみ有効である。
Event:保留中の状態が現在ない場合、呼出し元はこのイベントを待機して、新しい状態情報が入手可能になったときを決定すべきである。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
5.RmCancelRequest
a)プロトタイプ
NTSTATUS
RmCancelRequest(
IN PRM_ACTIVITY Activity,
);
b)説明
この呼出しは、任意の保留中の非同期呼出しをキャンセルするのに使用することができる。現在、RmReserveResourcesおよびRmGetResourceStatusだけが非同期として定義されている。
この呼出しは、RmCancelRequestを呼び出す同じスレッドから開始された任意の保留中RM要求をキャンセルする。RMがトランザクションをキャンセルするときは、RM_ACTIVITY_STATUS構造体のStatusフィールドをSTATUS_CANCELLEDに設定し、対応するイベントを信号で知らせる。
トランザクションをキャンセルした後、呼出し元は、RM_ACTIVITY_STATUS構造体のStatusフィールドを常にチェックして、トランザクションが実際にキャンセルされたかどうか、またはトランザクションがキャンセルされる前にうまく完了したかどうかを検証すべきである。
c)パラメータ
Activity:前に生み出されたアクティビティのハンドル。
d)戻り値
STATUS_SUCCESS:RMが指定のタイプのトランザクションをすべてキャンセルした。
6.RmCreateConfiguration
a)プロトタイプ
NTSTATUS
RmCreateConfiguration (
IN PRM_ACTIVITY Activity,
IN ULONG Merit,
OUT PRM_HANDLE ConfigId
);
b)説明
指定のアクティビティ内に構成を生み出す。
c)パラメータ
Activity:前に生み出されたアクティビティのハンドル。
Merit:このアクティビティ内の他の構成に対して相対的なこの構成の重要性。
ConfigId:生み出される構成へのハンドル。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
7.RmRemoveConfiguration
a)プロトタイプ
NTSTATUS
RmRemoveConfiguration (
IN PRM_ACTIVITY Activity,
IN RM_HANDLE ConfigId
);
b)説明
指定のアクティビティから構成を除去する。
c)パラメータ
Activity:前に生み出されたアクティビティのハンドル。
ConfigId:除去される構成へのハンドル。予約されているリソースがあれば、RMは自動的にクリーンアップする。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
8.RmGetResourceParent
a)プロトタイプ
NTSTATUS
RmGetResourceParent (
IN PRM_ACTIVITY Activity,
IN RM_HANDLE ResourceIdIn,
OUT PRM_HANDLE ResourceIdReturned
);
b)説明
ResourceIdInの親ResourceIdを返す。
c)パラメータ
Activity:前に生み出されたアクティビティのハンドル。
ResourceIdIn:ResourceIdへのハンドル。
ResourceIdReturned:ResourceIdへのポインタ。得られるResourceIdがこの位置に返される。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
9.RmGetResourceChild
a)プロトタイプ
NTSTATUS
RmGetResourceChild (
IN PRM_ACTIVITY Activity,
IN RM_HANDLE ResourceIdParent,
IN RM_HANDLE ResourceIdIn,
OUT PRM_HANDLE ResourceIdReturned
);
b)説明
ResourceIdInの第1の子ResourceIdを返す。
c)パラメータ
Activity:前に生み出されたアクティビティのハンドル。
ResourceIdParent:ResourceIdまたはConfigurationIdへのハンドル。
ResourceIdIn:ResourceIdへのハンドル。1に設定された場合、関数は第1の子リソースを返す。
ResourceIdReturned:ResourceIdへのポインタ。得られるResourceIdがこの位置に返される。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
10. RmGetResourceInformation
a)プロトタイプ
NTSTATUS
RmGetResourceInformation (
IN PRM_ACTIVITY Activity,
IN RM_HANDLE ResourceId,
IN RM_RESOURCE_INFO_TYPE ResourceInfoType,
IN ULONG AvailableBufferSize,
OUT ULONG *RequiredBufferSize,
OUT PVOID *ResourceInfo
);
b)説明
指定のResourceIdに関する情報を返す。
c)パラメータ
Activity:前に生み出されたアクティビティのハンドル。
ResourceId:ResourceIdまたはConfigurationIdへのハンドル。
ResourceInfoType:どのタイプの情報を返すかを指定するenum値。現在定義されている値およびそれらが返す対応バッファは、以下のとおりである。
ResourceInfo_Default
バッファ中に以下の構造体を返す。
typedef struct_RM_RESOURCE_INFO_DEFAULT
{
BOOL FailedReservation; //このリソースが、その最後の予約を失敗した（This resource failed its last reservation）
BOOL DescendantFailedReservation; //子孫が、その最後の予約を失敗した（A descendant failed its last reservation）
BOOL PeerFailedReservation; //同じプロバイダの仲間が、最後の予約を失敗した（Peer of same provider failed last reservation）
GUID ResourcePoolGUID; //リソースGUID（Resource GUID）
RM_HANDLE ResourcePoolHandle; //プロバイダのハンドル（Handle of provider）
ULONG TagLength; //タグバッファのサイズ（Size of tag buffer）
} RM_RESOURCE_INFO_DEFAULT;
ResourceInfo_Tag
リソースが追加されたときに元々指定されたタグを返す。
ResourceInfo_Amount
バッファ中に以下の構造体を返す。
typedef struct_RM_RESOURCE_INFO_AMOUNT
{
ULONG AmountReserved;
ULONG AmountInSystem;
ULONG AmountAvailable;
ULONG AmountUsed;
ULONG AmountUsedPeak;
WCHAR AmountLabel[32];
WCHAR ProviderDescription[128];
} RM_RESOURCE_INFO_AMOUNT;
AvailableBufferSize:バイトで表したバッファサイズ。
RequiredBufferSize:バイトで表した、バッファ中に返されるデータのサイズ。
ResourceInfo:RMが要求のデータを記憶することになるバッファへのポインタ。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
11.RmGetLastAccumulator
a)プロトタイプ
NTSTATUS
RmGetLastAccumulator(
IN PRM_ACTIVITY Activity,
IN RM_HANDLE ProviderHandle,
OUT PVOID *AccumulatorBuffer
);
b)説明
指定されたアクティビティのリソースのいずれかを追加する前の、最後のアキュムレータバッファを返す。
c)パラメータ
Activity:前に生み出されたアクティビティのハンドル。
ProviderHandle:RmRegisterResourceから返されたハンドル。
AccumulatorBuffer:リターンが成功したときにアキュムレータバッファへのポインタがここに記憶される。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
e)コメント
この呼出しは、リソース不足のせいでアクティビティが通常なら立ち退かされることになる場合に、リソースプロバイダが再度アクティビティ内のリソースのバランスをとることができるようにするために、RmGetResourcePeerと共に使用することができる。
12.RmGetResourcePeer
a)プロトタイプ
NTSTATUS
RmGetResourcePeer (
IN PRM_ACTIVITY Activity,
IN RM_HANDLE ResourceProvider,
IN RM_HANDLE ResourceIdIn,
OUT PRM_HANDLE ResourceIdReturned
);
b)説明
指定されたアクティビティ内の、指定されたリソースプロバイダを有する次のリソースのResourceIdを返す。
c)パラメータ
Activity:前に生み出されたアクティビティのハンドル。
ResourceProvider:リソースプロバイダへのハンドル。
ResouceIdIn:ResouceIdへのハンドル。このパラメータが1に設定された場合、関数は指定のプロバイダに関連する第1のリソースを返す。
ResourceIdReturned:ResouceIdへのポインタ。得られるResourceIdがこの位置に返される。
d)戻り値
STATUS_SUCCESSまたは適切なエラーコード。
e)コメント
この呼出しを実装すると、以下のようなRmGetResourceInformationの変更が引き起こされることがある。
1.リソースに関連する属性バッファを返すためにResourceInfo_AttributesのResourceInfoTypeを追加する。
2.RM_RESOURCE_INFO_DEFAULT構造体にULONG AttributeBufferLengthフィールドを追加する。
【０２０４】
（結び）
以上の説明では、構造上の特徴、および/または方法の動作に特有の言葉を使用したが、頭記の特許請求の範囲に定義する本発明は、述べた具体的な特徴または動作に限定されるものではないことを理解されたい。そうではなく、これらの具体的な特徴および動作は、本発明を実施する例示的な形として開示する。
【図面の簡単な説明】
【図１】 一実施形態による、娯楽コンピューティングユニットの形をとる例示的なコンピューティングユニットのブロック図である。
【図２】 図1のコンピューティングユニットによって実現される例示的なリソース管理アーキテクチャのブロック図である。
【図３】 図2のリソース管理アーキテクチャによって実現される例示的なリソース管理方法のステップを記述する流れ図である。
【図４】 述べた実施形態による例示的なリソース予約プロセスを示すブロック図である。
【図５】 述べた実施形態による、リソース予約プロセスで利用される例示的な種々の構造を示すブロック図である。
【図６】 述べた実施形態による、優先度ベースのプリエンプトを用いたリソース割振り方法におけるステップを記述する流れ図である。
【図７】 述べた実施形態による、優先度ベースのプリエンプトを用いたリソース割振りについてのシナリオを示すブロック図である。
【図８】 述べた実施形態による、優先度ベースのプリエンプトを用いたリソース割振りについてのシナリオを示すブロック図である。
【図９】 述べた実施形態による、優先度ベースのプリエンプトを用いたリソース割振りについてのシナリオを示すブロック図である。
【図１０】 述べた実施形態による、優先度ベースのプリエンプトを用いたリソース割振りについてのシナリオを示すブロック図である。
【図１１】 述べた実施形態による、より好ましい構成からより好ましくない構成に動的にダウングレードする方法におけるステップを記述する流れ図である。
【図１２】 述べた実施形態による、より好ましくない構成にダウングレードする方法におけるシナリオの1つを示すブロック図である。
【図１３】 述べた実施形態による、より好ましくない構成からより好ましい構成に動的にアップグレードする方法におけるステップを記述する流れ図である。
【図１４】 述べた実施形態による、より好ましい構成にダウングレードする方法におけるシナリオの1つを示すブロック図である。
【図１５】 構成を構築する方法におけるシナリオの1つを示すブロック図である。
【図１６】 述べた実施形態による、構成を構築する方法におけるステップを記述する流れ図である。
【図１７】 述べた実施形態による、エラー報告方法におけるステップを記述する流れ図である。
【図１８】 例示的なポリシー管理アーキテクチャのブロック図であって、図2のリソース管理アーキテクチャを用いて実現されるポリシーマネージャをさらに示す図である。
【図１９】 図18のポリシー管理アーキテクチャによって実現される例示的なポリシー管理方法におけるステップを記述する流れ図である。
【図２０】 図2と同様だがインテリジェントインタフェースコンポーネントをさらに備える、別の例示的なリソース管理アーキテクチャのブロック図である。
【図２１】 図2と同様だがスケジューリングコンポーネントをさらに備える、別の例示的なリソース管理アーキテクチャのブロック図である。

Claims (18)

1. リソース管理アーキテクチャを有するシステムであって、
   リソースに関連する複数のリソースプロバイダと、
   前記リソースプロバイダから提供されるリソースを利用する複数のコンシューマと、
   各々が前記複数のリソースプロバイダの少なくとも１つのリソースプロバイダを識別するリソース構成に関して前記リソースプロバイダから提供されるリソースへのアクセスを前記コンシューマのために調停するリソースマネージャと
   を含み、
   前記コンシューマが前記リソースマネージャにおいてアクティビティを生み出し、各アクティビティは、対応するコンシューマによって実施されるタスクと関連し、前記アクティビティは、前記調停のために使用される優先度の情報を有し、
   前記コンシューマが前記リソースマネージャにおいて各アクティビティについての１つまたは複数の構成を構築し、各構成がタスクを実行する１つまたは複数のリソースのセットを識別し、前記各構成は、１つまたは複数のリソース記述子を含み、前記各記述子は、前記リソースに関連するリソースプロバイダの識別子、および前記タスクを実行するのに必要なリソースの量を含むデータを保持することを特徴とするシステム。
2. 前記リソースプロバイダおよび前記リソースマネージャがカーネルレベルに存在することを特徴とする請求項１に記載のシステム。
3. 少なくとも１つの前記コンシューマがアプリケーションプログラムを含むことを特徴とする請求項１に記載のシステム。
4. 少なくとも１つのリソースプロバイダが、少なくとも１つの他のリソースプロバイダから提供されるリソースのコンシューマとして行動することを特徴とする請求項１に記載のシステム。
5. 前記コンシューマが、前記リソースを予約する要求を前記リソースマネージャに提出することを特徴とする請求項１に記載のシステム。
6. 前記リソースプロバイダが、前記コンシューマが前記リソースを最初に予約せずに使用することができないようにすることを特徴とする請求項５に記載のシステム。
7. 前記リソースプロバイダが前記リソースマネージャに登録することを特徴とする請求項１に記載のシステム。
8. 前記リソースプロバイダの各々が、割振りに利用可能な関連するリソースの量を決定するリソース定量化部を含むことを特徴とする請求項１に記載のシステム。
9. 前記リソース定量化部が、割振りにいくつのリソースが利用可能かについてのカウントを維持するカウンタを含むことを特徴とする請求項８に記載のシステム。
10. 前記リソース定量化部が、リソースを割振りに利用できる期間を追跡する時間追跡コンポーネントを含むことを特徴とする請求項８に記載のシステム。
11. 前記リソース定量化部が、割振りに利用可能なリソースのパーセンテージを追跡するパーセンテージ追跡コンポーネントを含むことを特徴とする請求項８に記載のシステム。
12. 前記リソースマネージャがアプリケーションプログラムインタフェースを公開し、前記リソースプロバイダおよび前記コンシューマが、前記アプリケーションプログラムインタフェースを介して前記リソースマネージャへの呼出しを行うことを特徴とする請求項１に記載のシステム。
13. 割振りポリシーを確立するポリシーマネージャをさらに含み、前記リソースマネージャが前記割振りポリシーを使用して前記リソースへのアクセスを調停することを特徴とする請求項１に記載のシステム。
14. 前記コンシューマのために１つまたは複数のリソースのセットを要求するインタフェースコンポーネントをさらに含み、前記インタフェースコンポーネントが前記リソースマネージャに要求を提出することを特徴とする請求項１に記載のシステム。
15. リソース管理アーキテクチャを有するシステムであって、
    リソースに関連する複数のリソースプロバイダと、
    前記リソースプロバイダから提供されるリソースを利用する複数のコンシューマと、
    各々が前記複数のリソースプロバイダの少なくとも１つのリソースプロバイダを識別するリソース構成に関して前記リソースプロバイダから提供されるリソースへのアクセスを前記コンシューマのために調停するリソースマネージャと
    を含み、
    前記コンシューマの１つが、実行されるタスクに関連して前記リソースマネージャにおいてアクティビティを生み出し、かつ該アクティビティの複数の構成を構築し、前記アクティビティは、前記調停のために使用される優先度の情報を有し、各構成が該タスクを実行する１つまたは複数のリソースのセットを識別し、
    前記リソースマネージャは、特定のリソースをアクティビティに再割振りし、またはアクティビティから取り去って再割振りするために、アクティビティを前記構成のうちの１つから前記構成のうちの別の１つに切り替えるように構成されることを特徴とするシステム。
16. 前記リソースマネージャは、前記ある構成を前記他の構成に自動的に切り替えるように構成されることを特徴とする請求項１５に記載のシステム。
17. 前記構成は、好ましさ（preference）の順にランク付けされ、前記リソースマネージャは、より好ましい構成からより好ましくない構成に前記アクティビティを切り替えるように構成されることを特徴とする請求項１５に記載のシステム。
18. リソース管理アーキテクチャを有するシステムであって、
    リソースに関連する複数のリソースプロバイダと、
    前記リソースプロバイダから提供されるリソースを利用する複数のコンシューマと、
    各々が前記複数のリソースプロバイダの少なくとも１つのリソースプロバイダを識別するリソース構成に関して前記リソースプロバイダから提供されるリソースへのアクセスを前記コンシューマのために調停するリソースマネージャと
    を含み、
    前記コンシューマが前記リソースマネージャにおいてアクティビティを生み出し、各アクティビティは、対応するコンシューマによって実施されるタスクと関連し、前記アクティビティは、前記調停のために使用される優先度の情報を有し、
    前記コンシューマが前記リソースマネージャにおいて各アクティビティについての１つまたは複数の構成を構築し、各構成がタスクを実行する１つまたは複数のリソースのセットを識別し、前記各構成は、１つまたは複数のリソース記述子を含み、前記各記述子は、前記リソースに関連するリソースプロバイダの識別子、および前記タスクを実行するのに必要なリソースの量を含むデータを保持し、
    前記リソースプロバイダは、実時間の概念なしで構成され、
    その後になって前記リソースのセットの割振りをスケジュールするスケジューリングコンポーネントをさらに含むことを特徴とするシステム。

Images