JPS6035702B2 - 多重プロセツサ・システム - Google Patents

Description

【発明の詳細な説明】 以下の順序で本発明を説明する。

Ａ 産業上の利用分野 Ｂ 開示の概要 Ｃ 従来の技術 Ｄ 発明が解決しようとする問題点 Ｅ 問題点を解決するための手段 Ｆ 実施例 ＦＩ システム構造（第１図） Ｆ２ 資源クラス（第２図） Ｆ３ 全般的な動作（第３図） Ｆ４ＥＥＦの構成（第４図） Ｆ５１ＥＦの構成（第４図） Ｆ６ＥＥＦからの要求（第５図） Ｆ７ ユーザ・プログラムからの要求（第５図）Ｆ８
ＥＥＦからＩＥＦへの応答（第４図一第６図）Ｆ９ 動
作の説明（第４図、第５図）ＦＩＯ 一定の深さのプロ
トコル（第２図）ＦＩＩモジュール形の深さのプロトコ
ル（第２図）Ｆ１２ 一定の深さのプロトコルの結果 Ｆ１３ モジュール形の深さのプロトコルの結果Ｆ１４
１ＥＦのユーザ・プログラムからの要求に対するＩＥ
Ｆの動作例（第５図）Ｆ１５ ＥＥＦからの要求に対す
るＩＥＦの動作例（第４図、第５図）Ｈ 発明の効果 Ａ 産業上の利用分野 この発明は、少なくとも２つのＣＰＵが資源に対するア
クセスを共有する場合、この資源を同時に使う為に要求
を送り出す装置に関する。

この装置はＣＰＵの外部にあるチャネル間アダプタの形
にすることが出来るが、多数のＣＰＵを持つシステム内
の１つのＣＰＵに同じ機能を組込むことが出来る。Ｂ
開示の概要 本発明は、複数のＣＰＵが共通のシステム資源に対する
アクセスを競合するような多重プロセッサ・システムに
おいて、各ＣＰＵに関連する内部照会装置（ＩＥＦ）及
びこれらの内部照会装置が対等に結合された外部照会装
置（ＥＥＦ）を設け、或るＣＰＵからシステム資源に対
するアクセス要求が生ぜられた場合には、まず当該ＣＰ
Ｕに関連する内部照会装置の資源テーブルを参照して当
該ＣＰＵがこのシステム資源を所有（ロック）している
か否かを判定し、所有していなければこのアクセス要求
を外部照会装置に送り、その資源テーブルを参照してこ
のシステム資源を他のＣＰＵが所有しているか否かを判
定し、所有していればその該当する内部照会装置ヘアク
セス要求を転送するとともに、該内部照会装置からの応
答を要求中のＣＰ山こ関連する内部照会装置へ返送する
ことにより、１つのＣＰＵが故障した場合であっても他
のＣＰＵがシステム資源を依然としてアクセスしうるよ
うにしたものである。

Ｃ 従来の技術 従来、ＣＰＵの所謂対等結合をしやすくする為にチャネ
ル間アダプタを使うことが知られている。

従来の種々の解決策の違いは、通信プロトコル、行なう
機能及びアダプタの設計にある。この種のシステムに使
える装置が米国特許第３４００３７２号‘こ記載されて
いる。この特許には、端末装置を接続したチャネル間ァ
ダプタが示されている。この為、端末装置はどのチャネ
ルとも通信することが出来る。然し、このチャネル間ア
ダプタは共有資源の間の対等結合を容易にするようなも
のではない。米国特許第３９３４２３２号もこは、ＣＰ
Ｕサブシステム（１００）を１／０サブシステム（２０
０）に結合するァダブタ（２５０）が示されている。こ
の特許は、ＣＰＵ間の情報転送をしやすくするのがその
目的の１つである。共有しうるデータ資源に対するアク
セスの衝突を解決するラツチ機構がこの特許の第５図に
示されている。これは強制メカニズムである。どのＣＰ
Ｕでも、最初にラッチをセットしたものが、他のＣＰＵ
を排除する。Ｄ 発明が解決しようとする問題点然しな
がら、このような強制メカニズムを持つプロトコルは、
誤動作があった時に、システムの障害を発生し易い。

例えば、或るプロトコルはラッチをセットして、システ
ム内の或るＣＰＵに対して資源のアクセスを認めると共
に、他のＣＰＵ全部を排除する。もし資源に対するアク
セスを許可されたＣＰＵが、このラツチをリセットする
。（これによって資源がアンロックされる）前に故障す
るならば、保守技術員がこのラッチをリセットするのを
持っている間に、全部のＣＰＵに対して資源が失われる
。従って、この発明の全般的な目的は、システムの１メ
ンバであるＣＰＵが故障した場合に、システムの各ＣＰ
Ｕが資源からロックアウトされることを防止しつつ、資
源に対するアクセスを容易にする装置を提供することで
ある。

この発明の別の目的は、複数個のＣＰＵが資源を共有す
ることが出来るようにする装置を提供することである。

この発明の特定の目的は、共有プロセスでしなければな
らない仕事量を最小限に押えて、データ資源をＣＰＵに
共有させる装麿を提供することである。Ｅ 問題点を解
決するための手段 データ・レコードの様な資源を多数のＣＰＵ、例えばＣ
ＰＵＩとＣＰＵ２で共有する多重プロセッサ環境では、
１つのＣＰＵが所定の資源を排他的に使用（所有）しな
ければならないことがある。

ここに述べる実施例では、資源は複数個のセクションを
持つ１つのデータ・レコードと定義することが出来るが
、例えば１群のデータ・レコードというような別の定義
を用いてもよい。資源を共有するという問題の解決策は
数多くあり、その効果もさまざまである。この発明の解
決策は、資源を共有する為にしなければならない全体的
な仕事を管理し、資源共有プロセスでしなければならな
い付加的な仕事を少なくする。この発明の装置は、シス
テムの任意のＣＰＵによって所有（管理）されるデータ
資源に対するアクセス要求の第１のＣＰＵから受理する
。

もし第１のＣＰＵがそれまでに資源に対する所有権を持
っていなければ、この装置は、この要求に応答して資源
テーブルを索引し、そしてこの要求が第２のＣＰＵによ
って所有される資源に対して衝突した場合にだけ、この
要求を衝突に関係する全ての所有ＣＰＵに送る。所有Ｃ
ＰＵとは、既にその資源に対する所有権を持っていて、
資源共有フ。。トコルのメンバであるようなＣＰＵを言
う。すべてのメンバ間の合意（肌ａｍｍｉｔｙ）規則を
適用して、所有ＣＰＵは、要求中のＣＰＵに対し、この
発明の装置を通じて伝達される返答により、そのアクセ
ス要求を許可し、遅らせ、又は拒否する。この装置は資
源テーブルの必要な変更を行なう。前に述べたように、
所有ＣＰＵは資源共有プロトコルのメンバと定義するこ
とが出来る。

予定の資源共有プロトコルのすべてのメンバが、この発
明の装置を使う事が出来る。資源共有プ。トコルのメン
バは、どんなものであっても、そのプロトコルの規則を
遵守しなければならない。この発明の実施例では強制メ
カニズムがないから、これは資源共有プロトコルのメン
バであるＣＰＵをプログラムする者の合意によらなけれ
ばならない。前述のように、この発明では、強制メカニ
ズムを使わずに、自発的な資源共有プロトコルを使う。
衝突の解決は、合意された予定の資源共有プロトコルに
従って、もっぱら各ＣＰＵによって処理される。この発
明では衝突の通知は衝突の解決とは切離される。これは
ここに挙げた従来の特許に見られない特徴である。Ｆ
実施例 ＦＩ システム構成（第１図） 第１図のシステムでは、４つのＣＰＵ１，２，３，４が
示されている。

各ＣＰＵはＩＥＦ１，ＩＥＦ２，ＩＥＦ３，ＩＥＦ４と
呼ばれる内部照会装置（ｌｎｔｅｍａＩＥｎｑｕｅｕｅ
Ｆａｃｉｌｉｔｖｔｙ：ＩＥＦ）を持っている。ＩＥＦ
はＣＰＵの内部のあるハードウェア及び／又はフ。。グ
ラミングである。ＩＥＦのユーザは、このＩＥＦに関連
するＣＰＵの内部プログラムである。ＩＥＦの１つの機
能は、そのユーザー・プログラムからの資源に対するア
クセス要求を受理し、それを許可するか、或いはその資
源に対するアクセスを許可する為に必要な措置をとるこ
とである。各ＣＰＵは、そのＩＥＦを介して、外部照会
装置（Ｅ幻ｅｒｎａＩＥｎｑｕｅｕｅＦａｃｉｌｉｔｙ
．ＥＥＦ）５にも接続される。従って、ＩＥＦは、その
データを供給し且つ管理を実行するプログラミング及び
ハードウェアを用いて、ＥＥＦ５を介して互いに通信す
ることが出来る。後で詳しく説明するが、ＥＥＦ５は、
１つ以上のＩＥＦがその１つ以上のユーザー・プログラ
ムの為に要求する資源とのアクセスを容易にする。

前に述べたように、この発明のシステムでは、資源共有
フ。。トコルが使われる。ＥＥＦはこの資源共有プロト
コルの実行を容易にする装置であって、このプロトコル
を実行する装置ではない。云いかえれば、ＥＥＦはこの
資源共有プロトコルを実現する為に使う事が出来る道具
である。資源共有フ。ロトコルは、それに伴なう規則お
共に、システム内の各ＣＰＵにプログラムされるのが普
通である。一般に、ＥＥＦは階層形資源構造について動
作するが、階層形構造にする必要のない程、資源が十分
に定義されている場合も考えられる。

基本的には、ＥＥＦは、次のように資源を管理する。川
ある資源に対する実際の衝突が起った場合にだけ、シ
ステム内の通信を行なわしめる。【２｝ 衝突が起った
場合は、この衝突に関係する資源の所有ＣＰＵだけを、
衝突を解決する為の通信に関与させる。

資源はシステム内の適宜に定義した任意のェンテイテイ
であってよい。

それは１つのデータ・レコードである場合が多いが、場
合によっては、１つのデータ・レコード内の１フィール
ドとして更に狭く定義されていてもよい。資源を後者の
ように定義した場合、そのアクセスを希望するのがシス
テム内の１つのＣＰＵで、その所有権を持つのが別のＣ
ＰＵであることがある。或るＣＰＵによって資源が要求
される場合、この要求は関連するＩＥＦに設けられた資
源共有プロトコルの資源クラス決定アルゴリズムによっ
て、１つの資源クラスに変換される。もしこのｍＦのＣ
ＰＵが当該資源クラスを既に「所有」していなければ、
このＩＥＦはＥＥＦからこの資源クラスを要求する。シ
ステム内の各ＩＥＦは同じ資源クラス決定アルゴリズム
を持っている。このアルゴリズムの１例はハッシュ・プ
ログラムであり、それについて記述した文献は数多くあ
る。Ｆ２ 資源クラス（第２図） 資源クラスの１例が第２図に示されている。

この例のデータ・レコードは製品構造に関係すると仮定
することが出来る。例えば、貯蔵装置内の１つのレコー
ドが木材製品に関する情報を持ち、別のレコートが軸受
に関する情報を持つと考えてよい。更に木材製品はリト
ルリーグ用野球バット又は正規の野球バットに分けられ
よう。木材製品は斧の短かし、柄又は斧の長い柄のこと
もあろう。これに対して軸受はころ軸受、玉軸受、又は
ニードル軸受であってよい。資源クラス決定アルゴリズ
ムは、１つより多くの資源を１つの資源クラスに関係づ
けることが出来るし、そうするのが普通である。例えば
第２図に見られるように、木材製品及び軸受が同じ資源
クラス、即ちこの場合は資源クラス×に関係づけられて
いる。つまり、資源クラス×は木材製品を意味すること
も、軸受を意味することもある。資源クラス決定アルゴ
リズムの基本的な性質は、それが資源共有プロトコルの
全てのメンバに対して終始一貫していることである。こ
のアルゴリズムはどんな形でもよいが、これは「平坦」
な分布を与えるようなものにすべきである。即ち、任意
の資源クラスの使われ方が、他のすべてに対しても大体
同じになるようにすべきである。この様なアルゴリズム
は周知であるし、この発明の一部分を構成するものでも
ない。Ｆ３ 全般的な動作（第３図）ＥＥＦの広汎な動
作の一例が第３図のフローチャートに示されている。

この図で、ＣＰＵＮがその１つプログラムで使う為に、
特定の資源を必要とすると仮定する。ＣＰＵＮ自体は、
その内部の資源クラス決定アルゴリズム（これは前述の
様にシステムの全てのＣＰＵが使うものと同じである）
を使って、この資源を資源クラスＸに変換．（写像）す
る。もしＣＰＵＮが資源クラス×を現に「所有」してい
なければ、これはＥＥＦにメッセージを送り、資源クラ
スＸのアクセスを要求する。この場合、ＥＥＦは、何れ
かのＣＰＵが資源クラス×を所有しているかどうかを判
定する。もしどのＣＰＵも所有していなければ、ＥＥＦ
は、資源クラスＸのＣＰＵＮによって所有されると、マ
−クし、そしてＣＰＵＮにアクセスを許可する。他方、
ＣＰＵＮ以外の１つ以上のＣＰＵが資源クラスＸを所有
する場合、ＥＥＦは、かかるＣＰＵを識別する資源テー
ブルを参照して、その所有ＣＰＵだけに要求を送り、ア
クセスを許可してよいかどうかについて、所有ＣＰＵか
らの返答を待つ。所有ＣＰＵからの全てのメッセージを
受取った時、ＥＥＦは適当なメッセージをＣＰＵＮに送
る。この適当なメッセージは、要求中のＣＰＵ Ｎに対
して、資源クラスＸに対する完全なアクセスを許可して
よい、ということもあろうし、所有ＣＰＵがＣＰＵＮに
資源クラス×の一部分に対するアクセスは許すが、その
全体に対するアクセスは許さない、ということもあろう
。これは後で詳しく説明する。要求中ＣＰＵＮは、資源
共有プロトコルに従って、この応答に対して作用する。
要求中ＣＰＵＮがもはやこの資源を必要としなくなった
場合、ＣＰＵＮはＥＥＦにメッセージを送ってこの資源
をアンロックする。この結果、ＥＥＦを介しての通信ト
ラヒツクは全くないこ又はごく少なくて、この資源を他
のＣＰＵが使うことが出来る。Ｆ４ＥＥＦの構成（第４
図）この発明のＥＥＦの一例が第４図に示されている。

この図に見られる様に、ＥＥＦは、システム内のどのＣ
ＰＵが所定の資源クラスの所有権を持っているかを示す
資源テーブル３７を持っている。例えば、資源クラスＡ
に或るレベルＣＰＵＩ及びＣＰＵ２によって同時に所有
（ロック）され、資源クラスＢはＣＰＵ２及びＣＰＵ３
によって同時に所有されている、という具合である。資
源テーブル３７中の各ＣＰＵに対応するロック列はゼロ
検出器２５に接続され、同じくゲート２３にも接続され
る。システム内の要求中ＣＰＵからのアクセス要求をＥ
ＥＨこ伝達する母線９は復号器１１に接続され、該復号
器は要求された所定の資源クラスのアドレスを復号する
。母線９上の要求は、要求中ＣＰＵ（又はそのｍＦ）の
アドレスをも持っていてよい。母線９はゲート１５，１
７，１９，２１に個別に接続され、これらのゲートには
ゲート２３の出力も接続されている。資源テーフル３７
中のロック列は、システムのメンバＣＰＵからの信号を
適当に復号することにより、個別にセット又はリセット
される。資源テーブル３７の所定の行をアクセスした場
合、その行が資源テーブル３７から謙出され、ゲート２
３及びゼロ検出器２５の入力になる。もし所定の資源ク
ラス、例えば資源クラスＢに対して読出された行が全部
ゼロであれば、これは資源クラスＢを所有しているＣＰ
Ｕが存在しないことを表わす。この場合、ゼロ検出器２
５の線２７が付勢される。これは要求中ＣＰＵ‘こ対し
、該ＣＰＵが資源クラスＢをロックしてよい、という表
示として、直接的に送ることが出来る。ＥＥＦに対する
始めのメッセージ中にあるＣＰＵアドレス（又はＩＥＦ
アドレス）を使って、この信号を要求中のＣＰＵへ送信
させることが出釆るが、これは周知の方法で行なうこと
ができる。また、この同じアドレスを復号器１２で使っ
て、線３０上の信号を現在アドレスされている資源テー
ブル３７の行の適当なＣＰＵ列に与えることにより、そ
の資源を今や要求中ＣＰＵが所有するとマークする、す
なわちロックすることが出来る。所定の資源クラス例え
ば、資源クラスＢに対して謙出された行が全部ゼロでは
なければ、これは、１つ以上のＣＰＵが資源クラスＢを
所有していることを表わす。

この場合、ゼロ検出器２５の線２８が付勢され、資源テ
ーブル３７から行Ｂの内容をゲート１５，１７，１９，
２１へ通す。これらのゲートは、要求中ＣＰＵからの要
求を、資源クラスＢを所有している特定のＣＰＵへ通す
。この例では、要求がＣＰＵ２及びＣＰＵ３へ送られる
。これらのＣＰＵの伍Ｆは、これから説明するようにし
て、この要に対して作用する。この資源クラスを所有す
る各々のＣＰＵによってこの要求に対する応答が構成さ
れ、応答アセンブル・レジスタ３６に送り返される。こ
のレジスタの内容は母線５０を介して要求中ＣＰＵへ送
られ、そのＩＥＦにより、要求した資源に体するアクセ
スの許可又は拒否として解釈される。Ｆ５１ＥＦの構成
（第５図） 也Ｆの１つの機能は、ＥＥＦからの資源に対するアクセ
ス要求に応答出釆るように、そのＣＰＵがどの資源を所
有しているかを表示することである。

ｍＦの別の機能は、自分のユーザ・プログラムからの資
源の要求に応答することである。即ち、そのＣＰＵのユ
ーザ・プログラムに対し、ｍＦはＥＥＦとして機能する
。システムの各ＣＰＵで使えるＥＦの一例が第５図に示
されている。第５図にはＣＰＵＩのｍＦＩが示されてお
り、これはそれ自体の資源テーブル４７を持っている。
資源テーブル４７のロック列にある記入事項は、第４図
のＥＥＦの資源テーブル３７に記入されたものと同様に
、ＣＰＵＩが資源クラスＡ、Ｃ、Ｘ、Ｚをロックしてい
ること、即ちその所有権を持っていることを示す。資源
テーブル４７には、資源名称／所有者の列もある。この
列は、ユーザ・プログラムが資源クラスをを使う時の資
源の名称と、そのユーザ・プログラムの識別符号とを表
わしている。例えば、第２図の例で言うと、ＣＰＵＩの
ユーザ・プログラム４は、野球バットに関する資源を使
うことがあろう。その場合、資源の名称は木材製品・野
球バット（ＷＰ／ＢＢ）である。これは、ＩＥＦＩと関
連している第４図の資源クラス決定アルゴリズム４９に
より、資源クラスＸに変換される。この為、資源クラス
Ｘに対する資源名称ノ所有者列の記入項目は（ＷＰ／Ｂ
Ｂ、４）になる。この列は幾つかの記入項目を持つ位に
広いと観てよい。例えば、ユーザー・プログラム５がニ
ードル軸受に関する資源を使っている場合、資源の名称
は軸受・ニードル（Ｂ／Ｎ）になろう。これも資源クラ
ス×に変換されよう。この為、資源クラスＸの資源名称
／所有者列の記入項目は（ＷＰ／ＢＢ、４）と（Ｂ／Ｎ
、５）になり、ロックされた資源クラスＸが木材製品の
内の野球バットのサブクラスを使っているユーザ・プロ
グラム４と、軸受の内のニードル軸受のサブクラスを使
っているユーザ・プログラム５とによって使用中である
ことが表示される。資源クラス決定アルゴリズム４９に
よって資源クラスＸに変換された資源の名称と、この資
源を使用しているユーザ・プログラムの識別符号をマー
クする機構も、第５図に示されている。或るユーザ・プ
ログラムからの要求は、全体を５４で示した母線の１つ
を介して伝達され、資源クラス決定アルゴリズム４９に
入る。これらの母線はオア・ゲート５１にも接続され、
その出力母線５３は資源テーブル４７の資源名称／所有
者列を構成するラッチに接続される。ここで、ユーザ・
プログラム４からのアクセス要求として、木材製品、野
球バットが母線５５を介して伝達されたと仮定する。今
の例に従って、この資源は資源クラスＸに変換される。
資源クラスＸの識別符号が母線５５′を介して復号器５
７へ送られ、そこで、資源クラス×の為に予約されてい
る資源テーブル４７のアドレスに複号される。アルゴリ
ズム４９及び復号器５７が整定する為の適当な遅延時間
の後、母線５３を介して、（ＷＰ／ＢＢ、４）の符号を
、資源テーブル４７の資源名称／所有者列の内の資源ク
ラス×に対して復号されたアドレスに設定することが出
来る。

Ｆ６ＥＥＦからの要求（第５図）第５図には、第４図の
ＥＥＦからの要求をＩＥＦに伝達する母線３８も示され
ている。

前に述べた様に、この要求は要求された資源クラス、所
望の資源の名称、及び要求中ＣＰＵ（又はそのＩＥＦ）
のアドレスを含んでいる。母線３８は復号器５７に接続
される。要求中ＣＰＵは既に所望の資源を１つの資源ク
ラスに変換しているから、あらためて資源クラス決定ア
ルゴリズム４９を経由する必要はない。従って、資源ク
ラス決定ァルゴリズム４９の出力が接続されるのと同じ
目的の為に、母線３８が復号器５７に直接接続される。
母線３８から、母線８１がプロトコル論理装置７０‘こ
接続され、後でプロトコル論理装置７０で使う為、所望
の資源の名称を伝達する。母線３８は、要求が活勢であ
る時に付勢される線６１を含んでいてもよい。線６１は
アンド・ゲート６６に接続され、このアンド・ゲートの
他方の入力は、復号器５７の出力によってアドレスされ
た行のロック列から釆る。アンド・ゲート６６の出力は
ゼロ検出器６７に接続される。線６１はィンバータを介
してアンド・ゲート７１にも接続される。アンド・ゲー
トＴＩの他方の入力もロック列から来る。アンド・ゲー
ト７１の出力は、ゼロ検出器７３に接続される。要求は
ＥＥＦから来るのであるから、これは母線３８に生じ、
そして復号器５７の出力が資源テーブル４７の所望の行
をアドレスする。

この要求は外部の要求であるから、この時線６１が活勢
であり、アンド・ゲート６６を条件づける。従って、ア
ドレスされた行のロック・ビットがアンド・ゲート６６
を介してゼロ検出器６７へ送られる。もしこのロック・
ビットがゼロであれば、要求された資源クラスがこのＩ
ＥＦによってロックされていない、ということである。
従って、線６８はプロトコル論理装置７０を条件づける
ことにより、このｍＦに関する限り、要求を許可するこ
とが出来るという応答をＥＥＦに送らせる。もしロック
・ビットが１であれば、このＩＥＦが要求された資源ク
ラスをロックしていることを表わす。この場合、線７９
Ａがゲート６０を条件づけ、要求された資源クラスの内
、このＩＥＦがロックしているサブクラスを表わす資源
の名称を通す。もし、資源共有プロトコルが許せば、プ
ロトコル論理装置７０は、このＩＥＦに関する限り、要
求された資源クラスの任意のもの（即ち、。ックされて
いない資源の名称）に対するアクセスを許可することが
出来るかどうかを表わす応答をＥＥＦに送る。このやり
方は後で説明する。Ｆ７ ユーザ・プログラムからの要
求（第５図）全般的な動作で、適当な時点を仮定すると
、復号器５７がユーザ・プログラムからの資源に対する
アクセス要求を復号している場合、線６１は不宿勢であ
る。

資源クラス決定アルゴリズム４９がユーザ・プログラム
からの要求を１つの資源クラスに変換した後、復号器５
７はこの資源クラスを持つ資源テーブル４７内の行をア
ドレスする。線６１は不活勢である（ユーザ・プログラ
ムの要求であって、ＥＥＦからの要求ではない）から、
線７２が活勢となり、アドレスされた行のロック・ビッ
トがァンド・ゲート７１を介してゼロ検出器７３に送ら
れる。もしこのビットがゼロであれば、このＩＥＦ（具
体的にはそのＣＰＵのユーザ・プログラム。

以下同じ。）は要求された資源クラスを所有していない
。従って、このＩＥＦのアドレスと要求されて資源クラ
ス及び資源の名称を含む要求（その形で後で詳しく説明
する）が、要求アセンブリ・レジスタ７７で組立てられ
、母線９を介してＥＥＦに送られて、要求中のユーザ・
プログラムに対し、このＩＥＦが当該資源クラスを或る
レベルでロックすることが出来るかどうかを決定する。
もしロック・ビットが１であれば、ゼロ検出器７３の非
ゼロ出力が線７４を付勢する。

つまり、要求れた資源クラスがこのＩＥＦによって所有
されている、ということである。この要求は内部のユー
ザ・プログラムから出たものであるから、プロトコル論
理装置７０から線８０を介して、ユーザ・プログラムに
対して要求を許可することが出来る。利用し得る資源共
有プロトコルは後で説明する。線８０が付勢されると、
要求が許可される。Ｆ８ ＥＥＦからＩＥＦへの応答（
第４図−第６図）前段で述べた様に、要求中ＣＰＵのＩ
ＥＦが要求アセンブリ・レジスタ７７を介してＥＥＦに
要求を送った場合、第４図に示したＥＥＦの応答アセン
ブリ・レジスタ３６によって、最終的な応答が組立てら
れる。

この応答は、要求中ｍＦのアドレスを使って、母線５０
を介して要求中ＩＥＦに送られる。このアドレスは応答
に入れることが出釆る。この応答は母線５０を通って、
第５図の許可／拒否論理装置へ送られ、そこで解釈され
る。この論理装置の一例を第６図に示す。第６図にはＩ
ＥＦＩからとＩＥＦ４からとの２つの応答に対する論理
装置が示されている。これは任意の数の応答に拡大する
ことが出釆る。第６図において、位置１は、応答中ＩＥ
Ｆが、資源クラス×に対するアクセスをどんな制御レベ
ルでも許可することが出来ないことを示す。位置２は、
要求が応答中ＩＥＦによって完全に許可されることを示
す。従って、応答の各々の位置２がアンド・ゲート８１
に接続される。各々の応答が完全なアクセスを許可した
場合、許可線が付勢され、要求を許可すると共に、資源
テーブル４７の資源クラス×をロックする。各々の位置
１はオア・ゲート８３に接続される。何れかの応答中Ｉ
ＥＦがどの制御レベルでもアクセスを許可出釆ない場合
、出し直し線がユーザ・プログラムに対して付勢され、
この場合ユーザ・プログラムは後の時点でその要求を出
し直すことが出来る。Ｆ９ 動作の説明（第４図、第５
図） 次に図面を参照して、この発明の動作の詳細を一例につ
いて説明する。

ＣＰＵＩが、例えば更新の為にｔニードル軸受資源」を
使っていると仮定する。

この場合、第５図に示したのと同様なＣＰＵ１のｍＦに
設けられた資源クラス決定アルゴリズムが、第２図の例
で述べた様に、「ニードル軸受」を資源クラスＸに変換
し、第４図の資源テーブル３７のうち資源クラスＸのＣ
ＰＵＩの列に１をセットすることにより、資源クラスＸ
の所有権をＣＰＵＩが持ったことをマークする（即ち、
資源クラスＸをロックする）。この時、ＣＰＵ２が、例
えば「リトルリーグ野球バット」をアクセスしたければ
、ＣＰＵ２はこの資源をロックしなければならない。従
って、ＣＰＵ２に関連するｍＦ２は、「木材製品」を資
源クラスＸに変換する。というのは、第２図の例では、
資源クラス決定アルゴリズム４９が「木材製品」及び「
軸受」の両方を資源クラスＸへ変換するからである。Ｉ
ＥＦ２の資源テーブル４７の資源クラスＸで、ロック・
ビットがゼロであると仮定すると、伍Ｆ２は、その要求
アセンブリ・レジスタ７７で、下記の形ロックＸ、ｍＦ
２、木材製品・野球バット・リトルリーグの２つの部分
から成る、ＥＥＦへのアクセス要求を構成する。

下線を施した部分は命令部分であり、もしＥＥＦの資源
テーブル３７で資源クラスＸに対する所有権がなければ
、ＣＰＵ２が、これ以上の通信トラヒックを必要とせず
に、第４図の線２７を介して、自動的に所有権を得るこ
とをＥＥＦに知らせる。

要求の残りの部分は情報都分であり、システム内の他の
所有ＣＰＵに対して、これを必要とするかどうかの要求
情報を供給する。第４図の例では、資源クラス×はＣＰ
ＵＩ及びＣＰＵ４が所有している。従って、ゲート２３
は夫々線２９，３５を介してゲート１５，２１にゲート
信号を送り、この要求をＣＰＵＩ及びＣＰＵ４の伍Ｆへ
送らせる。例えば、ｍＦＩが、この要求を受取ると、Ｃ
ＰＵ２が「木材製品」を希望していることをその情報部
分から判断する。

ｍＦＩは「軸受」を使っているから、そのプロトコル論
理装置７川ま、資源クラスＸの内のサブクラスである木
材製品に対する完全なアクセスをＣＰＵ２に与える応答
をその応答アセンブリ・レジスタで構成して、ＥＥＦに
伝達することにより、ＣＰＵ２にアクセスを許可する。
この応答は、Ｘ許可、ＩＥＦ２，ＩＥＦ１、木材製品と
いう形にすることが出釆る。この場合、ＣＰＵＩは、Ｃ
ＰＵ２に資源クラス×の前述のサブクラスに対するアク
セスが許可されていて、ＣＰＵ２が未だこのアクセスを
放棄していないかも知れないので、ＣＰＵ２が資源クラ
スＸの共有者であるかも知れない、ということを承知し
ている。

ＣＰＵＩ及びＣＰＵ２は、資源共有プロトコル（これは
この発明の一部ではない）により、互いに資源クラス×
を使うことについて、希望する任意のレベルの細目を保
有することに同意することが出来る。然し、その保有量
が多くなればなる程、システム内でその間に必要な通信
量が多くなる。この通信を制限する為には、深さがモジ
ュール形であるか、或いは特性の深さの高レベルに制限
された資源共有プロトコルにすることが望ましいと思わ
れる。ＦＩＯ 一定の深さのプロトコル（第２図）もし
資源共有プロトコルが或るレベルを定め、それよりも低
い所では、ロックされた資源クラスがあるかどうかの照
会をしえない場合、一定の深さのプロトコルになる。

例えば、製品のクラス（即ち、第２図の木材製品又は軸
受）又は合意によってその他の任意の深さがメモリの最
探しベル（即ち、共有レベルとして記憶されるように選
ばれた深さ）として定められた場合、各々のＩＥＦに要
求が送られて来た時、この要求を許可することができる
かどうかを判断するのに、この一定の深さより下の所を
このｍＦは照会しないのである。例えば、製品クラスが
一定の深さと定められた場合、Ｘロック、ｍＦ２、木材
製品・斧の柄という様なＩＥＦ２からの要求をＩＥＦＩ
が受取り、且つ伍ＦＩが木材製品・野球バンドを使って
いるならば、ｍＦＩからはこの要求を拒否する応答がＥ
ＥＦに送られ、そこから伍Ｆ２に伝達される。というの
は、ＩＥＦＩは合意によって、製品クラス（即ち、木材
製品）より低い所を照合して、それが木材製品・斧の柄
を使っていないかどうかを判断しないからである。ＩＥ
Ｆ２は、ＩＥＦＩが木材製品・野球バットを使い終るま
で、ＥＥＦを通じて木材製品・斧の柄を求めつづけても
よいし、或いはｍＦ２は、ＩＥＦＩが木材製品・野球バ
ットの使用を完了したことを通知して来るのを待っても
よい。一定の深さに制限された資源共有プロトコルは、
システム内の通信を制限するが、更に照会する合意があ
った場合には許可したかも知れないアクセスを、要求中
也Ｆに対して許可しないことがある。ＦＩＩ モジュー
ル形の深さのプロトコル（第２図）モジュール形の深さ
の資源共有プロトコルでは、所有ＣＰＵの伍Ｆは、許可
することが出来るものであれば、到来した要求を許可す
るのに必要な深さまで、照会することに合意する。

例えば、ｍＦ２がＸロック ＩＥＦ２ 木材製品・斧の
柄を要求し、伍ＦＩが現在、木材製品・野球バット・リ
トルリーグを使っている場合、伍ＦＩは自分が使ってい
るのがリトルリーグ・野球バットの資源であることを識
別して、斧の柄の資源に対しては、ＩＥＦ２にアクセス
を許可する。モジュール形の深さのプロトコルの利点は
、資源の所有者が、自分が所有する最終制御レベル又は
それより低い全ての資源を自由に使えることである。

即ち、或るＩＥＦの資源の一部分を放棄する場合、この
ＩＥＦは階層中の所定のレベルだけを放棄すればよい。
この例を第２図について説明する。

前に述べた様に、Ｘの様な所定の資源クラスは２つ以上
の製品クラスを含んでいてよい。例えば第２図の資源ク
ラス×は、２つの製品クラスとして、木材製品及び軸受
を含んでいる。

各々の製品クラスを図示の様に更に細分することが出釆
る。也ＦＩは資源クラス×を所有し、田Ｆ２が、次のよ
うに、短かし、斧の柄の資源に対するアクセスを要求し
たと仮定する。×ロック 伍Ｆ２ 木材製品・斧の柄・
短モジュール形の資源共有プロトコルでは、ＩＥＦＩが
木材製品の内の野球バットの資源を使っている場合、也
ＦＩは短かし、斧の柄という資源に対するＥＦ２からの
要求を許可することが出来る。

実際、ｍＦＩが、例えば野球バットの在庫調べをしてい
るが、斧の柄は必要がないと判断すれば、ＥＦＩは全て
の斧の柄に対してＩＥＦ２にアクセスを許可しても、木
材製品の内の野球バットという資源は保有することが出
来る。この為、ＩＥＦＩは、階層形トリーの内、使って
いない最高の節を選択し、その節しベル（即ち、斧の柄
）でアクセスを許可し、しかも木材製品・斧の柄以外の
資源クラスＸの全てについて、そのユーザ・プログラム
に対するアクセスを自由に即座に許可することが出来る
。Ｆ１２ 一定の深さのプロトコルの結果 ＩＥＦは、そのユーザーとして、この伍Ｆに関連するＣ
ＰＵのユーザ・プログラムを持っている。

これらのプログラムは当然資源に対するアクセスを要求
する。こういうユーザ・プログラムに対し、ＩＥＦは、
ＥＥＦがｍＦに対して作用するのと同様に作用する。例
えば、ＩＥＦがその１つのユーザ・プログラムに対して
、資源に対するアクセスを直ちに許可することが出来る
のであれば、そうする。このアクセスを許可することが
出釆なければ、アクセスを得る為にＥＥＦに照会しなけ
ればならい。システムが一定の深さの資源共有ブロトコ
ルを採用した場合、ＲＦは、そのユーザ・プログラムに
対し、この一定の深さのレベルか或いはそれより下にあ
る要求に、直ちにアクセスを認める自由がある。例えば
、ＩＥＦＩが木材製品・野球バット・リトルリーグを使
っていて、ｍＦ２が木材製品・斧の柄を要求した場合、
ＩＥＦ２の要求を拒否することは前に述べた通りである
。然し、この結果、ｍＦＩは、ＥＥＦをわずらわさずに
、そのユーザに対し、木材製品・斧の柄に対するアクセ
スを（又は実際には木材製品の中の資源に対するどんな
アクセスをも）直ちに許可することが出来る。従って、
この点で、ｍＦＩは、自分のユーザ・プログラムに対し
ては、ＥＥＦとして作用する。唯一の拘束は、この例の
ＩＥＦＩが、そのどのユーザ・プログラムにどの資源を
許可したかを内部で記録しておくことである。この為、
前に述べた様に、一定の深さのブロトコルはシステム内
の通信を制限する。Ｆ１３ モジュール形のプロトコル
の結果モジュール形のプロトコルは、資源に対するｍＦ
のアクセス要求を許可する場合の方が多いのが普通であ
るが、許可する時の細分度が細かい。

例えば、ＥＦＩが木材製品・野球バットという資源を使
っている時、也Ｆ２に対して木材製品（更に粗の細分度
）を許可することは出釆ないがＩＥＦ２に対して木材製
品・斧の柄（更に細かい細分度）を許可することは出来
る。この為、ＩＥＦ２は、そのユーザに対し、木材製品
・斧の柄に対するアクセスだけを直ちに許可することが
出来るが、ｍＦ２のユーザ・プログラムからの木材製品
に対する他の全てのアクセスの要求については、ＥＥＦ
の手をかりなければならない。この為、モジュール形の
資源共有プロトコルにすると、要求中位Ｆに対してアク
セスが許可される場合が一層多くなるが、ｍＦのユーザ
・プログラムから要求に対し、そのｍＦがシステム内で
行なう通信が一層多くなる。Ｆ１４ １ＥＦのユーザ・
プログラムからの要求に対するｍＦの動作例（第５図）
伍ＦＩのユーザ・フ。

。グラム５がニードル軸受を使いたいと仮定する。更に
最初は、資源クラスＸの資源名称／所有者列の記入項目
が（ＷＰ／ＢＢ、４）だけであると仮定する。ニードル
軸受の資源に対するアクセス要求が、例えば第５図の母
線５５に置かれて、資源クラス決定アルゴリズム４９に
送られる。この要求は資源クラスＸに変換され、資源テ
ーブル４７でこの資源クラスＸの行に対応するアドレス
が、アルゴＩＪズム４９の出力に現われ、復号器５７に
よって復号される。資源クラスＸに関連するロック列が
謙出される。これは１として示してあるから、ゼロ検出
器７３は、この資源クラスＸが当該ＩＥＦによって所有
されていることを検出し、そしてゲート６９を条件づけ
で、資源名称／所有者列の内容をプ。トコル論理装置７
０‘こ送る。要求（Ｂ／Ｎ、５）を伝える母線５３が、
この要求をブロトコル論理装置７０に伝達する。資源名
称／所有者列の内容は、資源クラスＸの内の木材製品・
野球バットというサブクラスが、ユーザ・プログラム４
（ＷＰ／ＢＢ、４）によって使われているが、今の例で
は、ニ−ドル軸受は使われていないことを示しているか
ら、プロトコル論理装置７０は、一定又はモジュール形
の何れのプロトコルを使っていても、ユーザ・プログラ
ム５に対し、資源クラス×の内のニードル軸受のサブク
ラスに対するアクセスを許可する。線８０がアクセスを
許可し、次に要求があった時に使う為この要求の識別符
号を資源テーブル４７の資源名称／所有者列へ送る。ユ
ーザ・プログラム５を完了すると、それを適当に復号し
てユーザ・プログラム完了線を付勢し、資源テーフル４
７から（Ｂ／Ｎ、５）を除き、若しこれが資源クラスＸ
を使用する最後の回であれば、ロック列をリセツトする
。もし資源クラス×のロック列がゼロであったとすると
、ゼロ検出器７３は線７５を付勢して、このｍＦが資源
クラスＸをロックしていないことを表示する。

線７５は、Ｘロック、ｍＦ１、軸受・ニードルという要
求としてＥＥＦに送る為、資源クラスの名称及び資源の
名称を要求アセンブリ・レジスタ７７に送り、資源を要
求するが、これは前に述べた通りである。

Ｆ１５ ＥＥＦからの要求に対するＩＥＦの動作例ｍＦ
２の斧の柄に関する資源をアクセスする必要があると仮
定する。

更にこの例では、第５図がＩＥＦＩを示しているとする
。前段で述べた様にｍＦ２は、自分が資源クラス×を所
有していないと判断する。次にｍＦ２はＸｏック、ｍＦ
２、木材製品・斧の柄 という要求を構成する。

この要求はＥＥＦへ伝達される。第４図を参照するに、
ＥＥＦは前述の如く、資源クラス×がＩＥＦＩとＩＥＦ
４とによってロックされていると判定する。この例では
、ＩＥＦＩの動作を詳しく説明する。ＩＥＦ４の動作も
同様である。第５図の資源テーブル４７を参照するに、
ｍＦＩが資源クラスＸを所有している。

資源クラス×の内、実際に使われているサブクラスは、
ユーザ・プログラム４による材木製品・野球バット（Ｗ
Ｐ／ＢＢ、４）とユーザ・プログラム５によるニードル
軸受（Ｂ／Ｎ、５）である。木材製品・斧の柄は、ｍＦ
Ｉによって使われていない。Ｘロック、ｍＦ２、木材製
品・斧の柄という要求が、母線３８を介して第５図の復
号器５７へ送られる。行×が読出される。アンド・ゲー
ト６６がロック列から１をゼロ検出器６７へ送る。この
１で付勢されている為、線７９は、行×の資源名称／所
有者列の内容をプロトコル論理装置７０１こ送ると共に
、資源クラスＸがロックされていることをプロトコル論
理装置７０に直接的に知らせる。プロトコル論理装置７
０１こは、母線８１を介して、資源（木材製品・斧の柄
）が、そしてゲート６９を介して、ｍＦＩが木材製品・
野球バット及び軸受ニードルだけを使っており、木材製
品・斧の柄を使っていないという事実が伝えられている
。この場合、一定の深さのプロトコルを使えば、前に述
べた様に、アクセスが拒否される。モジュール形のプロ
トコルを使えば、プロトコル論理装置７０は、資源クラ
ス×はロックされているが、ｍＦＩが木材製品・斧の柄
を使っていないと判定し、×許可、田Ｆ２、木材製品・
斧の柄という形の応答をＥＥＦに送ることにより、この
要求を許可する。

この応答は第４図の応答アセンフル・レジスタ３６で組
立てられ、ＩＥＦ２の許可／拒否論理装置へ送られ、そ
こで、斧の柄という資源を使うアクセスを要求に対する
許可と解釈される。Ｈ 発明の効果 以上詳述したように、本発明によれば、システムの１メ
ンバであるＣＰＵが故障した場合でも、他のＣＰＵがシ
ステム資源を依然としてアクセスすることができるとい
う、優れた効果が得られる。

【図面の簡単な説明】

第１図は各ＣＰＵがデータ資源を共有することが出来る
多重プ。 セッサ・システムの全体図、第２図はこの発明の装置で
使われる資源クラスの構成を示す図、第３図はこの発明
の装置の動作を示すフローチャート、第４図はこの発明
の外部照会機構（ＥＥＦ）の略図、第５図は多重プロセ
ッサ・システム内の内部照会装置（ＩＥＦ）の略図、第
６図は許可／拒否論理装置の構成を示す図である。１〜
４・・…・中央演算処理装置、ｍＦＩ〜４・・・・・・
内部照会機構、５・・・・・・外部照会機構（ＥＥＦ）
。 ＦＩＧ．ＩＦＩＧ，２ ＦＩＧ．６ ＦＩＧ，３ ＦＩＧ，ム ＦＩＧ，５

Claims (1)

【特許請求の範囲】
1. １ 複数のＣＰＵと、該ＣＰＵによつてアクセスされる
   システム資源とを有する多重プロセツサ・システムであ
   つて、前記ＣＰＵに関連してそれぞれ設けられた複数の
   内部照会装置（第１図のＩＥＦ）と、前記内部装置の各
   々に対等に結合された共通の外部照会装置（第１図のＥ
   ＦＦ）とを備え、前記内部照会装置の各々は、関連する
   前記ＣＰＵまたは前記外部照会装置から受取られた前記
   システム資源に対するアクセス要求に応答して当該内部
   照会装置によつて管理されている特定の前記システム資
   源の使用状況を示す第１の資源テーブルを参照する手段
   （第５図の４７，５１，５５，５７）と、該資源テーブ
   ルの内容に応じて当該アクセス要求を直ちに許可するこ
   とができるか否か判定し且つその判定結果を当該アクセ
   ス要求の応答として前記関連するＣＰＵまたは前記外部
   照会装置へ通知する手段（第５図の６７，７０，７３）
   と、前記関連するＣＰＵからのアクセス要求を直ちに許
   可することができない場合は該アクセス要求を前記外部
   照会装置へ発信する手段（第５図の７７）とを含み、前
   記外部照会装置は、前記内部照会装置から受取られたア
   クセス要求に応答して前記複数の内部照会装置によつて
   管理されている前記システム資源の使用状況を示す第２
   の資源テーブルを参照する手段（第４図の１１，３７）
   と、該資源テーブルの内容に応じて当該アクセス要求を
   直ちに許可することができるか否かを判定し且つ直ちに
   許可することができる場合は当該アクセス要求を発信し
   た特定の前記内部照会装置へ許可信号を供給する手段（
   第４図の２５）と、当該アクセス要求を直ちに許可する
   ことができない場合には所望の前記システム資源を管理
   している前記内部照会装置へ当該アクセス要求を送信す
   る手段（第４図の１５〜２３）と、該内部照会装置から
   の応答を受取つて該応答を前記特定の内部照会装置へ返
   送する手段（第５図の３６）とを含んでいることを特徴
   とする、多重プロセツサ・システム。