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

Abstract

(57)【要約】 【課題】 タスクの遅延保証とタスクの効率的な実行と
を両立する。 【解決手段】 タスクＡ１，Ａ２，Ａ３そのものを保証
部分と制御可能部分とに分けて段階的に設定し、後者を
制御可能、つまり場合に応じて削除できる部分として扱
うこととした。予約済みのタスクＡ１，Ａ２の処理レベ
ルを、制御可能部分を含む場合と含まない場合の両者の
間で仮想的に変更しながら、新規に予約要求がされたタ
スクＡ３の実行可能性を判定すると共に、実行可能と判
定された処理レベルで、実行対象となるタスクＡ１，Ａ
２，Ａ３の選択を実行するようにした。予約済みのタス
クＡ１，Ａ２について品質を調整することで、新規に予
約要求がされたタスクＡ３を受付けて実行でき、タスク
の遅延保証とタスクの効率的な実行とを両立できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、マルチタスクシス
テムにおけるタスク管理装置およびプログラムに関し、
特にシステムのリソース量に応じた実行保証機能を有す
るものに関する。

【０００２】

【従来の技術】コンピュータ間通信において、動画や音
声といったリアルタイム情報の通信を行いたいという要
求は近年、一段と増している。動画や音声を扱うリアル
タイム通信端末では、例えば相手側の端末から動画や音
声といった情報を受信するタスク、受信した情報を表示
するタスク、相手側の端末に対して情報を送信するタス
ク等の複数のタスクを実行しなければならない。したが
って、この端末は、リアルタイム処理を必要とする複数
のタスクを実行するマルチタスクシステムとなり、この
ようなマルチタスクシステムにおいて、サービス品質
（Ｑｏｓ；Qualityof service）の保証が必要となる。

【０００３】このようなマルチタスクシステムにおい
て、サービス品質を保証する技術としては、ＯＳ（Oper
ating System）のタスク優先度設定機能を用いて、動画
や音声といった情報を扱うリアルタイム性を要求される
タスクの優先度を他のタスクより高く設定して、遅延要
求の厳しいタスクの処理を優先させるという手法が一般
的に使用されている。また、サービス品質を保証する他
の技術として、実行終了目標時刻が設定されたタスクに
ついて、その実行終了目標時刻が近づくほど優先度を上
げて優先的に処理することにより、タスク処理を実行終
了目標時刻までに完了させるという手法も提案されてい
る（特開昭６２−２８４４３７号公報）。

【０００４】

【発明が解決しようとする課題】しかし、いずれの従来
技術も、実行の予約が要求されているタスクの所要リソ
ース量の合計が、その時点でシステムが提供可能なリソ
ース量を上回る場合には、処理能力を超えたタスクをシ
ステムが実行しようとしてしまい、優先度の低いタスク
や新規に実行の予約が要求されたタスクを実行できな
い、あるいは全てのタスクを実行できないか、遅延が許
容される所定のデッドライン内に実行できないことにな
る。

【０００５】例えば、図９（ａ）に示すように、ある時
点でシステムが提供できるリソース量Ｒ１が、要求され
ているタスクの合計の所要リソース量がｒ１＋ｒ２より
大である場合には、システムは実行が要求されている全
てのタスクを実行できる。しかし、この状態から、図９
（ｂ）に示すように所要リソース量ｒ３の追加のタスク
の処理が要求された場合には、合計の所要リソース量ｒ
１＋ｒ２＋ｒ３が、提供できるリソース量Ｒ１を上回る
ため、追加のタスクの受付がリジェクトされるか、ある
いは全てのタスクの受付がリジェクトされることにな
る。

【０００６】また、図１０（ａ）〜（ｃ）に示すよう
に、周期がＳ１、要求処理時間がＴ１、デッドライン
（その時間内で処理が完了すれば品質が満足されるよう
な許容時間、許容遅延時間）がＨ１に設定されたタスク
Ａ１，Ａ２，Ａ３がある場合についてみると、タスクＡ
１およびタスクＡ２は、両者をこの順で実行する場合に
それぞれのデッドラインを満足（デッドライン以前に処
理を終了）できるため、共に実行可能である。しかし、
タスクＡ１，Ａ２，Ａ３をこの順で実行する場合には、
タスクＡ１，Ａ２のデッドラインを満足できてもタスク
Ａ３のデッドラインを満足できないため、タスクＡ３は
実行できないことになる。

【０００７】そこで本発明の目的は、タスクの遅延保証
とタスクの効率的な実行とを両立できる手段を提供する
ことを目的とする。

【０００８】

【課題を解決するための手段】第１の本発明は、請求項
１に記載のとおり、複数のタスクのいずれかを選択的に
実行するマルチタスクシステムにおいて、各タスクの所
要リソース量に基づいて各タスクの実行可能性を判定す
る判定手段と、判定手段の判定結果に基づいて実行対象
となるタスクを選択するタスク選択手段と、を備えたタ
スク管理装置であって、少なくともいずれかのタスクに
ついて規定された保証部分と制御可能部分との所要リソ
ース量情報を取得する所要リソース量情報取得手段を更
に備え、前記判定手段は、少なくともいずれかの予約済
みのタスクの処理レベルを前記制御可能部分の範囲内で
仮想的に変更して前記判定を実行し、前記タスク選択手
段は、実行可能と判定された処理レベルで前記選択を実
行することを特徴とするタスク管理装置である。

【０００９】タスクの中には、例えば画像における解像
度や、動画におけるフレームレート（秒あたりの描画
数）など、ある程度の実行品質の低下がユーザに許容で
きる場合が少なくない。したがって、優先度の高いタス
クや現在実行中であるタスクに、いわば削れる部分があ
るにも関わらず、優先度の低いタスクや新規に予約要求
がされたタスクがリジェクトされるのでは不合理といえ
る。

【００１０】この点、第１の本発明では、タスクそのも
のを保証部分と制御可能部分とに分けて段階的に設定
し、後者を制御可能、つまり場合に応じて付加・削除・
増加または減少できる部分として扱うこととした。すな
わち第１の本発明では、判定手段が、各タスクの所要リ
ソース量に基づいて、少なくともいずれかの予約済みの
タスクの処理レベルを制御可能部分の範囲内で仮想的に
変更して各タスクの実行可能性を判定すると共に、タス
ク選択手段が、実行可能と判定された処理レベルで、実
行対象となるタスクの選択を実行するようにしたので、
システムのリソース量、各タスクのデッドラインや実行
周期などの外的制約がある場合にも、予約済みのタスク
について品質を調整することで、優先度の低いタスクや
新規に予約要求がされたタスクを受付けて実行すること
ができ、タスクの遅延保証とタスクの効率的な実行とを
両立できる。

【００１１】第２の本発明は、請求項２に記載のとお
り、請求項１に記載のタスク管理装置であって、前記判
定手段は、少なくともいずれかの予約済みのタスクにお
ける保証部分と制御可能部分との両者が実行可能かを判
定する第１判定手段と、第１判定手段によって不可との
判定があった場合に、前記予約済みのタスクにおける保
証部分が実行可能かを判定する第２判定手段と、を備
え、前記タスク選択手段は、第１判定手段により実行可
能と判定された前記予約済みのタスクにつきその保証部
分と制御可能部分との両者を選択し、第２判定手段によ
り実行可能と判定された前記予約済みのタスクにつきそ
の保証部分のみを選択することを特徴とするタスク管理
装置である。

【００１２】第２の本発明では、制御可能部分の付加ま
たは削除により、判定処理と品質の調整とを行うことと
した。すなわち、図４（ａ）に示すように、各タスクの
所要リソース量ｒ１，ｒ２を、予め保証部分に係る所要
リソース量ｒ１ａ，ｒ２ａと、制御可能部分に係る所要
リソース量ｒ１ｂ，ｒ２ｂとに分割して設定しておき、
例えば所要リソース量ｒ３の新たなタスク（図４
（ｂ））の登録の要求があった場合などには、まず、要
求されている全タスクの保証部分と制御可能部分（所要
リソース量ｒ１＋ｒ２＋ｒ３）が実行可能かを判定し、
実行可能と判定された場合にはその保証部分と制御可能
部分とが選択される。他方、保証部分と制御可能部分と
が実行不能と判定された場合、次に、要求されている全
タスクの保証部分のみ（図４（ｃ）、所要リソース量ｒ
１ａ＋ｒ２ａ＋ｒ３ａ）が実行可能かが判定され、実行
可能と判定された場合には全タスクの保証部分のみが選
択される。このように第２の本発明では、制御可能部分
の付加または削除によって所要リソース量を調整するの
で、簡易な構成により第１の本発明と同様の効果を得る
ことができる。

【００１３】第３の本発明は、請求項３に記載のとお
り、請求項１または２に記載のタスク管理装置であっ
て、前記判定手段が、全ての予約済みのタスクについ
て、処理レベルを前記制御可能部分の範囲内で仮想的に
変更することを特徴とするタスク管理装置である。

【００１４】第３の本発明では、処理レベルの仮想的な
変更を、全ての予約済みのタスクについて行うこととし
たので、大きな変更量をとることにより要求リソース量
の大きな変化を許容できる。

【００１５】本発明における判定手段による判定は、所
要リソース量の変動が予想される場合に行うのが特に好
適であり、第４の本発明のように処理対象となるタスク
数の変更要求があった場合に行うこととしたり、第５の
本発明のように少なくともいずれかのタスクについてパ
ラメータの変更要求があった場合に行うこととしてもよ
い。また、第５の本発明におけるパラメータは、第６の
本発明のように前記少なくともいずれかのタスクのデッ
ドラインとしたり、第７の本発明のように前記少なくと
もいずれかのタスクの実行周期とするのが好適である。

【００１６】第８の本発明は、請求項８に記載のとお
り、請求項１ないし７のいずれか１に記載のタスク管理
装置であって、少なくともいずれかのタスクについてそ
の保証部分と制御可能部分とを識別するための保証対象
識別子を取得する保証対象識別子取得手段を更に備え、
前記タスク選択手段が、前記保証対象識別子を利用し
て、前記選択を行うことを特徴とするタスク管理装置で
ある。

【００１７】第８の本発明では、タスク選択手段が、保
証対象識別子の利用によって、実行対象となるタスクを
選択できるので、簡易な構成により第１の本発明と同様
の効果を得ることができる。

【００１８】第９の本発明は、請求項９に記載のとお
り、請求項１ないし８のいずれかに記載のタスク管理装
置であって、少なくともいずれかのタスクに含まれる複
数の制御可能部分に付与されたこれら複数の制御可能部
分の選択順位を識別するための順位識別子を取得する順
位識別子取得手段を更に備え、前記判定手段が、判定対
象となるタスクのうち選択される制御可能部分を前記順
位識別子を利用しその選択順位に従って選択すると共
に、その選択および前記判定を前記選択の対象を変えな
がら試行することを特徴とするタスク管理装置である。

【００１９】第９の本発明では、判定手段が、判定対象
となるタスクにおける制御可能部分を、順位識別子を利
用しその選択順位に従って選択すると共に、その選択お
よび前記判定を選択の対象を変えながら試行することに
より、そのタスクに係る所要リソース量を更にきめ細や
かに調整できる。

【００２０】第１０の本発明は、請求項１０に記載のと
おり、請求項１ないし９のいずれか１に記載のタスク管
理装置であって、所定の主タスクと、前記主タスクの実
行が実行の条件となる従タスクと、を識別するための主
従タスク識別子を取得する主従タスク識別子取得手段を
更に備え、前記判定手段および前記タスク選択手段が、
前記主従タスク識別子を利用して、前記主タスクを前記
保証部分として処理し、前記従タスクを前記制御可能部
分として処理することを特徴とするタスク管理装置であ
る。

【００２１】第１０の本発明では、互いに主従関係のあ
る複数のタスクを、主従タスク識別子の利用によって保
証部分や制御可能部分として処理できるので、タスク内
での制御可能部分の処理とタスク間での主従関係の処理
とを共通のアルゴリズムで実行できる。

【００２２】第１１の本発明は、請求項１１に記載のと
おり、複数のタスクのいずれかを選択的に実行するマル
チタスクシステムにおいて、各タスクの所要リソース量
に基づいて各タスクの実行可能性を判定する判定ステッ
プと、判定ステップの判定結果に基づいて実行対象とな
るタスクを選択するタスク選択ステップと、を含むタス
ク管理方法であって、少なくともいずれかのタスクにつ
いて規定された保証部分と制御可能部分との所要リソー
ス量情報を取得する所要リソース量情報取得ステップを
更に含み、前記判定ステップでは、少なくともいずれか
の予約済みのタスクの処理レベルを前記制御可能部分の
範囲内で仮想的に変更して前記判定を実行し、前記タス
ク選択ステップでは、実行可能と判定された処理レベル
で前記選択を実行することを特徴とするタスク管理方法
である。第１１の本発明によれば、第１の本発明と同様
の効果を得ることができる。

【００２３】第１２の本発明は、請求項１２に記載のと
おり、請求項１１に記載のタスク管理方法であって、少
なくともいずれかのタスクについてその保証部分と制御
可能部分とを識別するための保証対象識別子を取得する
保証対象識別子取得ステップを更に含み、前記タスク選
択ステップでは、前記保証対象識別子を利用して、前記
選択を行うことを特徴とするタスク管理方法である。第
１２の本発明によれば、第８の本発明と同様の効果を得
ることができる。

【００２４】第１３の本発明は、請求項１３に記載のと
おり、請求項１１または１２に記載のタスク管理方法で
あって、少なくともいずれかのタスクに含まれる複数の
制御可能部分に付与されたこれら複数の制御可能部分の
選択順位を識別するための順位識別子を取得する順位識
別子取得ステップを更に含み、前記判定ステップでは、
判定対象となるタスクのうち選択される制御可能部分を
前記順位識別子を利用しその選択順位に従って選択する
と共に、その選択および前記判定を前記選択の対象を変
えながら試行することを特徴とするタスク管理方法であ
る。第１３の本発明によれば、第９の本発明と同様の効
果を得ることができる。

【００２５】第１４の本発明は、請求項１４に記載のと
おり、請求項１１ないし１３のいずれか１に記載のタス
ク管理方法であって、所定の主タスクと、前記主タスク
の実行が実行の条件となる従タスクと、を識別するため
の主従タスク識別子を取得する主従タスク識別子取得ス
テップを更に含み、前記判定ステップおよび前記タスク
選択ステップでは、前記主従タスク識別子を利用して、
前記主タスクを前記保証部分として処理し、前記従タス
クを前記制御可能部分として処理することを特徴とする
タスク管理方法である。第１４の本発明によれば、第１
０の本発明と同様の効果を得ることができる。

【００２６】第１５の本発明は、請求項１５に記載のと
おり、複数のタスクのいずれかを選択的に実行するマル
チタスクシステムにおいて、各タスクの所要リソース量
に基づいて各タスクの実行可能性を判定する判定処理
と、判定処理の判定結果に基づいて実行対象となるタス
クを選択するタスク選択処理と、を前記システムに実行
させるためのプログラムであって、少なくともいずれか
のタスクについて規定された保証部分と制御可能部分と
の所要リソース量情報を取得する所要リソース量情報取
得処理を更に含み、前記判定処理では、少なくともいず
れかの予約済みのタスクの処理レベルを前記制御可能部
分の範囲内で仮想的に変更して前記判定を実行し、前記
タスク選択処理では、実行可能と判定された処理レベル
で前記選択を実行することを特徴とするプログラムであ
る。第１５の本発明では、第１の本発明と同様の効果を
得ることができる。

【００２７】本発明のタスク管理方法と関連して用いら
れるプログラムは、第１６の本発明のように、タスクの
処理レベルの変更前後の所要リソース量を格納する所要
リソース量情報格納手段を備えることとしたり、第１７
の本発明のように、タスクの保証部分と制御可能部分と
を識別するための保証対象識別子を備えることとした
り、第１８の本発明のように、タスクに含まれる複数の
制御可能部分の順位を識別するための順位識別子を備え
ることとすれば、実行されるプログラムとこれに含まれ
るタスクの諸情報とを組として取り扱うことができ好適
である。

【００２８】また、本発明のタスク管理方法と関連して
用いられるプログラムは、第１９の本発明のように、所
定の主タスクを保証部分として前記システムに認識さ
せ、前記主タスクの実行が実行の条件となる従タスクを
制御可能部分として前記システムに認識させるように、
前記保証対象識別子を備えることとすれば、互いに主従
関係のある複数のタスクを、主従タスク識別子の利用に
よって保証部分や制御可能部分として処理できるので、
タスク内での制御可能部分の処理とタスク間での主従関
係の処理とを共通のアルゴリズムで実行できる。他方、
第２０の本発明のように、保証対象識別子に代えて、主
従関係の処理のための主従タスク識別子を備えることと
してもよい。

【００２９】

【発明の実施の形態】本発明の実施形態について、以下
に図面を参照して説明する。図１において、本発明の実
施形態に係るマルチタスクシステム１は、ＣＰＵ２、タ
イマ３、例えばハードディスク装置等の記憶装置４、メ
モリ５、ネットワーク１１とのインタフェースとなるイ
ンタフェース制御部６を備えている。これらＣＰＵ２、
タイマ３、記憶装置４、メモリ５、ネットワーク制御部
６は、内部バス７で接続されている。

【００３０】タイマ３は、設定された一定時間までの計
時を繰り返すものであり、設定時間ごとにＣＰＵ２に割
り込みをかけることにより、設定時間の経過をＣＰＵ２
に通知することが可能である。記憶装置４にはタスクプ
ログラム等が記録されており、必要に応じてメモリ５に
読み出される。

【００３１】本発明に係るタスク管理機能を実現するに
はＣＰＵ制御が必要であり、タスク管理の機能をＯＳ
（Operating System）に組み込む必要がある。そこで、
メモリ５上には、後述するタスク受付処理をＣＰＵ２に
実行させるためのタスク受付プログラムが格納されるタ
スク受付プログラム格納部８と、同様にタスク実行処理
をＣＰＵ２に実行させるためのタスク実行プログラムが
格納されるタスク実行プログラム格納部９が存在する。
そして、これらプログラムを格納部８、９に格納するこ
とにより、本発明に係るタスク管理機能がＯＳに組み込
まれる。

【００３２】本実施形態におけるリソース量としては、
ＣＰＵ２の使用時間が用いられる。なお、本発明におけ
るリソース量は、ＣＰＵ２のほかに記憶装置４やメモリ
５、あるいは図示しないビデオメモリの使用時間および
記憶容量、ネットワークの通信速度やネットワークサー
バの記憶容量・メモリ容量など、特定のタスクを実行す
るために必要なハードウェア資源およびソフトウェア資
源の全てを選択的に用いることができる。また、リソー
ス量としては、タスクの種類および機能に応じて異なる
ものを利用でき、例えばタスクがデータ読込に係るもの
である場合にはＣＰＵ２の使用時間・ハードディスクの
記憶容量・メモリの使用時間と記憶容量、タスクが復号
処理に係るものである場合にはＣＰＵ２の使用時間・メ
モリの使用時間と記憶容量、タスクが映像出力に係るも
のである場合にはＣＰＵ２の使用時間・メモリの使用時
間と記憶容量・ビデオメモリの使用時間と記憶容量を、
それぞれリソース量として用いることができる。

【００３３】本実施形態では、各タスクについて、予め
保証部分と制御可能部分とが設定されている。例えば、
タスクがＭＰ３音声再生プログラムである場合、保証部
分は復号処理に係る処理部分であり、制御可能部分は、
高音質化のための補完処理に係る処理部分である。

【００３４】また、タスクがＭＰＥＧ動画再生プログラ
ムである場合、保証部分は描画間隔１／１５秒のフレー
ムレートに相当する処理部分であり、制御可能部分は、
描画間隔１／３０秒のフレームレートに相当する処理部
分である。なお、タスクが静止画または動画の再生プロ
グラムである場合には、受認できる最低限の解像度に相
当する処理部分を保証部分とし、それ以上の解像度に相
当する処理部分を制御可能部分とする、というように解
像度を調整するのも好適である。

【００３５】また、アプリケーションがＷｅｂブラウザ
である場合、保証部分は、ネットワークタイムアウト時
間内のパケット通信間隔の通信レートに相当する処理部
分であり、制御可能部分は、より大きい通信レート、例
えば（パケットサイズ）／（スループット）の通信レー
トに相当する処理部分である。

【００３６】なお、本実施形態におけるアプリケーショ
ンプログラムでは、各タスクの保証部分のプログラム文
と制御可能部分のプログラム文とが互いに分離して記述
されており、また保証部分のメモリアドレスには、本発
明における保証対象識別子としての所定の保証対象フラ
グが付されている。

【００３７】また、各タスクの保証部分、すなわち最低
限の割当を保証すべきリソース量は、実行されるハード
ウェアおよびソフトウェア環境におけるスケジューラプ
ログラムの時間計測機能を用いて計測する。具体的に
は、最低限保証すべきリソース量は、対象となる処理
が、割り当てタイミングごとに開始してから終了するま
でに、各リソースを使用する時間を測定することによっ
て予め計測される。また、各タスクのデッドラインは、
割り当てタイミングから処理開始までの時間をずらし、
品質が満足できなくなるまでの空白時間を測定すること
で計測できる。また、制御可能部分のリソース量は、各
タスクの最高の処理品質による処理を実行しながら同様
のスケジューラプログラムを利用した計測値から、保証
部分の計測値を減算することで算出できる。これらのリ
ソース量情報は、このような測定をシステム上で実際に
行うことで取得してもよいし、アプリケーションプログ
ラムのベンダーから提供される諸元値をそのまま利用し
てもよい。

【００３８】さらに、メモリ５上には、リアルタイム性
が要求されるタスク、すなわち遅延時間を小さくする必
要のあるタスク（以下、このようなタスクを遅延保証が
必要なタスクと呼ぶ）を管理するために、これら各タス
クの情報を格納しておくためのタスク管理テーブル１０
が存在する。

【００３９】図２はタスク管理テーブル１０の一例を示
す図である。タスク管理テーブル１０は、タスク情報管
理テーブル２１とタスク実行管理テーブル２２とから構
成される。

【００４０】タスク情報管理テーブル２１は、後述する
タスク受付処理で受付けられた遅延保証が必要なタスク
に関する情報を管理するテーブルである。

【００４１】このタスク情報管理テーブル２１に格納さ
れる情報には、タスク識別子格納部２１ａ、タスクポイ
ンタ格納部２１ｂ、周期格納部２１ｃ、保証部分処理時
間格納部２１ｄ、制御部分処理時間格納部２１ｅ、許容
遅延時間格納部２１ｆに格納されるタスク識別子ＩＤ、
タスクポインタＰ、周期Ｓ、保証部分処理時間Ｇ、制御
可能部分処理時間Ｃ、デッドラインＨ、があり、これら
の情報がそれぞれタスクごとに格納されている。なお、
図２では、横１列が１つのタスクに関する情報を示して
いる。

【００４２】タスク識別子ＩＤは、各タスクを識別する
ためのものであり、タスクポインタＰは、記憶装置４あ
るいはメモリ５上に存在する各タスクのプログラムの位
置を指し示すものである。周期Ｓは、各タスクにおける
実行開始時点から次の実行開始時点までの時間であり、
あるタスクが実行されると、設定された周期Ｓの間、こ
のタスクが新たに実行されることはない。

【００４３】保証部分処理時間Ｇは、本発明における保
証部分の所要リソース量であり、各タスクにおける保証
部分の実行に要する処理時間である。制御可能部分処理
時間Ｃは、本発明における制御可能部分の所要リソース
量であり、各タスクにおける制御可能部分の実行に要す
る処理時間である。なお、これら保証部分処理時間Ｇ・
制御可能部分処理時間Ｃは、予め設定されるサンプル値
なので、実際のタスクがこれらの値より前に終了するこ
ともあり得る。

【００４４】デッドラインＨは、その時間内で処理が完
了すれば品質が満足されるような許容時間であって、周
期Ｓで示される時間内に設定される。あるタスクに対し
てイベントが発行された状態で前回の実行開始時点から
の経過時間が周期Ｓを超えたり、タスク処理が中断した
りすると、このタスクに遅延が生じる。このような遅延
の発生は、許容遅延時間Ｈを消費することを意味する。
したがって、この許容遅延時間Ｈが全て消費される前に
タスク処理が終了しなければならない。

【００４５】なお、これらの周期Ｓ、保証部分処理時間
Ｇ、制御可能部分処理時間Ｃ、デッドラインＨは、この
タスク予約を要求したアプリケーションプログラムに予
め格納されており、このアプリケーションプログラムの
外部記憶媒体経由やネットワーク経由でのインストール
により記憶装置４に記憶され、後述するシステムコール
によってＯＳに渡され、受付が許可されると、タスク識
別子ＩＤ３が付与されてタスク情報管理テーブル２１に
格納されることになる。

【００４６】タスク実行管理テーブル２２は、受付けら
れたタスク、すなわちタスク情報管理テーブル２１に登
録されたタスクの実行時に使用される情報を管理するテ
ーブルである。このタスク実行管理テーブル２２に格納
される情報としては、タスク識別子ＩＤ、実行識別フラ
グＦ、および部分実行フラグＦＰがあり、これらの情報
はタスクごとに、それぞれタスク識別子格納部２２ａ、
実行識別フラグ格納部２２ｂ、部分実行フラグ格納部２
２ｃに格納される。

【００４７】実行識別フラグＦは、実行中または実行を
中断しているタスクを識別するためのものである。この
実行識別フラグＦは、各タスクが実行中または実行中断
状態ならばセットされ（例えば、「１」となる）、タス
クの実行が終了した場合はリセットされる（例えば、
「０」となる）。

【００４８】部分実行フラグＦＰは、実行対象が保証部
分のみであるタスクを識別するためのものである。この
部分実行フラグＦＰは、各タスクの実行対象が保証部分
のみであるならばセットされ（例えば、「１」とな
る）、各タスクの実行対象が保証部分と制御可能部分の
両方である場合にはリセットされる（例えば、「０」と
なる）。

【００４９】次に、遅延保証が必要なタスクの受付処理
について、図３に従って説明する。例えばタスクＡ１，
Ａ２，Ａ３について、予め所要リソース量ｒ１，ｒ２，
ｒ３、保証部分に係る所要リソース量ｒ１ａ，ｒ２ａ，
ｒ３ａ、制御可能部分に係る所要リソース量ｒ１ｂ，ｒ
２ｂ，ｒ３ｂ、デッドラインＨ１，Ｈ２，Ｈ３が設定さ
れている場合であって、タスクＡ１，Ａ２が既に予約さ
れている場合において、いま、アプリケーションからの
システムコールにより、新規タスクＡ３の予約が要求さ
れると、ＣＰＵ２は、タスク受付プログラム格納部８に
格納されたプログラムに従って以下のような処理を実行
する。

【００５０】図３において、まずＣＰＵ２は、システム
の現在のリソース量、既に受付けられた予約済みのタス
クＡ１，Ａ２の保証部分・制御可能部分の各所要リソー
ス量、および新規タスクＡ３の保証部分・制御可能部分
の各所要リソース量を読み込む（Ｓ１）。予約済みのタ
スクＡ１，Ａ２の各所要リソース量は、タスク情報管理
テーブル２１に登録された情報に基づいて、タスク管理
テーブル１０から抽出される。また新規タスクＡ３の各
所要リソース量は、システムコールと共に入力され、メ
モリ５の所定領域に保持されている。

【００５１】次に、予約済みのタスクＡ１，Ａ２と、新
たに予約が要求されたタスクＡ３の、全ての保証部分と
制御可能部分（所要リソース量ｒ１＋ｒ２＋ｒ３）が実
行可能かが、外的制約である各タスクのデッドラインＨ
１，Ｈ２，Ｈ３との比較に基づいて判定される（Ｓ
２）。

【００５２】ステップＳ２で実行可能と判定された場合
には、これらタスクＡ１，Ａ２，Ａ３の保証部分と制御
可能部分とが、実行対象として選択され、タスク情報管
理テーブル２１に登録される（Ｓ３）。

【００５３】他方、図５（ａ）の例のように、各タスク
Ａ１，Ａ２，Ａ３の保証部分と制御可能部分とを順に実
行したと仮定した場合にタスクＡ３についてデッドライ
ンＨ３を満たせず遅れ時間を生じてしまうような場合に
は、ステップＳ２で実行不能と判定され、次に、要求さ
れている全タスクの保証部分の所要リソース量として、
各タスクの保証部分処理時間Ｇの合計が各タスクのデッ
ドラインＨ１，Ｈ２，Ｈ３と比較され、これにより、全
タスク（図５（ｃ）、所要リソース量ｒ１ａ＋ｒ２ａ＋
ｒ３ａ）が実行可能かが判定される（Ｓ４）。

【００５４】実行可能と判定された場合には、全タスク
の保証部分のみが、実行対象として選択され、タスク情
報管理テーブル２１に登録される（Ｓ５）。すなわち、
要求された新規タスクＡ３と受付済みのタスクＡ１，Ａ
２の遅延保証が可能な場合であるとして受付許可とさ
れ、タスクＡ１，Ａ２，Ａ３の各タスク識別子ＩＤ１，
ＩＤ２，ＩＤ３と、保証部分のみが実行対象である旨を
示す部分実行フラグＦＰとが、メモリ５のタスク管理テ
ーブル１０に書き込まれ、続いて、保証部分のみを実行
対象として受付できた旨がアプリケーションに返答され
て、受付処理が終了する。

【００５５】ステップＳ４で実行不能と判定された場合
には、新規タスクが予約できない場合であるとして、そ
の旨の登録不可信号が出力され（Ｓ６）、また受付でき
ない旨がアプリケーション側に通知される。なお、アプ
リケーションの処理により、新規タスクの登録ができな
い旨が、例えば図示しない表示装置における文字メッセ
ージによってユーザに提示され、ユーザは不要なアプリ
ケーションを閉じるなどしてこれに対処する。

【００５６】以上の処理の結果、タスクＡ１，Ａ２，Ａ
３が、それぞれデッドラインＨ１，Ｈ２，Ｈ３を満足し
つつ、保証部分のみのリソース割当を確保して実行され
ることになる。なお、各タスクの実行の開始タイミング
は、システムのスケジューラで制御されることになるの
で、例えばタスクが動画の表示に係るものである場合に
は、その実行は図６に示すように該当フレームの読込み
（Ｓ１１）とフレーム出力（Ｓ１２）のように機能ごと
に構成すれば足り、タイマ等を利用した各タスクの実行
タイミング管理をアプリケーション側で行う必要はな
い。

【００５７】以上のとおり、第１実施形態では、タスク
Ａ１，Ａ２，Ａ３そのものを保証部分と制御可能部分と
に分けて段階的に設定し、後者を制御可能、つまり場合
に応じて削除できる部分として扱うこととした。すなわ
ち本実施形態では、予約済みのタスクＡ１，Ａ２の処理
レベルを、制御可能部分を含む場合（Ｓ１）と含まない
場合（Ｓ４）の両者の間で仮想的に変更しながら、新規
に予約要求がされたタスクＡ３の実行可能性を判定する
と共に、実行可能と判定された処理レベルで、実行対象
となるタスクＡ１，Ａ２，Ａ３の選択を実行するように
した。したがって本実施形態では、予約済みのタスクＡ
１，Ａ２について品質を調整することで、新規に予約要
求がされたタスクＡ３を受付けて実行することができ、
タスクの遅延保証とタスクの効率的な実行とを両立でき
る。

【００５８】また本実施形態では、制御可能部分の付加
または削除により、判定処理と品質の調整とを行うこと
としたので、簡易な構成により本発明に所期の効果を得
ることができる。

【００５９】また本実施形態では、タスクの処理レベル
の仮想的な変更を、全ての予約済みのタスクＡ１，Ａ２
と予約が要求されているタスクＡ３とについて行うこと
としたので、大きな変更量をとることにより要求リソー
ス量の大きな変化を許容できる。

【００６０】また本実施形態では、保証対象識別子の利
用によって、実行対象となるタスクを選択できるので、
簡易な構成により本発明に所期の効果を得ることができ
る。

【００６１】なお、本実施形態では、各タスクの相互間
の優先度を特に考慮せずにこれを選択する構成について
説明したが、各タスクは所定の優先度（例えば、要求処
理時間と許容遅延時間との和が大きいタスクほど処理の
優先度を下げる、優先度の高いタスクの要求処理時間が
優先度の低いタスクの許容遅延時間内に収まらなければ
ならない等）に従って登録されることとしてもよい。

【００６２】次に、第２実施形態について説明する。上
記第１実施形態では、処理対象となるタスク数の変更要
求があった場合に、所要リソース量を仮想的に変更しな
がら実行可能性の判定を行うこととした。しかし、タス
ク数の変更要求がなくても、例えば映像や音声の早送り
再生の場合など、所要リソース量の変動が予想される場
合があり、そのような場合であれば本発明における判定
手段による判定、つまり所要リソース量を仮想的に変更
しながらの実行可能性の判定を好適に実施できる。第２
実施形態は、少なくともいずれかのタスクについてパラ
メータの変更要求、とくにデッドラインの変更要求があ
った場合に、このような判定を行うものである。なお、
第２実施形態においても、マルチタスクシステムの構成
は上記第１実施形態のものと同様であるため、その説明
は省略する。

【００６３】例えばタスクＡ１，Ａ２，Ａ３の実行中
に、アプリケーションからのシステムコールにより、タ
スクＡ３のデッドラインの変更（例えば、標準値からの
所定値の減算）が要求されると、ＣＰＵ２は、タスク受
付プログラム格納部８に格納されたプログラムに従って
以下のような処理を実行する。

【００６４】図７において、まずＣＰＵ２は、システム
の現在のリソース量、実行中のタスクＡ１，Ａ２，Ａ３
のデッドライン、および保証部分・制御可能部分の各所
要リソース量を読み込む（Ｓ２１）。

【００６５】次に、現在の所要リソース量設定でデッド
ラインの変更が可能かが、デッドラインを仮想的に変更
した場合のタスクＡ１，Ａ２，Ａ３の所要リソース量
（保証部分と制御可能部分の両者についてのもの）と、
外的制約である各タスクのデッドライン（変更後のも
の）との比較に基づいて判定される（Ｓ２２）。

【００６６】ステップＳ２２で実行可能と判定された場
合には、現在の所要リソース量設定（すなわち、タスク
Ａ１，Ａ２，Ａ３の保証部分と制御可能部分とが選択さ
れた状態）で、タスクＡ３のデッドラインが変更され、
タスク情報管理テーブル２１に登録される（Ｓ２３）。

【００６７】他方、ステップＳ２２で実行不能と判定さ
れた場合には、次に、制御可能部分の範囲内で減少され
た所要リソース量設定（すなわち、保証部分のみについ
ての所要リソース量）において、デッドラインの変更が
可能かが、この場合の最適化演算および各タスクのデッ
ドライン（変更後のもの）との比較に基づいて判定され
る（Ｓ２４）。

【００６８】実行可能と判定された場合には、減少され
た所要リソース量設定が採用され（すなわち、全タスク
の保証部分のみが実行対象として選択され）、その状態
でデッドラインが変更されて、タスク情報管理テーブル
２１に登録される（Ｓ２５）。すなわち、要求されたデ
ッドライン変更がされた状態で、タスクＡ１，Ａ２，Ａ
３の遅延保証が可能な場合であるとして受付許可とさ
れ、タスクＡ１，Ａ２，Ａ３の各タスク識別子ＩＤ１，
ＩＤ２，ＩＤ３と、保証部分のみが実行対象である旨を
示す部分実行フラグＦＰとが、メモリ５のタスク管理テ
ーブル１０に書き込まれ、続いて、保証部分のみを実行
対象として受付できた旨がアプリケーションに返答され
て、受付処理が終了する。

【００６９】ステップＳ２４で実行不能と判定された場
合には、デッドラインが変更できない場合であるとし
て、その旨の変更不可信号が出力され（Ｓ２６）、また
受付できない旨がアプリケーション側に通知される。な
お、アプリケーションの処理により、デッドラインの変
更ができない旨が、例えば図示しない表示装置における
文字メッセージによってユーザに提示され、ユーザは不
要なアプリケーションを閉じるなどしてこれに対処す
る。

【００７０】以上の処理の結果、タスクＡ１，Ａ２，Ａ
３が、それぞれ変更されたデッドラインを満足しつつ、
保証部分のみのリソース割当を確保して実行されること
になる。したがって第２実施形態では、上記第１実施形
態と同様に、タスクＡ１，Ａ２，Ａ３について品質を調
整することで、デッドラインを変更して実行を継続で
き、タスクの遅延保証とタスクの効率的な実行とを両立
できる。

【００７１】次に、第３実施形態について説明する。第
３実施形態は、上記第２実施形態と同様にパラメータの
変更要求に応じた実行可能性の判定を行うものであっ
て、これを周期の変更要求があった場合に適用したもの
である。なお、第３実施形態においても、マルチタスク
システムの構成は上記第１実施形態のものと同様である
ため、その説明は省略する。

【００７２】例えばタスクＡ１，Ａ２，Ａ３の実行中
に、アプリケーションからのシステムコールにより、タ
スクＡ３の周期の変更（例えば、標準値からの所定値の
減算）が要求されると、ＣＰＵ２は、タスク受付プログ
ラム格納部８に格納されたプログラムに従って以下のよ
うな処理を実行する。

【００７３】図８において、まずＣＰＵ２は、システム
の現在のリソース量、実行中のタスクＡ１，Ａ２，Ａ３
の周期、および保証部分・制御可能部分の各所要リソー
ス量を読み込む（Ｓ３１）。

【００７４】次に、現在の所要リソース量設定で周期の
変更が可能かが、周期を仮想的に変更した場合のタスク
Ａ１，Ａ２，Ａ３の所要リソース量（保証部分と制御可
能部分の両者についてのもの）と、各タスクの実行周期
（変更後のもの）との比較に基づいて判定される（Ｓ３
２）。

【００７５】ステップＳ３２で実行可能と判定された場
合には、現在の所要リソース量設定（すなわち、タスク
Ａ１，Ａ２，Ａ３の保証部分と制御可能部分とが選択さ
れた状態）で、タスクＡ３の周期が変更され、タスク情
報管理テーブル２１に登録される（Ｓ３３）。

【００７６】他方、ステップＳ３２で実行不能と判定さ
れた場合には、次に、制御可能部分の範囲内で減少され
た所要リソース量設定（すなわち、保証部分のみについ
ての所要リソース量）において、周期の変更が可能か
が、この場合の最適化演算および各タスクの実行周期
（変更後のもの）との比較に基づいて判定される（Ｓ３
４）。

【００７７】実行可能と判定された場合には、減少され
た所要リソース量設定が採用され（すなわち、全タスク
の保証部分のみが実行対象として選択され）、その状態
で周期が変更されて、タスク情報管理テーブル２１に登
録される（Ｓ３５）。すなわち、要求された周期の変更
がされた状態で、タスクＡ１，Ａ２，Ａ３の遅延保証が
可能な場合であるとして受付許可とされ、タスクＡ１，
Ａ２，Ａ３の各タスク識別子ＩＤ１，ＩＤ２，ＩＤ３
と、保証部分のみが実行対象である旨を示す部分実行フ
ラグＦＰとが、メモリ５のタスク管理テーブル１０に書
き込まれ、続いて、保証部分のみを実行対象として受付
できた旨がアプリケーションに返答されて、受付処理が
終了する。

【００７８】ステップＳ３４で実行不能と判定された場
合には、周期が変更できない場合であるとして、その旨
の変更不可信号が出力され（Ｓ６）、また受付できない
旨がアプリケーション側に通知される。なお、アプリケ
ーションの処理により、周期の変更ができない旨が、例
えば図示しない表示装置における文字メッセージによっ
てユーザに提示され、ユーザは不要なアプリケーション
を閉じるなどしてこれに対処する。

【００７９】以上の処理の結果、タスクＡ１，Ａ２，Ａ
３が、それぞれ変更された周期を満足しつつ、保証部分
のみのリソース割当を確保して実行されることになる。
したがって第３実施形態では、上記第２実施形態と同様
に、タスクＡ１，Ａ２，Ａ３について品質を調整するこ
とで、周期を変更して実行を継続でき、タスクの遅延保
証とタスクの効率的な実行とを両立できる。

【００８０】なお、上記各実施形態では、各タスクにつ
いての制御可能部分を１つとし、その保証部分への付加
の有無によって所要リソース量を変更する構成とした
が、各タスクについての制御可能部分は複数としてもよ
い。この場合には更に、複数設けられた制御可能部分に
相互の選択順位を設定（付与）し、これら複数の制御可
能部分がこの選択順位に従って選択されることとするの
が好適であり、とくに、複数設けられた制御可能部分の
うちの選択順位を識別するための所定の順位識別子（例
えば、所定の順位フラグ）を、各タスクのプログラム文
における各対応する部分に付すと共に、その各制御可能
部分の所要リソース量情報を予めタスク情報管理テーブ
ル２１に記憶させておき、動作の際には、判定対象とな
るタスクについて制御可能部分をその順位識別子が示す
選択順位に従って選択すると共に、その選択および判定
を選択の対象を変えながら（例えば、選択される制御可
能部分の個数を変えながら）試行することとするのが好
適である。このような構成とすれば、動作上の重要度の
低い部分から処理対象を削除していくことで処理量を段
階的に減少させつつ、実行可能性の判断を繰り返すこと
により、そのタスクに係る所要リソース量を更にきめ細
かに調整でき、またシステムのリソース量の有効利用を
図ることができる。

【００８１】また、上記第１ないし第３実施形態では、
タスク内での制御可能部分を利用した増減によって所要
リソース量を調整したが、このような所要リソース量の
調整は、実行順序に依存関係があり互いに主従関係にあ
る複数のタスク間での動作の調整にも適用できる。

【００８２】すなわち、所定の主タスクと、この主タス
クの実行が実行の条件となるような従タスクとがある場
合に、上記第１実施形態において用いられていたものと
同様の保証対象フラグを主タスクの全体に付し、また従
タスクには保証対象フラグを付さない構成とする。この
ような主タスクと従タスクとについて、上記第１実施形
態におけるタスク受付プログラムをそのまま実行させた
場合には、主タスクの全体が保証部分として、また従タ
スクの全体が制御可能部分として、それぞれシステムに
認識されることになる。その結果、リソース量に余裕が
ある場合には、主タスクと従タスクの両方が実行され、
またリソース量に余裕がない場合には、主タスクのみが
実行されることになり、これによって、タスク内での制
御可能部分の処理とタスク間での主従関係の処理とを共
通のアルゴリズムで実行でき、また、主タスクと従タス
クとを併せて一つのタスクとして扱うことができるため
タスク数の節約を図ることができる。

【００８３】なお、このようにタスク内での保証部分と
制御可能部分との識別に用いられる保証対象識別子とし
ての保証対象フラグを利用する構成に代えて、専ら主タ
スクと従タスクとの識別のために利用される所定の主従
タスク識別子（例えば、主従フラグ）を、主タスクと従
タスクの一方または両方に設け、またタスク受付プログ
ラムが、主タスクを保証部分として処理し、従タスクを
制御可能部分として処理することとしてもよく、同様の
効果を得ることができる。

【００８４】本発明のタスク管理装置と関連して用いら
れるプログラムは、第１２の本発明のように、タスクの
処理レベルの変更前後の所要リソース量を格納する所要
リソース量情報格納手段を備えることとしたり、第１３
の本発明のように、タスクの保証部分と制御可能部分と
を識別するための保証対象識別子を備えることとした
り、第１４の本発明のように、タスクに含まれる複数の
制御可能部分の順位を識別するための順位識別子を備え
ることとすれば、実行されるプログラムとこれに含まれ
るタスクの諸情報とを組として取り扱うことができ好適
である。

【００８５】また、本発明のタスク管理装置と関連して
用いられるプログラムは、第１５の本発明のように、所
定の主タスクを保証部分として前記システムに認識さ
せ、前記主タスクの実行が実行の条件となる従タスクを
制御可能部分として前記システムに認識させるように、
前記保証対象識別子を備えることとすれば、互いに主従
関係のある複数のタスクを、主従タスク識別子の利用に
よって保証部分や制御可能部分として処理できるので、
タスク内での制御可能部分の処理とタスク間での主従関
係の処理とを共通のアルゴリズムで実行できる。他方、
第１６の本発明のように、保証対象識別子に代えて、主
従関係の処理のための主従タスク識別子を備えることと
してもよい。

【００８６】なお、上記各実施形態では、制御可能部分
を全体として仮想的に削除することで処理量を調整する
構成としたが、逆に、リソース量に余裕がある場合（す
なわち、例えば、現在の提供可能なリソース量と現在の
全タスクの所要リソース量の合計との差が所定値を上回
る場合）に、処理品質を上げるような追加的な制御可能
部分を、全てのタスクに付加する構成としてもよい。ま
た、上記各実施形態では、リソース量の余裕の有無に応
じて、タスクの処理品質を段階的に増減変更する構成に
ついて説明したが、タスクの処理品質は無段階的に増減
変更することとしてもよい。

【００８７】また、上記各実施形態では、全てのタスク
について処理品質を変更することとしたので、要求リソ
ース量の大きな変化を許容できるという利点があるが、
本発明における処理品質の変更は一部のタスクについて
実行することとしてもよく、このような構成によっても
本発明に所期の効果を相当程度に実現できる。

【００８８】また、本発明におけるタスク受付プログラ
ムは、複数のタスクのいずれかを選択的に実行するマル
チタスクシステムにおいて、各タスクの所要リソース量
に基づいて各タスクの実行可能性を判定する判定処理
と、判定処理の判定結果に基づいて実行対象となるタス
クを選択するタスク選択処理と、を前記システムに実行
させるためのプログラムであって、少なくともいずれか
のタスクについて規定された保証部分と制御可能部分と
の所要リソース量情報を取得する所要リソース量情報取
得処理を更に含み、前記判定処理では、少なくともいず
れかの予約済みのタスクの処理レベルを前記制御可能部
分の範囲内で仮想的に変更して前記判定を実行し、前記
タスク選択処理では、実行可能と判定された処理レベル
で前記選択を実行することを特徴とするプログラムとし
て構成でき、これをＣＤ−ＲＯＭなどの公知の記録媒体
に記録した状態で、あるいはネットワーク経由のダウン
ロードによって取引でき、本発明の効果を実現するため
の有用な手段として用いることができる。

【図面の簡単な説明】

【図１】 本発明の第１実施形態に係るマルチタスクシ
ステムのブロック図である。

【図２】 タスク管理テーブルの一例を示す説明図であ
る。

【図３】 第１実施形態におけるタスク受付処理を示す
フロー図である。

【図４】 本発明の作用を示す説明図である。

【図５】 第１実施形態の作用を示す説明図である。

【図６】 第１実施形態における画像の表示処理を示す
フロー図である。

【図７】 第２実施形態におけるデッドライン変更受付
処理を示すフロー図である。

【図８】 第３実施形態における周期変更受付処理を示
すフロー図である。

【図９】 本発明による改良前のタスク受付処理の一例
を示す説明図である。

【図１０】 本発明による改良前のタスク受付処理の他
の一例を示す説明図である。

【符号の説明】

１ マルチタスクシステム、２ ＣＰＵ、３ タイマ、
４ 記憶装置、５ メモリ、６ インタフェース制御
部、７ 内部バス、１０ タスク管理テーブル、１１
ネットワーク、２１ タスク情報管理テーブル、２２
タスク実行管理テーブル。

Claims (20)

【特許請求の範囲】
1. 【請求項１】 複数のタスクのいずれかを選択的に実行
   するマルチタスクシステムにおいて、各タスクの所要リ
   ソース量に基づいて各タスクの実行可能性を判定する判
   定手段と、判定手段の判定結果に基づいて実行対象とな
   るタスクを選択するタスク選択手段と、を備えたタスク
   管理装置であって、 少なくともいずれかのタスクについて規定された保証部
   分と制御可能部分との所要リソース量情報を取得する所
   要リソース量情報取得手段を更に備え、 前記判定手段は、少なくともいずれかの予約済みのタス
   クの処理レベルを前記制御可能部分の範囲内で仮想的に
   変更して前記判定を実行し、 前記タスク選択手段は、実行可能と判定された処理レベ
   ルで前記選択を実行することを特徴とするタスク管理装
   置。
2. 【請求項２】 請求項１に記載のタスク管理装置であっ
   て、 前記判定手段は、 少なくともいずれかの予約済みのタスクにおける保証部
   分と制御可能部分との両者が実行可能かを判定する第１
   判定手段と、 第１判定手段によって不可との判定があった場合に、前
   記予約済みのタスクにおける保証部分が実行可能かを判
   定する第２判定手段と、 を備え、 前記タスク選択手段は、 第１判定手段により実行可能と判定された前記予約済み
   のタスクにつきその保証部分と制御可能部分との両者を
   選択し、 第２判定手段により実行可能と判定された前記予約済み
   のタスクにつきその保証部分のみを選択することを特徴
   とするタスク管理装置。
3. 【請求項３】 請求項１または２に記載のタスク管理装
   置であって、 前記判定手段が、全ての予約済みのタスクについて、処
   理レベルを前記制御可能部分の範囲内で仮想的に変更す
   ることを特徴とするタスク管理装置。
4. 【請求項４】 請求項１ないし３のいずれか１に記載の
   タスク管理装置であって、 前記判定手段による判定が、処理対象となるタスク数の
   変更要求があった場合に実行されることを特徴とするタ
   スク管理装置。
5. 【請求項５】 請求項１ないし４のいずれか１に記載の
   タスク管理装置であって、 前記判定手段による判定が、少なくともいずれかのタス
   クについてパラメータの変更要求があった場合に実行さ
   れることを特徴とするタスク管理装置。
6. 【請求項６】 請求項５に記載のタスク管理装置であっ
   て、 前記パラメータが前記少なくともいずれかのタスクのデ
   ッドラインであることを特徴とするタスク管理装置。
7. 【請求項７】 請求項５に記載のタスク管理装置であっ
   て、 前記パラメータが前記少なくともいずれかのタスクの実
   行周期であることを特徴とするタスク管理装置。
8. 【請求項８】 請求項１ないし７のいずれか１に記載の
   タスク管理装置であって、 少なくともいずれかのタスクについてその保証部分と制
   御可能部分とを識別するための保証対象識別子を取得す
   る保証対象識別子取得手段を更に備え、 前記タスク選択手段が、前記保証対象識別子を利用し
   て、前記選択を行うことを特徴とするタスク管理装置。
9. 【請求項９】 請求項１ないし８のいずれかに記載のタ
   スク管理装置であって、 少なくともいずれかのタスクに含まれる複数の制御可能
   部分に付与されたこれら複数の制御可能部分の選択順位
   を識別するための順位識別子を取得する順位識別子取得
   手段を更に備え、 前記判定手段が、判定対象となるタスクのうち選択され
   る制御可能部分を前記順位識別子を利用しその選択順位
   に従って選択すると共に、その選択および前記判定を前
   記選択の対象を変えながら試行することを特徴とするタ
   スク管理装置。
10. 【請求項１０】 請求項１ないし９のいずれか１に記載
    のタスク管理装置であって、 所定の主タスクと、前記主タスクの実行が実行の条件と
    なる従タスクと、を識別するための主従タスク識別子を
    取得する主従タスク識別子取得手段を更に備え、 前記判定手段および前記タスク選択手段が、前記主従タ
    スク識別子を利用して、前記主タスクを前記保証部分と
    して処理し、前記従タスクを前記制御可能部分として処
    理することを特徴とするタスク管理装置。
11. 【請求項１１】 複数のタスクのいずれかを選択的に実
    行するマルチタスクシステムにおいて、各タスクの所要
    リソース量に基づいて各タスクの実行可能性を判定する
    判定ステップと、判定ステップの判定結果に基づいて実
    行対象となるタスクを選択するタスク選択ステップと、
    を含むタスク管理方法であって、 少なくともいずれかのタスクについて規定された保証部
    分と制御可能部分との所要リソース量情報を取得する所
    要リソース量情報取得ステップを更に含み、 前記判定ステップでは、少なくともいずれかの予約済み
    のタスクの処理レベルを前記制御可能部分の範囲内で仮
    想的に変更して前記判定を実行し、 前記タスク選択ステップでは、実行可能と判定された処
    理レベルで前記選択を実行することを特徴とするタスク
    管理方法。
12. 【請求項１２】 請求項１１に記載のタスク管理方法で
    あって、 少なくともいずれかのタスクについてその保証部分と制
    御可能部分とを識別するための保証対象識別子を取得す
    る保証対象識別子取得ステップを更に含み、 前記タスク選択ステップでは、前記保証対象識別子を利
    用して、前記選択を行うことを特徴とするタスク管理方
    法。
13. 【請求項１３】 請求項１１または１２に記載のタスク
    管理方法であって、 少なくともいずれかのタスクに含まれる複数の制御可能
    部分に付与されたこれら複数の制御可能部分の選択順位
    を識別するための順位識別子を取得する順位識別子取得
    ステップを更に含み、 前記判定ステップでは、判定対象となるタスクのうち選
    択される制御可能部分を前記順位識別子を利用しその選
    択順位に従って選択すると共に、その選択および前記判
    定を前記選択の対象を変えながら試行することを特徴と
    するタスク管理方法。
14. 【請求項１４】 請求項１１ないし１３のいずれか１に
    記載のタスク管理方法であって、 所定の主タスクと、前記主タスクの実行が実行の条件と
    なる従タスクと、を識別するための主従タスク識別子を
    取得する主従タスク識別子取得ステップを更に含み、 前記判定ステップおよび前記タスク選択ステップでは、
    前記主従タスク識別子を利用して、前記主タスクを前記
    保証部分として処理し、前記従タスクを前記制御可能部
    分として処理することを特徴とするタスク管理方法。
15. 【請求項１５】 複数のタスクのいずれかを選択的に実
    行するマルチタスクシステムにおいて、各タスクの所要
    リソース量に基づいて各タスクの実行可能性を判定する
    判定処理と、判定処理の判定結果に基づいて実行対象と
    なるタスクを選択するタスク選択処理と、を前記システ
    ムに実行させるためのプログラムであって、 少なくともいずれかのタスクについて規定された保証部
    分と制御可能部分との所要リソース量情報を取得する所
    要リソース量情報取得処理を更に含み、 前記判定処理では、少なくともいずれかの予約済みのタ
    スクの処理レベルを前記制御可能部分の範囲内で仮想的
    に変更して前記判定を実行し、 前記タスク選択処理では、実行可能と判定された処理レ
    ベルで前記選択を実行することを特徴とするプログラ
    ム。
16. 【請求項１６】 請求項１１ないし１４のいずれか１に
    記載のタスク管理方法と関連して用いられるプログラム
    であって、 その少なくともいずれかのタスクの処理レベルの変更前
    後の所要リソース量を格納する所要リソース量情報格納
    手段を備えたことを特徴とするプログラム。
17. 【請求項１７】 請求項１２に記載のタスク管理方法と
    関連して用いられるプログラムであって、 その少なくともいずれかのタスクの保証部分と制御可能
    部分とを識別するための保証対象識別子を備えたことを
    特徴とするプログラム。
18. 【請求項１８】 請求項１３に記載のタスク管理方法と
    関連して用いられるプログラムであって、 その少なくともいずれかのタスクに含まれる複数の制御
    可能部分の選択順位を識別するための順位識別子を備え
    たことを特徴とするプログラム。
19. 【請求項１９】 請求項１２に記載のタスク管理方法と
    関連して用いられるプログラムであって、 所定の主タスクを保証部分として前記システムに認識さ
    せ、前記主タスクの実行が実行の条件となる従タスクを
    制御可能部分として前記システムに認識させるように、
    前記保証対象識別子を備えたことを特徴とするプログラ
    ム。
20. 【請求項２０】 請求項１４に記載のタスク管理方法と
    関連して用いられるプログラムであって、 所定の主タスクと、前記主タスクの実行が実行の条件と
    なる従タスクと、を識別するための主従タスク識別子を
    備えたことを特徴とするプログラム。