JP6490092B2 - トランザクション・ステータスを示すためのコヒーレンス・プロトコルの強化 - Google Patents

Description

本発明は、一般に、要求及び応答プロトコルに関し、より具体的には、トランザクション・ステータスを示すためのコヒーレンス・プロトコルの強化に関する。

増大するワークロード容量の需要をサポートするために、チップ上の中央処理ユニット（ＣＰＵ）コアの数及び共有メモリに接続されたＣＰＵコアの数は、著しく増大し続けている。協働して同じワークロードを処理するＣＰＵの数の増大は、ソフトウェアの拡張性（scalability）への大きな負担となり、例えば、従来のセマフォにより保護される共有キュー又はデータ構造はホットスポットになり、ほぼ直線のｎウェイ・スケーリング曲線（sub-linear n-way scaling curves）をもたらす。従来より、これは、ソフトウェアにおける細粒度ロック（finer-grained locking）の実装とハードウェアにおける低遅延／高帯域幅の相互接続とにより相殺される。ソフトウェアの拡張性を改善するために細粒度ロックを実装することは、非常に複雑でエラーが発生しやすい場合があり、今日のＣＰＵ周波数においては、ハードウェア相互接続の待ち時間は、チップ及びシステムの物理的寸法、並びに光の速度により制限される。

ハードウェア・トランザクション・メモリ（ＨＴＭ、又は本考察では単にＴＭ）が導入され、ここで、トランザクションと呼ばれる命令のグループが、他の中央処理ユニット（ＣＰＵ）及びＩ／Ｏサブシステムが見たときに、メモリ内のデータ構造上でアトミックな方法で動作する（他の文献では、アトミック操作は、「ブロック・コンカレント（block concurrent）」又は「シリアル化される」としても知られる）。トランザクションは、ロックを取得することなく楽観的に（optimistically）実行されるが、メモリ位置上の実行中のトランザクションの動作が同じメモリ位置上の別の動作と競合する場合、トランザクション実行のアボート及び再試行を必要とすることがある。これまでに、ソフトウェア・トランザクション・メモリ（ＴＭ）をサポートするために、ソフトウェア・トランザクション・メモリの実装が提案されている。

米国特許第６，３４９，３６１号明細書

「Ｐｏｗｅｒ ＩＳＡ（商標）Ｖｅｒｓｉｏｎ ２．０７」、ＩＢＭ（登録商標）、２０１３年５月２２日 「ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅ，Ｐｒｉｎｃｉｐｌｅｓ ｏｆ Ｏｐｅｒａｔｉｏｎ」、第１０版、ＩＢＭ（登録商標）ＳＡ２２−７８３２−０９、２０１２年９月 「Ｉｎｔｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｅｘｔｅｎｓｉｏｎｓ Ｐｒｏｇｒａｍｍｉｎｇ Ｒｅｆｅｒｅｎｃｅ」３１９４３３−０１２Ａ、２０１２年２月 Ａｕｓｔｅｎ ＭｃＤｏｎａｌｄ著、「ＡＲＣＨＩＴＥＣＴＵＲＥＳ ＦＯＲ ＴＲＡＮＳＡＣＴＩＯＮＡＬ ＭＥＭＯＲＹ」、哲学博士号の要件の部分的履行として、スタンフォード大学のＣｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ学部及び大学院の委員会に提出された論文、２００９年６月 「Ｔｒａｎｓａｃｔｉｏｎａｌ Ｍｅｍｏｒｙ Ａｒｃｈｉｔｅｃｔｕｒｅ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｆｏｒ ＩＢＭ Ｓｙｓｔｅｍ ｚ」、カナダ国ブリティッシュ・コロンビア州バンクーバーにおいて２０１２年１２月１〜５日開催のＭＩＣＲＯ−４５予稿集、２５〜３６ページ、ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ Ｃｏｎｆｅｒｅｎｃｅ Ｐｕｂｌｉｓｈｉｎｇ Ｓｅｒｖｉｃｅｓ（ＣＰＳ）より入手可能 Ｐ．Ｍａｒｋ、Ｃ．Ｗａｌｔｅｒｓ、及びＧ．Ｓｔｒａｉｔ著、「ＩＢＭ ｓｙｓｔｅｍ ｚ１０ ｐｒｏｃｅｓｓｏｒ ｃａｃｈｅ ｓｕｂｓｙｓｔｅｍ ｍｉｃｒｏａｒｃｈｉｔｅｃｔｕｒｅ」、ＩＢＭ Ｊｏｕｒｎａｌ ｏｆ Ｒｅｓｅａｒｃｈ ａｎｄ Ｄｅｖｅｌｏｐｍｅｎｔ、Ｖｏｌ５３：１、２００９年

コヒーレンス・プロトコルを実施するための方法、システム及びコンピュータ・プログラム製品を提供する。

実施形態は、コヒーレンス・プロトコルを実施するための方法、システム及びコンピュータ・プログラム製品を含む。データ要求が遠隔プロセッサに送られる。プロセッサは、遠隔プロセッサから応答を受け取り、応答は、遠隔プロセッサ上の遠隔トランザクションのトランザクション・ステータスを有する。プロセッサは、遠隔プロセッサ上の遠隔トランザクションのトランザクション・ステータスをローカル・トランザクション干渉追跡テーブル内に付加する。

実施形態としてみなされる主題が、本明細書の最後にある特許請求の範囲において具体的に示され、明確に特許請求されている。実施形態の前記及び他の特徴、並びに利点は、添付図面と併せて用いられる以下の詳細な説明から明らかである。

１つの実施形態による、例示的なマルチプロセッサ（ＣＰＵ）コアのトランザクション・メモリ環境の概略的ブロック図を示す。 １つの実施形態によるトランザクション・プロセッサを示す概略的ブロック図を示す。 １つの実施形態による、図１及び図２に示されるトランザクション・プログラム（ＣＰＵ）の例示的コンポーネントの概略的ブロック図を示す。 １つの実施形態による、ハードウェア・トランザクション・メモリ環境における要求及び応答を可能にするための、図１−図３に示されるマルチプロセッサ・システムのようなコンポーネントを有するコンピュータ・システムの概略的ブロック図を示す。 １つの実施形態による、例示的なプロトコル要求及び応答を示す。 １つの実施形態による、例示的なプロトコル要求を示す。 １つの実施形態による、データ要求を行うプロトコルによるプロトコル要求生成のフロー図を示す。 １つの実施形態による、要求を受け取り、応答を送る受信／遠隔プロセッサによる要求処理のフロー図を示す。 １つの実施形態による、プロトコルによるトランザクション処理を示すフロー図を示す。 １つの実施形態による、プロトコル要求及び新しいプロトコル応答を示す。 １つの実施形態による、プロトコル書き込み要求及び新しい応答を示す。 １つの実施形態による、要求を受け取る受信／遠隔プロセッサによるコヒーレンス要求処理を示すフローチャートを示す。 １つの実施形態による、要求プロセッサによるプロトコル要求の発信及び処理を示すフロー図を示す。 １つの実施形態による、プロトコルによるトランザクション処理を示すフロー図を示す。 １つの実施形態による、プロセッサがローカル・トランザクション干渉追跡テーブル内の干渉表示にどのように応答するかを示すフロー図を示す。 １つの実施形態による、プロセッサがローカル・トランザクション干渉追跡テーブル内の干渉表示にどのように応答するかを示すフロー図を示す。 １つの実施形態による、コヒーレンス・プロトコル処理のための方法を示す。 １つの実施形態による、コンピュータ可読媒体を示す。

マルチプロセッサ・システムは、分散共有メモリのシステムにおける全てのキャッシュ間の一貫性を維持するために、コヒーレンス・プロトコルを使用する。特定のキャッシュのデータに対して要求がなされると、キャッシュはデータを発行し、データをそれ以上有していない又はデータは排他的に保持されていないというその状態を更新する。プロセッサがトランザクション実行にあり、トランザクションの部分であるそのキャッシュからのデータが要求された場合、プロセッサはトランザクションをアボートし、データを送る。

要求が別のトランザクションのアボートを引き起こしたかどうかの情報は与えられない。幾つかの例では、オリジナルのリクエスタ（要求側）に、要求が別のトランザクションに影響を与えたかどうかを通知してフィードバックを与え、リクエスタのオリジネータが、その実行に適合すること、例えば、ライブロック・シナリオを検出し、そのシナリオに対処することを可能にすることが望ましい。

実施形態によると、コヒーレンス・プロトコルが、トランザクション・ステータスについての付加的な情報を含むように拡張される。プロセッサがトランザクション実行にあり、例えば、データがトランザクション読み出し又は書き込みセットの部分であり、競合が検出されるために、コヒーレンス要求がその実行のアボートを引き起こすことがある。コヒーレンス・プロトコル要求は、実施形態によるトランザクション実行の際にそれ（コヒーレンス要求を受け取るプロセッサ）がトランザクションをアボートした付加的な情報を有するように拡張される。

その全体が引用により本明細書に組み入れられる非特許文献１は、例示的な縮小命令セット・コンピュータ（reduced instruction set computer、ＲＩＳＣ）命令セット・アーキテクチャ（ＩＳＡ）を教示する。また、その全体が引用により本明細書に組み入れられる非特許文献２は、例示的なＣＩＳＣ（complex instruction set computer）命令セット・アーキテクチャを開示する。

従来、コンピュータ・システム又はプロセッサは、シングル・プロセッサ（別名、処理ユニット又は中央処理ユニット）しか有していなかった。プロセッサは、命令処理ユニット（ＩＰＵ）、分岐ユニット、メモリ制御ユニット等を含んでいた。こうしたプロセッサは、一度に単一のプログラム・スレッドを実行することができた。一定の期間プロセッサ上で実行されるようにプログラムをディスパッチし、次に、別の期間プロセッサ上で実行されるように別のプログラムをディスパッチすることによって、プロセッサを時分割する（time-share）ことが可能なオペレーティング・システムが開発された。技術が発展すると、メモリ・サブシステム・キャッシュ、並びに変換ルックアサイド・バッファ（ＴＬＢ）を含む複雑な動的アドレス変換が、プロセッサに付加されることが多くなった。ＩＰＵ自体が、多くの場合、プロセッサと呼ばれた。技術が発展し続けると、プロセッサ全体を単一の半導体チップ又はダイとしてパッケージ化できるようになり、こうしたプロセッサは、マイクロプロセッサと呼ばれた。その後、複数のＩＰＵを組み入れたプロセッサが開発され、こうしたプロセッサは、多くの場合、マルチプロセッサと呼ばれた。マルチプロセッサ・コンピュータ・システム（プロセッサ）のこうしたプロセッサの各々は、個々の又は共有のキャッシュ、メモリ・インターフェース、システム・バス、アドレス変換機構等を含むことができる。仮想マシン及び命令セット・アーキテクチャ（instruction set architecture、ＩＳＡ）エミュレータは、ソフトウェアの層をプロセッサに付加し、シングル・ハードウェア・プロセッサ内にシングルＩＰＵのタイムスライスを使用することにより、複数の「仮想プロセッサ」（別名、プロセッサ）を有する仮想マシンを提供した。技術がさらに発展すると、マルチスレッド・プロセッサが開発され、シングル・マルチスレッドＩＰＵを有するシングル・ハードウェア・プロセッサが異なるプログラムのスレッドを同時に実行する能力を提供することを可能にし、従って、コンピュータ・システムには、マルチスレッド・プロセッサの各スレッドが１つのプロセッサとして見えるようになった。技術がさらに発展すると、単一の半導体チップ又はダイ上に複数のプロセッサ（各々がＩＰＵを有する）をのせることが可能になった。これらのプロセッサは、プロセッサ・コア、又は単にコアと呼ばれた。従って、例えば、プロセッサ、中央処理ユニット、処理ユニット、マイクロプロセッサ、コア、プロセッサ・コア、プロセッサ・スレッド及びスレッドといった用語は、交換可能に使用されることが多い。本明細書における実施形態の態様は、本明細書での教示から逸脱することなく、上に示されるものを含むいずれかの又は全てのプロセッサによって実施することができる。「スレッド」又は「プロセッサ・スレッド」という用語が本明細書で用いられる場合、実施形態の特定の利点は、プロセッサ・スレッドの実装において有することができたと考えられる。

Ｉｎｔｅｌ(登録商標)ベースの実施形態におけるトランザクション実行
その全体が引用により組み入れられる非特許文献３において、第８章は、部分的に、マルチスレッド・アプリケーションが、より高い性能を達成するためにＣＰＵコアの数の増大を利用できることを教示する。しかしながら、マルチスレッド・アプリケーションの書き込みでは、プログラマーが、複数のスレッド間のデータ共有を理解し、考慮に入れる必要がある。共有データへのアクセスは、一般的に、同期機構を必要とする。これらの同期機構を用いて、多くの場合、ロックで保護されたクリティカル・セクション（critical section）を用いて、共有データに適用される動作をシリアル化することにより、複数のスレッドが共有データを更新することを保証する。シリアル化により、並行性（concurrency）が制限されるので、プログラマーは、同期に起因するオーバーヘッドを制限しようと試みる。

Ｉｎｔｅｌ(登録商標) Ｔｒａｎｓａｃｔｉｏｎａｌ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎｓ（Ｉｎｔｅｌ(登録商標)ＴＳＸ）は、プロセッサが、ロックで保護されたクリティカル・セクションによりスレッドをシリアル化する必要があるかどうかを動的に判断し、必要な場合にのみこのシリアル化を行うことを可能にする。これにより、プロセッサは、動的な不要な同期のためにアプリケーション内に隠れている並行性を顕在化させ利用することができる。

Ｉｎｔｅｌ ＴＳＸでは、プログラマーが指定したコード領域（「トランザクション領域」又は単に「トランザクション」とも呼ばれる）がトランザクション実行される。トランザクション実行が成功裏に完了すると、トランザクション領域内で実施された全てのメモリ操作は、他のプロセッサから見たときに瞬時に起こったように見える。プロセッサは、成功裏にコミットが行われる場合にのみ、即ち、トランザクションが成功裏に実行を完了した場合にのみ、他のプロセッサに見えるトランザクション領域内で実施される、実行されたトランザクションのメモリ操作を行う。このプロセスは、アトミック・コミットと呼ばれることが多い。

Ｉｎｔｅｌ ＴＳＸは、トランザクション実行のためのコード領域を指定するための、２つのソフトウェア・インターフェースを提供する。Ｈａｒｄｗａｒｅ Ｌｏｃｋ Ｅｌｉｓｉｏｎ（ＨＬＥ）は、トランザクション領域を指定するための、従来の（legacy）互換命令セット拡張（compatible instruction setextension）（ＸＡＣＱＵＩＲＥ及びＸＲＥＬＥＡＳＥプリフィックスを含む）である。Ｒｅｓｔｒｉｃｔｅｄ Ｔｒａｎｓａｃｔｉｏｎａｌ Ｍｅｍｏｒｙ（Restricted Transactional Memory、ＲＴＭ）は、新しい命令セット・インターフェース（ＸＢＥＧＩＮ、ＸＥＮＤ、及びＸＡＢＯＲＴ命令を含む）であり、プログラマーは、ＨＬＥで可能なよりも柔軟性の高い手法でトランザクション領域を定義できる。ＨＬＥは、従来の相互排他プログラミング・モデルの後方互換性（backward compatibility）を好み、従来のハードウェア上でＨＬＥ対応のソフトウェアを実行したいが、ＨＬＥサポートを有するハードウェア上で新しいロック無効化機能を利用したいと望むプログラマー向けのものである。ＲＴＭは、トランザクション実行ハードウェアよりも柔軟なインターフェースを好むプログラマー向けのものである。さらに、Ｉｎｔｅｌ ＴＳＸはまた、ＸＴＥＳＴ命令も提供する。この命令は、論理プロセッサが、ＨＬＥ又はＲＴＭのいずれかによって識別されたトランザクション領域においてトランザクション実行しているかどうかを、ソフトウェアが照会することを可能にする。

成功したトランザクション実行はアトミック・コミットを保証するので、プロセッサは、明示的な同期を行うことなく、コード領域を楽観的に実行する。特定の実行で同期が不要であった場合、いかなるクロススレッドのシリアル化も行うことなく、実行をコミットすることができる。プロセッサがアトミックにコミットできない場合、楽観的実行に失敗する。楽観的実行に失敗すると、プロセッサは実行をロールバックし、プロセスはトランザクション・アボートと呼ばれる。トランザクションがアボートすると、プロセッサは、トランザクションが使用するメモリ領域で実行された全ての更新を廃棄し、あたかも楽観的に実行が行われなかったように見えるようにアーキテクチャ上の状態を復元し、非トランザクションに実行を再開する。

プロセッサは、多くの理由によりトランザクションをアボートすることがある。トランザクションをアボートする主たる理由は、トランザクションを実行している論理プロセッサと別の論理プロセッサとの間のメモリ・アクセスの競合によるものである。このようなメモリ・アクセス競合は、トランザクション実行の成功の妨げとなり得る。トランザクション領域内から読み取られたメモリ・アドレスによりトランザクション領域の読み取りセット（read set）が構成され、トランザクション領域内に書き込まれたアドレスによりトランザクション領域の書き込みセット（write set）が構成される。Ｉｎｔｅｌ ＴＳＸは、キャッシュラインの粒度で読み取りセットと書き込みセットを維持する。別の論理プロセッサがトランザクション領域の書き込みセットの一部の場所で読み取りを行うか又はトランザクション領域の読み取りセット若しくは書き込みセットの一部の場所で書き込みを行う場合、メモリ・アクセス競合が発生する。アクセス競合は、一般的には、そのコード領域に対してシリアル化が必要であることを意味する。Ｉｎｔｅｌ ＴＳＸは、キャッシュラインの粒度でデータ競合を検出するため、同じキャッシュラインに置かれた無関係なデータ位置は競合として検出され、その結果、トランザクション・アボートがもたらされる。トランザクション・アボートはまた、トランザクション・リソースの制限により発生することもある。例えば、領域内でアクセスされるデータの量が、実装固有の能力を超えた場合である。さらに、一部の命令とシステム・イベントがトランザクション・アボートを引き起こすこともある。頻繁なトランザクション・アボートは無駄なサイクル及び非効率性の増大をもたらす。

Ｈａｒｄｗａｒｅ Ｌｏｃｋ Ｅｌｉｓｉｏｎ
Ｈａｒｄｗａｒｅ Ｌｏｃｋ Ｅｌｉｓｉｏｎ（ＨＬＥ）は、プログラマーがトランザクション実行を使用するための従来の互換命令セット・インターフェースである。ＨＬＥは、２つの新しい命令プリフィックス・ヒント、即ちＸＡＣＱＵＩＲＥ及びＸＲＥＬＥＡＳＥを提供する。

ＨＬＥでは、プログラマーは、クリティカル・セクションを保護するロックの取得に使用する命令の前に、ＸＡＣＱＵＩＲＥプリフィックスを付加する。プロセッサは、ロック取得操作と関連付けられている書き込みを無効化する（elide）ヒントとしてプリフィックスを扱う。ロック取得がロックと関連付けられている書き込み操作を有していても、プロセッサは、トランザクション領域の書き込みセットにロックのアドレスを追加せず、ロックに対するいかなる書き込み要求も発行しない。代わりに、ロックのアドレスが読み取りセットに追加される。論理プロセッサがトランザクション実行に入る。ＸＡＣＱＵＩＲＥプリフィックス付加された命令の前にロックが利用可能であった場合、命令の後に他の全てのプロセッサはそのロックを利用可能なものとして見なし続ける。トランザクション実行する論理プロセッサは、書き込みセットにロックのアドレスを追加せず、外部に明確な書き込み操作を行わないため、他の論理プロセッサは、データ競合を引き起こすことなくロックを読み取ることができる。これにより、他の論理プロセッサがロックで保護されたクリティカル・セクションに入り、同時実行することが可能になる。プロセッサは、トランザクション実行中に引き起こされるあらゆるデータ競合を自動的に検出し、必要に応じてトランザクション・アボートを実行する。

無効化を行うプロセッサがロックに対するいかなる外部書き込み操作も行わないにもかかわらず、ハードウェアは、ロックに対する操作のプログラム順を保証する。無効化を行うプロセッサ自体がクリティカル・セクションにおいてロックの値を読み取ると、プロセッサがロックを取得したように見える、即ち、読み取りにより、非無効化（non-elide）値が戻される。この挙動は、ＨＬＥ実行が、ＨＬＥプリフィックスなしの実行と機能的に等しくなることを可能にする。

ＸＲＥＬＥＡＳＥプリフィックスは、クリティカル・セクションを保護するロックの解放（release）に使用される命令の前に追加することができる。ロックの解放には、ロックに対する書き込みが含まれる。この命令により、ロックの値が、同じロックのＸＡＣＱＵＩＲＥプリフィックスでロック取得操作の前にロックが有していた値に戻された場合、プロセッサは、ロックの解放に関連付けられている外部書き込み要求を無視し、書き込みセットにロックのアドレスを追加しない。次に、プロセッサは、トランザクション実行をコミットしようとする。

ＨＬＥでは、複数のスレッドが同じのロックで保護されたクリティカル・セクションを実行する場合でも、互いのデータに対していずれかの競合が発生する操作を行わないのであれば、スレッドをシリアル化することなく同時に実行することができる。ソフトウェアが共通のロックでロック取得操作を使用した場合でも、ハードウェアはこれを認識し、ロックを無効化し、ロックを通じていずれの通信も行うことなく、２つのスレッドでクリティカル・セクションを実行する（こうした通信が動的に不要だった場合）。

プロセッサが領域をトランザクション実行できない場合、プロセッサは、その領域を、非トランザクションに且つ無効化を行わずに実行する。ＨＬＥ対応のソフトウェアは、基礎をなす非ＨＬＥのロック・ベースの実行と同じように前方進行を保証する。ＨＬＥ実行を成功させるためには、ロック及びクリティカル・セクションコードが特定のガイドラインに従わなければならない。これらのガイドラインは性能のみに影響し、これらのガイドラインに従わなかった場合でも機能的不具合は生じない。ＨＬＥサポートを有していないハードウェアは、ＸＡＣＱＵＩＲＥ及びＸＲＥＬＥＡＳＥプリフィックス・ヒントを無視するが、これらのプリフィックスはＸＡＣＱＵＩＲＥ及びＸＲＥＬＥＡＳＥが有効な場合に命令で無視されるＲＥＰＮＥ／ＲＥＰＥ ＩＡ−３２プリフィックスに対応しているので、いかなる無効化も行わない。重要なことに、ＨＬＥは既存のロック・ベースのプログラミング・モデルと互換性がある。ヒントを不適切に使用しても機能的なバグは起こらないが。コードに既に含まれている潜在的なバグが暴露する可能性がある。

Ｒｅｓｔｒｉｃｔｅｄ Ｔｒａｎｓａｃｔｉｏｎａｌ Ｍｅｍｏｒｙ（ＲＴＭ）は、トランザクション実行用の柔軟なソフトウェア・インターフェースを提供する。ＲＴＭは、プログラマーがトランザクション実行を開始、コミット、アボートする３つの新しい命令（ＸＢＥＧＩＮ、ＸＥＮＤ、及びＸＡＢＯＲＴ）を提供する。

プログラマーは、ＸＢＥＧＩＮ命令を使用してトランザクション・コード領域の開始を指定し、ＸＥＮＤ命令を使用してトランザクション・コード領域の終了を指定する。ＸＢＥＧＩＮ命令は、ＲＴＭ領域がトランザクション実行に成功しなかった場合、相対的なオフセットをフォールバック命令アドレスに与えるオペランドを利用する。

プロセッサは、多くの理由によりＲＴＭトランザクション実行をアボートすることがある。多くの例において、ハードウェアは、トランザクション・アボート条件を自動的に検出して、ＸＢＥＧＩＮ命令の開始、及びアボート・ステータスを説明するために更新されたＥＡＸレジスタに対応するアーキテクチャ状態で、フォールバック命令アドレスから実行を再開する。

ＸＡＢＯＲＴ命令は、プログラマーが、ＲＴＭ領域の実行を明示的にアボートすることを可能にする。ＸＡＢＯＲＴ命令には、ＲＴＭアボートの後にソフトウェアで利用可能になる、ＥＡＸレジスタにロードされる８ビットの即時引数を利用する。ＲＴＭ命令は、いずれのデータ・メモリ位置とも関連付けられない。ハードウェアは、ＲＴＭ領域がこれまでトランザクション・コミットに成功したかどうかに関して保証しないが、推奨されるガイドラインに従う大部分のトランザクションは、トランザクション・コミットに成功すると予想される。しかしながら、プログラマーは、前方進行を保証するため、フォールバック経路に代替コード・シーケンスを常に提供しなければならない。これは、ロックを取得して指定されたコード領域を非トランザクションに実行するのと同じくらい簡単であり得る。さらに、所与の実装では常にアボートされるトランザクションが、将来の実装ではトランザクションに完了する可能性がある。従って、プログラマーは、トランザクション領域と代替コード・シーケンスのコード経路が機能的にテストされることを保証しなければならない。

ＨＬＥサポートの検出
プロセッサは、ＣＰＵＩＤ．０７Ｈ．ＥＢＸ．ＨＬＥ［ｂｉｔ４］＝１の場合に、ＨＬＥ実行をサポートする。しかしながら、アプリケーションは、プロセッサがＨＬＥをサポートするかどうかをチェックすることなく、ＨＬＥプリフィックス（ＸＡＣＱＵＩＲＥ及びＸＲＥＬＥＡＳＥ）を使用することができる。ＨＬＥサポートを有していないプロセッサは、これらのプリフィックスを無視し、トランザクション実行に入ることなく、コードを実行する。

ＲＴＭサポートの検出
プロセッサは、ＣＰＵＩＤ．０７Ｈ．ＥＢＸ．ＲＴＭ［ｂｉｔ１１］＝１の場合に、ＲＴＭ実行をサポートする。アプリケーションは、ＲＴＭ命令（ＸＢＥＧＩＮ、ＸＥＮＤ、ＸＡＢＯＲＴ）を使用する前に、プロセッサがＲＴＭをサポートしているかどうかをチェックする必要がある。これらの命令は、ＲＴＭをサポートしていないプロセッサで使用されると、＃ＵＤ例外が発生する。

ＸＴＥＳＴ命令の検出
プロセッサが、ＨＬＥ又はＲＴＭのいずれかをサポートしている場合、ＸＴＥＳＴ命令をサポートする。アプリケーションは、ＸＴＥＳＴ命令を使用する前に、これらの特徴フラグのどちらかをチェックする必要がある。この命令は、ＨＬＥ又はＲＴＭのいずれもサポートしていないプロセッサで使用されると、＃ＵＤ例外が発生する。

トランザクション実行ステータスを照会する
ＸＴＥＳＴ命令は、ＨＬＥ又はＲＴＭによって指定されたトランザクション領域のトランザクション・ステータスを判断するために使用することができる。ＨＬＥプリフィックスは、ＨＬＥをサポートしていないプロセッサ上で無視されるが、ＸＴＥＳＴ命令は、ＨＬＥ又はＲＴＭのいずれもサポートしていないプロセッサ上で使用されると、＃ＵＤ例外が発生することに留意されたい。

ＨＬＥロックの要件
ＨＬＥ実行がトランザクション・コミットに成功するために、ロックが特定の特性を満たし、ロックへのアクセスが次の特定のガイドラインに従っていなければならない。

ＸＲＥＬＥＡＳＥプリフィックスの付いた（prefixed）命令は、無効化されたロックの値を、ロック取得の前に有していた値に復元する必要がある。これにより、ハードウェアは、書き込みセットに追加することなく、安全にロックを無効化することができる。ロック解放（ＸＲＥＬＥＡＳＥプリフィックスが付加された）命令のデータ・サイズ及びデータ・アドレスは、ロック取得（ＸＡＣＱＵＩＲＥプリフィックスの付いた）命令のものと一致していなければならず、ロックはキャッシュライン境界をまたぐことはできない。

ソフトウェアは、ＸＲＥＬＥＡＳＥプリフィックス命令以外のいかなる命令によってもトランザクションＨＬＥ領域内の無効化されたロックに書き込みを行うべきではなく、さもなければ、こうした書き込みがトランザクション・アボートを引き起こすことがある。さらに、再帰ロック（recursive lock）（スレッドが、最初にロックを解放することなく、同じロックを複数回取得する場合）もトランザクション・アボートを引き起こすことがある。ソフトウェアは、クリティカル・セクション内で取得された無効化されたロックの結果を観察できることに留意されたい。こうした読み取り操作は、書き込みの値をロックに戻す。

プロセッサは、これらのガイドラインの違反を自動的に検出し、無効化を行うことなく、安全に非トランザクション実行に遷移する。Ｉｎｔｅｌ ＴＳＸは、キャッシュラインの粒度で競合を検出するので、無効化されたロックと同じキャッシュライン上に配置されたデータへの書き込みは、同じロックの無効化を行う他の論理プロセッサによってデータ競合として検出される可能性がある。

トランザクション・ネスト化
ＨＬＥ及びＲＴＭの両方とも、ネスト化された（nested）トランザクション領域をサポートする。しかしながら、トランザクション・アボートは、状態を、トランザクション実行を開始した操作に、即ち、最外（outermost）ＸＡＣＱＵＩＲＥプリフィックスの付いたＨＬＥ適格（HLE-eligible）命令、又は最外ＸＢＥＧＩＮ命令のいずれかに復元する。プロセッサは、全てのネスト化トランザクションを１つのトランザクションとして扱う。

ＨＬＥのネスト化及び無効化
プログラマーは、ＨＬＥ領域を、ＭＡＸ＿ＨＬＥ＿ＮＥＳＴ＿ＣＯＵＮＴの実装指定深さまでネスト化することができる。各論理プロセッサは、ネスト化カウントを内部で追跡するが、このカウントはソフトウェアに利用可能でない。ＸＡＣＱＵＩＲＥプリフィックスの付いたＨＬＥ適格命令はネスト化カウントをインクリメントし、ＸＲＥＬＥＡＳＥプリフィックスの付いたＨＬＥ適格命令はこれをデクリメントする。論理プロセッサは、ネスト化カウントがゼロから１になったとき、トランザクション実行に入る。論理プロセッサは、ネスト化カウントがゼロになったときにのみ、コミットしようと試みる。ネスト化カウントがＭＡＸ＿ＨＬＥ＿ＮＥＳＴ＿ＣＯＵＮＴを上回った場合には、トランザクション・アボートが発生することがある。

ネスト化されたＨＬＥ領域をサポートすることに加えて、プロセッサはまた、複数のネスト化されたロックを無効化することもできる。プロセッサは、無効化に関してロックを追跡し、そのロックに対するＸＡＣＱＵＩＲＥプリフィックスの付いたＨＬＥ適格命令から開始し、その同じロックに対するＸＲＥＬＥＡＳＥプリフィックスの付いたＨＬＥ適格命令で終了する。プロセッサは、常に、ロックのＭＡＸ＿ＨＬＥ＿ＥＬＩＤＥＤ＿ＬＯＣＫＳ数まで追跡することができる。例えば、実装が２のＭＡＸ＿ＨＬＥ＿ＥＬＩＤＥＤ＿ＬＯＣＫＳ値をサポートし、プログラマーが３つのＨＬＥ識別クリティカル・セクションをネスト化する場合（ロックのどれに対しても介在するＸＲＥＬＥＡＳＥプリフィックスの付いたＨＬＥ適格命令を実行することなく、３つの個別ロックに対して介在するＸＡＣＱＵＩＲＥプリフィックスの付いたＨＬＥ適格命令を実行することによって）、最初の２つのロックは無効化されるが、第３のロックは無効化されない（しかし、トランザクションの書き込みセットに追加される）。しかしながら、実行は依然としてトランザクションに続行する。２つの無効化されたロックの１つに対してＸＲＥＬＥＡＳＥに遭遇すると、ＸＡＣＱＵＩＲＥプリフィックスの付いたＨＬＥ適格命令を介して取得された後続のロックが無効化される。

プロセッサは、全ての無効化されたＸＡＣＱＵＩＲＥ及びＸＲＥＬＥＡＳＥのペアが一致し、ネスト化カウントがゼロになり、ロックが要件を満たした場合に、ＨＬＥ実行をコミットしようと試みる。実行がアトミックにコミットできない場合、実行は、あたかも最初の命令がＸＡＣＱＵＩＲＥプリフィックスを有していなかったかのように、無効化を行わない非トランザクション実行に遷移する。

ＲＴＭのネスト化
プログラマーは、ＲＴＭ領域を、実装指定のＭＡＸ＿ＲＴＭ＿ＮＥＳＴ＿ＣＯＵＮＴまでネスト化することができる。論理プロセッサは、ネスト化カウントを内部で追跡するが、このカウントはソフトウェアに利用可能でない。ＸＢＥＧＩＮ命令はネスト化カウントをインクリメントし、ＸＥＮＤ命令はネスト化カウントをデクリメントする。論理プロセッサは、ネスト化カウントがゼロになった場合にのみ、コミットを試みる。ネスト化カウントがＭＡＸ＿ＲＴＭ＿ＮＥＳＴ＿ＣＯＵＮＴを上回った場合には、トランザクション・アボートが発生する。

ＨＬＥ及びＲＴＭのネスト化
ＨＬＥ及びＲＴＭは、２つの代替的なソフトウェア・インターフェースを一般的なトランザクション実行機能に提供する。トランザクション処理の挙動は、例えばＨＬＥがＲＴＭの内部にある又はＲＴＭがＨＬＥの内部にあるなど、ＨＬＥ及びＲＴＭが互いにネスト化された場合、実装固有のものである。しかしながら、全ての場合において、実装は、ＨＬＥ及びＲＴＭのセマンティクスを維持する。ある実装は、ＲＴＭ領域内で使用されるとき、ＨＬＥヒントを無視するように選択することができ、ＲＴＭ命令がＨＬＥ領域内で使用されるとき、トランザクション・アボートを発生させることがある。後者の場合、プロセッサは実際に無効化を行わずにＨＬＥ領域を再実行し、次にＲＴＭ命令を実行するので、トランザクション実行から非トランザクション実行への遷移はシームレスに行われる。

アボート・ステータスの定義
ＲＴＭは、ＥＡＸレジスタを使用して、アボート・ステータスをソフトウェアに伝える。ＲＴＭアボートの後、ＥＡＸレジスタは、以下の定義を有する。

ＲＴＭに関するＥＡＸアボート・ステータスは、アボートの原因のみを提供する。これ自体が、ＲＴＭ領域に関してアボートが発生したか又はコミットが発生したかをコード化するものではない。ＥＡＸの値は、ＲＴＭアボートの後に、０になることがある。例えば、ＲＴＭ領域の内部でＣＰＵＩＤ命令を使用すると、トランザクション・アボートを引き起こすが、ＥＡＸビットのいずれかを設定する要件を満たさない場合がある。これにより、ＥＡＸの値が０になる場合がある。

ＲＴＭメモリの順序付け
ＲＴＭがコミットに成功すると、ＲＴＭ領域内の全てのメモリ操作はアトミックに実行されるように見える。ＲＴＭ領域内でメモリ操作が行われない場合でも、ＸＢＥＧＩＮの後にＸＥＮＤが続き、コミットに成功したＲＴＭ領域は、ＬＯＣＫプリフィックス命令と同じ順序付けセマンティクスを有する。

ＸＢＥＧＩＮ命令には、フェンス・セマンティクスがない。しかしながら、ＲＴＭ実行がアボートした場合、ＲＴＭ領域内部から全てのメモリ更新が廃棄され、あらゆる他の論理プロセッサから見えなくなる。

ＲＴＭ対応デバッガのサポート
デフォルトでは、ＲＴＭ領域内部のあらゆるデバッグ例外がトランザクション・アボートを引き起こし、アーキテクチャ状態が復旧し、ビット４がＥＡＸ内に設定された状態で、制御フローをフォールバック命令アドレスにリダイレクトする。しかしながら、ソフトウェア・デバッガが、デバッグ例外時に実行をインターセプトするのを可能にするために、ＲＴＭアーキテクチャは付加的な機能を提供する。

ＤＲ７のビット１１及びＩＡ３２＿ＤＥＢＵＧＣＴＬ＿ＭＳＲのビット１５が両方とも１である場合、デバッグ例外（＃ＤＢ）又はブレークポイント例外（＃ＢＰ）に起因するいずれかのＲＴＭアボートにより、実行がロールバックし、フォールバック・アドレスの代わりにＸＢＥＧＩＮ命令から再開する。このシナリオでは、ＥＡＸレジスタもまた、ＸＢＥＧＩＮ命令の時点に復元される。

プログラミング上の考慮事項
一般的に、通常プログラマーが指定した領域は、トランザクション実行及びコミットに成功することが想定される。しかしながら、Ｉｎｔｅｌ ＴＳＸでは、そうした保証はない。トランザクション実行は、様々な理由によりアボートされることがある。トランザクション機能を最大限に利用するために、プログラマーは、特定のガイドラインに従い、トランザクション実行のコミットが成功する可能性を高める必要がある。

このセクションでは、トランザクション・アボートを引き起こし得る様々なイベントについて論じる。アーキテクチャは、後で実行をアボートするトランザクション内で行われた更新は決して見えるようにならないことを保証する。コミットされたトランザクション実行のみが、アーキテクチャ状態の更新を開始する。トランザクション・アボートは、決して機能的不具合を引き起こすことはなく、性能にのみに影響を与える。

命令ベースの考慮事項
プログラマーは、トランザクション（ＨＬＥ又はＲＴＭ）の内部であらゆる命令を安全に使用することができ、あらゆる特権レベルでトランザクションを使用することができる。しかしながら、一部の命令は常にトランザクション実行をアボートさせ、実行は非トランザクション経路にシームレスかつ安全に遷移される。

Ｉｎｔｅｌ ＴＳＸでは、アボートを引き起こさずに、殆どの一般的な命令をトランザクション内部で使用することができる。通常、以下の操作により、トランザクションでアボートが引き起こされることはない。
・命令ポインタ・レジスタ、汎用レジスタ（ＧＰＲ）及びステータス・フラグ（ＣＦ、ＯＦ、ＳＦ、ＰＦ、ＡＦ、及びＺＦ）に対する操作、及び、
・ＸＭＭレジスタ及びＹＭＭレジスタ、並びにＭＸＣＳＲレジスタに対する操作。

しかしながら、プログラマーは、トランザクション領域内でＳＳＥ操作及びＡＶＸ操作を混在させる際に注意深くなければならない。ＸＭＭレジスタにアクセスするＳＳＥ命令と、ＹＭＭレジスタにアクセスするＡＶＸ命令との混在により、トランザクションがアボートする可能性がある。プログラマーは、トランザクション内でＲＥＰ／ＲＥＰＮＥプリフィックスの付いた文字列操作を使用することができる。しかしながら、長い文字列はアボートを引き起こすことがある。さらに、ＣＬＤ及びＳＴＤ命令の使用は、これらがＤＦフラグの値を変えた場合に、アボートを引き起こすことがある。しかしながら、ＤＦが１である場合、ＳＴＤ命令はアボートを引き起こさない。同様に、ＤＦが０である場合、ＣＬＤ命令はアボートを引き起こさない。

トランザクション内部で使用されたときにアボートを引き起こすものとしてここで列挙されていない命令によりトランザクションがアボートされることは通常ない（例として、これらに限定されるものではないが、ＭＦＥＮＣＥ、ＬＦＥＮＣＥ、ＳＦＥＮＣＥ、ＲＤＴＳＣ、ＲＤＴＳＣＰ等が挙げられる）。

以下の命令は、あらゆる実装でトランザクション実行をアボートする。
・ＸＡＢＯＲＴ
・ＣＰＵＩＤ
・ＰＡＵＳＥ

さらに、一部の実装では、以下の命令は常にトランザクション・アボートを引き起こし得る。これらの命令は通常、トランザクション領域の内部で使用されることは想定されていない。しかしながら、これらの命令がトランザクション・アボートを引き起こすかどうかは実装に依存するため、プログラマーは、これらの命令に依存してトランザクション・アボートを強制すべきではない。
・Ｘ８７及びＭＭＸ（商標）のアーキテクチャ状態に対する操作。これには、ＦＸＲＳＴＯＲ及びＦＸＳＡＶＥ命令を含む、全てのＭＭＸ及びＸ８７命令が含まれる。
・ＥＦＬＡＧの非ステータス部分の更新：ＣＬＩ、ＳＴＩ、ＰＯＰＦＤ、ＰＯＰＦＱ、ＣＬＴＳ。
・セグメント・レジスタ、デバッグ・レジスタ、及び／又は制御レジスタを更新する命令：ＤＳ／ＥＳ／ＦＳ／ＧＳ／ＳＳに対するＭＯＶ、ＰＯＰ ＤＳ／ＥＳ／ＦＳ／ＧＳ／ＳＳ、ＬＤＳ、ＬＥＳ、ＬＦＳ、ＬＧＳ、ＬＳＳ、ＳＷＡＰＧＳ、ＷＲＦＳＢＡＳＥ、ＷＲＧＳＢＡＳＥ、ＬＧＤＴ、ＳＧＤＴ、ＬＩＤＴ、ＳＩＤＴ、ＬＬＤＴ、ＳＬＤＴ、ＬＴＲ、ＳＴＲ、Ｆａｒ ＣＡＬＬ、Ｆａｒ ＪＭＰ、Ｆａｒ ＲＥＴ、ＩＲＥＴ、ＤＲｘに対するＭＯＶ、ＣＲ０／ＣＲ２／ＣＲ３／ＣＲ４／ＣＲ８に対するＭＯＶ、及びＬＭＳＷ。
・リング遷移：ＳＹＳＥＮＴＥＲ、ＳＹＳＣＡＬＬ、ＳＹＳＥＸＩＴ、及びＳＹＳＲＥＴ。
・ＴＬＢ及びキャッシュ可能な制御：ＣＬＦＬＵＳＨ、ＩＮＶＤ、ＷＢＩＮＶＤ、ＩＮＶＬＰＧ、ＩＮＶＰＣＩＤ、及び非一時的ヒントを有するメモリ命令（ＭＯＶＮＴＤＱＡ、ＭＯＶＮＴＤＱ、ＭＯＶＮＴＩ、ＭＯＶＮＴＰＤ、ＭＯＶＮＴＰＳ、及びＭＯＶＮＴＱ）。
・プロセッサ状態の保存：ＸＳＡＶＥ、ＸＳＡＶＥＯＰＴ、及びＸＲＳＴＯＲ。
・割り込み：ＩＮＴｎ、ＩＮＴＯ。
・ＩＯ：ＩＮ、ＩＮＳ、ＲＥＰ ＩＮＳ、ＯＵＴ、ＯＵＴＳ、ＲＥＰ ＯＵＴＳ、及びその変形。
・ＶＭＸ：ＶＭＰＴＲＬＤ、ＶＭＰＴＲＳＴ、ＶＭＣＬＥＡＲ、ＶＭＲＥＡＤ、ＶＭＷＲＩＴＥ、ＶＭＣＡＬＬ、ＶＭＬＡＵＮＣＨ、ＶＭＲＥＳＵＭＥ、ＶＭＸＯＦＦ、ＶＭＸＯＮ、ＩＮＶＥＰＴ、及びＩＮＶＶＰＩＤ。
・ＳＭＸ：ＧＥＴＳＥＣ。
・ＵＤ２、ＲＳＭ、ＲＤＭＳＲ、ＷＲＭＳＲ、ＨＬＴ、ＭＯＮＩＴＯＲ、ＭＷＡＩＴ、ＸＳＥＴＢＶ、ＶＺＥＲＯＵＰＰＥＲ、ＭＡＳＫＭＯＶＱ、及びＶ／ＭＡＳＫＭＯＶＤＱＵ。

ランタイムの考慮事項
命令ベースの考慮事項に加えて、ランタイム・イベントによりトランザクション実行がアボートされる場合がある。これは、データ・アクセス・パターン又はマイクロ・アーキテクチャの実装機能に起因し得る。以下のリストは、全てのアボートの原因を包括的に説明したものではない。

ソフトウェアに対して暴露しなければならないトランザクションのフォルト又はトラップは抑止される。トランザクション実行がアボートすると、フォルト又はトラップが発生しなかったように、実行は非トランザクション実行に遷移する。例外がマスクされない場合、そのマスクされない例外はトランザクション・アボートを引き起こし、状態は、例外が発生しなかったように見える。

トランザクション実行中に同期例外イベント（＃ＤＥ、＃ＯＦ、＃ＮＰ、＃ＳＳ、＃ＧＰ、＃ＢＲ、＃ＵＤ、＃ＡＣ、＃ＸＦ、＃ＰＦ、＃ＮＭ、＃ＴＳ、＃ＭＦ、＃ＤＢ、＃ＢＰ／ＩＮＴ３）が発生すると、トランザクション実行はコミットされず、非トランザクション実行が必要となる場合がある。これらのイベントは、発生しなかったかのように抑止される。ＨＬＥでは、非トランザクション・コード経路はトランザクション・コード経路と同一であるため、例外を引き起こした命令が非トランザクションに再実行されると、これらのイベントは再度現れ、非トランザクション実行で関連する同期イベントが適切に配信される。トランザクション実行中に非同期イベント（ＮＭＩ、ＳＭＩ、ＩＮＴＲ、ＩＰＩ、ＰＭＩ等）が発生すると、トランザクション実行はアボートされ、非トランザクション実行に遷移し得る。非同期イベントは保留され、トランザクション・アボートが処理された後に処理される。

トランザクションは、ライトバック・キャッシュが可能なメモリ・タイプの操作のみをサポートする。トランザクションがいずれかの他のメモリ・タイプの操作を含む場合、トランザクションは常にアボートし得る。これには、ＵＣメモリ・タイプにフェッチする命令が含まれる。

トランザクション領域内のメモリ・アクセスには、プロセッサが参照するページ・テーブル・エントリのアクセス（Ａｃｃｅｓｓｅｄ）フラグ及びダーティ（Ｄｉｒｔｙ）フラグを設定しなければならないことがある。プロセッサがこの制御をどのように行うかの挙動は、実装固有である。一部の実装では、トランザクション領域が続いてアボートされた場合でも、これらのフラグに対する更新を外部から見えるようにすることが可能である。一部のＩｎｔｅｌ ＴＳＸの実装では、これらのフラグを更新する必要がある場合、トランザクション実行のアボートを選択することがある。さらに、プロセッサのページ・テーブル・ウォークが、それ自体に書き込まれるが、コミットされていない状態へのアクセスをもたらす場合がある。一部のＩｎｔｅｌ ＴＳＸの実装では、このような状況でトランザクション領域の実行のアボートを選択することがある。それにも関わらず、アーキテクチャは、トランザクション領域がアボートした場合、トランザクションに書き込まれた状態が、アーキテクチャ上、ＴＬＢのような構造の挙動により目に入らないようにすることを保証する。

自己修正（self-modifying）コードのトランザクション実行がトランザクション・アボートを引き起こすこともある。プログラマーは、ＨＬＥ及びＲＴＭを使用する場合でも、自己修正コード及びクロス修正コードの記述に際してＩｎｔｅｌ（登録商標）が推奨するガイドラインに引き続き従う必要がある。ＲＴＭ及びＨＬＥの実装では通常、共通のトランザクション領域を実行するための十分なリソースが提供されるが、トランザクション領域の実装を制約し、サイズを必要以上に大きくすると、トランザクション実行がアボートされ、非トランザクション実行に遷移することがある。アーキテクチャは、トランザクション実行で利用可能なリソース量を保証せず、また、トランザクション実行が常に成功することを保証しない。

トランザクション領域内にアクセスするキャッシュラインに対して競合する要求を行うと、トランザクション実行の成功の妨げとなることがある。例えば、論理プロセッサＰ０がトランザクション領域内のラインＡを読み取り、別の論理プロセッサＰ１がラインＡ（トランザクション領域の内部又は外部のいずれか）に書き込み、論理プロセッサＰ１の書き込みがプロセッサＰ０のトランザクション実行能力を妨げる場合には、論理プロセッサＰ０はアボートし得る。

同様に、Ｐ０がトランザクション領域内のラインＡに書き込み、Ｐ１がラインＡ（トランザクション領域の内部又は外部のいずれか）を読み取る又は書き込む場合にも、Ｐ１のラインＡへのアクセスがＰ０のトランザクション実行能力を妨げる場合には、Ｐ０はアボートし得る。さらに、他のコヒーレンス・トラフィックが競合する要求として見え、アボートを引き起こすことがある。これら偽の競合（false conflict）が発生することはあるが、一般的ではないと考えられる。上記のシナリオにおいて、Ｐ０がアボートするか又はＰ１がアボートするかを決定するための競合解消ポリシーは、実装固有である。

一般的なトランザクション実行の実施形態：
その全体が引用により組み入れられる非特許文献４によれば、基本的に、アトミックな及び分離された（isolated）トランザクション領域を実装するのに必要な３つの機構：即ち、バージョニング（versioning）、競合検出、及びコンテンション管理（contentionmanagement）が存在する。

トランザクション・コード領域がアトミックに見えるようにするために、そのトランザクション・コード領域により行われた全ての修正を、コミット時まで格納し、他のトランザクションから分離する必要がある。本システムは、バージョニング・ポリシーの実装によってこれを行う。２つのバージョニング・パラダイム：即ち、ｅａｇｅｒ及びｌａｚｙが存在する。ｅａｇｅｒバージョニング・システムは、新しく生成されたトランザクション値をイン・プレースに（in place）格納し、以前のメモリ値は、ｕｎｄｏ（取り消し）ログと呼ばれるものの中に別に格納する。ｌａｚｙバージョニング・システムは、新しい値を、書き込みバッファと呼ばれるものの中に一時的に格納し、コミット時にのみこれらをメモリにコピーする。どちらのシステムにおいても、新しいバージョンの格納の最適化のために、キャッシュが使用される。

トランザクションがアトミックに実行されるように見えることを保証するために、競合を検出し、解決する必要がある。２つのシステム、即ちｅａｇｅｒ及びｌａｚｙバージョニング・システムは、楽観的（optimistic）又は悲観的（pessimistic）のいずれかの競合検出ポリシーを実装することにより、競合を検出する。楽観的システムは、トランザクションを並行して実行し、トランザクションのコミット時にのみ競合をチェックする。悲観的システムは、ロード及びストアごとに競合をチェックする。バージョニングと同様に、競合検出もまたキャッシュを使用し、各ラインを読み取りセットの一部、書き込みセットの一部、又はその両方としてマーク付けする。２つのシステムは、コンテンション管理ポリシーを実装することにより、競合を解決する。多数のコンテンション管理ポリシーが存在し、一部は楽観的競合検出により適し、一部は悲観的競合検出により適している。幾つかの例示的なポリシーを以下に説明する。

各トランザクション・メモリ（ＴＭ）システムは、バージョニング検出と競合検出の両方を必要とするので、これらの選択肢は４つの個別のＴＭ設計：Ｅａｇｅｒ−悲観的（Ｐｅｓｓｉｍｉｓｔｉｃ）（ＥＰ）、Ｅａｇｅｒ−楽観的（Ｏｐｔｉｍｉｓｔｉｃ）（ＥＯ）、Ｌａｚｙ−悲観的（ＬＰ）、及びＬａｚｙ−楽観的（ＬＯ）を生み出す。表２は、４つの個別のＴＭ設計の全てを簡単に説明する。

図１及び図２は、マルチコアＴＭ環境の一例を示す。図１は、相互接続制御１２０ａ、１２０ｂの管理下で、相互接続１２２と接続された、１つのダイ１００上の多数のＴＭ対応ＣＰＵ（ＣＰＵ１ １１４ａ、ＣＰＵ２ １１４ｂ等）を示す。各々のＣＰＵ１１４ａ、１１４ｂ（プロセッサとしても知られる）は、実行されるメモリからの命令をキャッシュするための命令キャッシュ１１６ａ、１１６ｂと、ＣＰＵ１１４ａ、１１４ｂ（図１においては、各々のＣＰＵ１１４ａ、１１４ｂ及びその関連したキャッシュは、１１２ａ、１１２ｂと呼ばれる）によって動作されるメモリ位置のデータ（オペランド）をキャッシュするためのＴＭをサポートするデータ・キャッシュ１１８ａ、１１８ｂとから成る分割キャッシュ（split cache）を有することができる。１つの実装において、複数のダイ１００のキャッシュが相互接続され、複数のダイ１００のキャッシュ間のキャッシュ・コヒーレンシをサポートする。１つの実装においては、分割キャッシュではなく単一のキャッシュが使用され、命令及びデータの両方を保持する。１つの実装においては、ＣＰＵキャッシュは、階層キャッシュ構造におけるキャッシュ・レベル１である。例えば、各ダイ１００は、共有キャッシュ１２４を、ダイ１００上の全てのＣＰＵ間で共有されるように使用することができる。別の実装においては、各ダイは、全てのダイ１００の全てのプロセッサの間で共有される共有キャッシュ１２４へのアクセスを有することができる。

図２は、ＴＭをサポートするための追加物を含む、例示的なトランザクションＣＰＵ１１４の詳細を示す。トランザクションＣＰＵ（プロセッサ）１１４は、レジスタ・チェックポイント１２６及び特殊ＴＭレジスタ１２８をサポートするためのハードウェアを含むことができる。トランザクションＣＰＵキャッシュは、従来のキャッシュのＭＥＳＩビット１３０、タグ１４０及びデータ１４２を含むことができるが、同様に、例えば、トランザクション実行中にＣＰＵ１１４によりラインが読み取られたことを示すＲビット１３２と、トランザクション実行中にＣＰＵ１１４によりラインに書き込まれたことを示すＷビット１３８とを含むことができる。

いずれのＴＭシステムにおいても、プログラマーにとって重要な詳細は、非トランザクション・アクセスがどのようにトランザクションと対話するかである。意図的に、トランザクション・アクセスは、上記の機構を用いて互いから遮蔽される。しかしながら、通常の非トランザクション・ロードと、そのアドレスについての新しい値を含むトランザクションとの間の対話を依然として考慮する必要がある。さらに、非トランザクション・ストアとそのアドレスを読み取ったトランザクションとの間の対話も検討する必要がある。これらは、データベースの概念分離の問題である。

あらゆる非トランザクション・ロード及びストアがアトミック・トランザクションのように動作する場合、ＴＭシステムは、強い分離性（strong isolation）（強いアトミック性（strong atomicity）と呼ばれることもある）を実装すると言われる。従って、非トランザクション・ロードは、コミットされないデータを見ることができず、非トランザクション・ストアは、そのアドレスを読み取ったいずれのトランザクションにおいても、アトミック性違反を引き起こす。これが当てはまらないシステムは、弱いアトミック性（weak atomicity）と呼ばれることもある、弱い分離性（weakisolation）を実装すると言われる。

強い分離性の概念化及び実装が相対的に容易であるため、強い分離性は、弱い分離性よりも望ましいことが多い。さらに、プログラマーが何らかの共有メモリ参照をトランザクションで囲うことを忘れた場合、バグが生じ、強い分離性では、プログラマーはアトミック性違反を引き起こす非トランザクション領域を見るので、プログラマーは、単一のデバッグ・インターフェースを用いて見落としを検出することが多い。また、１つのモデルにおいて書かれたプログラムは、別のモデル上では異なるように動作する場合がある。

さらに、強い分離性は、弱い分離性よりもハードウェアＴＭにおいてサポートが容易であることが多い。強い分離性では、コヒーレンス・プロトコルが既にプロセッサ間のロード及びストア通信を管理しているので、トランザクションは、非トランザクション・ロード及びストアを検出し、適切に動作することができる。ソフトウェア・トランザクション・メモリ（ＴＭ）において強い分離性を実装するためには、非トランザクション・コードを、読み取りバリア（read barrier）及び書き込みバリア（write barrier）を含むように修正する必要があり、性能を損なう可能性がある。多くの不要なバリアを取り除くために多大な努力が費やされてきたが、こうした技術は複雑であることが多く、性能は、通常、ハードウェアＴＭのものに比べてはるかに低い。

表２は、トランザクション・メモリの基本的な設計空間を示す（バーショニング及び競合検出）。

Ｅａｇｅｒ−悲観的（ＥＰ）
後述するこの最初のＴＭ設計は、Ｅａｇｅｒ−悲観的として知られる。ＥＰシステムは、その書き込みセットを「イン・プレースに」格納し（従って、「ｅａｇｅｒ」の名がある）、かつ、ロールバックをサポートするために、上書きされたラインの古い値を「ｕｎｄｏログ」に格納する。プロセッサは、Ｗ１３８キャッシュ・ビット及びＲ１３２キャッシュ・ビットを用いて、読み取り及び書き込みセットを追跡し、スヌープした（snooped）ロード要求を受信したときに競合を検出する。恐らく、既知の文献におけるＥＰシステムの最も顕著な例は、ＬｏｇＴＭ及びＵＴＭである。

ＥＰシステムにおけるトランザクションの開始は、他のシステムにおけるトランザクションの開始とよく似ている：ｔｍ＿ｂｅｇｉｎ（）がレジスタ・チェックポイントを取り、あらゆるステータス・レジスタを初期化する。ＥＰシステムはまたｕｎｄｏログの初期化も必要とし、この詳細はログ・フォーマットに依存するが、多くの場合、予め割り当てられたスレッド・プライベート・メモリの領域へのログ・ベース・ポインタを初期化すること、及びログ境界レジスタをクリアすることを含む。

バージョニング：ＥＰにおいては、ｅａｇｅｒバージョニングが機能するように設計される方法に起因して、ＭＥＳＩ １３０の状態遷移（Ｍｏｄｉｆｉｅｄ（修正）、Ｅｘｃｌｕｓｉｖｅ（排他）、Ｓｈａｒｅｄ（共有）、及びＩｎｖａｌｉｄ（無効）のコード状態に対応するキャッシュライン・インジケータ）は、殆ど変更されないままである。トランザクションの外部では、ＭＥＳＩ １３０の状態遷移は、全く変更されないままである。トランザクション内部のラインを読み取るとき、標準的コヒーレンス遷移が適用され（Ｓ（Ｓｈａｒｅｄ）→Ｓ、Ｉ（Ｉｎｖａｌｉｄ）→Ｓ、又はＩ→Ｅ（Ｅｘｃｌｕｓｉｖｅ））、必要に応じてロード・ミスを発行するが、Ｒ１３２ビットも設定される。同様に、ラインの書き込みに、標準的遷移が適用され（Ｓ→Ｍ、Ｅ→Ｉ、Ｉ→Ｍ）、必要に応じてミスを発行するが、加えてＷ（書き込み）１３８ビットも設定する。現トランザクションがアボートした場合には、ラインが初めて書き込まれる際、ライン全体の古いバージョンをロードし、次に、ｕｎｄｏログに書き込んで保存する。次に、新しく書き込まれたデータが、古いデータの上に「イン・プレースに」格納される。

競合検出：悲観的競合検出は、ミス、又はアップグレード時に交換されるコヒーレンス・メッセージを用いて、トランザクション間の競合を探す。トランザクション内で読み取りミスが発生すると、他のプロセッサはロード要求を受信するが、それらが必要とされるラインを有していない場合には、この要求を無視する。他のプロセッサが、必要とされるラインを非投機的に有する又はラインＲ１３２（読み取り）を有する場合、このラインをＳにダウングレードし、ある場合には、それらがＭＥＳＩ １３０のＭ又はＥ状態でラインを有する場合、キャッシュ間転送（cash-to-cash transfer）を発行する。しかしながら、キャッシュがラインＷ１３８を有する場合には、２つのトランザクション間に競合が検出され、追加のアクションを取らなければならない。

同様に、（最初の書き込み時に）トランザクションがラインをｓｈａｒｅｄからｍｏｄｉｆｉｅｄにアップグレードしようとした際、トランザクションは、競合の検出にも使用される排他的ロード要求を発行する。受信しているキャッシュがラインを非投機的に有する場合、次に、そのラインは無効にされ、特定の場合には、キャッシュ間転送（Ｍ又はＥ状態）が発行される。しかしながら、このラインがＲ１３２又はＷ１３８である場合には、競合が検出される。

妥当性検査：競合検出はあらゆるロードで実施されるので、トランザクションは常に、それぞれの書き込みセットに対する排他的アクセスを有する。従って、妥当性検査は、いずれの付加的な作業も必要としない。

コミット：ｅａｇｅｒバージョニングはデータ項目の新たなバージョンをイン・プレースに格納するので、コミット・プロセスは、単にＷ１３８ビット及びＲ１３２ビットをクリアし、ｕｎｄｏログを廃棄する。

アボート：トランザクションがロールバックすると、ｕｎｄｏログ内の各キャッシュラインのオリジナルのバージョンを復元しなければならず、プロセスは、ログの「アンロール（unrolling）」又は「適用」と呼ばれる。これは、ｔｍ＿ｄｉｓｃａｒｄ（）の間に行われ、他のトランザクションに関してアトミックでなければならない。具体的には、競合を検出するために、書き込みセットを依然として使用しなければならない：このトランザクションは、そのｕｎｄｏログ内にラインの正しいバージョンのみを有し、要求トランザクションは、そのログから正しいバージョンを復元するのを待たなくてはならない。こうしたログは、ハードウェア状態マシン又はソフトウェア・アボート・ハンドラを用いて適用することができる。

Ｅａｇｅｒ−悲観的は、以下の特徴を有する：コミットは単純であり、イン・プレースにあるため非常に高速である。同様に、妥当性検査はノー・オペレーション（ｎｏ−ｏｐ）である。悲観的競合検出は、競合を早期に検出し、それにより、「失敗させられた（doomed）」トランザクションの数が減少する。例えば、２つのトランザクションが、Ｗｒｉｔｅ−Ａｆｔｅｒ−Ｒｅａｄ依存関係に関与する場合、その依存関係は、悲観的競合検出において瞬時に検出される。しかしながら、楽観的競合検出においては、ライタ（writer）がコミットするまで、そうした競合は検出されない。

Ｅａｇｅｒ−悲観的はまた、以下の特徴も有する：上述したように、初めてキャッシュラインに書き込まれる際、古い値をログに書き込む必要があり、余分なキャッシュ・アクセスを招く。アボートはログの取り消し（ｕｎｄｏ）を必要とするため、費用がかかる。ロードは、ログ内のキャッシュラインごとに発行しなければならず、恐らく、次のラインに進む前にメインメモリまで前進する。悲観的競合検出はまた、特定のシリアル化可能なスケジュールの存在を防止する。

さらに、競合は、それらが発生した時に処理されるので、ライブロック（livelock）の可能性があり、前方進行を保証するために、慎重なコンテンション管理機構を利用しなければならない。

Ｌａｚｙ−楽観的（ＬＯ）
別の一般的なＴＭ設計は、Ｌａｚｙ−楽観的（ＬＯ）であり、これは、その書き込みセットを「書き込みバッファ」又は「ｒｅｄｏログ」に格納し、コミット時に競合を検出する（依然として、Ｒ１３２及びＷ１３８ビットを使用する）。

バージョニング：ＥＰシステムと同様に、ＬＯ設計のＭＥＳＩプロトコルが、トランザクションの外側で実施される。トランザクションの内部に入ると、ラインの読み取りは標準的ＭＥＳＩ遷移を招くが、同様にＲ１３２ビットも設定する。同様に、ラインの書き込みは、ラインのＷ１３８ビットを設定するが、ＬＯ設計のＭＥＳＩ遷移の処理は、ＥＰ設計のものとは異なる。第１に、ｌａｚｙバージョニングにおいては、書き込まれたデータの新しいバージョンは、コミットまでキャッシュ階層に格納されるが、他のトランザクションは、メモリ又は他のキャッシュにおいて利用可能な古いバージョンにアクセスすることができる。古いバージョンを利用可能にするために、トランザクションによる最初の書き込み時に、ダーティ・ライン（Ｍライン）を無効化しなければならない。第２に、楽観的競合検出の特徴のため、アップグレード・ミスは必要とされない：競合検出はコミット時に行われるので、トランザクションがＳ状態のラインを有する場合、トランザクションは単にラインに書き込み、変更を他のトランザクションと通信することなく、そのラインをＭ状態にアップグレードするだけでよい。

競合検出及び妥当性検査：トランザクションを検証し、競合を検出するために、ＬＯは、コミットの準備をしているときのみ、投機的に修正されたラインのアドレスを他のトランザクションに通信する。妥当性検査において、プロセッサは、書き込みセット内の全てのアドレスを含む、１つの、恐らくは大容量の、ネットワーク・パケットを送信する。データは送信されないが、コミッタ（committer）のキャッシュ内に残され、ダーティ（Ｍ）とマーク付けされる。Ｗとマーク付けされたラインを求めてキャッシュを検索することなくこのパケットを構築するために、これらの投機的に修正されたラインを追跡するために、キャッシュラインごとに１ビットを有する、「ストア・バッファ」と呼ばれる簡潔ビットベクトル（simple bit vector）を使用する。他のトランザクションは、このアドレス・パケットを使用して競合を検出する：アドレスがキャッシュ内に見つかり、Ｒ１３２ビット及び／又はＷ１３８ビットが設定された場合、競合が開始される。ラインは見つかったが、Ｒ１３２もＷ１３８も設定されない場合には、ラインは単に無効にされ、これは排他的ロードの処理に類似している。

トランザクションのアトミック性をサポートするために、これらのアドレス・パケットをアトミックに処理しなければならない、即ち、同じアドレスに対して２つのアドレス・パケットが同時に存在することはできない。ＬＯシステムにおいては、これは、アドレス・パケットを送信する前に、単にグローバル・コミット・トークンを獲得することにより達成することができる。しかしながら、最初にアドレス・パケットを送信し、応答を収集し、順序付けプロトコルを実施し（恐らく最も古いトランザクションを先頭に）、そして、全ての応答が満たされた場合にコミットすることによって、２段階コミット・スキームを用いることもできる。

コミット：ひとたび妥当性検査が行われると、コミットは、いかなる特別な処理も必要とせず、単にＷ１３８ビット及びＲ１３２ビット、並びにストア・バッファをクリアするだけである。トランザクションの書き込みは既にキャッシュ内でダーティとしてマーク付けされており、これらのラインの他のキャッシュのコピーは、アドレス・パケットにより無効にされる。次に、他のプロセッサは、通常のコヒーレンス・プロトコルを通じてコミットされたデータにアクセスすることができる。

アボート：ロールバックは等しく容易である：書き込みセットがローカル・キャッシュ内に含まれているので、これらのラインを無効にすることができ、次に、Ｗ１３８ビット及びＲ１３２ビット、並びにストア・バッファをクリアする。ストア・バッファは、キャッシュを検索する必要なしに、Ｗラインを見つけて無効にすることを可能にする。

Ｌａｚｙ−楽観的は、以下の特徴を有する：即ち、アボートは非常に高速であり、付加的なロード又はストアを必要とせず、ローカル変更のみを行う。ＥＰにおいて見出されるよりも多くのシリアル化可能なスケジュールが存在することができ、これにより、トランザクションが独立であることを、ＬＯシステムがより積極的に推測することが可能になり、そのことはより高い性能をもたらし得る。最終的に、競合検出が遅いと前方進行の可能性が高くなり得る。

Ｌａｚｙ−楽観的はまた、以下の特徴を有する：即ち、妥当性検査では、書き込みセットのサイズに比例してグローバル通信時間を要する。コミット時にしか競合が検出されないので、失敗させられたトランザクションは無駄な作業になり得る。

Ｌａｚｙ−悲観的（ＬＰ）
Ｌａｚｙ−悲観的（ＬＰ）は、ＥＰとＬＯとの間のどこかに位置する第３のＴＭ設計選択肢を表し：新しく書き込まれたラインを書き込みバッファに格納するが、アクセスごとに競合を検出する。

バージョニング：バージョニングはＬＯのものと類似しているが、同一ではない：ラインの読み取りによりＲビット１３２が設定され、ラインの書き込みによりＷビット１３８が設定され、ストア・バッファは、キャッシュ内のＷラインを追跡するために使用される。また、ＬＯと同様に、トランザクションによる最初の書き込み時に、ダーティ（Ｍ）ラインを無効化しなければならない。しかしながら、競合検出は悲観的であるので、トランザクション・ラインをＩ，Ｓ→Ｍにアップグレードするときに、ｌｏａｄ ｅｘｃｌｕｓｉｖｅを実行しなければならず、これはＬＯとは異なる。

競合検出：ＬＰの競合検出は、ＥＰのものと同様に動作する：コヒーレンス・メッセージを用いて、トランザクション間の競合を探す。

妥当性検査：ＥＰにおけるように、悲観的競合検出は、どの時点でも、実行中のトランザクションがいずれの他の実行中のトランザクションとも競合しないことを保証し、従って、妥当性検査はノー・オペレーションである。

コミット：ＬＯにおけるように、コミットは、特別な処理を必要としない：単にＷ１３８ビット及びＲ１３２ビット、並びにストア・バッファをクリアするだけである。

アボート：ロールバックもまた、ＬＯのものに類似している：単にストア・バッファを用いて書き込みセットを無効にし、Ｗビット及びＲビット、並びにストア・バッファをクリアするだけである。

ＬＰは、以下の特徴を有する：ＬＯと同様に、アボートは非常に高速である。ＥＰと同様に、悲観的競合検出の使用により、「失敗させられた」トランザクションの数が低減する。ＥＰと同様に、一部のシリアル化可能なスケジュールは許容されず、キャッシュ・ミスごとに競合検出を実施しなければならない。

Ｅａｇｅｒ−楽観的（ＥＯ）
バージョニングと競合検出の最終的な組み合わせは、Ｅａｇｅｒ−楽観的（ＥＯ）である。ＥＯはＨＴＭシステムにとって最適とはいえない選択肢であり得る：新しいトランザクション・バージョンはイン・プレースに書き込まれるので、競合の発生時に（即ち、キャッシュ・ミスの発生時に）競合に気付かざるを得ない。しかしながら、ＥＯはコミット時まで競合の検出を待つので、これらのトランザクションは「ゾンビー（zombie）」になり、実行を続行し、リソースを浪費し、しかもアボートする「運命にある」。

ＥＯは、ＳＴＭにおいて有用であることが分かっており、Ｂａｒｔｏｋ−ＳＴＭ及びＭｃＲＴにより実装される。ｌａｚｙバージョニングＳＴＭは、読み取りごとに書き込みバッファをチェックし、最新の値を読み取っていることを保証する必要がある。書き込みバッファはハードウェア構造ではないので、高価であり、従って、ｗｒｉｔｅ−ｉｎ−ｐｌａｃｅを好む。付加的に、競合のチェックもまた、ソフトウェアＴＭにおいて高価であるので、楽観的競合検出は、この操作をまとめて実行する利点をもたらす。

コンテンション管理
ひとたびシステムがそのトランザクションのアボートを決定すると、トランザクションがどのようにロールバックするかについて上述したが、競合には２つのトランザクションが関与するので、どのトランザクションをアボートすべきか、そのアボートをどのように開始すべきか、及びアボートされたトランザクションをいつ再試行すべきかのトピックを検討する必要がある。これらは、トランザクション・メモリの重要なコンポーネントである、コンテンション管理（ＣＭ）により対処されるトピックである。システムがどのようにアボートを開始するか、及び、競合においてどのトランザクションをアボートすべきかを管理する種々の確立された方法が後述される。

コンテンション管理ポリシー
コンテンション管理（ＣＭ）ポリシーは、競合に関与するどのトランザクションをアボートすべきか、及び、アボートされたトランザクションをいつ再試行すべきかを決定する機構である。例えば、アボートされたトランザクションを瞬時に再試行することが最良の性能につながらない場合が多い。逆に、アボートされたトランザクションの再試行を遅延させるバックオフ機構を用いるが、より良い性能をもたらすことがある。ＳＴＭは最初に最良のコンテンション管理ポリシーを見出すことに取り組んでおり、以下に概説したポリシーの多くは、もともとソフトウェアＴＭ向けに開発されたものである。

ＣＭポリシーは、トランザクションのエイジ（age）、読み取りセット及び書き込みセットのサイズ、以前のアボート数などを含む、判断を行うための多数の尺度を利用する。こうした判断を行うための尺度の組み合わせは無限にあるが、特定の組み合わせを、複雑性が高い順に大まかに後述する。

幾つかの専門語を確立するために、最初に、競合においては、アタッカ（attacker）及びデフェンダ（defender）の両者が存在することに留意されたい。アタッカは、共有メモリ位置へのアクセスを要求しているトランザクションである。悲観的競合検出においては、アタッカは、ｌｏａｄ又はｌｏａｄ ｅｘｃｌｕｓｉｖｅを発行するトランザクションである。楽観的競合検出においては、アタッカは、検証を行おうとするトランザクションである。デフェンダは、どちらの場合も、アタッカの要求を受け取るトランザクションである。

積極的な（Aggressive）ＣＭポリシーは、瞬時にかつ常にアタッカ又はデフェンダのいずれかを再試行する。ＬＯにおいては、積極的とは、アタッカが常に勝つことを意味し、従って、積極的は、コミッタの勝利と呼ばれることもある。こうしたポリシーは、最も初期のＬＯシステムに使用された。ＥＰの場合には、積極的は、デフェンダの勝利、又はアタッカの勝利のいずれかとすることができる。

直ちに別の競合に直面する競合するトランザクションの再開は、必ず作業の無駄を引き起こす、即ち、相互接続される帯域幅がキャッシュ・ミスを再充填する。丁寧な（Polite）ＣＭポリシーは、競合を再開する前に、指数関数的バックオフ（exponentialbackoff）を使用する（しかし、線形を用いることもできる）。スターベーション（starvation）、即ち、プロセスがスケジューラにより割り当てられたリソースを有していない状況を防止するために、指数関数的バックオフは、およそｎ回の再試行後、トランザクションの成功の勝算を大幅に高める。

競合解決の別の手法は、アタッカ又はデフェンダをランダムにアボートすることである（ランダム化（Randomized）と呼ばれるポリシー）。こうしたポリシーは、不必要なコンテンションを回避するためのランダム化バックオフ・スキームと組み合わせることができる。

しかしながら、アボートするトランザクションを選択する際、ランダムな選択を行うことは、「多くの作業」を完了したトランザクションのアボートをもたらすことがあり、これによりリソースが無駄になり得る。こうした無駄を回避するために、どのトランザクションをアボートするかを決定するときに、トランザクションにおける完了した作業の量を考慮に入れることができる。作業の１つの尺度は、トランザクションのエイジとすることができる。他の方法として、Ｏｌｄｅｓｔ、Ｂｕｌｋ ＴＭ、Ｓｉｚｅ Ｍａｔｔｅｒｓ、Ｋａｒｍａ、及びＰｏｌｋａが挙げられる。Ｏｌｄｅｓｔは、競合における若い方のトランザクションをアボートする単純なタイムスタンプである。Ｂｕｌｋ ＴＭはこのスキームを使用する。Ｓｉｚｅ Ｍａｔｔｅｒｓは、Ｏｌｄｅｓｔに類似しているが、トランザクションのエイジの代わりに、読み取り／書き込みワードの数が優先順位として用いられ、一定数のアボートの後、Ｏｌｄｅｓｔに戻る。Ｋａｒｍａは類似しており、書き込みセットのサイズを優先順位として用いる。次に、一定の時間バックオフした後、ロールバックが進行する。アボートされたトランザクションは、アボートされた後もその優先順位を保持する（従って、Ｋａｒｍａの名が付いている）。Ｐｏｌｋａは、Ｋａｒｍａと同様であるが、所定の時間バックオフする代わりに、毎回指数関数的により多くバックオフする。

アボートは作業を無駄にするので、デフェンダがそのトランザクションを終了するまでアタッカをストールすることがより良い性能をもたらすという議論は理にかなっている。残念なことに、こうした単純なスキームは、容易にデッドロックをもたらす。

この問題を解決するために、デッドロック回避技術を用いることができる。Ｇｒｅｅｄｙは、デッドロックを回避するために２つの規則を用いる。第１の規則は、第１のトランザクションＴ１が第２のトランザクションＴ０よりも低い優先順位を有する場合、又は、Ｔ１が別のトランザクションを待っている場合、Ｔ１は、Ｔ０との競合時にアボートするというものである。第２の規則は、Ｔ１がＴ０よりも高い優先順位を有し、待機していない場合、Ｔ０は、Ｔ１のコミットまで待つか、アボートするか、又は待機を開始する（この場合、第１の規則が適用される）というものである。Ｇｒｅｅｄｙは、トランザクションのセットを実行するための期限についての何らかの保証を提供する。１つのＥＰ設計（ＬｏｇＴＭ）は、Ｇｒｅｅｄｙに類似したＣＭポリシーを用いて、保守的なデッドロック回避によるストールを達成する。

例示的なＭＥＳＩコヒーレンシ規則は、マルチプロセッサ・キャッシュ・システムのキャッシュラインが存在し得る４つの可能な状態、即ち、次のように定義される４つの可能な状態Ｍ、Ｅ、Ｓ、Ｉを提供する。：
Ｍｏｄｉｆｉｅｄ（Ｍ）：キャッシュラインは現キャッシュ内にのみ存在し、ダーティである。即ち、キャッシュラインは、メインメモリ内の値から修正されている。キャッシュは、（もはや有効ではない）メインメモリ状態のいずれかの他の読み取りを可能にする前に、将来のいずれかの時点で、データをメインメモリにライトバックしなければならない。ライトバックによりラインはＥｘｃｌｕｓｉｖｅ状態に変化する。
Ｅｘｃｌｕｓｉｖｅ（Ｅ）：キャッシュラインは現キャッシュ内にのみ存在するが、クリーンである。即ち、キャッシュラインはメインメモリと一致する。キャッシュラインは、読み取り要求に応答して、いつでもＳｈａｒｅｄ状態に変わることが可能である。代替的に、キャッシュラインは、書き込みがなされると、Ｍｏｄｉｆｉｅｄ状態に変わることが可能である。
Ｓｈａｒｅｄ（Ｓ）：このキャッシュラインは、マシンの他のキャッシュ内に格納することができ、「クリーン」であることを示す。即ち、このキャッシュラインはメインメモリと一致する。ラインは、いつでも廃棄する（Ｉｎｖａｌｉｄ状態に変更する）ことができる。
Ｉｎｖａｌｉｄ（Ｉ）：このキャッシュラインが、無効である（未使用である）ことを示す。

ＭＥＳＩコヒーレンシ・ビットに加えて又はそこに符号化された、各キャッシュラインに対して、ＴＭコヒーレンシ・ステータス・インジケータ（Ｒ１３２、Ｗ１３８）を設けることができる。Ｒ１３２インジケータは、現トランザクションがキャッシュラインのデータから読み取りを行ったことを示し、Ｗ１３８インジケータは、現トランザクションがキャッシュラインのデータに書き込みを行ったことを示す。

ＴＭ設計の別の態様において、システムは、トランザクション・ストア・バッファを用いて設計される。２０００年３月３１日に出願され、その全体が引用により本明細書に組み入れられる「Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｒｅｏｒｄｅｒｉｎｇ ａｎｄ Ｒｅｎａｍｉｎｇ Ｍｅｍｏｒｙ Ｒｅｆｅｒｅｎｃｅｓ ｉｎ ａ Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ」という名称の特許文献１は、少なくとも第１及び第２のプロセッサを有するマルチプロセッサ・コンピュータ・システムにおいて、メモリ参照を再順序付けし、再命名するための方法を教示する。第１のプロセッサは、第１のプライベート・キャッシュ及び第１のバッファを有し、第２のプロセッサは、第２のプライベート・キャッシュ及び第２のバッファを有する。この方法は、第１のプロセッサが受信した、データを格納する複数のゲート付きストア要求（gated store request）の各々について、第１のプライベート・キャッシュによって、データを含むキャッシュラインを排他的に取得し、データを第１のバッファに格納する動作を含む。第１のバッファが、第１のプロセッサから、特定のデータをロードするロード要求を受信すると、ロード及びストア操作のイン・オーダー・シーケンスに基づいて、特定のデータが、第１のバッファに格納されたデータの中から第１のプロセッサに提供される。第１のキャッシュが所定データのロード要求を第２のキャッシュから受信すると、エラー条件が示され、所定データのロード要求が第１のバッファに格納されたデータに対応する場合、プロセッサの少なくとも１つの現在の状態が以前の状態にリセットされる。

１つのこうしたトランザクション・メモリ機能の主要実装コンポーネントは、トランザクション前の（pre-transaction）ＧＲ（汎用レジスタ）のコンテンツを保持するためのトランザクション・バックアップ・レジスタ・ファイル、トランザクション中にアクセスされたキャッシュラインを追跡するためのキャッシュ・ディレクトリ、トランザクションが終了するまでストアをバッファするためのストア・キャッシュ、及び種々の複雑な機能を実施するためのファームウェア・ルーチンである。本セクションでは、詳細な実装を説明する。

ＩＢＭ ｚＥｎｔｅｒｐｒｉｓｅ ＥＣ１２エンタープライズ・サーバの実施形態
ＩＢＭ ｚＥｎｔｅｒｐｒｉｓｅ ＥＣ１２エンタープライズ・サーバは、トランザクション・メモリにトランザクション実行（ＴＸ）を導入し、その全体が引用により本明細書に組み入れられる非特許文献５に部分的に説明される。

表３は、例示的なトランザクションを示す。例えば他のＣＰＵとの競合の繰り返しが原因で、あらゆる実行の試行においてアボート条件に遭遇し得るので、ＴＢＥＧＩＮで開始されたトランザクションが、ＴＥＮＤで常に成功裏に完了することは保証されない。このことは、プログラムが、例えば従来のロック・スキームを用いることにより、同じ操作を非トランザクション的に実行するためにフォールバック経路をサポートすることを必要とする。このことは、特にフォールバック経路が信頼できるコンパイラによって自動的に生成されない場合、プログラミング及びソフトウェア検証チームに著しい負担をかける。

アボートされたトランザクション実行（ＴＸ）のトランザクションに対してフォールバック経路を提供する要件は、負担になり得る。共有データ構造で動作する多くのトランザクションは短いものであり、ぼんの数個の個別メモリ位置にタッチし、単純な命令しか使用しないと考えられる。これらのトランザクションに対して、ＩＢＭ ｚＥｎｔｅｒｐｒｉｓｅ ＥＣ１２は、制約付き（constrained）トランザクションの概念を導入する。通常の条件下で、ＣＰＵ１１４は、制約付きトランザクションが、たとえ必要な再試行の数に厳密な制限を与えなくても最終的に成功裏に終了することを保証する。制約付きトランザクションは、ＴＢＥＧＩＮＣ命令で開始し、通常のＴＥＮＤで終了する。制約付きトランザクション又は制約なしトランザクションとしてのタスクの実装は、一般的に、極めて匹敵する機能をもたらすが、制約付きトランザクションは、フォールバック経路に対する必要性を取り除くことにより、ソフトウェア開発を簡単化する。ＩＢＭのトランザクション実行アーキテクチャは、その全体が引用により本明細書に組み入れられる非特許文献２にさらに説明される。

制約付きトランザクションは、ＴＢＥＧＩＮＣ命令で開始する。ＴＢＥＧＩＮＣで開始されたトランザクションは、プログラミング上の制約のリストに従わなければならない。そうでない場合には、プログラムはフィルタリング可能でない制約違反割り込み（non-filterable constraint-violation interruption）を利用する。例示的な制約として、これらに限定されるものではないが、トランザクションは最大３２個の命令を実行することができる、全ての命令テキストはメモリの連続した２５６バイトの範囲内になければならない、トランザクションは前方を指示する相対分岐のみを含む（即ち、ループ又はサブルーチン呼び出しはない）、トランザクションはメモリの最大４つの位置合わせされたオクトワード（オクトワードは３２バイトである）にアクセスすることができる、及び１０進演算又は浮動小数点数演算のような複雑な命令を除外するための命令セットの制限を挙げることができる。最大４つの位置合わせされたオクトワードをターゲットにするアトミックｃｏｍｐａｒｅ−ａｎｄ−ｓｗａｐの非常に強力な概念を含む、二重連結リスト（doubly linked list）−挿入／削除演算のような多くの一般的な演算を実行できるように、制約が選択される。同時に、制約は、将来のＣＰＵ実装が、制約の調整を必要とせずにトランザクションの成功を保証できるように保守的に選択されるが、それは、そうでない場合にソフトウェアの非互換性を招くためである。

ＴＢＥＧＩＮＣは、浮動小数点数レジスタ（ＦＰＲ）制御及びプログラム割り込みフィルタリング・フィールドが存在せず、制御はゼロであると見なされる点を除いて、大部分は、ＴＳＸにおけるＸＢＥＧＩＮ又はＩＢＭ（登録商標）のｚＥＣ１２サーバ上のＸＢＥＧＩＮのように挙動する。トランザクションがアボートすると、命令アドレスは、制約付きトランザクションについての即時再試行及びアボート経路の不存在を反映して、命令の後ではなく、直接ＴＢＥＧＩＮＣに戻される。

ネスト化されたトランザクションは、制約付きトランザクション内で許容されないが、ＴＢＥＧＩＮＣが非制約付きトランザクション内で行われた場合には、ＴＢＥＧＩＮと同様に新しい非制約付きネスト・レベルを開くものとして扱われる。このことは、例えば、非制約付きトランザクションが制約付きトランザクションを内部で使用するサブルーチンを呼び出した場合などに起こり得る。

割り込みフィルタリングは暗黙的にオフにされるので、制約付きトランザクション中の全ての例外は、オペレーティング・システム（ＯＳ）への割り込みをもたらす。最終的なトランザクションの終了の成功は、いずれかの制約付きトランザクションによりタッチされたせいぜい４ページをページインするＯＳの能力に依存する。ＯＳはまた、トランザクションが完了するのを可能にするのに十分に長いタイムスライスも保証しなければならない。

表４は、制約付きトランザクションが他のロック・ベースのコードと対話しないと仮定する、表３のコードの制約付きトランザクション実装を示す。従って、ロック・テストは示されないが、制約付きトランザクションとロック・ベースのコードが混合された場合には、これを付加することができる。

失敗が繰り返し起こった場合、ソフトウェア・エミュレーションが、システム・ファームウェアの一部としてミリコードを用いて実施される。有利なことに、プログラマーから負担が取り除かれるので、制約付きトランザクションは所望の特性を有する。

図３を参照すると、ＩＢＭ ｚＥｎｔｅｒｐｒｉｓｅ ＥＣ１２プロセッサは、トランザクション実行ファシリティを導入した。このプロセッサは、クロックサイクルごとに３つの命令をデコードすることができる。即ち、単純な命令は、単一のｍｉｃｒｏ−ｏｐ（マイクロ・オペレーション）としてディスパッチされ、より複雑な命令は、複数のｍｉｃｒｏ−ｏｐに分割される。ｍｉｃｒｏ−ｏｐ（Ｕｏｐｓ２３２ｂ）が、統合された発行キュー２１６に書き込まれ、そこから、それらをアウト・オブ・オーダー式に発行することができる。サイクルごとに、最大２つの固定小数点数命令、１つの浮動小数点数命令、２つのロード／ストア命令、及び２つの分岐命令を実行することができる。グローバル完了テーブル（ＧＣＴ）２３２は、あらゆるｍｉｃｒｏ−ｏｐ及びトランザクション・ネスト化深さ（transaction nesting depth、ＴＮＤ）２３２ａを保持する。ＧＣＴ２３２は、デコード時にイン・オーダー式に書き込まれ、各ｍｉｃｒｏ−ｏｐ２３２ｂの実行ステータスを追跡し、最も古い命令グループの全てのｍｉｃｒｏ−ｏｐ２３２ｂが成功裏に実行されると、命令を完了する。

レベル１（Ｌ１）データ・キャッシュ２４０は、２５６バイトのキャッシュライン及び４サイクルの使用待ち時間を有する９６ＫＢ（キロバイト）の６ウェイ・アソシアティブ・キャッシュ（6-way associative cache）であり、Ｌ１ ２４０ミスに対して７サイクルの使用待ち時間ペナルティを有して、プライベート１ＭＢ（メガバイト）の８ウェイ・アソシアティブ第２レベル（Ｌ２）データ・キャッシュ２６８に結合される。Ｌ１ ２４０キャッシュは、プロセッサに最も近いキャッシュであり、Ｌｎキャッシュは、第ｎ番目のキャッシュ・レベルのキャッシュである。Ｌ１ ２４０キャッシュ及びＬ２ ２６８キャッシュの両方とも、ストアスルー（store through）方式である。各々の中央処理装置（ＣＰ）チップ上の６つのコアは、４８ＭＢの第３レベル・ストアイン（store-in）方式キャッシュを共有し、６つのＣＰチップは、ガラス・セラミック・マルチチップ・モジュール（ＭＣＭ）上に一緒にパッケージ化されたオフ・チップの３８４ＭＢの第４レベル・キャッシュに接続される。最大４つのマルチチップ・モジュール（ＭＣＭ）を、最大１４４個のコアを有するコヒーレントな対称マルチプロセッサ（ＳＭＰ）システムに接続することができる（顧客のワークロードを実行するのに全てのコアが利用可能とは限らない）。

コヒーレンシは、ＭＥＳＩプロトコルの変形により管理される。キャッシュラインは、読み取り専用（ｓｈａｒｅｄ）又はｅｘｃｌｕｓｉｖｅで所有することができ、Ｌ１ ２４０及びＬ２ ２６８はストアスルー方式であり、従って、ダーティラインを含まない。Ｌ３ ２７２及びＬ４のキャッシュ（図示せず）はストアイン方式であり、ダーティ状態を追跡する。各キャッシュは接続された全ての下位レベルのキャッシュを含む。

コヒーレンシ要求は「相互問い合わせ」（cross interrogate、ＸＩ）と呼ばれ、上位レベルのキャッシュから下位レベルのキャッシュにかつＬ４間で階層的に送信される。１つのコアがＬ１ ２４０及びＬ２ ２６８をミスし、ローカルＬ３ ２７２からキャッシュラインを要求すると、Ｌ３ ２７２は、Ｌ３がこのラインを所有するかどうかをチェックし、必要に応じて、コヒーレンシを保証するために、そのＬ３ ２７２下で現在所有しているＬ２ ２６８／Ｌ１ ２４０にＸＩを送信してから、キャッシュラインを要求側に戻す。要求がＬ３ ２７２もミスした場合、Ｌ３ ２７２は要求をＬ４（図示せず）に送信し、Ｌ４は、ＸＩをそのＬ４下の全ての必要なＬ３及び近隣のＬ４に送信することによって、コヒーレンシを実施する。次に、Ｌ４は要求中のＬ３に応答し、Ｌ３は応答をＬ２ ２６８／Ｌ１ ２４０に転送する。

キャッシュ階層の包含の規則のために、要求から他のキャッシュラインへのアソシアティビティ・オーバーフローにより引き起こされた上位レベルのキャッシュに対するエビクション（eviction）が原因で、キャッシュラインが下位レベルのキャッシュから相互問い合わせされる（ＸＩ）ことに留意されたい。これらのＸＩは「ＬＲＵ ＸＩ」と呼ぶことができ、ここでＬＲＵは、最長時間未使用（least recently used）を意味する。

さらに別のタイプのＸＩ要求を参照すると、Ｄｅｍｏｔｅ−ＸＩは、キャッシュ・オーナーシップを、ｅｘｃｌｕｓｉｖｅからｒｅａｄ−ｏｎｌｙ（読み取り専用）状態に遷移させ、Ｅｘｃｌｕｓｉｖｅ−ＸＩは、キャッシュ・オーナーシップをｅｘｃｌｕｓｉｖｅからｉｎｖａｌｉｄ状態に遷移させる。Ｄｅｍｏｔｅ−ＸＩ及びＥｘｃｌｕｓｉｖｅ−ＸＩは、元のＸＩ送信者への応答を必要とする。ターゲット・キャッシュは、ＸＩを「受け入れる」ことができ、又は、ＸＩを受け入れる前に最初にダーティ・データをエビクトする必要がある場合には、「拒否」応答を送信することができる。Ｌ１ ２４０／Ｌ２ ２６８はストアスルー方式であるが、ストア・キュー内に、排他的状態をダウングレードする前にＬ３に送信する必要があるストアを有する場合には、ｄｅｍｏｔｅ−ＸＩ及びｅｘｃｌｕｓｉｖｅ−ＸＩを拒否することができる。拒否されたＸＩは、送信者により繰り返される。Ｒｅａｄ−ｏｎｌｙ−ＸＩは、ラインを読み取り専用で所有するキャッシュに送信され、こうしたＸＩを拒否することができないので、こうしたＸＩに対して応答は必要ない。ＳＭＰプロトコルの詳細は、その全体が引用により本明細書に組み入れられる非特許文献６により、ＩＢＭ ｚ１０に関して説明されるものと類似している。

トランザクション命令の実行
図３は、ＣＰＵ１１４及びこれが対話するキャッシュ／コンポーネント（図１及び図２に示されるもののような）を含む、例示的なＣＰＵ環境１１２の例示的なコンポーネントを示す。命令デコード・ユニット（ＩＤＵ）２０８は、現トランザクション・ネスト化深さ２１２（ＴＮＤ）を常時監視している。ＩＤＵ２０８がＴＢＥＧＩＮ命令を受信すると、ネスト化深さ２１２がインクリメントされ、逆に、ＴＥＮＤ命令時にはデクリメントされる。あらゆるディスパッチされた命令について、ネスト化深さ２１２がＧＣＴ２３２に書き込まれる。ＴＢＥＧＩＮ又はＴＥＮＤが、後でフラッシュされる投機的経路上でデコードされると、ＩＤＵ２０８のネスト化深さ２１２は、フラッシュされない最も若いＧＣＴ２３２エントリからリフレッシュされる。実行ユニットによる、大部分はロード／ストア・ユニット（ＬＳＵ）２８０による消費のために、トランザクション状態も発行キュー２１６内に書き込まれ、実効アドレス計算器２３６もＬＳＵ２８０内に含まれる。ＴＢＥＧＩＮ命令は、ＴＥＮＤ命令に到達する前にトランザクションがアボートした場合にステータス情報を記録するためのトランザクション診断ブロック（ＴＤＢ）を指定することができる。

ネスト化深さと同様に、ＩＤＵ２０８／ＧＣＵ２３２は、トランザクション・ネストを通じて、アクセス・レジスタ／浮動小数点数レジスタ（ＡＲ／ＦＰＲ）修正マスクを協調的に追跡する。即ち、ＡＲ／ＦＰＲ修正命令がデコードされ、修正マスクがそれをブロックすると、ＩＤＵ２０８は、アボート要求をＧＣＴ２３２内に配置することができる。命令がｎｅｘｔ−ｔｏ−ｃｏｍｐｌｅｔｅになると、完了がブロックされ、トランザクションがアボートする。制約付きトランザクション内にある間にデコードされた場合又は最大ネスト化深さを上回る場合、ＴＢＥＧＩＮも含む他の制限付き命令が同様に処理される。

最外ＴＢＥＧＩＮは、ＧＲ−Ｓａｖｅ−Ｍａｓｋに応じて、複数のｍｉｃｒｏ−ｏｐに分割され、各ｍｉｃｒｏ−ｏｐ２３２ｂ（例えば、ｕｏｐ０、ｕｏｐ１及びｕｏｐ２を含む）は、２つの固定小数点数ユニット（ＦＸＵ）２２０の一方によって実行され、トランザクション・アボートの場合、１対のＧＲ２２８を、ＧＲ２２８のコンテンツを後で復元するために用いられる特殊トランザクション・バックアップ・レジスタ・ファイル２２４内に保存する。ＴＢＥＧＩＮはまた、１が指定されている場合、ＴＤＢのアクセシビリティ・テストを実施するためのｍｉｃｒｏ−ｏｐ２３２ｂも生成し、このアドレスは、アボートの場合に後で使用するために、専用レジスタ内に保存される。最外ＴＢＥＧＩＮのデコードにおいて、潜在的な後のアボート処理のために、ＴＢＥＧＩＮの命令アドレス及び命令テキストもまた、専用レジスタ内に保存される。

ＴＥＮＤ及びＮＴＳＴＧは、単純なｍｉｃｒｏ−ｏｐ２３２ｂ命令である。ＮＴＳＴＧ（非トランザクション・ストア（non-transactional store））は、発行キュー２１６において非トランザクションとしてマーク付けされ、ＬＳＵ２８０がそれを適切に処理できるようにする点を除いて、通常のストアのように処理される。ＴＥＮＤは、実行時にノー・オペレーションであり、ＴＥＮＤが完了したときに、トランザクションの終了が行われる。

上述のように、トランザクション内にある命令は、発行キュー２１６においてそのようにマーク付けされるが、他の点ではほぼ変更されずに実行され、ＬＳＵ２８０は、次のセクションで説明されるように、分離追跡（isolation track）を行う。

デコードはイン・オーダー式であり、かつ、ＩＤＵ２０８は現在のトランザクション・ステータスを常時監視し、これをトランザクションからの全ての命令と併せて発行キュー２１６内に書き込むことから、ＴＢＥＧＩＮ、ＴＥＮＤ、並びにトランザクションの前、内部及び後の命令の実行は、アウト・オブ・オーダー式に実行することができる。ＴＥＮＤを最初に、トランザクション全体を次に実行し、最後にＴＢＥＧＩＮを実行することさえ可能である（可能性は低いが）。プログラム順は、完了時にＧＣＴ２３２により復元される。汎用レジスタ（ＧＲ）２２８は、バックアップ・レジスタ・ファイル２２４から復元することができるので、トランザクションの長さは、ＧＣＴ２３２のサイズによって制限されない。

実行中、プログラム・イベント記録（ＰＥＲ）イベントが、イベント抑止制御に基づいてフィルタリングされ、ＰＥＲ ＴＥＮＤイベントは、イネーブルにされた場合に検出される。同様に、トランザクション・モードにある間、トランザクション診断制御によりイネーブルにされたときに、擬似乱数生成器がランダム・アボートを引き起こしていることがある。

トランザクション分離の追跡
ロード／ストア・ユニット２８０は、トランザクション実行中にアクセスされたキャッシュラインを追跡し、別のＣＰＵからのＸＩ（又はＬＲＵ−ＸＩ）がフットプリントと競合する場合にアボートをトリガする。競合するＸＩがｅｘｃｌｕｓｉｖｅ又はｄｅｍｏｔｅ ＸＩである場合、Ｌ３ ２７２がＸＩを繰り返す前にトランザクションが終了することを期待して、ＬＳＵ ２８０はＸＩを拒否してＬ３ ２７２に戻す。この「押しのけ（stiff-arming）」は、高競合状態のトランザクションにおいて非常に有効である。２つのＣＰＵが互いに押しのけ合う際のハングアップを防止するために、ＸＩ拒否カウンタが実装され、該ＸＩ拒否カウンタは、閾値が満たされると、トランザクション・アボートをトリガする。

Ｌ１キャッシュ・ディレクトリ２４０は、従来より、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）で実装される。トランザクション・メモリの実装では、ディレクトリの有効ビット２４４（６４行×６ウェイ）は通常の論理ラッチに移動され、キャッシュラインごとにさらに２つのビット、即ちＴＸ−読み取りビット２４８及びＴＸ−ダーティビット２５２が補充される。

新しい最外ＴＢＥＧＩＮ（先のまだ保留中のトランザクションに対してインターロックされる）がデコードされると、ＴＸ−読み取り２４８ビットがリセットされる。ＴＸ−読み取り２４８ビットは、発行キュー内で「トランザクショナル（transactional）」としてマーク付けされた全てのロード命令によって実行時に設定される。これは、投機的ロードが、例えば誤って予測された分岐経路上で実行される場合に、過剰なマーク付けをもたらし得ることに留意されたい。ロード完了時にＴＸ−読み取り２４８ビットを設定する代替案は、複数のロードが同時に完了することがあり、ロード・キュー上に多数の読み取りポートを必要とすることから、シリコン面積に対して高価すぎるものであった。

ストアは、非トランザクション・モードと同じ方法で実行されるが、トランザクション・マークが、ストア命令のストア・キュー（ＳＴＱ）２６０エントリ内に置かれる。ライトバック時に、ＳＴＱ２６０からのデータがＬ１ ２４０内に書き込まれるとき、書き込まれたキャッシュラインに関して、Ｌ１ディレクトリ２５６内のＴＸ−ダーティビット２５２が設定される。Ｌ１ ２４０へのストア・ライトバックは、ストア命令が完了した後にのみ行われ、サイクルごとにせいぜい１つのストアがライトバックされる。完了及びライトバックの前に、ロードは、ストア転送により、ＳＴＱ２６０からのデータにアクセスすることができ、ライトバック後は、ＣＰＵ１１４（図２）は、Ｌ１ ２４０内の投機的に更新されたデータにアクセスすることができる。トランザクションが成功裏に終了した場合、全てのキャッシュラインのＴＸ−ダーティビット２５２はクリアされ、ＳＴＱ２６０において、まだ書き込まれていないストアのＴＸ−マークもクリアされ、有効に保留中のストアを通常のストアに変える。

トランザクションがアボートすると、全ての保留中のトランザクション・ストアは、既に完了したものでさえ、ＳＴＱ２６０から無効にされる。Ｌ１ ２４０内のトランザクションにより修正された、つまり、ＴＸ−ダーティビット２５２がオンにされ、その有効ビットがオフにされた、全てのキャッシュラインが、有効に、これらをＬ１ ２４０キャッシュから瞬時に取り除く。

アーキテクチャは、新しい命令を完了する前に、トランザクションの読み取りセット及び書き込みセットの分離が保持されることを必要とする。この分離は、ＸＩが保留中の適切な時点で命令の完了をストールすることにより確実にされる。投機的なアウト・オブ・オーダー式実行が許容され、保留中のＸＩが異なるアドレスに対するものであり且つ実際にトランザクション競合を引き起こさないと楽観的に仮定する。この設計は、アーキテクチャが必要とする強力なメモリ順序付けを保証するために最新のシステム上に実装されるＸＩ対完了（XI-vs-completion）インターロックに非常に自然に適合する。

Ｌ１ ２４０がＸＩを受信すると、Ｌ１ ２４０はディレクトリにアクセスして、相互問い合わせ（ＸＩ）されたＬ１ ２４０内のアドレスの有効性をチェックし、相互問い合わせ（ＸＩ）されたライン上でＴＸ−読み取りビット２４８がアクティブであり、かつ、ＸＩが拒否されない場合、ＬＳＵ２８０がアボートをトリガする。アクティブなＴＸ−読み取りビット２４８を有するキャッシュラインがＬ１ ２４０から最長時間未使用（ＬＲＵ）にされると、特別なＬＲＵ拡張ベクトルは、Ｌ１ ２４０の６４行の各々について、その行上にＴＸ−読み取りラインが存在したことを思い出す。ＬＲＵ拡張に対して正確なアドレス追跡は存在しないので、あらゆる拒否されないＸＩが有効な拡張行にヒットし、ＬＳＵ２８０がアボートをトリガする。正確でないＬＲＵ拡張追跡に対する他のＣＰＵ１１４（図１）との競合がアボートを引き起こさなければ、ＬＲＵ拡張の提供は、Ｌ１サイズからＬ２サイズまでの読み取りフットプリント能力及びアソシアティビティを有効に向上させる。

ストア・フットプリントは、ストア・キャッシュ・サイズ（ストア・キャッシュは、以下により詳細に説明される）によって、従って、Ｌ２ ２６８サイズ及びアソシアティビティによって暗黙的に、制限される。ＴＸ−ダーティ２５２キャッシュラインがＬ１ ２４０からＬＲＵ処理された場合、ＬＲＵ拡張アクションを実施する必要はない。

ストア・キャッシュ
従来のシステムにおいて、Ｌ１ ２４０及びＬ２ ２６８はストアスルー・キャッシュであるので、全てのストア命令は、Ｌ３ ２７２ストア・アクセスを引き起こし、今やＬ３ ２７２ごとに６つのコアがあり、各コアの性能がさらに改善され、Ｌ３ ２７２に関する（及びより少ない程度ではあるがＬ２ ２６８に関する）ストア速度が、特定のワークロードに関して問題になる。ストア・キューイングの遅延を避けるために、ストアをＬ３ ２７２に送信する前にストアを近隣のアドレスと組み合わせる、収集ストア・キャッシュ２６４を付加する必要がある。

トランザクション・メモリ性能については、Ｌ２キャッシュ２６８は、もう少しでクリーン・ラインを戻すので（７サイクルＬ１ ２４０ミス・ペナルティ）、トランザクション・アボート時に、Ｌ１ ２４０からのあらゆるＴＸ−ダーティ２５２キャッシュラインを無効にすることが許容可能である。しかしながら、性能（及び追跡のためのシリコン領域）に関して、トランザクションが終了する前にトランザクション・ストアにＬ２ ２６８を書き込ませ、次に、アボート時に（又はさらに悪いことには共有Ｌ３ ２７２で）全てのダーティＬ２ ２６８キャッシュラインを無効にすることは、許容可能でない。

ストア帯域幅及びトランザクション・メモリ・ストア処理の２つの問題はどちらも、収集ストア・キャッシュ２６４で対処することができる。キャッシュ２３２は、６４エントリの循環キューであり、各エントリは、バイト精度（byte-precise）の有効ビットを有する１２８バイトのデータを保持する。非トランザクション操作において、ＬＳＵ２８０からストアを受信すると、ストア・キャッシュ２６４は、同じアドレスのエントリが存在するかどうかをチェックし、存在する場合には、新しいストアを既存のエントリに収集する。エントリが存在しない場合には、新しいエントリがキューに書き込まれ、空きエントリの数が閾値より下になる場合、最も古いエントリがＬ２ ２６８キャッシュ及びＬ３ ２７２キャッシュにライトバックされる。

新しい最外トランザクションが開始すると、ストア・キャッシュ２６４内の全ての既存のエントリは、新しいストアをそこに収集できないように、ｃｌｏｓｅｄとしてマーク付けされ、Ｌ２ ２６８及びＬ３ ２７２に対するこれらのエントリのエビクションが開始される。その時点から、ＬＳＵ２８０ ＳＴＱ２６０から得られるトランザクション・ストアは、新しいエントリを割り当てる、又は既存のトランザクション・エントリに集まる。Ｌ２ ２６８及びＬ３ ２７２へのこれらのストアのライトバックは、トランザクションが成功裏に終了するまでブロックされ、その時点で、後の（トランザクション後の）ストアは、次のトランザクションがそれらのエントリを再び閉じるまで、引き続き既存のエントリ内に集めることができる。

ストア・キャッシュは、あらゆるｅｘｃｌｕｓｉｖｅ ＸＩ又はｄｅｍｏｔｅ ＸＩのたびに照会され、ＸＩがいずれかのアクティブ・エントリと比較された場合、ＸＩの拒否を引き起こす。継続的にＸＩを拒否する間、コアがさらなる命令を完了しない場合、トランザクションは、ハングアップを回避するために特定の閾値でアボートされる。

ストア・キャッシュがオーバーフローすると、ＬＳＵ２８０は、トランザクション・アボートを要求する。ＬＳＵ２８０は、既存のエントリにマージする（merge）ことができない新しいストアを送信しようと試みたときに、この条件を検出し、ストア・キャッシュ全体が現トランザクションからのストアで満たされる。ストア・キャッシュは、Ｌ２ ２６８のサブセットとして管理され、ダーティラインをＬ１ ２４０からトランザクション的にエビクトすることができるが、これらは、トランザクション全体を通じてＬ２ ２６８内に常駐しなければならない。従って、最大ストア・フットプリントは、６４×１２８バイトのストア・キャッシュ・サイズに制限され、Ｌ２ ２６８のアソシアティビティによっても制限される。Ｌ２ ２６８は、８ウェイ・アソシアティブであり、５１２行を有するので、一般的には、十分に大きく、トランザクション・アボートを引き起こさない。

トランザクションがアボートした場合、ストア・キャッシュに通知され、トランザクション・データを保持する全てのエントリが無効にされる。ストア・キャッシュはまた、１ダブルワード（８バイト）ごとに、エントリがＮＴＳＴＧ命令により書き込まれたかどうかのマークを有し−これらのダブルワードは、トランザクション・アボートにわたって有効なままである。

ミリコード実装の機能
従来より、ＩＢＭメインフレーム・サーバ・プロセッサは、特定のＣＩＳＣ命令実行、割り込み処理、システム同期、及びＲＡＳのような複雑な機能を実施する、ミリコードと呼ばれるファームウェアの層を含む。ミリコードは、マシン依存命令、並びに、アプリケーション・プログラム及びオペレーティング・システム（ＯＳ）の命令と同様にメモリからフェッチされ、実行される命令セット・アーキテクチャ（ＩＳＡ）の命令を含む。ファームウェアは、顧客プログラムがアクセスできないメインメモリの制限区域内に常駐する。ハードウェアが、ミリコードを呼び出す必要がある状況を検出すると、命令フェッチ・ユニット２０４が「ミリコード・モード」に切り替わり、ミリコード・メモリ領域内の適切な位置でフェッチを開始する。ミリコードは、命令セット・アーキテクチャ（ＩＳＡ）の命令と同じ手法でフェッチ及び実行することができ、ＩＳＡ命令を含むことができる。

トランザクション・メモリに関して、ミリコードは、種々の複雑な状況に関与する。あらゆるトランザクション・アボートは、必要なアボート操作を行うために、専用ミリコード・サブルーチンを呼び出す。トランザクション・アボート・ミリコードは、ハードウェア内部のアボート原因、潜在的な例外原因、及びアボートされた命令アドレスを保持する特殊用途レジスタ（ＳＰＲ）を読み取ることで開始し、次に、ミリコードを用いて、１が指定されている場合には、ＴＤＢを格納する。ミリコードがどのＧＲ２３８を復元するかを知るのに必要とされるＧＲ保存マスクを取得するために、ＴＢＥＧＩＮ命令テキストがＳＰＲからロードされる。

ＣＰＵ１１４（図２）は、バックアップＧＲ２２４を読み出し、それらをメインＧＲ２２８にコピーするための、特殊ミリコード専用命令をサポートする。ＴＢＥＧＩＮ命令アドレスもＳＰＲからロードされ、ひとたびミリコード・アボート・サブルーチンが終了すると、ＴＢＥＧＩＮ後の実行を続行するための新しい命令アドレスをＰＳＷ内に設定する。このＰＳＷは、アボートがフィルタリングされていないプログラム割り込みにより引き起こされた場合、プログラム−旧ＰＳＷとして後に保存することができる。

ＴＡＢＯＲＴ命令は、ミリコード実装することができる、即ち、ＩＤＵ２０８がＴＡＢＯＲＴをデコードすると、ＴＡＢＯＲＴ命令は、ＴＡＢＯＲＴのミリコードに分岐するように命令フェッチ・ユニットに指示し、そこからミリコードが共通のアボート・サブルーチンに分岐する。

Ｅｘｔｒａｃｔ Ｔｒａｎｓａｃｔｉｏｎａｌ Ｎｅｓｔｉｎｇ Ｄｅｐｔｈ（トランザクション・ネスト化深さ抽出）（ＥＴＮＤ）命令も、パフォーマンス・クリティカル（performance critical）ではないので、ミリコード化することができる。即ち、ミリコードは、特殊ハードウェア・レジスタから現在のネスト化深さをロードし、それをＧＲ２２８に入れる。ＰＰＡ命令はミリコード化することができる。ＰＰＡ命令は、ＰＰＡへのオペランドとしてソフトウェアにより提供される現在のアボート・カウントと、同じく他のハードウェア内部状態とに基づいて、最適な遅延を実施する。

制約付きトランザクションに関して、ミリコードは、アボートの数を常時監視することができる。ＴＥＮＤが成功裏に完了したとき、又は、ＯＳへの割り込みが生じた場合、カウンタは０にリセットされる（ＯＳがプログラムに戻るかどうか、又はＯＳがいつプログラムに戻るかは知られていない）。現在のアボート・カウントに依存して、ミリコードは、特定の機構を呼び出して、後のトランザクションの再試行が成功する可能性を高めることができる。この機構は、例えば、再試行の間のランダムな遅延を連続的に増大させることと、投機的実行の量を低減させて、トランザクションが実際には使用していないデータへの投機的アクセスにより引き起こされるアボートに遭遇するのを回避することとを含む。最後の手段として、他のＣＰＵ１１４を解放して通常の処理を続行する前に、ミリコードを他のＣＰＵ１１４（図２）にブロードキャストして、全ての競合する作業を停止させ、ローカル・トランザクションを再試行することができる。デッドロックを引き起こさないように、複数のＣＰＵ１１４を連携させる必要があるので、異なるＣＰＵ１１４上のミリコード・インスタンス間の何らかのシリアル化が必要とされる。

図４は、１つの実施形態によるコンピュータ・システム３００を示す。図４は、図１−図３及び図５−図１８において述べられる特徴部を実装するように構成される。コンピュータ３００は、階層キャッシュ・サブシステムを介してメモリ３１０と通信する、プロセッサ１１２ａ（ＣＰＵ１）及び１１２ｂ（ＣＰＵ２）として示される複数のプロセッサを含み（図示されない付加的なプロセッサと共に）、階層キャッシュ・サブシステムのキャッシュにおいて、プロセッサにより、トランザクション・ロードが監視される。図４に示されるコンピュータ・システム３００は、図１に示されるコンピュータ・システム１００と同じ要素及び同じ参照番号を有するが、図４には、図１の全ての要素は示されない。

コンピュータ・システム３００は、例えば、トランザクションに利用可能な又はトランザクションを現在処理している１つ又は複数のプロセッサに与えられる割り込みなどの要求を管理することができる。一例において、要求（requesting）プロセッサ（例えば、ＣＰＵ１（１１２ａ））は、受信（receiving）／遠隔プロセッサ（例えば、ＣＰＵ２（１１２ｂ））を選択し、要求を選択された遠隔プロセッサに送ることができる。一例において、コンピュータ・システムは、例えばトランザクションを実行することができるＣＰＵ又はプロセッサを含む、トランザクション実行（ＴＸ）システム又は環境である。各々のトランザクションは、それぞれ、プロセッサ１１２ａ及び１１２ｂ内でそれぞれ実行されるトランザクション命令３２０ａ及び３２０ｂとして示される。各々のプロセッサ１１２ａ及び１１２ｂは、それぞれのレジスタ３３４ａ及び３３４ｂを有する。

各々のデータ・キャッシュ１１８ａ及び１１８ｂは、それぞれ、それぞれのＬ１及びＬ２キャッシュを含むことができる。コンピュータ・メモリは、一般的にメモリ３１０で表され、このメモリ３１０は、ＴＸ ＣＰＵ、つまりプロセッサ１１２ａ及び１１２ｂとして示されるＣＰＵ内の上位レベル・キャッシュ・メモリを含むことができる。各プロセッサ１１２ａ及び１１２ｂは、それぞれ、テーブル１３５０ａ及び１３５０ｂとして示される、それぞれのローカル・トランザクション干渉追跡テーブル（local transaction interference tracking table）を有する。テーブル１３５０ａ及び１３５０ｂは、それぞれ、データ・キャッシュ１１８ａ、１１８ｂ、レジスタ３３４ａ、３３４ｂ、及び／又はメモリ３１０内に格納することができる。本明細書でさらに説明されるように、メモリ３１０はまた、テーブル１３５０ａ及び１３５０ｂ内に格納されたトランザクション干渉情報を含むことができる（統計値と共に）、トランザクションの診断情報を格納するためのトランザクション診断ブロック３５０を含むこともできる。

コンピュータ・システム３００は、実施形態による要求及び応答の両方を送信、受信及び処理するトランザクション（ＴＸ）環境の表示である。種々の例が与えられ、プロセッサ１１２ａ（ＣＰＵ１）は、要求を作成し、要求を、受信する受信／遠隔プロセッサとして示されるプロセッサ１１２ｂ（ＣＰＵ２）に送る要求プロセッサとして示されることに留意されたい。当業者により理解されるように、いずれのプロセッサもデータに対する要求を受送信できるので、この表示は説明目的のためであることが理解される。

図５は、プロトコル要求及び応答の例を示す。プロトコル要求は、メインフレーム・マルチプロセッサ・プロトコルと呼ばれることがあり、プロトコルは、バス・ベース又はスイッチベースの相互接続を介することができる。プロトコルは全て、パラレル・シグナリング（バス・スヌーピング）、シリアル・パケット、又はその組み合わせとすることができる。

一例として、データ要求５０５を、ＣＰＵ１（１１２ａ）からＣＰＵ２（１１２ｂ）に送信することができる。要求５０５は、どのタイプの要求が送られているか（例えば、周知のＭＥＳＩコヒーレンス・プロトコルに従った、ｒｅａｄ−ｓｈａｒｅｄ若しくはｒｅａｄ ｅｘｃｌｕｓｉｖｅ、又はｒｅａｄ ｆｏｒ ｏｗｎｅｒｓｈｉｐ要求、又は他のそうしたプロトコルに従ったプロトコル要求）を示すタイプ・フィールド５０６と、要求を送った特定のプロセッサ（例えば、ＣＰＵ１）及び随意的に要求が送られる、例えばＣＰＵなどの受信プロセッサ、及び随意的に、複数の要求を同時に処理できる場合、各要求を一意に識別するための特有の要求ＩＤを識別するタグ・フィールド５０７とを含む。要求５０５はまた、要求プロセッサ（ＣＰＵ１）により要求されるアクセスのタイプを識別するアクセス・フィールド５０８と、アドレス・フィールド５０９とを含む。アドレス・フィールド５０９は、要求されているキャッシュライン又はメモリ・ワードのメモリ・アドレスを識別する。要求５０５のプロトコルは、例えば、巡回冗長検査（ＣＲＣ）、パリティ・ビット、又はＥＣＣなど、使用されるエラー検出及び／又は訂正コードを含むエラー訂正フィールド５１０を含むことができる。

応答５１５は、受信プロセッサ（ＣＰＵ２）から要求プロセッサ（ＣＰＵ１）に送り返すことができる。応答５１５は、読み取り応答（ＲＥＡＤＲＥＳＰＯＮＳＥ）のような応答のタイプを示すタイプ・フィールド５１６と、タグ・フィールド５１７とを含む。タグ・フィールド５１７は、オリジナルの要求５０５のタグ・フィールド５０７と同じタグとすることができ、及び／又は、タグ・フィールド５１７は、キャッシュラインの要求されたメモリ・アドレスを含むことができる。応答５１５は、要求プロセッサ（ＣＰＵ１）により要求される要求データであるデータ・フィールド５１８を含む。幾つかのプロトコル応答は、データ転送を含むことができず（例えば、ラインに関してｓｈａｒｄからｅｘｃｌｕｓｉｖｅ ｏｗｎｅｒｓｈｉｐに所有権をエスカレートさせるためのプロトコル要求）、処理が実施された確認応答（acknowledgement）のみを含むことができる。エラー訂正フィールド５１９は、応答５１５内に含められる。

幾つかの実施形態において、プロトコル要求のためのシグナリングは、複数のビット・ラインにわたって並行して行うことができ、いずれの未使用フィールドも、プロトコル定義値をもたないラインに対応することができ、デフォルト値に設定され、又はさもなければプロトコル・メッセージの部分と考えられない。幾つかの実施形態において、プロトコル要求は、複数の「ビート（beat）」で、例えば、その全体がプロトコル・メッセージを表す連続するビットのグループで伝送することができる。さらに他の実施形態において、プロトコル要求は、ビットシリアルに（bit-serially）伝送することができる。複数のビートで又はシリアルに伝送されるプロトコルにおいて、幾つかのメッセージは、他のプロトコル要求よりもより多いバス・シグナリング・サイクルから成る。

図６は、別のプロトコル要求の例を示す。多くのプロトコルは、書き込み操作のためにＲＦＯ（ｒｅａｄ ｆｏｒ ｏｗｎｅｒｓｈｉｐ）又はｒｅａｄ−ｅｘｃｌｕｓｉｖｅ要求を介して、排他的アクセスを獲得し、一方で、幾つかの他のプロトコルは、直接書き込み（制限された）を行うことができる。一例として、データを書き込むための例示的な要求６０５を、ＣＰＵ１（１１２ａ）からＣＰＵ２（１１２ｂ）に送ることができる。要求６０５は、送られる要求のタイプ（例えば、書き込み）を識別するタイプ・フィールド５０６と、書き込み要求を送った特定のプロセッサ（例えば、ＣＰＵ１）及び随意的に、要求が送られる、例えばＣＰＵ２などの受信プロセッサ、及び特定の要求を識別するタグ・フィールド５０７とを含む。要求６０５はまた、要求プロセッサ（ＣＰＵ１）により書き込まれるデータを伝送するデータ・フィールド５０４と、アドレス・フィールド５０９とを含む。アドレス・フィールド５０９は、書き込まれるキャッシュライン又はアドレスラインのメモリ・アドレスを識別する。要求６０５のプロトコルは、例えば、巡回冗長検査（ＣＲＣ）、パリティ・ビット、又はＥＣＣなど、使用されるエラー検出及び／又は訂正コードを含むエラー訂正フィールド５１０を含むことができる。

書き込み要求に応答して、書き込みを行う前に排他的アクセスのためのデータを取得する必要がないので、一般的には応答がない。

図７は、１つの実施形態によるデータ要求を行っているプロセッサ（例えば、ＣＰＵ１（１１２ａ））によるプロトコル要求生成のフロー図７００である。ブロック７０５において、プロセッサ（例えば、ＣＰＵ１）は、メモリ・データに対する要求を有する。ブロック７１０において、プロセッサ（例えば、ＣＰＵ１（１１２ａ））は、要求されたデータがプロセッサ自身のローカル・キャッシュ（例えば、データ・キャッシュ１１８ａ内のＬ１キャッシュ）内にあるかどうかをチェックする。データがプロセッサ自身のローカル・キャッシュ内で利用可能な場合、フローはブロック７３５に進む。データがプロセッサ（ＣＰＵ１）のローカル・キャッシュ内で利用可能でない場合、ブロック７１５において、プロセッサは、ＸＩ要求（相互問い合わせ）を生成し、他のプロセッサ（ＣＰＵ２（１１２ｂ）など）から所望のデータを要求する。ブロック７２０において、要求プロセッサ（ＣＰＵ１）は、相互接続１２２を介して、データに対するＸＩ要求を受信プロセッサ（ＣＰＵ２）に送り、ブロック７２５において、要求プロセッサ（ＣＰＵ１）は、受信プロセッサ（ＣＰＵ２）から、（要求されたデータ）と共にＸＩ応答を受け取る。ブロック７３０において、要求プロセッサ（ＣＰＵ１）は、データを、データ・キャッシュ１１８ａのローカル・キャッシュ（例えば、Ｌ１、Ｌ２キャッシュ）内に入れる。ブロック７３５において、要求プロセッサ（ＣＰＵ１）は、命令キャッシュ１１６ａを介して、そのローカル・キャッシュ１１８ａからデータを取得する。ブロック７４０において、要求プロセッサの命令キャッシュ１１６ａは、処理のためにデータをＣＰＵ１の回路に与える。

一実施形態において、一般的なキャッシュ・プロトコル（例えば、周知のＭＥＳＩプロトコル）によると、プロセッサが読み取りのためにデータにアクセスし、データが利用可能でない場合、データが共有方式で取得されるｒｅａｄ−ｓｈａｒｅｄのためにＸＩが生成されるので、複数のＣＰＵ１１２ａ、１１２ｂは、キャッシュ内のデータのコピーを有することができ、各ＣＰＵは、データに対応するメモリ読み取りアクセスを処理することができる。受け取ったデータは、キャッシュに入れられ、共有アクセスのためにマーク付けされ、プロセッサは、メモリ読み取り操作に応答して、コピーから読み取りアクセスを実施することができる。プロセッサが、書き込みのためにデータにアクセスし、データが、ｅｘｃｌｕｓｉｖｅ状態で利用可能でない場合、データが排他的方式で取得されるｒｅａｄ−ｅｘｃｌｕｓｉｖｅのためにＸＩが生成されるので、単一のＣＰＵ（例えば、ＣＰＵ１１２ａ）だけがキャッシュ内のデータのコピーを有することができる。受け取ったデータはキャッシュに入れられ、排他的アクセスのためにマーク付けされ、プロセッサは、メモリ書き込み操作に応答して、コピーを更新することができる。一実施形態において、データが共有モードで存在し、書き込みアクセスを受け取った場合、ｒｅａｄ−ｅｘｃｌｕｓｉｖｅ ＸＩが生成される。少なくとも１つの実施形態においては、これは、データが応答の部分として受信されない別個のｒｅａｄ−ｅｘｃｌｕｓｉｖｅ要求として示される。一実施形態において、応答を受信すると、キャッシュ・データは、排他的アクセスのためにマーク付けされる。

図８は、１つの実施形態による、要求を受け取り、応答を送る受信／遠隔プロセッサ（例えば、ＣＰＵ２（１１２ｂ））による要求処理の例示的なフロー図８００を示す。

ブロック８０５において、遠隔プロセッサ（ＣＰＵ２）は、要求プロセッサ（ＣＰＵ１）からデータに対するＸＩ要求を受け取る。ブロック８１０において、遠隔プロセッサ（ＣＰＵ２）は、遠隔プロセッサが要求されたデータ（遠隔プロセッサのローカル・キャッシュ内の）を現在必要とするトランザクションを処理しているかどうかをチェックすることにより、干渉が検出されるかどうかをチェックする。ブロック８１０において、遠隔プロセッサ（ＣＰＵ２（１１２ｂ）が、遠隔プロセッサは、要求プロセッサ（ＣＰＵ１（１１２ａ））が要求するデータを現在使用していると判断した場合、ブロック８１５において、遠隔プロセッサは、干渉が検出される（肯定）と判断し、遠隔プロセッサ（ＣＰＵ２）は、該遠隔プロセッサ（ＣＰＵ２）において発生しているローカル・トランザクションをアボートする。ひとたび遠隔プロセッサ（ＣＰＵ２）においてローカル・トランザクションがアボートされると、ブロック８２０において、遠隔プロセッサは、読み取り応答（ＲＥＡＤ ＲＥＳＰＯＮＳＥ）と共にデータを要求プロセッサ（ＣＰＵ１）に伝送する。ブロック８２５において、遠隔プロセッサ（ＣＰＵ２）は、データ・ステータスを変更し、随意的に、必要に応じてそのローカル・キャッシュからデータをパージする。一実施形態において、キャッシュ・ステータスの変更は、トランザクションがアボートされたときに、データを読み取り又は書き込みセットのうちの少なくとも一方から解放することを含むことができる。一実施形態において、キャッシュ・ステータスの変更は、キャッシュ・ディレクトリ内のキャッシュラインのステータスを変更すること、例えば、周知のＭＥＳＩプロセッサなどのキャッシュ・プロセッサに従って、ステータスをｓｈａｒｅｄ、ｅｘｃｌｕｓｉｖｅ、ｉｎｖａｌｉｄ等のうちの１つに設定することを含むことができる。ブロック８３０において、遠隔プロセッサ（ＣＰＵ２）は、トランザクション失敗処理を開始し、フローは終了する。ブロック８１０において、遠隔プロセッサ（ＣＰＵ２（１１２ｂ）が、遠隔プロセッサは要求プロセッサ（ＣＰＵ１（１１２ａ））が要求するデータを現在使用していないと判断した場合、ブロック８３５において、遠隔プロセッサは、干渉は検出されないと判断し、ブロック８３５において、遠隔プロセッサは、読み取り応答（ＲＥＡＤ ＲＥＳＰＯＮＳＥ）と共にデータを伝送する。ブロック８４０において、遠隔プロセッサ（ＣＰＵ２）はデータ・ステータスを変更し、ブロック８４０において、随意的に、必要に応じてローカル・キャッシュからデータをパージし、フローは終了する。

図９は、１つの実施形態によるプロセッサによるトランザクション処理を示すフロー図９００である。ブロック９０５において、トランザクションは、プロセッサ（例えば、ＣＰＵ１又はＣＰＵ２）上での実行を開始する。図９において、各プロセッサ（ＣＰＵ１及びＣＰＵ２）がこれらのアクションを実行できること、即ち、両方の１１２ａ、１１２ｂ等によりトランザクションを処理できることに留意されたい。ブロック９１０において（例えば、図７に述べられるように）、プロセッサは、トランザクション内の命令を実施する。ブロック９１５において、プロセッサは、トランザクション命令に応答して、プロトコル・アクションを実施する。ブロック９２０において、プロセッサに、そのトランザクションをアボートすることを求める干渉（データを用いた）が存在するかどうかをチェックする。プロセッサが、干渉が検出される（肯定）と判断すると、ブロック９２５において、プロセッサは、それ自身のトランザクション（データ上での）をアボートし、流れはブロック９３５に進む。プロセッサが、干渉が検出されないと判断すると、ブロック９３０において、プロセッサは、そのトランザクション（の命令）を完了する。ブロック９３５において、プロセッサは、（トランザクション診断ブロック（ＴＤＢ）などの）トランザクション情報をレジスタに書き込む。

実施形態によると、コヒーレンス・プロトコルが、トランザクション・ステータスについての付加的な情報を含むように拡張される。図１０は、実施形態によるプロトコル要求５０５及び新しいプロトコル応答１００５を示す。図１０に示されるように、要求５０５の幾つかのフィールドは、図５に述べられるフィールドと同一である。上述のように、要求５０５は、どのタイプの要求が送られるか（例えば、ＲＥＡＤ）を識別するタイプ・フィールド５０６と、要求を送った特定のプロセッサ（例えば、ＣＰＵ１）（及び随意的に、要求が送られる、例えばＣＰＵ２などの受信／遠隔プロセッサ、並びに要求番号）を識別するタグ・フィールド５０７とを含む。要求５０５はまた、要求プロセッサ（ＣＰＵ１）により要求されるアクセスのタイプを示すアクセス・フィールド５０８と、要求されるキャッシュライン又はアドレスラインのメモリ・アドレスを示すアドレス・フィールド５０９とを含む。要求５０５のプロトコルは、巡回冗長検査（ＣＲＣ）のような、使用されるエラー・コードのタイプを示すエラー訂正フィールド５１０を含む。

新しい応答１００５は、付加的なトランザクション・アボート・ステータス・フィールド１０１０と共に、（図５の）応答５１５のフィールドを含む。応答１００５は、受信／遠隔プロセッサ（ＣＰＵ２）から要求プロセッサ（ＣＰＵ１）に送り返すことができる。応答５１５は、読み取り応答（ＲＥＡＤＲＥＳＰＯＮＳＥ）などの応答のタイプを示すタイプ・フィールド５１６と、要求されたキャッシュラインのメモリ・アドレスを示すタグ・フィールド５１７（オリジナルの要求５０５のタグ・フィールド５０７と同じタグとすることができる）とを含む。応答５１５は、要求プロセッサ（ＣＰＵ１）により要求された要求データであるデータ・フィールド５１８を含む。データがプロトコル応答と共に伝送されない場合、データ・フィールド５１８は空であるか又は存在しない。エラー検出／訂正フィールド５１９は、応答１００５内に含められる。

付加的に、新しいプロトコル応答１００５（遠隔プロトコルＣＰＵ２により要求プロセッサ（ＣＰＵ１）に送られた）は、トランザクション・アボート・ステータス・フィールド１０１０を有する。トランザクション・アボート・ステータス・フィールド１０１０は、アボートされる前に、遠隔／受信プロセッサ（ＣＰＵ２）上で既に実行されているトランザクションについての以下の情報の１つ又は複数を含む。：
１）要求５０５（要求プロセッサ（ＣＰＵ１）からの））がロールバック（即ち、アボート）を引き起こしたか、及び／又は引き起こさなかったか、
２）アボートされる前に、遠隔／受信プロセッサ（ＣＰＵ２）上で実行されていたこのトランザクションの優先順位、
３）トランザクションがアボートされる前、遠隔／受信プロセッサ（ＣＰＵ２）上で既に実行されているトランザクションにより、幾つの命令、メモリ操作、及び／又は作業の他の尺度が実施されたか、
４）遠隔プロセッサ（ＣＰＵ２）上で既に実行されているトランザクション（トークン、ＴＢＥＧＩＮのアドレス、及び／又はアボートされたトランザクションを識別する他の手段）の識別。

さらに、トランザクション・アボート・ステータス・フィールド１０１０は、アボートする必要があったトランザクション（遠隔／受信プロセッサ（ＣＰＵ２）上で既に実行されている）により、どのデータが取得されたか、トランザクションのアドレス、及びトランザクションをアボートするコスト（作業の３クロック周期又は２０，０００クロック周期とすることができる）を示す。

プロセッサ（例えば、例示的なシナリオにおける受信プロセッサＣＰＵ２）がトランザクション実行にあるとき、例えば、データはトランザクション読み出し又は書き込みセットの部分であり、競合（即ち、干渉）が検出されるという理由で、コヒーレンス要求が、トランザクション実行をアボートさせることがある。

１つの実施形態によると、図１１は、データ（要求プロセッサＣＰＵ１（１１２ａ）から受信／遠隔プロセッサＣＰＵ２（１１２ｂ）に送られた）を書き込むための、図６の（書き込み）要求６０５を示し、新しい応答１１０５が、遠隔プロセッサＣＰＵ２（１１２ｂ）から要求プロセッサＣＰＵ１（１１２ａ）に送り返される。図１１は、トランザクションの干渉／アボート情報を要求発信元（originator）に伝送するために、これまでプロトコル応答を必要としなかったトランザクションに新しいプロトコル応答を導入することにより、トランザクション情報を実施形態による応答に付加する、プロトコル要求及び応答の例である。少なくとも１つの実施形態において、トランザクション・アボート・ステータスを提供する目的のためだけに伝送されるプロトコル応答は、オプションであり、幾つかのモードにおいて、構成ビットに応答して、バス輻輳に応答して、及び／又は他の理由で抑止されることがある。応答を受け取らないこうしたシナリオにおいて、応答を受け取らなかった要求に対応して、トランザクション・アボート・ステータスは報告されない。少なくとも１つの実施形態において、１つ又は複数の応答の不存在を報告することができる。上述のように、要求６０５は、どのタイプの要求が送られるか（例えば、書き込み）を示すタイプ・フィールド５０６と、書き込み要求を送った特定のプロセッサ（例えば、ＣＰＵ１）（及び要求が送られる、例えばＣＰＵ２などの受信プロセッサ）を識別するタグ・フィールド５０７とを含む。要求６０５はまた、要求プロセッサ（ＣＰＵ１）により要求されるアクセスのタイプを示すアクセス・フィールド５０８と、アドレス・フィールド５０９とを含む。アドレス・フィールド５０９は、書き込むために要求されるキャッシュライン又はアドレスラインのメモリ・アドレスを示す。要求６０５のプロトコルは、パリティ・ビット、ＥＣＣ、又は巡回冗長検査（ＣＲＣ）のようなエラー訂正／検出コードを有するエラー検出及び／又は訂正フィールド５１０を含むことができる。

書き込み要求６０５に応答して、新しい応答１１０５（書き込み要求に対する）が今や、本明細書で述べられるトランザクション・アボート・ステータス・フィールド１０１０を含む。新しい応答１１０５は、応答１００５（図１０における）のフィールドを含む。応答１１０５は、受信／遠隔プロセッサ（ＣＰＵ２）から要求プロセッサ（ＣＰＵ１）に送り返すことができる。応答１１０５は、書き込み応答（ＷＲＩＴＥＲＥＳＰＯＮＳＥ）のような応答のタイプを示すタイプ・フィールド５１６と、キャッシュラインの要求されたメモリ・アドレスを示すタグ・フィールド５１７（応答が対応する要求を識別するための、オリジナルの要求５０５のタグ・フィールド５０７と同じタグとすることができる）とを含む。応答５１５は、要求プロセッサ（ＣＰＵ１）により要求された要求データであるデータ・フィールド５１８を含むことができる。受信／遠隔プロセッサ（ＣＰＵ２）の（ローカル）キャッシュからのデータはないので、データ・フィールド５１８は空である。エラー訂正フィールド５１９は、応答１００５内に含められる。

本明細書で述べられるように、トランザクション・アボート・ステータス・フィールド１０１０は、（要求プロセッサ（ＣＰＵ１）からの）書き込み要求のためにアボートする必要があった（受信／遠隔プロセッサ（ＣＰＵ２）上でこれまで実行されている）トランザクションのステータスを提供する。

本開示によるプロトコルの性能向上は、１つの例示的な実施形態においては、トランザクション・アボート・ステータス及び関連した情報に対応するプロトコル・フィールドを、読み取り要求に対する既存の読み取り応答に付加することと併せて、及び、別の例示的な実施形態においては、トランザクション・アボート・ステータス及び関連した情報に対応する少なくとも１つのプロトコル・フィールドを伝送するために、最新のプロトコル応答を有していないプロトコル書き込み要求に対応するプロトコル応答を付加し、対応する書き込み要求を識別することと併せて、説明されるが、当業者であれば、本明細書に含まれる教示は、他のＸＩ形式、プロトコル形式、要求のタイプ、コヒーレンス・プロトコル等に適用することができる。

１つの実施形態によると、図１２は、例えば、要求プロセッサＣＰＵ１（１１２ａ）から要求を受け取る受信／遠隔プロセッサＣＰＵ２（１１２ｂ）による、コヒーレンス要求処理を示すフローチャート１２００である。図１２は、プロトコル応答の部分として（トランザクション・アボート・ステータス・フィールド１０１０における）トランザクション・アボート・ステータスを伝送することを含む、新しい（修正された）ブロック１２０５及び１２１０と併せて、図８のブロックを含む。

図１２において、受信／遠隔プロセッサ（例えば、ＣＰＵ２（１１２ｂ））による要求処理は、１つの実施形態による要求を受け取る。ブロック８０５において、遠隔プロセッサ（ＣＰＵ２）は、要求プロセッサ（ＣＰＵ１）からデータに対するＸＩ要求（例えば、要求５０５及び／又は要求６０５）を受け取る。ブロック８１０において、遠隔プロセッサ（ＣＰＵ２）は、遠隔プロセッサが、例えば要求５０５及び６０５などの受信した要求と両立しない方法でデータを参照するトランザクションを処理しているかどうかをチェックすることにより、干渉が検出されるかどうかをチェックする。例えば、１つの例示的な実施形態において、ｒｅａｄ ｓｈａｒｅｄ要求は、トランザクション読み取りセットにおけるデータへの参照と両立するが、書き込み要求は両立しない。さらに、ｒｅａｄ−ｅｘｃｌｕｓｉｖｅ、読み取りエスカレーション（read escalation）（即ち、ｓｈａｒｅｄからｅｘｃｌｕｓｉｖｅへの変更）、又は書き込み要求は、トランザクションの読み取り又は書き込みセットのいずれかにおいて参照される同じデータと両立しない。ブロック８１０において、遠隔プロセッサ（自身）が、現在、要求プロセッサ（ＣＰＵ１（１１２ａ））により要求されたデータを使用していると判断すると、ブロック８１５において、遠隔プロセッサは、干渉が検出され（肯定）、遠隔プロセッサ（ＣＰＵ２）は、該遠隔プロセッサ（ＣＰＵ２）で行われているローカル・トランザクションをアボートすると決定する。遠隔プロセッサ（ＣＰＵ２）においてローカル・トランザクションがアボートされると、ブロック１２０５において、遠隔プロセッサは、トランザクション・アボート・ステータス・フィールド１０１０（要求を満たすために、遠隔／受信プロセッサ（ＣＰＵ２）において、要求により（これまで実行されている）トランザクションがアボートしたことを通知する）と共に、読み取り応答（ＲＥＡＤ ＲＥＳＰＯＮＳＥ）と共にデータを要求プロセッサ（ＣＰＵ１）へ伝送する。別の実施形態において、遠隔プロセッサは、書き込み応答１１０５により受信した書き込み要求に確認応答することができる。最新のシステムにおいて、トランザクション・アボート・ステータス・フィールド１０１０は、（今はアボートされたそのトランザクションをこれまで実行している）遠隔ＣＰＵ２から、元の（要求５０５及び／又は６０５を送った）要求プロセッサＣＰＵ１に送られた応答（ＲＥＳＰＯＮＳＥ）内に含められない。遠隔プロセッサ（ＣＰＵ２）は、データ・ステータスを変更し、ブロック８２５において、随意的に、必要に応じてデータをそのローカル・キャッシュからパージする。ブロック８３０において、遠隔プロセッサ（ＣＰＵ２）はトランザクション失敗処理を開始し、フローは終了する。ブロック８１０において、遠隔プロセッサ（ＣＰＵ２（１１２ｂ））が、該遠隔プロセッサは、現在、要求プロセッサ（ＣＰＵ１（１１２ａ））により要求されるデータを使用していないと判断すると、ブロック１２１０において、遠隔プロセッサは、干渉が検出されず、遠隔プロセッサ（ＣＰＵ２）は、トランザクション・アボート・ステータス・フィールド１０１０（要求によりトランザクションがアボートされなかったことを示す）と共に、読み取り応答（ＲＥＡＤ ＲＥＳＰＯＮＳＥ）によりデータを伝送する。遠隔プロセッサ（ＣＰＵ２）は、データ・ステータスを変更し、ブロック８４０において、随意的に、必要に応じてデータをそのローカル・キャッシュからパージし、フローは終了する。

図１３は、１つの実施形態による、要求プロセッサ（ＣＰＵ１（１１２ａ））によるプロトコル要求の発信及び処理を示すフロー図１３００である。図１３は、図７に上述されたブロックを含み、図７の説明は繰り返さない。さらに、フロー図１３００は、新しいブロック１３０５及び１３１０を含む。例えば、要求プロセッサ（ＣＰＵ１）は、新しいトランザクション・アボート・ステータス・フィールド１０１０と共に、遠隔プロセッサ（ＣＰＵ２）からのデータと共にＸＩ応答を受け取る（ブロック７２５）。ブロック７３５において、要求プロセッサ（ＣＰＵ１）は、データをローカル・キャッシュ（Ｌ１及び／又はＬ２キャッシュなど）に入れる。ブロック１３１０において、要求プロセッサ（ＣＰＵ１）は、受け取ったステータス（例えば、トランザクション・アボート・ステータス・フィールド１０１０内の情報）を、データ・キャッシュ１１８ａ（及び／又はメモリ３１０）内のローカル・トランザクション干渉追跡テーブル１３５０ａに付加する。ローカル・トランザクション干渉追跡テーブル１３５０ａは、要求プロセッサ（ＣＰＵ１）が、干渉（遠隔プロセッサ（ＣＰＵ２）においてトランザクション・アボートをもたらす）を引き起こすとき、干渉を常時監視するストレージ位置とすることができ、このローカル・トランザクション干渉追跡テーブル１３５０ａは、この情報のログを含むことができる。ローカル・トランザクション干渉追跡（ストレージ）テーブル１３５０ａは、インクリメント統計値及び現在のトランザクション・ステータスを含む。インクリメント統計値は、（元の要求プロセッサ（ＣＰＵ１）に報告された）トランザクション・アボートごとに増大し、かつ、ｓｈａｒｅｄ／ｅｘｃｌｕｓｉｖｅ（Ｒ／Ｗ）要求及び集約要求に分離することができる。ローカル・トランザクション干渉追跡ストレージ・テーブル１３５０ａは、要求プロセッサ（ＣＰＵ１）により引き起こされた各々のトランザクション・アボートについての、及び、要求プロセッサ（ＣＰＵ１）においてトランザクションがアボートされる度にインクリメントするカウンタを含むことができる。幾つかの実施形態において、ブロック１３１０と共に受け取ったトランザクション・アボート・ステータスは、性能監視ユニット、ランタイム計装（instrumentation）ユニット、及び／又は別の性能追跡論理内で集約し、情報を動的オプティマイザ、ｊｕｓｔ ｉｎ ｔｉｍｅ（ＪＩＴ）コンパイラに利用可能にし、又はプログラマーにより性能調整することもできる。ストレージ内、性能監視に向けられた構造体内にログ記録することにより、及び／又は、例えば、ＰｏｗｅｒＩＳＡ（商標）に従ったＰＭＵイベント・ベースの分岐又は例外などの通知を出すことにより、情報を記録することができる。報告は、干渉の性質、干渉の識別及び／又は干渉されたトランザクション、プロセッサＩＤ、そうした干渉を受けるアドレス等を含むことができる。

本明細書で述べられるように、コヒーレンス・プロトコルは、多数のビット（アドレス、データ）及びステータス、並びに制御ビットを使用する。これらのデータは、データ要求を発行し、その所有権（例えば、ｓｈａｒｅｄ、ｅｘｃｌｕｓｉｖｅ）及びステータス（例えば、ダーティ、クリーン）を示すために使用される。付加的な１つ又は複数のビット（トランザクション・アボート・ステータス・フィールド１０１０に関する）を付加して、要求がトランザクションのアボートを引き起こしたこと及び／又は要求がトランザクションのアボートを引き起こし得ることを示す。例えば、ステータス・ビット（トランザクション・アボート・ステータス・フィールド１０１０）は、遠隔プロセッサ（ＣＰＵ１）がデータを放棄したときに、要求されたデータがトランザクションについての競合を引き起こしたことを示す。既述のように、要求への応答は、トランザクションが進行中であり、要求はトランザクションのアボートを引き起こしたという表示と共に戻り得る。

一実施形態において、アボートされたトランザクションにおける命令の数などの付加的なメトリックが、トランザクション・アボート・ステータス・フィールド１０１０に伝送される。一実施形態において、表示は、例えば、ライブロック・シナリオを回避するために、成功しているトランザクションが後でアボートになって再開される場合のトランザクションの再開に対する、ホールドオフを決定するために用いられる。要求プロセッサ（ＣＰＵ１）はまた、ローカル・トランザクション・アボート・ステータス・フィールド１０１０をチェックすることにより、要求プロセッサ（ＣＰＵ１）が、遠隔／受信プロセッサ（ＣＰＵ２）において多過ぎる（例えば、所定量の）トランザクション・アボートを引き起こしたと判断したとき、システム全体の処理量を増大させるために多過ぎる遠隔トランザクションをアボートすることに応答して、その要求速度を減速させる（低減させる）こともできる。

さらに別の実施形態において、こうした通知（トランザクション・アボート・ステータス・フィールド１０１０における）は、ログ内に集められ、及び／又は、通知機構（例えば、例外）を介して、動的再最適化コンポーネントに通知され、動的再最適化コンポーネントは、コードを動的に再最適化して、干渉を減らし、及び／又は、代替的なコードを生成し、トランザクションの代わりにロックを使用することができる。

ここで、図９のブロックは、図１４内に含まれるが、その記述は繰り返さない。図１４はまた、図９への修正も含む。図１４は、１つの実施形態による、プロセッサによるトランザクション処理を示すフロー図１４００である。プロセッサは要求プロセッサ（ＣＰＵ１）であると仮定することができる。図１４は、ブロック１４０５と共に、図９のブロックを含む。ブロック１４０５において、要求プロセッサ（ＣＰＵ１）は、レジスタ３３４、キャッシュ１１８ａ及び／又はメモリ３１０内に、（ローカル・トランザクション・アボート・ステータス・フィールド１０１０から取得され、ローカル・トランザクション干渉追跡ストレージ・テーブル１３５０ａ内に格納された）トランザクション干渉統計値を含む（トランザクション診断ブロック（ＴＤＢ）のような）トランザクション情報を書き込む。一実施形態において、トランザクションが完了すると、該トランザクションは、トランザクションが、例えば、結果レジスタ、結果条件レジスタ等（例えば、レジスタ３３４ａ、３３４ｂにおける）などの結果コードの部分として、１つ又は複数のトランザクションのアボートを引き起こしたかどうかの表示を含むことができる。一実施形態において、トランザクションが、結果ステータスを、１つ又は複数のレジスタ（例えば、レジスタ３３４ａ、３３４ｂ）及び／又はメモリ位置内に設定すると、１つ又は複数のレジスタ（例えば、レジスタ３３４ａ、３３４ｂにおける）及び／又はメモリ位置（例えば、メモリ３１０、キャッシュ１１８ａ、１１８ｂにおける）は、データをトランザクションに提供するためにアボートされた、干渉するトランザクションの数、干渉の性質（書き込みセットを伴う読み取り要求、又は読み取り若しくは書き込みのいずれかを伴う書き込み要求等）を含むことができる。一実施形態において、そのように格納された情報は、干渉が生じたプロセッサを識別する方法、（例えば、トランザクション開始ＸＢＥＧＩＮ又はＴＢＥＧＩＮのアドレス、トークン、トランザクションＩＤ等を識別することにより）アボートされたトランザクション、アボートされる前にそのトランザクションにより実施された作業の尺度等を含む、トランザクションの各々についての特別な情報を含むことができる。一実施形態において、最新のトランザクション診断ブロックが、本開示に従って、干渉及びトランザクション・アボート・ステータスに対応する付加的なフィールドを有するように拡張されると、１つ又は複数のメモリ位置に格納された情報は、例えば、ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅ（引用により本明細書に含められる）によるトランザクション診断ブロック（ＴＤＢ）のメモリ位置、並びに、本開示によるトランザクション診断ブロックのフィールドに対応し、このフィールドは、新しく導入されたプロトコル・フィールドにより、及び／又は、複数のそうしたフィールドからの集約情報により個々に伝送された情報に対応する。別の実施形態において、レジスタ及び／又はメモリ位置内に格納された情報は、別個の、分離し、独立した最新のＴＤＢとして与えられる。

ブロック１４０５において、要求プロセッサ（ＣＰＵ１）は、性能監視ユニット及び／又はランタイム計装ユニットを介して、干渉統計値をプログラマーに提供し、干渉情報をファームウェア、ミリコード等に与えるように構成される。ミリコードにおいて、ミリコード・コードは、干渉統計情報を用いて、ライブロックを回避すること、及び／又は、干渉統計情報を用いて、トランザクション再開を最適化することができる。アプリケーションにおいて、アプリケーションは、干渉統計情報を用いて、ライブロックを回避し、トランザクション再開を最適化することができる。

１つの実施形態によると、例示的なコードが、説明目的のために以下に与えられる。

以下の疑似コード（プロセッサ１１２ａ、１１２ｂ上で実行される）は、トランザクションがアボートされ、特に、ライブロック・シナリオを回避するように最適化された際、トランザクションを再開するために、（ミリコードにおいてトランスペアレントに、及び／又はプロセッサ上で実行されているアプリケーション内に統合されたコードにより）トランザクション再開の最適化を実施する１つの形態を提供する。例示的なコードは、例示的な方法でＴＤＢ内に格納された情報を使用するが、当業者であれば、これらに限定されるものではないが、メモリ位置（例えば、メモリ３１０）、レジスタ３３４ａ、３３４ｂ、ステータス・コード、及び／又は性能監視ユニット、ランタイム計装ユニット等などから取得された情報を使用できるであろう。

例示的なコードによると、トランザクション再開コードは、トランザクションがそれ自体アボートされたか、そして、別のトランザクションをアボートしたかをチェックすることを含む。一実施形態において、可能なライブロックが即座に診断される。別の実施形態において、本トランザクション及び干渉されたトランザクションが循環干渉グラフの部分であるかどうか（即ち、各トランザクションは、他のトランザクションを直接又は間接的にアボートしている）のテストが行われる（図示せず）。一実施形態において、相互シュートダウン（ｍｕｔｕａｌ ｓｈｏｏｔｄｏｗｎ）が診断されると、干渉回避アクションがとられる。一実施形態において、相互シュートダウンが診断されると、ライブロック回避アクションがとられる。一実施形態において、干渉回避アクションは、関数ａｖｏｉｄ＿ｌｉｖｅｌｏｃｋ（）を呼び出すことにより、呼び出される。幾つかの実施形態において、これらのアクションは、これらに限定されるものではないが、本トランザクションの低い優先順位、バックオフ期間の待機、ロックを用いた同期等のうちの１つ又は複数を含むことができる。

別の例示的な実施形態において、以下の疑似コードは、トランザクションがアボートされ、特に、ライブロックを回避するように最適化された際、トランザクションを再開するために、（ミリコードにおいてトランスペアレントに、又はプロセッサ上で実行されているアプリケーション内に統合されたコードにより）トランザクション再開の最適化を実施する１つの形態を提供する。例示的なコードは、例示的な方法でＴＤＢ内に格納された情報を使用するが、当業者であれば、これらに限定されるものではないが、メモリ位置、レジスタ、ステータス・コード、又は性能監視ユニット、ランタイム計装ユニット等などから取得された情報を使用できるであろう。例示的なコードにおいて、トランザクションは、これが（潜在的に）相互シュートダウンの閾値を超えたトランザクションに対応するとき、ライブロック防止操作をとる。

例示的なコードによると、トランザクション再開コードは、トランザクションがそれ自体アボートされたか、そして、別のトランザクションをアボートしたかをチェックすることを含む。一実施形態において、可能なライブロックが即座に診断される。別の実施形態において、本トランザクション及び干渉されたトランザクションが循環干渉グラフの部分であるかどうか（即ち、各トランザクションは、他のトランザクションを直接又は間接的にアボートしている）のテストが行われる（図示せず）。一実施形態において、相互シュートダウンの閾値数より多くが診断された場合（ｍｕｔｕａｌ＿ｓｈｏｏｔｄｏｗｎ ＞ ｔｈｒｅｓｈｏｌｄ）、干渉回避アクションがとられる。一実施形態において、相互シュートダウンの閾値数より多くが診断された場合（ｍｕｔｕａｌ＿ｓｈｏｏｔｄｏｗｎ ＞ ｔｈｒｅｓｈｏｌｄ）、ライブロック回避アクションがとられる。一実施形態において、干渉回避アクションは、関数ａｖｏｉｄ＿ｌｉｖｅｌｏｃｋ（）を呼び出すことにより、呼び出される。幾つかの実施形態において、これらのアクションは、これらに限定されるものではないが、本トランザクションの低い優先順位、バックオフ期間の待機、ロックを用いた同期等のうちの１つ又は複数を含むことができる。

再開の最適化（ミリコード又はアプリケーションにおいてトランスペアレントに）：

例示的なコードによると、トランザクション再開コードは、トランザクションがそれ自体アボートされたか、そして、別のトランザクションをアボートしたかをチェックすることを含む。一実施形態において、可能なライブロックが即座に診断される。一実施形態において、相互シュートダウンの閾値数より多くが診断された場合（ｍｕｔｕａｌ＿ｓｈｏｏｔｄｏｗｎ ＞ ｔｈｒｅｓｈｏｌｄ）、テストが実施されｌｉｖｅ＿ｌｏｃｋ＿ｌｏｏｐ＿ｄｅｔｅｄｔｅｄ（）、このテストは、本トランザクション及び干渉されたトランザクションが、循環干渉グラフの部分であるか、又は、別の実施形態においては、循環干渉グラフの部分とすることができる（即ち、各トランザクションは、他のトランザクションを直接又は間接的にアボートしている）場合、応答アボート・ステータス・メッセージを介して及び随意的に他の手段と共に受け取った付加的な情報にアクセスすることができる。循環干渉グラフの部分である場合、ライブロック回避アクションがとられる。一実施形態において、ライブロック回避アクションは、関数ａｖｏｉｄ＿ｌｉｖｅｌｏｃｋ（）を呼び出すことにより、呼び出される。幾つかの実施形態において、これらのアクションは、これらに限定されるものではないが、本トランザクションの低い優先順位、バックオフ期間の待機、ロックを用いた同期等のうちの１つ又は複数を含むことができる。

１つの実施形態によると、図１５は、プロセッサ（例えば、要求プロセッサＣＰＵ１）が、例えば、トランザクション・アボート・ステータス・フィールド１０１０内の情報から、ローカル・トランザクション干渉追跡ストレージ・テーブル１３５０ａ内に格納された（そして、インクリメントされ、追跡された）干渉表示にどのように応答するかを示すフロー図１５００である。ブロック１５０５において、要求プロセッサＣＰＵ１は、干渉統計値を報告する。干渉統計値を報告することは、ブロック１４０５に述べられるように、トランザクション情報を書き込むことを含むことができる。ブロック１５１０において、要求プロセッサ（ＣＰＵ１）は、干渉コストが高過ぎると判断することにより、干渉の繰り返しを回避するために、付加的な同期化が可能であるかどうかを判断する。要求プロセッサ（ＣＰＵ１）が、受信／遠隔プロセッサ（ＣＰＵ２）上で実行されている（同じ）トランザクションを繰り返し、所定の回数（例えば、４回）だけアボートしたとき、及び／又は、トランザクションが、アボートされる前に命令のクロック周期の所定数（例えば、１０，０００クロック周期）を完了したとき、干渉コストは高過ぎる。

ブロック１５１０において、要求プロセッサ（ＣＰＵ１）が、該要求プロセッサ（ＣＰＵ１）からのデータに対する要求が引き起こす干渉の繰り返し（遠隔プロセッサ（ＣＰＵ２）上のトランザクション・アボートの繰り返し）を回避するため、付加的な同期は可能でないと判断すると、ブロック１５１５において、要求プロセッサ（ＣＰＵ１）は、コードの再最適化が可能であるかどうかを判断する。要求プロセッサ（ＣＰＵ１）が、再最適化が可能であると判断すると、ブロック１５２０において、要求プロセッサは、コードを再最適化する。要求プロセッサ（ＣＰＵ１）が再最適化は可能でないと判断すると、ブロック１５２５において、要求プロセッサは、現在のコード（バックオフのような寛容（toleration）尺度を含む）を進行する。バックオフとは、受信／遠隔プロセッサ（ＣＰＵ２）が、（アボートする必要なしに）実行を完了させるために、受信／遠隔プロセッサのトランザクションのための時間を有するために、データ要求を作成する前に所定量の時間待つと決定する場合である。

要求プロセッサ（ＣＰＵ１）は、ブロック１５１０において、要求プロセッサ（ＣＰＵ１）が、該要求プロセッサ（ＣＰＵ１）からのデータ要求が引き起こす干渉の繰り返し（遠隔プロセッサ（ＣＰＵ２）上のトランザクション・アボートの繰り返し）を回避するために、付加的な同期が可能であると判断すると、ブロック１５３０において、要求プロセッサ（ＣＰＵ１）は、代替的な同期化を利用する。ブロック１５３５において、（遠隔／受信プロセッサ（ＣＰＵ２）上の同じトランザクション（即ち、同じキャッシュ／メモリ・アドレスを有する）の）干渉の繰り返しがいつ発生するかを判断するために、例えば、ローカル・トランザクション干渉追跡ストレージ・テーブル１３５０ａ内のログをチェックする。干渉の繰り返しがない場合、流れはブロック１５２５に進む。要求プロセッサ（ＣＰＵ１）が、（遠隔／受信プロセッサ（ＣＰＵ２）上の同じアボートされたトランザクションについての）干渉の繰り返しがあると判断すると、ブロック１５４０において、要求プロセッサは、コードの再最適化が可能であるかどうかをチェックする。再最適化が可能である場合、ブロック１５４５において、要求プロセッサ（ＣＰＵ１）は、コードを再最適化する。

要求プロセッサ（ＣＰＵ１）が、コードの再最適化が可能でないと判断すると、ブロック１５５０において、要求プロセッサ（ＣＰＵ１）は、受信／遠隔プロセッサ（ＣＰＵ２）からのデータを要求している（要求プロセッサ（ＣＰＵ１）上で実行されている）この特定のトランザクションのための代替的な同期方法を恒久的に（及び／又は所定の期間）選択するように構成される。

１つの実施形態によると、図１６は、プロセッサ（例えば、要求プロセッサＣＰＵ１）が、トランザクション・アボート・ステータス・フィールド１０１０内の情報から、例えば、ローカル・トランザクション干渉追跡ストレージ・テーブル１３５０ａ内に格納された（そして、インクリメント／追跡された）干渉の表示にどのように応答するかを示すフロー図１６００である。図１６は、ブロック１６０５がブロック１５４０に置き換わった以外、図１５のブロックを含む。図１５のブロックは、繰り返さない。

ブロック１５３５が肯定（ＹＥＳ）であるとき、フローは、図１６のブロック１６０５に進む。ブロック１６０５において、要求プロセッサ（ＣＰＵ１）は、再最適化又は代替的な同期が好ましいかどうかをチェックする。ブロック１６０５における判断が肯定であるとき、フローはブロック１５４５に進む。ブロック１６０５における判断が否定（ＮＯ）であるとき、フローはブロック１５５０に進む。図１５のブロック１５４０において、コードの再最適化が可能であるとき、コードの再最適化は常に実施される。１６０５において、メトリックを計算して、コードの再最適化又は代替的な同期方法（例えば、ロック）が望ましいかどうかを判断し、一方又は他方を選択する。これは、例えば、代替的な同期方法の総コストを、再最適化コストを用いるコストに再最適化を実施するコストを加えたものと比較し、どちらが望ましいかを判断するテストに基づくことができる。例えば、再最適化コストを閾値と比較することにより、再最適化のオーバーヘッドのコストを最小化するなど、他のコスト・メトリックが可能であり、本開示により考えられる。

図１７は、１つの実施形態による、コヒーレンス・プロトコルを実施するための（プロセッサ１１２ａ、１１２ｂにより実行される）方法のフローチャート１７００である。

ブロック１７０５において、要求プロセッサ１１２ａ（ＣＰＵ１）は、相互接続１２２を介して、データに対する要求（要求５０５、６０５など）を遠隔プロセッサ１１２ｂ（ＣＰＵ２）に送る。ブロック１７１０において、要求プロセッサ１１２ａ（ＣＰＵ１）は、遠隔プロセッサ１１２ｂから応答（応答１００５、１１０５）を受け取り、この応答は、遠隔プロセッサ１１２ｂ上の遠隔トランザクション（例えば、トランザクション３２０ｂ）のトランザクション・ステータス（例えば、トランザクション・アボート・ステータス１０１０）を含む。ブロック１７１５において、要求プロセッサ１１２ａは、遠隔プロセッサ上の遠隔トランザクションのトランザクション・ステータス（例えば、フィールド１０１０からの情報）をローカル・トランザクション干渉追跡テーブル（例えば、テーブル１３５０ａ）に付加する。

上述した特徴の１つ又は複数に加えて、又は代案として、更に別の実施形態は、遠隔トランザクションのトランザクション・ステータスが、（要求プロセッサ１１２ａにより）トランザクション診断ブロック（ＴＤＢ）に付加されることを含むことができる。遠隔トランザクションは、遠隔プロセッサ１１２ｂ上で実行され、要求プロセッサがデータ要求を遠隔プロセッサに送ることに基づいて実行をアボートする。要求は、要求を送る要求プロセッサ１１２ａ上で実行される要求トランザクション（例えば、トランザクション３２０ａ）によるものである。

上述した特徴の１つ又は複数に加えて、又は代案として、更に別の実施形態は、要求が、要求トランザクションにより、遠隔プロセッサ１１２ｂにおける遠隔トランザクション（例えば、トランザクション３２０ｂ）のアボートを引き起こすことに基づいて、要求プロセッサ１１２ａが、（フィールド１０１０から取得された）遠隔トランザクションのトランザクション・ステータスをローカル・トランザクション干渉追跡テーブル１３５０ａに付加し、遠隔トランザクション（アボートする各特定のトランザクション３２０ｂ）に関して生じたトランザクション・アボートのカウントをインクリメントすることを含むことができる。

上述した特徴の１つ又は複数に加えて、又は代案として、更に別の実施形態は、遠隔プロセッサ１１２ｂからの応答１００５、１１０５における、要求プロセッサ１１２ａが受け取った遠隔トランザクションのトランザクション・ステータスが、要求プロセッサ１１２ａからの要求５０５、６０５を受け取ることに基づき、遠隔トランザクション（トランザクション３２０ｂ）をアボートする必要があったことを示すことを含むことができる。

上述した特徴の１つ又は複数に加えて、又は代案として、更に別の実施形態は、ローカル・トランザクション干渉追跡テーブル１３５０ａが、要求プロセッサ１１２ａ上で実行されている要求トランザクション３２０ａと干渉し、これによりアボートされたトランザクションの数を保持することを含むことができる。ローカル・トランザクション干渉追跡テーブル１３５０ａは、遠隔プロセッサ１１２ｂ（及び他のプロセッサ）上の遠隔トランザクション３２０ｂについて説明する情報を保持する。遠隔プロセッサ１１２ａ上の遠隔トランザクション３２０ｂについて説明する情報は、プロセッサ上で実行されている要求トランザクションにより引き起こされた干渉のタイプ、要求トランザクションによりアボートされた遠隔トランザクションの各々の識別又はアドレス、干渉が生じた遠隔プロセッサの各々の識別、アボートされた遠隔トランザクションの各々のアドレス、及び／又はアボートされる前に遠隔トランザクションの各々により実施された作業の尺度のうちの少なくとも１つを含む。

技術的効果及び利点として、コヒーレンス・プロトコルが、トランザクション・ステータスについての付加的な情報を含むように拡張されることが挙げられる。プロセッサがトランザクション実行にあるとき、競合が検出されるため、コヒーレンス要求は、受信プロセッサのトランザクション実行のアボートを引き起こすことがある。コヒーレンス・プロトコル要求は、受信プロセッサが、実施形態によるトランザクション実行をアボートしたという付加的な情報により拡張される。

本明細書において用いられる用語は、特定の実施形態を説明する目的のためのものにすぎず、本発明を限定することを意図するものではない。本明細書で用いられるとき、単数形「１つの（a）」、「１つの（an）」及び「その（the）」は、文脈が明らかにそうでないことを示していない限り、複数形も含むことが意図されている。本明細書で用いられるとき、「含む（comprise）」及び／又は「含んでいる（comprising）」という用語は、提示された特徴、整数、ステップ、動作、要素、及び／又はコンポーネントが存在することを特定するものであるが、１つ又は複数の他の特徴、整数、ステップ、動作、要素、コンポーネント、及び／又はそれらのグループの存在又は追加を排除するものではないことがさらに理解されるであろう。

以下の特許請求の範囲における全ての「手段又はステップと機能との組み合わせ（ミーンズ又はステップ・プラス・ファンクション）」要素の対応する構造、材料、行為及び均等物は、その機能を、明確に特許請求されているように他の特許請求された要素と組み合わせて実行するための、いかなる構造、材料又は行為をも含むことが意図される。本発明の説明は、例示及び説明の目的で提示されたものであるが、網羅的であることを意図するものではなく、本発明を開示された形態に限定することを意図するものでもない。本発明の範囲及び精神から逸脱することのない多くの変更及び変形が、当業者には明らかであろう。実施形態は、本発明の原理及び実際の用途を最も良く説明するため、及び、当業者が本発明を種々の変更を有する種々の実施形態について企図される特定の使用に適したものとして理解することを可能にするために、選択及び記載された。

本発明の種々の実施形態の説明は、例示の目的で提示されたものであるが、網羅的であることを意図するものではなく、開示された実施形態に限定することを意図するものでもない。説明された実施形態の範囲及び精神から逸脱することのない多くの変更及び変形が、当業者には明らかであろう。本明細書において用いられる用語は、本実施形態の原理、実際の用途若しくは市場で見出される技術に対する技術的改良を最も良く説明するため、又は当業者が本明細書に開示される実施形態を理解することを可能にするために選択された。

ここで図１８を参照すると、コンピュータ可読ストレージ媒体１８０２及びプログラム命令１８０４を含む一実施形態によるコンピュータ・プログラム製品１８００が全体的に示される。

本発明は、システム、方法、及び／又はコンピュータ・プログラム製品とすることができる。コンピュータ・プログラム製品は、プロセッサに、本発明の態様を実施させるためのコンピュータ可読プログラム命令をそこに有するコンピュータ可読ストレージ媒体（単数又は複数）を含むことができる。

コンピュータ可読ストレージ媒体は、命令実行デバイスにより使用される命令を保持し、格納することができる有形デバイスとすることができる。コンピュータ可読ストレージ媒体は、例えば、これらに限定されるものではないが、電子記憶装置、磁気記憶装置、光記憶装置、電磁気記憶装置、半導体記憶装置、又は上記のいずれかの適切な組み合わせとすることができる。コンピュータ可読ストレージ媒体のより具体的な例の非網羅的なリストとして、以下のもの：即ち、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能なプログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル、コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリ・スティック、フロッピー・ディスク、パンチカード若しくはそこに命令が記録された溝内の隆起構造などの機械的符号化デバイス、及び上記のいずれかの適切な組み合わせが挙げられる。本明細書で使用される場合、コンピュータ可読ストレージ媒体は、電波又は他の自由に伝搬する電磁波、導波路若しくは他の伝送媒体を通じて伝搬する電磁波（例えば、光ファイバ・ケーブルを通る光パルス）、又は配線を通じて伝送される電気信号のような、一時的信号それ自体として解釈されるべきではない。

本明細書で説明されるコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体からそれぞれのコンピュータピューティング／処理デバイスに、又は、例えばインターネット、ローカル・エリア・ネットワーク、広域ネットワーク、及び／又は無線ネットワークなどのネットワークを介して外部コンピュータ若しくは外部ストレージ・デバイスに、ダウンロードすることができる。ネットワークは、銅製伝送ケーブル、光伝送ケーブル、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、及び／又はエッジ・サーバを含むことができる。各コンピューティング／処理デバイス内のネットワーク・アダプタ・カード又はネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受け取り、それぞれのコンピューティング／処理デバイス内のコンピュータ可読ストレージ媒体内に格納するためにコンピュータ可読プログラム命令を転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、ミリコード、ファームウェア命令、状態設定データ、又はＳｍａｌｌｔａｌｋ、Ｃ＋＋等などのオブジェクト指向型プログラミング言語、及び、「Ｃ」プログラミング言語、若しくは同様のプログラミング言語のような従来の手続き型プログラミング言語を含む１つ又は複数のプログラミング言語のいずれかの組み合わせで書かれたソース・コード若しくはオブジェクト・コードのいずれかとすることができる。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で実行される場合もあり、スタンドアロンのソフトウェア・パッケージとして、一部がユーザのコンピュータ上で実行される場合もあり、一部がユーザのコンピュータ上で実行され、一部が遠隔コンピュータ上で実行される場合もあり、又は完全に遠隔コンピュータ若しくはサーバ上で実行される場合もある。最後のシナリオにおいては、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続される場合もあり、又は外部コンピュータへの接続がなされる場合もある（例えば、インターネット・サービス・プロバイダを用いたインターネットを通じて）。幾つかの実施形態において、例えば、プログラム可能論理回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、又はプログラム可能論理アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実施するために、コンピュータ可読プログラム命令の状態情報を用いて電子回路を個人化することにより、コンピュータ可読プログラム命令を実行することができる。

本発明の態様は、本発明の実施形態による方法、装置（システム）及びコンピュータ・プログラム製品のフローチャート図及び／又はブロック図を参照して、本明細書で説明される。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図内のブロックの組み合わせは、コンピュータ可読プログラム命令によって実装できることが理解されるであろう。

これらのコンピュータ可読プログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えてマシンを製造し、それにより、コンピュータ又は他のプログラム可能データ処理装置のプロセッサによって実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装するための手段を作り出すようにすることができる。これらのコンピュータ可読プログラム命令を、コンピュータ、プログラム可能データ処理装置、及び／又は他のデバイスを特定の方式で機能させるように指示することができるコンピュータ可読ストレージ媒体内に格納し、それにより、内部に命令が格納されたコンピュータ可読ストレージ媒体が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作の態様を実装する命令を含む製品を含むようにすることもできる。

コンピュータ可読プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上にロードして、一連の動作ステップをコンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上で行わせてコンピュータ実施のプロセスを生成し、それにより、コンピュータ又は他のプログラム可能装置、又は他のデバイス上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実行するためのプロセスを提供するようにもできる。

図面内のフローチャート及びブロック図は、本発明の種々の実施形態によるシステム、方法及びコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能及び動作を示す。この点に関して、フローチャート又はブロック図内の各ブロックは、指定された論理機能を実装するための１つ又は複数の実行可能命令を含むモジュール、セグメント、又は命令の部分を表すことができる。幾つかの代替的な実装において、ブロック内に記載された機能は、図面内に記載された順序とは異なる順序で行われ得ることもある。例えば、連続して示された２つのブロックが、関与する機能に応じて、実際には、実質的に同時に実行されることもあり、又は、ときにはブロックが逆順に実行されることもある。また、ブロック図及び／又はフローチャート図の各ブロック、並びにブロック図及び／又はフローチャート図内のブロックの組み合わせは、指定された機能又は動作を行う専用ハードウェア・ベースのシステムによって、又は専用ハードウェアとコンピュータ命令との組み合わせによって実装できることにも留意されたい。

１１２ａ、１１２ｂ：プロセッサ（ＣＰＵ）
１１８ａ、１１８ｂ：データ・キャッシュ
３００：コンピュータ・システム
３１０：メモリ
３２０ａ、３２０ｂ：トランザクション命令
３３４ａ、３３４ｂ：レジスタ
３５０：トランザクション診断ブロック（ＴＤＢ）
５０５、６０５：要求
５０６、５１６：タイプ・フィールド
５０７、５１７：タグ・フィールド
５０８：アクセス・フィールド
５０９：アドレス・フィールド
５１０：エラー訂正フィールド
５１５、１００５：応答
５１８：データ・フィールド
１０１０：トランザクション・アボート・ステータス・フィールド
１３５０ａ、１３５０ｂ：テーブル

Claims (8)

1. コヒーレンス・プロトコルを実施するためのコンピュータ・プログラムであって、
   プロセッサに、
   ローカルでキャッシュされていないデータに対する要求を遠隔プロセッサに送ることと、
   前記遠隔プロセッサから前記要求にかかるデータを含む応答を受け取ることであって、前記応答は、前記遠隔プロセッサ上で実行されていた遠隔トランザクションが前記要求にかかるデータを使用することによりアボートされたか否かを示すトランザクション・アボート・ステータスをさらに含む、受け取ることと、
   前記遠隔プロセッサ上の前記遠隔トランザクションの前記トランザクション・アボート・ステータスをローカル・トランザクション干渉追跡テーブル内に付加することと、
   を実行させるためのコンピュータ・プログラム。
2. 前記遠隔トランザクションの前記トランザクション・アボート・ステータスは、トランザクション診断ブロックに付加される、請求項１に記載のコンピュータ・プログラム。
3. 前記要求は、前記要求を送る前記プロセッサ上で実行されている要求トランザクションによるものである、請求項１のコンピュータ・プログラム。
4. 前記プロセッサに、
   前記要求トランザクションによる前記要求が前記遠隔プロセッサ上で前記遠隔トランザクションをアボートさせることに基づいて、前記遠隔トランザクションの前記トランザクション・アボート・ステータスを前記ローカル・トランザクション干渉追跡テーブル内に付加させ、かつ前記遠隔トランザクションに関して発生したトランザクション・アボートのカウントをインクリメントさせる、請求項３のコンピュータ・プログラム。
5. コヒーレンス・プロトコルを実施するためのコンピュータ・システムであって、前記システムは、
   メモリと、
   前記メモリに通信可能に結合されたプロセッサと、
   を含み、前記プロセッサが、
   ローカルでキャッシュされていないデータに対する要求を遠隔プロセッサに送ることと、
   前記遠隔プロセッサから前記要求にかかるデータを含む応答を受け取ることであって、前記応答は、前記遠隔プロセッサ上で実行されていた遠隔トランザクションが前記要求にかかるデータを使用することによりアボートされたか否かを示すトランザクション・アボート・ステータスをさらに含む、受け取ることと、
   前記遠隔プロセッサ上の前記遠隔トランザクションの前記トランザクション・アボート・ステータスをローカル・トランザクション干渉追跡テーブル内に付加することと、
   を実行する、コンピュータ・システム。
6. 請求項１乃至４の何れか一項に記載のコンピュータ・プログラムを格納したメモリと、前記メモリに格納された前記コンピュータ・プログラムを実行するプロセッサと、
   を備えたコンピュータ・システム。
7. コヒーレンス・プロトコルを実施するための方法であって、
   プロセッサが、
   ローカルでキャッシュされていないデータに対する要求を遠隔プロセッサに送ることと、
   前記遠隔プロセッサから前記要求にかかるデータを含む応答を受け取ることであって、前記応答は、前記遠隔プロセッサ上で実行されていた遠隔トランザクションが前記要求にかかるデータを使用することによりアボートされたか否かを示すトランザクション・アボート・ステータスをさらに含む、受け取ることと、
   前記遠隔プロセッサ上の前記遠隔トランザクションの前記トランザクション・アボート・ステータスをローカル・トランザクション干渉追跡テーブル内に付加することと、
   を実行する、方法。
8. 請求項１乃至４の何れか一項に記載のコンピュータ・プログラムをプロセッサが実行することで行われる各ステップを含む方法。
   

Images