JP3524700B2 - タスク監視方法 - Google Patents
タスク監視方法Info
- Publication number
- JP3524700B2 JP3524700B2 JP29134396A JP29134396A JP3524700B2 JP 3524700 B2 JP3524700 B2 JP 3524700B2 JP 29134396 A JP29134396 A JP 29134396A JP 29134396 A JP29134396 A JP 29134396A JP 3524700 B2 JP3524700 B2 JP 3524700B2
- Authority
- JP
- Japan
- Prior art keywords
- task
- monitoring
- monitored
- priority
- monitoring task
- 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
Landscapes
- Debugging And Monitoring (AREA)
Description
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、複数のタスクを有
するマルチタスクシステムにおけるタスク監視方法に関
するものである。
するマルチタスクシステムにおけるタスク監視方法に関
するものである。
【０００２】
【従来の技術】監視タスクを有するマルチタスクシステ
ムにおける従来のタスク監視方法としては、特開平５−
２３３３３３号公報、特開平６−４３１８号公報に開示
されているように監視タスクのプライオリティを最上位
にして、各タスクの動作を監視する方法がある。この方
法によると、監視タスクの実行はどのタスクの実行より
も優先して行われる事になるので、メッセージの通信等
により常に他のタスクの監視を行う事ができる。よっ
て、異常が生じたタスクを容易に発見できる。
ムにおける従来のタスク監視方法としては、特開平５−
２３３３３３号公報、特開平６−４３１８号公報に開示
されているように監視タスクのプライオリティを最上位
にして、各タスクの動作を監視する方法がある。この方
法によると、監視タスクの実行はどのタスクの実行より
も優先して行われる事になるので、メッセージの通信等
により常に他のタスクの監視を行う事ができる。よっ
て、異常が生じたタスクを容易に発見できる。
【０００３】
【発明が解決しようとする課題】しかしながら、上記従
来例においては、監視タスクの実行はどのタスクよりも
優先して行われるので、他のタスクの実行に影響を及ぼ
す事になる。更に、監視タスクの監視内容を複雑にする
と、監視タスクに多くの資源（ＣＰＵパワー）が消費さ
れるため、アプリケーションの実行効率が落ちたり、タ
イミング等に影響を及ぼすという問題も生じる。
来例においては、監視タスクの実行はどのタスクよりも
優先して行われるので、他のタスクの実行に影響を及ぼ
す事になる。更に、監視タスクの監視内容を複雑にする
と、監視タスクに多くの資源（ＣＰＵパワー）が消費さ
れるため、アプリケーションの実行効率が落ちたり、タ
イミング等に影響を及ぼすという問題も生じる。
【０００４】本発明は、上記問題点を鑑みてなされたも
のであり、監視タスクを設けてタスクを監視するシステ
ムにおいて、監視タスクの実行が他のタスクの実行に与
える影響ができる限り少ないタスク監視方法を提供する
事を目的とする。
のであり、監視タスクを設けてタスクを監視するシステ
ムにおいて、監視タスクの実行が他のタスクの実行に与
える影響ができる限り少ないタスク監視方法を提供する
事を目的とする。
【０００５】
【課題を解決するための手段】本発明は、少なくとも一
つの被監視タスクと該被監視タスクを監視する第１の監
視タスクとを有するマルチタスクシステムのタスク監視
方法において、前記第１の監視タスクのプライオリティ
を前記被監視タスクのプライオリティより低くし、前記
マルチタスクシステムは第１の監視タスクの動作のみを
監視する第２の監視タスクを有し、前記第２の監視タス
クのプライオリティは前記被監視タスクのプライオリテ
ィより高くするように構成する。
つの被監視タスクと該被監視タスクを監視する第１の監
視タスクとを有するマルチタスクシステムのタスク監視
方法において、前記第１の監視タスクのプライオリティ
を前記被監視タスクのプライオリティより低くし、前記
マルチタスクシステムは第１の監視タスクの動作のみを
監視する第２の監視タスクを有し、前記第２の監視タス
クのプライオリティは前記被監視タスクのプライオリテ
ィより高くするように構成する。
【０００６】第１の監視タスクは、例えば各被監視タス
クへメッセージで問い合わせたり、各監視タスクの状態
を示すフラグを読み込む事によって被監視タスクの監視
を行う事ができる。ここで、第１の監視タスクのプライ
オリティは、どの被監視タスクより低いので、第１の監
視タスクの監視動作が他の被監視タスクの実行に及ぼす
影響は少ない。
クへメッセージで問い合わせたり、各監視タスクの状態
を示すフラグを読み込む事によって被監視タスクの監視
を行う事ができる。ここで、第１の監視タスクのプライ
オリティは、どの被監視タスクより低いので、第１の監
視タスクの監視動作が他の被監視タスクの実行に及ぼす
影響は少ない。
【０００７】また、第１の監視タスクの監視も第２の監
視タスクによりなされる事になる。また、第２の監視タ
スクの実行は第１の監視タスクの監視を行うだけなの
で、実行内容は単純であり、実行時間を短くする事は可
能なので、他の被監視タスクの実行に大きな影響を与え
ることはない。
視タスクによりなされる事になる。また、第２の監視タ
スクの実行は第１の監視タスクの監視を行うだけなの
で、実行内容は単純であり、実行時間を短くする事は可
能なので、他の被監視タスクの実行に大きな影響を与え
ることはない。
【０００８】また、前記第１の監視タスクは前記被監視
タスクの状態を監視し、各被監視タスク固有のとり得る
状態以外の状態であると判断した被監視タスクを異常と
判断するようにする。つまり、第１の監視タスクは被監
視タスクは被監視タスクの状態を読み込み、その状態を
予めテーブル等に登録されている状態と比較し、異常か
どうかを判定する事ができる。そして異常なタスクが特
定されたならば、その異常なタスクを例えば強制終了さ
せれば、システム全体がスムーズに実行される事にな
る。
タスクの状態を監視し、各被監視タスク固有のとり得る
状態以外の状態であると判断した被監視タスクを異常と
判断するようにする。つまり、第１の監視タスクは被監
視タスクは被監視タスクの状態を読み込み、その状態を
予めテーブル等に登録されている状態と比較し、異常か
どうかを判定する事ができる。そして異常なタスクが特
定されたならば、その異常なタスクを例えば強制終了さ
せれば、システム全体がスムーズに実行される事にな
る。
【０００９】
【００１０】
【００１１】
【発明の実施の形態】図１は本発明の第１の実施形態の
基本構成を示すブロック図である。リアルタイムＯＳ６
上に、制御実行するｎ個の被監視タスク３1〜３nと、被
監視タスク３を監視する第１の監視タスク１と、第１の
監視タスク１を監視する第２の監視タスク２とテーブル
１４が設けられている。
基本構成を示すブロック図である。リアルタイムＯＳ６
上に、制御実行するｎ個の被監視タスク３1〜３nと、被
監視タスク３を監視する第１の監視タスク１と、第１の
監視タスク１を監視する第２の監視タスク２とテーブル
１４が設けられている。
【００１２】テーブル１４は、第１の監視タスク１が参
照できるように設定されている。被監視タスク３のプラ
イオリティは３1、３2、３3、・・・、３nとなるに従っ
て低くなる。第１の監視タスク１のプライオリティは、
全ての被監視タスク３のプライオリティより低く設定さ
れている。
照できるように設定されている。被監視タスク３のプラ
イオリティは３1、３2、３3、・・・、３nとなるに従っ
て低くなる。第１の監視タスク１のプライオリティは、
全ての被監視タスク３のプライオリティより低く設定さ
れている。
【００１３】尚、プライオリティとは実行優先度を決め
るもので、実行可能状態のタスクが複数個存在した場
合、プライオリティの高いタスクから実行状態に遷移す
るようになっている。この事について、一般的なタスク
の状態と遷移の様子を示す図６を用いて説明する。タス
クは三つの基本状態、すなわち実行可能状態７、実行状
態８、待機状態９をとる。実行可能状態７はＣＰＵの使
用が可能な状態であり、実行状態８はＣＰＵを使用中の
状態であり、待機状態９は入出力動作などの終了を待っ
ている状態でＣＰＵが使用できない状態である。
るもので、実行可能状態のタスクが複数個存在した場
合、プライオリティの高いタスクから実行状態に遷移す
るようになっている。この事について、一般的なタスク
の状態と遷移の様子を示す図６を用いて説明する。タス
クは三つの基本状態、すなわち実行可能状態７、実行状
態８、待機状態９をとる。実行可能状態７はＣＰＵの使
用が可能な状態であり、実行状態８はＣＰＵを使用中の
状態であり、待機状態９は入出力動作などの終了を待っ
ている状態でＣＰＵが使用できない状態である。
【００１４】ＣＰＵを使用中のタスクが入出力動作など
の終了を待つ場合、矢印１０に従って遷移する。待って
いた事象（例えば入出力終了）が発生したタスクは、矢
印１１に従って遷移する。ＣＰＵ使用中のタスクがＣＰ
Ｕ使用権を他のタスクに移す場合、矢印１２に従って遷
移する。ＣＰＵ使用権が与えられたタスクは、矢印１３
に従って遷移する。
の終了を待つ場合、矢印１０に従って遷移する。待って
いた事象（例えば入出力終了）が発生したタスクは、矢
印１１に従って遷移する。ＣＰＵ使用中のタスクがＣＰ
Ｕ使用権を他のタスクに移す場合、矢印１２に従って遷
移する。ＣＰＵ使用権が与えられたタスクは、矢印１３
に従って遷移する。
【００１５】本実施形態のマルチタスクシステムのよう
に複数のタスクで一つのＣＰＵを使用する場合は、実行
状態８のタスクはシステムに一つしか存在しない。よっ
て、実行可能状態７にあるタスクの中から、プライオリ
ティの最も高いタスクが実行状態に遷移する事になる。
に複数のタスクで一つのＣＰＵを使用する場合は、実行
状態８のタスクはシステムに一つしか存在しない。よっ
て、実行可能状態７にあるタスクの中から、プライオリ
ティの最も高いタスクが実行状態に遷移する事になる。
【００１６】つまり、プライオリティの最も低い第１の
監視タスク１の実行は、実行可能状態７の他のタスクが
存在しないときのみ行われる事になる。また、第１の監
視タスク１が実行状態８にある場合においても、他のタ
スクが実行可能状態７となれば他のタスクの実行の割り
込みを受け付ける。よって、第１の監視タスクの実行は
被監視タスク３のリアルタイムの実行に対してはほとん
ど影響を与える事がない。
監視タスク１の実行は、実行可能状態７の他のタスクが
存在しないときのみ行われる事になる。また、第１の監
視タスク１が実行状態８にある場合においても、他のタ
スクが実行可能状態７となれば他のタスクの実行の割り
込みを受け付ける。よって、第１の監視タスクの実行は
被監視タスク３のリアルタイムの実行に対してはほとん
ど影響を与える事がない。
【００１７】一方、第２の監視タスク２はプライオリテ
ィが最も高くなるように設定されている。従って、第２
の監視タスク２の実行は実行可能状態７のタスクが複数
存在しても、どのタスクの実行よりも優先して行われる
事になる。よって、被監視タスク３の実行に影響を与え
る事になるので、できるだけ短い時間で行う必要があ
る。本実施形態では、第２の監視タスク２の実行内容は
第１の監視タスク１を監視するだけなので、実行時間を
短くする事ができる。
ィが最も高くなるように設定されている。従って、第２
の監視タスク２の実行は実行可能状態７のタスクが複数
存在しても、どのタスクの実行よりも優先して行われる
事になる。よって、被監視タスク３の実行に影響を与え
る事になるので、できるだけ短い時間で行う必要があ
る。本実施形態では、第２の監視タスク２の実行内容は
第１の監視タスク１を監視するだけなので、実行時間を
短くする事ができる。
【００１８】図２は、第１の監視タスク１の被監視タス
ク３を監視する監視方法を示すフローチャートである。
第１の監視タスク１は、まず始めにステップ＃１０で周
期起床設定を行う。次にステップ＃１５で最初に監視を
行う被監視タスク３xを指定する（ｘは１≦ｘ≦ｎとな
る整数）。ここでタスクは実行可能状態７となり、ステ
ップ＃２０のスリープである一定時間待って、ステップ
＃２５で実行状態８に遷移する。
ク３を監視する監視方法を示すフローチャートである。
第１の監視タスク１は、まず始めにステップ＃１０で周
期起床設定を行う。次にステップ＃１５で最初に監視を
行う被監視タスク３xを指定する（ｘは１≦ｘ≦ｎとな
る整数）。ここでタスクは実行可能状態７となり、ステ
ップ＃２０のスリープである一定時間待って、ステップ
＃２５で実行状態８に遷移する。
【００１９】ステップ＃２５では、先にステップ＃１５
で指定した被監視タスク３xの状態を取得する。これ
は、被監視タスク３xにセットされている現在の状態を
示すフラグを読み込む事によって行う。そして、ステッ
プ＃３０では取得した状態がテーブル１４にある状態か
否か判定する。テーブル１４には表１に示すように予め
各被監視タスク３の取り得る状態が登録されている。
で指定した被監視タスク３xの状態を取得する。これ
は、被監視タスク３xにセットされている現在の状態を
示すフラグを読み込む事によって行う。そして、ステッ
プ＃３０では取得した状態がテーブル１４にある状態か
否か判定する。テーブル１４には表１に示すように予め
各被監視タスク３の取り得る状態が登録されている。
【００２０】
【表１】
【００２１】ステップ＃３０では、監視を行った被監視
タスク３xの状態がテーブル１４に登録されている状態
でなければ、ステップ＃４０に進みＥＲＲに１をセット
して、ステップ＃４５で第２の監視タスク２へ監視を行
った被監視タスク３xが異常であったというメッセージ
を送る。このメッセージを受けた第２の監視タスク２は
異常である被監視タスク３xの強制終了を行う。
タスク３xの状態がテーブル１４に登録されている状態
でなければ、ステップ＃４０に進みＥＲＲに１をセット
して、ステップ＃４５で第２の監視タスク２へ監視を行
った被監視タスク３xが異常であったというメッセージ
を送る。このメッセージを受けた第２の監視タスク２は
異常である被監視タスク３xの強制終了を行う。
【００２２】監視を行った被監視タスク３xの状態がテ
ーブルに登録されている状態であれば、ステップ＃３５
でＥＲＲに０をセットして、ステップ＃４５で第２の監
視タスク２へ異常がなかったというメッセージを送る。
ーブルに登録されている状態であれば、ステップ＃３５
でＥＲＲに０をセットして、ステップ＃４５で第２の監
視タスク２へ異常がなかったというメッセージを送る。
【００２３】ステップ＃４５で第２の監視タスクへのメ
ッセージの送信が終了すると、ステップ＃５０では、先
に監視を行った被監視タスク３xがテーブル上に登録さ
れている最後の被監視タスク３か否かを判定する。最後
の被監視タスク３でなければステップ＃５５へ進み、次
に監視を行う被監視タスク３x'を指定して、ステップ＃
２０へ戻る。ステップ＃５０で最後の被監視タスク３で
あると判定されれば再びテーブル１４上に登録されてい
る被監視タスク３の監視を繰り返すので、ステップ＃１
５へ戻り最初に監視を行う被監視タスク３を指定する。
ッセージの送信が終了すると、ステップ＃５０では、先
に監視を行った被監視タスク３xがテーブル上に登録さ
れている最後の被監視タスク３か否かを判定する。最後
の被監視タスク３でなければステップ＃５５へ進み、次
に監視を行う被監視タスク３x'を指定して、ステップ＃
２０へ戻る。ステップ＃５０で最後の被監視タスク３で
あると判定されれば再びテーブル１４上に登録されてい
る被監視タスク３の監視を繰り返すので、ステップ＃１
５へ戻り最初に監視を行う被監視タスク３を指定する。
【００２４】尚、異常タスクが発見され特定された場合
は、第２の監視タスク２により異常タスクの強制終了が
なされる。しかし、異常タスクを強制終了後再起動させ
てもまだ異常であるとの情報が送られてくる場合は、第
２の監視タスク２はシステム全体のデータを保持しなが
らシステムをリセットし、システムがウォームスタート
するようにセットする。図３にリセット後のシステムの
処理内容のフローチャートを示す。
は、第２の監視タスク２により異常タスクの強制終了が
なされる。しかし、異常タスクを強制終了後再起動させ
てもまだ異常であるとの情報が送られてくる場合は、第
２の監視タスク２はシステム全体のデータを保持しなが
らシステムをリセットし、システムがウォームスタート
するようにセットする。図３にリセット後のシステムの
処理内容のフローチャートを示す。
【００２５】システムはリセット後、ステップ＃６５で
ハードウェアの初期化を行う。そして、ステップ＃７０
でウォームスタートか否かを判定し、ウォームスタート
であればステップ＃７５のメモリの初期化を行わずにス
テップ＃８０へジャンプする。尚、前述の場合は、ここ
でウォームスタートであると判断する。ステップ＃８０
では、初期タスクを起動する。以上でシステムのリセッ
ト後の処理が終了する。尚、ステップ＃７０でウォーム
スタートでないと判断された場合は、ステップ＃７５で
メモリの初期化を行ってからステップ＃８０へ進む事に
なる。
ハードウェアの初期化を行う。そして、ステップ＃７０
でウォームスタートか否かを判定し、ウォームスタート
であればステップ＃７５のメモリの初期化を行わずにス
テップ＃８０へジャンプする。尚、前述の場合は、ここ
でウォームスタートであると判断する。ステップ＃８０
では、初期タスクを起動する。以上でシステムのリセッ
ト後の処理が終了する。尚、ステップ＃７０でウォーム
スタートでないと判断された場合は、ステップ＃７５で
メモリの初期化を行ってからステップ＃８０へ進む事に
なる。
【００２６】また、本実施形態の第２の監視タスク２は
プライオリティが最上位であるために、これを監視する
タスクは用意されていない。この第２の監視タスク２の
監視はウォッチドッグタイマでハードウェア的に行う。
以下、その監視方法について説明する。
プライオリティが最上位であるために、これを監視する
タスクは用意されていない。この第２の監視タスク２の
監視はウォッチドッグタイマでハードウェア的に行う。
以下、その監視方法について説明する。
【００２７】図４は、第２の監視タスク２とウォッチド
ッグタイマ（ＷＤＴ）５の関係を示した図である。第２
の監視タスク２は動作する度に、ハードウェアとして独
立して動作するウォッチドッグタイマ５のリセットを行
う。第２の監視タスク２に異常が生じウォッチドッグタ
イマ５のリセットが行われないと、ウォッチドッグタイ
マ５は不図示のクロックをカウントし、所定時間をカウ
ントした後、システム４に対しリセットをかける。リセ
ット後、システム４は図３に示すフローチャートの処理
を行う。この場合は、ウォームスタートではないのでス
テップ＃７５のメモリの初期化は行われる事になる。
ッグタイマ（ＷＤＴ）５の関係を示した図である。第２
の監視タスク２は動作する度に、ハードウェアとして独
立して動作するウォッチドッグタイマ５のリセットを行
う。第２の監視タスク２に異常が生じウォッチドッグタ
イマ５のリセットが行われないと、ウォッチドッグタイ
マ５は不図示のクロックをカウントし、所定時間をカウ
ントした後、システム４に対しリセットをかける。リセ
ット後、システム４は図３に示すフローチャートの処理
を行う。この場合は、ウォームスタートではないのでス
テップ＃７５のメモリの初期化は行われる事になる。
【００２８】次に、本発明の第２の実施形態について説
明する。図５（ａ）は基本構成を示すブロック図であ
る。リアルタイムＯＳ６上にｎ個の被監視タスク３1〜
３nと、第１の監視タスク１と第２の監視タスク２が設
けられている。被監視タスク３のプライオリティは
３1、３2、３3、・・・、３nの順に従って低くなる。第
１の監視タスク１のプライオリティは全ての被監視タス
ク３のプライオリティより低く、第２の監視タスク２の
プライオリティは全ての被監視タスク３のプライオリテ
ィより高く設定されている。
明する。図５（ａ）は基本構成を示すブロック図であ
る。リアルタイムＯＳ６上にｎ個の被監視タスク３1〜
３nと、第１の監視タスク１と第２の監視タスク２が設
けられている。被監視タスク３のプライオリティは
３1、３2、３3、・・・、３nの順に従って低くなる。第
１の監視タスク１のプライオリティは全ての被監視タス
ク３のプライオリティより低く、第２の監視タスク２の
プライオリティは全ての被監視タスク３のプライオリテ
ィより高く設定されている。
【００２９】第１の監視タスク１は実行される毎に、つ
まりこれよりプライオリティの高い被監視タスク３の実
行が順調に進み第１の監視タスク１が実行状態に移る毎
に、イベントフラグをセットしてイベントフラグの情報
を第２の監視タスク２に送る。第２の監視タスク２は第
１の監視タスク１から送られてくるイベントフラグの情
報を一定時間毎に監視し、ある一定時間以上イベントフ
ラグがセットされないと第１の監視タスク１が実行され
ていないと判断し異常とする。
まりこれよりプライオリティの高い被監視タスク３の実
行が順調に進み第１の監視タスク１が実行状態に移る毎
に、イベントフラグをセットしてイベントフラグの情報
を第２の監視タスク２に送る。第２の監視タスク２は第
１の監視タスク１から送られてくるイベントフラグの情
報を一定時間毎に監視し、ある一定時間以上イベントフ
ラグがセットされないと第１の監視タスク１が実行され
ていないと判断し異常とする。
【００３０】第２の監視タスク２は第１の監視タスクが
異常であると判断すると、図５（ｂ）に示すように第１
の監視タスク１のプライオリティを１段階上げる。つま
り、第１の監視タスク１のプライオリティが被監視タス
ク３nと３n-1の間のプライオリティになるようにする。
異常であると判断すると、図５（ｂ）に示すように第１
の監視タスク１のプライオリティを１段階上げる。つま
り、第１の監視タスク１のプライオリティが被監視タス
ク３nと３n-1の間のプライオリティになるようにする。
【００３１】その後、第２の監視タスク２は第１の監視
タスク１からの情報を一定時間待つ。一定時間待って
も、イベントフラグがセットされたとの情報が送られて
こないと、第２の監視タスク２は図５（ｃ）に示すよう
に第１の監視タスク１のプライオリティをもう１段階上
げる。つまり、第１の監視タスク１のプライオリティが
被監視タスク３n-1と３n-2の間のプライオリティになる
ようにする。
タスク１からの情報を一定時間待つ。一定時間待って
も、イベントフラグがセットされたとの情報が送られて
こないと、第２の監視タスク２は図５（ｃ）に示すよう
に第１の監視タスク１のプライオリティをもう１段階上
げる。つまり、第１の監視タスク１のプライオリティが
被監視タスク３n-1と３n-2の間のプライオリティになる
ようにする。
【００３２】第２の監視タスク２はこのような操作を第
１の監視タスク１のイベントフラグがセットされるよう
になるまで繰り返し、異常である被監視タスク３を特定
する。ここで、例えば図５（ｃ）に示すようにセットし
たときに、第１の監視タスク１からイベントフラグがセ
ットされたとの情報が送られてくるようになったとする
と、第２の監視タスク２は被監視タスク３n-1が異常で
あったと判断する。
１の監視タスク１のイベントフラグがセットされるよう
になるまで繰り返し、異常である被監視タスク３を特定
する。ここで、例えば図５（ｃ）に示すようにセットし
たときに、第１の監視タスク１からイベントフラグがセ
ットされたとの情報が送られてくるようになったとする
と、第２の監視タスク２は被監視タスク３n-1が異常で
あったと判断する。
【００３３】これは、第１の監視タスク１のプライオリ
ティが、被監視タスク３n-1のプライオリティより高く
なってようやく第１の監視タスク１が実行されるように
なったので、異常である被監視タスク３n-1が第１の監
視タスク１の実行を妨げていたと判断するからである。
ティが、被監視タスク３n-1のプライオリティより高く
なってようやく第１の監視タスク１が実行されるように
なったので、異常である被監視タスク３n-1が第１の監
視タスク１の実行を妨げていたと判断するからである。
【００３４】そして、第２の監視タスク２は異常な被監
視タスク３を特定すると、その被監視タスク３の強制終
了を行う。その後、第１の監視タスク１を最下位つまり
図５（ａ）の状態に戻して、強制終了させた被監視タス
ク３を再起動させる。このようにしても、まだ第１の監
視タスク１からイベントフラグがセットされたとの情報
が送られてこない場合は、第２の監視タスク２はデータ
を保持しながら、システム全体をウォームスタートさせ
る。その際の処理方法は第１の実施形態と同様であるの
で説明を省略する。
視タスク３を特定すると、その被監視タスク３の強制終
了を行う。その後、第１の監視タスク１を最下位つまり
図５（ａ）の状態に戻して、強制終了させた被監視タス
ク３を再起動させる。このようにしても、まだ第１の監
視タスク１からイベントフラグがセットされたとの情報
が送られてこない場合は、第２の監視タスク２はデータ
を保持しながら、システム全体をウォームスタートさせ
る。その際の処理方法は第１の実施形態と同様であるの
で説明を省略する。
【００３５】また、第２の監視タスク２は第１の実施形
態と同様にプライオリティが最上位であるため、ウォッ
チドッグタイマ５でハードウェア的に監視がなされる。
このときの監視方法は第１の実施形態と同様であるので
説明を省略する。
態と同様にプライオリティが最上位であるため、ウォッ
チドッグタイマ５でハードウェア的に監視がなされる。
このときの監視方法は第１の実施形態と同様であるので
説明を省略する。
【００３６】
【発明の効果】本発明によると、第１の監視タスクのプ
ライオリティは全ての被監視タスクのプライオリティよ
りも低く構成される事になるので、第１の監視タスクの
実行つまりタスクの監視は、他の被監視タスクの実行に
影響を与える事がない。従って、システムのアプリケー
ション効率を維持したまま、監視内容を厳密にする事も
できる。
ライオリティは全ての被監視タスクのプライオリティよ
りも低く構成される事になるので、第１の監視タスクの
実行つまりタスクの監視は、他の被監視タスクの実行に
影響を与える事がない。従って、システムのアプリケー
ション効率を維持したまま、監視内容を厳密にする事も
できる。
【００３７】また、第１の監視タスクを監視する第２の
監視タスクも構成される事になるので、第１の監視タス
クの異常を発見する事が可能となる。また、第２の監視
タスクの実行内容は第１の監視タスクの監視を行うだけ
なので、実行時間は短くて済み、他のタスクの実行に大
きな影響を及ぼす事はない。
監視タスクも構成される事になるので、第１の監視タス
クの異常を発見する事が可能となる。また、第２の監視
タスクの実行内容は第１の監視タスクの監視を行うだけ
なので、実行時間は短くて済み、他のタスクの実行に大
きな影響を及ぼす事はない。
【００３８】また、異常のある被監視タスクが特定され
るので、システムが正常に動作するようにその後の処理
を行う事ができるようになる。
るので、システムが正常に動作するようにその後の処理
を行う事ができるようになる。
【００３９】また、この発明においては、第１の監視タ
スクが被監視タスクの状態を読み込み、この状態と被監
視タスク固有のあるべき状態とを比較するという動作を
行うだけで異常タスクの特定ができる。つまり、被監視
タスクとしては特別な動作が必要なく、システム全体も
複雑にはならない。
スクが被監視タスクの状態を読み込み、この状態と被監
視タスク固有のあるべき状態とを比較するという動作を
行うだけで異常タスクの特定ができる。つまり、被監視
タスクとしては特別な動作が必要なく、システム全体も
複雑にはならない。
【００４０】
【００４１】
【図１】第１の実施形態の基本構成を示すブロック図。
【図２】第２の監視タスクの監視方法を示したフローチ
ャート。
ャート。
【図３】リセット後のシステムの処理を示したフローチ
ャート。
ャート。
【図４】第２の監視タスクとウォッチドッグタイマの関
係を示すブロック図。
係を示すブロック図。
【図５】第２の実施形態の（ａ）基本構成を示すブロッ
ク図と（ｂ）、（ｃ）第１の監視タスクのプライオリテ
ィを上げた後のブロック図。
ク図と（ｂ）、（ｃ）第１の監視タスクのプライオリテ
ィを上げた後のブロック図。
【図６】タスクの三つの基本状態と遷移の関係を示す
図。
図。
１ 第１の監視タスク
２ 第２の監視タスク
３ 被監視タスク
４ システム
５ ウォッチドッグタイマ
６ リアルタイムＯＳ
１４ テーブル
フロントページの続き
(56)参考文献 特開 平４−245547（ＪＰ，Ａ)
特開 平２−212940（ＪＰ，Ａ)
特開 平７−219790（ＪＰ，Ａ)
特開 平５−233333（ＪＰ，Ａ)
特開 平６−4318（ＪＰ，Ａ)
(58)調査した分野(Int.Cl.7，ＤＢ名)
G06F 9/46
G06F 11/30
Claims (2)
- 【請求項１】 少なくとも一つの被監視タスクと該被監
視タスクを監視する第１の監視タスクとを有するマルチ
タスクシステムのタスク監視方法において、前記第１の
監視タスクのプライオリティを前記被監視タスクのプラ
イオリティより低くし、前記マルチタスクシステムは第
１の監視タスクの動作のみを監視する第２の監視タスク
を有し、前記第２の監視タスクのプライオリティは前記
被監視タスクのプライオリティより高くする事を特徴と
するタスク監視方法。 - 【請求項２】 前記第１の監視タスクは前記被監視タス
クの状態を監視し、各被監視タスク固有のとり得る状態
以外の状態であると判断した被監視タスクを異常と判断
する事を特徴とする請求項１に記載のタスク監視方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP29134396A JP3524700B2 (ja) | 1996-11-01 | 1996-11-01 | タスク監視方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP29134396A JP3524700B2 (ja) | 1996-11-01 | 1996-11-01 | タスク監視方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10133887A JPH10133887A (ja) | 1998-05-22 |
| JP3524700B2 true JP3524700B2 (ja) | 2004-05-10 |
Family
ID=17767701
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP29134396A Expired - Fee Related JP3524700B2 (ja) | 1996-11-01 | 1996-11-01 | タスク監視方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3524700B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4609381B2 (ja) * | 2006-06-14 | 2011-01-12 | 株式会社デンソー | 異常監視用プログラム、記録媒体及び電子装置 |
| JP5335552B2 (ja) * | 2009-05-14 | 2013-11-06 | キヤノン株式会社 | 情報処理装置、その制御方法、及びコンピュータプログラム |
| JP5418066B2 (ja) * | 2009-08-25 | 2014-02-19 | 富士通モバイルコミュニケーションズ株式会社 | 情報処理装置 |
-
1996
- 1996-11-01 JP JP29134396A patent/JP3524700B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10133887A (ja) | 1998-05-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7137117B2 (en) | Dynamically variable idle time thread scheduling | |
| US7849463B2 (en) | Dynamically variable idle time thread scheduling | |
| US5748959A (en) | Method of conducting asynchronous distributed collective operations | |
| US20050039181A1 (en) | Processor system, task control method on computer system, computer program | |
| US20030233485A1 (en) | Event queue | |
| US7043729B2 (en) | Reducing interrupt latency while polling | |
| JP2001154885A (ja) | コンピュータシステムのロックアップ防止方法及びコンピュータシステムをモニターする方法 | |
| US7231468B2 (en) | Future activity list for peripheral bus host controller | |
| WO2000073895A1 (en) | Method and device for monitoring the creation and destruction of child processes within an application executing in a computer system | |
| US6795873B1 (en) | Method and apparatus for a scheduling driver to implement a protocol utilizing time estimates for use with a device that does not generate interrupts | |
| JP2001160041A (ja) | オンラインシステムのｃｐｕ負荷軽減方式 | |
| JP3524700B2 (ja) | タスク監視方法 | |
| JPH02300939A (ja) | セマフォオペレーション方式 | |
| CN111352803A (zh) | 业务数据处理方法、装置、设备和存储介质 | |
| WO2000028418A1 (en) | Scheduling resource requests in a computer system | |
| JP2001236236A (ja) | タスク制御装置およびそのタスクスケジューリング方法 | |
| EP1503270A2 (en) | Apparatus and method for controlling CPU speed transition | |
| JP2004213122A (ja) | クライアント／サーバによる制御システムの安定稼働方法及びそのプログラム | |
| CN111796949A (zh) | 通讯任务处理方法、装置、设备及存储介质 | |
| JP3494788B2 (ja) | プログラム実行管理システム及びプログラム実行管理方法 | |
| US20080141267A1 (en) | Cooperative scheduling of multiple partitions in a single time window | |
| JP2005182594A (ja) | コンピュータ及びプログラム | |
| JPH09305414A (ja) | プロセス管理方法 | |
| CN113656468A (zh) | 基于nifi的任务流程触发方法及装置 | |
| CN114237954A (zh) | 非对称多核amp分时循环工作方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20031218 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040210 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040213 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080220 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090220 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100220 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |