JP3676827B2 - マルチプロセッサシステム用のスケジューリング方法 - Google Patents

Description

【０００１】
【産業上の利用分野】
本発明はコンピュータシステムに関し、特に、マルチプロセッサ；マルチタスキングシステムのタスクをスケジューリングする方法に関する。
【０００２】
【従来の技術】
マルチ処理は並列処理の一種であり、２個以上のプロセッサで別々のプログラムの実行を分担するやり方である。マルチタスキングはマルチ処理の特別の場合であって、ソフトウェアの処理、すなわちタスクを規定するものである。タスクはサブプログラムであって、同時に他のサブプログラムと一緒に実行することができる。
【０００３】
マルチタスク環境では、衝突せずに並列に実行できるように、タスクとジョブのデータ構造とを注意深く分割しなければならない。しかし、プロセッサの使用可能度、実行の順番およびタスクの完了はシステムの運転時の状態の関数である。したがって、タスク自身は正しく決められていても、マルチタスキングは時間に関して本質的に不確定なものである。
【０００４】
マルチタスキングを確実に成功させるには、一旦タスクを分割した場合、効率的に資源を共有するようにオペレーティングシステムを展開しなければならない。資源を処理に割り当てることを「スケジューリング」と呼ぶ。スケジューリングはリアルタイム入力に対してリアルタイムに応答することを必要とするシステムにおいて特に重要である。
【０００５】
既存のマルチタスキング・スケジューリング・システムではたいていが優先度方式を用いているが、これは本質的に静的なものである。優先度方式では、タスクがどれほどの時間を必要とするか、タスクがどれほどのメモリ量を必要とするか、あるいはそのメモリが必要とする時間のような、タスクの処理に必要なことを考慮していない。メモリに対する要求は、タスクがもっとメモリを必要とする前に、所定量のメモリを用いて、どれ位の時間そのタスクを実行することができるかにより決定される。
【０００６】
スケジューリングを行う他の方法としては、「タイムスライシング」がある。この場合、タスクの各部分に、限定された実行時間が与えられる。この時間が経過すると、別のタスクの部分が実行される。すなわち、タスクが所定の時間内に終らなかったならば、プロセッサは次に待っているタスクに割当てられ、未完了のタスクはもう一度スケジューリングされる。タイムスライス方式の欠点は、タスクの切替え時にオーバヘッドがあることである。
【０００７】
【発明が解決しようとする課題】
余分な処理用オーバヘッドを生ずることなく、資源を効率よく利用するタスクのスケジューリング方法が必要である。
【０００８】
【課題を解決するための手段】
本発明によれば、マルチタスキング、マルチプロセッサシステムのプロセッサにより実行される、タスクのスケジューリング方法が提供される。メモリの要求やプロセッサの使用のような、実行すべきタスクの処理特性が実験的に決められる。各タスクはそのタスクの処理特性を表わすデータ構造に関連づけられている。実行時にはタスクが呼び出されて、タスク待ち行列の中に配置される。実行のためにタスクが待ち行列から取り出されると、タスクは自分の処理特性をスケジューラプログラムに知らせる。それからスケジューラはタスクの処理特性と利用可能な資源とに応じて、タスクにより使用される処理資源を選択する。
【０００９】
本発明の技術的特徴は、リアルタイム応答性を従来より容易に維持できることである。タスクは必要な時間だけ実行し続けられるように、その処理の必要性に応じてスケジューリングされる。システムの資源の負荷がどの位か、および、更に処理を負担させることができるか否かを決めるために、システムの性能を監視することもできる。
【００１０】
【実施例】
図１はマルチプロセッサ、マルチタスキングコンピュータ処理システム１０のブロック図であり、ホストプロセッサシステム１１が信号プロセッサシステム１５と通信可能になっている。プロセッサ１１と１５間の通信手段はバス１９であって、例えば３２ビットＮＵ−ＢＵＳ標準のような認知されたいくつかの２進通信法のうち任意のものに適合している。本発明の利点の一つはＮＵ−ＢＵＳ標準の簡単なメモリマップアーキテクチャに適合していることである。
【００１１】
ホストプロセッサシステム１１はホストプロセッサ１２とメモリ１３とを含む。ホストプロセッサ１２は例えばモトローラ社製の６８０３０のような汎用プロセッサである。メモリ１３はホストプロセッサ１２の命令を記憶するためのプログラムメモリと、信号プロセッサシステム１５にダウンロードされるプログラムルーチンとパラメータとを記憶するメモリとを含む。ダウンロードするプロセスは後述する。
【００１２】
信号プロセッサシステム１５はいくつかの信号プロセッサ１６とそれらの各々に付属したメモリ１７とを含む。信号プロセッサ１６は例えばテキサスインスツルメント社製のＴＭＳ３２０Ｃ３０である。本実施例の場合、メモリ１７の適当な大きさは２５０Ｋ×４バイトである。信号プロセッサシステム１５はホストプロセッサ１２からダウンロードされたプログラムルーチンを実行する。１個のプログラムルーチンを実行し終わると、信号プロセッサシステム１５はそのことをホストプロセッサ１２に知らせるので、ホストプロセッサは別のルーチンをダウンロードすることができる。
【００１３】
信号プロセッサ１６同士は相互に通信可能なので、信号プロセッサシステム１５は同時に２個以上のタスクを実行することができる。例えば、信号プロセッサシステムは図１に示すように３個の信号プロセッサ１６から構成してもよい。各信号プロセッサ１６は自己に割当てられたメモリ１７を有し、各メモリは隣接メモリ１７と相互に接続されているので、信号プロセッサ１６間で通信することができる。
【００１４】
各信号プロセッサ１６は呼処理部を持っているので、２個以上の呼出しを同時に処理することができる。処理の仕方はホストプロセッサ１２から供給されたスクリプトにより各呼出しに毎に異なってもよい。
【００１５】
図２は電話回線通信に使われる典型的なマルチプロセッサシステム１０の適用例を示す。この例では、ホストプロセッサシステム１１はボイスメールサービスを扱うサービスコントロールシステム２１の一部である。サービスコントロール２１はまた、データベース管理システム（図示せず）と通信するための通信搬送部と適当なインタフェイスとを有する。データベース管理システムとは、大きなデータベースシステムを必要とする顧客の記録とその他の情報とを管理するものである。サービスコントロールシステムはまた、バス１９を介して電話制御システム２２とも通信することができるようになっている。電話制御システム２２にはディジタル処理システム１５が含まれている。ディジタル処理システム１５はＴ１線２４からＴ１バッファ２３を経由してデータを受信して、電気通信プロトコルに従って音声データを実際に送受信する。Ｔ１バッファ２３は例えば、マイテル社製のＭＴ８９２０ ＳＴ−バス並列アクセス回路である。図３を用いて後述するが、本発明を実際に応用する際には、信号処理システム１５は、複数個の信号プロセッサ１６を有し、Ｔ１線の複数チャネルから入力を受信するマルチプロセッサ、マルチタスキングシステムである。
【００１６】
ボイスメールにマルチプロセッサシステム１０を使うことに関しては、係属中の米国特許出願シリアルNo. ５７０，１７１，「Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｃｏｎｔｒｏｌ Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ（ディジタル信号処理制御方法および装置）」にもっと詳細に記載されている。なお、この特許出願も本発明の譲り受け人に譲渡されている。そこに開示されている方法は、その発明のマルチプロセッサ環境の範囲内でデータを転送するひとつの方法である。しかし、本発明の方法はそのような特定の構成を用いて機能するものに限らず、図１に示すように、少なくとも２個のプロセッサが１個のプロセッサのメモリへのアクセスを共有するようなマルチプロセッサ環境ならば、どんなものでも使うことができよう。
【００１７】
信号処理システム１５の処理タスク、すなわち、信号プロセッサ１６により実行される機能は、ホストプロセッサシステム１１にロードされるアプリケーションプログラムの部分により表わされる。これらのコードの部分はここでは「スクリプト」と呼ぶ。ホストプロセッサ１２は実行すべきタスクの特定の順番を動的に決定する。したがって「スクリプト」を決定する。スクリプトは擬似コード形式で信号プロセッサ１２にダウンロードされ、図３に示すようにスクリプトインタプリンタ３２により解読される。その結果は、ホストプロセッサ１２が信号プロセッサ１６に実行することを要求するタスクを特定する１組のバイトコードを表わす。ホストプロセッサ１２またはスクリプトインタプリンタ３２のいずれかによって、タスクを処理する能力のある特定の信号プロセッサ１６にタスクが割当てられる。
【００１８】
ボイスメールの場合には、タスクは着呼により開始される。タスクの一例は電話に応答することである。他のタスクにはメッセージを聴くことや、メッセージを記録することなどがある。ボイスメッセージ処理のような場合には、一旦電話に応答するタスクが実行されると、その次のタスクは発呼者の入力により変る。例えば発呼者はメッセージを聴くこと、メッセージを記録すること、あるいは交換手につなぐことなどを要求するだろう。したがって、ボイスメッセージの場合には、スクリプトは、一旦電話応答がなされたとき、続いて信号プロセッサが実行すべきコードを表わす。
【００１９】
マルチタスキング動作の一例として、電話に応答するタスクがある。ホストドライバ３３は選択組を受信するために「複合読取り」を行い、ホストプロセッサ１２はこのタスク用のスクリプトを含む領域サブセットを信号プロセッサ１６に供給する。タスクを実行する能力を有する各信号プロセッサ１６はスクリプトを解釈してそれを実行する準備を行う。電話が鳴ると、最初に利用可能な信号プロセッサ１６が呼び出しに応答する。次の電話が鳴ると、第２の信号プロセッサ１６が処理する。以下同様に動作する。
【００２０】
図３はメモリ１７に記憶されている信号プロセッサ１６のプログラムとデータの記憶に関する機能ブロック図である。プログラムは３個の主部を有する。実行制御部３１と、スクリプトインタプリタ部３２と、ホストドライバ部３３とである。実行制御部３１は信号プロセッサ１６により実行されるコードを記憶する。このコードはホストプロセッサ１２により変えられない。このコードはダウンロードされたルーチンからの特定の機能の呼出しをサポートする。例えば、ダウンロードされたルーチンは機能「ゲントーン（ｇｅｎｔｏｎｅ）５」を呼び出してもよいだろう。この機能はキーパッドの数字５に相当するＤＴＭＦ信号が所望されていることを示している。ホストドライバ３３は、標準デバイスドライバがディスクドライブのような周辺機器とやりとりするのと同様なＩ／Ｏ処理法で、ホストプロセッサ１２とＩ／Ｏ処理のやりとりを行う。スクリプトインタ プリタ部３２は上述のようにスクリプトを解釈する。図３に示すように、メモリ１７はまたホストプロセッサ１２からダウンロードされたプログラムコードとその他のデータを記憶するための主記憶領域３４を有する。
【００２１】
ホストプロセッサ１２と信号プロセッサ１６は各々それぞれ自分のメモリ１３と１７ヘのアクセスに関して、排他的に制御することができる。したがって、各プロセッサ１２と１６は自分自身のＩ／Ｏ動作を実行する。
【００２２】
プロセッサ間の通信、特にホストプロセッサ１２から信号プロセッサ１６へのダウンロードについては、係属中の米国特許出願シリアルＮｏ．５７６，２５８，「Ｍｅｔｈｏｄ ｆｏｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｂｅｔｗｅｅｎ Ｐｒｏｃｅｓｓｏｒｓ ｏｆ ａ Ｍｕｌｔｉ−ｐｒｏｃｅｓｓｏｒ Ｓｙｓｔｅｍ（マルチプロセッサシステムにおけるプロセッサ間の通信方法）」に詳しく述べてある。なお、この発明も本発明の譲り受け人に譲渡されている。要約すると、ホストプロセッサ１２は信号プロセッサ１６に書きこもうとするデータを領域により特定する。信号プロセッサ１６は整合読取り動作を行って、その領域のデータを受信する。これらの整合書込み／読取り動作を行うことにより、信号プロセッサ１６上ではホストプロセッサ１２の領域へ排他的にアクセスする処理がなされるようになる。信号プロセッサに領域が供給可能になる前に信号プロセッサが領域を要求できるようにすることによって、信号プロセッサ１６がホストプロセッサの領域へのアクセスを完了する前に、ホストプロセッサがその領域に書込むことができないようにする。
【００２３】
ホストドライバ３３を用いて「複合読取り」（ｃｏｍｐｏｕｎｄｒｅａｄ）操作を行うことにより、処理のオーバヘッドが軽減される。この操作は１スクリプト当り１回だけＩ／Ｏ動作を必要とするが、この操作を行うと、信号プロセッサ１６が必要とするすべての領域を１度に受信することができるようになる。
【００２４】
特定のタスク用のデータをダウンロードする際に効率を考慮することとは別に、タスクスケジューリングはリアルタイム処理にも望ましいことである。本発明の基本概念は、スケジューラが処理特性に基づいたスケジュールを決めることができるように、各タスクに処理特性を割り当てることである。これらの特性は処理に必要な時間とメモリ容量とを含む。
【００２５】
ひとつの処理特性は「リアルタイム」プロセッサ比率である。これは処理時間をデータ時間で割ったものである。例えば、データが２０ｍｓの合計データ時間の間、ｋＨｚで１６０サンプル読まれて、そのデータの処理時間が５ｍｓであるとしよう。プロセッサ比率は５／２０＝２５％である。もしタスクが５ｍｓプラス「スロップファクタ」（ｓｌｏｐ ｆａｃｔｏｒ）よりも長時間要したならば、その処理はリアルタイムと見なされない。データの多少に対して必要な処理時間は容易に決めることができる。
【００２６】
次のデータ構造はタスクにより主張される処理特性の一例であり、Ｃ言語でプログラムが書かれている。
【００２７】
Ｓｔｒｕｃｔ Ｔａｓｋ＿Ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ
｛
ｌｏｎｇ ｔａｓｋ＿ｔｙｐｅ；
ｌｏｎｇ ｔａｓｋ＿ｄｅｇｒａｄｅ＿ｐａｔｈ；
ｌｏｎｇ ｔａｓｋ＿ｔｉｍｅ＿ｍａｘ；
ｌｏｎｇ ｔａｓｋ＿ｉｄ：
ｌｏｎｇ ｂｕｆｆｅｒ＿ｓｉｚｅ；
ｌｏｎｇ ｂｕｆｆｅｒ＿ｔｉｍｅ；
ｌｏｎｇ ａｖｅｒａｇｅ＿ｅｘｅｃｕｔｉｏｎ＿ｔｉｍｅ；
ｌｏｎｇ ｔｏｔａｌ＿ｅｘｅｃｕｔｉｏｎ＿ｔｉｍｅ；
ｌｏｎｇ ｍｉｎｉｍｕｍ＿ｅｘｅｃｕｔｉｏｎ＿ｔｉｍｅ；
ｌｏｎｇ ｍａｘｉｍｕｍ＿ｅｘｅｃｕｔｉｏｎ＿ｔｉｍｅ；
ｌｏｎｇ ｎｕｍｂｅｒ＿ｅｘｅｃｕｔｉｏｎｓ；
ｌｏｎｇ ｎｕｍｂｅｒ＿ａｌａｒｍｓ；
ｌｏｎｇ ｔａｓｋ＿ｓｔａｔｕｓ；
｝
【００２８】
この構造におけるデータ項目は次のように記述されている。
ｔａｓｋ＿ｔｙｐｅ タスクが実行する処理の種類を識別する。例えば
ｔａｓｋ＿ｔｙｐｅ＝ＤＴＭＦ＿ＲＥＣＥＩＶＥＲ．
ｔａｓｋ＿ｄｅｇｒａｄｅ＿ｐａｔｈ より低次の資源集約タスクへの下がり
方、または現在のタスクの処理をより低次の資源集約動作への変更の
仕方を指示する。
ｔａｓｋ＿ｔｉｍｅ＿ｍａｘ アラームが発せられる前にタスクの実行が許さ
れる最長の時間を示す。
ｔａｓｋ＿ｉｄ このタスクを他のすべてのタスクから唯一に識別する数。
ｂｕｆｆｅｒ＿ｓｉｚｅ 各タスクに割当てられているバッファのバイト数を
を規定する。
ｂｕｆｆｅｒ＿ｔｉｍｅ ｂｕｆｆｅｒ＿ｓｉｚｅのタスクバッファ内のデー
タで表わされる時間量を規定する。
ａｖｅｒａｇｅ＿ｅｘｅｃｕｔｉｏｎ＿ｔｉｍｅ このタスクがデータバッフ
ァを処理するのに要する平均時間を示す統計値。
ｔｏｔａｌ＿ｅｘｅｃｕｔｉｏｎ＿ｔｉｍｅ このタスクがデータバッフアを
処理するのに使った合計時間を示す統計値。
ｍｉｎｉｍｕｍ＿ｅｘｅｃｕｔｉｏｎ＿ｔｉｍｅ データバッファを処理する
のに使った最短時間を示す統計値。
ｍａｘｉｍｕｍ＿ｅｘｅｃｕｔｉｏｎ＿ｔｉｍｅ データバッファを処理する
のに使った最長時間を示す統計値。
ｎｕｍｂｅｒ＿ｅｘｅｃｕｔｉｏｎｓ 処理されたデータバッファの数を明ら
かにする。
ｎｕｍｂｅｒ＿ａｌａｒｍｓ このタスクの実行中に起きたアラームの数。
ｔａｓｋ＿ｓｔａｔｕｓ このタスクの現在の状態。例えば、
ＴＡＳＫ＿ＯＫ ＡＬＡＲＭ＿ＯＮ ＴＡＳＫ＿ＫＩＬＬＥＤ。
【００２９】
実行時スケジューラは各ディジタルプロセッサ１６のプログラミングの一部である。このスケジューラはタスク識別子と、タスクの処理特性を表わすデータと、資源の使用可能度とを用いる。スケジューラはこのデータを用いて、各タスクの実行時間中に資源を動的に割当てたり解除したりする。処理特性は後述するように、ホストプロセッサ１２からダウンロードされるか、または動的に再構築されることによって、初期化時に決定される。本発明の発展形として、システムが過負荷になった際の低次への移行を扱ったり、あるいは実行統計を提供したりする付加プログラミングを含むことができる。
【００３０】
信号プロセッサシステム１５の初期化を行っている間、各プロセッサ１６が実行するタスクにデータとスタック空間とが割当てられる。これらの資源割当ては実行時間中スケジューラにより利用される。
【００３１】
図４はスケジューラのプログラム構成と、スケジューリングタスクの実行時プロセスとを示す。スケジューラの主なプログラム構成は、タスク待ち行列４１、待ち行列マネージャー４２、アラームドライバ４３、タイミング発生器４４、およびオーバタイムマネージャ４５である。
【００３２】
処理が始まる前には、タスクＡ−Ｅがタスク待ち行列４１の中に保管されている。タスクの要求があると、タスクＡをタスク待ち行列４１から取り出して、待ち行列マネージャ４２に渡す。
【００３３】
それからタスクＡは待ち行列マネージャ４２に自分の処理特性を知らせる。これは「主張特性」と呼ぶ。
【００３４】
タスクＡを扱う次のステップは、その処理特性とシステム資源の使用可能度とにより決定される。すなわち、どのプロセッサ１６が利用可能であってタスクＡの要求に合っているかにより、タスクはその方向に向けられる。すなわち、待ち行列マネージャ４２はタスクＡの主張する処理特性を読んで、どの資源が利用可能であるかを決定する。タスクＡの要求にあう資源の利用可能度により、スケジューラ４２はプロセッサ１６にタスクＡを割当てて実行させるか、もしくは実行を遅らせる。
【００３５】
タスクＡが実行開始されると、タスクＡはアラームドライバ４３に「パンチイン」する。アラームドライバ４３は前述の機能を監視する役を果たす。タイミング発生器４４がタスクＡの処理時間を計る。タスクＡが自分の主張した時間以内で処理を完了すれば、タスクＡはパンチアウトし、アラームはオフになる。性能データが集められて、タスクＡ用に記憶される。タイミング発生器４４で使われるタイマは周知のハードウェアのタイミング装置のうち任意のものでよい。
【００３６】
しかし、もしタスクＡの実行が自分の主張した時間よりも長くかかったならば、タイミング発生器４４がプロセッサ１６に割込み信号を送る。割込み信号はアラームサービスルーチン４３ａを動かし、それがアラーム信号を送ってオーバタイムマネージャ４５を動かす。
【００３７】
オーバタイムマネージャ４５はタスクＡの処理状態を診断して、メモリ故障、無限ループ、デッドロックあるいはスタック不良のような問題が遅延を引起こしているか否かを決定する。オーバタイムマネージャ４５はまた、タスクを再スケジュールするとか、あるいはバッファを操作するというような、遅延の解決方法も決定する。オーバタイムマネージャ４５はまた、タスクが誤った実行時間の期待値を提供したに過ぎないのか否かも決定する。オーバタイムマネージャはアラーム信号により作動開始させられる優先度の高いタスクとして働く。
【００３８】
前述の例において、もしタスクＡが５ｍｓプラス小さい「スロップ」時間要因より長時間かかったならば、アラームが発せられる。オーバタイムマネージャ４５はバッファ戦略を変更するか、タスクＡを停止するか、あるいはタスクＡがもっと短い時間で実行されるアルゴリズムでプログラムするか、もしくは他の管理決定法を実行する。
【００３９】
オーバタイムマネージャ４５にタスクの処理特性に関する情報を提供することにより、タスクをの実行を延期することができる。例えば、ＲＡＭを要求することにより、前述したバッファの操作が可能になる。いいかえれば、タスクの実行を延期してそのデータをバッファに記憶することができる。更に、ＲＡＭの要求はプロセッサ比の倍数でなされるから、オーバタイムマネージャ４５は所定量のデータに対してどの位処理時間がかかるかと共に、メモリの容量がどのくらい必要かも知る。
【００４０】
オーバタイムマネージャ４５の他の特徴は、タスクが延期されたときに、低下技法を提供することである。例えば、オーバタイムマネージャ４５はプロセッサ比という表現により集約度の低いタスクを呼出すことができる。このタスクはユーザに代わりのサービスを提供して、サービスが完全に欠落するのを避けることができる。例えば、代わりのサービスがビジィ信号を発生し続けることがある。
【００４１】
ディジタルプロセッサ１６により実行されるタスクの処理特性を監視する能力をスケジューラシステムが有しているので、実行時間中これらの特性を動的に修正することが可能である。あるいは、これらの特性を別々に試験してシステムに供給することもできよう。
【００４２】
以上、本発明を特定の実施例について説明したが、限定的意味を持つものではない。開示した実施例をいろいろ修正したり、代わりの実施例を考えたりすることは当業者にとって容易である。したがって、本発明の範囲はすべてのそれらの修正例を含むものである。
【００４３】
【発明の効果】
以上説明したように本発明によれば資源が効率よく割当てられ、リアルタイム応答性にすぐれたマルチプロセッサ、マルチタスキングシステムが提供される。
【図面の簡単な説明】
【図１】 信号プロセッサシステムと通信可能なホストプロセッサを有する、マルチプロセッサ、マルチタスキングコンピュータ処理システムのブロック図。
【図２】 電話通信の処理に利用される、図１のマルチプロセッサシステムの典型的な応用を示すブロック図。
【図３】 図１の各信号プロセッサのプログラムとデータの記憶に関する機能ブロック図。
【図４】 図１の各信号プロセッサ用のスケジューリングシステムのプログラムの構成図。
【符号の説明】
１１ ホストプロセッサシステム
１２ ホストプロセッサ
１３ メモリ
１５ 信号プロセッサシステム
１６ 信号プロセッサ
１７ メモリ
１９ バス

Claims (6)

1. マルチタスキング、マルチプロセッサシステムの複数のプロセッサにより実行されるタスクのスケジューリング方法であって、
   複数のタスクを特定のシーケンスで実行する要求のアプリケーションプログラムを実行するステップと、
   前記実行が要求される複数のタスクの処理特性を決めるステップと、
   前記複数のタスクを前記処理特性を表わすデータ構造に関連づけるステップと、
   前記複数のタスクをタスク待ち行列に配置するステップと、
   前記複数のタスクの中から実行するために第１のタスクを取り出すステップと、
   スケジューラプログラムに前記第１のタスクの処理特性を伝えるステップと
   前記処理特性と利用可能な資源とに応じて、前記スケジューラプログラムを用いて、前記第１のタスクで使うべき処理資源を選択するステップと、
   前記第１のタスクが前記処理資源の利用を開始する時アラームドライバを活性化し、実際の処理特性を生成するために前記利用を計測するステップと、
   前記実際の処理特性が予め定められた値を超えた場合には、オーバータイムマネージャーを活性化するステップを有し、その際、オーバータイムマネージャーは前記タスクの実行を停止し、前記第１のタスクの処理状態を診断して障害が遅延を引き起こしているか否かを決定し、もしそうならば該遅延の解決方法を決定し、処理特性は不正か否かを判定しており、更に
   タスクを取り出し、処理特性を伝え、処理資源を選択し、アラームドライバとオーバータイムマネージャーを活性化するステップを、もし適切ならば、全てのタスクが実行されるまで繰り返すステップを有する方法。
2. 請求項１記載の方法において、更に、前記伝えられた特性と前記実際の特性を比較するステップを含む方法。
3. 請求項２記載の方法において、更に、前記実際の特性が前記伝えられた特性を予め定められた値越えた時、割り込みサービスを活性化するステップを含む方法。
4. 請求項１記載の方法において、更に、前記伝えられた特性を前記実際の特性に基づいて修正するステップを含む方法。
5. 請求項１記載の方法において、前記処理特性はプロセッサの使用比率を含む方法。
6. 請求項１記載の方法において、前記アラームマネージャは代わりの処理方法を決めステップを含む方法。

Images