JP3975795B2

JP3975795B2 - タスク管理装置、同方法およびプログラム

Info

Publication number: JP3975795B2
Application number: JP2002080799A
Authority: JP
Inventors: 睦阿部
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2002-03-22
Filing date: 2002-03-22
Publication date: 2007-09-12
Anticipated expiration: 2022-03-22
Also published as: JP2003280929A

Description

【０００１】
【発明の属する技術分野】
本発明は、マルチタスクシステムにおけるタスク管理装置およびプログラムに関し、特にシステムのリソース量に応じた実行保証機能を有するものに関する。
【０００２】
【従来の技術】
コンピュータ間通信において、動画や音声といったリアルタイム情報の通信を行いたいという要求は近年、一段と増している。動画や音声を扱うリアルタイム通信端末では、例えば相手側の端末から動画や音声といった情報を受信するタスク、受信した情報を表示するタスク、相手側の端末に対して情報を送信するタスク等の複数のタスクを実行しなければならない。したがって、この端末は、リアルタイム処理を必要とする複数のタスクを実行するマルチタスクシステムとなり、このようなマルチタスクシステムにおいて、サービス品質（Ｑｏｓ；Quality of service）の保証が必要となる。
【０００３】
このようなマルチタスクシステムにおいて、サービス品質を保証する技術としては、ＯＳ（Operating System）のタスク優先度設定機能を用いて、動画や音声といった情報を扱うリアルタイム性を要求されるタスクの優先度を他のタスクより高く設定して、遅延要求の厳しいタスクの処理を優先させるという手法が一般的に使用されている。また、サービス品質を保証する他の技術として、実行終了目標時刻が設定されたタスクについて、その実行終了目標時刻が近づくほど優先度を上げて優先的に処理することにより、タスク処理を実行終了目標時刻までに完了させるという手法も提案されている（特開昭６２−２８４４３７号公報）。
【０００４】
【発明が解決しようとする課題】
しかし、いずれの従来技術も、実行の予約が要求されているタスクの所要リソース量の合計が、その時点でシステムが提供可能なリソース量を上回る場合には、処理能力を超えたタスクをシステムが実行しようとしてしまい、優先度の低いタスクや新規に実行の予約が要求されたタスクを実行できない、あるいは全てのタスクを実行できないか、遅延が許容される所定のデッドライン内に実行できないことになる。
【０００５】
例えば、図９（ａ）に示すように、ある時点でシステムが提供できるリソース量Ｒ１が、要求されているタスクの合計の所要リソース量がｒ１＋ｒ２より大である場合には、システムは実行が要求されている全てのタスクを実行できる。しかし、この状態から、図９（ｂ）に示すように所要リソース量ｒ３の追加のタスクの処理が要求された場合には、合計の所要リソース量ｒ１＋ｒ２＋ｒ３が、提供できるリソース量Ｒ１を上回るため、追加のタスクの受付がリジェクトされるか、あるいは全てのタスクの受付がリジェクトされることになる。
【０００６】
また、図１０（ａ）〜（ｃ）に示すように、周期がＳ１、要求処理時間がＴ１、デッドライン（その時間内で処理が完了すれば品質が満足されるような許容時間、許容遅延時間）がＨ１に設定されたタスクＡ１，Ａ２，Ａ３がある場合についてみると、タスクＡ１およびタスクＡ２は、両者をこの順で実行する場合にそれぞれのデッドラインを満足（デッドライン以前に処理を終了）できるため、共に実行可能である。しかし、タスクＡ１，Ａ２，Ａ３をこの順で実行する場合には、タスクＡ１，Ａ２のデッドラインを満足できてもタスクＡ３のデッドラインを満足できないため、タスクＡ３は実行できないことになる。
【０００７】
そこで本発明の目的は、タスクの遅延保証とタスクの効率的な実行とを両立できる手段を提供することを目的とする。
【０００８】
【課題を解決するための手段】
第１の本発明は、複数のタスクのいずれかを選択的に実行するマルチタスクシステムにおいて、各タスクの所要リソース量に基づいて各タスクの実行可能性を判定する判定手段と、判定手段の判定結果に基づいて実行対象となるタスクを選択するタスク選択手段と、を備えたタスク管理装置であって、少なくともいずれかのタスクについて規定された保証部分と制御可能部分との所要リソース量情報を取得する所要リソース量情報取得手段を更に備え、前記判定手段は、少なくともいずれかの予約済みのタスクの処理レベルを前記制御可能部分の範囲内で仮想的に変更して前記判定を実行し、前記タスク選択手段は、実行可能と判定された処理レベルで前記選択を実行することを特徴とするタスク管理装置である。
【０００９】
タスクの中には、例えば画像における解像度や、動画におけるフレームレート（秒あたりの描画数）など、ある程度の実行品質の低下がユーザに許容できる場合が少なくない。したがって、優先度の高いタスクや現在実行中であるタスクに、いわば削れる部分があるにも関わらず、優先度の低いタスクや新規に予約要求がされたタスクがリジェクトされるのでは不合理といえる。
【００１０】
この点、第１の本発明では、タスクそのものを保証部分と制御可能部分とに分けて段階的に設定し、後者を制御可能、つまり場合に応じて付加・削除・増加または減少できる部分として扱うこととした。すなわち第１の本発明では、判定手段が、各タスクの所要リソース量に基づいて、少なくともいずれかの予約済みのタスクの処理レベルを制御可能部分の範囲内で仮想的に変更して各タスクの実行可能性を判定すると共に、タスク選択手段が、実行可能と判定された処理レベルで、実行対象となるタスクの選択を実行するようにしたので、システムのリソース量、各タスクのデッドラインや実行周期などの外的制約がある場合にも、予約済みのタスクについて品質を調整することで、優先度の低いタスクや新規に予約要求がされたタスクを受付けて実行することができ、タスクの遅延保証とタスクの効率的な実行とを両立できる。
【００１１】
第２の本発明は、タスク管理装置であって、前記判定手段は、予約済みのタスクのうち、実行が開始されていないタスクの少なくともいずれかのタスクのみについて、その保証部分と制御可能部分との両者が実行可能かを、新規タスクの予約要求があった際に判定する第１判定手段と、第１判定手段によって不可との判定があった場合に、第１判定手段で不可と判定された前記実行が開始されていないタスクについて、その保証部分が実行可能かを判定する第２判定手段と、を備え、前記タスク選択手段は、第１判定手段により実行可能と判定された前記実行が開始されていないタスクにつきその保証部分と制御可能部分との両者を実行対象として選択し、第２判定手段により実行可能と判定された前記実行が開始されていないタスクにつきその保証部分のみを実行対象として選択することを特徴とするタスク管理装置である。
【００１２】
第２の本発明では、制御可能部分の付加または削除により、判定処理と品質の調整とを行うこととした。すなわち、図４（ａ）に示すように、各タスクの所要リソース量ｒ１，ｒ２を、予め保証部分に係る所要リソース量ｒ１ａ，ｒ２ａと、制御可能部分に係る所要リソース量ｒ１ｂ，ｒ２ｂとに分割して設定しておき、例えば所要リソース量ｒ３の新たなタスク（図４（ｂ））の登録の要求があった場合などには、まず、要求されている全タスクの保証部分と制御可能部分（所要リソース量ｒ１＋ｒ２＋ｒ３）が実行可能かを判定し、実行可能と判定された場合にはその保証部分と制御可能部分とが選択される。他方、保証部分と制御可能部分とが実行不能と判定された場合、次に、要求されている全タスクの保証部分のみ（図４（ｃ）、所要リソース量ｒ１ａ＋ｒ２ａ＋ｒ３ａ）が実行可能かが判定され、実行可能と判定された場合には全タスクの保証部分のみが選択される。このように第２の本発明では、制御可能部分の付加または削除によって所要リソース量を調整するので、簡易な構成により第１の本発明と同様の効果を得ることができる。
【００１３】
第３の本発明は、タスク管理装置であって、前記判定手段が、実行が開始されていない予約済みのタスクの全てについて、前記第１判定手段及び第２判定手段による判定を実行することを特徴とするタスク管理装置である。
【００１４】
第３の本発明では、前記第１判定手段及び第２判定手段による判定を実行することによる処理レベルの仮想的な変更を、実行が開始されていない予約済みのタスクの全てについて行うこととしたので、大きな変更量をとることにより要求リソース量の大きな変化を許容できる。
【００１５】
本発明における判定手段による判定は、所要リソース量の変動が予想される場合に行うのが特に好適であり、第４の本発明のように処理対象となるタスク数の変更要求があった場合に行うこととしたり、第５の本発明のように少なくともいずれかのタスクについてパラメータの変更要求があった場合に行うこととしてもよい。また、第５の本発明におけるパラメータは、第６の本発明のように前記少なくともいずれかのタスクのデッドラインとしたり、第７の本発明のように前記少なくともいずれかのタスクの実行周期とするのが好適である。
【００１６】
第８の本発明は、タスク管理装置であって、少なくともいずれかのタスクについてその保証部分と制御可能部分とを識別するための保証対象識別子を取得する保証対象識別子取得手段を更に備え、前記タスク選択手段が、前記保証対象識別子を利用して、前記選択を行うことを特徴とするタスク管理装置である。
【００１７】
第８の本発明では、タスク選択手段が、保証対象識別子の利用によって、実行対象となるタスクを選択できるので、簡易な構成により第１の本発明と同様の効果を得ることができる。
【００１８】
第９の本発明は、タスク管理装置であって、少なくともいずれかのタスクに含まれる複数の制御可能部分に付与されたこれら複数の制御可能部分の選択順位を識別するための順位識別子を取得する順位識別子取得手段を更に備え、前記判定手段が、判定対象となるタスクのうち選択される制御可能部分を前記順位識別子を利用しその選択順位に従って選択すると共に、その選択および前記判定を前記選択の対象を変えながら試行することを特徴とするタスク管理装置である。
【００１９】
第９の本発明では、判定手段が、判定対象となるタスクにおける制御可能部分を、順位識別子を利用しその選択順位に従って選択すると共に、その選択および前記判定を選択の対象を変えながら試行することにより、そのタスクに係る所要リソース量を更にきめ細やかに調整できる。
【００２０】
第１０の本発明は、タスク管理装置であって、所定の主タスクと、前記主タスクの実行が実行の条件となる従タスクと、を識別するための主従タスク識別子を取得する主従タスク識別子取得手段を更に備え、前記判定手段および前記タスク選択手段が、前記主従タスク識別子を利用して、前記主タスクを前記保証部分として処理し、前記従タスクを前記制御可能部分として処理することを特徴とするタスク管理装置である。
【００２１】
第１０の本発明では、互いに主従関係のある複数のタスクを、主従タスク識別子の利用によって保証部分や制御可能部分として処理できるので、タスク内での制御可能部分の処理とタスク間での主従関係の処理とを共通のアルゴリズムで実行できる。
【００２２】
第１１の本発明は、複数のタスクのいずれかを選択的に実行するマルチタスクシステムにおいて、各タスクの所要リソース量に基づいて各タスクの実行可能性を判定する判定ステップと、判定ステップの判定結果に基づいて実行対象となるタスクを選択するタスク選択ステップと、を含むタスク管理方法であって、少なくともいずれかのタスクについて規定された保証部分と制御可能部分との所要リソース量情報を取得する所要リソース量情報取得ステップを更に含み、前記判定ステップでは、少なくともいずれかの予約済みのタスクの処理レベルを前記制御可能部分の範囲内で仮想的に変更して前記判定を実行し、前記タスク選択ステップでは、実行可能と判定された処理レベルで前記選択を実行することを特徴とするタスク管理方法である。第１１の本発明によれば、第１の本発明と同様の効果を得ることができる。
【００２３】
第１２の本発明は、タスク管理方法であって、少なくともいずれかのタスクについてその保証部分と制御可能部分とを識別するための保証対象識別子を取得する保証対象識別子取得ステップを更に含み、前記タスク選択ステップでは、前記保証対象識別子を利用して、前記選択を行うことを特徴とするタスク管理方法である。第１２の本発明によれば、第８の本発明と同様の効果を得ることができる。
【００２４】
第１３の本発明は、タスク管理方法であって、少なくともいずれかのタスクに含まれる複数の制御可能部分に付与されたこれら複数の制御可能部分の選択順位を識別するための順位識別子を取得する順位識別子取得ステップを更に含み、前記判定ステップでは、判定対象となるタスクのうち選択される制御可能部分を前記順位識別子を利用しその選択順位に従って選択すると共に、その選択および前記判定を前記選択の対象を変えながら試行することを特徴とするタスク管理方法である。第１３の本発明によれば、第９の本発明と同様の効果を得ることができる。
【００２５】
第１４の本発明は、タスク管理方法であって、所定の主タスクと、前記主タスクの実行が実行の条件となる従タスクと、を識別するための主従タスク識別子を取得する主従タスク識別子取得ステップを更に含み、前記判定ステップおよび前記タスク選択ステップでは、前記主従タスク識別子を利用して、前記主タスクを前記保証部分として処理し、前記従タスクを前記制御可能部分として処理することを特徴とするタスク管理方法である。第１４の本発明によれば、第１０の本発明と同様の効果を得ることができる。
【００２６】
第１５の本発明は、複数のタスクのいずれかを選択的に実行するマルチタスクシステムにおいて、各タスクの所要リソース量に基づいて各タスクの実行可能性を判定する判定処理と、判定処理の判定結果に基づいて実行対象となるタスクを選択するタスク選択処理と、を前記システムに実行させるためのプログラムであって、少なくともいずれかのタスクについて規定された保証部分と制御可能部分との所要リソース量情報を取得する所要リソース量情報取得処理を更に含み、前記判定処理では、少なくともいずれかの予約済みのタスクの処理レベルを前記制御可能部分の範囲内で仮想的に変更して前記判定を実行し、前記タスク選択処理では、実行可能と判定された処理レベルで前記選択を実行することを特徴とするプログラムである。第１５の本発明では、第１の本発明と同様の効果を得ることができる。
【００２７】
本発明のタスク管理方法と関連して用いられるプログラムは、第１６の本発明のように、タスクの処理レベルの変更前後の所要リソース量を格納する所要リソース量情報格納手段を備えることとしたり、第１７の本発明のように、タスクの保証部分と制御可能部分とを識別するための保証対象識別子を備えることとしたり、第１８の本発明のように、タスクに含まれる複数の制御可能部分の順位を識別するための順位識別子を備えることとすれば、実行されるプログラムとこれに含まれるタスクの諸情報とを組として取り扱うことができ好適である。
【００２８】
また、本発明のタスク管理方法と関連して用いられるプログラムは、第１９の本発明のように、所定の主タスクを保証部分として前記システムに認識させ、前記主タスクの実行が実行の条件となる従タスクを制御可能部分として前記システムに認識させるように、前記保証対象識別子を備えることとすれば、互いに主従関係のある複数のタスクを、主従タスク識別子の利用によって保証部分や制御可能部分として処理できるので、タスク内での制御可能部分の処理とタスク間での主従関係の処理とを共通のアルゴリズムで実行できる。他方、第２０の本発明のように、保証対象識別子に代えて、主従関係の処理のための主従タスク識別子を備えることとしてもよい。
【００２９】
【発明の実施の形態】
本発明の実施形態について、以下に図面を参照して説明する。図１において、本発明の実施形態に係るマルチタスクシステム１は、ＣＰＵ２、タイマ３、例えばハードディスク装置等の記憶装置４、メモリ５、ネットワーク１１とのインタフェースとなるインタフェース制御部６を備えている。これらＣＰＵ２、タイマ３、記憶装置４、メモリ５、ネットワーク制御部６は、内部バス７で接続されている。
【００３０】
タイマ３は、設定された一定時間までの計時を繰り返すものであり、設定時間ごとにＣＰＵ２に割り込みをかけることにより、設定時間の経過をＣＰＵ２に通知することが可能である。記憶装置４にはタスクプログラム等が記録されており、必要に応じてメモリ５に読み出される。
【００３１】
本発明に係るタスク管理機能を実現するにはＣＰＵ制御が必要であり、タスク管理の機能をＯＳ（Operating System）に組み込む必要がある。そこで、メモリ５上には、後述するタスク受付処理をＣＰＵ２に実行させるためのタスク受付プログラムが格納されるタスク受付プログラム格納部８と、同様にタスク実行処理をＣＰＵ２に実行させるためのタスク実行プログラムが格納されるタスク実行プログラム格納部９が存在する。そして、これらプログラムを格納部８、９に格納することにより、本発明に係るタスク管理機能がＯＳに組み込まれる。
【００３２】
本実施形態におけるリソース量としては、ＣＰＵ２の使用時間が用いられる。なお、本発明におけるリソース量は、ＣＰＵ２のほかに記憶装置４やメモリ５、あるいは図示しないビデオメモリの使用時間および記憶容量、ネットワークの通信速度やネットワークサーバの記憶容量・メモリ容量など、特定のタスクを実行するために必要なハードウェア資源およびソフトウェア資源の全てを選択的に用いることができる。また、リソース量としては、タスクの種類および機能に応じて異なるものを利用でき、例えばタスクがデータ読込に係るものである場合にはＣＰＵ２の使用時間・ハードディスクの記憶容量・メモリの使用時間と記憶容量、タスクが復号処理に係るものである場合にはＣＰＵ２の使用時間・メモリの使用時間と記憶容量、タスクが映像出力に係るものである場合にはＣＰＵ２の使用時間・メモリの使用時間と記憶容量・ビデオメモリの使用時間と記憶容量を、それぞれリソース量として用いることができる。
【００３３】
本実施形態では、各タスクについて、予め保証部分と制御可能部分とが設定されている。例えば、タスクがＭＰ３音声再生プログラムである場合、保証部分は復号処理に係る処理部分であり、制御可能部分は、高音質化のための補完処理に係る処理部分である。
【００３４】
また、タスクがＭＰＥＧ動画再生プログラムである場合、保証部分は描画間隔１／１５秒のフレームレートに相当する処理部分であり、制御可能部分は、描画間隔１／３０秒のフレームレートに相当する処理部分である。なお、タスクが静止画または動画の再生プログラムである場合には、受認できる最低限の解像度に相当する処理部分を保証部分とし、それ以上の解像度に相当する処理部分を制御可能部分とする、というように解像度を調整するのも好適である。
【００３５】
また、アプリケーションがＷｅｂブラウザである場合、保証部分は、ネットワークタイムアウト時間内のパケット通信間隔の通信レートに相当する処理部分であり、制御可能部分は、より大きい通信レート、例えば（パケットサイズ）／（スループット）の通信レートに相当する処理部分である。
【００３６】
なお、本実施形態におけるアプリケーションプログラムでは、各タスクの保証部分のプログラム文と制御可能部分のプログラム文とが互いに分離して記述されており、また保証部分のメモリアドレスには、本発明における保証対象識別子としての所定の保証対象フラグが付されている。
【００３７】
また、各タスクの保証部分、すなわち最低限の割当を保証すべきリソース量は、実行されるハードウェアおよびソフトウェア環境におけるスケジューラプログラムの時間計測機能を用いて計測する。具体的には、最低限保証すべきリソース量は、対象となる処理が、割り当てタイミングごとに開始してから終了するまでに、各リソースを使用する時間を測定することによって予め計測される。また、各タスクのデッドラインは、割り当てタイミングから処理開始までの時間をずらし、品質が満足できなくなるまでの空白時間を測定することで計測できる。また、制御可能部分のリソース量は、各タスクの最高の処理品質による処理を実行しながら同様のスケジューラプログラムを利用した計測値から、保証部分の計測値を減算することで算出できる。これらのリソース量情報は、このような測定をシステム上で実際に行うことで取得してもよいし、アプリケーションプログラムのベンダーから提供される諸元値をそのまま利用してもよい。
【００３８】
さらに、メモリ５上には、リアルタイム性が要求されるタスク、すなわち遅延時間を小さくする必要のあるタスク（以下、このようなタスクを遅延保証が必要なタスクと呼ぶ）を管理するために、これら各タスクの情報を格納しておくためのタスク管理テーブル１０が存在する。
【００３９】
図２はタスク管理テーブル１０の一例を示す図である。タスク管理テーブル１０は、タスク情報管理テーブル２１とタスク実行管理テーブル２２とから構成される。
【００４０】
タスク情報管理テーブル２１は、後述するタスク受付処理で受付けられた遅延保証が必要なタスクに関する情報を管理するテーブルである。
【００４１】
このタスク情報管理テーブル２１に格納される情報には、タスク識別子格納部２１ａ、タスクポインタ格納部２１ｂ、周期格納部２１ｃ、保証部分処理時間格納部２１ｄ、制御部分処理時間格納部２１ｅ、許容遅延時間格納部２１ｆに格納されるタスク識別子ＩＤ、タスクポインタＰ、周期Ｓ、保証部分処理時間Ｇ、制御可能部分処理時間Ｃ、デッドラインＨ、があり、これらの情報がそれぞれタスクごとに格納されている。なお、図２では、横１列が１つのタスクに関する情報を示している。
【００４２】
タスク識別子ＩＤは、各タスクを識別するためのものであり、タスクポインタＰは、記憶装置４あるいはメモリ５上に存在する各タスクのプログラムの位置を指し示すものである。周期Ｓは、各タスクにおける実行開始時点から次の実行開始時点までの時間であり、あるタスクが実行されると、設定された周期Ｓの間、このタスクが新たに実行されることはない。
【００４３】
保証部分処理時間Ｇは、本発明における保証部分の所要リソース量であり、各タスクにおける保証部分の実行に要する処理時間である。制御可能部分処理時間Ｃは、本発明における制御可能部分の所要リソース量であり、各タスクにおける制御可能部分の実行に要する処理時間である。なお、これら保証部分処理時間Ｇ・制御可能部分処理時間Ｃは、予め設定されるサンプル値なので、実際のタスクがこれらの値より前に終了することもあり得る。
【００４４】
デッドラインＨは、その時間内で処理が完了すれば品質が満足されるような許容時間であって、周期Ｓで示される時間内に設定される。あるタスクに対してイベントが発行された状態で前回の実行開始時点からの経過時間が周期Ｓを超えたり、タスク処理が中断したりすると、このタスクに遅延が生じる。このような遅延の発生は、許容遅延時間Ｈを消費することを意味する。したがって、この許容遅延時間Ｈが全て消費される前にタスク処理が終了しなければならない。
【００４５】
なお、これらの周期Ｓ、保証部分処理時間Ｇ、制御可能部分処理時間Ｃ、デッドラインＨは、このタスク予約を要求したアプリケーションプログラムに予め格納されており、このアプリケーションプログラムの外部記憶媒体経由やネットワーク経由でのインストールにより記憶装置４に記憶され、後述するシステムコールによってＯＳに渡され、受付が許可されると、タスク識別子ＩＤ３が付与されてタスク情報管理テーブル２１に格納されることになる。
【００４６】
タスク実行管理テーブル２２は、受付けられたタスク、すなわちタスク情報管理テーブル２１に登録されたタスクの実行時に使用される情報を管理するテーブルである。このタスク実行管理テーブル２２に格納される情報としては、タスク識別子ＩＤ、実行識別フラグＦ、および部分実行フラグＦＰがあり、これらの情報はタスクごとに、それぞれタスク識別子格納部２２ａ、実行識別フラグ格納部２２ｂ、部分実行フラグ格納部２２ｃに格納される。
【００４７】
実行識別フラグＦは、実行中または実行を中断しているタスクを識別するためのものである。この実行識別フラグＦは、各タスクが実行中または実行中断状態ならばセットされ（例えば、「１」となる）、タスクの実行が終了した場合はリセットされる（例えば、「０」となる）。
【００４８】
部分実行フラグＦＰは、実行対象が保証部分のみであるタスクを識別するためのものである。この部分実行フラグＦＰは、各タスクの実行対象が保証部分のみであるならばセットされ（例えば、「１」となる）、各タスクの実行対象が保証部分と制御可能部分の両方である場合にはリセットされる（例えば、「０」となる）。
【００４９】
次に、遅延保証が必要なタスクの受付処理について、図３に従って説明する。例えばタスクＡ１，Ａ２，Ａ３について、予め所要リソース量ｒ１，ｒ２，ｒ３、保証部分に係る所要リソース量ｒ１ａ，ｒ２ａ，ｒ３ａ、制御可能部分に係る所要リソース量ｒ１ｂ，ｒ２ｂ，ｒ３ｂ、デッドラインＨ１，Ｈ２，Ｈ３が設定されている場合であって、タスクＡ１，Ａ２が既に予約されている場合において、いま、アプリケーションからのシステムコールにより、新規タスクＡ３の予約が要求されると、ＣＰＵ２は、タスク受付プログラム格納部８に格納されたプログラムに従って以下のような処理を実行する。
【００５０】
図３において、まずＣＰＵ２は、システムの現在のリソース量、既に受付けられた予約済みのタスクＡ１，Ａ２の保証部分・制御可能部分の各所要リソース量、および新規タスクＡ３の保証部分・制御可能部分の各所要リソース量を読み込む（Ｓ１）。予約済みのタスクＡ１，Ａ２の各所要リソース量は、タスク情報管理テーブル２１に登録された情報に基づいて、タスク管理テーブル１０から抽出される。また新規タスクＡ３の各所要リソース量は、システムコールと共に入力され、メモリ５の所定領域に保持されている。
【００５１】
次に、予約済みのタスクＡ１，Ａ２と、新たに予約が要求されたタスクＡ３の、全ての保証部分と制御可能部分（所要リソース量ｒ１＋ｒ２＋ｒ３）が実行可能かが、外的制約である各タスクのデッドラインＨ１，Ｈ２，Ｈ３との比較に基づいて判定される（Ｓ２）。
【００５２】
ステップＳ２で実行可能と判定された場合には、これらタスクＡ１，Ａ２，Ａ３の保証部分と制御可能部分とが、実行対象として選択され、タスク情報管理テーブル２１に登録される（Ｓ３）。
【００５３】
他方、図５（ａ）の例のように、各タスクＡ１，Ａ２，Ａ３の保証部分と制御可能部分とを順に実行したと仮定した場合にタスクＡ３についてデッドラインＨ３を満たせず遅れ時間を生じてしまうような場合には、ステップＳ２で実行不能と判定され、次に、要求されている全タスクの保証部分の所要リソース量として、各タスクの保証部分処理時間Ｇの合計が各タスクのデッドラインＨ１，Ｈ２，Ｈ３と比較され、これにより、全タスク（図５（ｃ）、所要リソース量ｒ１ａ＋ｒ２ａ＋ｒ３ａ）が実行可能かが判定される（Ｓ４）。
【００５４】
実行可能と判定された場合には、全タスクの保証部分のみが、実行対象として選択され、タスク情報管理テーブル２１に登録される（Ｓ５）。すなわち、要求された新規タスクＡ３と受付済みのタスクＡ１，Ａ２の遅延保証が可能な場合であるとして受付許可とされ、タスクＡ１，Ａ２，Ａ３の各タスク識別子ＩＤ１，ＩＤ２，ＩＤ３と、保証部分のみが実行対象である旨を示す部分実行フラグＦＰとが、メモリ５のタスク管理テーブル１０に書き込まれ、続いて、保証部分のみを実行対象として受付できた旨がアプリケーションに返答されて、受付処理が終了する。
【００５５】
ステップＳ４で実行不能と判定された場合には、新規タスクが予約できない場合であるとして、その旨の登録不可信号が出力され（Ｓ６）、また受付できない旨がアプリケーション側に通知される。なお、アプリケーションの処理により、新規タスクの登録ができない旨が、例えば図示しない表示装置における文字メッセージによってユーザに提示され、ユーザは不要なアプリケーションを閉じるなどしてこれに対処する。
【００５６】
以上の処理の結果、タスクＡ１，Ａ２，Ａ３が、それぞれデッドラインＨ１，Ｈ２，Ｈ３を満足しつつ、保証部分のみのリソース割当を確保して実行されることになる。なお、各タスクの実行の開始タイミングは、システムのスケジューラで制御されることになるので、例えばタスクが動画の表示に係るものである場合には、その実行は図６に示すように該当フレームの読込み（Ｓ１１）とフレーム出力（Ｓ１２）のように機能ごとに構成すれば足り、タイマ等を利用した各タスクの実行タイミング管理をアプリケーション側で行う必要はない。
【００５７】
以上のとおり、第１実施形態では、タスクＡ１，Ａ２，Ａ３そのものを保証部分と制御可能部分とに分けて段階的に設定し、後者を制御可能、つまり場合に応じて削除できる部分として扱うこととした。すなわち本実施形態では、予約済みのタスクＡ１，Ａ２の処理レベルを、制御可能部分を含む場合（Ｓ１）と含まない場合（Ｓ４）の両者の間で仮想的に変更しながら、新規に予約要求がされたタスクＡ３の実行可能性を判定すると共に、実行可能と判定された処理レベルで、実行対象となるタスクＡ１，Ａ２，Ａ３の選択を実行するようにした。したがって本実施形態では、予約済みのタスクＡ１，Ａ２について品質を調整することで、新規に予約要求がされたタスクＡ３を受付けて実行することができ、タスクの遅延保証とタスクの効率的な実行とを両立できる。
【００５８】
また本実施形態では、制御可能部分の付加または削除により、判定処理と品質の調整とを行うこととしたので、簡易な構成により本発明に所期の効果を得ることができる。
【００５９】
また本実施形態では、タスクの処理レベルの仮想的な変更を、全ての予約済みのタスクＡ１，Ａ２と予約が要求されているタスクＡ３とについて行うこととしたので、大きな変更量をとることにより要求リソース量の大きな変化を許容できる。
【００６０】
また本実施形態では、保証対象識別子の利用によって、実行対象となるタスクを選択できるので、簡易な構成により本発明に所期の効果を得ることができる。
【００６１】
なお、本実施形態では、各タスクの相互間の優先度を特に考慮せずにこれを選択する構成について説明したが、各タスクは所定の優先度（例えば、要求処理時間と許容遅延時間との和が大きいタスクほど処理の優先度を下げる、優先度の高いタスクの要求処理時間が優先度の低いタスクの許容遅延時間内に収まらなければならない等）に従って登録されることとしてもよい。
【００６２】
次に、第２実施形態について説明する。上記第１実施形態では、処理対象となるタスク数の変更要求があった場合に、所要リソース量を仮想的に変更しながら実行可能性の判定を行うこととした。しかし、タスク数の変更要求がなくても、例えば映像や音声の早送り再生の場合など、所要リソース量の変動が予想される場合があり、そのような場合であれば本発明における判定手段による判定、つまり所要リソース量を仮想的に変更しながらの実行可能性の判定を好適に実施できる。第２実施形態は、少なくともいずれかのタスクについてパラメータの変更要求、とくにデッドラインの変更要求があった場合に、このような判定を行うものである。なお、第２実施形態においても、マルチタスクシステムの構成は上記第１実施形態のものと同様であるため、その説明は省略する。
【００６３】
例えばタスクＡ１，Ａ２，Ａ３の実行中に、アプリケーションからのシステムコールにより、タスクＡ３のデッドラインの変更（例えば、標準値からの所定値の減算）が要求されると、ＣＰＵ２は、タスク受付プログラム格納部８に格納されたプログラムに従って以下のような処理を実行する。
【００６４】
図７において、まずＣＰＵ２は、システムの現在のリソース量、実行中のタスクＡ１，Ａ２，Ａ３のデッドライン、および保証部分・制御可能部分の各所要リソース量を読み込む（Ｓ２１）。
【００６５】
次に、現在の所要リソース量設定でデッドラインの変更が可能かが、デッドラインを仮想的に変更した場合のタスクＡ１，Ａ２，Ａ３の所要リソース量（保証部分と制御可能部分の両者についてのもの）と、外的制約である各タスクのデッドライン（変更後のもの）との比較に基づいて判定される（Ｓ２２）。
【００６６】
ステップＳ２２で実行可能と判定された場合には、現在の所要リソース量設定（すなわち、タスクＡ１，Ａ２，Ａ３の保証部分と制御可能部分とが選択された状態）で、タスクＡ３のデッドラインが変更され、タスク情報管理テーブル２１に登録される（Ｓ２３）。
【００６７】
他方、ステップＳ２２で実行不能と判定された場合には、次に、制御可能部分の範囲内で減少された所要リソース量設定（すなわち、保証部分のみについての所要リソース量）において、デッドラインの変更が可能かが、この場合の最適化演算および各タスクのデッドライン（変更後のもの）との比較に基づいて判定される（Ｓ２４）。
【００６８】
実行可能と判定された場合には、減少された所要リソース量設定が採用され（すなわち、全タスクの保証部分のみが実行対象として選択され）、その状態でデッドラインが変更されて、タスク情報管理テーブル２１に登録される（Ｓ２５）。すなわち、要求されたデッドライン変更がされた状態で、タスクＡ１，Ａ２，Ａ３の遅延保証が可能な場合であるとして受付許可とされ、タスクＡ１，Ａ２，Ａ３の各タスク識別子ＩＤ１，ＩＤ２，ＩＤ３と、保証部分のみが実行対象である旨を示す部分実行フラグＦＰとが、メモリ５のタスク管理テーブル１０に書き込まれ、続いて、保証部分のみを実行対象として受付できた旨がアプリケーションに返答されて、受付処理が終了する。
【００６９】
ステップＳ２４で実行不能と判定された場合には、デッドラインが変更できない場合であるとして、その旨の変更不可信号が出力され（Ｓ２６）、また受付できない旨がアプリケーション側に通知される。なお、アプリケーションの処理により、デッドラインの変更ができない旨が、例えば図示しない表示装置における文字メッセージによってユーザに提示され、ユーザは不要なアプリケーションを閉じるなどしてこれに対処する。
【００７０】
以上の処理の結果、タスクＡ１，Ａ２，Ａ３が、それぞれ変更されたデッドラインを満足しつつ、保証部分のみのリソース割当を確保して実行されることになる。したがって第２実施形態では、上記第１実施形態と同様に、タスクＡ１，Ａ２，Ａ３について品質を調整することで、デッドラインを変更して実行を継続でき、タスクの遅延保証とタスクの効率的な実行とを両立できる。
【００７１】
次に、第３実施形態について説明する。第３実施形態は、上記第２実施形態と同様にパラメータの変更要求に応じた実行可能性の判定を行うものであって、これを周期の変更要求があった場合に適用したものである。なお、第３実施形態においても、マルチタスクシステムの構成は上記第１実施形態のものと同様であるため、その説明は省略する。
【００７２】
例えばタスクＡ１，Ａ２，Ａ３の実行中に、アプリケーションからのシステムコールにより、タスクＡ３の周期の変更（例えば、標準値からの所定値の減算）が要求されると、ＣＰＵ２は、タスク受付プログラム格納部８に格納されたプログラムに従って以下のような処理を実行する。
【００７３】
図８において、まずＣＰＵ２は、システムの現在のリソース量、実行中のタスクＡ１，Ａ２，Ａ３の周期、および保証部分・制御可能部分の各所要リソース量を読み込む（Ｓ３１）。
【００７４】
次に、現在の所要リソース量設定で周期の変更が可能かが、周期を仮想的に変更した場合のタスクＡ１，Ａ２，Ａ３の所要リソース量（保証部分と制御可能部分の両者についてのもの）と、各タスクの実行周期（変更後のもの）との比較に基づいて判定される（Ｓ３２）。
【００７５】
ステップＳ３２で実行可能と判定された場合には、現在の所要リソース量設定（すなわち、タスクＡ１，Ａ２，Ａ３の保証部分と制御可能部分とが選択された状態）で、タスクＡ３の周期が変更され、タスク情報管理テーブル２１に登録される（Ｓ３３）。
【００７６】
他方、ステップＳ３２で実行不能と判定された場合には、次に、制御可能部分の範囲内で減少された所要リソース量設定（すなわち、保証部分のみについての所要リソース量）において、周期の変更が可能かが、この場合の最適化演算および各タスクの実行周期（変更後のもの）との比較に基づいて判定される（Ｓ３４）。
【００７７】
実行可能と判定された場合には、減少された所要リソース量設定が採用され（すなわち、全タスクの保証部分のみが実行対象として選択され）、その状態で周期が変更されて、タスク情報管理テーブル２１に登録される（Ｓ３５）。すなわち、要求された周期の変更がされた状態で、タスクＡ１，Ａ２，Ａ３の遅延保証が可能な場合であるとして受付許可とされ、タスクＡ１，Ａ２，Ａ３の各タスク識別子ＩＤ１，ＩＤ２，ＩＤ３と、保証部分のみが実行対象である旨を示す部分実行フラグＦＰとが、メモリ５のタスク管理テーブル１０に書き込まれ、続いて、保証部分のみを実行対象として受付できた旨がアプリケーションに返答されて、受付処理が終了する。
【００７８】
ステップＳ３４で実行不能と判定された場合には、周期が変更できない場合であるとして、その旨の変更不可信号が出力され（Ｓ６）、また受付できない旨がアプリケーション側に通知される。なお、アプリケーションの処理により、周期の変更ができない旨が、例えば図示しない表示装置における文字メッセージによってユーザに提示され、ユーザは不要なアプリケーションを閉じるなどしてこれに対処する。
【００７９】
以上の処理の結果、タスクＡ１，Ａ２，Ａ３が、それぞれ変更された周期を満足しつつ、保証部分のみのリソース割当を確保して実行されることになる。したがって第３実施形態では、上記第２実施形態と同様に、タスクＡ１，Ａ２，Ａ３について品質を調整することで、周期を変更して実行を継続でき、タスクの遅延保証とタスクの効率的な実行とを両立できる。
【００８０】
なお、上記各実施形態では、各タスクについての制御可能部分を１つとし、その保証部分への付加の有無によって所要リソース量を変更する構成としたが、各タスクについての制御可能部分は複数としてもよい。この場合には更に、複数設けられた制御可能部分に相互の選択順位を設定（付与）し、これら複数の制御可能部分がこの選択順位に従って選択されることとするのが好適であり、とくに、複数設けられた制御可能部分のうちの選択順位を識別するための所定の順位識別子（例えば、所定の順位フラグ）を、各タスクのプログラム文における各対応する部分に付すと共に、その各制御可能部分の所要リソース量情報を予めタスク情報管理テーブル２１に記憶させておき、動作の際には、判定対象となるタスクについて制御可能部分をその順位識別子が示す選択順位に従って選択すると共に、その選択および判定を選択の対象を変えながら（例えば、選択される制御可能部分の個数を変えながら）試行することとするのが好適である。このような構成とすれば、動作上の重要度の低い部分から処理対象を削除していくことで処理量を段階的に減少させつつ、実行可能性の判断を繰り返すことにより、そのタスクに係る所要リソース量を更にきめ細かに調整でき、またシステムのリソース量の有効利用を図ることができる。
【００８１】
また、上記第１ないし第３実施形態では、タスク内での制御可能部分を利用した増減によって所要リソース量を調整したが、このような所要リソース量の調整は、実行順序に依存関係があり互いに主従関係にある複数のタスク間での動作の調整にも適用できる。
【００８２】
すなわち、所定の主タスクと、この主タスクの実行が実行の条件となるような従タスクとがある場合に、上記第１実施形態において用いられていたものと同様の保証対象フラグを主タスクの全体に付し、また従タスクには保証対象フラグを付さない構成とする。このような主タスクと従タスクとについて、上記第１実施形態におけるタスク受付プログラムをそのまま実行させた場合には、主タスクの全体が保証部分として、また従タスクの全体が制御可能部分として、それぞれシステムに認識されることになる。その結果、リソース量に余裕がある場合には、主タスクと従タスクの両方が実行され、またリソース量に余裕がない場合には、主タスクのみが実行されることになり、これによって、タスク内での制御可能部分の処理とタスク間での主従関係の処理とを共通のアルゴリズムで実行でき、また、主タスクと従タスクとを併せて一つのタスクとして扱うことができるためタスク数の節約を図ることができる。
【００８３】
なお、このようにタスク内での保証部分と制御可能部分との識別に用いられる保証対象識別子としての保証対象フラグを利用する構成に代えて、専ら主タスクと従タスクとの識別のために利用される所定の主従タスク識別子（例えば、主従フラグ）を、主タスクと従タスクの一方または両方に設け、またタスク受付プログラムが、主タスクを保証部分として処理し、従タスクを制御可能部分として処理することとしてもよく、同様の効果を得ることができる。
【００８４】
本発明のタスク管理装置と関連して用いられるプログラムは、第１２の本発明のように、タスクの処理レベルの変更前後の所要リソース量を格納する所要リソース量情報格納手段を備えることとしたり、第１３の本発明のように、タスクの保証部分と制御可能部分とを識別するための保証対象識別子を備えることとしたり、第１４の本発明のように、タスクに含まれる複数の制御可能部分の順位を識別するための順位識別子を備えることとすれば、実行されるプログラムとこれに含まれるタスクの諸情報とを組として取り扱うことができ好適である。
【００８５】
また、本発明のタスク管理装置と関連して用いられるプログラムは、第１５の本発明のように、所定の主タスクを保証部分として前記システムに認識させ、前記主タスクの実行が実行の条件となる従タスクを制御可能部分として前記システムに認識させるように、前記保証対象識別子を備えることとすれば、互いに主従関係のある複数のタスクを、主従タスク識別子の利用によって保証部分や制御可能部分として処理できるので、タスク内での制御可能部分の処理とタスク間での主従関係の処理とを共通のアルゴリズムで実行できる。他方、第１６の本発明のように、保証対象識別子に代えて、主従関係の処理のための主従タスク識別子を備えることとしてもよい。
【００８６】
なお、上記各実施形態では、制御可能部分を全体として仮想的に削除することで処理量を調整する構成としたが、逆に、リソース量に余裕がある場合（すなわち、例えば、現在の提供可能なリソース量と現在の全タスクの所要リソース量の合計との差が所定値を上回る場合）に、処理品質を上げるような追加的な制御可能部分を、全てのタスクに付加する構成としてもよい。また、上記各実施形態では、リソース量の余裕の有無に応じて、タスクの処理品質を段階的に増減変更する構成について説明したが、タスクの処理品質は無段階的に増減変更することとしてもよい。
【００８７】
また、上記各実施形態では、全てのタスクについて処理品質を変更することとしたので、要求リソース量の大きな変化を許容できるという利点があるが、本発明における処理品質の変更は一部のタスクについて実行することとしてもよく、このような構成によっても本発明に所期の効果を相当程度に実現できる。
【００８８】
また、本発明におけるタスク受付プログラムは、複数のタスクのいずれかを選択的に実行するマルチタスクシステムにおいて、各タスクの所要リソース量に基づいて各タスクの実行可能性を判定する判定処理と、判定処理の判定結果に基づいて実行対象となるタスクを選択するタスク選択処理と、を前記システムに実行させるためのプログラムであって、少なくともいずれかのタスクについて規定された保証部分と制御可能部分との所要リソース量情報を取得する所要リソース量情報取得処理を更に含み、前記判定処理では、少なくともいずれかの予約済みのタスクの処理レベルを前記制御可能部分の範囲内で仮想的に変更して前記判定を実行し、前記タスク選択処理では、実行可能と判定された処理レベルで前記選択を実行することを特徴とするプログラムとして構成でき、これをＣＤ−ＲＯＭなどの公知の記録媒体に記録した状態で、あるいはネットワーク経由のダウンロードによって取引でき、本発明の効果を実現するための有用な手段として用いることができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態に係るマルチタスクシステムのブロック図である。
【図２】タスク管理テーブルの一例を示す説明図である。
【図３】第１実施形態におけるタスク受付処理を示すフロー図である。
【図４】本発明の作用を示す説明図である。
【図５】第１実施形態の作用を示す説明図である。
【図６】第１実施形態における画像の表示処理を示すフロー図である。
【図７】第２実施形態におけるデッドライン変更受付処理を示すフロー図である。
【図８】第３実施形態における周期変更受付処理を示すフロー図である。
【図９】本発明による改良前のタスク受付処理の一例を示す説明図である。
【図１０】本発明による改良前のタスク受付処理の他の一例を示す説明図である。
【符号の説明】
１マルチタスクシステム、２ＣＰＵ、３タイマ、４記憶装置、５メモリ、６インタフェース制御部、７内部バス、１０タスク管理テーブル、１１ネットワーク、２１タスク情報管理テーブル、２２タスク実行管理テーブル。

Claims

複数のタスクのいずれかを選択的に実行するマルチタスクシステムにおいて、各タスクの所要リソース量に基づいて各タスクの実行可能性を判定する判定手段と、判定手段の判定結果に基づいて実行対象となるタスクを選択するタスク選択手段と、を備えたタスク管理装置であって、
少なくともいずれかのタスクについて規定された保証部分と制御可能部分との所要リソース量情報を取得する所要リソース量情報取得手段を更に備え、
前記判定手段は、
予約済みのタスクのうち、実行が開始されていないタスクの少なくともいずれかのタスクのみについて、その保証部分と制御可能部分との両者が実行可能かを、新規タスクの予約要求があった際に判定する第１判定手段と、
前記第１判定手段によって不可との判定があった場合に、前記第１判定手段で不可と判定された前記実行が開始されていないタスクについて、その保証部分が実行可能かを判定する第２判定手段と、
を備え、
前記タスク選択手段は、
前記第１判定手段により実行可能と判定された前記実行が開始されていないタスクにつきその保証部分と制御可能部分との両者を実行対象として選択し、
前記第２判定手段により実行可能と判定された前記実行が開始されていないタスクにつきその保証部分のみを実行対象として選択することを特徴とするタスク管理装置。
請求項１に記載のタスク管理装置であって、
前記判定手段が、実行が開始されていない予約済みのタスクの全てについて、前記第１判定手段及び第２判定手段による判定を実行することを特徴とするタスク管理装置。
請求項１または２に記載のタスク管理装置であって、
前記判定手段による判定が、処理対象となるタスク数の変更要求があった場合に実行されることを特徴とするタスク管理装置。
請求項１ないし３のいずれか１に記載のタスク管理装置であって、
前記判定手段による判定が、少なくともいずれかのタスクについてパラメータの変更要求があった場合に実行されることを特徴とするタスク管理装置。
請求項４に記載のタスク管理装置であって、
前記パラメータが前記少なくともいずれかのタスクのデッドラインであることを特徴とするタスク管理装置。
請求項４に記載のタスク管理装置であって、
前記パラメータが前記少なくともいずれかのタスクの実行周期であることを特徴とするタスク管理装置。
請求項１ないし６のいずれか１に記載のタスク管理装置であって、
少なくともいずれかのタスクについてその保証部分と制御可能部分とを識別するための保証対象識別子を取得する保証対象識別子取得手段を更に備え、
前記タスク選択手段が、前記保証対象識別子を利用して、前記選択を行うことを特徴とするタスク管理装置。
請求項１ないし７のいずれかに記載のタスク管理装置であって、
少なくともいずれかのタスクに含まれる複数の制御可能部分に付与されたこれら複数の制御可能部分の選択順位を識別するための順位識別子を取得する順位識別子取得手段を更に備え、
前記判定手段が、判定対象となるタスクのうち選択される制御可能部分を前記順位識別子を利用しその選択順位に従って選択すると共に、その選択および前記判定を前記選択の対象を変えながら試行することを特徴とするタスク管理装置。
請求項１ないし８のいずれか１に記載のタスク管理装置であって、
所定の主タスクと、前記主タスクの実行が実行の条件となる従タスクと、を識別するための主従タスク識別子を取得する主従タスク識別子取得手段を更に備え、
前記判定手段および前記タスク選択手段が、前記主従タスク識別子を利用して、前記主タスクを前記保証部分として処理し、前記従タスクを前記制御可能部分として処理することを特徴とするタスク管理装置。
複数のタスクのいずれかを選択的に実行するマルチタスクシステムにおいて、各タスクの所要リソース量に基づいて各タスクの実行可能性を判定する判定ステップと、判定ステップの判定結果に基づいて実行対象となるタスクを選択するタスク選択ステップと、を含むタスク管理方法であって、
少なくともいずれかのタスクについて規定された保証部分と制御可能部分との所要リソース量情報を取得する所要リソース量情報取得ステップを更に含み、
前記判定ステップは、
予約済みのタスクのうち、実行が開始されていないタスクの少なくともいずれかのタスクのみについて、その保証部分と制御可能部分との両者が実行可能かを、新規タスクの予約要求があった際に判定する第１判定ステップと、
前記第１判定ステップによって不可との判定があった場合に、前記第１判定ステップで不可と判定された前記実行が開始されていないタスクについて、その保証部分が実行可能かを判定する第２判定ステップと、
を含み、
前記タスク選択ステップは、
前記第１判定ステップにより実行可能と判定された前記実行が開始されていないタスクにつきその保証部分と制御可能部分との両者を実行対象として選択し、
前記第２判定ステップにより実行可能と判定された前記実行が開始されていないタスクにつきその保証部分のみを実行対象として選択することを特徴とするタスク管理方法。
請求項１０に記載のタスク管理方法であって、
少なくともいずれかのタスクについてその保証部分と制御可能部分とを識別するための保証対象識別子を取得する保証対象識別子取得ステップを更に含み、
前記タスク選択ステップでは、前記保証対象識別子を利用して、前記選択を行うことを特徴とするタスク管理方法。
請求項１０または１１に記載のタスク管理方法であって、
少なくともいずれかのタスクに含まれる複数の制御可能部分に付与されたこれら複数の制御可能部分の選択順位を識別するための順位識別子を取得する順位識別子取得ステップを更に含み、
前記判定ステップでは、判定対象となるタスクのうち選択される制御可能部分を前記順位識別子を利用しその選択順位に従って選択すると共に、その選択および前記判定を前記選択の対象を変えながら試行することを特徴とするタスク管理方法。
請求項１０ないし１２のいずれか１に記載のタスク管理方法であって、
所定の主タスクと、前記主タスクの実行が実行の条件となる従タスクと、を識別するための主従タスク識別子を取得する主従タスク識別子取得ステップを更に含み、
前記判定ステップおよび前記タスク選択ステップでは、前記主従タスク識別子を利用して、前記主タスクを前記保証部分として処理し、前記従タスクを前記制御可能部分として処理することを特徴とするタスク管理方法。
複数のタスクのいずれかを選択的に実行するマルチタスクシステムにおいて、各タスクの所要リソース量に基づいて各タスクの実行可能性を判定する判定処理と、判定処理の判定結果に基づいて実行対象となるタスクを選択するタスク選択処理と、を前記システムに実行させるためのプログラムであって、
少なくともいずれかのタスクについて規定された保証部分と制御可能部分との所要リソース量情報を取得する所要リソース量情報取得処理を更に含み、
前記判定処理は、
予約済みのタスクのうち、実行が開始されていないタスクの少なくともいずれかのタスクのみについて、その保証部分と制御可能部分との両者が実行可能かを、新規タスクの予約要求があった際に判定する第１判定処理と、
前記第１判定処理によって不可との判定があった場合に、前記第１判定処理で不可と判定された前記実行が開始されていないタスクについて、その保証部分が実行可能かを判定する第２判定処理と、
を含み、
前記タスク選択処理では、
前記第１判定処理により実行可能と判定された前記実行が開始されていないタスクにつきその保証部分と制御可能部分との両者を実行対象として選択し、
前記第２判定処理により実行可能と判定された前記実行が開始されていないタスクにつきその保証部分のみを実行対象として選択することを特徴とするプログラム。