JP3683082B2

JP3683082B2 - 呼処理装置

Info

Publication number: JP3683082B2
Application number: JP28584097A
Authority: JP
Inventors: あゆ美山田; 三津之水野; 敦内田
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1997-10-17
Filing date: 1997-10-17
Publication date: 2005-08-17
Anticipated expiration: 2017-10-17
Also published as: JPH11120014A; US6389012B1

Description

【０００１】
【発明の属する技術分野】
本発明は、マルチプロセッサ装置に関し、特に、各プロセッサが共に利用可能なリソースを持つマルチプロセッサ装置（呼処理装置）に関する。
【０００２】
【従来の技術】
近年、複数のプロセッサによって制御が行われる装置が増えてきている。そのような装置には、各プロセッサに全く異なる制御を行わせる装置と、類似の制御を行わせ装置があり、後者の装置としては、例えば、各プロセッサに呼処理を行わせる（スイッチ、トランク等を制御させる）装置、いわゆる、マルチプロセッサ方式の交換機が知られている。
【０００３】
マルチプロセッサ方式の交換機としては、リソースが集中管理される交換機と分散管理される交換機がある。以下、各タイプの交換機の構成、動作を簡単に説明する。
【０００４】
まず、図７を用いて、集中管理型の交換機の構成、動作を説明する。図示してあるように、このタイプの交換機には、幾つかの呼処理用プロセッサとともに、リソース管理用プロセッサが設けられる。リソース管理用プロセッサは、各呼処理用プロセッサが利用する全リソースの管理を行うプロセッサであり、呼処理は行わない。逆に、呼処理用プロセッサは、呼処理のみを行う。
【０００５】
この交換機では、リソースが必要となった呼処理用プロセッサ（図では、呼処理用プロセッサ１）は、プロセッサ間通信により、リソースの捕捉要求をリソース管理用プロセッサに出す。リソース管理用プロセッサは、図中、模式的に示してあるように、リソースの使用状況（空／塞状況）を管理しており、リソースの捕捉要求を受けた場合、管理している使用状況に基づき、要求を満たす量の空リソースが存在するか否かを判断する。そして、存在していた場合には、空リソースを捕捉し、捕捉したリソースに応じた回路番号（使用して良いトランクを指定するデータ；以下、捕捉回路番号と表記する）を、要求元の呼処理用プロセッサに通知する。
【０００６】
捕捉回路番号の通知を受けた呼処理用プロセッサは、その捕捉回路番号を用いた制御（リソースを利用する制御）を開始する。そして、リソースが不要となった際には、捕捉回路番号を含む開放要求をリソース管理用プロセッサに出し、開放要求を受けたリソース管理用プロセッサは、その内容に応じたリソースを開放する。
【０００７】
次に、分散管理型の交換機の構成、動作の概要を説明する。
このタイプの交換機では、各プロセッサが、リソース管理機能を持っており、全リソースの中の自らに割り当てられたリソースの管理を行う。すなわち、図７に示した集中管理型の交換機と同じ量のリソースを有し、３つのプロセッサによって制御される分散管理型の交換機では、図８に模式的に示したように、各プロセッサによって、集中管理型交換機のリソース管理用プロセッサが管理していたリソースの１／３が独立に管理される。
【０００８】
【発明が解決しようとする課題】
上記説明から明らかなように、従来の分散管理型の交換機は、プロセッサ間通信を用いることなくリソースの捕捉／開放が行える装置となっている。このため、分散管理型の交換機は、リソースの捕捉／解放時に常にプロセッサ間通信が必要となる集中管理型の交換機に比して、高速に動作可能な装置となる。また、分散管理型の交換機は、リソース管理用プロセッサが不要であるので、集中管理型の交換機に比して低コストで製造できる装置にもなっている。さらに、集中管理型の交換機は、リソース管理用プロセッサがダウンした場合、交換機全体がダウンしてしまうのに対し、分散管理型の交換機は、全てのプロセッサがダウンしない限り、交換機全体がダウンすることがない。
【０００９】
このように、分散管理型の交換機は、集中管理型の交換機に比して優れた点を多く持つ装置となっている。しかしながら、分散管理型の交換機は、リソースの分割損があるという欠点を有した装置ともなっていた。
【００１０】
そこで、本発明の目的は、リソースの分割損がなく、しかも、従来の集中管理型の装置が持つ欠点を有さないマルチプロセッサ装置を提供することにある。
【００１１】
【課題を解決するための手段】
上記課題を解決するために、本発明では、複数のプロセッサと、複数のプロセッサが共通して使用可能なリソースを有するマルチプロセッサ装置を構成するに際して、リソースを複数のリソースグループに分け、複数のプロセッサにそれぞれ割り当てるとともに、各プロセッサに、（イ）他のプロセッサとの間で通信を行うための通信手段と、（ロ）自身に割り当てられたリソースグループ内の各リソースの使用状況を管理するとともに、リソースの使用許可が要求されたときには、その要求元に、使用状況に基づき、リソースの使用許可あるいは使用不許可を通知する管理手段と、（ハ）リソースが必要となったときに、そのリソースの使用許可を管理手段に要求し、管理手段から使用不許可が通知された場合には、通信手段を利用して他のプロセッサ内の管理手段にリソースの使用許可を要求する要求手段とを具備させる。
【００１２】
このような構成を有するマルチプロセッサ装置では、通常は（リソースグループ内のリソースの使用率がさほど高くないとき）、各プロセッサのリソースの捕捉／開放が、プロセッサ間通信（通信手段）を使用せずに行われることになる。また、各プロセッサは、自身が管理しているリソースが全塞がりであった場合等には、プロセッサ間通信を利用して、他プロセッサが管理しているリソースの使用許可を受けることができる。従って、本マルチプロセッサ装置は、分散管理型装置が有する各種利点をそのまま持ち、しかも、分割損がない装置として動作することになる。
【００１３】
本発明によるマルチプロセッサ装置を構成する際には、要求手段として、全てのプロセッサ内の管理手段から使用不許可が通知されるか、リソースの使用許可を要求した他のプロセッサ内の管理手段から、使用許可が通知されるまで、順次、他のプロセッサ内の管理手段にリソースの使用許可を要求する手段を採用しておくことが望ましい。
【００１４】
さらに、そのような要求手段を採用する場合には、各要求手段がｉ番目にリソースの使用許可を要求するプロセッサが互いに異なるように、各要求手段を構成しておくことが望ましい。このような構成を採用すれば、各リソースグループが平均的に使用されるマルチプロセッサ装置が得られることになる。
【００１５】
また、本発明のマルチプロセッサ装置を構成するに際して、各プロセッサに、通信手段を利用して他のプロセッサに、自身に割り当てられたリソースグループのリソースの使用率を通知する通知手段と、他のプロセッサから通知されたリソースの使用率を記憶する記憶手段とを付加し、要求手段として、記憶手段に記憶された使用率が所定値以上のプロセッサに対しては、リソースの使用許可を要求しない手段を採用しても良い。
【００１６】
このような構成を採用した場合、プロセッサ間通信（通信手段）により使用不許可が通知される確率が低くなるので、その分、高速に動作するマルチプロセッサ装置が得られることになる。
【００１７】
さらに、本発明のマルチプロセッサ装置を構成するに際して、リソースグループの割り当てが行われていないプロセッサを付加することも出来る。この場合、当該プロセッサとしては、他のプロセッサとの間で通信を行うための第２通信手段と、リソースが必要となったときに、そのリソースの使用許可を第２通信手段を利用して他のプロセッサ内の管理手段に要求する第２要求手段とを含むプロセッサを用いる。また、その際、第２要求手段として、他の全てのプロセッサ内の管理手段から使用不許可が通知されるか、リソースの使用許可を要求した他のプロセッサ内の管理手段から使用許可が通知されるまで、順次、他のプロセッサ内の管理手段にリソースの使用許可を要求する手段を採用することも出来る。
【００１８】
すなわち、リソースの管理機能を持たないプロセッサを付加した形で本発明のマルチプロセッサ装置を実現しても良い。
【００１９】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して具体的に説明する。
＜第１実施形態＞
図１に、第１実施形態のマルチプロセッサ装置の概略構成を示す。図示してあるように、第１実施形態のマルチプロセッサ装置は、交換機となっており、スイッチ１１と複数のトランク１２と、４つのプロセッサ１３と３つの分散リソース空/塞データ用メモリ１４を備える。
【００２０】
マルチプロセッサ装置内の４つのプロセッサ１３は、それぞれ、優先順テーブル（詳細は後述）を備える。また、４つのプロセッサ１３のうちの３つのプロセッサＡ〜Ｃは、リソース管理部を有し、３つの分散リソース空/塞データ用メモリ１４は、これら、リソース管理部を有するプロセッサＡ〜Ｃに接続されている。
【００２１】
リソース管理部は、分散リソース空/塞データ用メモリ１４を利用してリソースの管理（リソースの空／塞管理並びに使用の許可）を行う部（プロセッサの一機能）であり、各リソース管理部には、互いに異なるリソースが管理対象として設定されている。すなわち、本装置では、全リソースが３つに区分されており、各リソース管理部は、自身に割り当てられた区分のリソース（分散リソース）のみの管理を、分散リソース空/塞データ用メモリ１４を利用して行う。
【００２２】
優先順テーブルは、リソースを捕捉する必要が生じたときに参照されるテーブルとなっている。優先順テーブルには、リソース管理部を有するプロセッサ１３の識別情報が、リソースの捕捉を依頼すべき順番（優先順）が分かる形態で記憶されている。図中に模式的に示してあるように、リソース管理部を有するプロセッサの優先順テーブルは、優先順が最も高いプロセッサの識別情報として、自プロセッサの識別情報を保持するよう構成される。リソース管理部を有するプロセッサの優先順テーブルは、優先順が第ｉ位（ｉ＝２〜Ｎ；Ｎはリソース管理部を有するプロセッサの数）のプロセッサが互いに異なるようにも構成される。
【００２３】
リソース管理部を有さないプロセッサＤには、プロセッサＡ内の優先順テーブルと同じ内容の優先順テーブルが設定されている。なお、プロセッサＤの優先順テーブルは、プロセッサＡの優先順テーブルと同じ内容である必要はなく、リソース管理部を有するプロセッサの識別情報のリストとなっていれば良い。ただし、リソース管理部を有さないプロセッサを、複数個設ける場合には、優先順が第ｊ位（ｊ＝１〜Ｎ）のプロセッサの重複数が少なくなるように、それらのプロセッサ内の優先順テーブルを構成しておくことが望ましい。
【００２４】
以下、図２を用いて、リソースを捕捉する必要が生じた場合の、各プロセッサの動作を説明する。
図示したように、各プロセッサは、リソースが必要となったときに、まず、優先順テーブルを用いて優先順が最も高いプロセッサを特定する（ステップＳ１０１）。次いで、特定したプロセッサに対してリソース捕捉要求を出す（ステップＳ１０２）。
【００２５】
すなわち、リソース管理部を有するプロセッサは、リソースの捕捉が必要となった場合、まず、自プロセッサ内のリソース管理部にリソースの捕捉を要求する。一方、リソース管理部を有さないプロセッサは、プロセッサ間通信により、他プロセッサ内のリソース管理部にリソースの捕捉を要求する。
【００２６】
リソースの捕捉に成功した場合（ステップＳ１０３；Ｙ）、プロセッサは、捕捉したリソースを利用する制御を開始する。なお、本マルチプロセッサ装置は、交換機であるので、リソース管理部は、リソースの捕捉を行えた場合、回路番号（使用を許可するトランクを指定する情報）を出力し、リソースの捕捉が行えない場合、その旨を示す情報を出力する。
【００２７】
リソースの捕捉に成功しなかった場合、プロセッサは、リソースの捕捉を要求した先のプロセッサが、優先順テーブルの最終プロセッサ（優先順が最も低いプロセッサ）であるか否かを判定し、最終プロセッサでなかった場合（ステップＳ１０４；Ｎ）には、優先順テーブルを用いて優先順が次位のプロセッサの特定を行う（ステップＳ１０５）。次いで、ステップＳ１０２に戻り、そのプロセッサに対して、リソースの捕捉要求を出し、リソースの捕捉に成功したとき（ステップＳ１０３；Ｙ）には、捕捉したリソースを利用する制御（得られた回路番号を用いた制御）を開始する。
【００２８】
そして、そのような処理を最終プロセッサまで繰り返したにもかかわらず、リソースの捕捉に成功しなかった場合（ステップＳ１０４；Ｙ）、プロセッサは、リソース捕捉が行えないときに行う処理である後処理を開始する。
【００２９】
すなわち、図３に示したように、本マルチプロセッサ装置内の、リソース管理部を有するプロセッサ（図では、プロセッサＡ）は、リソースの捕捉が必要となったとき、まず、自身が管理している分散リソースの中から、必要量のリソースの捕捉を試みる。そして、リソースが捕捉できなかった場合には、優先順テーブルから優先順が次順位のプロセッサを特定し、プロセッサ間通信を用いて、そのプロセッサ内のリソース管理部にリソースの捕捉を依頼する。プロセッサＡの優先順テーブル（図１参照）内の次順位のプロセッサはプロセッサＢであるので、図示してあるように、プロセッサＢ内のリソース管理部に対して、リソースの捕捉要求が出されることになる。
【００３０】
そして、プロセッサＢ内のリソース管理部は、管理を行っている分散リソースの空／塞データに基づき、リソースの捕捉が可能か否かを判断する。そして、捕捉が可能であった場合には、空リソースの捕捉を行い、捕捉したリソースに応じた回路番号（以下、捕捉回路番号と表記する）を、要求元であるプロセッサＡに通知する。
【００３１】
そして、プロセッサＡは、その捕捉回路番号を用いた制御（リソース利用制御）を行い、リソースが不要となったとき（呼が切断されたとき）、捕捉回線番号を含む開放要求を、リソースを捕捉してもらったプロセッサ（この場合、プロセッサＢ）に出す。そして、使用されていたリソースが、プロセッサＢによって、開放される。
【００３２】
このように、本マルチプロセッサ装置内のリソース管理部を有する各プロセッサのリソースの捕捉／開放は、通常は（分散リソースの使用率がさほど高くないとき）、プロセッサ間通信を使用せずに行われる。しかも、リソース管理部を有する各プロセッサは、自身が管理しているリソースが全塞がりであった場合等には、プロセッサ間通信を利用して、他プロセッサが管理しているリソースの使用許可を受けることができる。すなわち、本マルチプロセッサ装置は、分散管理型装置が有する各種利点を失ことなく、分割損がない装置となっている。
【００３３】
また、リソース管理部を有する各プロセッサの優先順テーブルは、優先順が第ｉ位のプロセッサが互いに異なるように構成されているので、特定のプロセッサが管理しているリソースの使用率のみが高くなることもない。すなわち、リソースが平均的に使用される装置となっている。
【００３４】
＜第２実施形態＞
第２実施形態のマルチプロセッサ装置は、第１実施形態のマルチプロセッサ装置を変形したものであるため、ここでは、構成が異なる部分のみの説明を行うことにする。
【００３５】
第２実施形態のマルチプロセッサ装置（交換機）にも、リソース管理部を有する３つのプロセッサとリソース管理部を有さない１つのプロセッサが設けられている。リソース管理部を有さないプロセッサは、第１実施形態のマルチプロセッサ装置内のプロセッサＤと全く同じ構成を有する。一方、リソース管理部を有する各プロセッサは、以下に記すように、第１実施形態のマルチプロセッサ装置内のプロセッサＡ等とは異なる構成を有する。
【００３６】
第２実施形態のマルチプロセッサ装置内の、リソース管理部を有する各プロセッサは、優先順テーブルの代わりに、優先順・使用率テーブルを備える。また、リソース管理部を備える各プロセッサは、使用率通知部をも備える。
【００３７】
図４に示したように、優先順・使用率テーブルは、優先順テーブルに、リソース使用率用の記憶領域が付加されたテーブルとなっている。使用率通知部は、自プロセッサが管理しているリソースの使用率を、リソース管理部を有する他プロセッサに通知する処理を周期的に行い、他プロセッサからリソース使用率が通知された場合には、そのリソース使用率を、優先順・使用率テーブルに設定する。また、使用率通知部は、リソースが全塞がりとなった場合には、設定されている周期によらず、リソース使用率の他プロセッサへの通知を行う。
【００３８】
すなわち、第２実施形態のマルチプロセッサ装置内の、リソース管理部を有する各プロセッサは、リソース管理部を有する他プロセッサのリソース使用率を認識（推定）できるように構成されている。
【００３９】
以下、図５を用いて、リソース管理部を有するプロセッサ（以下、単に、プロセッサとも表記する）の動作を説明する。なお、リソース管理部を有さないプロセッサは、第１実施形態のマルチプロセッサ装置内に設けられているリソース管理部を有さないプロセッサと同じ手順で動作する。このため、その説明は省略する。
【００４０】
図示したように、プロセッサは、リソースが必要となったときに、まず、自身が有するリソース管理部によるリソースの捕捉を試みる（ステップＳ２０１）。リソースの捕捉に成功した場合（ステップＳ２０２；Ｙ）、プロセッサは、捕捉したリソースを利用する制御を開始する。一方、リソースの捕捉に成功しなかった場合、プロセッサは、優先順・使用率テーブルを用いて優先順が次位のプロセッサの識別情報並びにリソース使用率Ｒ_USEDを得る（ステップＳ２０３）。そして、Ｒ_USEDが９０％以上であるか否かを判定し、９０％以上であった場合（ステップＳ２０４；Ｙ）には、ステップＳ２０３に戻り、再び、優先順が次位のプロセッサの識別情報並びにリソース使用率Ｒ_USEDを得る。
【００４１】
優先順・使用率テーブルから得られたＲ_USEDが９０％以上であった場合（ステップＳ２０４；Ｙ）、プロセッサは、取得した識別情報で識別されるプロセッサに対して、プロセッサ間通信により、リソースの捕捉要求を出す（ステップＳ２０５）。
【００４２】
リソースの捕捉に成功した場合（ステップＳ２０６；Ｙ）、プロセッサは、捕捉したリソースを利用する制御を開始する。一方、リソースの捕捉に成功しなかった場合、プロセッサは、捕捉依頼先プロセッサが、優先順テーブルの最終プロセッサでなかった場合（ステップＳ２０７；Ｎ）には、ステップＳ２０３からの処理を再び実行する。捕捉依頼先プロセッサが最終プロセッサであった場合（ステップＳ２０７；Ｙ）、プロセッサは、リソース捕捉が行えないときに行う処理である後処理を開始する。
【００４３】
すなわち、第２実施形態のマルチプロセッサ装置では、図６に示したように、リソース管理部を有するプロセッサ（図では、プロセッサＡ）は、リソースの捕捉が必要となったとき、まず、自身（リソース管理部）が管理している分散リソースの中から、必要量のリソースの捕捉を試みる。そして、リソースが捕捉できなかった場合には、優先順・使用率テーブルから優先順が次順位のプロセッサの識別情報並びにリソース使用率を得る。
【００４４】
この時点における優先順・使用率テーブルの内容が、図中に示したようなものであった場合、プロセッサＢの識別情報と、使用率９０％が得られることになる。このため、プロセッサＢに対してはリソースの捕捉要求を出さないといった使用率判定（図５；Ｓ２０４参照）がなされ、さらに、優先順・使用率テーブルを用いた次順位プロセッサの特定が行われることになる。
【００４５】
このとき得られる使用率は５０％であるので、プロセッサＡは、プロセッサＣ内のリソース管理部に対してリソースの捕捉要求を出す。
その結果、プロセッサＣ内のリソース管理部は、管理を行っている分散リソースの空／塞データに基づき、リソースの捕捉が可能か否かを判断する。そして、捕捉が可能であった場合には、空リソースの捕捉を行い、捕捉回路番号を、要求元であるプロセッサＡに通知する。
【００４６】
そして、プロセッサＡは、その捕捉回路番号を用いた制御（リソース利用制御）を行い、リソースが不要となったとき、捕捉回線番号を含む開放要求を、リソースを捕捉してもらったプロセッサ（この場合、プロセッサＣ）に出し、使用されていたリソースが、プロセッサＣによって、開放される。
【００４７】
このように、第２実施形態のマルチプロセッサ装置は、捕捉要求が拒否される可能性の高いプロセッサに対しては捕捉要求が送出されないように構成されている。従って、第２実施形態のマルチプロセッサ装置は、捕捉要求の拒否のためのプロセッサ間通信量が、第１実施形態のマルチプロセッサ装置よりも少ない状態で運用が可能な装置、すなわち、無駄なプロセッサ間通信が行われることが少ない装置となっている。また、第２実施形態のマルチプロセッサ装置は、第１実施形態のマルチプロセッサ装置を変形したものであるので、やはり、分散管理型装置が有する各種利点をそのまま持ち、かつ、分割損がない装置になっている。
【００４８】
＜変形形態＞
第１、第２実施形態のマルチプロセッサ装置は各種の変形が可能である。例えば、各実施形態のマルチプロセッサ装置は、リソース管理部を有するプロセッサを３つ、リソース管理部を有さないプロセッサを１つ備えたものであったが、各プロセッサの数はいくつであっても良く、リソース管理部を有さないプロセッサの数を“０”とすることも出来る。また、各実施形態のマルチプロセッサ装置は、いわゆる、交換機であったが、本技術は、複数のプロセッサで共通に制御できるリソースを有する装置であれば、どのような装置にも適用可能である。
【００４９】
また、各実施形態では、リソース管理部を有するプロセッサに、自プロセッサの識別情報を含む優先順テーブル（あるいは優先順・使用率テーブル）を持たせている。優先順テーブルをそのような構成としているのは、リソース管理部を有するプロセッサのリソース捕捉時の動作手順を、リソース管理部を有さないプロセッサのそれと類似したものとするためであるので、自プロセッサ関連の情報を含まない優先順テーブルを用いて各実施形態に示したような動作をするマルチプロセッサ装置を構成しても良いことは当然である。
【００５０】
また、第２実施形態では、周期的にリソース使用率を他プロセッサに通知するに使用率通知部を用いてあるが、リソース使用率が第１所定値を上回ったときと、第２所定値を下回ったときだけに、リソース使用率を他プロセッサに対して通知する使用率通知部を用いてマルチプロセッサ装置を構成することも出来る。また、使用率通知部に、リソース管理部を有さないプロセッサにもリソース使用率を通知させ、リソース管理部を有さないプロセッサを、リソース使用率が高いプロセッサに対してはリソース捕捉要求を出さないように構成しておくことも出来る。
【００５１】
【発明の効果】
本発明によれば、分散管理型装置が有する各種利点をそのまま持ち、しかも、分割損がないマルチプロセッサ装置が得られることになる。
【図面の簡単な説明】
【図１】本発明の第１実施形態によるマルチプロセッサ装置（交換機）の概略構成を示すブロック図である。
【図２】第１実施形態のマルチプロセッサ装置内の各プロセッサの、リソース捕捉が必要となったときの動作手順を示した流れ図である。
【図３】第１実施形態のマルチプロセッサ装置におけるリソース捕捉手順の一例を示したシーケンス図である。
【図４】本発明の第２実施形態のマルチプロセッサ装置（交換機）内の、リソース管理部を有するプロセッサが備える優先順・使用率テーブルの説明図である。
【図５】第２実施形態のマルチプロセッサ装置内の、リソース管理部を有する各プロセッサの、リソース捕捉が必要となったときの動作手順を示した流れ図である。
【図６】第２実施形態のマルチプロセッサ装置におけるリソース捕捉手順の一例を示したシーケンス図である。
【図７】従来のマルチプロセッサ方式の交換機（集中管理型）におけるリソース捕捉手順を説明するためのシーケンス図である。
【図８】従来のマルチプロセッサ方式の交換機（分散管理型）におけるリソース捕捉手順を説明するためのシーケンス図である。
【符号の説明】
１１スイッチ
１２トランク
１３プロセッサ
１４分散リソース空／塞データ用メモり

Claims

他の装置と接続される複数の接続用回路リソースのうちのいずれかを捕捉して呼処理を行うとともに、前記捕捉したリソースを用いた処理を行う複数のプロセッサを備えた呼処理装置において、
前記複数のプロセッサのそれぞれは、
前記リソースのうち、自身に割当てられたリソースの使用状況を管理するリソース管理手段と、
前記自身に割当てられたリソース以外のリソースが必要となった場合に、そのリソースの使用を前記複数のプロセッサのうちの他のプロセッサに要求することにより、この他のプロセッサが管理する前記リソースの使用許可を受ける要求手段と、
前記複数のプロセッサのうちの他のプロセッサから前記リソースの使用を要求された場合、前記使用状況に基づき、要求した他のプロセッサに対して前記リソースの使用許可あるいは使用不許可を通知する通知手段と、
前記リソースが必要となった場合に、最初に要求すべきプロセッサの情報を格納したテーブルとを備え、
前記要求手段は、前記リソースが必要となった場合に、最初に要求すべきプロセッサを前記テーブルに基づいて決定し、
前記要求手段が前記リソースの使用許可を要求する際のプロセッサの順番が、前記複数のプロセッサ間で互いに異なるように前記テーブルに設定されている
ことを特徴とする複数のプロセッサを備えた呼処理装置。