JP5215779B2 - 情報処理装置及び情報処理方法 - Google Patents

Description

本発明は、システムリソースリークによる情報処理装置の動作停止を回避するための情報処理技術に関するものである。

一般に、アプリケーションプログラムが実行されると、オペレーティングシステム（ＯＳ）が提供する機能を介して、ファイル、ポート、セマフォ、メモリ等のシステムリソースの確保及び解放といった処理が繰り返し行われる。

このとき、アプリケーションプログラムによって、システムリソースを解放する処理が行われないと、確保したシステムリソースは使用されることなく、無駄に占有され続けることとなる。このような状態を、一般に、システムリソースリーク（資源解放漏れ）と呼ぶ。

システムリソースリークは、ＯＳを再起動することにより、正常な状態に戻すことができるため（つまり、システムリソースリークを解放することができるため）、連続稼動時間が短い装置においては、大きな問題とならない。

しかし、連続稼動時間が長い装置（例えば、工業用製造装置など）においては、システムリソースリークが発生すると、システムリソースが無駄に消費された状態が長時間続くため、場合によっては装置が動作停止することもある。

通常、アプリケーションプログラムは、出荷前のテスト工程においてシステムリソースリークの原因を抽出し、除去される。しかしながら、出荷前のテスト工程でシステムリソースリークの原因を完全に除去することが困難な場合もありえる。

例えば、半導体ウェハの焼き付けを行う半導体露光装置等では、露光条件と手順を記した露光レシピと、装置設定の組み合わせとによって動作が決定される。このため、多量のパラメータを持つうえ、これらのパラメータは、工場ラインの生産計画に基づいて顧客によって設定されるという特徴がある。このため、全てのパラメータの組み合わせをテスト工程にてチェックすることは実際には不可能である。

そこで、このような装置では、仮にシステムリソースリークが発生した場合であっても、動作停止が回避できるような構成としておくことが望ましい。

かかる構成を実現するための方法として、例えば特許文献１では、システムリソースの確保及び解放を検出するための管理プロセスを設けることで、単一プロセスにおけるシステムリソースリークを検出し、解放する方法が提案されている。

また、特許文献２では、各プロセスにおけるシステムリソースの確保及び解放を検出した場合に、検出結果を管理テーブルに登録しておき、所定のプロセス群が終了した時点で、解放されていないシステムリソースの有無を判定する方法が提案されている。
特開２００２−３５８２０４号公報 特開２００６−３３１２１３号公報

しかしながら、上記特許文献１に開示された方法の場合、単一プロセスで確保するシステムリソースに対するシステムリソースリークを検出することは可能であるが、複数プロセスで確保するシステムリソースに対しては、正確に検出することが困難である。

一方、上記特許文献２に開示された方法の場合、複数プロセスが協調して動作する場合でも、システムリソースリークを検出することは可能である。

しかし、管理テーブルに登録された全プロセスが終了した時点でシステムリソースリークの有無を判定する構成としているため、例えば、常駐型のプロセスが存在する場合には、システムリソースリークの有無を正確に判定することができない。

また、ユーザが予め全プロセスを管理テーブルに登録しておくことが必要であるため、アプリケーションプログラムの規模が大きくなり、実行されるプロセス数が膨大になった場合には、ユーザの作業負荷が増大するため、実用的な方法とはいえない。

本発明は、上記課題に鑑みてなされたもので、ユーザの作業負荷を増大させることなく、システムリソースリークを確実に検出し、解放することができる情報処理技術を提供することを目的とする。

上記の目的を達成するために本発明に係る情報処理装置は以下のような構成を備える。即ち、
複数のプロセスが属するジョブを順に実行し、前記プロセスからの要求に従って、システムリソースを管理する情報処理装置であって、
前記ジョブに属するプロセスからシステムリソースを確保する要求があった場合に、該要求に含まれる、該要求元のプロセスが属するジョブに割り当てられた識別子と、システムリソースに関する情報とを対応付けて管理テーブルに格納する第１の格納手段と、
前記ジョブに属するプロセスからシステムリソースを解放する要求があった場合に、該要求に対応するシステムリソースに関する情報を、対応付けられた識別子とともに、前記管理テーブルから削除する削除手段と、
前記ジョブが終了する毎に、前記管理テーブルを参照し、該終了したジョブに割り当てられた識別子が、前記管理テーブルに格納されている場合に、該格納されている識別子に対応付けられた前記システムリソースに関する情報により特定されるシステムリソースを解放する解放手段とを備える。

本発明によれば、ユーザの作業負荷を増大させることなく、システムリソースリークを確実に検出し、解放することができる情報処理技術を提供することが可能となる。

以下、図面を参照しながら、本発明の好適な実施の形態について説明する。

［第１の実施形態］
１．情報処理装置の構成
はじめに、本発明の一実施形態にかかる情報処理装置の構成について説明する。図１は、本発明の一実施形態にかかる情報処理装置１００の構成を示す図である。

図１において、１０１はメモリ（ＲＯＭ）、１０２は中央演算処理装置（ＣＰＵ）、１０３はメモリ（ＲＡＭ）、１０４は入力装置、１０５は出力装置、１０６は外部記憶装置、１１０はバスである。

外部記憶装置１０６には、システムリソースを確保する機能を提供するＯＳ１０７と、システムリソースを管理するシステムリソース管理モジュール１０８と、複数のジョブから構成されるアプリケーションプログラム１０９が格納されている。

これらのプログラム等は、中央演算処理装置（ＣＰＵ）１０２の制御のもと、バス１１０を通じて適宜メモリ（ＲＡＭ）１０３に取り込まれ、中央演算処理装置１０２によって実行される。

２．システムリソース管理機能の機能構成
図２は、情報処理装置１００において実現されるシステムリソース管理機能の機能構成を示す図である。図２に示すように、システムリソース管理機能は、システムリソース２５０と、システムリソース２５０の確保／解放を要求するアプリケーションプログラム１０９と、システムリソース２５０を管理するシステムリソース管理モジュール１０８により実現される。

アプリケーションプログラム１０９は、複数のジョブ２４０から構成され、それぞれのジョブ２４０は、常駐型プロセス２４１または非常駐型プロセス２４２の一方または両方を備える。なお、ここでいう「プロセス」とは、プログラムが実行されることにより生成される、システムリソースを使う処理における実行の最小単位であり、プログラムをＣＰＵ側から見た処理単位をいう。また、「ジョブ」とは、ユーザ側から見た、コンピュータで処理させる、ひとまとまりの仕事の単位をいう。

また、本実施形態において、常駐型プロセス２４１とは、情報処理装置１００起動時に起動され、情報処理装置１００停止時に消滅するプロセスのことをいい、他のプロセスからのメッセージ受信などをきっかけに処理が開始されるプロセスをいう。また、非常駐型プロセス２４２とは、処理開始時に起動し、処理終了時に消滅するプロセスのことをいう。

なお、本実施形態において、ジョブ２４０は、実行毎に実行ＩＤ（以下、ジョブ実行ＩＤと呼ぶ）が割り当てられるものとする。ジョブ２４０内の常駐型プロセス２４１と非常駐型プロセス２４２は、該当処理実行時に、ジョブ実行ＩＤが通知されることを特徴とする。

システムリソース２５０には、ジョブ２４０実行毎に常駐型プロセス２４１、もしくは、非常駐型プロセス２４２が確保するメモリ２５１、ポート２５２、ファイル２５３などが含まれる。

システムリソース管理モジュール１０８は、システムリソース管理プログラム２２０と、管理テーブル２３０から構成される。

管理テーブル２３０は、システムリソース２５０の確保／解放を登録する（つまり、管理対象を決定する）ための登録条件が規定されたシステムリソース管理対象外条件管理テーブル（条件テーブル）２３２を備える（第２の格納手段）。ここで、管理対象を決定するための登録条件とは、具体的には、システムリソース情報管理テーブル２３１に登録しないシステムリソース２５０に関する規定である。

また、管理テーブル２３０は、システムリソース情報管理テーブル２３１を備える（第１の格納手段）。システムリソース情報管理テーブル２３１には、管理対象のシステムリソース２５０に関する情報及びシステムリソース２５０を確保した箇所のファイル名（クラス名）、関数名などのソースコード情報が格納／削除される。これにより、管理対象のシステムリソース２５０の確保／解放がシステムリソース情報管理テーブル２３１に登録される。なお、管理テーブル２３０の詳細は後述する。

システムリソース管理プログラム２２０は、アプリケーションプログラム１０９からの指示に基づいて、不図示のＯＳが提供する機能を介して、システムリソース２５０の確保／解放を実行させるためのプログラムである。

具体的には、システムリソース管理機構２２３と、システムリソースリーク検出機構２２１と、システムリソースリーク情報通知機構２２２とから構成され、それぞれ、以下のような動作を実行する。

（１）システムリソース管理機構２２３
不図示のＯＳが提供する機能を介して、システムリソース２５０の確保／解放を行う。確保の際には、システムリソース管理対象外条件管理テーブル２３２を参照し、条件に一致しない場合のみ、該当するジョブ実行ＩＤとシステムリソース２５０に関する情報とソースコード情報とを対応付けてシステムリソース情報管理テーブル２３１に格納する。また、解放の際は、該当するジョブ実行ＩＤとシステムリソース２５０に関する情報とソースコード情報とをシステムリソース情報管理テーブル２３１から削除する。

（２）システムリソースリーク検出機構２２１
ジョブ２４０の実行が終了するごとに、システムリソース情報管理テーブル２３１を参照し、該ジョブ２４０内の常駐型プロセス２４１、もしくは、非常駐型プロセス２４２が確保したシステムリソース２５０に関する情報が格納されているか否かを判断する。そして、システムリソース２５０に関する情報が格納されていると判断した場合に、システムリソースリークと判断し、システムリソース管理機構２２３に対して、該システムリソース２５０を解放するよう指示する。また、システムリソースリーク情報通知機構２２２に対して、システムリソースリークが発生した旨を通知する。

（３）システムリソースリーク情報通知機構２２２
ジョブ２４０の実行が終了した際に、システムリソースリーク検出機構２２１より、システムリソースリークが発生した旨の通知を受けた場合に、該当するソースコード情報をユーザ（例えば、プログラム開発者）に通知する。

３．管理テーブルの構成
次に、管理テーブル２３０の詳細について説明する。

３．１ システムリソース情報管理テーブルの構成
図３は、システムリソース情報管理テーブル２３１の一例を示す図である。図３に示すように、システムリソース情報管理テーブル２３１には、ジョブ実行ＩＤ３０１とシステムリソースに関する情報３０２とソースコード情報３０３とがそれぞれ対応付けて登録される。

なお、システムリソースに関する情報３０２には、システムリソース種別３０２−１とシステムリソースＩＤ３０２−２とが含まれ、ソースコード情報３０３には、ファイル名３０３−１、関数名３０３−２とが含まれる。

なお、システムリソース情報管理テーブル２３１では、ジョブ実行ＩＤ毎に、システムリソース種別と、システムリソースＩＤと、システムリソースを確保した箇所を特定するソースコード情報（ファイル名や関数名等）が管理できるよう構成されていればよい。このため、図３に示すフォーマットに限定されるものではない。

なお、例えば、システムリソース管理機構２２３が、ＯＳが提供するシステムコールを実行することでシステムリソースを確保した場合には、システムリソースＩＤ３０２−２には、システムコールの戻り値が格納されることとなる。具体的には、システムリソースがファイルの場合にはファイルディスクリプタが、メモリの場合には確保領域の先頭アドレスが格納されることとなる。

３．２ システムリソース管理対象外条件管理テーブルの構成
図４は、システムリソース管理対象外条件管理テーブル２３２の一例を示す図である。図４に示すように、システムリソース管理対象外条件管理テーブル２３２には、システムリソース情報管理テーブル２３１にて管理しないシステムリソース２５０の条件（管理対象外条件４０２）が、システムリソース種別４０１毎に規定されている。

なお、システムリソース管理対象外条件管理テーブル２３２のフォーマットは図４に示すフォーマットに限定されるものではない。

４．システムリソース管理プログラムによるシステムリソース管理処理の流れ
次に、システムリソース管理プログラム２２０によるシステムリソース管理処理の流れについて説明する。

３．１ 全体処理の流れ
図５は、システムリソース管理プログラム２２０によるシステムリソース管理処理の流れを示すフローチャートである。

ステップＳ５０１では、システムリソースリーク検出機構２２１が、ジョブ２４０から処理終了要求が通知されているか否か判定する。ジョブ２４０は、処理終了後、処理終了通知をシステムリソースリーク検出機構２２１へ通知する。

処理終了要求が通知されていると判定した場合には、ステップＳ５０６へ進む。一方、通知されていないと判定された場合には、ステップＳ５０２へ進む。

なお、ジョブ２４０から通知される処理終了要求には、少なくともジョブ実行ＩＤが含まれているものとする。また、通知は、例えば、メッセージ通信や、システムリソースリーク検出機構２２１が提供する関数（例えば、図９参照）などを利用して行われるものとする。ただし、本発明は、これに限定されるものではない。

ステップＳ５０２では、システムリソース管理機構２２３が、実行中のジョブ２４０内の常駐型プロセス２４１、もしくは、非常駐型プロセス２４２からシステムリソース確保要求が通知されているか否か判定する。

システムリソース確保要求が通知されていると判定した場合には、ステップＳ５０３へ進み、通知されていないと判定した場合には、ステップＳ５０４へ進む。

なお、システムリソース確保要求には、少なくともジョブ実行ＩＤ、常駐型プロセス２４１または非常駐型プロセス２４２に関する情報、確保するシステムリソース２５０に関する情報、ソースコード情報が含まれているものとする。また、通知は、例えば、メッセージ通信や、システムリソース種別毎にシステムリソース管理機構２２３が提供するシステムリソース確保関数（例えば、図１０参照）などを利用して行われるものとする。ただし、本発明はこれに限定されるものではない。

なお、常駐型プロセス２４１または非常駐型プロセス２４２に関する情報は、システムリソース確保処理（処理内容詳細は後述）における判定において用いられる。このため、常駐型プロセス２４１または非常駐型プロセス２４２を一意に識別できる情報であればよい。本実施形態では、プログラム開発時に割り当てた識別子（ＯＳが動的に割り当てるプロセスＩＤとは異なる）を利用するものとする。

また、システムリソース２５０に関する情報には、ファイル名、確保するメモリサイズ等、システムリソース管理機構２２３がシステムリソース確保処理（処理内容詳細は後述）にてシステムリソース２５０を確保する際に用いられる情報が含まれていればよい。

また、ソースコード情報には、システムリソース２５０を確保したソースコードの箇所が特定できる情報が含まれていればよい。本実施形態では、ファイル名、関数名が含まれているものとする。

ステップＳ５０３では、システムリソース管理機構２２３が、システムリソース確保処理（処理内容詳細は後述）を行う。システムリソース確保処理（ステップＳ５０３）が実行されることにより、常駐型プロセス２４１または非常駐型プロセス２４２では、確保されたシステムリソース２５０に関する情報（システムリソースＩＤ３０２−２）を取得する。

ステップＳ５０４では、システムリソース管理機構２２３が、常駐型プロセス２４１または非常駐型プロセス２４２プロセスからシステムリソース解放要求が通知されているか否かを判定する。

システムリソース２５０解放要求が通知されていると判定した場合には、ステップＳ５０５へ進み、通知されていないと判定した場合には、ステップＳ５０１へ進む。

なお、常駐型プロセス２４１または非常駐型プロセス２４２から通知されるシステムリソース解放要求には、少なくともシステムリソースＩＤが含まれているものとする。また、通知は、例えば、メッセージ通信や、システムリソース種別毎にシステムリソース管理機構２２３が提供するシステムリソース解放関数（例えば、図１１参照）などを利用して行われるものとする。ただし、本発明はこれに限定されるものではない。

ステップＳ５０５では、システムリソース管理機構２２３が、システムリソース解放処理（処理内容詳細は後述）を行う。システムリソース解放処理（ステップＳ５０５）が実行されることにより、常駐型プロセス２４１または非常駐型プロセス２４２では、システムリソース２５０の解放結果を取得する。

一方、ステップＳ５０６では、システムリソースリーク検出機構２２１が、システムリソースリーク解放処理（処理内容詳細は後述）を行う。

４．２ システムリソース確保処理の流れ
次に、ステップＳ５０３のシステムリソース確保処理の詳細について説明する。図６は、システムリソース確保処理の詳細を示すフローチャートである。

ステップＳ６０１では、システムリソース管理機構２２３が、通知されたシステムリソース２５０に関する情報に基づき、対応するシステムリソース２５０を確保する。具体的には、ＯＳが提供するシステムコールを実行するものとする。ただし、本発明はこれに限定されるものではない。

ステップＳ６０２では、システムリソース管理機構２２３が、システムリソース管理対象外条件管理テーブル２３２を参照し、通知された各種情報に一致する条件が規定されているか否か判定する。

一致する条件が規定されていると判定した場合には、ステップＳ６０４へ進み、一致する条件が規定されていないと判定した場合には、ステップＳ６０３へ進む。

例えば、システムリソース２５０に関する情報として、ファイル名＝“ＬＯＧ_００１.ｌｏｇ”が通知された場合は、図４に基づいて管理対象外条件４０２に一致する条件が規定されていると判定する。このため、確保したシステムリソース（この場合は、ファイル）は、システムリソース情報管理テーブル２３１による管理対象外となる。

ステップＳ６０３では、システムリソース管理機構２２３が、システムリソース情報管理テーブル２３１に、ジョブ実行ＩＤ、システムリソース２５０に関する情報、ソースコード情報を対応付けて登録する。

ステップＳ６０４では、システムリソース管理機構２２３が、システムリソースＩＤをシステムリソース確保処理の要求元へ通知し、システムリソース確保処理を終了する。なお、通知は、例えば、メッセージ通信や、システムリソース種別毎にシステムリソース管理機構２２３が提供するシステムリソース確保関数（例えば、図１０参照）の戻り値などを利用して行われるものとする。ただし、本発明はこれに限定されるものでない。

４．３ システムリソース解放処理の流れ
次に、ステップＳ５０５におけるシステムリソース解放処理の詳細について説明する。図７は、システムリソース解放処理の詳細を示すフローチャートである。

ステップＳ７０１では、システムリソース管理機構２２３が、通知されたシステムリソースＩＤに基づき、該当するシステムリソース２５０を解放する。具体的には、ＯＳが提供するシステムコールを実行するものとする。ただし、本発明はこれに限定されるものではない。

ステップＳ７０２では、システムリソース管理機構２２３が、通知されたシステムリソースＩＤが、システムリソース情報管理テーブル２３１に格納されているか否か判定する。格納されていると判定した場合には、ステップＳ７０３へ進み、格納されていないと判定した場合には、ステップＳ７０４へ進む。

ステップＳ７０３では、システムリソース管理機構２２３が、通知されたシステムリソースＩＤが格納されているレコードをシステムリソース情報管理テーブル２３１から削除する。

ステップＳ７０４では、システムリソース管理機構２２３が、システムリソース２５０の解放結果（解放成功、もしくは解放失敗）をシステムリソース解放処理の要求元へ通知し、システムリソース確保処理を終了する。

なお、通知は、例えば、メッセージ通信や、システムリソース種別毎にシステムリソース管理機構２２３が提供するシステムリソース解放関数（例えば、図１１参照）の戻り値などを利用して行われるものとする。ただし、本発明はこれに限定されるものでない。

４．４ システムリソースリーク解放処理の流れ
次に、ステップＳ５０６におけるシステムリソースリーク解放処理の詳細について説明する。

図８は、システムリソースリーク解放処理の詳細を示すフローチャートである。

ステップＳ８０１では、システムリソースリーク検出機構２２１が、システムリソース情報管理テーブル２３１を参照する。そして、ステップＳ５０１で取得したジョブ実行ＩＤ（ジョブ終了要求があったジョブのジョブ実行ＩＤ）が格納されているレコードが存在するか否か判定する。

該当するレコードが存在すると判定した場合には、システムリソースリークが発生していると判定し、ステップＳ８０２へ進む。該当するレコードが存在しないと判定した場合には、システムリソースリークが発生していないと判定し、システムリソースリーク解放処理を終了する。

ステップＳ８０２では、システムリソースリーク情報通知機構２２２が、システムリソース情報管理テーブル２３１に格納されている各種情報をユーザ（例えば、プログラム開発者）へ通知する。なお、通知内容には、解放できていないシステムリソース２５０に関する情報（例えば、ファイル名、ポート番号等）が含まれているものとする。また、該当するシステムリソース２５０を確保したソースコードの箇所が特定できるソースコード情報（例えば、ファイル名、関数名など）が含まれているものとする。ただし、本発明は、これらに限定されるものではない。また、通知は、例えば、メールにより行われるものとするが、これに限定されるものではない。

ステップＳ８０３では、システムリソースリーク検出機構２２１が、ステップＳ５０１で取得したジョブ実行ＩＤに関する全てシステムリソース２５０の解放が完了したか否か判定する。完了していないと判定した場合には、ステップＳ８０４へ進み、完了していると判定した場合には、システムリソースリーク解放処理を終了する。

ステップＳ８０４では、システムリソースリーク検出機構２２１が、システムリソース情報管理テーブル２３１に登録されているシステムリソースＩＤに基づき、システムリソースリークを解放する。処理内容は、図５のステップＳ５０５と同様であるため、詳細は省略する。

以上の説明から明らかなように、本実施形態では、プロセスからの要求に従って、確保／解放が行われるシステムリソースに関する情報を、管理テーブルに格納することで管理する構成とした。また、ジョブの実行が終了するごとに、当該管理テーブルにより管理されているシステムリソースについて、システムリソースリークの発生の有無を判断する構成とした。更に、システムリソースリークが発生していると判断した場合には、ジョブの実行が終了した際に、システムリソースリークを解放する処理を行う構成とした。

この結果、管理テーブルに予め全プロセスを登録しておく必要がなくなり、ユーザの作業負荷を低減させることが可能となった。また、複数プロセスで確保するシステムリソースが存在する場合であっても、システムリソースリークを正確に検出することが可能となった。更に、システムリソースリークが発生した場合であっても、ジョブの実行が完了するごとに、システムリソースリークの解放処理が行われるため、情報処理装置の動作停止を確実に回避することが可能となった。

［他の実施形態］
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェース機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録したコンピュータ読取可能な記憶媒体を、システムあるいは装置に供給するよう構成することによっても達成されることはいうまでもない。この場合、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することにより、上記機能が実現されることとなる。なお、この場合、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現される場合に限られない。例えば、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、前述した実施形態の機能が実現される場合も含まれる。つまり、プログラムコードがメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって実現される場合も含まれる。

本発明の一実施形態にかかる情報処理装置１００の構成を示す図である。 情報処理装置１００において実現されるシステムリソース管理機能の機能構成を示す図である。 システムリソース情報管理テーブル２３１の一例を示す図である。 システムリソース管理対象外条件管理テーブル２３２の一例を示す図である。 システムリソース管理プログラム２２０によるシステムリソース管理処理の流れを示すフローチャートである。 システムリソース確保処理の詳細を示すフローチャートである。 システムリソース解放処理の詳細を示すフローチャートである。 システムリソースリーク解放処理の詳細を示すフローチャートである。 システムリソースリーク検出機構２２１が提供する関数の一例を示す図である。 システムリソース管理機構２２３が提供するシステムリソース２５０の確保関数の一例を示す図である。 システムリソース管理機構２２３が提供するシステムリソース２５０の解放関数の一例を示す図である。

Claims (6)

1. 複数のプロセスが属するジョブを順に実行し、前記プロセスからの要求に従って、システムリソースを管理する情報処理装置であって、
   前記ジョブに属するプロセスからシステムリソースを確保する要求があった場合に、該要求に含まれる、該要求元のプロセスが属するジョブに割り当てられた識別子と、システムリソースに関する情報とを対応付けて管理テーブルに格納する第１の格納手段と、
   前記ジョブに属するプロセスからシステムリソースを解放する要求があった場合に、該要求に対応するシステムリソースに関する情報を、対応付けられた識別子とともに、前記管理テーブルから削除する削除手段と、
   前記ジョブが終了する毎に、前記管理テーブルを参照し、該終了したジョブに割り当てられた識別子が、前記管理テーブルに格納されている場合に、該格納されている識別子に対応付けられた前記システムリソースに関する情報により特定されるシステムリソースを解放する解放手段と
   を備えることを特徴とする情報処理装置。
2. 前記管理テーブルへ格納するための条件を規定した条件テーブルを格納する第２の格納手段を更に備え、
   前記第１の格納手段は、前記システムリソースを確保する要求があった場合に、前記条件テーブルに規定された条件に基づいて、格納するか否かを決定することを特徴とする請求項１に記載の情報処理装置。
3. 前記第１の格納手段は、前記識別子と対応付けて、前記システムリソースを確保した箇所を示すソースコード情報を格納することを特徴とする請求項１に記載の情報処理装置。
4. 前記管理テーブルに格納されている場合に、該格納されている識別子に対応付けられた前記システムリソースに関する情報と前記ソースコード情報とを、ユーザに通知する通知手段を更に備えることを特徴とする請求項３に記載の情報処理装置。
5. 複数のプロセスが属するジョブを順に実行し、前記プロセスからの要求に従って、システムリソースを管理する情報処理装置における情報処理方法であって、
   格納手段が、前記ジョブに属するプロセスからシステムリソースを確保する要求があった場合に、該要求に含まれる、該要求元のプロセスが属するジョブに割り当てられた識別子と、システムリソースに関する情報とを対応付けて管理テーブルに格納する格納工程と、
   削除手段が、前記ジョブに属するプロセスからシステムリソースを解放する要求があった場合に、該要求に対応するシステムリソースに関する情報を、対応付けられた識別子とともに、前記管理テーブルから削除する削除工程と、
   判断手段が、前記ジョブが終了する毎に、前記管理テーブルを参照し、該終了したジョブに割り当てられた識別子が、前記管理テーブルに格納されている場合に、該格納されている識別子に対応付けられた前記システムリソースに関する情報により特定されるシステムリソースを解放する解放工程と
   を備えることを特徴とする情報処理方法。
6. コンピュータを、請求項１乃至４のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラムを格納したコンピュータ読取可能な記憶媒体。

Images