(57)【要約】【課題】コンピューティング装置においてリソースを管理して、デバイス上で動作する競合するクライアントの間においてリソースの割り当てを円滑にすることを提供すること。【解決手段】バジェットの階層が構築されて、リソースプロバイダによって１つまたは複数のクライアントに割り当てられたリソースの総計の使用量に対する制限を符号化する。リソースマネージャは、リソースプロバイダによる１つまたは複数のクライアントにリソースを割り当てる要求を、階層を構成するバジェットに従って承認し、調停する。リソースマネージャは、リソースの利用可能性および不足をクライアントに通知して、階層のバジェットの中において符号化された制限の遵守を促進する。【選択図】図１
2006236351.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータシステムにおけるリソースの効率的な管理を円滑にする方法であって、
第１のバジェットにおける少なくとも１つのクライアントによるリソースの使用に関係する値を追跡するステップであって、前記値は、前記クライアントに割り当てることが可能な前記リソースの最大量を表す第１の限度と、前記クライアントに既に割り当てられている前記リソースの量を表す第１のコミットとを含むステップと、
前記リソースのプロバイダによって、前記リソースのうち一定の量を前記少なくとも１つクライアントに割り当てるクライアント要求を承認する要求を受け取るステップと、
前記要求された量だけ前記第１のコミットを増加させることにより、前記第１のコミットが前記第１の限度を超えない場合、前記クライアント要求を承認するステップと
を備えたことを特徴とする方法。
【請求項２】
前記要求された量が前記少なくとも１つのクライアントに割り振られたという確認を、前記リソースのプロバイダから受け取るステップと、
前記第１のコミットを前記要求された量だけ増加させるステップと
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１の限度は、ソフト限度であり、前記第１のコミットを前記要求された量だけ増加させるステップは、通常のコミットを前記第１の限度まで増加させるステップを含み、
前記第１の限度を超える剰余量を前記リソースのプロバイダに超過コミットとして報告するステップであって、前記通常のコミットは、通常のサービスレベルで前記少なくとも１つのクライアントに割り当て可能な量を表し、前記超過コミットは、低下したサービスレベルで前記少なくとも１つのクライアントに割り当て可能な量を表すステップをさらに備えたことを特徴とする請求項２に記載の方法。
【請求項４】
前記値は、前記クライアントに事前割り当てすることが可能な前記リソースの最大量を表す第１の確保をさらに含み、前記第１の確保は、前記第１の限度によって限界が定められており、
前記リソースのプロバイダによって、前記リソースのうち一定の量を前記少なくとも１つのクライアントに事前割り当てするクライアント要求を承認する要求を受け取るステップと、
前記第１のコミットを前記要求された量だけ増加させることにより、前記第１のコミットが前記第１の確保を超えない場合、前記クライアント要求を承認するステップと
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項５】
前記要求された量は前記少なくとも１つのクライアントに事前割り当てされているという確認を前記リソースの前記プロバイダから受け取るステップと、
前記第１のコミットを前記要求された量だけ増加させるステップと
をさらに備えたことを特徴とする請求項４に記載の方法。
【請求項６】
第２のバジェットにおける少なくとも１つの他のクライアントによる同一のリソースの使用に関係する値を追跡するステップであって、前記値は、前記他のクライアントに割り当てられることが可能な前記リソースの最大量を表す第２の限度と、前記他のクライアントに既に割り当てられている前記リソースの量を表す第２のコミットとを含むステップと、
前記第１のバジェットおよび前記第２のバジェットの前記複数のクライアントのすべてに割り当て可能な前記リソースの最大量を表す有効限度の値を有する共通のルートバジェットの子として、前記第１のバジェットおよび前記第２のバジェットを階層化して関係付ける（ｈｉｅｒａｒｃｈｉｃａｌｌｙ  ｒｅｌａｔｅ）ステップと、
前記リソースのプロバイダによって、前記リソースのある量を前記少なくとも１つの他のクライアントに割り当てるクライアント要求を承認する、要求を受け取るステップと、
前記第１のコミットと前記第２のコミットとを総計するステップと、
前記総計されたコミットを前記要求された量だけ増加させることにより、前記総計されたコミットが前記有効限度を超えない場合、前記クライアント要求を承認するステップと
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項７】
前記リソースの使用はフレーバ制限をさらに受け、前記フレーバ制限は前記リソースの使用の種類に基づいており、さらに、前記クライアント要求により、前記クライアントが前記リソースを使用しても、前記リソースの使用の前記種類に関する前記フレーバ制限を超えない場合、前記クライアント要求は承認されることを特徴とする請求項１に記載の方法。
【請求項８】
前記リソースの前記プロバイダによって、前記リソースを求めるクライアント要求を調停する要求を受け取るステップと、
前記リソースが現在割り当てられている目標クライアントに関する相対優先順位、および少なくとも１つの許されたアクションを特定するステップと、
前記相対優先順位、および前記少なくとも１つの許されたアクションに基づき、前記リソースを、前記目標クライアントから回収することが可能である場合、前記要求側クライアントに有利に調停するステップと
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項９】
前記目標クライアントに関する前記相対優先順位、および前記少なくとも１つの許されたアクションを特定するステップは、ポリシーデータベースに対する問い合わせ（ｑｕｅｒｙ）を生成するステップを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記リソースを回収することが可能な前記目標クライアントに、前記リソースを自発的に譲るように通知するステップをさらに備えたことを特徴とする請求項８に記載の方法。
【請求項１１】
前記少なくとも１つの許されたアクションは、受動的アクション、事前対応アクション、および積極的アクションの１つであることを特徴とする請求項８に記載の方法。
【請求項１２】
コンピューティング装置におけるリソースを管理するシステムであって、
リソースに対する制限を符号化するバジェット階層と、
前記バジェット階層におけるバジェットに関連付けられたクライアントのために動作するプロセスと、
前記バジェット階層の中に符号化された制限に基づき、前記リソースのうち一定の量を求めるクライアント要求を承認するリソースマネージャであって、前記制限は、リソースプロバイダが前記クライアントに割り当てることが可能な前記リソースの最大量を表す限度を含むリソースマネージャーと、
前記認証されたクライアント要求に応答して、前記リソースの前記要求された量を前記プロセスに割り当てるリソースプロバイダと
を備えたことを特徴とするシステム。
【請求項１３】
前記リソースマネージャは、前記リソースの前記要求された量を前記プロセスに割り当てることにより、前記クライアントが、前記リソースに関する該クライアントのバジェットに組み込まれた限度を超えない場合、前記要求を承認し、前記リソースの前記要求された量を前記プロセスに割り当てることにより、前記クライアントが、前記リソースに関する該クライアントのバジェットに組み込まれた限度を超える場合、前記要求を無効にすることを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記制限は、前記クライアントに既に割り当てられている前記リソースの量を表すコミットメントをさらに含み、前記コミットメントは、前記限度内で割り当てられた量を表す通常のコミットメントと、前記限度を超えて割り当てられた量を表す超過コミットメントとを含み、前記リソースマネージャは、前記通常のコミットメントに追加される前記要求された量が前記リソースに関する該クライアントのバジェットに組み込まれた限度の範囲内である場合、前記クライアント要求を承認することを特徴とする請求項１２に記載のシステム。
【請求項１５】
前記制限は、前記リソースプロバイダによって前記クライアントに事前割り当てすることが可能な前記リソースの最大量を表す確保をさらに含み、前記確保は前記限度によって制約されており、さらに、前記リソースマネージャは、前記リソースの前記要求された量を前記プロセスに事前割り当てすることにより、前記クライアントが、前記リソースに関する該クライアントのバジェットに組み込まれた確保を超えない場合、前記クライアント要求を承認し、前記リソースの前記要求された量を前記プロセスに事前割り当てすることにより、前記クライアントが、前記リソースに関する該クライアントのバジェットに組み込まれた確保を超える場合、前記要求を無効にすることを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記バジェットの階層における前記制限は、前記階層を上に行く方向で総計されて（ａｇｇｒｅｇａｔｅｄ  ｕｐ  ｔｈｅ  ｈｉｅｒａｒｃｈｙ）、前記バジェットの階層のサブツリー内のバジェットのすべてのクライアントに割り当てられることが可能な前記リソースの最大量を提供し、前記バジェットの階層内のすべてのバジェットのすべてのクライアントに割り当てられることが可能な前記リソースの最大量によってさらに管理されることを特徴とする請求項１４に記載のシステム。
【請求項１７】
前記リソースが現在割り当てられている目標クライアントに関する相対優先順位と、許されたアクションとの少なくともどちらかを提供するポリシーモジュールをさらに備え、前記リソースマネージャは、前記相対優先順位と前記許されたアクションとの少なくともどちらかに基づき、前記リソースが現在割り当てられている前記目標クライアントのうちの少なくとも１つから前記リソースを回収することが可能な場合、前記要求側クライアントに有利に調停することにより、前記クライアント要求を調停することを特徴とする請求項１３に記載のシステム。
【請求項１８】
前記許されたアクションは、受動的アクション、事前対応アクション、および積極的アクションの１つであることを特徴とする請求項１７に記載のシステム。
【請求項１９】
コンピューティング装置におけるリソースを管理する命令を格納したコンピュータ読み書き可能な記録媒体であって、前記命令は、
クライアントにリソースを割り振ることに関する、前記クライアントに割り当て可能な最大リソース量を表す限度を、バジェット階層に編成されたバジェットの中に符号化するステップと、
制限されたリソースを求める要求を行うクライアントに関連付けられたアクティブな、前記バジェット階層内の１のレベルにあるバジェットを獲得するステップと、
前記クライアントに前記リソースを割り当てることにより、前記クライアントが、前記アクティブなバジェットの中、および前記バジェット階層内で前記アクティブなバジェットの前記１のレベル以上のレベルにおけるあらゆるバジェットの中の、前記バジェットに組み込まれた限度を超えない場合、前記要求を承認するステップと
を備えたことを特徴とするコンピュータ読み書き可能な記録媒体。
【請求項２０】
前記命令は、
現在前記リソースが割り当てられている目標クライアントを特定するステップと、
前記特定された目標クライアントの各々に関連付けられた相対優先順位、および許されたアクションセットを獲得するステップと、
前記関連付けられた相対優先順位、および許されたアクションセットに従って前記目標クライアントのうちの少なくとも１つから前記リソースを回収することにより、前記クライアント要求を調停するステップと
をさらに備えたことを特徴とする請求項１９に記載のコンピュータ読み書き可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
一般に、本発明は、コンピューティング装置におけるリソースに関し、より詳細には、コンピューティング装置におけるリソースを管理することに関する。
【背景技術】
【０００２】
オペレーティングシステムは、リソース管理スキームを使用して、アプリケーション間の衝突を抑制し、優先順位を付けてリソース割り当て、またはリソース割り当てを別の形で制御するポリシーを適用し、一般に、多くの独立のソフトウェアアプリケーションを実行しているシステムの全体的な動作を管理する。
【０００３】
既存のリソース管理スキームは、大抵、先着順サービス（ｆｉｒｓｔ−ｃｏｍｅ  ｆｉｒｓｔ−ｓｅｒｖｅｄ）である。Ｄｉｇｉｔａｌ  ＶＡＸ／ＶＭＳオペレーティングシステム、ＢＳＤ／ＵＮＩＸ（登録商標）オペレーティングシステム、およびＷｉｎｄｏｗｓ（登録商標）ＮＴオペレーティングシステムにおいて使用されるような、カウンタベースのリソース管理スキームは、１つまたは複数のプロセスによってリソースを使用する回数についての絶対カウントを保持しようと試みる。カウンタは、例えば、カーネルメモリ利用率、中央処理装置（ＣＰＵ）利用率、または入出力（Ｉ／Ｏ）データ転送を記録するようにすることができる。
【０００４】
カウンタベースのリソース管理スキームの抱える問題の１つは、どのぐらいが限度であるかを決定すること、およびその限度に達し、またはその限度を超えたと決定することである。しばしば、限度は、限度に達すると、単に引き上げられる。Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムの場合は、あるリソースの使用に対する限度は、一般に、ジョブオブジェクト、カーネルクォータ、ＣＰＵアフィニティ（ａｆｆｉｎｉｔｉｅｓ）、および様々のアドホックなリソース固有の限度などの機構を介して設定される。また、例えば、メモリマネージャが、カーネル仮想アドレス空間がどのように使用されるかに基づいてその空間の使用に上限を設けるなどの場合には、機能にあわせてリソースの使用に上限を設けることも可能である。もう１つの例には、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）によりカーネルプールを使用する場合、現在、伝送されているパケットのタイプに基づいて動的に上限が設けられるものがあり、例えば、音声データを表すパケットは、高品質の音声伝送を可能にするため、音声データを表さないパケットに比し、カーネルプールを使用する場合、より高い上限を設定することがある。
【０００５】
リソース管理スキームには、例えば、ＣＰＵリソースのスケジュールにおいて現在行われているように、リソース競合を解決する（ａｒｂｉｔｒａｔｅ）のを支援するために、リソースを求めて競合するプロセスの相対的優先順位を設定することに基づいてなされるものがある。さらに、リソース管理スキームは、特権に基づくことができる。すなわち、現在行われているように、例えば、プロセスにメモリ内の物理的ページをロックする特権を付与することを要求することにより、リソースの割り当てを行うための一部の動作を実行する特権をプロセスが有するようを要求することに基づくことができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
既存のリソース管理スキームには、いくつかの問題が存在する。ほとんどのリソースはシステム全体にわたるので、先着順サービスでリソースを管理することにより、サービス拒否問題が発生する可能性がある。これは、他のアプリケーション、他のユーザ、またはネットワーク可視（ｎｅｔｗｏｒｋ  ｖｉｓｉｂｌｅ）サービスにより、リソースが制限なく消費されてしまう可能性があるからである。既存の機構に頼ることによって、逸脱したアプリケーション、利己的なアプリケーション、または悪意のあるアプリケーションがリソースを既に消費しているという理由で、アプリケーションを実行するのに必要なリソースをしばしば獲得することができないという、予測できない環境がもたらされる。この問題は、大型の端末サービスマシンにおいて特に深刻となる。
【０００７】
優先順位ベースのリソース管理スキームでは、競合はただ悪化するだけである。すなわち、アプリケーションは、他のアプリケーションに対する自らの優先順位を独立に確立することができないので、一般に、リソースを公平に共有する優先順位を設定することはできない。ほとんどの場合、優先順位を公平に定義することさえできない。このため、ＣＰＵリソースの場合では、しばしば、アプリケーションは、自らの優先順位を作為的に（ａｒｔｉｆｉｃｉａｌｌｙ）上げて、別に要求が存在するかどうかに関わりなく、アクセスを可能にする。最終的に、アプリケーションは、上昇させられた優先順位レベルで競合して、優先順位スキームの目標である公平性のポリシーが価値のないものとなる。
【０００８】
リソース競合に対する制限が全くないと、あらかじめ定義されたレベルのサービスを特定のアプリケーションに提供することが非常に困難である。管理者またはサービスプロバイダは、一般に、アプリケーションに関する最小リソース量も、最大リソース量も指定することが不可能である。これにより、サーバ統合（ｃｏｎｓｏｌｉｄａｔｉｏｎ）シナリオにおいて問題が生じ、管理者またはサービスプロバイダは、例えば、優先順位を動的に調整して、特定のアプリケーションによるＣＰＵ利用率を管理することにより、統合を支援することを余儀なくされる。
【０００９】
一部のシステムにおいて、リソース保証を使用することによって、リソース管理に固有の問題のいくつかを克服しようと試みられてきた。単に限度または優先順位を設定する代わりに、アプリケーションは、暗示的に割り当てられたリソースに関して、前もって約定を定めることができる。保証は、リソースの要求と、リソースの実際の使用との間に間接的（ｉｎｄｉｒｅｃｔｉｏｎ）な処理を追加することにより、リソースを求める層の瞬間的な競合をなくす。先着順サービスの形でリソースを明示的に確保することにより、クライアントは、任意の他の保証が未処理であるかどうかに関わらず、リソースの将来の使用に関する約定（例えば、保証されたＩ／Ｏ待ち時間）を定める。マルチメディアアプリケーションの実行のためにリソース保証が特に重要である一例として、大域幅が挙げられる。しかし、保証自体リソースであり、保証の割り当ては失敗する可能性がある。
【００１０】
パーソナルコンピュータが、家庭内で、多くの新たな役割を引き受けるなかで、リソース管理は、特に、リソース使用における競合を管理する際に、より重要になる。さらに、サーバコンピュータは、より予測可能な動作環境を提供するために、より効率的にリソースを管理する必要がある。
【００１１】
先行技術の抱える以上の諸問題は、コンピューティング装置におけるリソースを管理するための方法、システム、コンピュータプログラム製品、およびデータ構造に向けられた、本発明の諸原理によって克服される。本発明は、コンピューティング装置におけるリソースを管理して、デバイス上で実行される競合するプロセスまたはスレッドの間におけるリソースの割り当てを円滑にするための方法、システム、コンピュータプログラム製品、およびデータ構造にさらに向けられる。
【課題を解決するための手段】
【００１２】
本発明の一態様によれば、バジェットが、１つまたは複数のクライアントに関するリソース要件およびリソース制限を符号化する。クライアントに代行して実行される任意の数のプロセス、スレッド、またはプロセスとスレッドの組み合わせが、単一のバジェットに関連することができる。また、特定のプロセスまたはスレッドが、複数のバジェットに関連することもできるが、任意の一時点で、１つだけのバジェットに支配されている。複数のプロセスおよびスレッドは、他にも考慮されるなかで、とりわけ、アクティブなバジェットに符号化された要件および制限に基づき、リソースを求めて競合する。
【００１３】
本発明のさらに別の態様によれば、特定のプロセスまたはスレッドに関するアクティブなバジェットは、プロセスまたはスレッドが代行で実行されているクライアントに少なくともある程度依存して、バジェットの存続期間中に多数回、変更される可能性がある。現在、実行されているスレッドのセットの上で、１つまたは複数のクライアントに関するサービスを実行しているサービスプロセスの場合、現在プロセスまたはスレッドが代行で実行されているクライアントは、擬似リソース−クライアントＩＤを使用して特定することができる。擬似リソース−クライアントＩＤは、クライアントのリソースＩＤを装うことによってプロセスまたはスレッドをクライアントに一時的に関連付けて、クライアントのアクティブなバジェットを探し出し、そのバジェットに一時的に結び付く。通常、これは、現在のクライアントスレッドに関するアクティブなバジェットを検査することによって達せられる。
【００１４】
本発明の別の態様によれば、バジェットは、少なくともある程度、（複数の）クライアントに関してサポートされる各リソースに関する３つの量の１つまたは複数を保持することにより、バジェットに関連するクライアント（またはクライアント群）に関するリソース要件およびリソース制限を符号化し、それらの量は、限度「Ｌ」、確保「Ｒ」、およびコミット「Ｃ」を示す。
【００１５】
本発明の一態様によれば、バジェット限度「Ｌ」は、バジェットに関連するクライアントが、サポートされるリソースのプロバイダ、すなわち、リソースプロバイダから獲得することが可能なリソースの量に対する最大限度を表す。限度は、ハード限度であることも、ソフト限度とすることができ、この区別により、閾値に達した場合の適切な動作を規定する。この限度は、ハード限度の場合、絶対最大限度であり、リソースを割り当てる要求を失敗させる（ｆａｉｌ）こと、またはレート制御を使用することなどの、１つまたは複数のアクションを行うことにより、その限度を実施することができる。しかし、限度が、ソフト限度である場合、その限度は、リソースを割り当てるクライアントの要求を満たすか否かを決める際に、関係のあるリソースプロバイダに対する勧告（ａｄｖｉｓｏｒｙ）の役割をするだけである。通常、リソースプロバイダは、リソース利用レベルに基づき、ソフトリソース割り当てを提供するかどうかの判定を行い、必要とされる場合に、最小限のパフォーマンスオーバーヘッドで割り当てを回収（ｒｅｃｌａｉｍ）することが可能かどうかを判定する。
【００１６】
本発明のもう１つの態様によれば、バジェット確保「Ｒ」は、確保「Ｒ」の量までクライアントのためにリソースを割り当てる将来の要求が成功する可能性を確実にする、リソースの事前割り当てを表し、本明細書では保証とも呼ぶ。バジェット確保「Ｒ」は、限度がハード限度であるか、ソフト限度であるかに関わらず、バジェット限度「Ｌ」によって制約される。バジェット確保「Ｒ」は、そのバジェット確保からある分量を各々の割り当てが切り取る（ｃａｒｖｅ  ｏｕｔ）が、複数の割り当てにわたるだけ十分なリソース量をさらに表すことができる。
【００１７】
本発明のもう１つの態様によれば、バジェットコミット「Ｃ」は、リソースプロバイダが、バジェットが関連する（複数の）クライアントにそれまでに割り当てたリソースの量を表す。確保値と同様に、バジェットコミット「Ｃ」は、限度がハード限度であるか、ソフト限度であるかに関わらず、バジェット限度「Ｌ」によって制約される。さらに、バジェットコミット「Ｃ」は、確保値「Ｒ」を超えることができる。
【００１８】
本発明のさらに別の態様によれば、バジェット階層が、別々のバジェットの中に、符号化されたリソース要件およびリソース制限を一緒にリンクする。バジェット階層の中のバジェットは、Ｎ項（ｎ−ａｒｙ）ツリーフォーマットに編成され、各バジェットオブジェクトは、多くても１つの親と、無制限の数の子を有する。このため、バジェット階層は、親を全く有さない単一のルートバジェットを有するものと考えることができる。バジェット階層の中の子バジェットに関連するクライアント群も、ルートバジェットを含む、親バジェットのリソース限度「Ｌ」に支配されている。親バジェットは、子バジェットが明示的に作成されない限り、既定のアクティブなバジェットとして機能することができる。クライアントに課せられる限度は、子バジェットおよび親バジェットにおいて保持される限度のうち、より制限的な方であり、本明細書ではこれを有効リソース限度と呼ぶ。
【００１９】
本発明のさらに別の態様によれば、バジェット階層は、外部バジェット階層であっても、内部バジェット階層であってもよい。バジェットポリシーの考慮すべき事項（ｐｏｌｉｃｙ  ｃｏｎｓｉｄｅｒａｔｉｏｎｓ）に基づいて、外部バジェット階層を使用に先立って明示的に構築することができる。クライアントに代行して実行されるスレッドおよびプロセスによるリソース消費を自己管理しようと試みるクライアントにより、内部バジェット階層を動的に構築することができる。クライアントが例えば現在のバジェットに符号化されている以外のポリシーにアプリケーションを従わせるだけの十分な特権を有する場合、クライアントの現在アクティブなバジェットが一部を成すバジェット階層からクライアントが免れる（ｅｓｃａｐｅ）ことを可能にすることができる。新たなプロセスに利用可能なリソースを制限する必要があるアプリケーションは、潜在的に悪意のある、または危険な動作を抑えるために、子バジェットを作成することが可能である。
【００２０】
本発明のもう１つの態様によれば、追加の限度がバジェットの中にまたは別の場所に符号化されて、クライアントがリソースをどのように使用しているかに基づきクライアントに課せられるリソース制限を動的に変更することが可能である。クライアントによるリソースの使用は、動作モードなどに依存して、時とともに変化する可能性がある。クライアントは、使用の種類によって追加の限度を定義し、アクティブなフレーバ（ｆｌａｖｏｒ）を示すことにより、リソースの現在の用途を伝える。アクティブなフレーバは、リソースを振り向ける（ｐｕｔ）ことができる様々な用途を表す、複数のフレーバの１つである。このようにして、クライアントは、クライアントの関連するバジェットによって課せられた制約の範囲内で、使用の種類に基づき、クライアントのリソース使用を分けることができる。通常、アクティブなフレーバは、例えば、パラメータとしてリソース割り当てＡＰＩに送ることによって明示的に、または、例えば、クライアントに関するユーザモードメモリ状態および／またはカーネルモードメモリ状態の中にアクティブなフレーバを設定することによって暗示的に、リソースマネージャと通信することが可能である。
【００２１】
本発明のさらに別の実施形態によれば、バジェットの中でサポートできるリソースには、個別のリソース、レートベースのリソース、および保証されたリソースが含まれる。個別のリソースは、クライアントに代行して実行されるプロセスまたはスレッドによる排他的な使用のために、クライアントに割り当てられたリソースである。個別のリソースには、オペレーティングシステムの実際の物理的限界によって、またはオペレーティングシステムの設計によって課せられた人為的な限界によって制限されるリソースが含まれる。レートベースのリソースには、ＣＰＵ消費、Ｉ／Ｏ帯域幅、またはネットワーク帯域幅、その他のレートなどの、時間に対する任意の個別リソースの使用パターンが含まれる。保証されたリソースは、個別のリソースとレートベースのリソースのいずれか、または両方に関連することができる。保証されたリソースは、指定された量までのリソースの将来の利用可能性に関する保証書（ｖｏｕｃｈｅｒ）の役割をする。
【００２２】
本発明のさらに別の態様によれば、リソースを管理することができるクライアントは、アプリケーション、またはグループのアプリケーションを含むことができる。クライアントは、オプションとして、他のクライアントに代行して、バジェットにリソース要件およびポリシー規則を符号化する特権を有するバジェットマネージャとして機能することもできる。
【００２３】
本発明のさらに別の態様によれば、リソースマネージャは、バジェットを実施すること、利用可能なリソースを監視すること、およびリソース割り当て失敗から回復することを含め、リソースの管理を一元化する（ｃｅｎｔｒａｌｉｚｅ）。リソースマネージャは、バジェット制約を指定し、リソースプロバイダと通信するインタフェース群をさらに提供することができる。リソースマネージャは、動的ポリシー状態に従って、クライアントに代行してリソースプロバイダから転送されたリソース割り当て要求を承認することができる。動的ポリシー状態は、現在、実行されているプロセスおよびスレッドの識別、例えば優先順位レベルで示すことができるプロセスおよびスレッドの相対的重要度、ならびにプロセスおよびスレッドの現在アクティブなバジェットを含め、リソース管理ポリシーの現在の状態を表す。リソースマネージャは、動的ポリシー状態の中で、目標クライアントに代行して実行されるプロセスおよびスレッドに関して指定された、許可されたアクションセットに従って、要求側クライアントと目標クライアントとの間における競合をさらに調停する。許可されたアクションセットは、目標クライアントが、要求側クライアントへの再割り当てのためにリソースを自発的に譲る受動的アクションから、目標クライアントからリソースを強制的に回収する事前対応アクション、リソースが回収される目標クライアントを終了させることをもたらす積極的なアクションまでの幅がある。リソースマネージャは、オプションとして、リソースプロバイダに代行してリソースのレート制御を実施することもできる。
【００２４】
本発明のもう１つの態様によれば、リソースプロバイダは、要求側クライアントにリソースを割り当て、目標クライアントからリソースを回収することを、リソースマネージャによる承認および調停判定とは別個に、ただし、それらの承認および判定に従って行う。リソースの割り当て、およびリソースの回収が行われると、リソースプロバイダは、リソースマネージャと連携して、クライアントのバジェットと直接に、または間接的にさらに対話して、サポートされるリソースの消費および解放を記録する。
【００２５】
本発明のさらに別の態様によれば、リソース通知サービスが提供されて、リソースプロバイダおよびリソースマネージャから要求側クライアントおよび目標クライアントへの、リソースに関する通知を円滑にする。通知には、とりわけ、リソース調停に関係する通知、およびリソース使用量が閾値に達した、または閾値を超えたという通知が含まれる。
【００２６】
本発明のさらに別の諸態様によれば、バジェットの作成、保持、およびクエリ（問い合わせ）を行うため、リソースの確保および保持を行うため、リソースの消費を記録するため、およびリソース競合を調停するためのデータ構造およびコンピュータ実行可能コンポーネントを格納するための媒体を含む、コンピューティング装置におけるリソースを管理するためのコンピュータアクセス可能媒体が提供される。データ構造は、前述したシステムおよび方法と全体的に整合性のある形で、リソースおよびリソースプロバイダ、バジェット、ならびに他のポリシーデータを定義する。同様に、リソースマネージャ、ならびにバジェットおよびリソースプロバイダに対するリソースマネージャインタフェース群を含む、コンピュータ実行可能コンポーネントも、前述したシステムおよび方法と全体的に整合性のあるアクションを実行することができる。
【００２７】
本発明の以上の態様、および付随する利点の多くは、添付の図面と併せて解釈すると、以下の詳細な説明を参照して本発明がよりよく理解されるにつれ、より容易に理解されるようになろう。
【発明を実施するための最良の形態】
【００２８】
コンピューティング装置上でアプリケーションを正常に実行するために、デバイスのオペレーティングシステムは、アプリケーションに様々なリソースを提供しなければならない。それらのリソースを管理して、それらのリソースを効率的に割り当て、および使用を円滑にするための改良された方法を実施するのに適した、本発明の諸実施形態に係るコンピューティングシステムを、以下の説明で詳細に説明する。
【００２９】
一般に、本発明の実施形態において管理することができるリソースには、リソースを一時的にまたは永久的に使い尽くされる可能性のある環境下、またはその他利用できない状況下で、アプリケーションまたはオペレーティングシステムの使用のために全部または一部を割り当てることが有意義な、任意の定量化可能なリソースが含まれる。管理することができるリソースのいくつかの例を以下に詳細に説明する。リソースは、通常、デバイス上で実行されている、競合するプロセスまたはスレッドの間で割り当てられる。１つまたは複数のアプリケーション、またはオペレーティングシステムのために、競合するプロセスまたはスレッドを実行することができる。
【００３０】
本発明の実施形態において管理することができる最も馴染み深いリソースは、現実のハードウェア、および仮想化されたハードウェア、つまり物理的メモリページ、ディスクブロック、周辺デバイス、仮想アドレス空間、ページファイル空間、ＣＰＵ時間、オブジェクト名前空間などに基づく。それらのリソースに、暗示的に割り当てられるものがある。例えば、ＣＰＵをスケジュールすることにより、ＣＰＵ時間が割り当てられ、Ｉ／Ｏ動作を要求することにより、Ｉ／Ｏシステム全体で帯域幅が消費され、無効なアドレスにアクセスすることにより、ページフォールト（ｆａｕｌｔ）が生じる。
【００３１】
ほとんどのシステムでは、注目すべき基本的な（つまり、ベース）リソースは、少数しか存在せず、代表的な例には、ディスク（ストレージ）、Ｉ／Ｏ、ＣＰＵ、カーネル仮想アドレス空間（ＫＶＡ；ｋｅｒｎｅｌ  ｖｉｒｔｕａｌ  ａｄｄｒｅｓｓ  ｓｐａｃｅ）、ユーザ仮想アドレス空間（ＵＶＡ；ｕｓｅｒ  ｖｉｒｔｕａｌ  ａｄｄｒｅｓｓ  ｓｐａｃｅ）、および物理的ページフレームがある。その他のほとんどのリソースは、通常、以上の基本的なベースタイプから合成される（ｃｏｍｐｏｓｉｔｅ）。ＫＶＡおよびＵＶＡは、物理的メモリの上に構築された抽象化（ａｂｓｔｒａｃｔｉｏｎ）であるが、ＫＶＡ空間およびＵＶＡ空間の量は、論理アドレスピンの数、およびオペレーティングシステム設計によって制限され、基礎にある物理的メモリの量によっては制限されないという点で、基本的なリソースである。
【００３２】
Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）ＮＴシステムにおいて実施される本発明の実施形態において管理することができるリソースの例には、非ページプールおよびページプール、ＫＶＡから切り離される（ｐａｒｔｉｔｉｏｎｅｄ  ｏｆｆ）仮想ページのためのシステムページテーブルエントリ（ＰＴＥ；ｐａｇｅ  ｔａｂｌｅ  ｅｎｔｒｙ）、ページファイル空間、ページングレート、およびＡＷＥメモリが含まれるが、以上には限定されない。ベースリソースであるか合成リソースであるかに関わらず、オペレーティングシステムに存在する設計構造（ａｒｔｉｆａｃｔ）および／または設計判断または要求から生じるいくつかの特徴セットによって、以上のリソースの各々を定義することができる。そのような特徴のリストを以下に示す。すなわち、
限られた（絶対）リソース：多くの場合、特定のリソースの利用可能性は、オペレーティングシステムによって課せられる作為的な（ａｒｔｉｆｉｃｉａｌ）限度によって制約される可能性がある。例えば、何らかのテーブル中で、スロットが決まった数であることに起因して、オペレーティングシステムによって使用されるデータ構造が、制限される可能性がある。他方、（ページフォールトの総数、転送されたＩ／Ｏバイト数、コンテキストスイッチ回数、ＣＰＵ時間など）カウントすることができるどんなものでも、作為的な限度と組み合わせた場合、リソースと見なすことができる。「カウントされる」と分類されるリソースのほとんどは、リソースを必要とするアプリケーションによって、通常、暗示的に割り当てられる。通常の環境では、オペレーティングシステムは、例えば、オペレーティングシステムが同時に処理することが可能なアクティブなネットワーク接続の数を制限することにより、同時に消費されるリソース消費を制限することもできる。
【００３３】
レートベース（Ｒａｔｅ−ｂａｓｅｄ）：リソースを割り当てることが可能なレートも、リソースとすることができる。例えば、スケジュールされたＣＰＵ時間、Ｉ／Ｏ、ページフォールト、およびコンテキストスイッチはすべて、それらが発生するレートによって制限することができる。そのような限度は、作為的とすることも（オペレーティングシステムによって課せられる）、実際的な限界（例えば、維持できる最大の可能なＩ／Ｏレート）とすることもできる。限られたリソースは、絶対量（例えば、消費される総ＣＰＵ時間、被るページフォールト総数、または割り当てられる非ページプール総計）に基づき、計上され、制限されるという点で、レートベースのリソースと区別することができる。また、レートベースのリソースは、一定の期間にわたってリソースが使用されない場合、通常、自動的に再度満たされる（ｒｅｐｌｅｎｉｓｈ）という点でも、他の種類のリソースとは異なる可能性がある。
【００３４】
保証：リソースを割り当てるほとんどの場合で、オペレーティングシステムは、リソースを利用できるかどうかについて瞬時に解決しなければならない。他のクライアントによるリソース使用の状態によっては、オペレーティングシステムは、長い期間にわたってリソース要求に十分に応じることができない場合がある。例えば、優先順位の低いスレッドは、システムがそのスレッドの優先順位を上昇させるまで、またはこれに代えて、すべてのより優先順位の高いスレッドがレディ状態／実行可能状態ではなくなるまで、欠乏状態に置かれる（ｒｅｍａｉｎ  ｓｔａｒｖｅｄ）可能性がある。この問題を軽減するために、特に、サービス品質（ＱｏＳ）レベルを維持するのに必要な、一定の待ち時間要件に拘束されるクライアントに関して、システムは、リソースを利用することができるかについて保証を提供することができる。実施例には、毎秒１００ミリ秒（ｍｓ）のＣＰＵ時間を提供すること、毎秒２メガバイトのＩ／Ｏデータを転送すること、または毎秒８０のハードページフォールトに対処する（ｓｅｒｖｉｃｅ）ことを約束するものがある。そのような保証は、システムが、それらの保証を実現する措置を後にとるからこそ、意味があるので、システムが同時に行うことができるそのような約束の数に対して、必然的に何らかの制限が存在することになる。この点で、保証自体、リソースと見なすことができる。
【００３５】
本発明の実施形態において管理できるリソースには、回復可能な（ｒｅｎｅｗａｂｌｅ）リソースと回復不可能なリソースの双方が含まれる。リソースは、そのリソースがどのように再度満たされるかに基づき、回復可能または回復不能と分類することができる。回復可能なリソースは、アプリケーションに割り当てられると消費されるが、時間の経過とともに自動的に再度使用可能である。ＣＰＵレート、Ｉ／Ｏ帯域幅、およびページフォールトレートなどの、ほとんどの間接的にレートベースのリソースは、回復可能である。回復可能でないリソースは、アプリケーションが割り当てを返した場合に、再度使用可能となる。メモリブロック、装置、カウントされる限度、およびデータ構造の限度はすべて、回復不可能なリソースの例である。ほとんどのリソースは、回復不可能である。
【００３６】
また、本発明の実施形態において管理できるリソースには、回収可能なリソースも含まれる。回収可能なリソースは、システムがアプリケーションの協力なしに、アプリケーションから回収することが可能なリソースである。最も制限された形態の回収は、アプリケーションを単に終了させて、アプリケーションのリソースのすべてが、システムに明け渡されるようにする（ｒｅｌｉｎｑｕｉｓｈ）ことである。しかし、多くの場合、個々のリソースを回収されることが可能であり、アプリケーションに対する影響は、低下したパフォーマンスから低下した機能まで、場合によっては、異常終了（ａｂｎｏｒｍａｌ  ｅｘｉｔ）まで、様々なものがある。回収の実施例には、メモリリソースをマップ解除すること、アプリケーションをスケジュール解除すること、ハンドルを無効にすること、および保証を守ることを止めることが含まれる。もちろん、一部のリソースは、以上に説明した意味で回収することができず、通常、そのようなリソースは、量が無限であるが、クライアントに割り当てられた任意の部分は、「消費され」、その部分をシステムに戻すことはできない。例としては、消費される総ＣＰＵ時間や、被るページフォールト総数などの、単調に増加する量が含まれる。
【００３７】
図１は、本発明の実施形態による、例示的なリソース管理システム１００、ならびに前述したようなリソースを管理することができる適切な動作環境を示す。図示するように、リソースマネージャ１０８は、リソースプロバイダ１１２およびクライアント１０２と連携して動作して、動的なポリシー状態に従って、リソースプロバイダ１１２によるクライアント１０２へのリソースの割り当てを管理する。リソースプロバイダ１１２は、リソースの実際の割り当てを制御し、他方、リソースマネージャ１０８は、リソースの管理を一元化する。このようにして、リソース管理システム１００のアーキテクチャにより、リソースの割り当ては、リソースを管理する諸機能から切り離される。
【００３８】
通常の実施形態では、リソースマネージャ１０８は、カーネルモードコンポーネントにおいて実装されるが、本発明の原理を逸脱することなく、別の場所で実装することも可能である。リソースプロバイダ１１２は、通常、ユーザモードコンポーネントとしてか、またはカーネルモードコンポーネントとして実装される。実施例は、メモリマネージャ、ＣＰＵ予約機構、およびＩＯ分類機構を備える。一実施形態では、ユーザモードリソースプロバイダ１１２は、カーネルモードリソースプロバイダをプロキシとして使用して、カーネルモードリソースマネージャ１０８と対話する。
【００３９】
前述したとおり、リソースマネージャ１０８は、リソースプロバイダ１１２およびクライアント１０２と連携して動作して、動的なポリシー状態に従って、リソースプロバイダ１１２によるクライアント１０２へのリソースの割り当てを管理する。動的なポリシー状態は、少なくともある程度、ポリシーモジュール１１４に従って形成された１つまたは複数のバジェット１０４Ａ、１０４Ｂ、１０４Ｃにおいて実現される。一実施形態では、ポリシーモジュール１１４は、１つまたは複数のポリシーマネージャ１１６、およびポリシーデータベース１１８を備えることができる。一般に、ポリシーモジュール１１４は、ポリシーデータベース１１８の中で、特定のクライアント１０２の優先順位や他の静的な（または比較的静的な）ポリシーデータなどの、一部の選好（ｐｒｅｆｅｒｅｎｃｅ）を符号化するように動作する。他方、バジェット１０４Ａ、１０４Ｂ、１０４Ｃは、一般に、特定のクライアント、または特定のクライアントセットの動的リソース要件および動的リソース制限を符号化する。リソースの管理におけるポリシーモジュール１１４の使用を、図７を参照してさらに詳細に説明する。
【００４０】
バジェット１０４Ａ、１０４Ｂ、１０４Ｃは、アクティブとすることも、非アクティブとすることもできる。アクティブなバジェットは、クライアント１０２に現在、関連付けられているバジェットである。非アクティブなバジェットは、ポリシーの考慮すべき事項を表すように、１つまたは複数のクライアント向けに一般的に前もって作成されているが、いくつかの理由で、クライアント１０２に現在、関連付けられていないバジェットである。通常の実施形態では、バジェットは、バジェットオブジェクトにおいて実装される。バジェットオブジェクトは、クライアント１０２のために現在、実行されている１つまたは複数のプロセスまたはスレッドに関連する。他にも用途があるなかで、とりわけ、リソースマネージャ１０８は、アクティブなバジェットを使用して、関連するプロセスまたはスレッドが、所与の時点で、いずれのリソースをどれだけ使用することができるかを決める。一実施形態では、バジェットは、動的に作成され、かつ／またはアクティブにされ、グループの関係するアプリケーション１０２Ａ、無関係なアプリケーション１０２Ｂ、およびバジェットマネージャ１０２Ｃの任意の１つまたは複数に、バジェットを関連付けることができる。グループの関係するアプリケーション１０２Ａ、無関係なアプリケーション１０２Ｂ、およびバジェットマネージャ１０２Ｃは、リソースが管理されるクライアント群１０２を共に構成する（ｃｏｍｐｒｉｓｅ）。リソースを管理するのにバジェットを使用することを、図２〜図４を参照してさらに詳細に説明する。
【００４１】
一実施形態では、リソースマネージャ１０８の機能には、とりわけ、リソースに関する事前確保（ａｄｖａｎｃｅ  ｒｅｓｅｒｖａｔｉｏｎ）要求および帯域幅保証を管理すること、利用可能なリソースを監視すること、およびリソース競合を調停することを含めて、バジェット１０４Ａ、１０４Ｂ、１０４Ｃを実行することが含まれる。リソースマネージャ１０８の諸機能には、第三者リソースプロバイダによって制御されてもされなくてもよい動的なリソースを追加すること、および除去することをさらに含めることができる。
【００４２】
一実施形態では、競合するクライアント１０２の間におけるリソース競合を調停する機能を、リソースアービタモジュール１２２において実現することが可能である。通常の実施形態では、調停は、リソースプロバイダ１１２の要求で実行される。一実施形態では、リソースアービタ１２２は、１つのクライアント、すなわち、目標クライアントへの残っている（ｏｕｔｓｔａｎｄｉｎｇ）割り当てから、別のクライアント、すなわち、要求側クライアントからのリソースを求める未処理の要求を満たすために、リソースが回収されるべきかどうかを判定する。リソースアービタ１２２は、図６を参照してさらに詳細に説明するとおり、動的なポリシー状態、すなわち、現在のバジェットオブジェクト、および他のポリシーデータに関連して、そのような調停判定を行う。
【００４３】
一実施形態では、リソースマネージャ１０８は、クライアント１０２、リソースプロバイダ１１２、ならびにリソース管理システム１００のその他のコンポーネントとの通信を円滑にするリソースマネージャインタフェース１０６をさらに備える。詳述すると、リソースマネージャインタフェース１０６は、リソースマネージャ１０８とバジェット１０４Ａ、１０４Ｂ、および１０４Ｃとの間の対話、ならびにリソースマネージャ１０８と、ポリシーモジュール１１４のコンポーネント群との間の対話を制御するのに使用することができる。一実施形態では、リソースマネージャインタフェース１０６は、リソースマネージャ１０８とリソース通知サービス１２４との間の対話をさらに制御することができる。リソースマネージャ１０８は、オプションとして、リソース通知サービス１２４を使用して、関心のあるクライアント１０２に、リソースが利用可能かどうかおよびリソース管理について通知することもできる。通知を受信すると、クライアント１０２は、リソースマネージャ１０８に協力して、供給不足になっているリソースを解放して、効率的なリソース管理を円滑にすることができる。通知に対してクライアントが協力を行うことにより、後にリソース競合を調停しなければならないことを回避することができる可能性がある。
【００４４】
一実施形態では、リソースマネージャ１０８は、リソースプロバイダ１１２に代行してリソースのレート制御を実行する、すなわち単位時間当たりの１つまたは複数のクライアント１０２によるリソースの消費量を制御するための、リソースレートコントローラ１２０をさらに備えることができる。
【００４５】
通常の動作環境では、リソースプロバイダ１１２は、１つまたは複数のリソースプロバイダインタフェース１１０を介して、リソースプロバイダ１１２、クライアント１０２、およびリソースマネージャ１０８との間における対話を制御することができる。
【００４６】
図２は、本発明の一実施形態を実施するための、図１に示したバジェットのコンポーネントの構成の一部をさらに詳細に示すブロック図である。バジェット１０４は、クライアント１０２のために実行されている１つまたは複数のプロセス２０２および／またはスレッド２０４に関連するバジェットオブジェクト２００として実施することができる。バジェット１０４は、リソースマネージャ１０８およびリソースプロバイダ１１２が、サービス品質（ＱｏＳ）レベル、リソース確保、およびクライアント分離（クライアントにより使用されるリソースを絞ること（ｔｈｒｏｔｔｌｉｎｇ））を可能にするのを支援するようにバジェット１０４が関連しているクライアント１０２のリソース要件をカプセル化する。
【００４７】
内部では、バジェットは、サポートされる各リソース２０６に関して、次の３つの量を記録する。すなわち、限度（Ｌ）２０８、確保（Ｒ）２１０、およびコミット値（Ｃ）２１２である。以下の説明では、バジェット１０４に関連するスレッド、プロセスなどを、そのバジェットのクライアントと呼び、クライアントとは、一般に、スレッドまたはプロセスが代行して実行されているクライアント１０２を指す。説明を容易にするため、特に明記しない限り、スレッド２０４に言及する場合は、プロセス２０２、あるいは、クライアント１０２のために実行されている任意の論理を含むものとなる。いずれの時点でも、実行されているスレッドのリソースを使用する場合、単一のバジェット１０４、すなわち、アクティブなバジェットオブジェクト２００に支配されている。同一の時点で、アクティブなバジェットオブジェクト２００は、同一のクライアント１０２、または相異なるクライアント１０２のために実行されている複数のスレッドに関連付けすることができる。バジェットのパラメータ、ならびにバジェット１０４を表す実際のバジェットオブジェクト２００は、リソースマネージャ１０８によって実施されるポリシー判断に起因して、またはバジェットが関連している複数のスレッド２０４および／またはプロセス２０２による操作に起因して、時間とともに変化する可能性がある。さらに、バジェット１０４は、スレッド２０４が代行で実行されている、相異なるクライアント１０２の間における関係を表現するために、階層関係にあるようにすることができ、したがって、１つのクライアントのリソース使用を、同一のバジェット階層におけるバジェットに関連する他のクライアントのリソース使用に結び付けることができる。
【００４８】
限度値（Ｌ）２０８は、バジェットのクライアントが将来使用するためにバジェットが確保することができるリソースの最大量を表す。限度は、通常、バジェット作成後、一定のままであるが、十分な特権を有するシステムコンポーネントは、それらの限度を後で変更することができる。限度は、２つの種類、すなわち、ハードタイプ、またはソフトタイプとすることができる。ハード限度は、通常のサービスレベルでバジェットに割り当てることができるリソースの量に対する絶対限度である。限度がソフトである場合、限度値Ｌ２０８を超えるリソース割り当ては、十分に低下したサービスレベルで要求側クライアントに分配されて、通常のリソース要求を満たすシステムの能力が、損なわれないようにする。そのようなより低いサービスレベルのリソースを分配することにより、クライアントは、さもなければ十分に利用されない可能性があるリソースを利用することができるようになる。
【００４９】
確保値（Ｒ）２１０は、バジェットのクライアントが確保することができる、バジェットに組み込まれた（ｂｕｄｇｅｔｅｄ）リソースの最大量を表し、Ｌが、ハードであるか、ソフトであるかに関わらず、限度Ｌ２０８によって常に限界が定められる。このため、確保値（Ｒｅｓｅｒｖａｔｉｏｎ  Ｖａｌｕｅ）Ｒ２１０により、バジェットのクライアントがリソース調停をしなくても通常のサービスレベルで後に割り当てることができるリソースの量に最大限度が課される。確保済みのリソースは、他のクライアントによる確保に実質的に利用できないので、リソースが十分に利用されないことおよび不必要なリソース競合を最小限に抑えるように、すべてを確保することは、通常、保守的（ｃｏｎｓｅｒｖａｔｉｖｅ）である。
【００５０】
コミット値（Ｃ）２１２は、リソースプロバイダ１１２が、バジェットのクライアント１０２に割り当てたリソースの実際の量を記録する。ソフトである限度Ｌ２０８は、通常のサービスレベルでリソース割り当ての提供が停止される閾値を示すため、コミット値Ｃ２１２は、２つの値、すなわち、通常のコミット（Ｃｎ）と超過コミット（Ｃｅ）との合計として記述することができる。限度Ｌまでのすべての割り当ては、Ｃｎタイプと見なされ、これは、リソースプロバイダが、通常のサービスレベルでクライアントにＣｎリソースを割り当てたことを示す。Ｃｅは、低下したサービスレベルでアプリケーションに与えられ、Ｌがソフトであり、かつＣｎ＝Ｌである場合にだけ、すなわち、リソースプロバイダが、ソフト限度の完全な量を既に割り当てている場合にだけ、アプリケーションに与えられるコミットの割合（ｆｒａｃｔｉｏｎ）を表す。このため、Ｌがハード限度である場合、Ｃｅは、必然的に０である。
【００５１】
限度Ｌ２０８自体、確保されることが可能なリソースの量Ｒ２１０に拘束される緩い上限の役割をする。Ｒ２１０は、図３を参照して以下に説明するとおり、クライアントのバジェット階層で別途確保され、およびシステムの別の場所において確保されることによって制約を受ける。超過コミットＣｅと分類されるリソース割り当ては、回収可能であるので、クライアント１０２は、通常、超過リソース割り当てを使用して、任意に選択できる、または急を要しない（ｎｏｎ−ｔｉｍｅ  ｃｒｉｔｉｃａｌ）（例えば、追加的なＭＰ３ビデオディスプレイ効果などをもたらすための）処理を実行する。
【００５２】
ソフト限度の目的は、特に競合が存在しない場合は、システムにおいてリソースが十分に利用されないことがないようにすることである。例えば、未使用（ｉｄｌｅ）であるリソースに関して、一般に、リソースプロバイダ１１２は、そのリソースを超過と分類し、そのリソースを貧窮しているクライアントに割り当てることを認めるのが無難である。コミットされるのに先立って明示的に確保されることが可能なリソース、すなわち、レートベースのリソースではなく有限なリソースに関して、リソースプロバイダ１１２は、確保されているがコミットされていないリソースのいずれの部分が、近い将来に使用される可能性が低いかについて、推測する（ｓｐｅｃｕｌａｔｅ）ことができる。次に、リソースプロバイダ１１２は、そのようなリソースを要求側クライアント１０２に分配することができるが、迅速に、効率的に、また多分、クライアント１０２の明示的な協力なしに、リソースを回収することが可能であることが保証されていなければならない。さもなければ、リソースプロバイダ１１２は、必要なリソースが回収される間、事前確保を行ったクライアント１０２に、過度の遅延を被らせる可能性がある。このため、リソースマネージャ１０８にとって、ソフト限度の概念を実現することが有意義であるとともに実際的でもあるリソースは、ほんの一握りしか存在しない。
【００５３】
ソフト限度の例示的な実装において、ａ＜ｂであり、時刻ａの、Ｃの値がＣａであり、時刻ｂでは、Ｃｂであり、Ｃ’＝Ｃｂ−Ｃａという単一の割り当てが行われ、Ｃａ＜Ｒ＜Ｃｂであるものと想定する。この場合、Ｃｎの一部である（Ｒ−Ｃａ）を、リソース調停することなく生成することを常に保証することが可能である。ソースプロバイダが、利用可能な（未使用の）リソースプールからリソースを割り当てるのに要する時間にほぼ等しい時間内に、次のアクションを実行可能である限り、この要件によって、リソースプロバイダが、別のクライアントに与えられたＣｅからリソース量（Ｒ−Ｃａ）を回収し、そのリソース量（Ｒ−Ｃａ）を使用して、その要求を満たすことが排除されることはない（ｐｒｅｃｌｕｄｅ）。リソースが、断片化された形で割り当てられる（例えば、物理的ページの場合と同様に）ことが可能でない場合、（Ｃｂ−Ｒ）だけでなく、割り当てＣ’全体に関して、調停が要求される可能性があることに留意されたい。
【００５４】
ソフト限度の通常の用途は、ＣＰＵが十分に利用されないことを回避することである。バジェット１０４が、ある割合のＣＰＵ消費量という限度Ｌ２０８を有し、ＣＰＵに関する競合が全く存在しない場合、一般に、制限する例の（ｒｅｓｔｒｉｃｔｉｎｇ）バジェットのクライアントがＣＰＵのすべてを消費することができない理由は、全くない（というのは、さもなければ、ＣＰＵは、完全に使用されないことになるからである）。利用可能なＣＰＵを問題のクライアントに単に分配することにより生じる問題は、他のいずれのクライアント（制限するバジェットに束縛されない）がレディになった場合でも、その分配が容易に取り消されなければならないことである。ＣＰＵを回収して、正当なクライアントに分配することを容易に行うことができない場合、制限する例のバジェットの中で設定されたソフト限度Ｌ２０８の有用性は阻害される（ｔｈｗａｒｔｅｄ）。回収費用ゼロを実現することは困難であるが、回収費用は、大幅に小さくすることができる場合がある。例えば、ＣＰＵの場合、限度Ｌ２０８を超えると、制限されたスレッドの優先順位を劇的に下げてから、スレッドが実行を続けることを許すことが可能となる。このため、ＣＰＵ競合が存在しない場合、制限されたスレッドは、ＣＰＵ上でスケジュールされ、スレッドの動作は、妨げられずに続けられる。他のいずれかの制限されていないスレッド（バジェットに関連していない）が、動作可能（ｒｅａｄｙ）になった場合、または別の形で、ＣＰＵに関する競合が生じた場合、下げられた優先順位により、制限されたスレッドは、確実に、制限されていないスレッドの正当な活動を妨害しないようになる。リソースが再度満たされると、制限されたスレッドの優先順位は、以前のレベルに復元される。
【００５５】
通常、リソースプロバイダは、超過リソース割り当てを提供するかどうか、すなわちハード限度ではなく、ソフト限度を課すかどうかを、回収を実現することができる時間に基づいて判定する。このようにして、他のバジェットにおいてリソースがＣｅ割り当ての中で保持されているものと想定すると、回収時間を使用して、正当な通常のリソース割り当てＣｎに生じる可能性がある待ち時間の限界を定めることができる。一般に、前述したとおり、回収時間は、Ｒより少ないＣｎ割り当ての部分に関してだけ、限界を定めることが可能であり、Ｒの他の部分は、悪くすると、他のクライアントに与えられたＣｎ割り当てからリソースを回収するのに要する時間だけ遅延させられる可能性があることに留意されたい。
【００５６】
ソフト限度を認めることにより、バジェット１０４のクライアント１０２は、システムにおける他のクライアントによって行われた未使用の確保に起因して確保要求に対して設定された作為的な制限を、ある程度補償することができる。ソフト限度は、コミット済みのリソースを無制限で使用できるようにすることから、リソース使用を制限する際、バジェット１０４の有効性が打ち消されるように見える可能性があることに留意されたい。しかし、さもなければ、ソフト限度を超える割り当ては、通常、十分に利用されないリソースに限定される。すべてのリソースプロバイダ１１２がソフト限度に対応しているわけではない。例えば、目的が一貫した処理（最適な処理ではなく）が提供される場合、十分に利用されないことを回避するようにソフト限度を使用することは望ましくないことがある。このため、バジェット１０４に対応するリソース２０６のすべてが、ソフト限度Ｌ２０８に管理されるわけではない可能性がある。
【００５７】
ソフト限度によって、リソースの十分でない利用に対抗する（ｃｏｍｂａｔ）ことができる手段が提供されるが、特定のバジェットによって追跡されるリソース使用量がある閾値を超えたという事前通知を関心のあるパーティが受け取ることができる手段は、提供されない。この問題に対処するため、リソースバジェット１０４は、バジェットセンチネル（ｓｅｎｔｉｎｅｌ）値２１４をオプションとして含めることにより、リソース使用量に関する、「センチネル」、つまり、警報の概念を取り入れる。バジェットセンチネル２１４の値に対する唯一の制限は、値が、バジェット１０４の中で設定された現在のリソース限度Ｌ２０８以下である（リソース限度Ｌが、センチネルの値より小さい値に切り詰められている（ｃｏｎｔｒａｃｔｅｄ）場合、センチネルは、無効にされる）ことである。センチネルの値は、現在の通常のコミット（Ｃｎ）、または問題のリソースに関する確保値Ｒに対して、全く順序関係（ｏｒｄｅｒｉｎｇ  ｒｅｌａｔｉｏｎ）を有さない。特定のリソースの現在の通常のコミットＣｎ値がセンチネル値２１４を超えると、例えば、図５を参照して以下に詳細に説明する通知サービス１２４を使用することにより、他のクライアント１０２は通知を受けることができる。そのような通知を受信すると、クライアント１０２は、随意に（ａｓ  ｉｔ  ｓｅｅｓ  ｆｉｔ）（例えば、リソース使用量を調整すること、リソース限度を変更することなどにより）対応することができる。通常の実施形態では、（現在の通常のコミットＣｎ値が、バジェットセンチネル２１４の値をはさんで行き来するように揺れ動く）履歴状態となる場合において深刻な性能低下を回避するため、センチネル通知は、１回限りのイベントとする。すなわち、通知が発行されると、センチネルは、関心のある受信者（ｌｉｓｔｅｎｅｒ）、例えば、クライアント１０２またはシステム管理者が、センチネルを明示的に再びアクティブにするまで、非アクティブなままである。
【００５８】
バジェット１０４は、図３Ａ〜図３Ｂを参照して以下に詳細に説明するとおり、バジェット階層の一部とすることができる。以下の説明において簡明にするため、限度は、ハードであるものと想定され、したがって、Ｃｅ＝０であり、このため、Ｃ＝Ｃｎである。一般化して説明するため、以下では、ＣｎをＣに代入することができる。階層の一部である場合、前述したＬ２０８値、Ｒ２１０値、Ｃ２１２値、およびバジェットセンチネル２１４値に加えて、各バジェット１０４は、現在のバジェット１０４のレベルより下位の、階層関係にあるすべてのバジェットのリソース確保Ｒ２１０の累積量が保持される、サブツリー確保とも呼ばれる、累積確保２１６の値を含むことができる。累積確保２１６の値により、図３Ａ〜図３Ｂを参照して以下に詳細に説明するとおり、バジェット階層の一部であるバジェットに関するバジェット制限を円滑に行うことができる。
【００５９】
図３Ａ〜図３Ｂは、本発明の実施形態に従って形成された例示的なバジェット階層の図である。他の用途もあるなかで、とりわけ、バジェット階層は、その階層に属するバジェットのリソース要件およびリソース制限に関する規則群を表現する機構を提供する。図３Ａに示すとおり、例示的なバジェット階層３００は、バジェット階層３００を形成するバジェット３０２、バジェット３０４Ａ〜Ｃ、およびバジェット３０６Ａ〜Ｅの中で表現されるリソース要件およびリソース制限、すなわち、限度Ｌ２０８、確保Ｒ２１０、およびコミットメントＣ２１２を、ｎ項ツリー構成で一緒にリンクする。
【００６０】
バジェット階層３００は、通常、ルートバジェット３０２と、１つまたは複数の子バジェット３０４Ａ、３０４Ｂ、および３０４Ｃとを備える。子バジェットは、さらなる子バジェット３０６Ａ、３０６Ｂ、３０６Ｃ、３０６Ｄ、３０６Ｅ、および３０６Ｆを備えることができる。リソースマネージャ１０８は、ルートレベルバジェット３０２を使用して、バジェット階層３００におけるバジェット群の１つのクライアント１０２によって開始されたリソース確保要求を認める、または拒否することに対する最終的なバリアを課す。いずれのそのような確保要求も、開始時の（ｉｎｉｔｉａｔｏｒ）のバジェットとそのルートとの間で階層３００の各レベルに存在するバジェット制約を満たさなければならない。このため、バジェット３０６Ｆのクライアントによって開始された要求は、バジェット３０６Ｆの制約だけでなく、バジェット３０４Ｃ、およびルートバジェット３０２の制約も満たさなければならない。
【００６１】
一実施形態では、バジェット階層３００におけるバジェットに従って、リソース要求がリソースマネージャ１０８によって認められると、要求は、一般に適切なリソースプロバイダ１１２によってさらに点検され、未処理の確保および割り当てを考慮して、確保要求を認めることが実際的であるかどうかが確かめられる。認める方が実際的であるような要求は、バジェット階層３００におけるバジェットによって指定された制約の下では、リソースマネージャ１０８によって先行して（ｐｒｅｅｍｐｔｉｖｅｌｙ）拒否できることに留意されたい。
【００６２】
通常の実施形態では、バジェット階層３００を上に行くように移動する（ｔｒａｖｅｒｓｅ  ｕｐ）性能を向上させるため、リソースマネージャ１０８は、バジェット階層３００のサブツリーにおいて行われた確保の総累積量を、サブツリーのルートバジェットにキャッシュすることができる。このようにして、ルートでないバジェット（本明細書で派生バジェットとも呼ぶ）のクライアントによって開始されたリソース確保要求は、要求側のバジェット、ならびに階層におけるそのバジェットより上位のすべてのバジェットに照らして調べるだけでよい。図示する実施例では、子バジェット３０６Ｆのクライアントによって開始された要求は、要求側のバジェット、すなわち、子バジェット３０６Ｆ自体、ならびにルートバジェット３０２への直接パス上のバジェット階層３００における子バジェット３０６Ｆより上位のバジェットのすべてに照らして調べられるが、サブツリー３０４Ａ、３０４Ｂまたは同一のレベルにおけるバジェットである子バジェット３０６Ａ〜Ｅに照らして調べられることはない。
【００６３】
派生バジェットは、派生バジェットの祖先のいずれかの中で指定された限度より小さい限度（Ｌ）２０８を必ずしも有する必要はないことに留意されたい。これは、外部ポリシーが、クライアント１０２のアプリケーションの起動に応答して、事前定義されたバジェット１０４をバジェット階層３００の中にリンクすることができるからである。それでも、ローカルの限度、すなわち子バジェットの限度が、祖先の中の限度より大きい場合では、正しい結果が得られる。というのは、要求はツリーのより上位でブロックされるからである。
【００６４】
通常の実施形態では、ルートバジェット３０２は、すべてのルートレベルバジェット３０２にわたるＬ値２０８の合計が、システムにおける利用可能なリソース全体と正確に等しくない限り、システムのリソースの絶対的なパーティションではない。限度Ｌ２０８は、調整されたポストバジェット（ｐｏｓｔ−ｂｕｄｇｅｔ）作成に適応することが可能であり、リソースのサブスクリプション（予約）過剰（ｏｖｅｒ−ｓｕｂｓｃｒｉｐｔｉｏｎ）をもたらす可能性があるので、リソースパーティションは、その代わりに、通常リソース保証（例えば、ＣＰＵ帯域幅保証）の確保を要求することにより得られる。
【００６５】
前述したとおり、バジェット階層３００は、階層に属するバジェットのリソース要件およびリソース制限に関する規則群を表現する機構を提供する。バジェット階層、およびその階層において表現される規則群の実施例３０８を図３Ｂに示す。実施例３０８では、システム管理者が、クライアント｛Ａ，Ｂ，Ｃ，Ｄ｝３１２およびクライアント｛Ｘ，Ｙ，Ｚ｝３１８によるＣＰＵの総計の使用量を、システムにおける利用可能なＣＰＵの８０パーセント以下に制限することを所望する。しかし、クライアント｛Ａ，Ｂ，Ｃ，Ｄ｝は、総計使用量規則３２２の中で示されるとおり、ＣＰＵの５０パーセントまで使用することができ、他方、クライアント｛Ｘ，Ｙ，Ｚ｝は、総計使用量規則３２４の中で示されるとおり、単に４０パーセントまでに制限される。単一のスタンドアロンバジェットを使用してこの種類の規則を表現することは、特に、５０パーセントおよび４０パーセントという個々の限度が、合計で、総計使用量規則３２０（Ｌ2＋Ｌ3＞＝Ｌ1，例えば、５０＋４０＝９０＞＝８０）の中で示される８０パーセントという所望の有効限度を超えるので、難しいことが分かる。しかし、システム管理者は、本発明の実施形態に従って形成された、図示するバジェット階層３０８を作成することにより、所望の結果を実現することが可能となる。
【００６６】
図示するとおり、図示する実施例のバジェット階層３０８は、バジェットＢ2３１４（５０パーセントの限度Ｌ2を有する）およびバジェットＢ3３１６（４０パーセントの限度Ｌ3を有する）を備え、バジェットＢ2３１４およびバジェットＢ3３１６の各々は、ルートバジェットＢ1３１０（８０パーセントの限度Ｌ1を有する）から派生している。クライアント｛Ａ，Ｂ，Ｃ，Ｄ｝３１２は、バジェットＢ2３１４に関連し、クライアント｛Ｘ，Ｙ，Ｚ｝３１８は、バジェットＢ3３１６に関連する。リソースマネージャ１０８は、コミットされるリソースのそれぞれの量を、総計使用量規則３２２（コミットされたＢ2＜＝５０、ΣＢ2．Ｃ＜＝Ｌ2）および総計使用量規則３２４（コミットされたＢ3＜＝４０、ΣＢ3．Ｃ＜＝Ｌ3）の中で示されるとおり、バジェットＢ2３１４の中の限度Ｌ2、およびバジェットＢ3３１６の中の限度Ｌ3に制限することにより、例示的なバジェット階層３０８における限度を適用する。リソースマネージャ１０８は、コミットされるリソースの合算した量を、総計使用量規則３２６（ΣＢ2．Ｃ＋ΣＢ3．Ｃ＜＝Ｌ1）の中で示すとおり、バジェットＢ1３１０の中で表現される有効限度Ｌ1に制限することにより、例示的なバジェット階層３０８における限度をさらに適用する。
【００６７】
図示した例示的なバジェット階層３０８において示すとおり、バジェット階層３００は、クライアントのローカルバジェットの中で、すなわち、子バジェットつまり派生バジェットの中で、指定された限度の中で最も制限的な限度に等しい有効限度、ならびに対応するルートバジェットへのパス上のバジェット群の中に符号化された限度に等しい有効限度を課しながら、クライアント１０２のそれぞれのリソース使用をカプセル化するために、クライアント１０２にリソース限度Ｌ２０８を配分する手段を一般に提供する。
【００６８】
一般に、以下の不変関係（ｉｎｖａｒｉａｎｔｓ）が、いずれのバジェット階層３００に関しても成立する。いずれのバジェットに関しても、限度Ｌ２０８は、ハードであっても、ソフトであってもよい。さらに、限度Ｌ２０８は、通常、確保Ｒ２１０以上であり、通常のコミットＣｎ２１２以上でもある。限度Ｌ２０８の値がソフトである場合、超過コミットＣｅは、０以上とすることができ、一般にシステムにおいて利用可能な未使用のリソースの量によって限界が定められる。限度Ｌ２０８が、ハード限度である場合、超過コミット値は、通常は全く設定されない。すなわち、Ｃｅは、通常は０であり、これは、リソースマネージャ１０８によって通常、適用される要件である。いずれのバジェット１０４に関する確保Ｒ２１０の量も、そのバジェットの限度値Ｌ２０８によってだけでなく、バジェット階層３００における別の場所で設定された確保および限度によっても制限される。このため、限度Ｌ２０８は、通常、行うことができる確保Ｒ２１０の量に拘束される緩い上限としてだけの役割をする。最後に、通常のコミット値ＣｎがＲの値に達するために、リソースマネージャ１０８がリソースプロバイダ１１２と協働して、他のクライアント１０２に確保され、または割り当てられている可能性がある任意の超過のコミットされたリソースＣｅを回収することを要求される場合であっても、通常のコミット値ＣｎがＲの値に達することは常に可能である。また、Ｒ２１０より小さい、いずれの大きさの通常のコミット値Ｃｎによっても、バジェットの中のＲの値が、階層における限度に照らして、前もって検証されているために、限度を考慮するための階層の走査（ｔｒａｖｅｒｓａｌ）が回避されるという点で、パフォーマンスの点で有利である。この場合も、通常のコミット値Ｃｎが有することができる最大値は、通常Ｌ２０８によって限界が定められるが、階層制限、ならびにリソースの過剰要求（ｏｖｅｒ  ｓｕｂｓｃｒｉｐｔｉｏｎ）に起因して、決してその値に達しない可能性がある。
【００６９】
図４は、本発明の実施形態を実施するための、図１に示したバジェットのいくつかのコンポーネントの構成をさらに詳細に示すブロック図である。前述したとおり、特定のプロセス２０２、または特定のスレッド２０４のための能動的なバジェット１０４は、少なくともある程度、プロセスまたはスレッドが代行で実行されているクライアント１０２に依存して、バジェット１０４の存続期間中に多数回、変更される可能性がある。リソースの使用許諾の目的で、特定のバジェットと一時的に関連することが有益な場合がある。例えば、現在実行されている一組のスレッド上で、１つまたは複数のクライアントのためにサービスが実行されているサービスプロセスの場合、そのプロセスまたはスレッドが代行で現在実行されている特定のクライアントに基づき、バジェット制限を実施し、消費量を記録することが望ましい場合がある。実施例には、クライアントに代行して作業をしばしば実行する（さらに、リソースを消費する）ドライバおよびサービスが含まれる。
【００７０】
リソース管理システム１００の通常の実施形態では、そのようなバジェット実施および消費量は、一般化された概要が図４に示される、擬似クライアントリソースＩＤ４００を使用することによって記録することができる。擬似クライアントリソースＩＤ４００は、プロセス又はスレッドをクライアントのリソースＩＤ４１０とみなすことによって、クライアントの能動的にバジェット１０４を探し出し、バジェット１０４に一時的に結び付ける４１２ために、プロセスまたはスレッド２０２をクライアント１０２に一時的に関連付ける。すると、リソースマネージャ１０８は、プロセス２０２またはスレッド２０４がクライアント１０２のために使用しているリソース４０８に関して、能動的にバジェットを制限し、消費量を適切に記録する行うことができる。通常の実施形態では、クライアントのリソースＩＤ４１０は、アプリケーションＩＤ４０２から、あるいは現在のトークンなどの、システムがクライアント１０２のために保持する他の識別情報から導出することができる。
【００７１】
通常の実施形態では、サービス、すなわち、サービスのために動作しているプロセス２０２またはスレッド２０４が、クライアントのアクティブなバジェット１０４に一時的に結び付けられている間に、リソースを割り当てること、および明け渡すことをともに行う場合に、擬似クライアントリソースＩＤ４００は適切である。サービスが、ローカルキャッシュに関するオブジェクト（ハンドル）またはメモリなど、適用期間を超えて存続するリソースを割り振る場合、これは、クライアントに請求される（ｃｈａｒｇｅ）べきではない。というのは、それらのリソースは、異なるクライアントに関する他の将来の要求を円滑にするために、サービスによって通常保持されるからである。このため、通常の実施形態では、クライアント要求を受信すると、サービスはまず、クライアントのタスクを達成するのに必要なリソースの性質および存続期間を所与（ｇｉｖｅ）として、擬似リソースクライアントが適切であるかどうかを判定する。擬似リソースクライアントが適切な措置であるとサービスが確認した場合でも、サービスは、クライアントのバジェット１０４を探し出し、自らをバジェット１０４に結び付けるのに十分な特権を有さなければならない。サービスは、擬似リソースクライアントを達成するのに十分な特権を有さない場合、またはそのような処理が不適切であると判定した場合、以下に説明するとおり、リソース使用量を制限する代替のアクションを行うことができる。
【００７２】
サービスのために動作しているプロセス２０４またはスレッド２０２は、任意の数のクライアントにサービスを提供することができるが、特定のクライアント要求に応答して、（ハンドルなどの）存続するリソースを割り当てることができるので、プロセス（またはスレッド）は、この使用に対して何らかの種類の制限をクライアント別に課すことを所望することができる。このため、サービスプロセス２０４またはサービススレッド２０２は、自らのリソース消費量をクライアント別に制限する２つのアプローチ、すなわち、所与のクライアント１０２がサービスを呼び出すことが可能なレートを制限するか、またはプロセス２０４またはスレッド２０２のクライアント群（ｃｌｉｅｎｔｅｌｅ）を反映するように自らのバジェットを分割するかのいずれかを行うことが可能である。
【００７３】
第１の場合、サービスは、クライアントがサービスを呼び出すことができるレートを制限するようにリソースマネージャ１０８によって提供されるレートコントローラ１２０の機能を使用することにより、特定のクライアントがサービス独自のリソースを使い尽くすようにサービスに強制されるレートを制御することが可能である。これにより、特定のクライアントの要求が、システムにおけるすべてのクライアントのニーズに対応するサービスの能力に与える可能性のある影響を軽減することが可能である。すべてのクライアントバジェットに、すべてのサービスに関するレート限度を配分する場合のオーバーヘッドを回避するため、デフォルトでは、そのような限度は、通常いずれのバジェット１０４の中にも全く存在しない。むしろ、そのような制限を課すことに関心があるサービスは、限度４１４をクライアントのバジェット１０４の中に動的に挿入することができるが、これは、通常は適切なアクセス権を要する操作である。例えば、リソースプロバイダ１１２が、特定のリソースに関して請求しようと試みた際に戻された障害コードに基づき、動的限度挿入を自動的に試みることができる。次に、リソースマネージャ１０８が、クライアントのアクティブなバジェット１０４を適用する際、リソースレートコントローラ１２０を使用して、その限度を適用することができる。バジェット１０４に関連するいずれのクライアント１０２も、さらなるサービス別の限度をバジェットの中に挿入することができるので、リソースマネージャ１０８は、レート再充填（ｒｅｐｌｅｎｉｓｈｍｅｎｔ）中、最長未使用時間の（ｌｅａｓｔ  ｒｅｃｅｎｔｌｙ  ｕｓｅｄ）バジェットのエントリを定期的に消去（ｐｕｒｇｅ）することができる。
【００７４】
第２の場合、サービスは、関心対象の（ｏｆ  ｉｎｔｅｒｅｓｔ）各クライアントにフレーバ４０４を割り当て、そのフレーバに関連する所望のリソース限度４０６をサービス独自のアクティブなバジェット４１８の中に動的に挿入する４１６ことができる。これにより、サービスが、サービス独自のリソース使用をクライアント別の形で配給する（ｒａｔｉｏｎ）ことが可能になる。この場合、いずれのフレーバがいずれのクライアントに対応するかを追跡する負担は、サービスにかかり、リソースマネージャ１０８にはかからないのに対して、第１の場合、限度がクライアントバジェット１０４の中に挿入されると、リソースマネージャ１０８がその限度自動的に遵守することに留意されたい。
【００７５】
第２の場合で示すフレーバの使用は、使用の種類に基づいてリソースの自らの使用を管理することを望むクライアント１０２にも、同様の形で適用することができることに留意されたい。その場合では、クライアントは、クライアント独自のフレーバ４０４、ならびに対応するフレーバリソース限度４０６を保持し、クライアントが特定のリソースをどのように現在使用しているかに依存して、それらの限度をクライアントのアクティブなバジェット１０４の中に動的に挿入する。
【００７６】
ドライバは、サービスと同様な形で、リソースを制限することができる。しかし、一般に、ドライバは、必ずしもクライアント要求に応答してコードを実行するのではなく、外部イベントに応答してコードを実行する可能性があるので、正しい擬似リソースクライアントは困難になる。このため、ドライバは、リソース割り当てを実行する際、適切な状態にない可能性がある。ドライバは、擬似リソースクライアント手法をとることを所望する場合、適切なバジェットへの参照を自ら保持し、それらのバジェットの使用を適切に管理することができる。この場合も、そのような手法により、クライアントバジェットは、ドライバリソース漏れ（ｌｅａｋ）および／または逸脱したリソースを使用されやすい状態のままとなる。さらに、ドライバによって割り当てられたがクライアントバジェットに請求される。存続するカーネル状態を考慮した場合、公平性の問題が生じる。通常の実施形態では、ドライバは、前述したとおり、クライアント別のフレーバ４０４、およびフレーバリソース限度４０６を使用して、ドライバ独自のバジェットを分割することにより、そのような問題を回避し、相応してリソースを割り当てることができる。しかし、ドライバは、単一のクライアントの事情で実行されないため、アクティブなフレーバは、パラメータとして、または実際のバジェットへの参照を送ることにより、リソース割り当てＡＰＩに対して明示的に指定されること、またはドライバの実行の期間にわたって、現在のクライアント（または現在のプロセッサ）に暗示的に関連付けられることができる。
【００７７】
図５は、本発明の実施形態を実施するための、図１に示したリソース通知サービス１２４のいくつかのコンポーネントの構成をさらに詳細に示すブロック図である。リソース管理は、リソースが管理されているクライアント１０２からの協力があって、最もうまく機能する。したがって、リソース管理システムの通常の実施形態は、通知サービスコンポーネント５００を含む。図示する実施形態では、通知サービス５００は、リソース通知５０２をクライアント１０２に配信して５０８、リソース管理システム１００が、それらのクライアントの協力を求めて、より少ないリソース消費または一時停止を実現すること、または、クライアントに影響を与える可能性があるもしくは別の形でクライアントの関心を引く可能性があるリソース利用可能性の変化をクライアント１０２に知らせることが必然的にできるようになる。通知５０２の目的は、クライアント１０２にリソースマネージャ１０８と協力する機会を与えることであるが、システム１００は、クライアントが逸脱している（ｅｒｒａｎｔ）場合でも、最善を尽くして（ａｓ  ｂｅｓｔ  ｉｔ  ｃａｎ）機能しつづけなければならない。
【００７８】
通知サービス５００は、信頼できる軽量のイベント通知機構を関心のあるクライアント１０２に提供する。クライアント１０２は、所望の配信方法を選択することができ、配信方法は、様々なレベルの配信保証を有する。通常の実施形態では、通知５０２は、生じたイベントのセットを表すビットマスク５０４から成る。さらに、クライアント１０２と通知プロバイダ、例えばリソースマネージャ１０８またはリソースプロバイダ１１２の間で、通常、帯域外ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を使用することにより、通知５０２に関連する補助通知パラメータ５０６を、オプションとして通信することが可能である。
【００７９】
一実施形態では、通知サービス５００は、プルシステムを利用して、イベント配信を管理し、完全な通知ビットマスク５０４を取得するとした場合、いつ取得するかを決める自由をクライアント１０２に与える。クライアントの関心セット（通知プロバイダのサポートされるビットマスクの、何らかのクライアントによって指定されたサブセット）の中のイベントの最初の発生により、クライアントによって指定された配信技術が始動する（ｔｒｉｇｇｅｒ）一方で、同一種類であるかまたは同一種類ではない後のイベントは、バッチ処理されて、格納されたビットマスクの中に入れられる。このため、特定のイベントはクライアントがビットマスク５０４を取得することを選択するまで繰り返えされず、選択した時点で、バッチ処理されたビットマスクがリセットされる（すなわち、消去される）。選択された配信方法に依存して、このアプローチは、通知５０２を自らの意志で処理する自由をクライアント１０２に与える。リソース通知サービス１２４の例示的な使用を、図６におけるリソース調停を参照して以下に説明する。
【００８０】
図６は、本発明の実施形態による、リソース調停６００を実行するための、図１に示したリソース管理システム１００のいくつかのコンポーネントの構成をさらに詳細に示すブロック図である。動作の際、リソースプロバイダ１１２が、要求側クライアント１０２Ｄからリソース割り当て要求を受け取る。要求側クライアント１０２Ｄが単にバジェットリソース限度を超えたからではなく、利用できるリソースが不十分であるために、リソースプロバイダ１１２がリソース割り当てを満たすことができない場合、リソースプロバイダは、リソースアービタ１２２の機能（ｆａｃｉｌｉｔｉｅｓ）を使用してリソース調停を実行するよう、リソースマネージャ１０８に要求することができる。
【００８１】
通常の実施形態では、リソースプロバイダ１１２は、要求側クライアントの要求を満たすために、何らかの未処理の割り当てからリソースが回収されるべきかどうかを判定するのに必要な情報を、リソースマネージャ１０８に提供する。リソースマネージャ１０８は、ポリシーモジュール１１４において実現される動的ポリシー状態に関連してこれを判定する。図１を参照して説明したとおり、ポリシーモジュール１１４は、他にもコンポーネントが存在するが、とりわけ、ポリシーマネージャ１１６またはバジェットマネージャ１０２Ｃなどの、より高いレベルのエンティティによって配置される（ｐｏｐｕｌａｔｅｄ）、クライアント優先順位およびユーザ選好のポリシーデータベース１１８を備える。ポリシーモジュール１１４の詳細を、図７を参照してさらに詳細に説明する。
【００８２】
実施例として、ポリシーデータベース１１８は、ユーザが、最高の選好を要求側クライアント１０２に割り当てたことを示すことができる。動的ポリシー状態も、潜在的な回収目標クライアント１０２Ｅ、ならびにリソースを回収するために目標に対して行うことができる、許されるアクションのセットを示すことができる。動的ポリシー状態の中で反映される現在のポリシーに依存して、リソースマネージャ１０８は、必要なあらゆる手段を使用することによって要求側のクライアントの割り当て要求を満たすよう、プロバイダに命令することによって、呼び出し側リソースプロバイダ１１２の調停要求に応答することができる。必要なあらゆる手段には、その目標に関して許されたアクションセットの中で指定されたアクションに従って、１つまたは複数の目標１０２Ｅに割り当てられていることができるリソースを回収することが含まれる。
【００８３】
要求側クライアント１０２Ｄによって使用するためにリソースを回収しようと試みる際、リソースプロバイダ１１２は、リソースを回収することができる潜在的な目標クライアント１０２Ｅを選択する。リソースマネージャ１０８が、回収のための目標（動的ポリシー状態の中で示される）を示唆しない場合、リソースプロバイダ１１２は、プロバイダ１１２が適切であると考えるリソースのクライアントを選択することができる。リソースプロバイダ１１２が目標を選択すると、リソースマネージャは、問題のリソースを解放するために１つまたは複数の目標から協力を求め、リソース通知サービス１２４を使用してリソース通知５０２を発行することができる。または、これに代えて、またはさらに、リソースプロバイダ１１２は、独自のリソース通知５０２を（この場合も、リソース通知サービス１２４を使用して）発行すること、および／または動的ポリシー状態の中で示されるアクションのセットから選択された１つまたは複数のアクションを使用することにより、リソースの回収を開始することができる。アクションのセットは、（目標クライアント１０２Ｅに連絡をとり、一定の量のリソースをクライアント１０２が自発的に譲ることを要求する、例えば、通知５０２を発行する）受動的アクションから、（リソースを強制的に回収する）事前対応アクション、（目標を終了させる）積極的アクションまで様々とすることができる。一実施形態では、うまく記述された（ｗｅｌｌ−ｗｒｉｔｔｅｎ）クライアントは、リソース状態変化に関して、リソースマネージャ１０８および様々なリソースプロバイダ１１２によって発行された様々な通知に従うことにより、受動的アクションに切れ間なく協力することが可能である。例示的な通知５０２は、「単位数のリソースＸを解放する（ｒｅｌｅａｓｅ  ｕｎｉｔｓ  ｏｆ  ｒｅｓｏｕｒｃｅ  Ｘ）」、または場合により、「後の再開のために状態を凍結する（ｆｒｅｅｚｅ  ｓｔａｔｅ  ｆｏｒ  ｌａｔｅｒ）」を含むことができる。
【００８４】
クライアント１０２が、発行された通知を無視することなどにより、通知５０２に協力しない場合、またはこれに代えて、目標クライアント１０２Ｅが、リソース管理より前の時代の（ｐｒｅｄａｔｅ）古い（ｌｅｇａｃｙ）レガシアプリケーションである場合、またはリソース管理に参加しないことを選択した場合、またはそれ以外で応答しない場合、リソースプロバイダ１１２は、事前対応アクションまたは積極的アクションを使用して、リソースを解放する試みを増やすことができる。
【００８５】
前述したとおり、回収可能なリソースは、アプリケーションの協力なしに、アプリケーションから安全に取り戻すことが可能なリソースである。リソースは、アプリケーションからトランスペアレントな形で常に回収することが可能であるが、目標クライアント１０２Ｅは潜在的に、低下したパフォーマンスから、低下した機能、異常終了まで様々な影響を受ける可能性がある。回収（ｒｅｃｌａｍａｔｉｏｎ）は、目標の動作に対する影響が、予測可能であり、予期しない終了につながらない場合にのみ、より積極的なアクション（例えば、アプリケーションを終了させること）より好ましい。例えば、回収方法には、帯域幅保証を守ることを止めること、アプリケーションをスケジュール解除すること、ハンドルを無効にすること、およびメモリリソースをマップ解除することを含むことが可能である。この実例では、最初の２つの場合でだけ、回収によって、妥当であると考えられる。というのは、後の２つの場合では、予測不能な（ｎｏｎ−ｄｅｔｅｒｍｉｎｉｓｔｉｃ）影響が生じる可能性があるからである。
【００８６】
消費される合計ＣＰＵ時間や、被るページフォールト総数などの、前述した回収することが不可能なリソースは、一般にリソース調停を受けないことに留意されたい。これは、回収することができないリソースの割り当て失敗が、通常リソースマネージャ１０８によって実施される作為的なバジェットに組み込まれた限度Ｌ２０８に起因する場合だけ生じ、その場合、リソース調停は不必要だからである。
【００８７】
図７は、本発明の実施形態を実施するための、図１に示したポリシーモジュール１１４のいくつかのコンポーネントの構成をさらに詳細に示すブロック図である。図示するとおり、ポリシーモジュール１１４は、他にもコンポーネントが存在するが、とりわけ、ポリシーデータベース１１８と、１つまたは複数のポリシーマネージャ１１６とを備える。ポリシーは、静的部分７０２と動的部分７０４の少なくともどちらかで表現され、部分７０２と部分７０４は、リソースマネージャ１０８およびリソースプロバイダ１１２が、リソースを確保する要求およびリソースを割り当てる要求を認める判定、または拒否する判定を行う際に使用する動的ポリシーデータベース状態７０６をともに構成する。静的部分７０２は、一般に、ポリシーデータベース１１８の中に記録された情報を表し、動的部分７０４は、一般に、アクティブなバジェットオブジェクト７００の中で保持される限度Ｌ２０８、確保Ｒ２１０、およびコミットされたリソースＣ２１２などの、プロセスまたはスレッドが作成された時点で生成された情報を表す。
【００８８】
図７における例示する実施形態で示すとおり、動的ポリシーデータベース７０６は、一意の＜アプリケーションＩＤ，ユーザＩＤ＞（＜Ａ，Ｕ＞）タプル（ｔｕｐｌｅ）によって識別されるポリシーデータベースエントリを備えることができる。プロセス２０２またはスレッド２０４は、開始、または作成されると、＜Ａ，Ｕ＞タプルにマップされる。各＜Ａ，Ｕ＞タプルは、マップされたプロセスおよびスレッドに関する、相対優先順位の指示、および許されたアクションセットを含むことができる。また、データエントリは、＜Ａ，Ｕ＞タプルにマップされたプロセスおよびスレッドにアクティブに関連することが可能なバジェットまたはバジェット群１０４を特定することもできる。
【００８９】
通常の実施形態では、許されたアクションセットは、リソース競合を調停する過程で許容できると考えられるアクションのセットを記述する。最高優先順位レベルにない、いずれの＜Ａ，Ｕ＞タプルに関しても、少なくとも１つのそのようなアクションが指定されなければならない。前述したとおり、許されたアクションは、受動的アクションから、事前対応アクション、積極的アクションまで、厳しさの幅を有することができる。例示的なアクションには、リソースを譲るよう（タイムアウトを伴って）クライアント１０２に要求すること、確保されたリソースをトランスペアレントな形で回収すること、割り当てられたリソースを回収すること、状態を保存し、休止（ｑｕｉｅｓｃｅｎｔ）状態に移るようクライアント１０２に要求すること、またはクライアントを強制的に終了して、競合対象の（ｉｎ  ｃｏｎｔｅｎｔｉｏｎ）リソースを回収することが含まれる。許されたアクションセットの中で、アクションが全く指定されていない場合、対応する＜Ａ，Ｕ＞タプルにマップされたいずれのプロセスまたはスレッドも、すべてのリソース調停アクションは実行されず、無限の優先順位を持つとみなされる。
【００９０】
他にも用途はあるが、とりわけ、動的ポリシーデータベース状態７０６は、割り当て失敗、ならびにリソースプロバイダ１１２からの後の調停要求の結果、生じる可能性があるあらゆる競合（ｃｏｎｆｌｉｃｔ）の解決において、リソースマネージャ１０８を支援する。可能な措置をリソースプロバイダ１１２に示唆することで、動的ポリシーデータベース状態７０６は、リソースマネージャ１０８が、Ｗｉｎｄｏｗｓ（登録商標）およびその他のオペレーティングシステムの最新バージョンにおいて見られる先着順サービスの割り当てポリシーを大幅に改良することができる点で有利である。
【００９１】
ポリシーモジュール１１４の別の態様は、特定のクライアント１０２のリソース要件および／またはリソース制限を前もって記述するポリシーデータベース１１８の中に、情報を格納することである。一実施形態では、オペレーティングシステムは、その格納された情報の問い合わせを行い、その情報を利用して、クライアント１０２のために実行されているプロセス２０２またはスレッド２０４を、適切なバジェット１０４またはバジェット階層３００の中に含まれる妥当なリソース要件およびリソース制限によって管理して、確実に処理を開始することを可能にする。この要件および制限は、プロセス作成時点に適用されて、プロセス２０２またはスレッド２０４が、ポリシーモジュール１１４の中で指定された要件および制限を外れて実行されることを防止する。ポリシーマネージャ１１６は、この特徴を活用して、とりわけ、潜在的に有害な（ｒｏｇｕｅ）アプリケーション（クライアント）を確実に分離し、または一部のクライアントが、要求されるリソースのセットをオペレーティングシステムが前もって確保可能な場合にだけ、確実に起動可能にすることができる。
【００９２】
図８は、本発明の実施形態による、リソースプロバイダと、リソースを割り当てる８００、図１に示したリソース管理システムのいくつかのコンポーネントとの間の対話をさらに詳細に示すブロック図である。図示するとおり、クライアントリソース要求８０２が、担当のリソースプロバイダ１１２に対して発行され、プロバイダ１１２は、その要求を満たし、要求側クライアントリソース割り当て８０８を実行することが可能か、またはリソースマネージャ１０８を介してクライアントリソース要求８０２の承認（ｖａｌｉｄａｔｉｏｎ）を求める要求８１０を生成することにより、リソース管理システム１００に参加するかを判定する。これに代えて、またはさらに、リソースプロバイダ１１２が、リソース競合に起因してクライアントリソース要求８０２を満たすことができない場合で、リソースプロバイダは、リソースマネージャ１０８から調停を求める要求８１０を生成し、調停要求８１０の結果に従って、目標クライアントリソース回収８１２を後に実行することにより、リソース管理システム１００にさらに参加することができる。
【００９３】
通常の実施形態では、承認および調停を求める要求８１０は、リソース要求８０２を発行したクライアントに対応する＜Ａ，Ｕ＞タプルを指定するクエリ８０４の形態で実装することができる。クエリ８０４は、動的ポリシーデータベース状態７０６に対して適用され、対応する＜Ａ，Ｕ＞タプルが、指定された＜Ａ，Ｕ＞タプルより低い優先順位であるプロセスまたはスレッドのリストを含む結果リスト８０６が戻される。通常の実施形態では、リソースプロバイダ１１２は、オプションとして、問題のリソースを現在、使用しているプロセス（またはスレッド）のリストをクエリ８０４に供給して、動的ポリシーデータベース状態７０６から取得される結果リスト８０６が、適当な数のエントリにまで適切に削減される（ｔｒｉｍｍｅｄ）ことが可能なようにすることができる。
【００９４】
図９は、本発明の実施形態によるリソースを管理するための方法のリソース管理ワークフロー９００を示す流れ図である。とりわけ、リソースマネージャ１０８、リソースプロバイダ１１２、バジェット１０４およびバジェット階層３００、ならびにバジェット１０４および階層３００のそれぞれのバジェットに組み込まれた値、およびポリシーモジュール１１４を含む、リソース管理システム１００の様々なコンポーネントの以上の説明を参照して、リソース管理ワークフロー９００を説明する。
【００９５】
ワークフロー９００は、リソースを割り当てるのに先立って、リソースプロバイダ１１２からリソースマネージャ１０８に制御を移すプロセス９０２を備え、その後に、リソースマネージャ１０８が、リソースプロバイダ１１２から、クライアントのリソース確保要求またはリソース割り当て要求を承認する要求を受け取るプロセス９０４を備える。リソースマネージャ１０８は、判定ブロック９０８で承認を開始し、その時点で、リソースマネージャ１０８は、割り当て要求に関連するアクティブなバジェット９０６、すなわち要求を開始したプロセス２０２またはスレッド２０４に関連するアクティブなバジェット１０４を調べる。図３Ａ〜図３Ｂを参照して説明したとおり、リソースマネージャ１０８は、アクティブなバジェット１０４、ならびにアクティブなバジェットが一部を成すバジェット階層３００における、現在のバジェット限度Ｌ２０８値、確保Ｒ２１０値、およびコミットＣ２１２値を適用する。これを行う際、リソースマネージャ１０８は、要求がバジェットに組み込まれた値を超える場合、その要求を拒否することができる。その場合、プロセス９１０で、リソースマネージャ１０８は、リソースプロバイダ１１２がレート制御を要求した場合、レート制御を実行することができ、あるいはプロセスブロック９１２でリソースプロバイダ９１２に制御を戻すことができ、プロバイダ１１２は、プロセス９２０でクライアントに制御を戻し、クライアントのリソース確保要求またはリソース割り当て要求を拒否することができる。
【００９６】
要求が、バジェットに組み込まれた値の範囲内にある場合、リソースマネージャ１０８は、その要求を認めることができる。プロセスブロック９１４で、リソースマネージャ１０８は、クライアントの事前に確保されたプールから満たすことが可能なクライアントの割り当て要求の部分について、リソースプロバイダ１１２にさらに知らせることができる。制御は、プロセスブロック９１６で、リソースプロバイダ１１２に戻され、その後、リソースプロバイダ１１２が、要求側クライアントによって必要とされるとおりに、リソースを割り当てようと試みることができる。判定ブロック９１８で、割り当てが成功した場合、プロセス９２０で、制御を要求側クライアントに戻すことができる。そうではなく、割り当てが失敗した場合、リソース競合が生じている。その時点で、プロセスブロック９２２で、リソースプロバイダ１１２は、オプションとして、リソースマネージャ１０８にリソース調停を求めて、可能な場合、図６を参照して前述したとおりの調停に従って、リソースを回収することができる。十分なリソースが回収されると、リソース管理ワークフロー９００は、プロセスブロック９１６で再開して、前述したのと同一の形で、割り当て要求を再試行することができる。
【００９７】
図１０は、本発明の実施形態を実施するのに使用することができる例示的なリソースマネージャバジェットインタフェース群１０００の概略ブロック図である。以下のテーブル１は、インタフェース群、およびインタフェース群の意図される対象ユーザ（ａｕｄｉｅｎｃｅ）を要約する。テーブルの後で、各インタフェースを簡単に説明する。
【００９８】
【表１】
2006236351.tif 000003
【００９９】
一実施形態では、ポリシーマネージャ１１６およびクライアント１０２がバジェット作成インタフェース１００２を使用し、バジェット１０４およびバジェット階層３００を作成し、操作することができる。通常の実施形態では、バジェット１０４は、図２を参照して前述したとおり、バジェットオブジェクト２００として作成される。インタフェース１００２のデフォルトの動作により、新たに作成されたバジェットオブジェクト２００を呼び出し元の現在のアクティブなバジェットに自動的にリンクして、バジェット階層３００の一部を形成することができる。一実施形態では、呼び出し元は、現在の階層を「免れる」こと所望することを示すパラメータをオプションとして指定することにより、デフォルトの動作を無効にする（ｏｖｅｒｒｉｄｅ）ことができる。現在の階層を免れることにより、バジェット１０４は、実質的に、独自のルートバジェットになる。そのような操作（ｍａｎｅｕｖｅｒ）は、現在のバジェット階層における別の場所に存在する制約から、そのバジェットを解放する。
【０１００】
ほとんどの場合、クライアント１０２は、クライアント１０２独自のバジェット１０４を作成して管理することはない。というのは、手動でそれを行うことは、困難であり、誤りを犯しやすく、厄介だからである。むしろ、バジェット作成の作業は、ポリシーマネージャ１１６を使用して、その作業を正しく実行する知識と権限をともに有する管理者の役を務める人間サービスまたはソフトウェアサービスに任される。その場合、ポリシーマネージャ１１６は、バジェット作成インタフェース１００２を使用して、バジェットを関連付けることができるプロセス２０２またはスレッド２０４が作成されると同時に、バジェットを作成することができる。バジェットを生成するのに使用されるデータ（例えば、どのようなパラメータが、バジェット限度Ｌ２０８を設定（ｐｏｐｕｌａｔｅ）するのに使用されるべきか、いずれの確保を前もって実行すべきか、その他）を、ポリシーデータベース１１８から、またはシステム動作を調整する経験則（ｈｅｕｒｉｓｔｉｃｓ）を使用する自動化された管理ソフトウェアから獲得することができる。通常の実施形態では、リソースの利用可能性、クライアントの性質、およびユーザ選好が考慮される時点で、ポリシーデータベース１１８を前もってポピュレートすることができる。
【０１０１】
一般に、バジェット作成インタフェース１００２を使用してバジェット１０４が最初に作成される際、バジェット１０４の中でコミットされる、または確保されるリソースは、全く存在しない。したがって、（マシンのパーティションおよび分離を達するために）事前の設定（ｐｒｅ−ｐｏｐｕｌａｔｉｏｎ）を要するバジェットは、通常、バジェット作成インタフェース１００２を使用してポリシーマネージャ１１６によってまず作成され、次に、リソース確保インタフェース１００４に渡されて、次に説明するとおり、必要な確保を実現する。
【０１０２】
プロセス作成時に、プロセスグループ、プロセス、または（場合により）スレッドに、バジェット１０４を動的に関連付けることができる。例えば、一実施形態では、バジェット作成インタフェース１００２を使用して作成されると、バジェット１０４は、プロセス（またはスレッド）作成を扱うルーチンに引数として渡されて、新規のプロセス（またはスレッド）が、バジェットの中で指定されたリソース制限に自動的に関連付けられ、したがって、そのような制限を受けるようにすることができる。
【０１０３】
バジェット作成インタフェース１００２を使用して、バジェット作成の時点で１つまたは複数のフレーバを示すパラメータを指定することにより、リソース使用量を外部から分割することができる。そのような指示が存在しない場合、バジェット作成インタフェース１００２のデフォルトの動作は、すべてのリソース使用の請求が行われる、単一の中立のフレーバを有するバジェットを作成することができる。これに代えて、またはさらに、フレーバ挿入インタフェース１０１６に関連して以下に説明するとおり、１つまたは複数のフレーバを、バジェットの作成の後、バジェットの中に動的に挿入することもできる。これは、ユーザがフレーバを使用して、リソース使用量を内部で分割することに加え、例えば特定のタスクによるリソースの消耗（ｅｘｈａｕｓｔｉｏｎ）を制限し、またはエラーから回復する際に使用するためのリソースを確保する。
【０１０４】
一実施形態では、クライアント１０２が将来の使用のために１つまたは複数のリソースを確保するのに、リソース確保インタフェース１００４を使用することができる。このようにして、リソース獲得の順序付けが関わるデッドロック（ｄｅａｄｌｏｃｋ）条件を回避するために、リソースを獲得するトランザクション上の処理が、クライアント１０２に課せられる。しかし、これは、主に、クライアント１０２への支援であり、クライアントが所望する場合、インタフェース１００４は、リソースを確保するように複数回、独立に呼び出すことができ、または長い間（ｏｖｅｒ  ｔｉｍｅ）呼び出すことができる。リソースを確保することにより、一般に、その量のリソースが、システム全体で利用できなくなるので、事実上（ｉｎ  ｎａｔｕｒｅ）確保は、通常、控えめなものである。ソフト限度を使用して、確保の乱用の恐れを改善し、リソースが十分に利用されないことを回避することができる。
【０１０５】
通常の実施形態では、確保がうまく行われると、確保値Ｒ２１０は、その確保を反映するように更新され、およびクライアント１０２はｑ、リソース調停の必要なしにバジェットのコミット値Ｃ２１２で表されるリソースのその量までコミットすること、すなわちクライアント１０２は、通常のサービスレベルで、限度Ｌ２０８までコミットすることができる。バジェットの限度Ｌ２０８がソフト限度である場合、クライアント１０２は、低下したサービスレベルで、限度Ｌを超えてリソースをコミットして、システムが、将来、他のＣｎ割り当てのために、そのリソースを効率的に回収することができるようにする。
【０１０６】
一実施形態では、リソース確保インタフェース１００４は、現在アクティブなバジェット、および該当するバジェット階層３００が存在する場合、その階層３００の状況において、確保要求を検証、すなわち確保要求を認めるか、または拒否する手段を提供する。対応するリソースの実際の確保は、通常、リソースプロバイダ１１２自体によって別個に扱われる。このようにして、リソースに対する２つのレベルの制御が実行される。１つは、現在のアクティブなバジェットに従った、ならびに存在する場合バジェット階層に従った、リソースマネージャ１０８による制御であり、１つは、リソースプロバイダ１１２による制御である。このため、現在、アクティブなバジェットおよびバジェット階層に関して認められる確保要求は、適切なリソースプロバイダ１１２に提示された際、不合格になる可能性があり、同様に、リソースプロバイダ１１２によって容認できると考えられたであろう確保要求も、リソースマネージャ１０８によって事前対応の形で拒否される可能性がある。
【０１０７】
リソース確保インタフェース１００４を使用して、該当するバジェット階層３００の状況で特定の確保要求が承認されると、リソースプロバイダ１１２には、すべての未処理の確保を所与として、実際のリソース確保を満たすことが可能かどうか、すなわち、割り当てることができるかどうかを判定する責任が課される。したがって、受付コールバック登録インタフェース１００６が提供されて、クライアントの確保要求がリソースプロバイダ１１２によって認められたか否かをリソースマネージャ１０８が確認することが可能となる。確保要求が認められると、そのリソースの分量は、他のクライアント１０２による通常のコミットＣｎ使用に利用できなくなる。したがって、要求が認められると、リソースマネージャ１０８は、未処理のリソース確保の現在の状態を正確に反映するように、バジェット階層３００における適切なバジェットまたはバジェット群を更新する。
【０１０８】
一実施形態では、クライアント１０２は、バジェット１０４の中で保持される特定の制限および要件を調べるのに、クエリバジェットインタフェース１００８を使用することができる。例えば、バジェットに問い合わせを行う能力は、バジェットを継承するまたは外部から割り当てられたバジェットを有するクライアント１０２にとって、特に役立つ可能性がある。クライアントのバジェットの現在の状態を調べることにより、クライアントは、どのようにクライアントのリソース使用量を調整して、クライアントのバジェットの範囲内に留まるかについて、情報を得た上で決定を行うことができる。例えば、クライアントのバジェットに問い合わせを行った後、クライアントは、所望のリソースが利用可能になったという通知などを受け取るように、リソースマネージャ１０８およびリソースプロバイダ１１２に登録する（ｒｅｇｉｓｔｅｒ）ことを所望することができる。別の実施例として、通知を受け取るのを待つのではなく、代わりに、クライアント１０２は、クライアント１０２が必要とするリソースをより迅速に獲得しようとして、クライアント１０２が必要と考えるとおりに、クライアント１０２のバジェットを変更することを決めることができる（クライアント１０２が、それを行うのに十分な権限を有するものと想定して）。さらなる実施例として、リソースマネージャ１０８は、通知を使用して、キャッシュされる情報のサイズを小さくすることにより、または、空間対時間または時間対空間のトレードオフを行うのに使用されるアルゴリズムのセットを変更することにより、クライアントのリソース消費量を減らすように、協力するクライアントに要求することができる。リソースマネージャは、バジェットの中の限度をさらに調整して、システムが、過剰にリソース不足になるのを防止することができる。
【０１０９】
時間とともにリソースの消費量を追跡するために、消費量記録インタフェース１０１０をリソースプロバイダ１１２に提供することができる。一実施形態では、リソース管理システム１００に参加している各リソースプロバイダ１１２は、提供されるリソースをクライアント１０２に割り当てた後、すなわち、リソースがコミットされた後、消費量記録インタフェース１０１０を呼び出すことを担う。次に、リソースマネージャ１０８は、リソースを回収することを目的とする、任意の可能な将来のリソースマネージャ判定を円滑にするために、コミット済みのリソース値（Ｃｎ）を追跡することができる。これに対して、コミットされたリソースのいずれの部分が、超過コミットＣｅとして分類されることが可能であるかを追跡し管理することは、剰余量に関連して以下に説明するとおり、リソースプロバイダ１１２に任される。
【０１１０】
通常の実施形態では、リソースの消費量を追跡するために消費量記録インタフェース１０１０を使用することは、例えば、リソース確保インタフェース１００４を使用することにより、その量は前もって確保されている必要はない。リソースは、利用可能である場合、そのリソースがクライアント１０２に割り当てられた時点で、デフォルトで暗示的に「確保」されている。現在アクティブなバジェットを適用したことにより、リソースマネージャ１０８が、記録された消費量の全部の量を通常のコミットＣｎの一部として認めることを禁じられる場合、消費量記録インタフェース１０１０は、剰余量をリソースプロバイダ１１２に折り返し報告することができる。その場合、ソフト限度をサポートするリソースプロバイダ１１２は、超過コミットＣｅリソースを許容できることをクライアント１０２が示しているものと想定すると、オプションとして、その剰余量をクライアントに超過コミットＣｅとして分配することができる。超過コミットＣｅリソースは、通常のコミットＣｎよりも容易に回収することができるため、一部のクライアントは、超過コミットなしで済ませて（ｆｏｒｅｇｏ）、通常のコミットで割り当てられることが可能なリソースが利用可能になるまで待つことを選好する可能性がある。ほとんどの暗示的に消費されるリソースの場合では、関連するリソースプロバイダ１１２は、通常、リソースの超過コミットＣｅ割り当てを管理するのに、相当な柔軟性を有する。
【０１１１】
通常の実施形態では、リソースプロバイダ１１２は、消費量記録インタフェース１０１０において、請求が行われるリソースのＩＤを指定する。このようにして、リソースマネージャ１０８は、正しいリソースの消費を請求することができる。さらに、リソースマネージャ１０８は、以下にさらに詳細に説明する一部の動的に導入されるリソースの場合と同様に、限度挿入インタフェース１０１４を使用して、動的限度をバジェットの中に挿入する必要があるかどうかも判定することができる。
【０１１２】
特定のバジェット１０４に関して追跡される通常のコミットＣｎ値がバジェットのセンチネル値２１４を超えた場合に、１回限りの通知を受けるように登録するため、センチネル設定インタフェース１０１２を、ポリシーマネージャ１１６、クライアント１０２、およびサービスに提供することができる。追加の通知が所望される場合、ポリシーマネージャ１１６およびクライアント１０２は、センチネル設定インタフェース１０１２を使用して、明示的に再登録することができる。一実施形態では、登録者は、所望の通知配信方法を指定することができ、その方法には、図５を参照して全体的に説明するリソースマネージャ１０８によってサポートされる通知機構群の少なくともすべてが含まれる。実施例として、センチネルベースの通知は、リソース消費量がバジェットのセンチネル値を超えると、リソース料金請求（ｂｉｌｌｉｎｇ）モデルを変更するのに役立つ可能性がある。
【０１１３】
バジェット１０４の中に限度Ｌ２０８を動的に挿入するために、限度挿入インタフェース１０１４をポリシーマネージャ１１６に提供することができる。例えば、図４を参照して説明したとおり、リソースが、クライアントのために動作しているサービスによって消費される場合、サービスは、限度挿入インタフェース１０１４の使用を介して、クライアントのアクティブなバジェットの中に限度を挿入して、サービスのリソースを使い尽くすように、クライアントがサービスに強制することができるレートを制御することができる。その後に呼び出されると、クライアント１０２は、動的に挿入された限度により管理される。通常の実施形態では、信頼されるポリシーマネージャ１１６およびサービスだけが、目標バジェットへの動的限度挿入を実行するのに不可欠な特権を有することができる。というのは、クライアントバジェットの中に低い限度を悪意のある形で挿入することにより、サービス拒否攻撃がなされる可能性があるからである。
【０１１４】
図４を参照して前述したとおり、バジェット１０４の中にフレーバを動的に挿入するために、クライアントのために動作しているサービスおよびドライバを含むクライアント１０２に、フレーバ挿入インタフェース１０１６を提供することができる。一実施形態では、クライアント１０２は、フレーバ挿入インタフェース１０１６を使用して、クライアント１０２独自の現在のアクティブなバジェットに対して、フレーバ挿入を実行することができる。相異なるクライアントに属するバジェットの中に動的にフレーバを挿入することにより、フレーバの目的が達せられなくなる可能性があり、フレーバは、クライアント独自のリソース使用を、クライアント独自のバジェットによって課せられた制約の範囲内でやりくりする（ｍａｎａｇｅ）手段をクライアントに提供することを一般に意図して考えられるものである。この困難を回避するため、フレーバを使用するリソースの内部分割および外部分割は、別々のフレーバセットに依拠しなければならない。
【０１１５】
図４で導入した実施例では、サービスは、フレーバ挿入インタフェース１０１６を使用して、サービスが代行で動作している特定のクライアント１０２のＩＤに基づき、サービスのバジェットのフレーバ（パーティション）を画定する（ｄｅｌｉｎｅａｔｅ）ことができる。クライアント１０２とフレーバの間のマッピングを確立することは、サービスに完全に任される。リソースの消費が代行で行われている特定のクライアントに基づき、リソース使用量を配給することを所望するドライバ群は、同様のシナリオを使用することができる。このため、フレーバ挿入インタフェース１０１６を使用してフレーバを動的に挿入することを選択するサービスまたはドライバに、フレーバ管理の負担がかかってくる。
【０１１６】
これに代えて、またはさらに、許されたメモリ使用量を事前定義された静的パケットタイプセットの間で分割することを所望するネットワークドライバなどの、動的フレーバが全く必要ない場合では、フレーバ挿入インタフェース１０１６を使用して動的にフレーバを指定する必要はない。むしろ、所望のフレーバは、バジェット作成インタフェース１００２を使用してバジェット作成時に指定されて、パフォーマンスの利益を得られる場合がある。
【０１１７】
また、フレーバは、エラー回復を実施するため、およびソフトウェアの堅牢性および信頼性を向上させるためにも役立つ。システムにおける低リソース状況から回復するためだけに使用されるフレーバを使用してリソースを確保することによっても、ソフトウェアは、十分な形で回復することが可能である。例えば、クライアントは、キャッシュを縮小することによってリソース消費量を削減すべきであるというリソースマネージャ１０８の通知に応答するのに十分なリソースを利用することができなければならない。
【０１１８】
最後に、他の用途もあるなかで、とりわけ、図４における擬似クライアントリソースＩＤシナリオに関連して説明したとおり、クライアント１０２に代行して実行されるプロセス２０２またはスレッド２０４を特定のバジェット１０４に一時的に結び付けるため、サービス、およびその他のコンポーネントにバジェット設定インタフェース１０１６を提供することができる。結び付ける操作の期間にわたって、サービスのリソース使用量のすべてを、特定のバジェットに請求することができる。リソースが、結び付けの期間中に確保され、割り当てられて解放される場合では、バジェット設定インタフェース１０１６は、要求側クライアントのために直接に動作を実行しているサービスがリソース消費をサービス独自のバジェットにではなく、クライアントのバジェットに対して請求する方法を提供する。
【０１１９】
以上の説明は、本発明の様々な特徴を実施するのに適したコンピューティングシステムの簡単な一般的説明を提供することを目的としてきた。通信ネットワークを介して一緒にリンクされたリモートコンピューティング装置群が相補的なタスクを実行することができる分散コンピューティング環境において使用可能なパーソナルコンピュータの一般的な文脈で説明してきたが、本発明は、他の多くのコンピュータシステム構成で実施することもできることが、当業者には理解されよう。例えば、本発明は、スタンドアロン環境で動作しているパーソナルコンピュータで、またはマルチプロセッサシステム、ミニコンピュータ、メインフレームコンピュータなどで実施してもよい。さらに、本発明は、ラップトップコンピュータ、タブレットコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）、セル電話、ゲームコンソール、パーソナルメディアデバイス、あるいはコンピュータソフトウェアまたは他のデジタルコンテンツがインストールされる任意のデバイスを含む、他のコンピューティング装置上で実施してもよいことが、当業者には認識されよう。
【０１２０】
便宜上、本発明の諸特徴を実施するのに適したコンピューティングシステムの説明のいくらかは、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムへの言及を含んでいた。しかし、それらの言及は、単に例示的であり、本発明の一般的な適用を限定する役割をしないことが、当業者には認識されよう。例えば、本発明は、ＬＩＮＵＸオペレーティングシステムまたはＵＮＩＸ（登録商標）オペレーティングシステムなどの、他のオペレーティングシステムの状況で実施してもよい。
【０１２１】
本発明の一部の態様は、パーソナルコンピュータと連携してオペレーティングシステムによって実行される、またはアクセスされるプログラムに関して説明してきた。しかし、それらの態様は、他の様々な種類のプログラムモジュールまたはデータ構造と組み合わせで実施することもできることが、当業者には認識されよう。一般に、プログラムモジュールおよびデータ構造には、特定のタスクを実行する、または特定の抽象データ型を実装する、ルーチン、サブルーチン、プログラム、サブプログラム、メソッド、インタフェース、プロセス、手続き、関数、コンポーネント、スキーマなどが含まれる。
【図面の簡単な説明】
【０１２２】
【図１】本発明による、例示的なリソース管理システム、ならびにリソースを管理することができる１つの適切な動作環境を示す図である。
【図２】本発明の実施形態を実施するための、図１に示したバジェットのいくつかのコンポーネントの構成をさらに詳細に示すブロック図である。
【図３Ａ】本発明の実施形態に従って形成された例示的なバジェット階層を示す図である。
【図３Ｂ】本発明の実施形態に従って形成された例示的なバジェット階層を示す図である。
【図４】本発明の実施形態を実施するための、図１に示したバジェットのいくつかのコンポーネントの構成をさらに詳細に示すブロック図である。
【図５】本発明の実施形態を実施するための、図１に示したリソース通知サービスのいくつかのコンポーネントの構成をさらに詳細に示すブロック図である。
【図６】本発明の実施形態を実施するための、図１に示したリソースアービタのいくつかのコンポーネントの構成をさらに詳細に示すブロック図である。
【図７】本発明の実施形態を実施するための、図１に示したポリシーモジュールのいくつかのコンポーネントの構成をさらに詳細に示すブロック図である。
【図８】本発明の実施形態による、リソースプロバイダと、リソースを割り当てる、図１に示したリソース管理システムのいくつかのコンポーネントとの間の対話をさらに詳細に示すブロック図である。
【図９】本発明の実施形態による、リソースを管理するために実行される論理を示す流れ図である。
【図１０】本発明の実施形態に従って形成された例示的なリソースマネージャバジェットインタフェース群を示す概略ブロック図である。
【符号の説明】
【０１２３】
１０２  クライアント
１０２Ａ  アプリケーショングループ
１０２Ｂ  アプリケーション
１０２Ｃ  バジェットマネージャ
１０４Ａ、１０４Ｂ、１０４Ｃ  バジェット
１０６  リソースマネージャインタフェース
１０８  リソースマネージャ
１１０  リソースプロバイダインタフェース
１１２  リソースプロバイダ（例えば、メモリ、ＣＰＵ、Ｉ／Ｏドライバ）
１１４  ポリシーモジュール
１１６  ポリシーマネージャ
１１８  ポリシーデータベース
１２０  リソースレートコントローラ
１２２  リソースアービタ
１２４  リソース通知サービス
【図１】
2006236351.tif 000004
【図２】
2006236351.tif 000005
【図３Ａ】
2006236351.tif 000006
【図３Ｂ】
2006236351.tif 000007
【図４】
2006236351.tif 000008
【図５】
2006236351.tif 000009
【図６】
2006236351.tif 000010
【図７】
2006236351.tif 000011
【図８】
2006236351.tif 000012
【図９】
2006236351.tif 000013
【図１０】
2006236351.tif 000014