JP2007512592A - 制限されたバケット使用方法及びシステム - Google Patents
制限されたバケット使用方法及びシステム Download PDFInfo
- Publication number
- JP2007512592A JP2007512592A JP2006539060A JP2006539060A JP2007512592A JP 2007512592 A JP2007512592 A JP 2007512592A JP 2006539060 A JP2006539060 A JP 2006539060A JP 2006539060 A JP2006539060 A JP 2006539060A JP 2007512592 A JP2007512592 A JP 2007512592A
- Authority
- JP
- Japan
- Prior art keywords
- bucket
- task
- margin
- guaranteed
- scheduler
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 claims abstract description 147
- 230000008569 process Effects 0.000 claims description 117
- 230000007246 mechanism Effects 0.000 claims description 75
- 230000003213 activating effect Effects 0.000 claims 1
- 230000003993 interaction Effects 0.000 description 15
- 238000012545 processing Methods 0.000 description 12
- 230000001360 synchronised effect Effects 0.000 description 7
- 230000008859 change Effects 0.000 description 5
- 230000000737 periodic effect Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000009467 reduction Effects 0.000 description 3
- 238000013468 resource allocation Methods 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000007704 transition Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 230000009469 supplementation Effects 0.000 description 2
- 230000002123 temporal effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000006227 byproduct Substances 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- CNQCVBJFEGMYDW-UHFFFAOYSA-N lawrencium atom Chemical compound [Lr] CNQCVBJFEGMYDW-UHFFFAOYSA-N 0.000 description 1
- 108010092763 macromolecular insoluble cold globulin Proteins 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
- G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
リアルタイムオペレーティングシステム(110,170)でマルチプルタスクを制御する方法(60)は、プライオリティを2以上のタスク(114,115;174,175)に割り当てる。第1のタスク(114;174)は、上位タスクにアサインされる。第2のタスク(115;175)は、下位タスクにアサインされる。各タスクは、バケット割当ての情報が提供される。保証バケットマージンは、上位保証バケットに従って上位タスクに割り当てられる。下位保証バケットは、下位タスクに割り当てられる。実行中のあるポイントにおいて、高プライオリティすなわち上位タスク(114;174)は、上位タスクがもはや保証バケットマージンを必要としないことを決定することができ、この場合、条件保証バケットマージンは、下位タスク(115;175)に割り当てられる。
Description
本発明は、一般に、オペレーティングシステムのリソースを管理する方法及び装置に関し、更に詳しくは、リアルタイムで機能するオペレーティングシステムのリソースを管理する方法及び装置に関する。
デジタルテレビジョンセットや、デジタル的に向上したアナログテレビジョンセットや、セットトップボックス(STB)のような大容量家電システム(High volume electronics (HVE) consumer system)は、典型的には、コスト的に有効で強固でありながらオープンかつ柔軟性になることが要求されるプロダクトファミリーの一部である。そのようなシステムは、ハードなリアルタイムドメインの特徴を持つ特性を有する。
オープンであること及び柔軟性があることが、典型的にはソフトウェアに基づくシステムの典型的な特徴であるので、HEVシステムにおける媒体処理に重要な部分は、制御及びサービスを現存するソフトウェアで実現するのに加えてソフトウェアで実現され始めると予測される。構成技術(component technology)は、オープンで柔軟性のあるシステムの基本的な技術であると考えられる。HVEシステムがプロダクトファミリーの典型的な部分であるので、構成技術は、現存するソフトウェアを集約したHEVシステムに対して既に非常に重要である。構成技術を用いたそのようなシステムの開発は、開発に要する時間及び開発コストを大幅に減少し、それはとりわけ有利である。
さらに、家電は、リソースが非常に制約される。その結果、利用できるリソースを、強固さのようなHVEシステムの典型的な品質を維持するとともに、例えば、高品質デジタルオーディオ及びビデオ処理によって課される厳格なタイミング要求に適合しながら、コスト的に非常に有利に用いる必要がある。強固さに関連して、例えば、テレビジョンセットにメッセージ「システムを再起動してください。」をストールすることを誰も予測しない。リソースバケット(又はリザベーション)は、アプリケーションの時間的な分離を提供する証明された概念である。
現在の作業は、固定プライオリティプリミティブスケジューリング(fixed-priority preemptive scheduling: FPPS)を提供する標準汎用品(commercial-off-the-shelf: COTS)リアルタイムオペレーティングシステム(RTOS)のトップでバケットを実現するシステムとともに存在する。
米国特許第5,838,968号は、リアルタイムオペレーティングシステムのタスク間でダイナミックなリソース管理を行うシステム及び方法を開示する。そのシステム及び方法は、システム特有のパフォーマンスモデルに従って、任意のセットのシステムリソースを管理し、システムタスク間でリソース割当てを全体的に最適化する。
米国特許公開2002/0138679号は、優先度承継システム及び方法を開示しており、その方法は、タスクに関連した優先度承継変数をテストし、優先度承継変数のテストが、優先度承継に含まれるリソースをタスクが保持しないことを表すとき、タスクの現在のプライオリティを低下する。
米国特許公開2002/0133530号は、高プライオリティタスクによって低プライオリティタスクからスチールするリソースを含むリソース制御方法を開示する。一部のケースにおいて、バケット割当ては理想で貴でなく、これによって、柔軟性のない動作又はリソースの不適切な使用となり得る。
したがって、本発明は、リアルタイムオペレーティングシステム及び他の同様なアプリケーションにおけるリザベーションに基づくスケジューリングでのリソースの使用を向上する方法及び装置の開発の問題に向けられたものである。
本発明は、マルチタスクプライオリティ化、リソースバケット化、リソース消費予測及び条件付バケット割当てを組み合わせるオペレーションシステムを制御する方法を設けることによってこれら及び他の問題を解決する。この組合せにおいて、バケットマージンは、バケットが十分でない場合に用いるために、高プライオリティタスクに割り当てられ、条件付バケットマージンが、設計された低プライオリティタスクに対して、バケットとともに条件付で割り当てられる。高プライオリティタスクは、バケットの使用をモニタし、高プライオリティタスクが、バケットマージンを不要と決定する場合、低プライオリティタスクは、条件付バケットマージンの使用が許容される。
本発明の一態様によれば、高プライオリティタスク(例えば、上位タスク)が、バケットの使用を、マージンのないバケットに制限し、その後、必要なときにマージンを使用することを明示的に決定する。
本発明の他の態様によれば、高プライオリティタスクは、決定についての情報をアロケーションメカニズムに提供し、低プライオリティタスク(例えば、下位タスク)も直接又は間接に同様な情報が提供される。これによって、アロケーションメカニズム又はスケジューラは、少なくとも高プライオリティタスクがバケットマージンを必要とすることを次に決定するまで、この未使用バケットマージンを低プライオリティタスクに提供する。本発明の他の態様は、添付図面を参照した詳細な説明から当業者に明らかである。
「例」の任意の参照番号は、本発明の少なくとも一例に含まれる例に関連して説明した特定の形態、構造又は特徴を意味する。明細書の種々の形態の「例」の文脈の表示は、必ずしも同一例を言及する全てではない。
プライオリティの割当て、MIT及びLITの表示、バケットの決定並びに他の関連の情報に関する詳細を、図面を含む全体でここに繰り返されるように、参照によってここに組み込んだ米国特許出願番号10/169,346号及び10/294,530号で見つけることができる。これらの特許出願において、プライオリティの表示を、オペレーションシステムのプライオリティの意味に用いており、相対的な重要性の意味に用いていない。用いられるスケジューリングアルゴリズムにおいて、先のプライオリティは、一般的にバケット周期に従って割り当てられる。時には、OSプライオリティ及び相対的な重要性をひとまとめにするのが、特に全てのタスクが同一バケット周期を有する場合に便利である。しかしながら、二つのプライオリティタイプを一まとめにすることを、常に適用できるわけではない。さらに、OSプライオリティを、例えば、最近の期限の最初のスケジューリングを用いるOSにおいてダイナミックにすることができる。その場合、二つのプライオリティのタイプを一まとめにすることができない。したがって、以下の説明では、MITによって用いられない場合に保証バケットマージンを利用するためにMIT,LIT、アロケーションメカニズム及び透け儒―タのインタラクションに関連する態様に焦点を当てる。図1〜5は、ここで利用できる本発明で説明する種々のエレメントを示す。
図1は、リアルタイムオペレーティングシステムで2タスクを制御するタスクマネージャプロセス10の一例を示す。ここで使用しているように、タスクマネージャ及びアプリケーションマネージャ(図5の記載参照)を同時に用いることができる。実際のタスクマネージャはサイクルを有する。これは、開始直後に条件エレメント(例えば、継続?−エレメント11)が存在することを意味する。yesの場合、プロセス10は、エレメント12〜16を実行し、条件エレメント11に戻る(while loop)。noの場合、プロセス10は停止する。プロセス10によれば、第1のタスクは、上位タスク(More Important Task)12にアサインされ、第2のタスクは、下位タスク(Less Important Task)13にアサインされる。2以上の上位−下位タスクペアが任意の時点で存在するが、ここでの説明では単一ペアを言及する。ここで説明することを、複数ペアを通じて適用することができる。プロセスのこの時点において、タスクマネージャ(又はその等価物)は、(これら2タスクに対して)インアクティブ14となる。その後、第1のタスクは、上位タスク15からデアサインされ、第2のタスクは、下位タスク16から割当てデアサインされ、プロセス10を終了する。
同一の2タスクに対する(例えば、図1のエレメント14中でアクティブであるときの)アロケーションメカニズムプロセス20の一例を、図2に示す。アロケーションメカニズムは、上位保証バゲット(More Important Guaranteed Budget :MIGB)21に従って保証バゲットマージン(GBM)をMITに割り当てる。アロケーションメカニズムは、下位保証バゲット(Less Important Guaranteed Budget :LIGB)をLIT22に割り当て、条件によっては条件保証バゲットマージン(Conditionally Guaranteed Budget Margin: CGBM)をLIT21に割り当てる。その後、アロケーションメカニズムは、行われた割当て23に従ってリザベーションコマンドを送信する。その後、所定のイベント24によってトリガがかけられるまでアロケーションメカニズムは何も行わない。イベントが決定エレメント25において継続を表す場合、バゲットが十分でない決定が27で行われ、アロケーションメカニズム20はエレメント21に戻り、それ以外の場合には、MIT及びLITの役割(role)は27で完了し、プロセスが終了する。
図2(並びに後に説明する図7及び12)において、バゲットが動的に調整可能であると仮定する。ここで説明する方法は、バゲットが動的に調整可能でないときにも実施される。この場合、図2(並びに後に説明する図7及び12)は皿簡単になる。その理由は、割当てが1回しか行われないからである。この場合、エレメント24,25,26及び27(並びに図7及び12の対応するもの)は必要とされない。
本実施の形態において、割り当てられたバゲットは、周期的に補充され、周期及び開始時間は、タスクによって決定される。周期的なバゲットのみアロケーションメカニズムによって決定される。そのような周期的なバゲットの使用は、以下の通りである。
タスクYが、周期T及び開始時間t0で周期的なバゲットBを受け取る場合、瞬時t0+n・T(n≧0)ごとに、Yのバケットに単位時間Bが補充される。その周期中にこれら単位時間を消費できる場合のみ、Yは、t0+n・Tとt0+(n+1)・Tの間で単位時間Bを受信するように保証される。所定の周期で時間単位を消費するのに十分な作業を有しない場合、使用されない時間がt0+n・Tで消失される。
周期的なバケットは、常に分数バケット(F:fractional budget)に関連し、この場合、F=B/Tであり、全ての割り当てられた分数バケットの和を1未満とする必要がある。本実施の形態は、周期的なバケットのみに適用されない。原理的には、本実施の形態を、全ての分数バケットに適用することができる。本実施の形態は、プロセッサ、CPU又はオペレーティングシステムのみに適用されるものではなく、本実施の形態を他の時間リソース(temporal resource)(例えば、トランスポーテーションバンド幅(transportation bandwidth))に適用することもできる。
スケジューラプロセス30の例を図3に示す。スケジューラプロセスは、アロケーションマネージャのサイクルと非常に類似するサイクルを有し、すなわち、スケジューラプロセスは、条件エレメント(継続?)を評価するイベント36を有する。yesの場合、アロケーションマネージャからの新たなコマンドが存在し、スケジューラサイクルはエレメント31に戻る。noの場合、スケジューラは停止する。スケジューラがループに戻ると、スケジューリングアルゴリズム30を実行し続け、これは、(スケジュールするタスクがまだ存在しないときでも)「スケジューリングメカニズムの開始」を述べるエレメント37により図3に示される。
スケジューリングプロセスは、MIT及びLIT31に対してアロケーションメカニズムからリザベーションコマンドを受け入れることによって開始する。スケジューラは、MIGB及びGBMをMITに付与し、これによって、スケジューリングメカニズムは、MIGB及びGBMの提供を、MIT32に対して典型的な周期で周期的に開始できるようになる。スケジューラは、LIGBをLITに付与し、これによって、スケジューリングメカニズムは、LIGBの提供を、LIT33に対して典型的な周期で周期的に開始できるようになる。スケジューラは、条件に応じてCGBをLITに付与し、これによって、スケジューリングメカニズムは、CGBの提供を、LIT34に対して典型的な周期で周期的に開始できるようになる。スケジューリングメカニズムは、スケジューリングアルゴリズム35の現在のセッティングに従って実行を継続する。このようにして、スケジューリングメカニズムは、付与されたバケットをタスクに提供する。外部イベントが発生する(36)場合、スケジューラは条件37に到達する。スケジューラプロセス30を継続する場合、スケジューラプロセスはエレメント31に戻り、そうでない場合、スケジューラの動作を停止し、スケジューラを終了する。
「XのYへの付与」は、「Yを受信するようXが保証されるようなスケジューリングパラメータの設定」を意味する。それに対して、「条件に応じた付与」は、例えば、LITが未使用バケットをMITから「受け継ぐ」ことを意味する。条件提示は内在(implicit)する。MITが、十分なGBMを未使用の状態にする場合、LITは十分なCGBMを取得する。
図1〜3の例に基づく上位プロセスインタラクションの例を、図4に示す。MITプロセスは、MIGB及びGBM41を用いて開始する。あるポイントにおいて、MITはもはやGBM42を要求しなくてもよい。したがって、MITは、MIGB43のみを用いて開始する。決定ポイント44において、MITは継続し又は継続しなくなる。MITが継続する場合、あるポイントでMITはGBM45を要求することができる。したがって、MITは、MIGB及びGBM46を用いて開始する。決定ポイント47において、MITプロセスは終了し又はエレメント43で継続する。
図1〜3の例に基づく下位プロセスインタラクションの例を、図19に示す。LITプロセスは、LIGB401を用いて開始する。あるポイントにおいて、CGBMの利用を開始する(402)。したがって、LITは、LIGB及びCGBMを用いて開始する(403)。決定ポイント404において、LITは継続し又は継続しなくなる。LITが継続する場合、あるポイントにおいて、CGBMはもはや利用できなくなる(405)。したがって、LITは、LIGBのみを用いて開始する(406)。決定ポイント407において、LITプロセスは終了し又はエレメント402で継続する。
図1〜4及び19のインタラクションの例50を、図5に示す。アプリケーションマネージャ51は、MITの役割を所定のタスクにアサインし及びデアサインする(図1のエレメント11〜14)。アプリケーションマネージら51は、LITの役割を他の所定のタスクにアサインし及びデアサインする(エレメント12〜15)。アプリケーションマネージャ51はインアクティブとなるとともに、アロケーションメカニズム52はアクティブとなる(エレメント13)。MIT及びLITの役割が完了する(図2のエレメント26)と、アプリケーションマネージャ51は再びアクティブとなるとともに、アロケーションメカニズム52がインアクティブとなる。アロケーションメカニズム52は、MIGB及びGBMをMITに割り当て(図2のエレメント21)、LIGB及びCGBMをLITに割り当てる(図2のエレメント22)。アロケーションメカニズム52は、リザベーションをスケジューラ55に送出し(図2のエレメント23)、スケジューラ55は、図3のエレメント31を起動し、スケジューラ55は、LIT及びMITに対するリザベーションコマンドをアロケーションメカニズムから受け入れ(エレメント31)、MIGB及びGBMをMIT53に付与し、スケジューリングメカニズムは、MIGB及びGBMの提供をMITに対して周期的に開始する(エレメント32)。スケジューラ55は、LIGBをLIT54に付与し、LIGBの提供をLITに対して周期的に開始する(エレメント33)。スケジューラ55は、条件に応じてCGBMをLIT54に付与し、CGBMの提供をLIT54に対して条件に応じて開始する(エレメント34)。スケジューラ55は、スケジューリングアルゴリズムに従って実行する(エレメント35)。この時間中、あるポイントでのMITはGBM42を要求せず、CGBMがLIT400に対して利用できるようになる。他のあるポイントにおいて、MITは再びGBMを要求し(45)、CGBMはもはやLIT405を利用できない。このような42−402から45−405のシーケンスを1回以上繰り返すことができる。実際的な零繰り返しの場合、条件エレメント47をエレメント46と42との間ではなくエレメント41と42との間にするよう図4及び19を変更する必要があり、これによってuntil loopの代わりにwhile loopとなる。
上位タスク(図4)は、2タイプの動作を有することができる。同期動作として知られている第1タイプの動作は、タスクがバケット消費に同期をとって動作するときに生じる(すなわち、バケットがバケット周期内で補充され及び作業を完了するときにタスクが開始する。)。
同期タスクに対するタイムライン200の例を、図20に示す。MIGB及びGBMの補充を伴う第1のバケット周期の開始時(201)に、対応するタスクの実行(例えば、第1のビデオフレームの処理)を開始する(202)。所定の時間後、タスクの実行を完了する(203)。MIGBは完全に使い切られず、GBMは完全に使用されない。所定の時間後、第1の周期が終了する(204)。MIGB及びGBMの補充を伴う第2のバケット周期205の開始時に、対応するタスクの実行(例えば、第1のビデオフレームの処理)を開始する(206)。所定の時間後、MIGBが完全に使い切られる(207)。所定の時間後、タスクの実行を完了する(208)。GBMは完全に使い切られない。所定の時間後、第2のバケット周期は終了する(209)。
タイムラインは、バケット周期の二つの例を示す。201〜204までのの第1のバケット周期において、タスクの実行はMIGB内で完了する。205〜209までの第2のバケット周期において、タスクの実行は、GBMの一部も要求する。
非同期動作として知られている第2のタイプの動作は、タスクがバケットに同期をとって動作しないときに生じる。非同期動作において、タスクは、バケット消費前後に作業することができる。非同期動作はしばしば負荷を取り除くのに用いられる。非同期タスクに対するタイムライン210の例を、図21に示す。MIGB及びGBMの補充を伴う第1のバケット周期の開始時(211)に、第1のタスクの実行(例えば、第1のビデオフレームの処理)を開始する(212)。所定の時間後、MIGBが完全に使い切られる(213)。所定の時間後、第1のタスクの実行は時間通り完了し、それに対して、GBMは完全に使い切られない(214)。その直後に、タスクは第2の実行を開始する(215)。所定の時間後、GBMも使い切られ(216)、第2のタスクの実行が中断される(217)。所定の時間後、周期が終了する(218)。この第1のバケット周期中、1タスクの完了が生じる。換言すれば、タスクが1作業単位を完了する。
MIGB及びGBMの補充を伴う第2のバケット周期の開始時(221)に、以前の周期で中断された第2のタスクの実行が再開される(222)。所定の時間後、MIGBが完全に使い切られる(223)。所定の時間後、GBMも使い切られ(224)、第2のタスクの実行も中断される(225)。所定の時間後、周期が終了する(226)。この第2の周期中、タスクの完了が生じない。第2のタスクの実行が後になる。
非同期タスクに対するタイムライン230の他の例を、図23に示す。MIGB及びGBMの補充を伴う第1のバケット周期の開始時(231)に、第1のタスクの実行を開始する(232)。所定の時間後、第1のタスクの実行が時間内に完了する(233)。その直後に、タスクは第2の実行を開始する(234)。所定の時間後、MIGBが完全に使い切られ(235)、その後、GBMも使い切られる(236)。このポイントにおいて、第2のタスクの実行が中断される(237)。所定の時間後、周期が終了する(238)。この第1の期間中、1タスクの実行が完了する。
MIGB及びGBMの補充を伴う第2のバケットの周期の開始時(239)において、以前の周期で中断したタスクの実行が再開される(240)。所定の時間後、第2のタスクの実行が完了し(241)、第3のタスクの実行を開始する(242)。所定の時間後、MIGBが完全に使い切られる(243)。所定の時間後、第3のタスクの実行が早く完了する(244)。第4のタスクの実行を開始する(245)。所定の時間後、GBMも使い切られ(246)、したがって、第4のタスクの実行が中断される(247)。所定の時間後、周期が終了する(248)。この第2の期間中、2タスクの実行が完了する。
二つのタイムライン210及び230は、状況がバケット周期に応じて非常に異なることを示すが、タスクを非同期で実行するときに必ずしも短いタスクがGBMを解放しない。
本発明の一態様によれば、条件付保証バケットマージン(Conditionally Guaranteed Budget Margin)(例えば、タスクに対して分配される量より上又は下のタスクに割り当てられたリソースの量。それは、各バケット周期に対して利用できるように保証される必要はなく、その利用可能性は、他の一部の要因に依存する。)を設けることが言外に含まれる(implicit)。それに対して、割当ては常に明示的(explicit)である。周期ごとに設けることが言外に含まれる。本発明の一態様によれば、上位タスク(MIT)が保証バケットマージンを使用しない場合、下位タスクは、MITの保証バケットマージンを受け取る。上位保証されたバケット(MIGB)が平均してMITに対して十分であるとしても、MITのバケット消費は、(同期タスクに対する過渡的な高負荷中(207〜208)のような、同期タスクに対する開始を行うために次のタスク実行の準備ができている(213及び243)ときである)所定のバケット周期中に上位保証バケットを超えることがある。これらの周期において、MITは、保証バケットマージンの一部を使用し、LITは、条件保証バケットマージン未満のものを受け取る。
非同期処理のみに生じる第2の関連の問題がある。非同期タスクは、バケットの使用を制約するよう使用することができない。その理由は、それが非同期だからである。同期動作を伴う負荷の見積り及び負荷調整MITは時々、作業前に行われる作業量を見積り、その後、バケットが完全に使い切られる前に作業を完了するように(すなわち、そのような品質レベルで)データを処理することができる。非同期動作を伴うMITは、典型的には、行われた処理量を測定し、その後、期限の消失を回避するよう処理データの品質レベルを調整する。いずれの場合も、MITは、常にバケットがその必要に良好に適合する方法の情報を得る。この性能を、バケットを調整するようアロケーションマネージャに要求するのに用いることができる。
一般に、上記エレメント及び機能に対して、本発明は、特に、関連の重要性に割り当てられたタスクに関連した条件保証バケットマージン(CGBM)を用いる。
本発明の一態様によれば、MIT及びLITは、明示的にバケットが知らされる。したがって、MITは、バケット使用をマージンなしのバケットに制限することができる。
本発明の他の態様によれば、上位タスク(MIT)は、自発的にバケット使用をマージンなしのバケットに制限し、必要な場合にはマージンを使用するか否か明示的に決定する。上位タスクは、決定についての環境(例えば、アロケーションメカニズム、スケジューラ又はバケットモニタ)の情報を提供する。下位タスク(LIT)は、(MITから直接又は他のエージェントを通じて)CGBMを受信し又は受信しない情報を得る。この決定は、必ずしもバケットごとに基づくよう意図する必要はないが、通常稀である。さらに、決定は、常にバケット境界で行われるわけではない。この決定は、典型的には新たなタスク実行の開始時に行われる。バケット使用の再開は十分でない。非同期タスクは、MIGBが使い切られたときに実行する停止を行うために使用することができず、GBMは利用できる。非同期タスクは、この遷移を検出するのに使用することができない。したがって、本発明の第2の態様では、MITがバケット制限を開始する間、MITをMIGBに制限することによってスケジューラが実際に制限を行う。
本発明の一態様によるリアルタイムオペレーティングシステムでマルチプルタスクを制御する方法60の例を、図6に示す。方法60において、第1のタスクが上位タスクに割り当てられる(エレメント61)。このタスクのプライオリティを決定することによって、システムは、プロセッサアクセスや、メモリや、ユーザインタフェースのようなリソース又は他の制限された利用可能なアイテムを割り当てることができる。
第2のタスクが下位タスクに割り当てられる(エレメント62)。第2のタスクは、第1のタスクより低いプライオリティ(すなわち、相対的に低い重要性)と考えられるタスクにすぎないが、第2のタスクを、他の一部のタスクより高いプライオリティ(すなわち、相対的に高い重要性)とすることもできる。
保証バケットマージンは、上位保証バケットに従って上位タスクに割り当てられ、MITにその割当てが知らされる(エレメント63)。上位保証バケットは、第1のタスクによる使用のためにとっておくリソース又は他の制限された利用可能アイテムの量である。保証バケットマージンは、第1のタスクによって必要とされる場合の上位保証バケットより上及び下である、第1のタスクによる使用のために取っておくリソース又は他の制限された利用可能アイテムの量である。
下位保証バケットは、割当てが知らされる下位タスクLITにも割り当てられる(エレメント64)。下位保証バケットは、低プライオリティの第2のタスクによる使用のために取っておくリソース又は他の制限された利用可能アイテムの量である。さらに、条件付保証バケットマージンは、割当てが知らされる第2のタスクに対して条件付で割り当てられる(エレメント65)。
実行中のあるポイントにおいて、高プライオリティすなわち上位タスクは、上位タスクが次のバケット周期においてもはや保証バケットマージンを要求しないことを決定することができる(エレメント66)。これは、高プライオリティタスクがバケットアイテムの使用をモニタするために生じることができ、所定のバケットサイクル中にその必要を予測することができる。その後、上位タスクが保証バケットマージンを要求しないというメッセージを送信する(エレメント67)。このメッセージは、MITともに又はスケジューラや条件付バケットモニタのような他のプロセスから生じることができる。しかしながら、このメッセージを送信できるもののみが、GBMがもはや必要とされないことを検出するものとなる。このメッセージを送信する最有力候補はMITである。非同期MITの場合、それはスケジューラとなりうる。本例において、MITは、事実を検出するとともにメッセージを送信するものである。他のパーティがこれを行う場合、MITも情報提供する必要がある。
高プライオリティすなわち上位タスク又は他のタスクが、MITが保証バケットマージンを必要としないことを表す場合、条件付で割り当てられたバケットマージンを下位タスクに提供することができる(エレメント68)。条件付保証バケットマージンは、第2のタスクによって必要とされる場合に下位保証バケットより上及び下である第2のタスクによる使用のためにとっておくリソース又は他の制限された利用可能アイテムの量であるが、その量は、高プライオリティすなわち上位タスクによるように他に必要とされないときにのみ設けられる。
一度メッセージが送信されると、各バケットサイクルでCGBMを第2のタスクに対して保証するために、CGBMが明示的に取り除かれるまで、上位タスクが実際に全体的又は部分的にGBMを使用しないことは重要である。
実行中の他のポイントにおいて、高プライオリティ又は上位タスクは、上位タスクが次のバケットサイクルにおいて保証バケットマージンを再び必要とすることを決定することができる(エレメント69)。その後、上位タスクが保証バケットマージンを必要としないメッセージが送信される(エレメント691)。高プライオリティ又は上位タスクが、保証バケットマージンを要求しないことを表す場合、条件付で割り当てられた保証バケットマージンは、もはや下位タスクに提供されず、したがって、CGBMはLITから取り除かれ、GBMがMITに提供され、MIT及びLITにこれらの割当ての情報が提供される(エレメント692)。GBMを要求し及び要求しないこのプロセスは、ループによって表されるように複数回繰り返される。本例において、高プライオリティタスク(例えば、MIT)に関連する制御アルゴリズムは、制御アルゴリズムが、
(a)適切な場合にはMITのバケット使用を自発的に制限し(図6のエレメント66の一部)、
(b)保証バケットマージン(GBM)が今から要求されること又は保証バケットマージンがもはや今から要求されないことの信号を送信する(図6のエレメント67参照)
ように拡張される。ここで用いられるように、高プライオリティタスクのバケットは、高プライオリティタスクによる使用のために取っておくリソース又は他の制限された利用可能アイテムの量に関連する。また、ここで用いられるように、保証バケットマージンは、高プライオリティタスクに対して既に割り当てられたのより上のリソース(又は他の制限された利用可能アイテム)の割り当てられた量を言及し、それは、高プライオリティタスクのために取っておかれる。
(a)適切な場合にはMITのバケット使用を自発的に制限し(図6のエレメント66の一部)、
(b)保証バケットマージン(GBM)が今から要求されること又は保証バケットマージンがもはや今から要求されないことの信号を送信する(図6のエレメント67参照)
ように拡張される。ここで用いられるように、高プライオリティタスクのバケットは、高プライオリティタスクによる使用のために取っておくリソース又は他の制限された利用可能アイテムの量に関連する。また、ここで用いられるように、保証バケットマージンは、高プライオリティタスクに対して既に割り当てられたのより上のリソース(又は他の制限された利用可能アイテム)の割り当てられた量を言及し、それは、高プライオリティタスクのために取っておかれる。
同期動作を伴うMITは、各バケット周期中にそれ自体を制約することができ、その結果、保証バケットマージンは自動的に低プライオリティタスク(例えば、下位タスク)に提供される(図20のエレメント201〜204参照)。非同期動作を伴うMITは、それを正確に行うことができない。その理由は、(図21〜24に示すように)その動作がバケット周期に対して非同期だからである。スケジューラの明示的な助けがない場合、非同期MITは、バケット周期より更に前の入力の欠如のために非同期MITがブロックを行うまで、バケットマージン(例えば、保証バケットマージン)に従ってバケット(例えば、上位保証バケット)の消費を続ける。更に一般的な場合である非同期MIT(図21〜24)の場合、本発明の第2の態様は、所望のバケット転送が2方向で行われることが要求される。
変更された制御アルゴリズムによって適切に実行時間中にタスクが非同期で動作する場合、以下の変更されたバケット割当てプロトコルは、所望のバケット転送を2方向で満足する。
A.バケットがアロケーションメカニズムによって割り当てられたとき、
1.アロケーションメカニズムは、上位保証バケット及び保証バケットマージンについての情報をMITに明示的に提供する(図6のエレメント63参照)。
2.アロケーションメカニズムは、下位保証バケット及び条件付保証バケットマージンについての情報を下位タスクに明示的に提供する(図6のエレメント64参照)。
3.スケジューラは、上位保証バケット及び保証バケットマージンを、最初のあり得るときにMITに提供する(図6のエレメント63参照)。
4.スケジューラは、下位保証バケットを、最初のあり得るときに提供する(図6のエレメント68参照)。
1.アロケーションメカニズムは、上位保証バケット及び保証バケットマージンについての情報をMITに明示的に提供する(図6のエレメント63参照)。
2.アロケーションメカニズムは、下位保証バケット及び条件付保証バケットマージンについての情報を下位タスクに明示的に提供する(図6のエレメント64参照)。
3.スケジューラは、上位保証バケット及び保証バケットマージンを、最初のあり得るときにMITに提供する(図6のエレメント63参照)。
4.スケジューラは、下位保証バケットを、最初のあり得るときに提供する(図6のエレメント68参照)。
B.MITがバケットマージンを要求しないとき、
1.実行中のあるポイントにおいて、MITは、上位保証バケットのみを用いてジョブを行うことができることを観察する(図6のエレメント66参照)。
2.MITは、保証バケットマージンを要求しないという情報をスケジューラに提供する(図6のエレメント67参照)。
3.スケジューラは、最初のあり得るときに保証バケットマージンをMITに提供することを停止する(図6のエレメント67の一部)。
4.スケジューラは、アプリケーションに応じて瞬時的に又は瞬時的でなくすることができる最初のあり得るときに、条件付バケットマージンのLITへの提供を開始する(エレメント68参照)。
5.スケジューラは、この条件付バケットの提供の情報をLITに提供する(エレメント68)。
1.実行中のあるポイントにおいて、MITは、上位保証バケットのみを用いてジョブを行うことができることを観察する(図6のエレメント66参照)。
2.MITは、保証バケットマージンを要求しないという情報をスケジューラに提供する(図6のエレメント67参照)。
3.スケジューラは、最初のあり得るときに保証バケットマージンをMITに提供することを停止する(図6のエレメント67の一部)。
4.スケジューラは、アプリケーションに応じて瞬時的に又は瞬時的でなくすることができる最初のあり得るときに、条件付バケットマージンのLITへの提供を開始する(エレメント68参照)。
5.スケジューラは、この条件付バケットの提供の情報をLITに提供する(エレメント68)。
C.MITがバケットマージンを再び要求するとき、
1.実行中のあるポイントにおいて、MITは、保証バケットマージンを要求することを観察する(エレメント69)。
2.MITは、保証バケットマージンを要求する情報をスケジューラに提供する(エレメント691)。
3.スケジューラは、条件付保証バケットマージンが取り除かれるという情報をLITに提供する(エレメント692)。
4.スケジューラは、あり得る最初のときにおける条件付保証バケットマージンのLITへの供給を停止する(エレメント692の一部)。
5.スケジューラは、あり得る最初のときにおける保証バケットマージンのMITへの提供を開始する(エレメント692の一部)。
1.実行中のあるポイントにおいて、MITは、保証バケットマージンを要求することを観察する(エレメント69)。
2.MITは、保証バケットマージンを要求する情報をスケジューラに提供する(エレメント691)。
3.スケジューラは、条件付保証バケットマージンが取り除かれるという情報をLITに提供する(エレメント692)。
4.スケジューラは、あり得る最初のときにおける条件付保証バケットマージンのLITへの供給を停止する(エレメント692の一部)。
5.スケジューラは、あり得る最初のときにおける保証バケットマージンのMITへの提供を開始する(エレメント692の一部)。
LITには、減少が生じる前にバケット減少の情報が提供される。LITには、増加が生じた後にバケット増加の情報が提供される。LITは、いずれにしろ変化に影響を及ぼさない。
図11は、図7〜10に記載した種々のプロセスの役割及びインタラクションの例を示す。第1のタスク114は、第1のプライオリティレベルを有し、第1のタスク114は、高プライオリティタスク又は上位タスクと称される。この高プライオリティタスク114は、オペレーティングシステム110の外部又は内部のタスクを有することができる。
第2のタスク115は、第1のプライオリティレベルより低い第2のプライオリティレベルを有する。この低プライオリティタスク(すなわち下位タスク)115は、オペレーティングシステム110の外部又は内部のタスクを有することができる。さらに、第2のタスク115は、第1のタスク114より低いプライオリティにすぎないが、2番目に上位のタスクとして実行することができる。これら2段落において、全てのプライオリティは相対的な重要性である。
アロケーションアルゴリズム112は、オペレーティングシステム110によって実行される種々のタスク114,115間でリソースのバケットを割り当てる。本発明の一態様によれば、アロケーションメカニズム112は、上位保証バケット及び保証バケットマージンについての情報を明示的に第1のタスク114に提供する。上位保証バケットは、第1のタスク114による使用のために取っておくリソース又は他の制限された利用可能アイテムの量である。保証バケットマージンは、第1のタスク114によって必要とされる場合における上位保証バケットより上又は下である第1のタスク114による使用のために取っておくリソース又は他の制限された利用可能アイテムの量である。アロケーションアルゴリズム112は、下位保証バケット及び条件付保証バケットマージンについての情報を明示的に第2のタスク115に提供する。下位保証バケットは、第2のすなわち低プライオリティタスク115の使用のために取っておくリソース又は他の制限された利用可能アイテムの量である。
スケジューラ113は、第1のタスク114及び第2のタスク115を含む、オペレーティングシステム110によって実行される種々のタスク114,115に対する割り当てられた量のリソースの提供を制御する。スケジューラ113は、最初のあり得るときに上位保証バケット及び保証バケットマージンを第1のタスク114に提供する。スケジューラは、最初のあり得るときに下位保証バケットを第2のタスク115にも提供する。
第1のタスクが、実行中のあるポイントにおいて、第1のタスク114が上位保証バケットのみを用いて適切に実行できることを決定する場合、第1のタスク114は、第1のタスク114が保証バケットマージンを必要としない情報をスケジューラ113に提供する。この場合、スケジューラ113は、最初のあり得るときに保証バケットマージンの第1のタスク114への供給を停止し、最初のあり得るときに条件付保証バケットマージンの第2のタスク115への提供を開始する。この後、スケジューラ112は、条件付保証バケットマージンを付与する情報を第2のタスク115に提供する。
条件付保証バケットマージンは、第2のタスク115によって必要とされる場合の下位保証バケットより上及び下の第2のタスク115による使用のために取っておくリソース又は他の制限された利用可能アイテムの量であるが、この量は、高プライオリティ又は上位タスク114によるような他に必要とされたいときにのみ提供される。
次に、第1のタスク114は、実行中のあるポイントにおいて第1のタスク114が保証バケットマージンを要求することを決定することができ、この場合、第1のタスク114は、第1のタスク114が保証バケットマージンを必要とする情報を明示的にスケジューラ113に提供する。その後、スケジューラ113は、条件付保証バケットマージンが取り除かれる情報を第2のタスク115に提供し、スケジューラ113は、最初のあり得るときに条件付保証バケットマージンの第2のタスク113への提供を停止し、スケジューラ113は、最初のあり得るときに保証バケットマージンの第1のタスク114への提供を開始する。
アプリケーションマネージャ111は、MITの役割を所定のタスクにアサインし及びデアサインする(図1のエレメント11及び14)。アプリケーションマネージャは、LITの役割を他の所定のタスクにアサインし及びデアサインする(エレメント12及び15)。その後、アプリケーションマネージャ111がインアクティブとなるとともに、アロケーションメカニズム112がアクティブになる(図1のエレメント13)。MIT及びLITの役割が終了する(図2のエレメント26)と、アプリケーションマネージャ111が再びアクティブとなるとともに、アロケーションメカニズム112がインアクティブとなる。アロケーションメカニズム112は、MIGB及びGBMをMITに割り当て(図7のエレメント71)、これらの割当ての情報を明示的にMITに提供する。アロケーションメカニズム112は、LIGB及びCGBMをLITに割り当て(図7のエレメント73)、これらの割当ての情報を明示的にLITに提供する。アロケーションメカニズム112は、リザベーションをスケジューラ113に送信し(図7のエレメント75)、スケジューラ113は、実行を完了するよう図8のスケジューラプロセス80を起動する。スケジューラ113は、LIT及びMITに対するアロケーションメカニズムからのリザベーションコマンドを受け入れ(エレメント81)、MIGB及びGBMをMITに付与し、LIGBをLITに付与する(エレメント82)。その後、スケジューラは、スケジューリングアルゴリズムに従って実行を行う(エレメント83)。スケジューラ113は、MITがもはやGBMを必要としないメッセージをMITから受信する(エレメント85)。その後、スケジューラは、MIGBのみをMITに付与し(エレメント86)、バケット増大の情報をLITに提供し(エレメント87)、LIGB及びCGBMをLITに付与する(エレメント88)。その後、スケジューラ113は、MITがGBMを必要とするメッセージをMITから受け取ることができ、この場合、スケジューラ113は、バケット減少の情報をLITに提供する(エレメント812)。
本発明の他の態様によるアロケーションメカニズムプロセス70の例を、図7に示す。アロケーションメカニズムプロセス70は、MIGB及びGBMをMIT71に割り当てる。アロケーションメカニズムプロセス70は、LIGBをLIT72に割り当てるとともに、CGBMを条件付でLIT72に割り当てる。アロケーションメカニズムプロセス70は、その割当ての情報を明示的にMITに提供する(73)。アロケーションメカニズムプロセス70は、その割当ての情報を明示的にLITにも提供する。アロケーションメカニズムプロセス70は、MIT及びLITへの割当てに従ってコマンドリザベーションを送信する(75)。その後、アロケーションメカニズムプロセス70は、あるイベントによってトリガがかけられるまで待機する(76)。バケットが不十分である場合、アロケーションメカニズムプロセスは、エレメント71に戻る。バケットが十分である場合、MIT及びLITの役割が終了し(78)、アロケーションメカニズムプロセス70を終了する。
図8は、本発明の他の態様によるスケジューラプロセス80の他の例を示す。スケジューラプロセス80は、(図7のエレメント75に示すように)リザベーションコマンドを受け取り、MIGB及びGBMをMITに付与するとともにLIGBをLITに付与する(82)。その後、スケジューリングプロセス80は、スケジューリングアルゴリズム83に従って実行を行う。決定ポイント84において、プロセス80は継続し又は終了する。スケジューリングプロセス80が継続する場合、あるポイントにおいて、スケジューリングプロセスは、MITがもはやGBM85を必要としないメッセージをMITから受け取る(85)。その後、スケジューラは、MIGBのみをMITに付与する(又は、GBMをMITから除去して、MITはMICGのみを有する。)(86)。その後、スケジューラプロセス80は、lIGB及びCGBMをLITに付与する(又は、CGBMをLITのリソースに加える。)(87)。その後、スケジューラプロセス80は、バケット増大の情報をLITに提供する(88)。その後、スケジューリングプロセス80は、スケジューリングアルゴリズムに従って実行を行う(89)。決定ポイント810において、スケジューリングプロセス80は継続し又は終了する。スケジューリングプロセス80が継続する場合、所定のポイントにおいて、スケジューリングプロセス80は、MITがGBMを必要とすることを表すメッセージをMITから受け取る(811)。LITは、バケット減少の情報をスケジューラ812から提供され、スケジューリングプロセス80はエレメント81に戻る。
他の種々のタスクによるMITプロセスのインタラクションの例90を、図9に示す。MITプロセス90は、アロケーションメカニズムプロセス70によってMIGB及びGBMの情報が提供される(91)。MITプロセス90は、MIGB及びGBMを用いながらスケジューラ92によって開始する。MITプロセス90は、GBMを必要としないことを決定し(93)、GBMが必要とされない情報をスケジューラプロセス80に提供する(94)。その後、MITプロセス90は、MIGBのみを用いて開始する(95)。決定ポイント96において、MITプロセス90は、継続し又は終了する。MITプロセス90が継続する場合、MITプロセス90は、GBMを必要としていることを決定する(97)ことができる。MITプロセス90は、GBMを必要とする情報をスケジューラプロセス80に提供し(98)、MITプロセス90は、MIGB及びGBMを用いてスケジューラプロセス99によって開始する(99)。決定ポイント910において、MITプロセス90は終了し又はエレメント93に戻る。
他の種々のタスクによるLITプロセスのインタラクションの例100を、図10に示す。LITプロセス100は、LIGB及びCGBMの情報がアロケーションメカニズムプロセス70によって提供される(101)。LITプロセス100は、LIGBを用いてスケジューラによって開始する(102)。あるポイントにおいて、LITプロセス100は、CGBMが利用できるという情報がスケジューラプロセス80によって提供される(103)。その後、LITプロセス100は、LIGB及びCGBMを用いて開始する(104)。決定ポイント105において、LITプロセス100は、継続し又は終了する。LITプロセス100が継続する場合、LITプロセス100は、CGBMがもはや利用できないという情報が提供される(106)。その後、LITプロセス100は、LIGBのみを用いてスケジューラ107によって開始する(107)。決定ポイント108において、LITプロセス100は、終了し又はエレメント103に戻る。
本発明の更に別の態様による、条件付バケットモニタプロセスを用いるアロケーションメカニズムの他の例を、図12に示す。本例において、アロケーションメカニズムは、リザベーションコマンドの受取側である。アロケーションメカニズムプロセス120は、MIGB及びGBMをMITに割り当てる(121)。アロケーションメカニズムプロセス120は、LIGBをLITに割り当てるとともにCGBMを条件付でLITに割り当てる(122)。アロケーションメカニズムは、割当ての情報を明示的にMITに提供する。アロケーションメカニズムは、割当ての情報を明示的にLITにも提供する(124)。アロケーションメカニズムは、MIT及びLITの割当てに従ってコマンドリザベーションを送信する(125)。その後、アロケーションメカニズムは、あるイベントによってトリガがかけられるまで待機する。決定エレメント127での決定でバケットが不十分である場合、アロケーションメカニズムプロセスはエレメント121に戻る。バケットが十分である場合、アロケーションメカニズムプロセス120は、エレメント128に進む。MIT及びLITが128を完了し、プロセスが終了する。
本発明の他の態様による条件付バケットモニタ(CBM)プロセス130の例を、図13に示す。CBMは、MIT及びLITに対するリザベーションコマンドを受け取り、リザベーション(MITに対するMIGB+GBM及びLITに対するLIGB)をスケジューラに送信する(132)。その後、CBMはイベントを待機する。決定ポイント133において、CBMプロセス130は継続し又は終了する。CBMプロセス130が継続する場合、あるポイントにおいて、CBMプロセスは、MITがもはやGBMを必要としないことを表すメッセージをMITから受け取ることができる(134)。その後、CBMは、リザベーション(MITに対するMIGB及びLITに対するLIGB+CGBM)をスケジューラに送信する(135)。その後、CBMは承認を待機する(136)。その後、CBMは、バケット増大の情報をLITに提供する(137)。その後、CBMはイベントを待機する(138)。決定ポイント139において、プロセス130は継続し又は終了する。プロセス130が継続する場合、あるポイントにおいて、CBMは、MITがGBMを必要とするメッセージをMITから受け取ることができる(1310)。CBMは、バケット減少の情報をLITに提供する(1311)。好適には、このメッセージは、リソースが取り除かれる前にLITに到達する必要があり、その成功は、引き出された距離、クロックタイミング、処理速度等の任意の要因に依存する。
本発明の更に別の態様によるスケジューラプロセス140の他の例を、図14に示す。スケジューラは、(例えば、図13のCBMから)一つ以上のタスクに対するリザベーションコマンドを受け取る(140)。エレメント142において、スケジューラは、エレメント141からリザベーション要求又は変更を付与する。その後、スケジューラは、リザベーションコマンドの送信側(例えば、図13のCBM)に対してリザベーションコマンドを承認する。その後、スケジューリングプロセスは、スケジューリングアルゴリズムに従って実行される(144)。プロセス140は、エレメント141まで継続し又は決定エレメント145で終了する。プロセス140が継続する場合、エレメント141に進む。
図12〜14からの種々のタスクによるMITのインタラクションの例150を、図15に示す。MITは、(例えば、アロケーションメカニズムによって)MIGB及びGBMの情報が提供される(151)。MITは、MIGB及びGBMを用いてスケジューラによって開始する(152)。MITは、GBMを必要としないことを決定し(153)、この影響に対するメッセージを(例えば、次のスケジューラに情報を提供するCBMに)送信する(154)。その後、MITは、MIGBのみを用いて開始する(155)。決定ポイント156において、プロセッサ150は継続し又は終了する。プロセス150が継続する場合、MITは、GBMを必要とすることを決定する(157)。MITは、GBMを必要とするメッセージを(例えば、次にスケジューラに情報を提供するCBMに)メッセージを送信し、MITは、MIGB及びGBMを用いてスケジューラ159によって開始する。決定ポイント1510において、プロセス150は、終了し又はエレメント153に戻る。
図12〜15の他の種々のタスクによるLITのインタラクションの例160を、図16に示す。LITは、アロケーションメカニズムによってLIGB及びCGBMの情報が提供される(161)。LITは、LIGBを用いてスケジューラによって開始する(162)。所定のポイントにおいて、LITは、CGBMが利用できるという情報が(例えば、CBMによって)提供される(163)。その後、LITは、LIGB及びCGBMを用いて開始する(164)。決定ポイント165において、プロセス160は、継続し又は終了する。プロセス160が継続する場合、LITは、CGBMがもはや利用できないという情報が(例えば、CBMによって)提供される(166)。その後、LITは、lIGBのみを用いてスケジューラによって開始する(167)。決定ポイント168において、プロセッサ160は、終了し又はエレメント163に戻る。
本発明の別の態様による図1〜16の種々のプロセスのインタラクションの例170を、図17に示す。アプリケーションマネージャ171は、MITの役割を所定のタスクにアサインし及びデアサインする(図1のエレメント11及び14)。アプリケーションマネージャは、LITの役割を他の所定のタスクにアサインし及びデアサインする(エレメント12及び15)。その後、アプリケーションマネージャ171がインアクティブになるとともに、アロケーションメカニズム172がアクティブになる(図1のエレメント13)。MIT及びLITの役割が完了する(図5のエレメント57)と、アプリケーションマネージャ171が再びアクティブになるとともに、アロケーションメカニズム172がインアクティブになる。アロケーションメカニズム172はMIGB及びGBMをMITに割り当て(エレメント121)、これらの割当ての情報を明示的にMITに提供する(エレメント123)。アロケーションメカニズム172は、LIGB及びCGBMをLITに割り当て(エレメント123)、これら割当ての情報をLITに提供する(エレメント124)。アロケーションメカニズム172は、リザベーションをCBM176に送信し(エレメント125)、図13のプロセス130を実行する。CBMは、リザベーションを図14のスケジューラプロセス140に送信し、実行を完了する。CBMは、MITがもはやGBMを必要としないというメッセージをMITから受け取る(エレメント134)とともに、MITがGBMを必要とするメッセージをMITから受け取る(エレメント1310)。その後、CBMは、CGBMが利用できるというメッセージをLITに送信する(エレメント137)とともに、CGBMがもはや利用できないというメッセージをLITに送信する(エレメント1311)。さらに、CBMは、リザベーション変化をスケジューラに送信し(エレメント142)、承認をスケジューラから受け取る(エレメント143)。スケジューラ173は、LIT及びMITに対するCBMからのリザベーションコマンドを受け入れ(エレメント121)、MIGB及びGBMをMITに付与するとともに、LIGBをLITに付与する(エレメント142)。その後、スケジューラは、スケジューリングアルゴリズムに従って実行する(エレメント143)。リザベーションの変化は、スケジューラ173によってLIT及びMITに送信される(エレメント142)。これらの変化の承認は、スケジューラ173によって送信側に送信される(エレメント143)。
本発明の更に別の態様による複数のプロセスを制御する方法の例180のタイムフローを、図18に示す。図18に示すプロセスの正確な順番は重要でないが、時間の順番は一部のプロセスに関して重要であり、それを、これらのプロセスを説明する際に示す。それを示さない場合、相対的な順序を変更することができる。開始181において、以下のプロセスが2処理システムに対して生じうる。同様なプロセスが3処理システムに対して生じ、この場合、インタラクションは、任意の2プロセス間で階層的に同様である。
先ず、相対的なプライオリティを確立する必要がある。アロケーションメカニズム又は他の一部のプロセスは、プライオリティのレベルを2タスクにアサインする。これらのタスクの一方は、上位タスク182に割り当てられ、この場合、アロケーションメカニズムは、プライオリティ指定の情報をこのプロセスに提供することができる。これらタスクの他方は、下位タスク184にアサインされ、この場合、アロケーションメカニズムは、プライオリティ指定の情報をこのプロセスに提供することができる。タスクにプライオリティをアサインする順序は、必ずしも重要でない。例えば、低プライオリティのタスクを最初に割り当てることができ、したがって、エレメント184がエレメント182の前に生じることができる。
一度プライオリティがアサインされると、タスクの各々にバケットの情報が明示的に提供される。例えば、アロケーションメカニズムは、上位保証バケット及び保証バケットマージンについての情報を明示的にMITに提供する(183)。アロケーションメカニズムは、下位保証バケットについての情報を明示的にLITに提供し(185)、条件付で保証バケットマージンをLITに提供する。プロセス183及び185の順番は、プロセスの各々が相対的なプライオリティのアサイン後に生じる必要があることに比べれば重要でない。さらに、MITへのバケットの情報提供を、MITのアサインの直後又は全てのプライオリティがアサインされた後に行うことができる。LITへのバケットの情報適用を、MITへのバケットの情報提供前後に行うことができる。要求されることは、バケットの情報提供が相対的なプライオリティのアサイン後にしか行うことができないことである。
バケットについての情報をMITに提供した後、スケジューラは、あり得る最初のときに上位保証バケット及び保証バケットマージンをMITに提供する(186)。このようなMITへのバケットの提供を、下位保証バケットについての情報のLITへの提供前後に行うことができ、そのように情報提供されたMITのバケットを用いてMITを開始できるような相対的なプライオリティの次のアサインの直後にできるだけ迅速に行うことができる。
MITへのバケットの提供に続いて、スケジューラは、最初のあり得るときに下位保証パケットをLITに提供する(187)。これは、通常、2タスクの相対的なプライオリティに起因してバケットをMITに提供した後に生じるが、そのように情報提供されたLITのバケットを用いてLITを開始できるような相対的なプライオリティの次のアサインの直後にできるだけ迅速に行うことができる。
実行中のあるポイントにおいて、MITは、上位保証バケットのみを用いてジョブを行えることを観察することができ、この場合、MITは、この観察の情報をスケジューラに提供する(188)。これは、バケットをMITに提供した後にしか生じることができないが、その後のバケット周期中の任意のポイントで生じることができる。簡単のために、観察及びスケジューラの情報提供を、単一エレメントで示すが、これらを時間的に分離することができる。
MITの観察についての情報が一度提供されると、スケジューラは、あり得る最初のときにおける保証バケットマージンのMITへの提供を停止する(189)。これは、できるだけ早く保証バケットマージンを使用できるようにするためのスケジューラによる次の情報の受信の直後に最も生じうる。一度この条件(すなわち、MITが保証バケットマージンを必要としないこと)がMITによって存在するよう決定されると、システムは、保証バケットマージンをできるだけ迅速に利用する必要がある。その理由は、この条件が今後(少なくともバケット周期の残りの期間中に)存在しないことがあるからである。
放送バケットマージンのMITへの供給を停止した(189)後、スケジューラは、最初のあり得るときに条件付保証バケットマージンのLITへの供給を開始する(190)。その後、スケジューラは、この追加のバケット提供の情報をLITに提供する(191)。好適には、LITが遅延なく他のバケットを用いて開始するために、この情報提供191を、条件付保証バケットマージン190の提供後に行う必要があるが、ある状況では、これら二つのエレメントを違う順番で行うことができる。
同一バケット周期の実行中のあるポイントにおいて、MITは、保証バケットマージンを要求することを観察する(192)。これを、エレメント188の後に行うことができ、エレメントのいずれか(すなわち、189,190及び191)の後に行われるかに影響を及ぼすことができる。この新たな決定の後に、MITは、保証バケットマージンを要求する情報をスケジューラに提供する(192)。既に説明したように、これら二つのサブステップを時間的に分離して行うことができるが、簡単のためにこれらを単一エレメントとして示す。この情報を受け取った後、スケジューラは、条件付保証バケットマージンが取り除かれる情報をLITに提供する(193)。典型的には、これを、リソースの不適切な使用を防止するとともにLITがそれに応じた調整を行って遷移を円滑にするためにこのバケットマージンのLITへの供給するのを停止する前に行う必要がある。
その後、スケジューラは、最初のあり得るときに条件付保証バケットマージンのLITへの提供を停止する(194)。その後、スケジューラは、最初のあり得るときに保証バケットマージンのMITへの供給を開始する(195)。スケジューラは、先ず、リソースの不適切な使用を防止するとともに円滑な遷移を可能にするために追加のバケットをMITに供給する前に追加のバケットのLITへの供給を停止する必要がある。
ある時点において、プロセスは終了する(196)が、エレメント188〜195の他の複数の繰り返しを、アプリケーション仕様に応じて行うことができる。さらに、MITは、保証バケットマージンを必要としないことを決定することができず(188)、又は、MITは、保証バケットマージンを必要としないことを決定した(188)後に保証バケットマージン192を必要とすることを決定することができない(192)。
1.条件付保証バケットマージンの明瞭な付与及び取り除きの間に、LITは実際にCGBMを計上することができる。本発明がない場合、LITは、実際に条件付保証バケットマージンを計上することができない。
2.構造的な負荷の増大を検出する個別のエンティティを必要としない。その理由は、MITアプリケーション内のローカル制御アルゴリズムが通常の動作の副産物としてこの検出を行うことができるからである。
3.MITのローカルアルゴリズムは、個別のエントリが行う場合に比べて構造的な負荷変化を検出することができる。その理由は、それがリソース使用法(resource usage means)に対して意味のある解釈を有するからである。
4.LITが、条件付保証バケットマージンの利用可能性についての情報を明示的に提供されるので、LITは、変化に対して更に高速かつ更に円滑に応答することができる。この利点は、既に説明している変更したバケット割当てプロトコル(ステップ(b))の直接的な結果である。
5.MITは、LITの一致を知る必要がない。MITは、LITが存在することを知る必要がない。
2.構造的な負荷の増大を検出する個別のエンティティを必要としない。その理由は、MITアプリケーション内のローカル制御アルゴリズムが通常の動作の副産物としてこの検出を行うことができるからである。
3.MITのローカルアルゴリズムは、個別のエントリが行う場合に比べて構造的な負荷変化を検出することができる。その理由は、それがリソース使用法(resource usage means)に対して意味のある解釈を有するからである。
4.LITが、条件付保証バケットマージンの利用可能性についての情報を明示的に提供されるので、LITは、変化に対して更に高速かつ更に円滑に応答することができる。この利点は、既に説明している変更したバケット割当てプロトコル(ステップ(b))の直接的な結果である。
5.MITは、LITの一致を知る必要がない。MITは、LITが存在することを知る必要がない。
(図1〜5に記載したような)基本プロセスの主な利点は有効なままである。アロケーションメカニズムは、バケット転送に含まれない。これによって、オーバヘッドが大幅に減少する。一例として、新たな状況に対する承認テスト、又は、種々のエンティティが実行される新たな品質レベルを決定する処理段階を必要としない。
同期MITの場合、既に説明している変更したパケット割当てプロトコル(ステップ(b))の変形により複数の利点を達成することができる。本発明の更に別の態様によれば、コンピュータ読出し可能媒体の一例は、上記プロセス及び方法を実行するプロセッサを制御する符号化プログラミング命令を有する。例えば、プロセッサは、図1〜18で説明した方法を実行する。コンピュータ読出し可能媒体は、CD−ROM,DVDに制約されず、磁気記憶装置、RAM,ROM、ハードディスク、メモリスティク、光メモリ等を含む。
本発明の使用を追跡することができる。その理由は、本発明の使用が明示的な他のインタフェースを要求するからである。
他のMITインタフェース
Set_budgets (in MIGB_value: budget_type; in GBM_value: budget_type);//called by AM
追加のLITインタフェース
Set_budgets (in LIGB_value: budget_type; in CGBM_value: budget_type);//called by AM
CGBM_available();/called by scheduler.
CGBM_not_available();called by scheduler.
他のスケジューラインタフェース
GBM_required (in tid, task id);//called by MIT
GBM_not_required (in tid, task id);//called by MIT
他のMITインタフェース
Set_budgets (in MIGB_value: budget_type; in GBM_value: budget_type);//called by AM
追加のLITインタフェース
Set_budgets (in LIGB_value: budget_type; in CGBM_value: budget_type);//called by AM
CGBM_available();/called by scheduler.
CGBM_not_available();called by scheduler.
他のスケジューラインタフェース
GBM_required (in tid, task id);//called by MIT
GBM_not_required (in tid, task id);//called by MIT
上記発明を、テレビジョン、受信機、オーディオ−ビデオプロセッサ、デジタルプロセッサ、セットトップボックス及び他の家電に適用できる。
種々の実施の形態をここで特定して説明したが、本発明の変更及び変形は、上記教示によってカバーされ、本発明の範囲を逸脱することなく添付した請求の範囲内にある。例えば、所定の用語及びプロトコルを用いたが、他の名称及びプロトコルを、本発明の範囲を逸脱することなく用いることができる。さらに、本例は、特許請求の範囲によってカバーされた発明の変更及び変形を制限するよう解釈すべきものではなく、あり得る変形を示しているにすぎない。
Claims (24)
- マルチプルタスクを制御する方法であって、
第1のタスクを上位タスクに割り当て、
第2のタスクを下位タスクに割り当て、
上位保証バケットに従って保証バケットマージンを上位タスクに割り当てるとともに、この割当ての情報を前記上位タスクに明示的に提供し、
下位保証バケットを前記下位タスクに割り当てるとともに、この割当ての情報を前記下位タスクに明示的に提供し、
前記保証バケットマージンをもはや必要としないメッセージを前記上位タスクに送信し、
条件付保証バケットマージンを前記下位タスクに割り当てるとともに、この割当ての情報を前記下位タスクに明示的に提供することを特徴とする方法。 - 前記上位タスクがもはや前記保証バケットマージンを必要としないことを決定することを特徴とする請求項1記載の方法。
- 第1のタスクを起動する方法であって、前記第1のタスクが、第2のタスクより高いレベルのプライオリティが割り当てられ、
前記第1のタスクが他のバケットマージンを必要とするか否か決定し、
前記他のバケットマージンがもはや必要とされない又は前記他のバケットマージンが必要とされているというメッセージを送信することを特徴とする方法。 - 前記第1のタスクがもはや他のバケットマージンを必要としないというメッセージを受信すると、条件付保証バケットマージンを自動的に前記第2のタスクに割り当てることを特徴とする請求項3記載の方法。
- マルチタスクプロセスの2以上のタスクを制御する方法であって、
上位保証バケット及び保証バケットマージンについての情報を、上位タスクである第1のタスクに明示的に提供し、
下位保証パケット及び条件付保証パケットマージンについての情報を、下位タスクである第2のタスクに明示的に提供し、
前記上位保証バケット及び前記保証バケットマージンを、最初のあり得るときに前記第1のタスクに提供し、
前記下位保証パケットを、最初のあり得るときに前記第2のタスクに提供し、
前記第1のタスクが、前記第1のタスクが前記上位保証バケットのみを用いてジョブを行うことができる実行中のあるポイントで決定すると、前記第1のタスクが保証バケットマージンを必要としないという情報をスケジューラに明示的に提供することを特徴とする方法。 - 前記保証バケットマージンの前記第1のタスクへの提供を、最初のあり得るときに停止することを特徴とする請求項5記載の方法。
- 前記条件付保証バケットマージンの前記第2のタスクへの提供を、最初のあり得るときに開始することを特徴とする請求項6記載の方法。
- 前記条件付保証バケットマージンの提供についての情報を前記第2のタスクに提供することを特徴とする請求項7記載の方法。
- 前記第1のタスクが前記保証バケットマージンを必要とすることを実行中のあるポイントで前記第1のタスクによって決定することを特徴とする請求項7記載の方法。
- 前記第1のタスクがその保証バケットマージンを必要とする情報を前記スケジューラに明示的に提供することを特徴とする請求項9記載の方法。
- 前記条件付バケットマージンを取り除くという情報を前記第2のタスクに提供することを特徴とする請求項10記載の方法。
- 前記条件付保証バケットマージンの前記第2のタスクへの提供を、最初のあり得るときに停止することを特徴とする請求項11記載の方法。
- 前記保証バケットマージンの前記第1のタスクへの提供を、最初のあり得るときに開始することを特徴とする請求項11記載の方法。
- 第1のプライオリティレベルを有する第1のタスクと、
前記第1のプライオリティレベルより低い第2のプライオリティレベルを有する第2のタスクと、
リソースのバケットの割当てを行うアロケーションメカニズムとを具え、前記アロケーションメカニズムが、上位保証バケット及び保証バケットマージンについての情報を前記第1のタスクに明示的に提供するとともに、下位保証バケット及び条件付保証バケットマージンについての情報を前記第2のタスクに明示的に提供し、
割り当てられて量を前記第1及び第2のタスクに提供するスケジューラを更に具え、前記スケジューラが、前記上位保証バケット及び前記保証バケットマージンを最初のあり得るときに前記第1のタスクに提供するとともに、前記下位保証バケットを最初のあり得るときに前記第2のタスクに提供し、前記第1のタスクが、前記第1のタスクが前記上位保証バケットのみを適切に実行できることを実行中のあるポイントで決定すると、前記第1のタスクが、前記第1のタスクがその保証バケットマージンを必要としないことを前記スケジューラに明示的に提供することを特徴とする装置。 - 前記スケジューラが、前記保証バケットマージンの前記第1のタスクへの提供を最初のあり得るときに停止するとともに、前記条件付保証バケットマージンの前記第2のタスクへの提供を最初のあり得るときに開始することを特徴とする請求項14記載の装置。
- 前記スケジューラが、前記条件付保証バケットマージンを提供する情報を前記第2のタスクに提供することを特徴とする請求項15記載の装置。
- 前記第1のタスクが、前記第1のタスクが前記保証バケットマージンを必要とすることを実行中のあるポイントで決定し、前記第1のタスクが、前記第1のタスクがその保証バケットマージンを必要とする情報を前記スケジューラに提供することを特徴とする請求項14記載の装置。
- 前記スケジューラが、前記条件付保証バケットが取り除かれる情報を前記第2のタスクに提供することを特徴とする請求項17記載の装置。
- 前記スケジューラが、前記条件付保証バケットマージンの前記第2のタスクへの提供を最初のあり得るときに停止することを特徴とする請求項18記載の装置。
- 前記スケジューラが、前記保証バケットマージンの前記第1のタスクへの提供を最初のあり得るときに開始することを特徴とする請求項19記載の装置。
- 第1のプライオリティレベルを有する第1のタスクと、
前記第1のプライオリティレベルより低い第2のプライオリティレベルを有する第2のタスクと、
リソースのバケットの割当てを行うアロケーションメカニズムとを具え、前記第1のタスクが、上位保証バケット及び保証バケットマージンについての情報を明示的に提供し、前記第2のタスクが、下位保証バケット及び条件付保証バケットマージンについての情報を明示的に提供し、
前記条件付保証バケットマージンの利用可能性をモニタする条件付バケットモニタを更に具え、前記条件付バケットモニタが、上位タスクがもはや前記保証バケットマージンを必要としないメッセージを受信し、前記上位タスクが前記条件付バケットマージンを必要とするメッセージを受信し、前記保証バケットマージン、前記条件付保証バケットマージン、前記上位保証バケット及び前記下位保証バケットのバケット割当てを前記アロケーションメカニズムから受信し、かつ、前記バケット割当てに関するリザベーションコマンドを送信し、
割り当てられた量を前記リザベーションコマンドに基づいて前記第1及び第2のタスクに提供するスケジューラを更に具え、前記スケジューラが、前記上位保証バケット及び前記保証バケットマージンを最初のあり得るときに前記第2のタスクに提供し、前記第1のタスクが、前記第1のタスクが前記上位保証バケットのみを用いて適切に実行することができることを実行中のあるポイントで決定し、前記条件付バケットモニタが、前記第1のタスクに対する前記上位保証バケットのみを含むとともに前記第2のタスクに対する前記下位保証バケットに従った前記条件付保証バケットマージンを含むリザベーションコマンドを、前記スケジューラに送信することを特徴とする装置。 - 前記第1のタスクが、前記保証バケットマージンを必要とすることを決定するとともに、これを前記条件付バケットモニタに送信し、前記第1のタスクに対する前記保証バケットマージン及び前記上位保証バケット並びに前記第2のタスクに対する前記下位保証バケットを含むリザベーションコマンドを前記スケジューラに送信することを特徴とする請求項21記載の装置。
- 前記条件付バケットモニタが、前記条件付保証バケットマージンの提供の情報を前記第2のタスクに提供することを特徴とする請求項21記載の装置。
- 前記条件付バケットモニタが、前記条件付保証バケットマージンが取り除かれる情報を前記第2のタスクに提供することを特徴とする請求項22記載の装置。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US51981103P | 2003-11-13 | 2003-11-13 | |
PCT/IB2004/052397 WO2005048097A2 (en) | 2003-11-13 | 2004-11-11 | Method and system for restrained budget use |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007512592A true JP2007512592A (ja) | 2007-05-17 |
Family
ID=34590449
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006539060A Withdrawn JP2007512592A (ja) | 2003-11-13 | 2004-11-11 | 制限されたバケット使用方法及びシステム |
Country Status (6)
Country | Link |
---|---|
US (1) | US20070083863A1 (ja) |
EP (1) | EP1685487A2 (ja) |
JP (1) | JP2007512592A (ja) |
KR (1) | KR20060132823A (ja) |
CN (1) | CN1879086A (ja) |
WO (1) | WO2005048097A2 (ja) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101819555B (zh) | 2005-07-06 | 2011-11-02 | 松下电器产业株式会社 | 访问控制装置、访问控制集成电路以及访问控制方法 |
JP2007058541A (ja) * | 2005-08-24 | 2007-03-08 | Matsushita Electric Ind Co Ltd | プロセッサ、処理方法及び処理プログラム |
US10555145B1 (en) * | 2012-06-05 | 2020-02-04 | Amazon Technologies, Inc. | Learned configuration of modification policies for program execution capacity |
CN106354553A (zh) * | 2015-07-14 | 2017-01-25 | 咪咕音乐有限公司 | 一种大数据系统中基于资源估算的任务调度方法及装置 |
US9606792B1 (en) * | 2015-11-13 | 2017-03-28 | International Business Machines Corporation | Monitoring communication quality utilizing task transfers |
CN110008026A (zh) * | 2019-04-09 | 2019-07-12 | 中国科学院上海高等研究院 | 基于额外预算均分的作业调度方法、装置、终端和介质 |
US11579959B2 (en) | 2021-05-26 | 2023-02-14 | Honeywell International Inc. | Systems and methods for margin based diagnostic tools for priority preemptive schedulers |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5838968A (en) * | 1996-03-01 | 1998-11-17 | Chromatic Research, Inc. | System and method for dynamic resource management across tasks in real-time operating systems |
CA2252238A1 (en) * | 1997-10-31 | 1999-04-30 | Sun Microsystems, Inc. | Method and apparatus for sharing a time quantum |
US6799208B1 (en) * | 2000-05-02 | 2004-09-28 | Microsoft Corporation | Resource manager architecture |
US7140022B2 (en) * | 2000-06-02 | 2006-11-21 | Honeywell International Inc. | Method and apparatus for slack stealing with dynamic threads |
US7058951B2 (en) * | 2000-11-06 | 2006-06-06 | Koninklijke Philips Electronics N.V. | Method and a system for allocation of a budget to a task |
US20030172160A9 (en) * | 2001-01-10 | 2003-09-11 | Widegren Ina B. | Method and apparatus for coordinating end-to-end quality of service requirements for media flows in a multimedia session |
US20020133530A1 (en) * | 2001-03-15 | 2002-09-19 | Maarten Koning | Method for resource control including resource stealing |
US6904483B2 (en) * | 2001-03-20 | 2005-06-07 | Wind River Systems, Inc. | System and method for priority inheritance |
US7328264B2 (en) * | 2001-07-31 | 2008-02-05 | Tandberg Telecom As | System and method for fractional resource scheduling for video teleconferencing resources |
US20030182425A1 (en) * | 2002-03-01 | 2003-09-25 | Docomo Communications Laboratories Usa, Inc. | Communication system capable of executing a communication task in a manner adaptable to available distributed resources |
US7328406B2 (en) * | 2004-04-30 | 2008-02-05 | Tandberg Telecom As | System, method and software for managing and publishing resource availability data |
-
2004
- 2004-11-11 KR KR1020067009053A patent/KR20060132823A/ko not_active Application Discontinuation
- 2004-11-11 US US10/579,159 patent/US20070083863A1/en not_active Abandoned
- 2004-11-11 CN CNA200480033282XA patent/CN1879086A/zh active Pending
- 2004-11-11 JP JP2006539060A patent/JP2007512592A/ja not_active Withdrawn
- 2004-11-11 EP EP04799128A patent/EP1685487A2/en not_active Withdrawn
- 2004-11-11 WO PCT/IB2004/052397 patent/WO2005048097A2/en not_active Application Discontinuation
Also Published As
Publication number | Publication date |
---|---|
KR20060132823A (ko) | 2006-12-22 |
CN1879086A (zh) | 2006-12-13 |
EP1685487A2 (en) | 2006-08-02 |
US20070083863A1 (en) | 2007-04-12 |
WO2005048097A2 (en) | 2005-05-26 |
WO2005048097A3 (en) | 2006-03-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6385638B1 (en) | Processor resource distributor and method | |
Nieh et al. | A SMART scheduler for multimedia applications | |
US11582166B2 (en) | Systems and methods for provision of a guaranteed batch | |
US8261275B2 (en) | Method and system for heuristics-based task scheduling | |
US8020161B2 (en) | Method and system for the dynamic scheduling of a stream of computing jobs based on priority and trigger threshold | |
TWI260543B (en) | Performance scheduling method and system, and computer readable medium | |
Lakshmanan et al. | Scheduling self-suspending real-time tasks with rate-monotonic priorities | |
EP1410199A2 (en) | A method and a system for allocation of a budget to a task | |
JP2005509976A (ja) | 予算剰余をタスクに割り当てるための方法及びシステム | |
Garcia-Valls et al. | Real-time reconfiguration in multimedia embedded systems | |
JP2013218744A (ja) | リソースに基づいたスケジューラ | |
JP2007512592A (ja) | 制限されたバケット使用方法及びシステム | |
JP2010287046A (ja) | リソース配分システム、リソース配分方法及びリソース配分プログラム | |
US8640131B2 (en) | Demand-based processor cycle allocation subsequent to equal group-based processor cycle distribution | |
Salehi et al. | Resource provisioning based on lease preemption in InterGrid | |
JPH10240548A (ja) | タスクスケジューリング装置及び方法 | |
JP2008276666A (ja) | 情報処理装置および方法、並びにプログラム | |
Bril et al. | A cognac-glass algorithm for conditionally guaranteed budgets | |
KR100471746B1 (ko) | 연성 실시간 태스크 스케줄링 방법 및 그 기록매체 | |
JP2003186686A (ja) | リソース制御装置、方法及び記憶媒体 | |
Taranovsky | CPU Scheduling in Multimedia Operating Systems | |
WO2021129917A1 (en) | Method for allocating processor resource, computing unit and video surveillance arrangement | |
EP1721251A2 (en) | Method and system for restrained budget use with controlled budget transfer | |
Povzner et al. | Supporting rate-based processes in an integrated system | |
US20130042247A1 (en) | Starvationless Kernel-Aware Distributed Scheduling of Software Licenses |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20080205 |