JP4999833B2 - 複数の独立プロセスによってアクセス可能なキャッシュメモリの一貫性を維持する方法及びシステム - Google Patents

Description

本発明は、一般に、ソフトウェア工学に関し、より詳細には、データの永久的利用可能性を必要とし且つそのデータに対する短いアクセス時間を保証する情報技術環境において独立プロセスによってアクセス可能なキャッシュメモリ内のデータの一貫性を長期間維持する方法及びシステムに関する。

コンピュータとその中央処理装置（ＣＵ、即ち、英語技術文献ではＣＰＵ（Central Processing Unit））の計算能力は、この数年の間に著しく向上したが、それと同時に、ますます要求が厳しくなってきているソフトウェアアプリケーションは、そのような中央処理装置の使用度を高めることによって処理能力の向上を利用するようになっている。これは、特に、中央処理装置が、例えば航空交通の世界的入札を含むデータベースなどの多量の情報を記憶しなければならない中央記憶装置内のデータにアクセスしなければならないときに当てはまる。そのようなデータは、無数の旅行代理店や販売拠点が連続的に調べることができ且つ世界中の航空会社が何時でも更新することができなければならない。

その成果を得るためにコンピュータネットワーク及びＩＴソリューションが使用する構成に関わらず、期待される性能、特に求められる情報に対するアクセス時間を短くするには、必ず記憶階層（memory hierarchy）の使用が必要となる。求められる情報は、実際には、中央装置が十分素早くアクセスすることができる記憶装置に送られなければならない。これは、そのような記憶装置が、求められる可能性のある全ての情報を含んでいない場合でも行われる。このタイプの記憶装置は、キャッシュメモリ又は大容量記憶装置（bulk storage）と呼ばれる。キャッシュメモリは、システムが所定の時間に最も頻繁にアクセスするデータを記憶する役割をし、それにより、中央装置とコンピュータプロセッサの待ち状態を短縮することができる。

必然的に限られたサイズのキャッシュメモリは、中央装置内で同時に実行しなけばならない様々な独立プロセス間で共用できなければならない。更に、複数の独立タスクが共通データを処理しているときに、複数の独立タスクがそのようなデータを複製せずに実行できることが好ましい。

従って、複数のプロセスによってアクセス可能なキャッシュメモリの管理は複雑な作業である。特に、幾つかのプロセスに共通のデータの一貫性を維持することが重要である。複数のプロセスのうちのあるプロセスが前記データを変更しなければならない場合、そのデータが完全に変更され更新されるまで別のプロセスがそのデータを使用できることが極めて重要である。プロセス間のメッセージ交換によってこれを達成できることは周知であるが、この方法は、メッセージ交換に必要な時間によってこのデータに対するアクセス速度が大きな影響を受ける方法である。

現在使用されている別の方法は、あるプロセスが共用データに対するアクセス権を排他的且つ一時的に取得できるようにし、それにより他のプロセスによるアクセスを阻止する方法であり、他のプロセスは待たなければならない。しかしながら、あるプロセスが、そのようなアクセス独占権を取得すると、そのプロセス自体も、やはり使用しなければならないデータを別のプロセスが開放するのを待たなければならない場合がある。従って、２つ以上のプロセスがインターロックされ、あるプロセスが他のプロセスが終了するのを待ちまたその逆になる場合があることは明らかである。これらのプロセスが実行しなければならないタスクは進まず閉塞状態になる。

当然ながら、プロセスと同じ数のキャッシュメモリを備えることも可能である。その結果、キャッシュメモリ内に共通データが複製される。共通データの複製は、主に使用可能なメモリスペースをより良く利用するために回避しなければならず、またこの場合も同じキャッシュメモリ内の複製データの一貫性の問題を引き起こす。

更に、キャッシュメモリは、プロセス自体によって使用される作業データを収容するだけでなく、厳密に編成されなければならない。実際に、キャッシュメモリは、常に、典型的には数テラバイト（１０^１２バイト）のデータを記憶できる磁気ディスク群のバックプレーン内に配置された遅くて低コストであるが極めて大きいメモリ内にある全てのデータの部分的且つ極めて動的なビューを提供する。この作業データは全て、共用キャッシュメモリに転送された後で所定の時間にプロセスによってアクセスされる可能性がある。従って、キャッシュメモリの組織化データ（organisationaldata）は、キャッシュメモリ内に所定の時点で実際に存在する作業データとバックプレーンメモリ内にある対応するデータ間の一貫性を維持できなければならない。しかしながら、プロセスが、正常終了の前に中断された場合（例えば、単にオペレータが要求を終了するのが早すぎたため）、或いはソフトウェアのプログラミングが不十分なためにプロセスが間違って実行された場合、キャッシュメモリの組織化データは、完全には更新されなかったり間違って更新されたりする可能性がある。この場合、この組織化データを含む制御テーブルが部分的に破壊される。アプリケーションソフトウェアは、一般に、部分的破壊により重大な結果が生じないように破壊やエラーを許容するように設計されているが、四六時中長期間動作し続けなければなければならないシステムにそのような破壊が蓄積すると、実際に使用できるメモリサイズが減少して、特に長期間でのキャッシュメモリの性能と効率が低下する。これにより、所定の時間に実行しなければならない全てのプロセスが共用することができる十分な作業データが、世界中の航空交通に関する情報や大きなホテルチェーンの予約を含むデータベースのような大きなデータベースにアクセスしなければならないコンピュータから生じる多数の要求に応えられなくなる。

従って、有効に使用できるキャッシュメモリのサイズは、その動作の重要なパラメータである。それは、最適な程度に満たされていなければならない。詳細には、キャッシュメモリが既に満杯の場合でも、プロセスは、常に、新しいクライアントの要求に応えるために新しい作業データを供給できなければならない。これは、スペースを開放することのみによって達成でき、従って、再使用される可能性の低い作業データ或いは事実上期限切れのデータ又は古すぎるデータをメモリから削除することによって達成することができる。このソリューションは、基本タスクが通常通り実行されなくなった場合に、キャッシュメモリが、期限切れのデータで満杯になるためにすぐに使用できなくなるという深刻な欠点をもつ。更に、基本タスクは、一般に、完全に又は通常通り実行されなかったプロセスによって破壊されたデータを開放することができない。

しかしながら、２４時間動作しなければならず従って再起動されることがないシステムでは、システムの信頼性は、よくあることだが、典型的に前述の基本タスクの単一要素の適正な動作に基づくものでなければならない。

以上述べたような先行技術の弱点の幾つかを改善しようとする機構が、米国特許庁又はＵＳＰＴＯ（米国特許商標庁）に提出された特許出願（公開番号２００３／０１９５８６６）で提案された。しかしながら、「Ｔｒａｎｓａｃｔｉｏｎ−ａｗａｒｅ ｃａｃｈｉｎｇ ｆｏｒ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｍｅｔａｄａｔａ」という名称で２００３年１０月１６日に公開されたこの特許出願は、既に満杯になっているキャッシュ内のスペースを開放する機構について何も説明しようとしていない。従って、このキャッシュ内のスペースの開放は、全く再起動されず、連続的な要求によってキャッシュメモリ内に絶えずデータが蓄積しやすいシステムで一定時間使用された後でしばしば必要になる動作である。

米国特許出願 公開番号２００３／０１９５８６６

従って、本発明の目的は、一般に先行技術の弱点を改善し、特にキャッシュメモリが新しいデータを収容しなければならないときにスペースを開放するために、プロセスのいかなるロックも適切に防ぐことによってキャッシュメモリの管理を改善することである。

本発明は、独立プロセスによってアクセス可能なキャッシュメモリの一貫性を維持する機構について説明する。プロセスは、共通データを共用する場合がある。プロセスは、同時にデータ検索動作を実行した後で、任意的にデータをプロセスが使用できるようにし、そのデータの削除又は新しいデータの挿入を実行する。検索、削除及び挿入動作は、独立プロセスによって開始された後で包括的に実行される。これらは、共通データを処理しなければならないときに互いに排他的に実行される。削除動作又は挿入動作はそれぞれ完全に可逆的である。この情況において、本発明では、ロッキングを防ぐために、データを使用可能にする動作、削除する動作、又は挿入する動作を、有限、即ち実行持続時間が制限されたものとしている。特に、挿入動作は、キャッシュメモリのある区分が満杯のときにエントリを開放する段階を含み、選択をするために区分全体を参照しなければならない場合がある。しかし、最大参照時間に達すると挿入動作は中断される。この場合、既に参照したエントリの中からの最も適切なエントリが開放される。具体的には、挿入動作は、エントリを開放する段階であって、最大参照時間を定義する段階と、新しいデータのサイズを決定する段階と、区分のエントリを参照する段階と、最大参照時間に達したときにエントリの参照を中断する段階と、参照したエントリの中から新しいデータを収容するのに十分なサイズを有する最も適切なエントリを選択する段階と、最も適切なエントリを開放する段階とを含んでいる段階と、最も適切なエントリに新しいデータを挿入し、それにより挿入動作は実行持続時間が制限される段階とを含む。区分のエントリが余すところなく参照されるが、これは各開放後に区分の最後に調べたアドレスを記憶する結果として生じる。

本発明の目標、目的、並びに機能及び利点は、添付図面によって示された本発明の好ましい実施形態の後述する詳細な説明から明らかになるであろう。

図１に図表で示したように、本発明は、高速アクセス記憶手段（１２０）を共用するコンピュータの一台以上の中央装置（ＣＵ）（１１０）を備えたシステム（１００）に関する。しかしながら、容量が限られた共有メモリ（ＳＭ）自体は、バックプレーンに配置されて一般に極めて大量のデータを記憶することができる磁気ディスク群（１３０）から成る一台以上のマスメモリ（ＭＭ）にアクセスすることができる。特に、このデータは、データベース、例えば、世界中にある旅行代理店が調べなければならず、また世界の航空交通又は国際的ホテルチェーンの予約状況に関する全ての情報を収集するデータベースである。中央装置は、オペレーションシステムの制御下で動作する。例えば、ＵＮＩＸ（登録商標）は、多数のユーザ（１４０）が同時にアクセスできるだけでなく、同時に別々に動作する多数のプロセスタスクを生成することができるため、よく使用されるオペレーティングシステムである。従って、制御機構（１２５）を含む共用システムでは、オペレーティングシステムは、直接或いはオペレーティングシステムに組み込まれた追加のソフトウェアレイヤによって、一個以上のキャッシュロジックエンティティ（ＣＬＥ）を定義することができる。従来技術の段落で既に述べたように、これらのキャッシュメモリ（１５０）の目的は、マスメモリ（１３０）から高速アクセスメモリ（共有メモリ（１２０））に、中央装置（１１０）によって開始される独立プロセスが所定の時間に処理すべきデータを供給することができることである。

図２は、独立プロセス（２００）（この例では１から５の参照番号を付けた）が、共通データのエンティティ（２１０）を共用できるようにする本発明の新しい様相を詳細に示す。共用できるようにする前に、これらのプロセスのうちの１つのプロセス（この例では番号３で示したプロセス）だけが、マスメモリ（２３０）内のデータを見つけ、そのデータを所定の時間に処理しなければならない可能性が高い全てのプロセスが有効に使用するのに必要なフォーマッティングと演算（２２０）を実行しなければならない。この手順によって、共有メモリに含まれるキャッシュメモリの記憶容量要件が、その効率を同程度に高めると共に中央装置の負荷を大幅に軽減することによって実質的に低減される。何故なら、フォーマットと演算が、この例では番号３で示したプロセスによってのみ実行されるためである。

図３は、同じＣＬＥのプロセス間でデータを好都合に共用することができるかどうか示すためのものである。幾つかのＣＬＥが共有メモリ内に共存する場合（３００）、本発明は、また、プロセス（３１０）が必ずしも全てのＣＬＥにアクセスしなくてもよいようにする。従って、この特定の例において、プロセス１は、ＣＬＥ ＡとＣにアクセスし、プロセス２は、ＣＬＥ ＢとＣにアクセスする。従って、ＣＬＥ Ｃ内にあるデータだけがプロセス１と２に共通であり、これは、例えばプロセス２が、プロセス１だけが変更することを許可されたデータ（その後ＣＬＥ Ａに含まれることが好ましいデータ）を変更するのを防ぐのに有効と考えられる。

以下の図は、所定の時間にキャッシュメモリに収容されたデータを見つけて更新するためにＣＬＥによって使用される様々なテーブルを示す。図４は、データテーブルの構成を示す。データテーブル（４００）は、その名前が示す通り、主に、ユーザデータ並びにそれらのユーザデータと関連した固有コード又は識別コード及び以下に示すパラメータを記憶する役割をする。ＣＬＥ内に存在するデータテーブルの最大数は、システムを構成する際に設定することができる。例えば、１００個のデータテーブルの作成を許可することができる。更に、これらのテーブルはそれぞれ、様々な数（この例では４つ）のエントリ（４１０）を含むことができる。これらのテーブル自体は、構成時に指定することができるサイズのものであり、それにより、本発明の特定の用途で収容しなければならないユーザデータにテーブルをよりよく適応させることができる。データテーブルの各エントリの形式は、
−コードのサイズ（４２０）、
−ユーザデータのサイズ（４３０）、
−データを識別する固有コード（４４０）（一般に、このコードは、関連データのタイプを識別するのに十分な情報を含む数十バイトのフィールドである）
−ユーザデータ自体（４５０）（例えば、このユーザデータは、所定の行き先と所定の期間について航空会社から課される価格でよい。）を含む４つのフィールドを含む。

図５は、所定の時間にＣＬＥ内にあるユーザデータを追跡するために使用される制御テーブルを示す。制御テーブル（５００）のエントリとデータテーブル（５１０，５２０）のエントリの間には一対一の対応がある。従って、制御テーブル内のエントリの数は、構成時に指定したデータテーブルの最大数にそれらの各テーブル内のエントリの数を掛けたものと等しい。図５の単純な例では、２つのデータテーブルだけを示しており、第１のデータテーブル（５１０）が４つのエントリを含み、第２のデータテーブル（５２０）は５つのエントリを含み、従って、関連付けられた制御テーブル（５００）は、合計９個のアクティブなエントリを含む。

これらのテーブルのエントリ０は常に未使用であり、従って各フィールド０は、エントリへの参照がないことを示す特定の意味を有することに気付くであろう。

制御テーブル内の各エントリは、
−データと関連付けられたコードのハッシュ値、
−データの挿入日、
−データの有効期限日、
−データテーブルの対応エントリに記憶されたデータのサイズ、
−制御テーブルとデータテーブルのエントリ（空き又は使用済み）の連鎖リスト内の次のエントリ、或いは他の連鎖エントリがない場合は値０、
−前の連鎖エントリ、或いは他の連鎖エントリがない場合は値０、
−図８で説明するハッシュテーブルの対応エントリ、或いは空きエントリの連鎖リストの場合は値０、
−制御テーブルのこのエントリと関連付けられたデータテーブルの数、
−データテーブル内の対応するエントリ、
−利用メータ（エントリのうちのどのエントリが最も最近使用されたかを決定する）、
−特に、対応するエントリが空いており使用できることを示すための２値インジケータを含む様々なパラメータを含む。

図６は、図５のデータテーブル１に対応する制御テーブルの区分（partition）が含むことができるものの例を示す。分かりやすくするために、上記リスト内のパラメータは、必ずしも全て図６のテーブルに示されていない。

この例では、エントリ２と４が空である（６００）。これらのエントリは、リストを両方向に参照できるように二重に連鎖されており、ユーザデータを格納するために使用することができる。従って、空きエントリ２は、次の空きエントリ４を参照する（６１０）。空きエントリ４は、前の空きエントリ２を参照する（６２０）。

使用中のエントリ１と３は、ここでは、異なるコードの同一ハッシングによって生じる衝突を解決するために使用されるのと同じ連鎖リストに属する。これらのエントリは、ハッシュテーブルの特定のエントリ（６３０）、即ちエントリ１２３を参照する。ハッシュテーブルと識別コードのハッシングは以下の図８で詳細に説明される。空きエントリのリストのように、衝突を解決するためのリストも二重連鎖されている。即ち、リストにおいて、エントリ１は、次の使用済みエントリ（６４０）、即ち３を参照し、このエントリ自体は、リストの前のエントリ（６５０）１を参照する。

既に述べた通り、「次のエントリ」と「前のエントリ」の０値は、何もエントリを参照せず、連鎖リストを開始又は終了する。

図７は、区分のテーブル（７００）示す。区分テーブルは、その名前が示す通り、制御テーブルとデータテーブルをどのように組織化し区分するかを決定するのに必要な情報を記憶する働きをする。従って、区分テーブル内には、データテーブルの数と同じ数のエントリ（７１０）があり、即ち前の図に示した例では２つのエントリがある。区分テーブル内の各エントリは、対応するデータテーブルを参照し（第１のエントリはテーブル番号１を参照し、その後も同様に続く）、各エントリは、以下のパラメータを含むが、これらのパラメータは、分かりやすくするために、図７の区分テーブルには全て示されているわけではない。
−制御テーブル内の対応する区分の最初のエントリのインデックス（７２０）、
−最後のエントリのインデックス（７３０）、
−この区分内のエントリの数、
−この区分内のエントリのサイズ
−空きエントリの数
−空きエントリの連鎖リスト内の最初のエントリ（７４０）
−区分ロッキングインジケータ
−取り出される可能性が高いエントリの次の検索が始まる制御テーブル内のインデックス。

図８は、ＣＬＥ内の検索の出発点であるハッシュテーブル（８００）を示す。

ハッシュテーブル内の出発点（８１０）は、データ識別コードをハッシュすることにより得られる値であり、データ識別コードは、データと関連付けられた固有コードであり、前の図に示されている。既に述べた理由のために、エントリ０は、未使用のままでなければならず、ハッシュ関数は、１とハッシュテーブルのアドレシング上限との間の値を返さなければならない。ハッシュテーブルは、システム構成中に設定される。本発明は、特定のハッシュ関数を使用することを仮定しない。任意のハッシュ関数の最終的な目的である、衝突を最小限にするために、恐らくコードの構造に依存するが、この主題に関する豊富な技術文献で提案されている多数のハッシュ関数及び方法のいずれかを選択することができる。しかしながら、ハッシュ関数は、値０が常に除外されるように選択又は適応されなければならない。

図８に示した本発明の好ましい実施形態では、固有識別コード（８４０）は、一般に５０〜１００バイトを必要とし、例えば以下でＨ［ｉｎｔ］と呼ぶ６４ビットのフィールド内の値を得るために第１のハッシュ（８５０）にかけられる。しかしながら、ハッシュテーブルは実際上２^６４個のエントリを含むことができないので、適切なサイズのテーブル（８００）を得るためにＨ［ｉｎｔ］の第２のハッシュ（８６０）が実行される。例えば、６４ビットのフィールドを１８ビットのフィールド、即ち約２５６，０００エントリ（２^１８）に縮小したい場合がある。ダブルハッシュを行う利点は、ハッシュテーブル内で衝突が発生した場合の疑いを取り除くためにプロセッサがすぐに処理することができるビット（６４ビット）のフィールドでの比較を可能にしながら妥当なサイズのハッシュテーブルを得ることができることである。実際に、第１のハッシュ関数を慎重に選択することにより衝突の確率をほとんど０にすることができる。ただし、例えば１８ビットへの更なる縮小後は衝突が更に増える。従って、図９と関連して前に述べたように、５０〜１００バイトからなるコードの全体比較を２回以上実行しなくてもよい。

従って、図６を再び参照すると、中間ハッシュ値Ｈ［ｉｎｔ］（上記の例では６４ビットを含む）が、制御テーブル内にあり（６６０）、主に比較を加速するために使用される。

データＨ［ＣＬＥＦ］と関連付けられたコードの最終ハッシュ値（８１０）が、ハッシュテーブルを調べるために使用される。対応するエントリは、以下の情報を含む。
−１度に１つのプロセスしか連鎖リスト（８２０）を変更できないようにするエントリのロッキングインジケータ（Ｖ）。（ハッシュテーブル内でこのエントリから始まる。）（本発明のこの様相については後で説明する。）
−制御テーブル内にあり、コードハッシュによって生じる可能性のある衝突を解決するために使用される連鎖リストの最初のエントリ（当然ながら、データコードのハッシングが、ハッシュテーブルの特定のエントリと衝突しない場合は、対応する連鎖リストは単一要素に縮小される。）
ハッシュテーブル内の０値（８３０）は、制御テーブル内のどのエントリも参照しない。データコードはどれもこのエントリについてハッシュ値を与えない。

図９は、ＣＬＥ内のデータに対するアクセス方法（９００）を示す。ＣＬＥ内のデータの検索は、求めるデータと関連したコードのハッシング（９１０）で始まる。得られた値は、前述のハッシュテーブルをアドレス指定するために使用される（９２０）。対応するエントリが０の場合は、直ちに検索を失敗と宣言することができる（９３２）。この結果は、問い合わせされたＣＬＥ内にデータがないことを知らせるために、データを探しているプロセスにすぐに示される（９４０）。

アドレス指定したエントリが０でない場合（９３４）は、ハッシュテーブルによって参照されるエントリにおいてＣＬＥの制御テーブルを読み出さなければならない（９５０）。このエントリは、求める情報を含む可能性の高いエントリの連鎖リストの最初の要素（恐らく１個の要素のみ）を含む。

しかしながら、対応するエントリが別のプロセスによってロックされている場合（９４５）は、制御テーブルのこの調査はすぐに行われない。その場合は、その別のプロセスがそのエントリをロック解除するのを待ち続けなければならない。進行中のプロセスが、テーブルの変更（削除又は挿入）を伴う可能性がある場合、ハッシュテーブルのエントリをロックする（９４７）。

ハッシュコード値の最初の比較を実行し（９６０）、即ち求めるコードハッシングの値が、制御テーブルから取り出された値と比較される。図８で述べたように、本発明の好ましい実施形態では、中間ハッシュ値Ｈ［ｉｎｔ］で比較が行われる。

これらの値が異なる場合（９７４）は、連鎖リストを参照して（９８０）連鎖リストが複数の要素を含むかどうかを検索し続けなければならない。要素が１つだけの場合、又はリストの最後の要素に達した場合（９８２）は、検索が失敗したことを宣言しなければならない（９４０）。

しかしながら、ハッシュ値が同一の場合（９７２）は、求めるコードが見つかった可能性がある。しかしながら、たとえハッシュ関数が異なるコードで始まる２つの同じハッシュ値を返すことができた場合でも、そのハッシュ値を検証しなければならない。その場合、疑いをなくすためにコードを比較しなければならない（９９０）。本発明の好ましい実施形態では、比較を加速するために、最初に、求めるコードのサイズが、（制御テーブルのそれに対応するエントリにある）データテーブルに記憶されたコードのサイズと比較される。コードのサイズが異なる場合は、コードは同一であることはなく、複数の要素を含む場合、前と同じように、連鎖リストを参照することによって検索し続けなければならない（９９４）。複数の要素を含まない場合、検索を失敗と宣言しなければならない（９４０）。

コードのサイズが同じ場合は、最終的にこれらのコードの全体比較が実行される。コードが実質上同一の場合（９９２）は、検索は成功である。求めるデータはデータテーブル内にある。コードが異なる場合は、前と同じように連鎖リストを参照することによって検索を続けなければならない。

データが実際に見つかったときは、ほとんどの場合、コード（５０〜１００バイト）を完全に１回比較しなければならないことに注意されたい。コードの完全な比較を複数回行わなければならない確率は、図８に示したような衝突を最小限にするために使用される第１のハッシュ関数の有効性に依存する。既に述べたように、この確率は実際上は０である。

図１０は、ＣＬＥ内のデータ検索後の様々なアクションを示す。

全ての場合において、検索が失敗した場合には、検索を開始したプロセスにそのことが通知される（１０００）。

検索が成功し、その検索がデータを調べるためのプロセスによって開始された場合、データは、データテーブルから取り出され、検索を開始したプロセスに送られる（１０１０）。

検索が成功し、その検索がＣＬＥ内の対応するデータを削除するためのプロセスによって開始された場合（１０２０）は、制御テーブルを変更しなければならない（１０２５）。区分の対応するエントリは、この区分内で使用されているエントリの連鎖リストから取り除かれ、空きエントリのリストに加えられなければならない。図６に示したように、必要に応じて「次」と「前」のエントリフィールドを変更して連鎖リストを再構成することによって、使用されているエントリの連鎖リストからエントリが削除されることは明らかである。

ＣＬＥに新しいデータを挿入するプロセス（１０３０）が、主に、そのＣＬＥ内に既にコードがあるかどうかに依存する場合は、挿入するために、必ず、このデータを挿入するのに必要なサイズを最初に計算して（１０３５）、データテーブルからのどの空きエントリを使用できるかを決定する必要がある。

検索が失敗だった場合は、挿入は、新しいデータを収容するのに適切なサイズの少なくとも１つのフリースペースが残っているかどうかを知ることに依存することになる。適切なサイズのフリースペースが残っている場合（１０４２）は、空きエントリが選択され（１０６０）、新しいデータの挿入が実行され（１０７０）、この新しいデータは、制御テーブル内の連鎖リストの変更と作成を含む。

十分なサイズのフリースペースがない場合（１０４４）は、挿入（１０７０）に進む前にＣＬＥのスペースを開放する必要がある（１０５０）。スペースを開放する方法を図１１により詳しく示す。

検索が成功した場合、求めるコードは既にあり、データテーブルに含まれるデータを変更しなければならない。この場合は、同じエントリに新しいデータを記憶するのに適切なスペースがあるかどうか知る必要がある。十分なスペースがある場合（１０４６）は、すぐに挿入に進むことができる（１０７０）。しかしながら、サイズが適切でない場合（１０４８）は、前と同じように適切なサイズのエントリを開放しなければならない（１０５０）。また、再び使用するのに十分でないと見なされたサイズのエントリも事前に開放されることになる（１０４５）。この段階は、前に述べたＣＬＥからデータを削除する段階と同じである（１０２０）。

最後に、図１０に見ると、テーブルの変更（即ち、削除（１０２５）又は挿入（１０７０））動作を伴う動作が終わったとき、動作が終了したのでハッシュテーブルの対応するエントリをロック解除しなければならないことが分かるであろう。

図１１は、挿入する新しいデータを収容するフリースペースがないときに開放するのに最も適したエントリを探す図１０の段階（１０５０）をより詳細に示す。この方法は、使用される全ての新しいデータを収容するのに十分なサイズの８つのエントリを含む制御テーブル（１１００）の区分の例を使って説明される。分かりやすくするため、挿入メカニズムを理解するのに必要な制御テーブル内のフィールドだけを示す。

この例では、データテーブル番号１（１１１０）とエントリ０〜７（１１２０）を参照する区分は、アドレス１、４及び５で始まる３つの連鎖リスト（１１３０）と、それぞれ３個、３個及び２個のエントリを含む。連鎖の始まり自体は、既に説明したハッシュテーブルによってアドレス指定される。

エントリを開放するために、挿入アルゴリズムは、制御テーブル内にある以下の一組の情報の内の一方又は他方或いはその両方を使用する。
−エントリと関連付けられたデータの有効性が終了する時間（時間／日付）（１１４０）。（この時間を現在時間と比較して、区分の全てのエントリを参照することによって、エントリの一つが既に有効期限切れになっていて削除することができるかを決定しなければならない。実際には、この時間は、図示したように、データの有効時間が終了したときに単純なカウンタが達しなければならない値の形をとる。）
−どのエントリが最も長い時間使用されてなかったかを決定することができるエントリの実際の使用状況（１１５０）（これらの主題に関する英語技術文献では「ＬＲＵ（least recently used）」）。図１１の例では、「使用状況」フィールドの最高値は、最も長い時間使用されなかったエントリを示す（即ち、制御テーブル内のアドレス７のエントリ（１１５５））。従って、置き換えられる可能性が高いのはこのエントリである。
本発明の使用のタイプによって、あるエントリを選択し取り出すための基準は、様々に設定することができる。これらのパラメータの通常の使用は、最初に、データの有効期限が切れたエントリがあるかどうかを決定することにある。この基準を満たす少なくとも１つのエントリがある場合、それは例えば全てのエントリを参照するとき最初に見つかったものであり、そのエントリが選択される（１１６０）。エントリに有効期限の切れたデータがない場合、最も長い時間未使用だったエントリを取り出すことができる（１１５５）。しかしながら、データを早過ぎる時期に削除しないように、この最後のパラメータを考慮するしきい値が設定されてもよい。この場合、エントリを削除する基準が、最初の期間内に満たされないことがあり、その場合は、アルゴリズムが、制限の少ないフォールバック戦略を提供しなければならず、その結果、できるだけ現在時間に近い期限終了時間を持つエントリを選択できるようになる。

本発明が、エントリを開放するためにこれらのパラメータを使用する特定の方法を想定しない場合、キャッシュに新しいデータを収容するためにエントリが常に開放されるという明確な仮定を行なうことを理解するであろう。

図１１の例は、現在時間が値１５を有するので、制御テーブルのエントリ２を削除することができると想定している。何故なら、このエントリのデータは現在時間より先行する時間１２で有効期限が切れているためである（１１４５）。このエントリ２が連鎖リストの一部を構成していたので、リストを変更しなければならず（１１３４）、１つの要素だけを含む新しいエントリが挿入される（１１３２）。従って、区分の新しい状態は、下のテーブル（１１０５）に示した通りである。

この例では、新しいエントリもハッシュテーブル内の新しいエントリに対応しており、従って衝突がないことを暗黙的に仮定している。当然ながら、新しいエントリは、既に使用されているハッシュ値に対応しる可能性があることを理解されるであろう。この場合、当面、１つの要素しか含まない追加リストを構成する代わりに、その新しいエントリを対応する連鎖リストに追加しなければならない。連鎖リストの処理は、当業者に周知の動作であり、従って後で説明しない。

説明の中で既に考察したように、複数のプロセスは、１つのＣＬＥを同時に自由に使用することができる。プロセスが、別のプロセスによって完全に変更されていないデータを使用しないようにするために、次の２つの制限だけが適用される。
−図８に既に示したように、ハッシュテーブルの各エントリは、２つのプロセスがＣＬＥの１つのエントリを同時に変更しようするのを防ぐためのロッキングインジケータを含む。図９の段階（９４５）に詳しく示したように、データテーブルを変更しなければならないプロセスがそのエントリから既に実行されている場合は、アクセスが阻止される。しかしながら、ハッシュテーブル内にある様々なエントリと同じ数の同時アクセスをＣＬＥに対して行うことができる。テーブルの変更を伴う動作のために同じハッシュ値からの複数のアクセスだけが不可能であり、その理由は、そのようなアクセスが、同じ連鎖リストを処理しなければならなくなるからである。
−図７に示した区分テーブルのエントリにはロッキングインジケータもある。このロックの目的は、同じ区分内で行われる独立プロセスが変更したい空きエントリの連鎖リストの更新を保護することである。区分テーブルのエントリは、特にスペースが開放されるとき、即ち図１０に示した段階（１０４５）、（１０５０）又は（１０２５）でロックされ、またハッシュテーブルの条件と同じ条件下でロック解除される。

従って、データテーブルの変更を伴うプロセスによって開始される動作は、常に余すところなく実行され、その後でなければ、変更中に別のプロセスがエントリを再使用することができない。制御テーブルの共通エントリを処理しなければならないプロセスは互いに、プロセスの実行中にプロセス自体を排除する。

図１１に示したように、挿入アルゴリズムは、満杯の制御テーブル内のエントリを開放しなければならない場合があることを想定しており、最も適切なエントリを選択するためにこのテーブルを参照（１１６０）しなければならないことに留意すべきである。プロセスがあまり長い時間エントリをロックするのを防ぐために、本発明では、例えば制御テーブルの連続読み出しの最大回数を指定することによって、この参照を制限することができる。このため、図７に示した区分テーブルは、このメカニズムが実行される度にエントリの検索を再開しなければならないポイントを指定するパラメータを含む。これは、制御テーブルがいつも同じポイント（例えば、第１のエントリ）から参照されるのを防ぐためである。最後に、これにより、全てのエントリを参照することができ、それぞれの置き換えが可能になる。

制御テーブルを参照することによってエントリの開放を要求するプロセスに関する限り、持続時間が有限、即ち制限されているので、永久的なロッキングが行われることはない。

図１２は、プロセスの実行中にＣＬＥを制御するテーブルを通常変更しなければならないプロセス（１２００）の事例を説明する。

これは、主に、連鎖リストの作成又は変更を必要とする新しいデータの挿入（図１０に示した動作）の事例である。

ＣＬＥのテーブルを変更する必要がありまだ完了していないプロセスが、テーブルを一貫性のない状態にしてはならない。そのような状態は、連鎖リストを乱すことによって作られ、その連鎖リストは正常に参照することができなくなり、データテーブルの関連エントリをロックする。本発明では、潜在的に危険なプロセスは、それらが実行される前にテーブルの内容を保存し（１２１０）、即ちそのようなプロセスが、完全に実行されなかった場合又は実行中に異常が検出された場合にテーブルの以前の状態を回復できるのに必要な全ての情報を記憶しなければならない。

各プロセスは、固有識別子（ＩＤ）を有し、この情報を実行中ずっと記憶する専用の作業記憶域を使用する。例えば、ロックがハッシュテーブル内に作成される場合、プロセスの識別子は、対応するハッシュテーブルのエントリの参照と共に登録される。同様に、プロセスによって変更される連鎖リストのリンクも登録される。プロセスに問題が生じた場合（１２３２）は、そのプロセスと関連した関数が、以前の状態を回復するために呼び出される（１２４０）。上記の例では、ハッシュテーブルのロックが開放され、連鎖リストのリンクが復元される。プロセスの実行（１２２０）中に、各プロセスは、特にキャッシュメモリの効率を測定するために使用される統計だけでなく、プロセスが正常に完了したかどうかを判定する（１２３４）ために使用される完了状態も確立する（１２３０）。

テーブルの内容の保存と復元並びにプロセスの完了状態の確立は、本発明に固有のメカニズムを必要としない。そのようなメカニズムを実施するためのソフトウェア工学専門家によく知られている全ての方法は、使用される可能性が高く、従って更に詳しく説明しない。

本発明が実施される環境を示す図である。 独立プロセスによるＣＬＥ（キャッシュロジックエンティティ）の共用を示す図である。 幾つかのＣＬＥが独立プロセスによってアクセスされる場合を示す図である。 ＣＬＥのデータテーブルの構造を示す図である。 データテーブルと関連付けられた制御テーブルを示す図である。 制御テーブルのある区分の内容の例を示す図である。 区分のテーブルの構造を示す図である。 ハッシュテーブルの構造とアドレシングを示す図である。 ＣＬＥ内のデータを検索する方法を示す図である。 ＣＬＥ内のデータを使用可能にし、削除し、交換し、挿入する方法を示す図である。 満杯のデータテーブル内のエントリを開放する方法を示す図である。 テーブルの一貫性を維持する役割をするプロセスを実行する段階を示す図である。

符号の説明

１５ キャッシュメモリ
１１０ 中央処理装置
１３０ マスメモリ

Claims (8)

1. 共通データ（２１０）を共用する複数の独立プロセス（２００）によってアクセス可能な少なくとも１つのキャッシュメモリ（１５０）の一貫性を維持する方法であって、
   前記キャッシュメモリはエントリを含む複数の区分を有する制御テーブルを備え、それらエントリには異なるサイズを有するエントリが含まれており、前記複数のプロセスは区分中のデータについて同時に検索動作（９００）を実行し、前記方法は区分の１つへの新しいデータの挿入動作（１０３０）を更に含み、
   その挿入動作は、エントリを開放する段階であって、最大参照時間を定義する段階と、新しいデータのサイズを決定する段階と、区分のエントリを参照する段階と、最大参照時間に達したときにエントリの参照を中断する段階と、参照したエントリの中から新しいデータを収容するのに十分なサイズを有する最も適切なエントリを選択する段階と、最も適切なエントリを開放する段階とを含んでいる段階と、
   最も適切なエントリに新しいデータを挿入し、それにより挿入動作は実行持続時間が制限される段階とを含む、方法。
2. 前記の参照したエントリの中から最も適切なエントリを選択する段階は、新しいデータを収容するのに十分なサイズの参照したエントリの最後のエントリを無条件に選択する段階を含む、請求項１に記載の方法。
3. 最後に参照したエントリのアドレスを記憶し（７００）、区分中の更に新しいデータの新しい挿入動作を動作させる段階を更に含み、
   その挿入動作は、エントリを開放する段階であって、最大参照時間を定義する段階と、最後に参照したエントリの次に位置するエントリから開始して区分のエントリを参照する段階と、最大参照時間に達したときにエントリの参照を中断する段階と、参照したエントリの中から最も適切なエントリを選択する段階と、最も適切なエントリを開放する段階とを含んでいる段階と、
   最も適切なエントリに更に新しいデータを挿入する段階とを含む、請求項１に記載の方法。
4. 前記の参照したエントリの中から最も適切なエントリを選択する段階は、最近最も使用されていなかったエントリを選択する段階を含む、請求項１に記載の方法。
5. 前記の参照したエントリの中から最も適切なエントリを選択する段階は、有効期限が切れたエントリを選択する段階を含む、請求項１に記載の方法。
6. 前記の最大参照時間を定義する段階は、エントリの連続読み出しの最大回数を指定する段階を含む、請求項１に記載の方法。
7. マスメモリ（１３０）に記憶されたデータを処理する複数の中央処理装置（１１０）を使用可能にするために使用されるシステム、特にキャッシュメモリ（１５０）であって、請求項１から６のいずれか１項に記載の方法を実施するように適応された手段を含む、システム。
8. 請求項１から６のいずれか１項に記載の方法を実施する、前記コンピュータによって実行可能なプログラムの命令を含む、コンピュータが読み出すことができる媒体。

Images