JP2006092057A - プロセスの強制終了処理方法 - Google Patents

Abstract

【課題】
構造化例外処理によれば、処理異常時の後処理、回復処理が簡単に記述できる。しかし、プロセスが外部から強制停止される場合に、この例外処理が実行できない。
【解決手段】
プロセスの強制終了を要求されたときに、当該プロセスが構造化例外処理に対応する実行時ライブラリを実行しているかを判定して、プロセスの実行時ライブラリに終了通知を配信するＯＳの強制終了通知処理と、ＯＳからのプロセス強制停止の通知を受けて、プロセス内のスレッドに登録されている構造化例外処理の後処理を実施させる実行時ライブラリの終了通知配信処理と、ある実行時ライブラリが強制終了通知を処理可能であることをＯＳに登録するＯＳのインターフェイスによる。
【選択図】 図１

Description

本発明は、計算機で実行されるプロセスを強制的に停止するときの処理に関する。特に、構造化例外によって定義された後処理を、プロセスの強制終了時に実行する方法に関する。

計算機システムで実行されるプログラムで例外が発生した場合、あるいはプログラムが強制終了される場合に、そのプログラムを実行していた計算機システムを矛盾のない状態に回復する方法として、例外処理やトランザクション処理がある。ここで「計算機システムを矛盾のない状態に回復する」とは、例外あるいは強制終了されたプログラムが実行中であった処理を取り消す等により、計算機システムで実行されている他のプログラムの処理にプログラムの中断の影響を与えないようにすることである。

尚、プログラムを外部から強制終了しなければならない場合としては、プログラムやオペレーティングシステム（以下「ＯＳ」）の論理不良によるデッドロックや無限ループ、メモリの不良によるプログラムの異常動作、I/O装置の故障によるプログラム異常、リソースの解放洩れによるリソース枯渇、計算機システムが有するハードウエア資源（以下「システムリソース」とも言う）不足による計算機システムの高負荷状態等で、システムが不安定になった場合等が想定される。

トランザクション処理では、プログラムで実行される複数の更新処理の一括実施を実現する。そしてトランザクション処理では、何らかの原因でプログラムの実行に基づく計算機システムの状態の更新が中途半端になった場合、その更新と一括して実施されていた処理を一括して取り消し、計算機システムの状態を矛盾のない状態（一括実施の前の状態）に回復する。

又、計算機システムのプログラムの実行中に発生する例外や強制終了に対応する例外処理について、特許文献１の方法が提案されている。

特許文献１では、排他制御用のデータ構造に例外処理を関連付けて、タスクの異常終了時にその例外処理を実施する方法、特に、例外処理の中でセマフォを解放する方法が開示されている。

更に、プログラム実行における例外処理の他の方法として、構造化例外処理という技術がある。構造化例外処理では、実行時に例外が発生する可能性があるプログラムの部分に、その例外を処理するコードを設定する方法である（例えば非特許文献１参照）。

図３は、構造化例外処理が埋め込まれたプログラムの例を示す図である。構造化例外処理では、プログラムで実行されるべき処理をtryブロックの中に、tryブロック実行中に発生する例外捕獲時の処理（その例外に対応する処理を行うこと）をcatchブロックの中に、例外の発生の如何に関わらずtryブロックの後に実行する後処理をfinallyブロックに記述する。この構造により、例外処理等が発生した場合に、このプログラムを実行する計算機システムは、cacheやfinallyブロックに記載された処理を実行して処理を終了することとなり、計算機システムの状態が、このプログラムの実行前の矛盾の無い状態に回復される。

一般に構造化例外処理は、ＯＳによる例外通知処理、構造化例外処理に対応するプログラミング言語、およびそのプログラミング言語の実行時ライブラリの組合せで実現される。

構造化例外処理は、プログラムの部分ごとに例外処理を記述できるという利点がある。このため、例外時の処理を主たる処理の近くに記述できるため、きめ細かく例外処理を記述でき、また、プログラムの更新時の例外処理プログラムの保守も容易になるという利点がある。

特開平１１−２４９４７（第１１頁、図９） Ken Arnold他、乃he Java Programming Language, JavaSoft, 1996年5月、p. 133-142

上述したトランザクション処理を利用するには、計算機システムで実行されるプログラムをトランザクション処理に対応させなければならない。また、トランザクション処理を利用する場合、計算機システムの状態回復に時間がかかるため、高度な応答性が要求される計算機システムでは適用できない場合がある。

一方、構造化例外処理はそもそもプログラムの実行に伴って発生する例外の処理を目的とする。このため、プログラムの実行がその実行とは無関係に外部から強制終了される場合、プログラム中で記述された例外処理が実行されない問題がある。

より具体的には、一般にプログラムの実行に関わるプロセスが強制終了される場合、ＯＳは強制終了の対象となるプロセスが何を実行しているかは関知せず、また、強制終了の対象となるプロセスになんら通知をせずにプロセスに割り当てられたシステムリソースを解放し、プロセスを強制終了する。すなわち、ＯＳは、強制終了対象のプロセスが構造化例外処理に対応するプログラムを実行するプロセスであるかどうかを考慮しない。このため、プログラムに構造化例外処理で例外処理を記述しても、プロセスが外部から強制終了される場合、記述された例外処理が実行されない。したがって、例外処理の中に計算機システムの回復処理を記述しても、プロセスが強制終了されるときにはこれらの処理が実行されないため、計算機システムが矛盾を含んだ状態になり得るという問題がある。

また、特許文献１に開示された方法では、排他制御と無関係の処理には、プロセス異常終了時に実施する例外処理等を定義できない問題がある。加えて、排他制御を司るデータ構造に例外処理を関連付けるため、１つの例外処理の中で発生しうるすべての異常な状況に対応しなければならない。したがって例外処理が複雑になり記述が難しくなるという問題がある。

上述した問題を解決するため、本発明として、以下の実施形態を提案する。具体的には、計算機においてプロセスを強制終了する方法であって、終了対象のプロセスに強制終了の実施を通知し、プロセスで実行中の処理に付随する特定処理を実行し、前記特定処理の終了に応じて、前記プロセスを強制終了するという形態である。

より具体的には、計算機においてプロセスの強制終了を要求されたときに、当該計算機が、当該プロセスが構造化例外処理に対応する実行時ライブラリで実行されているかを判定し、プロセスの実行時ライブラリに終了通知を配信し、ＯＳからのプロセス終了の通知を実行時ライブラリから受信したプロセスが、プロセス内のスレッドに登録されている構造化例外処理を実施し、その後プロセスの強制終了を行うという構成である。尚、本発明の他の実施態様については、明細書及び図面から明らかにされる。又、本発明は、実施形態の記載に限定されることはない。

本発明によれば、システムを矛盾のない状態に素早く復旧させることが可能となり、システム全体の可用性の向上が期待できる。また、ログやジャーナルといった履歴の記録も不要である。

又、クラスタや並列二重処理を実施する分散計算機システムに本発明を適用すれば、引継ぎに要する時間を短縮でき、システムの可用性の向上が期待できる。また、古い処理状況に基づいて引き継ぎ処理を実施する可能性も低減できるため、システムの信頼性も向上できる。

以下、図面を用いて各実施形態を説明する。まず第一の実施形態では、あるプロセスを強制終了する際に、ＯＳが、そのプロセスで実行されるプログラムが構造化例外処理に対応した実行時ライブラリで実行されているかを判定する。そして、実行されるプログラムが構造化例外処理に対応する場合、ＯＳはそのプロセスの終了時に実行時ライブラリに制御を移して例外処理等の特定の処理（以下「特定処理」）を実行させる。この場合、特定処理には上述したfinallyで定義される後処理も含まれ、例えば、特定処理として、プロセス終了に伴うシステムの回復処理が行われる。特定処理の終了後、ＯＳはプロセスを終了させる。以下第一の実施形態での処理方法について説明する。

図２は、第一の実施形態である計算機の概要例を示す図である。計算機２００は、ＣＰＵ２０１、メモリ２０３、外部記憶装置２０４、入出力装置２０２を有する一般的な計算機である。外部記憶装置２０４には、計算機２００のＣＰＵ２０１が実行するＯＳを構成するファイル２１０が格納されている。加えて、外部記憶装置２０４には、ＯＳが実行するプロセスとして実行されるプログラムとして、実行時ライブラリ２１２、アプリケーションプログラムファイル２１３が格納されている。

実行時ライブラリ２１２は、構造化例外処理に対応したプログラミング言語によって作成されたプログラムを、プロセスで実行するための実行環境を提供する。具体的には、実行時ライブラリ２１２は、プログラム開始終了の処理、OSの呼び出し、メモリ管理等の、プログラム実行に必要な基本的な処理を、プログラムに提供する。

アプリケーションプログラムファイル２１３は、構造化例外処理に対応したプログラミング言語で作成されたプログラムファイル（プログラムのデータ）である。プログラミングファイル２１３はヘッダを有し、実行時に使用される（以下「リンクする」とも言う）実行時ライブラリ２１２の名前を、そのヘッダに含んでいる。

また、外部記憶装置２０４は、ＯＳ２１０の実行時にＣＰＵ２０１が参照するＯＳ環境設定ファイル２１１も保持している。ＯＳ環境設定ファイル２１１は、計算機２００にインストールされている、強制終了処理時に実行される実行時ライブラリ２１２の情報を保持する。尚、「強制終了処理」とは、以下で説明する、プロセスの強制終了時の実行時ライブラリやスレッドで行われる構造例外処理を指すものとする。

図２では、メモリ２０３にＯＳ１００がロードされて、いくつかのプロセスがＣＰＵ２０１によって実行されていることが示されている。このように、外部記憶装置２０４に格納されたプログラムは、メモリ２０３にロードされた後、ＣＰＵ２０１で実行される。また本図では、１つのプロセス１１０が、実行時ライブラリ１２０上でアプリケーションプログラム１３０を実行していることを示している。ここで、メモリ２０３内に記載されている実行時ライブラリ１２０とアプリケーションプログラム１３０は、それぞれファイル２１２と２１３のメモリ２０３内のイメージを示す。

図１は、第一の実施形態におけるアプリケーションプログラムを実行するプロセス１１０とＯＳ１００の論理的な内部構造例を示す図である。以下、説明を簡単にするため、プログラムを主語として説明を行う。しかし、実際には、ＣＰＵ２０１が説明される処理を実行することとなる。

ＯＳ１００は、プロセス実行時の例外をプロセスに配信する例外通知モジュール１０１、及びＯＳ１００に登録されている実行時ライブラリ１２０を実行しているプロセスを強制終了する場合に、強制終了の対象となるプロセスに強制終了の旨を通知する強制終了通知モジュール１０２を有している。

また、ＯＳ１００は、強制終了通知の配信対象となる実行時ライブラリ１２０を定義する実行時ライブラリテーブル１０３を保持している。実行時ライブラリテーブル１０３には、実行時ライブラリ２１２の名前と、その実行時ライブラリ２１２に含まれ、ＯＳ１００からの強制終了通知を処理するモジュールのアドレスに関する情報を保持する。

図１に示した例では、実行時ライブラリテーブル１０３は、実行時ライブラリＡの情報を格納しており、その強制終了通知を処理するモジュールは終了例外配信モジュール１２２である。

プロセス１１０では、構造化例外処理に対応した実行時ライブラリＡ１２０と、アプリケーションプログラム１３０が実行されている。プロセス１１０では、複数のスレッドがアプリケーションプログラム中のモジュールを実行している。

尚、簡単にプロセス、スレッド、モジュールを説明する。プログラムは、複数のモジュールから構成される。モジュールは、例えば、手続き型言語での関数や、オブジェクト指向言語でのメソッドに相当する。プロセスはプログラム実行のための資源管理の単位で、具体的には、プログラム実行に必要なアドレス空間の定義と対応付けられる。スレッドは、プロセスのアドレス空間にロードされたプログラム（モジュール等）内のコードを実行する単位となる。スレッドは、スレッドで現在実行されている命令のアドレスや、スレッドの実行状態を保存するスタック等を保持している。

実行時ライブラリＡ１２０は、例外配信モジュール１２１と終了通知配信モジュール１２２を含んでいる。例外配信モジュール１２１は、発生した例外を、その例外を発生したスレッドに配送する。終了通知配信モジュール１２２は、プロセス１１０が強制終了される場合に呼び出されて、プロセス１１０の終了処理を実施する。

まず、通常の構造化例外処理の流れを説明する。図３は、３００に示したプログラムの実行中に例外が発生した場合の処理フロー例を示す図である。以下、図１のスレッド１４０が、図３の３００のプログラムを実行しているとして説明する。又、「モジュールProcess」等の表現は、ある特定のモジュール（その特定のモジュールに「Process」というモジュール名が付与されている）を指すものとする。

モジュールProcessを実行するスレッド１４０は、構造化例外処理のtry文の実行中にモジュールSub1を呼び出し（ステップ３０１）、モジュールSub1を実行するスレッド１４０は、Sub2を呼び出す（ステップ３０２）。

尚、スレッド１４０は、１つのtry文を実行する前に、そのtry/catch/finally文の情報をスレッド１４０の例外処理リスト１５０に、一つのブロックとして記録する。この際、作成されたブロックは、例外処理リスト１５０の先頭に挿入される。ここで「例外処理リスト１５０」とは、スレッド１４０の実行の過程で出現し、まだ処理が完了していないtry/catch/finally文の情報を保持するリストである。例外処理リスト150は、１つのtry/catch/finally文を表現するブロックから構成され、メモリに格納される。

try文実行の前に格納された構造化例外処理に関するデータは、そのtry文に対応するFinally文の実行の前に例外処理リスト１５０から削除される。これらの処理を実施するために必要なプログラムコードは、モジュールのコンパイル時に生成される。

図４は、例外処理リスト１５０の構造例を示す図である。ＯＳ１００は、スレッドの実行に必要なデータの１つとして、例外処理リスト１５０を保持している。例外処理リスト１５０は、１つのtry/catch/finally文に関する実行時の状態を保持する例外処理ブロック４１０を有する。そして、例外処理リスト１５０では、これらの例外処理ブロックがリスト構造となっている。

個々の例外処理ブロック４１０は、例外処理が定義されたときのスレッドのスタックポインタ、finally文がある場合はその開始アドレス、その時点で他に定義されている構造化例外処理に対応する例外処理ブロックへのリンクの情報を保持する。catch文が定義されている場合は、例外処理ブロック４１０は、catch文の情報を保持するcatchブロック４３０のリスト（catchブロックのリンク構造を有する構造体）への参照アドレスも保持する。

catchブロック４２０は、catch文毎に１つ作成される。個々のcatchブロック４２０は、ブロックに対応するcatch文が捕獲する例外の種類、対応するcatch文の開始アドレス、他のcatch文に対応するcatchブロック４２０への参照アドレスを示す情報を含む。

図４の例では、例外処理ブロック４２０とcatchブロック４３０がProcessモジュールの例外処理定義、例外処理ブロック４１０がSub1の例外処理定義に対応している。例外処理リスト１５０内の項目の順番は、最後に登録された構造化例外処理を記述する例外処理ブロック４１０がリストの先頭に登録されるようになっている。各例外処理ブロック４１０は、コンパイラが生成したコードによって、例外処理ブロック４１０に対応するFinally文が実行される直前に削除される。

図３に戻って処理手順の説明を続ける。ここで、モジュールSub2が、処理中にエラーを検出し、実行時ライブラリＡ１２０に例外生成を要求したとする（ステップ３０３）。実行時ライブラリＡ１２０は、要求を受けて、例外をスレッド１４０に配信する。

具体的には、要求を受けた実行時ライブラリＡ１２０は、スレッド１４０で例外配信モジュール１２１の実行を開始する。例外配信モジュール１２１は、スレッド１４０の例外処理リスト１５０を参照して、例外生成を要求したモジュールに対応する例外処理ブロック４１０を選択し、必要ならばそのブロック４１０に登録されている例外を捕獲するcatch文を含むcatchブロックを見つける。図４の例でいえば、catchブロック４３０が、Sub2の例外を捕獲するcatch文を含んでいる（ステップ３０４）。

次に例外配信モジュール１２１を実行するスレッド１４０は、例外処理リスト１５０に登録され、かつステップ３０４で見つけられたcatchブロック（ここではcatchブロック４３０）より前に例外処理リスト１５０に登録されている全ての例外処理ブロックに登録されたfinally文を実行する。図４の例でいえば、例外処理ブロック４１０が該当するので、スレッド１４０は、例外処理ブロック４１０に登録されているfinally処理を行う。その後、スレッド１４０は、先に選択されたcatchブロック４３０に登録されている、例外を捕獲するcatch文を実行し、それに付随するfinally文を実行する。

図３の例では、スレッド１４０は、モジュールsub2内のfinally文、モジュールsub1内のfinally文を実行する（ステップ３０５）。次にスレッド１４０は、モジュールProcess内のcatch文を実行し（ステップ３０６）、最後にモジュールProcess内のfinally文を実行する（ステップ３０７）。各々のfinally文実行の前に、各々のfinally文に対応する例外処理ブロック（ここでは例外処理ブロック４１０と４２０）は削除される。

図３の例では、プログラム自身がエラーを検出し例外を生成して通知する処理を説明したが、数値計算のオーバーフローやゼロ割り算のように、スレッド１４０を実行中のＣＰＵ２０１が例外を発生し、ＯＳ１００が例外を検知する場合もある。この場合、ＯＳの例外通知モジュール１０１が、プロセッサ例外の発生を実行時ライブラリＡ１２０の例外配信モジュール１２１に通知し、例外配信モジュール１２１が、例外を発生したスレッド１４０のコンテクストで例外処理リスト１５０に登録されている例外処理を実行する。

次に、本実施形態において、プロセス１１０が他のプロセスやＯＳから強制的に終了される場合の処理手順について説明する。図５と図６は、プロセスが強制終了される場合の処理の手順例を示す図である。図５は、ＯＳ１００の強制終了通知モジュール１０２が行う手順例を示す図である。

強制終了の場合、プロセス１１０で実行されるスレッド自身が、例外処理の開始をプロセス１１０で実行される実行時ライブラリＡ１２０に要求することが出来ない。したがって、この場合ＯＳ１００が、強制終了の対象となるプロセス１１０で実行される実行時ライブラリ１２０の特定のモジュール（ここでは、実行時ライブラリテーブル１０３に登録されたモジュール）を特定してそのモジュールに対して強制終了を通知する。

そして、特定されたモジュールは、プロセス１１０で実行されている全てのスレッドで特定処理、具体的には構成例外処理（finally処理のみ）を実行して全てのスレッドを終了させる。これにより、各スレッドの構成例外処理に定義されたfinally処理によって計算機システムの矛盾を解消してプロセスを終了することが出来る。以下、手順を説明する。

ＯＳ１００は、プロセス１１０を強制終了するように要求されると、強制終了通知モジュール１０２を実行し、まず、強制終了対象のプロセス１１０（以下「対象プロセス１１０」）が、強制終了処理に対応する実行時ライブラリ２１２を実行しているか検査する（ステップ５０１）。具体的には、ＯＳ１００は、プログラム１３０が実行時ライブラリテーブル１０３に登録されているライブラリとリンクしているか否かを確認することで、実行時ライブラリ２１２の実行の有無を判定する。尚、リンクの有無は、ＯＳ１００が、プロセス１１０が実行しているアプリケーションプログラム１３０を構成するファイル２１３のヘッダに含まれる情報を参照して判定する。

対象プロセス１１０が実行時ライブラリテーブル１０３に登録されている実行時ライブラリ２１２とリンクしていないならば、通常のプロセス強制終了の処理として、ＯＳ１００は、プロセス１１０に割り当てられたシステムリソースを解放し、プロセス１１０の実行を停止する（ステップ５０３）。

一方、対象プロセス１１０が実行時ライブラリテーブル１０３に登録されている実行時ライブラリ２１２とリンクしているならば、ＯＳ１００は、強制終了通知モジュール１０２の実行に基づいて、対象プロセス１１０に割り込み可能なスレッドがあるか検査する（ステップ５０２）。

対象プロセス１１０に割り込み可能なスレッドが存在しないならば、ＯＳは例外処理をあきらめて、通常の停止処理を実施する。これは、ＯＳ１１０から直接実行時ライブラリＡの終了通知配信モジュール１２２の起動を指示できないため、プロセス１１０で実行されているスレッドに割り込むことで終了通知配信モジュール１２２の起動を指示する必要があるからである（ステップ５０３）。

一方、対象プロセス１１０に割り込み可能なスレッドがあるならば、ＯＳ１００は、割り込み可能なスレッドを１つ選択する（ステップ５０４）。そしてＯＳ１００は、選択されたスレッドの実行に割り込んで、実行時ライブラリテーブル１０３に登録されている終了通知配信モジュール１２２に制御が移るようにスレッドのコンテクストを設定し、そのスレッドの実行を再開させる。この処理によって、割り込まれたスレッドは、ＯＳ１００によって次回スケジュールされたときに、終了通知配信モジュール１２２を実行して、登録されている構造化例外処理を実行する（ステップ５０５）。

この後、ＯＳ１００は、対象プロセス１１０内のすべてのスレッドの終了を待って（ステップ５０６）、プロセスの資源解放処理（ステップ５０３）を実施し、対象プロセス１１０の実行を終了させる。

尚、本実施形態では、対象プロセス１１０のすべてのスレッドの終了を待つとして説明したが、定められた所定の時間待って全てのスレッドが終了しなければ、ＯＳ１００が全スレッドの終了を待たずにステップ５０３を実行して、対象プロセス１１０を終了しても良い。この待ち時間は、実行時ライブラリの設定値、プロセスの終了を指示するときに指定する、あるいは、プロセスの属性として設定する、といった方法で定めることが考えられる。

次に、対象プロセス１１０におけるスレッドの終了処理について説明する。図６は、実行時ライブラリＡ１２０の終了通知配信モジュール１２２の処理フロー例を示す図である。図５で選択されたスレッドは、図５に示すＯＳ１００の割り込み後、終了通知配信モジュール１２２の実行を行う。

この終了処理では、この処理を実行しているスレッド（図５で選択されたスレッド）以外の対象プロセス１１０内の全てのスレッドに対して、ステップ６０３〜ステップ６０５の処理が実行される。まず、終了通知配信モジュール１２２は、他の実行中のスレッドに登録されている例外処理があるか検査する。具体的には、終了通知配信モジュール１２２は、他の実行中のスレッドに例外処理リスト１５０が設定されているかを検査する（ステップ６０３）。

他の実行中のスレッドに例外処理リスト１５０が設定されていないならば、終了通知配信モジュール１２２は、何もしない。このスレッドは、プロセスの資源解放処理（ステップ５０３）により消去される。

他の実行中のスレッドに例外処理リスト１５０が設定されている場合、終了通知配信モジュール１２２は、そのスレッドに割り込み、そのスレッドでステップ６０６からの例外配送処理が実行されるようスレッドのコンテクストを設定し（ステップ６０４）、スレッドの実行を再開させる（ステップ６０５）。尚、スレッドが、この時点で割り込めない待機状態にある場合は、終了通知配信モジュール１１２２は、割り込みを割り込み対象のスレッドの管理する記憶領域に記録し、待機状態から復帰したときに、例外配送処理を実施するようにコンテクストを設定する。

割り込まれたスレッドは、処理が再開された後に、例外配送処理を実行する。具体的には、割り込まれたスレッドは、そのスレッドの例外処理リスト１５０に登録されているfinally文を実行する（ステップ６０６）。このとき、割り込まれたスレッドは、例外処理リスト１５０に登録されているcatch文は無視する。そして、スレッドの実行を終了する。この際、割り込まれたスレッドは、ＯＳ１００に対して自身の終了を通知する（ステップ６０７）。

一方、ステップ５０４で選択されたスレッドは、終了通知配信モジュール１２２を実行して自分以外のスレッドへの通知を送信した後（ステップ６０２）、自分自身に登録されているfinally文を実行し（ステップ６０６）、処理を終了する（ステップ６０７）。

最後に、実行時ライブラリテーブル１０３への実行時ライブラリ１２０の登録について説明する。ＯＳ１００は、実行時ライブラリテーブル１０３へ実行時ライブラリ２１２の情報を登録するためのアプリケーションインターフェース（以下「ＡＰＩ」）を提供する。例えば、実行時ライブラリをＯＳ１００にインストールするときにＯＳ環境設定ファイル２１１に実行時ライブラリ情報（モジュール等）を登録するＡＰＩや、実行時ライブラリ１２０の初期化時に実行時ライブラリテーブル１０３にモジュール等の情報を登録するＡＰＩをＯＳ１００が有するようにする。ＯＳ１００は、起動時に、ＯＳ環境設定ファイル２１１よりインストールされている実行時ライブラリの情報を取り込み、実行時ライブラリテーブル１０３に登録する。

尚、ＯＳが実行時ライブラリテーブル１０３を持つ代わりに、プロセス毎の管理データとして、強制終了時に呼び出す終了通知配信モジュール１２２のアドレスと、その終了通知配信モジュール１２２をプロセスの起動時にプロセス自身がOSに登録するためのインターフェイスをＯＳ１００が有し、実行時ライブラリ１２０の初期化時に、プロセスが終了通知配信モジュール１２２をＯＳ１００に登録してもよい。

また、本実施形態では、プロセス側の終了通知配信モジュール１２２を実行時ライブラリ１２０内に置いたが、この限りではない。例えば、ユーザが作成するプログラム内においても良い。
本実施形態により、プロセスが外部から強制的に終了される場合にも、その時点で登録されている特定処理（構造化例外処理）を実行できる。これにより、プロセスに、処理途中で中途半端になっている状態を回復する機会を与えることができる。

一般に、ＯＳ１００に含まれないプログラムで回復処理を実現（例えばトランザクション処理）しようとすると、様々な異常の状態を想定した解析をしなければならないため、回復処理が複雑になり、長い時間がかかる。また、ログやジャーナルといった履歴の記録が必要であり、このための処理や記憶域が必要になる。

一方、構造化例外で回復処理を実装する場合、回復処理を簡単に記述でき、複雑な解析処理も低減されて回復処理も簡便になる。さらに、本実施形態を組み合わせれば、回復処理を記述した特定処理がプロセスを外部から終了させる場合にも実行されるため、短時間で必要な回復処理を実行できる。これにより、計算機システムを矛盾のない状態に素早く復旧させることが可能となり、計算機システム全体の可用性の向上が期待できる。また、短時間で回復処理が実施できることから、計算機システムの応答性能の向上にも繋がる。

次に、第２の実施形態について説明する。第１の実施形態では、プロセスを強制終了させる要求を受けたときに、ＯＳ１００が対象プロセス１１０内の割り込み可能なスレッドに割り込んで、そのスレッドに終了通知配信モジュール１２２を実行させた。しかし、プロセスが異常な状態にある場合、対象プロセス１１０には、割り込み可能なスレッドがない場合も考えられる。本実施形態は、そのような場合に対応する方法を示す。

図７は、第２の実施形態における、ＯＳ１００のプロセス起動処理の処理フロー例を示す図である。
ＯＳ１００は、プログラムを実行するプロセス１１０を作成する時に、そのプロセス１１０用のアドレス空間を初期化し（ステップ７０１）、そのアドレス空間にプログラムや必要な実行時ライブラリをロードする（ステップ７０２）。

次にＯＳ１００は、プロセス１１０を強制終了させるときに割り込み可能なスレッドがない場合に備えて、終了配信処理モジュール１２２を実行するためのスレッド資源を割り当てておく。この割り当てでＯＳ１００のスケジューリング対象となるスレッドを生成する必要はなく、終了処理のときにここで割り当てた資源を使ってＯＳ１００がスレッドを起動し、そのスレッドが終了配信モジュール１２２を実行できるようにしておけばよい。又、ＯＳ１００は、このスレッドを完全なスレッドとして生成して、必要なときまで待機させておいても良い（ステップ７０３）。

その後ＯＳ１００は、プロセス１１０の初期スレッドを生成する（ステップ７０４）。これにより、プロセス１１０が実行可能な状態となる。

その後、ＯＳ１００は、プロセス１１０の強制終了要求を受けると、ステップ７０３で用意したスレッドを実行可能な状態にして、終了通知配信モジュール１２２を実行させる。具体的には、図６で説明した通り、このスレッドは、モジュール１２２のステップ６０３ないし６０５で自身以外のスレッドに定義されたfinally文を実施させ、最後に自身の実行を終了する。

尚、本実施形態では、ＯＳ１００が終了処理用のスレッドを新たに作成してプロセス１１０に割り当てるとしたが、実行時ライブラリ１２０が、プロセス１１０の開始時に終了処理用のスレッドを割り当てても良い。具体的には、実行時ライブラリ１２０があるプログラムの実行を開始する際に、実行時ライブラリ１２０自身が、終了処理用のスレッドを、そのプログラムを実行するプロセスに実行させるように設定する。

またＯＳ１００が、プロセス１００の強制終了指示時に、終了通知配信モジュール１２２の実行を待機しているスレッドを実行可能状態とすることとしたが、このスレッドがプロセス間通信を使って他プロセスからの終了要求を待ち、プロセス間通信で要求を受信したときに、終了通知配信モジュール１２２の処理を実施するようにしても良い。

本実施形態により、プロセスの停止を要求した時点で割り込み可能なスレッドがない場合でも、実行時ライブラリに終了通知を配信できる。プロセス内のスレッドは、割り込みが可能になった時点で登録している例外処理のfinally文を実行して終了する。これにより、強制終了通知の配送をあきらめるよりも、登録されている構造化例外処理を実行できる可能性を高めることができ、プロセスが処理途中で中途半端になっている状態を回復する機会を増大できる。これは、システム全体の可用性の向上に繋がると期待できる。

次に、第三の実施形態として、プロセス強制終了時の構造化例外処理の実行を、選択的に定められるようにする方法を説明する。本実施形態では、プロセス強制終了時に、プログラムに記述されている構造化例外処理を実行するかどうかを、プログラムコードの属性として指定する方法を示す。

図８は、本実施形態でのプログラムのコードの例と、必要なデータ構造例を示した図である。図８の８０１で示されるコードでは、モジュールfunction1の記述の直前に、[doFinallyOnTerminate()]と記述している。これは、モジュールfunction1内の構造化例外処理について、プロセス１１０が強制終了された場合にfinallyを実行するように指定する記述である。また、図８の８０２で示されるコードでは、モジュールfunction1内のtryブロックの直前に、[doFinallyOnTerminate()]と記述している。これは、プロセス１１０が強制終了された場合に、このtryブロックのfinally処理を実行するよう指定する記述である。

これらの記述はプログラムをコンパイルするときにコンパイラによって認識され、コンパイラは、try文の実行の直前に、対応する例外処理ブロックを生成するコードを生成する。

図８では、本実施形態における例外処理ブロック８１０のデータ構造例をも示す。図４に示した例外処理ブロック４１０の内容に加えて、例外処理ブロック８１０は、プロセスの強制終了時にfinally文を実施するかどうかを示すフラグを格納する領域を持つ。コンパイラは、doFinallyOnTerminate属性が設定されているtry文を発見すると、その例外処理ブロック８１０のフラグをセットするコードを生成する。

第一の実施形態の終了通知配信モジュール１２２の処理では、ステップ６０３でスレッドに構造化例外処理が登録されているかどうかを判定していたが、本実施形態では、それに替えて、強制終了時のfinally処理実行が指定されている構造化例外処理が登録されているか判定して、指定されているスレッドでのみステップ６０６からの処理を実施させるようにする。さらに、ステップ６０６では、登録されている例外処理ブロック８１０を参照して、強制終了時にfinally処理実行するよう指定されているfinally文のみを実行する。

本実施形態により、登録されている構造化例外処理のうち、予め指定した処理だけを強制終了時に実行させるように指示できる。これにより、特定処理、具体的にはプロセス障害時の後処理を実施できる確率を高めることができ、システムの可用性の向上に繋がる。また、不要なfinally文を実行しないため、より素早くプロセスを停止でき、システムの復旧時間を短縮できる。

次に、上述した実施形態を他のシステム構成に応用する例について説明する。第４の実施形態は、クラスタ構成の計算機システムにおいて、プロセス障害時の系切り替え時間を短縮するために、上述した実施形態を適用する例である。

図９は、本実施形態のクラスタ構成例を示す図である。クラスタは、２台の計算機９００と９１０、及び共有ディスク９２０を有する。計算機９００と９１０は、ネットワークで相互に接続されている。それぞれの計算機で実行されるクラスタ制御部９０５と９１５が、ネットワークを介して互いの生死の状態を監視している（例えばハートビート信号等が用いられる）。

また、計算機９００と９１０は、共有ディスク９２０とも接続している。また、図示していないが、計算機９００と９１０には、クライアントとなる計算機がネットワーク経由で接続されている。

本実施形態では、計算機９００が主系となっており、アプリケーション９０１を実行している。アプリケーション９０１は、強制終了処理を実装する実行時ライブラリ９０４の元で実行され、いくつかのスレッド９０２を実行している。この実行時ライブラリ９０４は、上述した実施形態の特定処理（構造化例外処理）を実行する。また、実行時ライブラリ９０４は、強制終了処理を実装しているとしてＯＳ１１０に登録されているとする。

アプリケーション９０１の処理内容について説明する。アプリケーション９０１は、メモリ内のテーブル９０３に、各々の時点での自身の状態（変数の値、アドレスの戻り値等）を保持し、それを参照して処理を実施する。アプリケーション９０１は、クライアントからの要求を受けて、テーブル９０３の参照と更新を実施する。アプリケーション９０１は、テーブル９０３を更新する場合、更新の内容を共有ディスク９２０の更新ログファイル９２１に記録し、メモリのテーブル９０３を更新する。また、アプリケーション９０１は、定期的にメモリ内のテーブル９０３の内容を共有ディスク９２０内のテーブルファイル９２２に書き出す。

図１０は、アプリケーション９０１の処理プログラムの例を示す図である。モジュールmodifyTableは、テーブル９０３の更新内容を更新ログファイル９２１に記録し、メモリ内のテーブル９０３を更新する。モジュールwriteDiskは、定期的にテーブル９０３の内容を共有ディスク９２０のテーブルファイル９２２に書き出し、更新ログファイル９２１の内容を消去する。モジュールwriteDiskの処理内容は、try文に囲まれており、finally文（テーブル９０３の内容の書き出し等）を定義している。

計算機９００でアプリケーション９０１が障害のため停止すると、計算機９１０のクラスタ制御部９１５がこれを検知して、計算機９１０が主系となるように系切り替え処理を実施する。この中で、計算機９１０でアプリケーション９０１が起動する。アプリケーション９０１は、共有ディスク９２０からテーブル９２２と更新ログ９２１を読み取って、最新のテーブル内容を自身のメモリ内に構築してから、クライアントからの要求の受け付けを開始する。

以下、何らかの原因でアプリケーション９０１が不安定になり、アプリケーション９０１を強制停止する場合について説明する。計算機の使用者等がアプリケーション９０１のプロセスを強制停止するようＯＳ１００に要求すると、ＯＳ１００は、アプリケーション９０１が実行時ライブラリ９０４にリンクされていることを検出して、実行時ライブラリ９０４の終了通知配信モジュール１２２を起動する。

終了通知配信モジュール１２２は、モジュールwriteDiskを実行しているプロセスへ割り込んで、例外処理を実行させる。この結果、モジュールwriteDiskで定義されているfinally文が実行され、通常と同じ共有ディスク９２０の更新処理が実行される。

この更新処理が実行された後で、計算機９００のクラスタ制御部９１０は、計算機９１０に計算機９００の異常を通知する。この通知により、計算機９１０のクラスタ制御部９１５が計算機９００の異常を検知する。この場合、計算機９１０で起動するアプリケーション９０１は、共有ディスク９２０からテーブル９２２と更新ログファイル９２１を読み込むが、上述したようにテーブル９２２が最新の内容となっているため、計算機９１０におけるログファイル９２１を参照しての回復処理が不要となる。したがって、回復処理をしなければならない場合よりも、短時間でクライアントからの要求を受付可能となる。

このように、クラスタで実行されるアプリケーションが、上述した実施形態による構造化例外処理に対応する処理を実行時ライブラリで実行し、アプリケーションに適切な終了処理をfinally文に記述しておけば、クラスタの系切り替え処理を高速化できる。

次に、別の応用例として、第５の実施形態について説明する。この実施形態では、２台の計算機が同じ処理を並列で実行しているシステム構成において、上述した実施形態を適用する場合について説明する。

図１１は、本実施形態における計算機システムの構成例を示す図である。本実施形態のシステムでは、２台の計算機１１００と１１１０が、二重系制御モジュール１１０３と１１１３により主系と従系に構成されている。そして、これらの計算機は、クライアントとネットワークを介して接続されている。尚、本図では、計算機１１００が主系であるとする。それぞれの計算機で同一のアプリケーション１１０１と１１１１が実行されており、クライアントからの要求は両方の計算機が受信して処理し、外部に影響を与える処理結果は主系の計算機１１００だけが出力するよう制御されている。二重系制御モジュール１１０３と１１１３は、処理の進行状況を定期的に連絡しあい、双方の計算機の処理の進行状況を一致（同期）させている。

ここで、アプリケーション１１０１と１１１１が、上述した実施形態で説明した強制終了処理を実装している実行時ライブラリ１１０２と１１１２で実行されているとする。主系の計算機１１００で実行されるアプリケーション１１０１は、図１２に示したコードで表現されるモジュールsendLogを実行することで、処理の進行状況を従系１１１０に通知している。

以下、主系である計算機１１００で実行されるアプリケーション１１０１が、障害により異常となり、プロセスの強制終了により系切り替えを実施する例を説明する。

アプリケーション１１０１は、上述した実施形態で説明された例外処理に対応する実行時ライブラリ１１０２で実行されている。このため、アプリケーション１１０１のプロセスを外部から強制終了すると、強制終了の通知処理の中でfinally文が実行され、モジュールsendLogによって主系の最新の処理状況が従系に通知される。この通知の後、主系の計算機１１００は従系の計算機１１１０に異常を通知する。

一方、従系の計算機１１１０では、二重系制御モジュール１１１３が主系の異常を検知して系切り替えを行い、従系の計算機１１１０が主系となって処理を行う。このとき、計算機１１１０で実行するアプリケーションは、それまでに通知された進行状況を元に処理を引き継いで外部への出力処理を開始するが、計算機１１００のアプリケーション１１０１の最新の処理進行状況は、強制終了の中で計算機１１１０に通知されているため、計算機１１１０は最新の状態で処理を引き継ぐことができ、短時間で処理の再開が可能となる。また、最新の情報を引継ぎができるため、古い情報に基づいて引継ぎを実施してしまう可能性を低減できる。

このように、本実施形態によれば、クラスタで実行するアプリケーションが、本発明による構造化例外処理に対応する実行時ライブラリで実行され、アプリケーションに適切な終了処理をfinally文に記述しておけば、並列二重化処理における切り替え処理を高速化でき、信頼性も向上できる。

本発明によれば、構造化例外処理の後処理の部分に、プロセス強制終了時に実施する処理を記述できる。

トランザクション、ログ、ジャーナルによって外部のプログラムで回復する場合、様々な異常の状態を想定した解析をしなければならないため、回復処理が複雑になり、処理にも長い時間がかかる。一方、本発明では、異常時の回復処理を、主たる処理の近くに記述できるため、プロセス強制終了時に必要な回復処理の記述が容易になり、かつ、その回復処理をプロセス強制終了時に実行可能となる。また、例外発生時点の状態の解析が限定されるため、回復処理も簡便になる。これにより、システムを矛盾のない状態に素早く復旧させることが可能となり、システム全体の可用性の向上が期待できる。また、ログやジャーナルといった履歴の記録も不要である。

また本発明によれば、登録されている構造化例外処理のうち、予め指定した処理だけを強制終了時に実行させるように指示できる。これにより、プロセス障害時の後始末処理を、必要な処理だけ確実に実行させることができる。これは、確実なシステム回復に繋がり、システムの可用性を向上する。また、不要な後処理を実行しないため短時間でプロセスを停止でき、システムの復旧時間を短縮できる。

更に、クラスタや並列二重処理を実施する分散計算機システムに本発明を適用すれば、強制終了時の最新の処理状況をディスクやネットワークを通じて、他の計算機に連絡できる。障害によって計算機間で処理を引き継ぐ場合に、最新の処理状況を参照して引継ぎ処理を実行できるため、引継ぎに要する時間を短縮でき、システムの可用性の向上が期待できる。また、古い処理状況に基づいて引き継ぎ処理を実施する可能性も低減できるため、システムの信頼性も向上できる。引継ぎ時間を短縮できるため、高度な応答性が要求されるシステムにおいても有効である。

第一の実施形態の、ＯＳとプロセスの論理的構成例を示す図である。 第一の実施形態の、計算機の構成例を示す図である。 構成例外処理の手順例を示す図である。 第一の実施形態の、データ構造例を示す図である。 第一の実施形態の、プロセスの強制終了処理例を示すフローチャートである。 第一の実施形態の、プロセスの強制終了処理例を示すフローチャートである。 第二の実施形態の、プロセス初期化処理例を示すフローチャートである。 第３の実施形態の、プログラムコード例と、データ構造例を示す図である。 第４の実施形態の、クラスタ構成の計算機システム例を示す図である。 第４の実施形態の、クラスタ構成の計算機システムで実行するアプリケーションのプログラムコード例を示す図である。 第５の実施形態の、並列二重処理構成の計算機システム例を示す図である。 第５の実施形態の、並列二重処理構成の計算機システムで実行するアプリケーションのプログラムコード例を示す図である。

符号の説明

２００…計算機、２０１…ＣＰＵ、２０２…入出力装置、２０３…メモリ、２０４…外部記憶装置、９００…計算機、９０１…アプリケーション、９０５…クラスタ制御モジュール、９２０…共有ディスク。

Claims (13)

1. 計算機においてプロセスを強制終了する方法であって、
   終了対象のプロセスに強制終了の実施を通知し、
   前記プロセスで実行中の処理に付随する特定処理を実行し、
   前記特定処理の終了に応じて、前記プロセスを強制終了することを特徴とする方法。
2. 前記プロセスに強制終了の実施を通知する際に、前記プロセスを実行する実行時ライブラリが前記特定処理の実行が可能かどうかをオペレーティングシステム（以下「OS」）が判断することを特徴とする請求項１記載の強制終了方法。
3. 前記プロセスを強制終了する際に、前記OSが該プロセスで実行されている全てのスレッドの前記特定処理の終了を待って、前記プロセスを強制終了することを特徴とする請求項２記載の強制終了方法。
4. 前記プロセスを強制終了する際に、前記OSが該プロセスで実行されている全てのスレッドの前記特定処理の終了が所定の時間内に完了しない場合、前記所定の時間の経過後、前記プロセスを強制終了することを特徴とする請求項２記載の強制終了方法。
5. 前記プロセスに強制終了の実施を通知する際に、前記OSが、前記プロセスで実行されている任意のスレッドに割り込み、前記任意のスレッドが、前記プロセスで実行されている他のスレッドに対して前記特定処理の実行を割り込み処理を用いて指示することを特徴とする請求項３及び４のうちいずれか一つに記載の強制終了方法。
6. 前記プロセスに強制終了の実施を通知する際に使用するスレッド（以下「強制終了用スレッド」）をあらかじめ前記OSが前記プロセスに対して設定しておき、前記プロセスに強制終了の実施を通知する際に、前記強制終了用スレッドに割り込み、前記強制終了用スレッドが、前記プロセスで実行されている他のスレッドに対して前記特定処理の実行を割り込み処理を用いて指示することを特徴とする請求項３及び４のうちいずれか一つに記載の強制終了方法。
7. 前記特定処理を実行する際に、前記特定処理の記述に従って、所定の特定処理のみを実行することを特徴とする請求項１から６のうち、いずれか一つに記載の強制終了方法。
8. 構造化例外処理に対応するプログラミング言語の実行時ライブラリを実行するプロセスの強制終了に関して、ＯＳがプロセスを強制終了する時に、プロセスの実行する実行時ライブラリにプロセスの強制終了を通知し、実行時ライブラリは通知を受けて、スレッドを操作してプロセス内のスレッドに登録されている構造化例外処理の後処理を実行させることを特徴とする、ＯＳと実行時ライブラリのプロセスの強制終了方法。
9. 第一の計算機と、
   第二の計算機と、
   前記第一の計算機と前記第二の計算機とで共用される記憶装置とを有し、
   前記第一の計算機が強制終了する際、該第一の計算機は、自己が実行するプロセスに強制終了の実施を通知し、前記プロセスで実行中の処理に付随する特定処理を実行し、前記特定処理の終了に応じて、前記プロセスを強制終了して前記第二の計算機に処理を引き継ぐことを特徴とする計算機システム。
10. 前記特定処理とは、前記第一の計算機が有するメモリの前記強制終了時点の内容を前記記憶装置に格納する処理であり、
    前記第二の計算機は、前記処理の引継ぎの際に、前記記憶装置に格納された前記メモリの内容を読み出して処理を引き継ぐことを特徴とする請求項９記載の計算機システム。
11. 第一の計算機と、
    前記第一の計算機とネットワークを介して接続される第二の計算機を有し、
    前記第一の計算機が強制終了する際、該第一の計算機は、自己が実行するプロセスに強制終了の実施を通知し、前記プロセスに付随する特定処理を実行し、前記特定処理の終了に応じて、前記プロセスを強制終了して前記第二の計算機に処理を引き継ぐことを特徴とする計算機システム。
12. 前記特定処理とは、前記第一の計算機の処理経過の内容を前記第二の計算機に前記ネットワークを介して送信する処理であり、
    前記第二の計算機は、前記処理の引継ぎの際に、前記第一の計算機から送信された前記処理経過の内容に基づいて処理を引き継ぐことを特徴とする請求項１１記載の計算機システム。
13. 強制終了時の特定処理を実行するときに、定義されている例外捕獲処理を実施しないことを特徴とする請求項１〜７記載の強制終了方法。
    

Images