(57)【要約】【課題】デッドロック状態の検出、デッドロック発生タスクの特定が可能なソフトウエアのデッドロック検出方式を提供する。【解決手段】複数のタスク１，２，・・・Ｎに対応した複数のタスク管理エリアが割り付けられ、これにイベント処理状態の管理情報が設定されるメモリエリアが設けられている第１の管理情報（４）と、複数のタスクに対応した複数のタスク管理エリアが割り付けられ、イベント待ち状態のタイムアウトの管理情報が設定されるメモリエリアが設けられている第２の管理情報（７）と、第１、第２の管理情報の各タスク管理エリアに設定・記憶された内容をチェックすることによりソフトウエア動作のデッドロックの有無および当該タスクを特定する検出が行われるデッドロック検出タスク（５）と、デッドロック検出情報をメモリに記憶する不揮発メモリ（８）と、を備えた。【選択図】図１
2008217566.tif 000002
【特許請求の範囲】
【請求項１】
メッセージイベント型をした複数のタスクと、対応する該タスクにイベント発生の起動を仕掛ける複数のタスク用メッセージキューとが備わり、リアルタイムＯＳ上で動作させるソフトウエアのデッドロック検出方式であって、
前記複数のタスクに対応するように複数のタスク管理エリアがメモリエリアとして割り付けられ、該複数の管理エリアに前記複数のタスクから得られるイベント処理状態の管理情報が設定される第１の管理情報と、
前記第１の管理情報とは別に、前記複数のタスクに対応するように複数のタスク管理エリアがメモリエリアとして割り付けられ、該複数の管理エリアに前記複数のタスクから得られるイベント待ち状態のタイムアウトの管理情報が設定される第２の管理情報と、
前記第１の管理情報および第２の管理情報の各タスク管理エリアに設定・記憶された
内容をチェックすることにより前記ソフトウエア動作のデッドロックの有無および該当タスクを特定する検出が行われるデッドロック検出タスクと、
前記デッドロック検出タスクから得られた情報を記憶する不揮発メモリと、
を備えたソフトウエアのデッドロック検出方式。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リアルタイムＯＳ（オペレーティングシステム・システム）上での動作に供して好適なソフトウエアのデッドロック検出方式に関する。
【背景技術】
【０００２】
リアルタイムＯＳ（real-time operating system；処理を実時間で実行することを重視し、そのための機能、例えば、複数の処理要求が同時に発生した場合でも必要な時間内に完了させるための機構が実装されたOSのこと。）上で動作するアプリケーションソフトウエア（以下、ソフトウエアと云う。）は多くのプログラムの集合で構成され、更に、それぞれのプログラムは、最小単位とするタスクの集合で構成されている。
【０００３】
それぞれのプログラムを構成するタスクは、データ受け渡し用のキュー（以下、メッセージキューと記述）を持っており、タスク間においてメッセージキューを使用したデータの受け渡しを行うことにより、多くのプログラム動作の制御が行われている。
【０００４】
このような制御方法により各タスクでは、メッセージキューへのキューイング（以下、イベントと記述）の発生を常時監視し、イベント発生を契機としてリアルタイムＯＳにより優先度の高いタスクからＣＰＵ処理時間が割当てられ、イベントに対応した処理を実行後、再びイベント待ちとなるのが一般的なタスク制御構造である。
【０００５】
図３にタスク制御構造の概念を示す。このような制御構造を持つタスクをメッセージイベント型タスクと称する。タスク（１００）は、イベント待ちとイベントに対応した処理を実行するループで構成され、タスク用メッセージキュー（２００）からタスク（１００）に対してイベント発生の起動が仕掛けられて、イベント待ちからイベントに対応した処理の実行に遷移し、処理が完了すれば、イベント待ちに戻る動作が行われる。
【０００６】
このような制御構造を踏まえ、デッドロックが発生する状況の例について以下に説明する。
【０００７】
図４に、前記のタスク制御構造を３つ有する従来のソフトウエア構成例を示し、デッドロックが発生する状況を説明する。
タスクＡ（１０１）、タスクＢ（１０２）、タスクＣ（１０３）は、それぞれメッセージイベント型タスクとし、タスク優先度は、タスクＢが最も優先度が高く、次にタスクＣ、最も優先度が低いタスクをタスクＡとする。
【０００８】
先ず、タスクＣ（１０３）の動作として、タスクＣ（１０３）からタスクＡメッセージキュー（以下、キューＡと記載）（２０１）に対してイベントＣ（１）、イベントＣ（２）、イベントＣ（３）の送信が順次行われる。なお、キューＡ（２０１）のキューイング（イベント発生）可能数は「２」としている。このため、タスクＣ（１０３）はイベントＣ（３）の送信の時点では、キューＡ（２０１）が空くまで待ち状態となる。
【０００９】
次に、タスクＡ（１０１）の動作として、タスクＣ（１０３）が待ち状態となったため、タスクＡ（１０１）はキューＡ（２０１）からイベントＣ（１）を取得する。
【００１０】
次に、タスクＣ（１０３）の動作として、タスクＡ（１０１）がイベントＣ（１）を取得したためキューＡ（２０１）のキュー格納エリアが1つ空き、タスクＣ（１０３）の待ち状態が解除され、キューＡ（２０１）へのイベントＣ（３）の送信が完了する。この時点でキューＡ（２０１）はキュー格納エリアがＦｕｌｌ状態となる。
【００１１】
次に、タスクＡ（１０１）の動作として、タスクＣの送信処理完了により、再びタスクＡ（１０１）が動作し、タスクＣ（１０３）から取得したイベントＣ（１）の対応処理を実行する。そこで、タスクＡ（１０１）は、その対応処理において、タスクＢメッセージキュー（以下、キューＢと記載）（２０２）へ、イベントＡ（１）、イベントＡ（２）、イベントＡ（３）、イベントＡ（４）の送信が順次行われる。
タスクＢ（１０２）は、タスクＡ（１０１）より優先度が高いため、タスクＡ（１０１）がイベントＡ（１）を送信した時点でタスクＢ（１０２）へ処理の実行が切り替わる。
【００１２】
次に、タスクＢ（１０２）の動作として、キューＢ（２０２）よりイベントＡ（１）を取得し、対応処理としてキューＡ（２０１）に対しイベントＢ（１）の送信が行われる。
ここで、キューＡ（２０１）は、先の時点でキュー格納エリアがＦｕｌｌ状態となっているため、タスクＢ（１０２）がキューＡ（２０１）の空き待ち状態となる。
【００１３】
ふたたび、タスクＡ（１０１）の動作として、タスクＢ（１０２）が待ち状態となったため、再度タスクＡ（１０１）が動作し、キューＢ（２０２）へのイベントＡ（２）、イベントＡ（３）の送信が完了する。ここで、キューＢ（２０２）のキューイング（イベント発生）可能数は「２」である。このため、タスクＡ（１０１）はイベントＡ（４）送信の時点で、キューＢ（２０２）が空くまで待ち状態となる。
【００１４】
このような動作状態の段階の時点で、タスクＢ（１０２）の対応処理の実行は、キューＡ（２０１）の空き待ち状態となる。ところが、タスクＡ（１０１）はキューＢ（２０２）の空き待ち状態となっており、タスクＡ（１０１）がキューＡ（２０１）からのイベントを取得できないため、タスクＢ（１０２）の待ち状態は依然解除されない。
【００１５】
同様に、タスクＡ（１０１）はキューＢ（２０２）の空き待ち状態となるが、タスクＢがキューＡ（２０１）の空き待ち状態となっており、タスクＢ（１０２）がキューＢ（２０２）からのイベントを取得できないため、タスクＡ（１０１）の待ち状態は依然解除されない。
【００１６】
この状態において、タスクＡ（１０１）、タスクＢ（１０２）共にメッセージキューからのイベントを取得できないため、ソフトウエアは正常に動作できない（デッドロック）が、タスクＡ（１０１）、タスクＢ（１０２）は共にリアルタイムＯＳ上では正常な“待ち状態”として管理されている。従って、リアルタイムＯＳ上では、異常とは検出されず、従って、このＯＳ上で動作するソフトウエアのタスク実行処理上も、デッドロックが検出されていないという問題点がある。
【００１７】
従来、デッドロックの検出方式としては、資源を占有している全プロセスを記録するテーブルを設け、このテーブルに記録されている全プロセスについてデッドロック判定を行う提案がなされている。（例えば、特許文献１  参照）
【特許文献１】特開平７−３３４３７９号公報（図１）
【発明の開示】
【発明が解決しようとする課題】
【００１８】
リアルタイムＯＳ上で動作するソフトウエアのメッセージイベント型を有する複数のタスクの実行処理上において、デッドロックが検出されていないという問題点があった。このためソフトウエア開発段階およびシステム設置後のメンテナンス段階での障害対処の効率が悪かった。
【００１９】
本発明の目的は、上記従来技術の問題点を解決し、デッドロック状態の検出、デッドロック発生タスクの特定が可能なソフトウエアのデッドロック検出方式を提供することにある。
【課題を解決するための手段】
【００２０】
この目的を達成するために、本発明のソフトウエアのデッドロック検出方式は、メッセージイベント型をした複数のタスクと、対応する該タスクにイベント発生の起動を仕掛ける複数のタスク用メッセージキューとが備わり、リアルタイムＯＳ上で動作させるソフトウエアのデッドロック検出方式であって、
【００２１】
前記複数のタスクに対応するように複数のタスク管理エリアがメモリエリアとして割り付けられ、該複数の管理エリアに前記複数のタスクから得られるイベント処理状態の管理情報が設定される第１の管理情報と、
【００２２】
前記第１の管理情報とは別に、前記複数のタスクに対応するように複数のタスク管理エリアがメモリエリアとして割り付けられ、該複数の管理エリアに前記複数のタスクから得られるイベント待ち状態のタイムアウトの管理情報が設定される第２の管理情報と、
【００２３】
前記第１の管理情報および第２の管理情報の各タスク管理エリアに設定・記憶された
内容をチェックすることにより前記ソフトウエア動作のデッドロックの有無および該当タスクを特定する検出が行われるデッドロック検出タスクと、
【００２４】
前記デッドロック検出タスクから得られた情報を記憶する不揮発メモリと、
を備えた。
【発明の効果】
【００２５】
本発明によれば、これまで検出困難であったリアルタイムＯＳ上で動作するソフトウエアのデッドロック状態の検出、デッドロック状態に陥ったタスクを特定でき、デッドロック状態に陥った対処について、ソフトウエア開発段階およびシステム設置後のメンテナンス段階でのリアルタイム障害検出及びその後の迅速な障害解析が可能となり障害対処の効率向上となる。
【発明を実施するための最良の形態】
【００２６】
図１に、本発明であるソフトウエアのデッドロック検出方式のソフトウエア構成図を示し実施の形態として以下に説明する。
【００２７】
タスク１（１）、タスク２（２）、・・・タスクＮ（３）は、それぞれがメッセージイベント型のタスクである。タスク１（１）、タスク２（２）、・・・タスクＮ（３）それぞれのタスクは、「タイムアウト付きのイベント待ち」、「管理情報設定」、「対応処理実行」および「管理情報設定」の順にタスク動作が進み、「イベント待ち」に戻るループ動作としている。各タスクには、これに対応してタスク用メッセージキューが備えられている。例えば、タスク１（１）に対してタスク用メッセージキュー（９）が、およびタスク２（２）に対してタスク用メッセージキュー（１０）が備えられている。あるタスクに対応するタスク用メッセージキューは、他のタスクからのイベントを受け付けて、対応するタスクにイベント発生の起動を仕掛けるように動作する。
【００２８】
管理情報１（４）は、各タスクに対応した管理エリアとして、「タスク１管理エリア」、「タスク２管理エリア」、・・・「タスクＮ管理エリア」が割り付けられ、各タスクがイベント処理中であるか、イベント処理終了かのそれぞれのタスクからの管理情報設定の指示を受けて、対応するタスク管理エリアにイベント状態設定として記憶するメモリエリアである。
【００２９】
ＯＳイベント待ち情報（６）は、各タスクに対応した情報の記憶エリアとして、タスク１情報、タスク２情報、・・・タスクＮ情報が割り付けられ、各タスクのメッセージおよびイベントフラグのＯＳイベント待ち情報を受けて、対応するタスク情報のエリアに状態設定を記憶する、各タスクと管理情報２（７）との間に位置するメモリエリアである。
【００３０】
管理情報２（７）は、各タスクに対応した管理エリアとして、タスク１管理エリア、タスク２管理エリア、・・・タスクＮ管理エリアが割り付けられ、ＯＳイベント待ち情報（６）から得られた各タスクのイベント待ちのタイムアウト情報を受けて、対応するタスク管理エリアにタイムアウトの状態設定として記憶するメモリエリアである。
【００３１】
デッドロック検出タスク（５）は、タスク遅延およびチェックの動作ループで構成され、管理情報１（４）および管理情報２（７）の各タスク管理エリアの内容をチェックする機能を有するタスクである。このタスクでのチェック結果、デッドロック検出であると認識されれば、その管理情報を不揮発メモリ（８）へ送信し、不揮発メモリ（８）にてデッドロック検出情報が記憶される。
【００３２】
次にデッドロック検出タスク（５）の動作仕様について説明する。
【００３３】
ソフトウエア動作のデッドロック状態を監視するための遅延型タスクであるデッドロック検出タスク（５）を設けている。遅延型タスクとは、リアルタイムＯＳの中の機能として有する「タスク遅延」を用い、指定の時間だけ、タスクを待ち状態へ遷移させ、指定時間の経過後に待ち状態が解除されるタスクのことである。但し、指定時間経過後、自タスクより高優先度のタスクが動作中であった場合、高優先度タスクの動作が完了後に、このタスクに対してＣＰＵ動作処理のための時間が割当てられる。尚、デッドロック検出タスク（５）は全タスク中、最も優先度の低いタスクとしておく。前記「タスク遅延」は、デッドロック検出の誤検出を回避する為であり、他のタスク（例えば、タスク１〜Ｎ）で使用しているタスク遅延時間に比較して長いタスク遅延時間を設定させておく。この遅延時間は、それぞれのシステムに対応させた適切な値であればよい。
【００３４】
次にデッドロック状態を検出するための管理情報１（４）および管理情報２（７）の仕様について説明する。
【００３５】
第１の管理手段は、メッセージイベント型タスクであるタスク１（１）〜タスクＮ（３）が、それぞれイベント処理中であるか、イベント処理終了であるかの状態を管理することである。この状態の管理を担う管理情報１（４）は、予めタスク１（１）〜タスクＮ（３）のそれぞれに対応するように「タスク１管理エリア」〜「タスクＮ管理エリア」を割当てておき、各タスク管理エリアの初期値は、「イベント処理終了」に設定される。
【００３６】
第２の管理手段は、メッセージイベント型タスクであるタスク１（１）〜タスクＮ（３）の各タスクで情報転送に使用するタイムアウト付きメッセージ、イベントフラグの待ち状態を管理することである。この状態の管理を担う管理情報２（７）は、予めタスク１（１）〜タスクＮ（３）のそれぞれに対応するように、前記第１の管理エリアとは異なるエリアとして「タスク１管理エリア」〜「タスクＮ管理エリア」を割当てておき、各タスクのメッセージ、イベントフラグのタイムアウト情報として、その情報が各管理エリアに蓄積される。
【００３７】
なお、登録されているタスク１（１）〜タスクＮ（３）の全てのタスクは、「タイムアウト付き」である。
【００３８】
このように、管理情報２（７）のタスク1管理エリアには、タスク1（１）のＯＳイベント待ち情報の内容として、タスク1（１）のメッセージ、イベントフラグの各タイムアウト情報であるタスク1情報が入り、更に、タスク２管理エリアには、タスク２（２）のＯＳイベント待ち情報の内容として、タスク２（２）のメッセージ、イベントフラグの各タイムアウト情報であるタスク２情報が入り、同様に、タスクＮ管理エリアには、タスクＮ（３）のＯＳイベント待ち情報の内容として、タスクＮ（３）のメッセージ、イベントフラグの各タイムアウト情報であるタスクＮ情報は入るように構成されている。
【００３９】
そこで、デッドロック検出タスク（５）がこれらのタスク管理エリアをチェックすれば、漏れなく、すべてのタイムアウト情報をチェックすることになる。
【００４０】
上記の第１の管理手段、および第２の管理手段の構成を踏まえ、デッドロック検出方式について説明する。
【００４１】
先ず、管理情報１（４）の動作の実施例として、メッセージイベント型タスクであるタスク１（１）は、タスク用メッセージキュー（９）からのイベント発生時に管理情報１（４）の対応するタスクに割当てられたタスク管理エリア（ここでは、タスク１管理エリア）に「イベント処理中」を設定し、イベント対応処理の実行が完了後、「イベント処理終了」に設定される。
【００４２】
同様にタスク２（２）〜タスクＮ（３）の全てのタスクについて、タスク用メッセージキュー（９）からのイベント発生時に管理情報１（４）の対応するタスクに割当てられたタスク管理エリアに「イベント処理中」を設定し、イベント対応処理の実行が完了後、「イベント処理終了」に設定される。
【００４３】
管理情報１（４）のタスク１管理エリア〜タスクＮ管理エリアの記憶内容により、タスク１（１）〜タスクＮ（３）のそれぞれがイベント対応処理の実行を正常に終了し、再びイベント待ち状態へ遷移した場合、管理情報１（４）のタスク管理エリアは全て「イベント処理終了」に設定されることとなる。
【００４４】
次に、管理情報２（７）の動作の実施例として、メッセージイベント型タスクであるタスク２（２）は、タスク用メッセージキュー（１０）からのイベント発生後のイベント対応処理の実行を正常に終了し、再びイベント待ち状態へ遷移し、かつ、タイムアウトが起きた場合、管理情報２（７）の対応するタスクに割当てられたタスク管理エリア（例えば、タスク１管理エリア）に「タイムアウト情報」が設定される。
【００４５】
同様にタスク２（２）〜タスクＮ（３）の全てのタスクについて、タスク用メッセージキュー（１０）からのイベント発生後のイベント対応処理の実行を正常に終了し、再びイベント待ち状態へ遷移し、かつ、タイムアウトが起きた場合、管理情報２（７）の対応するタスクに割当てられたタスク管理エリアに「タイムアウト情報」が設定される。
【００４６】
なお、タスク１（１）〜タスクＮ（３）のイベント対応処理の実行が正常に終了し、再びイベント待ち状態へ遷移し、かつ、タイムアウトが起きたという状態は、ＯＳイベント待ち情報（６）に備えたタスク１情報〜タスクＮ情報の各タスクエリアに、メッセージおよびイベントフラグのＯＳイベント待ち情報として記憶される。引き続き管理情報２（７）は、ＯＳイベント待ち情報（６）の各タスク情報からタイムアウト情報を得る。
【００４７】
デッドロック検出タスク（５）は、処理実行の優先度が最低レベルに設定されたタスクであるため、メッセージイベント型のタスク１（１）〜タスクＮ（３）が全て待ち状態となった時点で検出動作を開始する。即ち、管理情報１（４）のタスク１〜Ｎ管理エリアの設定が、全て、イベント処理終了であり、タスク１〜Ｎは、全てイベント待ちの状態となってから、その後、デッドロック検出タスク（５）のチェック動作が開始される。
【００４８】
デッドロック検出タスク（５）の検出動作は、管理情報１（４）および管理情報２（７）のそれぞれタスク１〜Ｎの各管理エリアの記憶内容のチェックによって行なわれる。
【００４９】
第１のデッドロック判定は、管理情報１（４）のタスク１管理エリア〜タスクＮ管理エリアにおいて、“イベント処理終了”になっていない、即ち、イベント処理中として設定されたままとされているタスク管理エリアを検出した場合である。この、第１のデッドロック判定時においては、タスク（例えば、タスク１（１））が次の対応処理として実行中であり、「イベント待ち」ではない状態に進んでも、管理情報１のタスク１管理エリアが前のイベント処理中の設定状態を保っているので、デッドロック監視タスク（５）は動作を開始して、チェック動作に入ることができる。
【００５０】
第２のデッドロック判定は、管理情報２（７）のタスク１管理エリア〜タスクＮ管理エリアにおいて、“タイムアウト”になっているタスク管理エリアを検出した場合である。
【００５１】
即ち、タスク１管理エリア〜タスクＮ管理エリアに設定された各設定状態（イベント待ちのタイムアウト情報）が、デッドロック検出タスク（５）の動作開始によってチェックされる。
【００５２】
そこで、第２のデッドロック判定がどのような時にデッドロックと判定するかについて更に説明する。
【００５３】
デッドロック検出タスク（５）のチェック時、タスク１（１）〜タスクＮ（３）が正常に動作している状態、即ち、デッドロックを起こしてはいない状態であれば、メッセージがタイムアウト状態になることはなく、かつ、イベントフラグもタイムアウト状態になることはなく、この２つの状態が両方成立する場合である。
【００５４】
一方、タスク１（１）〜タスクＮ（３）が正常に動作していない状態、即ち、デッドロックを起こしている状態であれば、タスク１（１）〜タスクＮ（３）が、前記説明したようなキューによるイベントを取得できないため、ソフトウエアが正常に動作を進めない状態のようなタスク動作の異常時(デッドロック)であり、「メッセージがタイムアウトである」、「イベントフラグがタイムアウトである」、この２つのどちらかが成立することである。
【００５５】
上記、第１のデッドロック判定または第２のデッドロック判定のどちらかが検出されていれば、デッドロック状態と判定する。
即ち、管理情報1（１）の第１のデッドロック判定、管理情報２（７）の第２のデッドロック判定であるメッセージタイムアウト、および、管理情報２（７）の第２のデッドロック判定であるイベントフラグタイムアウトの３つの状態より、いずれか一つが成り立てばデッドロックであると認識される。
【００５６】
なお、デッドロック検出タスク（５）のチェック処理が動作に入る時とは、タスク１〜Ｎのそれぞれの動作状態が、イベント処理終了であり、かつ、タイムアウトでない状態である。また、タスク単独での異常でもデッドロック検出は可能である。
【００５７】
このように、本発明で対象とするデッドロックは、リアルタイムＯＳ上は正常な“待ち状態”であるのに、あるアプリケーションソフトのタスクの動作が固まったようになり、プログラム動作ができなくなる状態のことである。
【００５８】
よって、本発明のように、上記３つの状態の情報をチェックすることによって、デッドロックを確実に検出できるようにした。
【００５９】
次に、デッドロック検出タスク（５）によって判定された管理情報１（４）および管理情報２（７）のタスク管理エリアの管理情報を不揮発メモリ（８）へ記憶・保存させる。
【００６０】
不揮発メモリ（８）の記憶エリアに保存された管理情報を参照することにより、デッドロックの発生有無およびデッドロック発生したタスクを特定して認識することが可能である。
【００６１】
このように、デッドロック検出時には、不揮発メモリ（８）の記憶エリアに、障害情報として、例えば、年月日時分秒、タスクＩＤおよび上記３つの状態の情報などが記憶・保存される。
【００６２】
従って、製品開発のデバッグ時あるいは、製品設置後の運用解析時等で不揮発メモリ（８）のメモリエリアに記憶された障害情報を障害ログ情報(障害ログファイル)として、図示されてはいないが、障害ログ解析のためのツール（ＰＣ等）にて取得し、このデータ内容を参照し、障害回避対策に寄与させることができる。
【００６３】
以上、本発明は、第１および第２のデッドロック判定より得られた両方の結果をみての検出であり、このような二重の判定手段を用いているので、デッドロック発生有無を極めて高い認識精度で検出できる。
【００６４】
本発明であるソフトウエアのデッドロック検出方式における処理の流れの実施例としてフローチャートを図２に示し、以下に説明する。
【００６５】
タスク１〜Ｎのそれぞれは、イベント発生に従い、他のタスクよりイベントを取り込むイベント受信（Ｓ１）が行われ、そのイベントの管理情報設定のため、管理情報１の各タスクに対応した所定のタスク管理エリアに対して管理情報１の更新設定として管理情報１更新（Ｓ２）が行われる。
【００６６】
次に、取り込んだタスクに対し対応処理の実行が行われるイベント処理中（Ｓ３）へ進み、イベント処理終了となれば、管理情報１の更なる更新設定として管理情報１更新（Ｓ４）が行われる。
【００６７】
次に、管理情報２の所定のタスク管理エリアにタイムアウト情報を設定する管理情報２更新（Ｓ５）へ進み、その後イベント待ち（Ｓ６）となり、イベント受信（Ｓ１）へ戻るループ処理である。
【００６８】
デッドロック検出タスクは、タスク１〜Ｎが全てイベント待ち、即ち、タスク処理非動作となったときに開始される。
【００６９】
既に、タスク遅延動作が開始されているので、これが終了すればタスク遅延完了（イベント受信）（Ｓ７）となり、タスク１〜Ｎが全てのイベント処理中／処理終了の情報およびメッセージ、イベントフラグのタイムアウト情報を得る全タスク管理情報１，２（グローバル領域）取得（Ｓ８）へ進む。
【００７０】
全タスク管理情報１，２（グローバル領域）取得の結果、デッドロックの判定処理であるイベント処理中又は、タイムアウト有りの判定（Ｓ９）処理が行われる。
タイムアウト有りの判定（Ｓ９）がＮ（ＮＯ；イベント処理中又はタイムアウトいずれでもない）であれば、タスク１〜Ｎの相互動作は正常であるとし、タスク遅延開始（Ｓ１０）の繰り返しモードとなる。
【００７１】
一方、タイムアウト有りの判定（Ｓ９）がＹ（ＹＥＳ；イベント処理中又はタイムアウトいずれかが発生）であれば、タスク１〜Ｎの相互動作にデッドロック状態と認識され、管理情報を不揮発メモリに記憶させるログ書き込み（Ｓ１１）が行われる。
書き込みが完了すれば、タスク遅延開始（Ｓ１０）に戻される。
【００７２】
なお、書き込まれたログ内容の表示などの処理は別に行われる。
【産業上の利用可能性】
【００７３】
本発明の活用例として、ソフトウエア組み込みシステムのソフトウエア開発段階およびシステム設置後のメンテナンス段階の用途などに適用できる。
【図面の簡単な説明】
【００７４】
【図１】本発明のソフトウエアのデッドロック検出方式におけるソフトウエア構成図である。
【図２】本発明のソフトウエアのデッドロック検出方式における処理の流れを示すフローチャート図である。
【図３】メッセージイベント型タスク制御構造の概念図である。
【図４】デッドロック発生の状況を説明する従来のソフトウエア構成図である。
【符号の説明】
【００７５】
１  タスク１
２  タスク２
３  タスクＮ
４  管理情報１
５  デッドロック検出タスク
６  ＯＳイベント待ち情報
７  管理情報２
８  不揮発メモリ
９、１０、２００  タスク用メッセージキュー
１００  タスク
１０１  タスクＡ
１０２  タスクＢ
１０３  タスクＣ
２０１  タスクＡメッセージキュー
２０２  タスクＢメッセージキュー
【図１】
2008217566.tif 000003
【図２】
2008217566.tif 000004
【図３】
2008217566.tif 000005
【図４】
2008217566.tif 000006