JPH09319595A - マルチタスク制御装置 - Google Patents

Abstract

(57)【要約】 【課題】 高速なスケジューリング処理を可能とするマ
ルチタスク制御装置を提供する。 【解決手段】 前処理部１１、イベントフラグ管理部１
２、セマフォ管理部１３、メール管理部１４、タスク状
態データ保持部１５、状態遷移テーブル保持部１６、ス
ケジューリング管理部１７、タスク切替え管理部１８、
後処理部１９、状態遷移テーブル生成部２０を備え、ス
ケジューリング管理部１７が、イベントフラグ管理部１
２、セマフォ管理部１３、メール管理部１４からの事象
の発生の通知を受けて、タスク状態データ保持部１５の
内容と、状態遷移テーブル保持部１６に保持されている
状態遷移テーブルとを参照し、事象の発生後に実行すべ
きタスクを判定して、必要に応じてタスク切替え管理部
１８にタスクの切替えを指示する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、オぺレーティング
システム（以下「ＯＳ」と略称する）によるマルチタス
ク制御を行うマルチタスク制御装置に関する。

【０００２】

【従来の技術】近年、マイコン制御を行う家電製品等の
分野において、複数のタスクを有するマルチタスクプロ
グラムの実行に際して、同期通信機能を用いてタスクの
切替えを行うマルチタスク制御装置が広く利用されてい
る。ここで、同期通信機能とは、複数のタスクの処理を
同期して進行させるためにタスク間で通信を行う機能の
ことである。以下、同期通信機能を用いた従来のマルチ
タスク制御装置について説明する。

【０００３】図２３は、従来のマルチタスク制御装置の
構成を示すブロック図である。同図に示されるマルチタ
スク制御装置は、前処理部９１、イベントフラグ管理部
９２、セマフォ管理部９３、メール管理部９４、状態遷
移キュー９５、スケジューリング管理部９６、タスク切
替え管理部９７、後処理部９８を有する。前処理部９１
は、マルチタスク制御装置が、タスク若しくは割り込み
ルーチンからシステム呼び出し命令によって駆動された
直後に、呼び出し元を表す識別子の保存処理等、前処理
として毎回行う必要のある処理を行う。

【０００４】ここで、呼び出し元を表す識別子の保存を
行う必要性は、呼び出し元によって復帰時の処理内容に
相違があることに起因する。即ち、マルチタスク制御装
置がタスクから駆動された場合には、復帰時にタスクの
切替えを行っても何ら問題は起きない。しかし、割り込
みルーチンから駆動された場合には、割り込み処理を全
て終了してタスクに制御が戻るときにはタスクの切替え
を行ってもよいが、それ以外の場合、例えば多重割り込
みが行われた状態で割り込みルーチンから駆動された場
合のように、戻り先も割り込みルーチンであるような場
合にはタスクの切替えを行うことはできない。これは、
戻り先が割り込みルーチンである場合にタスクの切替え
を行ってしまうと、本来の戻り先である呼び出し元の割
り込みルーチンに戻れなくなってしまうというＯＳの機
能に基づくものである。

【０００５】従って、マルチタスク制御装置からの復帰
時には、呼び出し元を識別して、呼び出し元に応じた処
理を行う必要があるため、呼び出し元を表す識別子の保
存処理が必要となるのである。イベントフラグ管理部９
２は、マルチタスク制御装置がタスク若しくは割り込み
ルーチンからイベントフラグの設定命令又は待ち命令に
より駆動された場合にイベントフラグの設定処理等を行
う。

【０００６】ここで、イベントフラグとは、ＯＳが管理
するデータ領域（以下「ＯＳ領域」と呼ぶ）に、複数の
フラグＩＤごとに保持されているビットパタンを意味す
る。イベントフラグの設定命令とは、タスク若しくは割
り込みルーチンからフラグＩＤとビットパタンとを指定
してイベントフラグの設定を行う命令である。具体的に
は、例えばタスク若しくは割り込みルーチンにおいて "
setflag(setpattern,flagID)" というような命令が発行
されると、イベントフラグ管理部９２によりflagIDで指
定されたフラグＩＤを有するＯＳ領域にsetpatternで指
定されたビットパタンが設定される。設定命令は、タス
ク及び割り込みルーチンの両方から発行される場合があ
る。

【０００７】一方、イベントフラグの待ち命令とは、タ
スクからフラグＩＤとビットパタンを指定して、当該フ
ラグＩＤを有するＯＳ領域に設定されているビットパタ
ンと、タスクにより指定されたビットパタンとが一致す
るか否かを問い合わす命令である。具体的には、例えば
タスクにおいて "waitflag(waitpattern,flagID)" とい
うような命令が発行されると、イベントフラグ管理部９
２はflagIDで指定されたＩＤを有するＯＳ領域に設定さ
れているビットパタンと、waitpatternで指定されたビ
ットパタンとを比較する。比較の結果、両者が一致して
いれば命令を発行したタスクをそのまま処理を実行する
ことが可能であるが、一致していなければ待機状態（以
下「Ｗａｉｔ状態」と呼ぶ）となる。Ｗａｉｔ状態と
は、事象の発生によりタスクが実行可能状態（以下「Ｒ
ｅａｄｙ状態」と呼ぶ）となるまで（以下、Ｗａｉｔ状
態のタスクが事象の発生によりＲｅａｄｙ状態となるこ
とを「起床する」と称する）処理の実行を中断している
状態である。この場合の例であれば、他のタスク若しく
は割り込みルーチンから発行されたイベントフラグの設
定命令により、両者のビットパタンが一致するするまで
Ｗａｉｔ状態が継続する。なお、イベントフラグの待ち
命令はタスクのみから発行され、割り込みルーチンから
発行されることはない。

【０００８】Ｗａｉｔ状態において、事象の発生により
タスクが起床すると、当該タスクはまずＲｅａｄｙ状態
となり、当該タスクの優先度が最も高い場合や、他にＲ
ｅａｄｙ状態のタスクが存在しない場合等、当該タスク
を実行することが可能な状況が整えば実行状態（以下
「Ｒｕｎ状態」と呼ぶ）となる。イベントフラグの待ち
命令において、waitpatternで指定されたビットパタン
は、個々のタスクに割り当てられたＴＣＢ(Task Contro
l Block)に、フラグＩＤの指定と共に保持される。

【０００９】イベントフラグ管理部９２は、マルチタス
ク制御装置がイベントフラグの設定命令により駆動され
た場合には、イベントフラグの設定処理後、当該フラグ
ＩＤを有するフラグに対してビットパタンを指定してＷ
ａｉｔ状態となっているタスクが存在するか否かを検索
する。検索の結果Ｗａｉｔ状態のタスクが存在し、か
つ、Ｗａｉｔ状態のタスクにより指定されているビット
パタンと、設定処理後のＯＳ領域のビットパタンとが一
致した場合にはＷａｉｔ状態のタスクが起床する。この
場合、イベントフラグ管理部９２は、事象の発生による
タスクの起床をスケジューリング管理部９６に通知す
る。

【００１０】また、イベントフラグ管理部９２は、マル
チタスク制御装置がイベントフラグの待ち命令により駆
動された場合には、前述のとおりタスクにより指定され
たビットパタンとＯＳ領域のビットパタンとを比較し、
一致していればそのままタスクの処理の実行を継続す
る。一致しない場合には、タスクがＷａｉｔ状態となる
ため、イベントフラグ管理部９２はタスクのＷａｉｔ状
態への変化をスケジューリング管理部９６に通知する。

【００１１】セマフォ管理部９３は、資源に割り振られ
たＩＤごとに、その時点での資源の割当可能量を保持す
るカウンタを有しており、マルチタスク制御装置が、タ
スク若しくは割り込みルーチンから資源獲得要求及び資
源開放要求により駆動された場合にカウンタの更新処理
等を行う。ここで、資源獲得要求とはタスクから資源の
ＩＤと資源の獲得要求量を指定して発行される命令であ
る。具体的には、例えば "waitsem(semID,reqNo)" とい
うような命令が発行されると、セマフォ管理部９３はre
qNoで指定された要求量と、semIDで指定されたＩＤを有
する資源についてのカウンタに保持されている割当可能
量とを比較する。割当可能量が獲得要求量以上であれ
ば、セマフォ管理部９３がカウンタの値から獲得要求量
を減算し、タスクに対して、要求された資源が割り当て
られて、当該タスクの処理が継続実行されるが、割当可
能量が獲得要求量を下回っている場合には、当該タスク
は、他のタスクからの資源開放要求により当該資源の割
当可能量が増加して獲得要求量以上となるまでＷａｉｔ
状態となる。

【００１２】一方、資源開放要求とは、タスクから資源
のＩＤと資源の開放要求量を指定して発行される命令で
ある。具体的には、例えば "sigsem(semID,relNo)" と
いうような命令が発行されると、semIDで指定されたＩ
Ｄを有する資源についてのカウンタの値を加算する。な
お、資源開放要求は、タスク及び割り込みルーチンの両
方から発行される可能性があるが、資源獲得要求はタス
クのみから発行され、割り込みルーチンから発行される
ことはない。

【００１３】セマフォ管理部９３は、マルチタスク制御
装置が資源開放要求により駆動された場合には、カウン
タの値の加算の後、当該資源の割当可能量の増加を待っ
てＷａｉｔ状態となっているタスクが存在するか否かを
検索する。検索の結果Ｗａｉｔ状態のタスクが存在し、
かつ、Ｗａｉｔ状態のタスクにより要求されている資源
量が、加算後のカウンタの値以下である場合には、Ｗａ
ｉｔ状態のタスクが起床する。この場合セマフォ管理部
９３は、事象の発生によるタスクの起床をスケジューリ
ング管理部９６に通知する。

【００１４】セマフォ管理部９３は、マルチタスク制御
装置が資源獲得要求により駆動された場合には、前述の
とおりカウンタに保持されている資源の割当可能量が獲
得要求量以上であれば、カウンタの値を減算して、その
ままタスクの処理の実行を継続する。割当可能量が獲得
要求量を下回る場合は当該タスクがＷａｉｔ状態となる
ため、セマフォ管理部９３は、タスクのＷａｉｔ状態へ
の変化をスケジューリング管理部９６に通知する。

【００１５】メール管理部９４は、マルチタスク制御装
置がタスク若しくは割り込みルーチンからメールの受信
命令又は送信命令により駆動された場合にメールの管理
処理等を行う。メールは複数のメールボックスＩＤごと
に、メッセージを伴って、送信された順に保持される。
メールの受信命令とは、タスクからメールボックスＩＤ
を指定して当該メールボックスにメールが保持されてい
るか否かを問い合わす命令である。具体的には、例えば
"waitmsg(boxID,ptr)" というような命令が発行される
と、boxIDで指定されたメールボックスにメールが保持
されているか否かを検索する。メールが保持されていれ
ば、受信命令を発行したタスクは、そのメールを受信し
て処理の実行を継続することができる。ptrには、メッ
セージが存在する位置のアドレスが返されるので、タス
クはメッセージ領域に保持されたデータを使用して処理
を継続する。

【００１６】メールが保持されていなければ、タスク
は、他のタスクから当該メールボックスにメールが送信
されるまでＷａｉｔ状態となる。また、メールの送信命
令とは、タスク若しくは割り込みルーチンから、メール
ボックスＩＤとメッセージ保持領域のアドレスとを指定
してメールを送信する命令である。具体的には "sendms
g(boxID,ptr)" というような命令が発行されると、boxI
Dで指定されたメールボックスにptrで指定されたアドレ
スに保持されるメッセージを伴うメールが送信される。

【００１７】なお、メールの送信命令は、タスク及び割
り込みルーチンの両方から発行される可能性があるが、
メールの受信命令はタスクのみから発行され、割り込み
ルーチンから発行されることはない。メール管理部９４
は、マルチタスク制御装置がメールの送信命令により駆
動された場合には、メールの送信処理を行った後、当該
メールボックスへのメールの送信を待ってＷａｉｔ状態
となっているタスクが存在するか否かを検索する。

【００１８】検索の結果Ｗａｉｔ状態のタスクが存在し
ていれば、Ｗａｉｔ状態のタスクが起床することになる
ので、メール管理部９４は、事象の発生によるタスクの
起床をスケジューリング管理部９６に通知する。メール
管理部９４は、マルチタスク制御装置がメールの受信命
令により駆動された場合には、前述のとおり指定された
メールボックスにメールが保持されていれば、タスクに
メールを渡して、そのままタスクの処理の実行を継続す
る。メールが保持されていない場合は、受信命令を発行
したタスクがＷａｉｔ状態となるため、メール管理部９
４は、タスクのＷａｉｔ状態への変化をスケジューリン
グ管理部９６に通知する。

【００１９】状態遷移キュー９５は、ＲｕｎキューとＲ
ｅａｄｙキューとから構成される。ＲｕｎキューとはＲ
ｕｎ状態のタスクのＴＣＢが接続されている領域であ
り、Ｒｅａｄｙキューとは、Ｒｅａｄｙ状態のタスク
が、例えば優先順位の順に待ち行列を形成している領域
である。スケジューリング管理部９６は、イベントフラ
グ管理部９２、セマフォ管理部９３、メール管理部９４
からの通知を受け、Ｒｕｎ状態からＷａｉｔ状態となっ
たタスクをＲｕｎキューから切り離したり、事象の発生
により起床したタスクについて、Ｒｅａｄｙ状態の各々
のタスクの優先度を比較しながら、Ｒｅａｄｙキューの
待ち行列の並び順を管理するとともに、優先度の高いタ
スクから順にＲｕｎキューに接続されるようにスケジュ
ーリングを行う。

【００２０】タスク切替え管理部９７は、スケジューリ
ング管理部９６のスケジューリングに従って、実際にレ
ジスタの退避／復帰等のタスクの切替え処理を行う。後
処理部９８は、前処理部９１において保存された呼び出
し元の識別子等の更新、削除等、マルチタスク制御の最
後に毎回行う必要のある処理を行う。以上のように構成
されたマルチタスク制御装置について、以下、その動作
を具体例を用いて説明する。図２４は、本具体例におけ
る状態遷移キュー９５の状態を示す図である。

【００２１】例えば、三つのタスクＡ、Ｂ、Ｃが存在
し、タスクＡが最高優先度、タスクＢが次の優先度、タ
スクＣが最低優先度であり、タスクＡがＷａｉｔ状態、
タスクＢがＲｕｎ状態、タスクＣがＲｅａｄｙ状態であ
る場合を仮定する。タスクＡはメールボックスＸにメー
ルが送信されるのを待っているＷａｉｔ状態であるとし
て、Ｒｕｎ状態であるタスクＢからメールボックスＸに
対するメールの送信命令が発行された場合の動作につい
て説明する。

【００２２】まず前処理部９１は、タスクＢからメール
の送信命令により駆動されたことを表す識別子の保存等
のＯＳ共通処理を行う。今回の例ではメールの送信命令
により呼び出されているのでメール管理部９４による処
理が行われる。メール管理部９４は、メールボックスＸ
にメールを送信した後、メールボックスＸへのメールの
送信を待ってＷａｉｔ状態となっているタスクが存在す
るか否かを検索する。検索の結果、タスクＡが起床して
Ｒｅａｄｙ状態となることが判明するので、メール管理
部９４は、メールの送信によるタスクの起床をスケジュ
ーリング管理部９６に通知する。

【００２３】スケジューリング管理部９６は、メール管
理部９４の通知を受け、まず状態遷移キュー９５の状態
を図２４（ａ）から図２４（ｂ）のように変更する。即
ち、Ｗａｉｔ状態であったタスクＡがＲｅａｄｙ状態と
なるのでタスクＡのＴＣＢをＲｅａｄｙキューに繋ぐ。
この際、タスクＡの優先度はタスクＣの優先度より高い
ので、Ｒｅａｄｙキューのサーチの結果、タスクＡ、タ
スクＣの順にＲｅａｄｙキューに繋がれることになる。

【００２４】次にスケジューリング管理部９６はＲｕｎ
状態であるタスクＢと、Ｒｅａｄｙ状態であるタスクの
中で最も優先度の高いタスクであるタスクＡとの優先度
を比較し、状態遷移キュー９５の状態を図２４（ｂ）か
ら図２４（ｃ）のように変更する。即ち、タスクＡの優
先度の方がタスクＢの優先度より高いので、タスクＡの
ＴＣＢをＲｕｎキューに繋ぎ、タスクＢのＴＣＢをＲｅ
ａｄｙキューに繋ぐ。この場合、タスクＢの優先度はタ
スクＣの優先度よりも高いのでＲｅａｄｙキューのサー
チの結果タスクＢ、タスクＣの順にＲｅａｄｙキューに
繋がれる。

【００２５】スケジューリング管理部９６は、Ｒｕｎキ
ューに繋がれたタスクの変化を検知し、タスクの切替え
が必要であることをタスク切替え管理部９７に通知す
る。タスク切替え管理部９７は、レジスタの退避／復帰
等、実際のタスク切替えに必要な処理を行い、後処理部
９８に制御を渡す。後処理部９８が、タスクＢから駆動
されたことを示す識別子の削除等のＯＳ共通処理を行っ
た後、マルチタスク制御装置の処理が終了する。処理終
了後はタスクＡの処理が実行される。

【００２６】

【発明が解決しようとする課題】しかしながら、上記の
ような従来のマルチタスク制御装置においては、イベン
トフラグの設定、メールの送信等の事象の発生によりタ
スクのＷａｉｔ状態が解除され、Ｒｅａｄｙ状態となっ
た場合に、キューサーチ、キュー接続などのキュー操作
が必要であること、及び、Ｒｅａｄｙ状態となったタス
クとＲｕｎ状態のタスクとの優先度の比較処理、Ｒｅａ
ｄｙ状態のタスク同士の優先度の比較処理、タスク切替
え時のＲｕｎキュー、Ｒｅａｄｙキューの操作等が必要
であり、スケジューリング処理が遅いという問題点を有
していた。その結果、例えば高速な制御処理を行う必要
がある場合には、高機能を有する汎用的なマルチタスク
ＯＳを使用することができない等の問題が生じていた。

【００２７】本発明は上記の問題点に鑑み、高速なスケ
ジューリング処理を可能とするマルチタスク制御装置を
提供することを目的とする。

【００２８】

【課題を解決するための手段】上記の問題点を解決する
目的で、本発明に係るマルチタスク制御装置は、複数の
タスクを実行するシステムに備えられ、事象の発生に応
じて、前記システムが実行するタスクの切替えを行うマ
ルチタスク制御装置において、前記複数のタスクのそれ
ぞれが、実行状態、実行可能状態、待機状態を含む各種
の状態の中のどの状態にあるかを表すシステム状態ごと
に、各事象が発生した場合に次に実行すべきタスクを決
定する情報を保持する状態遷移テーブルと、事象の発生
を検知する事象検知手段と、前記事象検知手段により事
象の発生が検知された場合に、前記状態遷移テーブルを
参照し、その時点におけるシステム状態から次に実行す
べきタスクを判定する判定手段と、前記判定手段の判定
に応じてタスクの切替えを行うタスク切替え手段とを有
する。

【００２９】また、前記判定手段は、その時点における
システム状態を保持する保持部を有することもできる。
また、前記状態遷移テーブルは、前記システムにおいて
存在し得るシステム状態について、システム状態ごと
に、各事象が発生した場合の遷移先のシステム状態を保
持することができる。

【００３０】さらに、前記状態遷移テーブルにおいて、
各々のシステム状態には、優先度の高いタスクが実行状
態であるシステム状態から、昇順又は降順にて状態番号
が割り振られ、前記判定手段は、状態遷移テーブルに保
持されている遷移先のシステム状態の状態番号から次に
実行すべきタスクを判定することが可能である。前記マ
ルチタスク制御装置はさらに、タスクと、タスクごとの
優先度と、各々のタスクを実行可能状態に起床させる事
象との定義を含むシステム定義テーブルから、前記状態
遷移テーブルを生成する状態遷移テーブル生成手段を備
えることもできる。

【００３１】また、前記状態遷移テーブル生成手段は、
前記システム定義テーブルから、各タスクの状態の全て
の組み合わせを生成する状態生成手段と、所定のシステ
ム状態に関する規則に従って、前記状態生成手段が生成
した組み合わせから、前記システムにおいて存在し得な
いシステム状態を表す組み合わせを削除することによ
り、前記システムにおいて存在し得るシステム状態を表
す組み合わせを抽出する状態抽出手段と、前記状態抽出
手段により抽出された組み合わせから、前記状態遷移テ
ーブルを生成するテーブル生成手段とを有することも可
能である。

【００３２】さらに、前記状態抽出手段は、前記システ
ムの機能に基づくシステム状態に関する規則と、アプリ
ケーション固有の理由に基づくシステム状態に関する規
則とに従って前記システム状態を表す組み合わせを抽出
することが可能である。

【００３３】

【発明の実施の形態】以下、本発明の一実施の形態につ
いて図面を参照しながら説明する。図１は、本実施の形
態に係るマルチタスク制御装置の構成を示すブロック図
である。同図に示されるマルチタスク制御装置は、前処
理部１１、イベントフラグ管理部１２、セマフォ管理部
１３、メール管理部１４、タスク状態データ保持部１
５、状態遷移テーブル保持部１６、スケジューリング管
理部１７、タスク切替え管理部１８、後処理部１９を有
する。

【００３４】なお、本実施の形態のマルチタスク制御装
置は、ＯＳをＣＰＵが実行することにより実現されてい
る点、及び、ＣＰＵにおいて、イベントフラグの設定命
令及び待ち命令、資源の獲得要求及び開放要求、メール
の送信命令及び受信命令等の命令が実行される毎に駆動
されるものである点については、従来の技術で説明した
マルチタスク制御装置と同一である。

【００３５】前処理部１１は、本実施の形態のマルチタ
スク制御装置が、タスク若しくは割り込みルーチンから
駆動された直後に、呼び出し元を表す識別子の保存処理
等、前処理として毎回行う必要のある処理を行う。イベ
ントフラグ管理部１２は、マルチタスク制御装置がタス
ク若しくは割り込みルーチンからイベントフラグの設定
命令又は待ち命令により駆動された場合に、イベントフ
ラグに関する事象の発生及び当該事象の発生に伴うシス
テム状態の変化を管理する。システム状態とは、各々の
タスクがＲｕｎ状態、Ｒｅａｄｙ状態、Ｗａｉｔ状態の
何れの状態であるかを示す情報である。

【００３６】具体的には、マルチタスク制御装置が、イ
ベントフラグの設定命令で駆動された場合には、イベン
トフラグの設定処理を行う他、当該フラグの設定により
システム状態に変化があった場合に、設定命令で指定さ
れたフラグＩＤを有するフラグの設定という事象の発生
をスケジューリング管理部１７に通知する。また、マル
チタスク制御装置が、イベントフラグの待ち命令で駆動
された場合には、駆動したタスクがＷａｉｔ状態に変化
した場合に、マルチタスク制御装置を駆動したタスクの
Ｗａｉｔ状態への変化という事象の発生をスケジューリ
ング管理部１７に通知する。

【００３７】セマフォ管理部１３は、マルチタスク制御
装置が、タスク若しくは割り込みルーチンから資源の獲
得要求又は資源開放要求により駆動された場合に、資源
の制御に関する事象の発生及び当該事象の発生に伴うシ
ステム状態の変化を管理する。具体的には、マルチタス
ク制御装置が、資源の開放要求で駆動された場合には、
カウンタの加算処理を行う他、当該資源に開放によりシ
ステム状態に変化があった場合に、資源の開放という事
象の発生をスケジューリング管理部１７に通知する。ま
た、マルチタスク制御装置が、資源の獲得要求で駆動さ
れた場合には、駆動したタスクがＷａｉｔ状態に変化し
た場合に、マルチタスク制御装置を駆動したタスクのＷ
ａｉｔ状態への変化という事象の発生をスケジューリン
グ管理部１７に通知する。

【００３８】メール管理部１４は、マルチタスク制御装
置が、タスク若しくは割り込みルーチンからメールの受
信命令又は送信命令により駆動された場合に、メールに
関する事象の発生及び当該事象の発生に伴うシステム状
態の変化を管理する。具体的には、マルチタスク制御装
置がメールの送信命令で駆動された場合には、当該メー
ルの送信でシステム状態に変化があった場合に、送信命
令で指定されたメールボックスＩＤを有するメールボッ
クスへのメールの送信という事象の発生をスケジューリ
ング管理部１７に通知する。また、マルチタスク制御装
置が、メールの受信命令で駆動された場合には、駆動し
たタスクがＷａｉｔ状態に変化した場合に、マルチタス
ク制御装置を駆動したタスクのＷａｉｔ状態への変化と
いう事象の発生をスケジューリング管理部１７に通知す
る。

【００３９】タスク状態データ保持部１５には、実行中
のタスクを示す識別子が保持されている。状態遷移テー
ブル保持部１６は、現在のシステム状態と、発生した事
象とから、状態遷移後のシステム状態を判定するための
状態遷移テーブルを保持する。状態遷移テーブルは、状
態遷移テーブル生成部２０にて予め生成される。状態遷
移テーブルのデータ構造及び生成方法については後述す
る。

【００４０】スケジューリング管理部１７は、イベント
フラグ管理部１２、セマフォ管理部１３、メール管理部
１４からの通知を受け、タスク状態データ保持部１５及
び状態遷移テーブル保持部１６の内容を参照して、タス
ク切替えが必要か否かを判定し、タスク切替えが必要な
場合にタスク切替え管理部１８に指示する。タスク切替
え管理部１８は、スケジューリング管理部１７の指示に
従って、レジスタの退避／復帰等のタスクの切替え処理
を行うとともに、タスク状態データ保持部１５の内容を
更新する。

【００４１】後処理部１９は、前処理部１１において保
存された呼び出し元の識別子等の更新、削除等、マルチ
タスク制御の最後に毎回行う必要のある処理を行う。図
２は本実施の形態のマルチタスク制御装置の処理内容を
示すフロ−チャ−トである。本実施の形態のマルチタス
ク制御装置は、タスク若しくは割り込みルーチンからの
システム呼び出し命令を受けて動作を開始する（Ｓ１０
１）。

【００４２】まず、前処理部１１がシステム呼び出しを
行ったタスク若しくは割り込みルーチンの識別子を保存
する等のＯＳ共通処理を行う（Ｓ１０２）。次に、シス
テム呼び出し命令の内容に基づき、イベントフラグ管理
部１２、セマフォ管理部１３、メール管理部１４の何れ
かによる処理が行われる。例えば、システム呼び出し時
の命令がイベントフラグの設定命令であれば、イベント
フラグ管理部１２により、フラグ設定命令処理が行われ
る（Ｓ１０４）。また、イベントフラグの待ち命令であ
れば、イベントフラグ管理部１２により、フラグ待ち命
令処理が行われる（Ｓ１０５）。

【００４３】また、システム呼び出し時の命令が資源の
開放要求であれば、セマフォ管理部１３により、資源開
放要求処理が行われ（Ｓ１０６）、資源獲得要求であれ
ばセマフォ管理部１３により、資源獲得要求処理処理が
行われる（Ｓ１０７）。また、システム呼び出し時の命
令がメール送信命令であれば、メール管理部１４によ
り、メール送信処理が行われ（Ｓ１０８）、メールの受
信命令であればメール管理部１４により、メール受信処
理が行われる（Ｓ１０９）。

【００４４】図３は、イベントフラグ管理部１２が行う
フラグ設定命令処理の詳細な処理内容を示すフロ−チャ
−トである。イベントフラグ管理部１２は、イベントフ
ラグの設定命令において指定されたフラグＩＤにより示
されたＯＳのイベントフラグ領域に、指定されたビット
パタンを設定し（Ｓ２０１）、当該フラグＩＤを指定し
てＷａｉｔ状態となっているタスクを検索する（Ｓ２０
２）。検索の結果、Ｗａｉｔ状態となっているタスクが
存在していれば（Ｓ２０３：Ｙｅｓ）、設定命令により
設定されたビットパタンが、Ｗａｉｔ状態のタスクによ
って指定されているビットパタンと一致するか否かを調
べる（Ｓ２０４）。ビットパタンが一致していれば、Ｗ
ａｉｔ状態のタスクが起床することによりシステム状態
が変化するため、イベントフラグ管理部１２は、ビット
パタンのクリアを行い（Ｓ２０５）、イベントフラグの
設定という事象の発生をスケジューリング管理部１７に
通知する（Ｓ２０６）。なお、ステップＳ２０５におけ
るビットパタンのクリアについては、ＯＳの仕様や、処
理内容等によっては行わない場合もある。

【００４５】Ｗａｉｔ状態となっているタスクが存在し
ない（Ｓ２０３：Ｎｏ）か、タスクが存在してもビット
パタンが一致しない場合（Ｓ２０４：Ｎｏ）は、システ
ム状態に何ら変化がないことを意味するので、そのまま
イベントフラグ管理部１２の処理を終了する。図４は、
イベントフラグ管理部１２が行うフラグ待ち命令処理の
詳細な処理内容を示すフロ−チャ−トである。イベント
フラグ管理部１２は、フラグの待ち命令において指定さ
れたフラグＩＤを有するＯＳ領域に保持されているビッ
トパタンが、待ち命令により指定されたビットパタンと
一致しているか否かを比較する（Ｓ２１１）。一致して
いれば、システム状態に何ら変化が起きないことを意味
するのでイベントフラグ管理部１２は、ビットパタンの
クリアを行い（Ｓ２１４）、処理を終了する。ビットパ
タンのクリア処理を行わない場合もあることはフラグ設
定命令処理と同様である。

【００４６】一致していなければ、待ち命令を発行した
タスクがＷａｉｔ状態となるので、イベントフラグ管理
部１２は、タスクのＷａｉｔ状態への変化という事象の
発生をスケジューリング管理部１７に通知する（Ｓ２１
３）。図５は、セマフォ管理部１３が行う資源開放要求
処理の詳細な処理内容を示すフロ−チャ−トである。セ
マフォ管理部１３は、資源開放命令において指定された
ＩＤにより示された資源の割当可能量を保持しているカ
ウンタに、開放された資源の量を加算し（Ｓ３０１）、
当該資源の獲得待ちとしてＷａｉｔ状態になっているタ
スクが存在するか否かを検索する（Ｓ３０２）。検索の
結果、Ｗａｉｔ状態となっているタスクが存在する場合
にはステップＳ３０１におけるカウンタの加算により起
床するタスクが発生するか否かを判定する（Ｓ３０
４）。起床するタスクが発生すれば、当該起床するタス
クの資源獲得要求量だけ、カウンタの減算を行い（Ｓ３
０５）、資源の開放という事象の発生をスケジューリン
グ管理部１７に通知する（Ｓ３０６）。

【００４７】Ｗａｉｔ状態となっているタスクが存在し
ない場合（Ｓ３０３：Ｎｏ）か、Ｗａｉｔ状態のタスク
が存在しても、当該タスクによる資源の獲得要求量が更
新後のカウンタの値を上回っている場合（Ｓ３０４：Ｎ
ｏ）には、システム状態に何ら変化がないことを意味す
るので、そのままセマフォ管理部１３の処理を終了す
る。

【００４８】図６は、セマフォ管理部１３が行う資源獲
得要求処理の詳細な処理内容を示すフロ−チャ−トであ
る。セマフォ管理部１３は、資源獲得要求の命令中で指
定されたＩＤにより示された資源の割当可能量を保持し
ているカウンタに保持されている値を、命令中で指定さ
れた資源の獲得要求量と比較する（Ｓ３１１）。カウン
タに保持されている値が資源の獲得要求量以上である場
合には、当該タスクが要求した資源を確保して、そのま
ま処理の実行を継続することを意味する。従って、セマ
フォ管理部１３はカウンタの値から資源の要求量を減算
して（Ｓ３１４）、処理を終了する。

【００４９】カウンタに保持されている値が資源の獲得
要求量を下回っている場合には、当該タスクは資源待ち
としてＷａｉｔ状態となるため、セマフォ管理部１３
は、タスクのＷａｉｔ状態への変化という事象の発生を
スケジューリング管理部１７に通知する（Ｓ３１３）。
図７は、メール管理部１４が行うメール送信処理の詳細
な処理内容を示すフロ−チャ−トである。

【００５０】メール管理部１４は、命令中で指定された
ＩＤにより示されたメールボックスにメッセージを送信
する（Ｓ４０１）。その後、当該メールボックスへのメ
ールの送信を待ってＷａｉｔ状態となっているタスクが
存在するか否かを検索する（Ｓ４０２）。Ｗａｉｔ状態
のタスクが存在する場合は、当該Ｗａｉｔ状態のタスク
が起床することを意味する。この場合、メール管理部１
４は、当該Ｗａｉｔ状態のタスクにメールを渡し（Ｓ４
０４）、メールの受信という事象の発生をスケジューリ
ング管理部１７に通知する（Ｓ４０５）。Ｗａｉｔ状態
のタスクが存在しなければ（Ｓ４０３：Ｎｏ）、システ
ム状態に何ら変化がないことを意味するので、そのまま
メール管理部１４の処理を終了する。

【００５１】図８は、メール管理部１４が行うメール受
信処理の詳細な処理内容を示すフロ−チャ−トである。
メール管理部１４は、命令中で指定されたメールボック
スＩＤを有するメールボックスの内容を検索する（Ｓ４
１１）。指定されたメールボックスにメールが存在すれ
ば、当該タスクがそのメールを受信し、そのまま処理を
継続実行できる事を意味するので、メール管理部１４
は、呼び出したタスクにメールを渡し（Ｓ４１４）、そ
のまま処理を終了する。

【００５２】指定されたメールボックスにメールが存在
しなければ（Ｓ４１２：Ｎｏ）、受信命令を発行したタ
スクは、他のタスクからのメールの送信があるまでＷａ
ｉｔ状態となるため、メール管理部１４は、タスクのＷ
ａｉｔ状態への変化という事象の発生をスケジューリン
グ管理部１７に通知する（Ｓ４１３）。以上のように、
イベントフラグ管理部１２、セマフォ管理部１３、メー
ル管理部１４の何れかによる処理が終了すると、図２の
フロ−チャ−トに戻って、各事象管理部からのスケジュ
ーリング管理部１７への事象の発生の通知が行われたか
否かを見る（Ｓ１１０）。ここで、事象の発生の通知が
行われていないということは、システム状態に何ら変化
がないことを意味するので、スケジューリング管理部１
７及びタスク切替え管理部１８の処理は行われず、その
ままステップＳ１１１へと進む（Ｓ１１０：Ｎｏ）。

【００５３】各事象管理部から、スケジューリング管理
部１７への通知があった場合には、スケジューリング管
理部１７の処理が行われる（Ｓ１１１）。図９はスケジ
ューリング管理部１７の詳細な処理内容を示すフロ−チ
ャ−トである。スケジューリング管理部１７は、まずイ
ベントフラグ管理部１２、セマフォ管理部１３、メール
管理部１４の何れかからの通知を受けて事象の発生を検
知し（Ｓ５０１）、状態遷移テーブル保持部１６を参照
する。本実施の形態においては、スケジューリング管理
部１７は現在のシステム状態を表す状態番号（システム
状態には、後述するように状態番号が割り振られてい
る）を保持しているので、現在の状態番号と、発生した
事象とから、状態遷移後の状態番号を判定する（Ｓ５０
２）。

【００５４】図１５は状態遷移テーブルのデータ構造を
示す図である。状態遷移テーブルの生成方法について
は、後で詳細に説明するが、ここでは、状態遷移テーブ
ルの使用方法について簡単に説明する。図１５に示す状
態遷移テーブルは、縦軸に現在の状態番号をとり、横軸
に発生した事象をとる。状態番号とは、システム状態ご
とに割り振られた番号である。また、この例では横軸と
して、Ｒｕｎ状態のタスクがＷａｉｔ状態となる場合
（以下「Ｗａｉｔ状態への変化」と呼ぶ）、フラグの設
定命令が発行され、フラグＩＤが「ＦＬＡＧ＿Ａ」であ
るイベントフラグ領域にビットパタンが設定された場合
（以下「フラグＡの設定」と呼ぶ）、メールボックスＩ
Ｄが「ＭＢＸ＿Ｂ」であるメールボックスにメールが送
信された場合（以下「メッセージＢの送信」と呼ぶ）、
メールボックスＩＤが「ＭＢＸ＿Ｃ」であるメールボッ
クスにメールが送信された場合（以下「メッセージＣの
送信」と呼ぶ）の四つの事象が取られており、現在の状
態番号により示されるシステム状態において、それぞれ
の事象が発生した場合の、状態遷移後の状態番号が示さ
れている。

【００５５】即ち、図１５の状態遷移テーブルでは、例
えば状態番号１のシステム状態において、マルチタスク
制御装置を駆動したタスクがＷａｉｔ状態となった場合
には、状態番号４のシステム状態に遷移することを意味
している。ここで、状態番号は、優先度の高いタスクが
Ｒｕｎ状態であるシステム状態ほど小さい状態番号を有
するように割り振られている。図１５の例では、状態番
号が１、２、３であるシステム状態では、最も優先度の
高いタスクＡがＲｕｎ状態であり、状態番号が４、５で
あるシステム状態では、次に優先度の高いタスクＢがＲ
ｕｎ状態であり、状態番号が６であるシステム状態で
は、最も優先度の低いタスクＣがＲｕｎ状態である。こ
のように状態番号を割り振ることにより、状態番号か
ら、Ｒｕｎ状態となるタスクを判別することが容易にな
る。

【００５６】スケジューリング管理部１７は、まず、タ
スク状態データ保持部１５に保持されているタスク状態
データを参照して、現在Ｒｕｎ状態であるタスク、即ち
マルチタスク制御装置を駆動したタスクを判定する。次
に、状態遷移テーブルを参照して得られる状態遷移後の
システム状態を表す状態番号から、状態遷移後にＲｕｎ
状態となるタスクを判定し、両者を比較する（Ｓ５０
３）ことによりタスク切替えが必要か否かを判定する
（Ｓ５０４）。

【００５７】ここで、呼び出し元が割り込みルーチンで
ある場合にはタスク切替えはできないので、タスク切替
えは必要でないと判定する（Ｓ５０５）。以上の判定に
より、タスク切替えが必要である場合にはタスク切替え
管理部１８にタスクの切替えを要求して（Ｓ５０６）処
理を終了する。なお、呼び出し元が割り込みルーチンで
ある場合（Ｓ５０５：Ｙｅｓ）には、割り込みルーチン
に復帰する際にタスク切替えを行うことはできないが、
割り込みルーチンによる処理が終了して、タスクに制御
が戻るときにタスクの切替えを行う必要がある。そのた
め、タスク切替えのマーク付けという処理を行う（Ｓ５
０７）。タスク切替えのマーク付けとは、ステップＳ５
０４における状態遷移後のタスクについて、後のタイミ
ング（タスクに制御が戻るとき）でのタスク切替えを行
うために、当該状態遷移後に行うべきタスクの識別子等
を保存する処理である。具体的には、ＯＳ領域に設けら
れている所定の領域に、切替えるべきタスクを表す識別
子を保存する等の方法で行う。

【００５８】スケジューリング管理部１７の処理が終了
した後は、図２のフロ−チャ−トに戻って、タスク切替
えが必要ない場合（Ｓ１１２：Ｎｏ）には、タスク切替
え管理部１８による処理は行われずにそのままステップ
Ｓ１１４へと進む。タスク切替えが必要な場合は、タス
ク切替え管理部１８により、レジスタの退避／復帰等の
処理及びタスク状態データ保持部１５の更新処理が行わ
れ（Ｓ１１３）、後処理部１９にて、呼び出し元を表す
情報の更新、削除等の共通処理が行われて（Ｓ１１
４）、マルチタスク制御装置の処理が終了する。

【００５９】以上のように、本実施の形態のマルチタス
ク制御装置では、事象の発生が検知された場合に、キュ
ー操作やタスク間の優先度の比較等の処理を行わず、状
態遷移テーブルを参照することにより状態遷移後のシス
テム状態を判定するという方法をとっているので、スケ
ジューリング処理を高速に行うことが可能となる。次
に、状態遷移テーブルの生成方法について説明する。

【００６０】図１０は、状態遷移テーブル生成部２０の
詳細な構成を示すブロック図である。同図に示されるよ
うに、状態遷移テーブル生成部２０は、状態生成部２
１、状態抽出部２２、テーブル生成部２３から構成され
る。なお、同図に示されるシステム定義テーブル保持部
３０は、システム定義テーブルを保持している部分であ
り、従来のマルチタスク制御装置においても存在してい
たものである。最も、システム定義テーブル保持部３０
が保持するテーブルの内容については、ＯＳの仕様等に
よって異なる場合もある。

【００６１】図１１はシステム定義テーブルの内容の一
例を示す図である。同図は、種々存在するシステム定義
テーブルの中で、状態遷移テーブルの生成に必要な部分
を表したものである。同図に示されるように、システム
定義テーブルの中には図１１（ａ）に示すタスク定義テ
ーブルと、図１１（ｂ）に示す同期通信機能定義テーブ
ルとが存在する。図１１（ａ）のタスク定義テーブル
は、タスク名、タスクの優先度、スタックサイズ等を定
義する。同図の優先度はその数字が小さいほど、優先度
が高いことを意味している。本実施の形態の例では、タ
スクＡ、タスクＢ、タスクＣの三つのタスクを定義して
いるが、タスクの数に特に制限はなく、また複数のタス
クに同一の優先度を付与することも可能である。図１１
（ｂ）の同期通信機能定義テーブルには、発生し得る事
象に関連するフラグＩＤ、資源のＩＤ、メールボックス
ＩＤと、当該事象と関連のあるタスク名とが定義されて
いる。同図の例では、フラグＩＤが「ＦＬＡＧ＿Ａ」で
あるイベントフラグがタスクＡと関連している旨の定義
がなされているが、これは、「ＦＬＡＧ＿Ａ」というフ
ラグＩＤを有するイベントフラグの設定が事象の発生と
して検知され、当該事象の発生によりタスクＡが起床す
ることを意味している。

【００６２】メールボックスＩＤ「ＭＢＸ＿Ｂ」、「Ｍ
ＢＸ＿Ｃ］についても同様であり、当該メールボックス
へのメールの送信が事象の発生として検知され、当該事
象の発生によりタスクＢ、タスクＣがそれぞれ起床する
ことを意味している。状態生成部２１は、システム定義
テーブル保持部３０に保持されているシステム定義テー
ブルを参照して、システム状態テーブルを生成する。

【００６３】図１２は、システム状態テーブルのデータ
構造を示す図である。同図に示されるように、システム
状態テーブルは、システム定義テーブルに定義されてい
るタスクが取り得る状態の組み合わせを全て定義したも
のである。同図の例では三つのタスクが定義されてお
り、各々の優先度は全て異なっているが、複数のタスク
の優先度が同一である場合も有り得る。そのような場合
は、同一の優先度のタスクについては、起床した順番に
よりシステム状態が異なるものとみなしてシステム状態
テーブルを生成する。

【００６４】状態抽出部２２は、ＯＳ規則に基づく状態
抽出部２２１と、アプリケーション固有規則に基づく状
態抽出部２２２とを含む。例えば、図１３（ａ）に示す
ようなＯＳの機能に基づくシステム状態に関する規則
（以下「ＯＳ規則」と呼ぶ）及び図１３（ｂ）に示すよ
うなアプリケーション固有の理由に基づくシステム状態
に関する規則（以下「アプリケーション固有規則」と呼
ぶ）が存在する場合に、ＯＳ規則に基づく状態抽出部２
２１は、ＯＳ規則に合致するシステム状態のみをシステ
ム状態テーブルから抽出し、アプリケーション固有規則
に基づく状態抽出部２２２は、アプリケーション固有規
則に合致するシステム状態のみをさらに抽出する。状態
抽出部２２は、抽出されたシステム状態に状態番号を割
り振り直すことにより、システム状態最小テーブルを生
成する。図１４（ｂ）は、システム状態最小テーブルの
一例である。

【００６５】テーブル生成部２３は、システム状態最小
テーブルから状態遷移テーブルを生成する。次に、状態
遷移テーブル生成部２０の処理内容について説明する。
図１６は状態遷移テーブル生成部２０の処理内容を示す
フロ−チャ−トである。状態遷移テーブル生成部２０は
まず、状態生成部２１による処理を行う（Ｓ７０１）。
状態生成部２１は、前述のとおり、図１１に示すシステ
ム定義テーブルを参照して、図１２に示すシステム状態
テーブルを生成する。具体的には、図１１（ａ）に示さ
れるタスク定義テーブルからタスク名を抽出し、図１１
（ｂ）に示される同期通信機能定義テーブルから関連す
る事象を抽出して、各々のタスクが取り得る状態の組み
合わせを全て定義することにより、システム状態テーブ
ルを生成する。ここで、Ｗａｉｔ（Ｆａ）は、フラグＩ
Ｄ「ＦＬＡＧ＿Ａ」を有するイベントフラグの設定を待
つＷａｉｔ状態であり、Ｗａｉｔ（Ｍｂ）は、メールボ
ックスＩＤ「ＭＢＸ＿Ｂ」を有するメールボックスへの
メールの送信を待つＷａｉｔ状態であることを意味す
る。Ｗａｉｔ（Ｍｃ）についてもＷａｉｔ（Ｍｂ）と同
様である。

【００６６】システム状態テーブルの生成を終了する
と、図１６のフロ−チャ−トに戻って、状態遷移テーブ
ル生成部２０は、状態抽出部２２による処理として、ま
ず、ＯＳ規則に基づく状態抽出部２２１による処理を行
う（Ｓ７０２）。図１７はＯＳ規則に基づく状態抽出処
理の詳細な処理内容を示すフロ−チャ−トである。ＯＳ
規則に基づく状態抽出部２２１は、まず図１３（ａ）に
示すＯＳ規則（１）に基づいて、システム状態テーブル
から、Ｒｕｎ状態のタスクがシステムで二つ以上存在す
る組み合わせを削除する（Ｓ８０１）。この処理によ
り、システム状態テーブルから、状態番号が５、６、
８、９、１１〜１８、２０〜２７であるシステム状態を
表す組み合わせが抽出される。

【００６７】次に、ＯＳ規則に基づく状態抽出部２２１
は、ＯＳ規則（２）に基づいて、最高優先度のタスクが
Ｒｅａｄｙ状態となっている組み合わせを削除する（Ｓ
８０２）。本実施の形態の例では、最高優先度のタスク
はタスクＡであるので、この処理により、状態番号が
５、６、８、９、２０〜２７であるシステム状態を表す
組み合わせが抽出される。

【００６８】次に、ＯＳ規則に基づく状態抽出部２２１
は、ＯＳ規則（３）に基づいて、Ｒｕｎ状態のタスクが
存在する場合に、そのタスクよりも優先度の高いタスク
がＲｅａｄｙ状態となっている組み合わせを削除する
（Ｓ８０３）。本実施の形態の例では、タスクＡ、タス
クＢ、タスクＣの順に優先度が高いので、ステップＳ８
０２における抽出の結果を考慮すると、本ステップの処
理で削除の対象となるのはタスクＢがＲｅａｄｙ状態で
あり、かつ、タスクＣがＲｕｎ状態である組み合わせで
ある。即ち、この処理により、状態番号が５、６、８、
９、２０、２１、２３〜２７であるシステム状態を表す
組み合わせが抽出される。

【００６９】最後に、ＯＳ規則に基づく状態抽出部２２
１は、ＯＳ規則（４）に基づいてＲｅａｄｙ状態のタス
クが存在し、かつ、Ｒｕｎ状態のタスクが存在しない組
み合わせを削除する（Ｓ８０４）。この処理により、状
態番号が５、６、８、９、２０、２１、２５、２７であ
るシステム状態を表す組み合わせが抽出される。ＯＳ規
則に基づく状態抽出処理を終了すると、図１６のフロ−
チャ−トに戻って状態抽出部２２は、アプリケーション
固有規則に基づく状態抽出処理を行う（Ｓ７０３）。ア
プリケーション固有規則に基づく状態抽出部２２２は、
図１３（ｂ）に示すアプリケーション固有規則に基づい
て、ＯＳ規則に基づく状態抽出処理で抽出されたシステ
ム状態から、タスクＢとタスクＣとが同時にＷａｉｔ状
態となる組み合わせを削除する。この処理によリ、状態
番号が５、６、８、２０、２１、２５であるシステム状
態を表す組み合わせが抽出される。

【００７０】以上の抽出処理により、状態抽出部２２
は、図１４（ａ）に示すような状態抽出後のシステム状
態テーブルを得る。状態抽出部２２は、テーブルのサイ
ズ効率等の点で有利なように状態番号を割り当て直し、
最終的に図１４（ｂ）に示すようなシステム状態最小テ
ーブルを生成する。前述の如く、本実施の形態では、状
態番号の割り当ては、優先度の高いタスクがＲｕｎ状態
であるシステム状態ほど小さい状態番号を有するように
行っているが、状態番号の順番については、逆に、優先
度の高いタスクがＲｕｎ状態であるシステム状態ほど大
きい状態番号を有するように行うことも可能である。何
れの場合も、状態番号の範囲からＲｕｎ状態となるタス
クを判別することができる。

【００７１】状態抽出部２２によるシステム状態最小テ
ーブルの生成が終了すると、テーブル生成部２３が、シ
ステム状態最小テーブルと、システム定義テーブルとを
参照して、状態遷移テーブルを生成する（Ｓ７０４）。
状態遷移テーブルとは、前述のとおり、現在のシステム
状態と、発生した事象とから、状態遷移後のシステム状
態を判定すべく定義されたテーブルである。

【００７２】図１８及び図１９は、テーブル生成部２３
の詳細な処理内容を示すフロ−チャ−トである。テーブ
ル生成部２３は、まず、システム定義テーブルを参照し
て、タスク及びタスクに関連した事象の情報を抽出する
（Ｓ９０１）。例えば図１１に示した例では、タスク定
義テーブルから切替えが行われるタスク及びタスクの優
先度が抽出され、同期通信機能定義テーブルに定義され
ているタスクに関連したフラグＩＤ、メールボックスＩ
Ｄ等の情報からはタスクに関連した事象が抽出される。
ここで、抽出とは必ずしも別の領域に抽出することを意
味せず、テーブルの生成中に必要に応じてシステム定義
テーブルを参照しても差し支えない。

【００７３】ループＡの処理は、システム状態最小テー
ブルに含まれる全てのシステム状態について順次行われ
る（Ｓ９０２）。テーブル生成部２３は、システム状態
最小テーブルから一つずつシステム状態を読み出す（Ｓ
９０３）。ループＢの処理は、Ｒｕｎ状態のタスクがＷ
ａｉｔ状態に変化する場合と、ステップＳ９０１で同期
通信機能定義テーブルから抽出された事象が発生した場
合とを含む、発生し得る全ての事象について行われる
（Ｓ９０４）。

【００７４】即ち、ループＡ及びループＢの処理は、ス
テップＳ９０３において読み出されたシステム状態を現
在のシステム状態と仮定し、当該システム状態において
事象が発生した場合の状態遷移を、発生した事象ごとに
シミュレートして、図１５のような状態遷移テーブルの
マトリックスを一つずつ埋めていく処理である。以下、
ループＢにおける処理の内容について、具体例を示しな
がら詳細に説明する。

【００７５】テーブル生成部２３は、まず、どの事象が
発生した場合についてシミュレートを行うかを決定する
（Ｓ９０５）。その後、ステップＳ９０５において決定
された事象が、Ｒｕｎ状態のタスクがＷａｉｔ状態に変
化する場合であるか否かを判定する（Ｓ９０６）。これ
は、Ｒｕｎ状態のタスクがＷａｉｔ状態に変化する場合
と、事象の発生によりタスクが起床した場合とでは、明
らかに異なる種類の状態遷移を伴うからである。

【００７６】Ｒｕｎ状態のタスクがＷａｉｔ状態に変化
する場合についての状態遷移のシミュレート処理であれ
ば（Ｓ９０６：Ｙｅｓ）、まず、選択されたシステム状
態においてＲｕｎ状態であったタスクが、Ｗａｉｔ状態
に変化するものと仮定する（Ｓ９０７）。例えば、状態
番号１のシステム状態において、Ｒｕｎ状態のタスクが
Ｗａｉｔ状態に変化した場合を仮定すれば、図２０に示
す例のように、まずタスクＡがＷａｉｔ状態に変化した
ものとする（図２０（ｂ））。

【００７７】次に、残りのタスクの中で、Ｒｅａｄｙ状
態となっているタスクがあるか否かを判定する（Ｓ９０
８）。Ｒｅａｄｙ状態のタスクがなければ、図１９のフ
ロ−チャ−トに移って、状態遷移後のシステム状態の状
態番号を検索する（Ｓ９０９）。ここで、該当するシス
テム状態がシステム状態最小テーブルに存在すれば（Ｓ
９１０：Ｙｅｓ）、該当するシステム状態の状態番号を
状態遷移テーブルの対応する位置に保存する（Ｓ９１
１）。しかし、前記システム状態がシステム状態最小テ
ーブルに存在しない場合は、状態遷移後のシステム状態
を未定義とする（Ｓ９１２）。この場合、状態遷移テー
ブルのマトリックスには、状態遷移後の状態番号が未定
義であることを示すフラグ（図１５の例では「−」）が
設定される。

【００７８】ステップＳ９０８において、Ｒｅａｄｙ状
態のタスクが存在すれば、図１９のフロ−チャ−トに移
って、Ｒｅａｄｙ状態のタスクの中で最も優先度が高い
タスクが複数存在するか否かを判定する（Ｓ９１３）。
図２０の例であれば、図２０（ｂ）の状態においてＲｅ
ａｄｙ状態のタスクの中で最も優先度の高いタスクはタ
スクＢのみである。従ってステップＳ９１３ではＮｏと
判定されることになる。

【００７９】最も優先度の高いＲｅａｄｙ状態のタスク
が一つであれば（Ｓ９１３：Ｎｏ）、事象の発生によ
り、そのタスクがＲｕｎ状態となるため、Ｒｅａｄｙ状
態のタスクをＲｕｎ状態として状態遷移後のシステム状
態を決定する（Ｓ９１４）。図２０の例では、タスクＢ
がＲｕｎ状態となる（図２０（ｃ））。最も優先度の高
いＲｅａｄｙ状態のタスクが複数存在する場合は、どの
タスクをＲｕｎ状態とするかをシステムの仕様等に基づ
いて決定しておく必要がある。例えば最先に起床したタ
スクをＲｕｎ状態にする方法が考えられるが、他の方法
で決定してもよい。何れにしても、状況に応じて適切な
タスクがＲｕｎ状態に変化することになる（Ｓ９１
５）。ここでの詳細な説明は割愛するが、優先度が同一
であるタスクについては、システム状態テーブル生成時
に起床した順番ごとに別のシステム状態として定義する
ことにより対処を行う。

【００８０】以上のように状態遷移後のシステム状態が
決定されると、決定されたシステム状態に対応する状態
番号をシステム状態最小テーブルから検索し（Ｓ９０
９）、該当するシステム状態が、システム状態最小テー
ブルに存在すれば（Ｓ９１０：Ｙｅｓ）、検索された状
態番号を状態遷移テーブルに保存する（Ｓ９１１）。図
２０の例であれば、図２０（ｃ）に示されるシステム状
態の状態番号は４であるため、図２０（ｄ）に示される
ように、状態番号４が状態遷移テーブルの所定の位置に
保存されることになる。ステップＳ９１０において、シ
ステム状態がシステム状態最小テーブルに存在しなけれ
ば、状態遷移後のシステム状態を未定義とする（Ｓ９１
２）。

【００８１】一方、ステップＳ９０６において、Ｎｏと
判定された場合、即ち、Ｒｕｎ状態のタスクがＷａｉｔ
状態となる場合以外の事象の発生を仮定する場合には、
ステップＳ９０５で決定された事象に関連するタスク
が、現在のシステム状態においてＷａｉｔ状態であるか
否かを判定する（Ｓ９１６）。Ｗａｉｔ状態でない場合
とは、システム状態に何ら変更が無いことを意味するも
のであり、状態遷移テーブルが参照されない場合である
ので、状態遷移後のシステム状態を未定義とし（Ｓ９１
２）、ループＢの先頭に戻る。Ｗａｉｔ状態である場合
は、事象の発生によりタスクが起床することとなるの
で、当該Ｗａｉｔ状態のタスクをＲｅａｄｙ状態とする
（Ｓ９１７）。

【００８２】事象の発生によるシステム状態の遷移をシ
ミュレートする処理の一例を図２１に示す。同図に示さ
れる例は、状態番号６のシステム状態において、イベン
トフラグＩＤ「ＦＬＡＧ＿Ａ」を有するイベントフラグ
のＯＳ領域に、タスクＣが発行したフラグ設定命令によ
りビットパタンの設定がなされることによりタスクＡが
起床する場合の例である。同図に示される例では、「Ｆ
ＬＡＧ＿Ａ」のビットパタンの一致により、タスクＡが
Ｒｅａｄｙ状態となる（図２１（ｂ））。

【００８３】次に、テーブル生成部２３はステップＳ９
１７でＲｅａｄｙ状態となったタスクの優先度と、現在
のシステム状態においてＲｕｎ状態であるタスクの優先
度とを比較する（Ｓ９１８）。Ｒｕｎ状態のタスクの優
先度の方が、Ｒｅａｄｙ状態のタスクの優先度より高い
場合（Ｓ９１８：Ｙｅｓ）には、Ｒｕｎ状態のタスクが
そのまま継続実行されるので、図１９のフロ−チャ−ト
に移り、状態遷移後のシステム状態を表す状態番号を検
索し（Ｓ９０９）、システム状態がシステム状態最小テ
ーブルに存在すれば（Ｓ９１０：Ｙｅｓ）、状態番号を
状態遷移テーブルのマトリックスの所定の位置に保存す
る（Ｓ９１１）。

【００８４】図２１（ｂ）に示す例のように、Ｒｅａｄ
ｙ状態のタスクの優先度の方が、Ｒｕｎ状態のタスクの
優先度より高い場合（Ｓ９１８：Ｎｏ）には、Ｒｕｎ状
態のタスクをＲｅａｄｙ状態に変更し（Ｓ９１９）、図
１９のフロ−チャ−トのステップＳ９１３に進む。図２
１（ｂ）の例ではステップＳ９１９においてタスクＣが
Ｒｅａｄｙ状態に変更され（図２１（ｃ））、先に説明
したステップＳ９１３の判定の後、ステップＳ９１４に
おいてタスクＡをＲｕｎ状態とする（図２１（ｄ））。

【００８５】以上のように状態遷移後のシステム状態が
決定されると、ステップＳ９０９において、決定された
システム状態に対応する状態番号をシステム状態最小テ
ーブルから検索し、システム状態がシステム状態最小テ
ーブルに存在すれば（Ｓ９１０：Ｙｅｓ）、検索された
状態番号を状態遷移テーブルに保存する（Ｓ９１１）。
図２１の例であれば、図２１（ｄ）に示されるシステム
状態の状態番号が３であるため、図２１（ｅ）に示され
るように、状態番号３が状態遷移テーブルの所定の位置
に保存されることになる。

【００８６】以上のような処理を発生し得る全ての事象
について行い（Ｓ９２０）、さらに、システム状態最小
テーブルに含まれている全ての状態について行う（Ｓ９
２１）ことで、図１５に示すような状態遷移テーブルを
機械的に生成することができる。図１５に示す状態遷移
テーブルにおいて、網掛け部分の状態遷移においてタス
ク切替えが発生することを意味している。

【００８７】なお、本実施の形態では、最も一般的な例
として、各タスクが取り得る状態がＷａｉｔ状態、Ｒｅ
ａｄｙ状態、Ｒｕｎ状態の三種類であるシステムについ
て詳細に説明したが、ＯＳの機能によっては、他の状態
を取り得る場合もある。例えばサスペンド状態、サスペ
ンド待機状態、休止状態等である。図２２に、それらの
状態を含めた状態遷移図を示す。ここで、前記各状態に
ついて簡単に説明しておくと、サスペンド状態とは、タ
スクが強制的な待ち状態に置かれている状態である。具
体的には、当該タスクがＲｅａｄｙ状態である場合にお
いて他のタスクから中断命令が発行された場合や、サス
ペンド待機状態において、フラグの設定命令等により待
ちが解除された場合にとり得る状態であり、他のタスク
から、再開命令が発行されることによりＲｅａｄｙ状態
となる。ここで、中断命令とは、例えば"suspend(taskI
D)"というようにタスクＩＤを指定して発行され、再開
命令も、例えば"resume(taskID)"というようにタスクＩ
Ｄを指定して発行されるが、何れもシステム状態の変化
を伴う。

【００８８】サスペンド待機状態とは、Ｗａｉｔ状態に
おいて中断命令が発行された場合にとり得る状態であ
り、前述の如く、事象の発生による待ちの解除によりサ
スペンド状態に遷移する。また、他のタスクから再開命
令が発行された場合には、Ｗａｉｔ状態に戻る。休止状
態とは、スタック等のタスク実行のための最小限の資源
をも開放し、タスクの実行を休止している状態である。
休止状態へは、Ｒｕｎ状態のタスク自身の中で終了命令
を発行した場合や、Ｒｅａｄｙ状態、Ｗａｉｔ状態等の
状態から強制終了命令が発行された場合に遷移する。ま
た、休止状態からは、他のタスクから起動命令が発行さ
れた場合に、Ｒｅａｄｙ状態に移行する。

【００８９】ここで、終了命令は、例えば"exittask"と
いうような命令をＲｕｎ状態のタスク自体が発行するこ
とにより、当該Ｒｕｎ状態のタスク自身を休止状態に遷
移させる。中断命令は、例えば"terminate(taskID)"と
いうようにタスクＩＤを指定して発行され、起動命令
は、例えば"starttask(taskID)"というようにタスクＩ
Ｄを指定して発行される。何れもシステム状態の変化を
伴う。

【００９０】しかしながら、図２２に示された状態遷移
図及び以上の説明から明らかなように、何れの状態につ
いても、マルチタスク制御装置を駆動する際のシステム
呼び出し命令に基づく事象の発生により状態遷移が起こ
る点において前記Ｗａｉｔ、Ｒｅａｄｙ、Ｒｕｎの三種
類の状態と本質的に同一であり、状態遷移テーブルを用
いたタスク切替えについても、状態遷移テーブルの生成
についても、今回詳細に説明した方法を若干拡張するこ
とにより容易に適用することが可能である。

【００９１】即ち、タスク切替え時にあっては、前記中
断命令や、再開命令等の発行を事象の発生とみなして、
状態遷移テーブルを参照することにより状態遷移後のシ
ステム状態を判定し、さらに状態遷移後のシステム状態
から状態遷移後に実行すべきタスクを判定する。状態遷
移テーブルの生成においては、本実施の形態において説
明したような事象発生時の状態遷移のシミュレート処理
を、前記中断命令や、再開命令等についても、状態遷移
図に基づいて行うようにすれば良い。

【００９２】また、本実施の形態では、状態遷移テーブ
ルとして、状態番号番号ごとに、各事象が発生した後の
システム状態を表す状態番号を保持する形としたが、テ
ーブルのフォーマットは、本実施の形態の例に限られ
ず、状態遷移後に実行すべきタスクが決定できるもので
あれば他のフォーマットにしてもよく、例えば、システ
ム状態を表すテーブルを直接保持するようにしても構わ
ない。

【００９３】また、本実施の形態では、処理の高速化を
優先して、タスク状態データ保持部１５に、現在実行中
のタスクに関する情報を保持する形にしたが、前述の如
く、スケジューリング管理部１７に保持されている状態
番号から、現在実行中のタスクを判別することも可能で
ある。また、本実施の形態ではスケジューリング管理部
１７にその時点での状態番号を保持したが、システム状
態を認識することができれば、必ずしも状態番号の形で
保持する必要はない。また、システム状態を識別するた
めの情報も、常に保持せずに、事象の発生時にシステム
状態を検知するようにしてもよい。

【００９４】また、状態抽出部２２による状態抽出処理
においても、本実施の形態で用いたシステム状態に関す
る規則以外のシステム状態に関する規則に基づいて、シ
ステム状態最小テーブルを生成することも可能である。
また、本実施の形態では、前処理部１１で行われる処理
について、その全ての処理を毎回実行するようにした
が、前処理部１１にて行うべき処理の中には、必ずしも
毎回行う必要はない処理が含まれている場合もある。そ
のような処理については、例えば各事象管理部によりシ
ステム状態の変化が検知された場合のみに、各事象管理
部の処理の後で行うようにすることも可能である。その
場合には、前処理部１１の処理として行われなかった処
理に対応する後処理については、後処理部１９において
も行う必要はない。

【００９５】

【発明の効果】以上の説明から明らかなように、本発明
に係るマルチタスク制御装置は、複数のタスクを実行す
るシステムに備えられ、事象の発生に応じて、前記シス
テムが実行するタスクの切替えを行うマルチタスク制御
装置において、前記複数のタスクのそれぞれが、実行状
態、実行可能状態、待機状態を含む各種の状態の中のど
の状態にあるかを表すシステム状態ごとに、各事象が発
生した場合に次に実行すべきタスクを決定する情報を保
持する状態遷移テーブルと、事象の発生を検知する事象
検知手段と、前記事象検知手段により事象の発生が検知
された場合に、前記状態遷移テーブルを参照し、その時
点におけるシステム状態から次に実行すべきタスクを判
定する判定手段と、前記判定手段の判定に応じてタスク
の切替えを行うタスク切替え手段とを備え、判定手段
は、前記事象検知手段により事象の発生が検知された場
合に、システム状態ごとに、各事象が発生した場合に次
に実行すべきタスクを決定する情報を保持する状態遷移
テーブルを参照して、その時点におけるシステム状態か
ら次に実行すべきタスクを判定するので、事象の発生時
に、状態遷移キューのサーチ、キュー接続などのキュー
操作や、Ｒｕｎ状態のタスクとのＲｅａｄｙ状態のタス
クの優先度の比較処理、Ｒｅａｄｙ状態のタスク同士の
優先度の比較処理、タスク切替え時の状態遷移キューの
繋ぎかえ操作等を行う必要がなく、スケジューリング処
理を高速に行うことが可能になるという効果がある。

【００９６】また、前記判定手段は、その時点における
システム状態を保持する保持部を有することも可能であ
る。その場合には、各事象の発生時に、その時点でのシ
ステム状態を検知する必要がないため、スケジューリン
グ処理をより高速に行うことができるという効果があ
る。また、前記状態遷移テーブルは、前記システムにお
いて存在し得るシステム状態について、システム状態ご
とに、各事象が発生した場合の遷移先のシステム状態を
保持することが可能である。前記状態遷移テーブルが前
記システムにおいて存在し得るシステム状態についての
み保持することにより、状態遷移テーブルを保持する領
域が節約できるとともに、システム状態ごとに、各事象
が発生した場合の遷移先のシステム状態を保持すること
により、状態遷移後のシステム状態を、各々のタスクの
状態を調べることなく、迅速に認識することができると
いう効果がある。

【００９７】また、前記状態遷移テーブルにおいて、各
々のシステム状態には、優先度の高いタスクが実行状態
であるシステム状態から、昇順又は降順にて状態番号が
割り振られ、前記判定手段は、状態遷移テーブルに保持
されている遷移先のシステム状態の状態番号から次に実
行すべきタスクを判定することが可能である。システム
状態の抽出処理後に、システム状態に状態番号を割り振
り直すことにより、状態遷移テーブルを保持する領域が
節約できるとともに、前記の如く状態番号を割り振って
おけば、前記判定手段が、どのタスクがＲｕｎ状態とな
るかを容易に判定できるという効果がある。

【００９８】また、タスクと、タスクごとの優先度と、
各々のタスクを実行可能状態に起床させる事象との定義
を含むシステム定義テーブルから、前記状態遷移テーブ
ルを生成する状態遷移テーブル生成手段をさらに備える
こともできる。この場合には、状態遷移テーブル生成手
段が、システム定義テーブルから機械的に状態遷移テー
ブルを生成することにより、状態遷移テーブルの生成ミ
スを防止することができるという効果がある。

【００９９】また、前記状態遷移テーブル生成手段は、
前記システム定義テーブルから、各タスクの状態の全て
の組み合わせを生成する状態生成手段と、所定のシステ
ム状態に関する規則に従って、前記状態生成手段が生成
した組み合わせから、前記システムにおいて存在し得な
いシステム状態を表す組み合わせを削除することによ
り、前記システムにおいて存在し得るシステム状態を表
す組み合わせを抽出する状態抽出手段と、前記状態抽出
手段により抽出された組み合わせから、前記状態遷移テ
ーブルを生成するテーブル生成手段とを備えることが可
能である。

【０１００】状態生成手段が、システム定義テーブルを
参照して、各タスクの状態の全ての組み合わせを生成
し、状態抽出手段は、前記各タスクの状態の全ての組み
合わせから、システムにおいて存在し得ないシステム状
態を表す組み合わせを削除することにより、システムに
おいて存在し得るシステム状態を表す組み合わせを抽出
し、テーブル生成手段は、前記状態抽出手段により抽出
された組み合わせから状態遷移テーブルを生成すること
で、システムにおいて存在し得ないシステム状態につい
て状態遷移テーブルを生成することがなくなり、状態遷
移テーブルを保持する領域を節約することが可能となる
他、簡単なアルゴリズムで、状態遷移テーブルの生成ミ
スを防止することができるという効果がある。

【０１０１】また、前記状態抽出手段は、前記システム
の機能に基づくシステム状態に関する規則と、アプリケ
ーション固有の理由に基づくシステム状態に関する規則
とに従って前記システム状態を表す組み合わせを抽出す
ることが可能である。このような処理を行うことによ
り、オぺレーティングシステムの機能の変更や、アプリ
ケーションの変更に柔軟に対応できるという効果を有す
る。

【図面の簡単な説明】

【図１】本発明の一実施の形態におけるマルチタスク制
御装置の構成を示すブロック図である。

【図２】本発明の一実施の形態におけるマルチタスク制
御装置の処理内容を示すフロ−チャ−トである。

【図３】イベントフラグ管理部が行うフラグ設定命令処
理の詳細な処理内容を示すフロ−チャ−トである。

【図４】イベントフラグ管理部が行うフラグ待ち命令処
理の詳細な処理内容を示すフロ−チャ−トである。

【図５】セマフォ管理部が行う資源開放要求処理の詳細
な処理内容を示すフロ−チャ−トである。

【図６】セマフォ管理部が行う資源獲得要求処理の詳細
な処理内容を示すフロ−チャ−トである。

【図７】メール管理部が行うメール送信処理の詳細な処
理内容を示すフロ−チャ−トである。

【図８】メール管理部が行うメール受信処理の詳細な処
理内容を示すフロ−チャ−トである。

【図９】スケジューリング管理部の詳細な処理内容を示
すフロ−チャ−トである。

【図１０】状態遷移テーブル生成部の構成を示すブロッ
ク図である。

【図１１】（ａ）システム定義テーブルに含まれるタス
ク定義テーブルの内容の一例を示す図である。 （ｂ）システム定義テーブルに含まれる同期通信機能定
義テーブルの内容の一例を示す図である。

【図１２】システム状態テーブルのデータ構造を示す図
である。

【図１３】（ａ）ＯＳ規則の一例を示す図である。 （ｂ）アプリケーション固有規則の一例を示す図であ
る。

【図１４】（ａ）状態抽出部による状態抽出後のシステ
ム状態テーブルの一例を示す図である。 （ｂ）システム状態最小テーブルの一例を示す図であ
る。

【図１５】状態遷移テーブルの一例を示す図である。

【図１６】状態遷移テーブル生成部の処理内容を示すフ
ロ−チャ−トである。

【図１７】ＯＳ規則に基づく状態抽出処理の処理内容を
示すフロ−チャ−トである。

【図１８】テーブル生成部の処理内容を示すフロ−チャ
−トである。

【図１９】テーブル生成部の処理内容を示すフロ−チャ
−トである。

【図２０】テーブル生成部の処理内容を説明するための
図である。

【図２１】テーブル生成部の処理内容を説明するための
図である。

【図２２】サスペンド状態、サスペンド待機状態、休止
状態を含めた状態遷移図である。

【図２３】従来のマルチタスク制御装置の構成を示すブ
ロック図である。

【図２４】従来のマルチタスク制御装置の動作について
説明するための図である。

【符号の説明】

１１ 前処理部 １２ イベントフラグ管理部 １３ セマフォ管理部 １４ メール管理部 １５ タスク状態データ保持部 １６ 状態遷移テーブル保持部 １７ スケジューリング管理部 １８ タスク切替え管理部 １９ 後処理部 ２０ 状態遷移テーブル生成部 ２１ 状態生成部 ２２ 状態抽出部 ２２１ ＯＳ規則に基づく状態抽出部 ２２２ アプリケーション固有規則に基づく状態抽出
部 ２３ テーブル生成部 ３０ システム定義テーブル保持部

Claims (7)

【特許請求の範囲】
1. 【請求項１】 複数のタスクを実行するシステムに備え
   られ、事象の発生に応じて、前記システムが実行するタ
   スクの切替えを行うマルチタスク制御装置において、 前記複数のタスクのそれぞれが、実行状態、実行可能状
   態、待機状態を含む各種の状態の中のどの状態にあるか
   を表すシステム状態ごとに、各事象が発生した場合に次
   に実行すべきタスクを決定する情報を保持する状態遷移
   テーブルと、 事象の発生を検知する事象検知手段と、 前記事象検知手段により事象の発生が検知された場合
   に、前記状態遷移テーブルを参照し、その時点における
   システム状態から次に実行すべきタスクを判定する判定
   手段と、 前記判定手段の判定に応じてタスクの切替えを行うタス
   ク切替え手段とを有することを特徴とするマルチタスク
   制御装置。
2. 【請求項２】 前記判定手段は、 その時点におけるシステム状態を保持する保持部を有す
   ることを特徴とする請求項１記載のマルチタスク制御装
   置。
3. 【請求項３】 前記状態遷移テーブルは、 前記システムにおいて存在し得るシステム状態につい
   て、システム状態ごとに、各事象が発生した場合の遷移
   先のシステム状態を保持することを特徴とする請求項１
   又は２記載のマルチタスク制御装置。
4. 【請求項４】 前記状態遷移テーブルにおいて、 各々のシステム状態には、優先度の高いタスクが実行状
   態であるシステム状態から、昇順又は降順にて状態番号
   が割り振られ、 前記判定手段は、 状態遷移テーブルに保持されている遷移先のシステム状
   態の状態番号から次に実行すべきタスクを判定すること
   を特徴とする請求項３記載のマルチタスク制御装置。
5. 【請求項５】 前記マルチタスク制御装置はさらに、 タスクと、タスクごとの優先度と、各々のタスクを実行
   可能状態に起床させる事象との定義を含むシステム定義
   テーブルから、前記状態遷移テーブルを生成する状態遷
   移テーブル生成手段を備えることを特徴とする請求項１
   乃至４の何れかに記載のマルチタスク制御装置。
6. 【請求項６】 前記状態遷移テーブル生成手段は、 前記システム定義テーブルから、各タスクの状態の全て
   の組み合わせを生成する状態生成手段と、 所定のシステム状態に関する規則に従って、前記状態生
   成手段が生成した組み合わせから、前記システムにおい
   て存在し得ないシステム状態を表す組み合わせを削除す
   ることにより、前記システムにおいて存在し得るシステ
   ム状態を表す組み合わせを抽出する状態抽出手段と、 前記状態抽出手段により抽出された組み合わせから、前
   記状態遷移テーブルを生成するテーブル生成手段とを有
   することを特徴とする請求項５記載のマルチタスク制御
   装置。
7. 【請求項７】 前記状態抽出手段は、 前記システムの機能に基づくシステム状態に関する規則
   と、アプリケーション固有の理由に基づくシステム状態
   に関する規則とに従って前記システム状態を表す組み合
   わせを抽出することを特徴とする請求項６記載のマルチ
   タスク制御装置。