JP6536374B2 - 情報処理装置、情報処理方法及びプログラム - Google Patents

Description

本発明は、システムの監視技術に関する。

サーバやストレージ等の装置が複数存在する環境においては、これらの装置とは別に管理サーバを用意し、管理サーバにこれらの装置を一括で監視させることが一般的に行われる。管理サーバによる監視は、例えば、各装置の状態に関する情報等を一定の間隔で取得する処理を実行するための常駐型プログラムを管理サーバにインストールして、管理サーバに実行させることによって実現される。

ここで、管理サーバにインストールされた常駐型プログラムのスレッドが異常によって停止すると、装置の監視を行うことができなくなってしまう。そのため、このようなスレッドの異常（以下、スレッド異常と呼ぶ）を検出するための機構をシステム内に設けることも行われる。

スレッド異常を検出するための機構によって多くのリソースが使用されることは、他の処理が使用するリソースを不足させることになるため、又は、より多くのリソースをシステムに導入しなければならなくなるため、好ましくない。しかし、このような問題に着目した従来技術は存在しない。

特開２００８−３７７０号公報 特開２０００−９９４８０号公報

従って、本発明の目的は、１つの側面では、スレッド異常の検出に要するリソースの量を削減するための技術を提供することである。

本発明に係る情報処理方法は、プログラムの第１スレッドが動作中であり且つプログラムの第２スレッドが動作中ではない場合に、第１スレッドと第２スレッドとが共通に使用する記憶領域から読み出した識別子が第２スレッドの識別子であるか否かに基づき、第２スレッドに異常があるか否かの判定を行い、判定の後第１スレッドの処理が完了した場合に、記憶領域に格納されている識別子を第１スレッドの識別子で更新する処理を含む。

１つの側面では、スレッド異常の検出に要するリソースの量を削減できるようになる。

図１は、ウオッチドッグによる監視の一例を示す図である。 図２は、ウオッチドッグによる監視の一例を示す図である。 図３は、単一のスレッドによって装置の監視を行う例を示す図である。 図４は、二重化されたスレッドによって装置の監視を行う例を示す図である。 図５は、本実施の形態のシステム概要を示す図である。 図６は、メモリ領域に格納されるデータの一例を示す図である。 図７は、メインの処理フローを示す図である。 図８は、監視スレッドの実行時刻の設定について説明するための図である。 図９は、監視スレッドの処理の処理フローを示す図である。 図１０は、異常フラグについて説明するための図である。 図１１は、監視処理の処理フローを示す図である。 図１２は、メモリ領域に格納されるデータの一例を示す図である。 図１３は、管理サーバの動作の具体例を示す図である。 図１４は、管理サーバの動作の具体例を示す図である。 図１５は、管理サーバの動作の具体例を示す図である。 図１６は、管理サーバの動作の具体例を示す図である。 図１７は、二重化されたスレッドによって装置の監視を行うシステムにおいて行われる処理の処理フローを示す図である。 図１８は、コンピュータの機能ブロック図である。

管理サーバが常駐型プログラムを長時間実行している場合、管理サーバのハードウエアの障害や故障、或いはリソースの不足等によって常駐型プログラムが正常に動作しない場合がある。このような場合に備えるための技術としてウオッチドッグが知られている。

図１に、ウオッチドッグによる監視の一例を示す。図１においては、管理サーバが装置１ａ乃至３ａと定期的に通信を行い、装置１ａ乃至３ａの情報を取得する。また、管理サーバとは別にウオッチドッグサーバが設けられており、ウオッチドッグサーバにおけるウオッチドッグ部が管理サーバに対して問い合わせを行う。管理サーバにおける常駐型プログラム（以下、単にプログラムと呼ぶ）は、プログラムのスレッドに異常が無い場合には正常であることを示す応答を返すが、プログラムのスレッドが異常である場合にはスレッド異常が発生したことを示す応答を返すか又は応答自体を返すことができない。これによってウオッチドッグサーバのウオッチドッグ部はスレッド異常を検出することができる。

しかし、この方法はウオッチドッグ部として動作させるプログラムを別途用意しなければ実現することができない。また、図２に示すように、例えばスレッドの時刻調整処理が失敗した場合或いはメモリ不足により処理を実行できない場合等、スレッド異常が発生している環境においてプログラムがスレッド異常を検出できない場合には、正常であることを示す応答がウオッチドッグサーバに送信される。従って、ウオッチドッグサーバのウオッチドッグ部はスレッド異常を検出することができない。

別の方法として、プログラム内部のスレッドを二重で起動し、起動した２つのスレッドに同時並行で処理を実行させ、両スレッドの処理結果を比較することでスレッド異常を検出する方法が考えられる。しかし、この方法には、使用するリソースの量が増えるという問題と、プログラムの潜在的なバグにより両方のスレッドで同じ障害が同時に発生することがあるという問題とが有る。

例えば図３に示すように、単一のスレッドによって装置１ａの監視を実行する場合、監視の実行結果を保存する１つのメモリ領域（ここではメモリ領域１ｍ）を用意すればよい。また、ネットワークを介して管理サーバと監視対象の装置とが通信を行う場合においても、ネットワークリソース（例えば帯域）が１スレッド分だけ消費される。

一方、図４に示すように２つのスレッドによって装置１ａの監視を実行する場合、監視の実行結果を保存する２つのメモリ領域（ここではメモリ領域１ｍ及び２ｍ）を用意することになる。また、ネットワークリソースは２スレッド分消費される。さらに、装置１ａは２つのスレッドからアクセスされるため処理負荷が倍になる。なお、ここでは管理サーバ及び装置１ａに２つのＣＰＵが存在するが、必ずしも物理的に分離された２つのＣＰＵである必要は無い。

また、管理サーバ及び装置１ａそれぞれのプロトコルに有効なセッション数が設定されている場合が有り、たとえ二重でスレッドを実行する場合であっても使用できるセッション数の関係で片方のスレッドしか通信をすることができない場合がある。この場合、冗長構成を実現することはできない。

また、特定の条件（例えば時刻或いはタイミング）でスレッドが終了するバグ又はスレッド内部の処理が無限ループに陥るバグが含まれている場合、両方のスレッドで同じ障害が発生する。このようなバグとしては、例えば、閏秒の時刻でプログラム内の時刻調整処理が失敗してスレッドを実行できなくなるバグや負荷が過剰である場合にメモリ不足によってスレッドを実行できないバグが有る。

そこで、以下では、プログラムが上記のようなバグを含む場合においてもスレッド異常を検出できるようにしつつ、且つ、スレッド異常の検出をスレッドの二重動作時より少ないリソースで実現する方法を説明する。

図５に、本実施の形態のシステム概要を示す。本実施の形態の主要な処理を実行する管理サーバ１は、例えばＬＡＮ（Local Area Network）であるネットワーク３を介して監視対象である装置１ａ乃至３ａと接続される。管理サーバ１は、ネットワーク３を介して装置１ａ乃至３ａの状態に関する情報等を収集し、装置１ａ乃至３ａを監視する。なお、図５において装置の数は３であるが、数に限定は無い。

管理サーバ１は、時刻管理部１１と、起動制御部１２と、異常処理部１３と、例えばメインメモリの領域であるメモリ領域１４と、初期化処理部１５と、監視スレッド１ｔ及び２ｔとを含む。

時刻管理部１１は、監視スレッド１ｔ及び２ｔを実行する時刻を管理する。起動制御部１２は、監視スレッド１ｔ及び２ｔの起動を制御する。監視スレッド１ｔ及び２ｔは、メモリ領域１４に格納されたデータに基づきスレッド異常が発生したか判定する処理を実行し、スレッド異常が発生した場合には異常処理部１３に通知を行う。異常処理部１３は、スレッド異常が検出された場合に管理者に通知を行う（例えばメールを送信する）処理及び異常が発生した監視スレッドの再起動等を実行する。初期化処理部１５は、後述する初期化処理を実行する。

図６に、メモリ領域１４に格納されるデータの一例を示す。図６の例では、装置の識別情報と、取得処理の実行結果（例えば、装置から取得された情報等）と、監視スレッドの識別情報であるスレッドＩＤ（IDentification information）とが格納される。本データは、監視スレッド１ｔ及び２ｔによって更新される。メモリ領域１４は、監視スレッド１ｔ及び２ｔに共通で使用される。

次に、図７乃至図１２を用いて、管理サーバ１が実行する処理を説明する。本処理は、例えば管理サーバ１の起動後に実行される。

まず、初期化処理部１５は、監視スレッド１ｔ及び２ｔの実行時刻を設定する（図７：ステップＳ１）。実行時刻は、例えば図８に示すように、監視スレッド１ｔの処理及び監視スレッド２ｔの処理が交互に実行されるように制御される。例えば、監視スレッド１ｔの実行時刻は１９時００分、１９時２０分、１９時４０分・・・・で且つ監視スレッド２ｔの実行時刻は１９時１０分、１９時３０分、１９時５０分・・・・のように設定される。なお、各監視スレッドは処理の実行後にスリープ状態に移行する。

初期化処理部１５は、監視スレッド１ｔ及び２ｔのスレッドＩＤを生成し（ステップＳ３）、メモリ領域１４を初期化する（ステップＳ５）。本実施の形態においては、監視スレッド１ｔに対してスレッドＩＤ「０１」が生成され、監視スレッド２ｔに対してスレッドＩＤ「０２」が生成されるとする。

初期化処理部１５は、監視スレッド１ｔ及び２ｔを生成する（ステップＳ７）。具体的には、初期化処理部１５は起動制御部１２に監視スレッド１ｔ及び２ｔを起動させる処理を実行する。但し、ステップＳ７の時点においては監視スレッド１ｔ及び２ｔはスリープ状態であり、処理の実行指令が出力されるまで処理は実行されない。そして、初期化処理部１５は、監視スレッド１ｔ及び２ｔを生成したことを時刻管理部１１に通知する。

時刻管理部１１は、例えばＯＳ（Operating System）のシステム時計等が示す時刻を監視する（ステップＳ９）。そして、監視スレッド１ｔの実行時刻になった場合、時刻管理部１１は、監視スレッド１ｔの処理の実行指令を出力する（ステップＳ１１）。これに応じ、管理サーバ１は監視スレッド１ｔの処理を実行する（ステップＳ１３）。監視スレッド１ｔの処理が完了した後、監視スレッド１ｔはスリープ状態に移行する。スリープ状態の間は、リソースは全く消費されないか又は消費されたとしてもごくわずかである。

時刻管理部１１は、例えばＯＳのシステム時計等が示す時刻を監視する（ステップＳ１５）。そして、監視スレッド２ｔの実行時刻になった場合、時刻管理部１１は、監視スレッド２ｔの処理の実行指令を出力する（ステップＳ１７）。これに応じ、管理サーバ１は監視スレッド２ｔの処理を実行する（ステップＳ１９）。監視スレッド２ｔの処理が完了した後、監視スレッド２ｔはスリープ状態に移行する。

その後は、ステップＳ９乃至Ｓ１９の処理が繰り返される。これにより、監視スレッド１ｔの処理と監視スレッド２ｔの処理とが交互に行われるようになる。なお、監視スレッド１ｔの処理に要する時間及び監視スレッド２ｔの処理に要する時間は、実行指令が出力される間隔よりも短いものとする。すなわち、或る監視スレッドの処理が完了する前に他方の監視スレッドの処理が開始することはないものとする。

以上のように、本実施の形態においては、監視スレッド１ｔと監視スレッド２ｔとが同時並行で処理を実行することはないので、使用されるリソース（例えば、メモリリソース及びネットワークリソース）の量を減らすことができるようになる。また、監視の際に生成されるセッションの数を増加させることがない。さらに、監視対象である装置１ａ乃至３ａは、２つのスレッドから同時にアクセスされることがないので、処理負荷の増大が抑制される。

ここで、図９乃至図１２を用いて、監視スレッド１ｔの処理及び監視スレッド２ｔの処理について説明する。但し、両者は全く同じ処理であるので、ここでは監視スレッド１ｔの処理を例にして説明をする。

まず、監視スレッド１ｔは、異常フラグを「ＯＦＦ」に設定する（図９：ステップＳ２１）。管理サーバ１は、例えば図１０に示すような異常フラグをメモリ領域１４において管理しているとする。異常フラグが「ＯＮ」に設定されている場合にはスレッド異常が発生しており、異常フラグが「ＯＦＦ」に設定されている場合にはスレッド異常が発生していない。

監視スレッド１ｔは、未処理の装置を１台特定し（ステップＳ２３）、特定された装置について監視処理を実行する（ステップＳ２５）。監視処理については、図１１を用いて説明する。

まず、監視スレッド１ｔは、ステップＳ２３において特定された装置（以下では、対象装置と呼ぶ）の識別情報に関連付けられたスレッドＩＤをメモリ領域１４から読み出す（図１１：ステップＳ４１）。

監視スレッド１ｔは、読み出されたスレッドＩＤは他スレッド（ここでは、監視スレッド２ｔ）のスレッドＩＤであるか判定する（ステップＳ４３）。読み出されたスレッドＩＤが監視スレッド２ｔのスレッドＩＤではない場合（ステップＳ４３：Ｎｏルート）、監視スレッド２ｔの処理が適切に行われておらず、監視スレッド２ｔに異常が発生したと推定される。従って、監視スレッド１ｔは、異常フラグを「ＯＮ」に設定する（ステップＳ４５）。そしてステップＳ４７の処理に移行する。

一方、読み出されたスレッドＩＤが監視スレッド２ｔのスレッドＩＤである場合（ステップＳ４３：Ｙｅｓルート）、監視スレッド１ｔは、リトライ回数を表す変数ｒｅｔｒｙ＿ｃｏｕｎｔをｒｅｔｒｙ＿ｃｏｕｎｔ＝０と設定する（ステップＳ４７）。

監視スレッド１ｔは、取得処理を実行する（ステップＳ５１）。取得処理とは、対象装置の状態に関する情報等を対象装置から取得する処理である。

監視スレッド１ｔは、情報の取得に成功したか判定する（ステップＳ５３）。情報の取得に成功した場合（ステップＳ５３：Ｙｅｓルート）、監視スレッド１ｔは、メモリ領域１４に、対象装置についての取得処理の実行結果と監視スレッド１ｔのスレッドＩＤとを書き込む（ステップＳ５５）。そして呼び出し元の処理に戻る。例えば、図６に示したようなデータがメモリ領域１４に格納されている場合において、各スレッドＩＤが「０２」から「０１」に変更された場合、図１２に示すようなデータがメモリ領域１４に格納される。

一方、情報の取得に成功しなかった場合（ステップＳ５３：Ｎｏルート）、監視スレッド１ｔは、ｒｅｔｒｙ＿ｃｏｕｎｔ≦閾値（例えば５）が成立するか判定する（ステップＳ５７）。ｒｅｔｒｙ＿ｃｏｕｎｔ≦閾値が成立する場合（ステップＳ５７：Ｙｅｓルート）、リトライを継続すべきであるので、ｒｅｔｒｙ＿ｃｏｕｎｔを１インクリメントし（ステップＳ５９）、ステップＳ５１の処理に戻る。一方、ｒｅｔｒｙ＿ｃｏｕｎｔ≦閾値が成立しない場合（ステップＳ５７：Ｎｏルート）、監視スレッド１ｔは、メモリ領域１４に、対象装置についての取得処理が失敗したことを示す情報と監視スレッド１ｔのスレッドＩＤとを書き込む（ステップＳ６１）。そして呼び出し元の処理に戻る。スレッドＩＤは、監視スレッド１ｔである場合には「０１」であり、監視スレッド２ｔである場合には「０２」である。

スレッド異常が発生し監視スレッドによる情報取得が実行されない場合には、監視スレッド２ｔのスレッドＩＤは格納されない。従って、他方の監視スレッドのスレッドＩＤがメモリ領域１４に格納されているか否かに基づいて、スレッド異常を検出することができる。

図９の説明に戻り、監視スレッド１ｔは、未処理の装置が有るか判断する（ステップＳ２７）。未処理の装置が有る場合（ステップＳ２７：Ｙｅｓルート）、ステップＳ２３の処理に戻る。

一方、未処理の装置が無い場合（ステップＳ２７：Ｎｏルート）、監視スレッド１ｔは、異常フラグが「ＯＮ」であるか判断する（ステップＳ２９）。異常フラグが「ＯＮ」ではない場合（ステップＳ２９：Ｎｏルート）、監視スレッド１ｔはスリープ状態に移行する（ステップＳ３３）。そして処理は終了する。

一方、異常フラグが「ＯＮ」である場合（ステップＳ２９：Ｙｅｓルート）、監視スレッド１ｔは、スレッド異常が発生したことを異常処理部１３に通知する（ステップＳ３１）。そして処理は終了する。

なお、監視スレッド１ｔから通知を受けた異常処理部１３は、スレッド異常が検出された場合に管理者に通知を行う。これに応じ、管理者はＧＵＩ（Graphical User Interface）によって監視スレッドの異常を確認する。また、異常処理部１３は、異常が発生した監視スレッドの再起動等を、例えば初期化処理部１５によって決定された実行時刻に実行する。

以上のような処理を実行すれば、監視スレッド１ｔと監視スレッド２ｔとが同時並行で処理を実行しない場合であっても、監視スレッドの異常を漏れなく検出できるようになる。また、特定の条件（例えば時刻或いはタイミング）でスレッドが終了するバグ又はスレッド内部の処理が無限ループに陥るバグが含まれている場合であっても、監視スレッドによる監視が停止することがない。

次に、図１３乃至図１６のシーケンス図を用いて、管理サーバ１の動作の具体例を説明する。まず、正常時における管理サーバ１の動作を説明する。

１９時００分になると監視スレッド１ｔは起動され、監視スレッド１ｔは異常フラグを「ＯＦＦ」に設定する（図１３：ステップＳ１０１）。

監視スレッド１ｔは、装置１ａの識別情報に対応付けられたスレッドＩＤを確認する（ステップＳ１０３）。スレッドＩＤが「０２」であれば監視スレッド２ｔに異常は発生していない。ここでは、スレッドＩＤが「０２」であるので監視スレッド２ｔに異常は発生しておらず、監視スレッド１ｔは装置１ａの状態に関する情報等を取得する（ステップＳ１０５）。情報の取得に成功した場合、監視スレッド１ｔは、メモリ領域１４に、装置１ａについての取得処理の実行結果とスレッドＩＤ「０１」とを書き込む（ステップＳ１０７）。これにより、「０２」から「０１」へスレッドＩＤが変更される。

監視スレッド１ｔは、装置２ａの識別情報に対応付けられたスレッドＩＤを確認する（ステップＳ１０９）。スレッドＩＤが「０２」であれば監視スレッド２ｔに異常は発生していない。ここでは、スレッドＩＤが「０２」であるので監視スレッド２ｔに異常は発生しておらず、監視スレッド１ｔは装置２ａの状態に関する情報等を取得する（ステップＳ１１１）。情報の取得に成功した場合、監視スレッド１ｔは、メモリ領域１４に、装置２ａについての取得処理の実行結果とスレッドＩＤ「０１」とを書き込む（ステップＳ１１３）。これにより、「０２」から「０１」へスレッドＩＤが変更される。

監視スレッド１ｔは、装置３ａの識別情報に対応付けられたスレッドＩＤを確認する（ステップＳ１１５）。スレッドＩＤが「０２」であれば監視スレッド２ｔに異常は発生していない。ここでは、スレッドＩＤが「０２」であるので監視スレッド２ｔに異常は発生しておらず、監視スレッド１ｔは装置３ａの状態に関する情報等を取得する（ステップＳ１１７）。情報の取得に成功した場合、監視スレッド１ｔは、メモリ領域１４に、装置３ａについての取得処理の実行結果とスレッドＩＤ「０１」とを書き込む（ステップＳ１１９）。これにより、「０２」から「０１」へスレッドＩＤが変更される。

監視スレッド１ｔは異常フラグを確認するが、異常フラグは「ＯＦＦ」であるので、監視スレッド１ｔはスリープ状態に移行する（ステップＳ１２１）。

そして、１９時１０分になると監視スレッド２ｔは起動され、監視スレッド２ｔは、異常フラグを「ＯＦＦ」に設定する（図１４：ステップＳ１３１）。なお、既に異常フラグが「ＯＦＦ」であれば、本ステップは省略される。

監視スレッド２ｔは、装置１ａの識別情報に対応付けられたスレッドＩＤを確認する（ステップＳ１３３）。スレッドＩＤが「０１」であれば監視スレッド１ｔに異常は発生していない。ここでは、スレッドＩＤが「０１」であるので監視スレッド１ｔに異常は発生しておらず、監視スレッド２ｔは装置１ａの状態に関する情報等を取得する（ステップＳ１３５）。情報の取得に成功した場合、監視スレッド２ｔは、メモリ領域１４に、装置１ａについての取得処理の実行結果とスレッドＩＤ「０２」とを書き込む（ステップＳ１３７）。これにより、「０１」から「０２」へスレッドＩＤが変更される。

監視スレッド２ｔは、装置２ａの識別情報に対応付けられたスレッドＩＤを確認する（ステップＳ１３９）。スレッドＩＤが「０１」であれば監視スレッド１ｔに異常は発生していない。ここでは、スレッドＩＤが「０１」であるので監視スレッド１ｔに異常は発生しておらず、監視スレッド２ｔは装置２ａの状態に関する情報等を取得する（ステップＳ１４１）。情報の取得に成功した場合、監視スレッド２ｔは、メモリ領域１４に、装置２ａについての取得処理の実行結果とスレッドＩＤ「０２」とを書き込む（ステップＳ１４３）。これにより、「０１」から「０２」へスレッドＩＤが変更される。

監視スレッド２ｔは、装置３ａの識別情報に対応付けられたスレッドＩＤを確認する（ステップＳ１４５）。スレッドＩＤが「０１」であれば監視スレッド１ｔに異常は発生していない。ここでは、スレッドＩＤが「０１」であるので監視スレッド１ｔに異常は発生しておらず、監視スレッド２ｔは装置３ａの状態に関する情報等を取得する（ステップＳ１４７）。情報の取得に成功した場合、監視スレッド２ｔは、メモリ領域１４に、装置３ａについての取得処理の実行結果とスレッドＩＤ「０２」とを書き込む（ステップＳ１４９）。これにより、「０１」から「０２」へスレッドＩＤが変更される。

監視スレッド２ｔは異常フラグを確認するが、異常フラグは「ＯＦＦ」であるので、監視スレッド２ｔはスリープ状態に移行する（ステップＳ１５１）。

次に、スレッド異常発生時における管理サーバ１の動作を説明する。まず、１９時００分になると監視スレッド１ｔは起動され、監視スレッド１ｔは異常フラグを「ＯＦＦ」に設定する（図１５：ステップＳ１６１）。

監視スレッド１ｔは、装置１ａの識別情報に対応付けられたスレッドＩＤを確認する（ステップＳ１６３）。スレッドＩＤが「０２」であれば監視スレッド２ｔに異常は発生していない。ここでは、スレッドＩＤが「０２」であるので監視スレッド２ｔに異常は発生しておらず、監視スレッド１ｔは装置１ａの状態に関する情報等を取得する（ステップＳ１６５）。情報の取得に成功した場合、監視スレッド１ｔは、メモリ領域１４に、装置１ａについての取得処理の実行結果とスレッドＩＤ「０１」とを書き込む（ステップＳ１６７）。これにより、「０２」から「０１」へスレッドＩＤが変更される。

監視スレッド１ｔは、装置２ａの識別情報に対応付けられたスレッドＩＤを確認する（ステップＳ１６９）。スレッドＩＤが「０２」であれば監視スレッド２ｔに異常は発生していない。ここでは、スレッドＩＤが「０２」であるので監視スレッド２ｔに異常は発生しておらず、監視スレッド１ｔは装置２ａの状態に関する情報等を取得する（ステップＳ１７１）。情報の取得に成功した場合、監視スレッド１ｔは、メモリ領域１４に、装置２ａについての取得処理の実行結果とスレッドＩＤ「０１」とを書き込む（ステップＳ１７３）。これにより、「０２」から「０１」へスレッドＩＤが変更される。

ここで、スレッド異常の発生によって監視スレッド１ｔの処理が停止したとする。この場合、処理はステップＳ１７５に移行し、監視スレッド１ｔはスリープ状態に移行する（ステップＳ１７５）。従って、装置３ａについては取得処理が実行されず、スレッドＩＤは「０２」のままである。

そして、１９時１０分になると監視スレッド２ｔは起動され、監視スレッド２ｔは、異常フラグを「ＯＦＦ」に設定する（図１６：ステップＳ１８１）。なお、既に異常フラグが「ＯＦＦ」であれば、本ステップは省略される。

監視スレッド２ｔは、装置１ａの識別情報に対応付けられたスレッドＩＤを確認する（ステップＳ１８３）。スレッドＩＤが「０１」であれば監視スレッド１ｔに異常は発生していない。ここでは、スレッドＩＤが「０１」であるので監視スレッド１ｔに異常は発生しておらず、監視スレッド２ｔは装置１ａの状態に関する情報等を取得する（ステップＳ１８５）。情報の取得に成功した場合、監視スレッド２ｔは、メモリ領域１４に、装置１ａについての取得処理の実行結果とスレッドＩＤ「０２」とを書き込む（ステップＳ１８７）。これにより、「０１」から「０２」へスレッドＩＤが変更される。

監視スレッド２ｔは、装置２ａの識別情報に対応付けられたスレッドＩＤを確認する（ステップＳ１８９）。スレッドＩＤが「０１」であれば監視スレッド１ｔに異常は発生していない。ここでは、スレッドＩＤが「０１」であるので監視スレッド１ｔに異常は発生しておらず、監視スレッド２ｔは装置２ａの状態に関する情報等を取得する（ステップＳ１９１）。情報の取得に成功した場合、監視スレッド２ｔは、メモリ領域１４に、装置２ａについての取得処理の実行結果とスレッドＩＤ「０２」とを書き込む（ステップＳ１９３）。これにより、「０１」から「０２」へスレッドＩＤが変更される。

監視スレッド２ｔは、装置３ａの識別情報に対応付けられたスレッドＩＤを確認する（ステップＳ１９５）。スレッドＩＤが「０１」であれば監視スレッド１ｔに異常は発生していない。ここでは、スレッドＩＤが「０２」であるので監視スレッド１ｔに異常が発生したと判定され、監視スレッド２ｔは異常フラグを「ＯＮ」に設定する（ステップＳ１９７）。そして、監視スレッド２ｔは、装置３ａの状態に関する情報等を取得する（ステップＳ１９９）。情報の取得に成功した場合、監視スレッド２ｔは、メモリ領域１４に、装置３ａについての取得処理の実行結果とスレッドＩＤ「０２」とを書き込む（ステップＳ２００）。ここでは、スレッドＩＤは「０２」のままである。

監視スレッド２ｔは異常フラグを確認するが、異常フラグは「ＯＮ」であるので、監視スレッド２ｔは、異常処理部１３にスレッド異常が発生したことを通知する（ステップＳ２０２）。これに応じ、スレッド異常への対処（例えば、監視スレッド１ｔの再起動等）が実行される。

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明した管理サーバ１の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。

また、上で説明したデータ保持構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

［付録］
本付録では、図４に示した、二重化されたスレッドによって装置の監視を行うシステムの動作をより詳細に説明する。

まず、初期化処理部１５は、監視スレッド１ｔ及び２ｔの実行時刻を設定する（図１７：ステップＳ２０１）。監視スレッド１ｔ及び２ｔの実行時刻は、両監視スレッドが同時並行で処理を実行するように設定される。

初期化処理部１５は、異常処理部１３の実行時刻を設定する（ステップＳ２０３）。異常処理部１３の実行時刻は、監視スレッド１ｔ及び２ｔの処理の後に異常処理部１３の処理が実行されるように設定される。

初期化処理部１５は、監視スレッド１ｔ及び２ｔを生成する（ステップＳ２０５）。具体的には、初期化処理部１５は起動制御部１２に監視スレッド１ｔ及び２ｔを起動させる処理を実行する。但し、ステップＳ２０５の時点においては監視スレッド１ｔ及び２ｔはスリープ状態であり、処理の実行指令が出力されるまで処理は実行されない。そして、初期化処理部１５は、監視スレッド１ｔ及び２ｔを生成したことを時刻管理部１１に通知する。

時刻管理部１１は、例えばＯＳのシステム時計等が示す時刻を監視する（ステップＳ２０７）。そして、監視スレッド１ｔ及び２ｔの実行時刻になった場合、時刻管理部１１は、監視スレッド１ｔの処理の実行指令と監視スレッド２ｔの処理の実行指令とを出力する（ステップＳ２０９）。これに応じ、管理サーバ１は監視スレッド１ｔの処理と監視スレッド２ｔの処理とを実行する。監視スレッド１ｔの実行結果はメモリ領域１４におけるメモリ領域１ｍに格納され、監視スレッド２ｔの実行結果はメモリ領域１４におけるメモリ領域２ｍに格納される（ステップＳ２１１及びＳ２１３）。監視スレッド１ｔ及び２ｔは、処理が完了した後にスリープ状態に移行する（ステップＳ２１５及びＳ２１７）。

時刻管理部１１は、例えばＯＳのシステム時計等が示す時刻を監視する（ステップＳ２１９）。そして、異常処理部１３の実行時刻になった場合、時刻管理部１１は、異常処理部１３の処理の実行指令を出力する（ステップＳ２２１）。

これに応じ、異常処理部１３はメモリ領域１ｍ及び２ｍから取得処理の実行結果を読み出す（ステップＳ２２３）。

異常処理部１３は、メモリ領域１ｍから読み出した実行結果とメモリ領域２ｍから読み出した実行結果とに差異が有るか判定する（ステップＳ２２５）。差異が有る場合（ステップＳ２２５：Ｙｅｓルート）、スレッド異常が発生したことを管理者に通知する（ステップＳ２２７）。或いは、ステップＳ２２７において、異常処理部１３が異常に対処するための処理を実行してもよい。

一方、差異が無い場合（ステップＳ２２５：Ｎｏルート）、異常処理部１３はスリープ状態に移行する（ステップＳ２２９）。そして、ステップＳ２０７乃至Ｓ２２９の処理が繰り返される。

以上で付録を終了する。

なお、上で述べた管理サーバ１は、コンピュータ装置であって、図１８に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本発明の実施の形態をまとめると、以下のようになる。

本実施の形態の第１の態様に係る情報処理方法は、（Ａ）プログラムの第１スレッドが動作中であり且つプログラムの第２スレッドが動作中ではない場合に、第１スレッドと第２スレッドとが共通に使用する記憶領域から読み出した識別子が第２スレッドの識別子であるか否かに基づき、第２スレッドに異常があるか否かの判定を行い、（Ｂ）判定の後第１スレッドの処理が完了した場合に、記憶領域に格納されている識別子を第１スレッドの識別子で更新する処理を含む。

このようにすれば、たとえ第１スレッドと第２スレッドとが同時並行で動作していなくてもスレッドの異常を検出することができる。すなわち、スレッドの異常を検出することに要するリソースの量を削減することができるようになる。

また、本情報処理方法は、（Ｃ）記憶領域に格納されている識別子を第１スレッドの識別子に更新した後、第１スレッドをスリープ状態に移行する処理をさらに含んでもよい。これにより、第１スレッドによって消費されるリソース量を減らすことができるようになる。

また、本情報処理方法は、（Ｄ）第１スレッドがスリープ状態に移行した後、所定の時刻に第２スレッドのスリープ状態を解除し、第２スレッドの動作を開始する処理をさらに含んでもよい。これにより、第１スレッドの処理と第２スレッドの処理とが交互に実行されるようになる。

また、本情報処理方法は、（Ｅ）第２スレッドに異常があると判定された場合に、当該異常に対処するための処理を実行する処理をさらに含んでもよい。これにより、異常の拡大等を抑制できるようになる。

また、第１スレッドの処理は、複数の装置の動作を監視する処理であってもよい。

また、第２スレッドに異常があるか否かの判定を行う処理において、（ａ１）記憶領域から読み出した識別子が第２スレッドの識別子である場合、第２スレッドに異常が無いと決定し、記憶領域から読み出した識別子が第２スレッドの識別子ではない場合、第２スレッドに異常が有ると決定してもよい。

なお、上記方法による処理をプロセッサに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
プログラムであって、
前記プログラムの第１スレッドが動作中であり且つ前記プログラムの第２スレッドが動作中ではない場合に、前記第１スレッドと前記第２スレッドとが共通に使用する記憶領域から読み出した識別子が前記第２スレッドの識別子であるか否かに基づき、前記第２スレッドに異常があるか否かの判定を行い、
前記判定の後前記第１スレッドの処理が完了した場合に、前記記憶領域に格納されている識別子を前記第１スレッドの識別子で更新する、
処理をコンピュータに実行させるプログラム。

（付記２）
前記コンピュータに、
前記記憶領域に格納されている識別子を前記第１スレッドの識別子に更新した後、前記第１スレッドをスリープ状態に移行する、
処理をさらに実行させる付記１記載のプログラム。

（付記３）
前記コンピュータに、
前記第１スレッドがスリープ状態に移行した後、所定の時刻に前記第２スレッドのスリープ状態を解除し、前記第２スレッドの動作を開始する、
処理をさらに実行させる付記２記載のプログラム。

（付記４）
前記コンピュータに、
前記第２スレッドに異常があると判定された場合に、当該異常に対処するための処理を実行する、
処理をさらに実行させる付記１乃至３のいずれか１つ記載のプログラム。

（付記５）
前記第１スレッドの処理は、複数の装置の動作を監視する処理である、
付記１乃至４のいずれか１つ記載のプログラム。

（付記６）
前記第２スレッドに異常があるか判定する処理において、
前記記憶領域から読み出した識別子が前記第２スレッドの識別子である場合、前記第２スレッドに異常が無いと決定し、前記記憶領域から読み出した識別子が前記第２スレッドの識別子ではない場合、前記第２スレッドに異常が有ると決定する、
付記１乃至５のいずれか１つ記載のプログラム。

（付記７）
コンピュータが、
プログラムの第１スレッドが動作中であり且つ前記プログラムの第２スレッドが動作中ではない場合に、前記第１スレッドと前記第２スレッドとが共通に使用する記憶領域から読み出した識別子が、前記第２スレッドの識別子であるか否かに基づき、前記第２スレッドに異常があるか否かの判定を行い、
前記判定の後前記第１スレッドの処理が完了した場合に、前記記憶領域に格納されている識別子を前記第１スレッドの識別子で更新する、
処理を実行する情報処理方法。

（付記８）
複数のスレッドが共通で使用する記憶装置と、
プロセッサと、
を有し、
前記プロセッサが、
プログラムの第１スレッドが動作中であり且つ前記プログラムの第２スレッドが動作中ではない場合に、前記記憶装置から読み出した識別子が、前記第２スレッドの識別子であるか否かに基づき、前記第２スレッドに異常があるか否かの判定を行い、
前記判定の後前記第１スレッドの処理が完了した場合に、前記記憶領域に格納されている識別子を前記第１スレッドの識別子で更新する、
処理を実行する情報処理装置。

１ 管理サーバ １１ 時刻管理部
１２ 起動制御部 １３ 異常処理部
１４ メモリ領域 １５ 初期化処理部
１ｔ，２ｔ 監視スレッド ３ ネットワーク
１ａ，２ａ，３ａ 装置

Claims (6)

1. プログラムであって、
   前記プログラムの第１スレッドが動作中であり且つ前記プログラムの第２スレッドが動作中ではない場合に、前記第１スレッドと前記第２スレッドとが共通に使用する記憶領域から読み出した識別子が前記第２スレッドの識別子であるか否かに基づき、前記第２スレッドに異常があるか否かの判定を行い、
   前記判定の後前記第１スレッドの処理が完了した場合に、前記記憶領域に格納されている識別子を前記第１スレッドの識別子で更新する、
   処理をコンピュータに実行させるプログラム。
2. 前記コンピュータに、
   前記記憶領域に格納されている識別子を前記第１スレッドの識別子に更新した後、前記第１スレッドをスリープ状態に移行する、
   処理をさらに実行させる請求項１記載のプログラム。
3. 前記コンピュータに、
   前記第１スレッドがスリープ状態に移行した後、所定の時刻に前記第２スレッドのスリープ状態を解除し、前記第２スレッドの動作を開始する、
   処理をさらに実行させる請求項２記載のプログラム。
4. 前記コンピュータに、
   前記第２スレッドに異常があると判定された場合に、当該異常に対処するための処理を実行する、
   処理をさらに実行させる請求項１乃至３のいずれか１つ記載のプログラム。
5. コンピュータが、
   プログラムの第１スレッドが動作中であり且つ前記プログラムの第２スレッドが動作中ではない場合に、前記第１スレッドと前記第２スレッドとが共通に使用する記憶領域から読み出した識別子が、前記第２スレッドの識別子であるか否かに基づき、前記第２スレッドに異常があるか否かの判定を行い、
   前記判定の後前記第１スレッドの処理が完了した場合に、前記記憶領域に格納されている識別子を前記第１スレッドの識別子で更新する、
   処理を実行する情報処理方法。
6. 複数のスレッドが共通で使用する記憶装置と、
   プロセッサと、
   を有し、
   前記プロセッサが、
   プログラムの第１スレッドが動作中であり且つ前記プログラムの第２スレッドが動作中ではない場合に、前記記憶装置から読み出した識別子が、前記第２スレッドの識別子であるか否かに基づき、前記第２スレッドに異常があるか否かの判定を行い、
   前記判定の後前記第１スレッドの処理が完了した場合に、前記記憶装置に格納されている識別子を前記第１スレッドの識別子で更新する、
   処理を実行する情報処理装置。
   

Images