JPH0743665B2

JPH0743665B2 - コンピユータ・システム資源管理方法

Info

Publication number: JPH0743665B2
Application number: JP2165868A
Authority: JP
Inventors: マーガレツト・アン・ドング; リチヤード・ケント・トライバー
Original assignee: インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン
Priority date: 1989-06-26
Filing date: 1990-06-26
Publication date: 1995-05-15
Anticipated expiration: 2010-05-15
Also published as: US5093912A; EP0405724A3; EP0405724A2; JPH0336642A

Description

【発明の詳細な説明】 A.産業上の利用分野本発明は、計算機利用のデータ処理に関し、特に、多重
プロセスが、同時に実行されるシステム内のバッファな
どのコンピュータ・システム資源の管理に関する。

B.従来の技術マルチプロセッシング：コンピュータ・プログラムは、
コンピュータ命令シーケンスから構成され、命令の単一
順序、または「プロセス」と呼ぶ命令の独立シーケンス
・セットとして実行可能である。コンピュータ資源利用
を獲得するために、プログラムは、普通、コンピュータ
の「オペレーティング・システム」に対し、「システム
・コール」と呼ぶ命令を発する。オペレーティング・シ
ステムは、コンピュータ・メモリ、あるいは、ハードウ
ェア装置などのコンピュータ資源利用を管理するプログ
ラムである。プログラムによって要求される資源は、そ
の排他的利用のために予約され、各々が、オペレーティ
ング・システムの制御に戻る（「解放される」）まで、
再利用のために使用できない。システム資源は制限さ
れ、システム・コールは実行するには比較的高価である
から、プログラム（特に、高容量あるいは高性能プログ
ラム）は、それらを制御された方法で使用する。

プログラム及びプロセスは、多くのコンピュータ環境で
動作する。「多重プログラミング」環境では、２つある
いは複数のプログラムあるいはプロセスの実行は、プロ
セッサ上でインタリーブされる。その場合、実行されて
いるプロセスは、「割り込まれ」てもよい。つまり、コ
ンピュータはプロセスの実行を停止し、他のプロセスを
実行するなど、他のワークを実行する。割り込まれたプ
ロセスにおける次の命令が実行される前に、いくらか時
間があってもよい。この環境におけるいくつかのプロセ
スは、割込みに対して「使用禁止」されることができ
る。このようなプロセスは割り込まれず、シーケンスと
して最初から最後まで実行することになる。

「マルチプロセッシング」環境では、コンピュータは複
数のプロセッサから構成され、各プロセッサは、並行で
プログラムあるいはプロセスを実行することができる。
たとえば、プログラムが２つのプロセスを有する場合、
両者とも、マルチプロセッシング環境で同時に実行でき
る。マルチプロセッサ内の各プロセッサもマルチプログ
ラミングできる。

したがって、マルチプロセッシング環境では、プロセス
の活動は、他のプロセスの活動とともにインタリーブさ
れてもよい。だから、そのプロセスは他のプロセスと
「同時に」実行していると言われる。さらに、複数のプ
ロセスが同時に正確に実行できる。異なるプロセッサで
同時に実行するプロセスは、「並行」に実行していると
言われる。

直列化：同時に、すなわち並行に実行するプロセスは、
データを同時に、同じ記憶装置内に書き込むことができ
る。その結果、１つのプロセスは、他のプロセスが書き
込んだものを破壊することになる。この種のエラーを防
ぐため、そのようなプロセスは、プロセスを「直列」に
するために１つあるいは複数の「直列化機構」を使用し
なければならない。これらの機構は、いくつかは標準的
でかつ周知であり、シーケンスは実際には、いつでも割
込まれる可能性があるが、あたかもそれらが割り込まれ
ないシーケンスで達成されるように、プログラムが臨界
活動を完了できるようにする。また、それらは、それが
プログラムが資源へのアクセスを直列化でき、資源が一
度に唯１つのプロセスによって使われるようにすること
ができる。この目的のために、「固有の」直列化機構及
び、「外部からの」直列化機構を区別する。

固有の直列化機構は、IBM 370 Compare-and-Swap（C
S）、あるいは、Compare-Double-and-Swap（CDS）命令
などの「極小命令」のみを含む機構である。極小命令
は、分割できないことを保証するコンピュータ・ハード
ウェア命令である。そのような命令を実行するプロセス
は、それが、他のプロセスから妨害されずに命令を完了
できることが保証されている。たとえば比較及びスワッ
プ（Compare-and-Swap）は、プロセスが記憶装置のワー
ドを安全に更新できるようにする。命令は、プログラム
が、記憶装置内のワードの期待内容に注目し、命令実行
時に、記憶装置の期待内容が現行内容と一致する場合に
のみ、記憶が変えられることを要求できるようにする。
比較（Compare）及びスワップ（Swap）は、一度１つの
プロセスが「比較」を実行してしまうと、関連「スワッ
プ」が実行されるまで、他のプロセスは変更を実行でき
ないという意味で、分割できない活動である。これらの
命令並びにサンプル・コード化適用業務の説明は、「IB
Mシステム/370オペレーション拡張アーキテクチュア原
理（IBM System/370 Extended Architecture Principle
s of Operation（出版番号SA22-7085）に見ることがで
きる。

ラッチ：他のすべての直列化機構は「外来的」であると
言われる。その基礎的な２例は、「スピン・ラッチ」及
び「延期ラッチ」である。それらは、最初何らかの無意
味の値にセットされる単１の共用ラッチ変数を有するこ
とを含む。ラッチにより保護される活動を実行するため
に、まずプロセスはラッチ変数を非ゼロの値にうまくセ
ットすることにより、ラッチを「獲得」しなければなら
ない。ラッチ変数がすでに他のプロセスにより獲得され
ている場合は、要求プロセスは待たなければならない。

スピン・ラッチは、要求プロセス（及びプロセッサ）
が、それがラッチが「解放される」のを待っている時、
連続的に変数をテストする原因となるラッチである。こ
のテストが行なわれる間、プロセッサは「使用待ち」に
あると呼ばれ、他に何もすることはできない。この種の
ラッチは、それがプロセッサ時間を費やす時は、一般に
避けられるべきである。

他方、中断ラッチは、それがすでに保持されている場合
は、プロセスはラッチを使用待ちすることを要求しな
い。その代わりに、プロセスは「中断」し、ラッチが使
用可能になると、プロセッサが他のプロセスによって喚
起される（「再開される」）まで、プロセッサを放棄す
る。この方法はスピン・ラッチには好ましいが、それは
要求プロセスの中断と再開のトラックの保持に付随す
る、システム・オーバヘッドがあるために、注意深く使
用される。

マルチプロセッサ環境で動作する高性能プログラムにつ
いては、直列化機構の選択が重大になる可能性がある。
プログラム機能を、「メインライン」の機能とそうでな
い機能に分けることは有用である。メインラインの機能
はプログラムの本質であり、一方、非メインラインの機
能はメインライン活動を促進するか、または補足する補
助活動である。高性能プログラムでは、メインライン活
動は、典型的には繰り返して実行されるか、または時間
臨界性があり、そのため、CPU時間またはCPU資源から見
て高価な活動が避けられ、または非メインライン機能に
移動されることが必要である。一般に、メインラインの
外部直列化機構は高価であり、避けるべきである。

資源とバッファ：プログラムは、代表的には１つ、また
は複数の指定された反復機能を実行し、そして資源がこ
れらの機能を実行し、またはその関連目的を表示するこ
とを要求できる。プログラムは、そのような資源のため
に記憶装置を獲得することができ、その記憶装置をとも
ない。通常「資源プール」と呼ばれる所に集める。資源
プールを作る場合、多重処理環境内のプログラムは、プ
ール内の個々の資源へのアクセスを直列化できなければ
ならない。さらに、プログラムは普通動的にプールを
「拡張し」、さらに「短縮」する必要がある。すなわ
ち、プール内の資源の数を増減させる必要がある。

次の議論は、特定の例における資源プーリングの必要性
を述べ、また、プールの管理の際に生じるいくつかの論
点を議論する。プログラム（「受信側」）は、他のプロ
グラム（「送信側」）により生成されるデータを得る。
受信側は、送信側からのデータを保持するために、記憶
の一部を獲得することができる。この目的に使用される
コンピュータ記憶機構の各部分は、普通「バッファ」と
呼ばれ、その用語がその中で使われる資源の一型式であ
る。

データは、その到着時にバッファ内に置かれ、それが使
われるまでそこに保持される。受信側がバッファ内でデ
ータを使用すると、バッファは、処理用にさらにデータ
を受信できる。一度使われると、バッファは、新しいデ
ータを受信する際の再利用に役立つ。

データが処理できるよりも速く受信される場合、多くの
バッファが意外に早く獲得されることもある。プログラ
ムは通常、バッファを「バッファ・プール」すなわち資
源プールと呼ばれる論理構造の中に構成する。マルチプ
ロセッサ環境では、バッファ・プールは、プログラムに
属する任意のプロセスによって使用可能であり、そして
プログラムは、そのプロセスがバッファ・プール内でバ
ッファを使用する方法を制御しなければならない。通
常、プログラムは、２つのプロセスが同時に同じバッフ
ァを得るような方法で、バッファ・プールからバッファ
を「得たり」そして「解放したり」するための方法を、
プロセスに提供する。

バッファ・プール内バッファへのアクセスの制御に加え
て、またプログラムは、バッファ・プール内に含むバッ
ファの数も決定しなければならない。バッファ・プール
内にバッファがほとんど含まれていない場合は、プログ
ラムは、バッファを使い果たすことがある。プログラム
は、プログラムが使用を期待されているバッファの最大
値を決定することにより、この問題の回避を試みること
ができる。プログラムが、通常その数の僅かなパーセン
テージのみを使用する場合には、最大サイズのバッファ
・プールを割り当てることにより、プログラムは、他の
プログラムによって代わりに使用され得るコンピュータ
記憶装置を不必要に予約する。しかし、バッファ・プー
ルの最大期待サイズが非常に小さい場合は、プログラム
はバッファを使い果たす。

そのプロセスの１つが記憶すべきデータを有する時に、
プログラムがバッファを使い果たした場合は、プロセス
は正常に機能を果たすことができず、プログラムは直ち
に活動しなければならない。たとえば、プログラムは実
行を終了することがある。この「解決法」は、プログラ
ム実行の継続が会社や他の企業の操業に対して極めて重
大である大部分の場合に、受け入れることはできない。
代りに、プログラムはプロセスのデータを無駄にするこ
ともある。しかし、データが再生不可能である場合、ま
たは企業にとって非常に重大である場合、この解決法も
受け入れられない。

プログラムは、バッファが記憶用に使用可能になるまで
待つことができる。これは、他のプロセスが、記憶用バ
ッファを必要とするプロセスで、並行にバッファからデ
ータを用い、すぐに終了することが期待され、それを解
放する所で実行することができる。またこのアプローチ
がとられる場合、記憶用バッファを必要とするすべての
プロセスは、バッファからのデータを用いたプロセスが
終了するまで、待たなければならないことになる。しか
し、データを利用したこれらのプロセス自体が、記憶バ
ッファを待つプロセスによって活動を待っている場合、
プログラムは「行き詰まり」、仕事を継続できなくな
る。この理由で、他のプロセスを待って再利用のために
バッファを解放することは、受け入れられない。

IBM出版GC28-1154、「MVS/拡張アーキテクチュア監視サ
ービス及びマクロ命令（MVS/Extended Architectures S
upervisor Services and Macro Instructions）」は、
セル・プールの生成、割当て、拡張、及び削除を説明し
ている。セル・プールの短縮は説明していない。

1979年６月12日発行の、バローズ社（Burroughs Corpor
ation）に譲り受けられ、コール（Call）他の米国特許
第4158235号明細書、「マルチ・ポート時分割連想バッ
ファ記憶プール（Multi Port Time-shared Associative
Buffer Storage Pool）」は、バッファ・プールからの
バッファの動的割当てを記載しているが、プールの拡張
及び短縮をアドレスしていない。

1983年12月20日発行の、IBM社に譲り受けられたサッコ
（Sacco）他の米国特許第4422145号明細書は、「LRUピ
ージング・バッファ・プールを介したデータベースの要
求アクセスにおけるスラッシングの削減（Thrashing Pe
duction in Demand Accessing of a Data Base through
an LRV Paging Buffer Pool）」は、またバッファ・プ
ールの拡張または短縮をアドレスしないで、バッファを
割り当て、さらに利用する方法を記載している。

1988年２月23日発行の日立製作所に譲り受けられたマス
イ（Masui）他の米国特許第4727487号明細書「コンピュ
ータ・システムにおける資源割当て法（Resource Alloc
ation Method in a Computer System）」は、蓄積され
た経験的知識に基づく資源割当て法を記載している。マ
スイは、機械室内／動作環境での資源割当てを議論し、
（人間の）システム・オペレータによってのみ現在周知
のいくつかの知識を代替するための方法を、提案してい
る。第４コラム67行ないし、第５カラム２行は、そのよ
うな知識が、「数学的最適化あるいは線型プログラミン
グ用のモデルとして公式化するには、あまりに複雑で不
明瞭である」ということを述べている。

資源プール・マネジャのもう１つのクラスは外来的直列
化機構、典型的にラッチを用いて、１つのプロセスが、
一度に、資源プールが定義されているマネジャの制御領
域を参照または、修正することを保証する。この型式の
直列化は、プロセスが、他のプロセスに関係なく、制御
領域を参照できるようにし、したがって、プール短縮及
び同様な活動が、比較的簡単な方法で実行されるように
する。しかし、この代替アプローチは、外来的直列化機
構を用いたいくつかの欠点、特にスピン・ラッチによっ
てこうむるプロセッサ浪費時間、及び延期ラッチによる
追加命令オーバヘッドから被害を受ける。さらに、プロ
セスを矛盾する所では、プロセッサ命令コストは劇的に
増す。最後に、本質的に直列化（外来的及び固有の両方
共）は、コンピュータの性能を向上するためにますます
使用されつつある並行プロセッシングの利用を禁じてい
る。

C.発明が解決しようとする課題したがって、資源プールを劇的に拡張し、さらに短縮す
るための方法を必要とする。この方法は、多重処理シス
テム内で同時に実行するプロセスの資源の要件に合致し
なればならず、さらに直列化の利用を最小限にしなけれ
ばならない。

D.課題を解決するための手段資源プールを動的に、すなわち資源に対する要求に応じ
て、拡張及び短縮するための方法が開示されている。資
源は、１つのマスタ・プール22から使用するために割り
当てられる。利用可能な資源のすべてのプールは、拡張
プールを生成することにより、さらにその資源をマスタ
・プールに追加することにより拡張される。マスタ・プ
ールは、システム内で利用可能な資源の数の限界まで理
論的に拡張することができる。

プールを動的に短縮するために、まず拡張プールの１つ
を選んで解放する（FREE POOL 66）。解放プールが所有
するが、まだマスタ・プールにある（すなわち使用中で
ない）これらの資源は、拡張プール移動され、それらの
再利用を防ぐ。解放プールが所有する使用中の資源は、
それらが、マスタ・プールへの代わりに、拡張プールへ
戻るように、それらのホーム・アドレス52を変えてラベ
ル付けされる。一度そのようなすべての資源が解放拡張
プールに戻されると、それは削除され、それによって、
資源のすべてのプールを短縮する。

記憶バッファ及びバッファ・プールを操作するための手
順の擬似コード実施例が含まれる。

E.実施例本発明は、コンピュータ利用データ処理システムにおけ
る離散的資源のマスタ・プールを拡張・短縮するための
コンピュータ実施方法を含む。マスタ・プールは少なく
とも１つの追加資源を含む拡張プールを作成し、さら
に、マスタ・プールに拡張プール資源を追加することに
より拡張される。マスタ・プールは、拡張プールで生ず
る任意の本割当て資源をマスタ・プールから、拡張プー
ルへまず転送することにより短縮される。次に拡張プー
ル内で生ずる資源は、（それらがもはや使用されていな
い時のように）割当て解除されると、これらの資源は、
拡張プールに転送される。拡張プールが、その中で生じ
る資源のすべてを含む時、すなわち、その資源のどれも
割り当てられないままか、使用されていない時、それは
削除できる。資源プールの短縮は、外来的または他の直
列化を用いる方法が効果的に使用できても、極小命令に
よるように、固有に直列化されることが好ましい。

概観本発明の好ましい実施例は、マルチプログラミングまた
はマルチプロセッシング環境で資源のプールを処理する
ための、プログラムにより使用される方法である。これ
は、資源のメインライン使用を非能率にすることなく、
さらに他のラッチ、またはメインライン内の他の外来的
直列化機構の使用を必要とすることなく、資源プールを
拡大・短縮する。したがって、この方法は、能率的に操
作できるべき高性能プログラムによって、さらに割込み
禁止のモードで実行中（すなわち、それらが割り込まれ
ない時）に資源を得て、解放できるべきプログラムによ
って、使用可能である。

資源がバッファである所では、ほとんどのプログラム
は、大きな記憶装置をとり、それをバッファに細別する
ことにより、バッファ・プールの記憶装置を獲得するコ
ストを（実行される時間と実行される命令の数に関し
て）低減させる。これは、バッファ・プール中の各バッ
ファに対して個別システム・コールを行なうより安価で
あり、バッファ・プールを初めに作成するためと、プー
ルを後で拡張するための両方に使用される。

プログラムがシステムから記憶の１部分を得る場合、部
分的な記憶の解放、実行される時間と、命令の両方で高
価になるため、その部分全部を一度に戻すべきである。
さらに、少しずつの記憶の解放は、システムの記憶が断
片的になる原因となる。

最後に、プログラムは、プロセスがその記憶装置内のど
のバッファも使っていない場合だけ、バッファ記憶を解
放することに注意しなければならない。これは、すべて
に解放された記憶を使用するためのプロセスによる試み
が、プロセスを異常に終わらせたり、エラー状態をひき
起こす可能性があるからである。

第１図に示すように、バッファ・プール20は、マスタ・
プール22、及びいつでもマスタ・プールに追加できる拡
張プールのセット24の中に準備される。マスタ・プール
22は、ラベル付きボックスのセット（バッファなどの資
源）を含むトレイとして考えてよい。各拡張プール24
は、ラベル付きボックスの追加トレイとして考えてよ
い。資源プールは、拡張トレイを作成しマスタ・トレイ
上にそのすべての箱を積み重ねることにより拡張され
る。

各ボックスは、それをどのトレイが所有し、そしてその
使用が終わった後、マスタ・トレイに戻されるべきこと
を示すために、ラベル付けされる。すべてのボックス
は、マスタ・トレイ内にきちんと積み重ねられ、そこで
主プログラムのプロセスはそれらを取り、使用すること
ができる。マスタ・トレイ内のボックスは、追加に適応
するのに必要な高さまで積み重ねることができる。

ボックスを必要とするプロセスは、マスタ・トレイから
それを得て、直ちにそれを使用できる。

ボックスは、他のプロセスがそれらを再使用できる前
に、（空いた）マスタ・トレイに戻されなければならな
い。このために、ボックスを使用していたプロセスは、
ボックスの上のラベルを読み、ラベルが何を表すかに基
づいて、ボックスをその正しいトレイに戻す。

マスタ・トレイが、主プログラムのプロセスが必要とす
るより多くのボックスを保持する時は、資源プールは、
除去（解除）のために、拡張トレイの１つを選択するこ
とにより、（その瞬間に）動的に減少（短縮）される。
そのトレイが所有するすべてのボックスは、たとえそれ
らのいくつかが使用されていても、再びラベル付けされ
る。それからマスタ・トレイは、除去（解放）されてい
る拡張トレイが所有するボックスのために探査され、そ
してどれかが見つかった場合は、それらは拡張トレイの
上に積み重ねられる。そのトレイのボックスのどれかが
まだ使用されている場合は、それらの新しいラベルは、
それらが終える時、それらを拡張トレイに戻すよう該当
プロセスに知らせることになる。

除去のために選択された拡張トレイが、一度そのボック
スのすべてを含むと、それとすべてのそのボックスは削
除され、それによって資源プール内のボックス（資源）
の数を減ずる。

資源プールを力学的に拡大、短縮するための操作が準備
されるので本方法は、資源プールのサイズを変更するた
めに、主プログラムが停止されたりリセットされること
を要求する他の資源管理技術の限界と非能率性を防ぐ。
本方法は、期待される、あるいは普通の処理要件に基づ
く初期の資源プール・サイズを割り当て、さらに追加資
源を動的に割当て、不要の資源を割当て解除することに
より、条件変更に適合する。

最も重要なことは、本方法は、メインライン処理に影響
することなく、マルチプログラミング及びマルチプロセ
ッシング環境内で資源プールを短縮することである。こ
れは取得及び解放操作時に、外来的直列化機構を避ける
ことにより実行され、それによって、メインライン論理
通路内の使用中待ち及び延期の費用を避ける。この結
果、本方法は非常に能率的であり、割込み禁止されたプ
ロセスで使用することもできる。

また、本方法を用いたプログラムが資源を使い果すこと
もある。たとえば、それは、コンピュータで使用できる
よりも多くの資源を用いることがあり、またどれだけの
追加資源が必要であるかを誤算することもある。そのよ
うな状態は例外として取り扱うべきで、本方法の範囲外
である。

さらに、本方法は、共用設備の不公平な利用により生じ
る資源不足の問題を提出しない。たとえば、データを他
のプログラムに送るプログラムは、レシーバのバッファ
・プールをオーバーランすることもある。そのような状
態は、過剰制御方法を用いて処理されなければならず、
これも本発明の範囲外にある。

バッファ、及び、バッファ・プールにおける基礎的動作本発明の好ましい実施例は、バッファプール及び個々の
バッファを操作するための動作を提供する。しかし本発
明は、均一な資源のどんなセットにも適用できることを
理解されたい。

次の第１項は、バッファ・プールのための適当な構成を
述べている。これは、バッファとプールにおける動作を
説明する項目が続く。BUILD POOLは、システムから物理
的資源を獲得することにより、バッファの拡張プールを
作成し、それによって、資源プール全体を拡張する。GE
T BUFFERは、要求するプロセスにより使用するために、
プールから単一のバッファを要求する。FREE BUFFER
は、前のGET BUFFER要求で得られた単一の特定バッファ
をバッファ・プールに戻す。FREE POOLは、バッファの
拡張プールを解放し、それらのいくつかはまだ、使用中
の場合もある。DELETE POOLは、一度そのバッファのす
べてが解放され、そのプールに戻されると、一度解放さ
れた拡張プールを削除し、それによって資源プール全体
を短縮する。

個々のバッファを獲得したり、解放したりするGET BUFF
ER及びFREE BUFFERの動作は、メインライン動作であ
る。すべてがバッファ・プール上で動作する残りの動作
は、メインラインではない。

バッファ・プールの編成バッファ・プールには２つの型式がある。すなわち、マ
スタ・プール22と拡張プール24である。型式に関係な
く、各バッファ・プールは３つの要素を有する。すなわ
ち、プール制御要素、１つまたは複数のバッファ、及び
各バッファ用のバッファ制御要素である。１つのバッフ
ァは、一度に２つのバッファ・プールつまりその所有者
のプール及びそのホーム・プールに関連し、そして２つ
の状態つまり使用中及び解放中であることができる。

第２図に示すように、各バッファ・プール26は、型式に
関係なく、３つの要素、すなわち１つの「プール制御要
素」28、１つまたは複数のバッファ30、及び各バッファ
用の「バッファ制御要素」32を有する。バッファ30の
数、つまりバッファ制御要素32の数は、バッファ・プー
ル26が割り当てられる時、特定される。各バッファ30
は、そのプールのプール制御要素28により「所有され
る」と言われる。所与のプール26が所有するすべてのバ
ッファ制御要素32は、一連の「所有されたバッファ・リ
スト」34上にリストされている。したがって、プールの
バッファ制御要素32は、常にそのプール制御要素28から
位置決めできる。後で分かるように、各バッファ制御要
素32は、「ホーム」と呼ぶあるプール制御要素28のアド
レスも含む。バッファ用のこのホーム・アドレスは、そ
の所有バッファ・プール26である場合もあり、ない場合
もある。

作成された第１バッファ・プール26は、マスタ・バッフ
ァ・プール22であり、そのプール制御要素28は、「マス
タ・プール制御要素」36として周知である。主プログラ
ムが、追加バッファを必要とする場合は、それはBUILD
POOL動作を実行することにより「拡張バッファ・プー
ル」を作成できる。拡張バッファ・プール24のプール制
御要素28は、マスタ・プール制御要素36上に固定された
一連の「拡張プール・リスト」38の中に編成される。

拡張バッファ用のホームは、通常はマスタ・バッファ・
プール22である。これは、マスタ・プール22内で利用可
能なバッファ30の数を増加させることにより、バッファ
・プール20を拡張する効果があり、マスタ・プール22か
らバッファがそれらを使う必要のあるプロセスにより取
られ、戻される。拡張プール24が解放される時、そのバ
ッファ30のホーム・アドレスは、マスタ・プール22から
解放された拡張プール24へ、すなわちバッファ所有のバ
ッファ・プールへ変更される。

プロセスにより使用されていないバッファ30は、マスタ
・プール22内に保持され、「解放」状態にあると考えら
れる。これらの解放バッファは、マスタ・プール22また
は拡張プール24のどちらかによって所有されるが、すべ
てはマスタ・プールをそれらのホーム・アドレスとして
維持する。解放バッファの制御要素32は、マスタ・プー
ル制御要素36上にある一連の解放バッファ・リスト40内
に保持される。各拡張プール24は、同様に、連なった解
放バッファ・リスト42を有するが、それは空でありプー
ルがFREE POOL動作により解放されるまで、そのまま留
まる。

プロセスがバッファ30を必要とする時、それはGEL BUFF
ER動作60を実行し、GET BUFFER動作60は、第１バッファ
制御要素32を、マスタ・プールの解放バッファ・リスト
40から除去し、関連バッファ30を要求プロセスに利用可
能にする。したがって関連バッファは「使用中」と言わ
れる。

プロセスがバッファ30で終了される時、FREE BUFFER動
作64は、関連したバッファ制御要素32を、バッファのホ
ーム・プールに属する解放バッファ・リスト上に再待合
せするために使用される。通常、バッファはマスタの解
放バッファ・リスト40に戻される。しかしながら、バッ
ファの所有プールが、解放された拡張プール24である場
合は、バッファのホーム・アドレスは変更され、バッフ
ァはマスタ・プール22への代わりに、その解放された拡
張プール24の解放バッファ・リスト42へ戻される。した
がって、その解放された拡張プールのバッファのすべて
が、一度その自由バッファ・リスト42に戻されると、プ
ール24は、物理的にDELETE POOL動作によって解放する
ことができ、それによってバッファ・プール20全体を短
縮する。

第３図は、プール制御要素28及びバッファ制御要素32の
データ構造を示す。これは、本発明を使用にするために
は必要ないが、マスタ・プール22及び拡張プール24の両
方のプール制御要素に、同じフォーマットが使用され
る。

本方法のバッファの編成及びデータ構造を述べたが、次
の項では、これらの構造について実行された動作を詳細
にそして本方法のメインライン動作内でラッチを必要と
せずに、動的にいかに実行できるかについて、言及す
る。

バッファ・プールの作成−BUILD POOL58a、58b バッファ・プールは、BUILD POOL動作58a、58bにより、
作成（構成）され、その動作は、どのバッファが使用さ
れる前でも、主プログラムにより要求されなければなら
ない。同じ動作（BUILD POOL）が、マスタ・プール22及
び拡張プール24の両方を作成するために使用され、それ
らの構造のわずかの違いは、BUILD POOL内で処理され
る。BUILD POOL58a、58b、及びFREE POOL66の両方は、
まれな動作であると想定され、したがってメインライン
機能ではない。

マスタ・プール22は、任意の拡張プール24が作成される
前にも作成される。それは、BUILD POOL要求内で識別さ
れなければならず、一度作成されると、FREE POOL動作
によっては決して除去されない。マスタ・プール22は、
すべてのバッファ及びバッファ・プール処理のためのア
ンカーとして役立つ。

マスタ・プール22が作成される時、記憶機構が割り当て
られ、マスタ・プール制御要素POOL CTL36、バッファ制
御要素BUF CTL32、及びバッファ30のためにフォーマッ
トされる。個々のバッファ制御要素DUF CTL32は、各バ
ッファ制御要素BUF CTL32のNEXT FREEフィールド44を用
いたマスタ解放バッファ・リスト40の中に共に連鎖され
ている。このリスト40のヘッドは、マスタ・プール制御
要素36のFREE・FIRST FREEフィールド46内に記憶され
る。初期にはゼロである使用中バッファの数は、マスタ
・プール制御要素36のFREE.BUSY CTフィールド内に記憶
される。

マスタ・プール22が所有するバッファのリストは、マス
タ・プール解放バッファ・リスト40に対し、同様に作成
される。所有されたバッファ・リスト34は、マスタ・プ
ール制御要素36のFIRST OWNEDフィールド50内に記憶さ
れているリスト・ヘッドで、プールのバッファ制御要素
BUF CTL32のNEXT OWNEDフィールド48を用いて連鎖され
ている。

各バッファのホーム・アドレスは、バッファの制御要素
BUF CTL32のHOME POOLフィールド52内に記憶され、前記
のように、初期にはマスタ・プール制御要素36のアドレ
スにセットされる。各バッファ制御要素32のBUFFER ADD
Rフィールド54は、要素の関連バッファ30のアドレスに
セットされる。

最後に、マスタ・プール制御要素36のアドレスは、バッ
ファ・プールまたは、バッファ上の操作によって使用す
るために、ANCHOR.MASTERフィールド内に記憶される。

BUILD POOLが拡張バッファ・プールを作成するために要
求されると、データ構造は、マスタ・プール制御要素36
について述べたものと同様に作成される。しかし、バッ
ファ制御要素32が、プールの解放バッファ・リスト42を
形成するために連結された後で、そのリストは単一の極
小操作で、Compare-Double-and-Swap命令を用いたマス
タ・プール制御要素の解放バッファ・リスト40に転送さ
れる。

バッファ制御要素32のHOME POOLフィールド内に再び記
憶されたこれらの拡張プール24のバッファに対するホー
ム・アドレスは、マスタ・プール制御要素36のアドレス
にセットされる。拡張プールの使用中カウントBUSY CT
は、プール内のバッファの数にセットされ、プールのバ
ッファのどれも解放されていないことを表示する（前述
の拡張プールの再解放及び削除参照）。

拡張プール制御要素28は、拡張プール・リスト38のヘッ
ドに追加される。このリストは、拡張プール制御要素28
のNEXT POOLフィールド56を介して連鎖され、そのヘッ
ドは、マスタ・プール制御要素36のNEXT POOL内に配置
される。

BUILD POOL動作は、極小命令を用いて、それを他の並行
（同時）BUILD POOL及びFREE POOLプロセスから保護す
るために直列化されてもよい。これらの操作は稀で、非
メインラインであるから、ラッチのような外来的直列化
のどんな型式でも使用することができ、また使用される
型式は、設計選択の問題である。

拡張所有のバッファ・リストは、マスタ・プール22のバ
ッファのために、前記のように作成される。これは、た
とえバッファのいくつかがマスタの解放バッファ・リス
ト22から除去されても、拡張プールの構成要素のすべて
を、そのプール制御要素28から直接位置決めする方法を
提供する。

要するに、BUILD POOL動作は、マスタ・プール制御要素
36がプール処理用の固定具として役立つ、バッファ・プ
ール26を作成する。マスタ・プール制御要素36は、バッ
ファ・サービスがプログラムによって必要とされる限
り、削除されない。バッファ・サービスを使用するプロ
セスは、そのようなプロセスが拡張プールを直接引用し
ないので、同時に削除されているバッファ・プールをア
ドレスする試みに関係する必要は決してない。

BULID POOL58a、58b用の擬似コード：第2A表及び第2B表は、BUILD POOL手段58a、58bの実施を
従来の擬似コードで示す。

400-404行で、記憶はシステムから獲得され、副次的に
割り当てられる。これらの記憶領域は、２進法の０に初
期化されると仮定する。それから、各バッファ制御要素
BUF CTL32が、フォーマットされる（405-416行）。

バッファは各BUF CTL要素（407行）に割り当てられ、各
BUF CTL要素用のホーム・プールはマスタ・プール制御
要素POOL CTL36にセットされる。（407-410行）。411-4
15行で、プール所有のバッファ・リスト34及び解放バッ
ファ・リスト42が形成される。417行で、所有のバッフ
ァ・リスト34は、POOL CTL要素に連鎖される。

マスタ・プール22が、（拡張プールではなく）BUILD PO
OL動作を要求された場合は、418-427行が実行される。
まず、新しいプール解放バッファ・リスト42が、420行
によりマスタの解放バッファ・リスト40に追加される。
これは、他のプロセスがプール構造にまだアクセスして
いないので、非極小的に実施される。そしてマスタ・プ
ール制御要素POOL CTL36の位置は、すべてのバッファ・
プール構造を固定するANCHOR.MASTERフィールド内に極
小的に置かれる。動作が成功した場合、バッファは、バ
ッファ・サービスを必要とする他のプロセスに利用可能
である。BUILD POOL要求は、他の同時すなわち並列のプ
ロセスが、すでにアンカー内のそのマスタ・プール制御
要素POOL CTL36の位置（422-426行）をとった場合は、
失敗である。この極小動作は、IBM 370 Compare-and-Sw
ap命令などの極小命令を用いて完了することができる。
この命令の説明並びにコード化適用業務の例は、IBMシ
ステム 370オペレーション拡張アーキテクチュア原理
（出版番号SA22-7085）内に見ることができる。

拡張プールが要求された場合、428-433行は、418-427行
の代りに実行される。まず、拡張の全解放バッファ・リ
スト42は、マスタ・プールの解放バッファ・リスト40
（430行；後の第11a表を参照（1321行）に極小的に追加
され、拡張の解放バッファ・リスト42を空にする（431
行）。この動作は、拡張のバッファを他のプロセスに利
用可能にする。拡張プール制御要素28のBUSY CYフィー
ルドは、拡張プールが静止される時、すなわちそのバッ
ファのすべてが解放されて、プールが削除できるように
なる時を決定するために、FREE POOL動作（後記の第５
表）により使用される。最後に、拡張プールは、マスタ
の拡張プール・リスト（432行）に極小的に追加され
る。この極小動作は、第８表（1005行）で説明される。
434行は、成功した完了状態をBUILD POOL手順58を始め
たリクエスタに戻す。

バッファの獲得と解放−GET BUFFER60、及びFREE BUFFE
R64 ２つのメインライン動作は、GET BUFFER60及びFREE BUF
FER64である。本発明で、これらの動作は、延期、使用
中待ち、あるいは、デッドロックを生ずるラッチなどの
より高価な外来的直列化機構に依らないで、極小命令を
用いて直列化できる。

プロセスがバッファを要求する時、それは、GET BUFFER
手順60を実行するための要求を発する。GET BUFFERは、
マスタ解放バッファ・リスト40のヘッドでバッファ制御
要素BUF CTL32を選択する。すなわち、そのアドレス
は、マスタ・プール制御要素36のFREE.FIRST FREEフィ
ールド46内に記憶される。バッファ制御要素32は、リス
トから除かれ、リストの使用中カウント、POOL CTL.FRE
E.BUSY CTは、１だけ増分される。

GET BUFFER手順60が完了すると、要求プロセスは、バッ
ファ30に対するバッファ制御要素BUF CTL32のアドレス
である「トークン」を与えられる。要求プロセスは、こ
のトークンによって、バッファ制御要素BUF CTL32のBUF
FER ADDRフィールド内で識別されるバッファ30へのアク
セスを得る。

多重プロセスの直列化に使用され、禁止された割込みに
よるその実行を含み、並行してバッファを得るために探
索するラッチはない。代わりに、マスタ解放バッファ・
リスト40に関する単一Compare-Double-and-Swap動作
は、マスタ・プール制御要素のFREE.FIRST FREEフィー
ルド46内で識別されるヘッド要素を、安全に除去される
ようにするには十分である。

バッファの「ストップオーバ・リスト」も、GET BUFFER
64がバッファ超過エラー・メッセージを要求プロセスに
戻す前に、チェックされる。これは、FREE POOL動作66
（後で詳述する）がGET BUFFER要求で同時に進行中であ
るため、バッファ・プール20自体は空ではないが、マス
タ解放バッファ・リスト40が空になるからである。スト
ップオーバ・リストは、マスタ・プール制御要素36のST
OPOVERフィールド62内に固定された（前記解放バッファ
・リスト40、42のような）連鎖リストである。FREE POO
Lプロセスは、マスタの解放リストから拡張のバッファ
のすべてを除去しようとし、ストップオーバ・リスト
は、このプロセス中に除去される他のバッファのための
保持領域である。このリストはGET BUFFER機能に利用可
能であるから、ストップオーバ・リストは、FREE POOL
処理が原因で、誤ったバッファ超過条件を報告する可能
性を事実上排除する装置である。（実際に、このケース
は、解放リスト上に１つのバッファが確かに残っている
場合に発生し、GET BUFFER要求は、それが１つのリスト
から除去された後、そしてそれがストップオーバ・リス
ト上に置かれる前に、解放バッファをチェックする。）
マスタ解放バッファ・リスト40が空の場合は、GET BUFF
ERは、STOPOVERフィールド62をチェックする。ストップ
オーバ62が空でない場合（ストップオーバ・リスト内に
バッファがあることを表示する）は、GET BUFFERは、ス
トップオーバ・リスト上の第１バッファを除去し、その
トークンを要求プロセスに戻す。また、マスタ解放バッ
ファ・リスト40及びストップオーバ・リストの両方が空
の場合は、バッファ・プール20は、実際バッファ30の外
にあり、「バッファ超過」エラー条件の信号を発する。
GET BUFFERが、バッファ・プール20がバッファの外にあ
ることを誤って報告することはあり得るが、極めて稀で
ある。

プロセスが、バッファ30がバッファ・プール20に戻るこ
とを望むと、FREE BUFFER手順64を実行し、バッファに
関したトークン（前記の）を指定しなければならない。
FREE BUFFERは、バッファ制御要素32をバッファのホー
ム・プールの解放バッファ・リストのヘッドに追加し、
プールの解放バッファ使用中カウントFREE.BUSY CTを１
だけ減分する。特に、トークンにより識別されたバッフ
ァ制御要素BUF CTL32のアドレスは、バッファ制御要素
のHOME POOLフィールド52により指定されるプール（マ
スタ22あるいは拡張24）のプール制御要素28のFREE.FIR
ST FREEフィールド46内に置かれる。

Compare-Double-and-Swapなどの単一の極小動作は、GET
BUFFER手順60に対し、前記のように、このメインライ
ンFREE BUFFER手順64を直列化するのに十分である。ラ
ッチのような外来的直列化は、必要とされない。このCo
mpare-Double-and-Swap固有直列化は、メインラインGET
BUFFER及びFREE BUFFER動作を速め、能率的にする。さ
らに、GET BUFFER及びFREE BUFFERは、ラッチなしで動
的バッファ・プール拡張及び短縮を支援し、この能力の
ための唯一のコストは、マスタ解放バッファ・リスト40
が空のように見える時、ストップオーバ・リストのSTOP
OVERフィールド62をチェックすることである。ほとんど
の場合、この方法は、追加命令をバッファ・サービスを
用いるメインライン・プロセスに加えない。

GET BUFFER60用の擬似コード：第３表は、従来の擬似コード内のGET BUFFER手順60の実
施例を示す。

500行で、マスタ・プール22のアドレスが得られる。マ
スタ・プールは、いくつかのプロセスがバッファ・サー
ビスを必要とする限り、決して削除されないのでこれは
安全な基準である。

マスタ解放バッファ・リスト40の第１バッファ制御要素
BUF CTL32が極小的に除去され、使用中カウントが501行
で増分され、それは第12A表及び第12B表に示すRE-MOVE
BUFFER AND COUNT手順を呼び出す。正規には、バッファ
はマスタ解放バッファ・リスト40上にあるべきであるか
ら、501行は、GET BUFFER手順60の標準実行経路と考え
られる。成功した完了状態は、割り当てられるバッファ
の制御要素BUF CTL32（503行）の位置決め（トークン）
と共に要求プロセスに戻される。

マスタ解放バッファ・リスト40が空である場合（504
行）、GET BUFFERは、ストップオーバ・リスト（506
行）のSTOPOVERフィールド62からバッファ制御要素BUF
CTL32を除去することを試み、再び、第12A表及び第12B
表のRE-MOVE BUFFER AND COUNT手順66を用いる。これ
は、バッファ・プール20が真にバッファの外にある時、
あるいは、FREE POOL動作が、すべてバッファをストッ
プオーバ・リストにフラッシュした時にのみまれに起こ
る。FREE POOL動作が進行中で、バッファがストップオ
ーバ・リストから要求プロセスに割当て可能である場
合、そのバッファの制御要素BUF CTL32に対するトーク
ン、及び成功した完了状態コードは、リクエスタ（508
行）に戻される。

またストップオーバ・リストが空の場合（509行）、GET
BUFFERは要求プロセスに、バッファは現在利用できな
い（510行）ことを表示する。

FREE BUFFER64用の擬似コード：第４表は、従来の擬似コード内のFREE BUFFER手順64の
実施例を示す。

600行で、解放されているバッファ30のホーム・プール
のプール制御要素POOL CTL28は、バッファ制御要素BUF
CTL32のHOME POOLフィールド52から得られる。バッファ
30が、FREE POOL動作66で解放されているプロセス中に
ある拡張プール24に関連する場合、600行によって得ら
れるPOOL CTL要素28はバッファを有する拡張プールの要
素である。バッファ所有のプールが解放されていない場
合、そのホーム・プールはマスタ・プール22であり、マ
スタ・プール制御要素POOL CTL36は600行により得られ
る。

601行で、BUF CTL要素32は、バッファのホーム・プール
の解放バッファ・リストのヘッド（FREE.FIRST FREE4
6）に極小的に置かれ、ホーム・プールの解放バッファ
使用中カウントFREE.BUSY CYは、１だけ減分される。こ
の処理は、第11A表及び第11B表に示すADD BUFFER AND C
OUNTにより行なわれ、後述する。

解放された拡張プール24が所有するバッファ30は、拡張
の代わりにマスタ・プール22に戻されてもよい。これ
は、バッファが戻されるPOOL CTL要素28、36に決定した
後、FREE BUFFER動作64が割り込まれる（一時的に延期
される）場合、発生可能である。次にFREE POOL動作66
が実行される場合、FREE POOLはPOOL CTL要素を解放す
る。次に、FREE BUFFER動作が再開される時、それはバ
ッファをマスタ解放バッファ・リスト40に戻す。そのバ
ッファがマスタ・リスト40から除去されない場合、それ
は、それを所有した解除された拡張プール24が削除され
るのを防ぐ。このありそうもない発生は、第７表のDELE
TE POOL手順の916-920行により処理される。

Buffer Poolの解放−FREE POOL66 プログラムが、動的に拡張されたバッファ・プール20に
追加されたバッファのいくつかの使用をもはや要求しな
い場合、それはプールを短縮するためにFREE POOL手順6
6を用いる。FREE POOL動作66は、そのプールが所有する
バッファ30が、要求が出された時に他のプロセスによっ
て使用中であっても、拡張バッファ・プール24の削除を
生じる結果となる潜在的な２つの段階のプロセスを開始
する。

動的バッファ・プール短縮の第１段階で、FREE POOL手
順66は、最も最近作成された拡張プール24を選択し、そ
のバッファ30をさらにGET BUFFER要求に対して利用でき
なくする。解放されたバッファ・プールに属するバッフ
ァが他のプロセスによって使用中でない場合は、プール
は直ちに削除される。さもなければ、FREE POOL動作66
は終了し、解放された拡張プール24の削除を第２段階に
残す。

第２段階では、一度そのバッファ30のすべてがそれらを
使っていたプロセスにより解放されると、DELETE POOL
手順68は解放された拡張プール24を削除する。DELETE P
OOLは、第７表を参照して後述する。

FREE POOL68は、マスタ拡張プール・リスト38から第１
拡張プール24を除去する。その拡張プールは、マスタ・
プール制御要素POOL CTL36のNEXT POOLフィールド56で
識別される。解放されているプール24の個々のバッファ
制御要素BUF CTL32は、プール所有のバッファリスト34
を用いて識別され、そのリストはプールの制御要素POOL
CTL36のFIRST OWNEDフィールド50内に固定される。

各バッファ制御要素BUF CTL32のホーム・プール、HOME
POOL52のアドレスは、マスタ・プール制御要素36から解
放される拡張プールのプール制御要素POOL CTL28に変更
される。FREE BUFFER要求により解放されたバッファ
は、拡張プールの解放バッファ・リスト42に戻されるこ
とになり（第４表の600行参照）、一度そこに置かれる
と、それらはもはやGET BUFFER要求にアクセスできな
い。そのバッファのすべてが、その解放バッファ・リス
ト42に戻されると、拡張プール24は、それ自身「静止」
していると言われ、同時実行のプロセスに影響すること
なく、安全に削除できる。この削除は、FREE POOL66の7
07-709a行により、あるいはDELETE POOL手順68により直
ちに行なわれる。

解放されたプール24が所有するバッファ30のいくつか
は、FREE POOL操作66が実行される時、プロセスによっ
て使用中であることができる。これらのバッファは、そ
れらがFREE BUFFER手順により解放される時（第４表の6
01行）、拡張プール24に戻される。拡張の残りのバッフ
ァはマスタ解放バッファ・リスト40上にあり、正規に
は、それらが他のプロセスにより取られ、使用され、解
放されるまで、解放されたtaプール24に戻されない。

それらの正規の処理のコースで、これらの残りのバッフ
ァを取ったり解放したりするために、他のプロセスに頼
るよりもむしろ、FLUSH MASTER POOL手順70a、70bは、
解放されたプール24が、マスタ・プールの未使用バッフ
ァを「フラッシュ」することにより静止することを確証
する。FLUSH MASTER POOL70a、70bは、バッファをマス
タ解放バッファ・リスト40からマスタのストップオーバ
・リスト上に転送し、そこから、解放されたプールの解
放バッファ・リスト42、またはマスタ解放バッファ・リ
スト40に戻す。FLUSH MASTER POOL70a、70bは、Compare
-Double-and-Swap命令のみを用い、外来的直列化を避け
る。

マスタ・プール22のフラッシュにおける第１段階は、Co
mpare-Double-and-Swap論理回路を用いて、マスタ解放
バッファ・リスト40のヘッドにてバッファ制御要素UF C
TL32を除去し、さらにマスタ・プールの使用中カウン
ト、FREE.BUSY CTを１だけ増分する。第２に、バッファ
のホーム・プールが解放されている拡張プール24である
場合、バッファ制御要素BUF CTL32は、解放された拡張
の解放バッファ・リスト42のヘッドに（再びCompare-Do
uble-and-Swapを用いて）加えられ、その拡張プールの
使用中カウント、FREE.BUSY CTは、１だけ減分される。
しかし、そのバッファのホームがマスタ・プール22であ
る場合、そのバッファ制御要素BUF CTL32は、STOPOVER.
BUSY CTを変えることなく、Compare-Double-and-Swapを
用いたマスタ・プールのストップオーバ・リストのヘッ
ドに（すなわちSTOPOVER.FIRST FREEフィールド62に）
加えられる。

これらの３つの段階は、解放された拡張プールの使用中
カウントがゼロ（０）になるまで、あるいは、マスタ解
放バッファ・リスト40が空になるまで繰り返される。次
に、マスタのストップオーバ・リスト上のバッファはマ
スタ解放バッファ・リスト40に戻され、それらは使用の
ためにプロセスに割当て可能である。しかし、リスト全
体を除去することは短い間隔（ウィンドウ）を作ること
になり、この間にバッファ・プール20が、本当は空では
ない時に空のように見えることがあるため、ストップオ
ーバ・リスト上のバッファを一度に全部戻すことはでき
ない。その代わり、ストップオーバ・リストのバッファ
は、一度に１つ戻されCompare-Double-and-Swap論理回
路により直列化される。また、ある追加の簿記が、マス
タ・プールの使用中カウントBUSY CTがプロセスに割り
当てられたバッファの数を正確に反映することを確証す
る必要がある。

そのバッファ30がすべて戻された場合には、解放された
拡張プール24は、動的短縮の第１段階中にFREE POOL66
により直ちに削除され、第２段階は必要ではない。そう
でなければ、解放されたプールの制御要素POOL CTL28
は、解放されたプール・リスト72のヘッド（固定構造内
のFREEDフィールド74）に追加され、プール24は静止で
きる。先に解放されたプールのための他のFREE POOLプ
ロセスまたは、並行のDELETE POOLプロセスが進行中で
あるので、プール制御要素POOL CTL28の解放されたプー
ル・リスト72への追加は、（つまり極小命令によって）
直列化されなければならない。

解放されたプール・リスト72は、まだ物理的に削除でき
ない解放された拡大プール24のトラックを保持し、FREE
POOL操作66がいつでも実行できるようにする。解放さ
れたプール24からのバッファ30をすでに使用しているプ
ロセスは、そのバッファのプールに関連した物理的記憶
装置が、プール関連のすべてのバッファが解放されるま
で解放することはできないので、妨害されないでそれを
続けることができる。

FLUSH MASTER POOL70a、70b操作は、それが２つの並行
なプロセスにより同時に実行されることを防ぐために直
列化される。これが行なわれない場合、１つのFLUSH MA
STER POOLプロセスは、マスタ解放バッファ・リスト40
からバッファを除去し、ストップオーバ・リスト上にそ
れらを置くことができ、一方で、他のFREE BUFFERプロ
セスは、他の方向に（ストップオーバ・リストから、マ
スタ解放バッファ・リスト40へ）バッファを戻す。この
発生の見込みは非常に少ないが、それは、２つのプロセ
スが命令の永久のシーケンス、すなわち「無限のルー
プ」にインターロックされる原因となる。本方法では、
この可能性は、ラッチ（FREE POOLラッチ）を用いて、
バッファをマスタ・プールの解放バッファ・リスト40と
ストップオーバ・リストの間で移動する論理回路を保護
することにより除去される。

FREE POOL66用の擬似コード：第５表は、従来の擬似コード内のFREE POOL手順66の実
施例を示す。

700行で、第１拡張プール制御要素POOL CTL28は、マス
タ・プールの拡張プールリスト38（NEXT EXT）から除去
される。同時BUILD POOLまたは、FREE POOL動作が、拡
張プール・リスト38を処理することができるので、これ
は、第９表に示すREMOVE POOL手順75により極小的に行
なわれる。

プール制御要素POOL CTL28が除去された場合（701行）
には、関連した拡張プール24は解放される。まず、プー
ル所有のバッファ・リスト34が走査されて、HOME POOL
フィールド52（703-705行）内に記憶された各拡張バッ
ファのホーム・プールをリセットする。次に拡張バッフ
ァは、第6A表及び第6B表のFLUSH MASTER POOL70a、70b
手順を用いたマスタ解放バッファ・リスト40（706行）
から除去される。

拡張プール24が静止される場合（707-709a行）は、プー
ル・バッファ30は解放され、物理的にそれらを削除し、
それによってバッファ・プール20を短縮する。この場
合、マスタ・プールの使用中カウントBUSY CTは、ユー
ザ・プロセスがマスタ解放バッファ・リスト40から除去
したが、解放拡張プールの解放バッファ・リスト42に戻
されたバッファの数だけ減少される。

解放プール24が静止されていない場合（710-711行）
は、そのPOOL CTL要素28は、第８表を参照して後述する
ADD POOL手順76を用いて解放プール・リスト72上で待ち
行列に入れられる。ADD POOLは極小動作を用いて、同時
DELETE POOL及びFREE POOLプロセスに対し直列化する。

FLUSH MASTER POOL70a、70b用の擬似コード：第6A表及
び第6B表は、従来の擬似コード内のFLUSH MASTER POOL
手順70a、70bの実施例を示す。FLUSH MASTER POOLは、F
REE POOL及びDELETE POOL手順により用いられ、マスタ
解放バッファ・リスト40から解放された拡張プール・バ
ッファのすべてを除去する。

ラッチが獲得されて（801行）、同時FREE POOL及びDELE
TE POOL動作に対しFLUSH MASTER POOL手順70a、70bを直
列化する。そうでなければ、除去ループ（802-817行）
を実行する１つのFREE POOLプロセスは、戻りループ（8
18-825行）を実行する他のFREE POOLプロセスを妨害す
ることがある。これはありそうもないが、ラッチは永久
ループに対して動作を保護する。

除去ループ（802-817行）は、マスタ解放バッファ・リ
スト40（804行）からバッファを極小的に除去し、解放
された拡張プールの解放バッファ・リスト（808行）、
またはマスタ・プールのストップオーバ・リスト（810
行）のどちらかに、それらを戻す。マスタ解放バッファ
・リスト40内にもうバッファがない時、除去ループ（80
2-817行）は終わる。

プール制御要素POOL CTL28が、FLUSH MASTER POOL手順
に消される場合は、ゼロ値が、特定の制御要素の拡張プ
ール24が静止されていることを示すので、除去ループ
（802-817行）は、所与のPOOL CTL要素のBUSY CTがゼロ
（814-816行）の場合も、終了する。

除去ループは、第12A表及び第12B表のREMOVE BUFFER AN
D COUNT手順78a、78bを用いて、マスタ解放バッファ・
リスト40からバッファを極小的に除去し、そして除去さ
れた各バッファについて（804行）、マスタ・プールの
使用中カウントBUSY CTを１だけ増分する。808行は、第
11A表のADD BUFFER AND COUNT手順80aを用いて、バッフ
ァを拡張の解放バッファ・リスト42に極小的に戻し、拡
張プールの使用中カウントBUSY CTを１だけ減分するの
で、プールが静止すると、その使用中カウントはゼロ
（０）に等しくなる。810行は、第11表ＡのADD BUFFER
手順82を用いて、バッファをマスタ・プールのストップ
オーバ・リストに極小的に加える。ストップオーバ使用
中カウントは、それが有意の数を含まないので、ADD BU
FFERにより更新されない。

802-817行の除去ループが完了した後、マスタ・プール
のストップオーバ・リスト上のバッファは、818-825行
によりマスタ解放バッファ・リスト40に戻される。第12
A表のREMOVE BUFFER手順86は、使用中カウント（820
行）を更新せずに、極小的にストップオーバ・リストか
らバッファを除去し、ADD BUFFER AND COUNT手順80は、
これらのバッファをマスタ解放バッファ・リスト40に加
える。ストップオーバ・リストが空になると、戻りルー
プは終了する（824行）。801行で得られるラッチは、除
去ループが実行されると直ちに、826行で解放される。

マスタ・プールの使用中カウントBUSY CTが正確である
ことを確証するために、FLUSH MASTER POOLの除去ルー
プにより、マスタ解放バッファ・リスト40から極小的に
除去されるバッファの数は、827行によりマスタ・プー
ルの使用中カウントBUSY CTから減算される。直列化の
ためのCompare-and-Swap命令を用いるのが好ましい。マ
スタ解放リストから除去される拡張バッファの数は、拡
張POOL CTL.FLUSH CTに追加され、解放プール及び削除
プールにより使用される。

バッファ・プールの削除−DELETE POOL68 DELETE POOL68は、FREE POOL動作66の時に削除できなか
った解放された拡張プール24のために、バッファ・プー
ル20の動的短縮の第２段階を実行する。単一タイマ駆動
プロセスは、そのようなプールを解放されたプール・リ
スト72から独立して除去し、それらの関連バッファのす
べてが解放されてしまうと、それらの記憶装置を解放す
る。

DELETE POOL68は、解放プール24を監視し、静止された
解放プールを検出する責任がある。各タイマ間隔で、DE
LETE POOLは、使用中カウントBUSY CTがゼロ（０）であ
るプールのために、解放されたプール・リスト72を走査
する。そのようなものが１つリスト内のどこかで発見さ
れた場合には、DELETE POOLは、それをCompare-and-Swa
p論理回路を用いて除去し、バッファ・プール20を短縮
するように、プールに関連する物理的記憶を解放する。

FREEフィールド74内に固定された解放プール・リスト72
へのアクセスは、極小命令を注意深く使用することによ
り固有に直列化される。複数のFREE POOLプロセスが拡
張プールをリストのヘッドに追加できる間に、唯１つの
DELETE POOLプロセスがそれらを除去できる。DELETE PO
OLプロセスは１つしかないので、極小命令は、リスト内
のどこでもプール制御要素28を除去するために使うこと
ができる。さらに、DELETE POOL動作68は、その動作
が、解放プール24が完全に静止されている場合のみ実施
されるので、主プログラムのメインライン・プロセスと
矛盾しない。

DELETE POOL操作68は、解放されたが折よい仕方で静止
しなかった拡張プール24を検査する。通常これは、ユー
サ・プロセスが、バッファ30を得、それをまだ戻して
（解放して）いない時に発生する。しかしまれには、こ
れは、解放拡張に属するバッファが、拡張の解放バッフ
ァ・リスト42の代わりに、マスタ・プールの解放バッフ
ァ・リスト40に戻ったために発生することがある。前記
のように、これは、FREE BUFFER動作64がバッファをマ
スタ解放バッファ・リスト40に戻すことを決めた後、そ
れが妨害される場合にのみ発生する。FREE POOL操作66
が、その点で実行される場合、プールは解放され、別に
されて静止する。その間、FREE BUFFER動作は、回復さ
れた時、バッファをマスタ解放バッファ・リスト40に戻
す。バッファがユーザ・プロセスまたは他のFREE POOL
動作により続いて除去されない場合、解放されたプール
は決して静止しない。DELETE POOL68は、そのようなバ
ッファをマスタ解放リスト40から周期的にフラッシュす
ることにより、この状態を取り扱う。

DELETE POOL68用の擬似コード：第７表は、従来の擬似コード内のDELETE POOL手順68の
実施例を示す。

DELETE POOL68の901行は、動作がタイマを用いて周期的
に実行されるようにする。902行は、静止されたプール
のために、すべての解放されたプール・リスト72を走査
する。

DELETE POOL68は、解放された拡張リスト72からPOOL CT
L要素を除去する唯一のプロセスであるから、待ち行列
を処理する標準的技術を、そのような要素のリストから
解放された拡張プール制御要素POOL CTL28のどこでも除
去するために使うことができる。

解放プール・リスト72のPOOL CTL要素28に関連した拡張
プール24が静止している場合は、そのPOOL CTL要素は、
そのリスト（906-909行）から極小的に除去（解放）で
きる。プールの資源は解放され（912行）、マスタ・プ
ールの使用中カウントは、ユーザ・プロセスがマスタ解
放バッファ・リスト40から除去したが、解放された拡張
プールの解放バッファ・リスト42（913行）に戻したバ
ッファの数により調整される。この調整は、ユーザ・プ
ロセスがバッファをマスタまたは拡張解放バッファ・リ
ストに戻すか否かが、それが実際にバッファに戻るまで
分からないので、プールが静止するまで行なうことがで
きない。

907行または909行のUNCHAIN POOL極小操作が（910行で
テストされて）失敗した場合は、待ち行列全体は、DELE
TE POOL手順を再び902行から始めることにより再走査さ
れる（911行）。これは、連鎖されないで、削除された
解放プールのプール制御要素POOL CTL28が解放されるプ
ール・リスト72のヘッドに置かれ、同時に実行するFREE
POOLプロセスが他のPOOL CTL要素をリストのヘッドに
追加する場合に、起こりうる。

POOL CTL要素の解放されたプール24が静止されない場合
は、903-915行のDELETE POOLの走査ループ内のプールに
関しては活動はない。

前記のように、マスタ解放バッファ・リスト全体40が、
FLUSH MASTER POOL走査70a、70bを用いて時々フラッシ
ュされ、見捨てられたバッファを除去する。このプロセ
スは、DELETE POOL68の916-920行によりトリガされる
が、各タイマ間隔中実行される必要はない。色々な概略
図のどれも、それが実行される周波数を限定するのに使
うことができる。好ましい実施例では、マスタ解放バッ
ファ・リスト40は、選択された数のタイマ間隔が経過し
た後にのみ、フラッシュされる。代わりに、静止プール
は老朽化する可能性があり、マスタ解放バッファ・リス
トは、「老朽化した」いずれかのプールが現われた場合
にのみフラッシュされる。

極小的動作前記の手順は多くの極小的動作に依存する。これらは、
プール制御要素POOL CTL28上のADD POOL、REMOVE POO
L、UNCHAIN POOL動作、及びバッファ制御要素BUF CTL32
上のADD BUFFER AND COUNT、ADD BUFFER、ADD BUFFER L
IST、REMOVE BUFFER、及びREMOVE、BUFFER AND COUNT動
作である。これらの極小動作のすべては、IBM/370 Comp
are-and-Swap及び、Compare-Double-and-Swap命令のよ
うな極小命令を用いて固有に直列化される。

ADD POOL76用の擬似コード：第８表は、従来の擬似コード内のADD POOL手順76の実施
例を示す。

ADD POOL76は、プール制御要素POOL CTL28をそのような
要素のリストに追加する。そのリストは、プール制御要
素のNEXT POOLフィールド56を通って連鎖される。所与
のPOOL CTL要素28、及び所与のリストに対し、ADD POOL
は、要素をリストのヘッドに追加する。先にリストのヘ
ッドにあった要素は新しい要素（1003行）に連鎖され、
新しい要素はリストのヘッド（1005行）に置かれる。

新しい要素は、現在リスト・ヘッダが並行プロセスによ
り変えられていない場合のみ、リストに追加される。こ
の極小動作は、IBM 370 Compare-and-Swap命令などの極
小的命令を用いて達成できる。極小動作が失敗した場合
は、ADD POOLは、1002行から再試行することにより、新
しいリストのヘッドに要素を追加する試みを繰り返す
（1007行）。

REMOVE POOL75用の擬似コード：第９表は、従来の擬似コード内のREMOVE POOL手順75の
実施例を示す。

REMOVE POOLは、そのような要素のリストから、プール
制御要素POOL CTL28を極小的に除去する。

1100-1105行は、リスト・ヘッダに対し、インデックス
（1102行）とポインタ（1103行）から構成される倍長語
構造として、POOLCHAINデータ・タイプを定義する。そ
れはPOOL CTL要素のリスト用のアンカーとして使われ
る。POOLCHAINインデックスは、複数のプロセスが一度
にリストからPOOL CTL要素（すなわち、マスタプールの
拡張プール・リストからFREE POOLにより除去可能な要
素）を極小的に除去できるようにする。一度に１つのプ
ロセスだけがリストから要素を除去できた場合は、ポイ
ンタはリスト・アンカーとして適切である。しかし、こ
の擬似コードは、FREE POOL66及びDELETE POOL68の両方
で使われ、プール制御要素POOL CTL28のすべてのリスト
に対し、アンカーとしてPOOL-CHAINデータ・タイプを用
いることは好都合である。そのようなアンカーを解放さ
れたプール・リスト72に用いることは悪くない。要する
にそれは必要ではない。

所与のリスト・アンカーについて、REMOVE POOL75は、
第10表のUNCHAIN POOL動作88を用いて、リスト（1108
行）上の第１プール制御要素POOL CTL28の除去を試み
る。それが成功した場合は、REMOVE POOLは、新たな解
放された要素を要求プロセス（1112行）に戻す。このリ
スト内に要素がない場合は、空のPOOL CTL要素は戻され
る。

極小UNCHAIN POOL動作88が失敗し（1109行）、１つある
いは複数の同時プロセスがリストを変えたことを表示す
る場合は、REMOVE POOL75は、動作を再試行することに
より（1110行）、現行リスト・ヘッダを除去し、そして
戻す試みを繰り返す。

UNCHAIN POOL88用の擬似コード：第10表は、従来の擬似コードのUNCHAIN POOL手順88の実
施例を示す。

UNCHAIN POOL88は、REMOVE POOL75によって使用され、
リストのヘッドから要素を除去し、さらにDELETE POOL6
8によって使用され、リスト上のどこからも要素を除去
する。この理由で、連鎖域は常にデータ・タイプPOOLCH
AINであり、このためREMOVE POOL論理は、一度に複数の
プロセスにより、リストからの要素の除去に適応でき
る。しかし、ただ１つのプロセスが一度にそのリストか
ら要素を除去できるようにされる場合は、１つの簡単な
ポインタがリストの連鎖域とアンカーを表示するために
適切になる。

特定のプール制御「要素」POOL CTL28を含む特定のリス
ト「プールチェイン」に対して、UNCHAIN POOLが連鎖を
リスト内の次の要素に極小的に接続し、リストからPOOL
CTL要素（1210行）を除去する。連鎖域に連鎖された要
素がない場合には、空のPOOL CTL要素は戻される（1204
-1205行）。連鎖域が並行プロセスにより変えられてい
ない場合にのみ、要素28は除去される。この極小動作は
IBM 370 Compare-Double-and-Swap命令を用いて完了さ
れる。極小動作が失敗した場合は、UNCHAIN POOLは失敗
を示し（1216行）、この表示をリクエスタに戻す。

ADD BUFFER AND COUNT、ADD BUFFER及びADD BUFFER LIS
Tのための擬似コード：第11A表、及び第12B表は、それ
ぞれADD BUFFER AND COUNT、ADD BUFFER及びADD BUFFER
LIST手順80、82、及び84a、84bの従来の擬似コードに
おける実施例を示す。これらの動作は、１つまたは複数
のバッファ制御要素BUF CTL32をそのような要素の１つ
のリストに極小的に追加する。ADD BUFFER、ADD COUNT
及びADD BUFFER手順80、82は、共にADD BUFFER LIST手
順84a、84bに依存する。これらの動作により使われるリ
ストは、バッファ制御要素BUF CTL32のNEXT FREEフィー
ルド44を通して連鎖される。

第11A表の1300-1306行は、BUFHEADERデータ・タイプを
定義し、それはBUF CTL要素のリスト用のアンカーとし
て使用される。これは、使用中カウント「カウンタ」
（1304行）、インデックス（1303行）、及びリスト・ヘ
ッダ（1305行）から構成される倍長語構造である。BUF
CTL要素は、多重プロセスによりバッファ・リストから
追加または除去されるが、使用中カウント「カウンタ」
は、要素を追加または除去する同じ極小動作で更新され
なければならない。また同じ動作で、インデックスは増
分され、同時プロセスが同時にリストからBUF CTL要素
を除去している時に、干渉に対して保護しなければなら
ない。

ADD BUFFER AND COUNT（1307-1309行）は、１つの要素
（すなわち１要素リスト）を、リストのヘッドに極小的
に追加し、さらにBUSY CTを１だけ減分するADD BUFFER
AND COUNTは、単に1308行に示すようないくつかのパラ
メータをもつADD BUFFER LIST動作を呼ぶ。

ADD BUFFER（1310-1312行）は、極小的に１つの要素
（すなわち１要素リスト）をリストのヘッドに追加する
が、BUSY CTを更新しない（０だけ減分する）。ADD BUF
FERは、それがADD BUFFER AND COUNTにより渡される値
１の代わりに整数“n"に対する値０を渡すことを除い
て、ADD BUFFER AND COUNT（1311行）と同じパラメータ
をもつADD BUFFER LISTを呼ぶ。

ADD BUFFER LIST（1313-1324行）は、連鎖BUF CTL要素
の新しいリストを現存リストのヘッドに追加する。新し
いリストの最初及び最後の要素は、パラメータとしてAD
D BUFFER LISTに渡される。その機能は、現存リスト（1
319、1321行）を新しいヘッドとして新しいリストの第
１要素を置く。同時に現存リストの先のヘッド要素は、
新しいリスト内の最後の要素に連鎖される（1320行）。

新しいリストは、現存リストの現行ヘッダが並行プロセ
ス（第11B表の1322行）によって変えられなかった場合
にのみ、現在のリストに追加される。これは、極小IBM
370 Compare-and-Swap命令を用いて直列化される。同じ
極小動作が、入力カウントＮ（1318行）により使用中カ
ウントBUSY CTを減分するために使用される。さらに、
複数のプロセスは、リストから要素を除去できるので、
INDEXカウントは、また同じ操作（1317、1321行）で増
分される。もし、極小動作が失敗し、他のプロセスが現
存リストのヘッダを変えたことを表示した場合は、ADD
BUFFER LISTは、新しいリストを現存リスト（1323行）
に追加する試みを繰り返す。

REMOVE BUFFER AND COUNT及びREMOVE BUFFER用の擬似コ
ード：第12A表及び第12B表はそれぞれ、REMOVE BUFFER
AND COUNT及びREMOVE BUFFER手順86、及び78a、78bの従
来の擬似コードの実施例を示す。これらの動作は、その
ような要素のリストから、第１のバッファ制御要素BUF
CTL32を極小的に除去する。

REMOVE BUFFER86は、特定のリスト内の第１要素を極小
的に除去するが、しかし、BUSY CTを更新しない（０だ
け増分する）機能である。REMOVE BUFFER（1400-1402
行）は、1401行で示すようないくつかのパラメータを有
するREMOVE BUFFER AND COUNT手順動作を呼ぶ。

REMOVE BUFFER AND COUNT（1403-1421行）は、POOL CTL
要素のリストから第1BUF CTL要素を極小的に除去する。
それに渡される所与のリスト・ヘッダ「アンカー」につ
いては、REMOVE BUFFER AND COUNTは、リスト内に次の
要素を新しいリスト・ヘッダ（1413行）にすることによ
り、リスト上の第１（ヘッダ）要素を除去することを試
みる。古いヘッダ要素は、現在のリスト・ヘッダが並列
プロセスにより変えられない場合にのみ、リストから除
去される。これはIBM 370 Compare-Double-and-Swap命
令により直列化される。

使用中カウントBUSY CTが、同じ極小動作で入力カウン
トＮ（1411行）だけ増分され、そして複数のプロセスが
リストから要素を除去できるので、INDEXカウントも同
じ動作で（1412行）増分される。

極小動作が失敗した場合（1417行）は、REMOVE BUFFE
R、AND COUNTは、その手順を再試行することにより（14
18行）リストから第１要素を除去する試みを繰り返す。

リスト内に要素がない場合は、空のBUF CTL要素が戻さ
れる（1407-1408行）。さもなければ、除去された要素
が戻される（1420行）。

F.発明の効果以上説明したように、この発明によれば、コンピュータ
・システムにおいて資源プールの拡張がはかられる。

【図面の簡単な説明】

第１図は、本発明の好ましい実施例によるマスタ・プー
ル、使用中の活動拡張プール、及び削除を待っている解
放拡張プールを有するバッファ・プール連鎖を示すブロ
ック図である。第２図は、第１図のバッファ・プールの代表的な１つを
示すブロック図である。

───────────────────────────────────────────────────── フロントページの続き (56)参考文献特開昭60−5358（ＪＰ，Ａ) 特開昭62−274348（ＪＰ，Ａ) 特開昭63−208957（ＪＰ，Ａ)

Claims

【特許請求の範囲】

【請求項１】コンピュータ化されたデータ処理システム
において使用のため割り当て可能なコンピュータ資源の
マスター・プールを、該データ処理システムの処理によ
って縮小または拡大するための方法であって、（ａ）（ｉ）少なくとも１つの追加的なコンピュータ
資源を含む拡張プールを作成し、（ii）上記マスター・プールに対し、該拡張プールの
コンピュータ資源を追加することによって上記マスター
・プールを拡張する段階と、（ｂ）（ｉ）上記マスター・プールから上記拡張プー
ルへ、上記拡張プールに由来する非割り当てコンピュー
タ資源を転送し、（ii）上記拡張プールに由来するコンピュータ資源の
割り当て解除時に、該拡張プールに由来するコンピュー
タ資源を上記拡張プールに転送し、（iii）上記拡張プールが、上記拡張プールに由来す
る全てのコンピュータ資源を含むときに、上記拡張プー
ルを削除することによって上記マスター・プールを縮小
する段階とを有する、コンピュータ・システム資源管理方法。
【請求項２】コンピュータ化されたデータ処理システム
において使用のため割り当て可能なコンピュータ資源の
マスター・プールを、該データ処理システムの処理によ
って管理するための方法であって、（ａ）少なくとも１つの追加的なコンピュータ資源を
含む拡張プールを作成する段階と、（ｂ）上記拡張プールのコンピュータ資源を、上記マ
スター・プールに連鎖させる段階と、（ｃ）上記データ処理システムで実行中の処理によっ
て使用するために、上記マスター・プールから上記コン
ピュータ資源を割り当てる段階と、（ｄ）上記処理によって上記コンピュータ資源を開放
する段階と、（ｅ）活動拡張プールに属する上記開放されたコンピ
ュータ資源を上記マスター・プールに戻す段階と、（ｆ）開放拡張プールに属する上記上記開放されたコ
ンピュータ資源を上記拡張プールに戻す段階と、（ｇ）開放拡張プールに属する非割り当てコンピュー
タ資源を、上記マスター・プールから上記拡張プールに
転送する段階と、（ｈ）開放拡張プールが、該開放拡張プールに属する
全ての資源を含むときに、該開放拡張プールを削除する
段階を有する、コンピュータ・システム資源管理方法。