JP2002505465A - 分散処理システムにおいて記憶領域をリースするための方法及びシステム - Google Patents

Abstract

(57)【要約】 【目的】分散処理システムにおいて記憶領域のロケーションをリースする方法及びシステムを提供すること。 【解決手段】本発明に係る方法及びシステムによれば、クライアントは、所定時間の間、システムマネーシ゛ャなどのサーハ゛から記憶領域のロケーションにアクセスするための要求を送出する。これ応答して、サーハ゛は、リースヒ゜リオト゛アルコ゛リス゛ムを呼出し、更に、クライアントが記憶領域のロケーションにどのようなタイミンク゛・長さでアクセスするのかというリースヒ゜リオト゛を決定するために種々の要因を検討する。リースの許可後、サーハ゛は、オフ゛シ゛ェクトをクライアントに送信し、そのオフ゛シ゛ェクトは、クライアントにリースヒ゜リオト゛を報知するとともにクライアントにそのリースを修正するためのふるまい、例えば、リース解除又はリース更新といったふるまいを配信する。サーハ゛は、競合するリース、正確なリース、種々のアクセスタイフ゜のリースをサホ゜ートする。記憶領域のロケーションへの全リースの終了後、サーハ゛は記憶領域のロケーションを再び要求する。

Description

【発明の詳細な説明】

【０００１】 （関連出願） 参考のために示すが、本出願は、1996年10月11日提出の米国特許出願No.08/72
9,421の一部継続出願である。 以下に示した参考としての米国特許出願は、本特許出願の根拠となる。 1998年2月26日出願の米国特許仮出願No.60/076,048、発明の名称「分散コンピ
ュータシステム」。 同日出願の米国特許出願No.09/044,838、発明の名称「分散システムにおけるD
elegationCertificatesのリースに用いられる方法、装置及びプロダクト」（代 理人整理番号No.06502.0011-02000）。 同日出願の米国特許出願No.09/044,834、発明の名称「分散システムにおける グループメンバシップのリースに用いられる方法、装置及びプロダクト」（代理
人整理番号06502.0011-03000）。 同日出願の米国特許出願No.09/044,916、発明の名称「故障検出のためのリー ス」（代理人整理番号No.06502.0011-04000）。 同日出願の米国特許出願No.09/044,933、発明の名称「イベントに基づくシス テムにおける振るまい転送方法」（代理人整理番号no.06502.0054-00000）。 同日出願の米国特許出願No.09/044,919、発明の名称「オブジェクトの据え置 き型再構築と分散システムにおけるイベント通知用の遠隔ロード」（代理人整理
番号No.06502.0062-01000）。 同日出願の米国特許出願No.09/044,938、発明の名称「遠隔メソッド呼出用の 方法及び装置」（代理人整理番号No.06502.0102-00000）。 同日出願の米国特許出願No.09/045,652、発明の名称「遠隔メソッドを識別す るための決定論的ハッシュのための方法及びシステム」（代理人整理番号No.065
02.0103-00000）。 同日出願の米国特許出願No.09/044,790、発明の名称「分散システムにおける 遠隔オブジェクトのステータスを判断するための方法及び装置」（代理人整理番
号No.06502.0104-00000）。 同日出願の米国特許出願No.09/044,930、発明の名称「分散システムにおいて 遠隔手続コールに関連付けられた処理を実行するためのダウンロード可能なスマ
ートプロキシ」（代理人整理番号No.06502.0105-00000）。 同日出願の米国特許出願No.09/044,917、発明の名称「遠隔メソッドの停止及 び継続」（代理人整理番号No.06502.0106-00000）。 同日出願の米国特許出願No.09/044,835、発明の名称「データベースにおける マルチエントリ及びマルチテンプレートのマッチングのための方法及びシステム
」（代理人整理番号No.06502.0107-00000）。 同日出願の米国特許出願No.09/044,839、発明の名称「データベースにおける インプレイス・モディフィケーションのための方法及びシステム」（代理人整理
番号No.06502.0108）。 同日出願の米国特許出願No.09/044,945、発明の名称「データベースにおける タイプセイフ属性マッチングのための方法及びシステム」（代理人整理番号No.0
6502.0109-00000）。 同日出願の米国特許出願No.09/044,931、発明の名称「分散システムにおける ダイナミック検索サービス」（代理人整理番号No.06502.0110-00000）。 同日出願の米国特許出願No.09/044,939、発明の名称「分散システムのデバイ スとの情報通信用のダウンロード可能なコードを提供する装置及び方法」（代理
人整理番号No.06502.0112-00000）。 同日出願の米国特許出願No.09/044,826、発明の名称「検索サービスへのアク セスを容易にするための方法及びシステム」（代理人整理番号No.06502.0109-00
000）。 同日出願の米国特許出願No.09/044,932、発明の名称「分散システムにおいて ダイナミックに情報をベリファイするための装置及び方法」（代理人整理番号No
.06502.0114-00000）。 1998年2月26日出願の米国特許出願No.09/030,840、発明の名称「ネットワーク
上におけるダイナミックな分散コンピューティングをするための方法及び装置」
。 同日出願の米国特許出願No.09/044,936、発明の名称「永続的な共有メモリ空 間のための対話型設計ツール」（代理人整理番号No.06502.0116-00000）。 同日出願の米国特許出願No.09/044,934、発明の名称「多相型トークンに基づ く制御」（代理人整理番号No.06502.0117-00000）。 同日出願の米国特許出願No.09/044,915、発明の名称「スタックに基づくアク セス制御」（代理人整理番号No.06502.0118-00000）。 同日出願の米国特許出願No.09/044,944、発明の名称「スタックに基づく安全 性要求」（代理人整理番号No.06502.0119-00000）。 同日出願の米国特許出願No.09/044,837、発明の名称「安全性要求のメソッド の指定」（代理人整理番号No.06502.0120-00000）。

【０００２】 （背景技術） Ａ．発明の属する技術分野 本発明は、データ処理システムに関し、更に詳しくは、データ処理システムに
おける記憶領域のリースに関する。

【０００３】 Ｂ．関連技術の説明 完全なリソース管理は、コンピュータを効率的且つ効果的に利用するために重
要な要素である。一般的には、リソース管理は、リクエストに応じたリソース（
例えば、メモリ）の割当と、リクエスタがもはやリソースを要求しない場合等に
おける適当なタイミングでのリソースの割当解除とを含む。一般的には、リソー
スは、コンピュータ内で実行されるコンピュータ演算可能なエンティティ（例え
ば、アプリケーション、プログラム、アプレット等）により参照されるデータを
保持する。

【０００４】 実際には、コンピュータ上で実行するアプリケーションがリソースを参照する
ためにシークする時に、アプリケーションが完全にそれらを参照することができ
るようにするために、コンピュータは、まず最初にリソースを割当又は指定しな
ければならない。アプリケーションがもはやリソースを参照しない時は、コンピ
ュータは、リソースを再使用するために割当解除又は再生することができる。コ
ンピュータの各リソースは、特定の"ハンドル"を有しており、これによって、リ
ソースは参照可能なのである。ハンドルは、種々の方法、例えば、アドレス、配
列インデックス、ユニーク値、ポインタ等により実装することができる。

【０００５】 リソース管理は、単一コンピュータでは比較的簡単である。その理由は、リソ
ースが再生されえる時、例えば、アプリケーションがもはやそれらを参照しなく
なった場合や電源に異常が発生した場合を示すイベントが判断しやすいからであ
る。複数コンピュータを連結した分散システム用のリソース管理は、より難しい
。その理由は、種々の異なるコンピュータのアプリケーションが同一のリソース
を使用するからである。

【０００６】 分散システムにおけるディスコネクトは、不完全且つ時期尚早なリソースの再
生か、又は、リソースの再生不良を引きおこす場合がある。例えば、分散型シス
テムの異なるコンピュータ上で動作する複数アプリケーションは、他のマシン上
に配置されたリソースを参照することもできる。リソースが配置されているコン
ピュータと、それらのリソースを参照するアプリケーションとの間のコネクショ
ンが絶たれると、コンピュータは時期尚早にリソースを再生することになる。或
いは、コンピュータは、アプリケーションがリソースへのアクセスを失敗すると
、延長ピリオドになっても永久にリソースを維持することになる。

【０００７】 これらの問題を解決するために、ネットワークリソースを管理するためのシス
テムが開発され、その一つが"分散型ガベージコレクション"として周知である。
分散型ガベージコレクションは、分散型システム用の言語又はランタイムシステ
ムにより提供される機能を記述し、種々のネットワークコンピュータにおいて動
作する単一又はグループのアプリケーションにより使用されるリソースを自動的
に管理する。

【０００８】 一般的には、ガベージコレクションは、リソースがもはやアプリケーションの
どの部分からも参照されなくなったときに、リソースを後の使用のために解放さ
せるという概念を用いている。分散型ガベージコレクションは、分散型コンピュ
ーティングの領域にこの概念を拡張して、あらゆるコンピュータ上のアプリケー
ションが一つもリソースを参照しなくなったときにリソースを再生する。

【０００９】 分散型ガベージコレクションは、割当リソースとそれらのリソースへのリファ
レンスとの間の保全性を維持しなければならない。換言すれば、ネットワークの
コンピュータ上で走行するアプリケーションがそのリソースを参照し続ける限り
、システムはリソースの解放又は割当解除を行うことを許可されていない。この
リファレンス−リソースのバインドは、"リファレンスの保全性"と称されるが、
リファレンスが参照するリソースに当該リファレンスが常にアクセスすることを
許可することを保障するものではない。例えば、ネットワーク障害によりアクセ
スが不可能となる。しかしながら、保全性は、リファレンスを使用してあらゆる
リソースへアクセスすることができるならば、リファレンスが最初に付与された
リソースと同一リソースとなることを保障する。

【００１０】 ガベージコレクションを使用する分散型システムは、更に、リソースが制限時
間内に参照されない場合には、リソースを再生しなければならない。換言すれば
、システムは、"メモリリーク"に対し保障しなければならない。メモリリークは
、全てのアプリケーションがリソースに対するリファレンスを怠ったときに発生
するものであるが、例えば、いくつかのアプリケーションがそのリソースを参照
中であるという誤った判断が原因になって、システムは再使用を目的とするリソ
ースの再生に失敗する。

【００１１】 リファレンスの保全性の故障及びメモリリークは、リソースを参照するアプリ
ケーションと、それらのリソースの割当・割当解除を管理するガベージコレクシ
ョンシステムとの間のディスコネクトに起因することが多い。例えば、リソース
を参照するアプリケーションと、上述のリソースを管理するガベージコレクショ
ンシステムとの間のネットワークコネクション内のディスコネクトは、ガベージ
コレクションシステムがそのリソースを再生すべきか否か・いつ再生すべきかと
いうことを判断するのを妨害する。あるいは、ガベージコレクションシステムは
、アプリケーションが所定時間内にリソースにアクセスしなかったということを
理由として、誤ってそのリソースを収集してしまうという判断をすることもある
。分散型ガベージコレクションのメカニズムを改良するために、多くの技術が利
用されており、例えば、メモリリークを発生させずにリファレンスの保全性を維
持するメカニズムを確保しようとの試みがなされている。従来のアプローチの一
つとして、参照回数を数えるという形態を利用したものがあるが、そのカウント
は、互いのリソースを参照しているアプリケーションの数を数えることによって
なされるものである。リソースのカウント数がゼロになった時にガベージコレク
ションシステムはそのリソースを再生することができる。しかしながら、このよ
うなリファレンスカウント概念による機能は、リソースが対応するリファレンス
カウンタにより生成された場合にのみ有効である。この場合におけるガベージコ
レクションシステムは、リソースのリファレンスカウントをそのリソースを参照
するアプリケーションの数が追加されるに従って増加させ、アプリケーションが
そのリソースを参照しなくなったときに減少させるというものである。

【００１２】 しかしながら、リファレンスカウント概念は、とりわけ、分散型システム内で
起こり得る故障に直面しやすいという問題を引き起こす。このような故障は、リ
ソースが参照されなくなったガベージコレクションシステムを通知するメッセー
ジの配信を妨害するというコンピュータ又はアプリケーションの故障又はネット
ワークの故障という形態をとることができる。メッセージがネットワークのディ
スコネクトにより配信されなかった場合には、ガベージコレクションシステムは
、いつそのリソースを再生すべきかが判断できなくなる。

【００１３】 このような故障を防止するため、従来のリファレンスカウント概念は、"キー プアライブ"のメッセージを含み、それは、"ピングバック"とも称される。この 概念によれば、ネットワーク内のアプリケーションは、リソースを監視するガベ
ージコレクションシステムにメッセージを送信し、アプリケーションがまだ通信
可能であることを示す。これらのメッセージは、ガベージコレクションシステム
がリソースへの参照を抜かしてしまうのを防止する。このような"キープアライ ブ"のメッセージの受信の故障により、ガベージコレクションシステムは、リソ ースへのリファレンスカウントを減少させることができ、そのカウントがゼロに
なると、ガベージコレクションシステムはリソースを再生する。しかしながら、
このことは、ネットワークの故障に端を発した後、"キープアライブ"のメッセー
ジの受信の失敗に起因してリファレンスカウントがゼロになり、結局、時期尚早
のリソース再生という結果を招く。従って、リファレンスの保全性は確保されな
い。

【００１４】 ガベージコレクションシステムにおけるリファレンスの保全性に関する問題を
解決するために、リファレンス回数を保持するだけでなく、更に、リソースを参
照するコンピュータ演算可能な各エンティティに対応する識別子を保持するとい
う他の手法が提案されている。例えば、エイ・ビレル等による"ネットワークオブ
ジェクト用の分散型ガベージコレクション"（No.116デジタルシステムリサーチ センター、1993年12月15日）を参照されたい。この方法は、上述のリファレンス
カウント概念と同様の問題を有するものである。更に、この方法によれば、各リ
ソースを参照するコンピュータ演算可能な各エンティティ用のユニーク識別子の
追加が必要となり、これにより、分散型システム内の通信を不必要に増加させる
オーバーヘッドを追加することになり、記憶領域の追加が必要となる（すなわち
、各リソースを参照するアプリケーションに対応する識別子リスト）。

【００１５】 （発明の開示） 本発明によれば、リファレンスの保全性は、所定ピリオドの間、リソースをリ
ースすることにより、コスト高を招くメモリリークを起こすことなく保障される
。その間、分散型システム内の集合、例えば、リソースへのリファレンスを管理
するアプリケーション、そのリソースを管理するガベージコレクションシステム
等がそのリソースを承認すると、そのリソースへのリファレンスが保障される。
リースピリオドの終わりには、リソースへのリファレンスを継続する保障がなく
なり、ガベージコレクションシステムはリソースを再生することが可能になる。
リソースへのリファレンスを保持するアプリケーションとリソースを管理するガ
ベージコレクションシステムとが保障且つ制限されたリースピリオドを承認する
ため、両者は、リース及び保障がいつ終了するかを認識することができる。これ
により、リファレンスのリース期間内においては、リファレンスの保全性が保障
され、ネットワークエラーによるリソース解放の失敗の原因となることが回避さ
れる。リーステクニックは、メモリのみならず他のタイプの記憶領域、例えば、
記憶領域の周辺機器にも適用できる。

【００１６】 本発明に係る他の実施の形態は、ここに具体的且つ広い概念で説明されるよう
に、記憶領域のロケーションをリースする方法を提供するものである。この方法
は、記憶領域のロケーションとリースピリオドとを指定する発呼者からのリクエ
ストを受信する工程と、発呼者が指定された記憶領域のロケーションへアクセス
するリースピリオドを決定する工程と、許可されたリースピリオドを発呼者に通
知する工程と、発呼者がその決定されたリースピリオドの間、記憶領域のロケー
ションへアクセスするのを許可する工程と、からなることを要旨とするものであ
る。

【００１７】 （発明を実施するための最良の形態） 以下に、本発明の一実施の形態の詳細について添付図面を参照して説明する。
図面及び以下の説明において同一又は略同一の要素を参照する場合には、全体を
通してできる限り同一の符号を用いる。 本発明は、従来の分散型プロセッシングシステムのアーキテクチャに基づいて
構成されたコンピュータに実装することができる。しかしながら、本発明の実装
するためのアーキテクチャ及び手順は、従来のものとは異なる。その理由は、そ
のアーキテクチャ及び手順がリファレンスの保全性を保障するとともに、メモリ
リークを排除するからである。

【００１８】Ａ．概要 分散型プロセッシングシステム内の各コンピュータに配置されたメソッド呼出
（MI）コンポーネントは、本発明に係る分散型ガベージコレクション概念を実装
するものである。MIコンポーネントは、数多くのソフトウエアモジュールからな
り、これらのモジュールは、できればJAVA^TMプログラミング言語によって記述さ
れたものがよい。

【００１９】 一般的に、分散型プロセッシングシステム内のアプリケーションが、他のコー
ルに対する返り値としての名前の検索により、或いは、他の方法によって、分散
型リソースへのリファレンスを取得し、当該リソースへアクセスするためにシー
クするたびに、そのアプリケーションは、リソース又はそのリソースを管理する
MIコンポーネントに対してコールする。そのMIコンポーネントは、管理用MIコン
ポーネントと称され、そのリソースへの処理中のリファレンスの数を見失わない
ように監視する。リソースへのリファレンスの数がゼロになると、管理用MIコン
ポーネントは、リソースを再生することができる。リソースへのリファレンス数
は、一般的に、"リファレンスカウント"と称され、リファレンスカウントを増加
させるコールは、"ダーティーコール"と称される。

【００２０】 アプリケーションが分散型リソースをもはや要求しない場合には、リソース又
は管理用MIコンポーネントに異なったコールを送信する。このコールを受信する
と、管理用MIコンポーネントは、そのリソース用のリファレンスカウントを減少
させる。リファレンスをドロップさせるこのコールは、"クリーンコール"と称さ
れる。

【００２１】 本発明の一実施形態によれば、ダーティーコールは、リソースへのリファレン
スのために、リクエストされたタイムインターバル及びコールされたリースピリ
オドを含むことができる。ダーティーコールを受信すると、管理用MIコンポーネ
ントは、リースが許可されるピリオドを示すリターンコールを送信する。従って
、管理用MIコンポーネントは、処理中のリファレンスの数と同様に、それらのリ
ファレンスのためのリースピリオドを監視する。その結果、リソースへのリファ
レンスカウントがゼロになったとき、又は、リソースへのリースピリオドが終了
したときに、管理用MIコンポーネントは、そのリソースを再生することができる
。

【００２２】Ｂ．手順 MIコンポーネント内のアプリケーションコールプロセッサは、図１に示したア
プリケーションコール手順１００を実行する。管理用MIコンポーネント内のサー
バコールプロセッサは、図２から図４に示した手順２００、３００、４００の各
工程を実行する。管理用MIコンポーネントのガベージコレクタは、従来の手順を
実行してサーバコールプロセッサからの命令に基づいて既にリファレンスにバイ
ンドされたリソースを再生する。ガベージコレクタの従来の手順については説明
を省略する。

【００２３】 １．アプリケーションコールプロセッサ 図１は、分散型プロセッシングシステム内に配置された同一又は他のMIコンポ
ーネントにより管理されるリソースへのリファレンス用のアプリケーションリク
エストを処理するためにう、MIコンポーネントのアプリケーションコールプロセ
ッサが用いる手順１００のフローチャートを示したものである。

【００２４】 アプリケーションがリソースへのリファレンスを取得した後、アプリケーショ
ンコールプロセッサは、ダーティーコールを送信するが、このダーティーコール
は、そのリソース用の管理用MIコンポーネントに対するリソースへのリファレン
ス、リクエストされたリースピリオドを含む（ステップ１１０）。ダーティーコ
ールは、リソース又は管理用MIコンポーネントに対するものであればよい。

【００２５】 アプリケーションコールプロセッサは、次に、管理用MIコンポーネントコンポ
ーネントからのリターンコールを待ち、これを受信する（ステップ１２０）。リ
ターンコールは、許可されたリースピリオドを含み、この間、管理用MIコンポー
ネントは、ダーティーコールのリファレンスが、そのリソースへバインドされる
のを保障する。換言すれば、管理用MIコンポーネントは、許可ピリオドにおいて
は、ダーティーコールのリファレンスに対応するリソースを収集しないことに応
じる。管理用MIコンポーネントが許可ピリオドを配信しない場合又はリース用の
リクエストを拒否した場合には、アプリケーションコールプロセッサは、許可ピ
リオドを受信するまで他のダーティーコールを送信しなければならない。

【００２６】 アプリケーションコールプロセッサは、アプリケーションによるリファレンス
の使用を監視し、リファレンスがもはや必要ではなくなったことをアプリケーシ
ョンがアプリケーションコールプロセッサに明示的に通知する場合又はアプリケ
ーションコールプロセッサがこの決定をそれ自身で行う場合に（ステップ１３０
）、アプリケーションコールプロセッサは、クリーンコールを管理用MIコンポー
ネントへ送信する（ステップ１４０）。ダーティーコールに用いられる方法と同
様の方法で、クリーンコールは、リファレンスされたリソースに対して行うこと
ができ、管理用MIコンポーネントがクリーンコールを処理することになる。その
後に、アプリケーションコールプロセッサは、リファレンスのリストからアプリ
ケーションにより用いられているリファレンスを削除する（ステップ１５０）。

【００２７】 アプリケーションがリファレンスを終えていない場合には（ステップ１３０）
、アプリケーションコールプロセッサは、リファレンスに対する許可ピリオドが
終了しかけているか否かを判断し（ステップ１６０）、アプリケーションコール
プロセッサは、ステップ１１０から１２０までを繰り返し実行して、アプリケー
ションのかわりに管理用MIコンポーネントにより、リソースへのリファレンスが
管理されることを確保する。

【００２８】２．サーバコールプロセッサ MIコンポーネントのサーバコールプロセッサは、３つの主要手順、すなわち、
（１）ダーティーコールの処理、（２）到来するクリーンコールの処理、（３）
適当な時期にリソースを再生するためのガベージコレクションサイクルの初期化
を実行する。

【００２９】 （i）ダーティーコール 図２は、リソースをリファレンスするリクエスト、例えば、MIソフトウエアコ
ンポーネントが管理するダーティーコールを処理するために、MIコンポーネント
のサーバコールプロセッサが使用する手順２００のフローチャートである。これ
らのリクエストは、分散型プロセッシングシステムのMIコンポーネントのアプリ
ケーションコールプロセッサから到来し、その分散型プロセッシングシステムは
、リクエストを処理するサーバコールプロセッサと同一のMIコンポーネントのア
プリケーションコールプロセッサを包含する。

【００３０】 まず、サーバコールプロセッサは、ダーティーコールを受信する（ステップ２
１０）。サーバコールプロセッサは、次に、受け入れ可能な許可ピリオドを決定
する（ステップ２２０）。許可ピリオドは、リクエストされたリースピリオド又
は他のタイムピリオドと同一でもよい。サーバコールプロセッサは、要求された
リソースの量と、同一のリソース用に前に許可された他の許可ピリオドの数とに
基づいて、適当な許可ピリオドを決定する。

【００３１】 サーバコールプロセッサは、リソースが未だダーティーコールのリファレンス
に割り当てられていないと判断する場合には（ステップ２３０）、サーバコール
プロセッサは、要求されたリソースを割り当てる（ステップ２４０）。

【００３２】 サーバコールプロセッサは、次に、ダーティーコールのリファレンスに対応す
るリファレンスカウントを増加し（ステップ２５０）、受入可能な許可ピリオド
をリファレンス−リソースのバインドに設定し（ステップ２６０）、許可ピリオ
ドと一緒にリターンコールをアプリケーションコールプロセッサに送信する（ス
テップ２７０）。このようにして、サーバコールプロセッサは、その制御下でリ
ソースへのリファレンスについて到来するダーティーコールを制御する。

【００３３】 アプリケーションは、現在のリースが終了する前にダーティーコールを延長リ
クエストと一緒に送信することによってリースを延長することができる。手順２
００に示したように、リースを延長するためのリクエストは、リース用の初期化
リクエストと同様に取り扱われる。延長は、リソースがリファレンスカウントが
ゼロにならない限り、ただ単にタイムインターバルの追加によっては再生されな
いことを意味する。

【００３４】 （ii）クリーンコール MIコンポーネントのサーバコールプロセッサは、アプリケーションコールプロ
セッサから到来するクリーンコールをも処理する。分散型プロセッシングシステ
ム内のアプリケーションがもはやリソースへのリファレンスを要求しなくなった
場合には、アプリケーションは、そのリファレンス用にリソースを管理するMIコ
ンポーネントに、そのリソースが再生して再使用できることを通知する。

【００３５】 サーバコールプロセッサは、MIコンポーネントが管理するリソースへのリファ
レンスとクリーンコールとを受信して（ステップ３１０）、対応するリファレン
スカウントを減少させる（ステップ３２０）。クリーンコールは、リソースに送
信されるが、その際、サーバコールプロセッサはリソースを監視し、コール処理
のための手順３００が実行される。その後、サーバコールプロセッサは、クリー
ンコールを送信したMIコンポーネントに、受信承認としてリターンコールを送信
する。本発明の実装形態によれば、リファレンスをドロップさせるクリーンコー
ルを拒否できないが、承認しなければならない。

【００３６】 （iii）ガベージコレクション サーバコールプロセッサは、リソースを再生するためにガベージコレクション
サイクルの初期化をも行う。このため、より多くのリファレンスがリソースに対
してなされていないか又はリソースへの合意済みリースピリオドが終了したかを
判断する。図４に示した手順４００は、サーバコールプロセッサがガベージコレ
クションサイクルを初期化するために用いるステップである。

【００３７】 サーバコールプロセッサは、リファレンスカウントと許可されたリースピリオ
ドとを監視し、MIコンポーネントによって管理されるリソースへのリファレンス
カウントがゼロなのか又はリファレンス用の許可ピリオドが終了したのかを判断
する（ステップ４１０）。どちらかの状態が存在する場合には、サーバコールプ
ロセッサは、そのリソースのガベージコレクションを初期化する（ステップ４２
０）。そうでない場合には、リファレンスカウントと許可されたリースピリオド
とを監視し続ける。

【００３８】Ｃ．コールフロー 図５は、分散型プロセッシングシステムのMIコンポーネントにおけるコールフ
ローを説明するための図である。管理用MIコンポーネント５２５は、リソース５
３０へのリファレンスを監視することによりリソース５３０を管理する（ガベー
ジコレクト５０５参照）。管理用MIコンポーネント５２５がリソースを管理する
ため、管理用MIコンポーネント５２５のサーバコールプロセッサは、このコール
フロープログラムのオペレーションを実行する。

【００３９】 図５は、アプリケーション５１０，５４０がそれぞれ対応するMIコンポーネン
トコンポーネント５１５，５４５を有することをも示す。各アプリケーション５
１０，５４０は、リソース５３０のうちいずれかへのリファレンスを取得し、シ
ークしてリソース５３０のうちいずれかとのアクセスを取得し、これにより、リ
ファレンスは対応するリソースへバインドされることになる。アクセスを取得す
るために、アプリケーション５１０，５４０は、それぞれ対応するMIコンポーネ
ント５１５，５４５を呼び出し、それぞれダーティーコール５５１，５７１をMI
コンポーネント５２５へ送信する。MIコンポーネント５１５，５２５は、管理用
MIコンポーネント５２５等の他のMIコンポーネントにより管理されるリソース５
３０へのアクセスを行うためにアプリケーションリクエストを処理するため、MI
コンポーネント５１５，５４５のアプリケーションコールプロセッサは、このコ
ールフロープログラムのオペレーションを実行する。

【００４０】 ダーティーコール５５１，５７１に応答して、管理用MIコンポーネント５２５
は、それぞれリターンコール５５２，５７２を、それぞれMIコンポーネント５１
５，５４５に送信する。ダーティーコールは、ダーティーコール５５１，５７１
のリファレンス用に許可されたリースピリオドを含む。

【００４１】 同様に、図５は、更に、クリーンコール５６１，５８１をそれぞれ管理用MIコ
ンポーネント５２５に送信するMIコンポーネント５１５，５４５を示す。クリー
ンコール５６１，５８１は、アプリケーション５１０，５４０がそれぞれクリー
ンコール５６１，５８１内で指定されたリソースへのアクセスをもはや要求しな
いということを、管理用MIコンポーネント５２５に対して通知する。管理用MIコ
ンポーネント５２５は、クリーンコール５６１，５８１に対してそれぞれリター
ンコール５６２，５８２を用いて応答する。リターンコール５６２，５８２は、
リターンコール５５２，５７２とは異なり、MIコンポーネント５２５が受信した
クリーンコール５６１，５８１の単なる受信承認に過ぎない。

【００４２】 アプリケーション５１０，５４０は、両者とも、同一リソースへのアクセスを
要求することができる。例えば、アプリケーション５１０は、"リソース(1)"へ のアクセスをリクエストすることができるが、一方でアプリケーション５４０が
、以前にそのリソースへのアクセスが許可されていたということがある。MIコン
ポーネント５２５は、一致したリースピリオドの間、アプリケーション５１０，
５４０の両者に対して有効なリソースを作ることにより、この状況を処理する。
従って、MIコンポーネント５２５は、アプリケーション５１０，５４０の両者が
リソースへのリファレンスをドロップさせるか、最新の一致したピリオドが終了
するかのいずれかが発生するまでは、"リソース(1)"を再生するためにガベージ コレクションサイクルを初期化しないことになる。

【００４３】 同一のリソースへ同時にアクセスするために複数のアプリケーションを許可す
ることによって、本発明は、リソースへのリファレンスをドロップさせる管理用
MIコンポーネントへクリーンコールを送信した後に、アプリケーションがリソー
スへアクセスすることをも許可する。これが発生するのは、リソースが依然とし
て他のアプリケーションによって参照されているか、又は、リファレンスのリー
スがまだ終了していないために管理用MIコンポーネント５２５がまだリソースを
再生していないからである。しかしながら、リソースは、より多くのアプリケー
ションがどれもリースを保持しない場合又は最後のリースが終了した場合に、制
限ピリオドの後、再生されることになる。

【００４４】Ｄ．MIコンポーネント 図６は、本発明の一実施形態に係るMIコンポーネント６００を構成するモジュ
ールのブロック図である。MIコンポーネント６００は、監視されるリファレンス
用のリファレンスコンポーネント６０５、アプリケーションコールプロセッサ６
４０、サーバコールプロセッサ６５０及びガベージコレクタ６６０を含むことが
できる。

【００４５】 リファレンスコンポーネント６０５は、リファレンスデータポーション６１０
、リファレンス６２０、許可ピリオドレジスタ６３０を備えたテーブル又はこれ
と同様の構造体から構成される。MIコンポーネント６００は、対応するリファレ
ンスデータポーション６１０内で指定された各リファレンス用にリファレンスカ
ウント６２０と許可ピリオド６３０とを使用して、対応するリソースを再生する
には、いつガベージコレクタ６６０を初期化すればよいかを判断する。

【００４６】 アプリケーションコールプロセッサ６４０は、ソフトウエアモジュールであり
、図１に示した手順１００の各ステップを実行する。サーバコールプロセッサ６
５０は、ソフトウエアモジュールであり、図２から図４に示した手順２００，３
００，４００の各ステップを実行する。ガベージコレクタ６６０は、ソフトウエ
アモジュールであり、上述したようにサーバコールプロセッサ６５０からの命令
に応じてリソースを再生する。

【００４７】Ｅ．分散型プロセッシングシステム 図７は、本発明を実装するのに使用可能な分散型プロセッシングシステム５０
を示したものである。図７においては、分散型プロセッシングシステム５０は、
３つの独立した異種のプラットフォーム１００，２００，３００を含み、これら
は、ネットワーク雲５５によって表されるネットワークコンフィギュレーション
内で連結されている。図７の雲５５により表されるネットワークコンフィギュレ
ーションの構成及びプロトコルは、プラットフォーム７００，８００，９００の
間での情報通信が可能である限り余り重要ではない。加えて、これらの３つのプ
ラットフォームは、説明のために例示したものであるため、本発明におけるプラ
ットフォームの使用を特定数に限定するものではない。更に、本発明については
、専用のネットワークアーキテクチャは重要ではない。例えば、本発明に従って
使用可能な他のネットワークアーキテクチャとしては、あらゆるプラットフォー
ムが連結可能なネットワークコントローラのような単一のプラットフォームを使
用するものでもよい。

【００４８】 分散型プロセッシングシステム５０の実装においては、プラットフォーム７０
０，８００，９００は、各々、プロセッサ７１０，８１０，９１０をそれぞれ備
えるほか、メモリ７５０，８５０，９５０をそれぞれ備える。各プロセッサ７１
０，８１０，９１０の各々には、アプリケーション７２０，８２０，９２０、オ
ペレーティングシステム７４０，８４０，９４０、MIコンポーネント７３０，８
３０，９３０がそれぞれ含まれる。

【００４９】 アプリケーション７２０，８２０，９２０は、プログラムにより構成でき、こ
のプログラムは、予め作成されたものを本発明に従って作動するように修正され
たものか又は本発明によって得られるサービスの効果を得るべく専用として作成
されたものであればよい。

【００５０】 MIコンポーネント７３０，８３０，９３０は、図６を参照して説明したように
MIコンポーネント６００に対応している。

【００５１】 オペレーティングシステム７０，８４０，９４０は、それぞれ対応するプロセ
ッサ７１０，８１０，９１０に連結された標準オペレーティングシステムである
。プラットフォーム７００，８００，９００は、異種でもよい。例えば、プラッ
トフォーム７００は、プロセッサ７１０としてサンマイクロシステムズ インコ
ーポレーテッド製のUltraSparc（登録商標）マイクロプロセッサを備え、Solari
s（登録商標）オペレーティングシステム７４０を使用している。プラットフォ ーム８００は、プロセッサ８１０としてシリコングラフィックス インコーポレ
ーテッド製のMIPSマイクロプロセッサを備え、Unixオペレーティングシステム８
４０を使用している。そして、プラットフォーム９００は、プロセッサ９１０と
してインテル コーポレーテッド製のペンティアムマイクロプロセッサを備え、
マイクロソフトウインドウズ９５オペレーティングシステム９４０を使用してい
る。本発明は、これに限定されるものではなく、異種のプラットフォームを適用
することも可能である。

【００５２】 Sun、Sun Microsystems、Solaris、Java、the SunLogoは、米国又はその他の 国におけるサンマイクロシステムズ インコーポレーテッドの商標又は登録商標
である。UltraSparc及び他の全てのSPARC商標は、米国又はその他の国において ライセンス契約の下で使用されており、スパークインターナショナル インコー
ポレーテッドの商標である。SPARC商標を付した製品は、サンマイクロシステム ズ インコーポレーテッドにより開発されたアーキテクチャに基づいたものであ
る。

【００５３】 メモリ７５０，８５０，９５０は種々の機能、例えば、関連付けられたプラッ
トフォーム用の全体の記憶領域を提供する。他の機能は、各プロセッサ７１０，
８１０，９１０による実行前に、アプリケーション７２０，８２０，９２０、MI
コンポーネント７３０，８３０，９３０及びオペレーティングシステム７２０，
８４０，９４０を記憶することである。加えて、メモリ７５０，８５０，９５０
の各部分は、ネットワーク５０の全プラットフォーム７００，８００，９００に
有効な共有メモリからなる。

【００５４】Ｅ．メソッド呼出サービス 本発明はクライアント／サーバモデルを使用して実装することができる。クラ
イアントは、ダーティーコール、クリーンコール等のリクエストを生成し、サー
バはリクエストに対して応答を返す。

【００５５】 図７に示したMIコンポーネント７３０，８３０，９３０の各々は、クライアン
トコンポーネントとサーバコンポーネントの両者を含む。図８は、クライアント
プラットフォーム１０００及びサーバプラットフォーム１１００のブロック図で
あり、図７に示したプラットフォーム７００，８００，９００のうちいずれか２
つに適用される。

【００５６】 プラットフォーム１０００，１１００は、それぞれメモリ１０５０，１１５０
、プロセッサ１０１０，１１１０を保持する。プラットフォーム１０００，１１
００に含まれる要素は、図７を参照して説明した要素と同様の手法で機能する。
この例においては、プロセッサ１０１０は、クライアントアプリケーション１０
２０を実行し、プロセッサ１１１０は、サーバアプリケーション１１２０を実行
する。プロセッサ１０１０，１１１０は、更に、それぞれオペレーティングシス
テム１０４０，１１４０及びMIコンポーネント１０３０，１１３０を実行する。

【００５７】 MIコンポーネント１０３０，１１３０は、各々、サーバコールプロセッサ１０
３１，１１３１、アプリケーションコールプロセッサ１０３２，１１３２、ガベ
ージコレクタ１０３３，１１３３を含む。MIコンポーネント１０３０，１１３０
は、その各々が監視する各リファレンスとして、リファレンスデータポーション
１０３４，１１３４、リファレンスカウント１０３５，１１３５、許可ピリオド
レジスタ１０３６，１１３６を含むリファレンスコンポーネントをも含む。

【００５８】 アプリケーションコールプロセッサ１０３２，１１３２は、それぞれクライア
ントサービスを象徴し、これらの各々は、サーバサービスを象徴するサーバコー
ルプロセッサ１０３１，１１３１の各々と情報通信を行う。プラットフォーム１
０００，１１００は、サーバコールプロセッサ、アプリケーションコールプロセ
ッサ、ガベージコレクタ、リファレンスコンポーネントを保持しているため、プ
ラットフォームは、クライアント又はサーバのいずれかとして動作可能である。

【００５９】 しかしながら、問題を解決するためには、プラットフォーム１０００はクライ
アントプラットフォームと呼ばれ、プラットフォーム１１００はサーバプラット
フォームと呼ばれる。この例においては、クライアントアプリケーション１０２
０は、分散型リソースへのリファレンスを取得するとともにMIコンポーネント１
０３０を使用してサーバプラットフォーム１１００のMIコンポーネントにより管
理されるリソースへダーティーコールを送信する。

【００６０】 更に、サーバプラットフォーム１１００は、サーバアプリケーション１１２０
を実行することができる。サーバアプリケーション１１２０は、MIコンポーネン
ト１１３０を使用してダーティーコールを送信することもでき、このダーティー
コールは、ダーティーコールのリソースがMIコンポーネント１１３０により管理
される場合に、MIコンポーネント１１３０によって処理される。

【００６１】 従って、クライアントプラットフォーム１０００のMIコンポーネント１０３０
用のサーバコールプロセッサ１０３１、ガベージコレクタ１０３３及びリファレ
ンスカウンタ１０３５は、アクティブではなく、図８においては陰を付けて表示
されている。同様に、サーバプラットフォーム１１００のMIコンポーネント１１
３０のアプリケーションコールプロセッサ１１３２も休止中であるため陰を付し
て表示されている。

【００６２】 クライアントアプリケーション１０２０がリソースに対応するリファレンスを
取得する場合には、アプリケーションコールプロセッサ１０３２は、ダーティー
コールを送信し、サーバコールプロセッサ１１３１がこれを受信する。ダーティ
ーコールは、リクエストされたリースピリオドを含む。サーバコールプロセッサ
１１３１は、ダーティーコール内のリファレンス用にリファレンスカウント１１
３５を増加し、許可ピリオドを決定する。これに応答して、サーバコールプロセ
ッサ１１３１は、リターンコールを許可ピリオドとともに、アプリケーションコ
ールプロセッサ１０３０へ送信する。アプリケーションコールプロセッサ１０３
２は、許可ピリオドを使用して記録された許可ピリオド１０３５を更新し、いつ
ダーティーコールのリファレンスに対応するリソースを再生するかを決定する。

【００６３】 サーバコールプロセッサ１１３１は、更に、それが管理するリソースへのリフ
ァレンスに対応するリファレンスカウントと許可ピリオドとを監視する。リファ
レンスカウント１１３５のうちの一つがゼロになるか、又は、リファレンス用の
許可ピリオド１１３５が終了するかのいずれか最初のイベントが起こった時に、
サーバコールプロセッサ１１３１は、ガベージコレクタ１１３３を初期化して、
ゼロのリファレンスカウント又は終了した許可ピリオドを保持するリファレンス
に対応するリソースを再生することができる。

【００６４】 本発明の一実施形態によるリースされたリファレンスの概念は、プラットフォ
ーム１０００，１１００のプロトコル上でクロックの同期を必要としない。その
概念は、それらが同等の増加周期であることを要求するに過ぎない。リースは、
特定のタイミングでは終了しないが、特定のタイムインターバルで終了するもの
である。そのインターバルがほぼ正確に一致している限り、プラットフォーム１
０００，１１００は、許可されたリースピリオドについてほぼ正確に一致する。
更に、コンピュータ周期におけるリースタイミングは比較的長いため、クロック
速度のモニタ差異は殆どないか又は影響がない。

【００６５】 ダーティーコールの転送時間は、プロトコルに影響を及ぼす。MIコンポーネン
ト１０３０がリファレンス用のリースを保持し、リースが終了して更新リクエス
トをする直前までウエイトするとすれば、リースは、MIコンポーネント１１３０
がリクエストを受信する前に終了する。そうだとすれば、MIコンポーネント１１
３０は、更新リクエストを受信する前にリソースを再生することができる。従っ
て、ダーティーコールを送信する場合には、リソースへのリースピリオドが終了
する前に、更新されたダーティーコールが作成されるようにするために、送信元
では、ダーティーコールのリソースを処理するプラットフォームへの転送時間を
考慮に入れて、リクエストされたリースピリオドにタイムファクターを追加すべ
きである。

【００６６】Ｆ．結論 本発明による分散型ガベージコレクションの概念によれば、分散型プロセッシ
ングシステムのリソースへのリファレンスに対応する許可されたリースピリオド
を配信することにより、リファレンスの保全性が保障され、メモリリークが排除
される。具体的には、許可されたリースピリオドが終了したときに、リソースへ
のリファレンスを付すことによってなされる。その後、リソースは収集される。
リソースは、分散型プロセッシングシステムのプロセスによってリファレンスさ
れなくなった場合に、リソース用にリファレンスに割り当てられたカウンタへの
リファレンスとともに収集することもできる。

【００６７】 ［本発明の変形例］ 上述したリーステクニックは、ガベージコレクションに関するものである。し
かしながら、以下に説明するように記憶デバイスを使用すれば変形例も実施可能
である。

【００６８】 記憶デバイスは、種々の論理的にグループ化されたデータを保持する多くの記
憶ロケーションを備え、それらの論理的にグループ化されたデータは、複数プロ
グラムによって利用可能である。これらの論理的グループ化は、ファイル形態、
データベース形態又はドキュメント形態をとることができる。記憶ロケーション
のリースにより、所定の予め取り決めた時間長さだけ、記憶ロケーションにアク
セス（例えば、読出及び書込アクセス）することができる。どの種類のデータが
記憶ロケーションに保持されているか又は記憶ロケーションが全くデータを保持
していないのかということは、記憶ロケーションのリースに関しては無関係であ
る。記憶ロケーションのリースは、異なったレベルの記憶領域、例えば、データ
ベースフィールド、記憶ブロック、又は、実際の記憶ロケーション等にも適用可
能である。

【００６９】 コンピュータシステム又は分散型システムにおいては、多くのプログラムが記
憶ロケーションの種々のグループ内で記憶されたファイルに競合アクセスするこ
とができる。従って、記憶ロケーションのグループは、アクセスが競合する多く
のプログラムを保持することができる。リーステクニックは、このような環境で
の記憶ロケーションの使用を調整するのに使用することができる。

【００７０】 ファイル用のデータを保持する記憶ロケーションのグループに対してリースを
使用する場合には、プログラム（"クライアント"）は、ファイルシステムマネー
ジャ（"サーバ"）からのリースをリクエストし、所定時間（"リースピリオド"）
の間、記憶ロケーションのグループへアクセスする。有効性、優先順位及び以下
に説明する他の要因により、サーバは、リクエストを拒むか又はリースピリオド
を許可する。許可されたリースピリオドは、リクエストされた完全なリースピリ
オドでもよいし、その一部分でもよい。一旦、クライアントがリースを受信する
と、クライアントは、リースピリオドの間、記憶ロケーションのグループにアク
セスすることができる。

【００７１】 リースピリオドをリクエストする場合には、クライアントは、正確なリースピ
リオドをリクエストすることができる。この状況では、サーバは、リースピリオ
ドが、リクエストされた完全なリースピリオドである場合にのみ、リースを許可
することができ、その一部分のときとは対照的である。

【００７２】 リースがアクティブである間、クライアントは、記憶ロケーションのグループ
へのアクセスが保障され、それらに対して読出／書込のオペレーションを実行す
る。同様にして、サーバは、アクティブリースの間には、記憶ロケーションの保
全性を維持する。例えば、リースピリオドの間、サーバは、リースしたファイル
の消去・上書きをさせないほか、リースしたファイルに対してクライアント以外
のエンティティによる影響を与えない。しかしながら、リースが終了すると、サ
ーバは、もはや、クライアントへのファイルの保全性を保障することができない
ため、サーバは、そのファイルを消去するか又はそれを変更し、あるいは、同様
の処理を行う他のクライアントにリースを許可する。サーバにより再生されるの
は、処理中のリースがない記憶ロケーションである。

【００７３】 各記憶ロケーションは、関連の限定パラメータ、例えば、アクセスパラメータ
又は特権パラメータを保持可能である。アクセスパラメータは、その記憶ロケー
ション用にサーバがサポートするアクセスのタイプを決定する。例えば、記憶ロ
ケーションは、読出アクセスオンリーと定義することができる。この場合、サー
バは、特定の記憶ロケーションに対して許可されたリース用の読出アクセスのみ
を許可する。逆に言えば、その記憶ロケーションへクライアントが書込しようと
しても、サーバにより許可されない。他の記憶ロケーションのアクセスパラメー
タとしては、書込アクセス、割当アクセス、再割当アクセス及びサブブロックア
クセス（すなわち、大きな記憶ブロック用）を含むことができる。

【００７４】 関連する特権パラメータは、クライアントがリースを許可される前に保持すべ
き特権レベルを指定する。サーバは、特権パラメータを使用して競合するリース
のリクエストの優先順位を付ける。換言すれば、サーバが同一の記憶ロケーショ
ンに対して複数の処理中のリースリクエストを保持する場合には、サーバは、リ
クエストを行うクライアントの特権レベルに基づいてリクエストに優先順位を付
ける。

【００７５】 当該他の実施形態はまた、同一の記憶ロケーションに対する複数の競合リース
を許可することにより、記憶ロケーションのグループへの競合アクセスをサポー
トする。例えば、特定の記憶ロケーションのパラメータが"読出"アクセスを指定
するとすれば、サーバは、その記憶ロケーションへ当該記憶ロケーションの保全
性を破壊することなく、複数の競合するリースを許可することができる。競合す
るリースは、例えば、大きいサイズのファイルへも適用されることになる。サー
バは、そのより大きいサイズのファイルの保全性に悪影響を及ぼすことなく、よ
り小さいサイズのファイルのサブブロックへリースを許可するにすぎない。

【００７６】 クライアントが一旦リースをリクエストすると、サーバは、クライアントにオ
ブジェクトを返すが、そのオブジェクトは、リース時間の決定メソッド、リース
更新メソッド及びリースのキャンセルメソッドを含む。オブジェクトは、クラス
のインスタンスであり、より多くのファンクションを提供するために多くの手法
で拡張することができるが、ベーシッククラスは以下の表１のように定義される
。

【表１】

【００７７】 特に、"期間取得"メソッドは、許可されたリースピリオドの長さをクライアン
トに配信する。このピリオドは、サーバにより許可された最新のリースを表して
いる。しかしながら、リース上で処理中の時間量の決定は、クライアントの応答
性によるところとなる。

【００７８】 "更新"メソッドは、クライアントがリースを更新するのを許可するものであり
、オリジナルリースリクエストを再初期化することなく、より多くの時間を要求
することができる。クライアントがリースの更新を所望する場合としては、オリ
ジナルリースが不十分になった場合（すなわち、クライアントがより多くの記憶
ロケーションの使用を要求する場合）や、一部のリースのみが許可された場合（
すなわち、要求されたリースより少ない場合）がある。

【００７９】 クライアントは、更新メソッドを使用して、追加的なリースピリオドを要求す
るか又は多くの追加のリースピリオドが許可されるまで、継続的に更新メソッド
を何度も呼び出す。更新メソッドには戻り値がない；更新が許可されると、新た
なリースピリオドは、コールを行ったリースオブジェクトに反映される。サーバ
がリースを更新することができない場合又は更新しようとしない場合には、その
原因が更新メソッドにより生成されたLeaseDeniedExceptionに示される。

【００８０】 最終的には、クライアントは、当該クライアントがリースをキャンセルしたい
とする場合に"キャンセル"メソッドを呼び出すが、リース上にはまだ時間が残っ
ている。従って、キャンセルにより、サーバは、記憶ロケーションを再生するこ
とができ、他のプログラムがそれらにアクセスすることができるようになる。従
って、キャンセルメソッドにより、サーバは、分散型システム内で記憶ロケーシ
ョンの使用を最適化することができる。これに対し、リースが終了までくると（
すなわち、正常終了）、サーバは、記憶ロケーションの制御に戻ることになる。
従って、クライアントは、リースの正常終了をサーバに通知する義務はない。

【００８１】 図９は、本発明の他の実施形態に用いて好適なデータプロセッシングシステム
９０００を示したものである。データプロセッシングシステム９０００は、イン
ターネット９００２に連結されたコンピュータシステム９００１を含む。コンピ
ュータシステム９００１は、メモリ９００３、補助記憶デバイス９００４、中央
処理ユニット（CPU）９００６、入力デバイス９００８及びビデオディスプレイ ９０１０を含む。メモリ９００３は、更に、オペレーティングシステム９０１２
及びプログラム（"クライアント"）９０１４を含む。オペレーティングシステム
９０１２は、ファイルシステムマネージャ（"サーバ"）９０１６を保持し、これ
が補助記憶デバイス９００４のファイル９０１８を管理する。クライアント９０
１４は、サーバ９０１６からリースをリクエストすることによって一又は複数の
ファイル９０１８へのアクセスをリクエストする。これに応えて、サーバ９０１
６は、後述するように、リースの許可又は拒否のいずれかを選択することができ
る。コンピュータ９０００は、追加の又は異なるコンポーネントを保持するもの
でもよく、このことは、いわゆる当業者にとって周知である。

【００８２】 上述した変形例の要旨は、メモリ９００３に記憶させたものとして説明したが
、いわゆる当業者にとっては、これらの要旨を他のコンピュータ読取可能な媒体
、例えば、補助記憶装置（ハードディスク、フロッピーディスク、コンパクトデ
ィスク・読出オンリメモリ）；インターネット９００２からの伝送波；又はラン
ダムアクセスメモリや読出オンリメモリ等の他の媒体、に記憶させてもよいこと
は周知である。更に、いわゆる当業者にとっては、他のデータ形態、例えば、デ
ータベース、スプレッドシート、ドキュメント等の形態を補助記憶デバイスにお
けるリース用に使用可能であることは周知である。

【００８３】 図１０Ａ及び図１０Ｂは、クライアントがサーバからのリースをリクエストす
る場合に当該クライアントによって実行されるステップのフローチャートを示し
たものである。クライアントによって実行される最初のステップは、リースのリ
クエストをサーバに送信することである（ステップ１００２）。このリクエスト
は、ファンクションコールであり、(1)クライアントがリースしようとしている リクエストされた記憶ロケーション、(2)所望のリースピリオド、(3)正確なリー
スインジケータ、(4)クライアントが所望するアクセスタイプ、及び、(5)クライ
アントの特権、を含む多くのパラメータを含む。

【００８４】 リクエストされた記憶ロケーションは、リースされるべき記憶ロケーションの
表示を保持する。所望のリースピリオドは、クライアントが記憶ロケーションを
利用しようと欲する時間長さを保持する。正確なリースリクエストは、正確なリ
ースリクエストがなされているか又はリクエストされた時間よりも短いリースで
十分であるかの表示を保持する。リクエストされたアクセスタイプは、クライア
ントがリクエストした記憶ロケーションアクセスのタイプを表示する。アクセス
タイプは、読出アクセス、ライトアクセス、割当アクセス、再割当アクセス、サ
ブブロックアクセス（すなわち、大きなサイズの記憶ブロック用）を含む。特権
フィールドは、ユーザ又はクライアントの特権レベルを表示する。有効なリクエ
ストを形成するためには、クライアントリクエストは、リクエストされた記憶ロ
ケーション及び所望のリースピリオドの両者を保持しなければならない。

【００８５】 記憶ロケーションへのリースリクエストを生成するには、一般的に２つのシナ
リオがある。第一のシナリオは、ファイルが生成されたときに起こる。ファイル
を生成するのに使用される生成コマンドは、ファイルへアクセスするために、サ
ーバにリースリクエストを生成させる。新しいファイルをリース技術によって調
節するための必要条件は、記憶ロケーションが不明確なものを保持しないことを
保障する。従って、サーバは、新たなファイルに対して長時間の又は不明確なリ
ースを許可しようとはしない。第二のシナリオは、クライアントが既存の記憶ロ
ケーション又は既存リースを保持するファイル（すなわち、競合するリース）へ
アクセスしようとする場合に起こる。

【００８６】 リクエストを送信した後、クライアントは、サーバからリースオブジェクトを
受信したか否かによって、リースが許可されたか否かを決定する（ステップ１０
００６）。リースオブジェクトは、上述したように、ファイルハンドル、期間取
得メソッド、更新メソッド、キャンセルメソッドを含む種々の情報を保持する。
サーバが何らかの理由でリースを拒否する場合には、サーバは、クライアントの
種々の例外ハンドラにより処理される例外処理を生成する。

【００８７】 リースが不完全リクエストの理由で許可されない場合には（ステップ１０００
８）、クライアントの例外ハンドラが呼び出され、リクエストが再構築された後
（ステップ１００１０）、処理はステップ１０００２へ続くことになる。不完全
なリクエストは、大きすぎるリースピリオドリクエスト又は不明の記憶ロケーシ
ョンへのリースリクエストを含む。リクエストが不完全であるとすると、クライ
アントは、リクエストを再構築して有効リクエストを生成する。例えば、サーバ
が正確なリースリクエストを許可することができなかった場合には、クライアン
トは、そのリクエストを再構築して、より少ないリースピリオドとすることがで
きるし、又は、リクエストが不明確な記憶ロケーションであった場合には、クラ
イアントは、リクエストを再構築して明確な記憶ロケーションとすることができ
る。

【００８８】 しかしながら、記憶ロケーションが他のクライアントによりリースされている
という理由で、リースが許可されなかった場合には（ステップ１００１２）、例
外ハンドラが呼び出され、所定時間ウエイトした後（ステップ１００１４）、処
理はステップ１０００２へ引き継がれる。

【００８９】 しかしながら、サーバは、リースリクエストをキューに入れることもできる。
この場合には、所定時間ウエイトした後、リースが許可されたということを呈示
する応答を受信した場合に、クライアントは決定する。リースがその後許可され
ると、処理は、図１０Ｂのステップ１００２４へ続くことになる。リースが許可
されなかった場合には、クライアントは、ウエイトした後、ステップ１０００２
へ続くことになる。

【００９０】 クライアントが、ステップ１０００６においてリースリクエストがうまくいっ
たと判断した場合には、クライアントは、アクティブリースを保持することにな
る。この時点においては、クライアントは、リースによってカバーされた記憶ロ
ケーションへアクセスすることができる（ステップ１００２４）。記憶ロケーシ
ョンへアクセスした後、クライアントは、記憶ロケーションへのアクセスが終了
すると判断を行う（ステップ１００２６）。クライアントが記憶ロケーションへ
のアクセスを終了すると、クライアントは、リースが終了したかどうか判断する
（ステップ１００２８）。リースが終了すると、処理は終了し、クライアントと
サーバとの間での情報通信は不要となる（すなわち、正常終了が発生する）。一
方、リースが既にアクティブである場合には、クライアントは、キャンセルメソ
ッドを呼び出す（ステップ１００３０）。クライアントは、最適化の目的でこれ
を行う。クライアントは、リースオブジェクトを経由してキャンセルメソッドに
アクセスする。キャンセルメソッドは、サーバに、クライアントはもはや記憶ロ
ケーションには関係がないことをサーバに通知する。従って、キャンセルメソッ
ドにより、サーバは、迅速に、他のプログラムによって使用するために記憶ロケ
ーションを再生することができる。

【００９１】 リースされたファイルのクライアントの使用が完了していない場合には、クラ
イアントは、リースが終了するときか否かを判断する（ステップ１００３２）。
その時点の時間長さとリース時間とを比較することによりクライアントによって
なされる。リース期間は、期間取得メソッドを呼び出すことによって知ることが
できる。リースが終了しない場合には、クライアントは、ステップ１００２４に
おいて記憶ロケーションへアクセスし続けることになる。しかしながら、リース
が終了する場合には、クライアントは、リースを更新すべきか否かを決定しなけ
ればならない（ステップ１００３４）。クライアントがリースを更新することを
選択した場合には、クライアントは、リースオブジェクトの更新メソッドを呼び
出す。更新メソッドが呼び出されると、処理はステップ１００２４へ続いていく
。クライアントがリースを更新しない場合には、処理は終了し、クライアントと
サーバとの間での情報通信は不要となる（正常終了）。

【００９２】 図１１は、クライアントがリースを要求した場合に、サーバによって実行され
るステップのフローチャートを示したものである。これらのステップは、クライ
アントがファイルを生成したとき、既にリースを保持するファイル上でリースを
リクエストしたとき、又は、更新メソッドを呼び出すときに、呼び出すことがで
きる。サーバによって実行されるこの第一のステップは、クライアントによるリ
ースリクエストを受信することである（ステップ１１００２）。リクエストを受
信した後、サーバは、パラメータを調べてリクエストの適否を確かめる（ステッ
プ１１００４）。

【００９３】 パラメータを調べた後、サーバは、リクエストが完全か否かを判断する（ステ
ップ１１００６）。例えば、サーバは、リクエストされた記憶ロケーションが本
物の記憶ロケーションであるか否か、また、クライアントが十分な特権レベルを
所有しているか否かをチェックするまた、サーバは、所望のリースピリオドが指
定されたことを確かめる。更に、サーバは、リクエストされたアクセスのタイプ
が有効であるか否かをチェックする。サーバがリースリクエストが不完全である
と判断した場合には、サーバは、例外処理を生成し、適当なクライアントイベン
トハンドラ（ステップ１１００８）を移動させ、処理が終了する。

【００９４】 リクエストが完全である場合には、サーバは、リースピリオドアルゴリズム（
"LPA"）を実行し、許可されるべきリースピリオドを決定する（ステップ１１０ １０）。LPAは、クライアントの所望するリースピリオドから全くリースのない という状態まで変化するリースピリオドを生成する。LPAは、リースピリオドを 決定するに際して多くのファクターを考慮にいれるが、これらのファクターには
、更新メソッドから初期化されたリクエストか否か、生成インストラクション又
は次のリースリクエストか、クライアントの使用パターン、記憶ロケーションの
需要、記憶ロケーションのサイズ（大きなグルーピング）が含まれる。更に、LP
Aは、記憶ロケーションの値を考慮することができる。例えば、特定の記憶ロケ ーションがアクセスするのに費用がかかり、又は、高い需要がある場合には、LP
Aは、短いリースのみを許可することができる。

【００９５】 一旦、ＬＰＡがリースピリオドを決定すると、サーバは、リースピリオドが許
可されたか否か（すなわち、ゼロより大きいか否か）を判断する（ステップ１１
０１２）。リースピリオドが一つも許可されなかった場合には、サーバは、例外
処理を生成し（ステップ１１００８）、処理が終了する。上述したように、サー
バは、リースリクエストをキューに入れることもできる。この場合には、サーバ
は、その後の処理のためにリースリクエストを記憶する。

【００９６】 LPAがリースピリオドを許可した場合には、サーバは、正確なリースがクライ アントによってリクエストされたか否かを判断する（ステップ１１０１６）。正
確なリースがクライアントによりリクエストされた場合には、サーバは、LPAに よって許可されたリースピリオドがリクエストされたリースピリオドよりも小さ
いか否かを判断する（ステップ１１０１８）。LPAによって許可されたリースが 正確にリクエストされたリースピリオドよりも小さい場合には、サーバは、例外
処理を生成し（ステップ１１００８）、処理が終了する。

【００９７】 正確なリースがリクエストされなかった場合、又は、正確なリースが許可され
た場合には、サーバは、リースオブジェクトを生成し、それをクライアントに返
す（ステップ１１０２０）。サーバは、アクティブリースピリオドを監視するこ
とにより、リースされた記憶ロケーションを再生するが、当該記憶ロケーション
は、これに付属するアクティブリースをもはや保持しない。

【００９８】 以上本発明の実施例について一例を示す目的で説明した。本発明は、開示した
正確な形態によって用い尽くされるものではなく、また、これに限定されるもの
ではない。上述の開示により導き出される事項や、本発明の実施に際し必要な事
項から、種々の改良例や変形例が可能である。例えば、開示した実施形態は、ソ
フトウエアを含むものであるが、本発明は、ハードウエアとソフトウエアの組合
せや、ハードウエアとして実施することもできる。本発明の範囲は、特許請求の
範囲及びこれを裏付ける記載によって定まるものである。

【図面の簡単な説明】

【図１】 図１は、本発明の一実施の形態に係るアプリケーションコールプロセッサによ
って実行される工程のフローチャートである。

【図２】 図２は、本発明の一実施の形態に係るダーティーコールを処理するサーバコー
ルプロセッサによって実行される工程のフローチャートである。

【図３】 図３は、本発明の一実施の形態に係るクリーンコールを処理するサーバコール
プロセッサによって実行される工程のフローチャートである。

【図４】 図４は、本発明の一実施の形態に係るガベージコレクション処理を初期化する
サーバコールプロセッサによって実行される工程のフローチャートである。

【図５】 図５は、分散型プロセッシングシステムにおけるコールの好適なフローを示し
た図である。

【図６】 図６は、本発明に係るメソッド呼出サービスに実装されるコンポーネントを示
したブロック図である。

【図７】 図７は、本発明の一実施形態において使用される分散型プロセッシングシステ
ムの構成を示した図である。

【図８】 図８は、本発明の一実施形態に係る分散型プロセッシングシステムのプラット
フォームに含まれる個々のソフトウエアコンポーネントを示した図である。

【図９】 図９は、本発明の他の実施形態において使用される分散型プロセッシングシス
テム内で記憶領域のロケーションをリースするためのデータプロセッシングシス
テムを示した図である。

【図１０Ａ】 図１０Ａは、本発明の他の実施形態に係り、サーバからのリースをリクエスト
した場合にクライアントによって実行される工程を示したフローチャートである
。

【図１０Ｂ】 図１０Ｂは、本発明の他の実施形態に係り、サーバからリースをリクエストし
た場合にクライアントによって実行される工程を示したフローチャートである。

【図１１】 図１１は、本発明の他の実施形態に係り、クライアントがリースをリクエスト
した場合に、サーバによって実行される工程を示したフローチャートである。

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１２年４月１８日（２０００．４．１８）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正内容】

【特許請求の範囲】

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】０００１

【補正方法】変更

【補正内容】

【０００１】 （関連出願） 参考のために示すが、本出願は、1998年11月3日に発行された米国特許No.5,83
2,529号、発明の名称「分散型ガーベジコレクションのための方法、装置及びプ ロダクト」の関連出願である。また、本出願は、2000年1月18日に発行された米 国特許No.6,016,500号、発明の名称「故障検知のためのリース」の関連出願であ
る。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ， ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，Ｄ Ｋ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ， ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，Ｌ Ｔ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ， ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，Ｕ Ａ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者 ウォルド ジェイムズ エイチ アメリカ合衆国、01826 マサチューセッ ツ州、ドラカット、ルビー ロード 155 (72)発明者 アーノルド ケネス シー アール シー アメリカ合衆国、02173 マサチューセッ ツ州、レキシントン、ムーン ヒル ロー ド ７ Ｆターム(参考） 5B045 DD03 EE03 EE23 5B060 AA10 AA14 AC11 CA08 KA01 KA02 5B098 AA03 AA10 GA01 GD03 GD14 GD22

Claims (1)

【特許請求の範囲】
1. 【請求項１】 記憶領域の一部分を指定する発呼側からのアクセスリクエス
   トを受信して、リクエストされたリースピリオドを指定する指定工程と、 発呼側が記憶領域の一部分へアクセスするリースピリオドを決定する決定工程
   と、 決定されたリースピリオドを発呼者に通知する通知工程と、 発呼者がその決定されたリースピリオドの間、記憶領域の一部分へアクセスす
   るのを許可する許可工程とからなることを特徴とする記憶領域を備えたコンピュ
   ータシステムにおけるリース方法。