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

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

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

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

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

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

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

【００１０】文献Ｂ；K.Rokusawa, N.Ichiyoshi et al.
“An Efficient Termination Detection and Abortio
n Algorithm for Distributed Processing Systems”，
InProceedings of the 1988 InternationalConference
on Parallel Processing，Vol.1 ，pp.18-22，August 1
988 。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００３２】

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

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

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

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

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

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

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

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

【００４０】

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

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

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

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

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

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

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

【００４７】

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

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

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

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

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

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

【００５３】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１１１】

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

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

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

Claims (2)

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