JP3759040B2 - タスク・スケジューリングを改良する方法とシステム - Google Patents
タスク・スケジューリングを改良する方法とシステム Download PDFInfo
- Publication number
- JP3759040B2 JP3759040B2 JP2002006022A JP2002006022A JP3759040B2 JP 3759040 B2 JP3759040 B2 JP 3759040B2 JP 2002006022 A JP2002006022 A JP 2002006022A JP 2002006022 A JP2002006022 A JP 2002006022A JP 3759040 B2 JP3759040 B2 JP 3759040B2
- Authority
- JP
- Japan
- Prior art keywords
- task
- cost
- tasks
- time
- execution
- 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.)
- Expired - Fee Related
Links
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
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、一般にコンピュータ・システムに関し、特にタスクのスケジューリングを通じてリアルタイム・システムの動作を改良する方法、システム、コンピュータ・プログラム製品に関する。
【０００２】
【従来の技術】
リアルタイム・システムで実行されるタスクは、その実行特性（「リリース（release)特性」とも呼ばれる）の観点から極めて予測可能である、という傾向がある。特に、実行モデルの１つに、「周期的タスク・モデル」と呼ばれているタスク・モデルがある。この周期的タスク・モデルにおけるタスクの実行パターンは、タスクの周期とコストという２つの値の観点から予測可能である。あるタスクの周期とは、当該タスクの自然実行頻度の逆数で表わされる時間間隔のことである。あるタスクのコストとは、これも時間間隔であるが、当該タスクが１つの周期内で必要な作業を完了するのに要する最大時間のことである。例えば、５日ごとに１回実行するが、この５日間で２分間しか実行しないタスクを考える。この場合、このタスクの周期は５日であり、そのコストは２分間である。同様に、上記と同じシステムで、１０ミリ秒ごとに１回実行し、コストが１０マイクロ秒である別のタスクを考えることもできる。（第１番目の周期を除く）各周期は、先行する周期の終わりで直ちに開始する。意味的に正しい実行パターンは、次のようなものである。すなわち、タスクのインスタンスは、すべての周期の始めで実行可能状態になり、自分か呼ばれている周期が終わる少し前に自分の作業を完了する必要がある。タスクが呼び出されている周期の終わりは、締切と呼ばれている。
【０００３】
上述した周期的タスク・モデルに従う１組の周期的タスクの場合、すべてのタスクのすべての呼び出しが締切に間に合うか否かを計算するのは容易である。この判断（以下、実行可能性判断と呼ぶ）をなすのに、次に示す方程式を用いることができる。
【数１】
ただし、ＣI はタスクＩの実行コスト、ＴI はタスクＩの周期である（すべてのＩ＝１・・・Ｎにわたって同一の時間単位を用いる）。また、タスク間の優先順位は、周知の単調比率優先順位割り当て（rate-monotonic priority assignment: ＲＭＡ）アルゴリズムに従って割り当てる。（要するに、周期が短いタスクの場合、すべての締切が間に合うか否かをこのように判断するシステムの実行可能性は、当技術分野では公知である）。
【０００４】
大部分のリアルタイム・システムでは、予期される（スケジュール可能な）タスクの他に、実行可能であるけれども、スケジューリング・プロセスまたは上述した実行可能性判断プロセスにおいて考慮に入れることのできない別のエンティティが存在する。ここでは、これらのエンティティを「スケジュール不可エンティティ（non-schedulable entity: ＮＳＥ）」と呼ぶ。ＮＳＥは、実行時間を必要とすると共に、通常のシステムの動作にとって一般に不可欠のものである。ＮＳＥの一例として、ハードウェア割込みイベントがある。一般に、ハードウェア割込みなどのＮＳＥがいつ生じるのか（あるいは生じるのか否か）を予測することはできない。したがって、実行可能性アルゴリズムとスケジューリング・アルゴリズムは、通常、ＮＳＥを無視する。
【０００５】
しかしながら、ＮＳＥが実行する時に必要とする実行時間によって、タスクが締切を守れなくなる可能性がある。たとえ実行可能性アルゴリズムが実行可能であることを示したスケジュールに従ってタスクをディスパッチした場合であっても、そうである。この理由は、システムはスケジュール済みのタスクに優先してある種のＮＳＥ（例えばハードウェア割込み）を実行しうるからである。実行可能性アルゴリズムはＮＳＥを無視するから、スケジューリング・プロセスは、スケジュール済みのタスクの実行中に実行するすべてのＮＳＥの実行時間を、当該スケジュール済みのタスクに誤って割り当ててしまいがちである。例えば、特定のタスクのコストが２０ＡＴＵ（arbitrary time unit:任意時間単位）である場合、システムは、２０ＡＴＵの実行時間後に当該タスクが完了しているものと予期する。当該タスクが上記の時間内に完了していない場合（このことは２０ＡＴＵの間にＮＳＥが実行していた場合に成り立つ）、通常、システムはエラー状態を生成し、当該タスクは失敗する。
【０００６】
ここで、ＮＳＥの実行とスケジュール済みのタスクの実行とを区別しうるリアルタイム・システムがいくつか存在する、という点に留意する必要がある。実例としては、Ｒｅａｌ−ｔｉｍｅ ＭａｃｈとＬｉｎｕｘ／ＲＴがある。しかし、これらのシステムは、通常、実行可能性アルゴリズムにＮＳＥを含めていない。（様々な理論的理由から、実行可能性の計算でＮＳＥを無視することは、理由のある取り組みである。多くの場合、ＮＳＥは、全実行時間のほんのわずかな部分を占めるだけである。したがって、ＮＳＥは、システムの実行可能性に大した影響を与えない。しかし、これには、ＮＳＥは互いに無関係であることが知られており、それゆえ、ＮＳＥには累積効果がない、ということが言える必要がある。この仮定は、常に成り立つわけではない。また、例えば、ＮＳＥが割込みを無効にすると、ディスパッチャすなわちスケジューラは、プロセッサに十分な頻度でアクセスできなくなるので、システムが影響を受けていないことを保証することができなくなる）。
【０００７】
後述するように、ＮＳＥの発生に起因してタスクが予定の実行時間を超過した結果取り消されると、深刻な非効率が生じる。システム全体の実行可能性が保証される限り、タスクの取り消しを避け、完了するまでタスクを実行する可能性を増大させるのが望ましい。
【０００８】
「マルチメディア・コンピュータのオペレーティング・システムと方法」なる名称の米国特許第５６４０５６３号には、リアルタイム・システムにおいて、タスク・スケジューリング操作によって生じるプロセッサのオーバーヘッドを低減するために、開始時刻ではなく、締切（すなわち必要な終了時刻）に従ってタスクをスケジュールする手法が教示されている。しかし、この特許には、ＮＳＥが存在する場合における実行を処理する手法は教示されていない。
【０００９】
「プロジェクトを構成するタスクをスケジュールするコンピュータ実現方法」なる名称の米国特許第５４０８６６３号には、（プロジェクトの全所要時間すなわちプロジェクトのコストを含む）タスクの所要時間の効果が全体として不満足な場合におけるプロジェクト・スケジューリングを最適化する手法が教示されている。この特許では、タスクに割り当ててプロジェクトの用に供すべき資源を繰り返し調整して、プロジェクトの所要時間を短縮できるか否かを調べる。しかし、この特許にも、ＮＳＥが存在する場合における実行を処理する手法は教示されていない。特に、タスクが所定の時間間隔よりも長く実行を続けるのを可能にする手法が教示されていない。
【００１０】
上述した点から、従来技術の問題点を解消する改良されたタスク・スケジューリング手法が求められている。
【００１１】
【発明が解決しようとする課題】
本発明の目的は、タスク・スケジュール用の改良された手法を提供することである。
【００１２】
本発明の別の目的は、予定された実行時間を超過したタスクの実行を取り消すのを避けることのできる手法を提供することである。
【００１３】
本発明の別の目的は、システム全体が実行可能性を維持していることを保証しながら上記手法を実現することである。
【００１４】
【課題を解決するための手段】
上記目的を達成するために、本発明は、改良したタスク・スケジューリング手法を実現する方法、システム、およびコンピュータ・プログラム製品を提供する。
上記手法は、
各タスクが付随するコストおよび付随する締切を有する複数のタスクの実行が可能であるか否かを計算することと、
前記実行が可能であると計算された場合、各タスクについて付随するコストに追加の時間を付加して、各タスク用に改定されたコストを算出することと、
前記実行がもはや可能でないと計算されるまで、前記計算する手段および前記算出する手段の操作を反復的に繰り返すことと
を備えている。
この手法は、さらに、
前記反復的に繰り返すことの操作の後、前記改定されたコストをタスクの実行時間の上限として使用すること
を備えることができる。
【００１５】
本発明の一側面では、前記追加の時間がタスクに付随するコストの一定割合である。本発明の別の側面では、前記追加の時間が、一部のタスクについては零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合である。本発明のさらに別の側面では、前記算出することの最初の試行では、追加の時間がタスクに付随するコストの一定割合であり、残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である。本発明のさらに別の側面では、前記算出することの最初の試行では、一部のタスクについては追加の時間が零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合であり、残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である。
【００１６】
前記使用することは、さらに、
実行時に、タスク群のうちの特定のタスクがそれに付随するコストを超過しているか否かを判断することと、
もしそうである場合、
（１）前記特定のタスクに付随する締切までの残存時間、または、（２）前記特定のタスクの実行時間の上限、のうちの最小のものに到達するまで、前記特定のタスクが実行するのを許すことと
を備えることができる。
【００１７】
【発明の実施の形態】
図１は、本発明を実現することのできるコンピューティング装置を示す図である。コンピューティング装置１０には市販されている標準型のコンピューティング装置を用いるのが望ましい。コンピューティング装置１０は、ＣＰＵ（central processing unit)１２、メモリ１４、長期間記憶装置１６、そして（任意事項として）ネットワーク伝送機能１８を備えている。メモリ１４には主記憶装置および／または補助記憶装置を用いることができる。（「Ａおよび／またはＢ」は「ＡおよびＢ、Ａ、またはＢ」を表わす）。長期間記憶装置１６にはハード・ディスク駆動装置、ディスケット駆動装置、テープ駆動装置などのうちの少なくとも１つを用いることができる。本発明を実現するコンピュータ・プログラムの命令はメモリ１４（および／または長期間記憶装置１６）に格納するのが望ましい。
【００１８】
コンピューティング装置１０には、サーバ、メインフレーム、シングル・ユーザのワークステーションなど任意の型のコンピューティング装置を用いることができる。本発明の通常の使用では、コンピューティング装置１０上で、一連のリアルタイム・タスクが実行されている。
【００１９】
本発明を使用する際に依拠するシステムの中には、第１のコンピューティング装置１０で実行されているアプリケーションが第２のコンピューティング装置２０で実行されているアプリケーションと情報を交換するものがある。マシン相互間の伝送は、ネットワーク４０を使って行なわれる。（図１には図示してない）別の構成では、交換される情報は、単一のマシン内で１つのプロセスから別のプロセスに伝送することができる、あるいは、別の方法（例えば通信チャネルへの直接接続など）でマシン相互間で伝送することができる。
【００２０】
コンピューティング装置１０について述べたのと同様に、コンピューティング装置２０には市販されている標準のコンピューティング装置を用いるのが望ましい。コンピューティング装置２０も、ＣＰＵ２２、メモリ２４（これは主記憶装置および／または補助記憶装置でありうる）、少なくとも１つの長期間記憶装置２６、および、ネットワーク伝送機能２８を備えている。あるいは、コンピューティング装置２０は、ＲＯＭメモリ２４を使用してもよく、そして、長期間記憶装置２６を備えていなくてもよい。
【００２１】
ネットワーク４０には、ＬＡＮ（local area network）またはＷＡＮ（wide area network)を用いることができる。あるいは、他の任意の型のネットワーキング構成を用いてもよい。適切な通信ハードウェアとソフトウェアの他に、このようなネットワーキング構成も、当技術分野では公知である。
【００２２】
図２は、本発明を実現できるネットワーク構成４０の一例を示す図である。ネットワーク４０は、複数の個別ネットワーク、例えば無線ネットワーク４２やネットワーク４４を含むことができる。各ネットワークは、図１に関して説明した型の個別のコンピューティング装置を複数台備えることができる。さらに、当業者が認識しうるように、少なくとも１つのＬＡＮ（図示せず）を含めてもよい。この場合、ＬＡＮは、ホスト・プロセッサに接続されたインテリジェント・ワークステーションを複数台備えることができる。
【００２３】
さらに図２を参照する。ネットワーク４２、４４は、ゲートウェイ・コンピュータ４６やアプリケーション・サーバ４７（これらはデータ・リポジトリ４８にアクセスしうる）として、メインフレーム・コンピュータやサーバを備えることができる。ゲートウェイ・コンピュータ４６は、各ネットワーク４４への出入口として機能する。ゲートウェイ・コンピュータ４６は通信リンク５０ａによって別のネットワーク４２に接続されているのが望ましい。ゲートウェイ・コンピュータ４６は、通信リンク５０ｂ、５０ｃを使って少なくとも１つの有線装置または無線装置１０にも接続されているのが望ましい。ゲートウェイ・コンピュータ４６は、インターナショナル・ビジネス・マシーンズ・コーポレーションから入手できるＥＳＡ（Enterprise Systems Archtecture）／３７０コンピュータ、ＥＳＡ／３９０コンピュータなどを使って構築することができる。アプリケーションによっては、例えばＡＳ（Application System）／４００などの中型コンピュータを使うこともできる。（「ＥＳＡ／３７０」、「ＥＳＡ／３９０」、「ＡＳ／４００」はインターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標である）。
【００２４】
また、ゲートウェイ・コンピュータ４６は、記憶装置（例えばデータ・リポジトリ４８）に接続されていてもよい。さらに、ゲートウェイ・コンピュータ４６は、少なくとも１つのコンピューティング装置１０に直接にあるいは間接に接続されていてもよい。
【００２５】
当業者は、次の点を理解することができる。すなわち、ゲートウェイ・コンピュータ４６は、ネットワーク４２から地理的に大変離れた場所に設置してもよい。同様に、コンピューティング装置１０は、ネットワーク４２、４４から相当に離れた場所に置かれてもよい。例えば、ネットワーク４２をカリフォルニア州に設置し、ゲートウェイ・コンピュータ４６をテキサス州に設置し、少なくとも１つのコンピューティング装置１０をニューヨーク州に設置することができる。コンピューティング装置１０は、多数の等価な接続媒体、例えばセルラー電話、無線周波数ネットワーク、サテライト・ネットワークなどをまたいで、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol)などのネットワーキング・プロトコルを使って無線ネットワーク４２に接続することができる。無線ネットワーク４２はネットワーク接続５０ａを使ってゲートウェイ・コンピュータ４６に接続するのが望ましい。ネットワーク接続５０ａには、例えば、ＩＰ、Ｘ．２５、フレーム・リレー、ＩＳＤＮ（Integrated Services Digital Network:サービス総合ディジタル網) 、ＰＳＴＮ（Public SwitchedTelephone Network: 公衆交換電話網) などの上のＴＣＰまたはＵＤＰ（User Datagram Protocol）などがある。あるいは、コンピューティング装置１０は、ディジタル接続５０ｂ、５０ｃを使ってゲートウェイ・コンピュータ４６に直接に接続することができる。さらに、無線ネットワーク４２とネットワーク４４は、図２に示したものと同様の仕方で、少なくとも１つの別のネットワーク（図示せず）に接続することができる。
【００２６】
好適な実施形態では、本発明をコンピュータ・ソフトウェアで実現している。あるいは、本発明は、ハードウェアで、またはソフトウェアとハードウェアの組み合わせで実現することもできる。ソフトウェアで実現する実施形態では、図１に示すように、本発明を実現するソフトウェア・プログラミング・コードは、通常、ＣＤ−ＲＯＭやハード・ディスク駆動装置などある種の長期間記憶装置１６からＣＰＵ１２が取り出して、メモリ１４にロードする。（あるいは、ソフトウェア・プログラミング・コードの一部または全部を、ＲＯＭメモリ１４から直接に取り出すこともできる）。ソフトウェア・プログラミング・コードは、コンピューティング装置と共に使用する様々な公知の媒体、例えばディスケット、ハード・ディスク、ＣＤ−ＲＯＭなどの上に実現することもできる。また、ソフトウェア・プログラミング・コードは、このような媒体に載せて配付することができるし、あるいは、あるコンピューティング装置のメモリまたは記憶装置から、ある種のネットワークを介して、別のコンピューティング装置に、このような別のコンピューティング装置によって配付することができる。あるいは、ソフトウェア・プログラミング・コードは、長期間記憶装置１６から直接にアクセスすることもできる。メモリ中のソフトウェア・プログラミング・コードを物理媒体上に実現る手法と方法、および／または、当該ソフトウェア・プログラミング・コードをネットワークを介して配付する手法と方法は、周知であるので、ここではこれ以上説明しない。
【００２７】
ここで、ここでの説明はリアルタイム・システムの観点からのものであるが、これは説明目的のためであって限定を意図していない、という点に留意する必要がある。
【００２８】
本発明は、システム全体が実行可能であり続けていることを保証しながら、予定の実行時間（すなわちコスト）を超過したタスクの実行を取り消すのを避ける改良されたタスク・スケジューリング手法を提供するものである。特に、ＲＭＡ割り当てアルゴリズムを使う周期的タスクのシステムであって、使用率がＮ＊（２＊＊（１／Ｎ）−１）以下のものにおいて、本発明は、自分のコスト・パラメータよりも長く実行するタスクを呼び出すのを可能にする手法を提供するものである。コスト・パラメータは周期当たりの当該タスクの最大理論実行時間であり、決して超過してはならないものであるけれども、本発明では、ＮＳＥの存在下で効力を発揮する計算された拡張コストを用いている。
【００２９】
一例として、あるタスク「タスク１」の呼び出しコストが１０ＡＴＵ（任意時間単位）であり、タスク１の周期が１００ＡＴＵである、と仮定する。また、タスク１の実行中に、少なくとも１つのＮＳＥが合計１ＡＴＵの間実行する、と仮定する。さらに、スケジューラは、このＮＳＥ時間を別のものとして考慮せずに、それをタスク１の実行に割り当てる、と仮定する。この場合、スケジューラがタスク１用に１０ＡＴＵを累積した時に、タスク１は、実際には９ＡＴＵしか実行していない。したがって、その作業は完了できない可能性がある。従来技術によるシステムの多くは、タスク１がそのコスト・パラメータに到達したということを認識できない。したがって、何もしない。これらのシステムでは、タスク１は完了するまで実行し続ける。（これらのシステムは「撃ちてし止まん（run-to-block）」システムと呼ばれている）。このような長時間実行タスクが検査を受けずにすべて実行し続けると、システム全体の実行可能性は、極めて危険な状態になる。本発明は、タスク１がそのコスト・パラメータに到達したことを認識できるようなシステムを指向している。ここでは、そのようなシステムを「実行時間累積システム（execution time accumulating system）」と呼ぶ。本発明の手法を使うと、長時間実行タスクが実行し続けるのを許した場合に他のタスクが締切を守れなくなるか否かに関し、実行時間の決定を動的に行なうことが可能になる。さらに、本発明の手法は、他のタスクがすべて時間通りに完了するのを保証しながら、特定の長時間実行タスクに与えることのできる余分の時間を決定する方法を提供する。
【００３０】
次に、図３と図４を参照して、本発明の好適な実施形態を詳細に説明する。
【００３１】
図３に示す論理を使って、タスクが安全に実行しうるために追加する時間の上限を計算する。ここでは、この追加の時間を「拡張コスト（cost extension）」と呼ぶ。拡張コストの上限は、システムの実行可能性が保証されない値に到達するまで、漸増させながら計算する。好適な実施形態では、タスクのコストの一定割合を漸増的に加えることにより、各タスクごとに拡張コストを計算する。好適な実施形態では、この一定割合は、タスクのコスト・パラメータの１パーセントである。
【００３２】
図３の論理は、ブロック３００で、１からＮ（Ｎはシステム内のスケジュール可能なタスクの数）の拡張コスト値（図３ではＥi と表記）を零に初期化することにより開始する。各スケジュール可能なタスクは、拡張コスト、周期、締切の各値を格納する状態変数を備えているのが望ましい。本発明を使用する場合には、この状態変数にタスクの拡張コストに追加する値を格納する。
【００３３】
ブロック３１０で、各タスクのコストをその周期で除算したものを合計することにより、実行可能性分析（ＦＡ）の計算を実行する。次いで、ブロック３２０で、この合計値と図中の式（従来のシステムで使用している式と同じもの）とを比較して、すべてのタスクのすべての呼び出しが締切に間に合うか否かを判断する。ブロック３２０の試験の結果がＮｏの場合、システムは実行可能ではない。制御はブロック３６０に進む。図３の論理の初回の試行からブロック３６０に到達した場合、使用すべき拡張コストの値はすべて零である。したがって、システムは、従来技術の場合と同様に動作する。
【００３４】
ブロック３２０の試験の結果がＹｅｓの場合（すなわちシステムが実行可能である場合）、プロセスはブロック３３０に進む。ブロック３３０では、各タスクのコストの一定割合を計算する。この一定割合が１パーセントである場合、式（０．０１）Ｃi は、この試行で加算すべき追加の時間を定めている。この追加の時間を、各タスクの前回計算した拡張コストＥi に加算する。加算した結果を、各タスクのコスト・パラメータＣi に加算する。そして、その合計値を、各タスクの周期Ｔi で除算する。このプロセスを１からＮのスケジュール可能なタスクの各々について繰り返して、システムの新たな実行可能性分析（ＦＡ）値を定める。その後、ブロック３４０で、得られた結果と図中に示す使用率の式とを比較して、すべてのタスクのすべての呼び出しが締切に間に合うか否かを判断する。この試験の結果がＹｅｓの場合、ブロック３５０で、１からＮのスケジュール可能なタスクの各々のコストについて、新たな漸増拡張コストを生成する。次いで、制御はブロック３３０に戻って実行可能性分析（ＦＡ）計算を繰り返す。ブロック３４０の試験の結果がＮｏの場合（すなわち、拡張コストの現在の計算の後、システムがもはや実行可能でない場合）、制御はブロック３６０に進む。制御がブロック３６０に到達した場合、ブロック３６０に示すように、各タスクの拡張コストの上限は、既に発見されており、その値はＥi に格納されている（ただし、各タスクは各回の拡張コストの計算における一定割合として同一の値を用いるものと仮定している）。以上で、図３のプロセスは完了する。
【００３５】
図３に示す論理の別の実施形態では、一定割合の値として別の値を用いている。さらに別の実施形態では、拡張コストは、一部のタスクに対してだけ計算し、残りのタスクに対しては計算しない。例えば、長時間実行タスクには拡張を許すが、短いタスクには許さない（これは、長時間実行タスクは完了しないとシステム資源の観点から短いタスクよりも高くつく、という原理に基づいている）。この場合、短いタスクの拡張コストは零である、と考えられる。さらに別の実施形態では、漸増計算プロセスの間に一定割合として同一でない値を用いている。このアプローチの一例として、長時間実行タスクには短いタスクよりも大きな一定割合値を割り当てる。例えば、長時間実行タスクには２パーセントを使用し、短いタスクには１パーセントを使用する（この結果、長時間実行タスクには短いタスクよりも大きな拡張コストが割り当てられる）。あるいは、別の実施形態では、（ブロック３３０に示したように）タスクのコストに基づかずに、計算したての拡張コストに基づいて、各試行において追加の時間を計算している。この結果、長時間実行タスクは、幾何数列を使って拡張される。上述したこれらの実施形態を取り扱うのに図３に示す論理をどのように変更したらよいかは、当業者にとって明らかである。
【００３６】
図４の論理は、実行時に、特定の周期において呼び出されている間にコスト・パラメータを超過したタスクが安全に実行し続けうるか否かを判断すると共に、続けうる場合の継続期間を判断するのに使う。各タスクの拡張コストを知ることにより、スケジューラは、他のタスクの実行に影響を与えることなく、この判断をなすことができる。このように、リアルタイム・システムは、ＮＳＥの存在下で、本発明の教示を使わない従来技術の場合よりも長い時間間隔にわたって、通常の状態（すなわち、すべてのタスクが締切を守ることのできる状態）を維持することができる。したがって、たとえＮＳＥがあるタスクの実行時間の一部を消費したとしても、当該タスクは完了するまで実行することができる。拡張コストは、コスト・オーバーラン（超過）が生じているのが検出されると配分される（したがって、タスクの実行時間を累積しない、従来技術の「撃ちてし止まん」システムには、本発明は無用であると思われる）。次に、本発明の好適な実施形態を使用したときにコスト・オーバーランを処理する仕方を、図４の論理を参照して説明する。
【００３７】
実行中のタスクに対してコスト・オーバーランが検出されると、制御はブロック４００に至る。次いで、ブロック４１０で、このタスクは拡張コスト値（これは例えば図３の処理中に状態変数に格納される）を有するか否かを検査する。Ｎｏの場合、タスクの実行は拡張されず、制御をブロック４８０に進め従来技術の場合と同様に通常のコスト・オーバーラン・ハンドラを呼び出す。オーバーラン処理が完了すると、図４のこの呼び出しは完了する。
【００３８】
ブロック４１０の検査の結果がＹｅｓの場合、ブロック４２０で処理を継続する。ブロック４２０では、拡張コスト（Ｅi ）の最小値と、（図４中に「Ｄ」で示す）締切までの残存時間とを計算する。次いで、ブロック４３０で、拡張コストがＤよりも小さいか否かを検査する。Ｙｅｓならば、ブロック４４０で、当該タスクはその拡張コストの間実行し続けることを許される。図３を参照して説明したように、この拡張コストとは、当該タスクが他のスケジュール可能なタスクに影響を与えることなく実行し続けうる時間の上限のことである。当該タスクがこの追加の時間（拡張コスト）の間実行し続けた後、制御はブロック４６０に進む。ブロック４６０では、当該タスクが未（いま）だに実行しているか否かを検査する。Ｙｅｓの場合、当該タスクの締切は守られなかったことを意味する（すなわち、当該タスクがシステム中で他のタスクに影響を与えることなく実行を完了する、ということを保証できない）。したがって、ブロック４７０で締切ミス・ハンドラを呼び出す。締切ミス・ハンドラが（本発明の一部を形成しない従来技術の手法を使って）その処理を完了したら、コスト・オーバーラン・ハンドラを呼び出す（ブロック４８０）。必要な場合には、コスト・オーバーラン処理に、本発明に従う拡張コストを有するタスクが未だにコストをオーバーランしている状況を処理する論理を付加することができる。例えば、拡張コスト内に完了できないようなコスト超過タスクに関する統計をとることができる。
以上で当該タスクに関する図４の処理は終了する。
【００３９】
ブロック４６０の検査の結果がＮｏならば、当該タスクは拡張コストの間に実行を完了したことを意味する。好適な実施形態では、ブロック４８０でコスト・オーバーラン・ハンドラを呼び出す。以上で当該タスクに関する図４の処理は終了する。
【００４０】
ブロック４３０に戻り、現在のタスクの締切までの残存時間が当該タスクの拡張コスト以下の場合、ブロック４５０で、当該タスクが締切に至るまで実行し続けるのを許す。次いで、ブロック４６０で、当該タスクが別のオーバーラン状況に遭遇しているか否かを検査する（すなわち、当該タスクが締切に到達したのに完了していないか否かを検査する）。Ｙｅｓならば、ブロック４７０について上述したように、締切ミス・ハンドラを呼び出す。この処理の後、ブロック４８０について上述したように、コスト・オーバーラン・ハンドラを呼び出す。また、ブロック４６０の検査の結果がＮｏの場合（当該タスクが締切に間に合った場合）、ブロック４８０でコスト・オーバーラン・ハンドラを呼び出す。
以上で図４の処理は終了する。
【００４１】
上述したように、本発明は、システム全体の中で他のタスクに影響を与えることなく、実行時間累積システムにおいてコスト見積もりをオーバーランしたタスクの実行時間を安全に拡張するための極めて効率的な手法を提供するものである。この手法は、複雑なスケジューラを使用している多数の環境において役立つものと思われる。上記環境には、例えばリアルタイム・システムを実現するのにReal-Time Specification for Java（商標）を使っているような環境がある。（「Java」はサン・マイクロシステムズ社の商標である）。本発明を使用すると、タスクの締切を有する実行環境において柔軟性が増す。この結果、そのようなシステムを設計・管理するのが容易になると共に、操作が効率的になる。
【００４２】
以上、本発明の好適な実施形態を説明したが、この実施形態に対する変形と変更は、いったん本発明の基本概念を学んだ当業者にとって容易に想到しうるものである。したがって、特許請求の範囲は、好適な実施形態と、本発明の本旨と範囲の内にあるようなすべての変形および変更とを含むように解釈すべきである。
【００４３】
まとめとして以下の事項を開示する。
（１）タスク・スケジューリングを改良するコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品は少なくとも１つのコンピュータ読み取り可能な媒体に組み込まれており、
各タスクが付随するコストおよび付随する締切を有する複数のタスクの実行が可能であるか否かを計算するコンピュータ読み取り可能なプログラム・コード手段と、
前記実行が可能であると計算された場合、各タスクについて付随するコストに追加の時間を付加して、各タスク用に改定されたコストを算出するコンピュータ読み取り可能なプログラム・コード手段と、
前記実行がもはや可能でないと計算されるまで、前記計算するコンピュータ読み取り可能なプログラム・コード手段、および前記算出するコンピュータ読み取り可能なプログラム・コード手段の操作を反復的に繰り返すコンピュータ読み取り可能なプログラム・コード手段と、
前記反復的に繰り返すコンピュータ読み取り可能なプログラム・コード手段の操作の後、前記改定されたコストをタスクの実行時間の上限として使用するコンピュータ読み取り可能なプログラム・コード手段と
を備えたコンピュータ・プログラム製品。
（２）前記追加の時間がタスクに付随するコストの一定割合である、
上記（１）に記載のコンピュータ・プログラム製品。
（３）前記追加の時間が、一部のタスクについては零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合である、
上記（１）に記載のコンピュータ・プログラム製品。
（４）前記算出するコンピュータ読み取り可能なプログラム・コード手段の最初の試行では、追加の時間がタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（１）に記載のコンピュータ・プログラム製品。
（５）前記算出するコンピュータ読み取り可能なプログラム・コード手段の最初の試行では、一部のタスクについては追加の時間が零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（１）に記載のコンピュータ・プログラム製品。
（６）前記使用するコンピュータ読み取り可能なプログラム・コード手段が、実行時に、タスク群のうちの特定のタスクがそれに付随するコストを超過しているか否かを判断するコンピュータ読み取り可能なプログラム・コード手段と、
もしそうである場合、
（１）前記特定のタスクに付随する締切までの残存時間、または、（２）前記特定のタスクの実行時間の上限、のうちの最小のものに到達するまで、前記特定のタスクが実行するのを許すコンピュータ読み取り可能なプログラム・コード手段と
を備えている、
上記（１）に記載のコンピュータ・プログラム製品。
（７）タスク・スケジューリングを改良するシステムであって、
各タスクが付随するコストおよび付随する締切を有する複数のタスクの実行が可能であるか否かを計算する手段と、
前記実行が可能であると計算された場合、各タスクについて付随するコストに追加の時間を付加して、各タスク用に改定されたコストを算出する手段と、
前記実行がもはや可能でないと計算されるまで、前記計算する手段および前記算出する手段の操作を反復的に繰り返す手段と
備えたシステム。
（８）さらに、
前記反復的に繰り返す手段の操作の後、前記改定されたコストをタスクの実行時間の上限として使用する手段
を備えた、
上記（７）に記載のシステム。
（９）前記追加の時間がタスクに付随するコストの一定割合である、
上記（７）に記載のシステム。
（１０）前記追加の時間が、一部のタスクについては零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合である、
上記（７）に記載のシステム。
（１１）前記算出する手段の最初の試行では、追加の時間がタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（７）に記載のシステム。
（１２）前記算出する手段の最初の試行では、一部のタスクについては追加の時間が零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（７）に記載のシステム。
（１３）前記使用する手段が、
実行時に、タスク群のうちの特定のタスクがそれに付随するコストを超過しているか否かを判断する手段と、
もしそうである場合、
（１）前記特定のタスクに付随する締切までの残存時間、または、（２）前記特定のタスクの実行時間の上限、のうちの最小のものに到達するまで、前記特定のタスクが実行するのを許す手段と
を備えている、
上記（７）に記載のシステム。
（１４）タスク・スケジューリングを改良する方法であって、
各タスクが付随するコストおよび付随する締切を有する複数のタスクの実行が可能であるか否かを計算するステップと、
前記実行が可能であると計算された場合、各タスクについて付随するコストに追加の時間を付加して、各タスク用に改定されたコストを算出するステップと、前記実行がもはや可能でないと計算されるまで、前記計算する手段および前記算出する手段の操作を反復的に繰り返すステップと
備えた方法。
（１５）さらに、
前記反復的に繰り返す手段の操作の後、前記改定されたコストをタスクの実行時間の上限として使用するステップ
を備えた、
上記（１４）に記載の方法。
（１６）前記追加の時間がタスクに付随するコストの一定割合である、
上記（１４）に記載の方法。
（１７）前記追加の時間が、一部のタスクについては零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合である、
上記（１４）に記載の方法。
（１８）前記算出するステップの最初の試行では、追加の時間がタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（１４）に記載の方法。
（１９）前記算出するステップの最初の試行では、一部のタスクについては追加の時間が零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（１４）に記載の方法。
（２０）前記使用するステップが、
実行時に、タスク群のうちの特定のタスクがそれに付随するコストを超過しているか否かを判断するステップと、
もしそうである場合、
（１）前記特定のタスクに付随する締切までの残存時間、または、（２）前記特定のタスクの実行時間の上限、のうちの最小のものに到達するまで、前記特定のタスクが実行するのを許すステップと
を備えている、
上記（１４）に記載の方法。
【図面の簡単な説明】
【図１】 本発明を実現することのできるコンピューティング装置のブロック図である。
【図２】 本発明を実現することのできるネットワーク化されたコンピューティング環境を示す図である。
【図３】 本発明の改良された実行可能性アルゴリズムを実現するのに使用しうる論理の好適な実施形態のフローチャートを示す図である。
【図４】 本発明に従い実行時にタスクの実行をモニタするのに使用しうる論理の好適な実施形態のフローチャートを示す図である。
【符号の説明】
１０ コンピューティング装置
１２ ＣＰＵ
１４ メモリ
１６ 長期間記憶装置
１８ ネットワーク電送機能
２０ コンピューティング装置
２２ ＣＰＵ
２４ メモリ
２６ 長期間記憶装置
２８ ネットワーク伝送機能
４０ ネットワーク
４２ 無線ネットワーク
４４ ネットワーク
４６ ゲートウェイ・コンピュータ
４７ アプリケーション・サーバ
４８ データ・リポジトリ
５０ａ、５０ｂ、５０ｃ 通信リンク
【発明の属する技術分野】
本発明は、一般にコンピュータ・システムに関し、特にタスクのスケジューリングを通じてリアルタイム・システムの動作を改良する方法、システム、コンピュータ・プログラム製品に関する。
【０００２】
【従来の技術】
リアルタイム・システムで実行されるタスクは、その実行特性（「リリース（release)特性」とも呼ばれる）の観点から極めて予測可能である、という傾向がある。特に、実行モデルの１つに、「周期的タスク・モデル」と呼ばれているタスク・モデルがある。この周期的タスク・モデルにおけるタスクの実行パターンは、タスクの周期とコストという２つの値の観点から予測可能である。あるタスクの周期とは、当該タスクの自然実行頻度の逆数で表わされる時間間隔のことである。あるタスクのコストとは、これも時間間隔であるが、当該タスクが１つの周期内で必要な作業を完了するのに要する最大時間のことである。例えば、５日ごとに１回実行するが、この５日間で２分間しか実行しないタスクを考える。この場合、このタスクの周期は５日であり、そのコストは２分間である。同様に、上記と同じシステムで、１０ミリ秒ごとに１回実行し、コストが１０マイクロ秒である別のタスクを考えることもできる。（第１番目の周期を除く）各周期は、先行する周期の終わりで直ちに開始する。意味的に正しい実行パターンは、次のようなものである。すなわち、タスクのインスタンスは、すべての周期の始めで実行可能状態になり、自分か呼ばれている周期が終わる少し前に自分の作業を完了する必要がある。タスクが呼び出されている周期の終わりは、締切と呼ばれている。
【０００３】
上述した周期的タスク・モデルに従う１組の周期的タスクの場合、すべてのタスクのすべての呼び出しが締切に間に合うか否かを計算するのは容易である。この判断（以下、実行可能性判断と呼ぶ）をなすのに、次に示す方程式を用いることができる。
【数１】
【０００４】
大部分のリアルタイム・システムでは、予期される（スケジュール可能な）タスクの他に、実行可能であるけれども、スケジューリング・プロセスまたは上述した実行可能性判断プロセスにおいて考慮に入れることのできない別のエンティティが存在する。ここでは、これらのエンティティを「スケジュール不可エンティティ（non-schedulable entity: ＮＳＥ）」と呼ぶ。ＮＳＥは、実行時間を必要とすると共に、通常のシステムの動作にとって一般に不可欠のものである。ＮＳＥの一例として、ハードウェア割込みイベントがある。一般に、ハードウェア割込みなどのＮＳＥがいつ生じるのか（あるいは生じるのか否か）を予測することはできない。したがって、実行可能性アルゴリズムとスケジューリング・アルゴリズムは、通常、ＮＳＥを無視する。
【０００５】
しかしながら、ＮＳＥが実行する時に必要とする実行時間によって、タスクが締切を守れなくなる可能性がある。たとえ実行可能性アルゴリズムが実行可能であることを示したスケジュールに従ってタスクをディスパッチした場合であっても、そうである。この理由は、システムはスケジュール済みのタスクに優先してある種のＮＳＥ（例えばハードウェア割込み）を実行しうるからである。実行可能性アルゴリズムはＮＳＥを無視するから、スケジューリング・プロセスは、スケジュール済みのタスクの実行中に実行するすべてのＮＳＥの実行時間を、当該スケジュール済みのタスクに誤って割り当ててしまいがちである。例えば、特定のタスクのコストが２０ＡＴＵ（arbitrary time unit:任意時間単位）である場合、システムは、２０ＡＴＵの実行時間後に当該タスクが完了しているものと予期する。当該タスクが上記の時間内に完了していない場合（このことは２０ＡＴＵの間にＮＳＥが実行していた場合に成り立つ）、通常、システムはエラー状態を生成し、当該タスクは失敗する。
【０００６】
ここで、ＮＳＥの実行とスケジュール済みのタスクの実行とを区別しうるリアルタイム・システムがいくつか存在する、という点に留意する必要がある。実例としては、Ｒｅａｌ−ｔｉｍｅ ＭａｃｈとＬｉｎｕｘ／ＲＴがある。しかし、これらのシステムは、通常、実行可能性アルゴリズムにＮＳＥを含めていない。（様々な理論的理由から、実行可能性の計算でＮＳＥを無視することは、理由のある取り組みである。多くの場合、ＮＳＥは、全実行時間のほんのわずかな部分を占めるだけである。したがって、ＮＳＥは、システムの実行可能性に大した影響を与えない。しかし、これには、ＮＳＥは互いに無関係であることが知られており、それゆえ、ＮＳＥには累積効果がない、ということが言える必要がある。この仮定は、常に成り立つわけではない。また、例えば、ＮＳＥが割込みを無効にすると、ディスパッチャすなわちスケジューラは、プロセッサに十分な頻度でアクセスできなくなるので、システムが影響を受けていないことを保証することができなくなる）。
【０００７】
後述するように、ＮＳＥの発生に起因してタスクが予定の実行時間を超過した結果取り消されると、深刻な非効率が生じる。システム全体の実行可能性が保証される限り、タスクの取り消しを避け、完了するまでタスクを実行する可能性を増大させるのが望ましい。
【０００８】
「マルチメディア・コンピュータのオペレーティング・システムと方法」なる名称の米国特許第５６４０５６３号には、リアルタイム・システムにおいて、タスク・スケジューリング操作によって生じるプロセッサのオーバーヘッドを低減するために、開始時刻ではなく、締切（すなわち必要な終了時刻）に従ってタスクをスケジュールする手法が教示されている。しかし、この特許には、ＮＳＥが存在する場合における実行を処理する手法は教示されていない。
【０００９】
「プロジェクトを構成するタスクをスケジュールするコンピュータ実現方法」なる名称の米国特許第５４０８６６３号には、（プロジェクトの全所要時間すなわちプロジェクトのコストを含む）タスクの所要時間の効果が全体として不満足な場合におけるプロジェクト・スケジューリングを最適化する手法が教示されている。この特許では、タスクに割り当ててプロジェクトの用に供すべき資源を繰り返し調整して、プロジェクトの所要時間を短縮できるか否かを調べる。しかし、この特許にも、ＮＳＥが存在する場合における実行を処理する手法は教示されていない。特に、タスクが所定の時間間隔よりも長く実行を続けるのを可能にする手法が教示されていない。
【００１０】
上述した点から、従来技術の問題点を解消する改良されたタスク・スケジューリング手法が求められている。
【００１１】
【発明が解決しようとする課題】
本発明の目的は、タスク・スケジュール用の改良された手法を提供することである。
【００１２】
本発明の別の目的は、予定された実行時間を超過したタスクの実行を取り消すのを避けることのできる手法を提供することである。
【００１３】
本発明の別の目的は、システム全体が実行可能性を維持していることを保証しながら上記手法を実現することである。
【００１４】
【課題を解決するための手段】
上記目的を達成するために、本発明は、改良したタスク・スケジューリング手法を実現する方法、システム、およびコンピュータ・プログラム製品を提供する。
上記手法は、
各タスクが付随するコストおよび付随する締切を有する複数のタスクの実行が可能であるか否かを計算することと、
前記実行が可能であると計算された場合、各タスクについて付随するコストに追加の時間を付加して、各タスク用に改定されたコストを算出することと、
前記実行がもはや可能でないと計算されるまで、前記計算する手段および前記算出する手段の操作を反復的に繰り返すことと
を備えている。
この手法は、さらに、
前記反復的に繰り返すことの操作の後、前記改定されたコストをタスクの実行時間の上限として使用すること
を備えることができる。
【００１５】
本発明の一側面では、前記追加の時間がタスクに付随するコストの一定割合である。本発明の別の側面では、前記追加の時間が、一部のタスクについては零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合である。本発明のさらに別の側面では、前記算出することの最初の試行では、追加の時間がタスクに付随するコストの一定割合であり、残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である。本発明のさらに別の側面では、前記算出することの最初の試行では、一部のタスクについては追加の時間が零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合であり、残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である。
【００１６】
前記使用することは、さらに、
実行時に、タスク群のうちの特定のタスクがそれに付随するコストを超過しているか否かを判断することと、
もしそうである場合、
（１）前記特定のタスクに付随する締切までの残存時間、または、（２）前記特定のタスクの実行時間の上限、のうちの最小のものに到達するまで、前記特定のタスクが実行するのを許すことと
を備えることができる。
【００１７】
【発明の実施の形態】
図１は、本発明を実現することのできるコンピューティング装置を示す図である。コンピューティング装置１０には市販されている標準型のコンピューティング装置を用いるのが望ましい。コンピューティング装置１０は、ＣＰＵ（central processing unit)１２、メモリ１４、長期間記憶装置１６、そして（任意事項として）ネットワーク伝送機能１８を備えている。メモリ１４には主記憶装置および／または補助記憶装置を用いることができる。（「Ａおよび／またはＢ」は「ＡおよびＢ、Ａ、またはＢ」を表わす）。長期間記憶装置１６にはハード・ディスク駆動装置、ディスケット駆動装置、テープ駆動装置などのうちの少なくとも１つを用いることができる。本発明を実現するコンピュータ・プログラムの命令はメモリ１４（および／または長期間記憶装置１６）に格納するのが望ましい。
【００１８】
コンピューティング装置１０には、サーバ、メインフレーム、シングル・ユーザのワークステーションなど任意の型のコンピューティング装置を用いることができる。本発明の通常の使用では、コンピューティング装置１０上で、一連のリアルタイム・タスクが実行されている。
【００１９】
本発明を使用する際に依拠するシステムの中には、第１のコンピューティング装置１０で実行されているアプリケーションが第２のコンピューティング装置２０で実行されているアプリケーションと情報を交換するものがある。マシン相互間の伝送は、ネットワーク４０を使って行なわれる。（図１には図示してない）別の構成では、交換される情報は、単一のマシン内で１つのプロセスから別のプロセスに伝送することができる、あるいは、別の方法（例えば通信チャネルへの直接接続など）でマシン相互間で伝送することができる。
【００２０】
コンピューティング装置１０について述べたのと同様に、コンピューティング装置２０には市販されている標準のコンピューティング装置を用いるのが望ましい。コンピューティング装置２０も、ＣＰＵ２２、メモリ２４（これは主記憶装置および／または補助記憶装置でありうる）、少なくとも１つの長期間記憶装置２６、および、ネットワーク伝送機能２８を備えている。あるいは、コンピューティング装置２０は、ＲＯＭメモリ２４を使用してもよく、そして、長期間記憶装置２６を備えていなくてもよい。
【００２１】
ネットワーク４０には、ＬＡＮ（local area network）またはＷＡＮ（wide area network)を用いることができる。あるいは、他の任意の型のネットワーキング構成を用いてもよい。適切な通信ハードウェアとソフトウェアの他に、このようなネットワーキング構成も、当技術分野では公知である。
【００２２】
図２は、本発明を実現できるネットワーク構成４０の一例を示す図である。ネットワーク４０は、複数の個別ネットワーク、例えば無線ネットワーク４２やネットワーク４４を含むことができる。各ネットワークは、図１に関して説明した型の個別のコンピューティング装置を複数台備えることができる。さらに、当業者が認識しうるように、少なくとも１つのＬＡＮ（図示せず）を含めてもよい。この場合、ＬＡＮは、ホスト・プロセッサに接続されたインテリジェント・ワークステーションを複数台備えることができる。
【００２３】
さらに図２を参照する。ネットワーク４２、４４は、ゲートウェイ・コンピュータ４６やアプリケーション・サーバ４７（これらはデータ・リポジトリ４８にアクセスしうる）として、メインフレーム・コンピュータやサーバを備えることができる。ゲートウェイ・コンピュータ４６は、各ネットワーク４４への出入口として機能する。ゲートウェイ・コンピュータ４６は通信リンク５０ａによって別のネットワーク４２に接続されているのが望ましい。ゲートウェイ・コンピュータ４６は、通信リンク５０ｂ、５０ｃを使って少なくとも１つの有線装置または無線装置１０にも接続されているのが望ましい。ゲートウェイ・コンピュータ４６は、インターナショナル・ビジネス・マシーンズ・コーポレーションから入手できるＥＳＡ（Enterprise Systems Archtecture）／３７０コンピュータ、ＥＳＡ／３９０コンピュータなどを使って構築することができる。アプリケーションによっては、例えばＡＳ（Application System）／４００などの中型コンピュータを使うこともできる。（「ＥＳＡ／３７０」、「ＥＳＡ／３９０」、「ＡＳ／４００」はインターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標である）。
【００２４】
また、ゲートウェイ・コンピュータ４６は、記憶装置（例えばデータ・リポジトリ４８）に接続されていてもよい。さらに、ゲートウェイ・コンピュータ４６は、少なくとも１つのコンピューティング装置１０に直接にあるいは間接に接続されていてもよい。
【００２５】
当業者は、次の点を理解することができる。すなわち、ゲートウェイ・コンピュータ４６は、ネットワーク４２から地理的に大変離れた場所に設置してもよい。同様に、コンピューティング装置１０は、ネットワーク４２、４４から相当に離れた場所に置かれてもよい。例えば、ネットワーク４２をカリフォルニア州に設置し、ゲートウェイ・コンピュータ４６をテキサス州に設置し、少なくとも１つのコンピューティング装置１０をニューヨーク州に設置することができる。コンピューティング装置１０は、多数の等価な接続媒体、例えばセルラー電話、無線周波数ネットワーク、サテライト・ネットワークなどをまたいで、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol)などのネットワーキング・プロトコルを使って無線ネットワーク４２に接続することができる。無線ネットワーク４２はネットワーク接続５０ａを使ってゲートウェイ・コンピュータ４６に接続するのが望ましい。ネットワーク接続５０ａには、例えば、ＩＰ、Ｘ．２５、フレーム・リレー、ＩＳＤＮ（Integrated Services Digital Network:サービス総合ディジタル網) 、ＰＳＴＮ（Public SwitchedTelephone Network: 公衆交換電話網) などの上のＴＣＰまたはＵＤＰ（User Datagram Protocol）などがある。あるいは、コンピューティング装置１０は、ディジタル接続５０ｂ、５０ｃを使ってゲートウェイ・コンピュータ４６に直接に接続することができる。さらに、無線ネットワーク４２とネットワーク４４は、図２に示したものと同様の仕方で、少なくとも１つの別のネットワーク（図示せず）に接続することができる。
【００２６】
好適な実施形態では、本発明をコンピュータ・ソフトウェアで実現している。あるいは、本発明は、ハードウェアで、またはソフトウェアとハードウェアの組み合わせで実現することもできる。ソフトウェアで実現する実施形態では、図１に示すように、本発明を実現するソフトウェア・プログラミング・コードは、通常、ＣＤ−ＲＯＭやハード・ディスク駆動装置などある種の長期間記憶装置１６からＣＰＵ１２が取り出して、メモリ１４にロードする。（あるいは、ソフトウェア・プログラミング・コードの一部または全部を、ＲＯＭメモリ１４から直接に取り出すこともできる）。ソフトウェア・プログラミング・コードは、コンピューティング装置と共に使用する様々な公知の媒体、例えばディスケット、ハード・ディスク、ＣＤ−ＲＯＭなどの上に実現することもできる。また、ソフトウェア・プログラミング・コードは、このような媒体に載せて配付することができるし、あるいは、あるコンピューティング装置のメモリまたは記憶装置から、ある種のネットワークを介して、別のコンピューティング装置に、このような別のコンピューティング装置によって配付することができる。あるいは、ソフトウェア・プログラミング・コードは、長期間記憶装置１６から直接にアクセスすることもできる。メモリ中のソフトウェア・プログラミング・コードを物理媒体上に実現る手法と方法、および／または、当該ソフトウェア・プログラミング・コードをネットワークを介して配付する手法と方法は、周知であるので、ここではこれ以上説明しない。
【００２７】
ここで、ここでの説明はリアルタイム・システムの観点からのものであるが、これは説明目的のためであって限定を意図していない、という点に留意する必要がある。
【００２８】
本発明は、システム全体が実行可能であり続けていることを保証しながら、予定の実行時間（すなわちコスト）を超過したタスクの実行を取り消すのを避ける改良されたタスク・スケジューリング手法を提供するものである。特に、ＲＭＡ割り当てアルゴリズムを使う周期的タスクのシステムであって、使用率がＮ＊（２＊＊（１／Ｎ）−１）以下のものにおいて、本発明は、自分のコスト・パラメータよりも長く実行するタスクを呼び出すのを可能にする手法を提供するものである。コスト・パラメータは周期当たりの当該タスクの最大理論実行時間であり、決して超過してはならないものであるけれども、本発明では、ＮＳＥの存在下で効力を発揮する計算された拡張コストを用いている。
【００２９】
一例として、あるタスク「タスク１」の呼び出しコストが１０ＡＴＵ（任意時間単位）であり、タスク１の周期が１００ＡＴＵである、と仮定する。また、タスク１の実行中に、少なくとも１つのＮＳＥが合計１ＡＴＵの間実行する、と仮定する。さらに、スケジューラは、このＮＳＥ時間を別のものとして考慮せずに、それをタスク１の実行に割り当てる、と仮定する。この場合、スケジューラがタスク１用に１０ＡＴＵを累積した時に、タスク１は、実際には９ＡＴＵしか実行していない。したがって、その作業は完了できない可能性がある。従来技術によるシステムの多くは、タスク１がそのコスト・パラメータに到達したということを認識できない。したがって、何もしない。これらのシステムでは、タスク１は完了するまで実行し続ける。（これらのシステムは「撃ちてし止まん（run-to-block）」システムと呼ばれている）。このような長時間実行タスクが検査を受けずにすべて実行し続けると、システム全体の実行可能性は、極めて危険な状態になる。本発明は、タスク１がそのコスト・パラメータに到達したことを認識できるようなシステムを指向している。ここでは、そのようなシステムを「実行時間累積システム（execution time accumulating system）」と呼ぶ。本発明の手法を使うと、長時間実行タスクが実行し続けるのを許した場合に他のタスクが締切を守れなくなるか否かに関し、実行時間の決定を動的に行なうことが可能になる。さらに、本発明の手法は、他のタスクがすべて時間通りに完了するのを保証しながら、特定の長時間実行タスクに与えることのできる余分の時間を決定する方法を提供する。
【００３０】
次に、図３と図４を参照して、本発明の好適な実施形態を詳細に説明する。
【００３１】
図３に示す論理を使って、タスクが安全に実行しうるために追加する時間の上限を計算する。ここでは、この追加の時間を「拡張コスト（cost extension）」と呼ぶ。拡張コストの上限は、システムの実行可能性が保証されない値に到達するまで、漸増させながら計算する。好適な実施形態では、タスクのコストの一定割合を漸増的に加えることにより、各タスクごとに拡張コストを計算する。好適な実施形態では、この一定割合は、タスクのコスト・パラメータの１パーセントである。
【００３２】
図３の論理は、ブロック３００で、１からＮ（Ｎはシステム内のスケジュール可能なタスクの数）の拡張コスト値（図３ではＥi と表記）を零に初期化することにより開始する。各スケジュール可能なタスクは、拡張コスト、周期、締切の各値を格納する状態変数を備えているのが望ましい。本発明を使用する場合には、この状態変数にタスクの拡張コストに追加する値を格納する。
【００３３】
ブロック３１０で、各タスクのコストをその周期で除算したものを合計することにより、実行可能性分析（ＦＡ）の計算を実行する。次いで、ブロック３２０で、この合計値と図中の式（従来のシステムで使用している式と同じもの）とを比較して、すべてのタスクのすべての呼び出しが締切に間に合うか否かを判断する。ブロック３２０の試験の結果がＮｏの場合、システムは実行可能ではない。制御はブロック３６０に進む。図３の論理の初回の試行からブロック３６０に到達した場合、使用すべき拡張コストの値はすべて零である。したがって、システムは、従来技術の場合と同様に動作する。
【００３４】
ブロック３２０の試験の結果がＹｅｓの場合（すなわちシステムが実行可能である場合）、プロセスはブロック３３０に進む。ブロック３３０では、各タスクのコストの一定割合を計算する。この一定割合が１パーセントである場合、式（０．０１）Ｃi は、この試行で加算すべき追加の時間を定めている。この追加の時間を、各タスクの前回計算した拡張コストＥi に加算する。加算した結果を、各タスクのコスト・パラメータＣi に加算する。そして、その合計値を、各タスクの周期Ｔi で除算する。このプロセスを１からＮのスケジュール可能なタスクの各々について繰り返して、システムの新たな実行可能性分析（ＦＡ）値を定める。その後、ブロック３４０で、得られた結果と図中に示す使用率の式とを比較して、すべてのタスクのすべての呼び出しが締切に間に合うか否かを判断する。この試験の結果がＹｅｓの場合、ブロック３５０で、１からＮのスケジュール可能なタスクの各々のコストについて、新たな漸増拡張コストを生成する。次いで、制御はブロック３３０に戻って実行可能性分析（ＦＡ）計算を繰り返す。ブロック３４０の試験の結果がＮｏの場合（すなわち、拡張コストの現在の計算の後、システムがもはや実行可能でない場合）、制御はブロック３６０に進む。制御がブロック３６０に到達した場合、ブロック３６０に示すように、各タスクの拡張コストの上限は、既に発見されており、その値はＥi に格納されている（ただし、各タスクは各回の拡張コストの計算における一定割合として同一の値を用いるものと仮定している）。以上で、図３のプロセスは完了する。
【００３５】
図３に示す論理の別の実施形態では、一定割合の値として別の値を用いている。さらに別の実施形態では、拡張コストは、一部のタスクに対してだけ計算し、残りのタスクに対しては計算しない。例えば、長時間実行タスクには拡張を許すが、短いタスクには許さない（これは、長時間実行タスクは完了しないとシステム資源の観点から短いタスクよりも高くつく、という原理に基づいている）。この場合、短いタスクの拡張コストは零である、と考えられる。さらに別の実施形態では、漸増計算プロセスの間に一定割合として同一でない値を用いている。このアプローチの一例として、長時間実行タスクには短いタスクよりも大きな一定割合値を割り当てる。例えば、長時間実行タスクには２パーセントを使用し、短いタスクには１パーセントを使用する（この結果、長時間実行タスクには短いタスクよりも大きな拡張コストが割り当てられる）。あるいは、別の実施形態では、（ブロック３３０に示したように）タスクのコストに基づかずに、計算したての拡張コストに基づいて、各試行において追加の時間を計算している。この結果、長時間実行タスクは、幾何数列を使って拡張される。上述したこれらの実施形態を取り扱うのに図３に示す論理をどのように変更したらよいかは、当業者にとって明らかである。
【００３６】
図４の論理は、実行時に、特定の周期において呼び出されている間にコスト・パラメータを超過したタスクが安全に実行し続けうるか否かを判断すると共に、続けうる場合の継続期間を判断するのに使う。各タスクの拡張コストを知ることにより、スケジューラは、他のタスクの実行に影響を与えることなく、この判断をなすことができる。このように、リアルタイム・システムは、ＮＳＥの存在下で、本発明の教示を使わない従来技術の場合よりも長い時間間隔にわたって、通常の状態（すなわち、すべてのタスクが締切を守ることのできる状態）を維持することができる。したがって、たとえＮＳＥがあるタスクの実行時間の一部を消費したとしても、当該タスクは完了するまで実行することができる。拡張コストは、コスト・オーバーラン（超過）が生じているのが検出されると配分される（したがって、タスクの実行時間を累積しない、従来技術の「撃ちてし止まん」システムには、本発明は無用であると思われる）。次に、本発明の好適な実施形態を使用したときにコスト・オーバーランを処理する仕方を、図４の論理を参照して説明する。
【００３７】
実行中のタスクに対してコスト・オーバーランが検出されると、制御はブロック４００に至る。次いで、ブロック４１０で、このタスクは拡張コスト値（これは例えば図３の処理中に状態変数に格納される）を有するか否かを検査する。Ｎｏの場合、タスクの実行は拡張されず、制御をブロック４８０に進め従来技術の場合と同様に通常のコスト・オーバーラン・ハンドラを呼び出す。オーバーラン処理が完了すると、図４のこの呼び出しは完了する。
【００３８】
ブロック４１０の検査の結果がＹｅｓの場合、ブロック４２０で処理を継続する。ブロック４２０では、拡張コスト（Ｅi ）の最小値と、（図４中に「Ｄ」で示す）締切までの残存時間とを計算する。次いで、ブロック４３０で、拡張コストがＤよりも小さいか否かを検査する。Ｙｅｓならば、ブロック４４０で、当該タスクはその拡張コストの間実行し続けることを許される。図３を参照して説明したように、この拡張コストとは、当該タスクが他のスケジュール可能なタスクに影響を与えることなく実行し続けうる時間の上限のことである。当該タスクがこの追加の時間（拡張コスト）の間実行し続けた後、制御はブロック４６０に進む。ブロック４６０では、当該タスクが未（いま）だに実行しているか否かを検査する。Ｙｅｓの場合、当該タスクの締切は守られなかったことを意味する（すなわち、当該タスクがシステム中で他のタスクに影響を与えることなく実行を完了する、ということを保証できない）。したがって、ブロック４７０で締切ミス・ハンドラを呼び出す。締切ミス・ハンドラが（本発明の一部を形成しない従来技術の手法を使って）その処理を完了したら、コスト・オーバーラン・ハンドラを呼び出す（ブロック４８０）。必要な場合には、コスト・オーバーラン処理に、本発明に従う拡張コストを有するタスクが未だにコストをオーバーランしている状況を処理する論理を付加することができる。例えば、拡張コスト内に完了できないようなコスト超過タスクに関する統計をとることができる。
以上で当該タスクに関する図４の処理は終了する。
【００３９】
ブロック４６０の検査の結果がＮｏならば、当該タスクは拡張コストの間に実行を完了したことを意味する。好適な実施形態では、ブロック４８０でコスト・オーバーラン・ハンドラを呼び出す。以上で当該タスクに関する図４の処理は終了する。
【００４０】
ブロック４３０に戻り、現在のタスクの締切までの残存時間が当該タスクの拡張コスト以下の場合、ブロック４５０で、当該タスクが締切に至るまで実行し続けるのを許す。次いで、ブロック４６０で、当該タスクが別のオーバーラン状況に遭遇しているか否かを検査する（すなわち、当該タスクが締切に到達したのに完了していないか否かを検査する）。Ｙｅｓならば、ブロック４７０について上述したように、締切ミス・ハンドラを呼び出す。この処理の後、ブロック４８０について上述したように、コスト・オーバーラン・ハンドラを呼び出す。また、ブロック４６０の検査の結果がＮｏの場合（当該タスクが締切に間に合った場合）、ブロック４８０でコスト・オーバーラン・ハンドラを呼び出す。
以上で図４の処理は終了する。
【００４１】
上述したように、本発明は、システム全体の中で他のタスクに影響を与えることなく、実行時間累積システムにおいてコスト見積もりをオーバーランしたタスクの実行時間を安全に拡張するための極めて効率的な手法を提供するものである。この手法は、複雑なスケジューラを使用している多数の環境において役立つものと思われる。上記環境には、例えばリアルタイム・システムを実現するのにReal-Time Specification for Java（商標）を使っているような環境がある。（「Java」はサン・マイクロシステムズ社の商標である）。本発明を使用すると、タスクの締切を有する実行環境において柔軟性が増す。この結果、そのようなシステムを設計・管理するのが容易になると共に、操作が効率的になる。
【００４２】
以上、本発明の好適な実施形態を説明したが、この実施形態に対する変形と変更は、いったん本発明の基本概念を学んだ当業者にとって容易に想到しうるものである。したがって、特許請求の範囲は、好適な実施形態と、本発明の本旨と範囲の内にあるようなすべての変形および変更とを含むように解釈すべきである。
【００４３】
まとめとして以下の事項を開示する。
（１）タスク・スケジューリングを改良するコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品は少なくとも１つのコンピュータ読み取り可能な媒体に組み込まれており、
各タスクが付随するコストおよび付随する締切を有する複数のタスクの実行が可能であるか否かを計算するコンピュータ読み取り可能なプログラム・コード手段と、
前記実行が可能であると計算された場合、各タスクについて付随するコストに追加の時間を付加して、各タスク用に改定されたコストを算出するコンピュータ読み取り可能なプログラム・コード手段と、
前記実行がもはや可能でないと計算されるまで、前記計算するコンピュータ読み取り可能なプログラム・コード手段、および前記算出するコンピュータ読み取り可能なプログラム・コード手段の操作を反復的に繰り返すコンピュータ読み取り可能なプログラム・コード手段と、
前記反復的に繰り返すコンピュータ読み取り可能なプログラム・コード手段の操作の後、前記改定されたコストをタスクの実行時間の上限として使用するコンピュータ読み取り可能なプログラム・コード手段と
を備えたコンピュータ・プログラム製品。
（２）前記追加の時間がタスクに付随するコストの一定割合である、
上記（１）に記載のコンピュータ・プログラム製品。
（３）前記追加の時間が、一部のタスクについては零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合である、
上記（１）に記載のコンピュータ・プログラム製品。
（４）前記算出するコンピュータ読み取り可能なプログラム・コード手段の最初の試行では、追加の時間がタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（１）に記載のコンピュータ・プログラム製品。
（５）前記算出するコンピュータ読み取り可能なプログラム・コード手段の最初の試行では、一部のタスクについては追加の時間が零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（１）に記載のコンピュータ・プログラム製品。
（６）前記使用するコンピュータ読み取り可能なプログラム・コード手段が、実行時に、タスク群のうちの特定のタスクがそれに付随するコストを超過しているか否かを判断するコンピュータ読み取り可能なプログラム・コード手段と、
もしそうである場合、
（１）前記特定のタスクに付随する締切までの残存時間、または、（２）前記特定のタスクの実行時間の上限、のうちの最小のものに到達するまで、前記特定のタスクが実行するのを許すコンピュータ読み取り可能なプログラム・コード手段と
を備えている、
上記（１）に記載のコンピュータ・プログラム製品。
（７）タスク・スケジューリングを改良するシステムであって、
各タスクが付随するコストおよび付随する締切を有する複数のタスクの実行が可能であるか否かを計算する手段と、
前記実行が可能であると計算された場合、各タスクについて付随するコストに追加の時間を付加して、各タスク用に改定されたコストを算出する手段と、
前記実行がもはや可能でないと計算されるまで、前記計算する手段および前記算出する手段の操作を反復的に繰り返す手段と
備えたシステム。
（８）さらに、
前記反復的に繰り返す手段の操作の後、前記改定されたコストをタスクの実行時間の上限として使用する手段
を備えた、
上記（７）に記載のシステム。
（９）前記追加の時間がタスクに付随するコストの一定割合である、
上記（７）に記載のシステム。
（１０）前記追加の時間が、一部のタスクについては零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合である、
上記（７）に記載のシステム。
（１１）前記算出する手段の最初の試行では、追加の時間がタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（７）に記載のシステム。
（１２）前記算出する手段の最初の試行では、一部のタスクについては追加の時間が零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（７）に記載のシステム。
（１３）前記使用する手段が、
実行時に、タスク群のうちの特定のタスクがそれに付随するコストを超過しているか否かを判断する手段と、
もしそうである場合、
（１）前記特定のタスクに付随する締切までの残存時間、または、（２）前記特定のタスクの実行時間の上限、のうちの最小のものに到達するまで、前記特定のタスクが実行するのを許す手段と
を備えている、
上記（７）に記載のシステム。
（１４）タスク・スケジューリングを改良する方法であって、
各タスクが付随するコストおよび付随する締切を有する複数のタスクの実行が可能であるか否かを計算するステップと、
前記実行が可能であると計算された場合、各タスクについて付随するコストに追加の時間を付加して、各タスク用に改定されたコストを算出するステップと、前記実行がもはや可能でないと計算されるまで、前記計算する手段および前記算出する手段の操作を反復的に繰り返すステップと
備えた方法。
（１５）さらに、
前記反復的に繰り返す手段の操作の後、前記改定されたコストをタスクの実行時間の上限として使用するステップ
を備えた、
上記（１４）に記載の方法。
（１６）前記追加の時間がタスクに付随するコストの一定割合である、
上記（１４）に記載の方法。
（１７）前記追加の時間が、一部のタスクについては零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合である、
上記（１４）に記載の方法。
（１８）前記算出するステップの最初の試行では、追加の時間がタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（１４）に記載の方法。
（１９）前記算出するステップの最初の試行では、一部のタスクについては追加の時間が零であると共に、残りのすべてのタスクについてはタスクに付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
上記（１４）に記載の方法。
（２０）前記使用するステップが、
実行時に、タスク群のうちの特定のタスクがそれに付随するコストを超過しているか否かを判断するステップと、
もしそうである場合、
（１）前記特定のタスクに付随する締切までの残存時間、または、（２）前記特定のタスクの実行時間の上限、のうちの最小のものに到達するまで、前記特定のタスクが実行するのを許すステップと
を備えている、
上記（１４）に記載の方法。
【図面の簡単な説明】
【図１】 本発明を実現することのできるコンピューティング装置のブロック図である。
【図２】 本発明を実現することのできるネットワーク化されたコンピューティング環境を示す図である。
【図３】 本発明の改良された実行可能性アルゴリズムを実現するのに使用しうる論理の好適な実施形態のフローチャートを示す図である。
【図４】 本発明に従い実行時にタスクの実行をモニタするのに使用しうる論理の好適な実施形態のフローチャートを示す図である。
【符号の説明】
１０ コンピューティング装置
１２ ＣＰＵ
１４ メモリ
１６ 長期間記憶装置
１８ ネットワーク電送機能
２０ コンピューティング装置
２２ ＣＰＵ
２４ メモリ
２６ 長期間記憶装置
２８ ネットワーク伝送機能
４０ ネットワーク
４２ 無線ネットワーク
４４ ネットワーク
４６ ゲートウェイ・コンピュータ
４７ アプリケーション・サーバ
４８ データ・リポジトリ
５０ａ、５０ｂ、５０ｃ 通信リンク
Claims (27)
- タスク・スケジューリングを改良するためのコンピュータ・プログラムであって、
コンピューティング装置に、
複数のスケジュール可能なタスクの実行が可能であるか否かを計算するステップであって、各タスクが、付随するコストおよび付随する締切を有する、前記計算するステップと、
前記実行が可能であると計算された場合、各タスクについて、前記付随するコストに追加の時間を付加して、各タスク用に改定されたコストを算出するステップと、
前記計算するステップおよび前記算出するステップの操作を反復的に繰り返して、全てのタスクの全ての呼び出しが締切に間に合うか否かを判断し、前記実行がもはや可能でないと計算されるまで繰り返すステップと、
前記繰り返すステップの操作の後に、前記算出され且つ前記改定されたコストをタスクの実行時間の上限として使用するステップと
を実行させるコンピュータ・プログラム。 - 前記追加の時間が各タスクについての前記付随するコストの一定割合である、請求項１に記載のコンピュータ・プログラム。
- 前記追加の時間が、一部のタスクについては零であると共に、残りのすべてのタスクについてはタスクについての付随するコストの一定割合である、請求項１に記載のコンピュータ・プログラム。
- 前記算出するステップの最初の試行では、追加の時間がタスクについての付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
請求項１に記載のコンピュータ・プログラム。 - 前記算出するステップの最初の試行では、一部のタスクについては追加の時間が零であると共に、残りのすべてのタスクについてはタスクについての付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
請求項１に記載のコンピュータ・プログラム。 - 前記使用するステップが、
実行時に、タスク群のうちの特定のタスクがそれに付随するコストを超過しているか否かを判断するステップと、
もしそうである場合、
（１）前記特定のタスクについての付随する締切までの残存時間、または、（２）前記特定のタスクの実行時間の上限、のうちの最小のものに到達するまで、前記特定のタスクが実行するのを許すステップと
を含む、請求項１に記載のコンピュータ・プログラム。 - タスク・スケジューリングを改良するシステムであって、
複数のスケジュール可能なタスクの実行が可能であるか否かを計算する手段であって、各タスクが、付随するコストおよび付随する締切を有する、前記計算する手段と、
前記実行が可能であると計算された場合、各タスクについて、前記付随するコストに追加の時間を付加して、各タスク用に改定されたコストを算出する手段と、
前記計算する手段および前記算出する手段の操作を反復的に繰り返して、全てのタスクの全ての呼び出しが締切に間に合うか否かを判断し、前記実行がもはや可能でないと計算 されるまで繰り返す手段と、
前記繰り返す手段の操作の後に、前記算出され且つ前記改定されたコストをタスクの実行時間の上限として使用する手段と
を含むシステム。 - 前記追加の時間が各タスクについての前記付随するコストの一定割合である、請求項７に記載のシステム。
- 前記追加の時間が、一部のタスクについては零であると共に、残りのすべてのタスクについてはタスクについての付随するコストの一定割合である、請求項７に記載のシステム。
- 前記算出する手段の最初の試行では、追加の時間がタスクについての付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
請求項７に記載のシステム。 - 前記算出する手段の最初の試行では、一部のタスクについては追加の時間が零であると共に、残りのすべてのタスクについてはタスクについての付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
請求項７に記載のシステム。 - 前記使用する手段が、
実行時に、タスク群のうちの特定のタスクがそれに付随するコストを超過しているか否かを判断する手段と、
もしそうである場合、
（１）前記特定のタスクについての付随する締切までの残存時間、または、（２）前記特定のタスクの実行時間の上限、のうちの最小のものに到達するまで、前記特定のタスクが実行するのを許す手段と
を含む、請求項７に記載のシステム。 - タスク・スケジューリングを改良する方法であって、
コンピューティング装置に、
複数のスケジュール可能なタスクの実行が可能であるか否かを計算するステップであって、各タスクが、付随するコストおよび付随する締切を有する、前記計算するステップと、
前記実行が可能であると計算された場合、各タスクについて、前記付随するコストに追加の時間を付加して、各タスク用に改定されたコストを算出するステップと、
前記計算するステップおよび前記算出するステップの操作を反復的に繰り返して、全てのタスクの全ての呼び出しが締切に間に合うか否かを判断し、前記実行がもはや可能でないと計算されるまで繰り返すステップと、
前記繰り返すステップの操作の後に、前記算出され且つ前記改定されたコストをタスクの実行時間の上限として使用するステップと
を実行させる、方法。 - 前記追加の時間が各タスクについての前記付随するコストの一定割合である、請求項１３に記載の方法。
- 前記追加の時間が、一部のタスクについては零であると共に、残りのすべてのタスクについてはタスクについての付随するコストの一定割合である、請求項１３に記載の方法。
- 前記算出するステップの最初の試行では、追加の時間がタスクについての付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
請求項１３に記載の方法。 - 前記算出するステップの最初の試行では、一部のタスクについては追加の時間が零であると共に、残りのすべてのタスクについてはタスクについての付随するコストの一定割合であり、
残りの試行では、追加の時間が各タスク用に改定されたコストの一定割合である、
請求項１３に記載の方法。 - 前記使用するステップが、
実行時に、タスク群のうちの特定のタスクがそれに付随するコストを超過しているか否かを判断するステップと、
もしそうである場合、
（１）前記特定のタスクについての付随する締切までの残存時間、または、（２）前記特定のタスクの実行時間の上限、のうちの最小のものに到達するまで、前記特定のタスクが実行するのを許すステップと
を含む、請求項１３に記載の方法。 - タスク・スケジューリングを改良するためのコンピュータ・プログラムであって、
コンピューティング装置に、
複数のスケジュール可能なタスクの実行が可能であるか否かを計算するステップであって、前記タスクの夫々が付随するコストおよび付随する締切を有するステップと、
各タスクの次の実行のために許容されるタスク特定の最大の拡張コストを計算するステップであって、全ての前記タスクについてまとめられたときの前記最大の拡張コストは、前記複数のタスクの実行を可能であるように維持することを可能にし、各タスクのために許容される前記最大の拡張コストは、最初の次の実行について、改訂されたコストを計算するために前記タスクについて付随するコストの一定のパーセントを使用し、そして他の次の実行について、前記改訂されたコストの一定のパーセントを使用することによって漸増的に計算されるステップと、
前記スケジュール可能なタスクのいずれかが、タスクの次の実行の間にその付随するコストを超えると決定されると、そのタスクについての追加的な許容可能な実行時間の上限として、そのタスクについて前記最大の拡張コストを使用するステップと
を実行させるコンピュータ・プログラム。 - 前記最初の次の実行について、前記タスクのサブセットのために、前記最大の拡張コストを計算する場合に、零が、一定のパーセントの代わりに使用される、請求項１９に記載のコンピュータ・プログラム。
- 前記残存時間が前記タスクについての前記最大の拡張コストよりも大きくない場合に、追加的な許容可能な実行時間の上限として、前記タスクの付随する締切まで残存時間を使用することをさらに含む、請求項１９に記載のコンピュータ・プログラム。
- スク・スケジューリングを改良するシステムであって、
複数のスケジュール可能なタスクの実行が可能であるか否かを計算する手段であって、前記タスクの夫々が付随するコストおよび付随する締切を有する手段と、
各タスクの次の実行のために許容されるタスク特定の最大の拡張コストを計算する手段 であって、全ての前記タスクについてまとめられたときの前記最大の拡張コストは、前記複数のタスクの実行を可能であるように維持することを可能にし、各タスクのために許容される前記最大の拡張コストは、最初の次の実行について、改訂されたコストを計算するために前記タスクについて付随するコストの一定のパーセントを使用し、そして他の次の実行について、前記改訂されたコストの一定のパーセントを使用することによって漸増的に計算される手段と、
前記スケジュール可能なタスクのいずれかが、タスクの次の実行の間にその付随するコストを超えると決定されると、そのタスクについての追加的な許容可能な実行時間の上限として、そのタスクについて前記最大の拡張コストを使用する手段と
を含むシステム。 - 前記最初の次の実行について、前記タスクのサブセットのために、前記最大の拡張コストを計算する場合に、零が、一定のパーセントの代わりに使用される、請求項２２に記載のシステム。
- 前記残存時間が前記タスクについての前記最大の拡張コストよりも大きくない場合に、追加的な許容可能な実行時間の上限として、前記タスクの付随する締切まで残存時間を使用することをさらに含む、請求項２２に記載のシステム。
- タスク・スケジューリングを改良する方法であって、
コンピューティング装置に、
複数のスケジュール可能なタスクの実行が可能であるか否かを計算するステップであって、前記タスクの夫々が付随するコストおよび付随する締切を有するステップと、
各タスクの次の実行のために許容されるタスク特定の最大の拡張コストを計算するステップであって、全ての前記タスクについてまとめられたときの前記最大の拡張コストは、前記複数のタスクの実行を可能であるように維持することを可能にし、各タスクのために許容される前記最大の拡張コストは、最初の次の実行について、改訂されたコストを計算するために前記タスクについて付随するコストの一定のパーセントを使用し、そして他の次の実行について、前記改訂されたコストの一定のパーセントを使用することによって漸増的に計算されるステップと、
前記スケジュール可能なタスクのいずれかが、タスクの次の実行の間にその付随するコストを超えると決定されると、そのタスクについての追加的な許容可能な実行時間の上限として、そのタスクについて前記最大の拡張コストを使用するステップと
を含む方法。 - 前記最初の次の実行について、前記タスクのサブセットのために、前記最大の拡張コストを計算する場合に、零が、一定のパーセントの代わりに使用される、請求項２５に記載の方法。
- 前記残存時間が前記タスクについての前記最大の拡張コストよりも大きくない場合に、追加的な許容可能な実行時間の上限として、前記タスクの付随する締切まで残存時間を使用することをさらに含む、請求項２５に記載の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/782,780 US6957431B2 (en) | 2001-02-13 | 2001-02-13 | System for incrementally computing the maximum cost extension allowable for subsequent execution of each task using fixed percentage of the associated cost |
| US09/782780 | 2001-02-13 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002259144A JP2002259144A (ja) | 2002-09-13 |
| JP3759040B2 true JP3759040B2 (ja) | 2006-03-22 |
Family
ID=25127161
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002006022A Expired - Fee Related JP3759040B2 (ja) | 2001-02-13 | 2002-01-15 | タスク・スケジューリングを改良する方法とシステム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6957431B2 (ja) |
| JP (1) | JP3759040B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106095562A (zh) * | 2016-08-23 | 2016-11-09 | 北京云纵信息技术有限公司 | 任务调度管理的方法和装置 |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7472389B2 (en) * | 2003-10-29 | 2008-12-30 | Honeywell International Inc. | Stochastically based thread budget overrun handling system and method |
| US7458077B2 (en) * | 2004-03-31 | 2008-11-25 | Intel Corporation | System and method for dynamically adjusting a thread scheduling quantum value |
| US7941427B2 (en) * | 2004-04-14 | 2011-05-10 | International Business Machines Corporation | Dynamically managing computer resources based on valuations of work items being processed |
| JP4410661B2 (ja) * | 2004-11-09 | 2010-02-03 | 株式会社日立製作所 | 分散制御システム |
| CN101103336A (zh) * | 2005-01-13 | 2008-01-09 | 皇家飞利浦电子股份有限公司 | 数据处理系统和任务调度的方法 |
| US7613595B2 (en) * | 2005-03-01 | 2009-11-03 | The Math Works, Inc. | Execution and real-time implementation of a temporary overrun scheduler |
| CA2538503C (en) * | 2005-03-14 | 2014-05-13 | Attilla Danko | Process scheduler employing adaptive partitioning of process threads |
| US8245230B2 (en) * | 2005-03-14 | 2012-08-14 | Qnx Software Systems Limited | Adaptive partitioning scheduler for multiprocessing system |
| US9361156B2 (en) | 2005-03-14 | 2016-06-07 | 2236008 Ontario Inc. | Adaptive partitioning for operating system |
| US8387052B2 (en) * | 2005-03-14 | 2013-02-26 | Qnx Software Systems Limited | Adaptive partitioning for operating system |
| US7921425B2 (en) * | 2005-03-14 | 2011-04-05 | Cisco Technology, Inc. | Techniques for allocating computing resources to applications in an embedded system |
| US7630917B2 (en) * | 2006-04-14 | 2009-12-08 | At&T Intellectual Property Ii, L.P. | Automatic learning for mapping spoken/text descriptions of products onto available products |
| WO2011102219A1 (ja) * | 2010-02-19 | 2011-08-25 | 日本電気株式会社 | リアルタイムシステム用マルチコア向けタスク配置最適化システム、その方法及びそのプログラム |
| US8930954B2 (en) | 2010-08-10 | 2015-01-06 | International Business Machines Corporation | Scheduling parallel data tasks |
| WO2012056609A1 (ja) * | 2010-10-28 | 2012-05-03 | 日本電気株式会社 | タスク配置最適化システム、タスク配置最適化方法、及びタスク配置最適化プログラムが格納された非一時的なコンピュータ可読媒体 |
| US9535757B2 (en) * | 2011-12-19 | 2017-01-03 | Nec Corporation | Task allocation optimizing system, task allocation optimizing method and task allocation optimizing program |
| FR2990782B1 (fr) * | 2012-05-15 | 2015-06-26 | Sagem Defense Securite | Procede de gestion d'une execution de taches dans un systeme informatique |
| US9632830B1 (en) * | 2015-08-06 | 2017-04-25 | Rockwell Collins, Inc. | Cache retention analysis system and method |
| US10552215B1 (en) * | 2017-08-05 | 2020-02-04 | Jia Xu | System and method of handling real-time process overruns on a multiprocessor |
| US11042404B2 (en) * | 2018-03-16 | 2021-06-22 | Imam Abdulrahman Bin Faisal University | Real-time feasibility systems and methods |
| WO2024196401A1 (en) * | 2023-03-21 | 2024-09-26 | Microchip Technology Incorporated | Co-operative scheduler with detection of task executing longer than an expected execution time without interrupting execution of the task |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5325525A (en) * | 1991-04-04 | 1994-06-28 | Hewlett-Packard Company | Method of automatically controlling the allocation of resources of a parallel processor computer system by calculating a minimum execution time of a task and scheduling subtasks against resources to execute the task in the minimum time |
| US5210872A (en) * | 1991-06-28 | 1993-05-11 | Texas Instruments Inc. | Critical task scheduling for real-time systems |
| US5640563A (en) | 1992-01-31 | 1997-06-17 | International Business Machines Corporation | Multi-media computer operating system and method |
| US5408663A (en) * | 1993-11-05 | 1995-04-18 | Adrem Technologies, Inc. | Resource allocation methods |
| US6141412A (en) * | 1994-06-01 | 2000-10-31 | Davox Corporation | Unscheduled event task processing system |
| DE69703938T3 (de) * | 1996-11-22 | 2007-05-16 | (at)Road Ltd., Ipswich | Ressourcenzuordnung |
| US6335922B1 (en) * | 1997-02-11 | 2002-01-01 | Qualcomm Incorporated | Method and apparatus for forward link rate scheduling |
| US6117180A (en) * | 1997-02-24 | 2000-09-12 | Lucent Technologies Inc. | Hardware-software co-synthesis of heterogeneous distributed embedded systems for low overhead fault tolerance |
| US6601035B1 (en) * | 1997-07-10 | 2003-07-29 | At&T Corp. | Methods for dynamically predicting workflow completion times and workflow escalations |
| JPH11184717A (ja) | 1997-12-22 | 1999-07-09 | Toshiba Corp | スケジューリング解析装置及び方法並びにスケジューリング解析用ソフトウェアを記録した記録媒体 |
| US6430593B1 (en) * | 1998-03-10 | 2002-08-06 | Motorola Inc. | Method, device and article of manufacture for efficient task scheduling in a multi-tasking preemptive priority-based real-time operating system |
| US6321133B1 (en) * | 1998-12-04 | 2001-11-20 | Impresse Corporation | Method and apparatus for order promising |
| US6502062B1 (en) * | 1999-06-21 | 2002-12-31 | Lucent Technologies Inc. | System and method for scheduling data delivery using flow and stretch algorithms |
| US6687257B1 (en) * | 1999-08-12 | 2004-02-03 | Rockwell Automation Technologies, Inc. | Distributed real-time operating system providing dynamic guaranteed mixed priority scheduling for communications and processing |
| US6463457B1 (en) * | 1999-08-26 | 2002-10-08 | Parabon Computation, Inc. | System and method for the establishment and the utilization of networked idle computational processing power |
| US6711129B1 (en) * | 1999-10-26 | 2004-03-23 | Avaya Technology Corp. | Real-time admission control |
| JP2002007364A (ja) * | 2000-06-22 | 2002-01-11 | Fujitsu Ltd | 並列計算機システムのジョブスケジューリングを行うスケジューリング装置 |
| US6965562B2 (en) * | 2000-12-14 | 2005-11-15 | Nokia Networks | System and method for managing a network to sustain the quality of voice over internet protocol communications |
-
2001
- 2001-02-13 US US09/782,780 patent/US6957431B2/en not_active Expired - Fee Related
-
2002
- 2002-01-15 JP JP2002006022A patent/JP3759040B2/ja not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106095562A (zh) * | 2016-08-23 | 2016-11-09 | 北京云纵信息技术有限公司 | 任务调度管理的方法和装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20020138542A1 (en) | 2002-09-26 |
| JP2002259144A (ja) | 2002-09-13 |
| US6957431B2 (en) | 2005-10-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3759040B2 (ja) | タスク・スケジューリングを改良する方法とシステム | |
| US10659316B1 (en) | State machine controlled dynamic distributed computing | |
| Chetto et al. | Dynamic scheduling of real-time tasks under precedence constraints | |
| Audsley et al. | Applying new scheduling theory to static priority pre-emptive scheduling | |
| García et al. | Optimized priority assignment for tasks and messages in distributed hard real-time systems | |
| US8316376B2 (en) | Optimizing workflow execution against a heterogeneous grid computing topology | |
| US20060218551A1 (en) | Jobstream planner considering network contention & resource availability | |
| US8250131B1 (en) | Method and apparatus for managing a distributed computing environment | |
| US8843929B1 (en) | Scheduling in computer clusters | |
| EP1806002A1 (en) | Method for managing resources in a platform for telecommunication service and/or network management, corresponding platform and computer program product therefor | |
| Caccamo et al. | Handling execution overruns in hard real-time control systems | |
| Bai et al. | ASDYS: Dynamic scheduling using active strategies for multifunctional mixed-criticality cyber–physical systems | |
| Jha et al. | Transparent implementation of conservative algorithms in parallel simulation languages | |
| Garg et al. | Fault tolerant task scheduling on computational grid using checkpointing under transient faults | |
| CN105868012B (zh) | 处理用户请求的方法和装置 | |
| Rivas et al. | Optimized Deadline Assignment and Schedulability Analysis for Distributed Real-Time Systems with Local EDF Scheduling. | |
| Rahni et al. | Feasibility analysis of real-time transactions | |
| Kalogeraki et al. | Dynamic migration algorithms for distributed object systems | |
| CN112507347B (zh) | 面向分布式密码破解框架的破解作业描述信息生成方法 | |
| Son et al. | Deadline allocation in a time-constrained workflow | |
| Lee et al. | JMC: Jitter-Based Mixed-Criticality Scheduling for Distributed Real-Time Systems | |
| Hung et al. | A solution for optimizing recovery time in cloud computing | |
| Decker et al. | Adaptation of on-line scheduling strategies for sensor network platforms | |
| Hu et al. | Exploring the interplay between computation and communication in distributed real-time scheduling | |
| Sharifi et al. | A mathematical approach to reduce the mean number of waiting tasks in wireless sensor actor networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050601 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050614 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050826 Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20050826 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20050826 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20050829 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051220 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20051220 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20051220 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051227 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090113 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100113 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100113 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110113 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120113 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130113 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140113 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |