JP2013168168A - スレッドレベルの投機実行を拡張するためのプリミティブ - Google Patents

Abstract

【課題】プロセッサは、投機的スレッド化をサポートするためにアドレス監視テーブル及びアトミック更新テーブルを含み得る。
【解決手段】プロセッサは、投機的スレッドの実行に関連した状態を維持するために１つ又は複数のレジスタを含むこともできる。プロセッサは、プリミティブ（状態のレジスタに書き込むための命令、バッファリングされたメモリ更新のコミットをトリガするための命令、状態のステータス・レジスタを読み出すための命令、及び／又は、トラップ／例外／割り込み処理に関連した状態ビットの１つをクリアするための命令）の１つ又は複数をサポートすることができる。その他の実施例も本明細書及び特許請求の範囲で記載する。
【選択図】図２

Description

本願の開示は、一般に情報処理システムに関し、特にスレッドレベルの投機実行のサポートに関する。

ハードウェアにおけるマルチスレッド化のサポートが一層増えてきている。例えば、一手法では、マルチプロセッサ・システム（チップ・マルチプロセッサ（「ＣＭＰ」システムなど））におけるプロセッサはそれぞれ、複数のソフトウェア・スレッドの１つを同時に処理することができる。同時マルチスレッド化（「ＳＭＴ」）と呼ばれている別の手法では、単一の物理プロセッサは、オペレーティング・システム及びユーザ・プログラムには複数の論理プロセッサとしてみえるようにされる。ＳＭＴの場合、複数のソフトウェア・スレッドが、スイッチングなしで単一のプロセッサ上でアクティブであり、同時に実行することが可能である。すなわち、各論理プロセッサは完全なアーキテクチャ状態組を維持するが、物理プロセッサのその他の多くの資源（キャッシュ、実行ユニット、分岐予測器、制御ロジックやバスなど）は共有される。ＳＭＴの場合、複数のソフトウェア・スレッドからの命令がよって、各論理プロセッサに対して同時に実行する。

ソフトウェア・スレッドの同時の実行をサポートするシステム（ＳＭＴ及び／又はＳＭＰシステムなど）の場合、アプリケーションをマルチスレッド・コードに並列化して、システムの同時実行の潜在性を利用することができる。マルチスレッド・アプリケーションのスレッドは、通信し、同期化する必要があり得る。これは、共有メモリを介して行われることが多い。さもなければ、単一スレッド・プログラムは、プログラムを複数のスレッドに編成し、別個のスレッド・ユニット上にそれぞれがあるスレッドを同時に実行することによってマルチスレッド・コードに並列化することもできる。さもなければ単一のスレッド・プログラムの並列化処理中に、依存性に関する特定の前提が設けられる場合、この手法は時には、投機的マルチスレッド化と呼ばれる。

マルチスレッド・プログラムの性能を向上させ、かつ／又は、マルチスレッド・プログラムの書き込みを容易にするため、スレッドレベルの投機実行を用いることが可能である。スレッドレベル投機実行は、投機命令のブロックのスレッドの実行を表す。すなわち、スレッドは命令を実行するが、その他のスレッドは、投機的に実行された作業をコミットするか又は廃棄（アボートとしても知られている）する決定をスレッドが行うまで命令の結果をみることが可能でない。

プロセッサは、投機命令ブロックの一部として行われるメモリ更新をバッファリングし、含めるための機能を提供することによって、より効率的なスレッドレベル投機実行を行うことが可能である。投機的メモリ更新を実行又は廃棄するよう命令されるまでメモリ更新をバッファリングすることができる。

プログラムが投機実行したいことがあり得る対象の１つには、コード・ブロックが、その他のスレッド上で同時に実行しているその他のコードに依存するか否かということがある。プロセッサは、依存性の検出のサポートを提供するために、これをより効率的に行うことが可能である。例えば、プロセッサは、別の同時スレッドによって後に修正されるメモリ位置をコードの投機的ブロックが読み出すか否かを検出するためのサポートを提供することができる。

本発明の実施例は、以下の図面（同じ構成要素は同じ参照符号で示す）を参照して分かり得る。前述の図面は、限定的であることを意図するものでなく、その代わりに、トラザクション実行サポートを備えた投機的マルチスレッド化を提供するためのシステム、方法及び機構の、選択された実施例を示すよう備えている。

一般的な並列プログラミング手法を図で表すブロック図である。 本発明の少なくとも１つの実施例によるプロセッサの選択された特徴を示すブロック図である。 トランザクション実行サポートを備えた投機的マルチスレッド化を行う方法の少なくとも一実施例のデータ及び制御フローを示すフロー図である。 トランザクション実行サポートを備えた投機的マルチスレッド化を行う方法の少なくとも一実施例のデータ及び制御フローを示すフロー図である。 トランザクション実行サポートを備えた投機的マルチスレッド化を行う方法の少なくとも一実施例のデータ及び制御フローを示すフロー図である。 トランザクション・ブロックの実行に障害が生じた旨を判定するための機構の少なくとも１つの実施例を示すデータフロー図である。 本願開示の手法を行うことができるシステムの少なくとも１つの実施例を示すブロック図である。 トランザクション実行をサポートするためにアドレス・モニタ・テーブル及びアトミック更新テーブルを含むプロセッサの少なくとも１つの実施例を示すブロック図である。

以下の説明では、スレッドレベルの同期実行に対するハードウェア・サポートを提供するための方法、システム及び機構の選択された実施例を表す。本明細書及び特許請求の範囲記載の装置、システム及び方法の実施例は、単一コア又はマルチコアのマルチスレッド化システムに利用することができる。以下の説明では、具体的な多くの詳細（プロセッサ・タイプ、マルチスレッド化環境、システム構成、データ構造や、命令のニーモニック及びセマンティックなど）を記載して、本発明の実施例のより徹底的な理解を提供する。しかし、前述の具体的な詳細なしで本発明を実施することができるということは当業者によって認識されるであろう。更に、本発明を不必要に分かりにくくすることがないよう、周知の特定の構造、回路及び同様なものは詳細に示していない。

スレッドレベルの投機実行を利用するマルチスレッド作業負荷の場合、同時に実行するスレッドの少なくとも一部は（全部でなくても）同じメモリ空間を共有することができる。本明細書及び特許請求の範囲使用の語「協調型スレッド」は、同じメモリ空間を共有するスレッド群を表す。協調型スレッドはメモリ空間を共有するので、同じメモリ項目との間で読み出し及び／又は書き込みを行うことができる。よって、正確で有意義な作業を行うために、同時実行される協調型スレッドは互いに同期化されるべきである。

図１は、メモリの共通の論理ビューを共有する２つの協調型スレッド１２５、１２６を図で示すブロック図である。前述の共有メモリ・マルチプロセッシングのパラダイムを、並列プログラミングと呼ばれる手法に用いることができる。この手法によれば、アプリケーション・プログラマは、「アプリケーション」又は「処理」と場合によっては呼ばれるソフトウェア・プログラムを、ソフトウェア・プログラムの並行処理を表すために同時に実行する対象の複数のスレッドに分割することができる。すなわち、さもなければ単一スレッド化されたプログラム又は「処理」１２０は、同時に実行することができる２つのスレッド１２６、１２５に分割することができる。

図１は、各スレッド１２５、１２６がそれ自身のアプリケーション及びシステム状態２０２ａ、２０２ｂそれぞれを有することを示す。メモリの特定のロジカル・ビュー２０４が、特定の処理１２０に関連した協調型スレッド１２５、１２６によって共有される。よって、少なくとも１つの実施例の場合、協調型スレッド１２５、１５６はそれぞれ、処理１２０のオペレーティング・システムによって構成される仮想メモリの同じビューを供給することができ、互いの仮想アドレス空間に対する可視度を有し得る。

図１は、記載を単純にするために、処理１２０の２つのスレッド１２５、１２６のみを示す。しかし、前述の例の例証は、限定するものと解されるべきでない。処理１２０に関連した協調型スレッドの数は、３以上であり得る。処理１２０に関連したスレッドの数の上限は、ＯＳプログラム（図示せず）によって制限され得る。

協調型スレッドのメモリ・アクセスの同期化を扱うための種々の手法が考え出されている。協調型スレッドの同期化を扱う一般的な手法には、メモリ・ロックの使用がある。特定のコード部分の共有データに対する排他的なアクセスを特定のスレッドが有することを保証するためにメモリ・ロックを用いることができる。従来のマルチスレッド・アルゴリズムでは、クリティカルな部分を複数のスレッドが同時に実行した場合に誤った挙動を生じ得る何れかのクリティカルなコード部分近くでロックを用い得る。前述の手法の場合、スレッドはロックを獲得し、そのクリティカルな部分を実行し、次いで、ロックを解除することができる。複数のスレッドが同時に実行することを阻止し得るので、性能がロックによって劣化し得る。必要以上に「念のために」、ロックが保有されている場合、性能が更に劣化し得る。すなわち、多くの場合、ロックは幾分悲観的に用いられ得る。

ロックの性能の影響を最小にするために、別々のコード部分に関連するか、又は別々のコード・ブロックに関連した細かい粒度でロックが行われるように別々の複数のロックをアプリケーションによって用いることが可能である。細粒度ロックはコードで実現するのが面倒であり得るものであり、複数のロックのオーナシップを単一スレッドが獲得しなければならない場合、デッドロックを起こしやすいことがあり得る。

種々の理由で、クリティカルな部分内の複数のスレッドによる共有データ構造組への同時アクセスは実際に、如何なる特定の生起の場合にも競合しないことがあり得る。前述の場合、ロックによって提供される直列化は、正確な実行を確実にするうえで必要でない。一スレッドが、開放されたロックを待ち、次いで、直列的にロックを、正確なメモリ値を維持するためにそうした直列化が必要でない場合であっても、獲得するので、前述の場合におけるロックの悲観的な使用によって、並列処理の利点の完全な実現が阻止され得る。

よって、不必要な直列化を回避するための一手法は、投機的ロック回避（「ＳＰＥ」）として知られている。ＳＰＥ手法はロックのコストを削減することができる。前述の手法は、「Ｓｐｅｃｕｌａｔｉｖｅ Ｌｏｃｋ Ｅｌｉｓｉｏｎ： Ｅｎａｂｌｉｎｇ Ｈｉｇｈｌｙ Ｃｏｎｃｕｒｒｅｎｔ Ｍｕｌｔｉｔｈｒｅａｄｅｄ Ｅｘｅｃｕｔｉｏｎ， Ｒａｊｗａｒ ｅｔ ａｌ．， Ｐｒｏｃ． ３０ｔｈ ＡＣＭ／ＩＥＥＥ Ｉｎｔ’ｌ． Ｓｙｍｐ． Ｏｎ Ｍｉｃｒｏａｒｃｈｉｔｅｃｔｕｒｅ， ２００１」に開示されている。前述の手法の場合、特定の同期化命令は悲観的に使用されており、必要でない。ＳＰＥの場合、特定の同期化命令は、必要でないとして予測され、回避される。同時に実行される２つのクリティカルな部分が同じメモリ位置の何れにも接触しない場合、ロックの人工的な直列化は回避される。

前述のロッキング手法及びＳＰＥ手法とは別の手法として、トランザクション実行が登場している。トランザクション実行手法の下では、命令ブロックをアトミック・ブロックとして区分することができ、ロックの必要なくアトミックに実行することができる。（本明細書及び特許請求の範囲使用の「アトミック・ブロック」及び「トランザクション・ブロック」は同義で用いることができる。）区分された命令それぞれの正味の影響全てがみられ、プロセッサ状態にコミットされるか、又は、区分された命令の何れかの影響が何らみられないか、若しくはコミットされないように意味論を備えることができる。これは、同時処理の点で、かつ、プログラム・ライタによって行われることが必要な推論の点でもいくつかの利点を有する、共有メモリのアクセスのための同期化の別の形態を提供する。

投機的ロック回避、及びトラザクション実行は何れも、スレッドレベルの投機的サポートによって達成することが可能である。何れの場合にも、意味論は、データ依存性の監視中にコード・ブロックを投機的に実行することを必要とする。必要なサポートは、投機的な領域内で行われるメモリ更新をバッファリングし、次いで、更新をコミット又は廃棄するための特定のやり方を含む。必要なサポートは、投機実行の期間中に別のスレッドによって修正された値が投機的領域内で読み出されたメモリに存在していることを検出する特定のやり方も含む。これは、投機的領域内で読み出されるメモリ・アドレス全てを記憶し、他のスレッドによる更新を求めてそれらを監視するための特定のやり方を必要とする。

投機的マルチスレッド化は、プログラムをマルチスレッド化し、スレッドレベルの投機実行を用いるための別の手法である。投機的マルチスレッド化の場合、シーケンシャル・プログラムがシーケンシャル・タスク（又は、次いで並列に実行されるコード・ブロック）に分割される。元のシーケンシャルな意味論を維持するためにタスクはその更新をコミットすることが確実にされる。タスクは更に、観察した値を先行タスクによる更新が変えたかを求めて監視される。その場合、投機的更新を廃棄し、作業をやり直すことが必要である。これに対するハードウェア・サポートは、前述と基本的に同様のスレッドレベル投機実行サポートである。

スレッドレベル投機実行に対するハードウェア・サポートをどのようにして構築するか、及び、ソフトウェア・インタフェースをどのようにして設けるかについて種々の多くの提案がされている。前述の手法の大半は、種々のインタフェースを介して、同様の基本機能を提供している。事実上、それらは、アーキテクチャ状態の一部をチェックポイントする。次いで、メモリ更新をバッファリングし、外部書き込みのために読み出されるメモリ位置を監視して、実行し続ける。

協調型スレッドのアトミック・ブロックの実行中に、少なくとも１つの既知のトランザクション実行手法の場合、スレッドによって生成されるメモリ状態は投機的である。アトミック命令ブロックが、実行を首尾良く完了するか否かは分からないからである。すなわち、第２の協調型スレッドは同じデータを求めて競合し得るものであり、その場合、第１の協調型スレッドはアトミックに実行することが可能でないことが分かる。すなわち、第１の協調型スレッド及び／第２の協調型スレッドに関する誤投機実行が存在している。誤投機実行をもたらすために、少なくとも特定の本願提案のトラザクション実行手法によってアトミック・ブロックの命令の実行中に、プロセッサ状態は更新されない。その代わりに、プロセッサ状態は、アトミック・ブロックが実行を完了するまで、未定義の中間状態として維持される。

前述の手法の場合、アトミック・ブロックの各命令におけるプロセッサの状態は、アトミック・ブロックの状態が最終的にコミットされるか否かに依存する。よって、アトミック・ブロックの実行中に、中間状態は、１）状態が最終的にコミットされる場合（前述の投機的メモリ・バッファにおいて維持される状態と同等である場合）、第１の状態であり、２）状態が最終的にコミットされない場合、第２の状態である。

よって、特定の一般的なトランザクション実行手法の場合、アトミック・ブロックの中間状態は未定義である。これは、アトミック・ブロック内の命令に対する特定の処理（高精度のトラップ処理や単一ステップのデバッグなど）を実行不能にする。しかし、図２は、投機的スレッド化及びトランザクション実行をサポートし、アトミック・ブロック内の各命令の境界（確定など）における厳密なアーキテクチャ状態も提供する。

図２は、トランザクション・ブロック内の命令を含む各命令の境界において、厳密なアーキテクチャ状態を提供する一方でトランザクション実行を実現する機能を提供するマルチスレッド・プロセッサ２００を示すブロック図である。プロセッサ２００は、一度に２つ以上のスレッドの同時実行をサポートする。本明細書及び特許請求の範囲使用の「スレッド」の語は、少なくとも、処理のその他のスレッドと同時に実行することができる命令ストリームの独立した実行の概念を含む。したがって、「スレッド」の語は、関連したプロセッサ状態とともにソフトウェア命令ストリームを実行するという考えを包含する。

少なくとも一実施例の場合、プロセッサ２００は、協調型スレッドの使用によって並列化されているアプリケーション・コードの一部分を実行することができる。例えば、スポーニー・スレッドと呼ばれる投機的スレッドは、スポーンを実行したスレッドによってプロセッサ２００上で実行されるコードに、プログラム順序において先の命令を実行するようプロセッサ２００上で実行することができる。スポーンを実行したスレッドは、スポーナ・スレッドと呼ばれる。

図２は少なくとも１つのＣＭＰ実施例を示す。複数スレッド・ユニット１０４それぞれはプロセッサ・コアであり、複数のコア１０４ａ乃至１０４ｎが単一チップ・パッケージ１０３に存在している。各コア１０４は、単一スレッド・プロセッサ又はマルチスレッド・プロセッサである。少なくとも１つの実施例の場合、スポーナー・スレッド（例えば、１０４ｃなど）を実行するコアとは別個のＣＭＰコア（例えば、１０４ａなど）がスポーニー・スレッドを実行する。

少なくとも１つの別の実施例の場合、プロセッサ２００は、同時マルチスレッド化をサポートする単一コア・プロセッサであり得る。前述の実施例の場合、各スレッド・ユニット１０４は、それ自身の次命令ポインタ及びフェッチ・ロジックを有する論理プロセッサであるが、同じプロセッサ・コアが全スレッド命令を実行する。（「スレッド・ユニット」及び「シーケンサ」の語は本明細書及び特許請求の範囲では同義に用いている場合がある。）前述の実施例の場合、論理プロセッサ１０４はその自身のアーキテクチャ状態のバージョンを維持するが、単一のプロセッサ・コアの実行資源が全スレッド間で共有される。

前述の別の実施例の場合、スポーニー・スレッドは、投機的マルチスレッド化をサポートする単一コア同時マルチスレッド化システムにおいて実行される。前述の実施例の場合、スポーニー・スレッドが、スポーナ・スレッドと同じ物理プロセッサ２００上の第２のＳＭＴ論理プロセッサ（例えば、１０４ａなど）によって実行される一方、スポーナ・スレッドは、別のＳＭＴ論理プロセッサ（例えば、１０４ｎなど）によって実行される。本明細書及び特許請求の範囲記載のトランザクション実行の実施例は何れかのマルチスレッド化手法（ＳＭＴ、ＣＭＰマルチスレッド化やその他のマルチプロセッサ・マルチスレッド化や何れかのその他の既知のマルチスレッド化手法を含む）において利用することができる。

本明細書及び特許請求の範囲記載のプロセッサ２００のＣＭＰの実施例は、プロセッサ・コア毎の単一スレッド１０４を表すが、本明細書及び特許請求の範囲記載の開示が、単一スレッド・プロセッサに限定されるとみなすべきでない。本明細書及び特許請求の範囲記載の手法は、何れのＣＭＰシステム（単一チップ・パッケージ１０３内に複数のマルチスレッド・プロセッサ・コアを含むものを含む）においても利用することができる。

よって、図２は、２つ以上のスレッド・ユニット１０４ａ乃至１０４ｎをプロセッサ２００が含むことを示す。説明の目的で、スレッド・ユニットの数は「Ｎ」として表す。前述のスレッド・ユニット１０４が２つを超えることが任意の特性であることは、図２において点線及び省略で表す。すなわち、図２はＮ＞２を示す。記載を単純にするために、ＣＭＰ実施例を本明細書及び特許請求の範囲において更に詳細に記載する。すなわち、各スレッド・ユニット１０４は、３２ビット・プロセッサ及び／又は６４ビット・プロセッサ（ペンティアム（登録商標）、ペンティアム（登録商標）プロ、ペンティアム（登録商標）ＩＩ、ペンティアム（登録商標）ＩＩＩ、ペンティアム（登録商標）４、並びにアイテニアム（登録商標）及びアイテニアム（登録商標）２マイクロプロセッサなど）を表し得る。しかし、前述の部分的なリストは限定的に解されないものとする。

図２に示すプロセッサ２００の実施例は、投機的マルチスレッド化をサポートする特定の意味論を備えるよう構成される。（それぞれは、以下に更に詳細に説明する。）前述の構成の特定の具体的な実現形態を以下に説明するが、前述の実現形態の詳細は、例示の目的でのみ備えるものであり、限定的に解されないものとする。

まず、プロセッサ２００は、共有データのメモリ処理を含む命令組の最初及び最後を区分する特定のやり方（本明細書及び特許請求の範囲では「アトミック・ブロック」又は「トランザクション・ブロック」として同義で表す）を提供する。

第２に、プロセッサ２００は、協調型スレッド間の競合を検出するためにロード（メモリ・ロード）アドレスを監視するハードウェアを含む。

第３に、プロセッサ２００は、演算をバッファ記憶（メモリ書き込み）するためのハードウェア（「記憶バッファ」）を含む。

第４に、プロセッサ２００は、（アトミック・ブロックの実行中に競合が認識されない場合、記憶バッファからメモリのアトミック更新を行うよう構成される。

最後に、プロセッサ２００は、アトミック・ブロックの実行中に競合が検出された場合、記憶バッファのメモリ更新を廃棄し、障害を通知する。前述の一般的な機能は、プロセッサ２００の少なくとも１つの実施例によって提供される。

アトミック・ブロックの区分に関しては、プロセッサ２００は、いくつかのやり方の何れかで前述のサポートを提供することができる。少なくとも１つの実施例の場合、プログラマは、命令演算コード自体に特定のビットをセットすることによって読み出し命令又は書き込み命令がアトミック・ブロックの一部である旨を示すことができる。例えば、「アトミック」インディケータは、命令演算コードの一部であり得るか、又は、ロード命令若しくは記憶命令の特定のプレフィックスによって示し得る。

少なくとも１つの別の実施例の場合、プロセッサ２００によってサポートされる命令セットは、明示的なアーキテクチャ区分命令を含み得る。すなわち、プロセッサ２００の命令セットは、プログラマによってアトミック・ブロックの最初に配置し得る「監視開始」命令を含み得る。同様に、プロセッサ２００の命令セットは、プログラマによってアトミック・ブロックの最後の命令の後に配置し得る「監視停止」命令も含み得る。少なくとも１つの実施例の場合、「監視開始」命令及び「監視停止」命令を行うよう制御レジスタを操作するために単一の命令を用いることができる。前述の命令及び制御レジスタの少なくとも１つの実施例の更なる説明は、図７に関して以下に記載する。

前述の通り、投機的マルチスレッド化及びトランザクション実行をサポートするプロセッサ２００の実施例は、協調型スレッド間の競合を検出するためにロード（メモリ読み取り）アドレスのハードウェアベースの監視を提供することができる。図２は、外部更新を求めて監視する対象の１つ又は複数のアドレスを記憶するためのテーブル１０６を含み得る。前述のテーブル１０６は、アドレス監視テーブル（「ＡＭＴ」）と呼び得る。ＡＭＴ１０６の論理コンセプトは、スレッド・ユニット１０４についてアーキテクチャ的に定義することができるが、必ずしも、別個のハードウェア・テーブル構造として実現されなくてよい。

前述の通り、アトミック・ブロック内の潜在的な依存関係及び／又は共有データ競合があいまいであり得るので、ＡＭＴ１０６は有用であり得る。プログラマは、アトミック・ブロックの実行中にアトミック・ブロックにおいて用いるアドレスに別のスレッドが書き込もうとすることを知っていた場合、同時実行中にその位置を読み出そうとしなかったであろうと思われる。すなわち、元のプログラムに競合／依存関係が存在していたことをプログラマが知っていた場合、前述のコード並列化は試行されなかったであろう。コードは、元々書き込まれていたように、順次に競合命令を実行することが可能であったであろう。よって、ＡＭＴ１０６は、誤投機実行の識別に有用であり得る。

更に、図２は、更新を行うスレッドが誤投機実行していないことが判定された場合、その後に行い得るメモリ更新をバッファリングするためのテーブル１０８も含むことができる。前述のテーブル１０８は、アトミック更新テーブル（「ＡＵＴ」）と呼び得る。（ＳＭＴ実施例の場合、テーブルの別々の部分を各論理プロセッサに割り当てて、単一のＡＭＴ１０６及びＡＵＴ１０８を論理プロセッサ間で共有することができる。）ＡＵＴ１０８は、アトミック・ブロック中に行われるメモリ書き込みをバッファリングすることができる。前述の手法は、アトミック・ブロックの中間状態を利用するその他のスレッドを行うことを回避する。

別のスレッドとの未解決の依存関係又は競合なしでアトミック・ブロックが実行を完了することができたか否かが最終的に判定されると、ＡＵＴ１０８にバッファリングされたメモリ更新をアトミックに行うことができる。しかし、トランザクション・ファイルに障害が生じた場合（すなわち、競合、又は未解決のデータ依存関係が理由で、完全な実行をアトミック・ブロックが完了することができない場合）、ＡＵＴ１０８はクリアリングすることができ、バッファリングされた更新は行われない。このようにして、誤投機実行が行われた旨の判定に応じて、既に行われたメモリ書き込みはアンロールしなくてよい。

図２に示すプロセッサ２００の少なくとも１つの実施例は、アトミック・ブロックにおける各命令の境界（確定など）における厳密なアーキテクチャ状態を以下のように提供する。プロセッサ２００における特定のユーザ制御可能な状態は、アトミック・ブロックの命令の実行中にトラップ又は例外が生じた場合にトランザクション障害が生じるべきでない旨を示すよう設定することができる。その代わりに、例外／トラップが処理されている間、ＡＭＴ１０６及びＡＵＴ１０８の内容は維持される。前述の処理後、アトミック・ブロックの実行は続行し得る。このようにして、トラップ又は例外が処理された後にアトミック・ブロックの実行を再開することができるように厳密な状態が維持される。

図２にはＡＭＴ１０６及びＡＵＴ１０８を別個のブロックとして示しているが、前述の例証は、前述のテーブルが論理的に別個の構造であることを伝えることを意味している。前述のテーブル１０６、１０８はアーキテクチャ的に明示的であり得るが、その特定の編成及び物理構造は、設計上の選択であり、物理的な実現の厳密なやり方は、何れかの特定の構造又は編成に限定されると解されないものとする。一般に、ＡＭＴ１０６及びＡＵＴ１０８の情報は、何れの記憶領域にも維持することができる。例えば、論理「テーブル」１０６、１０８は、ビットの収集物であり得るか、又はその他の既存のハードウェア構造の拡張であり得る。

ＡＭＴ１０６及びＡＵＴ１０８を実現する特定のやり方に関し、テーブル１０６、１０８は一般に、１つ又は複数の物理的な記憶領域に有限論理構成として実現することができる。テーブル１０６、１０８の有限性は必然的に、トランザクションとして首尾良く実行可能な命令の数を制限する。よって、バックストア１６０における１つ又は複数のメモリ・テーブルを用いて、ＡＭＴ１０６及び／又はＡＵＴ１０８のサイズを拡張することができる。

図２は、プロセッサ２００の少なくとも１つの実施例がメモリ１５０に結合し得ることを示す。メモリ１５０の一部分をソフトウェアによって利用して、ＡＭＴ１０６及び／又はＡＵＴ１０８のバックストア１６０を維持することができる。ソフトウェアは、オーバフロー・エントリのテーブル１０６、１０８からバックストア１６０への流出を制御することができる。

少なくとも１つの実施例の場合、ＡＭＴ１０６は、ロード・バッファと並列の構造として実現することができる。同様に、ＡＵＴ１０８は、記憶バッファに並列の構造として実現することができる。前述の実施例の考えられる１つの構成を図８に示す。

図８は、ＡＭＴ１０６及びＡＵＴ１０８、並びに、ロード要求バッファ４４０及び記憶要求バッファ４５０を含むプロセッサ１００４の少なくとも１つの実施例を更に詳細に示すブロック図である。ＡＭＴ１０６、ＡＵＴ１０８、記憶要求バッファ４４０及び／又はロード要求バッファ４５０のうちの１つ又は複数は、メモリ配列バッファ（ＭＯＢ）２２３の一部であり得る。プロセッサ１００４は、命令セットの命令を受け取り、デコードするためのデコーダ１０２２も含み得る。デコーダ１０２２は、命令を受け取り、デコードすることができることがあり得る。デコーダ１０２２によってデコードされる対象の命令は、表１に関し説明する動作の実行のための１つ又は複数の命令を含み得る。

図８は、非ブロック化キャッシュ・メモリ・サブシステムを実現するプロセッサ１００４を示す（キャッシュ・メモリ・サブシステムは時には、本明細書及び特許請求の範囲では略称「キャッシュ・システム」として呼ぶものとする）。キャッシュ・システムは、Ｌ０キャッシュ４６０及びＬ１キャッシュ４１０を含む。少なくとも一実施例の場合、Ｌ０キャッシュ４６０及びＬ１キャッシュ４１０はダイ上キャッシュである。プロセッサ１００４は、主メモリ１０２からもデータを取り出すことができる。主メモリ１０２、Ｌ１キャッシュ４１０、及びＬ０キャッシュ４６０は併せてメモリ階層２４０を形成する。

メモリ配列バッファ（「ＭＯＢ」）２２３は、ディスパッチから完了までの未処理ロード及び記憶命令を一時的に保持することができる。少なくとも１つの実施例の場合、記憶命令のためのこの状態情報を記憶要求バッファ４５０に維持することができ、ロード命令のこの状態情報をロード要求バッファ４４０に維持することができる。

少なくとも１つの実施例の場合、ロード命令のトラッキングは任意に、ＡＭＴ１０６によって処理することができる。ＡＭＴ１０６は、トランザクション実行中のロード要求バッファ４４０と共に利用することができる。

少なくとも１つの実施例の場合、未処理記憶命令の状態情報は、通常の処理の場合に記憶要求バッファ４５０に維持することができるか、又は、代わりに、トランザクション実行中にＡＵＴ１０８において維持することができる。

図８は、制御部分５１５を各記憶バッファ・エントリ４５０ａ乃至４５０ｎが含み得ることを示す。図８に示すように互いに論理的に関連しているが、必ずしも、記憶装置の連続した記憶領域に、記憶要求バッファ・エントリ４５０ａ乃至４５０ｎの制御部分５１５及びデータ部分４８０が物理的に存在していなくてもよく、同じ記憶装置に存在していなくてもよいことを当業者は認識するであろう。例えば、図８は、記憶バッファ４５０の制御部分５１５がＭＯＢ２２３に含まれ得る一方、データ部分４８０がダイ上キャッシュ４１０に存在し得ることを示す。

少なくとも１つの実施例の場合、ＭＯＢ２２３は制御ロジック４７５を含む。制御ロジック４７５は、記憶データをバッファリングすべき所が記憶要求バッファ４５０であるか、ＡＵＴ１０８であるかを判定するための選択ロジック２３６を含む。少なくとも１つの実施例の場合、選択ロジック２３６は、記憶要求バッファ４５０及びＡＵＴ１０８の一方のみに記憶を記録すべきである旨を指示することができる。すなわち、記憶データを保持する所の判定は、「排他的論理和」演算であり得る。選択ロジック２３６は、アトミック実行が行われていない場合に、記憶状態を記憶要求バッファ４５０にバッファリングすることができる旨を示し得る。しかし、アトミック実行中、その代わりに、選択ロジック２３６は記憶状態をＡＵＴ１０８にバッファリングさせることができる。

少なくとも１つの実施例の場合、選択ロジック２３６は、メモリから読み出された、ロード・データのメモリ・アドレスをＡＭＴ１０６に入力すべきか否かも判定するものとする。前述の入力は、アトミック実行中に、メモリ読み出しデータをロード要求バッファ４４０にプルする通常の処理とともに行うことができる。すなわち、ＡＭＴ１０６におけるロード・アドレスを監視するか否かについての判定は、通常のロード要求バッファ４４０処理に加えて監視が行われるような選択的な処理であり得る。

ＡＭＴ１０６及びＡＵＴ１０８の利用によって、あいまいなデータ依存関係又はデータ競合が理由で並列化がさもなければ困難なコードの投機的マルチスレッド化が可能になる。論理アドレス監視テーブル１０６及び論理アドレス更新テーブル１０８の使用によって、プロセッサ２００は、実行前にあいまいにみえる特定の潜在的なデータ依存関係又はデータ競合が実行中にスレッド間に存在し得ることを検出することができる。前述のように、テーブル１０６、１０８はよって、ロード（メモリ読み出し）処理の監視、及び記憶（メモリ書き込み）処理のバッファリングそれぞれをサポートする。

図３は、ＡＭＴ１０６及びＡＵＴ１０８を用いたトランザクション実行サポートによって投機的マルチスレッド化を行う方法３００の少なくとも１つの実施例のデータ及び制御フローを示すフロー図である。一般に、方法３００は、アトミック・ブロックの命令を実行するが、更新をメモリにバッファリングする。更に、方法３００は一般に、同じアドレスへの書き込みを別のスレッドが行おうとしたかを判定するために、アトミック・ブロックの実行中に読み出されるメモリ・アドレスを監視するようにする。肯定の場合、アトミック・ブロックの実行中にそのメモリ・アドレスに対する競合が存在しており、ブロックのトランザクション実行は、メモリ・アドレスに対する競合が理由で障害が生じる。

図３は、ブロック３０２で方法３００が始まることを示す。トランザクション・ブロックとして区分されたブロック上で方法３００が行われるものとする。したがって、少なくとも１つの実施例の場合、前述のように、方法３００を開始する前に「監視開始」命令が実行されているものとする。更に、前述の実施例の場合、「監視停止」命令の実行によって、ブロック３１４での判定が偽の値に評価されるものとする。

あるいは、アトミック・ブロックの一部として命令を実行するものとするプレフィックス、命令コード・フィールドやその他の個別化されたインディケータとともにアトミック・ブロック内の各ロード及び記憶命令をマーキングすることによって区分を表すことができる。前述の実施例の場合、任意のブロック３０８及び３１２（破線を用いることによって任意的として表す）を行って、命令がアトミック・ブロックの一部であるか否かを判定する。

少なくとも一実施例の場合、方法３００は、ＡＭＴ１０６及びＡＵＴ１０８（図２参照）を含むプロセッサのスレッド実行ユニット（例えば、図２の１０４参照）によって行われるものとする。よって、命令がアトミック・ブロックの一部であるか否かの判定は、区分された命令の通常の実行中に行われたメモリ書き込みは何れも１０８にバッファリングされるべきであり、区分された命令の通常の実行中に行われた何れのメモリ読み出しのアドレスもＡＭＴ１０６に維持されるべきであることも示す。

図３は、図示した方法３００によるアトミック・ブロックの実行中のどの時点でも、トラップ、例外又は割り込みを行うことができることを示す。前述のイベントが行われた場合、厳密なアーキテクチャ状態を維持することができる。すなわち、ＡＭＴ１０６及びＡＵＴの内容を例外／割り込み／トラップ・イベントの処理中に維持することができる。前述のイベントは、障害をもたらす条件として扱われない。その代わりに、図３に示す方法３００によるアトミック・ブロックの実行は、イベントの処理後に再開することができる。図３は、ブロック３９０において、前述のイベントが方法３００の少なくとも１つの実施例の場合の障害条件でないことを示す。

図３は、方法３００の処理がブロック３０２からブロック３０４に進むことを示す。ブロック３０４では、スレッドの次命令がフェッチされ、デコードされる。処理は次いでブロック３０６に進む。ブロック３０６では、ブロック３０４でフェッチされ、デコードされた命令がメモリ読み出し命令（例えば、ロード命令など）であるか否かについて判定される。肯定の場合、処理は任意ブロック３０８に進む。さもなければ、処理はブロック３１０に進む。

任意ブロック３０８は、命令がアトミック・ブロックの一部であるか否かを判定する。前述の判定のやり方は、種々の実現形態間で変わり得る。前述の情報をメモリ書き込み命令自体に埋め込まないが、その代わりに「監視開始」命令を用いる実現形態の場合、前述の判定３０８は、メモリ読み出し命令毎に行わなくてよい。その代わりに、ブロック３０２で、方法３００の実行の開始の前に「監視開始」が実行されており、実行中に方法３００がこのことを知っているものとする。例えば、少なくとも１つの実施例の場合、前述の情報は、制御レジスタ（後述するトランザクション制御レジスタ（「ＴＣＲ」）など）に維持することができる。前述の実施例の場合、処理はブロック３０６からコネクタ「Ａ」に進み、任意ブロック３０８は行わない。コネクタ「Ａ」に関連した処理は、図４に関して更に詳細に説明する。

ブロック３１０では、ブロック３０４でフェッチされ、デコードされる命令がメモリ書き込み命令（例えば、記憶命令など）か否かが判定される。肯定の場合、処理は任意ブロック３１２に進む。さもなければ、処理はブロック３１１に進む。

任意ブロック３１２は、メモリ書き込み命令がアトミック・ブロックの一部であるか否かを判定する。やはり、前述の判定のやり方は、種々の実現形態の実施例間で異なり得る。メモリ書き込み命令自体に前述の情報を埋め込まないが、「監視開始」命令を用いる実現形態の場合、前述の判定３１２はメモリ書き込み命令毎に行わなくてよい。その代わりに、前述のように、方法３００の実行の開始に先行して「監視開始」命令が実行されているものとする。やはり、前述の情報を制御レジスタに記憶することができる。前述の実施例の場合、処理はブロック３１０からコネクタ「Ｂ」に進み、任意ブロック３１２を行わない。コネクタ「Ｂ」に関連した処理は、図５に関連して更に詳細に説明する。

ブロック３０４においてフェッチされた現在の命令がメモリ読み出し命令でもメモリ書き込み命令でもない場合、処理はブロック３１１に進む。命令はブロック３１１において実行される。処理は次いでブロック３１４に進む。

「監視開始」及び「監視停止」命令を利用した実施例の場合、ブロック３１４が行われる。前述の実施例の場合、ブロック３１４における判定は、「監視停止」命令を受けなかった場合に「偽」と評価される。

ブロック３１４は、「監視開始」区分命令を利用せず、その代わりに、個々のメモリ命令とアトミック・ブロック・インディケータを関連付ける実施例の場合にも行われる。前述の実施例の場合、ブロック３１４における判定は、特定の種類の終結インディケータに達したか否かを判定する。少なくとも１つの実施例の場合、終結インディケータは、ＡＵＴ（１０８、図２）においてバッファリングされた更新をメモリにコミットすべきである、命令、又は、命令の演算コード若しくはプレフィックスであり得る。前述の実施例の場合、ブロック３１４における判定は、終結インディケータを受けなかった場合に「真」に評価される。

ブロック３１４における判定が「真」に評価された場合、次命令をフェッチするために処理はブロック３０４にループ・バックする。さもなければ、処理はブロック３１８において終了し得るか、又は、任意的にブロック３１６に進み得る。

トランザクション障害割り込みを受けることなく方法３００がブロック３１６に達した場合、アトミック・ブロックは、競合なく実行を首尾良く完了している。よって、アトミック・ブロックの実行中にバッファリングされたメモリ更新はメモリにコミット（３１６）することができる。ブロック３１６では、ＡＵＴ１０８からのバッファリングされたメモリ更新はよって、メモリにアトミックにコミットされる。ＡＵＴ１０８のエントリは次いでクリアすることができる。ブロック３１６においてメモリにＡＵＴ１０８のエントリをコミットするアトミック更新は、命令（アトミック・ブロックの最後の命令後にプログラマによって入力される）に応じて行うことができる。前述の命令（すなわち、投機実行コミット命令）の例示的な実施例は、表１に関して以下に更に詳細に説明する。

少なくとも１つの実施例の場合、他の動作もブロック３１６で行うことができる。例えば、アトミック・ブロックが実行を完了すると、後のメモリ読み出しのためにＡＭＴ１０６の更新をディセーブルするための動作を行うことができる。ＡＵＴテーブル１０８における後続メモリ書き込みのバッファリングもブロック３１６でディセーブルすることができる。方法３００の処理は次いで、ブロック３１８で終了する。

図４は、現在の命令がアトミック・ブロックのメモリ読み出し命令であることを図３のブロック３０６（及び、適宜、任意のブロック３０）における判定が示す場合に行われる処理「Ａ」の少なくとも１つの実施例を示すブロック図である。前述の場合、処理はブロック４０２に進む。ブロック４０２では、示されたメモリ・アドレスを読み出すために命令が実行される。処理は次いでブロック４０４に進む。

ブロック４０４で、示されたメモリ・アドレスがアドレス・モニタ・テーブル（「ＡＭＴ」）１０６に追加される。やはり、ＡＭＴ１０６は論理的構成である。例えば、ブロック４０４では、指定されたメモリ・アドレスを含めるようＡＭＴテーブルのエントリを実際に修正する代わりに、ブロック４０４の処理は別々の実施例についで違ったふうに処理することができる。一例に過ぎないが、チップ上のデータ・キャッシュに関連したステータス・ビットをトグリングして、キャッシュ・ラインにおけるメモリ・アドレスを、外部書き込みを求めて監視する旨を示すことができる。ＡＭＴ１０６がブロック４０４で更新された後、処理は図３のブロック３１４に戻る。

図５は、現在の命令がアトミック・ブロックのメモリ書き込み命令であることを図３のブロック３１０（及び、適宜、任意のブロック３１２）における判定が示す場合に行われる「Ｂ」を処理する少なくとも１つの実施例を示すブロック図である。前述の場合、処理はブロック５０２に進む。ブロック５０２では、メモリ書き込み命令が実行される。しかし、メモリ書き込み命令は、メモリを更新するのではなく、ＡＵＴ１０８のエントリを更新する。このようにして、アトミック・ブロック中に行われるメモリ書き込みは、ＡＵＴ１０８にバッファリングされる。

やはり、ＡＵＴ１０８は、論理的構成であり、種々のやり方でハードウェアにおいて実現することができる。例えば、少なくとも１つの例示的な実施例の場合、ＡＵＴ１０８をゲーティングされた記憶キューとして実現することができる。ＡＵＴ１０８がブロック５０２で更新された後、処理は次いで図３のブロック３１４に進む。

アトミック・ブロックの区分の特定の形態とともにＡＭＴ１０６及びＡＵＴ１０８を用いることによってハードウェア・スレッド投機実行がサポートされることを前述した。更に、特定の命令及び状態も前述の手法に統合することができる。併せて、前述の構成要素は、広範囲に亘る投機的スレッド化モデルを可能にするための投機的スレッドの効率的な実行を可能にすることができる。

図７は、論理ＡＭＴ１０６テーブル及び論理ＡＵＴ１０８テーブル、並びに特定のトランザクション実行状態９５０を含むスレッド・ユニット９０４の少なくとも１つの実施例を示すブロック図である。更に、スレッド・ユニット９０４は、アトミック・ブロックの各命令の境界における厳密な状態を提供するやり方でアトミック・ブロックのトランザクション実行をサポートすることができる特定の命令を実行することができ得る。

図７に示すトランザクション状態９５０は破線で示すように任意である。すなわち、実行コア９３０におけるハードウェア状態として維持される代わりに、特定されたメモリ・アドレスによるメッセージ・パスを介してメモリにおいて維持することができる。しかし、少なくとも１つの実施例の場合、トランザクション状態９５０は１つ又は複数のハードウェア・レジスタに維持される。

少なくとも１つの実施例の場合、トランザクション状態９５０を維持するためのレジスタは、トランザクション制御レジスタ９５１（本明細書及び特許請求の範囲では「ＴＣＲ」
として表す）及びトランザクション・スタータス・レジスタ９５２（本明細書及び特許請求の範囲では「ＴＳＲ」として表す）を含む。トランザクション制御レジスタは、ＡＭＴ１０６及びＡＵＴ１０８に対する更新を制御する。トランザクション・ステータス・レジスタはＡＭＴ及びＡＵＴの状態を通知することができ、トランザクション障害を示すこともできる。

トランザクション制御レジスタ９５１は、セットされると、ＡＭＴテーブル１０６、ＡＵＴテーブル１０８に関連した各種の挙動をもたらす種々のビットを含み得る。トランザクション制御レジスタ９５１は、メモリ更新がバッファリングされているか否か、及び、依存関係検査についてメモリ参照が監視されるか否かを制御することができる。例えば、トランザクション制御レジスタは、以下の挙動それぞれを表すための１つ又は複数のビットを含み得る。

ＡＵＴのリセットの強制
ＡＭＴのリセットの強制
ＡＭＴの直接更新
メモリ書き込みの直接バッファリング（ＡＵＴへの更新）
少なくとも１つの実施例の場合、複数の挙動を単一ビットによって示すことができる。例えば、トランザクション制御レジスタ９５１における単一ビットは、ＡＵＴ及びＡＭＴをリセットすべきである旨を表すことができる。

特定の一実施例の場合、トランザクション制御レジスタ９５１（「ＴＣＲ」）は、何れかの特定の時点においてフィールドに記憶された値に応じてＡＭＴ及びＡＵＴの挙動を判定し得るものであり、かつ／又は各命令の実行に影響を及ぼし得るフィールドを含む。当然、その他の実施例はより多いか、又はより少ないビットを利用することができる。トランザクション制御レジスタ９５１の実施例の場合、フィールドは以下のように定義することができる。特定のビット数を例証的な目的でのみ記載しており、限定的に解されないものとする。何れかの任意の長さのレジスタにおいて、以下に記載したビット・フィールドを実現する実施例の場合、以下に記載していない更なるフィールドは「予約済」であり得る。前述の予約済ビットは、書き込み無視、読み出しゼロとして実現することができる。

ＴＣＲリセット・ビット ＴＣＲ９５１の２つの１ビット・フィールドは、ＡＭＴ及びＡＵＴをリセットし、クリアするために用いられる書き込みのみのビットであり得る。

ＡＭＴクリア・ビット（ＴＣＲビット０、書き込みのみ）は、ＡＭＴのリセットを制御する。「１」がこのビット位置に書き込まれた場合、有効なエントリが存在しないようにＡＭＴがクリアされる。ＡＭＴクリア・ビットは０を示す。

ＡＵＴクリア・ビット（ＴＲＣビット１、書き込みのみ）は、ＡＵＴのリセットを制御する。「１」がこのビット位置に書き込まれた場合、バッファリングされた投機的メモリ更新は廃棄される。ＡＵＴクリア・ビットは０を示す。

ＴＣＲ更新ビット ＴＣＲ９５１の２つの１ビット・フィールドを用いて、ＡＭＴ又はＡＵＴの更新に関する命令実行の挙動を制御することができる。

ＡＭＴ更新ビット（ＴＲＣビット２）は、ＡＭＴの更新を制御する。ＡＭＴ更新ビットがセットされた場合（「１」の値）、ＡＭＴは、命令によって読み出されるメモリ位置毎に更新される。セットされない場合（「０」の値）、ＡＭＴは、命令が実行された際に更新されない。ソフトウェアは、監視されたメモリ参照及び監視されないメモリ参照を混ぜることを可能にするようこのビットの状態をトグリングすることが可能である。ＡＭＴ更新ビットがセットされ、トランザクションに障害が生じた場合（ステータス・ビット参照）、ＡＭＴは更新しなくてよい。

ＡＵＴ更新ビット（ＴＲＣビット３）は、リングレベル３（ユーザ・モード）においてメモリ更新のバッファリングを制御する。ＡＵＴ更新ビットがセットされた場合（「１」の値）、命令によってリングレベル３において行われたメモリ更新はバッファリングされ、トランザクション・コミット処理までメモリに対して行われない。ビットがセットされない場合（「０」の値）、命令によるメモリ更新はバッファリングされず、通常と同様に、メモリに対して直接行われる。ＡＵＴ更新ビットがセットされ、トランザクションに障害が生じた場合（スタータス・ビット参照）、リングレベル３において行われたメモリ更新はバッファリングしなくてよく、単に廃棄することができる。

任意のＴＣＲビット 別の実現形態は、ＴＣＲにおいて定義される対象の以下のフィールドの１つ又は複数を提供することができる。

ＡＵＴ非バイパス・ビット（ＴＣＲビット６）は、ＡＵＴがイネーブルされた場合に通常行われるような書き込み後読み出しバイパスについてＡＵＴを検査することなくそのメモリ位置の値を命令が確かめることによってメモリ読み出しを引き起こす。上記ビットが実現形態においてサポートされない場合、ビットのセット（値「１」の書き込み）の試行によって、モードがサポートされないビットが、トランザクション・スタータス・レジスタにおいてセットされる。これは、アクティブなトランザクションの障害を強いる。

ハンドラにおけるＡＵＴ更新（ＴＣＲビット７）は、３より低いリングレベルにおいてメモリ更新を実施する。ＡＵＴイネーブル・ビットとこのビットが両方セットされた場合（「１」の値）、何れのリングレベルにおけるメモリ更新もＡＵＴにバッファリングされる。リングレベル３におけるこのビットに対する更新は無視される（値は変わらない）。このビットは、（トラップ／例外／割り込みで）リングレベル３から、より低いリングレベルへの遷移でゼロに自動的にクリアされ得る。このビットが実現されない場合、３よりも低いリングレベルにおける更新の試行は、トランザクション・ステータス・レジスタにおいてトラップ・フォース障害ビットをセットさせ得る。これは、アクティブなトランザクションの障害を強いることがあり得る。

トランザクション・ステータス・レジスタ９５２は、アトミック・ブロックの実行に関する特定のステータス状態を反映するための１つ又は複数のビットを含み得る。トランザクション・ステータス・レジスタ９５２の内容は、トランザクションのステータスを示し得るものであり、トランザクション障害を示し得る。例えば、トランザクション・ステータス・レジスタ９５２は、以下のステータス状態を表すための１つ又は複数のビットを含み得る。

トランザクション障害が生じたか否か
トランザクション障害の理由（障害が生じた場合） このフィールドの値はオーバフロー、衝突等を含み得る。

ＡＭＴ状態 このフィールドの値は、フル、フルでない、空き、空きでない等を含み得る。

ＡＵＴ状態 このフィールドの値は、フル、フルでない、空き、空きでない等を含み得る。

アトミック・ブロックの実行中にトラップが行われたか否か
トラップがトランザクション障害を引き起こしたか否か
特定の一実施例の場合、トランザクション・ステータス・レジスタ９５２（「ＴＳＲ」）は、ＡＭＴ、ＡＵＴ及び現在のトランザクションの一般的な状態についてのステータス情報を、何れかの特定の時点においてフィールドに記憶されている値に応じて提供し得るフィールドを含む読み出し専用レジスタである。当然、その他の実施例は、より多くの、又はより少ないビットを利用することができる。トランザクション・ステータス・レジスタ９５２の実施例の場合、フィールドは以下のように定義することができる。特定のビット番号は例証の目的でのみ記載しており、限定的に解されないものとする。任意の容量のレジスタにおいて、後述のビット・フィールドを実現する実施例の場合、以下に記載されていない更なるフィールドは「予約済」であることがあり得る。前述の予約済ビットは、書き込み無視、読み出しゼロとして実現することができる。

少なくとも一実施例の場合、ＴＳＲ９５２の最初のビットは、現在のトランザクションに障害が生じているかを示す。次の４ビットは、ＡＭＴ及びＡＵＴの状態についての情報ビットである。第６のビットは、アクティブなトランザクションが存在していた（ＡＭＴ及び／又はＡＵＴが空きでない）間に生じたトラップ／例外／割り込みを示す。最後のビット組は、現在のトランザクションに障害が生じていることを示し、その理由についての情報を提供するために用いることができる。

ＴＳＲのビットそれぞれは、特定の状況においてハードウェアによってセットすることができる。各ビットは１つ又は複数のイベントによって影響され得る。複数のイベントが同時に生じた場合、ビットをクリアするイベントは、ビットをセットするイベントよりも高い優先度を有し得る。

トランザクション障害ビット 現在のトランザクションに障害が生じた場合、トランザクション・ステータス・レジスタの第１のビットがセットされる）最後の８個のステータス・ビット（ビット６乃至ビット１３）がセットされる。

トランザクション障害ビット（ＴＳＲビット０）は、現在のトランザクションに障害が生じたことを示す。このビットがセットされている場合、障害の原因を示すようビット６乃至ビット１３のうちの少なくとも１つもセットされる。

情報ビット ＴＳＲの次の４ビットは、ＡＭＴ及びＡＵＴのステータスについての情報ビットである。ＡＵＴ若しくはＡＭＴ、又は両方が空きでない場合、トランザクションはアクティブであるとみなされる。これは、以下に定義する空きでないビットによって示す。上記ビットは以下の通りである。

空きでないＡＭＴビット（ＴＳＲビット１）は、少なくとも１つの有効エントリをＡＭＴが有していることを示す。

ＡＭＴフル・ビット（ＴＳＲビット２）は、ＡＭＴがフルであるか又はほとんどフルであることを示す（厳密な定義は、実現形態に依存する）。ＡＭＴへのその後の更新によって、構造がオーバフローする可能性が高くなることをこのビットは示す。

空きでないＡＵＴビット（ＴＳＲビット３）少なくとも１つのバファリングされたメモリ更新をＡＭＴが有していることを示す。

ＡＵＴフル・ビット（ＴＳＲビット４）は、ＡＵＴがフルであるか又はほとんどフルであることを示す（厳密な定義は、実現形態に依存する）。ＡＭＴへのその後の更新によって、（既にオーバフローしていない場合）構造がオーバフローする可能性が高くなることをこのビットは示す（まだオーバフローしていない場合）。

トラップ・ビット ＡＭＴ１０６又はＡＵＴ１０８が空きでない場合にトラップ／例外／割り込みが生じたことを示すためにＴＳＲ９５２の第５のビットをトラップ・ビットとして用いることができる。このビットは、トランザクション・クリア・トラップ・ビット命令（例えば、以下の表１におけるＴＲＮＸＯＫ命令）によってクリアすることが可能である。トラップ・ハンドラが戻った場合、又は、その後のトラップ／例外／割り込みが生じた場合にこのビットがなおセットされている場合、トラップ・フォース障害ビットがセットされ、トランザクションに障害が生じ得る。

トラップ・ビット（ＴＳＲビット５）は、ＡＭＴ又はＡＵＴが空きでない場合に、トラップ・ビット（ＴＳＲビット５）は、ハードウェアによってトラップ／例外／割り込みの際に自動的にセットすることができる。ユーザレベル・ハンドラに対してビットをセットすることはできない。トランザクションセーフであることを知っているトランザクションアウェア・ハンドラは、トランザクション・クリア・トラップ・ビット命令によってハンドラに入る際にこのビットをクリアし得る（例えば、以下の表１のＴＲＮＸＯＫ命令参照）。このようにして、トラップ／例外／割り込みが行われた際に行われたアトミック・ブロックの実行をイベントの処理後に再開することができるようにトラップ又は例外を非障害状態として処理することができる。

トランザクション障害ビット トランザクションに障害が生じたことを示すフィールドとしてＴＳＲ１０８の次の８ビットを用いることができる。アクティブなトランザクションが存在しており（ＡＵＴ１０６及びＡＭＴ１０８の一方又は両方が空きでなく）、以下の８ビットの何れかがセットされた場合、トランザクションに障害が生じたとみなされる。

ＡＭＴオーバフロー・ビット（ＴＳＲビット６）は、ＡＭＴがオーバフローし、トランザクションによって読み出される少なくとも１つのメモリ位置が、監視のためにＡＭＴにおいてログインされていないことを示す。

ＡＭＴコヒーレンシ衝突ビット（ＴＳＲビット７）は、ＡＭＴに、エントリと、メモリへの外部更新との間で衝突、又は衝突の可能性（保守的な近似は許容される）があった旨を示す。

ＡＭＴオーバフロー・ビット（ＴＳＲビット８）は、ＡＵＴがオーバフローしており、バッファリングされるはずであった少なくとも１つのメモリ更新が廃棄されていることを示す。

ＡＵＴコヒーレンシ衝突ビット（ＴＳＲビット９）は、ＡＵＴがコヒーレンシ・イベントをみた（バッファリングされた更新を完了することを可能にしない）ことを示す。

ＡＵＴバッファ・バイパス不可ビット（ＴＳＲビット１０）ＡＵＴ内の更新バッファリングをバイパスした直接メモリ更新をプロセッサがサポートしない場合に、ＡＵＴがイネーブルされ、空でない間にＡＵＴ更新ビットがクリアされた場合、このビットはハードウェアでセットすることができる。

ＡＵＴ障害ＲＡＷビット（ＴＳＲビット１１）は、正しい書き込み後読み出しの意味論を提供するためにＡＵＴからバイパスされた値を得ることができなかったか、又は、ＡＵＴにおける更新に関してあいまいさがあり、ロードの正しい値を求めることができなかったので、実行されるロードが、不整合の値をみたことがあり得ることを示す。あいまいさがある場合、ロードについて戻される値は、メモリからの値であり、ＡＵＴからの値でない。

トラップ強制障害ビット（ＴＳＲビット１２）は、ＡＭＴ又はＡＵＴが空きでなかった状態にある間にトラップ／例外／割り込みによって障害が強制されたことを示す。これは、より下位のリングレベルへの遷移の動作による特定の動作、又はより下位のリングレベル内の動作によって、アクティブなトランザクションに障害をもたらすことを示す。ＡＵＴが空きでなく、プロセッサは、バッファリングされた更新をバイパスするメモリ更新をサポートしないのでこのビットをセットすることが可能である。このビットは、トラップ／例外／割り込みが生じた場合、又はトラップ／例外／割り込みからの戻りが生じ、トラップ・ビット（ＴＳＲビット５）が現在セットされている場合、このビットもハードウェアによってセットすることができる。

サポートされないモード・ビット（ＴＳＲビット１３）は、トランザクション制御レジスタへの書き込みが、サポートされないモードにプロセッサを入れようとする場合、ハードウェアによって自動的にセットされる。

ＡＭＴ１０６に関連したＴＳＲ９５２ステータス・ビット全ては、ＡＭＴ１０６がクリアされた場合にゼロに自動的にクリアすることができる。前述のクリアは例えば、ＴＣＲ９５１のＡＭＴクリア・ビットへの「１」の書き込みに応じて、又はトランザクション・コミット命令に応じて行うことができる。

同様に、ＡＵＴ１０８に関連したＴＳＲ９５２ステータス・ビット全ては、ＡＵＴ１０８がクリアされた場合にゼロに自動的にクリアすることができる。前述のクリアは例えば、ＴＣＲ９５１のＡＵＴクリア・ビットへの「１」の書き込みに応じて、又はトランザクション・コミット命令によって行うことができる。

ＡＭＴ１０６及びＡＵＴ１０８が同時にクリアされるか、又はＡＭＴ１０６又はＡＵＴ１０８がクリアされ、他方の構造が空きの場合に、ＴＳＲ９５１の残りのビット全て（すなわち、ＡＭＴ１０６又はＡＵＴ１０８に直接関連していないもの）を自動的にゼロにクリアすることができる。クリアは、ＴＣＲ９５１のＡＭＴ１０６クリア・ビット及び／又はＡＵＴ１０８クリア・ビットに対する書き込みによって、又はトランザクション・コミット命令によって行うことが可能である。

図７は、メモリ・システム９０２に記憶されたユーザ・プログラム９６０が、いくつかのマルチスレッド・パラダイムの何れかの実現に有用な命令を含み得ることを示す。前述の命令を用いれば、例えば、プログラマは、トランザクション実行、ＳＰＥ、ロック回避、及び／又はその他のマルチスレッド・プログラミング・パラダイムを実現することができる。

図７は、何れか又は全ての前述の命令の使用が任意であることを破線によって示す。本発明の少なくとも一実施例によるスレッド・ユニット９０４は、以下に表１に表す命令又は「プリミティブ」の１つ又は複数のデコードし、実行することができる。一般に、命令は以下のうちの１つ又は複数を含み得る。トランザクション制御レジスタに書き込むための命令、バッファリングされたメモリ更新のコミットをトリガするための命令、トランザクション・ステータス・レジスタを読み出すための命令、及び／又は、トラップ／例外／割り込み処理に関連したトランザクション・ステータス・レジスタ・ビットの１つをクリアするための命令。当然、別の実施例は、上記機能を実現するために、表１に示すものよりも多いか、又は少ない命令を用いることができる。

ＴＲＮＸＳＥＴ命令は、少なくとも一実施例の場合、トランザクション制御レジスタ（ＴＣＲ）９５１に値を書き込む。ＴＲＮＸＳＥＴ命令の実行は、トランザクションの開始又は障害ももたらし得る。命令を用いて、メモリ読み出し（ロード）アドレスの監視を一時的にディセーブルすることもできる。

ＡＭＴ１０６及びＡＵＴ１０８がクリアされるようＴＣＲ９５１にビットをセットすることにより、かつ、アトミック・ブロックにおけるメモリ命令に基づいてテーブル１０６、１０８の更新及び検査をもたらすようＴＣＲ９５１にビットをセットすることにより、トランザクションの最初を区分するためにＴＲＮＸＳＥＴを用いることが可能である。ＴＲＮＸＳＥＴ命令の実行の結果としてＴＣＲ９５１に書き込まれる値は、ソース・レジスタにおける値に基づき得る。ソース・レジスタのビットの一部分を、ＴＣＲに書き込む対象の値として用いることができる。ソース・レジスタのビットの別の部分を保存マスク（更新マスクの逆）として用いることができる。保存マスクにおいてゼロを値を備えた各ビットは、更新値からの値によって更新された、ＴＣＲにおける値を有する一方、保存マスクにおいて１の値を備えた各ビットは、その先行値として保存されたＴＣＲにおける値を有する。ＴＲＮＸＳＥＴ命令は、何れの特権レベルでも実行することが可能である（しかし、通常、ＣＰＬ３において、又は、トランザクションアウェアな特定のトラップ・ハンドラにおいてのみ用いられるものとする）。

トランザクション内のアドレス監視をオフにし（ＡＭＴ更新をオフにし）、その後、監視をオンにして、特定のメモリ・アドレスをＡＭＴに監視させることなく特定のメモリ・アドレスのアクセスを可能にするために、ＴＲＮＸＳＥＴ命令を用いることも可能である。ブロックの障害につながることなくヘッド・トークンの概念を投機的ブロックに渡すことが可能であるように投機的マルチスレッド（マルチスカラ）実行を実現するためにこのことは重要である。

ＡＭＴ及びＡＵＴをクリアし、ＴＣＲ９５１を「ディセーブル」及び「更新なし」にセットすることによって、トランザクションの障害を強制するために、ＴＲＮＸＳＥＴ命令を用いることも可能である。

少なくとも一実施例の場合、ＴＲＮＸＣＭＴ命令の実行によって、プロセッサ９０４にトランザクション・ステータス・レジスタ９５２（ＴＳＲ）の値を検査させることができる。トランザクション障害ビットがセットされていない場合、ＴＲＮＸＣＭＴ命令の実行によって、アトミックに実行されているようにみえるようにメモリ９０２に対して、ＡＵＴ１０８からのバッファリングされたメモリ更新をプロセッサ９０４に行おうとさせることができる。

ＴＲＮＸＣＭＴ命令の実行は、ＡＭＴ１０６及びＡＵＴ１０８をプロセッサ９０４にクリアさせることができる。前述の実行は、トランザクション制御レジスタＴＣＲ９５１を全てゼロの値にクリアすることもできる。ＡＵＴ１０８からのバッファリングされた更新を首尾良く行ったかを示すための値をＴＲＮＸＣＭＴ命令は、ソース・レジスタに戻すことができる。更新を行うことが可能でなく、その代わりに、更新が廃棄された場合、プロセッサ９０４は、ゼロの値でソース・レジスタを更新することができる。更新が行われた場合、プロセッサ９０４は、ソース・レジスタを非ゼロ値で更新することができる。ＡＵＴ１０８が空きの場合、少なくとも１つの実施例の場合、コミットは首尾良く行われたとみなすことができ、非ゼロ値をソース・レジスタに戻すことができる。

ＴＲＮＸＲＤ命令の実行は、トランザクション制御レジスタ（ＴＣＲ）９５１及びトランザクション・ステータス・レジスタ（ＴＳＲ）９５２の値をデスティネーション・レジスタに、プロセッサ９０４に読み出させることができる。少なくとも１つの実施例の場合、トランザクション制御レジスタ９５１の値を、特定の固定量だけ左シフトさせ、トランザクション・ステータス・レジスタ９５１の値とのＯＲをとって、デスティネーション・レジスタに書き込まれる値を生成する。

少なくとも１つの実施例の場合、ＴＲＮＸＯＫ命令の実行は、トランザクション・ステータス・レジスタのトランザクション・トラップ・ビット（ビット５）にゼロの値を、プロセッサ９０４に書き込ませる。トランザクション・トラップ・ビットがセットされると、アトミック・ブロックの実行中にトラップが行われた場合に、トラップ・ハンドラは、誤差の強制を回避することができる。

すなわち、ＴＲＮＸＯＫ命令を用いることにより、かつ、ＴＣＲ９５１に特定のビットをセットすることにより、プログラマは、トラップ・ハンドリング中にＡＵＴ／ＡＭＴを更新するか否かを明示的に制御する。デフォールトによって、オフの間、トラップを行うことによってＡＭＴ１０６テーブル及びＡＵＴ１０８テーブルが更新されるようにプロセッサ９０４を構成することができる。前述のデフォールト動作の場合、アトミック・ブロック中に行われるトラップによってトランザクションが終結し、ＡＭＴ１０６及びＡＵＴ１０８が静止する。トラップが戻ると、トランザクションには障害が生じ、中間状態を廃棄させる。しかし、前述のデフォールト動作は、ＴＲＮＸＯＫ命令によって無効にされ得る。それによって、アトミック・ブロックの実行中にトラップが行われた場合にトランザクション障害を強制することをトラップ・ハンドラが回避することが可能になり、アトミック・ブロックの実行中に生じるトラップ又は例外の処理にわたってＡＭＴ１０６及びＡＵＴ１０８の状態が持続することが可能になる。前述の実施例では、トラップが戻った場合、トランザクションに障害は生じず、アトミック・ブロックの実行は、トラップ又は例外が生じた時点に存在した厳密なプロセッサ状態から再開し得る。

少なくとも１つの実施例の場合、ＴＲＮＸＯＫ命令の動作は、トラップ・ハンドラが作業をトランザクションの一部として実行することを可能にする。ＴＣＲ９５１の現在値によって示された場合、ＡＭＴ１０６及びＡＵＴ１０８のテーブルをトラップ処理中に更新することができる。よって、少なくとも１つの実施例の場合、少なくとも一部の種類のトラップ及び例外は、アトミック・ブロック内から処理することができる。

プロセッサ９０４の少なくとも１つの実施例は、アトミック・ブロックにわたる単一ステッピングを可能にし得る。このことは、ＡＭＴ１０６及びＡＵＴ１０８の値を維持しながら、アトミック・ブロック外部から単一ステップ・デバッガを実行することを可能にする。この効果として、プログラマは、本発明の少なくとも１つの実施例によれば、アトミック・ブロックにわたってシングルステップし、各命令の最後におけるアークテクチャ状態をみることができる。前述の手法は、ソフトウェア・デバッグの従来の手法をアトミック・ブロック内で用いることを可能にする。

この特徴は、アトミック・ブロックの命令の実行中に中間状態が未定義である他の手法と対照的である。前述の手法の場合、中間状態は、トラップを処理することができるか、又はシングルステップを行うことができる前にコミット若しくは廃棄される。

少なくとも１つの他の実施例の場合、ＴＲＮＸＯＫ命令は、トラップ・ハンドラが作業をトランザクションの一部として行うことを可能にし得るが、トラップ・ハンドラは、アトミック・ブロック外部から、ＡＭＴ１０６テーブル及びＡＵＴ１０８テーブルをバイパスして、メモリとの間で直接、読み出し、書き込むことができる。ＡＭＴ１０６及びＡＵＴ１０８をバイパスするか否かは、ＴＣＲ９５１の値によって示すことができる。前述の手法は、トラップ・ハンドラがアトミック・ブロック外部にある間に実行することを可能にする。

要約すれば、投機的スレッドにおける命令ブロックをトランザクション・ブロックとして区分し、更新がバッファリングされ、後に廃棄されるか、又は後にアトミックに実行されるようにハードウェアに実行させることを可能にする命令セット拡張組として実現することができる。上記拡張は、外部更新を検出してメモリ依存関係を検出するようメモリ・アドレス読み出しを監視するようにすることもできる。前述の拡張はよって、ソフトウェアが投機的スレッド実行を試行することを可能にすることができる。このハードウェアは、投機的スレッドの効率的な実行が、広範囲の投機的スレッド化モデルを可能にするためのサポートを提供する。

前述の命令をサポートするプロセッサ（図７に示すプロセッサ９０４など）には、投機的トランザクションが首尾良く行われることの何らかの保証を備えることが必ずしも要求されない。その代わりに、ハードウェアは、障害をソフトウェアに正しく通知する限り、トランザクションを処理できなくてもよい。

図６は、トランザクション・ブロックの実行に障害が生じたと判定するための機構の少なくとも１つの実施例を示すデータフロー図である。図６は、２つの協調型スレッド（スレッドＡ１２５及びスレッドＢ１２６）を示す。当然、図６に示す機構は、何れかの数（Ｙ）の協調型スレッド（Ｙ＞２）に用いることができることを当業者は認識するであろう。

図６は、第１の時間ｔ１（第１の協調型スレッド１２５が、アトミック・ブロック６０２の実行を開始する）を示す。時間ｔ２での、アトミック・ブロック６０２の実行中に、第１のスレッド１２５は、特定のアドレスのメモリ読み出し命令を実行する。メモリ・アドレス「０００Ａ」として図６に示すアドレスが、命令が実行される時間（ｔ２）においてＡＭＴ１０６に入力される。

図６は、時間ｔ３で、第２のスレッド（スレッドＢ１２６）が、第１のスレッドによって読み出されたメモリ・アドレスに対する書き込みを実行する。第２のスレッドによる更新は、第１のスレッドがメモリ・アドレスを読み出した後に、かつ、第１のスレッド（スレッドＡ１２５）が実行を完了する前に生じる。前述の、アトミック・ブロックの実行中に第１のスレッドによって既に読み出されているアドレスへの第２の協調型スレッドによる書き込みの試行は、ハードウェアによって認識される。ＡＭＴ１０６におけるアドレスの１つに対する「外部」書き込みとして認識されるからである。前述のイベントは、アトミック・ブロック６０２の実行に障害が生じたことを示すよう非同期イベントを引き起こし得る。

図６に示すデータフロー図は、アトミック・ブロックの実行中の障害の一インスタンスのみを示す。先行して読み出されたメモリ・アドレスに対する外部書き込み以外の他のイベントによって、アトミック・ブロックの実行に障害が生じることがあり得る。前述のイベントの１つとして、例えば、「テーブル・フル」、又はＡＭＴ１０６若しくはＡＵＴ１０８のオーバフローがある。前述の別のイベントとして、例えば、ＡＵＴ１０８における書き込み後読み出し（「ＲＡＷ」）違反がある。コヒーレンシ衝突等などの他の障害状態も実現することができる。

アトミック・ブロックの実行に障害が生じたことをソフトウェアに通知するための種々の機構を利用することができる。アトミック・ブロックの障害を生じさせ得る何れかのイベントの場合、前述のイベントは、割り込みなどの非同期イールド・イベント（ｙｉｅｌｄ ｅｖｅｎｔ）としてスレッド・ユニット（例えば、図２のスレッド・ユニット１０４など）によって通知することができる。少なくとも１つの実施例の場合、障害イベントはユーザ・レベル割り込みを引き起こすことができる。

トランザクション実行の障害を示すためのユーザ・レベル割り込みを実現する１つのやり方は、本明細書及び特許請求の範囲では、ユーザ・レベル・フライ級割り込み処理として表す。前述の機構は、特定のトリガ・イベントを示すことができるチャネルを含み得る。トリガ・イベントは「シナリオ」として表すことができる。トリガ・シナリオは、アーキテクチャ的に定義された１つ又は複数のイベント組であり得る。あるいは、トリガ・シナリオは、ユーザ定義された１つ又は複数のイベント組であり得る。チャネルに規定されたトリガ・シナリオを検出すると、制御をユーザレベル・ハンドラ・ルーチンに移すことができる。前述のユーザ・レベル・フライ級割り込み処理機構の少なくとも１つの実施例の更なる説明は、「Ａ ｐｒｏｇｒａｍｍａｂｌｅ ｅｖｅｎｔ ｄｒｉｖｅｎ ｙｉｅｌｄ ｍｅｃｈａｎｉｓｍ ｗｈｉｃｈ ｍａｙ ａｃｔｉｖａｔｅ ｓｅｒｖｉｃｅ ｔｈｒｅａｄｓ」と題する同時係属中の特許出願（代理人整理番号Ｐ１４９１２Ｘ）で見つけることができる。

図７に示すプロセッサ実施例９０４の場合、本明細書及び特許請求の範囲記載のトランザクション実行手法の１つ又は複数の実施例をサポートするための１つ又は複数のシナリオを定義することができる。少なくとも１つの実施例の場合、ＴＳＲ９５２の内容が変わると割り込みが生成されるようなシナリオ（「ステータス更新シナリオ」）を定義することができる。すなわち、ＴＳＲ９５２の内容が、特定のやり方で更新されると、割り込みを生成することができる。

ステータス更新シナリオは、トランザクション・ステータス・レジスタ（ＴＳＲ）をマスクによって監視することによって実現することができる。ステータス更新シナリオはよって、ＴＳＲに施されるマスクに関連付けることができる。マスクのＡＮＤ演算、及びＴＳＲが非ゼロ値をもたらし、プロセッサがリングレベル３にある場合、シナリオは、ユーザ・レベルのイベント・ハンドラをトリガし得る。トランザクションに障害が生じた旨をＴＣＲ９５２が示す場合に、ステータス更新シナリオに基づいた割り込みを生成することができるようにマスクを定義することができる。

よって、障害をソフトウェアに正しく通知する限り、図７に示すプロセッサ９０４などのプロセッサがトランザクションを処理できなくてもよいことを上記説明は示す。すなわち、前述のハードウェア手法に基づいて、アトミック・ブロックが首尾良く実行されることをプログラマは保証されない。少なくとも１つの実施例の場合、他の協調型スレッドからの競合なしでアトミック・ブロックが実行を完了することを確実にするために、必要な場合、１つ又は複数のユーザレベル・ソフトウェア命令をプログラマが用いることができるように更なる機能がプロセッサ９０４によって提供される。前述の更なる機能は、本明細書及び特許請求の範囲では、「ストップザワールド」機能として表す。

多数のメモリ命令（例えば、ロード及び／記憶命令）をアトミック・ブロックが含んでいてもアトミック・ブロック実行を確実にするためにストップザワールド機能を利用することができる。他のトランザクションとアトミック・ブロックが常に衝突してもアトミック・ブロック実行を確実にするためにストップザワールド機能を利用することもできる。一般に、そのソフトウェアが前述の命令（表１参照）を用いて投機的コード・ブロックを実行しようとし、有限の資源限度の理由で、又は、反復的メモリ相互関係違反の理由で、首尾良い実行の可能性が低いと判定した場合にストップザワールドをソフトウェアで利用することができる。ソフトウェアは、投機的スレッド化ハードウェアを用いることなくストップザワールド・プログラミング抽象化を起動させることができる。

ＡＭＴ１０６やＡＵＴ１０８などの論理構造に依存するのでなく、アトミック・ブロックの実行中に他の協調型スレッド全てを停止することによってアトミック性を保証するようユーザ・レベル割り込みを利用するソフトウェア層（ライブラリやランタイム・ルーチンなど）によってストップザワールドを提供することができる。ストップザワールド機能は、プロセッサ９０４によってサポートされる２つの割り込みシナリオを利用することができる。

ストップザワールドを実現するよう利用することができる第１のシナリオは、外部更新シナリオである。すなわち、上記シナリオは、外部更新を求めて、特定のメモリ・アドレスを監視し、前述の更新が生じた場合に割り込みを生成するための機能を提供する。「外部」更新は、メモリ・アドレスにおける値が別の協調型スレッドによって書き込まれたことを意味するものと理解し得る。よって、下にあるプログラミング・モデルの実現における同期化のために他の協調型スレッド全てを一スレッドが割り込む機構を外部更新シナリオは提供することができる。より早い投機的タスクが完了しており、投機的タスクが非投機的になるよう移行することが可能である状態になった時点で投機的タスクが通知されることが可能であるようにこの同じシナリオを用いることもできる。

ストップザワールドを実現するよう利用することができる第２のシナリオは、「特権から復帰」のシナリオである。第２のシナリオは、トラップ／例外／割り込みハンドラからユーザ・コードに制御が戻った時点でユーザハンドラを呼び出すというものである。上記シナリオは、リングレベル３への移行が生じた時点を検出し、ユーザレベル・ハンドラを呼び出す。前述のシナリオは基本的には、トラップ／例外／割り込みハンドラからリングレベル３に制御が戻る都度、ユーザレベル・ハンドラが呼び出されることを可能にする。このスレッドが同期化されるべきソフトウェアをその協調型スレッドが現在実行しているかをスレッドが検査することをこのシナリオは可能にする。スレッドがハンドラにあったか、又は、アクティブにスケジューリングされていなかった状態で協調型スレッドが同期化されていた場合にこのことは生じ得る。

前述の２つのシナリオを利用して、停止協調型スレッドからの衝突なしで特定の協調型スレッドがアトミック・ブロックを実行することができるようにプログラムは他の協調型スレッド全てを停止することができる。

ストップザワールドは、前述の更なるハードウェア構造１０６、１０８、状態９５１、９５２、及び命令（表１参照）（本明細書及び特許請求の範囲では、「ハードウェア」実施例として表す）なしでトランザクション実行を実現する別のやり方である。前述の手法は併せて用いることができる。アトミックであるという意味論によって実行するコード・ブロックが存在しているという概念をソフトウェア・プログラムが可能にするプログラミング・モデルが非常に望ましいことがあり得る。前述のハードウェア手法の実施例によってトランザクション実行に障害が生じた場合にプログラミング意味論を維持するためにストップザワールドを用いることができる。

前述の、外部更新シナリオ、及びハンドラからの復帰のシナリオを用いて、ストップザワールド挙動を実現することが可能である。そうするために、アトミック・ブロックを実行したいスレッドは、同期化に用いる所定のメモリ位置との交換を行うことができる。交換によって、メモリ位置に「ビジー」値を書き込むことができ、先行値が「アイドル」値であったことを確認することができる。先行値が「アイドル」でなかった場合、「アイドル」値が検出されるまでスレッドを繰り返すことができる。

協調型スレッドは全て、この同期化位置を監視するための手法を有し得る。少なくとも１つの実施例の場合、各協調型スレッドは、アクティブな「外部更新」シナリオをチャネル内に有し得るので、自分であるシナリオの状態に応答して割り込みが生成される。少なくとも１つの実施例の場合、「ビジー」値が同期化位置に書き込まれた場合、シナリオは充足され、ユーザ・レベル割り込みは、適宜、他の協調型スレッド全てについて生成される（別の実施例の場合、ユーザ・レベル割り込み機構ではなく、メモリ・インタフェースを通るメッセージを介して、同様な機能を実現することが可能である。）協調型スレッド毎の関連したイベント・ハンドラは、同期化位置における値が「アイドル」値に戻されるまで、スピン・ロックやその他の待ちモードに協調型スレッドを移させることができる。

全協調型スレッドは更に、アクティブな「リングレベル３への復帰」シナリオをチャネルにおいて有し得る。トラップ／例外／割り込みハンドラからユーザ特権レベルに制御が戻ると、協調型スレッドはよって、中断することができ、割り込みハンドラを呼び出すことができる。シナリオを充足すると、割り込みを生成することができる。関連した割り込みハンドラは、協調型スレッドに、同期化位置及びスピン・ロックを確認させるか、又は他の待ちモードによって待たせることができる（同期化位置における値が「アイドル」でない場合）。

有限時間の間待った後、他の協調型スレッド全てが同期化イベントを観察し、実行をストールする時間を与えるために、ストップザワールドを起動させたスレッドは次いで、アトミック・ブロックを実行することが可能である。アトミック・ブロックの最後に、スレッドは、協調型スレッド全てが実行し続けることが可能であるようにアイドル値を同期化位置に書き込むことができる。

本明細書及び特許請求の範囲記載の機構の実施例は、ハードウェア、ソフトウェア、ファームウェア、又は前述の実現機構の組み合わせで実現することができる。本発明の実施例は、少なくとも１つのプロセッサ、データ記憶システム（揮発性及び不揮発性のメモリ及び／又は記憶素子を含む）、少なくとも１つの入力装置、及び少なくとも１つの出力装置を備えるプログラム可能なシステム上で実行するコンピュータ・プログラムとして実現することができる。プログラム・コードを入力データに施して、本明細書及び特許請求の範囲記載の機能を行い、出力情報を生成することができる。出力情報は、既知のやり方で１つ又は複数の装置に入力することができる。本出願の目的で、処理システムは、プロセッサ（例えば、ディジタル信号プロセッサ（ＤＳＰ）、マイクロコントローラ、特定用途向集積回路（ＡＳＩＣ）やマイクロプロセッサなど）を有する何れかのシステムを含む。

プログラムをハイレベルの手続型プログラミング言語又はオブジェクト指向型プログラミング言語で実現して処理システムと通信することができる。プログラムは、所望の場合、アセンブラ言語又はマシン言語で実現することもできる。実際に、本明細書及び特許請求の範囲記載の機構の範囲は、何れかの特定のプログラミング言語に限定されるものでない。いずれにせよ、言語はコンパイラ言語又はインタープリタ言語であり得る。

プログラムは、汎用又は専用のプログラム可能な処理システムによって読み取り可能な記憶媒体上又は装置上（例えば、ハード・ディスク・ドライブ上、リードオンリメモリ（ＲＯＭ）上、ＣＤ−ＲＯＭ装置上、フラッシュ・メモリ装置上、ディジタル多用途ディスク（ＤＶＤ）上やその他の記憶装置上）に記憶することができる。処理システムにおけるプロセッサにアクセス可能な命令は、本明細書及び特許請求の範囲記載の手順を行うために記憶媒体又は記憶装置が処理システムによって読み出されると処理システムを構成し、動作させるようにする。本発明の実施例は、処理システムに用いるよう構成されたマシン読み取り可能記憶媒体として実現するものとすることもできる。そうして構成された記憶媒体は、本明細書及び特許請求の範囲記載の機能を行うために特定かつ所定のやり方で処理システムが動作するようにする。

前述のタイプの処理システムの例は図７に示す。システム９００は、インテル社から入手可能なペンティアム（登録商標）、ペンティアム（登録商標）プロ、ペンティアム（登録商標）ＩＩ、ペンティアム（登録商標）ＩＩＩ、ペンティアム（登録商標）４、並びにアイテニアム（登録商標）及びアイテニアム（登録商標）ＩＩのマイクロプロセッサに基づいた処理システムを表すが、他のシステム（他のマイクロプロセッサ、エンジニアリング・ワークステーション、セットトップ・ボックス等を有するパソコン（ＰＣ）を含む）も用いることができる。一実施例では、サンプル・システム９００は、マイクロソフト社から入手可能なウィンドウズ（登録商標）オペレーティング・システムのバージョンを実行することができるが、例えば、他のオペレーティング・システム及びグラフィカル・ユーザ・インタフェースも用いることができる。

図７は、本願開示の手法を行うことができる処理システム９００がメモリ・システム９４０及びプロセッサ９０４を含み得ることを示す。メモリ・システム９４０は、メモリ９０２、並びに１つ又は複数のオンチップ・キャッシュ又はオフチップ・キャッシュを含み得る。例えば、メモリ・システム９４０は、データ・キャッシュ９４２及び／又は命令キャッシュ９４４を含み得る。

メモリ・システム９４０は、プロセッサ９０４の動作を制御するための命令９１０及び／又はデータ９１２を記憶することができる。命令９１０及び／データ９１２は、本明細書及び特許請求の範囲記載の手法の何れか又は全てを行うコードを含み得る。メモリ・システム９４０は、メモリの一般化された表現として意図されており、各種のメモリ形態（ハード・ドライブ、ＣＤ−ＲＯＭ、ランダム・アクセス・メモリ（ＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）等、並びに、関連した回路）を含み得る。

図７は、プロセッサ９０４がフロントエンド９２０を含み得ることを示す。フロントエンド９２０はフェッチ及びデコード・ロジックを含み得る。例えば、複数の論理シーケンスを単一の物理フェッチ／デコード・ユニット３２２において実現することができるが、スレッド・コンテキスト毎に命令をフェッチするための論理的に別個の次命令ポインタ及びフェッチ・ロジック３２０を含み得る。フェッチ／デコード・ユニット３２２は、前述のＴＲＮＸＳＥＴ、ＴＲＮＸＣＭＴ、ＴＲＮＸＲＤ及び／ＴＲＮＸＯＫ命令などの命令をデコードするためのデコーダ・ロジックを含み得る。命令のうちの１つの受け取りに応答して、デコード・ロジックは、１つ又は複数の信号を実行コア９３０に送出することができる。これによって、実行コア９３０は所望の動作を行うことができる。（前述の命令それぞれの少なくとも１つの実施例に関連した動作は、表１の記載に関して前述している。）
図７に示すマルチシーケンサ・システム９００のＳＭＴ実施例の場合、「シーケンサ」の語は、スレッド・コンテキストの少なくとも次命令ポインタ及びフェッチ・ロジック３２０、及び、そのスレッド・コンテキストの関連したアーキテクチャ状態の少なくとも一部を包含する。ＳＭＴシステム９００のシーケンサは対称でなくてよい。例えば、同じ物理コア９０４の２つのＳＭＴシーケンサは、それぞれが維持するアーキテクチャ状態情報の量において異なり得る。

よって、少なくとも一実施例の場合、マルチシーケンサ・システム９００は、同時マルチスレッド化をサポートする単一コア・プロセッサ９０４である。前述の実施例の場合、各シーケンサは、それ自身の命令次命令ポインタ及びフェッチ・ロジック３２０、並びに、それ自身のアーキテクチャ状態情報を有するロジカル・プロセッサであるが、同じ物理プロセッサ・コア３０４はスレッド命令全てを実行する。前述の実施例の場合、論理プロセッサはそれ自身のアーキテクチャ状態バージョンを維持するが、単一のプロセッサ・コアの実行資源は、同時に実行するスレッド間で共有することができる。

図７に示すシステム９００の少なくとも１つの別の実施例は、マルチコア・プロセッサ（例えば、図２に示すプロセッサ２００参照）に基づく。別々のスレッドの少なくとも一部分の実行が同時に進み得るようにそれぞれが別々のスレッドを実行することができる２つ以上の別個の物理プロセッサ（例えば、図２の１０４−１０４ｎ参照）を前述のシステムは含み得る。各プロセッサは、そのそれぞれのスレッド毎に命令情報をフェッチするための物理的に別個のフェッチ・ユニット３２２を含む。単一のスレッドを各プロセッサが実行する実施例では、フェッチ／デコード・ユニット３２２は、単一の次命令ポインタ及びフェッチ・ロジック３２０を実現する。しかし、複数のスレッド・コンテキストを各プロセッサがサポートする実施例では、フェッチ／デコード・ユニット３２２は、別個の次命令ポインタ及びフェッチ・ロジック３２０を、サポートされるスレッド・コンテキスト毎に実現する。プロセッサ９０４における更なる次命令ポインタ及びフェッチ・ロジック３２０の任意性は図７の破線で表す。

本発明の特定の実施例を示し、説明したが、特許請求の範囲記載の範囲から逸脱しない限り、変更及び修正を行うことが可能であることが当業者には分かる。よって、本発明のそのより広い局面から逸脱しない限り、変更及び修正を行うことが可能であることを当業者は認識するであろう。特許請求の範囲は、本発明の真の範囲内に収まる前述の変更及び修正全てをその範囲内に包含するものとする。

Claims (3)

1. 装置であって、
   第１のプレフィックスを含む第１の命令及び第２のプレフィックスを含む第２の命令をデコードするよう構成されたデコード・ロジックであって、前記第１の命令はロック獲得命令であり、第１のアトミック・プレフィックスが前記ロック獲得命令に付加され、前記第２の命令はロック解除命令であり、第２のアトミック・プレフィックスが前記ロック解除命令に付加されたデコード・ロジックと、
   前記デコード・ロジックに結合された実行ロジックであって、前記第１のプレフィックスを含む前記第１の命令及び第２のプレフィックスを含む前記第２の命令を前記デコード・ロジックがデコードすることに応じて前記第１の命令及び前記第２の命令によって区分されたクリティカルな部分を投機的に実行するよう構成された実行ロジックと、
   前記実行ロジックに結合されたバッファ・ロジックであって、前記実行ロジックが前記クリティカルな部分を投機的に実行している間に、前記クリティカルな部分からのメモリ更新をバッファリングするよう構成されたバッファ・ロジックと、
   前記バッファ・ロジックに関連付けられた監視ロジックであって、前記実行ロジックが前記クリティカルな部分を投機的に実行している間にアクセスされたメモリ位置に対する他のスレッドからの競合を追跡するよう構成された監視ロジックと、
   前記バッファ・ロジック及び前記監視ロジックに結合されたアトミック・コミット・ロジックであって、前記デコード・ロジックが前記第２の命令をデコードし、前記実行ロジックが前記クリティカルな部分を投機的に実行している間にアクセスされたメモリ位置に対する他のスレッドからの競合を前記監視ロジックが追跡しないことに応じて、メモリに対して前記メモリ更新をアトミックにコミットするよう構成されたアトミック・コミット・ロジックと
   を備えた装置。
2. 方法であって、
   第１のアトミック・プレフィックスを含む第１のロック獲得命令をデコードする工程であって、前記第１のロック獲得命令は、クリティカルな部分に先行する工程と、
   前記第１のアトミック・プレフィックスを含む前記ロック獲得命令をデコードする工程に応じて、
   前記クリティカルな部分を投機的に実行し、
   前記クリティカルな部分の投機的な実行中に前記クリティカルな部分からのメモリ更新をバッファリングし、
   前記クリティカルな部分によってアクセスされるメモリ・アドレスを備えた他のスレッドからの競合が、前記クリティカルな部分の投機的な実行中に生じたかを監視する工程と、
   第２のアトミック・プレフィックスを含む第１のロック解放命令のデコードに応じてメモリに対して前記メモリ更新をアトミックにコミットする工程と
   を含む方法。
3. システムであって、
   プロセッサであって、第１のプレフィックスを含む第１の命令及び第２のプレフィックスを含む第２の命令をフェッチし、デコードするよう構成されたデコード・ロジックと、
   前記デコード・ロジックに結合された実行ロジックであって、前記第１のプレフィックスを含む前記第１の命令及び第２のプレフィックスを含む前記第２の命令を前記デコード・ロジックがデコードすることに応じて前記第１の命令及び前記第２の命令によって区分されたクリティカルな部分を投機的に実行するよう構成された実行ロジックと、
   前記実行ロジックに結合されたバッファ・ロジックであって、前記実行ロジックが前記クリティカルな部分を投機的に実行している間に、前記クリティカルな部分からのメモリ更新をバッファリングするよう構成されたバッファ・ロジックと、
   前記バッファ・ロジックに関連付けられた監視ロジックであって、前記実行ロジックが前記クリティカルな部分を投機的に実行している間にアクセスされたメモリ位置に対する他のスレッドからの競合を追跡するよう構成された監視ロジックと、
   前記バッファ・ロジック及び前記監視ロジックに結合されたアトミック・コミット・ロジックであって、前記デコード・ロジックが前記第２の命令をデコードし、前記実行ロジックが前記クリティカルな部分を投機的に実行している間にアクセスされたメモリ位置に対する他のスレッドからの競合を前記監視ロジックが追跡しないことに応じて、メモリに対して前記メモリ更新をアトミックにコミットするよう構成されたアトミック・コミット・ロジックと
   を含むプロセッサと、
   前記プロセッサに結合され、少なくとも前記第１の命令及び前記第２の命令を保有するよう構成されたメモリと
   を備えるシステム。

Images