JP6463367B2 - ハードウェア・トランザクションのサルベージ - Google Patents

Description

本開示は、一般に、トランザクション実行に関し、より具体的には、部分的に実行されたハードウェア・トランザクションをサルベージする（復旧させる、salvage）ことに関する。

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

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

２００５年７月２９日に出願された「Ｄｉｒｅｃｔ−Ｕｐｄａｔｅ Ｓｏｆｔｗａｒｅ Ｔｒａｎｓａｃｔｉｏｎａｌ Ｍｅｍｏｒｙ」という名称の特許文献１は、スレッドが、トランザクション内の１つ又は複数の共有メモリ位置に直接かつ安全にアクセスすることを可能にする一方で、１つ又は複数の他の並行スレッドによる同じ位置へのメモリ・アクセスを管理するための制御構造を保持する、トランザクション・メモリ・プログラミング・インターフェースを教示する。スレッドがアクセスする各メモリ位置は、登録記録（enlistment record）と関連付けられ、各スレッドは、そのメモリ・アクセスのトランザクション・ログを保持する。トランザクション内では、一部の中間バッファとは対照的に、読み取り操作はメモリ位置で直接実行され、書き込み操作はメモリ位置で直接試行される。スレッドは、メモリ位置の登録記録とスレッドのトランザクション・ログとの間の不一致を検出し、トランザクション内のメモリ・アクセスが信頼できず、トランザクションを再試行すべきであるかどうかを判断することができる。

２００９年１１月６日に出願された「Ｈｙｂｒｉｄ Ｔｒａｎｓａｃｔｉｏｎａｌ Ｍｅｍｏｒｙ Ｓｙｓｔｅｍ（ＨｙｂｒｉｄＴＭ） ａｎｄ Ｍｅｔｈｏｄ」という名称の特許文献２は、メモリと、コンピュータ・プログラムによりデータを処理するための処理ファシリティとを有し、高速相互接続要素を介して、システムの物理メモリアレイ、Ｉ／Ｏデバイスに結合されたモジュール１．．．ｎを有するハイブリッド・トランザクション・メモリのマルチプロセッサ・システムである、コンピュータ処理システムを教示する。ＣＰＵは、マルチチップ・モジュールにおけるように、マイクロプロセッサと統合され、アシスト・スレッド・ファシリティ、並びに、メモリ・コントローラ、キャッシュ・コントローラ、キャッシュ・メモリ、及び高速相互接続部に接続されるＣＰＵの一部を形成する他のコンポーネントを含むか、又はＣＰＵモジュールにおいてこれらに結合され、アーキテクチャ及びオペレーティング・システム下で機能して、コンピュータ・システムの要素を、物理メモリ、種々のＩ／Ｏデバイス、及びシステムの他のＣＰＵと相互接続する。現行のハイブリッド・トランザクション・メモリ要素は、限られたハードウェア・リソースで処理できる簡単で／費用対効果の高いハードウェア設計を有するトランザクション・メモリ・システムをサポートし、さらにこのトランザクション・メモリ・システムは、トランザクションが依然として既存のライブラリを参照し、かつ、プログラマーがそのトランザクション内の既存のソフトウェアのライブラリへの呼び出しを含むことを可能にするバックアップ・アシスト・スレッドを提供するトランザクション・ファシリティ制御論理を有し、そして、ユーザコードに第２のロック・ベースのソリューションを使用させない。

米国特許出願公開第２００７／００２８０５６号明細書 米国特許出願公開第２０１１／０１１９４５２号明細書 米国特許第６，３４９，３６１号

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

部分的に実行されたハードウェア・トランザクションをサルベージするトランザクション・メモリ・システムのための方法、コンピュータ・システム、及びコンピュータ・プログラムを提供する。

本開示の実施形態は、部分的に実行されたハードウェア・トランザクションをサルベージするトランザクション・メモリ・システムのための方法、コンピュータ・システム、及びコンピュータ・プログラム製品を提供する。トランザクション・メモリ・システムのプロセッサは、ハードウェア・トランザクションのコード領域のトランザクション実行のために、失敗直前（ａｂｏｕｔ−ｔｏ−ｆａｉｌ）ハンドラについての情報を判断する。プロセッサは、ハードウェア・トランザクションの状態情報を保存し、状態情報は、ハードウェア・トランザクションがサルベージされるか又はアボートされるかを判断するのに使用可能である。プロセッサは、ハードウェア・トランザクションのトランザクション実行中、失敗直前条件を検出する。プロセッサは、検出に基づいて、失敗直前ハンドラについての情報を用いて、失敗直前ハンドラを実行し、失敗直前ハンドラは、ハードウェア・トランザクションがサルベージされるか又はアボートされるかを判断する。

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

本開示の実施形態による、例示的なマルチコア・トランザクション・メモリ環境のブロック図を示す。 本開示の実施形態による、例示的なマルチコア・トランザクション・メモリ環境のブロック図を示す。 本開示の実施形態による、例示的なＣＰＵの例示的なコンポーネントを含むブロック図を示す。 本開示の実施形態による、失敗の検出時に、部分的に実行されたハードウェア・トランザクションをサルベージするための１つの実施形態を示すフロー図を示す。 本発明の１つの実施形態を示すフロー図を示す。 本発明の１つの実施形態を示すフロー図を示す。 本発明の１つの実施形態を示すフロー図を示す。 本発明の１つの実施形態を示すフロー図を示す。 本発明の１つの実施形態を示すフロー図を示す。 本開示の実施形態による、コンピュータ・システムの機能ブロック図を示す。

従来、コンピュータ・システム又はプロセッサは、シングル・プロセッサ（別名、処理ユニット又は中央処理ユニット）しか有していなかった。プロセッサは、命令処理ユニット（ＩＰＵ）、分岐ユニット、メモリ制御ユニット等を含んでいた。こうしたプロセッサは、一度に単一のプログラム・スレッドを実行することができた。一定の期間プロセッサ上で実行されるようにプログラムをディスパッチし、次に、別の期間プロセッサ上で実行されるように別のプログラムをディスパッチすることによって、プロセッサを時分割する（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）ＣＭポリシーは、競合を再開する前に、指数関数的バックオフ（exponential backoff）を使用する（しかし、線形を用いることもできる）。スターベーション（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）ではないので、ミリコード化することができる。即ち、ミリコードは、特殊ハードウェア・レジスタから現在のネスト化深さをロードし、それをＧＲ２２８に入れる。ＰＰＡ命令はミリコード化することができる。ＰＰＡ命令は、ＰＰＡへのオペランドとしてソフトウェアにより提供される現在のアボート・カウントと、同じく他のハードウェア内部状態とに基づいて、最適な遅延を実施する。

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

図４は、本開示の実施形態による、失敗の検出時に、部分的に実行されたハードウェア・トランザクションをサルベージするための実施形態を示す。図４の詳細を論じる前に、以下に本開示の実施形態を一般的に説明する。

上述のように、トランザクション・メモリ・システムにおけるトランザクション・セマンティクスは、各トランザクションにより読み取り及び書き込みされたメモリ位置を追跡することによって、実施することができる。複数のトランザクション実行論理プロセッサが、同じメモリに競合する方法でアクセスした場合、対立するすなわち競合するトランザクションの１つ又は複数がアボートされることがある。例えば、アクセスの少なくとも１つが書き込みである場合、同じメモリ位置の２つのアクセスは競合することがある。

さらに前述されたように、トランザクション・メモリ・システムは、様々な技術を通じてトランザクション・セマンティクスを実装する。一般に、所与のトランザクション・メモリ・システムは、実行されているトランザクションについての投機的状態を保持するための機構を含む（例えば、ロールバック情報がｕｎｄｏログに保存される間、投機的状態をイン・プレースに保持することができ、又は、ロールバック情報がイン・プレースに保存される間、投機的状態を書き込みバッファに保持することができる等）。１つ又は複数の実行中のトランザクションが、投機的状態の保持専用リソースを使い果たした場合、トランザクションの１つ又は複数がアボートされることがある。例えば、ネスト化トランザクションの数に対するハード制限（hard limit）を含むトランザクション・メモリ・システムは、ネスト化トランザクションの数がハード制限を超えた場合、１つ、幾つか、又は全てのネスト化トランザクションをアボートすることがある。別の例においては、格納された投機的状態の量に対するハード制限を含むトランザクション・メモリ・システムは、投機的状態の量がハード制限を超えた場合（本例では、投機的状態の量に対するハード制限は、例えば、投機的状態を保持する書き込みバッファのサイズ等に基づくことができる）、１つ又は複数のトランザクションをアボートすることがある。

本開示の実施形態によれば、実行中のハードウェア・トランザクションの際に失敗を検出すると、実行中のトランザクションをアボートする代わりに、トランザクション・メモリ・システムは、失敗直前ハンドラにジャンプし、これを実行することによって、部分的に実行されたトランザクションをサルベージすることができる。失敗直前ハンドラは、サルベージ可能な投機的状態を判断し、何らかのサルベージ可能な投機的状態をコミットし、トランザクションにおける残りの命令の実行を続ける。部分的に実行されたトランザクションをサルベージすることにより、トランザクション・メモリ・システムは、このように、他の場合にはアボート時に廃棄されている投機的状態を保存し利用する。

例示的な実施形態において、トランザクションが失敗直前であるとき、ハードウェアは、トランザクションが失敗直前であるという表示と共に、制御をソフトウェアに移す。次いで、ソフトウェアは、サルベージ可能な投機的状態を判断し、トランザクションをコミットし、トランザクションの実行を続ける。さらに、図１０の失敗直前ハンドラ情報決定器１０６０のようなハードウェアは、失敗直前ハンドラのアドレスを指し示すための手段をソフトウェアに与える。これは、そうしたアドレスを示すための明示的な命令（例えば、ｒｅｃｏｒｄ−ａｂｏｕｔ−ｔｏ−ｆａｉｌ−ｈａｎｄｌｅｒ−ａｄｄｒｅｓｓ（失敗直前ハンドラ・アドレス記録）命令等）を与えることによって、行うことができる。或いは、ハードウェアは、失敗（failure）ハンドラについての同じアドレスを使用し（すなわち、失敗ハンドラと失敗直前ハンドラの両方を有する実施形態において）、トランザクションが失敗直前であるが、実際にはまだ失敗していないという、例えば条件レジスタ（サルベージ・レジスタ１０６２等）内のインジケータを与えることができる。アドレスなどの、失敗直前ハンドラに関する情報は、トランザクション・メモリ・システムによって、レジスタ（例えば、サルベージ・レジスタ１０６２等）に格納することができる。ハードウェア、例えば図１０の失敗直前条件検出器１０６４は、トランザクションが失敗直前であるときを検出し、例えばハードウェア・トランザクション・トランスファラ（transferor）１０６６を用いて、制御を失敗直前ハンドラに移す。

ソフトウェアは、以下のようにこれらの技術を用いて、ハードウェア・トランザクションにおける計算をサルベージすることができる。：ソフトウェアは、条件レジスタをチェックして、トランザクションが失敗したのか、又はトランザクションが失敗直前であるが、実際にはまだ失敗していないかを判断することができる。代替的に、ソフトウェアは、失敗直前ハンドラの位置を判断するための手段を用いることができる（例えば、ｒｅｃｏｒｄ−ａｂｏｕｔ−ｔｏ−ｆａｉｌ−ｈａｎｄｌｅｒ−ａｄｄｒｅｓｓ命令は、サルベージ・レジスタ１０６２等における位置を記録する）。失敗直前ハンドラにおいて、ソフトウェアは、部分的に実行されたトランザクションのいずれかがサルベージ可能であるかどうかを判断し、あらゆるサルベージ可能な投機的状態をコミットする。ソフトウェアは、トランザクションにおける残りの命令の実行に進み、トランザクション実行の完了時に、投機的状態をコミットする。

１つの実施形態において、トランザクション・メモリ・システムは、ハードウェア・トランザクションを開始する（ブロック４１０）。具体的には、トランザクション・メモリ・システムは、「ＴＢＥＧＩＮ」を含む命令、すなわち一般的な「ｔｒａｎｓａｃｔｉｏｎ＿ｂｅｇｉｎ」命令を含むコード領域の実行を開始することができる。例えば、失敗直前ハンドラのアドレスを与える命令を受け取ること、又は、「ｓｅｔ＿ａｂｏｕｔ＿ｔｏ＿ｆａｉｌ＿ｈａｎｄｌｅｒ」のような、例えばｒｅｃｏｒｄ−ａｂｏｕｔ−ｔｏ−ｆａｉｌ−ｈａｎｄｌｅｒ−ａｄｄｒｅｓｓ命令などの失敗直前ハンドラの位置を格納する特殊命令を実行すること、若しくは特殊用途メモリ・アドレスにおける失敗直前ハンドラの指定されたアドレスを受け取ることにより失敗直前ハンドラの位置を記録することによって、トランザクション・メモリ・システムは、ハードウェア・トランザクションのコード領域のトランザクション実行のための、失敗直前ハンドラについての情報を判断する（ブロック４１２）。図１０において失敗直前ハンドラ情報決定器１０６０により表されるハードウェアは、失敗直前ハンドラについての情報を判断することができる。例示的な実施形態において、トランザクション・メモリ・システムは、例えば、ソフトウェア・コンポーネントがトランザクションの状態を追跡することを可能にする、状態変数などのローカル変数を設定することによって、状態情報の保存を含むトランザクション構成をサポートする。状態情報は、例えば、ハードウェア・トランザクションにおいて一度だけ、ハードウェア・トランザクションにおける幾つかの特定のプレースに、又はハードウェア・トランザクションにおける各命令の完了後などの幾つかの方法で保存することができ、かつ、投機的状態などのハードウェア・トランザクションのトランザクション実行の完了に必要な情報を含むことができ、又は、状態情報は、ハードウェア・トランザクションがサルベージされるか又はアボートされるかを判断するために使用可能である。状態情報は、図１０のサルベージ・レジスタ１０６２内に保存することができる。

トランザクション・メモリ・システムは、トランザクション・コード領域内の命令を実行する（ブロック４１４）。例えば、実行される命令は、状態情報を保存する命令、又は別の命令とすることができる。トランザクション・メモリ・システムは、ハードウェア・トランザクションが失敗しているかどうかを判断することができる（ブロック４１６）。例示的な実施形態において、トランザクション・メモリ・システムは、ハードウェア・トランザクションのトランザクション実行中、失敗直前条件を検出するが、直ちに失敗しないことがある。失敗直前条件は、図１０の処理ユニット１０１６内の失敗直前条件検出器１０６４によって検出することができる。失敗直前条件の以下の例の各々は、失敗直前条件検出器１０６４によって検出することができる。失敗直前条件は、例えば、トランザクション・コード領域内の次の命令の実行時に、ネスト化トランザクションの数に対するハード制限を超えた場合（例えば、次の命令が、ＴＢＥＧＩＮ、ＸＢＥＧＩＮ、又は一般に、ｔｒａｎｓａｃｔｉｏｎ＿ｂｅｇｉｎ命令等である場合）とすることができる。別の例において、トランザクション・コード領域内の次の命令の実行時に、格納された投機的状態の量に対するハード制限を超えた場合（例えば、次の命令が、投機的状態を保持する書き込みバッファへのストアを含み、書き込みバッファが既にフルである場合等）、トランザクションは失敗している。さらに別の例において、トランザクションが別のトランザクションとの共有競合に入った（例えば、別のプロセッサが競合するキャッシュラインに格納している）場合、トランザクションは失敗している。例えば、ハードウェア・トランザクションにおける次の命令の評価が、次の命令が失敗を引き起こす直前であると判断した場合、トランザクション・メモリ・システムは、トランザクションの失敗の原因を阻止することができ、トランザクション・メモリ・システムは、命令の実行を停止する。別の例において、失敗の潜在的な原因が、別のプロセッサによる割り込み又はメモリ要求などの外因である場合、トランザクション・メモリ・システムは、原因を阻止することができる。トランザクション・メモリ・システムが、トランザクションが失敗していると判断しなかった場合、示される実施形態は、トランザクション・コード領域内の次の命令に戻り、実行する。しかしながら、トランザクション・メモリ・システムが、トランザクションが失敗していると判断した場合、示される実施形態は、次の命令を識別し、４１８に進む。

検出に基づいて、トランザクション・メモリ・システムは、失敗直前ハンドラについての情報を用いて、失敗直前ハンドラを実行することができる。例示的な実施形態において、例えば、図１０のハードウェア・トランザクション・トランスファラ１０６６のようなトランザクション・メモリ・システムは、例えば、以前に判断した失敗直前ハンドラ情報に基づいて、失敗直前ハンドラの位置までジャンプすることにより、トランザクションの制御をソフトウェアの失敗直前ハンドラに移す（ブロック４１８）。例示的な実施形態において、失敗直前ハンドラは、保存されたハードウェア・トランザクションの状態情報に基づいて、トランザクションがサルベージされるか又はアボートされるかを判断する。実施形態においては、失敗直前ハンドラの位置にジャンプする前に、トランザクション・メモリ・システムは、失敗直前ハンドラが、ハードウェア・トランザクションが失敗したのか又はハードウェア・トランザクションが失敗直前であるのかを区別することを可能にする、例えばサルベージ・レジスタ１０６２などの条件レジスタ内にインジケータ値を設定することなどによって、失敗直前インジケータを提供することができる。失敗直前ハンドラは、例えば、１又は２に等しい条件コードなどの値をチェックし、進むか、又はトランザクションの制御を失敗ハンドラに移すかを判断することができる。別の実施形態において、失敗ハンドラなどの一般的なソフトウェア・ハンドラは、条件コードの値をチェックして、進むか、又は失敗直前状況を検出し、失敗直前ハンドラのコードを実行するかを判断することができる。

図５は、部分的に実行されたハードウェア・トランザクションをサルベージするための本開示の１つの実施形態を示す。この実施形態は、ハードウェア・トランザクションのコード領域のトランザクション実行のために、失敗直前ハンドラについての情報を判断する（ブロック５１０）。この実施形態は、ハードウェア・トランザクションの状態情報を保存し、この状態情報は、ハードウェア・トランザクションがサルベージされるか又はアボートされるかを判断するのに使用可能である（ブロック５１２）。この実施形態は、ハードウェア・トランザクションのトランザクション実行中、失敗直前条件を検出する（ブロック５１４）。失敗直前条件が検出されない場合、実施形態は、ハードウェア・トランザクションの状態情報の保存を続行する。失敗直前条件が検出された場合、示される実施形態は、失敗直前ハンドラについての情報を用いて失敗直前ハンドラを実行し、失敗直前ハンドラは、ハードウェア・トランザクションがサルベージされるか又はアボートされるかを判断する（ブロック５１６）。

図６に示されるように、示される実施形態は、失敗直前ハンドラについてのアドレスを与える命令を受け取ること（ブロック６２０）、失敗直前インジケータを与えること（ブロック６３０）、及び失敗直前ハンドラのアドレスを受け取ること（ブロック６４０）のうちの１つ又は複数によって、失敗直前ハンドラについての情報を判断する（ブロック５１０）。さらに、図７に示されるように、示される実施形態は、ハードウェア・トランザクションの各命令の完了後に、状態情報を保存することによって（ブロック７２０）、ハードウェア・トランザクションの状態情報を保存する（ブロック５１２）。また、保存されたハードウェア・トランザクションの状態情報（ブロック５１２）は、ハードウェア・トランザクションのトランザクション実行を完了するのに必要な情報を含む（ブロック７４０）。示される実施形態は、図８に示されるように、ハードウェア・トランザクションの制御を、ソフトウェア失敗直前ハンドラに移すことによって（ブロック８３０）、失敗直前ハンドラを実行する（ブロック５１６）。

図９を参照すると、図５に示される実施形態は、次の命令を評価し、その実行が失敗を引き起こすかどうかを判断し（ブロック９２０）、コード領域内の命令の実行時に、格納された投機的状態の量に対する制限を超えるかどうかを判断し（ブロック９３０）、又は別のプロセッサが競合するキャッシュラインに格納していることを判断する（ブロック９４０）ことによって、ハードウェア・トランザクショのトランザクション実行中に、失敗直前条件をさらに検出する（ブロック５１４）。

ここで図１０を参照すると、本開示の実施形態によるコンピュータ・システムの機能ブロック図が示される。コンピュータ・システム１０００は、好適なクラウド・コンピューティング・ノードの単なる一例であり、本明細書で説明される本開示の実施形態の使用又は機能の範囲に関するいずれかの制限を示唆することを意図するものではない。上記に関係なく、コンピュータ・システム１０００は、本明細書で上述された機能のいずれかを実装及び／又は実施することができる。

コンピュータ・システム１０００には、他の多数の汎用又は専用コンピューティング・システム環境又は構成で動作可能な、コンピュータ１０１２が存在する。コンピュータ１０１２と共に用いるのに好適であり得る周知のコンピューティング・システム、環境、及び／又は構成の例として、これらに限定されるものではないが、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、手持ち式又はラップトップ型デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラム可能民生電子機器、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、及び上記のシステム又はデバイス等のいずれかを含む分散型クラウド・コンピューティング環境が含まれる。

コンピュータ１０１２は、コンピュータ・システムによって実行される、プログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な文脈で説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行する又は特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含むことができる。コンピュータ１０１２は、通信ネットワークを通じてリンクされた遠隔処理デバイスによってタスクが実行される分散型クラウド・コンピューティング環境で実施することができる。分散型クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカル及び遠隔両方のコンピュータ・システム・ストレージ媒体に配置することができる。

図１０にさらに示されるように、コンピュータ・システム１０００のコンピュータ１０１２は、汎用コンピューティング・デバイスの形で示される。コンピュータ１０１２のコンポーネントは、これらに限定されるものではないが、１つ又は複数のプロセッサ又は処理ユニット１０１６、メモリ１０２８、及びメモリ１０２８を含む種々のシステム・コンポーネントを処理ユニット１０１６に結合するバス１０１８を含むことができる。処理ユニット１０１６は、種々の実施形態において、図１のＣＰＵ１１４ａ、１１４ｂの幾つか又は全て、図２のトランザクションＣＰＵ環境１１２、及び図３のプロセッサを含むことができる。さらに、処理ユニット１０１６は、種々の実施形態において、図４の文脈において上述されたような、失敗直前ハンドラ情報決定器１０６０、サルベージ・レジスタ１０６２の幾つか又は全て、失敗直前条件検出器１０６４、及びハードウェア・トランザクション・トランスファラ１０６６を含むことができる。

バス１８は、メモリ・バス又はメモリ・コントローラ、周辺バス、アクセラレーテッド・グラフィックス・ポート、及び種々のバス・アーキテクチャのいずれかを用いるプロセッサ又はローカル・バスを含む、幾つかのタイプのバス構造のうちのいずれかの１つ又は複数を表す。限定ではなく例としては、このようなアーキテクチャは、業界標準アーキテクチャ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ、ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ、ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカル・バス、及びＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスを含む。

コンピュータ１０１２は、典型的には、種々のコンピュータ・システム可読媒体を含む。このような媒体は、コンピュータ１０１２がアクセス可能ないずれかの利用可能媒体とすることができ、揮発性媒体及び不揮発性媒体の両方と、取り外し可能媒体及び取り外し不能媒体の両方とを含む。

メモリ１０２８は、ランダム・アクセス・メモリ（ＲＡＭ）１０３０及び／又はキャッシュ１０３２など、揮発性メモリの形のコンピュータ・システム可読媒体を含むことができる。一実施形態において、キャッシュ１０３２、及び／又は付加的なキャッシュは、処理ユニット１０１６内に含まれる。コンピュータ１０１２は、他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ・システム・ストレージ媒体をさらに含むことができる。単なる例として、取り外し不能の不揮発性磁気媒体（図示されておらず、典型的には「ハード・ドライブ」と呼ばれる）との間の読み出し及び書き込みのために、コンピュータ可読ストレージ媒体１０３４を設けることができる。図示されていないが、取り外し可能な不揮発性磁気ディスク（例えば、「フロッピー・ディスク」）との間の読み出し及び書き込みのための磁気ディスク・ドライブと、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又は他の光媒体などの取り外し可能な不揮発性光ディスクとの間の読み出し及び書き込みのための光ディスク・ドライブとを設けることができる。このような例においては、それぞれを、１つ又は複数のデータ媒体インターフェースによって、バス１０１８に接続することができる。以下でさらに示され説明されるように、メモリ１０２８は、本開示の実施形態の機能の一部又は全てを実行するように構成されたプログラム・モジュールのセット（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含むことができる。

限定ではなく例として、メモリ１０２８内に、１つ又は複数のプログラム・モジュール１０４２を有するプログラム１０４０、並びにオペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データを格納することができる。オペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データ、又はそれらの何らかの組み合わせの各々は、ネットワーキング環境の実装形態を含むことができる。幾つかの実施形態においては、プログラム・モジュール１０４２は、一般に、本明細書で説明される本開示の実施形態の機能及び／又は方法を実行し、一方、他の実施形態においては、処理ユニット１０１６が、一般に、本明細書で説明される本開示の実施形態の機能及び／又は方法を実行し、一方、さらに他の実施形態においては、コンピュータ１０１２の他の部分が、本明細書で説明される本開示の実施形態の機能及び／又は方法を実行する。

コンピュータ１０１２は、キーボード、ポインティング・デバイス等、並びにディスプレイ１０２４のような１つ又は複数の外部デバイス１０１４；ユーザがコンピュータ１０１２と対話することを可能にする１つ又は複数のデバイス；及び／又はコンピュータ１０１２が１つ又は複数の他のコンピューティング・デバイスと通信することを可能にするいずれかのデバイス（例えば、ネットワーク・カード、モデム等）と通信することもできる。このような通信は、入力／出力（Ｉ／Ｏ）インターフェース１０２２を経由して行うことができる。さらにまた、コンピュータ１０１２は、ネットワーク・アダプタ１０２０を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、汎用広域ネットワーク（ＷＡＮ）、及び／又は公衆ネットワーク（例えば、インターネット）などの１つ又は複数のネットワークと通信することもできる。示されるように、ネットワーク・アダプタ１０２０は、バス１０１８を介して、コンピュータ１０１２の他のコンポーネントと通信する。図示されないが、コンピュータ１０１２と共に他のハードウェア及び／又はソフトウェア・コンポーネントを使用できることを理解されたい。例として、これらに限定されるものではないが、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部のディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、及びデータ・アーカイブ・ストレージ・システム等が含まれる。

種々の実施形態は、システム・バスを通じてメモリ要素に直接又は間接的に結合された少なくとも１つのプロセッサを含むプログラム・コードを格納及び／又は実行するのに適したデータ処理システム内で実装することができる。メモリ要素は、例えば、プログラム・コードの実際の実行中に用いられるローカル・メモリ、大容量記憶装置、及び実行中に大容量記憶装置からコードを取り出さなければならない回数を減らすために少なくとも一部のプログラム・コードを一時的に格納するキャッシュ・メモリを含む。

入力／出力すなわちＩ／Ｏデバイス（これらに限定されるものではないが、キーボード、ディスプレイ、ポインティング・デバイス、ＤＡＳＤ、テープ、ＣＤ、ＤＶＤ、サムドライブ及び他のメモリ媒体等を含む）を、直接又は介在するＩ／Ｏコントローラを通じてシステムに結合することができる。ネットワーク・アダプタをシステムに結合して、データ処理システムが、介在する私的又は公衆ネットワークを通じて他のデータ処理システム又は遠隔プリンタ又はストレージ・デバイスに結合されるようになるのを可能にすることもできる。モデム、ケーブル・モデム及びイーサネットは、利用可能なタイプのネットワーク・アダプタのほんのわずかにすぎない。

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

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

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

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

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

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

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

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

本明細書において１つ又は複数の例が与えられたが、これらは例にすぎない。本開示の趣旨から逸脱することなく、多数の変形が可能である。例えば、本明細書で与えられた例以外の処理環境は、本開示の１つ又は複数の態様を含むこと、及び／又は１つ又は複数の態様から利益を得ることができる。さらに、この環境は、ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅ（登録商標）に基づくものである必要はないが、代わりに、例えば、ＩＢＭ（登録商標）、Ｉｎｔｅｌ（登録商標）、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ並びに他のものによって提供される他のアーキテクチャに基づくものであってもよい。さらにまた、この環境は、例として、パーティション化された及び／又は他のシステムに結合された複数のプロセッサを含むことができる。

好ましい実施形態が本明細書に詳細に示され、説明されたが、当業者には、本開示の趣旨から逸脱することなく、種々の修正、付加、置換等を行い得ることが明らかであり、従って、これらは以下の特許請求の範囲内に定められるような本開示の趣旨の範囲内にあると考えられる。

１００：ダイ
１１２：ＣＰＵ環境
１１４、１１４ａ、１１４ｂ：ＣＰＵ
１１６ａ、１１６ｂ：命令キャッシュ
１１８ａ、１１８ｂ、２４０：データ・キャッシュ
１２０ａ、１２０ｂ：相互接続制御
１２２：相互接続
１２４：共有キャッシュ
１２６：レジスタ・チェックポイント
１２８：トランザクション・メモリ（ＴＭ）レジスタ
２０８：命令デコード・ユニット（ＩＤＵ）
２１２：ネスト化深さ
２１６：発行キュー
２２４：ＴＸバックアップＧＲｓ
２２８：汎用レジスタ（ＧＲｓ）
２３２：グローバル完了テーブル（ＧＣＴ）
２３２ｂ：ｍｉｃｒｏ−ｏｐ
２３６：アドレス計算器
２４０：データ・キャッシュ
２６４：収集ストア・キャッシュ
２８０：ロード／ストア・ユニット（ＬＳＵ）
１０００：コンピュータ・システム
１０１２：コンピュータ
１０１６：処理ユニット
１０１８：バス
１０２８：メモリ
１０３０：ランダム・アクセス・メモリ（ＲＡＭ）
１０３２：キャッシュ
１０４０：プログラム
１０４２：プログラム・モジュール
１０６０：失敗直前ハンドラ情報決定器
１０６２：サルベージ・レジスタ
１０６４：失敗直前条件検出器
１０６６：ハードウェア・トランザクション・トランスファラ

Claims (10)

1. 部分的に実行されたハードウェア・トランザクションをサルベージするための方法であって、
   プロセッサにより、ハードウェア・トランザクションのコード領域のトランザクション実行のために、失敗直前ハンドラについての情報を判断することと、
   前記プロセッサにより、前記ハードウェア・トランザクションの状態情報を保存することであって、前記状態情報は、前記ハードウェア・トランザクションがサルベージされるか又はアボートされるかを判断するのに使用可能である、保存することと、
   前記プロセッサにより、前記ハードウェア・トランザクションの前記トランザクション実行中、失敗直前条件を検出することと、
   前記検出に基づいて、前記プロセッサにより、前記失敗直前ハンドラについての前記情報を用いて、前記失敗直前ハンドラを実行することであって、前記失敗直前ハンドラは、前記ハードウェア・トランザクションがサルベージされるか又はアボートされるかを判断するためのものである、実行することと、
   を含む、方法。
2. 前記プロセッサにより、前記失敗直前ハンドラについての情報を判断することは、前記失敗直前ハンドラについてのアドレスを与える命令を受け取ること、失敗直前インジケータを与えること、前記失敗直前ハンドラのアドレスを受け取ること、のうちの１つ又は複数を含む、請求項１に記載の方法。
3. 前記プロセッサにより、前記ハードウェア・トランザクションの状態情報を保存することは、前記ハードウェア・トランザクションの各命令の完了後、前記状態情報を保存することをさらに含む、請求項１に記載の方法。
4. 前記プロセッサにより、前記失敗直前ハンドラを実行することは、前記ハードウェア・トランザクションの制御を、ソフトウェアの失敗直前ハンドラに移すことをさらに含む、請求項１に記載の方法。
5. 前記ハードウェア・トランザクションの前記状態情報は、前記ハードウェア・トランザクションのトランザクション実行を完了するために必要な情報を含む、請求項１に記載の方法。
6. 前記プロセッサにより、前記ハードウェア・トランザクションの前記トランザクション実行中、前記失敗直前条件を検出することは、次の命令を評価して、その実行が失敗を引き起こすかどうかを判断することを含む、請求項１に記載の方法。
7. 前記プロセッサにより、前記ハードウェア・トランザクションの前記トランザクション実行中、前記失敗直前条件を検出することは、前記コード領域内の命令の実行時に、格納された投機的状態の量に対する制限を超えるかどうかを判断することを含む、請求項１に記載の方法。
8. 前記プロセッサにより、前記ハードウェア・トランザクションの前記トランザクション実行中、前記失敗直前条件を検出することは、別のプロセッサが、競合するキャッシュラインに格納していることを判断することを含む、請求項１に記載の方法。
9. 請求項１乃至８のいずれかに記載の方法における全てのステップを実行するように適合された手段を含むシステム。
10. コンピュータ・プログラムがコンピュータ・システム上で実行されたとき、請求項１乃至８のいずれかに記載の方法における全てのステップを実行するための命令を含む、コンピュータ・プログラム。

Images