(57)【要約】  【課題】  複数のプログラムがイベントにより連係して動作する場合に待機スレッドの実行再開遅れを検出する。  【解決手段】  監視イベントに関してスレッドから待機の要求を受けたとき、ＯＳは、待機を示す情報をメモリに記録する。そのイベントに関して通知を受けたとき、ＯＳは、その通知時刻をメモリに記録する。待機スレッドが実行再開されたとき、ＯＳは、対応する待機記録と該当する通知時刻を消し込む。待機記録と該当する通知記録が残っている状態で、現在時刻が残っている通知時刻より所定の許容時間以上過ぎている場合に、ＯＳは、該当するスレッドの実行再開遅れと判定する。【選択図】  図１
2007072958.tif 000002
【特許請求の範囲】
【請求項１】
プログラムを実行する少なくとも１つのスレッドが他のプログラムの処理とイベントによる同期を行う計算機において、前記スレッドの実行再開遅れを検出する遅延検出方法であって、
前記イベントに関して前記スレッドから待機の要求を受けたとき、当該スレッドと対応づけて待機することを示す情報をメモリに記録するステップと、
前記イベントに関して前記他のプログラムの処理から通知を受けたとき、その通知ごとに通知時刻を前記メモリに記録するステップと、
待機中の前記スレッドが実行再開されたとき、各々対応する前記の待機記録と該当する前記通知時刻を消し込むステップと、
前記待機記録と該当する前記通知記録が残っている状態で、現在時刻が残っている前記通知時刻より所定の許容時間以上過ぎているか否か判定するステップとを有し、
前記現在時刻が前記許容時間以上過ぎている場合に、該当するスレッドの実行再開遅れと判定することを特徴とするイベント同期の遅延検出方法。
【請求項２】
前記の現在時刻が前記許容時間以上過ぎているか否か判定するステップを、オペレーティングシステムのタイマ割込み処理の中で実行することを特徴とする請求項１記載のイベント同期の遅延検出方法。
【請求項３】
前記遅延検出方法の各ステップは、オペレーティングシステム（ＯＳ）を実行することによって実現され、前記スレッドからの待機要求のインタフェイスおよび前記他のプログラムの処理からの通知のインタフェイスは、汎用ＯＳのインタフェイスとは異なる専用のインタフェイスであることを特徴とする請求項１記載のイベント同期の遅延検出方法。
【請求項４】
主系として動作する第１の計算機と、待機系として動作する第２の計算機とを有するクラスタ構成の計算機システムにおいて、前記第１の計算機が前記遅延検出を行い、前記実行再開遅れを検出したとき前記第１の計算機の異常状態を表明し、前記第２の計算機が前記異常状態を検出して待機系の動作から主系の動作に切り替えることを特徴とする請求項１記載のイベント同期の遅延検出方法。
【請求項５】
前記イベントは、入出力操作の完了を通知するためのイベントであり、前記スレッドは前記入出力操作の完了を待機するための要求を発行し、前記他のプログラムの処理は前記入出力操作の完了を通知することを特徴とする請求項１記載のイベント同期の遅延検出方法。
【請求項６】
ＣＰＵとメモリとを備え、プログラムを実行する少なくとも１つのスレッドが他のプログラムの処理とイベントによる同期を行い、前記スレッドの実行再開遅れを検出する計算機であって、前記計算機は、
前記イベントに関して前記スレッドから待機の要求を受けたとき、当該スレッドと対応づけて待機することを示す情報を前記メモリに記録する手段と、
前記イベントに関して前記他のプログラムの処理から通知を受けたとき、その通知ごとに通知時刻を前記メモリに記録する手段と、
待機中の前記スレッドが実行再開されたとき、各々対応する前記の待機記録と該当する前記通知時刻を消し込む手段と、
前記待機記録と該当する前記通知記録が残っている状態で、現在時刻が残っている前記通知時刻より所定の許容時間以上過ぎているか否か判定する手段とを有し、
前記現在時刻が前記許容時間以上過ぎている場合に、該当するスレッドの実行再開遅れと判定することを特徴とする計算機。
【請求項７】
前記の現在時刻が前記許容時間以上過ぎているか否か判定する手段を、オペレーティングシステムのタイマ割込み処理の中で実行することを特徴とする請求項６記載の計算機。
【請求項８】
前記計算機の各手段は、オペレーティングシステム（ＯＳ）を実行することによって実現され、前記スレッドからの待機要求のインタフェイスおよび前記他のプログラムの処理からの通知のインタフェイスは、汎用ＯＳのインタフェイスとは異なる専用のインタフェイスであることを特徴とする請求項６記載の計算機。
【請求項９】
主系として動作する第１の計算機と、待機系として動作する第２の計算機とがクラスタ構成の計算機システムを構成し、前記計算機は、前記第１の計算機として前記遅延検出を行い、前記実行再開遅れを検出したとき前記第１の計算機の異常状態を表明し、前記第２の計算機が前記異常状態を検出して待機系の動作から主系の動作に切り替えることを特徴とする請求項６記載の計算機。
【請求項１０】
前記イベントは、入出力操作の完了を通知するためのイベントであり、前記スレッドは前記入出力操作の完了を待機するための要求を発行し、前記他のプログラムの処理は前記入出力操作の完了を通知することを特徴とする請求項６記載の計算機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機で実行するプログラムの動作を監視する技術に係わり、特に、プログラムがイベントで連携している場合に動作遅延を検出する技術に関する。
【背景技術】
【０００２】
高度な応答性能が要求される計算機システムや、処理完了までの時間が厳密に規定されている計算機システムでは、個々のプログラムの処理実行を予め定められた一定時間内に納めることが重要となる。このようなシステムの構築では、処理時間を一定時間内に収めるように設計するか、決められた時間を越えても処理が終了しないイベントを監視することが重要となる。
【０００３】
一般にリアルタイムＯＳと呼ばれるＯＳを用いて構築されるシステムでは、計算機で実行されるすべての処理の処理時間が計算可能であり、それによって、利用者が実行するプログラムの動作時間を予め設計できる。これによって、システムで実行する処理を一定の時間内に収めることが可能である。
【０００４】
一方、汎用のＯＳにおいては、プログラムの処理時間を予め求めることはできない。これは、利用者からは制御できない処理がＯＳ内で実行されるためである。このようなＯＳにおいては、プログラムが予め想定している通りに実行しているか否かを監視することが重要である。このために、特許文献１では、特定のプログラムを実行するプロセスについて、そのプロセスの状態を管理し、表示する方法を実現している。
【０００５】
また、汎用のＯＳは、複数のプロセスの連係動作が滞らないようにする機能を組み込んでいる場合もある。例えば、特許文献２では、プロセスの連係動作に利用する排他制御機能を用いて、プログラムの異常を検知する方法を開示している。また、非特許文献１では、プロセスのスケジューリングにおいて、優先度の高いプロセスが実行しているため、走行可能であってもＣＰＵを与えられないプロセスを走行させる仕掛けとして、プロセスの優先度を一時的に高くする方法を開示している。
【０００６】
他にも、プログラムが正常に実行していることを一定周期で連絡して、その状況を監視するウォッチドッグタイマと呼ばれる方法も一般的である。
【０００７】
【特許文献１】米国特許 第５，６３６，３７６号（１９９７年６月）  System and method for selectively and contemporaneously monitoring processes in a multiprocessing server
【特許文献２】特開２００１−５６９４号公報
【非特許文献１】D. Solomon他１名, “Windows(登録商標) Internal 4th Edition,” (Priority Boost for CPU  Starvation, pp354-355), Microsoft Press, 2005年
【発明の開示】
【発明が解決しようとする課題】
【０００８】
汎用ＯＳ向けの従来技術では、あるイベントによるプログラム間の連係動作を監視できないという問題がある。特に、イベント通知を待機しているプロセスが、イベント通知されたにも関わらず、システム内の他の高優先度プロセスのために走行不能である状況を検知できないという問題がある。プロセスをスレッドの単位で実行するときのスレッドについても同様である。
【０００９】
従来技術による個々のプログラムの動作監視では、何をもってそれぞれのプログラムが正常に実行しているとするのかを定めるのが困難であるという問題がある。例えば、ウォッチドッグタイマによる監視においては、プログラムは正常に動作していることを知らせるために、一定時間内にウォッチドッグタイマにアクセスするが、この動作は必ずしもプログラムが正常に実行していることを反映しないため、プログラムの動作監視にならない場合があり問題である。
【００１０】
本発明の目的は、複数のプログラムがイベントにより連携している場合の動作遅延を検出することにある。
【課題を解決するための手段】
【００１１】
本発明は、イベントによるプログラムの連係動作を監視するために、監視対象とするイベントを指定し、監視対象として指定されているイベント通知に対する待機、通知の操作を記録し、待機しているスレッドの実行再開を記録し、この記録を検査してイベント通知されたにも関わらず走行を再開しないスレッドが存在することを検知する技術を特徴とする。
【発明の効果】
【００１２】
本発明によれば、汎用ＯＳを利用するシステムにおいて、特定のイベントによるプログラムの連携が滞りなく動作しているか否かを監視できる。これによって、システム内で不正なプロセスがＣＰＵを占有する場合や、過負荷のために、所定のスレッドが所定の時間内に実行を再開できない事象を確実かつ迅速に検知できる。
【００１３】
本発明を複数の計算機から構成するクラスタシステムに適用すれば、イベント連携による遅延を異常として検知し、それを契機にクラスタの構成変更を開始できる。
【００１４】
また、本発明を非同期Ｉ／Ｏ操作の完了通知に適用すれば、Ｉ／Ｏ操作が完了しているのに実行を再開できないプログラムを検知できる。
【発明を実施するための最良の形態】
【００１５】
以下に、図を用いて本発明の実施形態について説明する。
【実施例１】
【００１６】
以下、実施例１について説明する。図５は、実施例１の計算機５００の構成例を示す図である。ここに示した構成は一例であって、本発明が実施可能な計算機の構成を限定するものではない。
【００１７】
計算機５００は、ＣＰＵ５０１、主記憶装置５０２、外部記憶装置５０３、通信制御部５０４、入出力装置、および、それらを接続する制御部から成る。ＣＰＵ５０１は、主記憶装置（メモリ）５０２にロードされたプログラムを実行する。以下、ＣＰＵがプログラムを実行することを、単にプログラムが実行すると説明する。また、ＯＳは、プログラムの実行をスレッドの単位でスケジュールする。
【００１８】
外部記憶装置５０３は、計算機５００の実行に必要なＯＳ、プログラム、監視対象イベントを登録する登録プログラム１２０、設定ファイル５２０などのファイルを格納している。図５の主記憶装置５０２は、ＯＳ、プログラム１２１、およびプログラム１２２がロードされている様子を示している。
【００１９】
ＯＳ内には、イベント連携監視用のイベント監視管理データ１００とイベント処理部５１１が存在している。ＯＳは、様々の処理間の連携のために、イベントオブジェクト（以下、イベントと略称する場合がある）を提供する。スレッドは、ＯＳ内に割り当てたイベントに対し、待機の操作ができる。あるイベントを待機するスレッドは、他の処理がそのイベントについて通知操作をするまで実行を中断して待機する。別の処理がそのイベントについて通知操作を実行すると、ＯＳはそのイベントで待機しているスレッドが実行を再開するようにスケジューラに指示する。
【００２０】
実施例１では、プログラム１２１とプログラム１２２がイベントによる同期をとるものとして説明する。また、外部記憶装置５０３はイベント監視に関する設定ファイル５２０を保持し、登録プログラム１２０が、設定ファイル５２０の内容に従ってＯＳに監視対象イベントを登録するものとする。
【００２１】
図１は、実施例１のデータ構造と処理モジュールの関係を示す図である。まず、データ構造について説明する。
【００２２】
計算機５００が実行するＯＳは、イベント監視管理データ１００を保持する。イベント監視管理データ１００は、監視イベントテーブル１０１と通知リスト１０２から成る。通知リスト１０２は、少なくとも１つの通知ブロック１０３ないし１０５から成る。監視イベントテーブル１０１は、登録プログラム１２０が監視対象として登録したイベントの情報を保持する。
【００２３】
監視イベントテーブル１０１は、各対象イベントオブジェクトについて、イベントオブジェクトのアドレス、イベント通知されてから待機スレッドが走行を再開するまでの許容時間、および、イベント通知操作それぞれについて待機スレッドの再開状況を保持する通知リスト１０２の先頭アドレスを保持する。
【００２４】
通知リスト１０２は、イベントに対して通知操作が実行されたときに待機しているスレッドの実行再開状況を記録する。通知リスト１０２は、少なくとも１つの通知ブロックから構成される。通知ブロックは、初期化処理によって１つ生成され、その後各イベント通知が行われるごとに１つずつ生成されて通知リスト１０２に追加される。通知ブロックは、イベントで待機した後に実行を再開していない待機スレッド数、イベント通知が受け付けられた通知時刻、より古いイベント通知記録を保持する次の通知ブロックのアドレスを保持する。
【００２５】
通知リスト１０２の先頭の通知ブロック１０３は、その時点での当該イベントに関するスレッドの待機状況を示している。通知ブロック１０５も同様である。通知リスト１０２の先頭以降のブロック１０４は、当該イベントで待機していたがイベント通知により実行を再開するはずのスレッドの状況を示している。図１の例では、通知リスト１０２は、通知ブロック１０３と１０４で構成されている。通知ブロック１０４は、以前にイベント通知されたが実行を再開していないスレッドが２つあることを示している。また、通知ブロック１０３は、現時点でイベント待機しているスレッドが３つあることを示している。
【００２６】
次に、実施例１のイベント操作の処理手順について説明する。イベント処理部５１１は、イベント登録処理部１１１、イベント待機処理部１１２、イベント通知処理部１１３およびイベント監視処理部１１４から構成される。
【００２７】
イベント登録処理部１１１は、監視イベントテーブル１０１へのイベントオブジェクトの登録や削除を実施する。登録処理は、イベントオブジェクトの名称と待機スレッドが実行を再開するまでの許容時間を受けて、必要に応じて指定されたイベントオブジェクトをそのスレッドに割り当て、監視イベントテーブル１０１にイベント用のエントリを割り当て、そのエントリにイベントオブジェクトのアドレスと許容時間を記録する。そして、通知リスト１０２を初期化する。初期化処理は、通知リスト１０２の先頭として通知ブロック１０３を割り当てて、そのアドレスを監視イベントテーブル１０１の当該エントリの通知リスト先頭アドレスに記録する。
【００２８】
登録処理は、イベント連携遅延検出時の動作の登録も含む。この処理では、指定された異常時動作を示す識別子を、異常時処理モード１１０に記録する。
【００２９】
登録プログラム１２０は、システム起動時に実行して、設定ファイル５２０の内容に従って、監視対象イベントとイベント連携異常時の処理を示す識別子を登録する。設定ファイル５２０の例を図６に示す。設定ファイル５２０は、監視対象のイベント毎に、イベント名、イベント連携についての遅延の許容時間を指定する。また、設定ファイル５０２は、イベント連携の異常を検知したときの動作識別子（この例では“panic”）も指定している。
【００３０】
イベント待機処理部１１２とイベント通知処理部１１３は、ユーザプログラムが利用するイベント連携処理である。本実施形態では、ＯＳが基本的なイベント連携機能を提供しており、それにイベント連携監視のための処理を加える。これらの処理部は、監視イベントテーブル１０１を参照してイベント連携操作を記録する。各処理部の処理手順は、後述する。
【００３１】
イベント監視処理部１１４は、監視イベントテーブル１０１を参照して、イベント通知操作がなされたが許容時間を経過しても実行を再開していないスレッドが存在していないかを検査する。イベント監視処理部１１４は、ＯＳが一定周期で受け付けるタイマ割り込み処理の中で実行されるように、ＯＳ自身がＯＳ初期化処理時に監視周期を設定する。例えば、ＯＳは、イベント監視処理部１１４が１秒毎に実行されるように登録する。この周期は外部からも設定可能であってよい。イベント監視処理部１１４の処理手順は、後述する。
【００３２】
イベント監視処理部１１４が再開の遅れているスレッドを見つけた場合は、異常時処理モード１１０に設定された処理を実行する。この処理としては、例えば、ＯＳの異常終了、通信制御部５０４を介する他の計算機への異常通知、主記憶装置５０２内への異常発生の記録、等が可能である。ここで可能な処理は、この記載の限りではない。
【００３３】
ＯＳは、ユーザプログラムが利用可能なＯＳインターフェイス１１５を提供する。インターフェイス１１５は、イベント待機と通知処理、及び、監視設定を登録するインターフェイスを含む。登録プログラム１２０、プログラム１２１、プログラム１２２は、インターフェイス１１５を介して、ＯＳのイベント待機、通知、登録処理を実行する。
【００３４】
次に、ＯＳのイベント処理手順について説明する。ここでは、プログラム１２１が、あるイベントについてイベント通知を待機し、プログラム１２２がそのイベントへの通知を行うものとして説明する。
【００３５】
図２は、実施例１のイベント待機処理手順である。プログラム１２１がＯＳのイベント待機処理を呼び出すと、イベント待機処理部１１２はステップ２０１からの処理を実行する。まず、イベント待機処理部１１２は、監視イベントテーブル１０１を参照して、対象のイベントが監視対象か否かを判定する（ステップ２０１）。監視対象でないならば、イベント待機を要求した当該スレッドをイベント待機状態とする（ステップ２１１）。この処理は、対象イベントオブジェクトに当該スレッドの識別子を登録し、スレッド状態をイベント待ち状態とし、スレッドのスケジュール処理を実行する。これは、一般的なＯＳのイベント待機処理と同等の処理である。イベントに対する通知操作が実行されるとスレッドは実行を再開し、プログラム１２１の処理に復帰する。
【００３６】
対象イベントが監視対象である場合は、イベント待機処理部１１２は、当該イベントへの操作を禁止する（ステップ２０２）。これは、当該イベントのロックの獲得等によって実現される。次に、当該イベントの通知リスト１０２の先頭の通知ブロックの待機スレッド数に１を加えて、待ちスレッドがあることを登録する（ステップ２０３）。
【００３７】
その後、スレッド待ちを記録した通知ブロックのアドレスを当該スレッドのメモリ領域に記録して（ステップ２０４）、当該スレッドをイベント待機状態とする（ステップ２０５）。通知ブロックのアドレスは、実行しているスレッドのスタック等を格納するメモリ領域に記録すればよい。ステップ２０３と２０４の処理は、当該スレッドと対応づけて待機を示す情報を記録する処理であれば、他の方法を用いてもよい。ステップ２０５の処理は、ステップ２１１と同様の処理である。本実施形態では、イベント待機を要求した当該スレッドの実行はステップ２０５とステップ２０６の間で待ち状態にあるものとする。
【００３８】
ステップ２０６以降の処理は、別の処理が当該イベントに対してイベント通知処理を実行し、待機しているスレッドが実行を再開するときの処理である。
【００３９】
イベント通知処理で詳細説明するが、プログラム１２２がイベントに通知処理を実行すると、通知リスト１０２の先頭に新しい通知ブロックが挿入される。以降の説明では、ステップ２０４でそのアドレスを記録した通知ブロックは図１の通知ブロック１０４であるとして説明する。
【００４０】
当該スレッドが実行を再開すると、イベント待機処理部１１２は、まず、当該イベントに対する操作を禁止し（ステップ２０６）、そのアドレスを当該スレッドのメモリ領域に記録した通知ブロック１０４の待機スレッド数から１を減じる（ステップ２０７）。待機スレッド数が０になった場合（ステップ２０８ｙｅｓ）、その通知ブロックに関する待機スレッドがすべて実行を再開したことを意味する。この場合、イベント待機処理部１１２は、当該通知ブロック１０４を通知リスト１０２から削除する（ステップ２０９）。ステップ２０８，２０９の処理は、ステップ２０３，２０４で記録した対応するスレッドの待機記録を消し込む処理であればよい。
【００４１】
最後に、当該イベントへの操作禁止を解除して（ステップ２１０）、プログラム１２１の処理に復帰する。
【００４２】
次に、イベント通知の処理手順を説明する。図３は、実施例１のイベント通知処理の手順である。プログラム１２２がイベント通知処理を呼び出すと、イベント通知処理部１１３はステップ３０１からの処理を実行する。
【００４３】
まず、イベント通知処理部１１３は、監視イベントテーブル１０１を参照して、対象イベントが監視対象か否かを判定する（ステップ３０１）。監視の対象でないならば、イベント通知処理部１１３は、通常のイベント通知操作を実行する。すなわち、イベントで待機しているスレッドの状態を走行可能に設定し、イベントオブジェクトから待機スレッドの識別子を削除し、スケジューリング要求を登録し（ステップ３０８）、終了する。イベント通知処理部１１３は、プログラム１２２に復帰する過程でスケジューリング要求を検査し、スレッドのスケジュール処理を実行し、待機していたスレッドが走行を再開することとなる。
【００４４】
イベントが監視対象である場合、イベント通知処理部１１３は、まず、対象イベントに対する操作を禁止する（ステップ３０２）。そして、通知リスト１０２の先頭の通知ブロックの待機スレッド数を参照して、スレッドが待機しているか否かを判定する（ステップ３０３）。待機していない場合は、ステップ３０７に進み、イベント通知処理を完了する。
【００４５】
待機しているスレッドがある場合、イベント通知処理部１１３は、通知リスト１０２の先頭の通知ブロックの通知時刻に、現在の時刻を記録する（ステップ３０４）。次に、イベント通知処理部１１３は、以降のイベント通知処理に備えて、通知リスト１０２の先頭に新しく割り当てた通知ブロックを挿入する（ステップ３０５）。この先頭の通知ブロックの「待機スレッド数」には、０が設定される。ステップ２０９を実行したとき、その通知リスト１０２の先頭の通知ブロックは、次のイベント待機と通知を記録するための空きブロックとなっている。図１の通知リスト１０２は、通知ブロック１０３を挿入後のデータ構造を示している。ステップ３０４で通知時刻を記録した通知ブロックは、通知ブロック１０４になっている。
【００４６】
続いて、イベント通知処理部１１３は、待機しているスレッドを走行可能としてスケジューリングを要求し（ステップ３０６）、イベント操作禁止を解除し（ステップ３０７）、プログラム１２２の処理に復帰する。
【００４７】
以上の処理により、通知リスト１０２は、次のイベント通知操作を記録する通知ブロック１０３と、過去の通知操作に対するスレッド待機状況を記録した通知ブロック１０４からなるリストとなる。イベントで待機しているスレッドが正常にスケジュールされて実行を再開すれば、ステップ２０６からの処理によって、待機状況を記録している通知ブロック１０４は通知リスト１０２から削除される。しかし、待機しているスレッドが走行を再開しない場合、通知ブロック１０４はリストに残り続ける。
【００４８】
図４は、イベント監視処理部１１４の処理手順を示す。この手順は、監視イベントテーブル１０１および通知リスト１０２を検査して、実行の再開が遅延しているスレッドを検知する。以下に、この処理手順を説明する。
【００４９】
図４に示した処理は、監視イベントテーブル１０１に登録されているすべてのイベントについて実行する。ステップ４０１では、イベント監視処理部１１４は、処理対象イベントを選択する。監視イベントテーブル１０１のイベントをすべて処理したとき、処理を終了する。
【００５０】
次に、イベント監視処理部１１４は、処理対象のイベントの通知リスト１０２を取得し（ステップ４０２）、リストに含まれるそれぞれのイベント通知ブロックを処理する。ステップ４０３では、リスト中のすべての通知ブロックを処理したか否かを判定し、残りの通知ブロックがあればその１つを選択する。すべての通知ブロックを処理したとき、ステップ４０１に戻り処理を繰り返す。
【００５１】
イベント監視処理部１１４は、選択した通知ブロックについて、以下の処理を実行する。まず、通知ブロックが通知リストの先頭である場合、ステップ４０３に戻り、次の通知ブロックを選択する。通知リストの先頭は、次のイベント通知を記録するための空きブロックであるためである。
【００５２】
通知ブロックがイベント通知されていてその待機スレッド数が０でない場合には、イベント監視処理部１１４は、現在時刻が通知ブロックに記載の通知時刻に監視イベントテーブル１０１に記載の許容時間を加えた時刻を過ぎているか否か検査する（ステップ４０５）。過ぎていない場合、つまり、待機スレッド数が０か、あるいはイベント通知されてからまだ設定されている許容時間を経過していない場合は、ステップ４０３に戻り、次の通知ブロックを選択する。
【００５３】
イベント通知されてから許容時間が経過している場合は、ＯＳは、異常時処理モード１１０で指定される処理を実行する（ステップ４０６）。この処理が終了して復帰した場合は、他のイベントを検査するためにステップ４０１に戻る。
【００５４】
実施例１の代替方式として、例えばスレッドから待機要求を受けるごとに時系列にそのスレッド識別子をテーブルに記録し、イベント通知があるごとにその通知時刻を時系列に記録されたスレッド識別子をテーブルに記録し、イベント通知があるごとにその通知時刻を時系列に記録されたスレッド識別子に対応づけて記録し、各スレッドが実行再開されるごとにスレッド識別子と対応する通知時刻を記録から削除する方式でもよい。イベント監視処理部１１４は、現在時刻が残っている通知時刻より所定の許容時間以上過ぎているか否か判定する。
【００５５】
以上のイベント通知と待機処理およびイベント監視処理により、イベント連係操作を介して実行されるプログラムの連係動作の遅延を検知することが可能となる。
【００５６】
実施例１では、ステップ４０１からのイベント監視処理をタイマ割り込み処理の中で実行するため、計算機５００内で優先度の高い処理が不正にＣＰＵを占有した場合でも、イベント連携の遅延を迅速に検知できる。加えて、異常の検知時に異常処理を実行することができるため、イベント連携の異常に対して迅速な対処が可能となる。
【００５７】
実施例１は、特に、汎用のＯＳを用いたシステムを構成する場合に有効である。すなわち、汎用ＯＳでは、利用者が制御できない処理が走行するため、これによるイベント連携の遅延の可能性が避けられない。本発明によれば、この遅延を検知することができ、それに対応するための処理の実行も可能となる。
【００５８】
なお、実施例１においては、監視イベントテーブル１０１と通知リスト１０２のデータ構造をＯＳのイベントオブジェクトとは別に設けたが、これらは、イベントオブジェクトに統合されていても良い。例えば、イベントオブジェクトに、監視対象であるかを示すフラグ、遅延許容時間、通知リストのアドレスといったデータを含めることによって、同等の処理が実現可能である。
【００５９】
また、実施例１においては、イベント監視処理部１１４をタイマ割り込みの処理内で実行するとしたが、通常のプログラムで実行しても良い。この場合には、イベント監視管理データ１００がそのプログラムから参照可能なように設定されている必要がある。また、そのプログラムの優先度を高くしておく、そのプログラムの実行をウォッチドッグタイマで監視する、といったことをしても良い。
【実施例２】
【００６０】
次に、実施例２について説明する。実施例１では、汎用のＯＳインタフェイスを利用し、イベント処理部５１１の中で監視対象のイベントとそうでないイベントに対する操作を分けていた。しかしイベント監視のために別のＯＳインターフェイスを設けても良い。実施例２では、監視対象イベントに関するＯＳインターフェイス１１５を、汎用のイベント操作インターフェイスとは別に専用的に設ける方法を示す。
【００６１】
ここでは、デバイスドライバによって新しいイベント操作インターフェイスを導入する構成を示す。図７が、実施例２の構成を示す図である。
【００６２】
実施例２においては、連携遅延監視を行うイベントに関する待機処理は、図２のステップ２０２からの処理、通知処理は図３のステップ３０２からの処理となる。これらの処理部は、デバイスドライバ内に実装される。但し、ステップ２１１およびステップ３０８の処理はＯＳ標準のイベント処理であって、デバイスドライバから呼び出し可能であるとする。
【００６３】
プログラム１２１，１２２は、新しく導入したデバイスドライバへの指示によって、イベント待機と通知処理を実行する。通常、ＯＳインターフェイス１１５は、デバイスドライバに対して指示を発行するためのインターフェイスを含んでおり、プログラムはそれを用いて、イベント操作を実行できる。
【００６４】
以上のように実施例２により、既存の汎用ＯＳのイベント連携方法を用いて、連携遅延の検知が可能なイベント連携処理を実現できる。
【実施例３】
【００６５】
次に、実施例３について説明する。実施例３は、実施例１または実施例２を適用するクラスタ構成の計算機システムを特徴とする。
【００６６】
クラスタ構成の計算機システムは、主系と従系となる２台の計算機で構成される。主系である計算機が実際の処理を行い、従系である計算機は主系での障害発生に備えて待機している。従系は、主系の障害発生を検知すると主系として実行するように切り替わる。これを系切り替えと呼ぶ。クラスタ構成によれば、計算機に障害が発生してもシステム全体としての処理を継続することができる。
【００６７】
クラスタ構成の計算機システムにおける課題の１つは、迅速に主系の障害を検知することである。本発明は、この障害検知方法の１つとして用いることができる。以下に、図面を用いて説明する。
【００６８】
図８は、実施例３のクラスタ構成の計算機システムの構成例と、クラスタ制御手順を示す。計算機８００と計算機８１０の２台の計算機が、通信制御部８０２と８１２を介して接続し、クラスタを構成する。クラスタ制御部８１１は、通信制御部を介してクラスタ制御部８０１と周期的に通信し、計算機８００が正常に動作しているか否かを常に検知する。また、各計算機で実行するＯＳは、本実施形態のイベント処理部５１１とイベント監視管理データ１００を保持している。各計算機で実行するプログラムは、実施例１，２のイベント待機と通知処理により連係動作を実行する。図には示していないが、登録プログラム１２０が指定されたイベントを監視対象としてＯＳに登録し、また、連携遅延検知時の動作をＯＳの異常終了として設定する。
【００６９】
例えば、計算機８００が主系として実行しているとして、処理の流れを説明する。８５０はその処理フローを示す図である。
【００７０】
計算機８００上のプログラム８０３と８０４は、イベントによって連携して処理を実行している（ステップ８５１）。連携するイベントは任意のものでよい。ここで、何らかの原因により、イベントによる連携に遅延が発生したとする（ステップ８５２）。イベント監視処理部１１４は、ステップ４０１からの処理によってイベント連携の遅延を検知し、ＯＳを異常終了する（ステップ８５３）。ここでＯＳ異常終了の意味は、計算機８００がシステムとして異常終了したことと同意である。
【００７１】
待機系の計算機８１０のクラスタ制御部８１１は、計算機８００からの通信が途絶えたことを検知して、主系であった計算機８００が停止したと判定し（ステップ８５４）、計算機８１０を主系として実行するように設定し（ステップ８５５）、対応するプログラムをイベント連携により実行する（ステップ８５６）。
【００７２】
以上により、本発明によるイベント連携の遅延の検知と、クラスタの系切り替え制御を連携できる。これによって、クラスタの系切り替えの要因とする異常の種類を追加でき、更に、イベント連携の遅延という異常を迅速にシステム構成の変更に反映できる。
【００７３】
以上実施例３の説明では、連携の遅延の検知時にＯＳを異常終了するとしたが、その代わりに通信制御部を介して相手系に異常を通知してもよい。この場合、更に、迅速な異常の検知が可能となる。
【実施例４】
【００７４】
実施例４は、プログラムが実行を起動するする入出力（Ｉ／Ｏ）操作からの復帰の遅延を検知する制御手順を示す。実施例４は、実施例１あるいは実施例２を利用して構成される。
【００７５】
ネットワーク受信やディスク読み取りなど、時間がかかることが予想されるＩ／Ｏ操作を、プログラムの実行とは非同期に実行できるＯＳがある。このようなＯＳの中には、非同期に実行したＩ／Ｏ操作の完了を、プログラムが割り当てたイベントへの通知操作によってプログラムに通知できるものがある。
【００７６】
このようなＯＳに本発明を適用することにより、Ｉ／Ｏ操作が完了しているにも関わらず、Ｉ／Ｏの完了を待機しているプログラムの再開が遅延する障害を検知可能となる。図９に、実施例４のプログラムおよびＯＳの処理手順を示す。
【００７７】
まず、プログラムは、Ｉ／Ｏ処理完了をＯＳに通知してもらうためのイベントを割り当て（ステップ９０１）、監視対象として登録する（ステップ９０２）。そして、プログラムは、このイベントをＩ／Ｏ完了時の通知イベントに指定して、ＯＳに非同期でＩ／Ｏ操作を実行するように要求する（ステップ９０３）。
【００７８】
ＯＳは、Ｉ／Ｏ操作要求を受けて、指示されたＩ／Ｏ操作を開始する（ステップ９０４）。ＯＳは、非同期にＩ／Ｏ操作を実行するよう指示されているので、Ｉ／Ｏ操作を開始してプログラムに制御を戻す。プログラムは、Ｉ／Ｏ操作の完了を割り当てたイベントで待機する（ステップ９０５）。このイベント待機処理は、実施例１又は２のイベント待機処理とする。
【００７９】
ＯＳは、非同期に実行しているＩ／Ｏ操作が完了すると、Ｉ／Ｏ操作開始時に指定されたイベントに対して通知操作を実行し、プログラムにＩ／Ｏ完了を通知する（ステップ９０６）。このイベント通知処理は、実施例１又は２のイベント通知処理とする。
【００８０】
その後、ＯＳのスケジューラによってイベント待機しているプログラムの実行が再開し（ステップ９０７）、プログラムは処理を継続する。
【００８１】
Ｉ／Ｏが完了してＯＳがイベント通知操作を実行したがプログラムの実行が再開されない場合、イベント監視処理部１１４が遅延を検知し、異常処理を実行することができる。
【００８２】
以上により、本発明によれば、Ｉ／Ｏ操作が完了し走行可能となっているにも関わらず、何らかの原因で実行の再開が遅延しているプログラムを検知できる。
【図面の簡単な説明】
【００８３】
【図１】実施例１のデータ構造と処理モジュールの構成を示す図である。
【図２】実施例１のイベント待機処理手順を示す図である。
【図３】実施例１のイベント通知処理手順を示す図である。
【図４】実施例１の実行再開が遅延しているスレッドを検出する手順を示す図である。
【図５】実施例１の計算機の構成を示す図である。
【図６】設定ファイルの内容例を示す図である。
【図７】実施例２の構成を示す図である。
【図８】実施例３のクラスタ構成の計算機システムの構成および制御手順を示す図である。
【図９】実施例４の処理手順を示す図である。
【符号の説明】
【００８４】
１０１…監視イベントテーブル、１０２…通知リスト、１０３ないし１０５…通知ブロック、１１１…イベント登録処理部、１１２…イベント待機処理部、１１３…イベント通知処理部、１１４…イベント監視処理部、１１５…ＯＳインターフェイス、１２０…登録プログラム、１２１、１２２…プログラム
【図１】
2007072958.tif 000003
【図２】
2007072958.tif 000004
【図３】
2007072958.tif 000005
【図４】
2007072958.tif 000006
【図５】
2007072958.tif 000007
【図６】
2007072958.tif 000008
【図７】
2007072958.tif 000009
【図８】
2007072958.tif 000010
【図９】
2007072958.tif 000011