JPH0668729B2 - マルチプロセッサシステムの新規プログラムの実行を開始する方法 - Google Patents

Description

【発明の詳細な説明】 （発明の背景） ［発明の属する技術分野］ 本発明はコンピュータのオペレーティングシステムに関
し、特に、複数のプロセッサ上で同時にアクティブであ
る拡張プロセスによるマルチプロセッサシステム上のプ
ログラムの初期実行に関する。

［問題点］ 単一のコンピュータまたはプロセッサ上でのプログラム
の実行、および、その実行中におけるそれらのプログラ
ムによる入出力装置やメモリのようなシステム資源の利
用を制御するオペレーティングシステムの使用は、既知
の技術である。このようなオペレーティングシステムの
１つにＵＮＩＸ（ユニックス）オペレーティングシステ
ムがある。このオペレーティングシステムは、ケー．ト
ンプソン(K.Thompson)の論文「ＵＮＩＸの実現(UNIX Im
plementation)」Bell System Technical Journal、１９
７８年７−８月、第５７巻第６号、に記載されている。
この論文に記載されているＵＮＩＸオペレーティングシ
ステムは、単一プロセッサの資源を制御するように設計
されている。新規プログラムの実行は、この論文の第１
９３３ページに記載されており、標準のｆｏｒｋ（フォ
ーク）およびｅｘｅｃ（エクゼク）システムコールにつ
いて説明してある。その手続きでは、ｆｏｒｋシステム
コールを実行して、実行中のプロセスを子プロセスと親
プロセスへと複製する。これらのプロセスは同じプログ
ラムを共有するが、データの記憶領域は異なる。続いて
子プロセスがｅｘｅｃシステムコールを実行する。ｅｘ
ｅｃシステムコールの実行によって、新たなプログラム
が実行される。ＵＮＩＸオペレーティングシステムに関
する詳細は、エム．ジェイ．バック(M.J.Bach)著「ＵＮ
ＩＸオペレーティングシステムの設計(The Design Of T
he UNIX Operating System)」、ニュージャージー、イ
ーグルウッド クリフス、プレンティス・ホール（１９
８６年）に説明されている。他の既知のオペレーティン
グシステムにも同様のシステムコールがある。

トンプソン論文に記載されているＵＮＩＸオペレーティ
ングシステムのｅｘｅｃシステムコールは、新規プログ
ラムの実行に特に効果的な機構ではあるが、ｅｘｅｃシ
ステムコールがあるプロセッサ上で実行され、第２の不
特定のプロセッサ上で新規プログラムを起動するような
マルチプロセッサ環境では実行できない。マルチプロセ
ッサ環境で、他のプロセッサ上の特殊なプロシジャまた
はサブルーチンを実行するようなオペレーティングシス
テムは既知である。しかし、こうしたシステムでは、他
のプロセッサ上に既にそのプロシジャまたはプログラム
が存在していることが要求される。このようなシステム
の１つが、米国特許第４，５３０，０５１号（発明者：
ジェー．ダブリュ．ジョンソン(J.W.Johnson)他）に記
載されている。この特許には、あるプロセッサが、他の
プロセッサ上でプロシジャ（サブルーチン）を実行する
ことができるようなマルチプロセッサシステムが記載さ
れている。問題なのは、このプロシジャが、実行前に他
のプロセッサ上に既に存在していなければならないこと
である。同様のシステムが、ピー．ジャクソン(P.Jacks
on)）の論文「マリツプロセッサシステムの管理への道
を開くＵＮＩＸの変形(UNIX Variant Opens a Path to
Managing Multiprocessor Systems)」(Electronics、１
９８３年７月２８日)に記載されている。この論文に
は、あるプロセッサ上で実行中のプログラムが、入出力
装置（例えばディスクドライブ）を制御する他のプロセ
ッサ上でプロシジャを起動することにより、そのディス
クドライブにアクセスすることが可能となるようなシス
テムが記載されている。当該他のプロセッサは、情報を
ディスクドライブから取得すると、この情報を要求した
プロセッサに転送する。この論文では、プログラムがリ
モートシステム上に存在するように事前に指定されず
に、自動的にディスクから取得され、リモートシステム
上で実行されるような一般的な機能は記載されていな
い。

第１のプロセッサから、第２のプロセッサ内のプログラ
ムを実行するもう１つの方法が、サン・マイクロシステ
ムズ社（アメリカ合衆国、９４０４３ カリフォルニ
ア、マウンテン ヴュー、ガルシア アヴェニュー ２
２５０）の品番８００−１１７７−０１のマニュアル
「リモートプロシジャコールプロトコル仕様」に詳述さ
れている。このマニュアルは、サン・マイクロシステム
ズ社によって実施された、ＵＮＩＸオペレーティングシ
ステムへの追加であるリモートプロシジャコールについ
て詳述している。リモートプロシジャコールによって、
第１のプロセッサから第２のプロセッサ上でプロシジャ
を実行することが可能となる。

従来技術の問題点は、マルチプロセッサシステムにおい
て新規プログラムを実行するシステムコールが、マルチ
プロセッサシステム内のさまざまなプロセッサの負荷、
プログラムがメモリ内にあるかファイルシステム内にあ
るかというプログラムの物理的位置、および、プログラ
ムの実行によってシステムコールがマルチプロセッサ内
の多くのプロセッサに拡がることが要求される場合に必
要なシグナリングパスの設定、を処理することを考慮せ
ずにすむような、マリチプロセッサシステムにおいて新
規プログラムを実行する一般的方法が存在しないことで
ある。

［解決策］ 本発明は以上の問題点およびその他の問題点ならびに従
来技術の欠点を解決するものである。本発明によれば、
マルチプロセッサシステムは、新規プログラムの実行の
要求に自動的に応答して、新規プログラムの実行に必要
な資源を有する複数のプロセッサに拡がる拡張プロセス
を確立する。最初に、拡張プロセスは、新規プログラム
の実行を要求している主プロセスからなる。新規プログ
ラムのオブジェクトコードファイルへのアクセスを獲得
し、新規プログラムを実行するプロセッサを割り当て、
新規プログラムの実行に割り当てられたプロセッサを初
期化するために必要な場合、補助プロセスが、拡張プロ
セスの一部として生成される。

マルチプロセッサシステムにおいて新規プログラムの実
行を開始する方法は、新規プログラムのオブジェクトコ
ードファイルに関係するプロセッサ（ファイルプロセッ
サ）を決定するステップと、ファイルプロセッサが開始
プロセッサとは異なると決定された場合に、決定された
ファイルプロセッサ上に第１の補助プロセスを生成する
ステップと、新規プログラムのオブジェクトコードファ
イルを実行するために他のプロセッサ（実行プロセッ
サ）を割り当てるステップと、実行プロセッサが開始プ
ロセッサまたはファイルプロセッサとは異なると決定さ
れた場合に、割り当てられた実行プロセッサ上に第２の
補助プロセスを生成するステップと、開始プロセッサ上
の第１主プロセスから第２補助プロセスへプロセス情報
を転送するステップと、第２補助プロセスを主プロセス
に変換するステップと、第１補助プロセスとともにその
主プロセスによってオブジェクトコードファイルを実行
するステップとからなる。

また、割当ステップは、開始プロセッサからファイルプ
ロセッサへ、第１補助プロセスがオブジェクトコードフ
ァイルの一部を読み出すことを要求する第１のパケット
を送信するステップと、要求されたブオジェクトコード
ファイルの一部を第１補助プロセスによって読み出すス
テップと、読み出した部分を含む第２のパケットをファ
イルプロセッサから開始プロセッサへ送信するステップ
とからなる。

さらに、このシステムは、プロセス管理機能を実行する
指定されたホストプロセッサを有し、このプロセス管理
機能はプロセッサの割当を行う。割当ステップは、新規
プログラム作成に対するプロセッサ割当を要求する第３
のパケットをホストプロセスに通信するステップと、プ
ロセス管理機能を実行するホストプロセッサにより新規
プログラムを実行するために実行プロセッサを割り当て
るステップと、第４パケットによって開始プロセッサに
割当情報を通信するステップとをさらに有する。

またオブジェクトコードファイルの一部は、第１のプロ
セッサ割当パラメータのセットを含み、開始プロセッサ
は第２の補助プロセスの情報のサブセットに格納されて
いる第２のプロセッサ割当パラメータのセットを有し、
第３のパケットは第１および第２のプロセッサ割当パラ
メータのセットを含み、割当ステップは、第３のパケッ
トからこれらのプロセッサ割当パラメータのセットを読
み取るステップと、これらのプロセッサ割当パラメータ
のセットに応じてプロセッサ割当に対する実行プロセッ
サを指定するステップとをさらに有する。

さらに、第１の主プロセスに関連するプロセス情報は、
拡張プロセスの主プロセスとして第１の主プロセスが機
能することを可能にし、また転送ステップは、開始プロ
セッサによりプロセス情報を読み取るステップと、開始
プロセスによりプロセス情報から第５のパケットを形成
するステップと、開始プロセッサから実行プロセッサへ
第５のパケットを転送するステップとをさらに有する。

転送するステップは、第５のパケットからプロセス情報
を読み取るステップと、プロセス情報を第２の補助プロ
セスに格納するステップと、第２の補助プロセスを第１
の補助プロセスに変換するステップとからなる。また変
換するステップは、もとの第１の主プロセスを第３の補
助プロセスに変える。さらに、変換するステップは、第
２の補助プロセスが主プロセスになり、もとの第１の主
プロセスが第３の補助プロセスになったことを第１およ
び第３の補助プロセスにそれぞれ通知する第６および第
７のパケットをそれぞれ第１および第３の補助プロセス
に送るステップをさらに有する。

本発明の以上およびその他の利点および特徴は、図面と
あわせて以下の本発明の実施例の説明で明らかとなる。

（実施例の説明） 第１図にバス１０７により相互に連結されている複数の
コンピュータ１０１〜１０６を有するマルチプロセッサ
システムを示す。第１図に示すコンピュータのうちのい
くつかは特定の機能を有する。例えばコンピュータ１０
１はホストコンピュータと見なされ、コンピュータ１０
５〜１０６は計算サーバやファイルサーバとすることが
できる。各コンピュータはオペレーティングシステムの
カーネルによって制御されており、このオペレーティン
グシステムのカーネルは例えば、トンプソンの論文で説
明されているあるバージョンのＵＮＩＸオペレーティン
グシステムのものである。トンプソンによって説明され
ているオペレーティングシステムカーネルは単一コンピ
ュータのみに限定されるが、第１図のカーネルは複数の
コンピュータ上にプロセスを拡張することが可能であ
る。この拡張プロセスは別個のコンピュータ上で作動す
る個々の特別のプロセスの集合体である（詳細は後
述）。この特別のプロセスは、主プロセスすなわちユー
ザプロセス、および、補助プロセスすなわちスラブプロ
セスともいう。拡張プロセスに関係する各カーネルは、
その拡張プロセスがそのカーネルにより制御されている
コンピュータ上で機能することが可能であるために必要
な別個のプロセスを維持する。コンピュータはそれぞれ
対応するメモリと入出力装置を有するが、あるコンピュ
ータは、データ通信インタフェースまたは大容量記憶装
置といった特別の入出力装置に連結されうる。

第１図のシステムにおいて新規プログラムが開始される
と、そのプログラムは、余分の処理能力を有するかまた
はこのプログラムにより要求される特別の入出力資源を
有する不特定のコンピュータに自動的に割り当てられ
る。この不特定のコンピュータは、要求を実行している
のと同一のコンピュータであることもあれば、他の異な
るコンピュータであることもある。プログラムの実行
は、処理能力を有する１つのコンピュータを利用し、さ
らに必要なファイルや特殊な入出力能力を有するコンピ
ュータを使用して、いくつかのコンピュータに分散され
ることも可能である。プログラム実行が分散されると、
拡張プロセスが生成される。プログラムを複数のコンピ
ュータで実行すうことを可能にするようにプログラムの
実行を開始し、その動作をアプリケーションプログラマ
にとって分かりやすいものにすることに本発明の課題が
ある。

資源の割当および動的負荷バランスは、第１図のシステ
ムのホストコンピュータとして示されているコンピュー
タ１０１で実行されているプロセス管理（ＰＭ）機能１
０８により行われる。新規プログラムの実行の開始はｅ
ｘｅｃシステムコールにより実行される。このｅｘｅｃ
システムコールは、マルチプロセッサシステム上で動作
するように本発明によって変更されている。このｅｘｅ
ｃシステムコールの実行について説明するために、以下
の例を考察する。コンピュータ１０２上のオールドユー
ザ(olduser)プロセス１０９というプロセスは、ｅｘｅ
ｃシステムコールを実行する。最終結果は、新規プログ
ラムが、コンピュータ１０４上のニューユーザ(newuse
r)プロセス１１１というプロセスにより実行されること
である。最初に、新規プログラムを含んでいるファイル
は、コンピュータ１０３のファイルシステム内にあり、
ａ．ｏｕｔ（エーアウト）プロセス１１０というプロセ
スによりアクセスされる。また、コンピュータ１０５お
よび１０６はニューユーザプロセス１１１により利用さ
れることになる資源を有する。

前述のトンプソンの論文によれば、プロセスは、メモリ
のテキスト領域、データ領域およびｂｓｓ領域を要求
し、オペレーティングシステムにはプロセス制御ブロッ
クによって識別されるソフトウェアユニットである。ト
ンプソンにより説明されているオペレーティングシステ
ムでは、オペレーティングシステムが単一プロセッサシ
ステム上で実行されているため、プロセス制御ブロック
はメモリの１領域に含まれる。第１図に例示されている
システムでは、プロセス制御ブロックは拡張プロセスと
関連しているコンピュータ全部に分散されている。拡張
プロセスはプソセス１１２、１１０、１１１からなり、
ｅｘｅｃシステムコールが完了した後は、おそらくはコ
ンピュータ１０５および１０６内にあるプロセスも含ま
れる。拡張プロセスは、ユーザプロセスおよび複数のス
タブプロセスからなる。ユーザプロセスは、プロセス制
御ブロックのほかに、メモリのテキスト領域、データ領
域およびｂｓｓ領域を有する。スタブプロセスは、プロ
セス制御ブロックのうち、拡張プロセスに関わる特定の
コンピュータの動作に関係した、任意の時点で要求され
るオペレーティングシステム機能に関連する部分のみを
含む。

オールドユーザプロセス１０９がｅｘｅｃシステムコー
ルを実行すると、コンピュータ１０２のカーネルはコン
ピュータ１０３にパケットを転送してａ．ｏｕｔプロセ
ス１１０により、ａ．ｏｕｔファイルのヘッダ部分を取
得し、このプログラムを実行するのに要求される資源の
タイプを決定する。次に、コンピュータ１０２のカーネ
ルは、コンピュータ１０１のカーネルへ、ニューユーザ
プロセス１１１の実行に対する資源の割当を要求するパ
ケットを転送する。この要求に答えてコンピュータ１０
１のカーネルは、プロセス管理機能１０８を実行する。
本実施例では、コンピュータ１０１のカーネルは、プロ
セス管理機能１０８を実行後、コンピュータ１０４がニ
ューユーザプロセス１１１を実行するように指示するメ
ッセージを返す。プロセス管理機能１０８の動作に関す
る詳しい情報は、本願と同日に出願した特許願（２）
（特願昭６２−３２３０１３号）に添付した明細書およ
び図面に詳細に説明されている。続いてコンピュータ１
０１のカーネルは、コンピュータ１０４のカーネルが拡
張プロセスの将来の実行のためにニューユーザプロセス
１１１ならびにコンピュータ１０２、１０５、および１
０６内のスタブプロセスをセットアップすることができ
るように、プロセス管理情報をコンピュータ１０４のカ
ーネルに転送する。

この初期化が行われると、コンピュータ１０２のカーネ
ルはｅｘｅｃシステムコールの実行をコンピュータ１０
４のカーネルに渡す。コンピュータ１０４のカーネルは
コンピュータ１０３からａ．ｏｕｔファイルを得る。ま
た、コンピュータ１０４のカーネルは、初めはオールド
ユーザプロセス１０９であったユーザプロセスがコンピ
ュータ１０４に移動してニューユーザプロセス１１１に
なることを伝えるメッセージを他のコンピュータのカー
ネルに送る。ここで、オールドユーザプロセス１０９は
スタブプロセスになる。他のコンピュータのカーネル
は、オールドユーザプロセス１０９に対するシグナルを
ニューユーザプロセス１１１に転送する。さらに、コン
ピュータ１０４のカーネルは拡張プロセスがコンピュー
タ１０４に移動したことを他のコンピュータが知らされ
る前にコンピュータ１０２に到着したオールドユーザプ
ロセス１０９宛のすべてのシグナルを回復するメッセー
ジを、コンピュータ１０２のカーネルに送る。ニューユ
ーザプロセス１１１がセットアップされ実行を開始する
と、ニューユーザプロセス１１１は、必要に応じて、他
のコンピュータにおいて生成されたスタブプロセスによ
ってそのコンピュータの資源を利用できる。プログラム
の実行中、拡張プロセスの一部として最初に指定されて
いなかったコンピュータにアクセスする必要がある場
合、その時コンピュータ１０４のオペレーティングシス
テムは、プログラムの実行の継続に必要なこのコンピュ
ータ上にスタブプロセスを生成することをを要求する。

第２図は、本実施例のｅｘｅｃシステムコールの実行お
よび拡張プロセスの生成をさらに詳しく示す。オールド
ユーザプロセス１０９によるｅｘｅｃシステムコールの
実行後、判断ブロック２０２が実行される。ｅｘｅｃシ
ステムコールは、プロセッサ割当に影響するパラメータ
を指定することがある。判断ブロック２０２は、ａ．ｏ
ｕｔファイルを含むファイルがコンピュータ１０２にと
ってローカルであるか、それともリモートコンピュータ
上にあるかを決定する。本実施例では、ファイルはコン
ピュータ１０３上にあることからリモートである。本拡
張プロセスに対して、スタブプロセスがコンピュータ１
０３上にまだ存在しない場合（２０３）、コンピュータ
１０３上にスタブプロセスを生成するパケットが送られ
る。このパケットに応じて、コンピュータ１０３のカー
ネルは、ａ．ｏｕｔファイルへのアクセスを可能にする
ａ．ｏｕｔプロセス１１０を生成する。続いてａ．ｏｕ
ｔプロセス１１０は拡張プロセスの一部になる。ブロッ
ク２０６で、ａ．ｏｕｔプロセス１１０によりコンピュ
ータ１０３上にあるａ．ｏｕｔファイルにアクセスす
る。ヘッダ情報をａ．ｏｕｔファイルから読み出し、
ａ．ｏｕｔプロセス１１０のプロセス制御ブロックに格
納する。続いてコンピュータ１０３のカーネルは、ヘッ
ダのサブセットをコンピュータ１０２のカーネルに送
る。コンピュータ１０２のカーネルは、コンピュータ１
０２内のオールドユーザプロセス１０９のプロセス制御
ブロックにそのサブセットを格納する。この時点で、
ａ．ｏｕｔファイルから得られる情報はａ．ｏｕｔファ
イルのサイズを指定するものであり、また、プロセッサ
割当決定に影響するパラメータも指定しうる。ａ．ｏｕ
ｔファイルからこの情報を得た後、ブロック２０８で、
コンピュータ１０２のカーネルは、コンピュータ１０１
のカーネルがプロセス管理機能１０８を実行してニュー
ユーザプロセス１１１を割り当てるコンピュータを選択
することを要求するパケットを、コンピュータ１０１の
カーネルに送る。このパケットは、ブロック２０６で
ａ．ｏｕｔファイルから得た情報、および、ｅｘｅｃシ
ステムコールにおけるプロセッサ割当に関するパラメー
タを含む。ニューユーザプロセス１１１のプロセッサ割
当をするために、プロセス管理機能１０８は、このパケ
ットに応じて、ａ．ｏｕｔまたはｅｘｅｃシステムコー
ルの情報に明示的な割当が含まれていればその割当を検
査し、または、第１図に示したマルチプロセッサシステ
ムに対し動的負荷バランスをとる。本実施例では、ユー
ザプロセス１１１はコンピュータ１０４に割り当てられ
る。

次に、コンピュータ１０２のカーネルは、ブロック２１
０を実行する。ブロック２１０の実行によって、ｅｘｅ
ｃシステムコールの引数が読み出される。コンピュータ
１０２のカーネルは、この引数およびオールドユーザプ
ロセス１０９のアドレス空間からの環境変数に応じて、
ニューユーザプロセス１１１に対する初期スタックにこ
の情報のフォーマットを合わせて、システム作業領域に
この情報を転送する。次にブロック２１２が実行され、
オールドユーザプロセス１０９の資源をコンピュータ１
０２のオペレーティングシステムに返して解放する。特
にオールドユーザプロセス１０９のアドレス空間が解放
される。

ここまでの実行は、ｅｘｅｃシステムコールの実行前段
階を表す。ニューユーザプロセスがオールドユーザプロ
セスとは異なるコンピュータ上にある場合、ブロック２
２０〜２３８を実行後、ブロック２４０〜２５０を実行
する。本実施例では、コンピュータ１０２のカーネルは
ブロック２２０〜２２８を実行し、コンピュータ１０４
のカーネルはブロック２３０〜２３８を実行する。しか
しオールドユーザプロセスおよびニューユーザプロセス
が同一コンピュータ上にある場合は、第２図に示される
ブロック２４０〜２５０はこの時点で実行される。判断
ブロック２１４はニューユーザプロセスおよびオールド
ユーザプロセスが異なるコンピュータ上にあるかどうか
決定する。本実施例では、オールドユーザプロセス１０
９はコンピュータ１０２上にあり、ニューユーザプロセ
ス１１１はコンピュータ１０４上にある。スタブプロセ
スがコンピュータ１０４上にまだ存在していない場合、
コンピュータ１０２のカーネルはブロック２２０を実行
し、パケットがコンピュータ１０４のカーネルに転送さ
れる。このパケットは、コンピュータ１０４上でニュー
ユーザプロセス１１１になることになるスタブプロセス
を生成することを要求する。カーネルはこの要求に応じ
て、プロトタイプスタブプロセスに対してカーネルｆｏ
ｒｋ機能を実行することによりスケルトンスタブプロセ
スを生成する。第１図の各カーネルは、スタブプロセス
を生成する目的で、このプロトタイプスタブプロセスの
コピーを保有している。次に、コンピュータ１０２のカ
ーネルはブロック２２２を実行する。このブロックで、
コンピュータ１０２からコンピュータ１０４への移動パ
ケットが転送される。このパケットはニューユーザプロ
セス１１１に対する初期プロセス制御情報を含む。この
情報はブロック２１０でフォーマットされたものであ
る。移動パケットは、コンピュータ１０４上のニューユ
ーザプロセス１１１に対するスタブプロセスを、拡張プ
ロセスの実行可能なユーザプロセスに変換するために必
要な情報を含む。ここで実行可能とは、ニューユーザプ
ロセスが、必要なときに正常に終了するために必要な情
報をすべて有することを意味する。正常終了とは、拡張
プロセスを終了させることが必要な場合、拡張プロセス
のすべての部分を第１図のすべてのコンピュータから削
除することができるような終了のことである。

移動パケットに含まれる主要な情報は、スタブプロセス
の再接続データおよび拡張プロセスのオープンファイル
を定義する情報である。このデータはスタブプロセスお
よびオールドユーザプロセス１０９に結合(attach)して
いたファイルをニューユーザプロセス１１１に再結合さ
せるために使用される。この再結合は、仮想チャネルを
再配置することにより実行される（第３図に関して後
述）。プロセスグループＩＤ、親プロセスＩＤ、フラグ
ワード、ユーザＩＤ、グループＩＤ、カレントディレク
トリ、プライベートルートディレクトリ、新しい引数の
ポインタ、および種々の時計フィールドを定義するプロ
セス制御ブロックからのいくつかの重要なデータも移動
パケットにより伝達される。コンピュータ１０４のカー
ネルは、オールドユーザプロセス１０９からの移動パケ
ットに応じて、このパケットに含まれるデータをニュー
ユーザプロセス１１１の制御ブロックに設定し、他のコ
ンピュータ内のすべてのスタブプロセスに再接続メッセ
ージを出す。ブロック２３２および２３４の実行後、ニ
ューユーザプロセス１１１は実行可能と見なされる。

ブロック２３４によって他のコンピュータに送られた再
接続メッセージによって、当該他のコンピュータのカー
ネルは、拡張プロセスのプロセス制御ブロックの当該他
のコンピュータの部分を変換して、コンピュータ１０２
内のオールドユーザプロセス１０９ではなくコンンピュ
ータ１０４内のニューユーザプロセス１１１を指すよう
にする。この再接続は、他のコンピュータのスタブプロ
セスによって拡張プロセスに対し発生されるシグナルが
オールドユーザプロセス１０９ではなくニューユーザプ
ロセス１１１に送られるようにすることを意味する。

次に、コンピュータ１０２のオペレーティングシステム
はブロック２２４を実行し、コンピュータ１０４のカー
ネルにより、コンピュータ１０２のカーネルからの一連
のパケットにより、ニューユーザプロセス１１１へｅｘ
ｅｃ引数およびその他の情報を転送する。続いて、ニュ
ーユーザプロセス１１１は、コンピュータ１０４のカー
ネルによりコンピュータ１０４上のニューユーザプロセ
ス１１１アドレス空間に、これらのパケットを設定する
ことによって構築される。これは、ニューユーザプロセ
ス１１１を、拡張プロセスのさらに完全なユーザプロセ
スに変換する。

続いてコンピュータ１０４のカーネルはブロック２３６
を実行し、ブロック２２６を実行させるメッセージをコ
ンピュータ１０２へ送り、このブロック２２６によっ
て、オールドユーザプロセス１０９はスラブプロセスに
変えられる。次に、ブロック２３８で、コンピュータ１
０４のカーネルは、コンピュータ１０２内のオールドユ
ーザスタブプロセス１０９に対して格納されている可能
性のある拡張プロセスのユーザプロセス宛のすべてのシ
グナルに対する要求をコンピュータ１０２のカーネルへ
送る。コンピュータ１０２のカーネルは、このメッセー
ジに応じて、ブロック２２８を実行し、これらのシグナ
ルをブロック２３８に送る。

次に、コンピュータ１０４のカーネルは、第２図のブロ
ック２４０〜２５０を実行する。これらブロックは、オ
ールドユーザプロセスおよびニューユーザプロセスの同
一のコンピュータ上にあるかどうかに関係なく同じよう
に実行される。最初にカーネルは、ブロック２４０を実
行して、ａ．ｏｕｔプロセス１１０により、コンピュー
タ１０３上あるａ．ｏｕｔファイルにアクセスし、ａ．
ｏｕｔヘッダを取得する。このヘッダ情報を利用して、
コンピュータ１０４のカーネルは、ブロック２４２を実
行して、ａ．ｏｕｔファイルからの種々のセクションを
コンピュータ１０３からコンピュータ１０４にロードす
ることにより、テキスト、データ、およびｂｓｓの空間
を含むニューユーザプロセス１１１のアドレス空間を作
成する。

この機能の実行後、カーネルは、ブロック２４４を実行
して、オールドユーザプロセス１０９に関係づけられて
いたがニューユーザプロセス１１１に関係づけられるこ
とのないファイルをすべて閉じる。

閉じるべきファイルは、アプリケーショーンプログラマ
によって決定される。プログラマは、ｅｘｅｃシステム
コールの実行前に、ｆｃｎｔｌシステムコールを使用し
て標準的なＵＮＩＸの方法で、閉じるべきファイルをマ
ークする。この情報はオールドユーザプロセス１０９の
プロセス制御ブロックに格納され、後でニューユーザプ
ロセス１１１に転送される。マークしたファイルを全部
閉じた後、コンピュータ１０４のカーネルは、ブロック
２４６を実行して、シグナル受信後にとるべき動作を定
義するエントリを含むシグナルハンドラの配列を再初期
化する。各エントリは、デフォルト値、ノグノア値、お
よび、そのシグナルのファンクションを識別するポイン
タのうちの１つを指定できる。シグナルはブロック２２
８で、コンピュータ１０２からコンピュータ１０４へ送
られ、ブロック２３８でシグナルエントリ４２３と結合
される。ブロック２４６で、シグナル配列においてファ
ンクションを指定するすべてのエントリはデフォルト値
にセットされるが、イグノア値のエントリは変更されな
い。プロセスからシグナルを受け取ると、カーネルはそ
のプロセスのプロセス制御ブロックにアクセスして、第
４図のエントリ４２３のようなｓｉｇエントリにそのシ
グナルを格納する。シグナルがカーネルによって処理さ
れる場合、シグナル番号はシグナル配列にアクセスする
ための添字として使用される。デフォルト値がアクセス
された場合、プロセスは正常終了する。アクセスされた
エントリがイグノア値である場合、処理は行われない。
アクセスされたエントリがポインタである場合、ポイン
タにより識別される機能が実行される。アプリケーショ
ンが実行されると、配列をそのプログラムの条件に合わ
せるためにｓｉｇｎａｌシステムコールが使用される。
シグナルの処理に関するさらに詳しい情報は、バックの
前掲書に記載されている。次に、コンピュータ１０４の
カーネルはブロック２４８を実行して、ニューユーザプ
ロセス１１１の新しいアドレス空間に必要なメモリ管理
情報を再初期化し、その他のこまごました処理を完了す
る。最後に、制御がニューユーザプロセス１１１に渡さ
れ、プログラムがブロック２５０を実行できるようにな
る。

第３図は、ｅｘｅｃシステムコールを実行した結果の拡
張プロセスの一部をさらに詳細に示す。ニューユーザプ
ロセス１１１は拡張プロセスのユーザプロセスであり、
プロセス１１２および１１０は拡張プロセスのスタブプ
ロセスである。拡張プロセスのプロセスはすべて共通の
ｐｉｄ番号を共有する。仮想チャネルは、スタブプロセ
スが確立されたとき、拡張プロセスのユーザプロセスと
スタブプロセスの間に設定される。このチャネルはユー
ザプロセスとスタブプロセスの間のパケットの通信に利
用される。拡張プロセスのスタブプロセスは、直接相互
に通信はしない。さらに、第１図に示したシステム内の
他のプロセスからの通信は、すべて拡張プロセスのユー
ザプロセスへと通じている。第１図に示す各コンピュー
タは、第３図の３０１〜３０３のようなｐｒｏｃポイン
タテーブルを保有する。ｐｉｄ番号は、３０１〜３０３
のようなｐｒｏｃポインタテーブル内を指し、３０４〜
３０６のようなポインタを取得して指定されたプロセス
を見つけるために、カーネルによって利用される。例え
ば、コンピュータ１０４のｐｉｄ番号は、パス３１２を
経由してｐｒｏｃテーブル３０９に通じるｐｒｏｃポイ
ンタテーブル３０３のエントリ３０６にアクセスするた
めに使用される。同様に、ｐｉｄ番号はｐｒｏｃポイン
タテーブル３０１のエントリ３０４にアクセスするため
に利用され、ｐｒｏｃテーブル３０７に通じるパス３１
０が得られる。

仮想チャネル３１３および３１４はプロセスに直接関係
づけられる。このチャネルの識別情報は個々のプロセス
のｐｒｏｃテーブル内に設定される。拡張プロセスのユ
ーザプロセスは、スタブプロセスのそれぞれに通じる仮
想チャネルを有する。しかし、ホストプロセス１１２の
ような、拡張プロセスの各スタブプロセスは、だた１つ
の仮想チャネルを有するのみである。このチャネルは、
ニューユーザプロセス１１１のような、拡張プロセスの
ユーザプロセスに通じる。

第４図は、ホストプロセス１１２およびニューユーザプ
ロセス１１１により利用されるメモリを詳しく説明して
おり、拡張プロセスのユーザプロセスとスタブプロセス
の間の差異を示している。各スタブプロセスのそれぞれ
に対し、ｐｒｏｃテーブルおよびｕブロックの一部が示
されている。さらにポートテーブルにおよびａｃｈａｎ
リストが示されている。ポートテーブルはプロセス間に
仮想チャネルを識別するものである。ニューユーザプロ
セス１１１に対し、実行中にこのプロセスにより利用さ
れるテキスト領域、データ領域およびスタック領域は図
示していない。同様に、拡張プロセスのスタブプロセス
であるホストプロセス１１２に対し、メモリのスタック
領域は図示していない。ニューユーザプロセス１１１は
拡張プロセスのユーザプロセスである。

次に、ｐｒｏｃテーブル３０７および３０９のエントリ
を詳しく考察する。テーブル３０７および３０９に対し
て示したエントリは、これらのテーブルに存在するエン
トリの一部のみである。ｎｉｃｅエントリ４０１、４０
２はプロセスのスケジューリング優先順位を定義する。
ｎｉｃｅエントリ４０１は、すべてのスタブプロセスに
対して、システム管理者により、システム全体で固定さ
れる。ｎｉｃｅエントリ４２１はユーザプロセスに対す
るものであるため、優先度のレベルを下げることができ
るような特定のシステムコールを実行するユーザによっ
て、または、優先度のレベルを上下させることができる
システム管理者すなわちスーパーユーザによりなされる
作用によって、調節可能である。ｐｉｄのエントリ４０
２および４２２はこの２つのエントリに対して同じプロ
セス識別番号を定義する。このｐｉｄ番号は拡張プロセ
スごとに付与されるため、拡張プロセスのユーザプロセ
スおよびすべてのスタブプロセスは同じｐｉｄ番号を有
する。

ｓｉｇエントリ４０３および４２３は、ｓｔａｔｕｓエ
ントリ４０６および４２６とともに、プロセス間のシグ
ナルを処理するために使用される。さらに、ｐｒｏｃテ
ーブルのｓｔａｔｕｓワードは、従来のＵＮＩＸシステ
ムタイプの情報を含む。スタブプロセス上では、ｓｔａ
ｔｕｓワード内に含まれるシグナルフラグは、シグナル
をユーザプロセスから受け取ったかどうかを示す。この
ユーザプロセスは本実施例ではニューユーザプロセス１
１１である。ホストプロセス１１２はエントリ４０３に
格納されたシグナルの受信に応じて、現在の動作を中断
できるかどうかによって異なる動作を実行する。ニュー
ユーザプロセス１１１では、ｓｔａｔｕｓエントリ４２
６内のシグナルフラグは、シグナルがホストプロセス１
１２に転送されたかどうかを示すために使用される。さ
らに、エントリ４２６内のシグナルフラグはメッセージ
がホストプロセス１１２のようなスタブプロセスに送ら
れたかどうかを記憶している。このシグナルフラグの表
示は、後の時点での異なるタイプの動作に整理を容易に
するために使用される。受け取られるシグナルのタイプ
は、ニューユーザプロセッサ１１１によりｓｉｇエント
リ４２３に格納される。

親ｐｉｄ（ｐｐｉｄ）エントリ４０４および４２４につ
いては、これらのエントリは拡張プロセスの親プロセス
の識別情報を記憶するために使用される。これは従来の
ＵＮＩＸシステムのタイプの分野である。しかし、拡張
プロセスでは、ｐｐｉｄエントリはホストコンピュータ
１０１によって実行中の拡張プロセスのプロセス上での
み有効である。この拡張プロセスのプロセスは、本実施
例ではホストプロセス１１２である。このことにより、
拡張プロセスの種々のスタブプロセスとユーザプロセス
の間のパケット通信量が削減される。拡張プロセスのユ
ーザプロセスがホストコンピュータ上に存在していない
場合、この拡張プロセスのユーザプロセスは、有効なｐ
ｐｉｄエントリを有しない。

ｂｉｃｉｄ変数は以下のようにして、特定のプロセスが
拡張プロセスのスタブプロセスまたユーザプロセスのい
ずれであるかを決定する。第１図に示したマルチプロセ
ッサシステムの各プロセッサは、プロセッサの識別番号
をその内容とする変数ＭＹＬＯＣにプロセッサの識別番
号を格納している。プロセッサがスタブプロセスである
かユーザプロセスであるかに関係なく、ｂｉｃｉｄ変数
は常に拡張プロセスのユーザプロセスを実行しているプ
ロセッサの識別番号である。本実施例では、このプロセ
ッサはコンピュータ１０４である。エントリ４２５は、
コンピュータ１０４のカーネルにより保持されているＭ
ＹＬＯＣ変数の内容と同じである。エントリ４０５もま
たコンピュータ１０４のＭＹＬＯＣ変数の内容を有し、
そのためコンピュータ１０１のＭＹＬＯＣ変数とは一致
しない。特定のコンピュータのカーネルは、そのｂｉｃ
ｉｄ変数をＭＹＬＯＣ変数と比較することにより、ユー
ザプロセスを実行中であるか、それともスタブプロセス
を実行中であるかを決定する。比較した結果、一致して
いる場合、カーネルは拡張プロセスのユーザプロセスを
実行している。

ｕブロックページエントリ４０７および４２７は、第４
図のｕブロック４１８および４３８に図示されているよ
うなｕブロックへのアクセスを可能にするために仮想ア
ドレスを設定するためのアドレス情報を含む。これらの
ｕブロックは、ｕブロックがホストプロセス１１２のよ
うな拡張プロセスのスタブプロセスであるか、ニューユ
ーザプロセス１１１のような拡張プロセスのユーザプロ
セスであるかによって異なる情報を含む。これらのｕブ
ロックのエントリの多くは、トンプソンの前掲論文に記
載されているＵＮＩＸシステムのｕブロックのエントリ
と同様である。拡張プロセスのスタブプロセスはテキス
ト、スタック、およびデータのメモリ領域を有しないた
め、ホストプロセス１１２に対してはエントリ４０８、
４０９および４１０は０（ゼロ）である。カーネルは、
スタブプロセスに関連する機能を実行しているとき、ス
ラブプロセスのｕブロック内に、そのスタブプロセスに
固有のカーネルスタックを保有する。これは、単一プロ
セッサＵＮＩＸシステムにおいてプロセスがカーネルモ
ードで実行中に、カーネルスタックが使用される方法と
同様である。エントリ４２８、４２９および４３０は、
必要な情報を含んでいるため、拡張プロセスのユーザプ
ロセスすなわちニューユーザプロセス１１１は、前述の
ようにａ．ｏｕｔファイルから取得したプログラムの実
行に対するテキスト領域、データ領域およびスタックを
有する。

拡張プロセスのユーザプロセスでは、変数ｌｏｃｋｉｐ
（エントリ４３１）およびｅｘｅｃｉｐ（エントリ４３
２）がそれぞれ旧ａ．ｏｕｔファイルおよび新ａ．ｏｕ
ｔファイルを識別するために使用される。本実施例で
は、コンピュータ１０３は新ａ．ｏｕｔファイルを格納
し、コンピュータ１０２は旧ａ．ｏｕｔファイルを格納
している。エントリ４３１は旧ａ．ｏｕｔファイルを指
し示しており、エントリ４３２はｅｘｅｃシステムコー
ルの結果として実行される新ａ．ｏｕｔファイルを指し
示している。このファイルが両方とも拡張プロセスのユ
ーザプロセスを実行するプロセッサにとってローカルで
ある場合、これらのエントリは、ローカルファイルを識
別するために、標準的なＵＮＩＸシステムの方法でロー
カルプロセッサのカーネルにより保有されるｉノードテ
ーブルを指し示すポインタである。ａ．ｏｕｔファイル
がプロセスにより直接使用されるのではなくカーネルに
より使用されるため、システムファイルのテーブルは使
用されない。しかし、このファイルがリモートである場
合、例えば他のプロセッサに関係づけられている場合、
エントリはポートテーブル４４０のようなユーザプロセ
スポートテーブル内のエントリの識別情報を含む。次
に、例えば、ポートテーブル４４０内のこのエントリは
仮想チャネルを識別し、４１１または４１２のようなリ
モートエントリは拡張プロセスのスタブプロセスにおい
て識別される。例えばエントリ４３１がリモートファイ
ルを示している場合、このエントリは、そのリモートフ
ァイルにとってローカルであるプロセッサに関係づけら
れたスタブプロセス内の対応するエントリ４１１を指示
する。これらのエントリについてさらに詳しい事報は、
第６図に関して後述する。

概して拡張プロセスのスタブプロセスのｕブロックは、
ユーザプロセスのｕブロックに関する３つのタイプのエ
ントリを含む。第１のタイプのエントリ４０８は、スタ
ブプロセスでは使用されないが、ユーザプロセスで通常
の方法で使用される。スタブプロセスのｕブロック内の
第２のタイプのエントリは常に用いられるものであり、
このタイプのエントリの例はａｃｐｔｒエントリ４１４
であり、後述する。スタブプロセスのｕブロック内の第
３のタイプは、特定の機能を実行する要求パケットがユ
ーザプロセスからスタブプロセスへ転送されるときに、
拡張プロセスのユーザプロセスから転送されてくる必要
な情報のみが必要に応じて入るエントリである。この一
例としてｄｉｒｐエントリ４１３があり、他の例として
エントリ４１１および４１２がある。エントリ４１３は
パス名を指し示すポインタである。拡張プロセスのユー
ザプロセスでは、このエントリは常に、パス名を指定す
るユーザアドレス空間を指し示す。しかしスタブプロセ
スでは、パス名に関する情報はユーザプロセスから受け
取られ、カーネルによって適切な位置に格納される。こ
の時点でカーネルは、パス名を指し示すようにｄｉｒｐ
エントリをセットする。パス名が送られる場合の例は、
ｏｐｅｎシステムコールの最中である。ｏｐｅｎシステ
ムコールは拡張プロセスのユーザプロセスを実行するプ
ロセッサ上で実行されるため、パス名の情報はスタブプ
ロセス上で得ることは不可能である。

ａｃｐｔｒエントリ４１４および４３４はａｃｈａｎリ
スト４１９および４３９をそれぞれ指し示す。ユーザプ
ロセスのａｃｈａｎリストは、スタブプロセスへの仮想
チャネルをそれぞれ定義する多くの構造体を有しうる。
本実施例では、ニューユーザプロセス１１１のａｃｈａ
ｎリスト４３９は、拡張プロセスのスタブプロセスへの
仮想チャネルをそれぞれ定義するいくつかの構造体を有
する。各構造体は仮想チャネル用に、リンクポインタお
よびポートポインタならびにその他の情報を含む。これ
らの構造体はリンクポインタ４４２および４３５によっ
てリンクされてリンクリストをなす。このリストは最後
のリンクポインタの内容がヌル（０）となるところで終
了する。仮想チャネルはポートポインタにより識別され
る。ポートポインタ４３１および４３６はポートテーブ
ル４４０を指し示す。ニューユーザプロセス１１１は、
ａｃｈａｎリスト４３９内でニューユーザプロセス１１
１に対応するリンクリストを指し示すａｃｐｔｒエント
リ４３４を利用することによって、対応する仮想チャネ
ルを識別する。次にポートポインタを利用してポートテ
ーブル４４０にアクセスする。同様にホストプロセス１
１２は、ａｃｈａｎリスト４１９のポインタ４１５およ
び４１６を含む構造体を指し示すａｃｐｔｒエントリ４
１４を有する。拡張プロセスのスタブプロセスは複数の
仮想チャネルを有し得ないため、リンクポインタ４１５
は、ポインタ４１５の内容がヌル（０）であることによ
りリンクリストを終了させる。ポート番号４１７はニュ
ーユーザプロセス１１１への仮想チャネル３１４を定義
する。仮想チャネルに関するさらに詳しい情報は、本願
と同日に出願した特許願（３）（特願昭６２−３２３０
１４号）に添付した明細書および図面を参照されたい。

第２図のブロック２３４および２３６の観点から、仮想
チャネルを考察する。再接続情報が最初にブロック２３
４により送られると、拡張プロセスのスタブプロセス
は、第４図に図示したのと同様にして、その時点でのユ
ーザプロセスであるオールドユーザプロセス１０９との
仮想チャネルを設定する。再接続情報を受信後、受信側
の各カーネルは、ポートテーブルおよびその他のチャネ
ル情報を更新し、その結果、スタブプロセスの仮想チャ
ネルはオールドユーザプロセス１０９ではなくニューユ
ーザプロセス１１１と接続される。ブロック２３６によ
り実行される動作の一部として、ａｃｈａｎリスト４３
９およびポートを第４図に示したテーブルに変換するこ
とがある。ブロック２２６は、オールドユーザプロセス
１０９のテーブルを第４図のホストプロセス１１２に対
して示したテーブルと同様のテーブルに変える。第５図
は、拡張プロセスのファイルが拡張プロセスのユーザプ
ロセスにより識別される方法を示している。ファイル
が、コンピュータ１０４およびニューユーザプロセス１
１１のように拡張プロセスのユーザプロセスを実行中の
プロセッサにとってローカルである場合、標準的なＵＮ
ＩＸシステムのファイル制御構造体が利用される。例え
ば、ローカルファイル５０７はファィルテーブル５０１
のエントリ５０４によって識別される。このファイルテ
ーブルはニューユーザプロセス１１１のｕブロックの一
部であり、ｕ−ｏｆｉｌｅ構造体と呼ばれるものであ
る。さらに、エントリ５０４の内容はシステムファイル
テーブル５０２のエントリ５０５を識別する。システム
ファイルテーブル５０２は、ｉノードテーブル５０３お
よびエントリ５０６を指し示すために利用される。エン
トリ５０４は、通常のＵＮＩＸシステムのように、ファ
イル５０７に関係づけられたファイルデイスクリプタ番
号を使用することによりテーブル５０１内で識別され
る。続いてエントリ５０６が通常のＵＮＩＸシステムの
ようにして、ローカルファイル５０７を識別する。ファ
イルが、リモートファイル５１７のようにリモートであ
る場合、エントリ５２０は、このファイルがリモートで
あり、システムファイルテーブル５０２を指し示すので
はなくポートテーブル４４０を指し示すことを識別す
る。リモートファイル５１７はコンピュータ１０５にと
ってローカルであると仮定する。ファイル５１７に対す
るファイルディスクリプタ番号はエントリ５２０にアク
セスするために使用される。エントリ５０８は、仮想チ
ャネル５０９を識別するポートテーブル４４０のエント
リ５２０によりテーブル４４０において識別される。仮
想チャネル５０９は、前述のように、拡張プロセスのス
タブプロセスであるファイルプロセス５１０と相互接続
される。ファイル５１７に対するファイルディスクリプ
タ番号を含むパケットは、コンピュータ１０５のカーネ
ルに送られる。このカーネルは、ファイルディスクリプ
タ番号を使用して、ファイルプロセス５１０のｕブロッ
ク内にあるファイルテーブル５１１のエントリ５１４を
識別する。するとファイル制御構造体がテーブル５１２
および５１３のそれぞれのエントリ５１５および５１６
によって通常のＵＮＩＸの方法でリモートファイル５１
７を識別する。

第６図は、拡張プロセスのユーザプロセス内のｌｏｃｋ
ｉｐ変数およびｅｘｅｃｉｐ変数ならびに拡張プロセス
のスタッブプロセス内のｒｅｍｌｏｃｋｉｐ変数および
ｒｅｍｅｘｅｃｉｐ変数の利用法を詳細に示す。第６図
は、第２図のブロック２２４の実行前の、第１図に示し
たマルチプロセッサシステムの状態を示す。このとき拡
張プロセスのユーザプロセスは、コンピュータ１０２に
より実行されているオールドユーザプロセス１０９であ
る。第６図は、ｅｘｅｃシステムコールを実行するため
に使用されたもとのａ．ｏｕｔファイルが、コンピュー
タ１０２にとってローカルであると仮定している。本実
施例では、もとのａ．ｏｕｔファイルは旧ａ．ｏｕｔフ
ァイル６０７である。新しいプログラムは新ａ．ｏｕｔ
ファイルから得られるが、この新ａ．ｏｕｔファイルは
リモートファイルであり、コンピュータ１０３に関係づ
けられる。このファイルはａ．ｏｕｔファイル６１７と
図示してある。コンピュータ１０３上で実行されている
拡張プロセスのスタブプロセスは、ａ．ｏｕｔプロセス
１１０である。オールドユーザプロセス１０９に対し
て、そのｕブロック６０１およびポートテーブル６２２
を図示してある。ａ．ｏｕｔプロセス１１０に対して
は、そのｕブロック６１１を図示してある。オールドユ
ーザプロセス１０９のｕブロック６０１のエントリ６０
４は、ｉノードテーブル６０３のエントリ６０６を利用
して、標準的なＵＮＩＸシステムの方法で、旧ａ．ｏｕ
ｔファイル６０７を識別する。ｌｏｃｋｉｐ変数がロー
カルファイルを識別するため、拡張プロセスに関係する
スタブプロセスで使用される対応するｒｅｍｌｏｃｋｉ
ｐ変数はない。

しかし新ａ．ｏｕｔファイルは、コンピュータ１０２か
らリモートである。ｕブロック６０１のエントリ６２０
は、ｉノードテーブル６０３を指し示すのではなく、ポ
ートテーブル６２２内のエントリ６２１を指し示す。エ
ントリ６２１は、ａ．ｏｕｔプロセス１１０のｕブロッ
ク６１０に接続されている仮想チャネル５０９を識別す
る。ｕブロック６１０のエントリ６１４は、ｉノードテ
ーブル６１３のａ．ｏｕｔファイル６１７へのエントリ
６１６を指し示す。旧ａ．ｏｕｔファイルはコンピュー
タ１０２にとってローカルであるため、ｒｅｍｌｏｃｋ
ｉｐ変数のエントリ６２３は、ｕブロック６１１内では
使用されない。

前述の例は本発明の原理を単に示したものであり、他の
組み合わせは本発明の精神および特許請求の範囲内に含
まれる。

【図面の簡単な説明】

第１図は本発明の一実施例のマルチプロセッサシステム
のブロック図、 第２図は第１図のマルチプロセッサにより、ｅｘｅｃシ
ステムコールの実行中に動作する機能の流れ図、 第３図は第１図のプロセッサのサブセットに対する拡張
プロセスの相互接続のブロック図、 第４図は第３図のソフトウェア相互接続の詳細図、 第５図は第１図のプロセッサ上で実行中の拡張プロセス
に対するファイル制御のブロック図、 第６図は第１図のプロサッサ上で実行中の拡張プロセス
に対するａ．ｏｕｔファイルにアクセスするファイル制
御構造のブロック図である。

フロントページの続き (72)発明者 ジェイムズ ステュアート ピターソン アメリカ合衆国，60505 イリノイ，オー ロラ，ペパートゥリィ レイン 255 (72)発明者 ウォルター ユージン トゥヴェル ジュ ニア アメリカ合衆国，07060 ニュージャージ ィ，ノース プレインフィールド，ノーウ ッド アヴェニュ 196 (56)参考文献 特開 昭60−79461（ＪＰ，Ａ)

Claims (6)

【特許請求の範囲】
1. 【請求項１】複数のプロセッサを有するマルチプロセッ
   サシステムで、オブジェクトコードのファイルとして表
   現された新規プログラムの実行を開始する方法におい
   て、 開始プロセッサ（１０２）によって実行される第１の主
   プロセス（１０９）によって、前記新規プログラムのオ
   ブジェクトコードに関係するファイルプロセッサ（１０
   ３）を決定するステップと、 前記ファイルプロセッサが前記開始プロセッサとは異な
   ると決定された場合に、前記ファイルプロセッサによっ
   て第１の補助プロセス（１１０）を生成するステップ
   と、 ホストプロセッサ（１０１）とともに、前記開始プロセ
   ッサによって、前記新規プログラムのオブジェクトコー
   ドを実行する実行プロセッサ（１０４）を割り当てる割
   当ステップと、 前記実行プロセッサが前記開始プロセッサと異なると決
   定された場合に、前記実行プロセッサによって第２の補
   助プロセス（１１１）を生成するステップと、 前記開始プロセッサによって、前記第１主プロセスから
   前記第２補助プロセスへプロセス情報を転送する転送ス
   テップと、 前記実行プロセッサによって、前記第２補助プロセスを
   第２の主プロセスに変換する変換ステップと、 前記ファイルプロセッサ上の前記第１補助プロセスとと
   もに、前記実行プロセッサ上で前記第２主プロセスによ
   って前記オブジェクトコードを実行するステップとから
   なることを特徴とする、新規プログラムの実行を開始す
   る方法。
2. 【請求項２】前記割当ステップが、 前記開始プロセッサから前記ファイルプロセッサに、前
   記第１補助プロセスが前記オブジェクトコードのファイ
   ルの一部を読み込むことを要求する第１のパケットを送
   信するステップと、 前記第１補助プロセスによって前記オブジェクトコード
   のファイルの一部を読み込むステップと、 前記ファイルプロセッサから前記開始プロセッサに、読
   み込んだ部分を含む第２のパケットを送信するステップ
   とからなることを特徴とする請求項１の方法。
3. 【請求項３】前記ホストプロセッサがプロセッサ割当を
   管理する機能を実行し、前記割当ステップが、 前記新規プログラムの実行中の前記プロセッサの割当を
   要求する第３のパケットを前記ホストプロセッサに送信
   するステップと、 前記管理機能によって、前記新規プログラムを実行する
   プロセッサを割り当てるステップと、 前記ホストプロセッサから前記開始プロセッサへ、第４
   のパケットによって、前記割当を通信するステップとを
   さらに有することを特徴とする請求項２の方法。
4. 【請求項４】前記オブジェクトコードのファイルの一部
   は第１のプロセッサ割当パラメータのセットを含み、前
   記開始プロセッサは前記第１主プロセスのプロセス情報
   のサブセットに格納されている第２のプロセッサ割当パ
   ラメータのセットを有し、前記第３パケットは前記第１
   セットおよび第２セットのプロセッサ割当パラメータを
   含み、 前記割当ステップが、 前記プロセッサ割当パラメータを前記第３パケットから
   読み出すステップと、 前記ホストプロセッサによって、前記プロセッサ割当パ
   ラメータのセットに応じて、プロセッサの割当のために
   前記実行プロセッサを指定するステップとからなること
   を特徴とする請求項３の方法。
5. 【請求項５】前記プロセス情報は、主プロセスとして機
   能するように前記第１主プロセスを変換し、 前記転送ステップが、 前記開始プロセッサによって前記プロセス情報を読み出
   すステップと、 前記開始プロセッサによって前記プロセス情報から第５
   のパケットを形成するステップと、 前記開始プロセッサから前記実行プロセッサへ前記第５
   パケットを送信するステップとからなることを特徴とす
   る請求項３の方法。
6. 【請求項６】前記変換ステップが、 前記プロセス情報を前記第５パケットから読み出すステ
   ップと、 前記プロセス情報を前記第２補助プロセスに格納するス
   テップと、 前記第２補助プロセスを第２の主プロセスに変換するス
   テップとからなることを特徴とする請求項５の方法。