JP3639366B2 - アドレス空間共有システム - Google Patents
アドレス空間共有システム Download PDFInfo
- Publication number
- JP3639366B2 JP3639366B2 JP31017495A JP31017495A JP3639366B2 JP 3639366 B2 JP3639366 B2 JP 3639366B2 JP 31017495 A JP31017495 A JP 31017495A JP 31017495 A JP31017495 A JP 31017495A JP 3639366 B2 JP3639366 B2 JP 3639366B2
- Authority
- JP
- Japan
- Prior art keywords
- thread
- stack
- address
- space
- address space
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Multi Processors (AREA)
Description
【発明の属する技術分野】
本発明は,複数のプロセッサが協調して処理を進める並列分散処理システムにおいて,複数のプロセッサまたはスレッドがアドレス空間を共有して動作するアドレス空間共有システムに関する。
【0002】
現在の並列分散処理の環境は,それ自身の複雑さおよび並列処理のためのプログラミングの困難さから一部の専門家の独占物となってしまっているが,単一のCPUによる処理のボトルネックが顕在化している現在,一般の計算機ユーザにも容易で高性能な並列処理を可能とする環境の提供が急務となっている。
【0003】
【発明が解決しようとする課題】
複数のプロセッサが協調して処理を進める並列処理分散システム,特に,LAN,WAN環境でヘテロジーニァスな複数のプロセッサを1クラスタとして協調させながら一つのタスクを並列分散処理させるようなシステム環境が考えられている。このような並列処理環境を一般ユーザに提供する際に問題となるのは,簡易性と習得のし易さとであるが,これは性能との間にトレードオフの関係を生ずる。
【0004】
従来の技術水準では,性能のために簡易性をかなりの程度犠牲にするか,または簡易性のために大幅な性能の低下を甘受せざるを得ない。
性能に関し,プロセッサ間のデータ転送の遅延とスループットが問題になるが,これは,本質的にはデータ転送の遅延の問題に還元できる。並列度の高い計算では,転送するデータの単位が小さく,転送量に関係のない転送回数だけに依存する遅延が主だからである。転送回数に依存する遅延を全体として減らすためには,転送するデータをある程度バッファに蓄積しておいて,まとめて一度に転送する必要があるが,このバッファの大きさをどの程度にすると最適であるのかは,因子が複雑に絡み合っているため,事実上実験してみないことには分からない。
【0005】
また,プログラムを並列実行するためには,それを並列実行の単位に分割しなければならない。しかし,より小さな単位に分割すればそれだけ多くのCPUが利用可能になる代わりに,実行の単位が小さくなることによる同期のオーバヘッド,コンテキスト・スイッチの増加によるオーバヘッド,データの遅延,データ転送量の増加,メモリのフラグメンテーションによるページングの増加等を招くことになり,ここでもまた,トレードオフを生じる。
【0006】
エンドユーザに対しても並列処理によるプログラムの高速化,大規模化のメリットを享受できるようにすることが望まれているが,現状では,ある程度の性能を得るためには,エンドユーザにもエキスパート・ユーザの持つ並列処理の煩雑なノウハウを獲得してプログラムのチューニングをしてもらわなければならないという矛盾に直面する。
【0007】
これらの解決の手段として,従来,並列処理のための高級言語,例えば,手続き型として,Occam(A.Burns, PROGRAMMING IN occam 2, Addison-Wesley,1988), HPF(High Performance Fortran Forum, High Performance Fortran Language Specification, 1994),関数型として,CLEAN(R.Plasmeijer and M.van Eekelen, Functional Programming and Parallel Graph Rewriting, Addison-Wesley,1993),論理型として,PARLOG(T.Conlon, Programming in PARLOG, Addison-Wesley,1989)のような高級言語が開発されている。
【0008】
また,高レベルのライブラリ・インタフェースとして,例えばPVM(A.Geist,A.Beguelin,J.Dongarra,W.Jiang,R.Manchek and V.Sunderam, PVM:Parallel Virtual Machine - A Users' Guide and Tutorial for Networked Parallel Computing -, MIT press,1994 ),MPI(Message Passing Interface Forum, MPI: A Message-Passing Interface Standard, May 5,1994)が開発されている。
【0009】
しかし,高級言語では十分な性能がでないか,性能を出すためにはエキスパート並みのノウハウが必要であり,また,高レベルのライブラリは,未だにエンドユーザが使えるようなレベルに達していない。
【0010】
他の中間的な解決手段として,比較的低レベルの手続き型の逐次言語と並列処理のための命令言語を組み合わせる方法(I.Foster, R.Olson and S.Tuecke, Productive Parallel Programming, Scientific Programming, Vol.1,pp.51-66, 1992; L.A.Crowl and T.J.LeBlanc, Parallel Programming with Control Abstraction, ACM Transactions on Programming Languages and Systems, Vol.16,No.3,pp.524-576, 1994)が提案されている。
【0011】
これらの方法は,全ての面にわたってエンドユーザであるのではなく,逐次処理のエキスパートであるが並列処理に関しては比較的エンドユーザに近い人を対象として,低レベルの逐次言語のチューニングと並列処理のチューニングとを分離し,並列処理のインタフェース部分だけに簡易で画一化されたチューニング・スタイルを導入するものである。
【0012】
本発明が対象とするシステムは,後者の考え方にもとづくものであるが,並列処理インタフェース部分のさらなる画一化とエキスパート・ユーザのための汎用性とを推進し,逐次処理部分とのインタフェースに柔軟性を持たせるために,全体を手続き型言語の意味論で統一することを図っている。
【0013】
例えば,以上のような並列分散処理システムのもとでの,ネットワーク上のワークステーション群,あるいは専用のマルチCPUの並列計算機上で並列プログラムを実行するとき,共有メモリ機構(仮想共有メモリ機構を含む。以下同様。)を使用して全てのCPUに共有するアドレス空間(実アドレス空間または論理アドレス空間)を構成する方法は,単一のCPUを使用したプログラミングに最も近い並列プログラミングを可能とする方法として知られている。また,スタックその他,各種のバッファ等のアドレス空間は,他のCPUと共有させる必要はないので,全てのアドレス空間を共有させるのではなく,アドレス空間の一部を各CPUにローカルになるようにする方法もある。
【0014】
これらの方法の処理モデルは,複数のスレッドと呼ばれる計算主体が,それぞれ共有するアドレス空間の中で,ときに同期を取りながら相互に並列に処理を進めるものである。各スレッドは,自分専用のスタックを使用し,他のスレッドと共有するアドレス空間上で,CPUを排他的に使用して処理を進める。すなわち,スレッドは,自分専用のデータ領域あるいは一時的なデータをスタック上に確保してCPUの演算に使用したり,他のスレッドにCPU使用権を明け渡す時にCPUのレジスタの中身を自分のスタック上に退避し,次にCPU使用権が自分に明け渡された時に,退避しておいたレジスタの中身を元に戻すことにより,スレッド毎のCPUの状態の一貫性を保持する。
【0015】
このように,スタック空間は各スレッド毎の専用空間の集まりであるのに,全てのCPUで共有されてしまうと,あるCPUのスレッドが使用しているために他のCPUには自分で使えないメモリのアドレス空間が多くできてしまうという問題が生じる。
【0016】
また,ローカルなアドレス空間にスタックを置く方式の場合でも,スレッドを他のCPUに移動させるときに,前と同じアドレス空間にスタックを配置しなければならないので,スレッドが移動可能である場合には,実際上,スタックを(仮想)共有アドレスに配置しなければならず,アドレス空間の利用効率が悪くなってしまう。
【0017】
図5は,以上の従来技術の問題点説明図である。
図5(A)に示すように,CPUiで実行していたスレッドAを他のCPUjに移動させて,CPUj上でスレッドAの実行を継続する場合,CPUjのアドレス空間においても,CPUiのアドレス空間のスレッドA用スタックと同じ位置にスタックを配置する必要がある。しかし,すでに他のスレッドC用スタックがその位置にある場合には,アドレスの衝突が生じるので,スレッドの移動が不可となる。
【0018】
スレッドAを移動可能にするには,例えば図5(B)に示すように,あらかじめスタックのアドレス空間に全てのスレッド用のスタックが重なることのないように,領域をリザーブしておく必要が生じ,アドレス空間という重要な資源を無駄に使用することになってしまう。
【0019】
本発明は上記問題点の解決を図り,共有メモリ・システムにおいて,スレッドまたはプロセスが移動しても,スタック等のアドレス衝突が起きないようにし,これによってアドレス空間の有効利用を可能にすることを目的とする。
【0020】
【課題を解決するための手段】
本発明では,アドレス空間を共有空間と他のCPUに共有されないローカル・アドレス空間に分け,さらにローカル・アドレス空間中にスタック・アドレス専用のスタック空間を構成する。そして,CPUからのスタック空間以外のアドレスへのメモリアクセスに対してはアドレス変換を行わず,スタック空間のアドレスのメモリへのアクセスに限り,自動的にアドレスを原点からのオフセットに変換して,専用のレジスタ(スタック・ベース・レジスタ:sbr)の中身を足し合わせるようにする。
【0021】
図1は,本発明の構成例を示す図である。
例えば,図1(A)に示すように,ネットワーク10で結合された複数のプロセッサ11,11’上でプロセッサ使用権を得る計算主体である複数のスレッド13a〜13dが動作するシステムにおいて,各プロセッサ11,11’のメモリのアドレス空間を,複数のスレッドが共有する第1のアドレス空間と,スレッド間で共有しない第2のアドレス空間とに分割して構成する。なお,ここでは,プロセッサ使用権を得る計算主体をスレッドとして説明するが,この計算主体がプロセスであっても,本発明を同様に適用することができる。
【0022】
各プロセッサ11,11’は,スレッドがメモリにアクセスする際に指定したアドレス(これをCPUアドレスという)の一部を,他のアドレス(これを論理アドレスという)に変換するCPUアドレス/論理アドレス変換回路12,12’を備える。
【0023】
CPUアドレス/論理アドレス変換回路12,12’は,例えば図1(B)に示すような,空間判別回路14,ベース・レジスタ15,加算回路16,アドレスレジスタ17からなる回路である。
【0024】
空間判別回路14は,スレッドからのメモリアクセス要求が,アドレス空間中の共有アドレス空間(例えばスタック空間以外の空間)に対するものであるか,またはスレッド間で共有しないアドレス空間(例えばスタック空間)に対するものであるかを判別する回路である。
【0025】
ベース・レジスタ15は,スレッド間で共有しない空間を相対アドレス空間とするためのベース・アドレスを保持する手段であって,例えばスレッドごとのスタックのオフセット値であるスタック・ベース・アドレスを保持する。加算回路16は,アクセス要求がスタック空間等のスレッド間で共有しない空間に対するものである場合に,ベース・レジスタ15に保持したベース・アドレスを,アクセス要求のアドレスに加算する回路である。
【0026】
アドレスレジスタ17は,CPUアドレスがスタック空間等の非共有空間を示すとき,加算回路16でベース・アドレスを加算したアドレスを保持し,またCPUアドレスが共有空間を示す場合には,そのCPUアドレスをそのまま保持し,それを論理アドレスとして出力する。
【0027】
このCPUアドレス/論理アドレス変換回路12,12’によって,図1(C)に示すように,CPUアドレス空間での各スレッドのスタック空間の位置は,論理アドレス空間ではアドレスの原点からベース・レジスタ15の値sbrが加算された位置へ移動可能となり,アドレスの衝突を回避することが可能となる。
【0028】
【発明の実施の形態】
本システムでは,並列化が容易で高性能な実行環境を提供するために,例えばネットワーク化されたヘテロジーニァスなクラスタ上で,実行中の任意のスレッド(またはプロセス)を適度に移動(マイグレート)させながら全体の処理を進めることを可能にすることと,ネットワーク上のプロセス間を高速なストリーム通信で結び付けることを実現する。
【0029】
すなわち,あるプロセスが通信の応答を待っている時間にCPUを他のプロセスの処理に割り当てることで,CPUの利用効率を上げると共に他のプロセスの実行による通信をも時間的にオーバラップさせて全体として平均した場合の通信のレイテンシを低下させることを可能とするシステムの提供を図る。
【0030】
このようなヘテロジーニァスな計算機環境での柔軟な対応のために計算機に依存しない仮想コード(中間コード)方式を採用するとともに,さらに,任意の時点でのスレッド(プロセス)・マイグレーションを可能とするために仮想共有メモリ機構を採用する。
【0031】
(1)仮想コード方式
本システムでは,仮想コードとこの仮想コードのインタプリタとをネットワーク上に複数分散配置して,仮想共有メモリ上のリモート・メモリへのアクセスを高速な通信に変換しながら処理を進める。
【0032】
仮想コードは,必要なときにサーバ間で転送することもできるが,仮想コードを予め各サーバに保持させて,移動の度の転送を不要とすることもできる。他のCPUのヒープ領域へのアクセスは,プロセスの実行中に毎回トラップしてその都度データをセル単位で転送する。したがって,この場合には,スレッドの移動時に仮想コードとヒープ領域のデータを転送する必要がなく,プロセスのスタック領域と仮想コードのインタプリタが使用する数個のレジスタの中身だけを転送すればよい。
【0033】
(2)仮想共有メモリ
ここで,スタック領域も仮想共有メモリの機構で管理すれば移動時に転送する必要はないが,スタックにアクセスできるのは,それを使用して処理を進めるプロセスだけであるので,仮想共有メモリを使用すると全てのサーバ上にメモリ空間をリザーブしてしまい,全サーバで利用可能なローカル・メモリ量が小さくなってしまう。また,仮想共有メモリのオーバヘッドもあるため効率が低下してしまう。
【0034】
プロセスの実行途中での動的な移動を可能とするためには,仮想コードをネットワーク上でポジション・インデペンダントにしておく必要がある。そのためには,仮想コードに表れる全てのメモリ・アドレスを仮想的に全ての計算機で共有させることが必要である。オペレーティング・システム(OS)のレベルでサポートするためには,大掛かりな仕組みの仮想共有メモリ(D.Lenoski,J.Laudon,K.Gharachorloo,A.Gupta,J.Hennessy, The Directory-Based Cache Coherent Protocol for the DASH multiprocessor, IEEE Proceedings of the 17th Annual International Symposium on Computer Architecture, pp.148-159, 1990)を採用しなければならない。
【0035】
本システムでは,任意の時点でサーバ間でスタックを移動できるようにするために,仮想コードの設計時に,仮想スタック・アドレス空間を仮想コードの内部レジスタであるスタック・ベース・レジスタ(sbr)を用いて相対アドレス化する。つまり,実際の計算機上では任意の時点でスタックの中身を別のアドレスにコピーし,そのアドレスの先頭をスタック・ベース・レジスタにセットすることにより,矛盾なく実行が継続できるようにする。
【0036】
すなわち,仮想コード領域は,各計算機上で最初のプロセスが動き出す直前にリザーブされたメモリ空間にオンデマンドで全体を一度にコピーすればよい。他のライトを伴うメモリ空間およびヒープ領域は,セルという可変長のライト・ワンスのメモリ単位で管理し,この限定されたセルへのアクセスに関してのみ仮想共有メモリを構築している。
【0037】
したがって,インタプリタが内部的に利用するメモリ空間,プロセスのスタック空間,ストリームのバッファ等はすべてローカルな計算機上に取ることができるので,仮想共有メモリが扱わなければならない対象であるセル空間はかなり小さい。しかも,セルは,ライト・ワンスなので,セル・データのキャッシュのコヒーレンスを保つ仕組みが省略でき,一度作られたセルのキャッシュを恒久的なローカルなデータとして,キャッシュのコヒーレンスを保つ仕組みのコストなしに保持することができる。これにより,仮想共有メモリ機構を用いることによるオーバヘッドを減少させることができる。
【0038】
図2は,CPUのアドレス空間を仮想メモリ機構が使用する論理アドレスに変換する処理を説明する図である。
図2において,スタック空間以外のCPUアドレスxであるAは,そのまま論理アドレスxのA’に変換され,スタック空間のCPUアドレスであるBは,一旦,原点からのオフセットyに変換された後,スタック・ベース・レジスタ(sbr)の値を足され,論理アドレス(sbr+y)に変換される。
【0039】
このように,CPU/論理アドレス変換をCPUレベルで実装するため,あらかじめアドレス変換のために最適化したアルゴリズムまたは回路を作り込むことができ,プログラムのレベルで明示的にアドレス変換を施す場合に比べ,非常に高速で,これによるオーバヘッドを非常に小さくすることができる。
【0040】
しかも,この小さなオーバヘッドのコストを払うことにより,CPUの数が増加すればするほど,CPUが有効に使用することができるアドレス空間を全体的に見て大きくすることができるというスケーラビリティを確保できる。
【0041】
【実施例】
図3は,本発明の実施例を示す図である。
ネットワーク上の複数のワークステーション(プロセッサ30,30’,…)で並列計算させるための言語を作り,そのインタプリタ用に本方式のスタック・ベース・レジスタを持つ仮想コードを設計し,それを実現している。この言語は,任意のスレッドが任意の時点で他のプロセッサに移動することが可能であるように設計されている。
【0042】
オペレーティング・システム(OS)のスレッド・スケジューラ33,33’は,プロセッサ間で通信を行いながら,各スレッドの実行制御およびプロセッサ間の移動制御を行う手段である。スレッド・スケジューラ33,33’が管理するスレッド制御テーブル34,34’には,各スレッドの実行に関する制御情報として,例えば,スレッドを識別するスレッドID,スレッド実行時間,スレッド実行権,そのスレッドが割り当てられているプロセッサ(CPU)番号,どのようなときにスレッドのマイグレーションを行うかについての移動条件,スタック・ベース・レジスタ(sbr)の値,スタック・ポインタ(sp)の値等が格納されている。スレッド制御テーブル34,34’は,プロセッサ30,30’がスレッドの実行スケジューリングを行うとき,他のプロセッサへのスレッドの転送を行うときに,登録,更新,削除される。
【0043】
図3は,プロセッサ30のスレッドAがプロセッサ30’へ移動するところを示している。ここで,スレッドAは,プロセッサ30上ではアドレス空間31のスレッド・スタックAを使用しているが,移動先のプロセッサ30’のアドレス空間31’では,既にスレッドCがスレッド・スタックAのアドレスを使用しているので,従来の方式では,スレッド・スタックAを移動させることができない状態である。
【0044】
しかし,本方式の場合,プロセッサ30上のスレッドAは,sbrというスタック・ベース・レジスタの値を持っており,これによってスタック専用のアドレス空間を相対化している。したがって,スレッドAをプロセッサ30からプロセッサ30’に移動させたときに,プロセッサ30’上でスタック・ベース・レジスタの値をスレッド・スタックCに重ならないようにsbr’に変えることにより,スレッドAはプロセッサ30’上でスレッド・スタックAを問題なく使用することができる。
【0045】
このように,アドレスの衝突時にスタック・ベース・レジスタの値の変更だけでよいのは,プロセッサのスタック空間のアドレスへのアクセスが,全てsbrに関する相対値になっているためである。また,プロセッサ上で使用されるアドレス空間と仮想メモリのアドレス空間(論理アドレス空間)とが,sbrを用いたアドレス変換を介して間接的に対応付けられていることから,プロセッサ上でロード,ストアされるアドレス,およびその他の計算に表れるアドレスが,全てプロセッサのCPUアドレスになっているためである。
【0046】
つまり,スタック・ベース・レジスタ(sbr)を使用した相対スタック・アドレス空間では,移動前と移動後とでアクセス要求元へ意識させることなく,スタックの場所を論理アドレス空間内で自由に平行移動させることができるので,OS間のネゴシエーションなしに,移動してきたスレッドのスタックを,空いている任意のスタック空間にコピーすることができる。
【0047】
以上のように,スレッドAをプロセッサ30からプロセッサ30’に移動させる場合に,スレッド・スケジューラ33は,スレッドAの移動により移動先のプロセッサ30’のアドレス空間31’でアドレスの衝突が発生するかどうかを判断することなく,スレッドAの制御情報をプロセッサ30’のスレッド・スケジューラ33’に渡し,スレッドAを移動させることができる。
【0048】
移動先のスレッド・スケジューラ33’は,スレッド・スタックAをアドレス空間31’における空きのスタック空間に割り当て,アドレス空間31’の原点からの相対値であるsbr’をスレッドAのスレッド制御情報へ設定し,実行スケジュールの契機にスレッドAにプロセッサ使用権を与えて,スレッドAを実行させる。
【0049】
なお,ここで,スタックポインタ(sp)は,スタック・ベース・レジスタ(sbr)からの相対値を保持し,スレッドの移動後もその値が保持される。
なお,図1(B)に示すCPUアドレス/論理アドレス変換回路における空間判別回路14において,受け取ったCPUアドレスがスタック空間であるかそれ以外の空間であるかを判別する方法として,本実施例では,CPUアドレスの上位2ビットが“11”の場合にスタック空間,上位2ビットが“11”以外の場合にスタック空間以外の空間と判断し,上位2ビットが“11”であって加算回路16によりベース・レジスタ15の値(sbr)を加算する際には,CPUアドレスの上位2ビットをマスクし,上位2ビットを“00”にしてから,加算している。
【0050】
この空間の判別をCPUアドレスの一部を利用して行うのではなく,例えば命令コードから得られる制御信号等を利用して行うようにしてもよい。
図4は,図3に示すスレッド・スケジューラの処理を中心とした処理フローチャートである。この処理フローチャートは,各CPU(プロセッサ)内のOSと各スレッドの処理の流れを示しており,他のCPU(OS)からのスレッドの受信(ステップS1〜S4),他のCPU(OS)へのスレッドの送信(ステップS5〜S8),自CPU内のスレッドの実行制御(ステップS9〜S15)の3つのループから構成されている。
【0051】
ステップS1では,他のCPU(OS)からのスレッドの転送要求の有無を判定する。転送要求があれば,ステップS2の処理を行い,転送要求がなければステップS5の処理へ進む。
【0052】
ステップS2では,他のCPU(OS)からスレッド・スタックを受信し,その内容をアドレス空間の空き領域にコピーする。
ステップS3では,スレッド・スタックをコピーしたアドレス空間の先頭を,そのスタック用のスタック・ベース・レジスタsbrの退避領域に設定する。この移動したスレッドのsbrの値の変更は,CPUがスタック用に確保したスタック制御テーブル上のsbr用領域に書き込むことで実行する。
【0053】
ステップS4では,他のCPU(OS)から転送されたスタックを用いるスレッドの制御情報を受信し,スレッド制御テーブルに設定する。その後,ステップS1へ戻る。
【0054】
ステップS5では,各スレッドについて,スレッド制御テーブルにおける移動条件をチェックし,移動するスレッドを決定する。
ステップS6では,移動条件を満足するスレッドが存在するかどうかを判定し,存在する場合にはステップS7の処理を行い,存在しない場合はステップS9の処理へ進む。
【0055】
ステップS7では,他のCPU(OS)へ移動条件に合致したスレッドのスレッド・スタックを転送する。
ステップS8では,他のCPU(OS)へ転送したスタックのスレッドの制御情報をスレッド制御テーブルから転送し,スレッド制御テーブルにおけるその情報を消去する。その後,ステップS5へ戻る。
【0056】
ステップS9では,実行するスレッドを決定する。
ステップS10では,実行するスレッドが存在するかどうかを判定する。存在する場合にはステップS11の処理を行い,実行可能な状態にあるスレッドが存在しない場合には,ステップS1へ戻る。
【0057】
ステップS11では,スタック・ベース・レジスタ(sbr)の値を,実行するスタックのスタック制御テーブルから得て,スタック・ベース・レジスタに設定する。
【0058】
ステップS12では,スタックに退避してあったその他のレジスタの中身を戻し,そのスレッドへコンテキスト・スイッチを行ってCPU使用権を与える。
ステップS13では,スレッドを実行する。
【0059】
ステップS14では,スレッドの実行を停止または中断する事象の発生により,レジスタのスタックへの退避とOSへのコンテキスト・スイッチを行う。
ステップS15では,スレッド制御テーブルへのスタック・ベース・レジスタ(sbr)の値を退避し,また,スレッド実行時間などのスレッド制御テーブルの更新を行う。
【0060】
以上のように,本システムは,▲1▼CPU内にスタックへのアクセスを,相対的なアドレスで行わせる専用のベース・レジスタを設けること,▲2▼ネットワーク上で結合された計算機群または並列計算機で,(仮想)共有メモリ機構を使うとき,(仮想)共有メモリの対象にならないローカル・メモリ空間にスタック専用の相対アドレス空間を作ること,▲3▼アドレス空間を分割し,一部に専用のベース・レジスタを使った相対アドレス空間を作ることにより,共有メモリあるいは仮想共有メモリ機構を用いるシステムにおけるローカル・メモリ空間の有効利用が可能になる。
【0061】
【発明の効果】
以上説明したように,本発明によれば,スタック空間をプロセッサ(CPU)間で独立に扱うことができるので,適切にスレッドを各プロセッサに分配すると,全体として,スタック空間を(仮想)共有させた場合に可能な最大のスレッド数にプロセッサ数を掛けた数に近いスレッドを動かすことができ,より大規模な計算が可能となる。また,スレッド1個当たりのスタックの大きさをより大きくして,大きなデータをスタック上に置くことができるようになる。
【図面の簡単な説明】
【図1】 本発明の構成例を示す図である。
【図2】 本発明のCPUのアドレス処理を説明する図である。
【図3】 本発明の実施例を示す図である。
【図4】 スレッド・スケジューラの処理フローチャートである。
【図5】 従来技術の問題点を説明する図である。
【符号の説明】
10 ネットワーク
11,11’ プロセッサ
12,12’ CPUアドレス/論理アドレス変換回路
13a〜13d スレッド
14 空間判別回路
15 ベース・レジスタ
16 加算回路
17 アドレスレジスタ
Claims (1)
- 複数のプロセッサ上でプロセッサ使用権を得る計算主体である複数のプロセスまたはスレッドが動作するシステムにおいて,
メモリのアドレス空間が,複数のプロセスまたはスレッドが共有する第1のアドレス空間と,プロセスまたはスレッド間で共有しない第2のアドレス空間とに分割して構成され,
前記各プロセッサは,
プロセッサ間で通信を行いながら,各プロセスまたはスレッドの実行制御およびプロセッサ間の移動制御を行うプロセスまたはスレッドの実行スケジュール制御手段と,
前記プロセッサまたはスレッドの実行時に,そのプロセスまたはスレッドが使用するスタックの先頭アドレスを保持するベース・レジスタと,
前記プロセスまたはスレッドからのメモリアクセス要求が前記スタックに対するものであるかどうかを判別する手段と,
アクセス要求が前記スタックに対するものである場合に,アクセス要求のアドレスに前記ベース・レジスタが保持する値を加算してアドレスを変換する手段とを備え,
前記プロセスまたはスレッドの実行スケジュール制御手段は,
他のプロセッサからのプロセスまたはスレッドの転送要求に対し,他のプロセッサから受信したスタックの内容を,前記第2のアドレス空間における他のプロセスまたはスレッドのスタックと競合しない領域にコピーし,そのコピーした領域の先頭アドレスを,前記各プロセスまたはスレッドごとに設定すべきベース・アドレスとして記憶する手段と,
前記プロセスまたはスレッドの実行開始時に,前記プロセスまたはスレッドごとに記憶したベース・アドレスを前記ベース・レジスタに設定する手段とを備えた
ことを特徴とするアドレス空間共有システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP31017495A JP3639366B2 (ja) | 1995-11-29 | 1995-11-29 | アドレス空間共有システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP31017495A JP3639366B2 (ja) | 1995-11-29 | 1995-11-29 | アドレス空間共有システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09146904A JPH09146904A (ja) | 1997-06-06 |
| JP3639366B2 true JP3639366B2 (ja) | 2005-04-20 |
Family
ID=18002071
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP31017495A Expired - Fee Related JP3639366B2 (ja) | 1995-11-29 | 1995-11-29 | アドレス空間共有システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3639366B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3250729B2 (ja) | 1999-01-22 | 2002-01-28 | 日本電気株式会社 | プログラム実行装置及びそのプロセス移動方法並びにプロセス移動制御プログラムを格納した記憶媒体 |
| US7437536B2 (en) | 2004-05-03 | 2008-10-14 | Sony Computer Entertainment Inc. | Systems and methods for task migration |
| JP5076574B2 (ja) * | 2007-03-19 | 2012-11-21 | 日本電気株式会社 | メモリアクセス装置及び方法 |
| CN101226488B (zh) | 2008-01-25 | 2010-06-02 | 中兴通讯股份有限公司 | 多实例应用程序在内核态地址空间冲突的解决方法及系统 |
| JP2009199414A (ja) | 2008-02-22 | 2009-09-03 | Renesas Technology Corp | マイクロコンピュータ |
| WO2012093488A1 (ja) | 2011-01-07 | 2012-07-12 | 富士通株式会社 | スケジューリング方法、およびマルチコアプロセッサシステム |
| JP5875530B2 (ja) * | 2011-01-31 | 2016-03-02 | 株式会社ソシオネクスト | プログラム生成装置、プログラム生成方法、プロセッサ装置及びマルチプロセッサシステム |
| EP2885708A4 (en) * | 2012-08-20 | 2016-11-09 | D Kevin Cameron | PROCESSING OF RESOURCE ALLOCATIONS |
| CN113806025B (zh) * | 2020-06-12 | 2023-08-18 | 富泰华工业(深圳)有限公司 | 数据处理方法、系统、电子装置及存储介质 |
-
1995
- 1995-11-29 JP JP31017495A patent/JP3639366B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09146904A (ja) | 1997-06-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Chen et al. | GFlink: An in-memory computing architecture on heterogeneous CPU-GPU clusters for big data | |
| US8091078B2 (en) | Dynamically partitioning processing across a plurality of heterogeneous processors | |
| US7934035B2 (en) | Apparatus, method and system for aggregating computing resources | |
| CN1278235C (zh) | 用于向一处理器让与资源的系统 | |
| US5692185A (en) | Object space manager method and circuit | |
| US8307053B1 (en) | Partitioned packet processing in a multiprocessor environment | |
| US6256704B1 (en) | Task management for data accesses to multiple logical partitions on physical disk drives in computer systems | |
| US7533377B2 (en) | Achieving autonomic behavior in an operating system via a hot-swapping mechanism | |
| JPH1011372A (ja) | Cpu及びi/oデバイス間のリファレンスによるコンピュータシステムデータi/o | |
| JP2006524381A (ja) | 共有リソースの同時アクセス | |
| CN108292235A (zh) | 使用选择性资源迁移的网络附连存储器 | |
| JPH01188965A (ja) | データ処理方法 | |
| US9052957B2 (en) | Method and system for conducting intensive multitask and multiflow calculation in real-time | |
| JPH09325944A (ja) | I/oデバイス及び多重メモリ装置間のリファレンスによるコンピュータシステムデータi/o | |
| JP3639366B2 (ja) | アドレス空間共有システム | |
| JPH09288654A (ja) | 多重データソース及びシンク間のリファレンスによるコンピュータシステムデータi/o | |
| Kim et al. | DEX: scaling applications beyond machine boundaries | |
| Thitikamol et al. | Multi-threading and remote latency in software DSMs | |
| JP3546694B2 (ja) | マルチスレッド計算機システム及びマルチスレッド実行制御方法 | |
| CN113448897A (zh) | 适用于纯用户态远端直接内存访问的数组结构及优化方法 | |
| CN111949687A (zh) | 基于共享内存和多进程的分布式数据库架构及其实现方法 | |
| JPH07248949A (ja) | 入出力実行方法 | |
| JP2602241B2 (ja) | 並列計算機 | |
| JPH09288653A (ja) | Cpu間のリファレンスによるコンピュータシステムデータi/o | |
| EP4682717A1 (en) | Dynamic concurrent object-based programming model |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040113 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040315 |
|
| 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: 20050111 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050114 |
|
| R150 | Certificate of patent (=grant) or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080121 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090121 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (prs date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100121 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |