JPH036751A - フアイル・ロツク方法及び装置 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明はネットワークを介して接続された処理システム
に関し、具体的に、ネットワーク内の局所処理システム
と遠隔処理システムの間でのファイル・アクセスに関す
る。

Ｂ、従来の技術 第１図に図示されるように、分散ネットワーキング環境
１は、通信リンクまたはネットワーク３を介して接続さ
れた２つ以上のノードＡ、Ｂ、Ｃから成る。ネットワー
ク３は、ローカル・エリア・ネットワーク（ＬＡＮ）　
、あるいは広域ネットワーク（ＷＡＮ）のどちらかであ
る。

ノードＡ１Ｂ、Ｃのどれにも、ワークステージジンなど
の処理システムＩＯＡ、ＩＯＢ、ＩＯＣがある。これら
の処理システムＩＯＡ、ＩＯＢ、１０Ｃはそれぞれ、遠
隔ノードにあるファイルにアクセスするためにネットワ
ーク３を使用することができる、単一ユーザ・システム
またはマルチユーザ・システムである。たとえば、局所
ノードＡにある処理システム１０Ａは、それぞれ遠隔ノ
ードＢ及びＣにあるファイル５Ｂ及び５Ｃにアクセスす
ることができる。

本明細書では、用語”サーバは、ファイルがそこに永久
に記憶される処理システムを表すために使用し、用語”
クライエント”は、ファイルにアクセスする処理を有す
る他の任意の処理システムを意味するために使用する。

ただし、用語”サーバは、ある種のローカル・エリア・
ネットワーク・システムで使用されるような専用サーバ
を意味しないことを理解されたい。本発明が実施される
分散サービス・システムは、実は、システム内の異なる
ノードで走行し、システム内のどこにあるファイルにも
アクセスできる、広範囲のアプリケージぼンを支援する
分散システムである。

上記のように、以下で説明する本発明は、通信ネットワ
ーク内の分散データ処理システムを対象とする。この環
境では、ネットワーク内のあるノードにある各プロセッ
サは、ファイルがどのノードにあろうと、ネットワーク
内のすべてのファイルに問題なくアクセスできる。

分散データ処理システムを支援する他の手法も知られて
いる。たとえば、ＡＩＸオペレーティング・システム用
のＩＢＭ分敢分散サービス米国特許出願第０７１０１４
８９７号明細書に開示されている。さらに、サン・マイ
クロシステムズ社（Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ
）は、ネットワーク−ファイル・システム（ＮＦＳ）を
発表し、ベル研究所は、遠隔ファイル・システム（ＲＦ
Ｓ）を開発した。

サン・マイクロシステムズのＮＦＳは、Ｓ、Ｒ，フライ
マン（Ｋｌｅｉｍａｎ）　　の「Ｖノード：サンＵＮＩ
Ｘにおける多重ファイル・システム・タイプ用のアーキ
テクチ＋　（Ｖｎｏｄｅｓ：Ａｎ　Ａｒｃｈｉｔｅｃｔ
ｕｒｅ　ｆｏｒＭｕｌｔｉｐｌｅ　　Ｆｉｌｅ　　Ｓｙ
ｓｔｅｍ　　Ｔｙｐｅｓ　　ｉｎ　　Ｓｕｎ　　ＵＮＩ
Ｘ）」ＵＳＥＮＩＸ１９８８年夏技術会議展示会報文集
、ｐｐ、２３８−２４７；ラッセル・サンドバーブ（Ｒ
ｕｓｓｅｔ　Ｓａｎｄｂｅｒｇ）他のｒサン・ネットワ
ーク・ファイル・システムの設計と実施様態（Ｄｅｓｉ
ｇｎ　ａｎｄＩｍｐｌｅｍｅｎｔａｔｉｏｎ　ｏｆ　ｔ
ｈｅ　Ｓｕｎ　Ｎｅｔｏｖｏｒｋ　ＦｉｌｅＳｙｓｔｅ
ｍ）　Ｊ　、Ｕ　Ｓ　Ｅ　Ｎ　Ｉ　Ｘ　１９８５報文集
、ｐｐ、ｔ１９−１３０；ダン・ウオールシー　（Ｄａ
ｎ　Ｖａｌｓｈ）他の「サンネットワーク・ファイル・
システムの概要（Ｏｖｅｒｖｉｅｗ　ｏｆ　ｔｈｅ　Ｓ
ｕｎ　Ｎｅｔｗｏｒｋ　ＦｉｌｅＳｙｓｔｅｍ）　Ｊ　
、ｐｐ、　１１７−１２４　；ジトメイ・チャン（Ｊｏ
）ｌｅｉ　Ｃｈａｎｇ）の「状態モニタはＮＦＳ用のネ
ットワーク・ロッキング・サービスを提供する（Ｓｔａ
ｔｕｓ　Ｍｏｎ１ｔｏｒ　Ｐｒｏｖｉｄｅｓ　Ｎｅｔｗ
ｏｒｋ　ＬｏｃｋｉｎｇＳｅｒｖｉｃｅ　ｆｏｒ　ＮＦ
Ｓ）　Ｊ　Ｎ　ジａＮメイ・チャン編「サンネット（Ｓ
ｕｎｓｅｔ）　Ｊ　、ｐｐ、　７１−７５　：及びプラ
トレイ・ティラー（Ｂｒａｄｌｅｙ　Ｔａｙｌｏｒ）の
１サン環境における安全なネットワーキング（Ｓｅｃｕ
ｒｅＮｅｔｖｏｒｋｉｎｇ　　ｉｎ　　ｔｈｅ　　Ｓｕ
ｎ　　Ｅｎｖｉｒｏｒｖｅｎｔ）Ｊ　　ｐｐ、２　８　
−３６を含む、一連の刊行物に記載されている。ＡＴ＆
ＴのＲＦＳも、アンドリューＰ・リフキン（Ａｎｄｒｅ
ｖ　Ｐ、　Ｒｉｆｋｉｎ）他の　ｒＲＦｓ構造の概要（
ＲＦＳ　　Ａｒｃｈｉｔｅｃｔｕｒａｌ　　Ｏｖｅｒｖ
ｉｅｗ）Ｊ　　、　（Ｕ　Ｓ　Ｅ　ＮＩＸ報文集、ジョ
ーシア州アトランタ（１９８６年６月）、ｐｐ−１−１
２；リチャード・ハミルトン（Ｒｉｃｈａｒｄ　）Ｉａ
ｍｉｌｔｏｎ）他の「遠隔ファイル共用に対する管理者
の見方（Ａｎ　Ａｄｍｉｎｉｓｔｒａｔｏｒ’ｓＶｉｅ
ｗ　　ｏｒ　　Ｒｅｍｏｔｅ　　Ｆｉｌｅ　　Ｓｈａｒ
ｉｎｇ）Ｊ　　％　　ｐｐ、　　１　−　９　　；トム
・ツートン（Ｔｏｍ　Ｉｌｏｕｇｈｔｏｎ）他の「ファ
イル・システム・スイッチ（Ｐｉｌｅ　５ｙｓｔｅｒａ
　５ｖｉｔｃｈ）４、ｐｐ。

１−２；及びデーヴイドＪ、オランダ−（ＤａｖｉｄＪ
　、　０１ａｎｄｅｒ　）他の、「システム■における
ネットワーキングのためのフレームワーク（Ａ　Ｆｒａ
ｍｅｗｏｒｋｆｏｒ　Ｎｅｔｖｏｒｋｉｎｇ　ｉｎ　５
ｙｓｔｅ＋＊　Ｖ）　Ｊ　％　ｐｐ、　１−８を含む、
一連の刊行物に記載されている。

遠隔ノードにあるデータにアクセスする際に遭遇する問
題のいくつかは、まず従来技術の分散データ処理システ
ムがどのようにファイルを使うかを検討すると、よりよ
く理解することができる。米国特許出願第０７１０１４
８９１号明細書に教示されているように、サーバ・ノー
ドに記憶されたファイルは、遠隔クライエント・ノード
上で走行する処理からアクセスすることができる。複数
のクライエントによるファイルの使用を同期し調整する
ために、そのような分散データ処理システム内で働くロ
ッキング機能が設けられている。ファイルをロックする
ことにより、処理はファイルを利用したいとの意図を示
す。実際は、排他的アクセスを望むことを示すロック、
共用アクセスを望むことを示すロック、ファイルの一部
分に対するロック、及びファイル全体に対するロックな
ど、様々な種類のファイル・ロックがある。複数のクラ
イエントが１つのファイルを使用中であることがあるの
で、置かれたロックを記述するデータ構造は、複数のク
ライエントが実際にファイルを使用中である可能性があ
る時は、サーバで保持される。単一のクライエントがそ
のファイルの唯一のユーザであることが明らかな場合に
は、ロックを記述するデータ構造は、そのクライエント
で保持される。従来技術では、このデータ構造がどこに
あるかの判定は、ファイルを開いた処理に基づいて行な
われる。ファイルにロックをかける前に、処理はそれら
のファイルを開かなければならない。

したがって、ファイルを開いた処理がすべて１つのノー
ドにある時は、そのファイルにかけたロックを記述する
データ構造は、そのノードに保持される。

この従来技術の手法に伴う難点は、この判定が、どの処
理がファイルを開いたかに基づいていることから生じる
。ファイルが複数のクライエントに共用される状況では
、ロックを記述するデータ構造は、−時にただ１つの処
理しかファイルをロックするのに関係していないにもか
かわらず、常にサーバで保持される。異なるクライエン
トにある処理がファイルを開く時、ロックを記述するデ
ータ構造を配置し直す必要があるため、もう１つの難点
が生じる。サーバにある資源に制限があるため、これを
開く時にデータ構造をサーバに戻すことが不可能となる
ことがある。それが発生すると、ロッキング情報が失わ
れるか、（非常に望ましくない選択肢）あるいは開いた
動作が拒絶される（ｍ＝のアプリケ−シロンが扱う準備
を終えている状況）。

従来技術によって教示されるように、ロックに対する要
求は、ロックを記述するデータ構造がサーバにある時は
、サーバに送られる。これらの要求は、サーバにあるカ
ーネルによって実行される。

カーネル処理とは、ロックを記述するデータ構造を含む
オペレーティング・システムのデータにアクセスできる
処理である。競合するロックがすでにかけられているた
めにロック要求が許可できない時は、妨げとなっている
ロックが解除され、要求されたロックがかけられるまで
待つように、はとんどのロック動作は設計されている。

従来技術によって用いられる技術に伴う問題は、妨げと
なっているロックが解除されるまで、カーネル処理（ｋ
ｐｒｏｃｓ　）がサーバで待たなければならないことで
ある。ｋｐｒｏｃｓは、サーバの資源を消費し、したが
ってその数が制限される。妨げとなるロックが存在する
時、カーネル処理を強制的に遊休状態にすると、その設
計は、すべての利用可能なｋｐｒｏｃｓが消耗しやすく
なる。いくつかのクライエントの処理が共用ファイルに
アクセスしているアプリケージ「ンでは、１つの処理が
ファイルをロックし、その後ユーザ・エラーまたはソフ
トウェア・エラーのために、ファイルのロックを解除で
きなかった場合、多数のｋｐｒｏｃｓが無期限に拘束さ
れることがある。極端な状況では、使用可能なすべての
ｋｐｒｏｃｓが、このようにして占有され、システムが
もうそれ以上遠隔動作を支援できなくなる。

したがって、処理がファイルを開くことに基づいである
ファイルに対するロックを記述するデータ構造を探さず
、かつ妨げとなるロックがある時１’：　ｋｐｒｏｃｓ
が待つ必要のない、遠隔ファイルをロックするためのシ
ステム及び方法を提供すれば、分散データ処理システム
において大きな利益となるはずである。

Ｃ２課題を解決するための手段 したがって、分散データ処理システムにおいて、ファイ
ルに対するロックは、クライエント機械またはそのファ
イルのサーバのどちらかに存在するデータ構造によって
支援される。ただ１つのクライアントの処理だけがファ
イルをロックしている時は、データ構造はそのクライエ
ント上に存在することができる。複数のクライエント機
械があるファイルに対してロックをかけようと試みる時
は、そのデータ構造はサーバに移される。このため、ロ
ック動作を実行する時、ファイルをロックしているクラ
イエントはサーバと通信することを強いられる。

クライエントで実行されるロック動作は、クライアント
に１つのファイル・ロック・データ構造がある時、その
データ構造を使用する。データ構造がロッキングを行な
っているクライアント内にある時は、サーバとの通信は
必要ない。デーフッ構造がクライエントにない時は、ク
ライエントはそのロック要求をサーバに送る。その要求
を受け取ると、ファイルのサーバは、要求されたロック
動作がファイルに現在適用されている唯一のものである
のかどうか決定する。それが唯一のものである場合は、
サーバは、ロック要求メンセージに応答して、クライエ
ントがそのノードでロッキング情報の維持を始めること
ができることを示す回答を出す。後で第２のクライエン
トが、このファイルに対するロック要求をサーバに送っ
た場合、サーバは第１のクライエントのロックを維持す
るデータ構造を取り消す。第１のクライエントは、デー
タ構造をサーバに送り戻し、その後（ロック情報の維持
を開始できることをサーバから再び知らされるまで）サ
ーバに要求を送ることにより、ロッキング動作を実行す
る。

クライエントが、妨げとなるロックが存在するために許
可できないサーバからのロックを要求する時、クライエ
ントは、要求処理を、再試行通知を待って休眠している
伏態に置くようにと指示される。ファイルに対するロッ
クに、そのようなりライエンドの現在休眠中の処理がロ
ックを獲得できそうな、変更がある時、サーバはクライ
エントに再試行通知を送る。これによって、クライエン
トで休眠中の処理が覚醒し、その処理は、次いでメツセ
ージをサーバに送ることによって、ロック動作を再び試
みる。

本発明の上記及びその他の目的、特徴、拡張、及び利点
は、添付の図面内に図示した本発明の好ましい実施例に
ついての下記のより具体的な説明から明らかになる。

Ｄ、実施例 本発明を、次のシナリオで例示する。本発明の改良によ
って機能が改善された、第１図の従来技術のネットワー
クを参照すると、クライエント１０Ａは、サーバ１０Ｃ
に記憶されているファイル５Ｃにロックをかけることを
要求するメツセージをサーバ１０Ｃに送る。サーバＩＯ
Ｃはフライエン）１０Ａの要求に答えて、現在そのファ
イルにロックがかかっていないと知らせ、かつサーバに
よって取り消されるまで、クライアント１０Ａにロック
情報を維持するようにと指示する。その後クライエント
ＩＯＢが、同じファイルに対するロック要求をサーバ１
０Ｃに送る。その場合、サーバ１０ＣはクライエントＩ
ＯＡに取り消しロック・メツセージを送る。それに応じ
て、クライアント１０Ａは、サーバＩＯＣにそのファイ
ルに対するロック情報を送り戻す。サーバＩＯＣは、こ
の時、クライアントＩＯＢによるロック要求が許可でき
ないこと、及びクライエントＩＯＢ上の処理が、ロック
を獲得するまで待たなければならないことを発見するこ
とがある。サーバ１０Ｃは、クライエントＩＯＡが妨げ
となるロックの１つを除去する時、再試行通知がクライ
エント１０Ｂに送られることを示す回答中で、クライエ
ントＩＯＢにこのことを示す。クライエントＩＯＢが再
びファイルのロックを試みる時、クライエントＩＯＢが
その再試行を実行する前にかけられたのと異なる口。

りまたは同じロックによって依然として妨げられている
こともある。

第２図は、そのクライエントで実行中の処理がファイル
に対するロック動作の実行を試みる時に、クライアント
・ノードで行なわれる処理を示すフローチャートである
。クライエントをサーバに接続する通信機械によってメ
ツセージが遅延する可能性があることから、２つの具体
的問題が発生する。これらの問題は、第２図に示した処
理によって扱われる。

この処理は、まず他のロック要求がそのファイルに対し
て進行中でないことを確かめる。他の口、。

り要求がこのファイルに対して進行中でないことを保証
することにより、−時に１つのファイルに対してわずか
１つのロック要求しか未処理となり得ない。第１の要求
に対する回答がクライエントに到着する前に、第１のロ
ック要求に答えたサーバに第２のロック要求が送られる
場合、問題が発生する可能性があるので、このことは重
要である。

この場合、サーバは、第１の要求に対する回答中で、そ
のクライエントにあるファイルに対する口、ツクを記述
するデータ構造を保持するための許可をクライエントに
与えることができる。このようにして、ロッキング情報
を記録するようにクライエントに指示した後、サーバは
、後続のロック要求を満足することを求められることを
予期しない。

クライエントが第１のロック要求に対する回答を受け取
る前に、第２のロック要求がそのクライエントから出さ
れる場合に、この望ましくない状況が発生し得る。この
ため、クライエントでのロック処理は、そのファイルに
対する後続のロック要求を開始する前に、ファイルに対
する未処理のロック要求が回答されるまで待つ。

進行中の未処理のロック要求がないことを確認した後、
ロック処理は、ファイル・サーバから受け取ったそのフ
ァイルに対するロック取消し要求の処理を妨げる。これ
は、ロック取消し要求が、回答中で許されるロックを参
照できるクライエントで処理される前に、サーバに送ら
れるロック要求に対する回答を受け取ることを保証する
ために重要である。ロック取消し要求が妨げられなかっ
た場合は、クライエントはファイルをロックするための
要求を送ることができ、サーバはその要求を許可して、
クライエントに回答を送ることができ、またサーバは、
次いで許可されたばかりのロックを参照するロック取消
しを出すことができる。

この場合に、ロック要求に回答する前にロック取消し要
求がクライエントに到着した場合は、クライエントは取
消しを正しく処理することができず、さらにロックに対
する回答が到着した時、クライエントは、ファイルに対
するロックを有すると、間違ってとるかも知れない。

第２図を参照すると、ステップ２０１で、テストを行な
って、そのファイルに対する処理中の未処理のロック要
求があるかどうか判定する。ある場合は、ステップ２０
６で、現在処理中の要求が待ち行列に入れられ、ステッ
プ２０７で、未処理の要求が完了した時に覚醒すべく休
眠状態に置かれる。これが起こると、処理ループはステ
ップ２０１に戻る。そのファイルに対する進行中のロッ
ク要求がない場合は、ステップ２０２に進み、ロック取
消し要求の処理が妨げられる。これは、現在処理中のロ
ック取消し要求が完了するまで現行の要求が待ち、さら
に後で解禁されるまで、まだ始まっていないロック取消
し要求が開始するのを防げることを意味する。ステップ
２０３で、このファイルに対するロック情報を記述する
データ構造（今後、このファイルに対する「ロック・テ
ーブル」と呼ぶ）が、局所的に保持されているかどうか
判定する。ステップ２０４で、ロック・テーブルが局所
にあり、ロック動作が局所テーブルで実行される場合、
次に進む。ステップ２０５で、ロック取消し要求の処理
が解禁される。

そのファイルに対するロック・テーブルが局所にない時
は、ステップ２１２に進み、このファイルに対するロッ
ク要求がサーバに送られる。ステップ２１４で、処理は
、ロック要求に対する回答を待つ。回答が到着すると、
ステップ２１５に進み、回答を検査する。その回答が、
処理を後で再び試みるようにと指示する場合は、ステッ
プ２１６に進んで、ロック取消し要求処理が解禁される
。ステップ２１３で、処理は、再試行メツセージを受け
取る時に覚醒すべく休眠状態に置かれる。覚醒すると、
ステップ２１７で、ロック取消し要求処理が妨げられ、
２１２に戻る。

ロック要求に対する回答が、後で再び試行するようにと
指示しない場合は、ステップ２０８で、回答を検査する
。回答が、ロックをこのクライエシトで局所的に保持す
るようにと指示する場合は、ステップ２０９に進む。ス
テップ２０９で、このファイルに対する局所ロック・テ
ーブルを作成する。ステップ２１０で、元のロック要求
を四ツク・テーブルに入れる。ステップ２０４でロック
・テーブルにロックを入れると、このファイルに対する
妨げとなるロックが別の処理によって解除されるまで、
待つことが必要となるこきがある。しかし、ステップ２
１０で、ロック・テーブルにロックを入れても、テーブ
ルが新しく作成された空のテーブルなので、妨げとなる
ロックを待つ必要はない。

これでロック要求が完了したので、ステップ２１１で、
ロック取消し要求の処理が解禁され、ロック取消し処理
が先に進むことが可能になる。

下記のプログラミング設計言語リストは、そのクライエ
ントで実行中の処理が、ファイルに対するロック動作の
実行を試みる時に、クライエント・ノードで行なわれる
上記の処理の、他の形による記述である。このリストは
、第２図について上述した動作と並行している。

／＊クライエンシト走行中の処理によるロッキング要求
＊／ ＷＨＩＬＥ　　ファイルに対して他のロック要求が進行
中　Ｄ。

待機中のロック要求側のリストにこの要求を入れる； 休眠する、ロック要求の完了時に覚醒する；ＥＮＤＷＨ
ＩＬＥ； この要求が進行中であることを示して、他の要求を休眠
させる； 新しいロック取消し要求が処理を開始されるのを妨げる
； ＩＦ　　ロック取消し要求が進行中　ＴＨＥＮ取消しが
完了するまで待つ； ＥＮＤ　Ｉ　Ｆ　； ＩＦ　　ファイルに対するロック・テーブルが局所にあ
る　ＴＨＥＮ ロック動作を実行する； ロック取消し要求の処理を解禁する； ＬＳＥ ロック要求をサーバに送る； 回答を待つ； ＷＨＩＬＥ　　回答が後で再び試行と指示するり。

ロック取消し要求の処理を解禁する； 休眠する、再試行メツセージで覚醒する；ロック取消し
要求の処理を妨げる； ロック要求をサーバに送る； 回答を侍つ； ＥＮＤＷＨＩ　ＬＥ　； ＩＦ　　回答が局所ロックの保持を始めよと指示する　
ＴＨＥＮ ファイルに対するロック・テーブルを作成する； ロックを局所テーブルに入れる； ＬＳＥ ／零回答が、遠隔ロッキング要求の結果を指＊／／＊示
する＊／ ＥＮＤ　　Ｉ　　Ｆ　　； ＥＮＤ　　Ｉ　　Ｆ　　； ／＊ロック動作は完了し、そのファイルミＺ対する＊／
／木他のロック要求に進むことができる＊／第３図は、
ロック要求に応じてサーバで実行される動作を示す流れ
図である。ファイル・ロック解除要求は、クライエント
への再試行通知の送信をトリガすることができる。クラ
イエントがらファイル・ロック要求があると、ロック・
テーブルを局所的に保持できること、あるいは再試行メ
ツセージを受け取るまで休眠すべきこと、あるいはロッ
ク動作が実行されたことがクライエントに知らされる。

これらのケースは、第３図に図示されている。

例として、クライエントＩＯＡが、サーバ１゜Ｃに記憶
されているファイルに対するロック・テーブルを現在維
持しているものと仮定する。クライエント１０Ｂが、こ
のファイルに対するロックを要求した場合、クライエン
トＩＯＣは、ロック取消しメツセージをクライエントＩ
ＯＡに送り、クライエントＩＯＣがもつ、ロック・テー
ブルを受け取るのに使用できる空間の量をクライエント
１ＯＡに知らせる。クライエントＩＯＡは、そのロック
・テーブルが大きすぎてこの空間に収容できないと判断
した場合、このことの指示をサーバ１０Ｃに戻す。この
場合、サーバ１０Ｃは、そのロック要求が許可されず、
失敗したとの回答をクライエントＩＯＢに送る。

第３図のステップ３１３で、ロック・テーブルがクライ
エントに記憶されているかどうか判定する。そうである
場合は、ステップ３１４で、サーバはロック取消しメツ
セージをクライエントに出す。ステップ３１５で、この
ロック・テーブル情報がうまく戻された場合は、ステッ
プ３０１に進む。（たとえば、ロック・テーブルのサイ
ズが、サーバにある、ロック・テーブルを記憶するのに
使用可能な空間を超えたため）ロック・テーブルがうま
く戻されなかった場合は、ステ、ブ３１６で、ロック要
求を拒絶し、クライエントにその旨を知らせる。

ステップ３０１で、実行中の要求のタイプを検査する。

要求がロック解除要求である場合は、ステップ３１０に
進み、以前にロック要求に対する回答を送られ、再メツ
セージを待って休眠させられたクライエント、及びロッ
ク解除が実行された後にその元のロック要求が許可され
る可能性のあるクライエントを決定する。ステップ３１
１で、ロック解除動作を実行し、結果を表示する回答を
要求側に送る。ステップ３１２で、影響を受けるすべて
のクライエントに再試行メツセージを送る。

要求のタイプがロック要求である場合は、ステップ３０
２に進み、現在ファイルに対する他のロックがあるかど
うか判定する。ない場合は、ステップ３０８に進み、ク
ライエントが局所ロック・テーブルを作成できることを
示す、元のロック要求に対する回答を送る。ステップ３
０９で、局所ロック・テーブルを維持しているクライエ
ントの記録を作る。

ファイルに対する他のロックがないと判定した場合は、
ステップ３０３に進んで、さらに、その要求が待つ必要
があるかどうか決定する。その要求が、すでに確立され
たロックに、その要求を待だせる形で干渉する場合は、
ステップ３０６に進んで、クライエントでの要求処理を
再試行メツセージを待つ休眠状態にするようにと指示す
る回答を送る。干渉をひき起こすロックに関連して、再
試行メツセージを待っているクライエントの記録をロッ
ク・テーブル内で作る。

その要求が、待つ必要なしに実行される場合は、ステッ
プ３０４に進んで、この要求を実行する。

ステップ３０５で、要求の結果を示す回答をクライエン
トに送る。

下記のプログラミング設計言語リストは、ロック要求に
応じてサーバで実行される上記の動作の、他の形による
記述である。このリストは、第３図について上述した動
作と並行している。

／＊ロック要求のサーバ処理＊／ ＩＦ　　ファイルに対するロック・テーブルが現在クラ
イエントにある　ＴＨＥＮ ロック・テーブルを有するクライエントにロック取消し
要求を送る； 回答を待つ； ＩＦ　　ロック・リストを戻すことができないＴＨＥＮ 要求が失敗したことを示す、ロック要求に対する回答を
送る； ＲＥＴＵＲＮ　； ＥＮＤ　Ｉ　Ｆ　； ＥＮＤ　Ｉ　Ｆ　； ＩＦ　　要求がロッキング要求である　ＴＨＥＮＩＦロ
ック・テーブルが少なくとも１つのエントリを有する　
ＴＨＥＮ ＩＦ　　その要求がすでにテーブル内でロックによって
妨げられている　ＴＨＥＮ 再試行通知を待って休眠しなければならないとの回答を
クライエントに送る： クライエントを、再試行を待っているクライエントのロ
ック・テーブル・リストに加える； ＬＳＥ ／＊要求が妨げられていない＊／ 要求を実行する： 回答をクライエントに送る； ＥＮＤ　Ｉ　Ｆ　； ＬＳＥ ／＊ファイルに対するロックがまだない＊／ロツタ・リ
ストを維持するようにとの回答をクライエントに送る； このクライエントがロック・テーブルをもっていると記
録する； ／＊将来の取消しで使用するため＊／ ＥＮＤ　Ｉ　Ｆ ＬＳＥ ／＊要求がロック解除要求である＊／ ロック・テーブル内で再試行を必要とするクライエント
のリストを走査することにより、影響を受けるクライエ
ントを決定する； ロック解除動作を実行する； ロック解除の要求側に回答を送る； 影響を受ける各クライエントに再試行メツセージを送る
； ＥＮＤ　Ｉ　Ｆ　； 第４図は、ファイル・ロック・テーブル４０１の構造を
示している。テーブルは、個々のエントリ４１０を含む
。それぞれのエントリ４０１は、４つのフィールド４０
４−４０７を有する。エントリ４０４は、ロックの範囲
とタイプを記述する。

範囲とは、このフィールドに示されたロックのタイプに
応じて、共用または排他的使用のためにロックされた、
ファイル中のバイトの範囲を表す。エントリ４０５は、
ファイルをロックした処理を識別し、エントリ４０６は
、この処理がそこで走行しているクライエント・ノード
を識別する。エントリ４０７は、要素４０２のリストを
指すポインタを含むリンク・フィールドである。各要素
は、次の要素に対するリンク、またはリストの終りを示
す値を含む、フィールド４０９を含む。各要素のフィー
ルド４０８は、要求処理が、再試行メツセージを送るま
で休眠するようにと指示する、ロック要求に対する回答
を送られたクライエントを識別する。ロックが解除され
ると、要素のリストを走査して、再試行通知が各クライ
エントに送られる。

要約すると、ファイルに対するロックが、クライエント
機械またはファイル・サーバのどちらかにあるデータ構
造によって支援されるという、分散データ処理のシステ
ムと方法が開示されている。

ただ１つのクライエントの処理だけがファイルをロック
している時は、データ構造はそのクライエントに存在す
ることができる。複数のクライエント機械があるファイ
ルにロックをかけようと試みる時は、データ構造はサー
バに移される。これによって、ロック動作を実行する時
、ファイルをロックするクライエントはサーバと通信す
ることを強いられる。クライエントがサーバから、妨げ
となるロックが存在するために、許可されないロックを
要求した時は、クライエントは、要求処理を再試行通知
を待って休眠状態にするようにと指示される。ファイル
に対するロックに、そのようなりライエンドの現在休眠
中の処理がロックを獲得できそうな変更がある時、サー
バは、再試行通知をクライエントに送る。これによって
、クライエントにある休眠中の処理が覚醒し、次いでそ
の処理は、サーバにメソセージを送ることによって、ロ
ック動作を再び試みる。

【図面の簡単な説明】

第１図は、当技術分野で周知の分散データ処理システム
のブロック・ダイヤグラムである。 第２図は、クライエントで実行中の処理が、ファイルに
対するロック動作の実行を試みる時に、クライエント・
ノードで行なわれる処理を示すフローチャートである。 第３図は、ロック要求に応じてサーバで実行される動作
を示すフローチャートである。 第４図は、ファイル・ロック・テーブルの構造を示す図
である。 Ａ、ＢｌＣ・・・・ノード、１・・・・ｌネットワーキ
ング環境、３・・・・ネットワーク、ｌ０Ａ１１０Ｂ・
・・・クライエント・ノード、１０Ｃ・・・・サーバ・
ノード。 ぜＤ

Claims (6)

【特許請求の範囲】
1. （１）少なくとも１つのクライエント機械がサーバに記
   憶されたファイルにアクセスできるようにした、分散デ
   ータ処理システムのサーバに記憶されたファイルの一部
   分をロックする方法であって、前記１つのクライエント
   機械が、前記ファイルの前記部分をロックしようと試み
   る唯一のクライエント機械である時に、前記ファイルの
   前記部分に対するロックを記述するデータ構造を、その
   クライエント機械で維持するステップと、 複数のクライエント機械が、前記ファイルの前記部分を
   ロックしようと試みている時に、前記データ構造を前記
   サーバで維持するステップとを有することを特徴とする
   ファイル・ロック方法。
2. （２）少なくとも１つのクライエント機械がサーバに記
   憶されたファイルにアクセスできるようにした、分散デ
   ータ処理システムのサーバに記憶されたファイルの第１
   部分をロックする方法であって、前記ファイルの前記第
   １部分をロックすることを求める１つのクライエント機
   械からの要求を、前記サーバで受け取るステップと、 他のクライエント機械が前記ファイルのいずれかの部分
   をロックしたかどうかを、前記サーバで検出するステッ
   プと、 他のクライエント機械が前記ファイルのどの部分もロッ
   クしようと試みない間、前記１つのクライエント機械が
   前記ファイルの前記第１部分に対する前記ロックを局所
   的に維持することができると、前記１つのクライエント
   機械に回答するステップとを有することを特徴とするフ
   ァイル・ロック方法。
3. （３）少なくとも１つのクライエント機械が、サーバに
   記憶されたファイルにアクセスできるようにした、分散
   データ処理システムのサーバで記憶されるファイルをロ
   ックする方法であって、 前記ファイルの一部分をロックすることを第１のクライ
   エント機械が試みるステップと、他のクライエント機械
   が前記ファイルの前記部分のデータをロックしたかどう
   かを、前記サーバで検出するステップと、 前記ファイルの前記部分が前記他のクライエント機械に
   よってすでにロックされているとき、前記ファイルに対
   する前記の試みられたロックを要求する処理を前記第１
   のクライエント機械で休眠させるように、前記サーバか
   ら前記第１のクライエント機械に通知するステップとを
   有することを特徴とするファイル・ロック方法。
4. （４）少なくとも１つのクライエント機械が、サーバに
   記憶されたファイルにアクセスできるようにした、分散
   データ処理システムのサーバに記憶されたファイルの第
   １部分をロックする装置であって、 前記ファイルの前記第１部分をロックすることを求める
   １つのクライエント機械からの要求を、前記サーバで受
   け取る手段と、 前記受取り手段に応答して、他のクライエント機械が前
   記ファイルのいずれかの部分をロックしたかどうかを前
   記サーバで検出する手段と、他のクライエント機械が前
   記ファイルのどの部分もロックしようと試みない間、前
   記１つのクライエント機械が前記ファイルの前記第１部
   分に対する前記ロックを局所的に維持することができる
   と、前記１つのクライエント機械に回答する、前記検出
   手段に接続された手段とを有することを特徴とするファ
   イル・ロック装置。
5. （５）少なくとも１つのクライエント機械が、サーバに
   記憶されたファイルにアクセスできるようにした、分散
   データ処理システムのサーバに記憶されたファイルをロ
   ックする装置であって、 前記試行手段に応答して、前記ファイルの一部分をロッ
   クすることを第１のクライエント機械によって試みる手
   段と、 他のクライエント機械が前記ファイルの前記部分のデー
   タをロックしたかどうかを、前記サーバで検出する手段
   と、 前記ファイルの前記部分が、前記他のクライエント機械
   によってすでにロックされているとき、前記ファイルに
   対する前記の試みられたロックを要求する処理を前記第
   １のクライエント機械で休眠させるように、前記サーバ
   から前記第１のクライエント機械に通知する、前記検出
   手段に接続された手段とを有することを特徴とするファ
   イル・ロック装置。
6. （６）少なくとも１つのクライエント機械が、サーバに
   記憶されたファイルにアクセスできるようにした、分散
   データ処理システムのサーバに記憶されたファイルの第
   １部分をロックするデータ処理プログラムであって、 前記ファイルの前記第１部分をロックすることを求める
   １つのクライエント機械からの要求を、前記サーバで受
   け取る手段と 前記受取り手段に応答して、他のクライエント機械が前
   記ファイルのいずれかの部分をロックしたかどうかを、
   前記サーバで検出する手段と、他のクライエント機械が
   前記ファイルのどの部分もロックしようと試みない間、
   前記１つのクライエント機械が前記ファイルの前記第１
   部分に対する前記ロックを局所的に維持することができ
   ると、前記１つのクライエント機械に回答する、前記検
   出手段に接続された手段とを有することを特徴とするデ
   ータ処理用プログラム製品。