JP3632635B2 - マルチスレッド実行方法及び並列プロセッサシステム - Google Patents
マルチスレッド実行方法及び並列プロセッサシステム Download PDFInfo
- Publication number
- JP3632635B2 JP3632635B2 JP2001218158A JP2001218158A JP3632635B2 JP 3632635 B2 JP3632635 B2 JP 3632635B2 JP 2001218158 A JP2001218158 A JP 2001218158A JP 2001218158 A JP2001218158 A JP 2001218158A JP 3632635 B2 JP3632635 B2 JP 3632635B2
- Authority
- JP
- Japan
- Prior art keywords
- thread
- execution
- cache line
- processor
- execution unit
- 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
- 238000000034 method Methods 0.000 title claims description 62
- 230000015654 memory Effects 0.000 claims description 173
- 230000004044 response Effects 0.000 claims description 47
- 238000012790 confirmation Methods 0.000 claims description 11
- 238000004891 communication Methods 0.000 claims description 4
- 238000005242 forging Methods 0.000 claims 1
- 238000012545 processing Methods 0.000 description 64
- 238000013479 data entry Methods 0.000 description 38
- 238000007726 management method Methods 0.000 description 38
- 230000008569 process Effects 0.000 description 27
- 238000010586 diagram Methods 0.000 description 12
- 230000008859 change Effects 0.000 description 9
- 238000012546 transfer Methods 0.000 description 9
- 230000000694 effects Effects 0.000 description 8
- 230000015556 catabolic process Effects 0.000 description 4
- 230000007850 degeneration Effects 0.000 description 4
- 238000006731 degradation reaction Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 230000009118 appropriate response Effects 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 230000010365 information processing Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
- G06F9/3842—Speculative instruction execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
- G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Memory System Of A Hierarchy Structure (AREA)
- Multi Processors (AREA)
Description
【発明の属する技術分野】
本発明は単一のプログラムを複数のスレッドに分割して複数のプロセッサにより並列に実行する並列プロセッサシステムに関し、特にターム後で確定前のスレッドをもつプロセッサへのフォークを可能にした並列プロセッサシステムに関する。
【0002】
【従来の技術】
単一のプログラムを並列プロセッサシステムで並列に処理する手法として、プログラムをスレッドと呼ぶ命令流に分割して複数のプロセッサで並列に実行するマルチスレッド実行方法があり、この方法を記載した文献として、特開平10−27108号公報(以下、文献1と称す)、「On−Chip Multiprocessor指向 制御並列アーキテクチャMUSCATの提案」(並列処理シンポジウムJSPP97論文集、情報処理学会、pp.229−236、May 1997)(以下、文献2と称す)、特開平10−78880号公報(以下、文献3と称す)、「非数値計算プログラムのスレッド間命令レベル並列を利用するプロセッサ・アーキテクチャSKY」(並列処理シンポジウムJSPP98論文集、情報処理学会、pp.87−94、平成10年6月)(以下、文献4と称す)、「Multiscalar Processor」(G.S.Sohi,S.E.Breach and T.N.Vijaykumar,The 22nd International Symposium on Computer Architecture,IEEE Computer SocietyPress,1995,ページ414−425)(以下、文献5と称す)等がある。以下、これらの文献に記載された従来の技術について説明する。
【0003】
一般にマルチスレッド実行方法において、他のプロセッサ上に新たなスレッドを生成することを、スレッドをフォーク(fork)すると言い、フォーク動作を行った側のスレッドを親スレッド、生成された新しいスレッドを子スレッド、スレッドをフォークする箇所をフォーク点、子スレッドの先頭箇所をフォーク先アドレスまたは子スレッドの開始点と呼ぶ。文献1〜4では、スレッドのフォークを指示するためにフォーク点にフォーク命令が挿入される。フォーク命令にはフォーク先アドレスが指定され、フォーク命令の実行によりそのフォーク先アドレスから始まる子スレッドが他プロセッサ上に生成され、子スレッドの実行が開始される。また、スレッドの処理を終了させるターム(term)命令と呼ばれる命令が用意されており、各プロセッサはターム命令を実行することによりスレッドの処理を終了する。
【0004】
図15にマルチスレッド実行方法の処理の概要を示す。同図(a)は3つのスレッドA、B、Cに分割された単一のプログラムを示す。このプログラムを単一のプロセッサで処理する場合、同図(b)に示すように1つのプロセッサPEがスレッドA、B、Cを順番に処理していく。これに対して文献1〜5のマルチスレッド実行方法では、同図(c)に示すように、1つのプロセッサPE1にスレッドAを実行させ、プロセッサPE1でスレッドAを実行している最中に、スレッドAに埋め込まれたフォーク命令によってスレッドBを他のプロセッサPE2に生成し、プロセッサPE2においてスレッドBを実行させる。また、プロセッサPE2はスレッドBに埋め込まれたフォーク命令によってスレッドCをプロセッサPE3に生成する。プロセッサPE1、PE2はそれぞれスレッドB、Cの開始点の直前に埋め込まれたターム命令によってスレッドの処理を終了し、プロセッサPE3はスレッドCの最後の命令を実行すると、その次の命令(一般にはシステムコール命令)を実行する。このように複数のプロセッサでスレッドを同時に並行して実行することにより、逐次処理に比べて性能の向上が図られる。
【0005】
従来の他のマルチスレッド実行方法として、図15(d)に示すように、スレッドAを実行しているプロセッサPE1からフォークを複数回行うことにより、プロセッサPE2にスレッドBを、またプロセッサPE3にスレッドCをそれぞれ生成するマルチスレッド実行方法も存在する。この図15(d)のモデルに対して、同図(c)に示したようにスレッドはその生存中に高々1回に限って有効な子スレッドを生成することができるという制約を課したマルチスレッド実行方法をフォーク1回モデルと呼ぶ。本発明はこのようなフォーク1回モデルを前提とする。フォーク1回モデルでは、スレッド管理の大幅な簡略化が可能となり、現実的なハードウェア規模でスレッド管理部のハードウェア化が実現できる。また、個々のプロセッサは子スレッドを生成する他プロセッサが1プロセッサに限定される。このため文献1〜4では、隣接するプロセッサを単方向にリング状に接続した並列プロセッサシステムを使ってマルチスレッド実行を行っている。
【0006】
従来の並列プロセッサシステムでは、個々のプロセッサはフリー状態、ビジー状態の2種類の状態で管理される。フリー状態は、プロセッサ資源が解放されており、何時でも新たなスレッドの実行を開始できる状態である。プロセッサを単方向にリング状に接続した並列プロセッサシステムでは、或るプロセッサからフォーク要求があった場合、その隣接プロセッサがフリー状態である場合に限って子スレッドのフォークが行われる。フリー状態のプロセッサがスレッドの実行を開始するとビジー状態に遷移し、そのスレッドの実行が終了しスレッド管理部で終了許可が得られるとフリー状態に戻る。スレッド管理部で終了許可が得られることを条件としているのは、逐次的な実行順序関係を持つ複数のスレッドを並列に実行する際、子スレッドは親スレッドが終了しなければ終了できないという制約があり、この制約をスレッドの生成、終了を管理するスレッド管理部で保証するためである。
【0007】
子スレッドをフォークした場合、親スレッドから子スレッドへのレジスタ継承が必要になる。このレジスタ継承に関しては、一般に2通りの方式がある。1つは、文献1〜3の並列プロセッサシステムで採用されているように、親スレッドのフォーク時点のレジスタファイルの内容だけを継承対象とし、フォーク後に更新されたレジスタは継承しない方式である。もう1つは、文献4、5の並列プロセッサシステムで採用されているように、フォーク後に更新されたレジスタも継承対象とする方式である。前者をフォーク時レジスタ転送方式、後者をフォーク後レジスタ転送方式と呼ぶ。
【0008】
マルチスレッド実行方法では、実行の確定した先行スレッドを並列に実行することを基本とするが、実際のプログラムでは実行の確定するスレッドが充分に得られない場合も多い。また、動的に決定される依存やコンパイラ解析能力の限界等により並列化率が低く抑えられ所望の性能が得られない可能性が生じる。このためスレッド並列処理では、スレッド間の順序関係に起因するメモリ依存関係に考慮し、プログラムの正しい実行結果を保証しつつ、スレッド間の順序関係によらずにスレッドの実行を並列に行うことで、プログラム実行を高速化するというスレッド単位の非プログラム順序実行が採用されている。
【0009】
スレッド単位の非プログラム順序実行においても、正しいプログラムの実行結果を得るためには、スレッドが含む命令間の依存関係の解消や保証が必要である。しかしながら、命令単位の非プログラム順序実行と同様に、特にメモリに関する正依存関係に対しては、本質的にプログラム順序で実行する必要があり、かつ、確定的にプログラム順序実行を行うと、非プログラム順序実行の実行性能向上の効果が十分得られないという問題がある。特に、スレッド単位の非プログラム順序実行では、複数の命令からなるスレッド単位で、非プログラム順序実行が妨げられるので、より問題は深刻である。この問題への対応としては、命令単位の非プログラム順序実行と同様に、データ依存投機実行が有効である。すわなち、スレッドが含む命令間の正依存関係の有無が判明するよりも以前に、正依存関係が存在しないと仮定して、投機的にスレッドの非プログラム順序実行を行う、スレッド単位のデータ依存投機実行である。
【0010】
一方、メモリに関する逆依存関係及び出力依存関係に対しては、命令単位の非プログラム順序実行と同様に、ストア命令が書き込みを行うデータを、プロセッサに固有のバッファやメモリに一時的に格納するなどの対応で、逆依存関係あるいは出力依存関係を解消して、非プログラム順序実行することが可能となる。
【0011】
例えば、それぞれが固有のキャッシュメモリを備える複数のプロセッサから構成される並列プロセッサシステムにおけるスレッド並列処理に関して、例えば特許第3139392号公報(以下、文献6と称す)に、メモリに関する逆依存関係及び出力依存関係を解消するキャッシュメモリの制御方式が開示されている。また、メモリに関する逆依存関係及び出力依存関係に加えて、正依存関係にも対応するキャッシュメモリの制御方式の例として、S.Gopal,T.N.Vijaykumar, J.E.Smith, G.S.Sohi らによる論文 ”Speculative Versioning Cache”, In Proceedings of the 4th International Symposium on High−Performance Computer Architecture,February 1998. (以下、文献7と称す)がある。
【0012】
その他、文献2に記載のMUSCATでは、スレッド間の同期命令など、スレッドの並列動作を柔軟に制御するための専用命令が数多く用意されている。
【0013】
【発明が解決しようとする課題】
隣接するプロセッサを単方向にリング状に接続した並列プロセッサシステムはハードウェアを簡素化できる利点を有するが、スレッドの粒度が異なる場合などにプロセッサ資源を有効に利用できず、スレッドの並列度が低下するという課題がある。図16にその例を示す。同図(a)に示すように、スレッドの粒度が比較的小さく略均一であると、スレッドth0→スレッドth1→スレッドth2→スレッドth3と順次に子スレッドのフォークが行われ、最後のプロセッサPE3が子スレッドをフォークする時点で隣接プロセッサPE0がフリー状態になっている確率が高い。このため、スレッドth3から子スレッドth4をフォークできる。同様に、このスレッドth4から隣接プロセッサPE1に子スレッドth5をフォークでき、高い並列度が確保できる。しかし、例えばスレッドth0の粒度が他のスレッドに比べて大きいと、図16(b)に示すように、プロセッサPE3が子スレッドをフォークする時点で隣接プロセッサPE0はスレッドth0を実行中で未だビジー状態にあるためフォークが行えず、スレッドの並列度が低下する。
【0014】
他方、文献1の図3に示される並列化プロセッサシステムでは、複数のプロセッサを共通バスで相互に接続することにより、個々のプロセッサから子スレッドをフォークする他プロセッサを隣接プロセッサに限定しない構成を採用している。しかし、個々のプロセッサの状態をフリー状態とビジー状態で管理し、フリー状態のプロセッサの中から子スレッドをフォークするプロセッサを選択するようにしており、然も図16(b)のプロセッサPE1のように親スレッドth0が未だ終了していないスレッドth1を実行しているプロセッサはビジー状態と管理している。従って、プロセッサPE3のスレッドth3からプロセッサPE1に子スレッドをフォークすることはできない。
【0015】
また、スレッドth1が投機スレッドの場合、プロセッサPE1の資源を解放する際にスレッドth1の処理結果の取り扱いが問題となる。何故なら、スレッドth1は親スレッドth0から取り消される可能性があり、スレッドth1の処理結果をメインメモリに書き戻すことはできず、また、スレッドth2等のスレッドth1の子スレッドはスレッドth1の処理結果を引き継ぐ必要があるためスレッドth1の処理結果をキャンセルすることはできないからである。
【0016】
本発明はこのような事情に鑑みて提案されたものであり、その目的は、プロセッサ資源の有効活用が可能でスレッド並列度を高めることができる新規なマルチスレッド実行方法及び並列プロセッサシステムを提供することにある。
【0017】
【課題を解決するための手段】
本発明は、単一のプログラムを複数のスレッドに分割し複数のスレッド実行部で並列に実行するマルチスレッド実行方法及び並列プロセッサシステムにおいて、ターム後で確定前のスレッドを持つスレッド実行部の前記スレッドをその直後の子スレッドへマージし、前記スレッド実行部へ新たなスレッドをフォークすることを基本とする。より具体的には、個々のスレッド実行部を、フォーク可能なフリー状態、スレッドを実行しているビジー状態、ターム後で確定前のスレッドを持つターム状態の3つの状態で管理し、新たなスレッドをフォークする際、フリー状態のスレッド実行部が存在しない場合、ターム状態のスレッド実行部が持つスレッドをその直後の子スレッドへマージして当該スレッド実行部をフリー状態にし、新たなスレッドをフォークする。これにより、プロセッサ資源の有効活用が可能になり、スレッド並列度を高めることができる。
【0018】
ターム後で確定前のスレッドの仮実行結果の取り扱いに関しては、例えば、ターム状態のスレッド実行部が持つスレッドをその直後の子スレッドへマージする際、ターム状態のスレッド実行部の仮実行用バッファに保存されている仮実行結果を前記子スレッドを実行するスレッド実行部の仮実行用バッファへ転送することで対処する。また、より効率を高めるために、個々のスレッド実行部毎に仮実行用バッファを兼ねるキャッシュメモリを備え、前記キャッシュメモリの各キャッシュライン毎に、ターム後で確定前のスレッドが生成したデータと前記マージ後に新たに生成されたスレッドが生成したデータとを区別するバージョン情報を保持し、各スレッド実行部のキャッシュメモリは、他のスレッド実行部からのアクセスに対して、前記バージョン情報とスレッドの逐次実行順序とを考慮した選択的な応答を行うことで対処する。また、各スレッド実行部で実行されるスレッドが自身のキャッシュメモリに書き込みを行う際、書き込み対象となるキャッシュラインのバージョン情報が自スレッドのバージョンより古い場合、当該キャッシュラインのバージョンが親スレッドの終了に応じて適宜変更されて自スレッドのバージョンに一致するまで待ち合わせを行うことで対処する。
【0019】
【作用】
ターム後で確定前のスレッドを持つスレッド実行部は、従来の並列プロセッサシステムではビジー状態として管理されていたが、本発明ではターム状態として管理し、ビジー状態と区別する。そして、フリー状態のスレッド実行部が1つも存在しない場合には、ターム状態のスレッド実行部のスレッドをその直後の子スレッドへマージすることにより、当該スレッド実行部をフリー状態にし、新たなスレッドをフォークする。例えば図16(b)と同様な状況を想定した図1の実行シーケンスにおいて、プロセッサPE3が子スレッドをフォークする時点で他の全てのプロセッサPE0、PE1、PE2がビジー状態にあるため、従来の並列プロセッサシステムではフォークは行えないが、本発明では、プロセッサPE1のターム後で確定前のスレッドth1をその直後の子スレッドth2にマージすることにより、フリー状態となったプロセッサPE1にスレッドth3からスレッドth4をフォークすることが可能になる。
【0020】
【発明の実施の形態】
次に本発明の実施の形態の例について図面を参照して詳細に説明する。
【0021】
図2を参照すると、本発明の並列プロセッサシステムの一例は、4スレッド並列実行型プロセッサであり、4個のスレッド実行部1−i(i=0〜3)が第1のバス2及び第2のバス4に接続され、第1のバス2にはスレッドの生成、終了を管理するスレッド管理部3が接続され、第2のバス4には全てのスレッド実行部1−iで共有のメモリ(メインメモリ)5が接続されている。この例では、4スレッド並列実行型プロセッサを取り上げたが、8スレッドや16スレッドの並列実行型プロセッサ等、一般にn(≧2)スレッド並列実行型プロセッサに対して本発明は適用可能である。また、スレッド実行部どうしを相互に接続する通信路(バス4)は、本実施の形態では共通バス形式としたが、クロスバスイッチ等の他の種類の通信路を採用することも可能である。なお、好ましくは、全てのスレッド実行部1−iはメモリ5及びスレッド管理部3と共に1つの半導体チップ上に集積化される。
【0022】
各スレッド実行部1−iは、プロセッサを含んでいる。各プロセッサは、プログラムカウンタ(以下、PCと称す)及びレジスタファイルを独立に有し、PCに従って、メモリ5中のスレッドの命令を同時にフェッチ、解釈、実行する機能を有している。また、各スレッド実行部1−iは、スレッド実行の取り消し(キャンセル)が可能なようにスレッドを仮実行状態で実行する機能を有している。仮実行状態でスレッドを実行した際のそのスレッドの処理結果は、仮実行用バッファ(temporary buffer)に保存される。仮実行用バッファとしては、それ専用のバッファを使用する構成や、個々のプロセッサが独自に有するキャッシュメモリを仮実行用バッファとして兼ねる構成などが採用される。
【0023】
各スレッド実行部1−iは、スレッド管理部3からバス2を通じてターゲットPC値を伴うスレッド開始要求が送信された時点で、スレッドの実行を仮実行状態で開始する。この時点で当該スレッド実行部1−iはビジー状態として管理される。スレッドの実行を終了するスレッド実行部1−iは、スレッド管理部3に対してバス2を通じてスレッド終了通知を送信する。このスレッド終了通知は、当該スレッド実行部1−iが最古親スレッドを実行していた場合にスレッド管理部3で受理されて当該スレッド実行部1−iはフリー状態として管理され、プロセッサ1−iにスレッド終了許可が返却される。プロセッサ1−iはスレッド終了許可を受信した時点で仮実行状態を解き、スレッドの実行を終えてプロセッサ資源を解放する。他方、スレッド終了通知を送信したスレッド実行部1−iで実行されていたスレッドが最古親スレッドでない場合、スレッド管理部3は当該スレッド実行部1−iにスレッド終了許可を出さず、当該スレッド実行部1−iをターム状態として管理する。ターム状態のスレッド実行部1−iは、その親スレッドが全て終了するか、または当該スレッド実行部1−iのスレッドがその直後のスレッドにマージされた時点でフリー状態として管理される。
【0024】
各スレッド実行部1−iは、スレッド管理部3を通じて、実行中の親スレッドに存在するフォーク命令によって他のスレッド実行部1−j(i≠j)に子スレッドをフォークすることができる。本実施の形態では、各スレッド実行部1−iのフォーク先はその隣接するスレッド実行部にのみ限定されない。各スレッド実行部1−iは、子スレッドのフォークを行う際、バス2を通じてスレッド管理部3に対し、子スレッドのフォーク先アドレス(開始PC値)を伴うフォーク要求を送信する。スレッド管理部3は、フォーク要求を受信すると、他のスレッド実行部の状態に基づいて、他スレッド実行部1−jに対するフォークが可能か否かを判定する。その時点でフリー状態のスレッド実行部が存在していれば直ちにフォーク可能である。また、その時点でフリー状態のスレッド実行部が存在していなくてもターム状態のスレッド実行部が存在していれば、ターム状態のスレッド実行部のスレッドをその直後の子スレッドへマージすることによって、ターム状態のスレッド実行部をフリー状態にすることでフォークが可能である。
【0025】
フォーク可能ならばフォーク先のスレッド実行部1−jに対してフォーク先アドレスを伴うスレッド開始要求を送信する一方、フォーク要求元のスレッド実行部1−iに対しては、フォーク応答を返却する。フォーク応答を受信したスレッド実行部1−iは、フォーク先のスレッド実行部1−jのレジスタファイルに対して、親スレッドのレジスタファイルの全内容をバス4を通じてコピーするか、当該子スレッドで必要なレジスタの値だけをコピーすることにより、レジスタ継承を行う。他方、スレッド実行部1−iからのフォーク要求時、他スレッド実行部1−jに対するフォークが不可能ならば、スレッド管理部3はその旨を要求元のスレッド実行部1−iに通知する。スレッド実行部1−iは、例えばフォークが可能になるまで処理を待ち合わせる。
【0026】
図3を参照すると、スレッド管理部3の一例は、スレッド管理シーケンサ301とスレッド状態テーブル302とから構成される。スレッド状態テーブル302は、スレッド実行部1−iと1対1に対応する状態エントリ303−i、親スレッド実行部番号エントリ304−i及び子スレッド実行部番号エントリ305−iを有する。個々の状態エントリ303−iは、対応するスレッド実行部1−iがビジー状態か、ターム状態か、フリー状態かを記録するために使用される。個々の親スレッド実行部番号エントリ304−iは、対応するスレッド実行部1−iで実行中のスレッドの親スレッドが実行されている他スレッド実行部の番号を示す。個々の子スレッド実行部番号エントリ305−iは、対応するスレッド実行部1−iで実行中のスレッドの直後の子スレッドが実行されている他スレッド実行部の番号を示す。スレッド管理シーケンサ301は、このようなスレッド状態テーブル302を用いて各スレッド実行部1−iにおけるスレッド生成、スレッド終了を管理する。スレッド実行部1−iからフォーク要求、スレッド終了通知を受信した際のスレッド管理シーケンサ301の処理例を図4及び図5に示す。
【0027】
図4を参照すると、スレッド管理シーケンサ301は、スレッド実行部1−iからフォーク要求を受信すると、スレッド状態テーブル302を参照して、フリー状態のスレッド実行部が存在するか否かを調べる(ステップS1)。フリー状態のスレッド実行部が存在した場合、その内から1つのスレッド実行部1−jを選択し(ステップS2)、スレッド管理テーブル302を更新する(ステップS3)。具体的には、ステップS2で選択したスレッド実行部1−jに対応する状態エントリ303−jをフリー状態からビジー状態に変更し、親スレッド実行部番号エントリ304−jにフォーク要求を行ったスレッド実行部1−iの番号を設定する。また、フォーク要求を行ったスレッド実行部1−iに対応する子スレッド実行部番号エントリ305−iに、ステップS2で選択したスレッド実行部1−jの番号を設定する。そして、フォーク要求に付随するフォーク先アドレスを添えたスレッド開始要求をフォーク先のスレッド実行部1−jに送信すると共に、要求元のスレッド実行部1−iに対してフォーク応答を送信する(ステップS4)。
【0028】
他方、フリー状態のスレッド実行部が1つも存在しなかった場合(ステップS1でNO)、スレッド管理部3は、スレッド状態テーブル302を参照して、ターム状態のスレッド実行部が存在するか否かを調べる(ステップS5)。ターム状態のスレッド実行部が1つも存在しない場合、子スレッドのフォークは物理的に不可能なので、その旨をフォーク要求元のスレッド実行部1−iへ送信する(ステップS8)。一方、ターム状態のスレッド実行部が存在した場合、その内から1つのスレッド実行部1−jを選択し(ステップS6)、この選択したスレッド実行部1−jのスレッドを当該スレッドが生成した子スレッドへマージし、当該スレッド実行部1−jをフリー状態とする(ステップS7)。そして、ステップS2〜S4を実行することにより、今回フリー状態にしたスレッド実行部に対する子スレッドのフォークを可能にする。
【0029】
ステップS7の処理をより具体的に説明する。先ず、ステップS6で選択したスレッド実行部1−jに対応する状態エントリ303−jをターム状態からフリー状態に変更する。次に、子スレッド実行部番号エントリ305−jに設定されている番号で特定されるスレッド実行部1−kに対応する親スレッド実行部番号エントリ304−kに、スレッド実行部1−jに対応する親スレッド実行部番号エントリ303−jの内容を設定する。次に、親スレッド実行部番号エントリ305−jに設定されている番号で特定されるスレッド実行部1−mに対応する子スレッド実行部番号エントリ305−mに、スレッド実行部1−jに対応する子スレッド実行部番号エントリ305−jの内容を設定する。最後に、スレッド実行部1−jに対応する子スレッド実行部番号エントリ304−jをNULLにする。これにより、スレッドの管理上、スレッド実行部1−jのスレッドがその直後の子スレッド実行部へマージされたことになる。
【0030】
図3でターム状態になっているスレッド実行部1−1を例に説明すると、状態エントリ303−1をターム状態からフリー状態に変更し、子スレッドを実行しているスレッド実行部1−2の親スレッド実行部番号エントリ304−2に親スレッド実行部番号エントリ304−1の内容「0」を設定し、親スレッドを実行しているスレッド実行部1−0の子スレッド実行部番号エントリ305−0に子スレッド実行部番号エントリ305−1の内容「2」を設定し、子スレッド実行部番号エントリ305−1の内容をNULLにする。
【0031】
以上のような処理によって、スレッドの管理上はスレッド実行部1−jのスレッドがその直後の子スレッドへマージされたことになるわけであるが、スレッド実行部1−jに残っている仮実行結果の取り扱いが問題となる。この問題を解決する一つの方法は、スレッド実行部1−jの仮実行バッファの内容を、バス4を通じて、マージした子スレッドを実行しているスレッド実行部の仮実行バッファに転送して格納し、スレッド実行部1−jの仮実行バッファを解放することである。但し、この方法はデータ転送に伴うオーバヘッドが大きいため、性能低下が懸念される。他の方法は、スレッド実行部1−jの仮実行バッファにおいて、マージしたスレッドの仮実行結果と、当該スレッド実行部1−jで新たに実行される新スレッドの仮実行結果とを区別して管理し、マージしたスレッドの仮実行結果はその子スレッドに有効なデータとして扱うが、当該スレッド実行部1−jで新たに実行された新スレッドの仮実行結果はマージしたスレッドから当該新スレッドまでの間のスレッドでは無効なデータとして扱う方法である。この後者の方法については後に詳細な実施例を挙げて説明する。
【0032】
図5を参照すると、スレッド管理シーケンサ301は、何れかのスレッド実行部1−iからスレッド終了通知を受信すると、スレッド状態テーブル302における当該スレッド実行部1−iに対応する親スレッド実行部番号エントリ304−iがNULLにクリアされているか否かによって、当該スレッド実行部1−iで実行中のスレッドの親スレッドが存在しているか否かを判定する(ステップS11)。親スレッドが存在している場合、当該スレッド実行部1−iに対応する状態エントリ303−iをビジー状態からターム状態に更新する(ステップS12)。
【0033】
他方、親スレッドが存在していない場合、ステップS13でスレッド状態テーブル302を更新する。ここでは、当該スレッド実行部1−iに対応する状態エントリ303−iをビジー状態からフリー状態に変更し、その子スレッド実行部番号エントリ305−iがNULLでなければその値で特定される子スレッドを実行しているスレッド実行部1−jに対応する親スレッド実行部番号エントリ304−jをNULLにクリアし、子スレッド実行部番号エントリ305−iもNULLにクリアする。また、親スレッド実行部番号エントリ304−jをNULLにしたスレッド実行部1−jの状態エントリ303−jがターム状態なら、このスレッド実行部1−jもフリー状態にする。具体的には、状態エントリ303−jをフリー状態に設定し、その子スレッド実行部番号エントリ305−jがNULLでなければその値で特定される子スレッドを実行しているスレッド実行部1−kに対応する親スレッド実行部番号エントリ304−kをNULLにクリアし、子スレッド実行部番号エントリ305−kもNULLにクリアする。以下、同様に親スレッドの終了によりフリー状態にできる全てのスレッド実行部をフリー状態に変更する。そして、次のステップS14では、フリー状態に変更した全てのスレッド実行部に対してスレッド終了許可を送信する。
【0034】
例えば図3で、スレッド実行部1−0からスレッド終了通知が出された場合、状態エントリ303−0がフリー状態に変更され、子スレッドを実行していたスレッド実行部1−1の親スレッド実行部番号エントリ304−1がNULLに設定される。また、状態エントリ303−1がターム状態なので、状態エントリ303−1がフリー状態に変更され、子スレッドを実行しているスレッド実行部1−2の親スレッド実行部番号エントリ304−1がNULLに設定される。この場合、スレッド終了通知は、スレッド実行部1−0とスレッド実行部1−1に送信される。
【0035】
以上のように本実施の形態によれば、個々のスレッド実行部をフリー状態、ビジー状態、ターム状態の3つの状態の何れかで管理し、何れかのスレッド実行部から子スレッドのフォークが要求されたとき、フリー状態のスレッド実行部が存在しなければ、ターム状態のスレッド実行部で実行終了しているが未確定のスレッドをその直後の子スレッドにマージすることによりフリー状態のスレッド実行部を動的に生成し、そのスレッド実行部に対するフォークを可能にしたことにより、プロセッサ資源の有効活用が可能になり、スレッド並列度を高めることができる。
【0036】
次に、直後の子スレッドへマージされたスレッドの仮実行結果を効率良く扱うことができる実施例について詳細に説明する。なお、以下では、実行は終了しているが親スレッドが未だ終了していない等により処理が確定していないスレッドのことを、term後で確定前のスレッドと呼ぶ。また、term後で確定前のスレッドをもつプロセッサへのフォークを、空きフォークと呼ぶ。空きフォークは、term後で確定前のスレッドを直後の子スレッドへマージし、該フォークによる新スレッドを実行することである。
【0037】
〔キャッシュメモリにおける問題点〕
先ず、個々のプロセッサが固有に備えるキャッシュメモリを仮実行用バッファとして兼用する場合の問題点を、スレッド実行シーケンス例を示す図6を参照して説明する。図6は以下のような実行シーケンスを示している。
【0038】
(1)プロセッサP0上のスレッドからプロセッサPiにスレッドth0がフォークされ、このスレッドth0からスレッドc00、c01、…、c0nが順次に複数の他プロセッサ上にフォークされる。スレッドc00〜c0nは、スレッドth0から見て子スレッドである。
(2)スレッドc0nのフォーク時、プロセッサPiではスレッドth0はタームしているが、親スレッドがタームしていないので、スレッドth0はterm後で確定前のスレッドである。このため、スレッドth0が直後の子スレッドc00にマージされ、このマージによりフリー状態となったプロセッサPiにスレッドc0nから新スレッドth1がフォークされている。以後、この新スレッドth1からスレッドc10、c11、…、c1nが順次にフォークされる。スレッドc10〜c1nは、新スレッドth1から見て子スレッドである。
(3)スレッドc1nのフォーク時、プロセッサPiではスレッドth1はタームしているが、親スレッドがタームしていないので、スレッドth1はterm後で確定前のスレッドである。このため、スレッドth1が直後の子スレッドc10にマージされ、このマージによりフリー状態となったプロセッサPiにスレッドc1nから新スレッドth2がフォークされている。以後、この新スレッドth2からスレッドc20、c21、…、c2nが順次にフォークされる。スレッドc20〜c2nは、新スレッドth2から見て子スレッドである。
(4)スレッドc2nのフォーク時、プロセッサPiではスレッドth2はタームしているが、親スレッドがタームしていないので、スレッドth2はterm後で確定前のスレッドである。このため、スレッドth2が直後の子スレッドc20にマージされ、このマージによりフリー状態となったプロセッサPiにスレッドc2nから新スレッドth3がフォークされている。
【0039】
このようなシーケンスが実行されている場合、term後で確定前のスレッドth0が生成しプロセッサPiのキャッシュメモリ上に格納されているデータは、スレッドth0の子スレッドc00〜c0nにとって有効である。しかし、空きフォークにより生成されたスレッドth1が生成しプロセッサPiのキャッシュメモリ上に格納されているデータは、スレッドth0からスレッドth1までのスレッドth0の子スレッドc00〜c0nに対しては、プログラム順序で後であるため、有効ではない。従って、スレッドth0が生成したデータとスレッドth1が生成したデータは、スレッドc00〜c0nがすべてタームするまで区別する必要がある。同様にスレッドth2、th3が生成したデータの区別も必要である。
【0040】
しかし、例えばスレッドth0は確定前なので、スレッドth0が生成したデータをメインメモリへ書き戻すことはできない。また、スレッドth0が生成したデータを直後の子スレッドc00を実行するプロセッサのキャッシュメモリへ転送し格納する方法では、そのオーバヘッドは大きく、性能低下等が発生するという問題がある。
【0041】
〔解決する手段〕
そこで、本実施例ではこの問題を以下のようにして解決する。
1.同一キャッシュ上でデータの複数のバージョンを区別し保持する。そのために、キャッシュライン毎にバージョンを示す記憶手段(vid)を備え、キャッシュライン毎にバージョンを管理する。新しいバージョンは、空きフォークにより生成されて現在実行しているスレッドがストア命令等で書き込みを行った場合に発生する。それ以外では発生しない。例えば、プロセッサPiのキャッシュ上に、スレッドth0が生成したバージョン、スレッドth1が生成したバージョン、…、を区別して保持する。
【0042】
2.他プロセッサ(他スレッド) からのアクセスに対して、バージョンを参照して、スレッド順序を考慮した選択的な応答を行う。例えば、スレッドth0からスレッドth1までのスレッドth0の子スレッドc00〜c0nからのアクセスには、スレッドth0のバージョンのキャッシュラインは応答するが、スレッドth1以降のバージョンのキャッシュラインは応答しない。スレッドth1からスレッドth2までのスレッドth1の子スレッドc10〜c1nからのアクセスには、スレッドth0,th1のバージョンのキャッシュラインは応答するが、スレッドth2以降のバージョンのラインは応答しない。
【0043】
3.バージョンの区別が不要になった際にバージョンの縮退を行う。例えば、スレッドth0からスレッドth1までのスレッドth0の子スレッドc00〜c0nがすべてタームしたら、スレッドth0のバージョンとスレッドth1のバージョンの区別は不要なので、その時点でスレッドth0とスレッドth1のバージョンを縮退する。
【0044】
4.バージョンを参照した選択的なスレッド(データ) の確定を行う。例えば、スレッドth0が確定した場合、スレッドth0のバージョンのキャッシュラインのみを確定する。スレッドth1,th2のバージョンのラインは未確定(投機) のままである。
【0045】
5.同アドレスで異なるバージョンのキャッシュラインの生成については、以下の3通りの方式の何れかで対処することができる。
a);同アドレスで異なるバージョンのキャッシュラインの生成を許可する。
この場合、バージョンの縮退時に複数の(同バージョンで) 同アドレスのラインが発生してしまう場合がある。そのため縮退時に、縮退の対象のバージョンのうち、古いバージョンのラインを無効化する処理を行う。
b);同アドレスで異なるバージョンのキャッシュラインを生成しない。
空きフォークにより生成されたスレッドが書き込みを行う際に、その対象のラインが古いバージョンをもち、かつ自プロセッサが前に書き込みを行ったライン(dirty なライン)の場合、前記古いバージョンが現在のバージョンに縮退されるまで書き込みの実行を遅らせて、複数のバージョンの発生を回避する。
c);bと同様に同アドレスで異なるバージョンのキャッシュラインを生成しないが、空きフォークにより生成されたスレッドが書き込みを行う際に、その対象のラインが古いバージョンをもつdirty なラインの場合、該ラインを直後の子スレッドを実行するプロセッサのキャッシュメモリに転送後、該ラインを無効化し、その後書き込みを実行することで、複数のバージョンの発生を回避する。
d);bと同様に同アドレスで異なるバージョンのキャッシュラインを生成しないが、空きフォークにより生成されたスレッドが書き込みを行う際に、その対象のラインが古いバージョンをもつdirty なラインの場合、そのまま書き込みを実行するとともに、前記古いバージョンのデータを破棄したこと記憶しておくことで、複数のバージョンの発生を回避する。前記破棄した古いバージョンのデータに対して、他のプロセッサからアクセスがあった場合には、前記破棄した古いバージョンのデータを生成したスレッド及びそのスレッドのすべての子スレッドの実行を取り消し、その後取り消したスレッドの再実行を行うことで、データの依存関係を保証する。本方式は、例えばキャッシュライン毎に古いバージョンのデータを破棄した旨を示す記憶手段を備えることで実現できる。
【0046】
〔実施例〕
以上のような方針に添った実施例の概略を示せば以下のようになる。
【0047】
先ず、キャッシュラインは、有効フラグ、変更フラグ、アドレスタグ、データエントリ等に加えて、少なくともデータのバージョンを示すバージョン識別子vidを備える。バージョン識別子vidは自プロセッサを除くマルチプロセッサシステムが備えるプロセッサ数分のビット数をもち、それぞれが自プロセッサを除く他プロセッサに対応する。
【0048】
ストア命令等の書き込みを行った場合、その対象ラインのバージョン識別子vidがセットされる。セットされるビットは、マージされたスレッドを除く該スレッドのすべての親スレッドを実行するプロセッサに対応するビットであり、それ以外のビットはリセットされる。
【0049】
あるスレッドがタームした場合、該スレッドを実行していたプロセッサを除くすべてのプロセッサのキャッシュメモリのすべてのキャッシュラインのバージョン識別子vidにおいて、該スレッドを実行していたプロセッサに対応するビットをリセットする。この処理は、例えばバージョン識別子vidを一括リセット機能付きメモリセルで構成することで容易に実現できる。
【0050】
すわなち、バージョン識別子vidはその時点での、自キャッシュラインを生成したスレッドのすべての親スレッドのうち、いまだタームしていない親スレッドを実行するプロセッサを示している。あるプロセッサPi上で実行された2つのスレッドにより生成された異なるバージョンのキャッシュラインは、その2つのスレッドのプログラム順序上で間のスレッドがすべてタームした時点で、バージョン識別子vidは同じバージョンを示し、すなわち、縮退が行われたことになる。
【0051】
他プロセッサから自キャッシュメモリにアクセスがあった場合にキャッシュヒットしたとき、バージョン識別子vidが参照される。バージョン識別子vidの前記他プロセッサに対応するビットがセットされている場合、自キャッシュラインにとっての親スレッドからのアクセスと判断できる。その場合、自キャッシュラインのデータはプログラム順序で後に位置し有効ではないので、前記アクセスに対して自キャッシュメモリからは応答しない。
【0052】
一方、バージョン識別子vidの前記他プロセッサに対応するビットがリセットされている場合、自キャッシュラインにとっての子スレッドからのアクセスと判断できる。その場合、自キャッシュラインのデータはプログラム順序で前に位置し有効であるので、前記アクセスに対して自キャッシュメモリから適切な応答処理を行う。
【0053】
前記タームによるバージョン識別子vidのリセットで、バージョン識別子vidのすべてのビットがリセットされた場合、自キャッシュラインのデータは少なくとも確定することになる。すなわち、バージョン識別子vidのすべてのビットがリセットされているキャッシュラインのデータは、メインメモリ等に書き戻すことができる。
【0054】
〔具体例〕
次に図7を参照して、4つのプロセッサP0〜P3からなるマルチプロセッサシステムにおいて、プロセッサP1に注目して本実施例の具体例を示す。
【0055】
図7の(1)において、プロセッサP1上で実行されているスレッドth0において、アドレスAに対するストア命令(stA)が実行され、アドレスAのキャッシュラインのバージョンは100となる。図中” A、100” はアドレスがAでバージョン識別子vidの値が100であることを示す。バージョン識別子vidのそれぞれのビットは左からそれぞれプロセッサP0、P2、P3に対応する。すなわち、この時点でスレッドth0に対してプロセッサP0のみで親スレッドが実行されているのでバージョン識別子vidには100が設定される。
【0056】
図7の(2)において、プロセッサP1でスレッドth0のターム後、スレッドc01から空きフォークによりスレッドth1が生成される。スレッドth0はスレッドc00にマージされる。このマージによってデータの転送等の処理は発生しないので、従って、空きフォークのオーバヘッドは小さい。
【0057】
図7の(3)において、スレッドth1でアドレスBに対するストア命令が実行される。スレッドth1の親スレッドはプロセッサP0、P2、P3で実行されているので、アドレスBのキャッシュラインのバージョンは111(図中”B,111”)となる。
【0058】
図7の(4)において、プロセッサP3で実行されているスレッドc01で、アドレスAに対するロード命令(ldA)、続いてアドレスBに対するロード命令(ldB)が実行される。ここで上記2つのロード命令ともプロセッサP3のキャッシュメモリにミスするとすると、プロセッサP1のキャッシュメモリもアクセスされる。プロセッサP1のキャッシュメモリに対するアクセスにおいてヒットすると、まずアドレスAに対してはバージョン識別子vidが100であるため、スレッドc01はアドレスAのキャッシュラインのバージョンを生成したスレッドth0にとっての子スレッドであることが判明し、当該アクセスに対してデータの転送等のヒット時の応答処理が行われる。一方、アドレスBに対するアクセスにおいては、アドレスBのキャッシュラインのバージョン識別子vidは111であるため、スレッドc01はアドレスBのキャッシュラインを生成したスレッドth1の親スレッドであることが判明し、当該アクセスに対しては応答しない。このように、他プロセッサからのアクセスに対して、バージョン識別子vid を参照するのみで、バージョンを考慮した選択的な応答を容易に行うことができる。
【0059】
図7の(5)において、プロセッサP3で実行されていたスレッドc01がタームし、その旨がプロセッサP1にも通知される。これにより、プロセッサP1のキャッシュメモリの全キャッシュラインのバージョン識別子vidにおいて、プロセッサP3に対応するビットがリセットされる。アドレスA及びアドレスBのキャッシュラインも該当ビットがリセットされ、それぞれ100及び110になる。
【0060】
図7の(6)において、スレッドth1からプロセッサP3に空きフォークが実行され、プロセッサP3において、スレッドc10が生成される。これによりタームしたスレッドc01はスレッドth1にマージされる。
【0061】
図7の(7)において、プロセッサP3で実行されているスレッドc10で、アドレスAに対するロード命令(ldA)、続いてアドレスBに対するロード命令(ldB)が実行される。ここで上記2つのロード命令ともプロセッサP3のキャッシュメモリにミスするとすると、プロセッサP1のキャッシュメモリもアクセスされる。この場合、プロセッサP1のキャッシュメモリにおいてヒットすると、アドレスAのラインのバージョン識別子vidは100、アドレスBのラインのバージョン識別子vidは110であるので、共にスレッドc10は子スレッドであることが判明し、今度は共に当該アクセスに対して応答することになる。このように、他プロセッサからのアクセスに対して、バージョン識別子vidを参照するのみで、バージョンを考慮した選択的な応答が行われた。
【0062】
図7の(8)において、プロセッサP1において、スレッドth1のターム後、スレッドc10から空きフォークが実行され、スレッドth2が生成される。スレッドth1はスレッドc10にマージされる。
【0063】
図7の(9)において、プロセッサP2で実行されていたスレッドc00がタームし、その旨がプロセッサP1にも通知される。これにより、プロセッサP1のキャッシュメモリの全キャッシュラインのバージョン識別子vidにおいて、プロセッサP2に対応するビットがリセットされる。アドレスA及びアドレスBのキャッシュラインも該当ビットがリセットされ、それぞれ100及び100になる。すなわち、上記2つのラインは同じバージョンを持つことになる。これは、アドレスAのバージョンを生成したスレッドth0からアドレスBのバージョンを生成したスレッドth1までの間のスレッドc00及びc01がこの時点ですべてタームし、前記2つのバージョンを区別する必要が無くなった為、スレッドth0のバージョンがスレッドth1のバージョンに縮退されたことに対応する。このように、バージョンの区別が不要になった際のバージョンの縮退が容易であることも本実施例の特徴である。
【0064】
図7の(10)において、スレッドth2でアドレスCに対するストア命令(stC)が実行される。スレッドth2の親スレッドはプロセッサP0、P3で実行されているので、アドレスCのキャッシュラインのバージョン識別子vidは101にセットされる。
【0065】
図7の(11)において、プロセッサP0において実行されていたスレッドがタームし、それにより、プロセッサP1のキャッシュメモリの全キャッシュラインのバージョン識別子vidにおいて、プロセッサP0に対応するビットがリセットされる。アドレスA,B,Cのキャッシュラインも該当ビットがリセットされ、それぞれ000、000及び001になる。すなわち、アドレスA及びBのラインは、バージョン識別子vidがすべてリセットされ、データが確定したことが判明する。これは、それぞれのバージョンを生成したスレッドth0及びth1が、その時点で最も古い親のスレッドになったことに対応する。一方、アドレスCのラインのバージョン識別子vidは001であり、アドレスCのバージョンを生成したスレッドth2にとっての親スレッドc10がプロセッサP3に存在していて、データが確定していないことがわかる。このように、本実施例によれば、バージョン識別子vidを参照するのみで、バージョンを考慮した選択的なキャッシュラインの確定判定を容易に行うことができる。
【0066】
〔本実施例の効果〕
このように本実施例によれば、1つのキャッシュメモリ上に複数のデータのバージョンを管理することにより、スレッドのマージ、空きフォーク時にデータの転送等のオーバヘッドが生じず、高速なスレッド並列処理が実現できる。
【0067】
また、バージョンをその時点での親スレッドを実行するプロセッサで表現することにより、アクセスに対するバージョンを考慮した選択的な応答、バージョンの縮退、バージョンを考慮した選択的な確定処理、等のデータ依存解消処理を容易、低オーバヘッドかつ高速に実現できる。
【0068】
また、他スレッドのタームに応じて、バージョン識別子vidが適切に変更され、バージョンの縮退が行われるので、空きフォークの回数に制限が存在しない。
【0069】
また、上記した選択的なアクセス応答や確定処理に必要な情報はすべてバージョン識別子vidに記憶されている為、以前にタームし未確定のスレッドやそのマージ、スレッド順序関係などの情報を別に記憶・管理する必要がない。
【0070】
〔適用例〕
次に、上述したキャッシュメモリの制御方法を図2の並列プロセッサシステムに適用した例について図面を参照しながら詳細に説明する。
【0071】
図8はスレッド実行部1−iの構成を示すブロック図である。図8を参照すると、スレッド実行部1−iは、プロセッサ10とキャッシュメモリ11とキャッシュ制御部12とを含み、プロセッサ10はバス2に接続され、キャッシュ制御部12はバス4に接続されている。バス4は、キャッシュ制御に関連するバスとして、要求バス13、応答バス14、データバス15を含んでいる。
【0072】
プロセッサ10は、キャッシュメモリ11及びキャッシュ制御部12と接続され、他のスレッド実行部のプロセッサと並列にスレッドを実行する。プロセッサ10とスレッド管理部3及び他のスレッド実行部のプロセッサとはバス2により接続され、スレッドの生成、スレッド実行の終了や取り消し、スレッド間の順序関係、等のスレッド実行に関する制御情報が伝達される。プロセッサ10は、バス2により伝達されるスレッド制御情報を参照して、自身が実行しているスレッドと他のプロセッサが実行しているスレッドとの順序関係を知ることができる。
【0073】
キャッシュ制御部12は、要求バス13、応答バス14及びデータバス15を通じて、他のプロセッサ及びメインメモリ5とメモリ操作命令が対象とするメモリデータの受渡しを制御する。このとき、プロセッサより通知されるスレッドの順序関係を参照し、メモリに関する正依存関係、逆依存関係、及び出力依存関係を考慮して、メモリデータ間の整合性の維持を図る。要求バス13、応答バス14、データバス15はそれぞれ一本のバスを各プロセッサで共有してもよいし、プロセッサ数分だけ固有のバスを備えてもよい。以下では、要求バス13、応答バス14、及びデータバス15を総称して単にバスとも表記する。
【0074】
図9は、キャッシュメモリ11を構成するキャッシュラインの詳細を示す説明図である。一つのキャッシュラインは、アドレスタグ25によって示されるアドレス範囲にあるデータを保持する。図9を参照すると、キャッシュメモリを構成するキャッシュラインは、有効フラグ20、変更フラグ21、共有フラグ22、投機フラグ23、更新フラグ24、アドレスタグ25、複数のデータエントリ26、複数のストア・フラグ27、複数の投機ロード・フラグ28、バージョン識別子(vid)29、から構成される。
【0075】
有効フラグ20は、そのキャッシュラインが有効であることを示す。有効フラグ20は、キャッシュミスが発生した時など、データをキャッシュメモリに転送し、キャッシュラインを生成する(リフィルする)際にセットし、キャッシュラインを入れ換える時など、キャッシュラインを無効化する際にリセットする。
【0076】
変更フラグ21は、そのキャッシュラインのデータをストア命令等で変更しており、メインメモリにあるデータと異なっている(dirty)ことを示す。変更フラグ21は、ストア命令等のデータの書き込みを実行した際にセットし、キャッシュラインのメインメモリへの書き戻し(ライトバック)を行った際にリセットする。
【0077】
共有フラグ22は、そのキャッシュラインと同アドレスのキャッシュラインを、他のプロセッサに固有のキャッシュメモリも保持し、データを共有していることを示す。本実施例による共有フラグは、並列プロセッサシステムが備えるプロセッサ数分のフラグを備えている。すなわち、それぞれのフラグ部分が各プロセッサに対応しており、フラグがセットされている場合、該フラグに対応するプロセッサとデータを共有していることを示し、フラグがリセットされている場合、該フラグに対応するプロセッサとデータを共有していないことを示す。したがって、共有フラグ22を参照すると、共有対象のプロセッサを特定することが可能である。共有フラグ22はバスアクセスが行われた際にセットまたはリセットされる。詳細には、あるプロセッサがキャッシュ制御部12を通じてバスアクセスを行った際には、全てのプロセッサのキャッシュ制御部12には、応答バス14を通じてすべてのキャッシュメモリ11のキャッシュライン状態が通知される。このとき、どのプロセッサと共有しているかが判明するので、共有フラグ22を構成するフラグのうち、共有しているプロセッサに対応するフラグをセットし、共有していないプロセッサに対応するフラグをリセットする。
【0078】
投機フラグ23は、そのキャッシュラインのデータが投機的なデータを含んでいることを示す。本実施例による投機フラグは、並列プロセッサシステムが備えるプロセッサ数分のフラグを備えている。すなわち、それぞれのフラグ部分が各プロセッサに対応しており、フラグがセットされている場合、該フラグに対応するプロセッサが、データが投機的である原因であることを示す。したがって、投機フラグ23を参照すると、該キャッシュラインのデータを投機的にならしめた原因のプロセッサを特定することが可能である。投機フラグ23は、キャッシュラインをリフィルする際、他のプロセッサのキャッシュメモリが保持している投機的なキャッシュラインからリフィル・データを得た場合、投機フラグ23の前記他のプロセッサに対応するフラグをセットする。また、自プロセッサが実行するスレッド(以下では、自スレッドと表記する)が含む投機的なストア命令により、投機的なデータでキャッシュラインを更新した場合、投機フラグ23の自プロセッサに対応するフラグをセットする。また、プログラム順序で先行するスレッド(親スレッド)が含む投機的なストア命令により、投機的なデータでキャッシュラインを更新した場合、投機フラグ23の前記親スレッドを実行するプロセッサに対応するフラグ部分をセットする。一方、投機フラグ23は、自スレッドの投機的な実行が確定して、そのキャッシュラインのデータが確定した際にリセットされる。
【0079】
更新フラグ24は、プログラム順序で後に位置するスレッド(子スレッド)により、そのキャッシュラインのデータが更新されたことを示す。すなわち、そのキャッシュラインのデータは、該プロセッサが実行する現スレッドには有効であるが、該プロセッサに次に割り当てられるスレッドには有効でない可能性があることを意味する。更新フラグ24は、1ビットの更新有効フラグ24aと、並列プロセッサシステムが備える、自プロセッサを除くプロセッサ数ビット分の更新対象フラグ24bとから構成される。更新有効フラグ24aは更新フラグ24全体が有効であることを示す。スレッドが終了した際には、すべての更新有効フラグ24aがセットされるが、別の実施例として、更新対象フラグ24bのいずれかがセットされている更新フラグ24の更新有効フラグ24aのみをセットしてもよい。更新有効フラグ24aがセットされていて、かつ、更新対象フラグ24bのいずれかがセットされている場合、当該キャッシュラインは次に実行されるスレッドでは有効でない可能性があることが示される。実際に当該キャッシュラインが有効か否かは、キャッシュミス時などに伴うバス要求の入出力時にキャッシュ制御部どうしで交換されるキャッシュライン状態によって調べられ、若し有効であれば更新対象フラグ24bと共に更新有効フラグ24aがリセットされる。他方、更新有効フラグ24aがリセットされているか、更新対象フラグ24bの全てがリセットされていれば、当該キャッシュラインは次に実行されるスレッドでも有効であることが示される。各更新対象フラグ24bは、それぞれが他のプロセッサに対応し、対応するプロセッサにより該キャッシュラインが更新されたことを示す。
【0080】
データエントリ26は、そのキャッシュラインのメモリデータを保持する。通常、一つのキャッシュラインは、アドレスタグ25が指定するアドレス範囲を構成する複数のデータエントリを備え、それぞれのデータエントリは、ストア命令等による書き込みの最小のデータ単位である。図9においては、複数のデータエントリ26のそれぞれをデータエントリ26a、データエントリ26b、データエントリ26c、データエントリ26d、…、と表記して区別している。
【0081】
ストア・フラグ27は、対応するデータエントリに、自プロセッサがストア命令などで書き込みを行ったことを示す。図9においては、ストア・フラグ27aはデータエントリ26aに、ストア・フラグ27bはデータエントリ26bに、ストア・フラグ27cはデータエントリ26cに、ストア・フラグ27dはデータエントリ26dに、それぞれ対応する。ストア・フラグは自プロセッサが書き込みを行った際にセットし、スレッドの実行が終了した際にリセットされる。
【0082】
投機ロード・フラグ28は、対応するデータエントリに、自プロセッサが投機的な読み出しを行ったことを示す。図9においては、投機ロード・フラグ28aはデータエントリ26aに、投機ロード・フラグ28bはデータエントリ26bに、投機ロード・フラグ28cはデータエントリ26cに、投機ロード・フラグ28dはデータエントリ26dに、それぞれ対応する。投機ロード・フラグは投機的な読み出しを行い、かつ読み出し対象のデータに対して先に書き込みを行っていない、すなわち対応するストア・フラグ27がセットされていないならばセットされる。一方、スレッドの投機実行が確定した際にはリセットされる。
【0083】
図9に示したキャッシュラインの実施例では、書き込みの最小データ単位に対応するデータエントリ26a、26b、…、のそれぞれに固有のストア・フラグ27a、27b、…、及び投機ロード・フラグ28a、28b、…、を備えたが、複数のデータエントリに対して単一のストア・フラグまたは投機ロード・フラグを代表させてもよい。例えば、図10は4つのデータエントリ26a、26b、26c、26d、に対して、一つの投機ロード・フラグ28aを備えたキャッシュラインの第2の実施例である。データエントリ26、ストア・フラグ27、投機ロード・フラグ28以外の構成要素は省略している。投機ロード・フラグ28aは、4つのデータエントリ26a、26b、26c、26d、のいずれかに投機的な読み出しを行ったことを示す。この場合、データエントリそれぞれに固有の投機ロード・フラグを備えるのに比べて、キャッシュメモリの実装に必要なハードウェア量が小さくなるという効果がある。
【0084】
バージョン識別子(vid)29は、自プロセッサを除く並列プロセッサシステムが備えるプロセッサ数分のビット数をもち、それぞれが自プロセッサを除く他プロセッサに対応する。ストア命令等の書き込みを行った場合、その対象ラインのバージョン識別子29がセットされる。セットされるビットは、マージされたスレッドを除く該スレッドのすべての親スレッドを実行するプロセッサに対応するビットであり、それ以外のビットはリセットされる。あるスレッドがタームした場合、該スレッドを実行していたプロセッサを除くすべてのプロセッサのキャッシュメモリのすべてのキャッシュラインのバージョン識別子29において、該スレッドを実行していたプロセッサに対応するビットがリセットされる。すわなち、バージョン識別子29はその時点での、自キャッシュラインを生成したスレッドのすべての親スレッドのうち、いまだタームしていない親スレッドを実行するプロセッサを示している。あるプロセッサPi上で実行された2つのスレッドにより生成された異なるバージョンのキャッシュラインは、その2つのスレッドのプログラム順序上で間のスレッドがすべてタームした時点で、バージョン識別子vidは同じバージョンを示し、すなわち、縮退が行われたことになる。他プロセッサから自キャッシュメモリにアクセスがあった場合、バージョン識別子29が参照される。バージョン識別子29の前記他プロセッサに対応するビットがセットされている場合、自キャッシュラインにとっての親スレッドからのアクセスと判断できる。その場合、自キャッシュラインのデータはプログラム順序で後に位置し有効ではないので、前記アクセスに対して自キャッシュメモリからは応答しない。一方、バージョン識別子29の前記他プロセッサに対応するビットがリセットされている場合、自キャッシュラインにとっての子スレッドからのアクセスと判断できる。その場合、自キャッシュラインのデータはプログラム順序で前に位置し有効であるので、前記アクセスに対して自キャッシュメモリから適切な応答処理を行う。前記タームによるバージョン識別子29のリセットで、バージョン識別子29のすべてのビットがリセットされた場合、自キャッシュラインのデータは少なくとも確定することになる。すなわち、バージョン識別子29のすべてのビットがリセットされているキャッシュラインのデータは、メインメモリ等に書き戻すことができる。なお、本実施例では、同アドレスで異なるバージョンのキャッシュラインは生成せず、空きフォークにより生成されたスレッドが書き込みを行う際に、その対象のラインが古いバージョンをもつdirty なラインの場合、すべての古いバージョンが確定して縮退されるまで書き込みの実行を遅らせて、複数のバージョンの発生を回避する。
【0085】
再び図8を参照すると、キャッシュ制御部12は少なくとも、バス要求制御部30、キャッシュ要求制御部31、バス要求出力バッファ32、バス要求入力バッファ33を含んでいる。
【0086】
バス要求制御部30は、キャッシュメモリ11からのキャッシュミス通知、ストア通知やその対象アドレス、ストア・データ、キャッシュライン状態等を受け取り、それらを参照してバス要求を生成し、バス要求出力バッファ32に登録する。ここで、キャッシュライン状態は、図9に示したキャッシュラインを構成する、有効フラグ20、変更フラグ21、共有フラグ22、投機フラグ23、更新フラグ24、ストア・フラグ27、バージョン識別子29を含み、キャッシュミスした場合は、そのミスによるリフィル処理対象のキャッシュラインの状態、キャッシュヒットした場合は、そのヒットしたキャッシュラインの状態を示す。
【0087】
バス要求出力バッファ32は、バス要求制御部30によって生成されたバス要求を格納し、順次バスを通じて他のプロセッサやメインメモリに出力する。より詳細には、バス要求はコマンド、アドレス、キャッシュライン状態、データ等から構成され、コマンド、アドレスは要求バス13、キャッシュライン状態は応答バス14、データはデータバス15に出力する。バス要求出力バッファ32は同時に、要求バス13に出力したコマンド、アドレス、及び応答バス14に出力したキャッシュライン状態を、バス要求入力バッファ33にも転送する。本実施例は、バス要求を出力する際には、キャッシュライン状態に含まれる共有フラグ22を参照して、データを共有しているプロセッサにのみ宛てて、バス要求を出力する。すなわち、データを共有していないプロセッサでは、該バス要求によるキャッシュメモリへのアクセスが発生せず、キャッシュメモリのアクセス競合による性能低下が小さく、またキャッシュメモリにおいて消費される電力を削減することができるという効果がある。
【0088】
バス要求入力バッファ33は、他プロセッサやメインメモリから要求バス13を通じて伝達されるバス要求のコマンド、アドレスや、応答バス14を通じて伝達されるキャッシュライン状態や、データバス15を通じて伝達されるデータなどを格納する。バス要求入力バッファ33はまた、バス要求出力バッファ32から要求バス13に出力されたバス要求のコマンド、アドレス、及び応答バス14に出力されたキャッシュライン状態を格納し、さらに、バス要求に応じて他プロセッサが応答バス14に出力するキャッシュライン状態を、その到着を待って格納する。同時にバス要求入力バッファ33は、格納しているバスから入力したバス要求、より詳細には、コマンド、アドレス、キャッシュライン状態、及びデータ、をキャッシュ要求制御部31に順次出力していく。
【0089】
キャッシュ要求制御部31は、バス要求入力バッファ33が保持し、順次入力されるバス要求を順次解釈する。まず、バスから入力された他プロセッサからのバス要求に対しては、キャッシュメモリ11にアクセスして、バス要求の対象のキャッシュラインを保持しているか否かを判定し、保持していなければその旨が、保持していればそのキャッシュラインの状態が、バス要求制御部30及びバス要求出力バッファ32を通じて、応答バス14に出力される。同時に、その自身のキャッシュメモリのキャッシュライン状態は、バス要求入力バッファ33の該当エントリに格納される。バス要求入力バッファ33において、自身のキャッシュライン状態も含めて、他プロセッサからのキャッシュライン状態の応答もすべて到着したら、再び、キャッシュ要求制御部31において、バス要求のコマンドと、自身のキャッシュライン状態、及び他プロセッサのキャッシュライン状態をすべて参照して、キャッシュラインの次の状態を決定し、対象のキャッシュラインの更新を行う。
【0090】
一方、自身が出力したバス要求に対しては、そのコマンド、アドレス、及びキャッシュライン状態が、バス要求入力バッファ33に格納されるので、バス要求入力バッファ33において、他プロセッサからのキャッシュライン状態の応答もすべて到着したら、キャッシュ要求制御部31において、バス要求のコマンドと、自身のキャッシュライン状態、及び他プロセッサのキャッシュライン状態をすべて参照して、キャッシュラインの次の状態を決定し、対象のキャッシュラインの更新を行う。
【0091】
次にフローチャートを参照しつつ、キャッシュメモリ11及びキャッシュ制御部12の動作の詳細を説明する。図11は、ロード命令が発行された場合のキャッシュメモリ11及びキャッシュ制御部12の動作を示すフローチャートである。まず、プロセッサ10でロード命令が発行されると(図11のステップ200)、キャッシュメモリ11がアクセスされ、キャッシュメモリにヒットするか、ミスするかが判定される(図11のステップ201)。ここで、キャッシュメモリにヒットするとは、有効フラグ20がセットされていて、かつアドレスタグ25で示されるアドレス範囲に該ロード命令の対象アドレスが入っているキャッシュラインが存在する場合である。前記条件を満たすキャッシュラインが存在しない場合、キャッシュメモリにミスするという。
【0092】
キャッシュメモリにヒットした場合、ヒットしたキャッシュラインが読み出され、キャッシュライン内の更新フラグ24が参照される(図11のステップ202)。更新フラグ24がセットされていない、すなわち、更新有効フラグ24aがセットされていないか、更新対象フラグ24bのいずれもがセットされていない場合、そのキャッシュラインは子スレッドにより更新されておらず、そのキャッシュラインは有効であると判断される。その場合、キャッシュメモリ11からプロセッサ10にロード対象のデータが転送される(図11のステップ206)。次に、該ロード命令がスレッド間の正依存関係に関して投機的な実行である場合、ロード対象のデータを格納したデータエントリ26に対応する投機ロード・フラグ28をセットして(図11のステップ207)、ロード命令の実行は終了する。発行されたロード命令が投機的であるか、確定的であるかはプロセッサ10からキャッシュメモリ11に通知される。
【0093】
一方、更新フラグ24の参照(図11のステップ202)で、更新フラグ24がセットされていた、すなわち、更新有効フラグ24aがセットされていて、かつ、更新対象フラグ24bのいずれかがセットされている場合、そのキャッシュラインは子スレッドにより更新されていて、そのキャッシュラインは既に無効である可能性があると判断される。ここで確定的に無効であると判定できないのは、子スレッドによる更新が投機的であって、かつ取り消されている場合があり、実際には有効である可能性もあるからである。確定的な判断は、子スレッドを実行したプロセッサのキャッシュメモリのキャッシュライン状態を参照する必要がある。そこで、バス要求制御部30は他のプロセッサのキャッシュメモリを参照するリード要求を生成し、バス要求出力バッファ32を通じて、要求バス13にリード要求を発行する(図11のステップ203)。同時にそのリード要求、リード要求の対象アドレス、及び自身のキャッシュライン状態は、バス要求入力バッファ33に格納され、他のプロセッサのキャッシュ制御部から、リード要求に対する応答である、キャッシュライン状態が応答バス14を通じて到着するのを待機する(図11のステップ204)。
【0094】
リード要求に対して、すべてのプロセッサからの応答が到着すると、前記した自身のキャッシュラインが実際に無効であるか、それとも有効であるかを判定する(図11のステップ205)。より詳細には、セットされている更新対象フラグ24bに対応するプロセッサのキャッシュライン状態を参照し、ヒットしていた場合は、実際にそのプロセッサに更新されていたと判断する。一方、セットされているすべての更新対象フラグ24bに対して、いずれのプロセッサでもミスしていた場合、その更新は投機実行の失敗により取り消されていて、実際には更新されていないと判断する。
【0095】
実際には更新されていなかった場合、該キャッシュラインは有効であるので、ただちに、読み出し処理を実行することができる。この場合、リフィル処理は必要なく、先に発行したリード要求を受信したプロセッサでは、そのリード要求に対する処理は行われない。読み出し処理では、キャッシュメモリ11からプロセッサ10にロード対象のデータを転送する(図11のステップ206)。次に、キャッシュライン状態を更新して、ロード命令の実行を終了する(図11のステップ207)。具体的には、まず、更新フラグ24をリセットし、次に、該ロード命令が投機的な実行である場合、ロード対象のデータを格納したデータエントリ26に対応する投機ロード・フラグ28をセットする。
【0096】
一方、実際に更新されていた場合、該キャッシュラインは無効であるので、他のプロセッサのキャッシュメモリ、またはメインメモリから、有効なデータをリフィルする必要がある。まず、リフィル処理の前に、該キャッシュラインのデータをライトバックする必要性を判断する(図11のステップ211)。該キャッシュラインは、自プロセッサが現在実行しているスレッドに対しては無効であるが、親スレッドに対しては有効である場合がある。より詳細には、該キャッシュラインを更新したプロセッサのキャッシュメモリに、確定したキャッシュライン、すわなち投機フラグ23がセットされていないキャッシュラインが存在しなければ、該キャッシュラインは唯一の確定したデータを保持しているため、ライトバックが必要であると判断する。一方、該キャッシュラインの更新元のプロセッサのキャッシュラインに、確定したキャッシュラインが存在すれば、ライトバックは必要ないと判断する。
【0097】
ライトバックが必要であると判断した場合、バス要求制御部30はライトバック要求を生成し、それをバス要求出力バッファ32を通じて、要求バス13に出力し(図11のステップ216)、次にデータバス15にライトバック対象のデータを出力する(図11のステップ217)。次に、先に発行しているリード要求に対して、他のキャッシュメモリまたはメインメモリからデータバス15を通じて伝達されるリフィル・データの到着を待つ(図11のステップ212)。次に、キャッシュ要求制御部31は到着したリフィル・データをキャッシュメモリ11へリフィルする処理を行い(図11のステップ213)、次に、キャッシュメモリ11からプロセッサ10にロード対象のデータを転送し(図11のステップ206)、キャッシュライン状態を更新して、ロード命令の実行を終了する(図11のステップ207)。
【0098】
一方、図11のステップ211でライトバックが必要でないと判断した場合、そのままリフィル・データの到着を待ち(図11のステップ212)、キャッシュメモリ11へのリフィルを行う(図11のステップ213)。次に、キャッシュメモリ11からプロセッサ10にロード対象のデータを転送し(図11のステップ206)、キャッシュライン状態を更新して、ロード命令の実行を終了する(図11のステップ207)。
【0099】
以上、図11のステップ201において、ロード命令がキャッシュメモリにヒットした場合の動作について説明した。一方、ロード命令がキャッシュメモリにミスした場合は、スレッド実行が確定的か投機的かで動作が異なる(図11のステップ208)。スレッド実行が投機的で、すなわち発行されたロード命令は投機的である場合、キャッシュメモリ11にリフィル可能か否かを判断する(図11のステップ214)。キャッシュメモリ11のリフィル先の候補のエントリに空きがなく、かつ、それらエントリに格納されているすべてのキャッシュラインの投機フラグ23及びストア・フラグ27のいずれかがセットされているか、あるいは投機ロード・フラグ28のいずれかがセットされている場合、リフィルすることができない。この場合、スレッドが確定するまで待機した後に(図11のステップ215)、図11のステップ209よりリフィル処理を開始する。
【0100】
一方、キャッシュメモリ11のリフィル先の候補のエントリに少なくとも1つの空きがあれば、リフィルは可能である。また、空きが無い場合でも、それらリフィル先候補のエントリに格納されているいずれかのキャッシュラインの投機フラグ23かストア・フラグ27のいずれかがセットされてなく、かつ投機ロード・フラグ28のいずれもセットされていない場合、そのエントリにリフィルすることが可能である。この場合、図11のステップ209よりリフィル処理を開始する。
【0101】
一方、スレッド実行が確定的で、すなわち発行されたロード命令は確定的である場合(図11のステップ208、Yes)、常にリフィルは可能であるので、図11のステップ209よりリフィル処理を開始する。具体的には、まず、要求バス13にリード要求を出力し(図11のステップ209)、それに対する他プロセッサからの応答を待つ(図11のステップ210)。
【0102】
次に、ライトバックが必要か否かを判定する(図11のステップ211)。リフィル先のエントリにストア命令により変更されたキャッシュライン、すわなち変更フラグ21がセットされているキャッシュラインが存在すれば、ライトバックが必要である。その場合、ライトバック要求を要求バス13に出力し(図11のステップ216)、次にデータバス15にライトバック対象のデータを出力する(図11のステップ217)。次に、リフィル・データの到着を待ち(図11のステップ212)、キャッシュメモリ11へのリフィルを行う(図11のステップ213)。次に、キャッシュメモリ11からプロセッサ10にロード対象のデータを転送し(図11のステップ206)、キャッシュライン状態を更新して、ロード命令の実行を終了する(図11のステップ207)。
【0103】
ライトバックが必要でない場合は、そのままリフィル・データの到着を待ち(図11のステップ212)、キャッシュメモリ11へのリフィルを行う(図11のステップ213)。次に、キャッシュメモリ11からプロセッサ10にロード対象のデータを転送し(図11のステップ206)、キャッシュライン状態を更新して、ロード命令の実行を終了する(図11のステップ207)。
【0104】
以上、ロード命令が発行された場合のキャッシュメモリ11及びキャッシュ制御部12の動作を説明した。次に、図12を参照して、ストア命令が発行された場合のキャッシュメモリ11及びキャッシュ制御部12の動作を説明する。
【0105】
まず、プロセッサ10でストア命令が発行されると(図12のステップ220)、キャッシュメモリ11がアクセスされ、キャッシュメモリにヒットするか、ミスするかが判定される(図12のステップ221)。ここで、キャッシュメモリにヒットするとは、有効フラグ20がセットされていて、かつアドレスタグ25で示されるアドレス範囲にストア命令の対象アドレスが入っているキャッシュラインが存在する場合である。前記条件を満たすキャッシュラインが存在しない場合、キャッシュメモリにミスするという。
【0106】
キャッシュメモリにヒットした場合、ヒットしたキャッシュラインが読み出され、まずキャッシュライン内のバージョン識別子が参照される(図12のステップ242)。ここで、バージョン識別子で示されるヒットしたキャッシュラインのバージョンと現在実行しているスレッドのバージョンが一致せず、かつdirty な(変更フラグ21がセットされている)キャッシュラインの場合、一致するまで待機する。バージョン識別子に記憶されるバージョンは、親スレッドの終了に応じて適宜変更され、いずれ現在実行しているスレッドのバージョンに一致する。バージョンが一致したか、あるいはdirty なキャッシュラインでない場合、次に図12のステップ222において、キャッシュライン内の更新フラグ24が参照される。
【0107】
更新フラグ24がセットされていない、すなわち、更新有効フラグ24aがセットされていないか、更新対象フラグ24bのいずれもがセットされていない場合、そのキャッシュラインは子スレッドにより更新されておらず、そのキャッシュラインは有効であると判断される。その場合、バス要求制御部30は、ライト要求を生成し、バス要求出力バッファ32を通じて、要求バス13にライト要求を出力する(図12のステップ226)。ライト要求は、ストア命令を実行したこと、及びそのストア・データを他のプロセッサやキャッシュメモリに通知し、それに対する処理を要求するバス要求である。
【0108】
次に、該ストア命令による書き込みの前に、以前のデータのメインメモリへのライトバックが必要か否かを判定する(図12のステップ227)。該ストア命令がヒットしたキャッシュラインが確定的である、すなわち投機フラグ23がセットされてなく、かつ該ストア命令が投機的な実行である場合、投機的なデータを書き込む前に、確定的なデータをメインメモリへライトバックする処理を行う。具体的には、要求バス13にライトバック要求を出力し(図12のステップ230)、続いてデータバス15を通じてライトバックするデータを転送する(図12のステップ231)。その後、該ストア命令が書き込みの対象とするキャッシュラインのデータエントリ26に、ストア・データの書き込みを行う(図12のステップ228)。次に、キャッシュライン状態を更新して、ストア命令の実行を終了する(図12のステップ229)。具体的には、まず、変更フラグ21、及びストア対象のデータを格納したデータエントリに対応するストア・フラグ27をセットする。さらに、該ストア命令が投機的な実行である場合、投機フラグ23の自プロセッサに対応するフラグ部分をセットする。さらに、バージョン識別子29に現在実行しているスレッドのバージョンの書き込みを行う。
【0109】
一方、ライトバックが必要なかった場合(図12のステップ227、No)、そのまま該ストア命令が書き込みの対象とするキャッシュラインのデータエントリに、ストア・データの書き込みを行う(図12のステップ228)。次に、キャッシュライン状態を更新して、ストア命令の実行を終了する(図12のステップ229)。
【0110】
一方、更新フラグの参照(図12のステップ222)で、更新フラグ24がセットされていた、すなわち、更新有効フラグ24aがセットされていて、かつ、更新対象フラグ24bのいずれかがセットされている場合、そのキャッシュラインは子スレッドにより更新されていて、そのキャッシュラインは既に無効である可能性があると判断される。その場合、バス要求制御部30はリード・ライト要求を生成し、要求バス13にリード・ライト要求を発行する(図12のステップ223)。リード・ライト要求は、同時に要求バスに出力する対象のアドレスに対して、リード要求に対する処理の後、ライト要求に対する処理を要求するバス要求である。
【0111】
次に、他のキャッシュ制御部からリード・ライト要求に対する応答の到着を待機し(図12のステップ224)、その応答を参照して、該キャッシュラインが子スレッドにより実際に更新されているか否かを判定する(図12のステップ225)。実際には更新されていなかった場合、該キャッシュラインは有効であるので、ただちにライト処理を開始することができる。この場合、リフィル処理は必要なく、先に発行したリード・ライト要求を受信したプロセッサでは、そのリード要求部分に対する処理は行われない。ライト処理では、まず、ライトバックが必要か否かの判断を行う(図12のステップ227)。ライトバックが必要な場合、ライトバック要求の発行(図12のステップ230)及び、ライトバック・データの転送(図12のステップ231)を行う。次に、該ストア命令が書き込みの対象とするキャッシュラインのデータエントリに、ストア・データの書き込みを行う(図12のステップ228)。次に、キャッシュライン状態を更新して、ストア命令の実行を終了する(図12のステップ229)。
【0112】
一方、図12のステップ225における子スレッドによる更新の有無の判断で、実際に更新されていた場合、該キャッシュラインは無効であるので、ロード命令の場合と同様に、他のプロセッサのキャッシュメモリ、またはメインメモリから、有効なデータをリフィルする必要がある。まず、リフィル処理の前に、該キャッシュラインのデータをライトバックする必要性を判断する(図12のステップ235)。該キャッシュラインは、自プロセッサが現在実行するスレッドに対しては無効であるが、親スレッドに対しては有効である場合がある。より詳細には、該キャッシュラインを更新したプロセッサのキャッシュラインに、確定したキャッシュライン、すわなち投機フラグ23がセットされていないキャッシュラインが存在しなければ、該キャッシュラインは唯一の確定したデータを保持しているため、ライトバックが必要であると判断する。一方、該キャッシュラインの更新元のプロセッサのキャッシュラインに、確定したキャッシュラインが存在すれば、ライトバックは必要ないと判断する。
【0113】
ライトバックが必要であると判断した場合は、ライトバック要求の発行(図12のステップ240)及び、ライトバック・データの転送(図12のステップ241)を行う。次に、先に発行しているリード・ライト要求に対して、他のキャッシュメモリまたはメインメモリからデータバス15を通じて伝達されるリフィル・データの到着を待つ(図12のステップ236)。次に、キャッシュ要求制御部31は到着したリフィル・データをキャッシュメモリ11へリフィルする処理を行う(図12のステップ237)。次に、該ストア命令が書き込みの対象とするキャッシュラインのデータエントリに、ストア・データの書き込みを行う(図12のステップ228)。次に、キャッシュライン状態を更新して、ストア命令の実行を終了する(図12のステップ229)。
【0114】
一方、ライトバックが必要でないと判断した場合は、そのまま、リフィル・データの到着を待ち(図12のステップ236)、キャッシュメモリ11へリフィルを行う(図12のステップ237)。次に、該ストア命令のストア・データの書き込みを行い(図12のステップ228)、キャッシュライン状態を更新して、ストア命令の実行を終了する(図12のステップ229)。
【0115】
以上、図12のステップ221において、ストア命令がキャッシュメモリにヒットした場合の動作について説明した。一方、ストア命令がキャッシュメモリにミスした場合は、ロード命令の場合と同様に、スレッド実行が確定的か投機的かで動作が異なる(図12のステップ232)。スレッド実行が投機的で、すなわち発行されたストア命令は投機的である場合、キャッシュメモリ11にリフィル可能か否かを判断する(図12のステップ238)。キャッシュメモリ11のリフィル先の候補のエントリに空きがなく、かつ、それらエントリに格納されているすべてのキャッシュラインの投機フラグ23及びストア・フラグ27のいずれかがセットされているか、あるいは投機ロード・フラグ28のいずれかがセットされている場合、リフィルすることができない。この場合、スレッドが確定するまで待機した後に(図12のステップ239)、リフィル処理を開始する。
【0116】
一方、キャッシュメモリ11のリフィル先の候補のエントリに少なくとも1つの空きがあれば、リフィルは可能である。また、空きが無い場合でも、それらリフィル先候補のエントリに格納されているいずれかのキャッシュラインの投機フラグ23かストア・フラグ27のいずれかがセットされてなく、かつ投機ロード・フラグ28のいずれもセットされていない場合、そのエントリにリフィルすることが可能である。この場合、そのままリフィル処理を開始する。
【0117】
一方、スレッド実行が確定的で、すなわち発行されたストア命令は確定的である場合(図12のステップ232、Yes)、常にリフィルは可能であるので、そのままリフィル処理を開始する。具体的には、まず、要求バス13にリード・ライト要求を出力し(図12のステップ233)、それに対する他プロセッサからの応答を待つ(図12のステップ234)。
【0118】
次に、ライトバックが必要か否かを判定する(図12のステップ235)。リフィル先のエントリに変更されたキャッシュライン、すわなち変更フラグ21がセットされているキャッシュラインが存在すれば、ライトバックが必要であると判断する。ライトバックが必要であると判断した場合は、ライトバック要求の発行(図12のステップ240)及び、ライトバック・データの転送(図12のステップ241)を行った後、リフィル処理を続行する。一方、ライトバックが必要でないと判断した場合は、そのままリフィル処理を続行する。リフィル処理は、先に発行しているリード・ライト要求に対して、他のキャッシュメモリまたはメインメモリからデータバス15を通じて伝達されるリフィル・データの到着を待つ(図12のステップ236)。次に、キャッシュ要求制御部31は到着したリフィル・データのキャッシュメモリ11へのリフィルを行う(図12のステップ237)。次に、該ストア命令が書き込みの対象とするキャッシュラインのデータエントリに、ストア・データの書き込みを行う(図12のステップ228)。次に、キャッシュライン状態を更新して、ストア命令の実行を終了する(図12のステップ229)。
【0119】
以上、ストア命令が発行された場合のキャッシュメモリ11及びキャッシュ制御部12の動作を説明した。次に、図13を参照して、他のプロセッサからバスを通じてリード要求を受信した場合、及びリード・ライト要求を受信した場合のリード要求部分に対する、キャッシュメモリ11及びキャッシュ制御部12の動作を説明する。リード・ライト要求を受信した場合は、リード要求に対する処理を行った後、後述するライト要求に対する処理を行う。以下の説明ではリード要求またはリード・ライト要求のリード要求部分を、単にリード要求と表記する。
【0120】
まず、他プロセッサのキャッシュ制御部12からのリード要求を、要求バス13を通じて受信すると、バス要求入力バッファ33は、該リード要求のコマンド、アドレス、リード要求を発行したプロセッサのキャッシュライン状態などを格納し、キャッシュ要求制御部31に通知する(図13のステップ245)。キャッシュ要求制御部31はリード要求を解釈すると、キャッシュメモリ11にアクセスし、リード要求の対象アドレスがキャッシュメモリにヒットするかミスするかを判定する(図13のステップ246)。ここで、キャッシュメモリにヒットするとは、有効フラグ20がセットされていて、かつアドレスタグ25で示されるアドレス範囲に当該リード要求の対象アドレスが入っているキャッシュラインが存在する場合である。前記条件を満たすキャッシュラインが存在しない場合、キャッシュメモリにミスするという。
【0121】
リード要求がキャッシュメモリ11にミスした場合、その旨を、バス要求制御部30、バス要求出力バッファ32、及び応答バス14を通じて、他プロセッサに通知し、リード要求に対する処理を終了する(図13のステップ247)。
【0122】
一方、リード要求がキャッシュメモリ11にヒットした場合、ヒットしたキャッシュラインの状態を、バス要求制御部30、バス要求出力バッファ32、及び応答バス14を通じて、その旨を他プロセッサに通知し(図13のステップ248)、他プロセッサからの応答である他のキャッシュメモリのキャッシュライン状態が到着するのを待機する(図13のステップ249)。次に、ヒットした自身のキャッシュライン状態の更新フラグ24を参照して、更新フラグ24がセットされているか否かを判定する(図13のステップ250)。
【0123】
更新フラグ24がセットされていない、すなわち、更新有効フラグ24aがセットされていないか、更新対象フラグ24bのいずれもがセットされていない場合、そのキャッシュラインは子スレッドにより更新されておらず、そのキャッシュラインは有効であると判断される。その場合、自身のキャッシュラインのデータをリフィル・データとして供給するか否かの判定を行う(図13のステップ256)。
【0124】
一方、更新フラグ24がセットされていた、すなわち、更新有効フラグ24aがセットされていて、かつ、更新対象フラグ24bのいずれかがセットされている場合、そのキャッシュラインは子スレッドにより更新されていて、そのキャッシュラインは既に無効である可能性があると判断される。その場合、他プロセッサからのキャッシュライン状態の応答を参照して、前記した自身のキャッシュラインが実際に無効であるか、それとも有効であるかを判定する(図13のステップ251)。より詳細には、セットされている更新対象フラグ24bに対応するプロセッサのキャッシュライン状態を参照し、ヒットしていた場合は、実際にそのプロセッサに更新されていたと判断する。一方、セットされているすべての更新対象フラグ24bに対して、いずれのプロセッサでもミスしていた場合、その更新は投機実行の失敗に取り消されていて、実際には更新されていないと判断する。
【0125】
子スレッドにより、実際には更新されていなかった場合、自身のキャッシュラインのデータをリフィル・データとして供給するか否かの判定を行う(図13のステップ256)。判定は、まず、リード要求を発行したプロセッサが、実際にリフィル処理を必要としているか否かを判断する。これは、リード要求を発行したが(図11の203、または図12の223)、実際にはキャッシュラインが有効でリフィル処理が必要ない場合(図11の205、No、または図12の225、No)があるからである。リード要求を受信したプロセッサでも、すべてのキャッシュメモリのキャッシュライン状態が参照できるので、リード要求を発行したプロセッサと同様の判断が可能である。
【0126】
リード要求を発行したプロセッサで、実際にリフィル処理を必要としていない場合は、リフィル・データの供給は行わない。一方、リード要求を発行したプロセッサで、実際にリフィル処理を必要としている場合、次に、プログラム順序の上で、ヒットした自身のキャッシュラインのデータを生成したスレッドと、リード要求を発行したプロセッサが実行するスレッドの間に位置するスレッドを実行するプロセッサのキャッシュライン状態を参照する。これら間に位置するスレッドを実行するプロセッサは、自身のキャッシュラインのバージョン識別子、及び他プロセッサから通知される他のキャッシュメモリでヒットしたキャッシュラインのバージョン識別子を参照して特定することができる。これは、バージョン識別子のうち、セットされているビットを参照すると、そのキャッシュラインのデータを生成したスレッドの親スレッドを実行しているプロセッサを特定できるためである。リフィル・データを供給するか否かは、それらの間のスレッドのキャッシュライン状態と自身のキャッシュライン状態により決定される。なお、スレッドの順序関係は、自身のプロセッサ10から各キャッシュ制御部12へ通知される。
【0127】
まず、前記間のスレッドのキャッシュラインの中に、投機的な(投機フラグ23がセットされた)キャッシュラインが存在する場合、自身のキャッシュラインのデータはリフィル・データとして無効であり、自プロセッサはリフィル・データの供給は行わない。
【0128】
次に、前記間のスレッドのキャッシュラインの中に、投機的なキャッシュラインは存在しないが、確定的なキャッシュラインは存在し、かつ自身のキャッシュラインも確定的である場合、自プロセッサはリフィル・データの供給は行わない。
【0129】
次に、間のスレッドのキャッシュラインの中に、投機的なキャッシュラインは存在しないが、確定的なキャッシュラインは存在し、かつ自身のキャッシュラインは投機的である場合、自プロセッサは自身のキャッシュラインからリフィル・データの供給を行う。
【0130】
次に、間のスレッドを実行するプロセッサではすべてキャッシュメモリにミスし、有効なキャッシュラインが存在しない場合、自プロセッサは自身のキャッシュラインからリフィル・データの供給を行う。
【0131】
リフィル・データの供給を行わない場合、キャッシュライン状態の更新、具体的には更新フラグ24のリセットを行い、リード要求に対する処理を終了する(図13のステップ257)。一方、リフィル・データの供給を行う場合、データバス15を通じて、自身のキャッシュラインが保持しているデータを転送し(図13のステップ258)、次に、キャッシュライン状態の更新を行い、リード要求に対する処理を終了する(図13のステップ257)。
【0132】
一方、子スレッドによる更新の有無判定で(図13のステップ251)、実際に更新されていた場合、該キャッシュラインは既に無効であるので、キャッシュラインの無効化を行う。まず、無効化処理の前に、該キャッシュラインのデータをライトバックする必要性を判断する(図13のステップ252)。該キャッシュラインは、自プロセッサが現在実行するスレッドに対しては無効であるが、親スレッドに対しては有効である場合がある。より詳細には、該キャッシュラインの更新元のプロセッサのキャッシュラインに、確定したキャッシュライン、すわなち投機フラグ23がセットされていないキャッシュラインが存在しなければ、該キャッシュラインは唯一の確定したデータを保持しているため、ライトバックが必要であると判断する。一方、該キャッシュラインの更新元のプロセッサのキャッシュラインに、確定したキャッシュラインが存在すれば、ライトバックは必要ないと判断する。
【0133】
ライトバックが必要であると判断した場合、要求バス13にライトバック要求を出力し(図13のステップ254)、次にデータバス15にライトバック対象のデータを出力する(図13のステップ255)。その後、キャッシュラインの有効フラグ20をリセットしてキャッシュラインの無効化を行い、リード要求に対する処理を終了する(図13のステップ253)。一方、ライトバックが必要でないと判断した場合は、そのままキャッシュラインの有効フラグ20をリセットしてキャッシュラインの無効化を行い、リード要求に対する処理を終了する(図13のステップ253)。
【0134】
以上、他のプロセッサからバスを通じてリード要求を受信した場合、及びリード・ライト要求を受信した場合のリード要求部分に対する、キャッシュメモリ11及びキャッシュ制御部12の動作を説明した。次に、図14を参照して、他のプロセッサからバスを通じてライト要求を受信した場合、及びリード・ライト要求を受信した場合のライト要求部分に対する、キャッシュメモリ11及びキャッシュ制御部12の動作を説明する。リード・ライト要求を受信した場合は、上述したリード要求に対する処理を行った後、ライト要求に対する処理を行う。以下の説明では、ライト要求、及びリード・ライト要求におけるライト要求部分を、単にライト要求と表記する。
【0135】
まず、他プロセッサのキャッシュ制御部12からのライト要求を、要求バス13を通じて受信すると、バス要求入力バッファ33は、該ライト要求のコマンド、アドレス、ライト要求を発行したプロセッサのキャッシュライン状態、ライト・データなどを格納し、キャッシュ要求制御部31に通知する(図14のステップ260)。キャッシュ要求制御部31はライト要求を解釈すると、キャッシュメモリ11にアクセスし、ライト要求の対象アドレスがキャッシュメモリにヒットするかミスするかを判定する(図14のステップ261)。ここで、キャッシュメモリにヒットするとは、有効フラグ20がセットされていて、かつアドレスタグ25で示されるアドレス範囲に当該ライト要求の対象アドレスが入っているキャッシュラインが存在する場合である。前記条件を満たすキャッシュラインが存在しない場合、キャッシュメモリにミスするという。
【0136】
ライト要求がキャッシュメモリ11にミスした場合、その旨を、バス要求制御部30、バス要求出力バッファ32、及び応答バス14を通じて、他プロセッサに通知し、ライト要求に対する処理を終了する(図14のステップ262)。
【0137】
一方、ライト要求がキャッシュメモリ11にヒットした場合、ヒットしたキャッシュラインの状態を、バス要求制御部30、バス要求出力バッファ32、及び応答バス14を通じて、その旨を他プロセッサに通知し(図14のステップ263)、他プロセッサからの応答である他のキャッシュメモリのキャッシュライン状態が到着するのを待機する(図14のステップ264)。次に、ヒットした自身のキャッシュライン状態の更新フラグ24を参照して、更新フラグ24がセットされているか否かを判定する(図14のステップ265)。
【0138】
更新フラグ24がセットされていない、すなわち、更新有効フラグ24aがセットされていないか、更新対象フラグ24bのいずれもがセットされていない場合、そのキャッシュラインは子スレッドにより更新されておらず、そのキャッシュラインは有効であると判断される。その場合、自身のキャッシュラインへのライト処理を開始する(図14のステップ265、No)。
【0139】
一方、更新フラグ24がセットされていた、すなわち、更新有効フラグ24aがセットされていて、かつ、更新対象フラグ24bのいずれかがセットされている場合、そのキャッシュラインは子スレッドにより更新されていて、そのキャッシュラインは既に無効である可能性があると判断される。その場合、他プロセッサからのキャッシュライン状態の応答を参照して、前記した自身のキャッシュラインが実際に無効であるか、それとも有効であるかを判定する(図14のステップ266)。より詳細には、セットされている更新対象フラグ24bに対応するプロセッサのキャッシュライン状態を参照し、ヒットしていた場合は、実際にそのプロセッサに更新されていたと判断する。一方、セットされているすべての更新対象フラグ24bに対して、いずれのプロセッサでもミスしていた場合、その更新は投機実行の失敗に取り消されていて、実際には更新されていないと判断する。
【0140】
子スレッドにより、実際には更新されていなかった場合、自身のキャッシュラインへのライト処理を開始する(図14のステップ266、No)。ライト処理はまず、ヒットした自身のキャッシュラインのデータを生成したスレッドにとって、親スレッドからのライト要求か否かを判断する(図14のステップ271)。この判断は、自身のキャッシュラインのバージョン識別子のうち、セットされているビットを参照して、該キャッシュラインのデータを生成したスレッドの親スレッドを実行するプロセッサを特定することで実現できる。子スレッドからのライト要求であった場合、それはプログラム順序の上で後に位置する書き込みなので、実際にデータの更新は行わず、子スレッドによって更新されたことを示す、キャッシュラインの更新フラグ24のうち、ライト要求を発行したプロセッサに対応する更新対象フラグ24bをセットして、ライト要求に対する処理を終了する(図14のステップ273)。
【0141】
一方、親スレッドからのライト要求であった場合、次に有効なライト・データ部分が存在するか否かを判定する(図14のステップ272)。判定には、まず、プログラム順序の上で、ライト要求を発行したプロセッサが実行するスレッドとヒットした自身のキャッシュラインのデータを生成したスレッドの間に位置するスレッドを実行するプロセッサのキャッシュライン状態を参照する。これら間に位置するスレッドを実行するプロセッサは、自身のキャッシュラインのバージョン識別子、及び他プロセッサから通知される他のキャッシュメモリでヒットしたキャッシュラインのバージョン識別子を参照して特定することができる。これは、バージョン識別子のうち、セットされているビットを参照すると、そのキャッシュラインのデータを生成したスレッドの親スレッドを実行しているプロセッサを特定できるためである。有効なライト・データ部分が存在するか否かは、それらの間のスレッドのキャッシュライン状態と自身のキャッシュライン状態により決定される。具体的には、ライト・データに対し、間のスレッドのキャッシュラインの中で、ストア・フラグ27がセットされているライト・データ部分が存在する場合、そのライト・データ部分は自スレッドに対して無効である。逆に、間のスレッドのキャッシュラインのいずれにも、ストア・フラグ27がセットされていないライト・データ部分が存在する場合、そのライト・データ部分は自スレッドに対して有効である。
【0142】
有効なライト・データ部分が存在しない場合、キャッシュライン状態を更新して、ライト要求に対する処理を終了する(図14のステップ273)。一方、有効なライト・データ部分が存在する場合、そのライト・データ部分の書き込み処理を行う。まず、実際に書き込みを行う前に、以前のデータのメインメモリへのライトバックが必要か否かを判定する(図14のステップ274)。該ライト要求がヒットしたキャッシュラインが確定的である、すなわち投機フラグ23がセットされてなく、かつ該ライト要求が投機的な要求である場合、投機的なデータを書き込む前に、確定的なデータをメインメモリへライトバックする。具体的には、要求バス13にライトバック要求を出力し(図14のステップ275)、続いてデータバス15を通じてライトバックするデータを転送する(図14のステップ276)。その後、実際の書き込み処理を開始する。一方、ライトバックが必要なかった場合(図14のステップ274、No)、そのまま実際の書き込み処理を開始する。ライト要求が投機的であるか、確定的であるかは、ライト要求の要因のストア命令が投機的であるか、確定的であるかにより、ライト要求と同時に要求を発行したプロセッサから与えられる。
【0143】
実際の書き込み処理では(図14のステップ277)、前記した有効なライト・データ部分を自身のキャッシュラインの対応するデータエントリ26へ書き込みを行う。ただし、自プロセッサが先に書き込みを行い、ストア・フラグ27がセットされている、データエントリに対しては書き込みを行わない。
【0144】
次に、受信したライト要求のストア命令から、自プロセッサが先に実行した正依存関係に対して投機的なロード命令への、正依存関係の検出を行う(図14のステップ278)。上記した有効なライト・データ部分に対応するデータエントリの投機ロード・フラグ28のいずれかがセットされていた場合、正依存関係が存在し、投機的なロード命令の実行は失敗であったと判断できる。その場合、キャッシュメモリ11はプロセッサ10に投機実行失敗を通知し、プロセッサ10はスレッド実行の取消しを行う(図14のステップ280)。
【0145】
一方、上記した有効なライト・データ部分に対応するデータエントリの投機ロード・フラグ28のいずれもセットされていない場合、正依存関係は存在せず、投機的なロード命令の実行は成功したと判断できる。その場合、キャッシュライン状態を更新して、ライト要求に対する処理を終了する(図14のステップ279)。
【0146】
一方、子スレッドによる更新の有無判定で(図14のステップ266)、実際に更新されていた場合、該キャッシュラインは既に無効であるので、キャッシュラインの無効化を行う。まず、無効化処理の前に、該キャッシュラインのデータをライトバックする必要性を判断する(図14のステップ267)。該キャッシュラインは、自プロセッサが現在実行するスレッドに対しては無効であるが、親スレッドに対しては有効である場合がある。より詳細には、該キャッシュラインを更新したプロセッサのキャッシュラインに、確定したキャッシュライン、すわなち投機フラグ23がセットされていないキャッシュラインが存在しなければ、該キャッシュラインは唯一の確定したデータを保持しているため、ライトバックが必要であると判断する。一方、該キャッシュラインの更新元のプロセッサのキャッシュラインに、確定したキャッシュラインが存在すれば、ライトバックは必要ないと判断する。
【0147】
ライトバックが必要であると判断した場合、要求バス13にライトバック要求を出力し(図14のステップ269)、次にデータバス15にライトバック対象のデータを出力する(図14のステップ270)。その後、キャッシュラインの有効フラグ20をリセットしてキャッシュラインの無効化を行い、ライト要求に対する処理を終了する(図14のステップ268)。一方、ライトバックが必要でないと判断した場合は、そのままキャッシュラインの有効フラグ20をリセットしてキャッシュラインの無効化を行い、ライト要求に対する処理を終了する(図14のステップ268)。
【0148】
以上、他のプロセッサからバスを通じてライト要求を受信した場合、及びリード・ライト要求を受信した場合のライト要求部分に対する、キャッシュメモリ11及びキャッシュ制御部12の動作を説明した。上記したように、本実施形態の特徴の一つに、同じアドレスに対するバス要求を結合して同時に発行することがある。さらに更新されて無効である可能性のあるキャッシュラインへの処理を、前記バス要求により暗黙的に実行することがある。これにより、発行されるバス要求を少なくすることができ、バスの競合による性能低下が小さく、バスで消費される電力が小さいという効果がある。上記説明では、同じアドレスに対するリード要求及びライト要求を統合してリード・ライト要求としたが、さらに同じアドレスに対するライトバック要求を統合しても良い。
【0149】
投機的なロード命令の実行に失敗した場合など、スレッドの実行が取り消された場合には、まず、キャッシュメモリ11を構成するすべてのキャッシュラインのすべての投機ロード・フラグ27をリセットすることで、投機実行したロード命令の記録を破棄する。次に、キャッシュメモリ11を構成するキャッシュラインのうち、投機的なキャッシュラインの無効化を行うことで、投機実行に失敗して無効であるデータの破棄を行う。具体的には、投機的なキャッシュラインのうち、該キャッシュラインが投機的である原因のプロセッサでも、スレッドの実行の取り消しが行われた場合、該キャッシュラインの有効フラグ20をリセットして無効化する。本実施例によれば、キャッシュラインが投機的なことを示す投機フラグ23を、複数のビットから構成しており、該キャッシュラインを投機的にならしめた原因のプロセッサを特定することが可能である。このため、投機フラグを1ビットで構成する従来の方法では、厳密には無効化が不必要なキャッシュラインも無効化されてしまうのに対して、本実施例によれば、厳密に無効化が必要なキャッシュラインのみが無効化されるため、キャッシュミスが発生する確率が小さく、高速なスレッド並列処理が可能であるという効果がある。
【0150】
一方、投機的なスレッドの実行が確定した場合には、キャッシュメモリ11を構成するキャッシュラインのうち、投機的なキャッシュラインの確定を行うことで、投機実行に成功して確定したデータの有効化を行う。この処理は、投機フラグ23、ストア・フラグ27、及び投機ロード・フラグ28をリセットすることで実現できる。各プロセッサで実行されているスレッドのうち、少なくともプログラム順序で最も先に位置するスレッドは、実行が確定している。それ以外のスレッドの実行は確定している場合と、投機的である場合があるが、いずれにしても、先行するすべてのスレッドの実行が終了し、自スレッドが実行中の最も先行するスレッドになった時点で、実行が確定する。
【0151】
以上、本発明を実施例を挙げて説明したが、本発明は以上の実施例にのみ限定されず、その他各種の付加変更が可能である。例えば、前記の実施例では複数のスレッド実行部に共通にスレッド管理部を設ける集中スレッド管理型の並列プロセッサシステムに本発明を適用したが、スレッド実行部毎にスレッド管理部を設ける分散スレッド管理型の並列プロセッサシステムにも本発明は適用可能である。
【0152】
【発明の効果】
以上説明したように本発明によれば、ターム後で確定前のスレッドをその直後の子スレッドにマージすることによってプロセッサ資源を有効に活用でき、スレッドの並列度を高めることが可能となる。
【図面の簡単な説明】
【図1】本発明の作用の説明図である。
【図2】本発明の並列プロセッサシステムの一例を示すブロック図である。
【図3】本発明の並列プロセッサシステムにおけるスレッド管理部の構成例を示すブロック図である。
【図4】本発明の並列プロセッサシステムにおけるスレッド管理部のスレッド管理シーケンサがスレッド実行部からフォーク要求を受信した際の処理例を示すフローチャートである。
【図5】本発明の並列プロセッサシステムにおけるスレッド管理部のスレッド管理シーケンサがスレッド実行部からスレッド終了通知を受信した際の処理例を示すフローチャートである。
【図6】個々のプロセッサが固有に備えるキャッシュメモリを仮実行用バッファとして兼用する場合の問題点を説明するためのスレッド実行シーケンス図である。
【図7】本発明の一実施例におけるキャッシュメモリの制御方法の説明図である。
【図8】本発明の並列プロセッサシステムのスレッド実行部の構成例を示すブロック図である。
【図9】キャッシュメモリを構成するキャッシュラインの第1の実施例の詳細を示す説明図である。
【図10】キャッシュメモリを構成するキャッシュラインの第2の実施例の詳細を示す説明図である。
【図11】ロード命令が発行された場合のキャッシュメモリ及びキャッシュ制御部の動作を示すフローチャートである。
【図12】ストア命令が発行された場合のキャッシュメモリ及びキャッシュ制御部の動作を示すフローチャートである。
【図13】リード要求を受信した場合のキャッシュメモリ及びキャッシュ制御部の動作を示すフローチャートである。
【図14】ライト要求を受信した場合のキャッシュメモリ及びキャッシュ制御部の動作を示すフローチャートである。
【図15】従来のマルチスレッド実行方法の処理の概要を示す図である。
【図16】従来の問題点の説明図である。
【符号の説明】
1−0〜1−3…スレッド実行部
2…第1のバス
3…スレッド管理部
4…第2のバス
5…メインメモリ
Claims (10)
- 単一のプログラムを複数のスレッドに分割し複数のスレッド実行部で並列に実行するマルチスレッド実行方法において、ターム後で確定前のスレッドを持つスレッド実行部の前記スレッドをその直後の子スレッドへマージし、前記スレッド実行部へ新たなスレッドをフォークすることを特徴とするマルチスレッド実行方法。
- 単一のプログラムを複数のスレッドに分割し複数のスレッド実行部で並列に実行するマルチスレッド実行方法において、個々のスレッド実行部を、フォーク可能なフリー状態、スレッドを実行しているビジー状態、ターム後で確定前のスレッドを持つターム状態の3つの状態で管理し、新たなスレッドをフォークする際、フリー状態のスレッド実行部が存在しない場合、ターム状態のスレッド実行部が持つスレッドをその直後の子スレッドへマージして当該スレッド実行部をフリー状態にし、新たなスレッドをフォークすることを特徴とするマルチスレッド実行方法。
- 個々のスレッド実行部毎に仮実行用バッファを備え、ターム状態のスレッド実行部が持つスレッドをその直後の子スレッドへマージする際、ターム状態のスレッド実行部の仮実行用バッファに保存されている仮実行結果を前記子スレッドを実行するスレッド実行部の仮実行用バッファへ転送する請求項1または2記載のマルチスレッド実行方法。
- 個々のスレッド実行部毎に仮実行用バッファを兼ねるキャッシュメモリを備え、前記キャッシュメモリの各キャッシュライン毎に、ターム後で確定前のスレッドが生成したデータと前記マージ後に新たに生成されたスレッドが生成したデータとを区別するバージョン情報を保持し、各スレッド実行部のキャッシュメモリは、他のスレッド実行部からのアクセスに対して、前記バージョン情報とスレッドの逐次実行順序とを考慮した選択的な応答を行う請求項1または2記載のマルチスレッド実行方法。
- 各スレッド実行部で実行されるスレッドが自身のキャッシュメモリに書き込みを行う際、書き込み対象となるキャッシュラインのバージョン情報が自スレッドのバージョンより古い場合、当該キャッシュラインのバージョンが親スレッドの終了に応じて適宜変更されて自スレッドのバージョンに一致するまで待ち合わせを行う請求項4記載のマルチスレッド実行方法。
- 単一のプログラムを複数のスレッドに分割し複数のスレッド実行部で並列に実行する並列プロセッサシステムにおいて、各スレッド実行部を相互に接続する通信路と、ターム後で確定前のスレッドを持つスレッド実行部の前記スレッドをその直後の子スレッドへマージし、前記スレッド実行部へ新たなスレッドをフォークする手段とを含むことを特徴とする並列プロセッサシステム。
- 単一のプログラムを複数のスレッドに分割し複数のスレッド実行部で並列に実行する並列プロセッサシステムにおいて、各スレッド実行部を相互に接続する通信路と、個々のスレッド実行部を、フォーク可能なフリー状態、スレッドを実行しているビジー状態、ターム後で確定前のスレッドを持つターム状態の3つの状態で管理する手段と、新たなスレッドをフォークする際、フリー状態のスレッド実行部が存在しない場合、ターム状態のスレッド実行部が持つスレッドをその直後の子スレッドへマージして当該スレッド実行部をフリー状態にし、新たなスレッドをフォークする手段とを含むことを特徴とする並列プロセッサシステム。
- 個々のスレッド実行部毎に仮実行用バッファを備え、ターム状態のスレッド実行部が持つスレッドをその直後の子スレッドへマージする際、ターム状態のスレッド実行部の仮実行用バッファに保存されている仮実行結果を前記子スレッドを実行するスレッド実行部の仮実行用バッファへ転送する構成を有する請求項6または7記載の並列プロセッサシステム。
- 個々のスレッド実行部毎に仮実行用バッファを兼ねるキャッシュメモリを備え、前記キャッシュメモリの各キャッシュライン毎に、ターム後で確定前のスレッドが生成したデータと前記マージ後に新たに生成されたスレッドが生成したデータとを区別するバージョン情報を保持し、各スレッド実行部のキャッシュメモリは、他のスレッド実行部からのアクセスに対して、前記バージョン情報とスレッドの逐次実行順序とを考慮した選択的な応答を行う構成を有する請求項6または7記載の並列プロセッサシステム。
- 各スレッド実行部のキャッシュメモリは、自スレッド実行部で実行されるスレッドからの書き込み時、書き込み対象となるキャッシュラインのバージョン情報が前記スレッドのバージョンより古い場合、当該キャッシュラインのバージョンが親スレッドの終了に応じて適宜変更されて前記スレッドのバージョンに一致するまで待ち合わせを行う構成を有する請求項9記載の並列プロセッサシステム。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001218158A JP3632635B2 (ja) | 2001-07-18 | 2001-07-18 | マルチスレッド実行方法及び並列プロセッサシステム |
US10/196,613 US7082601B2 (en) | 2001-07-18 | 2002-07-17 | Multi-thread execution method and parallel processor system |
GB0216756A GB2382181B (en) | 2001-07-18 | 2002-07-18 | Multi-thread execution method and parallel processor system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001218158A JP3632635B2 (ja) | 2001-07-18 | 2001-07-18 | マルチスレッド実行方法及び並列プロセッサシステム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2003030050A JP2003030050A (ja) | 2003-01-31 |
JP3632635B2 true JP3632635B2 (ja) | 2005-03-23 |
Family
ID=19052381
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001218158A Expired - Fee Related JP3632635B2 (ja) | 2001-07-18 | 2001-07-18 | マルチスレッド実行方法及び並列プロセッサシステム |
Country Status (3)
Country | Link |
---|---|
US (1) | US7082601B2 (ja) |
JP (1) | JP3632635B2 (ja) |
GB (1) | GB2382181B (ja) |
Families Citing this family (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3702813B2 (ja) * | 2001-07-12 | 2005-10-05 | 日本電気株式会社 | マルチスレッド実行方法及び並列プロセッサシステム |
US20040154010A1 (en) * | 2003-01-31 | 2004-08-05 | Pedro Marcuello | Control-quasi-independent-points guided speculative multithreading |
US6862664B2 (en) * | 2003-02-13 | 2005-03-01 | Sun Microsystems, Inc. | Method and apparatus for avoiding locks by speculatively executing critical sections |
GB0311006D0 (en) * | 2003-05-13 | 2003-06-18 | Nokia Corp | Registrations in a communication system |
JP3889726B2 (ja) * | 2003-06-27 | 2007-03-07 | 株式会社東芝 | スケジューリング方法および情報処理システム |
US7836450B2 (en) | 2003-08-28 | 2010-11-16 | Mips Technologies, Inc. | Symmetric multiprocessor operating system for execution on non-independent lightweight thread contexts |
US9032404B2 (en) | 2003-08-28 | 2015-05-12 | Mips Technologies, Inc. | Preemptive multitasking employing software emulation of directed exceptions in a multithreading processor |
US7870553B2 (en) | 2003-08-28 | 2011-01-11 | Mips Technologies, Inc. | Symmetric multiprocessor operating system for execution on non-independent lightweight thread contexts |
US20050050305A1 (en) * | 2003-08-28 | 2005-03-03 | Kissell Kevin D. | Integrated mechanism for suspension and deallocation of computational threads of execution in a processor |
EP1660998A1 (en) * | 2003-08-28 | 2006-05-31 | MIPS Technologies, Inc. | Mechanisms for dynamic configuration of virtual processor resources |
US7496921B2 (en) * | 2003-08-29 | 2009-02-24 | Intel Corporation | Processing block with integrated light weight multi-threading support |
GB0320386D0 (en) * | 2003-08-30 | 2003-10-01 | Ibm | A method, apparatus and computer program for executing a program |
CA2442803A1 (en) * | 2003-09-26 | 2005-03-26 | Ibm Canada Limited - Ibm Canada Limitee | Structure and method for managing workshares in a parallel region |
JP4803983B2 (ja) * | 2004-09-14 | 2011-10-26 | パナソニック株式会社 | 演算処理装置 |
US7913206B1 (en) * | 2004-09-16 | 2011-03-22 | Cadence Design Systems, Inc. | Method and mechanism for performing partitioning of DRC operations |
US7529888B2 (en) * | 2004-11-19 | 2009-05-05 | Intel Corporation | Software caching with bounded-error delayed update |
WO2009076324A2 (en) * | 2007-12-10 | 2009-06-18 | Strandera Corporation | Strand-based computing hardware and dynamically optimizing strandware for a high performance microprocessor system |
JP4484757B2 (ja) | 2004-12-09 | 2010-06-16 | 株式会社日立製作所 | 情報処理装置 |
CN101526935A (zh) * | 2004-12-09 | 2009-09-09 | 株式会社日立制作所 | 多节点服务器装置 |
US9753754B2 (en) * | 2004-12-22 | 2017-09-05 | Microsoft Technology Licensing, Llc | Enforcing deterministic execution of threads of guest operating systems running in a virtual machine hosted on a multiprocessor machine |
US7627864B2 (en) * | 2005-06-27 | 2009-12-01 | Intel Corporation | Mechanism to optimize speculative parallel threading |
CN101213527A (zh) * | 2005-06-29 | 2008-07-02 | 英特尔公司 | 用于缓存操作的方法、装置和*** |
US7904852B1 (en) | 2005-09-12 | 2011-03-08 | Cadence Design Systems, Inc. | Method and system for implementing parallel processing of electronic design automation tools |
US7593971B1 (en) * | 2005-12-07 | 2009-09-22 | Nvidia Corporation | Configurable state table for managing multiple versions of state information |
US7350027B2 (en) * | 2006-02-10 | 2008-03-25 | International Business Machines Corporation | Architectural support for thread level speculative execution |
US8201157B2 (en) * | 2006-05-24 | 2012-06-12 | Oracle International Corporation | Dependency checking and management of source code, generated source code files, and library files |
US8549499B1 (en) * | 2006-06-16 | 2013-10-01 | University Of Rochester | Parallel programming using possible parallel regions and its language profiling compiler, run-time system and debugging support |
US8448096B1 (en) | 2006-06-30 | 2013-05-21 | Cadence Design Systems, Inc. | Method and system for parallel processing of IC design layouts |
GB0625330D0 (en) | 2006-12-20 | 2007-01-24 | Ibm | System,method and computer program product for managing data using a write-back cache unit |
WO2008132761A2 (en) * | 2007-04-26 | 2008-11-06 | Hewlett-Packard Development Company L.P. | Method and system for managing heap across process replication |
JP4908363B2 (ja) * | 2007-09-25 | 2012-04-04 | 株式会社東芝 | 情報処理装置、並列処理最適化方法およびプログラム |
US20110067015A1 (en) * | 2008-02-15 | 2011-03-17 | Masamichi Takagi | Program parallelization apparatus, program parallelization method, and program parallelization program |
DE112009001700B4 (de) * | 2008-07-22 | 2019-02-07 | Toyota Jidosha Kabushiki Kaisha | Multikernsystem, fahrzeugseitige elektronische Steuerungseinheit und Aufgabenumschaltverfahren |
US10621092B2 (en) * | 2008-11-24 | 2020-04-14 | Intel Corporation | Merging level cache and data cache units having indicator bits related to speculative execution |
JP5547208B2 (ja) * | 2008-11-24 | 2014-07-09 | インテル コーポレイション | シーケンシャル・プログラムを複数スレッドに分解し、スレッドを実行し、シーケンシャルな実行を再構成するシステム、方法および装置 |
US9672019B2 (en) | 2008-11-24 | 2017-06-06 | Intel Corporation | Systems, apparatuses, and methods for a hardware and software system to automatically decompose a program to multiple parallel threads |
US8799582B2 (en) * | 2008-12-30 | 2014-08-05 | Intel Corporation | Extending cache coherency protocols to support locally buffered data |
KR101572879B1 (ko) | 2009-04-29 | 2015-12-01 | 삼성전자주식회사 | 병렬 응용 프로그램을 동적으로 병렬처리 하는 시스템 및 방법 |
US8397052B2 (en) * | 2009-08-19 | 2013-03-12 | International Business Machines Corporation | Version pressure feedback mechanisms for speculative versioning caches |
US8521961B2 (en) * | 2009-08-20 | 2013-08-27 | International Business Machines Corporation | Checkpointing in speculative versioning caches |
US8468539B2 (en) * | 2009-09-03 | 2013-06-18 | International Business Machines Corporation | Tracking and detecting thread dependencies using speculative versioning cache |
US8549523B2 (en) | 2009-11-23 | 2013-10-01 | International Business Machines Corporation | Performing runtime analysis and control of folding identified threads by assuming context of another thread and executing in lieu of another thread folding tool |
US8832663B2 (en) | 2009-11-23 | 2014-09-09 | International Business Machines Corporation | Thread serialization and disablement tool |
US8739164B2 (en) * | 2010-02-24 | 2014-05-27 | Advanced Micro Devices, Inc. | Automatic suspend atomic hardware transactional memory in response to detecting an implicit suspend condition and resume thereof |
US8713290B2 (en) * | 2010-09-20 | 2014-04-29 | International Business Machines Corporation | Scaleable status tracking of multiple assist hardware threads |
US20120198458A1 (en) * | 2010-12-16 | 2012-08-02 | Advanced Micro Devices, Inc. | Methods and Systems for Synchronous Operation of a Processing Device |
US8818970B2 (en) * | 2011-04-08 | 2014-08-26 | Symantec Corporation | Partitioning a directory while accessing the directory |
WO2013048468A1 (en) | 2011-09-30 | 2013-04-04 | Intel Corporation | Instruction and logic to perform dynamic binary translation |
US9747107B2 (en) | 2012-11-05 | 2017-08-29 | Nvidia Corporation | System and method for compiling or runtime executing a fork-join data parallel program with function calls on a single-instruction-multiple-thread processor |
US9867869B2 (en) | 2012-12-12 | 2018-01-16 | Massachusetts Institute Of Technology | Insulin derivatives for diabetes treatment |
US9891936B2 (en) | 2013-09-27 | 2018-02-13 | Intel Corporation | Method and apparatus for page-level monitoring |
CN105988704B (zh) * | 2015-03-03 | 2020-10-02 | 上海触乐信息科技有限公司 | 高效的触摸屏文本输入***及方法 |
EP3079064B1 (en) * | 2015-04-07 | 2017-11-29 | Huawei Technologies Co., Ltd. | Method and apparatus for tracking objects in a first memory |
JP6799258B2 (ja) * | 2016-12-28 | 2020-12-16 | 富士通株式会社 | ノード間通信プログラム、並列処理装置およびノード間通信方法 |
KR20200071282A (ko) * | 2018-12-11 | 2020-06-19 | 에스케이하이닉스 주식회사 | 메모리 시스템 및 메모리 시스템의 동작방법 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5050070A (en) | 1988-02-29 | 1991-09-17 | Convex Computer Corporation | Multi-processor computer system having self-allocating processors |
US5546593A (en) * | 1992-05-18 | 1996-08-13 | Matsushita Electric Industrial Co., Ltd. | Multistream instruction processor able to reduce interlocks by having a wait state for an instruction stream |
US5970250A (en) * | 1994-03-24 | 1999-10-19 | International Business Machines Corporation | System, method, and computer program product for scoping operating system semanticis in a computing environment supporting multi-enclave processes |
JP2882475B2 (ja) | 1996-07-12 | 1999-04-12 | 日本電気株式会社 | スレッド実行方法 |
JP2970553B2 (ja) | 1996-08-30 | 1999-11-02 | 日本電気株式会社 | マルチスレッド実行方法 |
WO1998043193A2 (en) * | 1997-03-21 | 1998-10-01 | University Of Maryland | Spawn-join instruction set architecture for providing explicit multithreading |
US6035374A (en) * | 1997-06-25 | 2000-03-07 | Sun Microsystems, Inc. | Method of executing coded instructions in a multiprocessor having shared execution resources including active, nap, and sleep states in accordance with cache miss latency |
US5890008A (en) * | 1997-06-25 | 1999-03-30 | Sun Microsystems, Inc. | Method for dynamically reconfiguring a processor |
US6003066A (en) * | 1997-08-14 | 1999-12-14 | International Business Machines Corporation | System for distributing a plurality of threads associated with a process initiating by one data processing station among data processing stations |
US6697935B1 (en) * | 1997-10-23 | 2004-02-24 | International Business Machines Corporation | Method and apparatus for selecting thread switch events in a multithreaded processor |
US6694425B1 (en) * | 2000-05-04 | 2004-02-17 | International Business Machines Corporation | Selective flush of shared and other pipeline stages in a multithread processor |
-
2001
- 2001-07-18 JP JP2001218158A patent/JP3632635B2/ja not_active Expired - Fee Related
-
2002
- 2002-07-17 US US10/196,613 patent/US7082601B2/en not_active Expired - Fee Related
- 2002-07-18 GB GB0216756A patent/GB2382181B/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
GB0216756D0 (en) | 2002-08-28 |
US20030018684A1 (en) | 2003-01-23 |
GB2382181B (en) | 2005-01-19 |
GB2382181A (en) | 2003-05-21 |
JP2003030050A (ja) | 2003-01-31 |
US7082601B2 (en) | 2006-07-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3632635B2 (ja) | マルチスレッド実行方法及び並列プロセッサシステム | |
JP3661614B2 (ja) | キャッシュメモリ制御方法及びマルチプロセッサシステム | |
JP3139392B2 (ja) | 並列処理システム | |
CN104375958B (zh) | 高速缓存存储器管理事务性存储器访问请求 | |
US7533227B2 (en) | Method for priority scheduling and priority dispatching of store conditional operations in a store queue | |
US8225120B2 (en) | Wake-and-go mechanism with data exclusivity | |
US10423446B2 (en) | Data processing | |
US8832415B2 (en) | Mapping virtual addresses to different physical addresses for value disambiguation for thread memory access requests | |
US9792147B2 (en) | Transactional storage accesses supporting differing priority levels | |
EP0514024B1 (en) | Method and apparatus for an improved memory architecture | |
US8850167B2 (en) | Loading/discarding acquired data for vector load instruction upon determination of prediction success of multiple preceding branch instructions | |
CN101038567B (zh) | 执行高速缓存线轮询操作的方法、***和设备 | |
WO2014090008A1 (zh) | 一种任务处理的方法和虚拟机 | |
CN101401071B (zh) | 利用存储和预留指令执行高速缓存线轮询操作的方法、***、设备和产品 | |
KR20080043378A (ko) | 복수의 병렬 클러스터들을 포함하는 계층 프로세서의스케쥴링 메카니즘 | |
JP2003029986A (ja) | プロセッサ間レジスタ継承方法及びその装置 | |
US20130268735A1 (en) | Support for speculative ownership without data | |
US10216519B2 (en) | Multicopy atomic store operation in a data processing system | |
CN1908890A (zh) | 用于使用记录板机制处理加载锁定指令的方法和装置 | |
JP4608099B2 (ja) | ジョブ信号を処理する多数の処理ユニットを有する処理システムにおけるジョブ信号処理方法および処理システム | |
JP2000047887A (ja) | 投機的マルチスレッド処理方法および投機的マルチスレッド処理装置 | |
JP2002530735A5 (ja) | ||
US20080134187A1 (en) | Hardware scheduled smp architectures | |
US20050283783A1 (en) | Method for optimizing pipeline use in a multiprocessing system | |
JP2002530736A5 (ja) |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20040823 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041029 |
|
A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20041029 |
|
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: 20041130 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041213 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080107 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090107 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100107 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110107 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110107 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120107 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130107 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130107 Year of fee payment: 8 |
|
LAPS | Cancellation because of no payment of annual fees |