JPS6035702B2 - 多重プロセツサ・システム - Google Patents
多重プロセツサ・システムInfo
- Publication number
- JPS6035702B2 JPS6035702B2 JP54144507A JP14450779A JPS6035702B2 JP S6035702 B2 JPS6035702 B2 JP S6035702B2 JP 54144507 A JP54144507 A JP 54144507A JP 14450779 A JP14450779 A JP 14450779A JP S6035702 B2 JPS6035702 B2 JP S6035702B2
- Authority
- JP
- Japan
- Prior art keywords
- resource
- cpu
- access
- request
- access request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/161—Computing infrastructure, e.g. computer clusters, blade chassis or hardware partitioning
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Multi Processors (AREA)
- Information Transfer Systems (AREA)
Description
【発明の詳細な説明】
以下の順序で本発明を説明する。
A 産業上の利用分野
B 開示の概要
C 従来の技術
D 発明が解決しようとする問題点
E 問題点を解決するための手段
F 実施例
FI システム構造(第1図)
F2 資源クラス(第2図)
F3 全般的な動作(第3図)
F4EEFの構成(第4図)
F51EFの構成(第4図)
F6EEFからの要求(第5図)
F7 ユーザ・プログラムからの要求(第5図)F8
EEFからIEFへの応答(第4図一第6図)F9 動
作の説明(第4図、第5図)FIO 一定の深さのプロ
トコル(第2図)FIIモジュール形の深さのプロトコ
ル(第2図)F12 一定の深さのプロトコルの結果 F13 モジュール形の深さのプロトコルの結果F14
1EFのユーザ・プログラムからの要求に対するIE
Fの動作例(第5図)F15 EEFからの要求に対す
るIEFの動作例(第4図、第5図)H 発明の効果 A 産業上の利用分野 この発明は、少なくとも2つのCPUが資源に対するア
クセスを共有する場合、この資源を同時に使う為に要求
を送り出す装置に関する。
EEFからIEFへの応答(第4図一第6図)F9 動
作の説明(第4図、第5図)FIO 一定の深さのプロ
トコル(第2図)FIIモジュール形の深さのプロトコ
ル(第2図)F12 一定の深さのプロトコルの結果 F13 モジュール形の深さのプロトコルの結果F14
1EFのユーザ・プログラムからの要求に対するIE
Fの動作例(第5図)F15 EEFからの要求に対す
るIEFの動作例(第4図、第5図)H 発明の効果 A 産業上の利用分野 この発明は、少なくとも2つのCPUが資源に対するア
クセスを共有する場合、この資源を同時に使う為に要求
を送り出す装置に関する。
この装置はCPUの外部にあるチャネル間アダプタの形
にすることが出来るが、多数のCPUを持つシステム内
の1つのCPUに同じ機能を組込むことが出来る。B
開示の概要 本発明は、複数のCPUが共通のシステム資源に対する
アクセスを競合するような多重プロセッサ・システムに
おいて、各CPUに関連する内部照会装置(IEF)及
びこれらの内部照会装置が対等に結合された外部照会装
置(EEF)を設け、或るCPUからシステム資源に対
するアクセス要求が生ぜられた場合には、まず当該CP
Uに関連する内部照会装置の資源テーブルを参照して当
該CPUがこのシステム資源を所有(ロック)している
か否かを判定し、所有していなければこのアクセス要求
を外部照会装置に送り、その資源テーブルを参照してこ
のシステム資源を他のCPUが所有しているか否かを判
定し、所有していればその該当する内部照会装置ヘアク
セス要求を転送するとともに、該内部照会装置からの応
答を要求中のCP山こ関連する内部照会装置へ返送する
ことにより、1つのCPUが故障した場合であっても他
のCPUがシステム資源を依然としてアクセスしうるよ
うにしたものである。
にすることが出来るが、多数のCPUを持つシステム内
の1つのCPUに同じ機能を組込むことが出来る。B
開示の概要 本発明は、複数のCPUが共通のシステム資源に対する
アクセスを競合するような多重プロセッサ・システムに
おいて、各CPUに関連する内部照会装置(IEF)及
びこれらの内部照会装置が対等に結合された外部照会装
置(EEF)を設け、或るCPUからシステム資源に対
するアクセス要求が生ぜられた場合には、まず当該CP
Uに関連する内部照会装置の資源テーブルを参照して当
該CPUがこのシステム資源を所有(ロック)している
か否かを判定し、所有していなければこのアクセス要求
を外部照会装置に送り、その資源テーブルを参照してこ
のシステム資源を他のCPUが所有しているか否かを判
定し、所有していればその該当する内部照会装置ヘアク
セス要求を転送するとともに、該内部照会装置からの応
答を要求中のCP山こ関連する内部照会装置へ返送する
ことにより、1つのCPUが故障した場合であっても他
のCPUがシステム資源を依然としてアクセスしうるよ
うにしたものである。
C 従来の技術
従来、CPUの所謂対等結合をしやすくする為にチャネ
ル間アダプタを使うことが知られている。
ル間アダプタを使うことが知られている。
従来の種々の解決策の違いは、通信プロトコル、行なう
機能及びアダプタの設計にある。この種のシステムに使
える装置が米国特許第3400372号‘こ記載されて
いる。この特許には、端末装置を接続したチャネル間ァ
ダプタが示されている。この為、端末装置はどのチャネ
ルとも通信することが出来る。然し、このチャネル間ア
ダプタは共有資源の間の対等結合を容易にするようなも
のではない。米国特許第3934232号もこは、CP
Uサブシステム(100)を1/0サブシステム(20
0)に結合するァダブタ(250)が示されている。こ
の特許は、CPU間の情報転送をしやすくするのがその
目的の1つである。共有しうるデータ資源に対するアク
セスの衝突を解決するラツチ機構がこの特許の第5図に
示されている。これは強制メカニズムである。どのCP
Uでも、最初にラッチをセットしたものが、他のCPU
を排除する。D 発明が解決しようとする問題点然しな
がら、このような強制メカニズムを持つプロトコルは、
誤動作があった時に、システムの障害を発生し易い。
機能及びアダプタの設計にある。この種のシステムに使
える装置が米国特許第3400372号‘こ記載されて
いる。この特許には、端末装置を接続したチャネル間ァ
ダプタが示されている。この為、端末装置はどのチャネ
ルとも通信することが出来る。然し、このチャネル間ア
ダプタは共有資源の間の対等結合を容易にするようなも
のではない。米国特許第3934232号もこは、CP
Uサブシステム(100)を1/0サブシステム(20
0)に結合するァダブタ(250)が示されている。こ
の特許は、CPU間の情報転送をしやすくするのがその
目的の1つである。共有しうるデータ資源に対するアク
セスの衝突を解決するラツチ機構がこの特許の第5図に
示されている。これは強制メカニズムである。どのCP
Uでも、最初にラッチをセットしたものが、他のCPU
を排除する。D 発明が解決しようとする問題点然しな
がら、このような強制メカニズムを持つプロトコルは、
誤動作があった時に、システムの障害を発生し易い。
例えば、或るプロトコルはラッチをセットして、システ
ム内の或るCPUに対して資源のアクセスを認めると共
に、他のCPU全部を排除する。もし資源に対するアク
セスを許可されたCPUが、このラツチをリセットする
。(これによって資源がアンロックされる)前に故障す
るならば、保守技術員がこのラッチをリセットするのを
持っている間に、全部のCPUに対して資源が失われる
。従って、この発明の全般的な目的は、システムの1メ
ンバであるCPUが故障した場合に、システムの各CP
Uが資源からロックアウトされることを防止しつつ、資
源に対するアクセスを容易にする装置を提供することで
ある。
ム内の或るCPUに対して資源のアクセスを認めると共
に、他のCPU全部を排除する。もし資源に対するアク
セスを許可されたCPUが、このラツチをリセットする
。(これによって資源がアンロックされる)前に故障す
るならば、保守技術員がこのラッチをリセットするのを
持っている間に、全部のCPUに対して資源が失われる
。従って、この発明の全般的な目的は、システムの1メ
ンバであるCPUが故障した場合に、システムの各CP
Uが資源からロックアウトされることを防止しつつ、資
源に対するアクセスを容易にする装置を提供することで
ある。
この発明の別の目的は、複数個のCPUが資源を共有す
ることが出来るようにする装置を提供することである。
ることが出来るようにする装置を提供することである。
この発明の特定の目的は、共有プロセスでしなければな
らない仕事量を最小限に押えて、データ資源をCPUに
共有させる装麿を提供することである。E 問題点を解
決するための手段 データ・レコードの様な資源を多数のCPU、例えばC
PUIとCPU2で共有する多重プロセッサ環境では、
1つのCPUが所定の資源を排他的に使用(所有)しな
ければならないことがある。
らない仕事量を最小限に押えて、データ資源をCPUに
共有させる装麿を提供することである。E 問題点を解
決するための手段 データ・レコードの様な資源を多数のCPU、例えばC
PUIとCPU2で共有する多重プロセッサ環境では、
1つのCPUが所定の資源を排他的に使用(所有)しな
ければならないことがある。
ここに述べる実施例では、資源は複数個のセクションを
持つ1つのデータ・レコードと定義することが出来るが
、例えば1群のデータ・レコードというような別の定義
を用いてもよい。資源を共有するという問題の解決策は
数多くあり、その効果もさまざまである。この発明の解
決策は、資源を共有する為にしなければならない全体的
な仕事を管理し、資源共有プロセスでしなければならな
い付加的な仕事を少なくする。この発明の装置は、シス
テムの任意のCPUによって所有(管理)されるデータ
資源に対するアクセス要求の第1のCPUから受理する
。
持つ1つのデータ・レコードと定義することが出来るが
、例えば1群のデータ・レコードというような別の定義
を用いてもよい。資源を共有するという問題の解決策は
数多くあり、その効果もさまざまである。この発明の解
決策は、資源を共有する為にしなければならない全体的
な仕事を管理し、資源共有プロセスでしなければならな
い付加的な仕事を少なくする。この発明の装置は、シス
テムの任意のCPUによって所有(管理)されるデータ
資源に対するアクセス要求の第1のCPUから受理する
。
もし第1のCPUがそれまでに資源に対する所有権を持
っていなければ、この装置は、この要求に応答して資源
テーブルを索引し、そしてこの要求が第2のCPUによ
って所有される資源に対して衝突した場合にだけ、この
要求を衝突に関係する全ての所有CPUに送る。所有C
PUとは、既にその資源に対する所有権を持っていて、
資源共有フ。。トコルのメンバであるようなCPUを言
う。すべてのメンバ間の合意(肌ammity)規則を
適用して、所有CPUは、要求中のCPUに対し、この
発明の装置を通じて伝達される返答により、そのアクセ
ス要求を許可し、遅らせ、又は拒否する。この装置は資
源テーブルの必要な変更を行なう。前に述べたように、
所有CPUは資源共有プロトコルのメンバと定義するこ
とが出来る。
っていなければ、この装置は、この要求に応答して資源
テーブルを索引し、そしてこの要求が第2のCPUによ
って所有される資源に対して衝突した場合にだけ、この
要求を衝突に関係する全ての所有CPUに送る。所有C
PUとは、既にその資源に対する所有権を持っていて、
資源共有フ。。トコルのメンバであるようなCPUを言
う。すべてのメンバ間の合意(肌ammity)規則を
適用して、所有CPUは、要求中のCPUに対し、この
発明の装置を通じて伝達される返答により、そのアクセ
ス要求を許可し、遅らせ、又は拒否する。この装置は資
源テーブルの必要な変更を行なう。前に述べたように、
所有CPUは資源共有プロトコルのメンバと定義するこ
とが出来る。
予定の資源共有プロトコルのすべてのメンバが、この発
明の装置を使う事が出来る。資源共有プ。トコルのメン
バは、どんなものであっても、そのプロトコルの規則を
遵守しなければならない。この発明の実施例では強制メ
カニズムがないから、これは資源共有プロトコルのメン
バであるCPUをプログラムする者の合意によらなけれ
ばならない。前述のように、この発明では、強制メカニ
ズムを使わずに、自発的な資源共有プロトコルを使う。
衝突の解決は、合意された予定の資源共有プロトコルに
従って、もっぱら各CPUによって処理される。この発
明では衝突の通知は衝突の解決とは切離される。これは
ここに挙げた従来の特許に見られない特徴である。F
実施例 FI システム構成(第1図) 第1図のシステムでは、4つのCPU1,2,3,4が
示されている。
明の装置を使う事が出来る。資源共有プ。トコルのメン
バは、どんなものであっても、そのプロトコルの規則を
遵守しなければならない。この発明の実施例では強制メ
カニズムがないから、これは資源共有プロトコルのメン
バであるCPUをプログラムする者の合意によらなけれ
ばならない。前述のように、この発明では、強制メカニ
ズムを使わずに、自発的な資源共有プロトコルを使う。
衝突の解決は、合意された予定の資源共有プロトコルに
従って、もっぱら各CPUによって処理される。この発
明では衝突の通知は衝突の解決とは切離される。これは
ここに挙げた従来の特許に見られない特徴である。F
実施例 FI システム構成(第1図) 第1図のシステムでは、4つのCPU1,2,3,4が
示されている。
各CPUはIEF1,IEF2,IEF3,IEF4と
呼ばれる内部照会装置(lntemaIEnqueue
Facilitvty:IEF)を持っている。IEF
はCPUの内部のあるハードウェア及び/又はフ。。グ
ラミングである。IEFのユーザは、このIEFに関連
するCPUの内部プログラムである。IEFの1つの機
能は、そのユーザー・プログラムからの資源に対するア
クセス要求を受理し、それを許可するか、或いはその資
源に対するアクセスを許可する為に必要な措置をとるこ
とである。各CPUは、そのIEFを介して、外部照会
装置(E幻ernaIEnqueueFacility
.EEF)5にも接続される。従って、IEFは、その
データを供給し且つ管理を実行するプログラミング及び
ハードウェアを用いて、EEF5を介して互いに通信す
ることが出来る。後で詳しく説明するが、EEF5は、
1つ以上のIEFがその1つ以上のユーザー・プログラ
ムの為に要求する資源とのアクセスを容易にする。
呼ばれる内部照会装置(lntemaIEnqueue
Facilitvty:IEF)を持っている。IEF
はCPUの内部のあるハードウェア及び/又はフ。。グ
ラミングである。IEFのユーザは、このIEFに関連
するCPUの内部プログラムである。IEFの1つの機
能は、そのユーザー・プログラムからの資源に対するア
クセス要求を受理し、それを許可するか、或いはその資
源に対するアクセスを許可する為に必要な措置をとるこ
とである。各CPUは、そのIEFを介して、外部照会
装置(E幻ernaIEnqueueFacility
.EEF)5にも接続される。従って、IEFは、その
データを供給し且つ管理を実行するプログラミング及び
ハードウェアを用いて、EEF5を介して互いに通信す
ることが出来る。後で詳しく説明するが、EEF5は、
1つ以上のIEFがその1つ以上のユーザー・プログラ
ムの為に要求する資源とのアクセスを容易にする。
前に述べたように、この発明のシステムでは、資源共有
フ。。トコルが使われる。EEFはこの資源共有プロト
コルの実行を容易にする装置であって、このプロトコル
を実行する装置ではない。云いかえれば、EEFはこの
資源共有プロトコルを実現する為に使う事が出来る道具
である。資源共有フ。ロトコルは、それに伴なう規則お
共に、システム内の各CPUにプログラムされるのが普
通である。一般に、EEFは階層形資源構造について動
作するが、階層形構造にする必要のない程、資源が十分
に定義されている場合も考えられる。
フ。。トコルが使われる。EEFはこの資源共有プロト
コルの実行を容易にする装置であって、このプロトコル
を実行する装置ではない。云いかえれば、EEFはこの
資源共有プロトコルを実現する為に使う事が出来る道具
である。資源共有フ。ロトコルは、それに伴なう規則お
共に、システム内の各CPUにプログラムされるのが普
通である。一般に、EEFは階層形資源構造について動
作するが、階層形構造にする必要のない程、資源が十分
に定義されている場合も考えられる。
基本的には、EEFは、次のように資源を管理する。川
ある資源に対する実際の衝突が起った場合にだけ、シ
ステム内の通信を行なわしめる。【2} 衝突が起った
場合は、この衝突に関係する資源の所有CPUだけを、
衝突を解決する為の通信に関与させる。
ある資源に対する実際の衝突が起った場合にだけ、シ
ステム内の通信を行なわしめる。【2} 衝突が起った
場合は、この衝突に関係する資源の所有CPUだけを、
衝突を解決する為の通信に関与させる。
資源はシステム内の適宜に定義した任意のェンテイテイ
であってよい。
であってよい。
それは1つのデータ・レコードである場合が多いが、場
合によっては、1つのデータ・レコード内の1フィール
ドとして更に狭く定義されていてもよい。資源を後者の
ように定義した場合、そのアクセスを希望するのがシス
テム内の1つのCPUで、その所有権を持つのが別のC
PUであることがある。或るCPUによって資源が要求
される場合、この要求は関連するIEFに設けられた資
源共有プロトコルの資源クラス決定アルゴリズムによっ
て、1つの資源クラスに変換される。もしこのmFのC
PUが当該資源クラスを既に「所有」していなければ、
このIEFはEEFからこの資源クラスを要求する。シ
ステム内の各IEFは同じ資源クラス決定アルゴリズム
を持っている。このアルゴリズムの1例はハッシュ・プ
ログラムであり、それについて記述した文献は数多くあ
る。F2 資源クラス(第2図) 資源クラスの1例が第2図に示されている。
合によっては、1つのデータ・レコード内の1フィール
ドとして更に狭く定義されていてもよい。資源を後者の
ように定義した場合、そのアクセスを希望するのがシス
テム内の1つのCPUで、その所有権を持つのが別のC
PUであることがある。或るCPUによって資源が要求
される場合、この要求は関連するIEFに設けられた資
源共有プロトコルの資源クラス決定アルゴリズムによっ
て、1つの資源クラスに変換される。もしこのmFのC
PUが当該資源クラスを既に「所有」していなければ、
このIEFはEEFからこの資源クラスを要求する。シ
ステム内の各IEFは同じ資源クラス決定アルゴリズム
を持っている。このアルゴリズムの1例はハッシュ・プ
ログラムであり、それについて記述した文献は数多くあ
る。F2 資源クラス(第2図) 資源クラスの1例が第2図に示されている。
この例のデータ・レコードは製品構造に関係すると仮定
することが出来る。例えば、貯蔵装置内の1つのレコー
ドが木材製品に関する情報を持ち、別のレコートが軸受
に関する情報を持つと考えてよい。更に木材製品はリト
ルリーグ用野球バット又は正規の野球バットに分けられ
よう。木材製品は斧の短かし、柄又は斧の長い柄のこと
もあろう。これに対して軸受はころ軸受、玉軸受、又は
ニードル軸受であってよい。資源クラス決定アルゴリズ
ムは、1つより多くの資源を1つの資源クラスに関係づ
けることが出来るし、そうするのが普通である。例えば
第2図に見られるように、木材製品及び軸受が同じ資源
クラス、即ちこの場合は資源クラス×に関係づけられて
いる。つまり、資源クラス×は木材製品を意味すること
も、軸受を意味することもある。資源クラス決定アルゴ
リズムの基本的な性質は、それが資源共有プロトコルの
全てのメンバに対して終始一貫していることである。こ
のアルゴリズムはどんな形でもよいが、これは「平坦」
な分布を与えるようなものにすべきである。即ち、任意
の資源クラスの使われ方が、他のすべてに対しても大体
同じになるようにすべきである。この様なアルゴリズム
は周知であるし、この発明の一部分を構成するものでも
ない。F3 全般的な動作(第3図)EEFの広汎な動
作の一例が第3図のフローチャートに示されている。
することが出来る。例えば、貯蔵装置内の1つのレコー
ドが木材製品に関する情報を持ち、別のレコートが軸受
に関する情報を持つと考えてよい。更に木材製品はリト
ルリーグ用野球バット又は正規の野球バットに分けられ
よう。木材製品は斧の短かし、柄又は斧の長い柄のこと
もあろう。これに対して軸受はころ軸受、玉軸受、又は
ニードル軸受であってよい。資源クラス決定アルゴリズ
ムは、1つより多くの資源を1つの資源クラスに関係づ
けることが出来るし、そうするのが普通である。例えば
第2図に見られるように、木材製品及び軸受が同じ資源
クラス、即ちこの場合は資源クラス×に関係づけられて
いる。つまり、資源クラス×は木材製品を意味すること
も、軸受を意味することもある。資源クラス決定アルゴ
リズムの基本的な性質は、それが資源共有プロトコルの
全てのメンバに対して終始一貫していることである。こ
のアルゴリズムはどんな形でもよいが、これは「平坦」
な分布を与えるようなものにすべきである。即ち、任意
の資源クラスの使われ方が、他のすべてに対しても大体
同じになるようにすべきである。この様なアルゴリズム
は周知であるし、この発明の一部分を構成するものでも
ない。F3 全般的な動作(第3図)EEFの広汎な動
作の一例が第3図のフローチャートに示されている。
この図で、CPUNがその1つプログラムで使う為に、
特定の資源を必要とすると仮定する。CPUN自体は、
その内部の資源クラス決定アルゴリズム(これは前述の
様にシステムの全てのCPUが使うものと同じである)
を使って、この資源を資源クラスXに変換.(写像)す
る。もしCPUNが資源クラス×を現に「所有」してい
なければ、これはEEFにメッセージを送り、資源クラ
スXのアクセスを要求する。この場合、EEFは、何れ
かのCPUが資源クラス×を所有しているかどうかを判
定する。もしどのCPUも所有していなければ、EEF
は、資源クラスXのCPUNによって所有されると、マ
−クし、そしてCPUNにアクセスを許可する。他方、
CPUN以外の1つ以上のCPUが資源クラスXを所有
する場合、EEFは、かかるCPUを識別する資源テー
ブルを参照して、その所有CPUだけに要求を送り、ア
クセスを許可してよいかどうかについて、所有CPUか
らの返答を待つ。所有CPUからの全てのメッセージを
受取った時、EEFは適当なメッセージをCPUNに送
る。この適当なメッセージは、要求中のCPU Nに対
して、資源クラスXに対する完全なアクセスを許可して
よい、ということもあろうし、所有CPUがCPUNに
資源クラス×の一部分に対するアクセスは許すが、その
全体に対するアクセスは許さない、ということもあろう
。これは後で詳しく説明する。要求中CPUNは、資源
共有プロトコルに従って、この応答に対して作用する。
要求中CPUNがもはやこの資源を必要としなくなった
場合、CPUNはEEFにメッセージを送ってこの資源
をアンロックする。この結果、EEFを介しての通信ト
ラヒツクは全くないこ又はごく少なくて、この資源を他
のCPUが使うことが出来る。F4EEFの構成(第4
図)この発明のEEFの一例が第4図に示されている。
特定の資源を必要とすると仮定する。CPUN自体は、
その内部の資源クラス決定アルゴリズム(これは前述の
様にシステムの全てのCPUが使うものと同じである)
を使って、この資源を資源クラスXに変換.(写像)す
る。もしCPUNが資源クラス×を現に「所有」してい
なければ、これはEEFにメッセージを送り、資源クラ
スXのアクセスを要求する。この場合、EEFは、何れ
かのCPUが資源クラス×を所有しているかどうかを判
定する。もしどのCPUも所有していなければ、EEF
は、資源クラスXのCPUNによって所有されると、マ
−クし、そしてCPUNにアクセスを許可する。他方、
CPUN以外の1つ以上のCPUが資源クラスXを所有
する場合、EEFは、かかるCPUを識別する資源テー
ブルを参照して、その所有CPUだけに要求を送り、ア
クセスを許可してよいかどうかについて、所有CPUか
らの返答を待つ。所有CPUからの全てのメッセージを
受取った時、EEFは適当なメッセージをCPUNに送
る。この適当なメッセージは、要求中のCPU Nに対
して、資源クラスXに対する完全なアクセスを許可して
よい、ということもあろうし、所有CPUがCPUNに
資源クラス×の一部分に対するアクセスは許すが、その
全体に対するアクセスは許さない、ということもあろう
。これは後で詳しく説明する。要求中CPUNは、資源
共有プロトコルに従って、この応答に対して作用する。
要求中CPUNがもはやこの資源を必要としなくなった
場合、CPUNはEEFにメッセージを送ってこの資源
をアンロックする。この結果、EEFを介しての通信ト
ラヒツクは全くないこ又はごく少なくて、この資源を他
のCPUが使うことが出来る。F4EEFの構成(第4
図)この発明のEEFの一例が第4図に示されている。
この図に見られる様に、EEFは、システム内のどのC
PUが所定の資源クラスの所有権を持っているかを示す
資源テーブル37を持っている。例えば、資源クラスA
に或るレベルCPUI及びCPU2によって同時に所有
(ロック)され、資源クラスBはCPU2及びCPU3
によって同時に所有されている、という具合である。資
源テーブル37中の各CPUに対応するロック列はゼロ
検出器25に接続され、同じくゲート23にも接続され
る。システム内の要求中CPUからのアクセス要求をE
EHこ伝達する母線9は復号器11に接続され、該復号
器は要求された所定の資源クラスのアドレスを復号する
。母線9上の要求は、要求中CPU(又はそのmF)の
アドレスをも持っていてよい。母線9はゲート15,1
7,19,21に個別に接続され、これらのゲートには
ゲート23の出力も接続されている。資源テーフル37
中のロック列は、システムのメンバCPUからの信号を
適当に復号することにより、個別にセット又はリセット
される。資源テーブル37の所定の行をアクセスした場
合、その行が資源テーブル37から謙出され、ゲート2
3及びゼロ検出器25の入力になる。もし所定の資源ク
ラス、例えば資源クラスBに対して読出された行が全部
ゼロであれば、これは資源クラスBを所有しているCP
Uが存在しないことを表わす。この場合、ゼロ検出器2
5の線27が付勢される。これは要求中CPU‘こ対し
、該CPUが資源クラスBをロックしてよい、という表
示として、直接的に送ることが出来る。EEFに対する
始めのメッセージ中にあるCPUアドレス(又はIEF
アドレス)を使って、この信号を要求中のCPUへ送信
させることが出釆るが、これは周知の方法で行なうこと
ができる。また、この同じアドレスを復号器12で使っ
て、線30上の信号を現在アドレスされている資源テー
ブル37の行の適当なCPU列に与えることにより、そ
の資源を今や要求中CPUが所有するとマークする、す
なわちロックすることが出来る。所定の資源クラス例え
ば、資源クラスBに対して謙出された行が全部ゼロでは
なければ、これは、1つ以上のCPUが資源クラスBを
所有していることを表わす。
PUが所定の資源クラスの所有権を持っているかを示す
資源テーブル37を持っている。例えば、資源クラスA
に或るレベルCPUI及びCPU2によって同時に所有
(ロック)され、資源クラスBはCPU2及びCPU3
によって同時に所有されている、という具合である。資
源テーブル37中の各CPUに対応するロック列はゼロ
検出器25に接続され、同じくゲート23にも接続され
る。システム内の要求中CPUからのアクセス要求をE
EHこ伝達する母線9は復号器11に接続され、該復号
器は要求された所定の資源クラスのアドレスを復号する
。母線9上の要求は、要求中CPU(又はそのmF)の
アドレスをも持っていてよい。母線9はゲート15,1
7,19,21に個別に接続され、これらのゲートには
ゲート23の出力も接続されている。資源テーフル37
中のロック列は、システムのメンバCPUからの信号を
適当に復号することにより、個別にセット又はリセット
される。資源テーブル37の所定の行をアクセスした場
合、その行が資源テーブル37から謙出され、ゲート2
3及びゼロ検出器25の入力になる。もし所定の資源ク
ラス、例えば資源クラスBに対して読出された行が全部
ゼロであれば、これは資源クラスBを所有しているCP
Uが存在しないことを表わす。この場合、ゼロ検出器2
5の線27が付勢される。これは要求中CPU‘こ対し
、該CPUが資源クラスBをロックしてよい、という表
示として、直接的に送ることが出来る。EEFに対する
始めのメッセージ中にあるCPUアドレス(又はIEF
アドレス)を使って、この信号を要求中のCPUへ送信
させることが出釆るが、これは周知の方法で行なうこと
ができる。また、この同じアドレスを復号器12で使っ
て、線30上の信号を現在アドレスされている資源テー
ブル37の行の適当なCPU列に与えることにより、そ
の資源を今や要求中CPUが所有するとマークする、す
なわちロックすることが出来る。所定の資源クラス例え
ば、資源クラスBに対して謙出された行が全部ゼロでは
なければ、これは、1つ以上のCPUが資源クラスBを
所有していることを表わす。
この場合、ゼロ検出器25の線28が付勢され、資源テ
ーブル37から行Bの内容をゲート15,17,19,
21へ通す。これらのゲートは、要求中CPUからの要
求を、資源クラスBを所有している特定のCPUへ通す
。この例では、要求がCPU2及びCPU3へ送られる
。これらのCPUの伍Fは、これから説明するようにし
て、この要に対して作用する。この資源クラスを所有す
る各々のCPUによってこの要求に対する応答が構成さ
れ、応答アセンブル・レジスタ36に送り返される。こ
のレジスタの内容は母線50を介して要求中CPUへ送
られ、そのIEFにより、要求した資源に体するアクセ
スの許可又は拒否として解釈される。F51EFの構成
(第5図) 也Fの1つの機能は、EEFからの資源に対するアクセ
ス要求に応答出釆るように、そのCPUがどの資源を所
有しているかを表示することである。
ーブル37から行Bの内容をゲート15,17,19,
21へ通す。これらのゲートは、要求中CPUからの要
求を、資源クラスBを所有している特定のCPUへ通す
。この例では、要求がCPU2及びCPU3へ送られる
。これらのCPUの伍Fは、これから説明するようにし
て、この要に対して作用する。この資源クラスを所有す
る各々のCPUによってこの要求に対する応答が構成さ
れ、応答アセンブル・レジスタ36に送り返される。こ
のレジスタの内容は母線50を介して要求中CPUへ送
られ、そのIEFにより、要求した資源に体するアクセ
スの許可又は拒否として解釈される。F51EFの構成
(第5図) 也Fの1つの機能は、EEFからの資源に対するアクセ
ス要求に応答出釆るように、そのCPUがどの資源を所
有しているかを表示することである。
mFの別の機能は、自分のユーザ・プログラムからの資
源の要求に応答することである。即ち、そのCPUのユ
ーザ・プログラムに対し、mFはEEFとして機能する
。システムの各CPUで使えるEFの一例が第5図に示
されている。第5図にはCPUIのmFIが示されてお
り、これはそれ自体の資源テーブル47を持っている。
資源テーブル47のロック列にある記入事項は、第4図
のEEFの資源テーブル37に記入されたものと同様に
、CPUIが資源クラスA、C、X、Zをロックしてい
ること、即ちその所有権を持っていることを示す。資源
テーブル47には、資源名称/所有者の列もある。この
列は、ユーザ・プログラムが資源クラスをを使う時の資
源の名称と、そのユーザ・プログラムの識別符号とを表
わしている。例えば、第2図の例で言うと、CPUIの
ユーザ・プログラム4は、野球バットに関する資源を使
うことがあろう。その場合、資源の名称は木材製品・野
球バット(WP/BB)である。これは、IEFIと関
連している第4図の資源クラス決定アルゴリズム49に
より、資源クラスXに変換される。この為、資源クラス
Xに対する資源名称ノ所有者列の記入項目は(WP/B
B、4)になる。この列は幾つかの記入項目を持つ位に
広いと観てよい。例えば、ユーザー・プログラム5がニ
ードル軸受に関する資源を使っている場合、資源の名称
は軸受・ニードル(B/N)になろう。これも資源クラ
ス×に変換されよう。この為、資源クラスXの資源名称
/所有者列の記入項目は(WP/BB、4)と(B/N
、5)になり、ロックされた資源クラスXが木材製品の
内の野球バットのサブクラスを使っているユーザ・プロ
グラム4と、軸受の内のニードル軸受のサブクラスを使
っているユーザ・プログラム5とによって使用中である
ことが表示される。資源クラス決定アルゴリズム49に
よって資源クラスXに変換された資源の名称と、この資
源を使用しているユーザ・プログラムの識別符号をマー
クする機構も、第5図に示されている。或るユーザ・プ
ログラムからの要求は、全体を54で示した母線の1つ
を介して伝達され、資源クラス決定アルゴリズム49に
入る。これらの母線はオア・ゲート51にも接続され、
その出力母線53は資源テーブル47の資源名称/所有
者列を構成するラッチに接続される。ここで、ユーザ・
プログラム4からのアクセス要求として、木材製品、野
球バットが母線55を介して伝達されたと仮定する。今
の例に従って、この資源は資源クラスXに変換される。
資源クラスXの識別符号が母線55′を介して復号器5
7へ送られ、そこで、資源クラス×の為に予約されてい
る資源テーブル47のアドレスに複号される。アルゴリ
ズム49及び復号器57が整定する為の適当な遅延時間
の後、母線53を介して、(WP/BB、4)の符号を
、資源テーブル47の資源名称/所有者列の内の資源ク
ラス×に対して復号されたアドレスに設定することが出
来る。
源の要求に応答することである。即ち、そのCPUのユ
ーザ・プログラムに対し、mFはEEFとして機能する
。システムの各CPUで使えるEFの一例が第5図に示
されている。第5図にはCPUIのmFIが示されてお
り、これはそれ自体の資源テーブル47を持っている。
資源テーブル47のロック列にある記入事項は、第4図
のEEFの資源テーブル37に記入されたものと同様に
、CPUIが資源クラスA、C、X、Zをロックしてい
ること、即ちその所有権を持っていることを示す。資源
テーブル47には、資源名称/所有者の列もある。この
列は、ユーザ・プログラムが資源クラスをを使う時の資
源の名称と、そのユーザ・プログラムの識別符号とを表
わしている。例えば、第2図の例で言うと、CPUIの
ユーザ・プログラム4は、野球バットに関する資源を使
うことがあろう。その場合、資源の名称は木材製品・野
球バット(WP/BB)である。これは、IEFIと関
連している第4図の資源クラス決定アルゴリズム49に
より、資源クラスXに変換される。この為、資源クラス
Xに対する資源名称ノ所有者列の記入項目は(WP/B
B、4)になる。この列は幾つかの記入項目を持つ位に
広いと観てよい。例えば、ユーザー・プログラム5がニ
ードル軸受に関する資源を使っている場合、資源の名称
は軸受・ニードル(B/N)になろう。これも資源クラ
ス×に変換されよう。この為、資源クラスXの資源名称
/所有者列の記入項目は(WP/BB、4)と(B/N
、5)になり、ロックされた資源クラスXが木材製品の
内の野球バットのサブクラスを使っているユーザ・プロ
グラム4と、軸受の内のニードル軸受のサブクラスを使
っているユーザ・プログラム5とによって使用中である
ことが表示される。資源クラス決定アルゴリズム49に
よって資源クラスXに変換された資源の名称と、この資
源を使用しているユーザ・プログラムの識別符号をマー
クする機構も、第5図に示されている。或るユーザ・プ
ログラムからの要求は、全体を54で示した母線の1つ
を介して伝達され、資源クラス決定アルゴリズム49に
入る。これらの母線はオア・ゲート51にも接続され、
その出力母線53は資源テーブル47の資源名称/所有
者列を構成するラッチに接続される。ここで、ユーザ・
プログラム4からのアクセス要求として、木材製品、野
球バットが母線55を介して伝達されたと仮定する。今
の例に従って、この資源は資源クラスXに変換される。
資源クラスXの識別符号が母線55′を介して復号器5
7へ送られ、そこで、資源クラス×の為に予約されてい
る資源テーブル47のアドレスに複号される。アルゴリ
ズム49及び復号器57が整定する為の適当な遅延時間
の後、母線53を介して、(WP/BB、4)の符号を
、資源テーブル47の資源名称/所有者列の内の資源ク
ラス×に対して復号されたアドレスに設定することが出
来る。
F6EEFからの要求(第5図)第5図には、第4図の
EEFからの要求をIEFに伝達する母線38も示され
ている。
EEFからの要求をIEFに伝達する母線38も示され
ている。
前に述べた様に、この要求は要求された資源クラス、所
望の資源の名称、及び要求中CPU(又はそのIEF)
のアドレスを含んでいる。母線38は復号器57に接続
される。要求中CPUは既に所望の資源を1つの資源ク
ラスに変換しているから、あらためて資源クラス決定ア
ルゴリズム49を経由する必要はない。従って、資源ク
ラス決定ァルゴリズム49の出力が接続されるのと同じ
目的の為に、母線38が復号器57に直接接続される。
母線38から、母線81がプロトコル論理装置70‘こ
接続され、後でプロトコル論理装置70で使う為、所望
の資源の名称を伝達する。母線38は、要求が活勢であ
る時に付勢される線61を含んでいてもよい。線61は
アンド・ゲート66に接続され、このアンド・ゲートの
他方の入力は、復号器57の出力によってアドレスされ
た行のロック列から釆る。アンド・ゲート66の出力は
ゼロ検出器67に接続される。線61はィンバータを介
してアンド・ゲート71にも接続される。アンド・ゲー
トTIの他方の入力もロック列から来る。アンド・ゲー
ト71の出力は、ゼロ検出器73に接続される。要求は
EEFから来るのであるから、これは母線38に生じ、
そして復号器57の出力が資源テーブル47の所望の行
をアドレスする。
望の資源の名称、及び要求中CPU(又はそのIEF)
のアドレスを含んでいる。母線38は復号器57に接続
される。要求中CPUは既に所望の資源を1つの資源ク
ラスに変換しているから、あらためて資源クラス決定ア
ルゴリズム49を経由する必要はない。従って、資源ク
ラス決定ァルゴリズム49の出力が接続されるのと同じ
目的の為に、母線38が復号器57に直接接続される。
母線38から、母線81がプロトコル論理装置70‘こ
接続され、後でプロトコル論理装置70で使う為、所望
の資源の名称を伝達する。母線38は、要求が活勢であ
る時に付勢される線61を含んでいてもよい。線61は
アンド・ゲート66に接続され、このアンド・ゲートの
他方の入力は、復号器57の出力によってアドレスされ
た行のロック列から釆る。アンド・ゲート66の出力は
ゼロ検出器67に接続される。線61はィンバータを介
してアンド・ゲート71にも接続される。アンド・ゲー
トTIの他方の入力もロック列から来る。アンド・ゲー
ト71の出力は、ゼロ検出器73に接続される。要求は
EEFから来るのであるから、これは母線38に生じ、
そして復号器57の出力が資源テーブル47の所望の行
をアドレスする。
この要求は外部の要求であるから、この時線61が活勢
であり、アンド・ゲート66を条件づける。従って、ア
ドレスされた行のロック・ビットがアンド・ゲート66
を介してゼロ検出器67へ送られる。もしこのロック・
ビットがゼロであれば、要求された資源クラスがこのI
EFによってロックされていない、ということである。
従って、線68はプロトコル論理装置70を条件づける
ことにより、このmFに関する限り、要求を許可するこ
とが出来るという応答をEEFに送らせる。もしロック
・ビットが1であれば、このIEFが要求された資源ク
ラスをロックしていることを表わす。この場合、線79
Aがゲート60を条件づけ、要求された資源クラスの内
、このIEFがロックしているサブクラスを表わす資源
の名称を通す。もし、資源共有プロトコルが許せば、プ
ロトコル論理装置70は、このIEFに関する限り、要
求された資源クラスの任意のもの(即ち、。ックされて
いない資源の名称)に対するアクセスを許可することが
出来るかどうかを表わす応答をEEFに送る。このやり
方は後で説明する。F7 ユーザ・プログラムからの要
求(第5図)全般的な動作で、適当な時点を仮定すると
、復号器57がユーザ・プログラムからの資源に対する
アクセス要求を復号している場合、線61は不宿勢であ
る。
であり、アンド・ゲート66を条件づける。従って、ア
ドレスされた行のロック・ビットがアンド・ゲート66
を介してゼロ検出器67へ送られる。もしこのロック・
ビットがゼロであれば、要求された資源クラスがこのI
EFによってロックされていない、ということである。
従って、線68はプロトコル論理装置70を条件づける
ことにより、このmFに関する限り、要求を許可するこ
とが出来るという応答をEEFに送らせる。もしロック
・ビットが1であれば、このIEFが要求された資源ク
ラスをロックしていることを表わす。この場合、線79
Aがゲート60を条件づけ、要求された資源クラスの内
、このIEFがロックしているサブクラスを表わす資源
の名称を通す。もし、資源共有プロトコルが許せば、プ
ロトコル論理装置70は、このIEFに関する限り、要
求された資源クラスの任意のもの(即ち、。ックされて
いない資源の名称)に対するアクセスを許可することが
出来るかどうかを表わす応答をEEFに送る。このやり
方は後で説明する。F7 ユーザ・プログラムからの要
求(第5図)全般的な動作で、適当な時点を仮定すると
、復号器57がユーザ・プログラムからの資源に対する
アクセス要求を復号している場合、線61は不宿勢であ
る。
資源クラス決定アルゴリズム49がユーザ・プログラム
からの要求を1つの資源クラスに変換した後、復号器5
7はこの資源クラスを持つ資源テーブル47内の行をア
ドレスする。線61は不活勢である(ユーザ・プログラ
ムの要求であって、EEFからの要求ではない)から、
線72が活勢となり、アドレスされた行のロック・ビッ
トがァンド・ゲート71を介してゼロ検出器73に送ら
れる。もしこのビットがゼロであれば、このIEF(具
体的にはそのCPUのユーザ・プログラム。
からの要求を1つの資源クラスに変換した後、復号器5
7はこの資源クラスを持つ資源テーブル47内の行をア
ドレスする。線61は不活勢である(ユーザ・プログラ
ムの要求であって、EEFからの要求ではない)から、
線72が活勢となり、アドレスされた行のロック・ビッ
トがァンド・ゲート71を介してゼロ検出器73に送ら
れる。もしこのビットがゼロであれば、このIEF(具
体的にはそのCPUのユーザ・プログラム。
以下同じ。)は要求された資源クラスを所有していない
。従って、このIEFのアドレスと要求されて資源クラ
ス及び資源の名称を含む要求(その形で後で詳しく説明
する)が、要求アセンブリ・レジスタ77で組立てられ
、母線9を介してEEFに送られて、要求中のユーザ・
プログラムに対し、このIEFが当該資源クラスを或る
レベルでロックすることが出来るかどうかを決定する。
もしロック・ビットが1であれば、ゼロ検出器73の非
ゼロ出力が線74を付勢する。
。従って、このIEFのアドレスと要求されて資源クラ
ス及び資源の名称を含む要求(その形で後で詳しく説明
する)が、要求アセンブリ・レジスタ77で組立てられ
、母線9を介してEEFに送られて、要求中のユーザ・
プログラムに対し、このIEFが当該資源クラスを或る
レベルでロックすることが出来るかどうかを決定する。
もしロック・ビットが1であれば、ゼロ検出器73の非
ゼロ出力が線74を付勢する。
つまり、要求れた資源クラスがこのIEFによって所有
されている、ということである。この要求は内部のユー
ザ・プログラムから出たものであるから、プロトコル論
理装置70から線80を介して、ユーザ・プログラムに
対して要求を許可することが出来る。利用し得る資源共
有プロトコルは後で説明する。線80が付勢されると、
要求が許可される。F8 EEFからIEFへの応答(
第4図−第6図)前段で述べた様に、要求中CPUのI
EFが要求アセンブリ・レジスタ77を介してEEFに
要求を送った場合、第4図に示したEEFの応答アセン
ブリ・レジスタ36によって、最終的な応答が組立てら
れる。
されている、ということである。この要求は内部のユー
ザ・プログラムから出たものであるから、プロトコル論
理装置70から線80を介して、ユーザ・プログラムに
対して要求を許可することが出来る。利用し得る資源共
有プロトコルは後で説明する。線80が付勢されると、
要求が許可される。F8 EEFからIEFへの応答(
第4図−第6図)前段で述べた様に、要求中CPUのI
EFが要求アセンブリ・レジスタ77を介してEEFに
要求を送った場合、第4図に示したEEFの応答アセン
ブリ・レジスタ36によって、最終的な応答が組立てら
れる。
この応答は、要求中mFのアドレスを使って、母線50
を介して要求中IEFに送られる。このアドレスは応答
に入れることが出釆る。この応答は母線50を通って、
第5図の許可/拒否論理装置へ送られ、そこで解釈され
る。この論理装置の一例を第6図に示す。第6図にはI
EFIからとIEF4からとの2つの応答に対する論理
装置が示されている。これは任意の数の応答に拡大する
ことが出釆る。第6図において、位置1は、応答中IE
Fが、資源クラス×に対するアクセスをどんな制御レベ
ルでも許可することが出来ないことを示す。位置2は、
要求が応答中IEFによって完全に許可されることを示
す。従って、応答の各々の位置2がアンド・ゲート81
に接続される。各々の応答が完全なアクセスを許可した
場合、許可線が付勢され、要求を許可すると共に、資源
テーブル47の資源クラス×をロックする。各々の位置
1はオア・ゲート83に接続される。何れかの応答中I
EFがどの制御レベルでもアクセスを許可出釆ない場合
、出し直し線がユーザ・プログラムに対して付勢され、
この場合ユーザ・プログラムは後の時点でその要求を出
し直すことが出来る。F9 動作の説明(第4図、第5
図) 次に図面を参照して、この発明の動作の詳細を一例につ
いて説明する。
を介して要求中IEFに送られる。このアドレスは応答
に入れることが出釆る。この応答は母線50を通って、
第5図の許可/拒否論理装置へ送られ、そこで解釈され
る。この論理装置の一例を第6図に示す。第6図にはI
EFIからとIEF4からとの2つの応答に対する論理
装置が示されている。これは任意の数の応答に拡大する
ことが出釆る。第6図において、位置1は、応答中IE
Fが、資源クラス×に対するアクセスをどんな制御レベ
ルでも許可することが出来ないことを示す。位置2は、
要求が応答中IEFによって完全に許可されることを示
す。従って、応答の各々の位置2がアンド・ゲート81
に接続される。各々の応答が完全なアクセスを許可した
場合、許可線が付勢され、要求を許可すると共に、資源
テーブル47の資源クラス×をロックする。各々の位置
1はオア・ゲート83に接続される。何れかの応答中I
EFがどの制御レベルでもアクセスを許可出釆ない場合
、出し直し線がユーザ・プログラムに対して付勢され、
この場合ユーザ・プログラムは後の時点でその要求を出
し直すことが出来る。F9 動作の説明(第4図、第5
図) 次に図面を参照して、この発明の動作の詳細を一例につ
いて説明する。
CPUIが、例えば更新の為にtニードル軸受資源」を
使っていると仮定する。
使っていると仮定する。
この場合、第5図に示したのと同様なCPU1のmFに
設けられた資源クラス決定アルゴリズムが、第2図の例
で述べた様に、「ニードル軸受」を資源クラスXに変換
し、第4図の資源テーブル37のうち資源クラスXのC
PUIの列に1をセットすることにより、資源クラスX
の所有権をCPUIが持ったことをマークする(即ち、
資源クラスXをロックする)。この時、CPU2が、例
えば「リトルリーグ野球バット」をアクセスしたければ
、CPU2はこの資源をロックしなければならない。従
って、CPU2に関連するmF2は、「木材製品」を資
源クラスXに変換する。というのは、第2図の例では、
資源クラス決定アルゴリズム49が「木材製品」及び「
軸受」の両方を資源クラスXへ変換するからである。I
EF2の資源テーブル47の資源クラスXで、ロック・
ビットがゼロであると仮定すると、伍F2は、その要求
アセンブリ・レジスタ77で、下記の形ロックX、mF
2、木材製品・野球バット・リトルリーグの2つの部分
から成る、EEFへのアクセス要求を構成する。
設けられた資源クラス決定アルゴリズムが、第2図の例
で述べた様に、「ニードル軸受」を資源クラスXに変換
し、第4図の資源テーブル37のうち資源クラスXのC
PUIの列に1をセットすることにより、資源クラスX
の所有権をCPUIが持ったことをマークする(即ち、
資源クラスXをロックする)。この時、CPU2が、例
えば「リトルリーグ野球バット」をアクセスしたければ
、CPU2はこの資源をロックしなければならない。従
って、CPU2に関連するmF2は、「木材製品」を資
源クラスXに変換する。というのは、第2図の例では、
資源クラス決定アルゴリズム49が「木材製品」及び「
軸受」の両方を資源クラスXへ変換するからである。I
EF2の資源テーブル47の資源クラスXで、ロック・
ビットがゼロであると仮定すると、伍F2は、その要求
アセンブリ・レジスタ77で、下記の形ロックX、mF
2、木材製品・野球バット・リトルリーグの2つの部分
から成る、EEFへのアクセス要求を構成する。
下線を施した部分は命令部分であり、もしEEFの資源
テーブル37で資源クラスXに対する所有権がなければ
、CPU2が、これ以上の通信トラヒックを必要とせず
に、第4図の線27を介して、自動的に所有権を得るこ
とをEEFに知らせる。
テーブル37で資源クラスXに対する所有権がなければ
、CPU2が、これ以上の通信トラヒックを必要とせず
に、第4図の線27を介して、自動的に所有権を得るこ
とをEEFに知らせる。
要求の残りの部分は情報都分であり、システム内の他の
所有CPUに対して、これを必要とするかどうかの要求
情報を供給する。第4図の例では、資源クラス×はCP
UI及びCPU4が所有している。従って、ゲート23
は夫々線29,35を介してゲート15,21にゲート
信号を送り、この要求をCPUI及びCPU4の伍Fへ
送らせる。例えば、mFIが、この要求を受取ると、C
PU2が「木材製品」を希望していることをその情報部
分から判断する。
所有CPUに対して、これを必要とするかどうかの要求
情報を供給する。第4図の例では、資源クラス×はCP
UI及びCPU4が所有している。従って、ゲート23
は夫々線29,35を介してゲート15,21にゲート
信号を送り、この要求をCPUI及びCPU4の伍Fへ
送らせる。例えば、mFIが、この要求を受取ると、C
PU2が「木材製品」を希望していることをその情報部
分から判断する。
mFIは「軸受」を使っているから、そのプロトコル論
理装置7川ま、資源クラスXの内のサブクラスである木
材製品に対する完全なアクセスをCPU2に与える応答
をその応答アセンブリ・レジスタで構成して、EEFに
伝達することにより、CPU2にアクセスを許可する。
この応答は、X許可、IEF2,IEF1、木材製品と
いう形にすることが出釆る。この場合、CPUIは、C
PU2に資源クラス×の前述のサブクラスに対するアク
セスが許可されていて、CPU2が未だこのアクセスを
放棄していないかも知れないので、CPU2が資源クラ
スXの共有者であるかも知れない、ということを承知し
ている。
理装置7川ま、資源クラスXの内のサブクラスである木
材製品に対する完全なアクセスをCPU2に与える応答
をその応答アセンブリ・レジスタで構成して、EEFに
伝達することにより、CPU2にアクセスを許可する。
この応答は、X許可、IEF2,IEF1、木材製品と
いう形にすることが出釆る。この場合、CPUIは、C
PU2に資源クラス×の前述のサブクラスに対するアク
セスが許可されていて、CPU2が未だこのアクセスを
放棄していないかも知れないので、CPU2が資源クラ
スXの共有者であるかも知れない、ということを承知し
ている。
CPUI及びCPU2は、資源共有プロトコル(これは
この発明の一部ではない)により、互いに資源クラス×
を使うことについて、希望する任意のレベルの細目を保
有することに同意することが出来る。然し、その保有量
が多くなればなる程、システム内でその間に必要な通信
量が多くなる。この通信を制限する為には、深さがモジ
ュール形であるか、或いは特性の深さの高レベルに制限
された資源共有プロトコルにすることが望ましいと思わ
れる。FIO 一定の深さのプロトコル(第2図)もし
資源共有プロトコルが或るレベルを定め、それよりも低
い所では、ロックされた資源クラスがあるかどうかの照
会をしえない場合、一定の深さのプロトコルになる。
この発明の一部ではない)により、互いに資源クラス×
を使うことについて、希望する任意のレベルの細目を保
有することに同意することが出来る。然し、その保有量
が多くなればなる程、システム内でその間に必要な通信
量が多くなる。この通信を制限する為には、深さがモジ
ュール形であるか、或いは特性の深さの高レベルに制限
された資源共有プロトコルにすることが望ましいと思わ
れる。FIO 一定の深さのプロトコル(第2図)もし
資源共有プロトコルが或るレベルを定め、それよりも低
い所では、ロックされた資源クラスがあるかどうかの照
会をしえない場合、一定の深さのプロトコルになる。
例えば、製品のクラス(即ち、第2図の木材製品又は軸
受)又は合意によってその他の任意の深さがメモリの最
探しベル(即ち、共有レベルとして記憶されるように選
ばれた深さ)として定められた場合、各々のIEFに要
求が送られて来た時、この要求を許可することができる
かどうかを判断するのに、この一定の深さより下の所を
このmFは照会しないのである。例えば、製品クラスが
一定の深さと定められた場合、Xロック、mF2、木材
製品・斧の柄という様なIEF2からの要求をIEFI
が受取り、且つ伍FIが木材製品・野球バンドを使って
いるならば、mFIからはこの要求を拒否する応答がE
EFに送られ、そこから伍F2に伝達される。というの
は、IEFIは合意によって、製品クラス(即ち、木材
製品)より低い所を照合して、それが木材製品・斧の柄
を使っていないかどうかを判断しないからである。IE
F2は、IEFIが木材製品・野球バットを使い終るま
で、EEFを通じて木材製品・斧の柄を求めつづけても
よいし、或いはmF2は、IEFIが木材製品・野球バ
ットの使用を完了したことを通知して来るのを待っても
よい。一定の深さに制限された資源共有プロトコルは、
システム内の通信を制限するが、更に照会する合意があ
った場合には許可したかも知れないアクセスを、要求中
也Fに対して許可しないことがある。FII モジュー
ル形の深さのプロトコル(第2図)モジュール形の深さ
の資源共有プロトコルでは、所有CPUの伍Fは、許可
することが出来るものであれば、到来した要求を許可す
るのに必要な深さまで、照会することに合意する。
受)又は合意によってその他の任意の深さがメモリの最
探しベル(即ち、共有レベルとして記憶されるように選
ばれた深さ)として定められた場合、各々のIEFに要
求が送られて来た時、この要求を許可することができる
かどうかを判断するのに、この一定の深さより下の所を
このmFは照会しないのである。例えば、製品クラスが
一定の深さと定められた場合、Xロック、mF2、木材
製品・斧の柄という様なIEF2からの要求をIEFI
が受取り、且つ伍FIが木材製品・野球バンドを使って
いるならば、mFIからはこの要求を拒否する応答がE
EFに送られ、そこから伍F2に伝達される。というの
は、IEFIは合意によって、製品クラス(即ち、木材
製品)より低い所を照合して、それが木材製品・斧の柄
を使っていないかどうかを判断しないからである。IE
F2は、IEFIが木材製品・野球バットを使い終るま
で、EEFを通じて木材製品・斧の柄を求めつづけても
よいし、或いはmF2は、IEFIが木材製品・野球バ
ットの使用を完了したことを通知して来るのを待っても
よい。一定の深さに制限された資源共有プロトコルは、
システム内の通信を制限するが、更に照会する合意があ
った場合には許可したかも知れないアクセスを、要求中
也Fに対して許可しないことがある。FII モジュー
ル形の深さのプロトコル(第2図)モジュール形の深さ
の資源共有プロトコルでは、所有CPUの伍Fは、許可
することが出来るものであれば、到来した要求を許可す
るのに必要な深さまで、照会することに合意する。
例えば、mF2がXロック IEF2 木材製品・斧の
柄を要求し、伍FIが現在、木材製品・野球バット・リ
トルリーグを使っている場合、伍FIは自分が使ってい
るのがリトルリーグ・野球バットの資源であることを識
別して、斧の柄の資源に対しては、IEF2にアクセス
を許可する。モジュール形の深さのプロトコルの利点は
、資源の所有者が、自分が所有する最終制御レベル又は
それより低い全ての資源を自由に使えることである。
柄を要求し、伍FIが現在、木材製品・野球バット・リ
トルリーグを使っている場合、伍FIは自分が使ってい
るのがリトルリーグ・野球バットの資源であることを識
別して、斧の柄の資源に対しては、IEF2にアクセス
を許可する。モジュール形の深さのプロトコルの利点は
、資源の所有者が、自分が所有する最終制御レベル又は
それより低い全ての資源を自由に使えることである。
即ち、或るIEFの資源の一部分を放棄する場合、この
IEFは階層中の所定のレベルだけを放棄すればよい。
この例を第2図について説明する。
IEFは階層中の所定のレベルだけを放棄すればよい。
この例を第2図について説明する。
前に述べた様に、Xの様な所定の資源クラスは2つ以上
の製品クラスを含んでいてよい。例えば第2図の資源ク
ラス×は、2つの製品クラスとして、木材製品及び軸受
を含んでいる。
の製品クラスを含んでいてよい。例えば第2図の資源ク
ラス×は、2つの製品クラスとして、木材製品及び軸受
を含んでいる。
各々の製品クラスを図示の様に更に細分することが出釆
る。也FIは資源クラス×を所有し、田F2が、次のよ
うに、短かし、斧の柄の資源に対するアクセスを要求し
たと仮定する。×ロック 伍F2 木材製品・斧の柄・
短モジュール形の資源共有プロトコルでは、IEFIが
木材製品の内の野球バットの資源を使っている場合、也
FIは短かし、斧の柄という資源に対するEF2からの
要求を許可することが出来る。
る。也FIは資源クラス×を所有し、田F2が、次のよ
うに、短かし、斧の柄の資源に対するアクセスを要求し
たと仮定する。×ロック 伍F2 木材製品・斧の柄・
短モジュール形の資源共有プロトコルでは、IEFIが
木材製品の内の野球バットの資源を使っている場合、也
FIは短かし、斧の柄という資源に対するEF2からの
要求を許可することが出来る。
実際、mFIが、例えば野球バットの在庫調べをしてい
るが、斧の柄は必要がないと判断すれば、EFIは全て
の斧の柄に対してIEF2にアクセスを許可しても、木
材製品の内の野球バットという資源は保有することが出
来る。この為、IEFIは、階層形トリーの内、使って
いない最高の節を選択し、その節しベル(即ち、斧の柄
)でアクセスを許可し、しかも木材製品・斧の柄以外の
資源クラスXの全てについて、そのユーザ・プログラム
に対するアクセスを自由に即座に許可することが出来る
。F12 一定の深さのプロトコルの結果 IEFは、そのユーザーとして、この伍Fに関連するC
PUのユーザ・プログラムを持っている。
るが、斧の柄は必要がないと判断すれば、EFIは全て
の斧の柄に対してIEF2にアクセスを許可しても、木
材製品の内の野球バットという資源は保有することが出
来る。この為、IEFIは、階層形トリーの内、使って
いない最高の節を選択し、その節しベル(即ち、斧の柄
)でアクセスを許可し、しかも木材製品・斧の柄以外の
資源クラスXの全てについて、そのユーザ・プログラム
に対するアクセスを自由に即座に許可することが出来る
。F12 一定の深さのプロトコルの結果 IEFは、そのユーザーとして、この伍Fに関連するC
PUのユーザ・プログラムを持っている。
これらのプログラムは当然資源に対するアクセスを要求
する。こういうユーザ・プログラムに対し、IEFは、
EEFがmFに対して作用するのと同様に作用する。例
えば、IEFがその1つのユーザ・プログラムに対して
、資源に対するアクセスを直ちに許可することが出来る
のであれば、そうする。このアクセスを許可することが
出釆なければ、アクセスを得る為にEEFに照会しなけ
ればならい。システムが一定の深さの資源共有ブロトコ
ルを採用した場合、RFは、そのユーザ・プログラムに
対し、この一定の深さのレベルか或いはそれより下にあ
る要求に、直ちにアクセスを認める自由がある。例えば
、IEFIが木材製品・野球バット・リトルリーグを使
っていて、mF2が木材製品・斧の柄を要求した場合、
IEF2の要求を拒否することは前に述べた通りである
。然し、この結果、mFIは、EEFをわずらわさずに
、そのユーザに対し、木材製品・斧の柄に対するアクセ
スを(又は実際には木材製品の中の資源に対するどんな
アクセスをも)直ちに許可することが出来る。従って、
この点で、mFIは、自分のユーザ・プログラムに対し
ては、EEFとして作用する。唯一の拘束は、この例の
IEFIが、そのどのユーザ・プログラムにどの資源を
許可したかを内部で記録しておくことである。この為、
前に述べた様に、一定の深さのブロトコルはシステム内
の通信を制限する。F13 モジュール形のプロトコル
の結果モジュール形のプロトコルは、資源に対するmF
のアクセス要求を許可する場合の方が多いのが普通であ
るが、許可する時の細分度が細かい。
する。こういうユーザ・プログラムに対し、IEFは、
EEFがmFに対して作用するのと同様に作用する。例
えば、IEFがその1つのユーザ・プログラムに対して
、資源に対するアクセスを直ちに許可することが出来る
のであれば、そうする。このアクセスを許可することが
出釆なければ、アクセスを得る為にEEFに照会しなけ
ればならい。システムが一定の深さの資源共有ブロトコ
ルを採用した場合、RFは、そのユーザ・プログラムに
対し、この一定の深さのレベルか或いはそれより下にあ
る要求に、直ちにアクセスを認める自由がある。例えば
、IEFIが木材製品・野球バット・リトルリーグを使
っていて、mF2が木材製品・斧の柄を要求した場合、
IEF2の要求を拒否することは前に述べた通りである
。然し、この結果、mFIは、EEFをわずらわさずに
、そのユーザに対し、木材製品・斧の柄に対するアクセ
スを(又は実際には木材製品の中の資源に対するどんな
アクセスをも)直ちに許可することが出来る。従って、
この点で、mFIは、自分のユーザ・プログラムに対し
ては、EEFとして作用する。唯一の拘束は、この例の
IEFIが、そのどのユーザ・プログラムにどの資源を
許可したかを内部で記録しておくことである。この為、
前に述べた様に、一定の深さのブロトコルはシステム内
の通信を制限する。F13 モジュール形のプロトコル
の結果モジュール形のプロトコルは、資源に対するmF
のアクセス要求を許可する場合の方が多いのが普通であ
るが、許可する時の細分度が細かい。
例えば、EFIが木材製品・野球バットという資源を使
っている時、也F2に対して木材製品(更に粗の細分度
)を許可することは出釆ないがIEF2に対して木材製
品・斧の柄(更に細かい細分度)を許可することは出来
る。この為、IEF2は、そのユーザに対し、木材製品
・斧の柄に対するアクセスだけを直ちに許可することが
出来るが、mF2のユーザ・プログラムからの木材製品
に対する他の全てのアクセスの要求については、EEF
の手をかりなければならない。この為、モジュール形の
資源共有プロトコルにすると、要求中位Fに対してアク
セスが許可される場合が一層多くなるが、mFのユーザ
・プログラムから要求に対し、そのmFがシステム内で
行なう通信が一層多くなる。F14 1EFのユーザ・
プログラムからの要求に対するmFの動作例(第5図)
伍FIのユーザ・フ。
っている時、也F2に対して木材製品(更に粗の細分度
)を許可することは出釆ないがIEF2に対して木材製
品・斧の柄(更に細かい細分度)を許可することは出来
る。この為、IEF2は、そのユーザに対し、木材製品
・斧の柄に対するアクセスだけを直ちに許可することが
出来るが、mF2のユーザ・プログラムからの木材製品
に対する他の全てのアクセスの要求については、EEF
の手をかりなければならない。この為、モジュール形の
資源共有プロトコルにすると、要求中位Fに対してアク
セスが許可される場合が一層多くなるが、mFのユーザ
・プログラムから要求に対し、そのmFがシステム内で
行なう通信が一層多くなる。F14 1EFのユーザ・
プログラムからの要求に対するmFの動作例(第5図)
伍FIのユーザ・フ。
。グラム5がニードル軸受を使いたいと仮定する。更に
最初は、資源クラスXの資源名称/所有者列の記入項目
が(WP/BB、4)だけであると仮定する。ニードル
軸受の資源に対するアクセス要求が、例えば第5図の母
線55に置かれて、資源クラス決定アルゴリズム49に
送られる。この要求は資源クラスXに変換され、資源テ
ーブル47でこの資源クラスXの行に対応するアドレス
が、アルゴIJズム49の出力に現われ、復号器57に
よって復号される。資源クラスXに関連するロック列が
謙出される。これは1として示してあるから、ゼロ検出
器73は、この資源クラスXが当該IEFによって所有
されていることを検出し、そしてゲート69を条件づけ
で、資源名称/所有者列の内容をプ。トコル論理装置7
0‘こ送る。要求(B/N、5)を伝える母線53が、
この要求をブロトコル論理装置70に伝達する。資源名
称/所有者列の内容は、資源クラスXの内の木材製品・
野球バットというサブクラスが、ユーザ・プログラム4
(WP/BB、4)によって使われているが、今の例で
は、ニ−ドル軸受は使われていないことを示しているか
ら、プロトコル論理装置70は、一定又はモジュール形
の何れのプロトコルを使っていても、ユーザ・プログラ
ム5に対し、資源クラス×の内のニードル軸受のサブク
ラスに対するアクセスを許可する。線80がアクセスを
許可し、次に要求があった時に使う為この要求の識別符
号を資源テーブル47の資源名称/所有者列へ送る。ユ
ーザ・プログラム5を完了すると、それを適当に復号し
てユーザ・プログラム完了線を付勢し、資源テーフル4
7から(B/N、5)を除き、若しこれが資源クラスX
を使用する最後の回であれば、ロック列をリセツトする
。もし資源クラス×のロック列がゼロであったとすると
、ゼロ検出器73は線75を付勢して、このmFが資源
クラスXをロックしていないことを表示する。
最初は、資源クラスXの資源名称/所有者列の記入項目
が(WP/BB、4)だけであると仮定する。ニードル
軸受の資源に対するアクセス要求が、例えば第5図の母
線55に置かれて、資源クラス決定アルゴリズム49に
送られる。この要求は資源クラスXに変換され、資源テ
ーブル47でこの資源クラスXの行に対応するアドレス
が、アルゴIJズム49の出力に現われ、復号器57に
よって復号される。資源クラスXに関連するロック列が
謙出される。これは1として示してあるから、ゼロ検出
器73は、この資源クラスXが当該IEFによって所有
されていることを検出し、そしてゲート69を条件づけ
で、資源名称/所有者列の内容をプ。トコル論理装置7
0‘こ送る。要求(B/N、5)を伝える母線53が、
この要求をブロトコル論理装置70に伝達する。資源名
称/所有者列の内容は、資源クラスXの内の木材製品・
野球バットというサブクラスが、ユーザ・プログラム4
(WP/BB、4)によって使われているが、今の例で
は、ニ−ドル軸受は使われていないことを示しているか
ら、プロトコル論理装置70は、一定又はモジュール形
の何れのプロトコルを使っていても、ユーザ・プログラ
ム5に対し、資源クラス×の内のニードル軸受のサブク
ラスに対するアクセスを許可する。線80がアクセスを
許可し、次に要求があった時に使う為この要求の識別符
号を資源テーブル47の資源名称/所有者列へ送る。ユ
ーザ・プログラム5を完了すると、それを適当に復号し
てユーザ・プログラム完了線を付勢し、資源テーフル4
7から(B/N、5)を除き、若しこれが資源クラスX
を使用する最後の回であれば、ロック列をリセツトする
。もし資源クラス×のロック列がゼロであったとすると
、ゼロ検出器73は線75を付勢して、このmFが資源
クラスXをロックしていないことを表示する。
線75は、Xロック、mF1、軸受・ニードルという要
求としてEEFに送る為、資源クラスの名称及び資源の
名称を要求アセンブリ・レジスタ77に送り、資源を要
求するが、これは前に述べた通りである。
求としてEEFに送る為、資源クラスの名称及び資源の
名称を要求アセンブリ・レジスタ77に送り、資源を要
求するが、これは前に述べた通りである。
F15 EEFからの要求に対するIEFの動作例mF
2の斧の柄に関する資源をアクセスする必要があると仮
定する。
2の斧の柄に関する資源をアクセスする必要があると仮
定する。
更にこの例では、第5図がIEFIを示しているとする
。前段で述べた様にmF2は、自分が資源クラス×を所
有していないと判断する。次にmF2はXoック、mF
2、木材製品・斧の柄 という要求を構成する。
。前段で述べた様にmF2は、自分が資源クラス×を所
有していないと判断する。次にmF2はXoック、mF
2、木材製品・斧の柄 という要求を構成する。
この要求はEEFへ伝達される。第4図を参照するに、
EEFは前述の如く、資源クラス×がIEFIとIEF
4とによってロックされていると判定する。この例では
、IEFIの動作を詳しく説明する。IEF4の動作も
同様である。第5図の資源テーブル47を参照するに、
mFIが資源クラスXを所有している。
EEFは前述の如く、資源クラス×がIEFIとIEF
4とによってロックされていると判定する。この例では
、IEFIの動作を詳しく説明する。IEF4の動作も
同様である。第5図の資源テーブル47を参照するに、
mFIが資源クラスXを所有している。
資源クラス×の内、実際に使われているサブクラスは、
ユーザ・プログラム4による材木製品・野球バット(W
P/BB、4)とユーザ・プログラム5によるニードル
軸受(B/N、5)である。木材製品・斧の柄は、mF
Iによって使われていない。Xロック、mF2、木材製
品・斧の柄という要求が、母線38を介して第5図の復
号器57へ送られる。行×が読出される。アンド・ゲー
ト66がロック列から1をゼロ検出器67へ送る。この
1で付勢されている為、線79は、行×の資源名称/所
有者列の内容をプロトコル論理装置701こ送ると共に
、資源クラスXがロックされていることをプロトコル論
理装置70に直接的に知らせる。プロトコル論理装置7
01こは、母線81を介して、資源(木材製品・斧の柄
)が、そしてゲート69を介して、mFIが木材製品・
野球バット及び軸受ニードルだけを使っており、木材製
品・斧の柄を使っていないという事実が伝えられている
。この場合、一定の深さのプロトコルを使えば、前に述
べた様に、アクセスが拒否される。モジュール形のプロ
トコルを使えば、プロトコル論理装置70は、資源クラ
ス×はロックされているが、mFIが木材製品・斧の柄
を使っていないと判定し、×許可、田F2、木材製品・
斧の柄という形の応答をEEFに送ることにより、この
要求を許可する。
ユーザ・プログラム4による材木製品・野球バット(W
P/BB、4)とユーザ・プログラム5によるニードル
軸受(B/N、5)である。木材製品・斧の柄は、mF
Iによって使われていない。Xロック、mF2、木材製
品・斧の柄という要求が、母線38を介して第5図の復
号器57へ送られる。行×が読出される。アンド・ゲー
ト66がロック列から1をゼロ検出器67へ送る。この
1で付勢されている為、線79は、行×の資源名称/所
有者列の内容をプロトコル論理装置701こ送ると共に
、資源クラスXがロックされていることをプロトコル論
理装置70に直接的に知らせる。プロトコル論理装置7
01こは、母線81を介して、資源(木材製品・斧の柄
)が、そしてゲート69を介して、mFIが木材製品・
野球バット及び軸受ニードルだけを使っており、木材製
品・斧の柄を使っていないという事実が伝えられている
。この場合、一定の深さのプロトコルを使えば、前に述
べた様に、アクセスが拒否される。モジュール形のプロ
トコルを使えば、プロトコル論理装置70は、資源クラ
ス×はロックされているが、mFIが木材製品・斧の柄
を使っていないと判定し、×許可、田F2、木材製品・
斧の柄という形の応答をEEFに送ることにより、この
要求を許可する。
この応答は第4図の応答アセンフル・レジスタ36で組
立てられ、IEF2の許可/拒否論理装置へ送られ、そ
こで、斧の柄という資源を使うアクセスを要求に対する
許可と解釈される。H 発明の効果 以上詳述したように、本発明によれば、システムの1メ
ンバであるCPUが故障した場合でも、他のCPUがシ
ステム資源を依然としてアクセスすることができるとい
う、優れた効果が得られる。
立てられ、IEF2の許可/拒否論理装置へ送られ、そ
こで、斧の柄という資源を使うアクセスを要求に対する
許可と解釈される。H 発明の効果 以上詳述したように、本発明によれば、システムの1メ
ンバであるCPUが故障した場合でも、他のCPUがシ
ステム資源を依然としてアクセスすることができるとい
う、優れた効果が得られる。
第1図は各CPUがデータ資源を共有することが出来る
多重プ。 セッサ・システムの全体図、第2図はこの発明の装置で
使われる資源クラスの構成を示す図、第3図はこの発明
の装置の動作を示すフローチャート、第4図はこの発明
の外部照会機構(EEF)の略図、第5図は多重プロセ
ッサ・システム内の内部照会装置(IEF)の略図、第
6図は許可/拒否論理装置の構成を示す図である。1〜
4・・…・中央演算処理装置、mFI〜4・・・・・・
内部照会機構、5・・・・・・外部照会機構(EEF)
。 FIG.IFIG,2 FIG.6 FIG,3 FIG,ム FIG,5
多重プ。 セッサ・システムの全体図、第2図はこの発明の装置で
使われる資源クラスの構成を示す図、第3図はこの発明
の装置の動作を示すフローチャート、第4図はこの発明
の外部照会機構(EEF)の略図、第5図は多重プロセ
ッサ・システム内の内部照会装置(IEF)の略図、第
6図は許可/拒否論理装置の構成を示す図である。1〜
4・・…・中央演算処理装置、mFI〜4・・・・・・
内部照会機構、5・・・・・・外部照会機構(EEF)
。 FIG.IFIG,2 FIG.6 FIG,3 FIG,ム FIG,5
Claims (1)
- 1 複数のCPUと、該CPUによつてアクセスされる
システム資源とを有する多重プロセツサ・システムであ
つて、前記CPUに関連してそれぞれ設けられた複数の
内部照会装置(第1図のIEF)と、前記内部装置の各
々に対等に結合された共通の外部照会装置(第1図のE
FF)とを備え、前記内部照会装置の各々は、関連する
前記CPUまたは前記外部照会装置から受取られた前記
システム資源に対するアクセス要求に応答して当該内部
照会装置によつて管理されている特定の前記システム資
源の使用状況を示す第1の資源テーブルを参照する手段
(第5図の47,51,55,57)と、該資源テーブ
ルの内容に応じて当該アクセス要求を直ちに許可するこ
とができるか否か判定し且つその判定結果を当該アクセ
ス要求の応答として前記関連するCPUまたは前記外部
照会装置へ通知する手段(第5図の67,70,73)
と、前記関連するCPUからのアクセス要求を直ちに許
可することができない場合は該アクセス要求を前記外部
照会装置へ発信する手段(第5図の77)とを含み、前
記外部照会装置は、前記内部照会装置から受取られたア
クセス要求に応答して前記複数の内部照会装置によつて
管理されている前記システム資源の使用状況を示す第2
の資源テーブルを参照する手段(第4図の11,37)
と、該資源テーブルの内容に応じて当該アクセス要求を
直ちに許可することができるか否かを判定し且つ直ちに
許可することができる場合は当該アクセス要求を発信し
た特定の前記内部照会装置へ許可信号を供給する手段(
第4図の25)と、当該アクセス要求を直ちに許可する
ことができない場合には所望の前記システム資源を管理
している前記内部照会装置へ当該アクセス要求を送信す
る手段(第4図の15〜23)と、該内部照会装置から
の応答を受取つて該応答を前記特定の内部照会装置へ返
送する手段(第5図の36)とを含んでいることを特徴
とする、多重プロセツサ・システム。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US96581078A | 1978-12-04 | 1978-12-04 | |
US965810 | 1978-12-04 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPS5576459A JPS5576459A (en) | 1980-06-09 |
JPS6035702B2 true JPS6035702B2 (ja) | 1985-08-16 |
Family
ID=25510520
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP54144507A Expired JPS6035702B2 (ja) | 1978-12-04 | 1979-11-09 | 多重プロセツサ・システム |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP0013301B1 (ja) |
JP (1) | JPS6035702B2 (ja) |
DE (1) | DE2963264D1 (ja) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2457521B1 (fr) * | 1979-05-23 | 1985-12-27 | Thomson Csf | Systeme multiprocesseur de traitement de signal |
EP0049423B1 (en) * | 1980-10-06 | 1987-04-01 | International Business Machines Corporation | Multiprocessor system |
JPS63263557A (ja) * | 1987-04-13 | 1988-10-31 | インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン | 階層リレーテツド・リソースへの同時トランザクシヨンによるアクセスを調節する方法 |
US5257374A (en) * | 1987-11-18 | 1993-10-26 | International Business Machines Corporation | Bus flow control mechanism |
GB9123264D0 (en) * | 1991-11-01 | 1991-12-18 | Int Computers Ltd | Semaphone arrangement for a data processing system |
US5454108A (en) * | 1994-01-26 | 1995-09-26 | International Business Machines Corporation | Distributed lock manager using a passive, state-full control-server |
CA2181009C (en) * | 1996-07-11 | 1999-09-07 | Paul Erb | Multiple owner resource management |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3400372A (en) * | 1965-02-16 | 1968-09-03 | Ibm | Terminal for a multi-data processing system |
US3864670A (en) * | 1970-09-30 | 1975-02-04 | Yokogawa Electric Works Ltd | Dual computer system with signal exchange system |
US3825902A (en) * | 1973-04-30 | 1974-07-23 | Ibm | Interlevel communication in multilevel priority interrupt system |
US3947823A (en) * | 1973-12-26 | 1976-03-30 | International Business Machines Corp. | Means for coordinating asynchronous main store accesses in a multiprocessing system using virtual storage |
US3970993A (en) * | 1974-01-02 | 1976-07-20 | Hughes Aircraft Company | Cooperative-word linear array parallel processor |
US3934232A (en) * | 1974-04-25 | 1976-01-20 | Honeywell Information Systems, Inc. | Interprocessor communication apparatus for a data processing system |
US3988716A (en) * | 1974-08-05 | 1976-10-26 | Nasa | Computer interface system |
US4009470A (en) * | 1975-02-18 | 1977-02-22 | Sperry Rand Corporation | Pre-emptive, rotational priority system |
US3964054A (en) * | 1975-06-23 | 1976-06-15 | International Business Machines Corporation | Hierarchy response priority adjustment mechanism |
JPS5837585B2 (ja) * | 1975-09-30 | 1983-08-17 | 株式会社東芝 | ケイサンキソウチ |
US4261033A (en) * | 1977-01-19 | 1981-04-07 | Honeywell Information Systems Inc. | Communications processor employing line-dedicated memory tables for supervising data transfers |
-
1979
- 1979-10-29 EP EP79104179A patent/EP0013301B1/en not_active Expired
- 1979-10-29 DE DE7979104179T patent/DE2963264D1/de not_active Expired
- 1979-11-09 JP JP54144507A patent/JPS6035702B2/ja not_active Expired
Also Published As
Publication number | Publication date |
---|---|
EP0013301A1 (en) | 1980-07-23 |
EP0013301B1 (en) | 1982-06-30 |
DE2963264D1 (en) | 1982-08-19 |
JPS5576459A (en) | 1980-06-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0972240B1 (en) | An agent-implemented locking mechanism | |
US5454108A (en) | Distributed lock manager using a passive, state-full control-server | |
US4480304A (en) | Method and means for the retention of locks across system, subsystem, and communication failures in a multiprocessing, multiprogramming, shared data environment | |
US5490253A (en) | Multiprocessor system using odd/even data buses with a timeshared address bus | |
US6205466B1 (en) | Infrastructure for an open digital services marketplace | |
US7600063B2 (en) | Techniques for improved read-write concurrency | |
US5987550A (en) | Lock mechanism for shared resources in a data processing system | |
JP3062070B2 (ja) | 分散ファイル・システム用マルチレベル・トークン管理のためのシステムおよび方法 | |
JPS6131500B2 (ja) | ||
US20040249913A1 (en) | System and method for application programming interface for extended intelligent platform management | |
US6697901B1 (en) | Using secondary resource masters in conjunction with a primary resource master for managing resources that are accessible to a plurality of entities | |
CN101183338A (zh) | 本地片载系统和在本地片载系统中维持存储一致性的方法 | |
CN102932164A (zh) | 群集客户端故障转移 | |
US5062038A (en) | Information control system | |
US5063501A (en) | Information control system for selectively transferring a tree lock from a parent node to a child node thereby freeing other nodes for concurrent access | |
US8086579B1 (en) | Semantic response to lock requests to reduce coherence overhead in multi-node systems | |
JPS6035702B2 (ja) | 多重プロセツサ・システム | |
US6529933B1 (en) | Method and apparatus for locking and unlocking a semaphore | |
JP2002202956A (ja) | セキュリティ管理システム、セキュリティ管理方法及びセキュリティ管理プログラム | |
JPH0387958A (ja) | バスロツク制御方式 | |
EP3629171A1 (en) | Lock manager for multi-core architectures | |
JPS63263557A (ja) | 階層リレーテツド・リソースへの同時トランザクシヨンによるアクセスを調節する方法 | |
JP2898012B2 (ja) | 計算機資源の排他制御方式 | |
KR20230174931A (ko) | 다중 운영 체제를 구비한 시스템 및 그 동작 방법 | |
JPH03294931A (ja) | 情報処理システムの資源名管理方式 |