(57)【要約】  リアルタイムオペレーティングシステム２０において複数のタスクを制御する方法１０，３０は、２つ又はそれ以上のタスク２４，２５に優先度を与える。第1のタスク２４はより重要なタスクであるように与えられる。第２のタスク２５は、より少なく重要なタスクであるように与えられる。その後、保証バジェットのマージンが、より重要な保証バジェットとともにより重要なタスクに割り当てられる。より少なく重要な保証マージンがより少なく重要なタスクに割り当てられもする。実行中のある時点において、より高い優先度の又はより重要なタスク２４が、保証バジェットのマージンをもはや必要としないことを決定し、その場合、条件付きの保証バジェットのマージンがより少なく重要なタスク２５に割り当てられる。保証バジェットのマージンを再要求する際、ＧＢＭを受け取る前又はＣＧＢＭがＬＩＴから取り除かれる前に、ＭＩＴはＧＢＭの開放又は再要求の際に決定された所定の静的期間又は動的期間のいずれか長い方の期間待つ。
2007523423.tif 000002
【特許請求の範囲】
【請求項１】
システムにおいて複数のタスクを制御する方法であって、
より重要なタスクであるように第1のタスクを与えることと、
より少なく重要なタスクであるように第２のタスクを与えることと、
より重要な保証バジェットと共に保証バジェットのマージンを前記より重要なタスクに割り当てることと、
条件付きの保証バジェットのマージンと共により少なく重要な保証バジェットを前記より少なく重要なタスクに割り当てることと、
前記より重要なタスクが前記保証バジェットのマージンを必要とすることを決定する時と前記より重要なタスクが実際に前記保証バジェットのマージンを必要とする時との間の静的期間を割り当てることと、
最初の可能な機会に、前記より重要な保証バジェットと前記保証バジェットのマージンとを前記より重要なタスクに与え、前記より少なく重要な保証バジェットを前記より少なく重要なタスクに与えることと、
前記より重要なタスクは前記保証バジェットのマージンをもはや必要としないことを前記より重要なタスクによって決定することと、
前記保証バジェットのマージンを前記より重要なタスクに与えることを中断し、条件付きの保証バジェットのマージンを前記より少なく重要なタスクに与えることを開始するとともに、前記条件付き保証バジェットの供給について前記より少なく重要なタスクに明示的に知らせることと、
前記より重要なタスクはその時点において前記保証バジェットのマージンを必要とすることを前記より重要なタスクによって決定することと、
前記条件付きの保証バジェットのマージンが解除されることを前記より少なく重要なタスクに明示的に知らせることと、
専ら前記より重要なタスクがその時点で前記保証バジェットのマージンを必要とする決定が行われた時から測定されるような前記静的期間の終了後に、前記より少なく重要なタスクから前記条件付きの保証バジェットのマージンを解除し、前記保証バジェットのマージンを前記より重要なタスクに与えることと
を有する当該方法。
【請求項２】
前記保証バジェットのマージンを次に再要求する際に前記より重要なタスクが待つことができる動的時間に関して、前記保証バジェットのマージンを解放する時にスケジューラに知らせることを更に有する請求項１記載の方法。
【請求項３】
専ら前記より重要なタスクがその時点で前記保証バジェットのマージンを必要とする決定が行われた時から測定されるような前記静的期間又は動的期間のより長い方の終了後に、前記より少なく重要なタスクから前記条件付きの保証バジェットのマージンを解除し、前記保証バジェットのマージンを前記より重要なタスクに与えることを更に有する請求項２記載の方法。
【請求項４】
前記保証バジェットのマージンを再要求する時に前記保証バジェットのマージンを受け取る前に前記より重要なタスクが待つことができる動的期間に関してスケジューラに知らせることを更に有する請求項１記載の方法。
【請求項５】
専ら前記より重要なタスクがその時点で前記保証バジェットのマージンを必要とする決定が行われた時から測定されるような前記静的期間又は前記動的期間のいずれか長い方の終了後に、前記より少なく重要なタスクから前記条件付きの保証バジェットのマージンを解除し、前記保証バジェットのマージンを前記より重要なタスクに与えることを更に有する請求項４記載の方法。
【請求項６】
前記条件付きの保証バジェットのマージンの供給についてより少なく重要なタスクに明示的に知らせることは、起こり得るこの次の解除が遅延する前記静的期間について前記より少なく重要なタスクに知らせることを更に有する請求項１記載の方法。
【請求項７】
前記条件付きの保証バジェットのマージンが解除されることをより少なく重要なタスクに明示的に知らせることは、前記解除が遅延する前記静的期間について前記より少なく重要なタスクに明示的に知らせることを更に有する請求項１記載の方法。
【請求項８】
前記より少なく重要なタスクに前記静的期間を知らせることを更に有する請求項１記載の方法。
【請求項９】
マルチタスクシステムの２つ又はそれ以上のタスクを制御する方法であって、
より重要なタスクである第１のタスクに、より重要な保証バジェット及び保証バジェットのマージンについて明示的に知らせることと、
より少なく重要なタスクである第２のタスクに、より少なく重要な保証バジェット、条件付きの保証バジェットのマージン及び前記条件付きの保証バジェットのマージンの解除が解除の通知に対して遅延する静的期間について明示的に知らせることと、
最初の可能な機会に、前記保証バジェットのマージンに加えて前記より重要な保証バジェットを前記第１のタスクに与えることと、
最初の可能な機会に、前記より少なく重要な保証バジェットを前記第２のタスクに与えることと、
前記第１のタスクが実行中のある時点において前記より重要な保証バジェットのみを用いてジョブを行うことができることを決定すると、前記第１のタスクは、前記保証バジェットのマージンを実際に必要とする前の前記保証バジェットのマージンを次に再要求する時に前記第１のタスクが待つ動的期間とともに保証バジェットのマージンを必要としないことをスケジューラに明示的に知らせることと
を有する当該方法。
【請求項１０】
最初の可能な機会に、前記第１のタスクに前記保証バジェットのマージンを与えることを中断することを更に有する請求項９記載の方法。
【請求項１１】
最初の可能な機会に、前記第２のタスクに前記条件付きの保証バジェットのマージンを与えることを開始することを更に有する請求項１０記載の方法。
【請求項１２】
前記条件付きの保証バジェットのマージンの次の解除が解除の通知に対して遅延する静的期間又は動的期間とともに前記条件付きの保証バジェットのマージンを与えることを前記第２のタスクに知らせることを更に有する請求項１１記載の方法。
【請求項１３】
前記第１のタスクが前記保証バジェットのマージンも必要とすることを実行中のある時点において前記第１のタスクによって決定することを更に有する請求項１１記載の方法。
【請求項１４】
前記第１のタスクが前記保証バジェットのマージンを受け取る前に待つことができる動的期間とともに前記第１のタスクが前記保証バジェットのマージンを必要とすることを前記スケジューラに明示的に知らせることを更に有する請求項１３記載の方法。
【請求項１５】
所定の静的期間又は動的期間のより長い方の後に前記条件付きの保証バジェットのマージンが解除されることを前記第２のタスクに知らせることを更に有する請求項１４記載の方法。
【請求項１６】
前記静的又は動的期間のより長い方の終了後に、前記条件付きの保証バジェットのマージンを前記第２のタスクに与えることを中断することを更に有する請求項１５記載の方法。
【請求項１７】
前記静的又は動的期間のより長い方の終了後に、前記保証バジェットのマージンを前記第１のタスクに与えることを開始することを更に有する請求項１５記載の方法。
【請求項１８】
第１の重要度レベルを持つ第１のタスクと、
前記第１の重要度レベルよりも低い第２の重要度レベルを持つ第２のタスクと、
リソースのバジェットを割り当てる割り当てメカニズムであって、より重要な保証バジェットと保証バジェットのマージンとについて前記第１のタスクに明示的に知らせ、より少なく重要な保証バジェットと、条件付きの保証バジェットのマージンと、前記条件付きの保証バジェットのマージンの解除が解除の通知に対して遅延する所定の静的時間とを前記第２のタスクに明示的に知らせる当該割り当てメカニズムと、
バジェット量を前記第１及び第２のタスクに与えるスケジューラであって、最初の可能な機会に前記保証バジェットのマージンに加えて前記より重要な保証バジェットを前記第１のタスクに与えるとともに、最初の可能な機会に前記より少なく重要な保証バジェットを前記第２のタスクに与え、前記第１のタスクは、実行中のある時点において前記より重要な保証バジェットのみを用いて適切に実行し得ることを決定すると、保証バジェットのマージンを必要としないことを当該スケジューラに明示的に知らせる当該スケジューラと
を有する装置であって、
前記スケジューラは、最初の可能な機会に前記保証バジェットのマージンを前記第１のタスクに与えることを中断し、最初の可能な機会に前記条件付きの保証バジェットのマージンを前記第２のタスクに与えることを開始し、
前記スケジューラは、前記第２のタスクに前記条件付きの保証バジェットのマージンを与えることを知らせ、
前記第１のタスクは、実行中のある時点において、前記保証バジェットのマージンも必要であることを決定し、前記保証バジェットのマージンを必要とすることを前記スケジューラに明示的に知らせ、
前記スケジューラは、前記条件付きの保証バジェットのマージンが解除されることを前記第２のタスクに知らせ、
前記スケジューラは、前記所定の静的期間の終了後に前記第２のタスクに前記条件付きの保証バジェットのマージンを与えることを中断する
当該装置。
【請求項１９】
前記スケジューラは、前記所定の静的期間の終了後に前記第１のタスクに前記保証バジェットのマージンを与えることを開始する請求項１８記載の装置。
【請求項２０】
前記第１のタスクが前記保証バジェットのマージンを必要としないことを前記スケジューラに知らせる際、前記第１のタスクは前記保証バジェットのマージンを再要求する時に待つことができる動的期間に関して前記スケジューラに知らせもし、前記第１のタスクが前記保証バジェットのマージンを次に再要求すると、前記スケジューラは所定の静的期間又は前記動的期間のより長い方の終了後に前記条件付きの保証バジェットのマージンを前記第２のタスクに与えることを中断する請求項１８記載の装置。
【請求項２１】
前記第１のタスクがその時点において前記保証バジェットのマージンを必要とすることを前記スケジューラに知らせる際、前記第１のタスクは前記保証バジェットのマージンを受け取る前に待つことができる動的期間に関して前記スケジューラに知らせもし、前記スケジューラは所定の静的時間又は前記動的時間のより長い方の終了後に前記条件付きの保証バジェットのマージンを前記第２のタスクに与えることを中断する請求項１８記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全体としてはオペレーティングシステムにおいてリソースを管理する方法及び装置に係り、より具体的にはリアルタイムで機能するオペレーティングシステムにおいてリソースを管理する方法及び装置に関する。
【背景技術】
【０００２】
条件付き保証バジェット（Conditional Guaranteed Budget；ＣＧＢ）は、システムの費用対効果の改善を目的として、最初はバジェットスケジューラのレベルにおけるメカニズムとして導入された。ＣＧＢの背景にある基本的なアイデアは、以下の通りである。より重要なタスク（more important task；ＭＩＴ）は、構造的な負荷の増大を予想するために、より重要な保証バジェット（more important guaranteed budget；ＭＩＧＢ）及び更に保証バジェットのマージン（guaranteed budget margin；ＧＢＭ）を受け取る。より少なく重要なタスク（less important task；ＬＩＴ）は、より少なく重要な保証バジェット（less important guaranteed budget；ＬＩＧＢ）を受け取る。また、上記ＬＩＴは、ＭＩＴが一貫してＧＢＭを使用しない場合に条件付きの保証バジェットのマージン（conditionally guaranteed budget margin；ＣＧＢＭ）を受け取る。このＣＧＢのオリジナルのタイプの問題は、ＣＧＢＭの割り当てが暗黙的であることである。我々は、このＣＧＢのオリジナルのタイプを弱いＣＧＢと呼ぶ。弱いという用語は、保証が弱いこと、例えば、上記ＭＩＴがＧＢＭ（の一部）を使用し、その結果上記ＬＩＴがＣＧＢＭを受け取ったとは言えないことを指す。
【０００３】
米国仮特許出願No.60/519,811（出願人整理番号no.613652）は、割り当てを明示的にすることによりこの考えを改善している。我々は、この後者の種類のＣＧＢを強いＣＧＢと呼ぶ。強いという用語は、保証が強いこと、例えば、上記ＭＩＴはＧＢＭを要求した時かつその時限りにおいてＧＢＭを使用することができ、ＭＩＴがＧＢＭを解放している（及びまだ再要求していない）時は上記ＬＩＴがＣＧＢＭを実際に頼りにし得ることを指す。上記ＭＩＴは、ＧＢＭを要求すると、瞬時に、すなわちその時点のバジェット期間中にＧＢＭを受け取る。結果として、上記ＣＧＢＭもまたＬＩＴから瞬時に解除（withdraw）される。
【０００４】
両方の種類のＣＧＢは、システムにおいて利点を有し、使用される。一例として、入力読み取り器のようなアプリケーションがスケールされることができず、従って負荷の変動に対応するために最悪のバジェットの割り当てを必要とする際、強いＣＧＢは適用され得ず、従ってシステムの費用対効果を改善したい場合には、弱いＣＧＢを必要とする。
【０００５】
追加の背景として、本質的に２つのタイプのタスクによるバジェットの消費が存在する。
・同期動作：タスクはバジェットの消費と同期して機能する（すなわち、バジェットが補充されるとタスクが始まり、バジェット期間内にその仕事を終える。）。
・非同期動作：タスクはバジェットと同期して機能しない。タスクは、バジェットの消費に比べて、先を行くか又は後れをとる。非同期動作は、負荷を均等化するために用いられることが多い。
【０００６】
ある場合においては、上記ＬＩＴからのＣＧＢＭの瞬間的なロスが問題を引き起こし得る。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従って、本発明は、上記ＣＧＢＭの瞬時の解除の発生を伴うことなく重要度をベースとするリアルタイムオペレーションシステムにおけるリソースの使用を改善するための方法及び装置を開発するという問題に目を向けられている。
【課題を解決するための手段】
【０００８】
本発明は、ＭＩＴが保証バジェットのマージンを再要求する際、ＬＩＴが条件付きの保証バジェットのマージンの使用からスムーズに移行できるように、ＭＩＴが保証バジェットのマージンを実際に必要とする前に所定の期間が生じることをスケジューラに示す先読み（look-ahead）メカニズムを与えることによりこれら及びその他の問題を解決する。
【０００９】
また、本発明の他の観点によれば、上記先読みメカニズムは、ＭＩＴがすぐにＧＢＭを必要とすることをスケジューラに通知した後少なくとも静的期間の間ＭＩＴがＧＢＭを必要としないことをスケジューラが知ることができる当該静的期間を使用する。この静的期間は、バジェットの割り当ての一部としてプリセットされる。
【００１０】
更に、本発明の更に他の観点によれば、上記先読みメカニズムは、ＭＩＴがＧＢＭを再要求する時にＧＢＭを必要としない期間をＭＩＴがスケジューラに示すことを可能にする動的期間を含む。この動的期間の場合、ＭＩＴは、ＧＢＭを解放するメッセージ又は代替としてＧＢＭを再要求するメッセージにこの値を含む。
【００１１】
本発明の他の観点は、以下の図面に照らし合わせて詳細な説明を検討すると当業者には明らかになるであろう。
【発明を実施するための最良の形態】
【００１２】
本明細書中における「一実施の形態」との全ての記載は、当該実施の形態に関して説明される特別な機能、構造又は特徴が本発明の少なくとも１つの実施の形態に含まれることを意味することに注意されたい。本明細書中の種々の箇所における「一実施の形態において」という表現の現れは、必ずしも全て同じ実施の形態を指しているわけではない。
【００１３】
ある状況において、ＭＩＴは、突然の負荷の増大に直面するとＧＢＭを瞬時に必要とする。従って、先のメカニズムは、ＬＩＴからのＣＧＢＭの即時の解除及びＭＩＴへのＧＢＭの瞬時の供給の両方を可能にする。しかしながら、瞬時のバジェットの移動は、ＬＩＴに関するオーバーシュートを伴うしとやかではない（non-graceful）質の劣化を招く（図６参照）。
【００１４】
このオーバーシュートを伴うしとやかではない質の劣化の理由は２つある。まず第１に、瞬時にＧＢＭを与えることができるように、ＣＧＢＭの解除はＣＧＢＭの供給の最中に起こる（以下に与えられる例を参照されたい。）。表１は、ＭＩＴ、ＬＩＴ及びＯＩＴ（other important task）に割り当てられるバジェットを説明している。５周期で２つのＭＩＧＢ及び追加の１つのＧＢＭがＭＩＴに割り当てられ、１０周期で３つのＬＩＧＢ及び追加の２つのＣＧＢＭがＬＩＴに割り当てられ、１２周期で１つのＯＩＧＢがＯＩＴに割り当てられる。我々は、バジェットの固定された優先順位のプリエンプティブスケジューリング（ＦＰＰＳ）及びＣＧＢの「代わりの（in-the-place-of）」インプリメンテーションを前提としている。ＣＧＢの「代わりの」インプリメンテーションは、米国特許出願（出願人整理番号PHNL010828EPP）に開示されており、参照することにより全部を本明細書において繰り返したかのように本明細書に取り込まれたものとする。
【００１５】
例：供給の最中におけるＣＧＢＭの解除
表１：タスクに割り当てられるバジェット
【表１】
2007523423.tif 000003
【００１６】
ここで、図７を考察する。図７は、バジェットの供給を伴う時系列を示しており、保証バジェットＭＩＧＢ、ＬＩＧＢ及びＯＩＧＢが同時に解放される。
【００１７】
ＭＩＧＢは、参照を容易にするために番号を付されている。ＭＩＴは、同時に解放する前にＧＢＭを解放していると仮定されている。従って、ＬＩＴは、ＭＩＴが１により識別されるＧＢの消費を終了した直後にＧＢＭ「の代わりに」ＣＧＢＭの第1のユニットを消費することを許可される。ＭＩＴは、２により識別されるＭＩＧＢの消費の間にＧＢＭを再要求する。ＧＢＭは瞬時にＭＩＴに与えられ、それに対応してＣＧＢＭがＬＩＴから瞬時に解除される。結果として、ＬＩＴは当該周期の間にＣＧＢＭの半分のみを受け取り、ＣＧＢＭは供給の最中に解除される。
【００１８】
そのような状況において、ＬＩＴは、典型的にはＣＧＢＭを放つ一方で、作業のユニットを処理する。従って、上記作業のユニットが処理される動作の質のレベルは、依然として仮定されたＣＧＢＭの供給に基づく。第２に、ＣＧＢＭが実際に解除される前にＬＩＴが知らされる場合でさえも、ＬＩＴは、依然としてスムーズな質の低下を容易にすることが、すなわち、オーバーシュートを伴うことなくしとやかに質を適応させることができない。
【００１９】
一例として、ＬＩＴがＩＢ１Ｂ２ＰＢ３Ｂ４の形態のＧＯＰ（group of picture）を伴うＭＰＥＧ２ストリームを処理している場合を考えてみる。そのようなＧＯＰの復号は、Ｂフレームのいずれかが復号される前にＰフレームが処理されることを要する。後に処理されるが、Ｂ１及びＢ２はＰの前に与えられる（例えばスクリーンにおいて与えれる）。従って、ＬＩＴがＰフレームを処理した後にＣＧＢＭが解除される場合、ＬＩＴは依然として当該ＧＯＰの全ての、すなわちＢ１及びＢ２を含むＢフレームを処理することを要する。結果として、Ｂ１及びＢ２は、Ｐよりも低い動作の質のレベルにおいて処理され、より早く与えられる。そのような質の変動は、Ｐもまたより低い動作の質において処理される状況よりも低い質として認識され得る。
【００２０】
スムーズな質の低下は、モード変更プロトコルが実行される時かつその時限り仮定され得る。この状況の場合、ＬＩＴは、まず質のレベルを新しい（より低い）レベルにスムーズに低下させることを許可され、専らその後ＣＧＢＭが解除されるべきである。ＬＩＴのオーバーシュートを伴うしとやかではない質の劣化は、ＭＩＴの一時的な質の低下を上回って好ましい。
【００２１】
先の取り組みは、ＭＩＴは瞬時にＧＢＭを必要とするという仮定、従ってＬＩＴからのＣＧＢＭの即時の解除を容易にする目的に基づいている。このセクションでは、我々は、ＭＩＴはＧＢＭを瞬時に必要としない状況を考える。そのような状況では、ＬＩＴからのＣＧＢＭの即座の解除も必要ない。このセクションにおいて、我々は、最初にＭＩＴの要求を再考し、その後ＬＩＴに関する結果として得られる機会を再考し、最後にシステムに対する影響を再考する。
【００２２】
以下の例により説明されるように、ＭＩＴがＧＢＭを瞬時に必要としない状況が存在する。
【００２３】
・早期の負荷の増大の検出：
スケーラブルアルゴリズムのコントローラは、質の低下の認識を防止するために予防措置を講じるためだけではなく、ＧＢＭに関する次回の必要性を知らせるためにも、十分に早く負荷の増大を検出することができる。
【００２４】
・シーン（又はショット）の変化：
人間の目は、シーン（又はショット）の変化に感度が悪い。また、システムは、ＭＰＥＧ２ストリームを分析し、シーン（又はショット）の変化を検出する手段を含み得る。従って、（ａ）シーンの変化により負荷の増大が生じると、（ｂ）シーンの変化が検出され、（ｃ）ＭＩＴはシーンの変化により増大された負荷が生じたことに気付き（気付かされ）、ＭＩＴは低級の動作の質のレベルでデータを一時的に処理し、ＧＢＭに関する次の必要性を知らせる。
【００２５】
・負荷の増大の告知：
データストリームは、次の負荷の増大を知らせる追加のデータを含み得る。ＭＰＥＧ２のような規格は負荷の増大の告知を定義していないが、そのようなデータを採り入れることを許可している。従って、符号化されたメディアストリームは、動的なスケーラブルなメディア処理を制御するためにデコーダ側において用いられ得る追加の情報により拡張される。そのような状況において、ＭＩＴはまたＧＢＭに関する必要性を知らせる。
【００２６】
全てのこれらの例では、ＬＩＴはＣＧＢＭの次の解除について知らされ、従って、ＬＩＴは上記環境を仮定して質をできる限りしとやかに低下させるための適切な戦略を選択する。従って、「本格的な」モード変更プロトコルは容易にならず、質のレベルをしとやかに低下させるためにＬＩＴに対して利用可能な十分な準備期間（lead-time）が存在し得る。
【００２７】
本発明の一観点によれば、ＭＩＴはＧＢＭに関する要求を適時に知らせ、これは、瞬時のバジェットの移動と本格的なモード変更プロトコルとの両極端をなす事物の間の中間の解決策である。ＭＩＴによるＧＢＭに関する要求の検出（及び従ってＬＩＴに対するＣＧＢＭの解除についての告知）と実際の要求との間の「経過」時間の最小限の量が知られている又は知られるようになる瞬間に依存して、幾つかの考えられるオプションが存在する。
【００２８】
・ＭＩＴの遅延した要求に関する割り当て時間の情報：
「経過」時間の（最小限の）量は、静的に、すなわちＧＢＭ及びＣＧＢＭがＭＩＴ及びＬＩＴに割り当てられる時に知られる。
【００２９】
・ＭＩＴの遅延した要求に関する動的情報：
「経過」時間の（最小限の）量に関する追加の情報は、ＧＢＭがＭＩＴにより解放される時及び／又はＭＩＴがＧＢＭを再要求する時に利用可能になる。
【００３０】
以下の制約は、種々の「経過」時間の場合に当てはまる。
【００３１】
・割り当てられる時間と解放時間との間：
ＭＩＴがＧＢＭを解放する際にＭＩＴによる情報として過ぎる「経過」時間の量は、少なくとも割り当て時間において指定される量であるべきである。
【００３２】
・解放時間と再要求時間との間：
ＭＩＴがＧＢＭを再要求する際の情報として過ぎる「経過」時間の量は、少なくともＭＩＴがＧＢＭを解放した時に過ぎた量であるべきである。
【００３３】
ＬＩＴは、この「経過」時間の（最小限の）量について知らされると、適切な質の低下を容易にするために予防措置を講じる。最初の措置は割り当て時間において選択され、その後、ＬＩＴが（ＭＩＴがＧＢＭを解放する際にＭＩＴにより与えられる情報に基づいて）ＣＧＢＭを受け取ると適応され、ＬＩＴが（ＭＩＴがＧＢＭを再要求する際にＭＩＴにより与えられる情報に基づいて）ＣＧＢＭの解除について知らされると再度適応される。
【００３４】
上記システムに関して３つの影響が存在する。第1に、ＭＩＴについての情報を拡張する必要がある。ＭＩＴに関するデータは、バジェットの割り当て時間における使用のために「経過」時間の最小限の量についての情報とともに拡張されなければならない。第２に、経過時間の経過とともに追加のインターフェースを拡張しなければならない。
【００３５】
ＭＩＴインターフェース（未変化）：
Set_budget(in MIGB_value: budget_type; in GBM_value; budget_type); //called by AM.
【００３６】
拡張された追加のＬＩＴインターフェース：
Set_budget(in LIGB_value: budget_type; in CGBM_value; budget_type; in elapse_time: time); //called by AM.
CGBM_available(in elapse_time: time); //called by schedular.
CGBM_not_available(in elapse_time: time); //called by schedular.
【００３７】
拡張された追加のスケジューラインターフェース：
GBM_required(in tid: task_id; in elapse_time: time); //called by MIT.
GBM_not_required(in tid: task_id; in elapse_time: time); //called by MIT.
【００３８】
最後に、ＭＩＴが瞬時にＧＢＭを決して必要としないことが知られると、先の仕事とは著しく異なる代替の設計及び対応するインプリメンテーションを考案する。
【００３９】
図１に目を向けると、図１には、システムにおける２つのタスクを制御する方法の一例の実施の形態１０のフローチャートが示されている。
【００４０】
ステップ１１において、２つのタスクのうちの第１のタスクがより重要なタスク（ＭＩＴ）であるように与えられる。
【００４１】
ステップ１２において、２つのタスクのうちの第２のタスクがより少なく重要なタスク（ＬＩＴ）であるように与えられる。
【００４２】
ステップ１３において、保証バジェットのマージン（ＧＢＭ）がより重要な保証バジェット（ＭＩＧＢ）とともにＭＩＴに割り当てられる。
【００４３】
ステップ１４において、条件付きの保証バジェットのマージン（ＣＧＢＭ）がより少なく重要な保証バジェット（ＬＩＧＢ）とともにＬＩＴに割り当てられる。
【００４４】
ステップ１５において、ＭＩＴがＧＢＭを必要とすることを決定する時とＭＩＴがＧＢＭを実際に必要とする時との間の静的期間が割り当てられる。
【００４５】
ステップ１５ａにおいて、上記ＭＩＧＢ及びＧＢＭがＭＩＴに与えられ、上記ＬＩＧＢがＬＩＴに与えられる。
【００４６】
ステップ１６において、ＭＩＴは、ＧＢＭをもはや必要としないことを決定し、ＭＩＴがＧＢＭを次に再要求する際に待つことができる動的期間とともに上記結果に関するメッセージを送る。ステップ１６及び１８における文のイタリック体の部分は互いに取って代わることが可能である。ステップ１６においてＭＩＴが上記動的期間を送ると、動的期間はステップ１８においては送られず、逆の場合も同様である。代替として、２つの異なる動的期間が送られ得る。一方はＧＢＭの解放の時間においてであり、他方はＧＢＭを再要求する時間においてであり、この時間枠において大きなイベントが起こっている可能性があるので、これらはインプリメンテーション及びＧＢＭの解放とＧＢＭの再要求との間に過ぎた時間の量に依存する。
【００４７】
ステップ１７において、ＧＢＭはＭＩＴにもはや与えられず、条件付きの保証バジェットのマージン（ＣＧＢＭ）がＬＩＴに与えられる。さらに、ＬＩＴは、静的又は動的期間のいずれか長い方とともにＣＧＢＭの供給について知らされる。
【００４８】
ステップ１８において、ＭＩＴは、ＧＢＭを必要とすることを決定し、ＭＩＴがＧＢＭを受け取る前に待つことができる動的期間とともに上記結果に関するメッセージを送る。
【００４９】
ステップ１９において、ＬＩＴは、ＣＧＢＭが回収されることを明示的に知らされる。暗黙的に、ＬＩＴは、これが少なくとも静的期間（ＭＩＴがスケジューラに知らせ、スケジューラがＬＩＴに知らせた時からのより少ない幾らかの処理の遅延）が終わった後に生じることを知る。また、ＬＩＴは、後にＣＧＢＭが解除される静的期間よりも長い期間（すなわち動的期間）に関して同時に知らされ得る。
【００５０】
ステップ１９１において、専らＭＩＴがＧＢＭを必要とする決定が行われた時から測定されるような静的期間又は動的期間のより長い方の終了後に、ＣＧＢＭはＬＩＴから解除され、ＧＢＭがＭＩＴに与えられる。
【００５１】
図２は、図１及び図３ないし図５において説明される種々のプロセスの役割及び相互作用の実施の形態の一例を示している。アプリケーションマネージャ２１は、オペレーティングシステム２０により実行される互いに異なるタスク２４，２５の間の相対的な重要度のレベルを与えるために含まれている。本発明の一観点によれば、上記アプリケーションマネージャは、第１の重要度レベルについて第１のタスク２４に明示的に知らされる（１１）とともに、第２の重要度レベルについて第２のタスクに明示的に知らせる（１２）。上記第１の重要度レベルは、上記第２の重要度レベルよりも高い。第１のタスク２４は、より重要なタスクと呼ばれる。このより高い重要度のタスク２４は、オペレーティングシステム２０の外部又はオペレーティングシステム２０の内部のいずれか一方にタスクを含み得る。
【００５２】
第２のタスク２５は、上記第１の重要度レベルよりも低い第２の重要度レベルを有する。このより低く重要なタスク（又はより少なく重要なタスク）２５は、オペレーティングシステム２０の外部又はオペレーティングシステム２０の内部のいずれか一方にタスクを含み得る。また、第２のタスク２５は、単に重要度において第１のタスク２４よりも低いが、実行される第２の最も重要なタスクでさえもあり得る。
【００５３】
割り当てメカニズム２２は、オペレーティングシステム２０により実行される互いに異なるタスク２４，２５の間にリソースのバジェットを割り当てるために含まれている。本発明の一観点によれば、アプリケーションマネージャ２１は、タスク２４，２５の相対的な重要度レベルについて上記割り当てメカニズムに明示的に知らせる（１１及び１２）。本発明の更に他の観点によれば、割り当てメカニズム２２は、より重要な保証バジェット（ＭＩＧＢ）及び保証バジェットのマージン（ＧＢＭ）について第１のタスク２４に明示的に知らせる。上記より重要な保証バジェットは、第１のタスク２４により用いられるために取っておかれるリソース又は他の制限された可用性アイテムの量である。上記保証バジェットのマージンは、第１のタスク２４により必要とされる場合における上記より重要な保証バジェットに加えて第１のタスク２４により用いられるために取っておかれるリソース又は他の制限された可用性アイテムの量である。割り当てメカニズム２２は、また、より少なく重要な保証バジェット（ＬＩＧＢ）及び条件付きの保証バジェットのマージン（ＣＧＢＭ）について第２のタスク２５に明示的に知らせる１４とともに、タスク２４がＧＢＭを必要とする前のＧＢＭを再要求した後に待つことができる静的期間について第２のタスク２５に明示的に知らせる（１５）。より少なく重要な保証バジェット（ＬＩＧＢ）は、第２の若しくはより低い優先度のタスク２５により用いられるために取っておかれるリソース又は他の制限された可用性アイテムの量である。
【００５４】
本発明の更に他の観点によれば、割り当てメカニズム２２は、タスク２４，２５に割り当てられるバジェットについてスケジューラ２３に明示的に知らせる（１３及び１４）とともに、タスク２４が保証バジェットのマージンを必要とする前の保証バジェットのマージンを要求した後に待つことができる静的期間についてスケジューラ２３に明示的に知らせる（１５）。スケジューラ２３は、第１のタスク２４と第２のタスク２５とを含むオペレーティングシステム２０により実行される互いに異なるタスク２４，２５にリソースのバジェット量（budgeted amount）の供給を制御する。スケジューラ２３は、最初の可能な機会に保証バジェットのマージンに加えてより重要な保証バジェットを第１のタスク２４に与える（１５ａ）。上記スケジューラは、また、最初の可能な機会により少なく重要な保証バジェットを第２のタスク２５に与える（１５ａ）。
【００５５】
第１のタスク２４は、実行中のある時点において、第１のタスク２４がより重要な保証バジェットのみを用いて適切に実行し得ることを決定すると、保証バジェットのマージンを必要としないことをスケジューラ２３に明示的に知らせる（１６）。第１のタスク２４は、また、ＧＢＭを次に再要求する際に待つことができる動的期間をスケジューラ２３に知らせることも可能である（１６）。
【００５６】
このケースでは、スケジューラ２３は、最初の可能な機会に第１のタスク２４に保証バジェットのマージンを与えることを中断し、最初の可能な機会に条件付きの保証バジェットのマージンを第２のタスク２５に与えることを開始する。この後、スケジューラ２３は、条件付きの保証バジェットのマージンの解除の通知と実際の解除との間の期間（動的又は静的のより長い方）を含む条件付きの保証バジェットのマージンの授与を第２のタスク２５に知らせる（１７）。このとき、第２のタスク２５は、ＣＧＢＭの実際の解除が始まる前にＣＧＢＭの解除を通知されるであろうことを知るので、少なくとも所定の静的（又はより長い場合には動的）期間の間ＣＧＢＭを持つことを知るとともに、解除の知らせと実際の解除との間の期間が少なくとも上記所定の静的（又はより長い場合には動的）時間と同じだけ長いことを知る。
【００５７】
上記条件付きの保証バジェットのマージンは、第２のタスク２５により必要とされる場合におけるより少なく重要な保証バジェットに加えて第２のタスク２５により用いられるために取っておかれるリソース又は他の制限された可用性アイテムの量であるが、この量は、その他のところで、例えばより高い重要度の又はより重要なタスク２４によって必要とされない場合にのみ与えられる。
【００５８】
その後、第１のタスク２４は、実行中のある時点において保証バジェットのマージンも必要とすることを決定し、その場合には、第１のタスク２４は保証バジェットのマージンを必要とすることをスケジューラ２３に明示的に知らせる（１８）。この時点において、第１のタスク２４は、また、第１のタスク２４が実際にＧＢＭを受け取る前にＧＢＭを次に再要求する際に所定の静的期間よりも長い動的期間の間待つことができることをスケジューラ２３に知らせる。その後、スケジューラ２３は、（動的期間又は静的期間のうちのより長い方の後に）条件付きの保証バジェットのマージンが解除されることを第２のタスク２５に知らせる（１９）。その後、スケジューラ２３は、静的又は動的期間のうちのより長い方の終了後に第２のタスク２５に条件付きの保証バジェットのマージンを与えることを中断し、静的又は動的期間の終了後に第１のタスク２４に保証バジェットのマージンを与えることを開始する（１９１）。
【００５９】
アプリケーションマネージャ２１は、ＭＩＴの役割をあるタスクに割り当て、割り当てを解除する。上記アプリケーションマネージャは、また、ＬＩＴの役割を他のあるタスクに割り当て、割り当てを解除する。その後、アプリケーションマネージャ２１がイナクティブになり、割り当てメカニズム２２がアクティブになる。上記ＭＩＴ及びＬＩＴの役割が終了すると、アプリケーションマネージャ２１は再度アクティブになる一方で、割り当てメカニズム２２はイナクティブになる。割り当てメカニズム２２は、ＭＩＧＢ及びＧＢＭをＭＩＴに割り当て、これらの割り当てをＭＩＴに明示的に知らせる。割り当てメカニズム２２は、また、ＬＩＧＢ及びＣＧＢＭをＬＩＴに割り当て、これらの割り当てをＬＩＴに明示的に知らせる。割り当てメカニズム２２は、スケジューラ２３に予約を送り、これは、終了するように実行するスケジューラのプロセスを活性化する。スケジューラ２３は、上記割り当てメカニズムからＬＩＴ及びＭＩＴに関する予約コマンドを受け入れ、ＭＩＴに対してＭＩＧＢ及びＧＢＭを承諾し、またＬＩＴに対してＬＩＧＢを承諾する。その後、上記スケジューラは、スケジューリングアルゴリズムに従って作動する。スケジューラ２３は、ＭＩＴがもはやＧＢＭを必要としないというＭＩＴからのメッセージを受け取る。その後、上記スケジューラは、ＭＩＴに対してＭＩＧＢのみを承諾し、バジェットの増大をＬＩＴに知らせ、ＬＩＴに対してＬＩＧＢ及びＣＧＢＭを承諾する。続いて、スケジューラ２３は、ＭＩＴがＧＢＭを必要とするというＭＩＴからのメッセージを受け取り、その場合には、スケジューラ２３はＬＩＴにバジェットの減少を知らせる。
【００６０】
種々のプロセスの相互作用に関するより詳細な内容は、米国特許出願（出願人整理番号613652）において見付けられることができ、参照することにより図面を含む全部を本明細書において繰り返したかのように本明細書に取り込まれたものとする。
【００６１】
図３ないし図４に目を向けると、マルチタスクシステムにおける２つのタスクを制御する方法の一例の実施の形態３０のフローチャートが示されている。
【００６２】
ステップ３１において、より重要なタスクである第１のタスクが、より重要な保証バジェット及び保証バジェットのマージンについて明示的に知らされる。
【００６３】
ステップ３２において、より少なく重要なタスクである第２のタスクが、より少なく重要な保証バジェット、条件付きの保証バジェットのマージン及び条件付きの保証バジェットのマージンの回収が回収の通知に対して遅延する静的期間について明示的に知らされる。
【００６４】
ステップ３３において、保証バジェットのマージンに加えてより重要な保証バジェットが、最初の可能な機会に第1のタスクに与えられる。
【００６５】
ステップ３４において、より少なく重要な保証バジェットが、最初の可能な機会に第２のタスクに与えられる。
【００６６】
ステップ３５において、実行中のある時点において、第１のタスクがより重要な保証バジェットのみを用いてジョブを行うことを決定するとすぐに、スケジューラは、第1のタスクが、第1のタスクが保証バジェットのマージンを実際に必要とする前に保証バジェットのマージンを次に再要求する時を待つ動的期間とともに保証バジェットのマージンを必要としないことを明示的に知らされる。
【００６７】
ステップ３６において、保証バジェットのマージンは最初の可能な機会に第1のタスクにもはや与えられない。
【００６８】
ステップ４１において、最初の可能な機会に第２のタスクに条件付きの保証バジェットのマージンが与えられる。
【００６９】
ステップ４２において、第２のタスクは条件付きの保証バジェットのマージンが与えられることを知らされ、これは、条件付きの保証バジェットのマージンの解除の通知と実際の解除との間の遅延を説明する情報を含んでいる。
【００７０】
ステップ４３において、第１のタスクは、実行中のある時点において保証バジェットのマージンも必要であることを決定する。
【００７１】
ステップ４４において、スケジューラは、第1のタスクが、保証バジェットのマージンを受け取る前に待つことができる動的期間とともに保証バジェットのマージンを必要とすることを明示的に知らされる。
【００７２】
ステップ４５において、第２のタスクは、所定の静的又は動的期間のより長い方の後に条件付きの保証バジェットのマージンが解除されることを知らされる。
【００７３】
ステップ４６において、条件付きの保証バジェットのマージンは、静的又は動的期間のより長い方の終了後に第２のタスクにもはや与えられていない。
【００７４】
ステップ４７において、保証バジェットのマージンが第１のタスクに与えられる。
【００７５】
図５に目を向けると、図５には、本発明の更に他の観点による複数のプロセスを制御する方法の一例の実施の形態５０の時間の流れが示されている。図５に示されているプロセスの正確な順序は重要ではないが、時間の順序は幾つかのプロセスに関して重要である。そのように示されていない場合、相対的な順序は変更され得る。スタートすると（５１）、２つのプロセス系統に関して以下のプロセスが行われる。３つのプロセス系統の場合も同様のプロセスが行われ、その場合、相互作用は階層構造における任意の２つのプロセス間において同様である。
【００７６】
最初に、相対的な重要度が確立されなければならない。上記割り当てアルゴリズム又は幾つかの他のプロセスが、２つのタスクに重要度のレベルを与える。これらのタスクのうちの一方はより重要なタスクであるように与えられ（５２）、その場合、割り当てメカニズムはこのプロセスに重要度の指定を知らせる。これらのタスクのうちの他方はより少なく重要なタスクであるように与えられ（５４）、その場合、割り当てメカニズムはこのプロセスに重要度の指定を知らせる。タスクが重要度のレベルを与えられる順序は、必ずしも重要ではない。例えば、より低く重要なタスクが最初に与えられることが可能であり、従って、要素５４が要素５２の前に生じ得る。
【００７７】
一度相対的な重要度が与えられると、タスクのそれぞれはバジェットを明示的に知らされる。例えば、上記割り当てメカニズムは、より重要な保証バジェット及び保証バジェットのマージンについてＭＩＴに明示的に知らせる（５３）。上記割り当てメカニズムは、また、より少なく重要な保証バジェット及び条件付きの保証バジェットのマージンについてＬＩＴに明示的に知らせる（５５）。また、上記ＣＧＢＭの情報は、ＬＩＴがＣＧＢＭを持つことを予想する（静的な）経過時間を含む。プロセス５３とプロセス５５との順序は、それらのそれぞれが相対的な重要度レベルの割り当て後に生じなければならないこと以外は重要ではない。更に、上記ＭＩＴのバジェットを知らせることは、ＭＩＴの付与後、又は全ての重要度レベルが与えられた後すぐに生じ得る。ＬＩＴのバジェットを知らせることは、ＭＩＴのバジェットを知らせる前又は後に生じ得る。専らの要件は、バジェットを知らせることが相対的な重要度レベルの付与後にのみ行われることである。
【００７８】
ＭＩＴにバジェットについて知らせた後、上記スケジューラは、最初の可能な機会に保証バジェットのマージンに加えてより重要な保証バジェットをＭＩＴに与える（５６）。このＭＩＴのバジェットの供給は、より少なく重要な保証バジェットについてＬＩＴに知らせる前又は後に生じ、それを知らされるとすぐにＭＩＴがＭＩＴのバジェットを使い始めることができるようにＭＩＴのバジェットを知らせた直後に早く生じさえするかもしれない。
【００７９】
ＭＩＴのバジェットの供給に続いて、上記スケジューラは、最初の可能な機会により少なく重要な保証バジェットをＬＩＴに与える（５７）。これは、２つのタスクの相対的な重要度レベルのために通常ＭＩＴのバジェットの供給の後に行われるが、それを知らされるとすぐにＬＩＴがＬＩＴのバジェットを使い始めることができるようにＬＩＴのバジェットの知らせに続いて早く生じ得る。
【００８０】
実行中のある時点において、ＭＩＴは、より重要な保証バジェットのみを用いてジョブを行うことができることに気付き、その場合、ＭＩＴはスケジューラに動的な遅延時間とともにこの所見を知らせる（５８）。上記動的な遅延時間は、ＭＩＴがＧＢＭを実際に受け取る前にＧＢＭを再要求する際に待つことができる時間である。このステップ５８は、ＭＩＴのバジェットの供給後にのみ生じるが、その後、バジェット期間の任意の時点において生じ得る。プロセスを簡単にするために、スケジューラの知らせ及び所見は、単一の要素として示されているが、調子を合わせて分離されていてもよい。
【００８１】
上記ＭＩＴの所見について一度知らされると、スケジューラは最初の可能な機会にＭＩＴに保証バジェットのマージンを供給することを中断する（５９）。これは、できる限り早く保証バジェットのマージンの使用を可能にするためにスケジューラによる情報の受け取りの直後にたいてい生じるようである。この（すなわち、ＭＩＴが保証バジェットのマージンを必要としない）状態は永く存在しないかもしれないので、一度この状態がＭＩＴにより存在するように決定されると、システムは保証バジェットのマージンの使用をできる限り速くすべきである。この時、ＭＩＴは、また、ＧＢＭを次に再要求する際にＧＢＭを受け取る前に自発的に待つ動的期間に関してスケジューラに知らせる。
【００８２】
上記保証バジェットのマージンをＭＩＴに供給することを中断した後（５９）、スケジューラは最初の可能な機会に条件付きの保証バジェットのマージンをＬＩＴに供給することを開始する（６０）。その後、上記スケジューラは、ＬＩＴがＬＩＧＢを持つことを少なくとも予想し得る静的又は動的期間（のより長い方）とともにこの追加のバジェットの供給をＬＩＴに知らせる（６１）。好ましくは、この知らせ６１は、ＬＩＴが遅延することなく上乗せ分のバジェットを使用し始めることができるように条件付きの保証バジェットのマージンの供給（６０）後に行われるべきであるが、幾つかの状況では、これら２つの要素６０，６１は異なる順序で行われ得る。上記スケジューラは、また、ＭＩＴがＧＢＭを次に再要求する際にＧＢＭを受け取る前に自発的に待つ期間（静的又は動的のいずれか長い方）に関してＬＩＴに知らせる。
【００８３】
同じバジェット期間における実行中のある時点において、上記ＭＩＴは、保証バジェットのマージンも必要であることに気付く（６２）。これは、要素５８の後の任意の時間に生じ、その後上記要素（すなわち５９，６０及び６１）の幾つかにかかわる時に依存する。この新しい決定の後、ＭＩＴは、保証バジェットのマージンを必要とすることをスケジューラに明示的に知らせる（６２）。前述の通り、これら２つのサブステップは調子を合わせて別々に生じるが、簡略化の目的のために単一の要素として図示されている。上記保証バジェットのマージンを再要求するこのメッセージは、ＭＩＴがＧＢＭを受け取る前に自発的に待つ動的期間を含み得る。斜線が付された四角形は、ＬＩＴがＣＧＢＭを失い、ＣＧＢＭが実際に解除されることを知らされる静的期間を表している。この静的期間は、また、ＭＩＴがＧＢＭを必要とすることをスケジューラに知らせる瞬間から（又はこの決定がＭＩＴによりなされる瞬間から）ＧＢＭがＭＩＴに与えられる瞬間までであり得る。この期間の正確な開始と終了は、メッセージ間の遅延が小さいので重要ではない。重要な点は、所定の静的期間が知られ、種々のプロセスがこの静的期間を信頼し、従って定義上それぞれがどの時点又は行為から静的期間が開始され、終了するかを知ることである。
【００８４】
この情報を受け取った後、スケジューラは、所定の静的期間の後に（この時間の長さに関してその後ＬＩＴに知られるか又はその時点で知らされるかのいずれか一方）条件付きの保証バジェットのマージンが解除されることをＬＩＴに知らせる（６３）。代替として、ＬＩＴは、上記静的期間よりも長い、ＣＧＢＭが取り除かれる前にＬＩＴがＣＧＢＭを持つ他の期間（動的期間）を知らされ得る。典型的には、これは、リソースの不適切な使用を防止し、それに応じてＬＩＴが調節することを可能にするとともに円滑な移行を可能にするために、スケジューラがＬＩＴにこのバジェットのマージンを与えることを中断する前に生じるべきである。
【００８５】
その後、スケジューラは、動的又は静的期間のより長い方の終了後に条件付きの保証バジェットのマージンをＬＩＴに与えることを中断する（６４）。その後、スケジューラは、静的又は動的期間のうちのより長いほうの終了後に保証バジェットのマージンをＭＩＴに与えることを開始する（６５）。スケジューラは、リソースの不適切な使用を防止し、円滑な移行を可能にするために、ＭＩＴに上乗せ分のバジェットを与える前にＬＩＴに上乗せ分のバジェットを与えることをまず中断すべきである。
【００８６】
やがてある時点において、プロセスは終了するが（６６）、要素５８〜６５の数回の他の繰り返しが、アプリケーションの詳細に依存して生じ得る。また、ＭＩＴは、保証バジェットのマージンを必要としないこと（５８）を決して決定しない場合があるか、又はＭＩＴは、保証バジェットのマージンを必要としないこと（５８）を決定した後で保証バジェットのマージンを必要とすること（６２）を決して決定しない場合がある。
【００８７】
我々は、瞬時のバジェットの移行の要件（すなわち、ＬＩＴからのＣＧＢＭの即時の解除及びＭＩＴへのＧＢＭの瞬時の供給）が多くの状況において厳しすぎることを示した。我々は、ＣＧＢに関する方法及びシステムの両方の拡張を説明することにより先の手法を一般化した。本発明のアプリケーションは、追加のインターフェースの拡張機能のために追跡可能になる。
【００８８】
本明細書において種々の実施の形態が具体的に示され、説明されたが、本発明の改良及び変形例が、上記教示により有効範囲に含まれ、本発明の精神及び意図する範囲から逸脱することなく後に付されている特許請求の範囲内に存在することは理解されるであろう。例えば、ある用語及びプロトコルが用いられているが、本発明の範囲から逸脱することなく他の名称及びプロトコルが用いられ得る。また、この例は、特許請求の範囲により有効範囲に含まれる本発明の改良及び変形例を制限するように解釈されるべきではなく、可能な変形例の単なる説明である。
【図面の簡単な説明】
【００８９】
【図１】本発明の一観点によるシステムにおける複数のタスクを制御する方法の実施の形態の一例を示している。
【図２】本発明の他の観点によるオペレーティングシステム内の第２のタスクよりも重要度の高いレベルを割り当てられた、オペレーティングシステム内の第１のタスクを制御する装置の実施の形態の一例を示している。
【図３】本発明の更に他の観点によるマルチタスクプロセスの２つ又はそれ以上のタスクを制御する方法の実施の形態の一例を示している。
【図４】本発明の更に他の観点によるマルチタスクプロセスの２つ又はそれ以上のタスクを制御する方法の実施の形態の一例を示している。
【図５】本発明の更に他の観点によるオペレーティングシステムの実施の形態の一例を示している。
【図６】ＬＩＴのオーバーシュートを伴うしとやかではない質の劣化を示している。
【図７】バジェットの供給とＬＩＴからＭＩＴへの瞬時のバジェットの移行とを伴う時系列を示している。
【図１】
2007523423.tif 000004
【図２】
2007523423.tif 000005
【図３】
2007523423.tif 000006
【図４】
2007523423.tif 000007
【図５】
2007523423.tif 000008
【図６】
2007523423.tif 000009
【図７】
2007523423.tif 000010
【国際調査報告】
2007523423.tif 000011
2007523423.tif 000012
2007523423.tif 000013