JP4833911B2 - プロセッサユニットおよび情報処理方法 - Google Patents

Description

本発明は、複数の計算資源に処理を分散させてコンピュータプログラムを実行するための技術に関する。

コンピュータゲームやウェブ検索ソフトをはじめとするソフトウェアの高機能化は、ハードウェアに対して大きな処理負荷をかけるようになってきている。このような状況に対処するためには、演算処理自体の高速化が必要であることはもちろんであるが、複数のプロセッサによるタスク処理の効率化も同様に重要である。

複数のプロセッサにおいてタスク処理を並列に実行させるためには、複数のサブプロセッサを管理する役割を担うメインプロセッサが、アプリケーションプログラムからタスクへの分割、各サブプロセッサへのタスクの割り当て、処理の切り替え、各サブプロセッサからメインメモリや入出力装置へのアクセスの制御などを行う。このようにメインプロセッサによる一元管理の下で複数のサブプロセッサがタスク処理を行うと、例えば複数のサブプロセッサが同時にアクセス要求を発行した際などにメインプロセッサが行うべき処理が集中し、実施が滞ることによりオーバーヘッドが生じる場合がある。

本発明は、このような課題に鑑みてなされたものであり、その主たる目的は、複数のプロセッサが効率的にタスクの並列処理を行うことのできる技術を提供することにある。

本発明のある態様は情報処理システムに関する。この情報処理システムは、ネットワークを介して接続した複数のプロセッサユニットを備え、一のプロセッサユニットに含まれる第１のプロセッサが同一のプロセッサユニットに含まれる第２のプロセッサ、または他のプロセッサユニットへ処理要求を発行する情報処理システムであって、第１のプロセッサは、第２のプロセッサへの処理要求および他のプロセッサユニットへの処理要求を、メインメモリに格納するリクエスト制御部を備え、第２のプロセッサは、メインメモリに格納された第２のプロセッサへの処理要求および他のプロセッサユニットへの処理要求を検出するリクエスト受付部と、第２のプロセッサへの処理要求において指定された処理を実行するとともに、他のプロセッサユニットへの処理要求を要求先のプロセッサユニットへ転送するリクエスト処理部と、を備え、第２のプロセッサのリクエスト受付部はさらに、第２のプロセッサへの処理要求に応じてリクエスト処理部が実行した処理の結果と、他のプロセッサユニットへの処理要求に応じて要求先のプロセッサユニットが実行した処理の結果とを、メインメモリに格納し、第１のプロセッサのリクエスト制御部はさらに、メインメモリに処理の結果が格納されたことを検知し、当該処理の結果を読み出すことを特徴とする。

本発明の別の態様は情報処理方法に関する。この情報処理方法は、第１のプロセッサにおいて処理の負荷が所定のしきい値を超えたときに、内部バスで接続された第２のプロセッサまたはネットワークを介して接続した他のプロセッサユニットのいずれかを選択して処理の一部の実行を要求する処理要求をメインメモリに格納するステップと、第２のプロセッサがメインメモリから読み出した処理要求が、他のプロセッサユニットへの処理要求であった場合に、第２のプロセッサが要求先のプロセッサユニットに当該処理要求を転送するステップと、第２のプロセッサがメインメモリから読み出した処理要求が、第２のプロセッサへの処理要求であった場合に、第２のプロセッサが処理要求に対応する処理を実行するステップと、第２のプロセッサが、第２のプロセッサまたは他のプロセッサユニットが行った処理要求に対応する処理の結果をメインメモリに格納するステップと、第１のプロセッサが処理の結果をメインメモリから読み出すステップと、を含むことを特徴とする。

ここで「処理の負荷」とは、一のプロセッサが処理するタスク、プロセス、スレッドの数や、使用するリソースの量など、負荷を表す量であればそのいずれでもよい。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、複数のプロセッサによるタスクの並列処理を容易に効率化することができる。

実施の形態１
図１は、本実施の形態における情報処理装置の構成例を示している。情報処理装置１０は、マイクロプロセッサユニット（ＭＰＵ）２２、グラフィックス処理ユニット（ＧＰＵ）４０、入出力装置（Ｉ／Ｏ）４１、メインメモリ４２、補助記憶装置（ＨＤＤ）４４を備え、それぞれがメインバス３８を介して接続される。情報処理装置１０は、ＬＡＮ、インターネットなどのネットワークを介して他の情報処理装置との間でデータを送受信できる。

ＭＰＵ２２は、非対称型のマルチプロセッサユニットであり、１つの管理ユニット（ＰＵ）２４と処理ユニット（ＳＰＵ）３０ａ、３０ｂを有し、それぞれがＭＰＵ２２の内部バス３６を介して接続される。ＰＵ２４はＯＳ（Operating System）の処理を行うほか、後述するようにＳＰＵ３０ａ、３０ｂとＧＰＵ４０、Ｉ／Ｏ４１、ＨＤＤ４４、およびネットワークを介して接続した別の情報処理装置とのデータ送受信、処理要求などを仲介する。各ＳＰＵ３０ａ、３０ｂは、主にアプリケーションプログラムを実行するユニットである。

ＯＳとしての機能は主としてＰＵ２４によって実行されるが、その機能の一部は各ＳＰＵ３０ａ、３０ｂに委譲されていてもよい。たとえば、あらかじめ処理を並列に行うように記述されたスクリプトコードをＰＵ２４が解釈して複数のタスクに分解し、各ＳＰＵ３０ａ、３０ｂは、自らの空き時間においてそれらのタスクから選択したタスクを自律的に処理するようにしてもよい。この場合、本来ＰＵ２４が担うべきタスクの割り当ておよびスケジューリングといったＯＳの機能が各ＳＰＵ３０ａ、３０ｂに委譲されたことになる。そして、ＳＰＵ３０ａ、３０ｂはメインメモリ４２等から必要なプログラムをロードして処理を開始する。

図２は、ＰＵ２４、ＳＰＵ３０、およびメインメモリ４２の詳細な構成を示している。なおＳＰＵは図１に示すとおり、ＭＰＵ２２に複数備えてよいがここでは簡単のためＳＰＵ３０として１つのみ示している。またそれぞれのユニットは図２に示した機能ブロック以外の機能ブロックを備えていてよいが、ここではその図示を省略している。本実施の形態では、ＳＰＵ３０がタスクの処理中、ＰＵ２４へ依頼すべき処理が生じた場合に、ＰＵ２４に対し処理要求を発行する。ここでＰＵ２４へ依頼すべき処理とは、ＰＵ２４にのみ実行が可能な処理や、処理の効率化やスケジューリングの関係でＰＵ２４が行うことが好適な処理である。

あるいは、ＳＰＵ３０が処理するタスクの数や使用するリソースの量など、ＳＰＵ３０の処理の負荷を表す量を既知の手法でリアルタイムに検出し、当該負荷が所定のしきい値を超えたら、本来ＳＰＵ３０が行うべきであった処理の一部をＰＵ２４に依頼するようにしてもよい。従って要求する処理の内容は限定されないが、例えばＧＰＵ４０への画像処理依頼、Ｉ／Ｏ４１に対するデータの送受信、メインメモリ４２における記憶領域の確保および解放、ＨＤＤ４４に対する書き込みおよび読み出し、ネットワークを介したネットワーク通信などが挙げられる。以後、このような処理を外部依頼処理と呼ぶ。

ＳＰＵ３０が発行した処理要求はメインメモリ４２に格納され、それを検出したＰＵ２４により当該処理が実行される。処理の結果ＰＵ２４が取得したデータや返値は、メインメモリ４２に格納され、それを検出した処理要求発行元のＳＰＵ３０が当該結果を取得することにより一連の外部依頼処理が完了する。

ＰＵ２４は、依頼された処理を実際に行うリクエスト処理部２６、メインメモリ４２に格納された処理要求を検出するリクエスト受付部２７を含む。ＳＰＵ３０は、割り当てられたタスクの処理を行うタスク処理部３２、処理要求を発行したり外部依頼処理の結果を取得するリクエスト制御部３３、および処理要求の発行や結果の取得に係るプログラム、タスクの実行に必要なプログラムやデータをメインメモリ４２から読み出し保存するローカルメモリ３４を含む。

メインメモリ４２はＰＵ２４、ＳＰＵ３０がリクエスト処理部２６やタスク処理部３２において実行する各タスクを実行するためのプログラムを格納するプログラム格納領域５０、ＳＰＵ３０が発行した処理要求を格納するリクエスト格納領域５２、およびＰＵ２４が行った処理の結果を格納する結果格納領域５４を含む。プログラム格納領域５０に格納されるプログラムには、ＳＰＵ３０が処理要求の発行や結果の取得を行うために呼び出すライブラリが含まれる。ＳＰＵ３０のリクエスト制御部３３およびＰＵ２４のリクエスト受付部２７は、呼び出されたライブラリによって起動することができる。

図２において様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、アクセス制御を行うプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。例えばリクエスト処理部２６、リクエスト受付部２７、リクエスト制御部３３、タスク処理部３２はＰＵ２４、ＳＰＵ３０のそれぞれにおいて並列に処理されるスレッドであってもよい。

ＰＵ２４は、ＳＰＵ３０が実行しているタスクにおいて外部依頼処理が生じた場合に、ＳＰＵ３０からの要求に応じてそれらの処理を実施し結果を取得する。取得する結果には、ＧＰＵ４０へ画像処理依頼を行った結果生成された画像データ、ＨＤＤ４４から読み出したデータ、ネットワーク通信の結果得られたデータなどの他、メインメモリ４２におけるそれらのデータの格納アドレスや、アクセスの正常・異常終了などを示す返値などのいずれでもよい。

ＳＰＵ３０が実行するアプリケーションプログラムなどでは、メインメモリ４２のプログラム格納領域５０に格納されたライブラリのうち、上述したＰＵ２４の機能に対応するライブラリを呼び出す記述を含めておく。これによりＳＰＵ３０はＰＵ２４の機能を起動させることができる。

ＳＰＵ３０からＰＵ２４への処理要求の発行および、ＰＵ２４からＳＰＵ３０への処理の結果の送信は、メインメモリ４２を介して非同期で行う。ＳＰＵ３０は処理要求を発行した後、それ以外のタスクを継続して行う。これにより、例えば一つまたは複数のＳＰＵ３０において外部依頼処理が一時期に集中して発生しても、ＰＵ２４における受け付け待ちによってＳＰＵ３０の処理が止まってしまうことがなくなる。またＳＰＵ３０におけるスケジュール上、最も効率のよいタイミングで結果を取得することにより、ＳＰＵ３０におけるタスクのコンテキストの切り替え頻度を抑えることができ、コンテキスト切り替えに要するトータルの時間を軽減することができる。

一方、処理要求に係る割り込み信号をＳＰＵ３０から受信する場合と比較すると、ＰＵ２４はそれまで行っていたタスクを中断させたり復帰させたりする必要がなくなり、効率的に複数の処理を遂行することができる。また、ＳＰＵ３０がＰＵ２４の機能を直接指定できるライブラリをあらかじめ用意しておくことにより、本体のプログラムを簡略化できる。ＰＵ２４の機能としてＭＰＵ２２以外のデバイス、すなわちＧＰＵ４０、Ｉ／Ｏ４１、メインメモリ４２、ＨＤＤ４４などへのアクセスを同様にライブラリとして用意することによって、デバイスの構成に依存しない共通化したプログラム開発が可能となる。

次に、これまで述べた構成によって実現される動作について説明する。図３は各機能ブロックによって外部依頼処理が遂行される手順の例を示すタイムチャートである。なお同図では、各信号の送信に対して適宜発信される応答信号の図示を省略している。まずＰＵ２４のリクエスト処理部２６は、それまでの処理が完了した場合などに、次の処理要求（以後、リクエストと呼ぶ）の実行が可能であることをリクエスト受付部２７に通知することにより、リクエスト格納領域５２に新たなリクエストが格納されているか否かを確認する（Ｓ１０）。それまでにＳＰＵ３０から新たなリクエストが発行されていない場合、リクエスト処理部２６は発行を監視しながら待機状態となる。その間、ＰＵ２４では別のタスク処理が行われていてよい。

ＳＰＵ３０のリクエスト制御部３３は、タスク処理部３２において外部依頼処理が生じると、必要な処理の内容に応じてリクエストを発行し、当該リクエストはメインメモリ４２のリクエスト格納領域５２に格納される（Ｓ１２）。リクエストには要求する処理の結果を格納する結果格納領域５４へのポインタ、要求する処理の内容を表す機能のＩＤが含まれる。ＳＰＵ３０はリクエストを格納した後、別のタスク処理を行ってよい。

ＰＵ２４のリクエスト受付部２７は、当該リクエストがリクエスト格納領域５２に格納されたことを検知すると、それを読み出すなどの受け付け処理を行う（Ｓ１６）。これによりリクエスト処理部２６が要求された処理を開始する。

リクエスト処理部２６が要求された処理を完了させたときなどに、リクエスト受付部２７は生成されたデータや返値などの結果を、メインメモリ４２の結果格納領域５４のうち、リクエストに含まれるポインタの示す領域に格納する(Ｓ１８)。そしてリクエスト受付部２７はリクエスト処理部２６に当該リクエストの処理完了を通知する（Ｓ２０）。ＳＰＵ３０のリクエスト制御部３３は、要求した処理の結果が結果格納領域５４に格納されているか否かを確認し（Ｓ２２）、格納されていればそれをローカルメモリ３４に読み出すなどして取得する（Ｓ２４）。結果が格納されているか否かは、Ｓ２２に代わりリクエスト受付部２７に対し確認を行ってもよい。ＰＵ２４のリクエスト処理部２６は、Ｓ２０の処理完了の通知を受信したら、他のタスク処理のスケジュールなどに基づく所望のタイミングで、別のリクエストについてＳ１０のリクエストの確認を適宜行い、以後の処理が繰り返される。

以上の手順によりＳＰＵ３０は、各自のタスク処理において発生した外部依頼処理をＰＵ２４に行わせその結果を取得することができる。

なおＳ１０のリクエストの確認処理より前にリクエスト格納領域５２にリクエストが格納されていれば、ＰＵ２４は待機状態とならずに当該リクエストを受け付けてよい。また、Ｓ２２の結果の確認処理において、結果格納領域５４に結果が格納されていなければ、ＳＰＵ３０は結果が格納されるまで待機状態となっていてよい。その間、ＳＰＵ３０のタスク処理部３２は、その他のタスク処理を行うことができる。

上述したのは、１つのＳＰＵ３０が１つのリクエストを発行した際のＳＰＵ３０およびＰＵ２４の処理手順であったが、複数のＳＰＵ３０がリクエストを発行しても同様の処理が行われる。すなわちあるＳＰＵ３０ａがリクエストを発行しそれに応じた処理がＰＵ２４において行われている間、別のＳＰＵ３０ｂがすぐに別のリクエストを発行した場合、後続のリクエストはリクエスト格納領域５２に格納される（Ｓ３０）。そして、ＰＵ２４で当該リクエストに応じた処理が開始されその結果がリクエスト格納領域５２に格納されるまでは、リクエスト発行元のＳＰＵ３０ｂのリクエスト制御部３３は結果を監視しながら待機する。その間、ＳＰＵ３０ｂでは他のタスク処理が行われていてよい。

さらに別のＳＰＵ３０がリクエストを発行した場合も、リクエスト格納領域５２にリクエストが複数保存され、それぞれの発行元のＳＰＵ３０のリクエスト制御部３３は、結果格納領域５４内の個別の領域に結果が格納されるまで待機する。その間、それぞれのＳＰＵ３０内では別のタスク処理が行われてよい。

このような状況においてメインメモリ４２を効率よく使用するためには、結果格納領域５４内のある領域に格納された結果がリクエスト発行元のＳＰＵ３０によって読み出された後、当該格納領域に別のリクエストの結果が格納できるようにすることが望ましい。このためメインメモリ４２にはさらにフラグ格納領域を設けてもよい。図４はメインメモリ４２にフラグ格納領域を設けた場合の態様例を模式的に示している。なお同図ではプログラム格納領域５０、リクエスト格納領域５２の図示を省略している。

同図に示すようにメインメモリ４２には、結果格納領域５４に加えてフラグ格納領域５６が含まれる。フラグ格納領域５６は、発行されたリクエストのそれぞれに対応したフラグを表すビット列を格納する領域である。従ってフラグ格納領域５６の総ビット数は同時に発行することのできるリクエストの数となる。あるいはリクエストの数に応じてビット数をリアルタイムに増減させてもよい。そして結果格納領域５４はフラグ格納領域５６の各ビットに対応した個別の領域を有し、それぞれの領域に一のリクエストに対する結果が格納される。図４では、結果格納領域５４の個別の領域を矩形で表し、フラグ格納領域５６の各ビットとの対応を破線の矢印で示している。

この場合、ＳＰＵ３０が発行するリクエストにはフラグ格納領域５６のアドレスと、その中のビット位置が含まれる。例としてフラグが「０」のときは新たなリクエストの結果を格納することができ、フラグが「１」のときは読み出し前の結果が格納されている、とする。このような場合、発行するリクエストには、フラグが「０」のビットのうちいずれかのビット位置を指定する。そしてＳＰＵ３０のリクエスト制御部３３が、結果が格納されているかどうかを確認する際は、リクエストにおいて指定したビット位置のフラグが「１」になるのを確認する。

ＰＵ２４のリクエスト受付部２７は、リクエスト処理部２６が処理した結果を、指定されたビット位置に対応した結果格納領域５４内の領域に格納するとともに、当該ビット位置のフラグを「１」とする。ＳＰＵ３０のリクエスト制御部３３は、フラグが「１」になったのを確認して、対応する結果格納領域５４内の領域から結果を取得し、フラグを「０」に戻す。このようにすることで、別のリクエストの発行に際して、以前使用されていた結果格納領域５４内の領域をすぐに再利用することができ、メインメモリ４２内の領域を節約することができる。

図５は以上述べた情報処理装置１０における動作の具体例を示すタイムチャートである。ここではＳＰＵ３０からのリクエストに応じＰＵ２４が「ＨＴＴＰ ＧＥＴ」のメソッドを発行し、ネットワークを介してウェブページのデータを取得する場合について示している。このときリクエスト処理部２６では、リクエスト処理の終了とリクエストの有無とを管理するリクエスト管理スレッド、ＨＴＴＰに係る処理を制御するＨＴＴＰモジュール、個々のコールバック処理を実施するコールバックスレッドが遂行される。また結果格納領域５４には、メソッドの呼び出し結果を格納するメソッド読み出し用の領域とコールバックにより取得したデータを格納するコールバック用の領域とが用意される。

まずＳＰＵ３０のリクエスト制御部３３は、「ＨＴＴＰ ＧＥＴ」のメソッドにあらかじめ割り振られたＩＤ、ＵＲＩなど必要な情報を含めてリクエストを発行する（Ｓ５０）。当該リクエストはメインメモリ４２のリクエスト格納領域５２に格納される。ＰＵ２４のリクエスト処理部２６のリクエスト管理スレッドは、それまでのリクエストが完了した場合などに、リクエスト受付部２７に対しリクエストの有無を確認する（Ｓ５２）。リクエスト受付部２７はリクエスト格納領域５２に格納されたリクエストを検知し、リクエスト処理部２６のＨＴＴＰモジュールにリクエストの情報を渡すことにより「ＨＴＴＰ ＧＥＴ」のメソッドを起動させる（Ｓ５４）。

ＨＴＴＰモジュールはリクエストの情報に基づきコールバックスレッドを生成する（Ｓ５６）。正常にスレッドが生成されたら、ＨＴＴＰモジュールはその旨をリクエスト受付部２７に通知する（Ｓ５８）。なおスレッドが正常に生成されなければエラーを示す返値が返されるが、その後のエラー処理については説明を省略する。リクエスト受付部２７は通知された結果をメモリ４２の結果格納領域５４に用意されたメソッド読出し用の領域に格納し（Ｓ６０）、リクエスト処理部２６のリクエスト管理スレッドに当該リクエストに対する処理の起動が完了した旨を通知する（Ｓ６２）。その間にリクエスト処理部２６のコールバックスレッドは「ＨＴＴＰ ＧＥＴ」をリクエストに指定されたＵＲＩに基づき実行している（Ｓ６４）。

ＳＰＵ３０のリクエスト制御部３３は、結果格納領域５４のメソッド読出し用の領域に、「ＨＴＴＰ ＧＥＴ」を起動した結果が格納されているか否かを確認し（Ｓ６６）、格納されていればそれを取得する（Ｓ６８）。一方、リクエスト処理部２６のコールバックスレッドは、Ｓ６４において実行していた「ＨＴＴＰ ＧＥＴ」のメソッドによって所望のデータを取得できたら、それを結果格納領域５４のコールバック用の領域に格納し（Ｓ７０）、メソッドから抜ける（Ｓ７２）。

ＳＰＵ３０のリクエスト制御部３３は、結果格納領域５４のコールバック用の領域に、「ＨＴＴＰ ＧＥＴ」の結果であるデータが格納されているか否かを確認し（Ｓ７４）、格納されていればそれを取得する（Ｓ７６）。以上の手順により、ＳＰＵ３０は所望のウェブページのデータを取得することができ、これに基づき処理依頼元であるタスクの処理を続行することができる。

以上述べた本実施の形態によれば、タスク処理の実行主体であるＳＰＵにおいて外部依頼処理の必要が生じた場合、そのアクセス要求を一旦メインメモリに保存する。外部依頼処理の実行主体であるＰＵは、新たな依頼処理が可能となったときにメインメモリから処理要求を読み出し実行する。これにより、要求が集中してもＰＵにおける処理の負荷は分散され、ＳＰＵから要求される処理以外のタスク、すなわちＯＳの実行などが滞ることが少なくなる。同様に、外部依頼処理の結果も一旦メインメモリに保存するため、ＳＰＵは処理要求を発行してからその処理の結果を取得するまで、当該結果を必要とするタスクを待機状態として別のタスクを進めることができる。結果としてＰＵ、ＳＰＵの双方でオーバーヘッドの発生を抑制することができる。

また、あらかじめＰＵが実施可能な処理の内容を識別する情報を設定しておくことにより、アクセス要求時にはその識別情報を指定するのみでＰＵ側での処理が実施される。これにより、ＳＰＵで実行されるプログラムを簡略化することができる。さらに当該識別情報を解釈するプログラムを、処理の種類によらず同等にライブラリとして用意しておくことにより、処理要求に係る処理が抽象化されるため、デバイスの構成など環境に応じたライブラリの設定を行うことにより、アプリケーションプログラムを汎用化させることができる。

またフラグを利用して処理の結果を格納する領域からデータが読み出されたか否かを判断し、読み出された領域に次の処理要求の結果を格納する。これによりメインメモリに多大な領域を確保しなくても本実施の形態を実現することができる。

実施の形態２
実施の形態１は、管理ユニットと処理ユニットとを含む単一のマイクロプロセッサユニットを備えた情報処理装置において、処理ユニットが管理ユニットに処理要求を行う態様であった。処理要求時には、ライブラリを呼び出して機能を指定することにより、要求先での処理を起動させることができ、また、処理要求の発行や処理結果の転送が要求元と要求先とで非同期に行われた。本実施の形態では、複数のマイクロプロセッサユニットがネットワークによって接続されている状態においても同様に、ネットワークを介した処理要求を、ライブラリを呼び出すことにより実現する。この場合の処理要求の発行や処理結果の転送も非同期で行うことにより、各マイクロプロセッサユニットにおけるタスク処理を効率化し、並列性を高める。

図６は本実施の形態における情報処理システムの構成を示している。情報処理システム１００は複数のプロセッサ要素（ＰＥ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄを含む。ここでＰＥの数は４つとしているが、情報処理システム１００の用途や規模によって増減させてよい。複数のＰＥ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄはそれぞれ、実施の形態１の図１で示したＭＰＵ２２、メインメモリ４２を含む。ＰＥ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄはさらに、ＧＰＵ、Ｉ／Ｏ、ＨＤＤなどの処理ユニットと、それらを接続する内部バスまたはメインバスを含んでよいが、ここでは図示を省略する。図１で示したように、ＭＰＵ２２は、ＰＵ２４とＳＰＵ３０ａ、３０ｂを含むが、ＳＰＵ３０ａ、３０ｂの数はＰＥ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄで異なっていてよい。

図６に示す情報処理システム１００は一例として、複数のＰＥ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうち、２つのＰＥ、すなわちＰＥ１０２ａおよび１０２ｂが第１ネットワーク８２、第２ネットワーク８４、および第３ネットワーク８６に、別のＰＥ１０２ｃが第２ネットワーク８４と第３ネットワーク８６に、さらに別のＰＥ１０２ｄが第３ネットワーク８６のみに接続するネットワーク構成を有する。ＰＥ相互の通信は接続したネットワークのいずれかを介して行われる。同図においてネットワークは第１、第２、および第３の３つが示されているが、その数を限定するものではない。第１ネットワーク８２、第２ネットワーク８４、および第３ネットワーク８６は、この順で通信速度が速い一方、接続性が低い。例えば、第１ネットワーク８２をＰＣＩ（Peripheral Component Interconnect）、ＩｎｆｉｎｉＢａｎｄ、ＧｂＥ（Gigabit Ethernet （Ethernetは登録商標））によるネットワークとし、第２ネットワーク８４はＩＰ（Internet Protocol）による直接通信を行うネットワーク、第３ネットワーク８６をＮＡＴ（Network Address Translation）を用いたネットワークなどとすることができる。

本実施の形態では、あるＰＥ１０２ａ内のＳＰＵ３０などが他のＰＥ１０２ｂ、１０２ｃ、１０２ｄに対し処理要求を行う。情報処理システム１００のようなマルチコア環境においては通常、それぞれ独立したＯＳによってタスク処理のスケジュールなどが管理される。このような状況下では、実施の形態１で示した単一のＭＰＵ２２を備えた情報処理装置１０と比較して、処理要求を発行してからその結果が戻るまでの時間を見積もるのが格段に困難となる。

また、ＰＥ１０２ａとＰＥ１０２ｂ、１０２ｃ、１０２ｄとはネットワークを介して処理要求や結果の転送を行うため、処理要求が完了するまでに伝送時間が余計にかかる。さらに、複数のＰＥ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄが共通のネットワークを利用するため、伝送するデータ量に依存してデータの伝送に要する時間も増加し易い。この場合、処理要求や結果の転送を要求元、要求先で同期させると、実施の形態１の場合と比較してさらに待機時間がかかることになる。また通信経路が長いため障害が発生する可能性が高くなる。障害が発生すると、処理要求元、処理要求先の双方で処理されている他のタスクがそのエラー処理によって滞る場合もある。このように、図６に示すようなマルチコア環境においてはさらに、システム全体でオーバーヘッドが発生しやすい。

そこで実施の形態１で示したような非同期の処理要求発行および結果の転送を情報処理システム１００に適用することにより、実施の形態１と比べ、さらに顕著な効果を得ることができる。要求する処理は、実施の形態１と同様、要求先のＰＥ１０２ｂ、１０２ｃ、１０２ｄのいずれかのＰＵ２４やＳＰＵ３０のみが実行可能な処理でもよいし、本来依頼元のＳＰＵ３０が実行すべき処理であるが、当該ＳＰＵ３０の処理の負荷が所定のしきい値を超えたために他のＰＥ１０２ｂ、１０２ｃ、１０２ｄのいずれかに要求する処理でもよい。後者の場合、処理要求先のＰＥ１０２ｂ、１０２ｃ、１０２ｄのいずれかにおけるＳＰＵ３０などにおいても処理の負荷がしきい値を超えたら、当該ＰＥ１０２ｂ、１０２ｃ、１０２ｄに含まれるＰＵ２４がまた別のＰＥに処理要求を発行することにより、情報処理システムに含まれるプロセッサユニット全体に渡る分散処理が自律的に達成されることになる。

上記のようなネットワーク構成を有する情報処理システム１００において、あるＰＥ１０２ａから別のＰＥ１０２ｂ、１０２ｃ、１０２ｄのいずれかに処理要求を行う場合、実施の形態１において行われた処理に加え、処理要求先のＰＥ１０２ｂ、１０２ｃ、１０２ｄが接続しているネットワークの種類を取得し、依頼する処理の内容などに応じて適切なネットワークを選択する必要がある。

例えば、図６に示すＰＥ１０２ａからＰＥ１０２ｃやＰＥ１０２ｄへ処理要求を行う際は、第１ネットワーク８２を介すことはできないため、通信可能なネットワークを判別する必要がある。また、ＰＥ１０２ａからＰＥ１０２ｂへ処理要求を行う際、両者は同じ３種類のネットワークに接続しているが、高速性が要求される処理は第１ネットワーク８２を選択し、それほど高速性を要求されない処理は第３ネットワーク８６を選択して通信を行うことにより、全体的な処理効率を向上させることができる。

ところが従来の一般的な構成において、あるＰＥ１０２ａのＳＰＵ３０に他のＰＥ１０２ｂなどへ通信を行う必要が生じた場合、所属するＰＥ１０２ａ内のＰＵ２４が当該通信要求を一旦受け付け、上記のようなネットワークに係る問題を解決して選択したネットワークを介して通信先と通信を確立するなどの処理を行っていた。このような構成に実施の形態１で述べたような非同期の処理要求を適用しても、ネットワークを解決する処理がＰＵ２４に集中し、結果的にＰＵ２４に負荷がかかり十分な効果が得られない場合がある。本実施の形態では、ネットワークの選択および転送に係る処理をＰＵ２４以外に分散させることによりＰＵ２４の負荷を軽減し、非同期の処理要求との相乗効果でシステム全体としての処理効率を向上させる。

図７は本実施の形態のＰＥ１０２ａにおけるＭＰＵ２２の構成を詳細に示している。なお図７、図８において実施の形態１と同様の構成には同じ符号を付し、説明は適宜省略する。本実施の形態では、ＭＰＵ２２にＰＵ２４の他、２種類のＳＰＵ、すなわちアプリケーションＳＰＵ２３０ａ、２３０ｂおよびシステムＳＰＵ２３１を設ける。アプリケーションＳＰＵ２３０ａ、２３０ｂは実施の形態１におけるＳＰＵ３０に相当し、主にアプリケーションプログラムを実行する。

アプリケーションＳＰＵ２３０ａはタスク処理部３２、リクエスト制御部３３の他、ネットワークを介して処理要求を発行する際、ネットワークの選択に係る処理を実行するインターフェース選択部１０１が含まれる。さらにアプリケーションＳＰＵ２３０ａのローカルメモリ３４には、実施の形態１と同様、プログラムをロードしたり処理に必要なデータを格納する領域（不図示）の他、以前に選択されたネットワークインターフェースを要求する処理の対象ごとに保持するオブジェクトＩＤルックアサイドバッファ（以後、単にルックアサイドバッファと呼ぶ）１０４を含む。インターフェース選択部１０１およびルックアサイドバッファ１０４の機能については後に詳述する。

アプリケーションＳＰＵ２３０ｂもアプリケーションＳＰＵ２３０ａと同様の構成を有してよいが、本図ではその図示を省略している。また以後の説明ではアプリケーションＳＰＵ２３０ａに代表させてその動作を説明する。

本実施の形態で新たに設けられたシステムＳＰＵ２３１は、アプリケーションＳＰＵ２３０ａと同様にタスク処理部３２を含み、さらに当該タスク処理部３２は図示するように第１ネットワーク通信部１１２を含む。システムＳＰＵ２３１は自らが行うタスク処理として、アプリケーションＳＰＵ２３０ａが外部のＰＥに行う処理要求を、第１ネットワーク通信部１１２によって転送する。このとき第１ネットワーク通信部１１２が転送する処理要求は、第１ネットワーク８２を介するものに限られる。図６の例では、ＰＥ１０２ａからＰＥ１０２ｂへの処理要求のうち、高速通信を行なう必要のある処理がこれに相当する。すなわち第１ネットワーク通信部１１２は第１ネットワーク８２へのネットワークインターフェースとして機能する。

なおアプリケーションＳＰＵ２３０ａ、２３０ｂおよびシステムＳＰＵ２３１は同図で示す数に限らない。例えば第１ネットワーク８２、第２ネットワーク８４、第３ネットワーク８６を介した転送をそれぞれ実行する個別のシステムＳＰＵを３つ設けてもよい。また１つのシステムＳＰＵ２３１で２つ以上のネットワークへ転送できるようにしてもよい。さらにシステムＳＰＵ２３１は、タスク処理部３２の一タスクとしてネットワークインターフェースの機能を発揮するため、実際にはアプリケーションＳＰＵ２３０ａと同一の構成を有していてもよい。すなわち複数のアプリケーションＳＰＵ２３０ａ、２３０ｂなどのうち、一のアプリケーションＳＰＵをシステムＳＰＵ２３１として機能させてもよい。

さらに本実施の形態のＰＵ２４は実施の形態１と同様にリクエスト受付部２７およびリクエスト処理部２６を含むが、リクエスト処理部２６は図示するように、通信制御部１１６、第１ネットワーク通信部１１８、第２ネットワーク通信部１２０、および第３ネットワーク通信部１２２を含む。第１ネットワーク通信部１１８、第２ネットワーク通信部１２０、および第３ネットワーク通信部１２２はいずれも、アプリケーションＳＰＵ２３０ａが外部のＰＥに処理要求を行う際のネットワークインターフェースとして機能する。ここで第１ネットワーク通信部１１８は第１ネットワーク８２を介する転送、第２ネットワーク通信部１２０は第２ネットワーク８４を介する転送、第３ネットワーク通信部１２２は第３ネットワーク８６を介する転送をそれぞれ行う。

通信制御部１１６は各処理要求の要求先のＰＥのノードの特定や要求先に接続したネットワークの特定などを行い、処理要求を第１ネットワーク通信部１１８、第２ネットワーク通信部１２０、第３ネットワーク通信部１２２へ振り分けることにより転送処理を制御する。ただし本実施の形態ではＰＵ２４におけるネットワークに係る処理を可能な限り省略できるようにすることでＰＵ２４の処理の負荷を軽減する。ＰＵ２４のリクエスト処理部２６は、その他、実施の形態１で述べたのと同様に、アプリケーションＳＰＵ２３０ａが当該ＰＵ２４に対して要求した外部依頼処理を実行するタスク処理部１１４も含む。

本実施の形態におけるシステムＳＰＵ２３１は、ＰＵ２４が行う上記のネットワークに係る処理より簡易な処理を行う。すなわち、あらかじめ処理要求先のノードの特定がなされ、さらに特定のネットワーク、図７の例では第１ネットワーク８２を介して転送するのが適切であることが判明した処理要求のみがシステムＳＰＵ２３１へ送られ、転送される。これにより、システムＳＰＵ２３１は高速かつ転送時間が見積もり可能なリアルタイム通信を実現することが可能となる。一方、ＰＵ２４はネットワークの特定などを含むネットワークに係る全ての処理を行えるほか、ネットワークに係る処理以外の処理も行う汎用プロセッサとしての機能を有する。

アプリケーションＳＰＵ２３０ａのインターフェース選択部１０１は、ＰＵ２４の通信制御部１１６が特定した、処理要求先のＰＥに接続したネットワークのうち、要求する通信速度に従いネットワークを選択する。さらに、当該ネットワークに対し通信を行えるネットワークインターフェースが複数存在する場合は、リアルタイム通信が必要か否かによってネットワークインターフェースを選択する。

例えば図６において、要求先がＰＥ１０２ｃであった場合は、第２ネットワーク８４または第３ネットワーク８６から一のネットワークが選択されるが、当該ネットワークへ通信を行えるインターフェースは図７においてＰＵ２４に含まれるものに限られるため、自ずとＰＵ２４内の第２ネットワーク通信部１２０または第３ネットワーク通信部１２２がネットワークインターフェースとなる。一方、要求先がＰＥ１０２ｂであった場合で第１ネットワーク８２を選択した場合は、当該ネットワークへ通信を行えるインターフェースがＰＵ２４の第１ネットワーク通信部１１８とシステムＳＰＵ２３１の第１ネットワーク通信部１１２との２つ存在するため、そのいずれかを選択する。

選択したネットワークインターフェースは、ローカルメモリ３４のルックアサイドバッファ１０４に格納しておく。これにより、次回に同一の処理対象の処理要求を行う際は、ＰＵ２４による要求先のＰＥのノードの特定や要求先に接続したネットワークの特定、およびインターフェース選択部１０１によるネットワークおよびネットワークインターフェースの選択といった処理を省略することができる。さらにネットワークインターフェースとしてシステムＳＰＵ２３１の第１ネットワーク通信部１１２を選択する場合は、ＰＵ２４は転送処理自体をも行わずに済む。これによりＰＵ２４の処理の負荷が軽減されるうえ、処理要求の内容に応じてリアルタイム通信、非リアルタイム通信を選択することができる。

図８は本実施の形態のＰＥ１０２ａにおけるメインメモリ４２の構成を詳細に示している。メインメモリ４２には、実施の形態１で示したプログラム格納領域５０、リクエスト格納領域５２、結果格納領域５４、フラグ格納領域５６の他、オブジェクトＩＤキャッシュを格納するオブジェクトＩＤキャッシュ格納領域１０６と、ルーティングテーブルを格納するルーティングテーブル格納領域１０８とを含む。

アプリケーションＳＰＵ２３０ａが外部のＰＥに対し処理要求を発行する際は、要求する処理対象をソフトウェア上で識別する情報を指定してライブラリを呼び出す。ここで「処理対象」とは、処理の対象をソフトウェア上で何らかの規則により区分けした単位であればよく、いわゆる「オブジェクト」でもよい。「処理対象」は例えばその処理を実現するプログラムコードを記憶したメモリや処理対象のデバイスなど、何らかのハードウェアの単位と対応する。そしてＳＰＵ２３０ａは、当該ハードウェアを含むＰＥに対し処理要求を行うことにより「処理対象」に対する処理を実現させる。以後、処理対象を識別する情報を「オブジェクトＩＤ」と呼ぶ。

同ライブラリによって当該処理要求の転送を受け付けたＰＵ２４は、ルーティングテーブル格納領域１０８に格納されたルーティングテーブルを参照して、オブジェクトＩＤに対応する要求先のＰＥのノード番号や接続したネットワークの特定を行う。またＰＵ２４は、特定した要求先のノード番号をオブジェクトＩＤと対応づけてオブジェクトＩＤキャッシュ格納領域１０６にオブジェクトＩＤキャッシュとして格納しておく。オブジェクトＩＤキャッシュにエントリされているオブジェクトＩＤについては、ノード番号および接続したネットワークが特定済みであるため、以後、それらの情報の特定処理を省略できる。

図９はメインメモリ４２のルーティングテーブル格納領域１０８に格納されるルーティングテーブルのデータ構造の例を示している。ルーティングテーブル１３０は、ノード番号欄１３２、ネットワーク欄１３４、およびローカルノードＩＤ欄１３６を含む。ノード番号欄１３２には、ＰＥ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれに一意に与えられ、かつ位置を表すノード番号が記録される。ネットワーク欄１３４にはＰＥ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄが接続するネットワークの種類が記録される。複数のネットワークに接続している場合はそれらの全てが記録される。ローカルノードＩＤ欄１３６には、ネットワーク欄１３４に記録されたネットワークごとに、当該ネットワーク内で各ノードを識別するためのローカルノードＩＤが記録される。

ルーティングテーブル１３０は外部記憶装置などにあらかじめ記憶されていたものをメインメモリ４２に読み出してもよいし、情報処理システム１００の起動時などにそれぞれのＰＥ１０２ｂ、１０２ｃ、１０２ｄの内部設定を読み出し、構成しなおすようにしてもよい。

上述のとおりＰＵ２４の通信制御部１１６はアプリケーションＳＰＵ２３０ａからの処理要求を転送する際、ルーティングテーブル１３０を参照し、要求先ＰＥへ接続したネットワークを取得する。このとき必要となる要求先ＰＥのノード番号は、要求元のアプリケーションＳＰＵ２３０ａが指定したオブジェクトＩＤに基づき既存の技術で取得する。例えばオブジェクトＩＤとノード番号との対応を管理している別のＰＥに問合せを行ったり、その対応をリスト化しておき検索を行ったり、実際に別のＰＥへ転送し、そこからの転送を経て目的のオブジェクトＩＤに対応するＰＥに到達したら当該ＰＥからノードの情報を受け取るようにしたりする。あるいは要求先までの距離などに応じてそれらを組み合わせてもよい。

図１０はメインメモリ４２のオブジェクトＩＤキャッシュ格納領域１０６に格納されるオブジェクトＩＤキャッシュのデータ構造の例を示している。オブジェクトＩＤキャッシュ１４０は、オブジェクトＩＤ欄１４２とノード番号欄１４４とを含む。オブジェクトＩＤ欄１４２には、過去に発行された処理要求のオブジェクトＩＤが記録される。ノード番号欄１４４には、各オブジェクトＩＤに対応する要求先ＰＥのノード番号が記録される。オブジェクトＩＤキャッシュ１４０は、ＰＵ２４の通信制御部１１６が上述のように新たなオブジェクトＩＤに対応する要求先のノード番号を取得するたびに追加される。一定期間、同じオブジェクトＩＤの処理要求が発生しない場合は上書きされるようにしてもよい。

図１１はアプリケーションＳＰＵ２３０ａのローカルメモリ３４に格納されるルックアサイドバッファ１０４のデータ構造の例を示している。ルックアサイドバッファ１０４は、オブジェクトＩＤ欄１５２およびネットワークインターフェース欄１５４を含む。オブジェクトＩＤ欄１５２には、過去に発行した処理要求のオブジェクトＩＤが記録される。ネットワークインターフェース欄１５４には、それぞれの処理要求に対してインターフェース選択部１０１が選択したネットワークインターフェースを識別する情報が記録される。ルックアサイドバッファ１０４においても、長期間参照されなかったオブジェクトＩＤについてはそのエントリを上書きするようにしてもよい。

上述した、オブジェクトＩＤからの要求先のノードの特定、要求先が接続するネットワークの特定、ネットワークおよびネットワークインターフェースの選択、および処理要求の転送、といった多段階のネットワークに係る処理を同一のライブラリとして提供することにより、アプリケーションＳＰＵ２３０ａで処理されるアプリケーションプログラム側では個々のネットワークを抽象化することができ、ライブラリによって自動的に適切なルーティングが行われることになる。アプリケーションＳＰＵ２３０ａはアプリケーションのタスク処理において、要求先のＰＥがネットワーク上のどの位置に存在しているかを考慮することなく、オブジェクトＩＤを設定してライブラリを呼び出すのみで処理要求を行うことができる。

図１２はＰＥ１０２ａ内のアプリケーションＳＰＵ２３０ａにＰＥ１０２ｂへの外部依頼処理が発生した際の、処理要求の転送に係る処理手順を示している。まず外部依頼処理が発生すると（Ｓ１１０）、アプリケーションＳＰＵ２３０ａのリクエスト制御部３３は、ローカルメモリ３４のルックアサイドバッファ１０４を参照し、要求する処理のオブジェクトＩＤがエントリされているか否かを確認する（Ｓ１１２）。ここでオブジェクトＩＤは、以前に当該オブジェクトＩＤに対応するＰＥと通信を確立した際に得たものでもよいし、メインメモリ４２や情報処理システム１００内の共有メモリなどにリストアップされているものから選択するようにしてもよい。オブジェクトＩＤがルックアサイドバッファ１０４にエントリされていない状況は、過去に当該オブジェクトＩＤの処理要求を行わなかった場合、または長期間当該オブジェクトＩＤが参照されずに上書きされた場合に発生する。

オブジェクトＩＤがエントリされていない場合（Ｓ１１２のＮ）、リクエスト制御部３３は、メインメモリ４２に格納されたオブジェクトＩＤキャッシュ１４０に当該オブジェクトＩＤがエントリされているか否かを確認する（Ｓ１１４）。オブジェクトＩＤがエントリされていない場合（Ｓ１１４のＮ）、すなわち過去に同一のオブジェクトＩＤの処理要求がなされていない場合または長期間参照されずにエントリが上書きされてしまっている場合、リクエスト制御部３３はオブジェクトＩＤを指定してＰＵ２４に対し当該処理要求の転送要求を発行する（Ｓ１２０）。この処理は実施の形態１と同様に非同期で行われる。これにより、リクエスト格納領域５２には、当該転送要求が格納される。

このとき、転送要求にＰＵ２４に対する転送要求であることを識別する情報を含めてもよいし、リクエスト格納領域５２に設けたＰＵ２４専用の領域に転送要求を格納することでＰＵ２４が検出できるようにしてもよい。

ＰＵ２４のリクエスト受付部２７がリクエスト格納領域５２に当該転送要求が格納されていることを検出すると、まずＰＵ２４のリクエスト処理部２６における通信制御部１１６は、オブジェクトＩＤに基づき一般的なの手法で処理要求先のＰＥ１０２ｂのノード番号を取得する（Ｓ１２２）。そしてメインメモリ４２のオブジェクトＩＤキャッシュ格納領域１０６に格納されるオブジェクトＩＤキャッシュに、当該オブジェクトＩＤと取得したノード番号とを対応づけて記録する（Ｓ１２４）。

次にＰＵ２４の通信制御部１１６は、ルーティングテーブル格納領域１０８のルーティングテーブル１３０を参照し、処理要求先のＰＥ１０２ｂが接続するネットワークとそのローカルノードＩＤを取得し（Ｓ１２６）、処理要求の転送を実行する（Ｓ１３２）。Ｓ１２０において、ＰＥ１０２ｂのノード番号を取得するために処理要求の転送も行ってしまう場合は、Ｓ１２２のオブジェクトＩＤキャッシュの更新のみ行えばよい。これにより、オブジェクトＩＤキャッシュ１４０には当該処理要求のオブジェクトＩＤがノード番号とともにエントリされる。

以後、同一のオブジェクトＩＤの処理要求を行う場合は、当該オブジェクトＩＤがオブジェクトＩＤキャッシュ１４０にエントリされている状態（Ｓ１１４のＹ）となっている。この場合、処理要求元のアプリケーションＳＰＵ２３０ａのインターフェース選択部１０１は、オブジェクトＩＤキャッシュ１４０およびルーティングテーブル１３０を参照して、処理要求先のＰＥ１０２ｂが接続しているネットワークを取得したうえで、当該処理要求を転送するのに適切なネットワークおよびネットワークインターフェースを通信速度などに鑑み選択する（Ｓ１１６）。そしてオブジェクトＩＤと選択したネットワークインターフェースとの対応をルックアサイドバッファ１０４に書き込む（Ｓ１１８）。

続いて、当初からルックアサイドバッファ１０４にオブジェクトＩＤがエントリされていた場合（Ｓ１１２のＹ）と同様、リクエスト制御部３３は選択されたネットワークインターフェースが属するブロックに対し転送要求を発行する（Ｓ１３０）。図７に示した例ではネットワークインターフェースはシステムＳＰＵ２３１またはＰＵ２４にあるため、メインメモリ４２のリクエスト格納領域５２に設けたシステムＳＰＵ２３１またはＰＵ２４専用の領域に当該転送要求を格納する。あるいは処理要求にシステムＳＰＵ２３１またはＰＵ２４を識別する情報を含める。

システムＳＰＵ２３１またはＰＵ２４は、リクエスト格納領域５２に転送要求が格納されていることを検出すると、当該転送要求を実行する（Ｓ１３２）。このとき、システムＳＰＵ２３１により転送された処理要求は、要求先のＰＥ１０２ｂのシステムＳＰＵ２３１に到達する。ＰＵ２４により転送された処理要求は、要求先のＰＥ１０２ｂのＰＵ２４に到達する。これにより、システムＳＰＵ２３１が転送した処理要求については、要求先のＰＥ１０２ｂにおいてもＰＵ２４が受信処理を行わずに済む。

要求先のＰＥ１０２ｂに到達した処理要求は、当該ＰＥ１０２ｂのアプリケーションＳＰＵ２３０ａなどにおいて処理が実行され、必要に応じて同じネットワークを介して結果が返される（Ｓ１３４）。このとき、システムＳＰＵ２３１が転送した処理要求の結果は、要求先のＰＥ１０２ｂ内のシステムＳＰＵ２３１から要求元のＰＥ１０２ａ内のシステムＳＰＵ２３１に返される。これにより、当該処理要求についてはＰＵ２４が関与することなく処理要求および処理の結果の取得が完了する。

図１３はこれまで述べた機構によって、ＰＥ１０２ａ内のアプリケーションＳＰＵ２３０ａから別のＰＥ１０２ｂへ処理要求を行った場合の手順の例を示すタイムチャートである。図６のネットワーク構成においてＰＥ１０２ｂは第１ネットワーク８２に接続しており、図７においてシステムＳＰＵ２３１は第１ネットワーク８２への通信を行う第１ネットワーク通信部１１２を含んでいるため、図１３ではネットワークインターフェースとしてシステムＳＰＵ２３１の第１ネットワーク通信部１１２が選択され、ルックアサイドバッファ１０４に記録されているものとする。ただし、本実施の形態はそれに限られず、システムＳＰＵ２３１をＰＵ２４に置き換えることもできる。

システムＳＰＵ２３１やアプリケーションＳＰＵ２３０ａがリクエストや処理の結果を監視しながら待機状態となる点など、リクエストの発行や受け付けに係る詳細な処理手順は実施の形態１と同様であるため、ここでは図示を省略する。また、アプリケーションＳＰＵ２３０ａおよびシステムＳＰＵ２３１内の各機能ブロックはそれぞれアプリケーションＳＰＵ２３０ａおよびシステムＳＰＵ２３１で包括的に示している。同様に、要求された処理を行う主体も、要求先であるＰＥ１０２ｂ内のアプリケーションＳＰＵ２３０ａなどであるが、ＰＥ１０２ｂで包括的に示している。

まず処理要求元のアプリケーションＳＰＵ２３０ａは、タスク処理の途中で外部依頼処理が生じると、実施の形態１で説明したようにフラグを確認するなどして、メインメモリ４２の結果格納領域５４のうち使用する領域を決定するなどの初期化処理を行う（Ｓ１４０）。次にアプリケーションＳＰＵ２３０ａは必要な処理の内容に応じてリクエストを発行し、リクエスト格納領域５２に格納する（Ｓ１４２）。

リクエストには処理の結果を格納する結果格納領域５４へのポインタ、要求する処理の内容を表すＩＤ、およびオブジェクトＩＤが含まれる。処理の内容は、呼び出す関数自身を異ならせることによって区別してもよい。当該リクエストが処理要求先でのデータの加工などであり、要求先へデータを転送する必要がある場合は、メインメモリ４２内にリクエスト格納領域５２と別に設けたデータ格納領域（不図示）に順次格納していくようにしてもよい。このときリクエストには転送するデータを格納した領域のアドレスやデータサイズなども含める。

ＰＥ１０２ａのシステムＳＰＵ２３１は、リクエスト格納領域５２に当該リクエストが格納されたことを検知すると、リクエストを転送するための処理を開始し（Ｓ１４４）、当該リクエストを要求先のＰＥ１０２ｂに送信する（Ｓ１４６）。処理要求先に転送すべきデータがメインメモリ４２のデータ格納領域に格納されている場合は、当該データもＲＤＭＡなどによって転送する。

処理要求先がリクエストされた処理を完了した場合など、要求先のＰＥ１０２ｂから処理の結果が転送されると（Ｓ１４８）、要求元のＰＥ１０２ａ内のシステムＳＰＵ２３１は、その結果をメインメモリ４２内の結果格納領域５４に格納する（Ｓ１５０）。それと同時に、実施の形態１で説明したフラグ格納領域５６のフラグを更新し、結果が格納されたことをアプリケーションＳＰＵ２３０ａが認識できるようにする（Ｓ１５２）。アプリケーションＳＰＵ２３０ａはフラグ格納領域５６のフラグの更新を確認すると、結果格納領域５４中、当該フラグに対応する領域から処理結果を取得する（Ｓ１５４）。以上の動作により、ネットワークを介して接続した別のＰＥ１０２ｂへ処理要求を行い、その結果を取得することができる。

この場合も実施の形態１と同様、リクエスト発行元のアプリケーションＳＰＵ２３０ａやリクエストを転送するシステムＳＰＵ２３１において、リクエストの発行、転送、結果の転送、取得などを非同期で行うため、他のユニットがリクエストに係る処理を遂行している間、アプリケーションＳＰＵ２３０ａやシステムＳＰＵ２３１は別のタスクを処理することができ、効率的なスケジューリングが可能となる。また、１度リクエストを発行した要求先に再度リクエストを発行する場合は、アプリケーションＳＰＵ２３０ａにおいてネットワークの選択が完結し、さらに要求する処理内容などに応じてシステムＳＰＵ２３１が転送処理を実行するため、ＰＵ２４が担う処理の数が格段に減少する。結果として、ＰＵ２４はさらに効率よくＯＳなどの処理を遂行することができる。

本実施の形態は、実施の形態１で述べたような、単一のＭＰＵ２２内部で閉じた処理要求の遂行と並列させることが可能である。図１４は、ＰＥ１０２ａ内のアプリケーションＳＰＵ２３０ａから別のＰＥ１０２ｂへのネットワークを介した処理要求と、同じＰＥ１０２ａ内の別のアプリケーションＳＰＵ２３０ｂへのローカルな処理要求とを並列に遂行する場合の手順の例を示すタイムチャートである。ここでアプリケーションＳＰＵ２３０ａは、要求する処理内容や結果取得までの許容時間などに基づき、ネットワークを介した処理要求かローカルな処理要求かを選択し使い分けることにより、状況に適した態様を実現することができる。

なお図１４で示した２つのリクエストの発行順序や結果の格納順序は一例であり、実際の状況に応じて変化する。またローカルな処理要求先のアプリケーションＳＰＵ２３０ｂはＰＵ２４としてもよく、この場合は実施の形態１と同様となる。

まず処理要求元のアプリケーションＳＰＵ２３０ａは、タスク処理の途中でネットワークを介して外部に依頼する処理が生じると、図１３と同様、メインメモリ４２の結果格納領域５４のうち使用する領域を決定するなどの初期化処理を行い（Ｓ１６０）、リクエスト格納領域５２にリクエストを格納する（Ｓ１６２）。ＰＥ１０２ａのシステムＳＰＵ２３１は、リクエスト格納領域５２に当該リクエストが格納されたことを検知すると、リクエストにおいて指定された処理要求を転送するための処理を開始する（Ｓ１６４）。そしてリクエストやデータを、要求先のＰＥ１０２ｂに送信する（Ｓ１７０）。

一方、処理要求元のアプリケーションＳＰＵ２３０ａにおいて、今度はＰＥ１０２ａ内の別のアプリケーションＳＰＵ２３０ｂに要求する処理が生じると、アプリケーションＳＰＵ２３０ａはメインメモリ４２の結果格納領域５４のうち、先に発行した、ネットワークを介したリクエストにおいて使用する領域とは別の使用領域を決定して初期化処理を行う（Ｓ１６６）。そしてリクエスト格納領域５２にリクエストを格納する（Ｓ１６８）。リクエストの格納場所も当然、先に発行したリクエストとは異なる。処理要求先のアプリケーションＳＰＵ２３０ｂは、リクエスト格納領域５２に当該リクエストが格納されたことを検知すると、リクエストに指定された機能を実現するためのプログラムをメインメモリ４２からロードするなどしてアプリケーションＳＰＵ２３０ｂのスケジューリングに則り処理を開始する（Ｓ１７２）。

要求先のアプリケーションＳＰＵ２３０ｂは、要求された処理が完了した際などに、結果格納領域５４内の、リクエストにおいて指定された領域に結果を格納し（Ｓ１７４）、それと同時に、フラグ格納領域５６の対応するフラグを更新する（Ｓ１７６）。要求元のアプリケーションＳＰＵ２３０ａはフラグ格納領域５６のフラグの更新を確認すると、結果格納領域５４の対応する領域から処理結果を取得する（Ｓ１７８）。

一方、ネットワークを介してリクエストを送信した先のＰＥ１０２ｂからも処理の結果が転送されると（Ｓ１７１）、要求元のＰＥ１０２ａ内のシステムＳＰＵ２３１は、結果格納領域５４内の、リクエストにおいて指定された領域にその結果を格納する（Ｓ１８０）。それと同時に、フラグ格納領域５６の対応するフラグを更新する（Ｓ１８２）。要求元のアプリケーションＳＰＵ２３０ａはフラグ格納領域５６のフラグの更新を確認すると、結果格納領域５４の対応する領域から処理結果を取得する（Ｓ１８４）。

なお、ＰＥ１０２ａ内で閉じた処理要求を行う際は、実施の形態１で示した手順そのものを実行すればよく、オブジェクトＩＤやネットワークの選択に係る処理を行うライブラリを呼び出す必要はない。これにより余分な処理を行うことなく処理時間が短縮できる。

以上の手順によって、ネットワークを介して行う処理要求か、単一のＭＰＵ２２内部で行われる処理要求かに関わらず、アプリケーションＳＰＵ２３０ａは必要に応じてリクエストを発行し、発行後は別のタスクを処理することができる。そしてスケジュール上、効率のよい時点で結果を取得することができる。リクエストを転送するシステムＳＰＵ２３１や要求先のＰＥ１０２ｂのアプリケーションＳＰＵ２３０ａなどにおいても、効率のよいタイミングでリクエストを取得することができる。さらに要求元のＰＥ１０２ａのＰＵ２４は、場合によっては転送処理自体も行う必要がなくなる。

フラグ格納領域５６は、リクエストを転送するシステムＳＰＵ２３１またはローカルな処理要求の要求先であるアプリケーションＳＰＵ２３０ｂが結果を格納する際に更新するものであるため、同一のビット列を共有してもよい。これにより、処理要求元のアプリケーションＳＰＵ２３０ａは、ネットワークを介して得られた結果か、同一のＰＥ１０２ａ内で得られた結果かを区別することなく、結果の格納を認識することができる。結果として、意図に反して一方の結果の取得が他方より優先されたり、他のタスクより優先されたりすることがなくなり、情報処理システム１００全体において高い並列性を実現することができる。フラグ格納領域５６のフラグを認識してから結果を取得するまでの手順をあらかじめライブラリ上で設定しておくことにより、結果格納領域５４に格納された２つの結果を同時に取得する、格納された順に取得する、など所望の態様を選択できる。

以上述べた本実施の形態によれば、外部依頼処理が発生した場合、当該処理要求の発行および受け付けを、メインメモリにリクエスト格納領域を設けることで非同期に行う。また処理結果の送信および取得を、メインメモリに結果格納領域を設けることで非同期に行う。これにより、処理要求元のアプリケーションＳＰＵ、処理要求先のＰＥ内のアプリケーションＳＰＵ、処理要求を転送するＰＵやシステムＳＰＵなどでは、内部のスケジュールに則り、コンテキストスイッチを最小限とするようなタイミングで、処理要求に係る処理を行うことができ、システム全体のオーバーヘッドを軽減できる。また、処理要求元は予め用意されたライブラリを呼び出すことにより、要求する処理の内容を抽象化した形式で指定することができるため、要求元となるアプリケーションプログラムを簡略化でき、デバイス構成に依存しない共通化したプログラム作成が可能となる。同様に、本実施の形態は、各ＰＥが内部で行っているタスク処理の管理方式にも依存せずに実現させることが可能である。

ネットワークを介した処理要求についても、ライブラリによって最適なネットワークおよびネットワークインターフェースの選択を行うため、ネットワークインターフェーススの構成を変化させても、少ない手順で最適なネットワークを介した処理要求が可能となる。一般的なシステムにおいてはネットワーク通信をＰＵが集中的に管理するため、ネットワークを介してデータを送信する際は、ＰＵにおける処理順待ちなどによって送信開始が遅延することが多い。一方、本実施の形態では、一度処理要求を発行した要求先については、最適なネットワークインターフェースを要求元アプリケーションＳＰＵのローカルメモリに記憶させておくことにより、次回の処理要求発行時にはネットワーク選択に係る処理を省略でき、より短時間で処理要求を送信できる。

また、転送処理の一部を担うシステムＳＰＵを設けることにより、アプリケーションＳＰＵが要求する処理内容などに応じて、転送を依頼する先であるネットワークインターフェースをシステムＳＰＵかＰＵか選択できる。例えば高速に処理を遂行したい場合はＰＵを介さずシステムＳＰＵが処理要求の転送を行うことにより、ＰＵでの処理待ち時間などが生じないリアルタイム通信が可能となる。結果としてＰＵを介した非リアルタイム通信と、ＰＵを介さないリアルタイム通信とを共存させることができ、ネットワークの特性を生かした臨機応変な通信機構を実現できる。またＰＵが行う転送処理が減り、ＰＵの処理の負荷がさらに軽減される。

ここでシステムＳＰＵをＰＵとアプリケーションＳＰＵとの中間的位置づけとして設けることにより、ＰＵの処理の負荷を軽減できると同時に、アプリケーションＳＰＵで読み出すべきライブラリのコードの増加を抑えることができ、処理の分散に伴うアプリケーションＳＰＵへの悪影響を抑えることができる。

さらに、情報処理システムにおける要求先のＰＥの位置や通信を行うネットワークなど低レベルのデバイス層に係るパラメータを、位置に依存しないオブジェクトＩＤによってユーザレベルで管理する。これにより、ネットワーク通信を行う際に必要な、アプリケーション層からデバイス層まで落とし込む処理を省略することができると同時に、要求元となるアプリケーションプログラムでのネットワークに係る処理を、位置に依存せずに記述することができる。従ってアプリケーションプログラムの作成段階では、それを実行するシステムの構成を考慮せずにオブジェクトＩＤとライブラリの記述のみでネットワークを介した処理を実現させることができるため、容易に汎用性のある分散処理が可能なプログラムを作成することができる。

また、アプリケーションＳＰＵなどにおいて処理の負荷がしきい値を超えたら処理要求を発行するようにすることで、あるアプリケーションＳＰＵへの負荷の集中を回避する。処理要求先のＰＥなどでも同様に処理要求を発行することにより、情報処理システムに含まれるプロセッサユニット全体に渡る分散処理が自律的に達成され、より高速な並列処理が可能となる。アプリケーションプログラム上では、処理要求先の指定はオブジェクトＩＤのみで管理するため、一のオブジェクトＩＤに対応した実際の要求先を、呼び出されたライブラリ上で変更することが可能である。これにより例えばアプリケーションプログラム上で詳細な設定をせずに、負荷の少ないプロセッサユニットを要求先として自動的に選択することも可能となる。

さらに、ネットワークを介した処理要求と、単一のＰＥ内の別のＳＰＵに対する処理要求とで、同一の機構を利用できるため、単一のＭＰＵを有する装置から、マルチコアの構成を有する情報処理システムへ容易に発展させることができる。また、例えばフラグ格納領域を共通化することにより、ネットワークを介すか否かに関わらず、同様の優先度で結果を受け取ることができるため、位置に依存しない高い並列性を有した処理が可能となる。

以上、本発明を実施例をもとに説明した。この実施例はあくまで例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

例えば、本実施の形態２で示したオブジェクトＩＤキャッシュを、ライブラリを実行するＰＵが動的に設定してもよい。 例えば、ある要求先のＰＥにおいて処理の負荷が増大してきた場合、１つのオブジェクトＩＤに対応して複数のノードを設定するように変更してもよい。要求元のＳＰＵではリクエストはオブジェクトＩＤのみで管理され、当該オブジェクトＩＤは位置に非依存であるため、このように設定を変更しても処理要求は同様に遂行される。これにより、処理の負荷の集中が回避され、より効率のよい処理を実現できる。

一方、オブジェクトＩＤにノード番号などの位置情報を含めてもよい。この場合は、ルーティングテーブルなどによって要求先のノード番号を取得する処理を省略することができる。この態様は、情報処理システム１００においてＰＥを再構築するなどノードの変更を伴わない環境では有効であり、より低コストで本実施の形態で述べたのと同様の効果を得ることができる。

実施の形態１における情報処理装置の構成例を示す図である。 実施の形態１におけるＰＵ、ＳＰＵ、およびメインメモリの詳細な構成を示す図である。 実施の形態１における各機能ブロックによって外部依頼処理が遂行される手順の例を示すタイムチャートである。 実施の形態１においてメインメモリにフラグ格納領域を設けた場合の態様例を模式的に示す図である。 実施の形態１における情報処理装置の動作の具体例を示すタイムチャートである。 実施の形態２における情報処理システムの構成を示す図である。 実施の形態２のＰＥにおけるＭＰＵの構成を詳細に示す図である。 実施の形態２のＰＥにおけるメインメモリの構成を詳細に示す図である。 実施の形態２におけるメインメモリのルーティングテーブル格納領域に格納されるルーティングテーブルのデータ構造の例を示す図である。 実施の形態２におけるメインメモリのオブジェクトＩＤキャッシュ格納領域に格納されるオブジェクトＩＤキャッシュのデータ構造の例を示す図である。 実施の形態２におけるアプリケーションＳＰＵのローカルメモリに設けられるルックアサイドバッファのデータ構造の例を示す図である。 実施の形態２におけるＳＰＵに外部依頼処理が発生した際の、処理要求の転送に係る処理手順を示すフローチャートである。 実施の形態２において、ＰＥ内のアプリケーションＳＰＵから別のＰＥへ処理要求を行った場合の手順の例を示すタイムチャートである。 実施の形態２において、ＰＥ内のアプリケーションＳＰＵから別のＰＥへのネットワークを介した処理要求と、同じＰＥ内の別のアプリケーションＳＰＵへのローカルな処理要求とを並列に遂行する場合の手順の例を示すタイムチャートである。

符号の説明

１０ 情報処理装置、 ２２ ＭＰＵ、 ２４ ＰＵ、 ２６ リクエスト処理部、 ２７ リクエスト受付部、 ３０ａ ＳＰＵ、 ３０ｂ ＳＰＵ、 ３２ タスク処理部、 ３３ リクエスト制御部、 ３４ ローカルメモリ、 ３６ 内部バス、 ３８ メインバス、 ４０ ＧＰＵ、 ４１ Ｉ／Ｏ、 ４２ メインメモリ、 ４４ ＨＤＤ、 ５０ プログラム格納領域、 ５２ リクエスト格納領域、 ５４ 結果格納領域、 ５６ フラグ格納領域、 ８２ 第１ネットワーク、 ８４ 第２ネットワーク、 ８６ 第３ネットワーク、 １００ 情報処理システム、 １０１ インターフェース選択部、 １０２ａ ＰＥ、 １０２ｂ ＰＥ、 １０４ ルックアサイドバッファ、 １０６ オブジェクトＩＤキャッシュ格納領域、 １０８ ルーティングテーブル格納領域、 １１２ 第１ネットワーク通信部、 １１４ タスク処理部、 １１６ 通信制御部、 １１８ 第１ネットワーク通信部、 １２０ 第２ネットワーク通信部、 １２２ 第３ネットワーク通信部、 ２３０ａ アプリケーションＳＰＵ、 ２３１ システムＳＰＵ。

Claims (5)

1. 複数のプロセッサを含み、そのうち第１のプロセッサが第２のプロセッサ、またはネットワークを介して接続した他のプロセッサユニットへ処理単位であるオブジェクトの処理要求を発行するプロセッサユニットであって、
   前記オブジェクトの識別情報と、当該オブジェクトに対応する他のプロセッサユニットのネットワーク上の位置と、を対応づけたオブジェクト情報を格納したメインメモリと、
   他のプロセッサユニットへ接続する、異なるアーキテクチャを有する複数のネットワークに対応する複数のネットワークインターフェースと、
   前記第１のプロセッサに接続したローカルメモリと、を備え、
   前記第１のプロセッサは、前記第２のプロセッサへの処理要求に加え、他のプロセッサユニットへの処理要求を、要求するオブジェクトの識別情報に基づき前記オブジェクト情報を参照することにより取得した転送経路のネットワークを指定したうえでメインメモリに格納するリクエスト制御部を備え、
   前記第２のプロセッサは、
   前記メインメモリに格納された前記第２のプロセッサへの処理要求および他のプロセッサユニットへの処理要求を検出するリクエスト受付部と、
   前記第２のプロセッサへの処理要求において指定された処理を実行するとともに、他のプロセッサユニットへの処理要求を、前記第１のプロセッサが指定したネットワークを介して要求先のプロセッサユニットへ転送するリクエスト処理部と、
   を備え、
   前記第２のプロセッサのリクエスト受付部はさらに、前記第２のプロセッサへの処理要求に応じて前記リクエスト処理部が実行した処理の結果と、他のプロセッサユニットへの処理要求に応じて要求先のプロセッサユニットが実行した処理の結果とを、前記メインメモリに格納し、
   前記第１のプロセッサのリクエスト制御部はさらに、前記メインメモリに前記処理の結果が格納されたことを検知し、当該処理の結果を読み出し、
   前記第１のプロセッサはさらに、他のプロセッサユニットへの処理要求を発行する際、前記取得したネットワークに対応する前記複数のネットワークインターフェースから所定の基準によって一のネットワークインターフェースを選択するインターフェース選択部を備え、
   前記第１のプロセッサのリクエスト制御部は前記インターフェース選択部によって選択された一のネットワークインターフェースを指定して他のプロセッサユニットへの処理要求を発行し、
   前記第２のプロセッサのリクエスト処理部は、前記リクエスト制御部が指定したネットワークインターフェースを介して要求先のプロセッサユニットへ処理要求を転送し、
   前記ローカルメモリは、前記インターフェース選択部が他のプロセッサユニットへの一のオブジェクトの処理要求を発行する際に初回に選択した一のネットワークインターフェースの識別情報と、当該オブジェクトの識別情報とを対応づけた識別情報バッファを含み、
   前記第１のプロセッサのリクエスト制御部は、他のプロセッサユニットへの同一オブジェクトの処理要求を再度発行する際、要求するオブジェクトの識別情報に基づき、前記オブジェクト情報に代えて前記識別情報バッファを参照することにより、当該オブジェクトに対し初回に選択されたネットワークインターフェースの識別情報を取得し、当該ネットワークインターフェースを指定して当該プロセッサユニットへの処理要求を発行することを特徴とするプロセッサユニット。
2. 前記オブジェクトの識別情報は、ネットワーク上のプロセッサユニットの位置に依存しない情報であり、
   前記第１のプロセッサのリクエスト制御部は、他のプロセッサユニットへの処理要求に要求するオブジェクトの識別情報を含め、
   前記第２のプロセッサのリクエスト処理部は、他のプロセッサユニットへの処理要求に含まれる前記オブジェクトの識別情報から当該オブジェクトに対応する他のプロセッサユニットの位置情報を特定し、前記オブジェクト情報を作成してメインメモリに格納する
   ことを特徴とする請求項１に記載のプロセッサユニット。
3. 前記第１のプロセッサのリクエスト制御部はさらに、要求するオブジェクトの識別情報に基づき前記識別情報バッファを参照することにより、当該処理対象に対し初回に選択されたネットワークインターフェースの識別情報を取得し、当該オブジェクトの処理要求を、取得したネットワークインターフェースを制御する第３のプロセッサに対し発行し、
   前記第３のプロセッサは、前記第２のプロセッサに代わり前記処理要求を要求先のプロセッサユニットへ転送することを特徴とする請求項１に記載のプロセッサユニット。
4. 第１のプロセッサにおいて処理の負荷が所定のしきい値を超えたときに、内部バスで接続された第２のプロセッサまたはネットワークを介して接続した他のプロセッサユニットのいずれかに対する、処理単位であるオブジェクトの処理要求をメインメモリに格納するステップと、
   前記第２のプロセッサが前記メインメモリから読み出した処理要求が、他のプロセッサユニットへの処理要求であった場合に、前記第２のプロセッサが要求先のプロセッサユニットに当該処理要求を転送するステップと、
   前記第２のプロセッサが前記メインメモリから読み出した処理要求が、前記第２のプロセッサへの処理要求であった場合に、前記第２のプロセッサが前記処理要求に対応する処理を実行するステップと、
   前記第２のプロセッサが、前記第２のプロセッサまたは他のプロセッサユニットが行った前記処理要求に対応する処理の結果を前記メインメモリに格納するステップと、
   前記第１のプロセッサが前記処理の結果を前記メインメモリから読み出すステップと、
   を含み、
   前記処理要求をメインメモリに格納するステップは、メインメモリに格納された、前記オブジェクトの識別情報と当該オブジェクトに対応する他のプロセッサユニットのネットワーク上の位置とを対応づけたオブジェクト情報を参照し、転送経路のネットワークを指定したうえで当該処理要求を格納し、
   前記転送するステップは、指定されたネットワークを介して処理要求を転送し、
   前記処理要求をメインメモリに格納するステップはさらに、同一のオブジェクトの処理要求を再度発行する際は、当該オブジェクトの識別情報に基づき、前記オブジェクト情報に代えて、前記第１のプロセッサに接続したローカルメモリに格納された、前記オブジェクトの識別情報と当該オブジェクトに対し初回に選択された一のネットワークインターフェースの識別情報とを対応づけた識別情報バッファを参照することにより、当該オブジェクトに対し初回に選択されたネットワークインターフェースを指定したうえで当該処理要求を格納し、
   前記転送するステップは、指定されたネットワークインターフェースを介して処理要求を転送することを特徴とする情報処理方法。
5. 前記オブジェクトの識別情報は、ネットワーク上のプロセッサユニットの位置に依存しない情報であり、
   前記処理要求をメインメモリに格納するステップは、他のプロセッサユニットへの処理要求に要求するオブジェクトの識別情報を含め、
   前記転送するステップは、他のプロセッサユニットへの処理要求に含まれる前記オブジェクトの識別情報から当該オブジェクトに対応する他のプロセッサユニットの位置情報を特定し、前記オブジェクト情報を作成してメインメモリに格納するステップを含むことを特徴とする請求項４に記載の情報処理方法。

Images