JPH04291445A - プロセス状態変更方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、非同期メッセージ通信
によってプロセッサ間処理を行なうマルチプロセッサシ
ステムにおいて、特定のＩＤ（一意名）を有する全ての
プロセスの状態を変更させるプロセス状態変更方式に関
するものである。

【０００２】

【従来の技術】マルチプロセッサシステムにおいては、
処理の高速化等を期して、特定のＩＤを有する複数のプ
ロセスを複数のプロセッサに分配して実行することが多
い。このような場合において、コンソールからの外部指
令やハードウェアの物理的な制約等によって、同一ＩＤ
を有する全てのプロセスの状態を変更させることも生じ
る。

【０００３】従来のプロセス状態変更方式として下記の
文献Ａに記載のものがある。従来のプロセス状態変更方
式の説明の準備としてまず、「計算モデル」と従来のプ
ロセス状態変更方式が利用している「終了の検出方式（
ＷＴＣ方式）」とをこの順に説明し、その後、従来の「
状態変更方式」を説明する。

【０００４】文献Ａ；川合英夫、仲瀬明彦、今井明、後
藤厚宏、六沢一昭、“並列推論マシンにおけるＫＬ１の
実行制御方式−分散ゴール管理の課題と対策−”、情報
処理学会第７４回計算機アーキテクチャ研究会８２−２
，１９９０．４．２０。

【０００５】（１）「計算モデル」 （１−１）　仮定するプロセスモデルは以下の通りであ
る。なお、図２は、仮定するプロセスモデルの説明図で
ある。 図２及び後述する各図において、制御プロセスをプロセ
スプールＩＤ（以下、単にＩＤと略す）を内部に有する
矩形の２重実線で示し、子プロセスをプロセスＩＤを内
部に有する円形の実線で示し、プロセッサをプロセスを
内部に有する実線で示している。

【０００６】（１−１−１）　１個のプロセスプールは
、１個の制御プロセスと少なくとも１個以上の子プロセ
スとからなる。 （１−１−２）　システムには複数のプロセスプールが
存在し得、各プロセスプールはシステムで固有のＩＤを
有する。 （１−１−３）　子プロセスは状態を持つ。 （１−１−４）　子プロセスはいつでも終了し得る。 （１−１−５）　子プロセスは、同じＩＤを有する子プ
ロセスをいつでも生成することができる。また、新しい
ＩＤを有するプロセスプールをいつでも生成することが
できる。 （１−１−６）　あるＩＤを有する全ての子プロセスが
終了すると、そのＩＤのプロセスプールは終了する。 （１−１−７）　あるＩＤのプロセスプールの状態変更
とは、そのＩＤを有する全ての子プロセスの状態を制御
プロセスが変更させることである。

【０００７】（１−２）　上述したプロセスプールは、
以下の形式によってマルチプロセッサシステムで実行さ
れる。 なお、図３は、プロセッサとプロセスプールとの関係の
説明図であって、３個のプロセッサＰＥｉ、ＰＥｊ、Ｐ
Ｅｋと、ＩＤがＡ及びＢの２個のプロセスプールとを示
している。ここで、プロセッサはハードウェア的にはＣ
ＰＵ、メモリ及び他のプロセッサとの通信構成とを基本
構成としているものである。

【０００８】（１−２−１）　１個のプロセッサ中に存
在するプロセスの内、同じＩＤを有するものを「サブプ
ール」と呼ぶ。 （１−２−２）　サブプールは、それを構成する全ての
子プロセスが終了すると終了する。 （１−２−３）　プロセッサは、自プロセッサ中のサブ
プールの終了を検出することができる。また、自プロセ
ッサ中の特定のＩＤを有するサブプールに属する全ての
子プロセスの状態を変更することができる。このような
状態変更処理を、ソフトウェアやハードウェアやファー
ムウェアのいずれで実現しても良い。 （１−２−４）　プロセッサは、自プロセッサ中に存在
する子プロセスを他のプロセッサに送信することができ
る。子プロセスの送信は、具体的には子プロセスを運ぶ
メッセージを送信することである。 （１−２−５）　制御プロセスと各プロセッサ（本明細
書においては、サブプールの終了処理部やサブプールの
状態変更部も単にプロセッサと呼んでいる）は非同期メ
ッセージによって互いに通信することができる。例えば
、サブプールの終了を検出したプロセッサは、その旨を
伝えるメッセージを制御プロセスに送ることができる。 また、制御プロセスは「特定のＩＤのサブプールに属す
る全ての子プロセスの状態を指定した状態に変更させる
メッセージ」をプロセッサに送ることができる。 （１−２−６）　メッセージは送信されてから受信され
るまでに任意の時間がかかる。このため、任意の時刻に
おいて、「送信はされたがまだ受信されていないメッセ
ージ」（以下、通信中のメッセージと呼ぶ）が存在し得
る。

【０００９】（２）「終了の検出方式（ＷＴＣ方式）」
全ての子プロセスが終了したことを検出することは上述
した計算モデルでは非常に基本的で重要な機能である。 文献Ａが述べている状態変更方式では、ＷＴＣ方式とい
うプロセス終了検出方式を使用している。このＷＴＣ方
式を以下に述べる。なお、ＷＴＣ方式は以下に示す文献
Ｂに書かれている。

【００１０】文献Ｂ；Ｋ．Ｒｏｋｕｓａｗａ，　Ｎ．Ｉ
ｃｈｉｙｏｓｈｉ　ｅｔ　ａｌ．　　“Ａｎ　Ｅｆｆｉ
ｃｉｅｎｔ　Ｔｅｒｍｉｎａｔｉｏｎ　Ｄｅｔｅｃｔｉ
ｏｎ　ａｎｄ　Ａｂｏｒｔｉｏｎ　Ａｌｇｏｒｉｔｈｍ
　ｆｏｒ　Ｄｉｓｔｒｉｂｕｔｅｄ　Ｐｒｏｃｅｓｓｉ
ｎｇ　Ｓｙｓｔｅｍｓ”，ＩｎＰｒｏｃｅｅｄｉｎｇｓ
　ｏｆ　ｔｈｅ　１９８８　Ｉｎｔｅｒｎａｔｉｏｎａ
ｌＣｏｎｆｅｒｅｎｃｅ　ｏｎ　Ｐａｒａｌｌｅｌ　Ｐ
ｒｏｃｅｓｓｉｎｇ，Ｖｏｌ．１　，ｐｐ．１８−２２
，Ａｕｇｕｓｔ　１９８８　。

【００１１】この方式は、制御プロセス、サブプール及
び通信中のメッセージにそれぞれ「重み」を持たせる方
式である。制御プロセスに持たせる重み（負）と、サブ
プール及びメッセージに持たせる重み（正）とは正負が
逆の整数である。そして、「重みの合計が０」になるよ
うに制御するものである。また、全ての子プロセスが終
了したときのみ制御プロセスの重みが０になるように制
御する。図４は、全て（３個）のサブプールのそれぞれ
に１８０、２５０、４８０の重みが付与され、通信中の
子プロセスに２０の重みが付与され、制御プロセスに−
８５０の重みが付与されている例である。

【００１２】このような重みを管理するため、各プロセ
ッサは、制御プロセス用重みテーブルとサブプール用重
みテーブルとを備えている。制御プロセス用重みテーブ
ルには、プロセッサが有する全制御プロセスのＩＤと制
御プロセスの重みとが対応付けられて格納されている。 図５は、ＩＤが０、１、３５、４０の制御プロセスが存
在し、それぞれ−２５０、−４５０、−５０１４、−４
００２の重みを有するテーブルを示している。サブプー
ル用重みテーブルには、プロセッサが有する全サブプー
ルのＩＤとサブプールの重みとが対応付けられて格納さ
れている。図６は、ＩＤが２１、２２、５０の制御プロ
セスが存在し、それぞれ８００、１３２、９５の重みを
有するテーブルを示している。サブプール用重みテーブ
ルには、サブプールのＩＤが格納されているので、当該
プロセッサに存在するサブプールの検索や、あるサブプ
ールが当該プロセッサに存在するか否かの確認に用いら
れる。

【００１３】次に、プロセッサ間で子プロセスを授受す
る際の重みの変化について説明する。プロセッサは子プ
ロセス（を運ぶメッセージ）に重みを付けて送信する。 その際、子プロセスに付けた分だけサブプールの重みを
減らす。他方、プロセッサは子プロセスを受信すると、
サブプール用重みテーブルに基づいてそのＩＤのサブプ
ールが存在していたか否かを判断する。存在していると
、付いていた重みを受信した子プロセスと同じＩＤのサ
ブプールに追加する。存在していないと、そのＩＤのサ
ブプールを新しく生成し、受信した子プロセスに付いて
いた重みをそのサブプールの重みとする。

【００１４】図７は、送信プロセッサＰＥｉが、ＩＤが
Ａのある子プロセスに重み４０を付与して送信すること
でそのサブプールの重みが４２０から３８０に変化し、
他方、この子プロセスを受信したプロセッサＰＥｊにお
いては、ＩＤがＡの既存のサブプールの重みがこの受信
によって２２０から２６０に変化したことを示している
。図８は、送信プロセッサＰＥｉが、ＩＤがＡのある子
プロセスに重み４０を付与して送信することでそのサブ
プールの重みが４２０から３８０に変化し、他方、この
子プロセスを受信したプロセッサＰＥｊにおいては、Ｉ
ＤがＡのサブプールが存在せず、そのため、重み４０を
有するＩＤがＡのサブプールを生成したことを示してい
る。

【００１５】次に、サブプールから制御プロセスに終了
メッセージを通信する際の重みの変化について説明する
。サブプールが終了すると終了メッセージを制御プロセ
スに送信する。終了メッセージには終了したサブプール
が有していた重みを全て付ける。また、終了したサブプ
ールをサブプール用重みテーブルから削除する。制御プ
ロセスは、終了メッセージを受信すると、付与されてい
た重みを自己の重みに加える。加えた結果の重みが０に
なると、プロセスプールの終了（全ての子プロセスが終
了したこと）を検出する。

【００１６】図９は、ＩＤがＡのサブプールが終了し、
自己の重み３４０を付与した終了メッセージを制御プロ
セスに送信し、これにより制御プロセスの重みが−１４
００から−１０６０に変化した例を示している。図１０
は、当初において重み−２５００が付与されている制御
プロセスに、全てのサブプールのそれぞれから順次その
サブプールが有していた重み１０００、８００、７００
が付与されている終了メッセージが与えられ、制御プロ
セスの重みが０になってプロセスプールの終了を検出し
た場合を示している。

【００１７】（３）「状態変更方式」 プロセスプールの全子プロセスの状態を変更するために
は、制御プロセスが「特定のＩＤを持つサブプールに属
する全ての子プロセスの状態を変更するメッセージ」（
以下、状態変更メッセージと呼ぶ）を全てのプロセッサ
へ送信することを要する。しかし、この状態変更メッセ
ージの送信だけでは、子プロセスの完全な状態変更はで
きない。すなわち、非同期メッセージ通信を利用して子
プロセスを通信するようにしているので、図１１に示す
ように、全てのサブプールに状態変更メッセージが与え
られたときにいずれのサブプールにも属さない通信中の
子プロセスが存在し得、この通信中の子プロセスの状態
は変更できない。なお、図１１において、制御プロセス
及び子プロセスに係る「ａ」及び「ｂ」の文字は状態を
表している。

【００１８】上述した文献Ａは、プロセッサがサブプー
ルを生成したときにその旨を制御プロセスへ伝えること
によって、通信中のプロセスの存在を制御プロセスが認
識してその通信中にあった子プロセスの状態をも変更で
きる方式を記載している。以下、状態変更メッセージの
送信時に通信中の子プロセスが存在していても、その子
プロセスの状態をも変更できる従来の状態変更方式を、
メッセージの追い越しがないシステムの場合と、メッセ
ージの追い越しがあるシステムの場合とに分けて説明す
る。

【００１９】（３−１）　メッセージの追い越しがない
場合プロセッサは、サブプールを生成するとその生成を
伝えるメッセージ（以下、生成メッセージと呼ぶ）を制
御プロセスへ送信する。制御プロセスは、生成メッセー
ジを受信するとその送信元プロセッサを記憶し、終了メ
ッセージを受信すると削除する。制御プロセスに記憶さ
れているプロセッサには必ずサブプールが存在する。生
成メッセージの送信元プロセッサを記憶するために各プ
ロセッサはサブプールテーブルを有する。サブプールテ
ーブルは、図１２に示すように、サブプールのＩＤと、
生成メッセージの送信元プロセッサとからなる。

【００２０】（３−１−１）　制御プロセスの処理この
サブプールテーブルをも用いた状態変更の際の制御プロ
セスの処理は、以下の通りである。サブプールテーブル
に登録されているプロセッサのみに状態変更メッセージ
を送信する。かかる処理の後に、生成メッセージを受信
したならば、その送信元プロセッサを記憶し、状態変更
メッセージを送信する。なお、状態変更メッセージにも
重みを付け、制御プロセスの重みはその分だけ減らす。

【００２１】（３−１−２）　プロセッサの処理状態変
更メッセージを受信したプロセッサは、まず、状態変更
メッセージが示すＩＤと同じＩＤのサブプールが存在す
るか否かをサブプール用重みテーブルを検索することで
調べる。

【００２２】サブプールが存在した場合には、そのサブ
プールに属する全ての子プロセスの状態を状態変更メッ
セージが指定した状態に変更する。また、状態変更メッ
セージが持っていた重みをサブプールの重みに加える。

【００２３】他方、サブプールが存在しなかった場合に
は、状態変更メッセージが有していた重みを送返すメッ
セージ（以下、重み返却メッセージと呼ぶ）を制御プロ
セスへ送ることで、状態変更メッセージが持っていた重
みを制御プロセスへ返す。

【００２４】（３−１−３）　状態変更状態変更開始時
点で制御プロセスが認識していた（サブプールテーブル
に登録されていた）サブプール内に存在した子プロセス
は、上述した最初の状態変更メッセージの送信によって
状態が変更される。一方、開始時点で通信中であった子
プロセスは、生成メッセージの受信後に再送信された状
態変更メッセージによって状態が変更される。これは、
通信中の子プロセスは有限時間内にどこかのプロセッサ
に到着し、サブプールが生成され、生成メッセージが制
御プロセスに送られるからである。

【００２５】図１３ないし図１６は、サブプールテーブ
ルに登録されていたプロセッサＰＥｉ及びＰＥｊ内のサ
ブプールに属する子プロセスは当初の状態変更メッセー
ジによって状態が変更（ａからｂへ）され、最初の状態
変更メッセージの送出時点で通信中の子プロセスは、サ
ブプールテーブルに登録されていないその送信先のプロ
セッサＰＥｋが制御プロセスに生成メッセージを送信し
た後に、制御プロセスが再度送信した状態変更メッセー
ジによって、その状態が変更されることを示したもので
ある。

【００２６】（３−２）　メッセージの追い越しがある
場合メッセージの追い越しがある（システムの）場合に
おいては、ある状態への変更を指示する状態変更メッセ
ージが、後から送信された別の状態への変更を指示する
状態変更メッセージに追い越されてしまう可能性がある
。そのため、受信した状態変更メッセージに従って単純
に状態を変更したのでは状態が正しく変更されない恐れ
がある。例えば、制御プロセスが、まず、状態ａへ変更
する状態変更メッセージ（以下、状態変更メッセージ（
ａ）と書くことにする）を送信し、次に、状態ｂへ変更
する状態変更メッセージ（ｂ）を送信した場合には、子
プロセスの状態は最終的には状態ｂに設定されるべきで
あるが、状態変更メッセージ（ｂ）が状態変更メッセー
ジ（ａ）を追い越してしまうと最終的には状態ａに設定
されてしまう。

【００２７】そのため、メッセージの追い越しがある場
合に特有な処理が必要である。上述した文献Ａには、扱
う状態が２状態に限定されているが、メッセージの追い
越しがある場合にも問題が生じないようにした方式を記
載している。この方式は、扱う状態をｓｔｏｐとｓｔａ
ｒｔ　の２状態に限定し、受信した状態変更メッセージ
数をカウントすることによって状態を正しく設定する方
式である。

【００２８】以下、具体的に説明する。プロセッサは、
サブプール毎にカウンタを設け、以下のように操作する
。例えば、サブプール用重みテーブル（図６）にカウン
タフィールドを設けて、カウンタの値を以下のように操
作する。サブプールを生成したときには０をセットする
。状態変更メッセージ（ｓｔｏｐ）を受信したときには
＋１する。状態変更メッセージ（ｓｔａｒｔ　）を受信
したときは−１する。

【００２９】状態変更メッセージ（ｓｔｏｐ）又は状態
変更メッセージ（ｓｔａｒｔ　）を受信したときには、
上述のようにカウンタを操作した後、以下のように状態
を設定する。カウンタの値が正ならば状態をｓｔｏｐに
設定する。カウンタの値が０以下ならば状態をｓｔａｒ
ｔ　に設定する。

【００３０】このようにして、状態変更メッセージ（ｓ
ｔｏｐ）と状態変更メッセージ（ｓｔａｒｔ）の到着順
序が入れ代わっても、以上の操作により状態は正しく設
定される。

【００３１】図１７は、サブプールが状態ｓｔａｒｔ　
、カウンタの値０にあるときに、制御プロセスがそのサ
ブプールの状態を状態ｓｔｏｐに変更させる状態変更メ
ッセージ（ｓｔｏｐ）と、状態ｓｔａｒｔ　に変更させ
る状態変更メッセージ（ｓｔａｒｔ　）とをこの順に送
信し、後で送信された状態変更メッセージ（ｓｔａｒｔ
　）が先にプロセッサに到着しても最終的な状態が正し
く状態ｓｔａｒｔ　に設定される様子を示したものであ
る。

【００３２】

【発明が解決しようとする課題】（１）追い越しがある
場合及びない場合に共通の課題 しかしながら、従来のプロセス状態変更方式によれば、
メッセージの追い越しがあるシステム及び追い越しがな
いシステムのいずれに適用しても、以下のような問題が
あった。

【００３３】各プロセッサが、状態変更のために、サブ
プールを生成したときには制御プロセスへ生成メッセー
ジを送信するという準備処理が必要であった。実際上、
各プロセッサの均一な稼動率を得るように、又は、プロ
セスの並行処理や高速処理を期して子プロセスが通信さ
れることも多く、生成メッセージの送信回数も多くなる
。最悪の場合、送信される子プロセスと同数の生成メッ
セージが送信されてしまう。しかしながら、結果として
状態の変更が指示されないプロセスプールもあり、この
ようなプロセスプールについての生成メッセージの通信
は無駄であり、この回数が多いことは問題である。

【００３４】制御プロセスが、生成メッセージを受信し
たときに、その送信元プロセッサを記憶する必要がある
。１個のサブプールについて記憶するだけでも全てのプ
ロセッサ数分の容量が必要であり、複数になるとその数
に応じた容量が必要でこのテーブルがメモリ容量を圧迫
していた。

【００３５】また、従来の方式によれば、制御プロセス
が状態の変更が完了したことを確認することができない
。すなわち、ある状態変更メッセージを送信した場合、
有限時間内に全ての子プロセスの状態変更が完了するこ
とは保証できるが、変更の完了を検出することはできな
い。そのため、制御プロセスによる状態制御が適切に実
行されない恐れも生じる。

【００３６】（２）追い越しがある場合に特有な課題メ
ッセージの追い越しがあるシステムの場合には、上述の
問題に加えて、さらに以下のような問題もある。

【００３７】状態変更メッセージの受信を管理するカウ
ンタをサブプール毎に用意しなければならず、このカウ
ンタの操作が非常に複雑であり、また、この情報もメモ
リ容量の圧迫を引き起こす原因となっていた。

【００３８】また、取り扱う状態が２状態に限定されて
おり、これより多い状態を取り扱うシステムに適用する
ことができない。

【００３９】（３）目的 本発明は、以上の点を考慮してなされたものであり、状
態変更処理期間以外に行なう状態変更のための準備処理
が不要な、状態変更処理のために必要なメモリ容量が少
ない、しかも、制御プロセスが状態変更の完了を検出す
ることができる、取り扱うことができる状態数が制限さ
れないプロセス状態変更方式を提供しようとするもので
ある。

【００４０】

【課題を解決するための手段】かかる課題を解決するた
め、本発明においては、非同期メッセージ通信によって
プロセッサ間処理を行なうマルチプロセッサシステムの
プロセス状態変更方式であって、１個の制御プロセスと
１個以上の子プロセスからなるプロセスプールの、各プ
ロセッサに存在するサブプールの状態を、制御プロセス
が、各プロセッサの状態変更部を制御して変更させるプ
ロセス状態変更方式を、以下の第１ないし第６の処理に
よって実現した。

【００４１】第１の処理：全てのプロセッサに状態変更
メッセージを送信する制御プロセスが行なう処理。

【００４２】第２の処理：各プロセッサの状態変更部が
状態変更メッセージを受信したときに行なう処理であっ
て、当該プロセッサに状態変更が求められたサブプール
が存在する場合にそのサブプールの状態を変更させて変
更済みメッセージを制御プロセスに送信すると共に状態
変更中情報を記憶し、当該プロセッサに状態変更が求め
られたサブプールが存在しない場合に状態変更中情報を
記憶する処理。

【００４３】第３の処理：状態変更中情報を記憶してい
る状態で他のプロセッサから子プロセスが与えられた場
合に、受信した子プロセスの状態を変更し、変更済みメ
ッセージを制御プロセスに送信する、各プロセッサの状
態変更部が行なう処理。

【００４４】第４の処理：受信した変更済みメッセージ
に基づいてプロセスプールの状態の変更の完了を監視し
、完了を検出したときに、全てのプロセッサに完了メッ
セージを送信する、制御プロセスが行なう処理。

【００４５】第５の処理：各プロセッサの状態変更部が
、完了メッセージを受信した場合に行なう処理であって
、状態変更中情報を削除すると共に、完了メッセージに
対する到着確認メッセージを制御プロセスに送信する処
理。

【００４６】第６の処理：全てのプロセッサから到着確
認メッセージを受信したとき、プロセスプールの状態変
更処理を終了させる制御プロセスが行なう処理。

【００４７】

【作用】本発明において、あるプロセスプールの状態の
変更が必要になると、制御プロセスは、全てのプロセッ
サに状態変更メッセージを送信する（第１の処理）。

【００４８】このとき、各プロセッサの状態変更部は、
当該プロセッサに状態変更が求められたサブプールが存
在する場合にはそのサブプールの状態を変更させて変更
済みメッセージを制御プロセスに送信すると共に状態変
更中情報を記憶し、当該プロセッサに状態の変更が求め
られたサブプールが存在しない場合には状態変更中情報
を記憶する（第２の処理）。

【００４９】なお、各プロセッサの状態変更部は、状態
変更中情報を記憶している状態で、他のプロセッサから
子プロセスが与えられた場合にはその子プロセスの状態
を変更し、変更済みメッセージを制御プロセスに送信す
る（第３の処理）。

【００５０】制御プロセスは、状態変更メッセージの送
信後、変更済みメッセージの受信を待ち受けており、受
信すると、受信した変更済みメッセージに基づいてプロ
セスプールの状態変更の完了を監視し、完了を検出した
ときに全てのプロセッサに完了メッセージを送信する（
第４の処理）。

【００５１】各プロセッサの状態変更部は、完了メッセ
ージを受信すると、状態変更中情報を削除すると共に、
完了メッセージに対する到着確認メッセージを制御プロ
セスに送信する（第５の処理）。

【００５２】制御プロセスは、全てのプロセッサから到
着確認メッセージを受信することによって、プロセスプ
ールの状態の変更処理を終了する（第６の処理）。

【００５３】

【実施例】以下、本発明の一実施例を図面を参照しなが
ら詳述する。なお、計算モデルは「従来の技術」の項で
説明した通りである。

【００５４】（１）テーブル この実施例において、各プロセッサは、テーブルとして
、制御プロセス用重テーブル及びサブプール用重みテー
ブルを有する。すなわち、従来とは異なり、サブプール
テーブルは設けられていない。

【００５５】（１−１）　制御プロセス用重みテーブル
この実施例の制御プロセス用重みテーブルは、図１８に
示すように、３個のフィールドからなっている。第１フ
ィールドには当該プロセッサに存在する制御プロセスに
係るプロセスプールのＩＤが格納されている。第２フィ
ールドには、制御プロセスに付与された重みが格納され
ている。第３フィールドは、状態変更処理時の作業エリ
アとして用いられるものであり、状態変更処理時の状態
変更が完了した分の子プロセスの重みや後述する到着確
認メッセージの受信していない数などを格納する。

【００５６】図１８は、ＩＤが０、１２、３２５０及び
４０００の制御プロセスについて、それぞれ重み−３０
０、−８２００、−５９００及び−７５が格納され、Ｉ
Ｄが３２５０のプロセスプールについては子プロセスの
状態の変更処理中であって重みが−３７００分の子プロ
セスについて状態の変更が完了していることを示してい
る。

【００５７】（１−２）　サブプール用重みテーブルこ
の実施例のサブプール用重みテーブルは、図１９に示す
ように、３個のフィールドからなっている。第１フィー
ルドには当該プロセッサに存在するサブプールに係るプ
ロセスプールのＩＤが格納されている。第２フィールド
には、サブプールに付与された重みが格納されている。 第３フィールドは新状態フィールドであって状態変更中
の新しい状態を格納している。新状態フィールドに状態
が書かれているときは、そのサブプールが状態変更中で
あることを意味する。なお、後述するように、メッセー
ジの追い越しがある場合には、新状態フィールドに状態
変更メッセージの受信待ちにあることが格納されること
がある。

【００５８】図１９は、ＩＤが３、５５、２３００及び
７２１４のサブプールについてそれぞれ重み３１００、
５５、２０９、２０３４０が格納され、ＩＤが２３００
のサブプールについては状態ｂへの変更中であることを
示している。

【００５９】この実施例のサブプール用重みテーブルに
も、上述したようにサブプールのＩＤが格納されている
ので、当該プロセッサに存在するサブプールの検索や、
あるサブプールが当該プロセッサに存在するか否かの確
認に用いられる。

【００６０】（２）子プロセスの送受信処理（２−１）
　子プロセスの送信処理 子プロセスを送信しようとするときには、サブプール用
重みテーブルを検索し、そのＩＤの子プロセスの状態の
変更処理中であるか否かを判別する。すなわち、新状態
フィールドに状態が記憶されているか否かを判別する。 状態変更中でない場合には、上述したＷＴＣ方式に従い
、子プロセスに重みを付けて送信する。この際には、サ
ブプールの重みをその分だけ減じる。すなわち、サブプ
ール用重みテーブルの重みフィールドの値を更新する。 なお、この減算によって重みが０になると、サブプール
用重みテーブルからそのサブプールを削除する。他方、
サブプール用重みテーブルの検索の結果、状態変更中で
あると、状態変更が完了して通常状態（状態変更中でな
い状態）になるのを待ち、通常状態になったときに上述
したＷＴＣ方式に従った送信を行なう。

【００６１】（２−２）　子プロセスを受信したときの
処理子プロセスを受信すると、正確には、子プロセスを
運ぶメッセージを受信すると、まず、サブプール用重み
テーブルを検索する。すなわち、受信した子プロセスと
同じＩＤのサブプールが既に存在しているか又は存在し
ていないかを調べ、存在している場合にはさらに、その
サブプールが通常状態にあるのか又は状態変更中である
のかを調べる。

【００６２】（２−２−１）　受信した子プロセスと同
じＩＤのサブプールが存在しない場合には、そのＩＤを
有するサブプールを生成して、サブプール用重みテーブ
ルに登録する。このとき、受信した子プロセスの重みを
生成したサブプールの重みの初期値とする。

【００６３】（２−２−２）　受信した子プロセスと同
じＩＤのサブプールが存在していて、そのサブプールが
通常状態にある場合には、受信した子プロセスの重みを
そのサブプールの重みに加える。すなわち、サブプール
用重みテーブルの重みフィールドの値をその加算値に更
新する。

【００６４】（２−２−３）　受信した子プロセスと同
じＩＤのサブプールが存在していて、そのサブプールが
状態変更中である場合には、子プロセスの状態をサブプ
ール用重みテーブルの新状態フィールドに書かれている
新しい状態に変える。また、子プロセスが持っていた重
みをサブプールの重みに加える。さらに、子プロセスが
持っていた重みを、変更済みメッセージによって制御プ
ロセスへ送る。この変更済みメッセージは、「この重み
分だけ子プロセスに対して状態の変更を行なった」とい
うことを伝えるものである。なお、この場合には、状態
変更中であることの情報を継続してサブプール用重みテ
ーブルに格納しておく。

【００６５】図２０は、ＩＤが８、重みが３５０であっ
て状態ｂへの変更処理中にあるサブプールを有するプロ
セッサが、他のプロセッサから送信された重みが５０、
ＩＤが８、状態がａの子プロセスを受信したため、サブ
プール用重みテーブルの重みを４００に更新すると共に
、制御プロセスに重みが５０の変更済みメッセージを送
信した場合を示している。

【００６６】なお、制御プロセスは、変更済みメッセー
ジを受信した場合には、制御プロセス用重みテーブルの
作業エリアの重みを更新する。

【００６７】（３）状態変更処理 次に、プロセスプールの全ての子プロセスの状態を変更
する処理について説明する。メッセージの追い越しがな
いシステムの場合及びメッセージの追い越しがあり得る
システムの場合共に、状態変更処理の特徴部分は同じで
あるが、以下では場合を分けて説明する。

【００６８】（３−１）　メッセージの追い越しがない
場合（３−１−１）　一般的な処理の流れ メッセージの追い越しがないシステムの状態変更処理を
、図１のフローチャーを参照しながら詳述する。なお、
図１（Ａ）は制御プロセスの処理を示しており、図１（
Ｂ）はプロセッサ（ソフトウェア、ハードウェア、ファ
ームウェアのいずれで実現されていようがプロセッサの
状態変更部と呼ぶべきであるかも知れないが、以下でも
プロセッサと呼ぶ）の処理を示している。また、図１で
は「メッセージ」を略して「ＭＳ」で表している。

【００６９】あるプロセスプールについて状態変更の必
要が生じると、制御プロセスは図１（Ａ）に示す処理を
開始する。そして、まず、全てのプロセッサに対して新
しい状態を運ぶ状態変更メッセージを送信すると共に（
ステップ１００）、制御プロセス用重みテーブルのその
サブプールの重みフィールドの値（重み）を作業エリア
フィールドに複写する（ステップ１０１）。作業エリア
の重みは、状態変更が未だなされていない子プロセスの
重みの合計を示すものである。その後、制御プロセスは
、変更済みメッセージの受信待ち状態に進む（ステップ
１０２）。なお、全てのプロセッサが送信先である点は
従来とは異なる。また、状態変更メッセージに重みを付
与する必要がない。

【００７０】状態変更メッセージを受信した各プロセッ
サは、図１（Ｂ）に示す処理を開始する。そしてまず、
状態変更が指示されたサブプールが存在するか否かを、
サブプール用重みテーブルを用いて調べる（ステップ２
００）。

【００７１】サブプールが存在した場合には、そのサブ
プールに属する全ての子プロセスの状態を状態変更メッ
セージが示す新しい状態に変更し（ステップ２０１）、
サブプール用重みテーブルの新状態フィールドにその新
しい状態を書き込む（ステップ２０２）。その後、サブ
プールが持っていた重みを全て付けた変更済みメッセー
ジを制御プロセスへ返信する（ステップ２０３）。上述
したように、サブプールが持っていた重みを全て付けた
変更済みメッセージは、「この重みの子プロセス分だけ
状態の変更を行なった」ことを意味している。なお、サ
ブプール用重みテーブルの重みをこの送信後にも保持し
ておく。

【００７２】他方、サブプールが存在しなかった場合に
は、そのサブプールをサブプール用重みテーブルに登録
した後（ステップ２０４）、状態変更メッセージが示す
プロセスプールが状態変更中であることをサブプール用
重みテーブルに書込む（ステップ２０５）。すなわち、
プロセッサは、重みフィールドには０を、新状態フィー
ルドには新しい状態を書込む。その後、メッセージの受
信待ち状態に進む（ステップ２０６）。

【００７３】制御プロセスは、上述したように、状態変
更メッセージを送信した後は変更済みメッセージッセー
ジの受信待ち状態に進み、いずれかのプロセッサからの
変更済みメッセージを受信すると、その変更済みメッセ
ージに付与されている重みを制御プロセス用重みテーブ
ルの作業エリアに格納されている重みに加算した後（ス
テップ１０３）、加算後の重みが全ての子プロセスの状
態変更が完了したことを表す０であるか否かを判別する
（ステップ１０４）。０でない場合には、変更済みメッ
セージの受信待ち状態に戻る。変更済みメッセージの受
信が進むに従って、作業エリアの重みは０に近付いてい
き、やがて０となってステップ１０４で肯定結果が得ら
れる。

【００７４】このときには、制御プロセスは、全てのプ
ロセッサに対して完了メッセージを送信する（ステップ
１０５）。ここで、完了メッセージとは、「そのＩＤの
全ての子プロセスの状態変更が完了したことを伝えるメ
ッセージ」である。その後、送信した完了メッセージ数
（プロセッサ数に等しい：図１ではＴで表している）を
、制御プロセス用重みテーブルの作業エリアに書込む（
ステップ１０６）。そして、到着確認メッセージの受信
待ち状態に進む（ステップ１０７）。

【００７５】プロセッサが、新しい状態を格納すること
で状態変更中であることをサブプール用重みテーブルに
設定した後のメッセージ受信待ち状態（ステップ２０６
）において、メッセージを受信すると受信したメッセー
ジの種別を判別する（ステップ２０７）。この状態変更
中のサブプールに対して送信されてくるメッセージは、
子プロセスを運搬するメッセージ又は完了メッセージで
ある。

【００７６】子プロセスを運搬するメッセージであると
、上述した子プロセスの受信処理で説明した処理を行な
う（ステップ２０８）。すなわち、子プロセスの状態を
新しい状態に変え、子プロセスが持っていた重みをサブ
プールの重みに加え、子プロセスが持っていた重みを、
変更済みメッセージによって制御プロセスへ送る。 その後、メッセージの受信待ち状態に戻る。

【００７７】子プロセスを運搬するメッセージを状態変
更中に受信したか否かに拘らず、完了メッセージは必ず
受信する。このときには、プロセッサは、サブプール用
重みテーブルの重みフィールドの重みが０であるか否か
を判断する（ステップ２０９）。すなわち、状態変更メ
ッセージの受信時において当該プロセッサにサブプール
が存在せず、新状態を記憶するためにサブプール用重み
テーブルに追加登録されたサブプール（ステップ２０４
参照）であるか否かを確認する。

【００７８】重みが０でない場合には、すなわち、状態
変更メッセージの受信時において当該プロセッサに存在
していたサブプールについては、サブプール用重みテー
ブルの新状態フィールドに格納されている状態を削除す
ることでそのサブプールを状態変更中から通常状態に復
帰させた後（ステップ２１０）、完了メッセージに対す
る到着確認メッセージを制御プロセスに返信して一連の
処理を終了する（ステップ２１１）。

【００７９】他方、重みが０か否かの判断で重みが０で
あるという結果を得ると、サブプール用重みテーブルか
らそのサブプールを削除した後（ステップ２１２）、完
了メッセージに対する到着確認メッセージを制御プロセ
スに返信して一連の処理を終了する（ステップ２１１）
。

【００８０】制御プロセスは、いずれかのプロセッサか
らの到着確認メッセージを受信すると、制御プロセス用
重みテーブルの作業エリアフィールドに格納されている
完了メッセージ送信数Ｔを１デクリメントした後（ステ
ップ１０８）、その値Ｔが０か否かを確認する（ステッ
プ１０９）。０でない場合には、到着確認メッセージの
受信待ち状態に戻る。このような処理を繰返すうちに全
てのプロセッサからの到着確認メッセージを受信して完
了メッセージ送信数（到着確認メッセージ数）Ｔが０と
なり、このときには制御プロセス用重みテーブルの作業
エリアフィールドをリセットして一連の処理を終了する
（ステップ１１０）。

【００８１】（３−１−２）　状態変更処理とサブプー
ルの終了以上、プロセスプールに属する全ての子プロセ
スの状態を変更する基本的な処理の流れを説明したが、
このような状態変更の処理中にサブプール（子プロセス
）が終了することがある。以下では、サブプールの終了
と状態変更処理との関係を説明する。

【００８２】状態変更中であるサブプールが終了した場
合には、プロセッサは、変更済みメッセージの送信を、
状態の変更が完了するのを待って行なう。完了メッセー
ジを受信し、到着確認メッセージを送信した後に終了メ
ッセージを送信する。終了メッセージを先に送信した場
合には、サブプール用重みテーブルからサブプールが削
除されて、上述した完了メッセージを受信した際の処理
を実行し得ないからである。

【００８３】状態変更中ではないサブプールが終了した
場合には、プロセッサは通常の終了処理を行なう。すな
わち、制御プロセスに終了メッセージを送信し、終了し
たサブプールをサブプール用重みテーブルから削除する
。

【００８４】状態変更中に終了メッセージを制御プロセ
スが受信した場合は、制御プロセス用重みテーブルの重
みフィールド及び作業エリアフィールドの両者の重みを
、終了メッセージに付与されていた重み分更新する。 この結果、作業エリアフィールドの重みが０になった場
合にも、全ての子プロセスの状態変更が完了したとして
完了メッセージの送信処理に進む。

【００８５】（３−１−３）　具体例での説明次に、図
２１ないし図２５を参照しながら、プロセス状態変更処
理を具体例を用いて説明する。

【００８６】図２１は、状態をａからｂへ変更させる状
態変更メッセージが送信された時点において、状態変更
の対象のサブプールが存在するプロセッサがＰＥｉ及び
ＰＥｊの２個であって、プロセッサＰＥｊからプロセッ
サＰＥｉに向かう子プロセス（運搬メッセージ）と、プ
ロセッサＰＥｊからプロセッサＰＥｋに向かう子プロセ
スとが存在している例を示している。

【００８７】サブプールが存在するプロセッサＰＥｉ及
びＰＥｊはそれぞれ状態変更メッセージを受信すると、
図２２に示すように、サブプールの状態をａからｂに変
更した後、サブプールの重み２０００、１６５０を付与
した変更済みメッセージを制御プロセスに返信すると共
に、状態変更中であることをサブプール用重みテーブル
に格納する。一方、サブプールが存在しないプロセッサ
ＰＥｋは、図示しない他のプロセッサと同様に、状態変
更メッセージを受信すると、図２２に示すように、その
サブプールをサブプール用重みテーブルに登録して状態
変更中であることをサブプール用重みテーブルに格納す
る。この段階で送信された変更済みメッセージを制御プ
ロセスが受信しても、通信中の子プロセスが存在するた
め、制御プロセス用重みテーブルの作業エリアの重みは
０にはならない。

【００８８】状態変更中であることをサブプール用重み
テーブルに格納した後、子プロセスを受信したプロセッ
サＰＥｉ及びＰＥｋはそれぞれ、図２３に示すように、
受信した子プロセスの状態を新しい状態ｂに変更すると
共に、受信した子プロセスの重みを付与した変更済みメ
ッセージを制御プロセスに送信する。この送信後も状態
変更中であることを維持する。勿論、プロセッサＰＥｉ
及びＰＥｋはそれぞれ、子プロセスを受信すると、サブ
プール用重みテーブルの重みフィールドの値を更新する
。

【００８９】これらの状態変更メッセージを受信して作
業エリアの重みの更新処理を行なうと、その重みは０に
なる。このとき、制御プロセスは、図２４に示すように
、これらプロセッサＰＥｉ及びＰＥｋだけでなく全ての
プロセッサに対して完了メッセージを送信する。また、
制御プロセスは完了メッセージの送信数Ｔを作業エリア
に格納する。

【００９０】子プロセスが属しているサブプールが存在
する各プロセッサＰＥｉ、ＰＥｊ、ＰＥｋは完了メッセ
ージを受信すると、図２５に示すように、状態変更中を
通常状態に復帰させた後到着確認メッセージを制御プロ
セスに返信して一連の処理を終了する。子プロセスがな
いサブプール（重み０でテーブルに登録されている）が
存在する図示しない他の各プロセッサは完了メッセージ
を受信すると、テーブルからサブプールを削除した後、
到着確認メッセージを制御プロセスに返信して一連の処
理を終了する。制御プロセスは、完了メッセージを送信
した数Ｔだけ到着確認メッセージを受信して作業エリア
の値が０になると、作業エリアをクリアして一連の処理
を終了する。

【００９１】（３−２）　メッセージの追い越しがある
場合上述したメッセージの追い越しがない場合の強制終
了方式を、メッセージの追い越しがある場合にそのまま
適用することはできない。以下では、変更する処理部分
について説明する。

【００９２】メッセージの追い越しが問題になるのは、
完了メッセージが状態変更メッセージを追い越してしま
う場合（サブプールが存在しないプロセッサについての
み生じる現象である）と、終了メッセージが到着確認メ
ッセージを追い越してしまう場合である。到着確認メッ
セージ同士の追い越しは同一のメッセージであるため、
問題となることはない。

【００９３】（３−２−１）　完了メッセージによる状
態変更メッセージの追い越し 追い越しした完了メッセージの受信時の処理を規定して
いない場合には、このような追い越した完了メッセージ
や追い越された状態変更メッセージの受信によってシス
テムが暴走する等の不都合を生じる。そのため、メッセ
ージの追い越しがある場合には、完了メッセージが状態
変更メッセージを追い越した際の処理を明確に規定して
おくことを要する。

【００９４】まず、完了メッセージをプロセッサが受信
した場合の処理を説明する。完了メッセージを受信した
場合には、単純に到着確認メッセージを送信するのでは
なく、状態変更メッセージを受信しているか否かを調べ
、未受信であったならば状態変更メッセージの受信を待
って到着確認メッセージを送信する必要がある。状態変
更メッセージの受信済み／未受信は、サブプール用重み
テーブルを検索することによって調べることができる。 該当するＩＤが登録されていて、新状態フィールドに状
態が格納されていれば（すなわち状態変更中であれば）
受信済みであり、これ以外の場合には未受信である。

【００９５】従って、プロセッサの処理は以下のように
なる。まず、状態変更メッセージの受信済み／未受信を
調べる。その結果、受信済みの場合（追い越しがなかっ
た場合）には追い越しがない場合と同様に処理する。未
受信の場合（追い越しがあった場合）には、完了メッセ
ージが示すＩＤのサブプールが存在するか否かを判断し
、存在する場合には直ちに、存在しない場合にはテーブ
ルにそのサブプールを登録した後に、新状態フィールド
に「状態変更メッセージ待ち」を書込む。なお、サブプ
ールが登録されていない場合において登録する際には重
みフィールドに０を書く。

【００９６】次に、状態変更メッセージをプロセッサが
受信した場合の処理を説明する。状態変更メッセージを
受信した場合にも完了メッセージの受信済み／未受信に
よって異った処理を行なう。完了メッセージの受信済み
／未受信は、サブプール用重みテーブルを検索すること
によって調べることができる。すなわち、該当するＩＤ
の新状態フィールドに「状態変更メッセージ待ち」が書
き込まれていたならば受信済み、それ以外は未受信であ
る。

【００９７】従って、プロセッサの処理は、以下のよう
になる。まず、完了メッセージの受信済み／未受信を調
べる。その結果、未受信の場合（追い越しがなかった場
合）には追い越しがない場合と同様に処理する。完了メ
ッセージが受信済みの場合（追い越しがあった場合）に
は、追い越しがない場合の完了メッセージを受信した際
の処理を行なう。すなわち、重みフィールドが０でなけ
れば新状態フィールドをクリアして通常状態に戻すと共
に、完了メッセージの到着確認メッセージを制御プロセ
スに送信し、重みフィールドが０の場合にはそのサブプ
ールの登録をテーブルから削除した後、完了メッセージ
の到着確認メッセージを制御プロセスに送信する。

【００９８】（３−２−２）　終了メッセージによる到
着確認メッセージの追い越し 上述したように、状態変更中であるサブプールが終了し
た場合には、プロセッサは、到着確認メッセージを送信
した後に終了メッセージを送信する。しかし、メッセー
ジの追い越しがあるシステムの場合には、終了メッセー
ジが先に制御プロセスに届くことがある。この終了メッ
セージの受信によっては、制御プロセス用重みテーブル
からそのサブプールが削除されることもある。この後に
到着確認メッセージが制御プロセスで受信されても、制
御プロセスはどのような処理を実行すれば良いかが明確
ではなく、暴走の恐れがある。そのため、メッセージの
追い越しがある場合には、終了メッセージが到着確認メ
ッセージを追い越した際の処理を明確に規定しておくこ
とを要する。

【００９９】プロセスプールの終了を確認するには重み
が０になっただけでは不十分であり、全ての到着確認メ
ッセージの受信を確認する必要がある。制御プロセス用
重みテーブルの作業エリアには未受信の到着確認メッセ
ージの数が書かれているので、作業エリアを調べること
によって全ての到着確認メッセージの受信を確認するこ
とができる。

【０１００】まず、終了メッセージの受信時の処理を説
明する。制御プロセスは終了メッセージを受信したこと
によってＷＴＣ方式に従って重みを更新し、その重みが
０になった場合には、制御プロセス用重みテーブルの作
業エリアを調べる。作業エリアが０の場合には、全ての
到着確認メッセージを受信済みであるので、プロセスプ
ールの終了を検出する。すなわち、プロセスプールのテ
ーブルからの削除を行なう。他方、０でない場合には、
受信していない到着確認メッセージが残っているので、
なんら処理することなく到着確認メッセージを待ち受け
る状態のままとし、重みが０であってもプロセスプール
の終了と検出することを留保しておく。すなわち、プロ
セスプールのテーブルからの削除を実行しない。

【０１０１】次に、到着確認メッセージの受信時の処理
を説明する。このときには、作業エリアの値を更新して
それが０か否かを判断する。０でない場合には、受信し
ていない到着確認メッセージがあるので、重みフィール
ドの値を調べることなく、次の到着確認メッセージを待
ち受ける状態のままとする。他方、作業エリアの値が更
新により０になると、全ての到着確認メッセージを受信
したので、さらに重みフィールドの値が０か否かを調べ
る。０であれば、そのプロセスプールの終了を検出した
としてテーブルから削除する。他方、重みが０の場合に
は、状態変更は完了したが、プロセスプールは終了して
いるわけではないので、作業エリアをクリアする処理の
みを行なう。

【０１０２】（４）実施例の効果 上述の実施例によれば、以下の効果を得ることができる
。

【０１０３】状態変更処理期間以外に、状態変更のため
の処理を行なう必要がない。例えば、生成メッセージの
送信処理等が不要である。すなわち、状態変更がなされ
ないサブプールに対する生成メッセージの送信処理は結
局のところ無駄であるが、このような無駄な処理が生じ
ない。

【０１０４】状態変更処理に必要なテーブルは、通常の
終了処理でも用いるテーブルだけであって、状態変更処
理だけに用いるテーブルは不要であり、メモリ資源の有
効利用を実現することができる。

【０１０５】メッセージの追い越しがあるシステム及び
追い越しがないシステムの両方に適用可能であり、しか
も、両者での処理の異なる部分が極わずかであり、多く
の部分の設計や構成を共通化し得る。また、メッセージ
の追い越しがないシステムを、追い越しがあるシステム
に変更することが容易である。

【０１０６】また、上述の実施例によれば、取り扱うこ
とができる状態の種類数は制限されるものではない。こ
の点から、本発明を広範囲のマルチプロセッサシステム
に適用することができる。

【０１０７】従来では、制御プロセスが全てのサブプー
ルの状態が変更されたことを検出できなかったが、この
実施例では検出することができる。そのため、制御プロ
セスが処理を適切なタイミングで行ない易くなる。

【０１０８】（５）他の実施例 状態変更中や状態変更メッセージ受信待ちを専用のテー
ブル等によって管理するようにしても良い。

【０１０９】制御プロセスが行なう状態変更メッセージ
や完了メッセージの送信を、マルチプロセッサシステム
の放送機能を利用して行なうようにしても良い。

【０１１０】本発明のプロセス状態変更方式が適用され
るマルチプロセッサシステムの用途及びプロセッサ数は
限定されるものではない。

【０１１１】

【発明の効果】以上のように、本発明によれば、状態変
更処理期間内のメッセージの授受だけで状態変更処理を
行なうようにしたので、また、到着確認メッセージの受
信数や変更済みメッセージの充分な受信を制御プロセス
が確認しながら処理を進めていくようにしたので、さら
に、状態変更中を記憶してその変更中に受信した子プロ
セスの状態をもプロセッサが変更して制御プロセスに報
告するようにしたので、状態変更処理期間以外に行なう
状態変更のための準備処理が不要な、必要なメモリ容量
が少ない、制御プロセスが状態変更の完了を検出するこ
とができる、取り扱うことができる状態数が制限されな
いプロセス状態変更方式を実現することができる。

【図面の簡単な説明】

【図１】実施例の制御プロセス及びプロセッサ（の状態
変更部）の処理フローチャートである。

【図２】プロセスプールの構成図である。

【図３】プロセスプールのマルチプロセッサシステムへ
の適用説明図である。

【図４】従来の終了検出方式であるＷＴＣ方式の説明図
である。

【図５】従来の制御プロセス用重みテーブルの構成図で
ある。

【図６】従来のサブプール用重みテーブルの構成図であ
る。

【図７】従来の送信先にサブプールが存在する場合の子
プロセスの送受信処理の説明図である。

【図８】従来の送信先にサブプールが存在しない場合の
子プロセスの送受信処理の説明図である。

【図９】従来のサブプールの終了処理の説明図である。

【図１０】従来のプロセスプールの終了検出処理の説明
図である。

【図１１】従来の通信中の子プロセスが状態変更処理に
与える影響の説明図である。

【図１２】従来、用いられていたサブプールテーブルの
構成図である。

【図１３】従来の状態変更処理の説明図（その１）であ
る。

【図１４】従来の状態変更処理の説明図（その２）であ
る。

【図１５】従来の状態変更処理の説明図（その３）であ
る。

【図１６】従来の状態変更処理の説明図（その４）であ
る。

【図１７】メッセージの追い越しがある場合の従来の状
態変更処理の説明図である。

【図１８】実施例の制御プロセス用重みテーブルの構成
図である。

【図１９】実施例のサブプール用重みテーブルの構成図
である。

【図２０】実施例の状態変更中に子プロセスを受信した
際の処理の説明図である。

【図２１】実施例の状態変更処理の説明図（その１）で
ある。

【図２２】実施例の状態変更処理の説明図（その２）で
ある。

【図２３】実施例の状態変更処理の説明図（その３）で
ある。

【図２４】実施例の状態変更処理の説明図（その４）で
ある。

【図２５】実施例の状態変更処理の説明図（その５）で
ある。

【符号の説明】

１００…状態変更メッセージの送信処理、１０１〜１０
４…状態変更の完了の検出処理、１０５…完了メッセー
ジの送信処理、１０６〜１０９…到着確認メッセージの
受信完了の検出処理、１１０…一連の処理の終了処理、
２０１…状態変更処理、２０２、２０５…状態変更中の
格納処理、２０３、２０８…変更済みメッセージの送信
処理、２０４…サブプール用重みテーブルへのサブプー
ルの登録処理、２１０…通常状態への復帰処理、２１１
…到着確認メッセージの送信処理、２１２…サブプール
用重みテーブルからのサブプールの削除処理。

Claims (2)

【特許請求の範囲】
1. 【請求項１】　　非同期メッセージ通信によってプロセ
   ッサ間処理を行なうマルチプロセッサシステムのプロセ
   ス状態変更方式であって、１個の制御プロセスと１個以
   上の子プロセスからなるプロセスプールの、各プロセッ
   サに存在するサブプールの状態を、上記制御プロセスが
   、上記各プロセッサの状態変更部を制御して変更させる
   プロセス状態変更方式において、全ての上記プロセッサ
   に状態変更メッセージを送信する上記制御プロセスが行
   なう第１の処理と、上記各プロセッサの状態変更部が状
   態変更メッセージを受信したときに行なう処理であって
   、当該プロセッサに状態変更が求められたサブプールが
   存在する場合にそのサブプールの状態を変更させて変更
   済みメッセージを上記制御プロセスに送信すると共に状
   態変更中情報を記憶し、当該プロセッサに状態変更が求
   められたサブプールが存在しない場合に状態変更中情報
   を記憶する第２の処理と、状態変更中情報を記憶してい
   る状態で、他のプロセッサから子プロセスが与えられた
   場合に受信した子プロセスの状態を変更すると共に変更
   済みメッセージを上記制御プロセスに送信する、上記各
   プロセッサの状態変更部が行なう第３の処理と、受信し
   た変更済みメッセージに基づいて上記プロセスプールの
   状態の変更の完了を監視し、完了を検出したときに、全
   ての上記プロセッサに完了メッセージを送信する、上記
   制御プロセスが行なう第４の処理と、上記各プロセッサ
   の状態変更部が、完了メッセージを受信した場合に行な
   う処理であって、上記状態変更中情報を削除すると共に
   、完了メッセージに対する到着確認メッセージを上記制
   御プロセスに送信する第５の処理と、全ての上記プロセ
   ッサから到着確認メッセージを受信することによって、
   上記プロセスプールの状態変更処理を終了させる上記制
   御プロセスが行なう第６の処理とからなることを特徴と
   するプロセス状態変更方式。
2. 【請求項２】　　完了メッセージが状態変更メッセージ
   より先に上記プロセッサに到達することが有り得る、マ
   ルチプロセッサシステムに適用される請求項１に記載の
   プロセス状態変更方式において、上記各プロセッサの状
   態変更部が完了メッセージを受信した場合に上記第５の
   処理に代えて行なう処理であって、上記状態変更中情報
   が記憶されているか否かに基づいてこの受信以前に上記
   状態変更メッセージを受信しているか否かを判別し、状
   態変更メッセージを先に受信しているときに上記第５の
   処理を実行すると共に、完了メッセージを先に受信して
   いるときに状態変更メッセージの受信待ち情報を記憶す
   る第７の処理と、上記各プロセッサの状態変更部が状態
   変更メッセージを受信したときに上記第２の処理に代え
   て行なう処理であって、状態変更メッセージの受信待ち
   情報が記憶されているか否かに基づいてこの受信以前に
   完了メッセージを受信しているか否かを判別し、状態変
   更メッセージを先に受信しているときに上記第２の処理
   を実行すると共に、完了メッセージを先に受信している
   ときに上記状態変更中情報を削除し、完了メッセージに
   対する到着確認メッセージを上記制御プロセスに送信す
   る第８の処理とを設けたことを特徴とするプロセス状態
   変更方式。