JP2004213628A - リソース・コンテンションを管理するための方法および装置 - Google Patents

Abstract

【課題】 マルチシステム・クラスタ内の複数リソースへのアクセスに関するユーザ間のコンテンションを管理するための方法および装置を提供すること。
【解決手段】 その管理は、各ユーザがチェーン内でそれより前のユーザ（複数も可）によって保持されているリソースを待っているコンテンション・チェーンを識別し、その必要性が少なくともそのチェーン内の最も困窮しているウェイタの必要性である場合と同様にそのチェーンの先頭にあるユーザ（複数も可）にシステム・リソースを割り振ることによって実施される。システム間のデータ・フローが最小限であり、いかなるシステムもクロスシステム・コンテンションに関する完全なビューを持たない場合でも、最適リソース割振りに必要なコンテンション・データはシステム・クラスタ全域に効果的に分散される。
【選択図】 図１

Description

本発明は、情報処理システム内の直列化リソースへのアクセスに関するユーザ間のコンテンションを管理するための方法および装置に関する。

リソース・コンテンションは、情報処理システムにおいて周知の現象である。これは、あるユーザ（たとえば、プロセスまたは他の作業単位）が他のユーザによってすでに保持されているリソースにアクセスしようと試み、第２のユーザによって要求されたアクセスが第１のユーザのアクセスと矛盾するときに発生する。これは、たとえば、いずれか一方のユーザが当該リソースに対する排他的アクセスを要求している場合に発生することになる。リソース・マネージャは、それらが制御するリソースに対するアクセスをホルダとして１人または複数のユーザに認可し、そのリソースが使用可能になるまで残りのユーザをウェイタのプールに入れることにより、そのリソースに関する競合リクエスタ間のコンテンションを管理するソフトウェア・コンポーネントである。

複数のリソース・マネージャと複数の作業単位を備えたＩＢＭのｚ／ＯＳ（商標）オペレーティング・システムなどのコンピュータ・オペレーティング・システムでは、リソース・コンテンション管理は複雑な問題である。コンテンション・チェーンが発生する可能性があり、言い換えれば、コンテンションは複数リソースにまたがる可能性がある。たとえば、ジョブＡはリソースＲ１を待っているがＲ２を保持しており、ジョブＢはＲ１を保持しているがＲ３を待っており、Ｒ３はジョブＣによって保持されている。コンテンションは複数システムにまたがる可能性もある。上記の例では、各ジョブは別々のシステム上にある可能性がある。コンテンションは複数のリソース・マネージャにまたがる可能性もある。たとえば、Ｒ１はＧＲＳエンキューである可能性があり、Ｒ２はＤＢ２（商標）ラッチである可能性がある。ｚ／ＯＳのグローバル・リソースの逐次化（ＧＲＳ）はエンキューを管理し、ＩＭＳ（商標）のリソース・ロック・マネージャ（ＩＲＬＭ）はＤＢ２のリソースを別々に管理する。

クロスリソース・コンテンションは通常、各リソースのホルダおよびウェイタのトポロジを追跡し、交点を見つけることによって、単一リソース・マネージャ（たとえば、ＧＲＳ）内で解決される。クロスシステム・コンテンションは通常、クラスタ全体のデータについてリソース・マネージャに気付かせる（独立システムとしてではなく、１つのユニットとしてクラスタを管理する）ことによって解決される。クロスリソース・マネージャ・コンテンションは通常、報告製品にすべてのインタフェースに照会させ、それが仮想リソース・マネージャである場合と同様にそのデータを相関させることによって「解決」される。問題はコンテンション中のリソースの数のオーダＯ（２ⁿ）になるので、計算上も複雑なものになる。

ｚ／ＯＳの基本ＭＶＳ（商標）コンポーネントは単純な効率の解決策（一般に「エンキュー・プロモーション」として知られている）を有しており、報告によるとコンテンション中のリソースを保持しているいずれかの作業のＣＰＵおよびＭＰＬアクセスを自動的（かつ一時的）にブーストし、その作業の困窮度に対してはまったく留意しない。これは、実際のトポロジにかかわらず、あるリソースについて「重要な」ウェイタ（複数も可）が存在する場合と同様にホルダを管理することと同等である。この動作を理解するために、以下の例を検討する。以下のように想定する。
１．ジョブＡはリソースＲ１を保持している。
２．ジョブＢはリソースＲ２を保持し、Ｒ１を待っている。
３．ジョブＣはＲ２を待っている。

表記上、これはＣ→Ｂ→Ａというチェーンとして表すことができ、大文字はジョブを表し、記号「→」（チェーン内の「リンク」）は記号の左側のジョブが記号の右側のジョブによって保持されているリソースを待っていることを示している。したがって、上記のチェーンは、ジョブＣがジョブＢによって保持されているリソースを待っており、ジョブＢはジョブＡによって保持されているリソースを待っていることを意味する。
ＩＢＭの資料「z/OS MVS Planning: Global Resource Serialization」ＳＡ２２−７６００−０２（２００２年３月） ＩＢＭの資料「z/OSMVS Planning: Workload Management」ＳＡ２２−７６０２−０４（２００２年１０月） ＩＢＭの資料「z/OSMVS Programming: Workload Management Services」ＳＡ２２−７６１９−０３（２００２年１０月） ＩＢＭの資料「z/OSMVS Initialization and Tuning Guide」ＳＡ２２−７５９１−０１（２００２年３月）の特に第３章（３−１〜３−８４ページ）

これらがＧＲＳリソースであると想定すると、従来のＭＶＳインプリメンテーションは、ジョブＡとジョブＢがコンテンション中のリソースを保持し、それぞれを限られた時間の間、均等にプロモートするので、これらのジョブを援助することになるだろう。しかし、Ｂは実際はＡを待っているので、Ｂを援助しても何も役に立たないだろう。Ｂ自体がマルチタスク式である場合、この援助は、リソース・コンテンションに関することは何も行わずに、実際には競合作業を害する可能性がある。

本発明の一態様は、本出願の主題であり、情報処理システム内のリソースへのアクセスに関するユーザ間のコンテンションを管理するための方法および装置を具備し、そのシステムでは各ユーザは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性がある。本発明のこの態様によれば、ユーザ・チェーン内の次のユーザを有する各ユーザが当該次のユーザが待っているリソースを保持しているユーザ・チェーンの先頭にあるウェイタではないユーザが識別される。チェーンの先頭にあるそのユーザは、その必要性が少なくともそのチェーン内の最も困窮しているウェイタの必要性である場合と同様に管理され、好ましくは、その必要性が少なくともこのような最も困窮しているウェイタの必要性である場合と同様にそのユーザにシステム・リソースを割り振ることにより管理される。

好ましくは、本発明のこの態様の独立した発明上の特徴として、クラスタ内の各リソースがそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれているリソースのクラスタを識別し、そのクラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性を決定することにより、このようなコンテンション・チェーンが識別される。そのクラスタ内のあるリソースのホルダであるが、他のいずれのリソースも待っていないユーザが識別され、そのリソースのそのホルダは、その必要性が少なくともそのクラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性である場合と同様に管理され、この場合も好ましくは、その必要性が少なくともこのような最も困窮しているウェイタの必要性である場合と同様にそのユーザにシステム・リソースを割り振ることにより管理される。

クラスタを識別するステップは好ましくは、あるリソースのコンテンション状況の変化の通知を受信したことに応答して実行される。したがって、あるリソースがその時点であるクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている場合に、そのリソースがそのクラスタに新たに割り当てられる。これに対して、あるリソースがもはやあるクラスタ内の他のリソースを待っているユーザによって保持されていないかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれていない場合に、そのリソースがそのクラスタから除去される。

したがって、本発明のこの態様では、あるチェーンの先頭にあるジョブ（たとえば、困窮度係数が４である上記のジョブＡ）が、それがそのリソースをリリースするまで、そのチェーン上の他の場所にあるより困窮しているジョブ（たとえば、必要性が１である上記のジョブＣ）の困窮度係数を有している場合と同様に実行できるように、ベース・システム・リソース割振りメカニズムに「困窮度」係数を統合することを企図している。前の例に困窮度の概念を統合すると、それがどのように異なる挙動をするかをさらに理解することができる。以下のように想定する。
１．「必要性」が４であるジョブＡはリソースＲ１を保持している。（本明細書では、より小さい数字はより高い必要性を意味し、したがって、それらは「援助の優先順位」と見なすことができる。）
２．必要性が５であるジョブＢはリソースＲ２を保持し、Ｒ１を待っている。
３．必要性が１であるジョブＣはＲ２を待っている。

表記上、これはＣ（１）→Ｂ（５）→Ａ（４）というチェーンとして表すことができ、大文字はジョブを表し、括弧内の数字はこれらのジョブの「必要性」を表し、記号「→」（チェーン内の「リンク」）は記号の左側のジョブが記号の右側のジョブによって保持されているリソースを待っていることを示している。したがって、上記のチェーンは、必要性が１であるジョブＣが、必要性が５であるジョブＢによって保持されているリソースを待っており、ジョブＢは必要性が４であるジョブＡによって保持されているリソースを待っていることを意味する。

このように「困窮度」係数を使用すると、いくつかの利点が付与されるが、その利点は明白ではない可能性がある。第１に、Ｂが他のリソースも待っていることが分かっているので、上記のＢのような作業を援助するのを回避し、その結果、良くても無益で、最悪の場合は無関係の競合作業に損害を与えるようなアクションを回避する。第２に、本来行われる以上に、しかも限られた時間の間ではなく無期限にＡを援助できるようにするための知識をシステム・リソース・アロケータに与える。従来のインプリメンテーションではチェーンを無視し、ある程度の限られた期間の間、ＡとＢの両方を「重要」なものとして扱うが、本発明では、Ｃが待っている限り、Ａは実際には１または「最も重要」という必要性を有することが分かっている。第３に、それが希望する場合、たとえば、ネットワーク内で最も困窮している作業が現行ホルダである場合に、チェーンの先頭にあるホルダ（複数も可）を援助するのを控えることができるようにするための知識をシステム・リソース・アロケータに与える。

本発明のこの第１の態様は、単一システム上または複数のこのようなシステムを含むシステム・クラスタ内で実施することができる。リソース・クラスタを識別する本発明のこの変形は、後述するようにローカル・コンテンション・データのサブセットのみの交換を必要とするので、マルチシステム・インプリメンテーションでの使用に特に適している。

本発明の他の態様は、上記の同時提出出願の主題であり、コンテンション中のマルチシステム・リソースの数のオーダＯ（ｎ）の非常にわずかなデータを次々に回しながら、複数システム間のリソース割振りを管理するためのプロトコルを企図している。

本発明の当該他の態様は、上記の単一システム発明の諸態様を組み込むものであり、複数のシステムを含むシステム・クラスタ内のリソースへのアクセスに関するユーザ間のコンテンションを管理するための方法および装置を企図し、各ユーザは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになることができる。本発明のこの態様によれば、このような各システムはローカル・システムとして動作し、ローカル・システム上のコンテンションを基礎としてローカル・クラスタ単位のリソースのグループ化を示し、各ローカル・クラスタ内の１つまたは複数のリソースに関する必要性をローカル・クラスタごとに示すローカル・クラスタ・データを記憶する。また、各システムは、リモート・システムとして動作するシステム・クラスタ内の他のシステムから、リモート・システム上のコンテンションを基礎としてリモート・クラスタ単位のリソースのグループ化をこのようなリモート・システムごとに示し、各リモート・クラスタ内の１つまたは複数のリソースに関する必要性をリモート・クラスタごとに示すリモート・クラスタ・データを受信する。各ローカル・システムは、ローカル・クラスタ・データとリモート・クラスタ・データとを組み合わせて、システム間のコンテンションを基礎として複合クラスタ単位のリソースのグループ化を示し、各複合クラスタ内の１つまたは複数のリソースに関する必要性を複合クラスタごとに示す複合クラスタ・データを生成する。その後、各ローカル・システムはこの複合クラスタ・データを使用して、複合クラスタ内のリソースのローカル・システム上でのホルダを管理する。

好ましくは、ローカル、リモート、および複合クラスタ・データは当該クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性を示し、複合クラスタ内のリソースのローカル・システム上でのホルダは、他のリソースを待っていないようなホルダを識別し、その必要性が少なくとも対応する複合クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性である場合と同様にシステム・リソースをこのようなホルダに割り振ることによって管理される。

好ましくは、各ローカル・システムは、そのローカル・システム上のあるユーザが他のリソースを待ちながらリソースの１つを保持している場合に１対のリソースを共通ローカル・クラスタに割り当て、そのローカル・システム上のあるユーザに関してあるリソースのコンテンション状況の変化の通知を受信したことに応答してローカル・クラスタ・データを更新する。また、各ローカル・システムは更新を含むそのローカル・クラスタ・データをリモート・システムに送信し、リモート・システムは送信したクラスタ・データを受信側システムに対するリモート・クラスタ・データとして扱い、それに応じてその複合クラスタ・データを更新する。送信したローカル・クラスタ・データは、リソースと、そのローカル・システム上のコンテンションを基礎としてそのリソースが割り当てられるクラスタと、そのリソースに関するローカル・システム上での必要性とを示す。

クラスタ内の各参加リソース・マネージャ・インスタンスからの部分データ（完全リソース・トポロジではない）と、一定の「困窮度」を使用すると、各システムは、あるリソースについて最も困窮しているウェイタ（クロス「上記全部」リソースの推移閉包内のいずれかのウェイタを含む）がチェーンの先頭にあるそのリソースのホルダより困窮しているかどうかを個別に理解することが可能である。その場合、このシステムは、その一定の困窮度が最も困窮している作業ブロック片ほど困窮していない場合と同様に、このようなホルダ（複数も可）にリソースを割り振ることができる。

このプロトコルは、各システムからのホルダとウェイタの全リストの代わりに、リソース当たり１組の情報のみを次々に回すので、いずれのシステムもクラスタ間のコンテンションに関する完全なビューを持たない。データ自体は、クラスタ固有リソース名と、送信側システム上の最も困窮しているウェイタの困窮度値と、送信側システム固有トークンのみからなる。２つのリソースについて後者のトークンが一致する場合、それらの管理を統合しなければならない（トークンは、送信側システムのローカル・データのみに基づいて割り当てられる）。また、このプロトコルは、トポロジ内の作業片の一部がコンテンション中ではない他のリソースを保持している場合でも、コンテンション中のリソースに関するデータのみを送信する。送信側システム・クラスタ情報は様々な方法でエンコードすることができる。したがって、送信側システム上のローカル・コンテンションのみに基づくトークンを送信するのではなく、ローカル・システムは、好ましい実施形態のように、非トリビアル・クラスタ割当て（すなわち、複数のリソースを含むクラスタへの割当て）がローカルまたはリモート情報に基づくものであるかどうかの表示とともに、リモート・コンテンションにも基づくクラスタ名を送信することができる。

本発明は好ましくは、コンピュータ・オペレーティング・システムの一部として、またはこのようなオペレーティング・システムとともに機能する「ミドルウェア」ソフトウェアとして実現される。このようなソフトウェア・インプリメンテーションは、本発明の方法ステップを実行するためにハードウェア・マシンによって実行可能な複数命令のプログラムの形の論理を含む。この複数命令のプログラムは、半導体、磁気、光学、またはその他の記憶技術を使用して１つまたは複数のボリュームを具備するプログラム記憶装置上で実施することができる。

図１は、本発明を組み込んだコンピュータ・システム・クラスタ１００を示している。クラスタ１００は、任意の適当なタイプの相互接続部１０４によってひとまとめに結合された個別システム１０２（Ｓｙ１、Ｓｙ２、Ｓｙ３）を含む。例示的な３つのシステムが示されているが、本発明は特定の数のシステムに限定されない。クラスタ１００は、様々なシステムからのリクエスタによって競合する１つまたは複数のグローバルまたはマルチシステム・リソース１０６を有する。

クラスタの各システム１０２は、単独の物理的マシンまたは１つまたは複数の物理的マシンの単独の論理区画を具備する可能性がある。各システムは、本発明の諸機能を実行することに加え、システム・サービスを提供し、システム・リソースの使用を管理するという通常の機能を実行するオペレーティング・システム（ＯＳ）１０８を含む。本発明は特定のハードウェアまたはソフトウェア・プラットフォームに限定されないが、好ましくは各システム１０２は、ＩＢＭのｚＳｅｒｉｅｓ（商標）サーバまたはこのようなサーバの論理区画で動作するＩＢＭのｚ／ＯＳオペレーティング・システムのインスタンスを具備する。

各システム１０２は、マルチシステム・リソース１０６と、任意選択で同じシステム上のリクエスタのみに使用可能なローカル・リソース１１２へのアクセスについて相互間で競合する１つまたは複数のリクエスタ１１０を含む。リクエスタ１１０は、リソース１０６または１１２へのアクセスについて競合し、システム・リソースを割り振る目的で単一エンティティとして扱われる任意のエンティティを具備することができる。

（リクエスタ１１０に割り振られるシステム・リソースは、リクエスタ間のコンテンションの対象になるリソース１０６および１１２と区別しなければならない。システム・リソースは、スループットまたは応答時間などのパフォーマンス尺度を改善するために通常はリクエスタ自体にとって透過になるように、リクエスタ１１０に割り振られる。これに対して、リソース１０６および１１０は、その実行の一部としてリクエスタによって明示的に要求される。それらを区別することが必要である場合、後者のクラスのリソースは、「直列化リソース」などの用語を使用して言及されることがある。）

各オペレーティング・システム１０８は、１つまたは複数のリソース・マネージャ１１４およびワークロード・マネージャ（ＷＬＭ）１１６を含む、本発明にとって関心のあるいくつかのコンポーネントを含む。

各リソース・マネージャ１１４は、それが制御するリソース１０６または１１２に対する１つまたは複数のリクエスタによるアクセスをホルダとして認可し、そのリソースが使用可能になるまで残りのリクエスタをウェイタのプールに入れることにより、そのリソースについて競合リクエスタ１１０間のコンテンションを管理する。本発明は特定のリソース・マネージャに限定されないが、このようなリソース・マネージャの１つ（マルチシステム・リソース１０６に使用）は、参照により本明細書に組み込まれるＩＢＭの資料「z/OS MVS Planning: Global Resource Serialization」ＳＡ２２−７６００−０２（２００２年３月）などの解説書に記載されているｚ／ＯＳオペレーティング・システムのグローバル・リソースの逐次化（ＧＲＳ）コンポーネントにすることができる。さらに、リソース・マネージャ１１４はオペレーティング・システム１０８の一部として示されているが（ＧＲＳはｚ／ＯＳの一部であるため）、他のリソース・マネージャ（ＩＲＬＭなど）がオペレーティング・システムとは無関係に存在する可能性もある。

ワークロード・マネージャ（ＷＬＭ）１１６は、作業単位（アドレス・スペース、エンクレーブなどである可能性がある）（またはそれが属すサービス・クラス）に割り当てられた「必要性」値を基礎としてその作業単位にシステム・リソースを割り振り、何らかの意味で処理中の他の作業単位に対するその作業単位の相対優先順位を反映する。本発明は特定のワークロード・マネージャに限定されないが、このようなワークロード・マネージャの１つは、ともに参照により本明細書に組み込まれるＩＢＭの資料「z/OS MVS Planning: Workload Management」ＳＡ２２−７６０２−０４（２００２年１０月）および「z/OS MVS Programming: Workload Management Services」ＳＡ２２−７６１９−０３（２００２年１０月）などの解説書に記載されているＩＢＭのｚ／ＯＳオペレーティング・システムのワークロード管理コンポーネントである。このようなワークロード管理コンポーネントは、参照により本明細書に組み込まれるＩＢＭの資料「z/OS MVS Initialization and Tuning Guide」ＳＡ２２−７５９１−０１（２００２年３月）の特に第３章（３−１〜３−８４ページ）などの解説書に記載されているＩＢＭのｚ／ＯＳオペレーティング・システムのシステム・リソース・マネージャ（ＳＲＭ）コンポーネントとともに機能する。これらのコンポーネントが相互作用する特定の方法は本発明の一部ではないので、どちらのコンポーネントも図１に「ＷＬＭ」と示されたボックス１１６で参照するものと想定する。

必要性値がユーザに割り当てられる特定の方法および割り当てられた必要性値を基礎としてシステム・リソースがユーザに割り振られる方法のいずれも本発明の一部ではない。どちらについても、当技術分野で周知のいくつかの技法のいずれでも使用することができる。好ましくは、必要性値は、システム・クラスタの全域で同様の意味を有するものでなければならない。図示の実施形態では、リソース・グループ限界と重要性をシステム全域で安全に比較できる単一数量に統合するのは、アクティブＷＬＭポリシーに基づく計算動的値である。順序付けは任意であるが、この説明では、数字が小さい方が高い必要性または優先順位を表しており、したがって、必要性が１であるユーザは必要性が５であるユーザより「より困窮している」。

図２〜５は、システム・クラスタ１００内のリソース１０６および１１２間で発生する可能性のある様々なコンテンション・チェーンを示している。これらのチェーンはより形式的には有向グラフとして知られているが、本明細書ではチェーンという用語を使用する。これらのチェーン内の各リンクは矢印で示され、あるユーザ（矢印の後部にあるノードによって表される）が他のユーザ（矢印の先頭にあるノードによって表される）によって保持されているリソースを待っている関係を表している。このような関係の「推移閉包」は、矢印をたどった場合にすべてのノードが結局、コンテンション中のリソースを待っておらず、したがって、チェーンの先頭に位置するホルダを指し示すように、チェーンのノードを伴うこのような関係をすべて含むことによって形成されるチェーンである。（１つのチェーンが複数の先頭を持ちうるかどうかは、図５の説明で後述する。）

図２は、上記の背景技術および発明の開示の部分で説明したコンテンション・シナリオを示しており、ユーザＣはユーザＢによって保持されているリソースＲ２を待っており、ユーザＢはユーザＡによって保持されているリソースＲ１を待っている。本明細書で開示するように、ホルダであるがウェイタではなく、したがって、チェーンの先頭にあるユーザＡは、その必要性が少なくともウェイタＢおよびＣのうち最も困窮しているウェイタの必要性である場合と同様にシステム・リソースが割り振られる。というのは、どちらのウェイタもＡをリソースＲ１で終わらせることによって利益を得るからである。ユーザＢもホルダであるが、この優先割振りは与えられない。というのは、そのユーザはリソースを待っており、したがって、動作しておらず、その結果、（ＢがホルダとしてリソースＲ１を取得したときに後で意味があるかもしれないが）この時点ではより多くのリソースをＢに割り振っても意味がないと思われるからである。

図２に示すコンテンション・シナリオは直線チェーンであり、各ユーザは単一ユーザによって保持されているリソースを保持しているかまたは待っているかあるいはその両方である。しかし、一般に、コンテンション・チェーンは分岐することができ、したがって、単一ユーザが複数のユーザによって待たれているリソースを保持しているかまたは複数のユーザによって保持されているリソースを待っている可能性がある。共用アクセスのためにいくつかのリソースを要求し、複数の同時ホルダを可能にすることもできる。

図３は、第１のタイプの分岐を伴うコンテンション・シナリオを示しており、追加ユーザＤがユーザＢによって保持されているリソースＲ３を待っている点で図２に示すシナリオとは異なっている。この場合、ユーザＡは、その必要性が少なくともウェイタＢ、Ｃ、Ｄのうち最も困窮しているウェイタの必要性である場合と同様にシステム・リソースが割り振られる。というのは、これらのウェイタのいずれもＡをリソースＲ１で終わらせることによって利益を得るからである。

図４は、両方のタイプの分岐を伴うコンテンション・シナリオを示しており、ユーザＣがユーザＤによって制御されている追加リソースＲ３を待っており、ユーザＤがユーザＡによって制御されているリソースＲ４を待っている点で図２に示すシナリオとは異なっている。この場合も、ユーザＡは、その必要性が少なくともウェイタＢ、Ｃ、Ｄのうち最も困窮しているウェイタの必要性である場合と同様にシステム・リソースが割り振られる。というのは、これらのウェイタのいずれもＡをリソースＲ１で終わらせることによって利益を得るからである。

最後に、図５は、第２のタイプの分岐を伴うコンテンション・シナリオを示しており、ユーザＣがユーザＤによって保持されているリソースＲ３も待っており、ユーザＤがユーザＥによって保持されているリソースＲ４を待っている点で図２に示すチェーンとは異なっている。理論的には、これは、それぞれが先頭を１つずつ有し、一方のチェーンがＣ→Ｂ→Ａになり、もう一方のチェーンがＣ→Ｄ→Ｅになる２つの部分オーバラップ・チェーンとして分析することができる。第１のチェーンのユーザＡは、その必要性が少なくともウェイタＢおよびＣのうち最も困窮しているウェイタの必要性である場合と同様にシステム・リソースが割り振られ、第２のチェーンのユーザＥは、その必要性が少なくともウェイタＣおよびＤのうち最も困窮しているウェイタの必要性である場合と同様にシステム・リソースが割り振られる。

これを要約し、図６を参照すると、理想的なインプリメンテーションでは、まず、チェーン内の次のユーザを有する各ユーザが、当該次のユーザが待っているリソースを保持しているユーザ・チェーンの先頭にあるウェイタではないユーザを識別することになるだろう（ステップ３０２）。図５ではこれは、ユーザＡ〜ＣからなるチェーンのユーザＡと、ユーザＣ〜ＥからなるチェーンのユーザＥになるだろう。次に、その必要性が少なくともそのチェーン内の最も困窮しているウェイタの必要性である場合と同様に、チェーンの先頭にあるユーザにシステム・リソースを割り振ることになるだろう（ステップ３０４）。すなわち、チェーンの先頭にあるユーザの必要性より大きい必要性を備えたこのような最も困窮しているウェイタが存在する場合、その必要性がそのユーザの必要性より大きければ、このようなウェイタの必要性を基礎としてそのユーザにシステム・リソースが割り振られることになるだろう。

２つのチェーンとしてのこの取扱いでは、ユーザＤの分岐（矢印の方向に移行する）がユーザＡへの供給を行わないので、ユーザＡのリソース割振りはユーザＤの必要性に依存せず、したがって、ユーザＤはユーザＡを優先することによって利益を得そうもないだろう。また、同様の理由で、ユーザＥのリソース割振りはユーザＢの必要性に依存しない。したがって、好ましい実施形態では、これらのチェーン（またはむしろこれらのチェーン内のリンクを構成するリソース）は２つの単独リソース・クラスタとして分析され、第１のクラスタはリソースＲ１〜Ｒ２を含み、第２のクラスタはリソースＲ３〜Ｒ４を含む。第１のクラスタのユーザＡは、その第１のクラスタ内のリソース（Ｒ１およびＲ２）のいずれかについて、その必要性が少なくともそのウェイタ（ＢおよびＣ）のうち最も困窮しているウェイタの必要性である場合と同様にシステム・リソースが割り振られる。同様に、第２のクラスタのユーザＥは、その第２のクラスタ内のリソース（Ｒ３およびＲ４）のいずれかについて、その必要性が少なくともそのウェイタ（ＣおよびＤ）のうち最も困窮しているウェイタの必要性である場合と同様にシステム・リソースが割り振られる。

上記の例のいずれでも、コンテンション・チェーンは非周期性であり、その矢印の方向に沿ってリンクをたどっても閉鎖パスを形成することができないことを意味する。このような閉鎖パスが存在する場合、リソース・デッドロックが存在するものと思われ、そのデッドロックは、デッドロック内に含まれるユーザのうちの１人または複数を終了することによってのみ打破することができるだろう。

次にマルチシステム・インプリメンテーションの詳細に目を向けると、図７は、いくつかのシステム上のトランザクションおよびリソース間の典型的なコンテンション・シナリオを示している。同図では、システムＳｙ１上のトランザクションＴｘＡ（必要性が１）がシステムＳｙ２上のトランザクションＴｘＢ（必要性が２）とＴｘＤ（必要性が４）によって保持されているリソースＲａを待っている。システムＳｙ２上のトランザクションＴｘＢは、システムＳｙ３上のトランザクションＴｘＥ（必要性が５）のように、システムＳｙ３上のトランザクションＴｘＣ（必要性が３）によって保持されているリソースＲｂを待っている。

この例では、システムＳｙ１〜Ｓｙ３がどのようにコンテンションを管理するかを示すものとしてシステムＳｙ２を見ることになる。本発明の一態様によれば、システムＳｙ２は、クラスタ内のコンテンションを示す完全なグローバル・ピクチャを記憶または維持するわけではなく、むしろ以下の表に示すようなコンテンション情報のサブセットを記憶または維持する。

上記の表に示すように、システムＳｙ２は、ホルダまたはウェイタのいずれかとしてリソースについて競合しているそのローカル・トランザクションＴｘＢおよびＴｘＤに関する完全な１組のコンテンション・データ（「ローカル・システム情報」）を記憶する。ローカル・トランザクションがコンテンション中であるこのような各リソースごとに、Ｓｙ２は、その真性「必要性」値を含むローカル・ホルダおよびウェイタを追跡する。また、システムＳｙ２は共通クラスタＣａｂにリソースＲａおよびＲｂを割り当てている。というのは、少なくとも１つのローカル・トランザクション（ＴｘＢ）が、一方の要求リソース（Ｒａ）のホルダのみならず、もう一方の要求リソース（Ｒｂ）のウェイタでもあるからである。

上記の表に示したデータまたは本来は（それをそのように記憶するかまたは必要に応じて他のデータからそれを導出することにより）ＷＬＭのローカル・インスタンスが追跡するデータは、ローカル・クラスタ・データと、リモート・クラスタ・データと、複合クラスタ・データとを含む。ローカル・クラスタ・データは、ローカル・システム上でのコンテンションを基礎としてローカル・クラスタ単位のリソースのグループ化と、このようなローカル・クラスタごとに、ローカル・クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性とを示す。同様に、リモート・クラスタ・データは、特定のリモート・システムについて、リモート・システム上でのコンテンションを基礎としてリモート・クラスタ単位のリソースのグループ化と、このようなリモート・クラスタごとに、リモート・クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性とを示す。最後に、複合クラスタ・データは、対応するローカル・データとリモート・データを組み合わせることによって生成され、システム間のコンテンションを基礎として複合クラスタ単位のリソースのグループ化と、このような複合クラスタごとに、複合クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性とを示す。

上記の表では、「ローカル・システム情報」という見出しの下にある項目は、ローカル・ユーザがあるリソースを待っているかまたはコンテンション中のリソースを保持しているという意味でローカル・コンテンションのみに基づくので、ローカル・クラスタ・データを表している。あるリソースについて最も困窮しているローカル・ウェイタの必要性は、「ローカル・システム情報」の下にある「ウェイタ」の列を調べることによって確認することができる。したがって、リソースＲａの場合、ローカル・ウェイタはまったくなく（このため、「最も困窮している」ローカル・ウェイタもまったくない）、リソースＲｂの場合、最も困窮しているウェイタ（ＴｘＢ）は２という必要性を有する。ローカル・コンテンションを基礎とするクラスタ単位のリソースのグループ化はこの表には明示的に示されていないが、ローカル・ユーザが一方のリソースを保持し、もう一方を待っているというリソース項目対を探すことによって導出することができる。したがって、上記の表では、リソースＲａのホルダおよびリソースＲｂのウェイタとしてユーザＴｘＢをリストすると、ローカル・コンテンション・データを基礎としてリソースＲａおよびＲｂが共通クラスタに割り当てられることを意味する。

同様に、「リモート・ウェイタ情報」という見出しの下にある項目は、特定のリモート・システム上のコンテンションのみに基づくので、リモート・クラスタ・データを表している。「システム名」の列内のリソースについてリストしたリモート・システムごとに、最も困窮しているウェイタの必要性が隣接する「ＮＱＯ」の列に示されている。特定のリモート・システムからのコンテンション・データを基礎とするクラスタ単位のリソースのグループ化は上記の表には示されていないが、それをローカル・クラスタ割当て情報と組み合わせて複合クラスタ割当てを取得できるようにローカルＷＬＭインスタンスによって追跡される。クラスタ同士の組合せは単純明快な方法で行われる。したがって、第１のシステムが（そのローカル・コンテンション・データを基礎として）共通クラスタにリソースＡおよびＢを割り当てる場合、第２のシステムは同様に共通クラスタにリソースＢおよびＣを割り当て、第３のシステムは共通クラスタにリソースＣおよびＤを割り当て、その結果得られる複合クラスタはリソースＡ、Ｂ、Ｃ、Ｄを含む。

これに対して、第１の列（「リソース・クラスタ」）は、クラスタへのリソースの割当てがローカル・クラスタ・データとリモート・クラスタ・データの両方に基づくので、複合クラスタ・データを表している。同様に、最後の列（「ＮＱＯ」）は、リストした必要性がすべてのシステム間でそのリソースについて最も困窮しているウェイタの必要性（ローカル・システムに報告されるもの）なので、複合クラスタ・データを表している。

システムＳｙ２は、上記に示す表形式でコンテンション・データを記憶することができるが、より一般的には、以下に詳述するように、このようなデータをいくつかのデータ構造に分散すると、操作しやすさを最適化することになるだろう。

図８は、ローカル・リソース・マネージャからのコンテンション通知に応答してＷＬＭのローカル・インスタンスが従う一般的な手順５００を示している。特定のステップ・シーケンスについて説明するが、このシーケンスは、各ステップを実行するときに必要な入力データが使用可能である限り、変更することができる。

手順５００は、ローカル・ユーザに関連するので、ＷＬＭインスタンスがあるリソースのコンテンション状態の変化についてローカル・リソース・マネージャから通知を受信したときに始まる。このような変化は以下のいずれかを意味する可能性がある。
１．ローカル・ユーザは、他のユーザによって保持されているリソースのウェイタになっている。
２．ローカル・ユーザはもはやあるリソースのウェイタではない。これは、それがホルダとしてそのリソースを取得したためか、またはそれがもはやホルダまたはウェイタのいずれかとしてそのリソースに関心がないため（おそらく、以下の例で説明するように、それが終了しており、したがって、もはや存在しないため）である可能性がある。
３．ローカル・ユーザによって保持されているリソースはその時点でコンテンション中である。
４．ローカル・ユーザによって保持されているリソースはもはやコンテンション中ではない。

ローカル・リソース・マネージャからの通知は、リソースならびにローカル・ホルダおよびウェイタを識別することになるだろう。好ましい実施形態では、ＷＬＭは、単独で示されていないＳＲＭコンポーネントからこれらのホルダおよびウェイタのそれぞれの「必要性」（それぞれの真性必要性であって、本発明により変更された必要性ではない）を入手するが、このデータの特定のソースは本発明の一部を形成しない。

リソース・マネージャ・インスタンスからこのような通知を受信したことに応答して、ＷＬＭのローカル・インスタンスはまず、当該リソースに関するローカル・コンテンション・データを更新する（ステップ５０４）。このような更新は、ローカル・システム上で新たにコンテンション中になっているリソースに関する新しい項目を作成すること、ローカル・システム上ですでにコンテンション中になっているリソースに関する既存の項目を修正すること、またはローカル・システム上でもはやコンテンション中になっていないリソースに関する既存の項目を削除することを含むことができる。このローカル・コンテンション・データは、そのリソースを保持しているかまたは待っているローカル・ユーザのＩＤとともにこのようなユーザの「必要性」を含む。

ローカル・コンテンション・データを更新した後、ＷＬＭのローカル・インスタンスは、必要であれば、そのリソースのクラスタ割当てを更新する（ステップ５０６）。デフォルトでは、メンバとしてそれ自体のみを含むトリビアル・クラスタにリソースが割り当てられる。ローカル・コンテンション・データまたはリモート・コンテンション・データのいずれかによって示されている場合は、少なくとも１つの他のリソースを含む非トリビアル・クラスタにリソースが割り当てられる。同じローカル・ユーザがリソースの一方を保持しながらもう一方のリソースを待っていること、すなわち、そのリソースが、もう一方のリソースを待っているユーザによって保持されているかまたはもう一方のリソースを保持しているユーザによって待たれていることをそのデータが示す場合は、ローカル・コンテンション・データを基礎として他のリソースを含むクラスタにリソースが割り当てられる。少なくとも１つのリモート・システムにとってローカルのコンテンション・データを基礎として、そのリモート・システムが共通クラスタに２つのリソースを割り当てたことをそのデータが示す場合は、リモート・コンテンション・データを基礎として他のリソースを含むクラスタにリソースが割り当てられる。したがって、このクラスタ割当てステップは、（１）そのリソースに関するクラスタ割当てを未変更のままにしておくこと、（２）変更したローカル・コンテンション・データと既存のリモート・コンテンション・データが示す場合に非トリビアル・クラスタにそのリソースを新たに割り当てること、または（３）変更したローカル・コンテンション・データと既存のリモート・コンテンション・データがもはやこのような割当てを示していない場合に既存のクラスタを分解することを伴う可能性がある。そのリソースのクラスタ割当てが変更された場合、その変更の影響を受ける他のリソースに関するクラスタ情報も同様にこの時点で修正される。

同時に、ＷＬＭのローカル・インスタンスは、そのリソースに関するローカル・コンテンション・データのみに基づく、そのリソースの帰属「必要性」値を更新する（ステップ５０８）。この帰属必要性は、そのリソースに関するローカル・コンテンション・データが示すように、そのリソースのローカル・ウェイタの必要性のうち最大のものである。このステップはクラスタ割当てステップに続くものとして示されているが、いずれのステップも他のステップの結果を使用しないので、諸ステップの順序は重要ではない。

そのリソースに関するクラスタ割当てと帰属必要性値を更新した後のある時点で、ＷＬＭのローカル・インスタンスはその複合クラスタ・データを更新するが、このデータは、（１）ローカルおよびリモート・コンテンション・データに基づくそのリソースに関する帰属必要性値（上記の表の「ＮＱＯ」の列）と、（２）ローカルおよびリモート・コンテンション・データに基づく複合クラスタ単位のリソースのグループ化と、（３）そのリソース・クラスタ全体の帰属「必要性」値とを含む（ステップ５１０）。最後に指定したものは、単に複合クラスタを構成するリソースのいずれかの必要性のうち最大のものであり、この場合も、その必要性はそのクラスタを構成するリソースに関するリモートならびにローカル・コンテンション・データに基づくものである。

次に、ＷＬＭのローカル・インスタンスは、その更新済みローカル・コンテンション・データの要約をクラスタ内の他のシステムにブロードキャストする（ステップ５１２）。このデータ要約は以下のものを含む。
１．ローカル・システム名。
２．リソース名。そのリソースがマルチシステム・リソースである場合、リソース名は、クラスタ全域で認識されるリソースの実際の名前である。そのリソースがローカル・リソースである場合、リソース名は、以下の実施例２で説明するように、実際のローカル・リソース名の「プロキシ」として機能する汎用ローカル・リソース名である。
３．そのリソースが割り当てられるクラスタを識別するクラスタＩＤ。この値は厳密にローカルなものであり、受信側システムはこの値を比較して、２つのリソースが送信側システム上の同じクラスタに属すかどうかを確認するが、この値の構造または内容に関する想定は行わない。以下の例では、純粋に読者の理解を容易にするための記憶を助ける工夫として、クラスタ内のマルチシステム・リソースの連結としてクラスタ名が与えられる。しかし、好ましい実施形態では、「クラスタ名」は実際には、同じ送信側システム上で発生する他のクラスタＩＤと等しいかどうかについてのみ受信側システムがテストできる不透明「クラスタＩＤ」である。
４．単に送信側システムの「ローカル・システム情報」に基づくそのリソースの「必要性」、すなわち、そのリソースについて最も困窮しているローカル・ウェイタ。これは、そのデータのみを考慮した場合にその必要性が何になるべきかをこのシステムが思考する際の投票と見なすことができる。そのリソースのローカル・ウェイタがまったくない場合、以下の実施例１で説明するように、ローカルの必要性がまったくないことを示すダミー値を送信する。
５．送信側システム上のいずれかのトランザクションが強制的にそのリソースをクラスタに含めるかどうか、すなわち、ローカル・コンテンション・データに基づいてそのリソースを非トリビアル・クラスタに割り当てるかどうかの表示。これは、この説明でローカル／リモートの値が与えられるＹＥＳ／ＮＯではなく、ブール値である。ローカルとは、（１）送信側システムが、１つのリソースのウェイタであるだけでなく他のリソースのホルダでもある少なくとも１つのトランザクションを有することと、（２）同じトランザクションがこのリソースのウェイタまたはホルダのいずれかであること（したがって、送信側システムはグループとして管理すべきトランザクション（複数も可）と接続されたリソース・グループを必要とする）を意味する。リモートとは、送信側システムのローカル・データのいずれも、そのリソースが非トリビアル・クラスタの一部であることを必要としないことを意味する。トリビアル・クラスタは正確に１つのリソースを有し、クラスタ化コードをいくらか容易にするために「リモート」の値をすでに持っている。

クラスタ再割当てが行われた場合、ＷＬＭは、その再割当ての影響を受ける他の各リソースに関する同様の情報もブロードキャストする。

最後に、ローカルＷＬＭインスタンスは、ローカル・ユーザの「必要性」値に対し、必要な調整を行う（ステップ５１４）。より具体的には、ＷＬＭは、少なくともそのリソースを含むクラスタ内で最も困窮しているウェイタの真性必要性と一致するように、同時に他のリソースのウェイタではない（したがって、コンテンション・チェーンの先頭にある）リソースのローカル・ホルダの「必要性」を調整する。調整した値は、システム・リソースをホルダに割り振るために実際に使用する帰属「必要性」値であって、そのユーザに割り当てられる（しかも他のユーザに値を帰属させるために使用される）真性必要性値ではない。したがって、特定の必要性値を帰属させるための理由が消滅した場合、あるユーザに帰属する必要性値は真性必要性値またはより小さい帰属必要性値に逆戻りする。

図９は、リモート・システム上のＷＬＭインスタンスからリモート・コンテンション・データのブロードキャスト（ステップ６０２）を受信したことに応答してＷＬＭのローカル・インスタンスが従う一般的な手順６００を示している。このブロードキャストは、影響を受けるリソースごとに、ステップ５１２の説明でリストした情報を含む。

このような通知を受信したことに応答して、ＷＬＭのローカル・インスタンスはまず、当該リソースに関するリモート・コンテンション・データを更新する（ステップ６０４）。ステップ５０４に記載したローカル・コンテンション・データの更新の場合のように、このような更新は、ローカル・システム上で新たにコンテンション中になっているリソースに関する新しい項目を作成すること、ローカル・システム上ですでにコンテンション中になっているリソースに関する既存の項目を修正すること、またはローカル・システム上でもはやコンテンション中になっていないリソースに関する既存の項目を削除することを含むことができる。このリモート・コンテンション・データは、そのリソースのウェイタを有するリモート・システムのＩＤとともに、そのリソースについてリモート・システム上で最も困窮しているウェイタの必要性を含む。

そのリソースに関するリモート・コンテンション・データを更新した後、ＷＬＭのローカル・インスタンスは、ステップ５１０で行ったように、そのリソースに関する複合クラスタ・データを更新する。ステップ５１０のように、更新した複合クラスタは、（１）ローカルおよびリモート・コンテンション・データに基づくそのリソースに関する帰属必要性値と、（２）ローカルおよびリモート・コンテンション・データに基づく複合クラスタ単位のリソースのグループ化と、（３）ローカルおよびリモート・コンテンション・データに基づくそのリソース・クラスタ全体の帰属「必要性」値とを含む（ステップ６０６）。

最後に、ステップ５１４のように、ローカルＷＬＭインスタンスは、少なくともそのリソースを含むクラスタ内で最も困窮しているウェイタの真性必要性と一致するように、同時に他のリソースのウェイタではない（したがて、コンテンション・チェーンの先頭にある）リソースのローカル・ホルダの「必要性」を調整することにより、ローカル・ユーザの「必要性」値に対し、必要な調整を行う（ステップ６０８）。

詳細な実施例およびシナリオは以下の通りである。

（「単純」推移閉包ケース）
この実施例はクロスシステム推移閉包ケースであり、複数のリソースが含まれ、１つのリソースを保持している困窮していないユーザは、他のリソース移動を待っている他の（困窮している）ユーザを獲得するために援助を受ける。トポロジは、同じリソースに関するホルダとウェイタがそれぞれ異なるシステム上にあるマルチシステムである。

これは、同じリソース・クラスタ内にマルチシステム・リソースのみが含まれるときに何が起こるかを示したものであり、したがって、「単純」推移閉包ケースである。

この実施例の表記法は以下の通りである。各ホルダおよびウェイタはトランザクション（Ｔｘｎ、たとえば、ＴｘＡ、ＴｘＢ）であり、ＮＱＯ（ｅＮＱｕｅｕｅ Ｏｒｄｅｒ）値を有する。ＮＱＯ値は、値がより小さい方がより困窮している（より援助に値する）ようになっている。各システムには番号が付けられ（Ｓｙ１、Ｓｙ２）、これらのシステムはいずれも同じ「システム・クラスタ」内にある。各リソースは小文字を有し（Ｒａ、Ｒｂ）、範囲としてはマルチシステムである。各リソース・クラスタは、そのクラスタ内のリソースのリストを示す１つまたは複数の小文字を有する（Ｃａ、Ｃａｂ）。特に明記されていない限り、リソースを入手するための要求は排他制御のためのものである。

時間順のイベント・シーケンスは以下の通りである。

ｔ＜６の場合、コンテンションは存在しないので、いずれのシステムにもＷＬＭコンテンション・データがまったくない。

ｔ＝６では、コンテンションが発生する（Ｓｙ１： ＴｘＢはＲｂを要求するが、ＴｘＣがそれを保持しているので中断される）。その結果、Ｓｙ１は以下のように動作する。
１．リソースＲｂに関するコンテンションを追跡し始める。
２．Ｒｂのみからなるリソース・クラスタを作成する。
３．Ｒｂに関するローカル・ウェイタ・リストにＴｘＢを追加する。

この時点でＳｙ１上の状態は以下のようになる。

次にＳｙ１は、そのリソース・トポロジを再評価するときに、Ｃｂに関するＮＱＯを計算する。
１．Ｓｙ１が把握しているもの（実際は、この時点は１つだけである）であって、Ｒｂに関するトポロジに含まれる最も困窮しているエンティティはＴｘＢであるので、Ｒｂに関するＮＱＯとしてＴｘＢのＮＱＯ（４）を使用する。
２．Ｃｂ内のすべてのリソースに関するＮＱＯを計算してあるので、Ｃｂ内のすべてのリソースＮＱＯのうち最も困窮しているものとしてＣｂに関するＮＱＯを計算する。これは、４というＮＱＯをＲｂからＣｂに伝えるものである。
３．Ｒｂはマルチシステム・リソースであるので、Ｓｙ１はＲｂの情報をシステム・クラスタ内の他のすべてのシステムにブロードキャストする。上記の通り、Ｒｂに関して送信された情報は、システム名と、リソース名と、クラスタＩＤと、送信側システムの「ローカル・システム情報」のみに基づくそのリソースのＮＱＯと、「ローカル」に設定されたときに送信側システム上のトランザクションが強制的にそのリソースをクラスタに含めることを示すブール値（ローカル／リモート）とを含む。
４．上記の説明に基づいて、送信されたデータは、Ｓｙ１、Ｒｂ、Ｃｂ、４、リモートである。

この時点でＳｙ１上の状態は以下のようになる。

Ｓｙ２はこの情報を受信し、同時に、Ｓｙ２上で動作するリソース・マネージャ・インスタンスはＲｂ上のコンテンションをＳｙ２に通知する。動作の順序は無関係であるが、前述の順序でリストされる。コード内の唯一の「トリック」は、Ｓｙ２上のリソース・マネージャがレースに勝った場合、リモート・データが到着したときに、コードは、それがすでに同等のクラスタを構築しており、リモート情報をその既存のデータに追加することを認識しなければならないことである。

Ｓｙ１からリモート情報を受信した後、Ｓｙ２上の状態は以下のようになる。

Ｓｙ２のローカル・リソース・マネージャがＲｂ上のコンテンションをＳｙ２に通知すると、Ｓｙ１およびＳｙ２上の状態は以下のようになる。

ただし、Ｒｂに関するＳｙ２上のローカルＮＱＯは４であって、ＴｘＣのＮＱＯである５ではないことに留意されたい。第１に、リソース・ホルダのＮＱＯ（複数も可）はリソースのＮＱＯにまったく影響を及ぼさず、そのホルダは動作しているので、ＷＬＭのポリシー調整コードはすでにＮＱＯを暗黙的に使用している。第２に、Ｓｙ２はその時点で、システム・クラスタ内のどこか他の箇所でＮＱＯが４であるトランザクションが待っていることを把握しており、４は５よりより困窮しているものとして定義されているので、Ｒｂに関するＮＱＯは４程度の困窮度でなければならない。

ｔ＝７では、他のリソース上でコンテンションが発生する（Ｓｙ２： ＴｘＡはＲａを要求するが、ＴｘＢがそれを保持しているので中断される）。図１０はｔ＝７後のトポロジを示している。

リソースＲａもマルチシステムの範囲を有するので、この結果、Ｒｂに関して発生したものと同様にわずかなハンドシェークが行われ、その結果得られる状態は以下の通りである。

Ｓｙ１上のリソース・マネージャ・インスタンスがＲａ上のコンテンションをＳｙ１に通知すると、Ｓｙ１は、ＣａとＣｂを（新しい）クラスタＣａｂにリンクするという重大なステップを実行する。単にＲａ上のコンテンションの通知を受けた後、有効な（しかしこれまでは不完全な）状態は以下のようになるだろう（これらが２つの個別ステップであるか１つの統合ステップであるかにかかわらずコード・インプリメンテーション次第であり、それらは別々に示される）。

次にＳｙ１は、そのトポロジを再評価するときに、ローカル情報に基づいて、単一トランザクション（ＴｘＢ）が２つの異なるリソース（ＲａおよびＲｂ）に関連し、したがって、それらのリソースの管理を統合しなければならない（換言すれば、ＲａとＲｂは同じリソース・クラスタＣａｂ内になければならない）ことを把握する。そのクラスタのＮＱＯは、そのメンバ・リソースのうち最も困窮しているＮＱＯ（このケースでは１）になる。

ＲａとＲｂをまとめて管理しなければならないという「信号」は、コンテンション中の１つまたは複数のリソースを保持しているだけでなくコンテンション中の他の１つまたは複数のリソースを待っている少なくとも１つのトランザクションの存在である。

トポロジに対するそのビューを再評価した後、Ｓｙ１は（以前と同様）クラスタ内の他のシステムにそのビューをブロードキャストする。
１．Ｓｙ１、Ｒａ、Ｃａｂ、ダミーＮＱＯ値、ローカル
２．Ｓｙ１、Ｒｂ、Ｃａｂ、４、ローカル

ダミーＮＱＯ値は、単にＷＬＭがこれまでに生成できたものより困窮度が低いものにすぎない。Ｓｙ１は、ローカル・ウェイタをまったく持っていないので純粋にローカルのＮＱＯ値をまったく持っていないが、そのローカル・データに基づいてＲａとＲｂを１つのユニットとして管理しなければならないという「仮想メッセージ」を送出する必要がある。

Ｓｙ２はデータを統合し（ＲａとＲｂを１つのユニットとして管理しなければならないという事実を含み、ＣａとＣｂをマージしなければならないことを意味する）、以下のものが得られる。

どちらのシステムも完全なトポロジのコピーを持っていない場合でも、この時点で両方のシステムがその問題の重要性（すなわち、最も困窮しているウェイタのＮＱＯ値）について合意に達している。

ｔ＝１０では、コンテンションはアンワインドし始める（Ｓｙ２： ＴｘＣはＲｂをリリースする）。この時点で、Ｒｂに関するＳｙ２のビューはリモート・データのみを含む。

ｔ＝１１では、Ｓｙ１上のリソース・マネージャ・インスタンスは、Ｒｂが使用可能であることを発見し、その待ち行列上の最初のウェイタにそれを与える（Ｓｙ１： ＴｘＢは再開され、Ｒｂを取得する）。リソース・マネージャの待機待ち行列はその時点で空になっているので、Ｒｂのコンテンションがすでに終了したことを示すようＷＬＭに通知する。各システム内では（２つのシステムがタイミング・ウィンドウのために異なるクラスタ内にある同じリソースを有する可能性があるが）どの単一リソースも単一クラスタにしか属すことができないので、Ｓｙ１はそのリソース・クラスタからＲｂを除去する。

並行して、Ｓｙ２上のリソース・マネージャ・インスタンスには、もはやＲｂに関する競合が発生していないことが告げられ（リソース・マネージャ・インプリメンテーションに応じて、これはｔ＝１０程度の早期に発生した可能性がある）、これもそのリソース・トポロジからＲｂを除去する。

ｔ＝１２では、リリースされたリソースがもはやコンテンション中ではないので、いかなる変化も存在しない（Ｓｙ１： ＴｘＢはＲｂをリリースする）。

ｔ＝１３では、コンテンションは完全にアンワインドする（Ｓｙ１： ＴｘＢはＲａをリリースする）。Ｓｙ１上のリソース・マネージャ・インスタンスは、Ｒａのコンテンションの終了を信号で知らせるようＷＬＭに通知する。

ｔ＝１４では、Ｓｙ２もコンテンションの終了を認識する（Ｓｙ２： ＴｘＡは再開され、Ｒａを取得する（コンテンションなし））。Ｓｙ２上のリソース・マネージャ・インスタンスは、Ｒａのコンテンションの終了を信号で知らせるようＷＬＭに通知する。

（ローカル・リソースを備えた推移閉包ケース）
この実施例はもう１つのクロスシステム推移閉包ケースであり、複数のリソースが含まれ、１つのリソースを保持している困窮していないユーザは、他のリソース移動を待っている他の（困窮している）ユーザを獲得するために援助を受けなければならない。トポロジはこの場合も、同じリソースに関するホルダとウェイタがそれぞれ異なるシステム上にあるマルチシステムである。その上、実施例１とは対照的に、各システムは純粋にローカルの（非マルチシステム）リソース上の同じトランザクションを伴うコンテンションを有する。これは、同じリソース・クラスタ内にマルチシステム・リソースと単一システム・リソースの両方が含まれるときに何が起こるかを示したものである。

表記法は実施例１と同じであるが、マルチシステム・リソースは大文字Ｒを使用し（Ｒａ、Ｒｂ）、ローカル・リソースは小文字ｒを使用する（ｒｃ、ｒｄ）。Ｒｌｏｃａｌ（＝ＲＬ）は、「リモート・システムにとって範囲がローカルである何らかの不明のリソース・セット」のプロキシ名である。実際の値は無関係であり、唯一の要件は、すべての参加者がその値に同意することと、任意の有効なリソース名と衝突できないようにすることである。

時間順のイベント・シーケンスは以下の通りである。

ｔ＜８の場合、各システム上のコンテンション状態はまさに実施例１と同じであり、したがって、ここでは説明しない。

ｔ＝８では、コンテンションはローカル（非マルチシステム）リソースｒｌ上で発生する（Ｓｙ１： ＴｘＳはｒｌを要求するが、ＴｘＢがそれを保持しているので中断される）。リソースｒｌは、Ｓｙ１上のリソース・クラスタのみに統合される。ｒｌのＮＱＯはＴｘＳからの３であるが、クラスタＣａｂｌはＲａのために依然として１というＮＱＯを有する。

Ｓｙ１はクラスタに対するそのビューをブロードキャストするときに、直接ｒｌをブロードキャストするわけではない。というのは、ＲａとＲｂは他のシステムにとって目に見える可能性のある、クラスタ内の唯一のリソースであるからである。むしろ、それは、Ｓｙ１のローカル・リソースのすべて（ｒｌのみであると把握している）のプロキシ（Ｒｌｏｃａｌ）をブロードキャストすることになる。
１．Ｓｙ１、Ｒａ、Ｃａｂｌ、ダミーＮＱＯ値、ローカル
２．Ｓｙ１、Ｒｂ、Ｃａｂｌ、４、ローカル
３．Ｓｙ１、Ｒｌｏｃａｌ、Ｃａｂｌ、３、ローカル

このデータを受信し、そのトポロジを更新した後、Ｓｙ２はこれが以下の状態になると確信する。

ｔ＝９では、もう１つのローカル・リソースがもう一方のシステム上でのコンテンションを示す（Ｓｙ２： ＴｘＴはｒｊを要求するが、ＴｘＡがそれを保持しているので中断される）。図１１は、ｔ＝９後のトポロジを示している。

Ｓｙ１上で行ったように同様の処理がＳｙ２上で行われ、次にＳｙ２はそのデータをＳｙ１にブロードキャストする。Ｓｙ２は以下のものをブロードキャストする。
１．Ｓｙ２、Ｒａ、ＣａｂＬ、１、ローカル
２．Ｓｙ２、Ｒｂ、ＣａｂＬ、ダミーＮＱＯ値、リモート
３．Ｓｙ２、Ｒｌｏｃａｌ、ＣａｂＬ、２、ローカル

上記のブロードキャストでは、Ｓｙ２上のローカル・リソースのプロキシの名前は暗黙的にクラスタ名によって修飾される。というのは、以下に注記するように、システム・クラスタ全体用ではなく、各リソース・クラスタごとにプロキシが定義されているからである。また、ＲａおよびＲｌｏｃａｌに関するブロードキャストのみがブール値「ローカル」を含むが、これは、この２つのリソースのみがローカル・データを基礎として共通クラスタに割当て可能であるからである。

Ｓｙ２上のＲｌｏｃａｌに関する「リモート・ウェイタ情報」に「Ｓｙ２、２」項目を追加するかまたはＳｙ２上の「ローカル・システム情報のウェイタ」にダミー・トランザクションを追加することによりすべてのローカル・リソース・コンテンションを要約できない理由はまったくないが、上記の表はこの最適化を行わずに示されている。上記の方法の１つによりＲｌｏｃａｌでローカル状態データを要約させると、おそらくブロードキャスト・コードがより単純なものになり、Ｒｌｏｃａｌはマルチシステムの範囲で生成可能であり、ブロードキャスト・コード内に特殊ケースはまったく不要になるだろう。明らかに特殊ケースにする必要があるようなケースが他に存在する。実際には、単にシステム当たり１つではなく、リソース・クラスタ当たり１つのＲｌｏｃａｌを可能にしなければならない。

ｔ＝１０では、コンテンションはアンワインドし始める（Ｓｙ２： ＴｘＣはＲｂをリリースする）。この時点で、Ｒｂに関するＳｙ２のビューはリモート・データのみを含む。

ｔ＝１１では、Ｓｙ１上のリソース・マネージャ・インスタンスは、Ｒｂが使用可能であることを発見し、その待ち行列上の最初のウェイタにそれを与える（Ｓｙ１： ＴｘＢは再開され、Ｒｂを取得する）。リソース・マネージャの待機待ち行列はその時点で空になっているので、Ｒｂのコンテンションがすでに終了したことを示すようＷＬＭに通知する。並行して、Ｓｙ２上のリソース・マネージャ・インスタンスには、もはやＲｂに関する競合が発生していないことが告げられる（リソース・マネージャ・インプリメンテーションに応じて、これはｔ＝１０程度の早期に発生した可能性がある）。各システム内ではどの単一リソースも単一クラスタにしか属すことができないので、どちらのシステムもそのリソース・クラスタからＲｂを除去しなければならない。２つのシステムが、タイミング・ウィンドウのために一時的にまたはリソース・トポロジのために永続的に同時に異なるクラスタ内にある同じリソースを有する可能性がある。非対称トポロジの例は、３つ以上のシステムが含まれるときに現れる。

ｔ＝１２では、リリースされたリソースがもはやコンテンション中ではないので、いかなる変化も存在しない（Ｓｙ１： ＴｘＢはＲｂをリリースする）。

ｔ＝１３では、マルチシステム・コンテンションは完全にアンワインドする（Ｓｙ１： ＴｘＢはＲａをリリースする）。Ｓｙ１上のリソース・マネージャ・インスタンスは、Ｒａのコンテンションの終了を信号で知らせるようＷＬＭに通知する。

この時点でＳｙ１上のリソース・クラスタは、ローカル・リソースと、マルチシステム・コンテンションに含まれるリモート・ローカル・リソースのプロキシのみからなるので、このプロキシもクラスタから除去することができる。Ｓｙ２にはＲａのコンテンションの終了がまだ通知されていないので、Ｓｙ２は依然としてそのプロキシ・リソースをクラスタの一部として維持する。

ｔ＝１４では、Ｓｙ２もコンテンションの終了を認識する（Ｓｙ２： ＴｘＡは再開され、Ｒａを取得する）。Ｓｙ２上のリソース・マネージャ・インスタンスは、Ｒａのコンテンションの終了を信号で知らせるようＷＬＭに通知する。

ｔ＝１５では、１つのローカル・リソース上でのコンテンションが終了し（Ｓｙ１： ＴｘＢはｒｌをリリースする）、ＴｘＳが再開される。ｒｌ上でのコンテンションが終了したことをリソース・マネージャがＳｙ１に通知すると、Ｓｙ１のトポロジはもう一度、空になる。

ｔ＝１７では、最後のコンテンションが終了し（Ｓｙ２： ＴｘＡはｒｊをリリースする）、ＴｘＴが再開される。ｒｌ上でのコンテンションが終了したことをリソース・マネージャがＳｙ２に通知すると、Ｓｙ２のトポロジはもう一度、空になる。

クラスタの分割（ＢｒｅａｋＣｌｕ１）
この実施例は、関連するいずれのリソースについてもコンテンションを終了せずに１つのリソース・クラスタを複数のより小さいクラスタに分割することを含む。ＲａとＲｂをリンクするトランザクションはキャンセルされるが、各リソースは他のウェイタを有しているので、どちらのリソースもその後、依然としてコンテンション中になる。表記法は実施例１と同様である。

時間順のイベント・シーケンスは以下の通りである。

ｔ＜４の場合、コンテンションは存在しないので、いずれのシステムにもＷＬＭコンテンション・データがまったくない。

ｔ＝４とｔ＝７の間に発生するイベントはこれ以前の実施例にカバーされている。図１２はｔ＝７後のトポロジを示している。この時点での状態データは以下のようになる。

トランザクションＴｘＤが（理由の如何を問わず）ｔ＝８で終了すると、各システム上のリソース・マネージャ・インスタンスは、ＴｘＤが未解決で持っていたすべての待機要求（Ｒａ）を除去し、それが保持していたすべてのリソース（Ｒｂ）をリリースする。このようなトポロジ変化がＷＬＭに通知されると、Ｓｙ１は、リソース・クラスタＣａｂを２つの片（ＣａおよびＣｂ）に分割しなければならないことを把握する。そのシステムがこれを把握するのは、その２つがリンクされていることをＳｙ１がローカルで決定した（これがローカルではもはや該当しないことを認識できる）からであり、いかなるリモート・システムのデータも、それらをリンクしなければならないことを示していない。しかし、どちらのリソースも依然としてコンテンション中である。次にＳｙ１がそのトポロジ・データをブロードキャストすると、Ｓｙ２上の「Ｓｙ１： Ｒａ、Ｒｂリンク済み」というデータが除去され、Ｓｙ２はそのトポロジも更新する。リソース・マネージャ・インスタンスが所有権を再割当てする前にＷＬＭがこれをすべて実施すると想定すると、結果として得られる状態は以下のようになる。

したがって、これは、関連するリソースの１つに関するコンテンションの終了によるのではなく、ＲａとＲｂをまとめて管理しなければならないという「メモリ」を除去するためのメカニズムがいくつかあることを暗示している。いくつかの代替策は以下の通りである。
１．Ｓｙ１は、所与のリソース・クラスタが必要であることをもはや確信していないことを示すためのデータを明示的に送信する。たとえば、Ｒａ、Ｃａ、４、リモートを送信する。Ｓｙ２がＲａに関するＳｙ１の以前のデータを置き換えると、それはもはやＳｙ１から得られるＲａとＲｂをまとめて管理するためのいかなる要件も認識せず、Ｓｙ２がそのクラスタを続行するための他の「投票」をまったく持っていない場合、Ｓｙ２はそのクラスタをローカルで分割することができる。
２．Ｓｙ１のデータは古くなっている（したがって、「まもなく」置き換えられない場合でも削除される）。これはおそらく、「存続時間」（ＴＴＬ）値を送信することによって実現されるだろうが、その後、データは受信側によって削除されるだろう。このメカニズムは、システム傷害、信号喪失、バグ、回復問題などにも安全策をもたらすことができるだろう。また、ＴＴＬは、通信待ち時間を透過的なものにし、送信側と受信側が共通間隔について合意に達する必要がないという利点を有する。

最も堅固な解決策は、おそらく３つすべてになるだろう。グローバルにコンテンションの終了を信号で知らせるリソース・マネージャにより、「Ｒａ」ブロックをローカルで削除するケースを処理すると、「クラスタの分割」というメッセージを送信するのに十分長い間、それを保持する必要がない。あるリソースに関するコンテンションがリモートではなくローカルで終了し、そのローカル・システムが、その投票によって強制的に非トリビアル・クラスタを構築したシステムである場合、ＴＴＬ値によってリモート・システム上のクラスタの破壊を引き起こす。クラスタを分割する必要があるがコンテンションが終了していない場合、依然として「Ｒａ」ブロックが存在し、いずれにしても何かを送信した当然の結果としては「クラスタの分割」というメッセージが発生する。

クラスタの分割（ＢｒｅａｋＣｌｕ２）
この実施例では、共通ホルダ（複数も可）のみによって結合されたリソース・クラスタを「ｎ」個のリソースからなる１つのリソース・クラスタとしてまたはそれぞれ１つのリソースからなる「ｎ」個のクラスタとして扱うことができる。この結果は、ドキュメント化に十分値するほど驚くべきものになる。

表記法は実施例１と同様である。

時間順のイベント・シーケンスは以下の通りである。

図１３は、ｔ＝６後のトポロジを示している。

ｔ＝６までに発生するイベントはこれ以前の実施例にカバーされている。この場合に興味深いことは、定義方法に応じて、この状況を１つのリソース・クラスタまたは２つのリソース・クラスタとして扱うことができることである。１つのリソースに関するホルダとしてならびに異なるリソースに関するウェイタとして同じトランザクションを有する（その後、システム・クラスタ内のすべてのシステムについてこの知識を要約する）システムによってリソース・クラスタを識別できるというこれ以前の実施例による定義を使用する場合、明らかに上記の図は、予想されるように１つのリソース・クラスタではなく、２つのリソース・クラスタを示す。

リソース・クラスタＣａｂを形成する際にまったく価値がなく、そのように実行する際に関連してオーバヘッドが発生する（より精密には、あるクラスタを分割しなければならないかどうかを決定するときに関連してオーバヘッドが発生する）ので、この定義は引き続き使用されることになる。したがって、上記の図に対応する状態データは以下のようになるだろう。

この定義に固有の想定は、ＷＬＭがその作業を援助しようと試みるときに、それが各リソースを検査し、ＮＱＯ値に基づいて必要に応じてホルダ（複数も可）を援助することになることである。このトポロジが単一リソース・クラスタとして扱われる場合、ＴｘＡはクラスタＣａｂから１というＮＱＯを継承するだろう。これを２つのクラスタとして扱うと、ＷＬＭは以下のように結論を下さなければならない。
１．ＮＱＯが３であるホルダはＮＱＯが４であるリソース・クラスタより困窮しているので、Ｃａは援助をまったく必要としない。
２．ＮＱＯが１であるクラスタはＮＱＯが３であるＴｘＡより困窮しているので、Ｃｂは援助を必要とする。

このシナリオが１つのリソース・クラスタとして扱われるか２つのリソース・クラスタとして扱われるかにかかわらず、ＴｘＡは最後に１というＮＱＯを継承するので、どちらを選択してもよい。複合クラスタの分解が必要な時期に関するテストのために、２つの「トリビアル」（単一リソース）クラスタを管理する方が単一複合クラスタより効率的なので、このケースは２つのトリビアル・リソース・クラスタとして扱われる。

単純３ウェイ・シナリオ（３ｗａｙＥａｓｙ）
この実施例は単純３システム・シナリオである。これも推移閉包ケースであるが、その非対称トポロジによって強制的にシステムがリソース・マネージャから得られるローカル・ウェイタ／ホルダ情報を持っていないリソースを追跡する。表記法は実施例１と同様である。

時間順のイベント・シーケンスは以下の通りである。

ｔ＝５までに発生するイベントはこれ以前の実施例にカバーされている。図１４は、ｔ＝５後のトポロジを示している。この時点での状態データは以下のようになる。

この場合に興味深いことは、Ｓｙ３がＲａとまったく関連がないが、それはＴｘＣのＮＱＯが（Ｓｙ１上のＴｘＡから継承した）１でなければならないことを決定するために、少なくともＲａに関する何らかのデータを追跡することである。これは多くの困難を引き起こさないはずであるが、Ｓｙ１とＳｙ２は他のどのシステムがＲａと関連するかを把握しておらず、すべてのシステムがそれぞれの最新トポロジ・データ（当然のことながら、移動ターゲットである）をブロードキャストした後で「発見可能」であるにすぎない。したがって、Ｓｙ１とＳｙ２はとにかくそれぞれのデータをブロードキャストしなければならない。追加の義務は、Ｓｙ３が対等システムから受信した要約データを記帳しなければならないことであるが、それがＲａと無関係である限り、複雑なトランザクションベースの論理のいずれも呼び出されない。これはおそらく、そのクラスタのＮＱＯと、そのＮＱＯに至るシステムのＩＤとをブロードキャストすることによって解消できるだろうが、クラスタをもう一度より小さい片に分割する時期に達したときに表面化する問題がいくつかある。各リソースを追跡することは、正しいＮＱＯに至ると認識できるものに見合うほど小さい代償のように思われる。

この状態からのアンワインドは、これ以前の実施例のように進行する。

クラスタの分割を伴う３ウェイ・シナリオ（３ｗａｙＢｒｅａｋＣｌｕ）
この実施例は、我々を駆り立てるための「コンテンションの終了」イベントなしに大きいクラスタをより小さいクラスタに分割する、３システム推移閉包ケースである。この実施例も、あるリソースの複数共用ホルダを含むトポロジを示している。表記法は実施例１と同様である。

時間順のイベント・シーケンスは以下の通りである。

ｔ＝７までに発生するイベントはこれ以前の実施例にカバーされている。前の実施例のように、Ｓｙ３はＲａとまったく関連がないが、それは少なくともＲａに関する何らかのデータを追跡する。

図１５は、ｔ＝７後のトポロジを示している。この時点での状態データは以下のようになる。

この状態からのアンワインドは、これ以前の実施例のように進行する。この場合、ｔ＝８およびｔ＝９でのイベントは、リソース・クラスタＣａｂがもはや不要であることを意味し、これ以前の実施例の通り、このケースではそのクラスタが分割されることになる。したがって、ｔ＝９後は、図１６および以下の表に示す状態になる。

関連するいずれのリソースについてもコンテンションをクリアせずにリソース・クラスタが分割される前のケースのように、コンテンション中のリソースを保持しているだけかまたは待っているだけである限り、単一トランザクション（この場合はＴｘＢ）が２つの個別リソース・クラスタに同時に関連することができることが分かるだろう。それがコンテンション中のいずれかのリソースを待つとすぐに、それが保持しているかまたは待っているコンテンション中のすべてのリソースを単一リソース・クラスタとして管理しなければならない。

データ構造
図１７〜２４は、本発明によりコンテンション・データを記憶するための１組の可能なデータ構造を示している。

図１７を参照すると、リソース・コンテンション制御テーブル（ＲＣＣＴ）８０２を使用して、関心のある様々な項目のみ（または主に）単一ＷＬＭサブコンポーネントにアンカーする。これは以下のものを含む。
１．リソース・クラスタ・エレメント（ＲＣＬＵ）８０６（図１８）用のアンカー８０４
２．リソース・エレメント（ＲＳＲＣ）８１０（図１９）用のアンカー８０８
３．トランザクション・テーブル（ＴＲＸＮＴ）８１４（図２２）用のアンカー８１２

図１８を参照すると、各リソース・クラスタ・エレメント（ＲＣＬＵ）８０６は、単一リソース・クラスタに関連するデータを含む。これは以下のものを含む。
１．クラスタＩＤ８１６
２．クラスタＮＱＯ８１８（クラスタ内のすべてのリソースの最小のもの）
３．クラスタ内のリソースのリソース・エレメント（ＲＳＲＣ）８１０（図１９）用のアンカー８２０

図１９を参照すると、各リソース・エレメント（ＲＳＲＣ）８１０は、コンテンション中のリソースを記述するものである。これは以下のものを含む。
１．リソース・フィンガプリント／名８２２
２．リソースＮＱＯ８２４（ブロードキャスト・パス上での効率のためにローカル／システム・クラスタ値を別々に保持する必要がある可能性があり、そうではない場合、これはシステム・クラスタＮＱＯになる。）
３．クラスタ・エレメント（ＲＣＬＵ）８０６（図１８）へのポインタ８２６
４．ローカル・ホルダに関するリソース・コンテンション待ち行列エレメント（ＲＣＱＥ）８３０（図２４）用のアンカー８２８
５．ローカル・ウェイタに関するリソース・コンテンション待ち行列エレメント（ＲＣＱＥ）８３０用のアンカー８３２
６．このリソースに関するリモート・データ用のシステム・データ・アンカー（ＳＤＡ）８３６（図２０）用のアンカー８３４

図２０を参照すると、各システム・データ・アンカー（ＳＤＡ）８３６は、単一システムに関するリモート・システム情報用のアンカーとして機能する。これは以下のものを含む。
１．リモート・システムＩＤ８３８
２．このシステムからのリモート・システム・データ・エレメント（ＲＳＤＥ）８４２（図２１）用のアンカー８４０
３．リモート・システムの最高の既知の送信シーケンス番号を表す値８４４。換言すれば、アウトバウンド・パス上で送信側システムは、トポロジ・データの各「バッチ」ごとに同じになる値（タイムスタンプなど）を含む。各受信側システムは着信メッセージ内の値とこの値を比較し、メッセージの方が小さい値（受信側システムがすでに同じ送信側からより最近のデータを受信したので、これが古くなっていることを暗示する）を有する場合、そのメッセージは無視される。
４．トポロジ・メッセージをリモート・システムから受信したときにローカル・クロックを使用して更新されるタイムスタンプ８４６

図２１を参照すると、各リソース・システム・データ・エレメント（ＲＳＤＥ）８４２はリソースに関するリモート・システム情報を含む。これは以下のものを含む。
１．そのシステム用のシステム・データ・アンカー（ＳＤＡ）（図２０）へのポインタ８４８
２．そのリソース用のリソース・エレメント（ＲＳＲＣ）８１０（図１９）へのポインタ８５０
３．同じリソースに関する他のＲＳＤＥ８４２用の待ち行列リンク８５２
４．リモート・システム上のウェイタのみを考慮するリモート・システムのＮＱＯ８５４
５．デバッグのみのための送信タイムスタンプ８５６（送信したときのリモート・システム上のクロック値）
６．デバッグおよびＴＴＬ処理のためのタイムスタンプ８５８であって、受信したときのローカル・クロック値を表すもの
７．このリソース用のリモート・クラスタＩＤ８６０。リモート・システムが、ホルダでありかつウェイタでもあるトランザクションを有する場合、関連するすべてのリソースは、そこでは同じクラスタＩＤを有することになり、ここでは同じクラスタ内にある必要がある。異なるシステムからのリモート・データが、どのリソースが１つのクラスタに属すかに関して一致しない場合、クラスタはローカルで合併される。
８．リモート・システムがいくらか余分のものを加えたデータの送信を計画する頻度に対応して、リモート・システムによって供給される存続時間（ＴＴＬ）期間８６２。ローカル時間が受信タイムスタンプにこの値を加えたものを超える場合、そのエレメントは削除の対象となる。

図２２を参照すると、トランザクション・テーブル（ＴＲＸＮＴ）８１４を使用して、関心のある様々な項目のみ（または主に）単一ＷＬＭサブコンポーネントにアンカーする。これは以下のものを含む。
１．トランザクション・テーブル８１４を構築したときのアドレス・スペースの数８６４
２．トランザクション・テーブル８１４を構築したときのエンクレーブの数８６６
３．トランザクション・テーブルの先頭から最初のテーブル項目８６８までのオフセット８６８
４．アドレス・スペースであるトランザクション用の項目（ＴＲＸＮＥ）（数８６４以内）用の領域８７０
５．エンクレーブであるトランザクション用の項目（ＴＲＸＮＥ）（数８６６以内）用の領域８７２

図２３を参照すると、トランザクション・テーブル（ＴＲＸＮＴ）８１４の領域８７０または８７２内の各項目（ＴＲＸＮＥ）８７４は、そのコンテンションがＷＬＭによって管理される少なくとも１つのリソースに関連する単一トランザクションに関する情報を含む。これは以下のものを含む。
１．タイプ８７６： アドレス・スペースまたはエンクレーブ
２．このトランザクション用のアドレス・スペースＩＤ（ＡＳＩＤ）またはエンクレーブＩＤ８７８
３．このトランザクション用のアドレス・スペースまたはエンクレーブ・トークン８８０。ＡＳＩＤおよびエンクレーブＩＤは再使用可能であり、ＩＤを再使用する場合でもトークンによって単一イメージ内の固有性が得られる。
４．このトランザクションによって保持されているリソースに関するコンテンション・エレメント（ＲＣＱＥ）８３０（図２４）の待ち行列８８４用のアンカー８８２
５．このトランザクションによって待たれているリソースに関するコンテンション・エレメント（ＲＣＱＥ）８３０の待ち行列８８８用のアンカー８８６
６．このトランザクションのＮＱＯ８８８

図２４を参照すると、各リソース・コンテンション待ち行列エレメント（ＲＣＱＥ）８３０は、トランザクション（ホルダまたはウェイタ）をリソースに関連づけるものである。これは以下のものを含む。
１．ＴＲＸＮＴ８１０内のトランザクション用のＴＲＸＮＥ８７４のオフセット８９２
２．このトランザクションに関する次／前のＲＣＱＥ８３０用の待ち行列リンク８９４
３．このリソース用のリソース・エレメント（ＲＳＲＣ）８１０へのポインタ８９６
４．このリソースに関する次／前のＲＣＱＥ８３０用の待ち行列リンク８９８
５．保持／待機ビット８９９（おそらく待ち行列検証のみのため）

図２５は、図７に示し、図７に付随する表でＳｙ２について要約したコンテンション・シナリオを図１７〜２４に示す様々なデータ構造がどのように取り込むかを示している。

特定の実施形態について図示し説明してきたが、様々な変更形態が当業者には明らかになるだろう。したがって、（ローカルまたはリモート・コンテンション・データを基礎として）共通クラスタの一部であると確信されるすべてのリソースについて共通クラスタＩＤを送出するのではなく、ローカル・システムはむしろ、ローカル・コンテンション・データを基礎として共通クラスタに属すことが分かっているリソースについてのみ共通クラスタＩＤを使用することができるだろう。さらに他の変形形態も当業者には明らかになるだろう。

まとめとして、本発明の構成に関して以下の事項を開示する。

（１）情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための方法であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記方法が、
ユーザ・チェーン内の次のユーザを有する各ユーザが、前記次のユーザが待っているリソースを保持している前記チェーンの先頭にあるウェイタではないユーザを識別するステップと、
その必要性が少なくとも前記チェーン内の最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザを管理するステップとを具備する方法。
（２）前記管理ステップが、
その必要性が少なくとも前記チェーン内の前記最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザにシステム・リソースを割り振るステップを具備する、上記（１）に記載の方法。
（３）前記識別ステップが、
クラスタ内の各リソースがそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている前記リソースのクラスタを定義するステップを具備する、上記（１）に記載の方法。
（４）前記管理ステップが、
前記クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性を決定するステップを具備する、上記（３）に記載の方法。
（５）情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための方法であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記方法が、
クラスタ内の各リソースがそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている前記リソースのクラスタを識別するステップと、
前記クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性を決定するステップと、
前記クラスタ内のあるリソースのホルダであって、他のいずれのリソースも待っていないホルダを識別するステップと、
その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダを管理するステップとを具備する方法。
（６）前記管理ステップが、
その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダにシステム・リソースを割り振るステップを具備する、上記（５）に記載の方法。
（７）クラスタを識別する前記ステップが、あるリソースのコンテンション状況の変化の通知を受信したことに応答して実行され、
そのリソースがその時点でそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている場合に、そのリソースをそのクラスタに新たに割り当てるステップを具備する、上記（５）に記載の方法。
（８）クラスタを識別する前記ステップが、あるリソースのコンテンション状況の変化の通知を受信したことに応答して実行され、
そのリソースがもはやそのクラスタ内の他のリソースを待っているユーザによって保持されていないかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれていない場合に、そのリソースをそのクラスタから除去するステップを具備する、上記（５）に記載の方法。
（９）情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための装置であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記装置が、
ユーザ・チェーン内の次のユーザを有する各ユーザが、前記次のユーザが待っているリソースを保持している前記チェーンの先頭にあるウェイタではないユーザを識別するための論理回路と、
その必要性が少なくとも前記チェーン内の最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザを管理するための論理回路とを具備する装置。
（１０）前記管理論理回路が、その必要性が少なくとも前記チェーン内の前記最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザにシステム・リソースを割り振る、上記（９）に記載の装置。
（１１）情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための装置であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記装置が、
クラスタ内の各リソースがそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている前記リソースのクラスタを識別するための論理回路と、
前記クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性を決定するための論理回路と、
前記クラスタ内のあるリソースのホルダであって、他のいずれのリソースも待っていないホルダを識別するための論理回路と、
その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダを管理するための論理回路とを具備する装置。
（１２）前記管理論理回路が、その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダにシステム・リソースを割り振る、上記（１１）に記載の装置。
（１３）クラスタを識別するための前記論理回路が、あるリソースのコンテンション状況の変化の通知を受信したことに応答して、そのリソースがその時点でそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている場合に、そのリソースをそのクラスタに新たに割り当てる、上記（１１）に記載の装置。
（１４）クラスタを識別するための前記論理回路が、あるリソースのコンテンション状況の変化の通知を受信したことに応答して、そのリソースがもはやそのクラスタ内の他のリソースを待っているユーザによって保持されていないかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれていない場合に、そのリソースをそのクラスタから除去する、上記（１１）に記載の装置。
（１５）情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための方法ステップを実行するためにマシンによって実行可能な複数命令のプログラムを具体的に実施し、マシンによって読取り可能なプログラム記憶装置であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記方法ステップが、
ユーザ・チェーン内の次のユーザを有する各ユーザが、前記次のユーザが待っているリソースを保持している前記チェーンの先頭にあるウェイタではないユーザを識別するステップと、
その必要性が少なくとも前記チェーン内の最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザを管理するステップとを具備する、プログラム記憶装置。
（１６）前記管理ステップが、
その必要性が少なくとも前記チェーン内の前記最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザにシステム・リソースを割り振るステップを具備する、上記（１５）に記載のプログラム記憶装置。
（１７）情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための方法ステップを実行するためにマシンによって実行可能な複数命令のプログラムを具体的に実施し、マシンによって読取り可能なプログラム記憶装置であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記方法ステップが、
クラスタ内の各リソースがそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている前記リソースのクラスタを識別するステップと、
前記クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性を決定するステップと、
前記クラスタ内のあるリソースのホルダであって、他のいずれのリソースも待っていないホルダを識別するステップと、
その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダを管理するステップとを具備する、プログラム記憶装置。
（１８）前記管理ステップが、
その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダにシステム・リソースを割り振るステップを具備する、上記（１７）に記載のプログラム記憶装置。
（１９）クラスタを識別する前記ステップが、あるリソースのコンテンション状況の変化の通知を受信したことに応答して実行され、
そのリソースがその時点でそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている場合に、そのリソースをそのクラスタに新たに割り当てるステップを具備する、上記（１７）に記載のプログラム記憶装置。
（２０）クラスタを識別する前記ステップが、あるリソースのコンテンション状況の変化の通知を受信したことに応答して実行され、
そのリソースがもはやそのクラスタ内の他のリソースを待っているユーザによって保持されていないかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれていない場合に、そのリソースをそのクラスタから除去するステップを具備する、上記（１７）に記載のプログラム記憶装置。

本発明を組み込んだコンピュータ・システム・クラスタを示す図である。 様々なタイプのコンテンション・チェーンを示す図である。 様々なタイプのコンテンション・チェーンを示す図である。 様々なタイプのコンテンション・チェーンを示す図である。 様々なタイプのコンテンション・チェーンを示す図である。 コンテンション・チェーンの先頭にあるユーザにリソースを割り振るための手順を示す図である。 いくつかのシステム上のトランザクションおよびリソース間の典型的なコンテンション・シナリオを示す図である。 ローカル・リソース・マネージャからの通知に応答して従う一般的な手順を示す図である。 リモート・システムからコンテンション・データのブロードキャストを受信したことに応答して従う一般的な手順を示す図である。 様々な動作例におけるマルチシステム・コンテンション状態を示す図である。 様々な動作例におけるマルチシステム・コンテンション状態を示す図である。 様々な動作例におけるマルチシステム・コンテンション状態を示す図である。 様々な動作例におけるマルチシステム・コンテンション状態を示す図である。 様々な動作例におけるマルチシステム・コンテンション状態を示す図である。 様々な動作例におけるマルチシステム・コンテンション状態を示す図である。 様々な動作例におけるマルチシステム・コンテンション状態を示す図である。 本発明の一実施形態においてコンテンション・データを記憶するための様々なデータ構造を示す図である。 本発明の一実施形態においてコンテンション・データを記憶するための様々なデータ構造を示す図である。 本発明の一実施形態においてコンテンション・データを記憶するための様々なデータ構造を示す図である。 本発明の一実施形態においてコンテンション・データを記憶するための様々なデータ構造を示す図である。 本発明の一実施形態においてコンテンション・データを記憶するための様々なデータ構造を示す図である。 本発明の一実施形態においてコンテンション・データを記憶するための様々なデータ構造を示す図である。 本発明の一実施形態においてコンテンション・データを記憶するための様々なデータ構造を示す図である。 本発明の一実施形態においてコンテンション・データを記憶するための様々なデータ構造を示す図である。 クラスタのシステムの１つが図７に示すコンテンション・シナリオをどのように取り込むかを示す図である。

符号の説明

１００ クラスタ
１０２ システムＳｙ１
１０２ システムＳｙ２
１０２ システムＳｙ３
１０６ マルチシステム・リソース
１０８ ＯＳ
１１０ リクエスタ
１１２ ローカル・リソース
１１４ リソース・マネージャ
１１６ ＷＬＭ

Claims (20)

1. 情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための方法であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記方法が、
   ユーザ・チェーン内の次のユーザを有する各ユーザが、前記次のユーザが待っているリソースを保持している前記チェーンの先頭にあるウェイタではないユーザを識別するステップと、
   その必要性が少なくとも前記チェーン内の最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザを管理するステップとを具備する方法。
2. 前記管理ステップが、
   その必要性が少なくとも前記チェーン内の前記最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザにシステム・リソースを割り振るステップを具備する、請求項１に記載の方法。
3. 前記識別ステップが、
   クラスタ内の各リソースがそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている前記リソースのクラスタを定義するステップを具備する、請求項１に記載の方法。
4. 前記管理ステップが、
   前記クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性を決定するステップを具備する、請求項３に記載の方法。
5. 情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための方法であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記方法が、
   クラスタ内の各リソースがそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている前記リソースのクラスタを識別するステップと、
   前記クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性を決定するステップと、
   前記クラスタ内のあるリソースのホルダであって、他のいずれのリソースも待っていないホルダを識別するステップと、
   その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダを管理するステップとを具備する方法。
6. 前記管理ステップが、
   その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダにシステム・リソースを割り振るステップを具備する、請求項５に記載の方法。
7. クラスタを識別する前記ステップが、あるリソースのコンテンション状況の変化の通知を受信したことに応答して実行され、
   そのリソースがその時点でそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている場合に、そのリソースをそのクラスタに新たに割り当てるステップを具備する、請求項５に記載の方法。
8. クラスタを識別する前記ステップが、あるリソースのコンテンション状況の変化の通知を受信したことに応答して実行され、
   そのリソースがもはやそのクラスタ内の他のリソースを待っているユーザによって保持されていないかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれていない場合に、そのリソースをそのクラスタから除去するステップを具備する、請求項５に記載の方法。
9. 情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための装置であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記装置が、
   ユーザ・チェーン内の次のユーザを有する各ユーザが、前記次のユーザが待っているリソースを保持している前記チェーンの先頭にあるウェイタではないユーザを識別するための論理回路と、
   その必要性が少なくとも前記チェーン内の最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザを管理するための論理回路とを具備する装置。
10. 前記管理論理回路が、その必要性が少なくとも前記チェーン内の前記最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザにシステム・リソースを割り振る、請求項９に記載の装置。
11. 情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための装置であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記装置が、
    クラスタ内の各リソースがそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている前記リソースのクラスタを識別するための論理回路と、
    前記クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性を決定するための論理回路と、
    前記クラスタ内のあるリソースのホルダであって、他のいずれのリソースも待っていないホルダを識別するための論理回路と、
    その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダを管理するための論理回路とを具備する装置。
12. 前記管理論理回路が、その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダにシステム・リソースを割り振る、請求項１１に記載の装置。
13. クラスタを識別するための前記論理回路が、あるリソースのコンテンション状況の変化の通知を受信したことに応答して、そのリソースがその時点でそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている場合に、そのリソースをそのクラスタに新たに割り当てる、請求項１１に記載の装置。
14. クラスタを識別するための前記論理回路が、あるリソースのコンテンション状況の変化の通知を受信したことに応答して、そのリソースがもはやそのクラスタ内の他のリソースを待っているユーザによって保持されていないかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれていない場合に、そのリソースをそのクラスタから除去する、請求項１１に記載の装置。
15. 情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための方法ステップを実行するためにマシンによって実行可能な複数命令のプログラムを具体的に実施し、マシンによって読取り可能なプログラム記憶装置であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記方法ステップが、
    ユーザ・チェーン内の次のユーザを有する各ユーザが、前記次のユーザが待っているリソースを保持している前記チェーンの先頭にあるウェイタではないユーザを識別するステップと、
    その必要性が少なくとも前記チェーン内の最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザを管理するステップとを具備する、プログラム記憶装置。
16. 前記管理ステップが、
    その必要性が少なくとも前記チェーン内の前記最も困窮しているウェイタの必要性である場合と同様に、前記チェーンの先頭にある前記ユーザにシステム・リソースを割り振るステップを具備する、請求項１５に記載のプログラム記憶装置。
17. 情報処理システム内の１つまたは複数のリソースへのアクセスに関するユーザ間のコンテンションを管理するための方法ステップを実行するためにマシンによって実行可能な複数命令のプログラムを具体的に実施し、マシンによって読取り可能なプログラム記憶装置であって、前記ユーザのそれぞれは何らかの必要性が割り当てられており、それがアクセスしようと努めるリソースに関するホルダまたはウェイタのいずれかになる可能性があり、前記方法ステップが、
    クラスタ内の各リソースがそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている前記リソースのクラスタを識別するステップと、
    前記クラスタ内のいずれかのリソースについて最も困窮しているウェイタの必要性を決定するステップと、
    前記クラスタ内のあるリソースのホルダであって、他のいずれのリソースも待っていないホルダを識別するステップと、
    その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダを管理するステップとを具備する、プログラム記憶装置。
18. 前記管理ステップが、
    その必要性が少なくとも前記クラスタ内のいずれかのリソースについて前記最も困窮しているウェイタの必要性である場合と同様に、前記リソースの前記ホルダにシステム・リソースを割り振るステップを具備する、請求項１７に記載のプログラム記憶装置。
19. クラスタを識別する前記ステップが、あるリソースのコンテンション状況の変化の通知を受信したことに応答して実行され、
    そのリソースがその時点でそのクラスタ内の他のリソースを待っているユーザによって保持されているかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれている場合に、そのリソースをそのクラスタに新たに割り当てるステップを具備する、請求項１７に記載のプログラム記憶装置。
20. クラスタを識別する前記ステップが、あるリソースのコンテンション状況の変化の通知を受信したことに応答して実行され、
    そのリソースがもはやそのクラスタ内の他のリソースを待っているユーザによって保持されていないかまたはそのクラスタ内の他のリソースを保持しているユーザによって待たれていない場合に、そのリソースをそのクラスタから除去するステップを具備する、請求項１７に記載のプログラム記憶装置。

Images