(57)【要約】【課題】マルチスレッドシステムにおいて、アプリケーションのソースコードに依存することなく、スレッド内で発生する無限ループを検知することができる新しい枠組みを提供する。【解決手段】マルチスレッドシステムにおけるスレッド動作異常検知方法であって、実行対象スレッドに関して連続して実行される命令の数を計数する計数工程と、前記計数した命令数が予め定めた閾値を超えた場合に、実行対象スレッドに動作異常が生じていると判断する工程と、動作異常が生じていると判断したスレッドの動作が停止するように制御する停止制御工程とを備える。【選択図】図４
2008204013.tif 000002
【特許請求の範囲】
【請求項１】
マルチスレッドシステムにおけるスレッド動作異常検知方法であって、
実行対象スレッドに関して連続して実行される命令の数を計数する計数工程と、
前記計数した命令数が予め定めた閾値を超えた場合に、実行対象スレッドに動作異常が生じていると判断する工程と、
動作異常が生じていると判断したスレッドの動作を停止する停止制御工程とを備えることを特徴とするスレッド動作異常検知方法。
【請求項２】
動作異常が生じていると判断したスレッドを特定する情報を含むデバッグ情報を出力する工程を備えることを特徴とする請求項１記載のスレッド動作異常検知方法。
【請求項３】
前記各工程を、マルチスレッドシステムを構築する仮想マシンが実行することを特徴とする請求項１又は２記載のスレッド動作異常検知方法。
【請求項４】
前記計数工程は、
実行される命令の数を計数する工程と、
スレッド切換の発生を検知する工程と、
スレッド切換の発生を検知した場合、前記計数した命令数を０にリセットする工程とを備えることを特徴とする請求項１乃至３のいずれか１項に記載のスレッド動作異常検知方法。
【請求項５】
前記計数工程は、
実行される命令の数を計数する工程と、
実行される命令がスレッド切替を発生させる命令であるか否かを判断する工程と、
スレッド切替を発生させる命令であると判断した場合、前記計数した命令数を０にリセットする工程とを備えることを特徴とする請求項１乃至３のいずれか１項に記載のスレッド動作異常検知方法。
【請求項６】
実行対象スレッドに関して連続して実行される命令の数を計数する計数手段と、
前記計数した命令数が予め定めた閾値を越えた場合に、実行対象スレッドに動作異常が生じていると判断する手段と、
動作異常が生じていると判断したスレッドの動作を停止する手段とを備えることを特徴とするマルチスレッドシステム。
【請求項７】
請求項１乃至５のいずれか１項に記載のスレッド動作異常検知方法をコンピュータで実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチスレッドシステムにおけるスレッド動作異常検知技術に関する。
【背景技術】
【０００２】
従来より、様々な情報処理システムにおいて、スレッド又はタスク（以下、まとめて「スレッド」という）を複数生成し、各スレッドに設定されている優先度に基づいてスレッドを切り替えながら実行することが可能なマルチスレッドシステムが採用されている。
【０００３】
このようなマルチスレッドシステムにおいて個々のスレッドの無限ループ等の動作異常を検知する方法として、ＷＤＴ（ウォッチドッグタイマ）を用いる方法が知られている。
【０００４】
例えば、特許文献１に記載されるシステムは、各スレッドがＷＤＴに生存通知を行う一方で、ＷＤＴが周期的に各スレッドに対応するカウンタを更新する構成を採用する。そして、ＷＤＴは、生存通知があったスレッドについては正常動作していると判断し、該スレッドに対応するカウンタをリセットする一方、一定時間にわたって生存通知がないスレッド、すなわちカウンタ値が一定以上となったスレッドについては動作異常と判断する。
【特許文献１】特開平５−３４６８７７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上記のように各スレッドがＷＤＴに生存通知を行うことで動作異常の有無を判断する場合、次のような問題がある。
【０００６】
すなわち、スレッドからＷＤＴへの生存通知は、スレッド内の生存通知命令が実行されることにより行われる。そのため、該バイトコードにおいて生存通知命令の実行を含むような無限ループが発生した場合、ループする都度、生存通知が行われて該スレッドに対応するカウンタがリセットされることになるので、ＷＤＴは無限ループの発生を検知することができない。
【０００７】
更に、アプリケーションのソースコードのどこに生存通知命令に対応するコードを埋め込むかによって、対応するスレッド内の生存通知命令の位置が定まるため、検知できない無限ループの存否、ひいてはスレッド動作異常の検知精度が、アプリケーションのソースコードに大きく依存してしまうという問題もある。
【０００８】
また、従来のＷＤＴを用いたスレッド動作異常検知方法では、正常に動作しないスレッドの検知は可能であるが、その原因となる無限ループなどのスレッド動作異常を起こすスレッドを特定することは難しかった。
【０００９】
そこで、本発明は、アプリケーションのソースコードに依存することなく、スレッド内で発生する無限ループを検知することができる新しい枠組みを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明のスレッド動作異常検知方法は、マルチスレッドシステムにおけるスレッド動作異常検知方法であって、実行対象スレッドに関して連続して実行される命令の数を計数する計数工程と、前記計数した命令数が予め定めた閾値を超えた場合に、実行対象スレッドに動作異常が生じていると判断する工程と、動作異常が生じていると判断したスレッドの動作を停止する停止制御工程とを備えることを特徴とする。
【００１１】
かかる構成によれば、スレッドからの生存通知を利用せずにスレッドの動作異常を検知できるため、従来のように生存通知命令を含む無限ループが検知できないといった問題は生じない。
好適には、動作異常が生じていると判断したスレッドを特定する情報を含むデバッグ情報を出力する工程を備える。かかる構成によれば、デバッグ情報に基づき、動作異常が生じているスレッドを特定してアプリケーションの修正作業を行うことができる。
【００１２】
また好適には、前記各工程を、マルチスレッドシステムを構築する仮想マシンが実行する。かかる構成によれば、マルチシステムシステムを構築する仮想マシンによってスレッドの動作異常を検知できるため、スレッドに対応するバイトコード、従って、アプリケーションのソースコードに依存することなく、スレッド内の無限ループを安定して検知することが可能となる。
【００１３】
また好適には、前記計数工程は、実行される命令の数を計数する工程と、スレッド切換の発生を検知する工程と、スレッド切換の発生を検知した場合、前記計数した命令数を０にリセットする工程とを備える。
【００１４】
かかる構成によれば、命令の連続実行が途切れるタイミングを、前記計数工程へ通知できるため、前記スレッド動作異常検知方法を適切に実現できる。
【００１５】
また好適には、前記計数工程は、実行される命令の数を計数する工程と、実行される命令がスレッド切替を発生させる命令であるか否かを判断する工程と、スレッド切替を発生させる命令であると判断した場合、前記計数した命令数を０にリセットする工程とを備える。
【００１６】
かかる構成によれば、時分割制御によってスレッド切換が発生した場合には命令数がリセットされないため、時分割制御によるマルチスレッド実行環境においても適用することができる。
【００１７】
本発明のマルチスレッドシステムは、実行対象スレッドに関して連続して実行される命令の数を計数する計数手段と、前記計数した命令数が予め定めた閾値を越えた場合に、実行対象スレッドに動作異常が生じていると判断する手段と、動作異常が生じていると判断したスレッドの動作を停止する手段とを備えることを特徴とする。
【００１８】
本発明のスレッド動作異常検知方法は、コンピュータにおいてＣＰＵにより実行することができるが、そのためのコンピュータプログラムは、ＣＤ−ＲＯＭ、磁気ディスク、半導体メモリ及び通信ネットワークなどの各種の媒体を通じてコンピュータにインストールまたはロードすることができる。
【発明の効果】
【００１９】
以上、本発明によれば、アプリケーションのソースコードに依存することなく、スレッド内で発生する無限ループを検知することができる新しい枠組みを提供することができる。
【発明を実施するための最良の形態】
【００２０】
（第１の実施形態）
以下に図面を参照しながら本発明の第１の実施形態を説明する。
【００２１】
図１は、第１実施形態におけるマルチスレッドシステム１が構築されるコンピュータ２のハードウェア構成の概略を示す。コンピュータ２は、ＣＰＵ（プロセッサ）、ＲＯＭ、ＲＡＭ、ユーザインタフェース、ＨＤＤなど、通常のコンピュータ装置と同様のハードウェアを備えている。
【００２２】
図２は、第１実施形態におけるマルチスレッドシステム１の機能構成の概略を示す。マルチスレッドシステム１は、ＯＳ１０、仮想マシン２０、スレッド情報記憶手段３０などを備えている。
【００２３】
スレッド情報記憶手段３０は、ユーザスレッド（アプリケーション上の並列実行の対象となる処理単位；以下、単に「スレッド」又は「実行対象スレッド」と記載した場合、ユーザスレッドを指すものとする）に対応するバイトコード（特定のＯＳやハードウェアに依存しないように定義された命令、又はその集合によって記述された実行形式のプログラム）等の情報を記憶している。
【００２４】
ＯＳ１０及び仮想マシン２０は、各スレッドに設定されている優先度に基づいてスレッドを切り替えながら実行するマルチスレッド実行環境を構築する。例えば、優先度が同じスレッドが２つ存在する場合、一方のスレッドのスレッド実行制御部に実行権限が与えられると、該スレッド実行制御部が実行権限を放棄する（該スレッドが終了する／停止する）まで他方のスレッドへスレッド切換は行われない。また優先度が異なるスレッドが２以上存在する場合、優先度が低いスレッドのスレッド実行制御部は、優先度の高いスレッドのスレッド実行制御部が実行権限を放棄している間のみ、実行権限を得ることができる。従って、優先度が低いスレッドの実行中、優先度の高いスレッドが実行可能になると、該優先度の低いスレッドの実行は停止され、該優先度の高いスレッドが実行されることになる。
【００２５】
このようなマルチスレッド実行環境を実現するために、ＯＳ１０は、Ｌｉｎｕｘ等の従来のＯＳと同様に、スレッドの動作管理のために優先度等の情報を格納するスレッド管理テーブル１１などを備えている。また仮想マシン２０は、Ｊａｖａ（登録商標）仮想マシン等の従来の仮想マシンと同様に、スレッドごとに作成され、その実行を制御するスレッド実行制御部２１などを備えている。なお、仮想マシン２０はＯＳ１０上で動作するソフトウェアによって実現されることから、スレッド実行制御部２１はＯＳ１０上のスレッド（仮想マシンスレッド）として把握することができる。
【００２６】
ただし、本実施形態のスレッド実行制御部２１は、図３に示すように、対応するバイトコードをコンピュータ２で実行可能なネイティブコードに変換して実行するアプリ実行部４０に加えて、スレッドの動作異常を検知する検知部５０を備えている点で、従来のスレッド実行制御部２１とは異なっている。具体的には、スレッド動作異常検知部５０は、実行対象スレッドに関して連続して実行される命令（バイトコード）の数を計数する連続実行命令計数手段５１（以下、「計数手段５１」という）、前記計数した命令数が予め定めた閾値を越えた場合に、実行対象スレッドに動作異常が生じていると判断する動作異常判断手段５２（以下、「判断手段５２」という）、動作異常が生じていると判断したスレッドの動作を停止する停止制御手段５３などを備えて構成される。
【００２７】
なお、仮想マシン２０（スレッド実行制御部２１等）のためのプログラムは、コンピュータ２が備えるＲＯＭやＨＤＤ等の不揮発性記憶装置上に記憶されている。またスレッド情報記憶手段３０等はコンピュータ２が備えるＲＯＭやＨＤＤ等の不揮発性記憶装置上に実現され、スレッド管理テーブル１１はコンピュータ２が備えるＲＡＭ上に実現される。
【００２８】
以下、図４のフローチャートを参照して、第１実施形態のマルチスレッドシステム１におけるスレッド動作異常検知の枠組みを説明する。なお、所定の言語で記述されたアプリケーションソースコードをコンパイルした結果、各スレッドのバイトコードが得られており、スレッド識別情報に対応づけてスレッド情報記憶手段３０に格納されているものとする。また、各工程（符号が付与されていない部分的な工程を含む）は処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。かかる点は、後述の第２実施形態においても同様とする。
【００２９】
（スレッド動作異常検知）
仮想マシン２０は、アプリケーションの実行指示を受け付けると、ｍａｉｎスレッドに対応するスレッド実行制御部２１を作成する（Ｓ１００）。この場合、ＯＳ１０は、スレッド管理テーブル１１にｍａｉｎスレッドに対応するスレッド実行制御部２１の情報（優先度など）を登録し、そのステータスをＲｕｎ状態とする。これにより、ｍａｉｎスレッドが実行対象スレッドとなる。なお、スレッド実行制御部２１等の仮想マシンスレッドは、Ｒｕｎ状態（実行状態）のほか、Ｒｅａｄｙ状態（実行可能状態）、Ｗａｉｔ状態（実行待ち状態）などのステータスを取り得る。
【００３０】
次に、実行対象スレッドに対応する（すなわち、Ｒｕｎ状態のスレッド実行制御部２１の）アプリ実行部４０は、スレッド情報記憶手段３０を参照して、実行対象スレッドのバイトコードを順次、取得する（Ｓ１０１）。なお、以下において特に区別せずにアプリ実行部４０と記載した場合、実行対象スレッドに対応するアプリ実行部４０を指すものとし、スレッド動作異常検知部５０の各手段についても同様とする。
【００３１】
Ｓ１０１においてバイトコードを取得できなかった場合（読み出すバイトコードが無かった場合）（Ｓ１０２：Ｎｏ）、仮想マシン２０は、Ｒｕｎ状態のスレッド実行制御部２１を解放する（Ｓ１０３）。この場合、ＯＳ１０は、解放されたスレッド実行制御部２１の情報をスレッド管理テーブル１１から削除するとともに、スレッド管理テーブル１１に登録されるＲｅａｄｙ状態のスレッド実行制御部２１から優先度に基づいて１つを選択し、該選択したスレッド実行制御部２１をＲｕｎ状態とする。仮想マシン２０は、Ｒｕｎ状態のスレッド実行制御部２１について処理を続行させるべく、Ｓ１０１に再帰する。なお、スレッド管理テーブル１１にスレッド実行制御部２１が登録されていない場合は、アプリケーションが終了することになる。
【００３２】
一方、バイトコードを取得できた場合（Ｓ１０２：Ｙｅｓ）、アプリ実行部４０は、前記取得したバイトコードをコンピュータ２で実行可能なネイティブコードに変換して実行する（Ｓ１０４）。
【００３３】
例えば、前記取得したバイトコードがスレッドの生成を示すものであった場合、Ｒｕｎ状態のスレッド実行制御部２１は、生成スレッドに対応するスレッド実行制御部２１を作成する。この場合、ＯＳ１０は、スレッド管理テーブル１１に生成スレッドに対応するスレッド実行制御部２１の情報を登録し、そのステータスをＷａｉｔ状態とする。
【００３４】
また例えば、前記取得したバイトコードが他のスレッドの開始を示すものであった場合、ＯＳ１０は、スレッド管理テーブル１１を参照し、開始スレッドに対応するスレッド実行制御部２１のステータスをＲｅａｄｙ状態とする。なお、ＯＳ１０は、スリープ時間が経過したスレッド実行制御部２１、ロックを獲得できたスレッド実行制御部２１、イベント待ちのイベントが起きたスレッド実行制御部２１等についても、そのステータスをＲｅａｄｙ状態とする。
【００３５】
また例えば、前記取得したバイトコードがスレッド切換を発生させるものであった場合（INVOKESTATIC命令によるスリープ関数呼び出し、MONITOR_ENTER命令によるロック確保待ちなど）、ＯＳ１０は、スレッド管理テーブル１１を参照し、Ｒｕｎ状態のスレッド実行制御部２１のステータスをＷａｉｔ状態とする一方、Ｒｅａｄｙ状態のスレッド実行制御部２１から各スレッドの優先度に基づいて１つを選択して、Ｒｕｎ状態とする（スレッドを切り替える）。
【００３６】
なお、Ｓ１０４の工程によってスレッド切換が発生しなかった場合、Ｓ１０４の工程を実行したスレッド実行制御部２１が続けてＳ１０５の工程を実行することになるが、Ｓ１０４の工程によってスレッド切換が発生した場合、Ｓ１０４の工程を実行したスレッド実行制御部２１は一旦停止し、他のスレッド実行制御部２１に実行権限が移ることになる。そして、一旦停止したスレッド実行制御部２１は、ＯＳ１０によって再びＲｕｎ状態とされた場合に、Ｓ１０５の工程から再開することになる。
【００３７】
Ｓ１０５において、計数手段５１は、スレッド切換が発生したかどうかを判断する（スレッド切換の発生を検知する）。
【００３８】
スレッド切換が発生したかどうかを判断する方法としては、例えば、前回Ｓ１０４を実行したスレッド実行制御部に対応するスレッドの識別情報、及び今回Ｓ１０４を実行したスレッド実行制御部に対応するスレッドの識別情報をそれぞれＲＡＭに記憶するように構成し、両者が一致しない場合にスレッド切換が発生したと判断することが考えられる。
【００３９】
スレッド切換が発生している場合、計数手段５１は、Ｒｕｎ状態のスレッド実行制御部２１の命令数カウンタを０にリセットする（Ｓ１０６）。命令数カウンタは、アプリ実行部４０が実行する命令（バイトコード）の数を格納するためにスレッド実行制御部ごとにＲＡＭ上に準備され、初期値は０であるものとする。仮想マシン２０は、その後、Ｒｕｎ状態のスレッド実行制御部２１について処理を続行させるべく、Ｓ１０１に再帰する。
【００４０】
スレッド切換が発生していない場合、計数手段５１は、Ｒｕｎ状態のスレッド実行制御部２１の命令数カウンタをカウントアップする（Ｓ１０７）。
【００４１】
次に、判断手段５２は、命令数カウンタの値が予め定めた閾値を越えたか否かを判断する（Ｓ１０８）。前記閾値は、コンピュータ２が所定期間（例えば２分間）に実行できる命令数とするなど、設計に応じて定めることができ、予めＲＯＭ又はＨＤＤ上に（例えばプログラムの一部として）記憶されているものとする。
【００４２】
前記閾値を越えていない場合、仮想マシン２０は、Ｒｕｎ状態のスレッド実行制御部２１について処理を続行させるべく、Ｓ１０１に再帰する。
【００４３】
一方、Ｓ１０８において前記閾値を越えている場合、判断手段５２は、実行対象スレッドに動作異常が生じている（無限ループが発生している）と判断する（Ｓ１０９）。
【００４４】
該判断を受けて、停止制御手段５３は、動作異常が生じていると判断したスレッドを停止する（Ｓ１１０）。この場合、ＯＳ１０は、動作異常スレッドに対応するスレッド実行制御部２１のステータスをＷａｉｔ状態に変更する一方、Ｒｅａｄｙ状態のスレッド実行制御部２１から各スレッドの優先度に基づいて１つを選択して、Ｒｕｎ状態とする。仮想マシン２０は、Ｒｕｎ状態のスレッド実行制御部２１について処理を続行させるべく、Ｓ１０１に再帰する。
【００４５】
なお、Ｓ１１０において、停止制御手段５３が、例えば標準エラー出力に、動作異常が生じているスレッドを特定する情報（スレッド名など）を含むデバッグ情報を出力するように構成してもよい。図５に、デバッグ情報の表示例を示す。該例に示すように、デバッグ情報には、スレッド名以外に、例えば、エラーメッセージ、スタックトレース情報などを含めることが考えられる。特に、本実施形態では、命令数をカウントアップする都度、動作異常を判断する構成となっているので、動作異常を検知したタイミングで実行中だった命令及びスレッドを容易に特定することができ、該命令がどのスレッドに属し、どのメソッドで呼ばれたかといったネスティング情報などをデバッグ情報に容易に含めることができる。
【００４６】
このように本実施形態では、仮想マシン２０のスレッド実行制御部２１が、同一スレッドにおいて（すなわち、スレッド遷移を挟まずに）連続して実行される命令数を計数して該命令数が閾値を越えた場合に動作異常と判断するスレッド動作異常検知部５０を備えるように構成しており、更に、該検知部５０において、スレッド内の生存通知命令によって命令数カウンタをリセットするのではなく、スレッド切換が発生した場合に命令数カウンタをリセットする構成を採用している。
【００４７】
かかる構成によれば、スレッドからの生存通知を利用せずにスレッドの動作異常を検知できるため、従来のように生存通知命令を含む無限ループが検知できないといった問題は生じない。
【００４８】
また、マルチシステム実行環境側にスレッド動作異常検知部が設けられているため、スレッドに対応するバイトコード、従って、アプリケーションのソースコードに依存することなく、スレッド内の無限ループを安定して検知することが可能となる。かかる点は、組み込みシステム向けのアプリケーション開発を、仮想マシン上で動作する組み込みシステムのエミュレータを用いて行う場合に、特に有用である。すなわち、アプリケーション自体にスレッド動作異常を検知するための処理を実装する必要がないので、アプリケーションを組み込みシステム本来の目的に適した構成とすることができるからである。
また、スレッド動作異常（無限ループ）が発生したスレッド名や、そのときのコールスタックなどをデバッグ情報として出力できるため、動作異常の解析をスムーズに行うことができる。
【００４９】
（第２の実施形態）
以下に図面を参照しながら本発明の第２の実施形態を説明する。
【００５０】
第２実施形態におけるマルチスレッドシステム１は、第１の実施形態同様、図１に示すようなコンピュータ２上に構築され、また図２に示すような機能構成を備える。
【００５１】
ただし、第２実施形態のＯＳ１０及び仮想マシン２０は、各スレッドの優先度及び時分割制御に基づいてスレッドを切り替えながら実行するマルチスレッド実行環境を構築している点で、第１実施形態とは異なる。例えば、優先度が同じスレッドが２つ存在し、そのうち一方のスレッドに実行権限が与えられた場合、該スレッドが実行権限を放棄するか、又は該スレッドがタイムスライス（予め定めた規定時間）分実行すると、他方のスレッドに実行権限が移される。なお、優先度が異なるスレッドの切換については、第１実施形態と同様に制御される。ただし、ある優先度のスレッドがタイムスライス分実行した場合であって、該スレッドと同じかそれ以上の優先度のスレッドが実行可能でない場合、時分割制御に基づき、優先度の低いスレッドへ実行権限が移されるように構成してもよい。
【００５２】
このようなマルチスレッド実行環境を実現するために、ＯＳ１０は、第１実施形態同様に、スレッドの動作管理のために優先度等の情報を格納するスレッド管理テーブル１１などを備えている。また仮想マシン２０は、第１実施形態同様に、スレッドごとに作成されるスレッド実行制御部２１（アプリ実行部４０、スレッド動作異常検知部５０）などを備えている（図２、図３参照）。
【００５３】
ただし、第２実施形態の仮想マシン２０は、図６に示すように、スレッド切換を発生させる命令（ＩＮＶＯＫＥＳＴＡＴＩＣ命令、ＭＯＮＩＴＯＲ＿ＥＮＴＥＲ命令、ＩＮＶＯＫＥＶＥＲＴＵＡＬ命令など）の一覧リストを記憶するスレッド切換命令記憶手段２２を備えている点で、第１実施形態とは異なっている。
【００５４】
また、第２実施形態のスレッド実行制御部２１は、その計数手段５１が、実行される命令がスレッド切り替えを発生させる命令であるか否かを判断し、スレッド切り替えを発生させる命令であると判断した場合、前記計数した命令数を０にリセットする点で、第１実施形態のスレッド実行制御部２１とは異なっている。
【００５５】
なお、スレッド切換命令記憶手段２２は、コンピュータ２が備えるＲＯＭやＨＤＤ等の不揮発性記憶装置上に実現される。
【００５６】
以下、図７のフローチャートを参照して、第２実施形態のマルチスレッドシステム１におけるスレッド動作異常検知の枠組みを説明する。
【００５７】
（スレッド動作異常検知）
第２実施形態では、実行対象スレッドの切換は、仮想マシン２０（スレッド実行制御部２１）がスレッド切換を発生させる命令を実行した場合に加えて、ＯＳ１０による時分割制御によっても発生する。そのため、第１実施形態のように、単純にスレッド切換が発生した場合に命令数カウンタを０にリセットする構成とすると、スレッドで無限ループが生じている場合であっても、時分割制御によってスレッド切換が発生した場合に命令数カウンタが０にリセットされてしまうので、無限ループの存在を検知することができないおそれがある。
【００５８】
かかる点は、時分割制御によるマルチスレッド実行環境を採用しない組み込みシステムのアプリケーション開発を、時分割制御によるマルチスレッド実行環境を採用するＯＳ上のエミュレータで行う場合に、特に問題となる。すなわち、組み込みシステムにおいて無限ループが生じる場合であっても、エミュレータ上ではその無限ループを検知できないおそれがあるからである。
【００５９】
そこで、第２実施形態では、仮想マシン２０（スレッド実行制御部２１）がスレッド切換を発生させる命令を実行した場合に命令数カウンタをリセットするように構成する（別言すれば、時分割制御によってスレッド切換が発生した場合には命令数カウンタがリセットされないように構成する）ことで、上記問題を解決する。
【００６０】
仮想マシン２０は、アプリケーションの実行指示を受け付けると、ｍａｉｎスレッドに対応するスレッド実行制御部２１を作成する（Ｓ２００）。この場合、ＯＳ１０は、ＲＡＭ上に作成したスレッド管理テーブル１１にｍａｉｎスレッドに対応するスレッド実行制御部２１の情報（優先度など）を登録し、そのステータスをＲｕｎ状態とする。これにより、ｍａｉｎスレッドが実行対象スレッドとなる。
【００６１】
次に、実行対象スレッドに対応するアプリ実行部４０は、スレッド情報記憶手段３０を参照し、実行対象スレッドのバイトコードを順次、取得する（Ｓ２０１）。
【００６２】
Ｓ２０１においてバイトコードを取得できなかった場合（Ｓ２０２：Ｎｏ）、仮想マシン２０は、実行対象スレッドに対応するスレッド実行制御部２１を解放する（Ｓ２０３）。この場合、ＯＳ１０は、スレッド管理テーブル１１から実行対象スレッドの情報を削除するとともに、スレッド管理テーブル１１に登録されるＲｅａｄｙ状態のスレッド実行制御部２１から優先度に基づいて１つを選択し、該選択したスレッド実行制御部２１をＲｕｎ状態とする。仮想マシン２０は、Ｒｕｎ状態のスレッド実行制御部２１について処理を続行させるべく、Ｓ１０１に再帰する。なお、スレッド管理テーブル１１にスレッド実行制御部２１が登録されていない場合は、アプリケーションが終了することになる。
【００６３】
一方、バイトコードを取得できた場合（Ｓ２０２：Ｙｅｓ）、計数手段５１は、スレッド切換命令記憶手段２２を参照し、前記取得したバイトコードがスレッド切換を発生させる命令であるか否か（スレッド切換命令記憶手段２２の一覧リストに登録されているか否か）を判断する（Ｓ２０４）。
【００６４】
スレッド切換を発生させる命令である場合、計数手段５１は、Ｒｕｎ状態のスレッド実行制御部２１の命令数カウンタを０にリセットし（Ｓ２０５）、Ｓ２０６の工程に進む。命令数カウンタは、第１実施形態同様、アプリ実行部４０が実行する命令の数を格納するためにスレッド実行制御部ごとにＲＡＭ上に準備され、初期値は０であるものとする。
【００６５】
一方、スレッド切換を発生させる命令でない場合、命令数カウンタをリセットすることなく、Ｓ２０６の工程に進む。
【００６６】
Ｓ２０６において、アプリ実行部４０は、第１実施形態同様、前記取得したバイトコードをコンピュータ２で実行可能なネイティブコードに変換して実行する。
【００６７】
次に、計数手段５１は、Ｒｕｎ状態のスレッド実行制御部２１の命令数カウンタをカウントアップする（Ｓ２０７）。
【００６８】
次に、判断手段５２は、命令数カウンタの値が予め定めた閾値を越えたか否かを判断する（Ｓ２０８）。前記閾値は、第１実施形態同様、コンピュータ２が所定期間（例えば２分間）に実行できる命令数とするなど、設計に応じて定めることができ、予めＲＯＭ又はＨＤＤ上に（例えばプログラムの一部として）記憶されているものとする。
【００６９】
前記閾値を越えていない場合、仮想マシン２０は、Ｒｕｎ状態のスレッド実行制御部２１について処理を続行させるべく、Ｓ２０１に再帰する。
【００７０】
一方、Ｓ２０８において前記閾値を越えている場合、判断手段５２は、実行対象スレッドに動作異常が生じている（無限ループが発生している）と判断する（Ｓ２０９）。
【００７１】
該判断を受けて、停止制御手段５３は、動作異常が生じていると判断したスレッドを停止する（Ｓ２１０）。この場合、ＯＳ１０は、動作異常スレッドに対応するスレッド実行制御部２１のステータスをＷａｉｔ状態に変更する一方、Ｒｅａｄｙ状態のスレッド実行制御部２１から各スレッドの優先度に基づいて１つを選択して、Ｒｕｎ状態とする。仮想マシン２０は、Ｒｕｎ状態のスレッド実行制御部２１について処理を続行させるべく、Ｓ２０１に再帰する。
【００７２】
この際、停止制御手段５３が、第１実施形態同様、例えば標準エラー出力に、動作異常が生じているスレッドを特定する情報（スレッド名など）を含むデバッグ情報を出力するように構成してもよい。
【００７３】
このように第２実施形態では、仮想マシン２０のスレッド実行制御部２１が、同一スレッドにおいて連続して実行される命令数を計数して該命令数が閾値を越えた場合に動作異常と判断するスレッド動作異常検知部５０を備えている点では、第１実施形態と同様であるが、更に、仮想マシン２０がスレッド切換命令記憶手段２２を備えるように構成するとともに、スレッド動作異常検知部５０において、スレッド切換命令の実行によってスレッド切換が発生した場合に、命令数カウンタをリセットする構成を採用している。
【００７４】
かかる構成によれば、第１実施形態同様、スレッドからの生存通知を利用せずにスレッドの動作異常を検知できるため、従来のように生存通知命令を含む無限ループが検知できないといった問題は生じない。
【００７５】
また、時分割制御によってスレッド切換が発生した場合には命令数カウンタがリセットされないため（別言すれば、時分割制御によるスレッド切換によっては、カウントする連続実行命令数の「連続」が中断されないため）、時分割制御に基づくマルチスレッド実行環境に対しても適用することができる。
【００７６】
また、マルチシステム実行環境側にスレッド動作異常検知部が設けられているため、スレッドに対応するバイトコード、従って、アプリケーションのソースコードに依存することなく、スレッド内の無限ループを安定して検知することが可能となる。
【００７７】
（変形例）
本発明は、上記各実施形態に限定されることなく種々に変形して適用することが可能である。例えば、上記各実施形態では、ユーザインタフェース、ＨＤＤを備えるコンピュータ２上にマルチスレッドシステム１を構築しているが、本発明は、ユーザインタフェース、ＨＤＤを備えていないデバイスにおいても適用可能である。
【００７８】
また例えば、第１実施形態では、前回Ｓ１０４の工程を実行したスレッド実行制御部に対応するスレッドの識別情報と今回Ｓ１０４の工程を実行したスレッド実行制御部に対応するスレッドの識別情報とが一致しない場合にスレッド切換が発生したと判断し、命令数カウンタをリセットする構成について説明したが、第１実施形態において、第２実施形態のようにスレッド切換命令を実行した場合に命令数カウンタをリセットする構成を採用してもよい。この場合、低い優先度のスレッドから高い優先度のスレッドへの強制的なスレッド切換によっては命令数カウンタが０にリセットされないので、第２実施形態同様、的確に無限ループの発生を検知することができる。また、第１及び第２実施形態において、スレッド実行制御部２１が、ＯＳ１０が管理するスレッド管理テーブル１１等の情報を参照したり、ＯＳ１０からの通知によって、スレッド切換命令の実行に基づくスレッド切換が発生したことを判断する構成としてもよい。
【００７９】
また、上記各実施形態では、動作異常が生じているスレッドを停止する場合、対応するスレッド実行制御部２１をＷａｉｔ状態とする構成としているが、Ｗａｉｔ状態とする代わりに休止状態に移行させてもよい。またこの場合、アプリケーション自体を終了させるように構成してもよい。
【００８０】
また、上記実施形態では、優先度に基づくスレッドのスケジューリングをＯＳ１０が実行するマルチスレッド実行環境としているが、該スケジューリングを仮想マシン２０が行うように構成してもよい。また、ＯＳ１０がＬＷＰ（Light Weight Process）に対応している場合は、ＯＳ１０及び仮想マシン２０においてそれぞれスケジューリングを行う２層構造のマルチスレッド実行環境を採用してもよい。また、上記実施形態では、マルチスレッド実行環境をＯＳ１０及び仮想マシン２０によって構築しているが、本発明は必ずしもこのような態様に限られない。例えば、仮想マシンを介さずにＯＳ単体でマルチスレッド実行環境を構築する態様であってもよい。
【図面の簡単な説明】
【００８１】
【図１】第１及び第２実施形態におけるマルチスレッドシステム１のハードウェア構成を示すブロック図である。
【図２】第１実施形態におけるマルチスレッドシステム１の機能構成を示すブロック図である。
【図３】第１及び第２実施形態におけるスレッド実行制御部２１の機能構成を示すブロック図である。
【図４】第１実施形態におけるスレッド動作異常検知の枠組みを説明するためのフローチャートである。
【図５】デバッグ情報の表示例を説明するための図である。
【図６】第２実施形態におけるマルチスレッドシステム１の機能構成を示すブロック図である。
【図７】第２実施形態におけるスレッド動作異常検知の枠組みを説明するためのフローチャートである。
【符号の説明】
【００８２】
１  マルチスレッドシステム；２  コンピュータ；１０  ＯＳ；２０  仮想マシン；２１  スレッド実行制御部；２２  スレッド切換命令記憶手段；３０  スレッド情報記憶手段；４０  アプリ実行部；５０  スレッド動作異常検知部；５１  連続実行命令計数手段；５２  動作異常判断手段；５３  停止制御手段
【図１】
2008204013.tif 000003
【図２】
2008204013.tif 000004
【図３】
2008204013.tif 000005
【図４】
2008204013.tif 000006
【図５】
2008204013.tif 000007
【図６】
2008204013.tif 000008
【図７】
2008204013.tif 000009