JP5932373B2 - プロセッサ間通信制御方法及びシステム - Google Patents
プロセッサ間通信制御方法及びシステム Download PDFInfo
- Publication number
- JP5932373B2 JP5932373B2 JP2012021167A JP2012021167A JP5932373B2 JP 5932373 B2 JP5932373 B2 JP 5932373B2 JP 2012021167 A JP2012021167 A JP 2012021167A JP 2012021167 A JP2012021167 A JP 2012021167A JP 5932373 B2 JP5932373 B2 JP 5932373B2
- Authority
- JP
- Japan
- Prior art keywords
- transfer
- instruction
- data transfer
- processor
- scheduler
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Multi Processors (AREA)
- Small-Scale Networks (AREA)
Description
マルチプロセッサシステムでは、各プロセッサが互いに処理結果をデータ転送しながら並列して処理を行い、全体として高い演算性能を出すことを目指す。この際に大きな問題となるのが、プロセッサ間のデータ転送にかかる通信である。
従来技術ではこのような場合に、どちらの通信を優先させるかにQoS技術を用いて制御を行っていた。
また特許文献1ではバス型のPE間ネットワークでの調停を想定しているが、プロセッサ間通信の単位をひとまとまりのデータ通信(アクセスブロック)ごとに行うことで、調停の回数を低減させていた。
また特許文献1ではPE間ネットワークのデータ転送レートをより高める制御に関しては言及していない。
図1は、マルチプロセッサシステムの一例を示す図である。なお、マルチプロセッサシステムの構成方法には幾つかあるが、本実施形態では図1に示すようなシステムを想定する。
各プロセッサPEx(11x)は、実際の演算を行うプロセシングユニットPU(12x)と、PEが優先して使用可能なローカルメモリLM(13x)と、を備える。このようなPEが互いに通信を行うために通信インターフェースPEIF(14x)を介してPE間ネットワーク15によって接続されている。
PE間ネットワーク15は、クロスバスイッチやリングバスといった、互いに異なるPE同士の通信であれば、他の通信との間で衝突(コリジョン)を起こさず、高速に通信可能なものである。
こうしたシステムの上で、効率的に通信を行うには、PE間ネットワーク内のデータ転送レートをより高めること、即ち衝突のない通信をいかに多く実行するかにかかっている。
図2Aは、データ転送を行う各PEで実践する転送ワーカーの構成の一例を示す図である。また、図2Bは、転送ワーカーとの間でやりとりを行うスケジューラの構成の一例を示す図である。スケジューラは、システム内で唯一つ存在する。データ転送トラフィックとの衝突を減らすという観点からは、スケジューラは、データ転送を行わないPEに配置するのがよい。但し、画像データのデータ転送のようにデータ転送トラフィックに比べて通信制御のためのトラフィックが十分に少ないと仮定できる場合には、スケジューラを転送ワーカーと同じPEに配置してもよい。
PE0ではPE1へデータ転送を行いたい旨(送信要求)を転送ワーカーのリクエストメッセージ生成部213に対して伝える。リクエストメッセージ生成部213ではPE0からPE1へのデータ転送を要求するリクエストメッセージを生成(発行)し、PE間ネットワークとのインターフェースであるPEIF14を経由して、スケジューラに対してメッセージを送出する(要求発行)。
スケジューラではリクエストメッセージ受信部224がPEIF14を経由して、このリクエストメッセージを受信し(要求受信)、転送リクエストチェック部221に伝える。
転送リクエストチェック部221は、転送状態管理テーブル223内の現在転送状態2231を参照し、前記リクエストメッセージの対となるメッセージを既に受信済みか否かをチェックする。対となるメッセージとは、この場合、受信側PEであるPE1から受信した「PE0からPE1への転送リクエスト」(受信要求)となる。
なお、転送状態管理テーブル223とは、スケジューラがPE間通信の制御を行うための情報を保持するもので、典型的には読み書き可能なメモリに実装される。但し、本実施形態はこの実装方法に限定されるものではない。
現在転送状態2231とは、PE間の現在のデータ転送状態を表すもので、各データ転送の状態を管理している。より具体的には各データ転送をその状態と共にエントリとしてまとめ、全てのエントリをテーブルとして保持する。但し本実施形態はデータ転送状態の保持方法については限定しない。現在転送状態2231は各PEからのリクエストを基にスケジューラが更新する。更新の詳細については、以降、説明する。
PE0と同様に、PE1の転送ワーカーは、スケジューラに対して「PE0からPE1へのデータ転送」に関する受信要求のリクエストメッセージを出す(要求発行)。
スケジューラでは、この受信要求をPEIF14経由でリクエストメッセージ受信部224が受信し、転送リクエストチェック部221へ渡す。
転送リクエストチェック部221では先ほどと同じように、「PE0からPE1へのデータ転送」に関するエントリを現在転送状態2231から取得し、チェックする。転送リクエストチェック部221は、今度は「リクエスト待ち」状態としてエントリが得られる。そこで転送リクエストチェック部221は、状態を「未スケジュール」と変更する。
なお、ここではPE0からの送信要求が、PE1からからの受信要求よりも先にスケジューラに届いた場合を説明したが、どちらが先にスケジューラに届いてもよい。転送リクエストチェック部221は、一方の要求がスケジューラに届いた際に「リクエスト待ち」状態のエントリを作成し、両者の要求が届いた際に「未スケジュール」に状態を変更する。
但し、リクエスト待ち状態のエントリの作成は、データ転送可能な状態に変化はないので、転送スケジュールの生成を含めた以降の処理は行わない。
現在転送状態2231が変更されるきっかけは、各PEからのデータ転送リクエスト(送信要求又は受信要求)メッセージ、或いは後述する現在転送中のデータ転送が完了したことを通知する転送完了メッセージの受信である。つまり、PEは、後述するように、現在転送中のデータ転送が完了した場合、完了したことを通知する転送完了メッセージを出す(通知発行)。
PE1からの受信要求により「PE0からPE1へのデータ転送状態」が「リクエスト待ち」状態から「未スケジュール」状態になったのを受け、転送スケジュール生成部222は、現在転送状態2231を基に更新転送スケジュール2232を生成する。
更新転送スケジュール2232とはスケジューラが各PEに出す指示の内容である。転送スケジュール生成部222は、現在転送状態2231と、受信したメッセージの内容とから、PE間ネットワークのデータ転送レートをより高めるよう、各PEに送信すべきデータ転送に関する指示を決定する。そして、転送スケジュール生成部222は、この更新転送スケジュール2232を基に、各PEへ指示を出すと共に現在転送状態2231に反映させる。
そして転送スケジュール生成部222が更新転送スケジュール2232で現在転送状態2231を更新すると共に、転送指示メッセージ生成部226が転送指示メッセージを生成する。
転送指示メッセージは、PE0に対するPE1への送信指示メッセージ(転送指示メッセージ)と、PE1に対するPE0からの受信指示メッセージ(転送指示メッセージ)である。転送指示メッセージ生成部226は、これらのメッセージをそれぞれのPEにPEIF14を通じて送信する。
そして転送リスト管理部211は、転送リスト212に「PE1への送信」というエントリを追加する。更に転送指示部216は、PEIF14にPE1へのデータ転送を指示する。
PE1では、PE0と同様にスケジューラからの「PE0からの受信メッセージ(転送指示メッセージ)」を、PEIF14を経由して転送指示メッセージ受信部214で受信する。
そして転送リスト管理部211が、転送リスト212に「PE0からの受信」というエントリを追加する。更に転送指示部216が、PEIF14にPE0からのデータ転送を指示する。
以上の手順により、PE0からPE1へのデータ転送が実現される。
同様に、PE1でもデータ転送が終わると、PEIF14が転送完了した旨を指示完了通知受信部217に対して伝える。転送リスト管理部211は、前記データ転送のエントリである「PE0からの受信」を転送リスト212から削除する。そして、完了通知メッセージ生成部215で前記データ転送が完了した旨のメッセージを生成し、PEIF14を通じてスケジューラに送信する。
スケジューラでは、PE0又はPE1からの転送完了メッセージを、PEIF14を経由して完了通知メッセージ受信部225で受信する。そして転送スケジュール生成部222は、現在転送状態2231のエントリ「PE0からPE1へのデータ転送」を削除する。
最初に受信した転送完了メッセージによって、前記エントリは削除されてしまうため、もう一方の転送完了メッセージ受信時には前記エントリがない。その場合、スケジューラは、何もしない。
この時点で現在転送状態2231が変化したので、転送スケジュール生成部222は、現在転送状態2231を参照し、更新転送スケジュール2232を生成するが、新たにスケジューリングできるデータ転送のエントリはないため、内容は何もない。
以上の手順により、PE0からPE1へのデータ転送が終了する。
図3は、実施形態1のPE間データ転送の様子を表した図である。点線が「未スケジュール」状態のデータ転送であり、実線のPE2⇒PE3のデータ転送は、「転送中」状態である。
実線の「転送中」のデータ転送により、点線の何れのデータ転送もPE2或いはPE3でコンフリクトを起こしてしまうため、「未スケジュール」状態にある。
この状態で実線のデータ転送が完了した場合、転送スケジュール生成部222は、点線の「未スケジュール」状態のデータ転送のうち、幾つかを選択して「転送中」状態にした更新転送スケジュール2232を生成する。
スケジュールの生成は、PE間ネットワーク内のデータ転送レートをより高めるよう、即ち衝突のないデータ転送をより多くするように行う。
この場合、PE0⇒PE3はPE0で、PE1⇒PE2はPE2で衝突を起こすため、1つの通信のみスケジューリング可能である。
ケース2)PE0⇒PE3、PE1⇒PE2
この場合、PE0⇒PE2はPE0及びPE2で衝突を起こすため、2つの通信をスケジューリング可能である。
以上のように衝突を起こさない通信のスケジューリングには2つのケースが考えられるが、ケース1の場合は1つ、ケース2の場合は2つの通信をスケジューリングできる。
そこで、転送スケジュール生成部222は、より多くの通信をスケジューリングできるケース2を更新転送スケジュール2232とし、「PE0⇒PE3」「PE1⇒PE2」のデータ転送の状態を「転送中」とする。
この結果を受けて、転送指示メッセージ生成部226は、以下の4つのメッセージを各PEに対して生成し、PEIF14を通じて送信する。
1)PE0に対して「PE0⇒PE3」の転送指示メッセージ(送信指示メッセージ)
2)PE1に対して「PE1⇒PE2」の転送指示メッセージ(送信指示メッセージ)
3)PE2に対して「PE1⇒PE2」の転送指示メッセージ(受信指示メッセージ)
4)PE3に対して「PE0⇒PE3」の転送指示メッセージ(受信指示メッセージ)
スケジューリングに関して、図4のような場合を例に説明を行う。図4は、実施形態2のPE間データ転送の様子を表した図である。
「PE0⇒PE1」が転送中である場合に、新たに「PE0⇒PE2」の転送要求があり「未スケジュール」状態となった場合である。
転送スケジュール生成部222は、現在転送状態2231を基に更新転送スケジュール2232を生成する。
仮に「PE0⇒PE2」を「転送中」状態にスケジューリングした場合、PE0で衝突してしまう。そこで転送スケジュール生成部222は、「PE0⇒PE2」のデータ転送を「PE0⇒PE1」のデータ転送が完了し次第開始するようにスケジューリングする。
これにはスケジューラがPE0、PE2に「PE0⇒PE2」の転送指示を出し、転送指示を受信したPEが受信した順にひとつずつ、先行するデータ転送が完了したら次のデータ転送を開始するようにすればよい。
・「PE0⇒PE2」の転送状態を「スケジュール済」とする。
転送スケジュール生成部222は、この更新転送スケジュール2232で現在転送状態2231を更新する。そして転送指示メッセージ生成部226は、以下の2つのメッセージを各PEに対して生成し、PEIF14を通じて送信する。
1)PE0に対して「PE0⇒PE2」の転送指示メッセージ(送信指示メッセージ)
2)PE2に対して「PE0⇒PE2」の転送指示メッセージ(受信指示メッセージ)
PE2が上記転送指示メッセージを受信したあとの動作は、実施形態1と同様であるので省略する。
転送リスト管理部211は、転送リスト212に「PE2への送信」というエントリを追加する。このとき、転送リスト管理部211は、既に何らかのエントリがあるかどうかをチェックする。空であれば、転送リスト管理部211は、実施形態1と同様に、データ転送を開始するために転送指示部216を呼び出し、データ転送を指示する。ここでは、「PE1へのデータ転送」というエントリが既に入っているため、転送リスト管理部211は、処理を終了する。
PE0では、転送リスト212の最初のエントリ「PE1への送信」を実行中である。このデータ転送が完了すると、実施形態1と同様に指示完了通知受信部217からデータ転送を終了した旨の通知を受け、転送リスト管理部211は、転送リスト212のエントリ(先頭エントリ)を削除し、完了通知メッセージ生成部215を呼び出す。
このとき、転送リスト管理部211は、先頭エントリ削除後の転送リスト212をチェックし、先頭エントリがあるか否かを調べる。ここでは「PE2への送信」が先頭エントリとして得られる。先頭エントリが得られた場合、このエントリの内容に従って転送指示部216は、PEIF14にデータ転送を指示する。
このように転送スケジュール生成部222は、更新転送スケジュール2232を生成する際に、「未スケジュール」状態のデータ転送のうち、どれを「転送中」にし、どれを「スケジュール済」とするか、の決定を行う。
これは「未スケジュール」状態のデータ転送のエンドポイントとなる2つのPE(送信側と受信側と)が「転送中」或いは「スケジュール済」状態のデータ転送のエンドポイントとなっているかによって決定すればよい。つまり、転送スケジュール生成部222は、
・両側が何れのデータ転送のエンドポイントにもなっていなければ、「転送中」状態とする。
・一方が「転送中」或いは「スケジュール済」状態のデータ転送のエンドポイントで、もう一方が何れのデータ転送のエンドポイントにもなっていなければ、「スケジュール済」とする。
・両側が「転送中」或いは「スケジュール済」状態のデータ転送のエンドポイントとなっている場合は、「未スケジュール」状態のままにする。
実施形態2の場合「PE0⇒PE2」のデータ転送について、PE0は「転送中」状態の「PE0⇒PE1」のエンドポイントとなっているが、PE2は何れのデータ転送のエンドポイントにもなっていない。そこで、転送スケジュール生成部222は、「PE0⇒PE2」のデータ転送は「スケジュール済」とする。
実施形態2では転送スケジュール生成部222は、「未スケジュール」状態のデータ転送のうち、どれを「転送中」にし、どれを「スケジュール済」とするか、の決定を行った。
しかしPE間ネットワーク15のデータ転送レートをより高めるには「スケジュール済」状態のデータ転送をキャンセルして、再スケジュールした方がよい場合もある。
図5はこのような場合の例である。図5は、実施形態3のPE間データ転送の様子を表した図(その1)である。
「PE0⇒PE2」は「転送中」状態であり、「PE0⇒PE3」は「スケジュール済」状態である。ここに新たに「PE1⇒PE3」が「未スケジュール」状態として加わる場合である。
実施形態2のようなスケジューリングを行った場合、「PE1⇒PE3」のデータ転送は「スケジュール済」状態となる。このときPE3の転送ワーカーでは転送リスト212には「PE0からの受信」と「PE1からの受信」との2つのエントリがある。
そのため「PE0⇒PE2」のデータ転送完了後、「PE0⇒PE3」のデータ転送を行い、更にそのあとに「PE1⇒PE3」のデータ転送を行うことになる。
しかしながら、実際には「PE0⇒PE3」のデータ転送は開始されていないため、このデータ転送をキャンセルした上で「PE1⇒PE3」のデータ転送を開始すれば、PE間ネットワーク15のデータ転送レートをより高めることができる。
「PE0⇒PE2」及び「PE1⇒PE3」のデータ転送は「転送中」状態にあり、「PE0⇒PE3」のデータ転送は「未スケジュール」状態にある。
こうした通信制御を実践するプロセッサ間通信制御方法の構成例を図7に示す。図7Aは、図2Aに対応する、転送ワーカーの構成の一例を示す図である。図7Bは、図2Bに対応するスケジューラの構成の一例を示す図である。
転送ワーカーの構成では、転送指示メッセージ受信部214が転送・キャンセル指示メッセージ受信部218に、転送指示部216が転送・キャンセル指示部219に変更されている。
スケジューラの構成では、転送スケジュール生成部222が更新転送状態生成部227に、転送指示メッセージ生成部226が転送・キャンセル指示メッセージ生成部229に、更新転送スケジュール2232が更新転送状態2233に変更されている。更に、スケジューラの構成では、更新転送状態生成部227と転送・キャンセル指示メッセージ生成部229との間に転送状態比較部228が新たに設けられている。
なお、このように変更しても、上述した実施形態で示した動作を行うことは可能である。
またスケジューラでは、更新転送状態生成部227は、実施形態2の条件に従って、更新転送状態2233を生成する。更新転送状態2233とは、転送指示を出した後の現在転送状態2231の状態そのものである。
転送状態比較部228では更新転送状態2233と現在転送状態2231との差分を抽出するが、これが更新転送スケジュール2232に相当する。
転送・キャンセル指示メッセージ生成部229では、この更新転送スケジュール2232に相当する情報を転送状態比較部228から受け、実施形態2と同様の動作を行う。
図5は現在の現在転送状態2231の状態である。図6は目標とする現在転送状態2231の状態である。更新転送状態生成部227は、図5の状態の現在転送状態2231から、図6の状態の更新転送状態2233を生成する。
このためには、更新転送状態生成部227は、「未スケジュール」状態のデータ転送だけではなく、「スケジュール済」状態のデータ転送も合わせたデータ転送のうち、どれを「転送中」にし、どれを「スケジュール済」状態にするのかを決定すればよい。
この決定は、更新転送状態生成部227は、実施形態2に準じて行えばよい。一例として図8に示す。図8は、更新転送状態生成部227における更新転送状態2233の決定の処理の一例を示すフローチャートである。
S81:更新転送状態生成部227は、現在転送状態2231に含まれる「スケジュール済」状態のデータ転送を全て「未スケジュール」状態としたものを候補とする。
例えば、S81の結果である候補に「スケジュール済」状態、或いは「未スケジュール」状態のデータ転送が3つある場合、最大8(=2の3乗)通りの組み合わせ候補がある。これらのうち、更新転送状態生成部227は、「転送中」状態のデータ転送が衝突を起こしている、即ち2つ以上の、「転送中」状態のデータ転送のエンドポイントとなっているPEがある場合は、候補から外す。
S83:更新転送状態生成部227は、S82で選択された全ての候補について、最も「転送中」状態のデータ転送が多いものを選択する。
更新転送状態生成部227は、残った候補のうちから、最も「転送中」状態のデータ転送が多いものを選択する。もし複数の候補が残った場合、更新転送状態生成部227は、全てを候補とする。ここまでで「転送中」状態のスケジューリング候補が決定する。
更新転送状態生成部227は、「転送中」状態のデータ転送が終わり次第、即座にデータ転送を始める「スケジュール済」状態のデータ転送をスケジューリングする。「スケジュール済」状態のデータ転送は、データ転送のエンドポイントの一方が他の何れのデータ転送のエンドポイントにもなっておらず、もう一方は他の「転送中」状態或いは「スケジュール済」状態のデータ転送のエンドポイントになっているものである。
このあと説明するが「スケジュール済」状態のデータ転送を「未スケジュール」状態とする(データ転送を「キャンセル」する)には、幾つかのやりとりをスケジューラと転送ワーカーとの間で行う必要がある。また「スケジュール済」状態のデータ転送が開始され「転送中」となってしまうこともある。
こうした状況では再度スケジューリングの機会が訪れた場合、最適なスケジューリングができない可能性がある。そのため更新転送状態生成部227は、キャンセルするデータ転送の数がより少ないものを候補として選択する。
「スケジュール済」状態のデータ転送は、先行する「転送中」状態のデータ転送の完了に伴い、即座に開始されるため、データ転送開始にかかるタイムラグを減らすことができる。そのため、更新転送状態生成部227は、タイムラグをより減らすことができるよう、「スケジュール済」状態のデータ転送数が最も多いものを選択する。
S87:更新転送状態生成部227は、S86で選択された候補を更新転送状態2233とする。
以上の手順で選択された候補が更新転送状態2233となる。
次に転送状態比較部228は、現在転送状態2231(図5)と更新転送状態2233(図6)とを比較し、差分を得る。図9にその結果を示す。図9は、転送状態の差分の一例を示す図である。
転送状態比較部228は、この結果を基に現在転送状態2231を更新する。
1番の差分に関しては、単に「スケジュール済」を「未スケジュール」とするわけにはいかない。「スケジュール済」状態のデータ転送に関しては、先行する「転送中」状態のデータ転送の完了に伴い、自動的にデータ転送が開始されてしまっている可能性がある。その場合は「転送中」としなければならない。
またスケジューラにおいては、前記データ転送が「転送中」であるにも関わらず「未スケジュール」状態となっている。そのため、前記データ転送が再スケジュールされてしまう可能性もある。
そこで転送状態が確定するまでは再スケジュールされないようにしなければならない。そのためには前記データ転送を「未確定」としてマークし、再スケジュール対象から外してもよいが、「転送中」状態としてしまってもよい。ここでは「転送中」状態にすることにする。
即ち、転送状態比較部228は、以下のような状態の変更を現在転送状態2231に対して行う。
・「PE0⇒PE3」のデータ転送状態を「転送中」とする。
・「PE1⇒PE3」のデータ転送状態を「転送中」とする。
1番の差分に関しては、転送・キャンセル指示メッセージ生成部229は、「PE0⇒PE3」を「スケジュール済」状態を「未スケジュール」状態にする「キャンセル」指示メッセージ生成する。但し、転送・キャンセル指示メッセージ生成部229は、このメッセージをPE3にのみ送信する(キャンセル指示発行)。
データ転送の開始はエンドポイントのPE間の合意の上で行われるので、一方がキャンセルされた場合、データ転送は始まらない。またPE3は受信待機状態であり、PE0からのデータ転送開始を待っている状態である。そこでスケジューラは、PE3に対してのみキャンセル指示を出し、キャンセルが確認できた時点でPE0にもキャンセル指示を出すようにする。
以上により、転送・キャンセル指示メッセージ生成部229は、以下のような指示メッセージを生成し、順番にPEIF14を通じて各PEに送信する。
1)PE1に対して「PE1⇒PE3」の転送指示メッセージ(送信指示メッセージ)
2)PE3に対して「PE0⇒PE3」のキャンセル指示メッセージ
3)PE3に対して「PE1⇒PE3」の転送指示メッセージ(受信指示メッセージ)
なお、受信PEは上記指示メッセージの上から順番に処理を行う。より具体的にはPE3はキャンセル指示メッセージの処理を行った上で、転送指示メッセージの処理を行う。
PE3は、まず2)のキャンセル指示メッセージの処理を行う。
PEIF14を経由して転送・キャンセル指示メッセージ受信部218は、キャンセル指示メッセージを受信する。
続いて転送リスト管理部211は、転送・キャンセル指示部219に対して「PE1⇒PE3」のデータ転送をキャンセルする旨の指示を出す。
キャンセル指示部219は、PEIF14に対してキャンセル指示を出し、前記データ転送がキャンセルできたか否かが指示完了通知受信部217に伝えられる。
キャンセルできたか否かの結果は、指示完了通知受信部217から転送リスト管理部211に戻される。
キャンセルできた場合は、転送リスト管理部211は、転送リスト212から「PE0からの受信」エントリを削除する。そして転送リスト管理部211は、完了通知メッセージ生成部215に対して、キャンセルできた旨を伝える。
完了通知メッセージ生成部215は、「PE0⇒PE3」のキャンセルができた旨のキャンセル受諾メッセージ(キャンセル受諾通知)を生成し、PEIF14を通じてスケジューラに送信する。
キャンセルできない旨の通知を指示完了通知受信部217から伝えられた転送リスト管理部211は、完了通知メッセージ生成部215に対して、キャンセルできなかった旨を伝える。
完了通知メッセージ生成部215は、「PE0⇒PE3」のキャンセルができなかった旨のキャンセル拒絶メッセージ(キャンセル拒絶通知)を生成し、PEIF14を通じてスケジューラに送信する。
メッセージをキャンセルできた場合、スケジューラにおいて、PE3からキャンセル受諾メッセージをPEIF14経由で完了通知メッセージ受信部225が受信する。
完了通知メッセージ受信部225は、「PE0⇒PE3」のキャンセルが受諾された旨を更新転送状態生成部227に伝える。
更新転送状態生成部227は、現在転送状態2231の「PE0⇒PE3」のデータ転送を「転送中」から「未スケジュール」に変更した更新転送状態2233を生成し、転送状態比較部228にキャンセルできた旨を伝える。
転送・キャンセル指示メッセージ生成部229は、キャンセル指示メッセージを生成し、PEIF14を通じてPE0に送信する。
キャンセル指示メッセージを受信したPE0は、前述のPE3のキャンセル指示メッセージの処理と同様に処理する。この場合、PE3へのデータ転送は起こらないので、キャンセルは必ず受諾され、キャンセル受諾メッセージがスケジューラ向けて送信される。
スケジューラは、PE0からのキャンセル受諾メッセージを受信する。前述のキャンセル受諾メッセージを受信したときの処理と同様に処理が進められ、更新転送状態生成部227は、更新転送状態2233を生成する。
ここで転送状態比較部228は、現在転送状態2231と更新転送状態2233との差分を生成するが、差分がないため、処理はここで終了する。
キャンセル拒絶メッセージを受信したということは、既に「PE0⇒PE3」のデータ転送は始まっているので、「PE1⇒PE3」のデータ転送を「スケジュール待ち」に変更を行う。
更新転送状態生成部227は、現在転送状態2231の「PE1⇒PE3」のデータ転送を「転送中」状態から「スケジュール済」状態に変更した更新転送状態2233を生成し、転送状態比較部228に伝える。
転送状態比較部228は、現在転送状態2231と更新転送状態2233との差分を取り、その差が「PE1⇒PE3」の状態変化(「転送中」→「スケジュール済」)のみだとわかると、「PE0⇒PE3」のキャンセルが拒絶されたと判断する。そして、転送状態比較部228は、更新転送状態2233で現在転送状態2231を更新し、処理を終了する。
キャンセル指示メッセージの処理は以上である。前述の3)のPE3に対する「PE1⇒PE3」の転送指示メッセージ(受信指示メッセージ)の処理は、実施形態2で示した通りであるので省略する。
以上の処理により、「PE0⇒PE3」がキャンセルできた場合は、目標である図6のように、キャンセルできなかった場合は図10のようになる。
また、プロセッサ間通信制御方式が実践されるマルチプロセッサシステムにおいて行われる処理は、各プロセッサが異なる処理を行うタスク並列処理、幾つかのプロセッサで同等の処理を異なるデータに対して行うデータ並列処理、等の処理の内容には影響されない。
また、図1では6つのPEの例を示したが、プロセッサの数を限定するものではない。
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(又はCPUやMPU等)がプログラムを読み出して実行する処理である。
Claims (6)
- 複数のプロセッサと、前記プロセッサの間でのデータ転送のスケジュールを行うスケジューラと、を含むシステムにおけるプロセッサ間通信制御方法であって、
プロセッサが、前記スケジューラに対して他のプロセッサとの間のデータ転送に関する要求を発行する要求発行ステップと、
プロセッサが、前記スケジューラから他のプロセッサとの間のデータ転送に関する指示の受け付けを行う指示受付ステップと、
プロセッサが、前記スケジューラに対して他のプロセッサとの間のデータ転送に関する通知を発行する通知発行ステップと、
プロセッサが、前記指示に応じてプロセッサ間のデータ転送を開始する開始ステップと、
前記スケジューラが、プロセッサより前記要求を受信する要求受信ステップと、
前記スケジューラが、プロセッサより前記通知を受信する通知受信ステップと、
前記スケジューラが、前記受信した要求、又は前記受信した通知に基づいて、プロセッサ間のデータ転送に関わる衝突がなく、かつ、より多くのプロセッサ間のデータ転送を行うように、スケジューリングを行い、スケジューリングの結果に基づき、プロセッサに対して指示を発行する指示発行ステップと、
を含み、
前記指示発行ステップでは、前記スケジューラが、前記要求が転送要求である場合、前記転送要求に基づいて、転送要求を受けた複数のデータ転送のうち最も多くのプロセッサ間のデータ転送を行うように、転送指示を発行していないものについて、転送指示を出すか否か決定し、転送指示を出すと決定した場合、該当するプロセッサに対して前記転送指示を発行することを特徴とするプロセッサ間通信制御方法。 - 前記指示のひとつは転送指示であり、
前記開始ステップでは、前記プロセッサが、前記転送指示を受信した順番に、先行する転送指示によるデータ転送の完了後、次のデータ転送を開始することを特徴とする請求項1記載のプロセッサ間通信制御方法。 - 前記指示のひとつは転送指示であり、
前記要求のひとつは他のプロセッサとの間でデータ転送が必要であることを示す転送要求であり、
前記通知のひとつは前記転送指示によるデータ転送が完了したことを表わす完了通知であり、
前記指示発行ステップでは、前記スケジューラが、前記転送要求、又は前記完了通知を受信するたびに再びスケジュールを行い、プロセッサに対して追加の指示を発行することを特徴とする請求項1又は2記載のプロセッサ間通信制御方法。 - 前記指示発行ステップでは、前記スケジューラが、どちらともデータ転送のエンドポイントとなっていないプロセッサ間、どちらかがエンドポイントとなっているプロセッサ間、どちらともデータ転送のエンドポイントとなっているプロセッサ間の順に優先して、前記転送指示を発行することを特徴とする請求項1乃至3何れか1項記載のプロセッサ間通信制御方法。
- 前記スケジューラが、より多くのプロセッサ間のデータ転送を行えるか否かの判断に基づき、前記指示発行ステップで転送指示を発行したものの未だデータ転送が始まっていないと思われるデータ転送をキャンセルするよう指示するキャンセル指示を出すか否かを決定し、キャンセル指示を出すと決定した場合、該当するプロセッサに対して前記キャンセル指示を発行するキャンセル指示発行ステップを更に含み、
前記指示受付ステップでは、プロセッサが、前記キャンセル指示を受け付け、
前記通知発行ステップでは、プロセッサが、前記キャンセル指示を受け付けたデータ転送が未だ始まっていない場合、データ転送のエントリをキャンセルした上でキャンセル受諾通知を前記スケジューラに発行し、前記キャンセル指示を受け付けたデータ転送が既に始まっている場合、キャンセル拒絶通知を前記スケジューラに発行することを特徴とする請求項1乃至4何れか1項記載のプロセッサ間通信制御方法。 - 複数のプロセッサと、前記プロセッサの間でのデータ転送のスケジュールを行うスケジューラと、を含むシステムであって、
前記プロセッサは、
前記スケジューラに対して他のプロセッサとの間のデータ転送に関する要求を発行する要求発行手段と、
前記スケジューラから他のプロセッサとの間のデータ転送に関する指示の受け付けを行う指示受付手段と、
前記スケジューラに対して他のプロセッサとの間のデータ転送に関する通知を発行する通知発行手段と、
前記指示に応じてプロセッサ間のデータ転送を開始する開始手段と、
を有し、
前記スケジューラは、
プロセッサより前記要求を受信する要求受信手段と、
プロセッサより前記通知を受信する通知受信手段と、
前記受信した要求、又は前記受信した通知に基づいて、プロセッサ間のデータ転送に関わる衝突がなく、かつ、より多くのプロセッサ間のデータ転送を行うように、スケジューリングを行い、スケジューリングの結果に基づき、プロセッサに対して指示を発行する指示発行手段と、
を有し、
前記指示発行手段は、前記要求が転送要求である場合、前記転送要求に基づいて、転送要求を受けた複数のデータ転送のうち最も多くのプロセッサ間のデータ転送を行うように、転送指示を発行していないものについて、転送指示を出すか否か決定し、転送指示を出すと決定した場合、該当するプロセッサに対して前記転送指示を発行することを特徴とするシステム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012021167A JP5932373B2 (ja) | 2012-02-02 | 2012-02-02 | プロセッサ間通信制御方法及びシステム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012021167A JP5932373B2 (ja) | 2012-02-02 | 2012-02-02 | プロセッサ間通信制御方法及びシステム |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2013161184A JP2013161184A (ja) | 2013-08-19 |
JP2013161184A5 JP2013161184A5 (ja) | 2015-03-19 |
JP5932373B2 true JP5932373B2 (ja) | 2016-06-08 |
Family
ID=49173395
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012021167A Active JP5932373B2 (ja) | 2012-02-02 | 2012-02-02 | プロセッサ間通信制御方法及びシステム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5932373B2 (ja) |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002259352A (ja) * | 2001-03-01 | 2002-09-13 | Handotai Rikougaku Kenkyu Center:Kk | マルチプロセッサシステム装置 |
JP2002358292A (ja) * | 2001-06-01 | 2002-12-13 | Toshiba Corp | データ転送装置およびマルチプロセッサシステム |
JP2006058956A (ja) * | 2004-08-17 | 2006-03-02 | Nec Corp | マルチノードコンピュータシステム、マルチノード間におけるデータの転送方法及びプログラム |
-
2012
- 2012-02-02 JP JP2012021167A patent/JP5932373B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2013161184A (ja) | 2013-08-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3922070B2 (ja) | 分散制御方法及び装置 | |
CN111950988B (zh) | 分布式工作流调度方法、装置、存储介质及电子设备 | |
CN103197968B (zh) | 一种融合同步异步特点的线程池处理方法及系统 | |
CN108647104B (zh) | 请求处理方法、服务器及计算机可读存储介质 | |
Koole et al. | Resource allocation in grid computing | |
JP5039016B2 (ja) | ネットワークシステム、管理サーバ及び設定スケジューリング方法 | |
TWI633424B (zh) | 在非核心組織中之電力管理技術 | |
US20090292810A1 (en) | Message binding processing technique | |
CN103279351B (zh) | 一种任务调度的方法及装置 | |
CN108063813B (zh) | 一种集群环境下密码服务网络并行化的方法与系统 | |
JP2004302748A (ja) | 分散型資源管理システムおよび分散型資源管理方法並びにプログラム | |
CN106776395B (zh) | 一种共享集群的任务调度方法及装置 | |
CN103814557A (zh) | 排队消息的并发处理 | |
CN101179553A (zh) | 用于并行消息的有效保序传递的方法和装置 | |
CN107092521A (zh) | 一种分布式任务调度方法、装置及系统 | |
CN110955501B (zh) | 服务请求处理方法、装置、电子设备及可读介质 | |
CN111240806B (zh) | 一种分布式容器镜像构建调度方法 | |
CN111221662B (zh) | 任务调度方法、系统及装置 | |
JP4912927B2 (ja) | タスク割当装置、及びタスク割当方法 | |
CN108063653B (zh) | 一种时延控制方法、装置及系统 | |
CN112540605A (zh) | 多机器人协作通关方法、服务器、机器人及存储介质 | |
CN111913793A (zh) | 分布式任务调度方法、装置、节点设备和系统 | |
EP2913981B1 (en) | Image forming system, relay server, communication controlling method and non-transitory computer readable recording medium | |
JP5932373B2 (ja) | プロセッサ間通信制御方法及びシステム | |
US20130185726A1 (en) | Method for Synchronous Execution of Programs in a Redundant Automation System |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20150128 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20150128 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20151027 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20151208 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20160203 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20160405 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160428 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 5932373 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |