JP6642806B2 - ロック無効化とロックの選択を用いたデータ共有のための適応プロセス - Google Patents

Description

本開示は、一般に、トランザクション・メモリ・システムに関し、より詳細には、ロック無効化（lock elision）とロック（locking）の選択を用いたデータの適応共有のための方法、コンピュータ・プログラム、及びコンピュータ・システムに関する。

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

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

２００２年８月２８日に出願され、引用により本明細書に組み入れられる「Ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｔｈｅ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｏｆ ｄｉｓｔｒｉｂｕｔｅｄ ｃａｃｈｅｓ」という名称の特許文献１は、分散キャッシュの同期のための方法及び装置を教示する。より特定的には、本実施形態は、キャッシュ・メモリ・システムに関し、より具体的には、キャッシュ入力／出力（Ｉ／Ｏ）ハブ内での使用を含む、分散キャッシュと共に使用するのに適した階層キャッシュ・プロトコルに関する。

１９９４年３月２４日に出願され、引用により本明細書に組み入れられる「Ｐａｒｔｉａｌ ｃａｃｈｅ ｌｉｎｅ ｗｒｉｔｅ ｔｒａｎｓａｃｔｉｏｎｓ ｉｎ ａ ｃｏｍｐｕｔｉｎｇ ｓｙｓｔｅｍ ｗｉｔｈ ａ ｗｒｉｔｅ ｂａｃｋ ｃａｃｈｅ」という名称の特許文献２は、メモリ、入力／出力アダプタ及びプロセッサを含む、提示されたコンピューティング・システムを教示する。プロセッサは、ダーティ・データ（dirty data）を格納することができるライトバック・キャッシュを含む。入力／出力アダプタからメモリへの一貫性のある書き込みを行う際、データ・ブロックは、入力／出力アダプタからメモリ内のあるメモリ位置に書き込まれる。データ・ブロックは、ライトバック・キャッシュ内のフル・キャッシュラインよりも少ないデータを含む。ライトバック・キャッシュを検索して、ライトバック・キャッシュがそのメモリ位置についてのデータを含むかどうかがを判断する。検索により、ライトバック・キャッシュがそのメモリ位置についてのデータを含むと判断された場合、そのメモリ位置についてのデータを含むフル・キャッシュラインはパージされる。

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

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

ロック無効化とロックの選択を用いたデータの適応共有のための方法、コンピュータ・プログラム、及びコンピュータ・システムを提供する。

Ｈａｒｄｗａｒｅ Ｌｏｃｋ Ｅｌｉｓｉｏｎ（ＨＬＥ）環境において、ＨＬＥトランザクションが実際にロックを取得し、非トランザクションに実行すべきかどうかを予測的に決定するための方法が提供される。本開示の１つの実施形態によれば、本方法は、ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令に遭遇することに基づき、ＨＬＥ予測器に基づいて、ロックを無効化し、ＨＬＥトランザクションとして進行させるか、又はロックを取得して非トランザクションとして進行させるかを決定することと、ＨＬＥ予測器が無効化を行うと予測することに基づき、ロックのアドレスをＨＬＥトランザクションの読み取りセットとして設定し、ｌｏｃｋ−ａｃｑｕｉｒｅ命令によるロックへのあらゆる書き込みを抑止し、ロックを解放するｘｒｅｌｅａｓｅ命令に遭遇するまで又はＨＬＥトランザクションがトランザクション競合に遭遇するまで、ＨＬＥトランザクション実行モードで進行させることと、ＨＬＥ予測器が無効化を行わないと予測することに基づき、ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令を非ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令として扱い、非トランザクション・モードで進行させることとを含むことができる。

本開示の別の実施形態において、Ｈａｒｄｗａｒｅ Ｌｏｃｋ Ｅｌｉｓｉｏｎ（ＨＬＥ）環境において、ＨＬＥトランザクションが実際にロックを取得し、非トランザクションに実行すべきかどうかを予測的に決定するためのコンピュータ・プログラム製品を提供することができる。本コンピュータ・プログラム製品は、処理回路により読み出し可能であり、ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令に遭遇することに基づき、ＨＬＥ予測器に基づいて、ロックを無効化し、ＨＬＥトランザクションとして進行させるか、又はロックを取得して非トランザクションとして進行させるかを決定することと、ＨＬＥ予測器が無効化を行うと予測することに基づき、ロックのアドレスをＨＬＥトランザクションの読み取りセットとして設定し、ｌｏｃｋ−ａｃｑｕｉｒｅ命令によるロックへのあらゆる書き込みを抑止し、ロックを解放するｘｒｅｌｅａｓｅ命令に遭遇するまで又はＨＬＥトランザクションがトランザクション競合に遭遇するまで、ＨＬＥトランザクション実行モードで進行させることと、ＨＬＥ予測器が無効化を行わないと予測することに基づき、ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令を非ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令として扱い、非トランザクション・モードで進行させることとを含む方法を実施するために、処理回路により実行される命令を格納するコンピュータ可読ストレージ媒体を含むことができる。

本開示の別の実施形態において、Ｈａｒｄｗａｒｅ Ｌｏｃｋ Ｅｌｉｓｉｏｎ（ＨＬＥ）環境において、ＨＬＥトランザクションが実際にロックを取得し、非トランザクションに実行すべきかどうかを予測的に決定するためのコンピュータ・システムが提供される。本コンピュータ・システムは、メモリと、メモリと通信するプロセッサとを含むことができ、かつ、ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令に遭遇することに基づき、ＨＬＥ予測器に基づいて、ロックを無効化し、ＨＬＥトランザクションとして進行させるか、又はロックを取得し、非トランザクションとして進行させるかを決定することと、ＨＬＥ予測器が無効化を行うと予測することに基づき、ロックのアドレスをＨＬＥトランザクションの読み取りセットとして設定し、ｌｏｃｋ−ａｃｑｕｉｒｅ命令によるロックへのあらゆる書き込みを抑止し、ロックを解放するｘｒｅｌｅａｓｅ命令に遭遇するまで又はＨＬＥトランザクションがトランザクション競合に遭遇するまで、ＨＬＥトランザクション実行モードで進行させることと、ＨＬＥ予測器が無効化を行わないと予測することに基づき、ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令を非ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令として扱い、非トランザクション・モードで進行させることとを含む方法を実施するように構成される。

開示される本実施形態の特徴及び利点は、添付図面と併せて読まれるべき、例示的な実施形態の以下の詳細な説明から明らかになるであろう。例証は、当業者が詳細な説明と併せて本開示を理解するのを容易にするときに明確にするためのものであるので、図面の種々の特徴は縮尺通りではない。

本開示の実施形態による例示的なマルチコア・トランザクション・メモリ環境を示す。 本開示の実施形態による例示的なマルチコア・トランザクション・メモリ環境を示す。 本開示の実施形態による例示的なＣＰＵの例示的なコンポーネントを示す。 例示的なハードウェア又はソフトウェア実施形態による、ロック無効化とロックの間の選択を用いたデータの適応共有のための方法のフロー図を示す。 ＨＬＥサポートが存在する環境において、ＨＬＥ予測器又はハードウェア・ロック・バーチャライザとも呼ばれる競合予測器が実装されるフロー図を示す。 付加的なハードウェア能力が存在しない例示的な実施形態による、ロック無効化とロックの間の選択を用いたデータの適応共有のための方法のフロー図を示す。 ハードウェア・ロック監視を有する例示的な実施形態による、ロック無効化とロックの間の選択を用いたデータの適応共有のための方法のフロー図を示す。 データの適応共有を行う例示的なフローを示す。 データの適応共有を行う例示的なフローを示す。 図４〜図７の方法の少なくとも１つの例示的な実施形態による、コンピュータ環境のハードウェア及びソフトウェアの概略的なブロック図である。

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

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

ここで図４を参照すると、参照符号４００は、一般に、データの適応共有のための方法をハードウェア又はソフトウェアで実装することができる、例示的な実施形態を示す。

現在の実装においては、ロックに基づいてデータ・アクセスを同期するための２つの手法を従来通りに実施することができる。ロック（locking）又は真のロック（true locking）とも呼ばれるデータ構造のロックにおいて、プログラムは、コードのクリティカル・セクションの間、共有データとも呼ばれるメモリ領域への排他的アクセスが保証されることを望む場合がある。この場合、プログラムは、この時点で共有データが利用可能でない競合するプログラムへのフラグのように働くロックによって、共有データを保護することができる。しかしながら、ロック機構は、共有データへのアクセスを厳格に制御することができる。低競合状態のメモリ領域では、競合するプログラムが不必要に待機することがあり、性能に悪影響を与える。例えば、以下のコード・サンプルにおいて、２つのスレッドは構造の異なる部分を更新しており、並列に実行するとしても、スレッド１が構造ｈａｓｈ＿ｔｂｌ上にロックを保持する間、スレッド２は実行を待つ。

ＨＬＥは、前述のように、従来のロック・コードを使用するように書かれたプログラムが、トランザクション実行を実装するハードウェアを利用する機会を可能にする。しかしながら、高競合状態のメモリ領域においては、競合が発生した場合、プロセッサは、トランザクションをアボートし、悲観的ロック挙動を用いてクリティカル・セクションを再び実行することができる。一実施形態においては、キャッシュラインをまたぐいずれのロックも無効化することができず、ＨＬＥなしに再実行を自動的にトリガする。従って、クリティカル・セクションが常にトランザクションとして失敗することが分かっている場合、トランザクション実行にデフォルト設定し、その後、ロックを用いて成功裏に再開させることは、性能を低下させることがある。

４１０において、プロセッサ、即ちＣＰＵ１１４（図２）が、メモリ領域にアクセスするためにコード・シーケンスを開始すると、ＣＰＵ１１４（図２）は、ハードウェア又はソフトウェアのいずれかで実装され得る競合予測器（即ち、ＨＬＥ予測器又はハードウェア・ロック・バーチャライザ）を呼び出して、ロック無効化が成功する可能性があるかどうか、又は代わりにロックを使用すべきかどうかを予測しようと試みる。後述のように、動作において、競合予測器は、種々のハードウェア及びソフトウェア環境で動作することができる。しかしながら、競合予測器がＨＬＥ環境内の競合予測の実施形態を指す場合には、競合予測器はＨＬＥ予測器と呼ぶこともできる。一実施形態において、成功したトランザクション実行の単純なカウントは、例えば、スレッドごとにハードウェア・レジスタ又はメモリ位置内に保持することができる、又は全てのスレッドについて共有することができる。成功したトランザクション実行のカウントを表す閾値を超えると、４１０において、干渉の可能性が低いため、競合予測器は、トランザクション実行経路、即ちロック無効化が、４５５における非トランザクション実行経路、即ちロックよりも有効であり得ると予測することができる。少なくとも１つの実施形態において、カウンタは、最初により有効な実行経路を好むように初期化され、少なくとも１つの実施形態においては、好ましくは、ロック無効化に基づくトランザクション実行に対応する。別の実施形態においては、ハードウェアで又はプログラム・ストリームに挿入された命令により、ロックの取得及び実行に対する、トランザクション実行の推定される相対コストを計算することができる。計算された相対コストに基づき、競合予測器は、例えば予測される経路は実行するコストが低いこと又は干渉に遭遇する可能性が低いことから、トランザクション経路又は非トランザクション経路がより有効であると予測することができる。別の実施形態においては、コンパイラが挙動ヒントを競合予測器に暗黙的に挿入し、４１０において、４２０におけるトランザクション実行経路、又は４５５におけるロック経路のいずれかを選択することができる。ＣＰＵ１１４（図２）は、４２０においてトランザクションとしてクリティカル・セクションの実行を開始し、４２５においてデータを必要に応じて更新することができる。４３０におけるトランザクションの終了時に、しかし結果をコミットする前に、ＣＰＵ１１４（図２）は、４３５において、トランザクションのアボートをもたらす干渉（即ち、２つ又はそれ以上のコード・シーケンスが同じデータ上で並列に動作すること）が検出されるかどうかを判断することができる。干渉が検出されない場合、４４０において、トランザクションは成功裏に結果をコミットすることができ、その後にそれを他のトランザクションにより使用することができる。しかしながら、４３５においてＣＰＵ１１４（図２）が干渉を検出した場合は、４５５において、実行はロックを用いて再開される。４６０において、クリティカル・セクションは、アクセスされるメモリ領域を保護するロックを明示的に取得しなければならない。しかしながら、ロック・リクエスタは、スピン（spinning）と呼ばれるアクションにおいて、ロックが競合プロセスにより解放されるまで、待機させられる場合がある。最終的に４６０においてロックを取得すると、クリティカル・セクションは処理を続行することができる。４７０において、ロックにより保護されるデータが更新されると、クリティカル・セクションは完了し、４７５においてロックを解放することができる。

図５を参照すると、参照符号５００は、一般に、ＨＬＥサポートが存在する環境において競合予測器（即ち、ハードウェア・ロック・バーチャライザ）が実装されている、例示的な実施形態を示す。上述したように、ＨＬＥは、ＸＡＣＱＵＩＲＥ及びＸＲＥＬＥＡＳＥを含む、Ｉｎｔｅｌ（登録商標）の従来の互換命令セット拡張であり、これは従来のロック・コードを使用するように書かれたプログラムが、コードを実質的に修正する必要なしにトランザクション実行を実装するハードウェアを利用する機会を可能にする。この実施形態においては、ＨＬＥ予測器は、Ｉｎｔｅｌ（登録商標）ＨＬＥの特定の例である。

５０５において、ＣＰＵ１１４（図２）は、Ｉｎｔｅｌ（登録商標）ＸＡＣＱＵＩＲＥプリフィックス命令を実行して、関連したロック取得トランザクションでＨＬＥシーケンスを開始する。一実施形態において、シーケンスは、ＸＡＣＱＵＩＲＥの後にロック取得トランザクションが続くように表すことができる。幾つかの実装では、ＸＡＣＱＵＩＲＥプリフィックスを無視することができる。他の実装では、ＸＡＣＱＵＩＲＥシーケンスを選択的に実施することができる。ＨＬＥ開始シーケンスの開始に続き、５１０において、競合予測器、即ちＨＬＥ予測器が呼び出される。予測に基づき、ロック無効化を行うことができる、又はロックを取得することができる。ロック無効化とロック取得との間の予測を行うと、処理は、図４の４２０〜４７５に説明されたものと実質的に同様に続行することができる。

図６を参照すると、参照符号６００は、一般に、付加的なハードウェア・ファシリティが存在しない例示的な実施形態による、ロック無効化とロックとの間の選択を用いたデータの適応共有のための方法のフロー図を示す。この例示的な実施形態においては、例えば、オペレーティング・システムを通じて又はハードウェアにより、アプリケーション・プログラムのコード・ストリーム内に、競合予測器へのヒントを提供することができる。例えば、一実施形態において、プログラマーが１つ又は複数の命令を明示的に挿入してもよく、又は、コンパイラが挙動のヒントを競合予測器に暗黙的に挿入してもよい。競合予測器は、例えば１秒といったある期間にわたって、成功した予測及び成功しなかった予測、即ち予測ミスの両方の数を追跡するために履歴ベクトル又はカウントを保持することができる。次に、６１０において、競合予測器は、予測ミスのカウントを、時間窓中の失敗の閾値数と比較することができる。予測ミスが時間窓の間の失敗の閾値数を上回ると、競合予測器は、時間窓の残りについて、ロックを用いた実行、即ち非トランザクション・モードにデフォルト設定することができる。時間窓の間、メモリ領域は、例えば複数のトランザクションが競合するデータを同時に更新する際、ワークロード特性に起因して高競合状態になることがある。デフォルトとしてロックを一時的に選択することにより、競合予測器は、失敗したトランザクションを再開しなければならない可能性を回避し、トランザクション・アボートを回避することによりスループットを改善することができる。しかしながら、ひとたび時間窓が期間満了すると、メモリ領域のコンテンションは緩和している可能性があり、競合予測器は、トランザクション実行を再び試みることができる。１つの実施形態において、競合予測器はソフトウェアで実装され、ロックの無効化を実施するか又はロックを実施するかの決定は、ソフトウェア実装のアルゴリズムが、ロック無効化を実装する第１バージョンのコード、又は、ロック取得を実装する第２バージョンのコードに制御を渡すことによって行われる。他の実施形態においては、決定６１０は、干渉の履歴に基づき、ソフトウェアによる特定のエントリの更新の指示に応答して、更新トランザクションのターゲットであるフィールドに関連した予測される干渉又は不干渉を反映して、代替的なテストを用いて実装される。

６５５において、クリティカル・セクションは、アクセスされるメモリ領域を保護するロックを明示的に取得しなければならない。しかしながら、ロック・リクエスタは、スピンと呼ばれるアクションにおいて、競合するプロセスによりロックが解放されるまで、待機せざるを得ないことがある。６６０において最終的にロックを取得すると、クリティカル・セクションは処理を続行することができる。６７０においてロックにより保護されるデータが更新されると、６７５においてクリティカル・セクションが完了し、ロックを解放することができる。６８０において、ＣＰＵ１１４（図２）は、時間窓の期間満了をチェックすることができる。時間窓が期間満了していない場合、次に６８０において、処理は終了する。しかしながら、時間窓が期間満了している場合、次に６８５において、失敗したトランザクション実行及び成功したトランザクション実行のカウントをリセットし、時間窓を有効にリセットし、競合予測器の再訓練を開始することができる。

予測ミスが、時間窓中の失敗の閾値数を上回らない場合、６１０において、競合予測器は、ロック無効化、即ち、ＨＬＥトランザクション、又は、ロック取得ではなくロック・ワードの明示的な読み取りと併せてロック無効化を実装するトランザクションを選択することができる。ＨＬＥトランザクションとして（又は、読み取りセット内のロック・ワードを含むトランザクションを実行することによりロック無効化を行うソフトウェア・トランザクションと併せてロック無効化を実装するトランザクションとして）実行することが選択されると、６１５において、ＣＰＵ１１４（図２）は、成功したトランザクション実行のカウントをインクリメントすることができる。６２０におけるＨＬＥトランザクションは、６２５において必要に応じてデータを更新することができる。６３０におけるトランザクションの終了後、しかし６３５において結果をコミットする前に、ＣＰＵ１１４（図２）は、トランザクションのアボートをもたらす干渉（即ち、２つ又はそれ以上のコード・シーケンスが同じデータ上で並列に動作すること）が検出されるかどうかを判断することができる。干渉が検出されない場合、６４０において、ＨＬＥトランザクション（又はロック無効化を実装する他のトランザクション）は成功裏に結果をコミットすることができ、その後にそれを他のプロセスにより使用することができる。しかしながら、６３５においてＣＰＵ１１４（図２）が干渉を検出した場合、失敗したトランザクションは予測ミスとしてカウントされ、これを用いて競合予測器を訓練し、競合予測器の将来の予測をより正確にすることができるため、６５０において、失敗したトランザクション実行のカウントがインクリメントされる。６５５及び６６０において、ＣＰＵ１１４（図２）はここで、メモリ領域に対するロックを取得し、クリティカル・セクションを非トランザクション的に、即ち、ロックを用いて再開しようと試みることができる。６７０において、ロックにより保護されるデータが最終的に更新されると、クリティカル・セクションの処理は完了し、６７５において、ロックを解放することができる。６８０において、ＣＰＵ１１４（図２）は、時間窓の期間満了をチェックすることができる。時間窓が期間満了していない場合、次に６８０において処理は終了する。しかしながら、時間窓が期間満了している場合、次に６８５において、失敗したトランザクション実行及び成功したトランザクション実行のカウントをリセットすることができ、競合予測器の再訓練を有効に開始する。

ここで図７を参照すると、参照符号７００は、一般に、データの適応共有のための方法が、ロックが実施されたときにハードウェア内に監視ファシリティを含むことができる、例示的な実施形態のフロー図を示す。図７において、ＨＬＥトランザクションの処理、即ち７１０乃至７５０は、図６の実施形態がＨＬＥを処理する方法、即ち６１０乃至６５０と実質的に類似している。しかしながら、図７は、クリティカル・セクションが非トランザクション的に実行される経路について、ハードウェア・ロック監視ファシリティを導入する。この実施形態においては、ハードウェア・ロック監視ファシリティは、クリティカル・セクションが、ロックされたメモリ領域内での実行を可能にする間、クリティカル・セクションが実際にＨＬＥトランザクションとして実行されたかのように結果を予測することによって、予測ミスを最小にしようと試みる。７６０及び７６５において成功裏にロックを取得すると、７７０において、ハードウェア・ロック監視ファシリティは、ロックの状態の監視を開始することができる。７７５において、クリティカル・セクションは、ロックされたメモリ領域内のデータを更新し、７８０において、ロックを解放することにより実行を終了する。しかしながら、実行中、７８５においてハードウェア・ロック監視ファシリティが、別のプロセスがロック・フラグのステータスをチェックし、次いでこのクリティカル・セクションが非トランザクション的ではなくトランザクションとして実行されていたことを検出した場合、他のプロセスにより試行されたアクセスは、干渉及びトランザクションの失敗をもたらした。一実施形態においては、ロックのみが監視される。別の実施形態においては、ロックされた領域の一部として更新されたデータが監視される。結果として、７９０において、ハードウェア・ロック監視ファシリティは、失敗したトランザクション実行のカウントをインクリメントすることができる。

別の実施形態において、ハードウェア・ロック監視ファシリティは、ロックされたメモリ領域内の全てのデータ・アクセスの試行を監視することができる。別のプロセスがこの領域内のデータにアクセスしようと試みた場合、次に７９０において、ハードウェア・ロック監視ファシリティは、これを干渉及び潜在的なトランザクション失敗としてカウントすることができる。従って、競合予測器は、トランザクション実行又は非トランザクション実行のどちらが成功する可能性が高いかについて、より正確に予測するよう学習することができる。

別の実施形態において、７５０において、トランザクション実行失敗のカウントがインクリメントされると、再開（restart）フラグを設定することができる。次に７５５において、成功したトランザクション実行のカウントがインクリメントされたとき、再開フラグをリセットすることができる。再開フラグは、失敗したトランザクション実行のカウントが２回、即ち、７５０におけるＨＬＥトランザクションのような失敗時に１回、及び７５５におけるロックを用いた再開時に１回、インクリメントされることを防止することにより、予測精度を改善することができる。

ここで図８を参照すると、１つの実施形態において、Ｈａｒｄｗａｒｅ Ｌｏｃｋ Ｅｌｉｓｉｏｎ（ＨＬＥ）環境において、ＨＬＥトランザクションが実際にロックを取得し、非トランザクション的に実行すべきかどうかを予測的に決定すること８１０は、ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令に遭遇することに基づき、ＨＬＥ予測器に基づいて、ロックを無効化し、ＨＬＥトランザクションとして進行させるか、又はロックを取得して非トランザクションとして進行させるかを決定すること８２０と、ＨＬＥ予測器が無効化を行うと予測することに基づき、ロックのアドレスを、ＨＬＥトランザクションの読み取りセットとして設定し、ｌｏｃｋ−ａｃｑｕｉｒｅ命令によるロックへのあらゆる書き込みを抑止し、ロックを解放するｘｒｅｌｅａｓｅ命令に遭遇するまで、又はＨＬＥトランザクションがトランザクション競合に遭遇するまで、ＨＬＥトランザクション実行モードで進行させること８３０と、ＨＬＥ予測器が無効化を行わないと予測することに基づき、ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令を非ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令として扱い、非トランザクション・モードで進行させること８４０と、を含む。

ここで図９を参照すると、１つの実施形態において、ＨＬＥ予測器を更新することは、ＨＬＥの予測の成功に基づく９１０。ロック・アドレスを有するＨＬＥトランザクションに初めて遭遇したことに基づき、ロック・アドレスと関連付けられた成功したＨＬＥトランザクション実行のカウントはゼロに初期化され、ロック・アドレスを有するいずれかの後のＨＬＥトランザクションを完了することに基づき、ＨＬＥ予測器において、ＨＬＥトランザクションのロック・アドレスと関連した失敗したＨＬＥトランザクション実行のカウントをインクリメントし、ここで、高いカウントはアボートの可能性が高いことを示す９２０。非トランザクション・モードにおいて、別のプロセスによるロックへのアクセスの試行を監視し、他のプロセスによるアクセスの試行が検出された際、失敗したＨＬＥトランザクションのカウントをインクリメントする９５０。時間窓内の成功したＨＬＥトランザクション実行のカウント及び失敗したＨＬＥトランザクション実行のカウントを追跡し、失敗したＨＬＥトランザクション実行のカウントが失敗の閾値数を上回ることに基づき、時間窓の残りについて非トランザクション・モードにデフォルト設定する９７０。時間窓の期間満了に基づき、成功したＨＬＥトランザクション実行のカウント及び失敗したＨＬＥトランザクション実行のカウントは、ゼロにリセットされる９６０。

ここで図１０を参照すると、コンピューティング・デバイス１０００は、内部コンポーネント８００及び外部コンポーネント９００のそれぞれのセットを含むことができる。内部コンポーネント８００のセットの各々は、１つ又は複数のバス８２６上の１つ又は複数のプロセッサ８２０、１つ又は複数のコンピュータ可読ＲＡＭ８２２、及び１つ又は複数のコンピュータ可読ＲＯＭ；１つ又は複数のオペレーティング・システム８２８；図５〜図７の方法を実行する１つ又は複数のソフトウェア・アプリケーション；及び１つ又は複数のコンピュータ可読有形ストレージ・デバイス８３０を含む。１つ又は複数のオペレーティング・システムは、それぞれのＲＡＭ８２２（一般的には、キャッシュ・メモリを含む）の１つ又は複数を介して、それぞれのプロセッサ８２０の１つ又は複数による実行のために、それぞれのコンピュータ可読有形ストレージ・デバイス８３０の１つ又は複数に格納される。図１０に示される実施形態において、コンピュータ可読有形ストレージ・デバイス８３０の各々は、内蔵ハード・ドライブの磁気ディスク・ストレージ・デバイスである。代替的に、コンピュータ可読有形ストレージ・デバイス８３０の各々は、ＲＯＭ８２４、ＥＰＲＯＭ、フラッシュ・メモリなどの半導体ストレージ・デバイス、又はコンピュータ・プログラム及びデジタル情報を格納することができるいずれかの他のコンピュータ可読有形ストレージ・デバイスである。

内部コンポーネント８００の各セットはまた、シン・プロビジョニング・ストレージ・デバイス、ＣＤ−ＲＯＭ、ＤＶＤ、ＳＳＤ、メモリ・スティック、磁気テープ、磁気ディスク、光ディスク、又は半導体ストレージ・デバイスといった、１つ又は複数のコンピュータ可読有形ストレージ・デバイス９３６との間で読み書きを行うためのＲ／Ｗドライブ又はインターフェース８３２も含む。Ｒ／Ｗドライブ又はインターフェース８３２は、コンピューティング・デバイス１０００のコンポーネントとの通信を容易にするために、デバイス・ドライバ８４０ファームウェア、ソフトウェア、又はマイクロコードを有形ストレージ・デバイス９３６にロードするために使用することができる。

内部コンポーネント８００の各セットはまた、ＴＣＰ／ＩＰアダプタ・カード、無線ＷＩ−ＦＩインターフェース・カード、又は３Ｇ若しくは４Ｇ無線インターフェース・カード、又は他の有線若しくは無線通信リンクといったネットワーク・アダプタ（又はスイッチ・ポート・カード）又はインターフェース８３６も含む。コンピューティング・デバイス１０００と関連付けられたオペレーティング・システム８２８は、ネットワーク（例えば、インターネット、ローカル・エリア・ネットワーク、又は広域ネットワーク）及びそれぞれのネットワーク・アダプタ又はインターフェース８３６を介して、外部コンピュータ（例えば、サーバ）からコンピューティング・デバイス１０００にダウンロードすることができる。ネットワーク・アダプタ（又はスイッチ・ポート・アダプタ）又はインターフェース８３６から、コンピューティング・デバイス１０００と関連付けられたオペレーティング・システム８２８が、それぞれのハード・ドライブ８３０及びネットワーク・アダプタ８３６内にロードされる。ネットワークは、銅線、光ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、及び／又はエッジ・サーバを含むことができる。

外部コンポーネント９００のセットの各々は、コンピュータ・ディスプレイ・モニタ９２０、キーボード９３０、及びコンピュータ・マウス９３４を含むことができる。外部コンポーネント９００はまた、タッチスクリーン、仮想キーボード、タッチパッド、ポインティング・デバイス、及び他のヒューマン・インターフェース・デバイスを含むこともできる。内部コンポーネント８００のセットの各々はまた、コンピュータ・ディスプレイ・モニタ９２０、キーボード９３０、及びコンピュータ・マウス９３４にインターフェース接続するためのデバイス・ドライバ８４０を含むこともできる。デバイス・ドライバ８４０、Ｒ／Ｗドライブ又はインターフェース８３２、及びネットワーク・アダプタ又はインターフェース８３６は、ハードウェア及びソフトウェア（ストレージ・デバイス８３０及び／又はＲＯＭ８２４内に格納される）を含む。

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

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

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

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

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

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

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

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

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

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

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

１００：ダイ
１１４ａ、１１４ｂ：ＣＰＵ
１１６ａ、１１６ｂ：命令キャッシュ
１１８ａ、１１８ｂ：データ・キャッシュ
１２０ａ、１２０ｂ：相互接続制御
１２２：相互接続
１２４：共有キャッシュ
１２６：レジスタ・チェックポイント
１２８：特殊ＴＭレジスタ
１３０：ＭＥＳＩビット
１３２：Ｒビット
１３８：Ｗビット
１４０：タグ
１４２：データ
２０４：命令フェッチ・ユニット
２０８：命令デコード・ユニット（ＩＤＵ）
２１２：トランザクション・ネスト化深さ（ＴＮＤ）
２１６：発行キュー
２２０：固定小数点数ユニット（ＦＸＵ）
２２４：バックアップ・レジスタ・ファイル
２２８：汎用レジスタ（ＧＲ）
２３２：グローバル完了テーブル（ＧＣＴ）
２３２ａ：トランザクション・ネスト化深さ（ＴＮＤ）
２３２ｂ：ｍｉｃｒｏ−ｏｐ（Ｕｏｐ）
２３６：アドレス計算器
２４０：Ｌ１データ・キャッシュ
２４４：有効ビット
２４８：ＴＸ−読み取りビット
２５２：ＴＸ−ダーティビット
２５６：Ｌ１ディレクトリ
２６０：ストア・キュー（ＳＴＱ）
２６４：収集ストア・キャッシュ
２６８：Ｌ２データ・キャッシュ
２８０：ロード／ストア・ユニット（ＬＳＵ）
８００：内部コンポーネント
８２０：プロセッサ
８２２：コンピュータ可読ＲＡＭ
８２４：コンピュータ可読ＲＯＭ
８２６：バス
８２８：オペレーティング・システム
８３０、９３６：コンピュータ可読有形ストレージ・デバイス
８３２：Ｒ／Ｗドライブ又はインターフェース
８３６：ネットワーク・アダプタ又はインターフェース
８４０：デバイス・ドライバ
９００：外部コンポーネント
９２０：コンピュータ・ディスプレイ・モニタ
９３０：キーボード
９３４：コンピュータ・マウス
１０００：コンピューティング・デバイス

Claims (20)

1. Ｈａｒｄｗａｒｅ Ｌｏｃｋ Ｅｌｉｓｉｏｎ（ＨＬＥ）環境において、ＨＬＥトランザクションが実際にロックを取得し、非トランザクション的に実行すべきかどうかを予測的に判断するための方法であって、
   ＨＬＥトランザクション実行のためのＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令に遭遇することに基づき、ＨＬＥ予測器に基づいて、前記ロックを無効化し、ＨＬＥトランザクションとして進行させるか、又は前記ロックを取得して非トランザクションとして進行させるかを決定することと、
   ＨＬＥ予測器が無効化を行うと予測することに基づき、前記ロックのアドレスを前記ＨＬＥトランザクションの読み取りセットとして設定し、前記ｌｏｃｋ−ａｃｑｕｉｒｅ命令による前記ロックへのあらゆる書き込みを抑止し、前記ロックを解放するｘｒｅｌｅａｓｅ命令に遭遇するまで又は前記ＨＬＥトランザクションがトランザクション競合に遭遇するまで、ＨＬＥトランザクション実行モードで進行させることと、
   ＨＬＥ予測器が無効化を行わないと予測することに基づき、前記ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令を非ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令として扱い、非トランザクション・モードで進行させることと、
   を含み、前記ＨＬＥ予測器は、前記ロックに関する以前の前記無効化を行わないとした予測の成否を考慮して、前記無効化を行うか前記無効化を行わないかの予測を行う、方法。
2. 前記ＨＬＥトランザクションの予測の成功に基づき、前記ＨＬＥ予測器を更新することであって、前記ＨＬＥ予測器は、ＨＬＥトランザクションがアボートする可能性が高いかどうかを予測する、更新することをさらに含む、請求項１に記載の方法。
3. 前記ロックのアドレスを有するＨＬＥトランザクションに初めて遭遇することに基づき、前記ロックのアドレスと関連付けられた成功したＨＬＥトランザクション実行のカウントをゼロに初期化することと、
   前記ロックのアドレスを有するあらゆる後のＨＬＥトランザクションをアボートすることに基づき、前記ＨＬＥ予測器内の前記ＨＬＥトランザクションの前記ロックのアドレスと関連付けられた失敗したＨＬＥトランザクション実行のカウントをインクリメントすることであって、失敗したＨＬＥトランザクション実行のカウントが高いことはアボートの可能性が高いことを示す、前記インクリメントすることと、
   前記ロックのアドレスを有するあらゆる後のＨＬＥトランザクションを完了することに基づき、前記ＨＬＥ予測器内の前記ＨＬＥトランザクションの前記ロックのアドレスと関連付けられた成功したＨＬＥトランザクション実行の前記カウントをインクリメントすることと、
   をさらに含み、前記無効化を行うか前記無効化を行わないかの予測は、前記成功したＨＬＥトランザクション実行のカウントおよび前記失敗したＨＬＥトランザクション実行のカウントを考慮して行われる、請求項１又は２に記載の方法。
4. 別のプロセスによる前記ロックへのアクセスの試行を非トランザクション・モードで監視することと、
   前記別のプロセスによる前記アクセスの試行を検出したとき、前記失敗したＨＬＥトランザクション実行の前記カウントをインクリメントすることと、
   をさらに含む、請求項３に記載の方法。
5. 時間窓内の前記成功したＨＬＥトランザクション実行のカウント及び前記失敗したＨＬＥトランザクション実行のカウントを追跡することと、
   前記失敗したＨＬＥトランザクション実行のカウントを、前記時間窓の間の失敗の閾値数と比較することと、
   前記失敗したＨＬＥトランザクション実行のカウントが前記失敗の閾値数を上回ることに基づき、前記時間窓の残りについて非トランザクション・モードにデフォルト設定することと、
   をさらに含む、請求項３又は４に記載の方法。
6. 前記時間窓の期間満了に基づき、前記成功したＨＬＥトランザクション実行のカウント及び前記失敗したＨＬＥトランザクション実行のカウントをゼロにリセットすることをさらに含む、請求項５に記載の方法。
7. Ｈａｒｄｗａｒｅ Ｌｏｃｋ Ｅｌｉｓｉｏｎ（ＨＬＥ）環境において、ＨＬＥトランザクションが実際にロックを取得し、非トランザクション的に実行すべきかどうかを予測的に決定するためのコンピュータ・プログラムであって、前記コンピュータ・プログラムは、コンピュータに、
   ＨＬＥトランザクション実行のためのＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令に遭遇することに基づき、ＨＬＥ予測器に基づいて、前記ロックを無効化し、ＨＬＥトランザクションとして進行させるか、又は前記ロックを取得して非トランザクションとして進行させるかを決定することと、
   ＨＬＥ予測器が無効化を行うと予測することに基づき、前記ロックのアドレスを前記ＨＬＥトランザクションの読み取りセットとして設定し、前記ｌｏｃｋ−ａｃｑｕｉｒｅ命令による前記ロックへのあらゆる書き込みを抑止し、前記ロックを解放するｘｒｅｌｅａｓｅ命令に遭遇するまで又は前記ＨＬＥトランザクションがトランザクション競合に遭遇するまで、ＨＬＥトランザクション実行モードで進行させることと、
   ＨＬＥ予測器が無効化を行わないと予測することに基づき、前記ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令を非ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令として扱い、非トランザクション・モードで進行させることと、
   を実行させるためのものであり、前記ＨＬＥ予測器は、前記ロックに関する以前の前記無効化を行わないとした予測の成否を考慮して、前記無効化を行うか前記無効化を行わないかの予測を行う、コンピュータ・プログラム。
8. 前記ＨＬＥトランザクションの予測の成功に基づき、前記ＨＬＥ予測器を更新することであって、前記ＨＬＥ予測器は、ＨＬＥトランザクションがアボートする可能性が高いかどうかを予測する、更新することをさらに実行させるための、請求項７に記載のコンピュータ・プログラム。
9. 別のプロセスによる前記ロックへのアクセスの試行を非トランザクション・モードで監視することと、
   前記別のプロセスによる前記アクセスの試行を検出したとき、前記ロックのアドレスと関連付けられた失敗したＨＬＥトランザクション実行のカウントをインクリメントすることと、
   をさらに実行させるための、請求項７又は８に記載のコンピュータ・プログラム。
10. 別のプロセスによる、前記ロックにより保護されるメモリ領域へのアクセスの試行を非トランザクション・モードで監視することと、
    前記別のプロセスによる前記アクセスの試行を検出したとき、前記ロックのアドレスと関連付けられた失敗したＨＬＥトランザクション実行のカウントをインクリメントすることと、
    をさらに実行させるための、請求項７ないし９のいずれかに記載のコンピュータ・プログラム。
11. 前記ロックのアドレスを有するＨＬＥトランザクションに初めて遭遇することに基づき、前記ロックのアドレスと関連付けられた成功したＨＬＥトランザクション実行のカウントをゼロに初期化することと、
    前記ロックのアドレスを有するあらゆる後のＨＬＥトランザクションをアボートすることに基づき、前記予測器内の前記ＨＬＥトランザクションの前記ロックのアドレスと関連付けられた失敗したＨＬＥトランザクション実行のカウントをインクリメントすることであって、失敗したＨＬＥトランザクション実行のカウントが高いことはアボートの可能性が高いことを示す、前記インクリメントすることと、
    前記ロックのアドレスを有するあらゆる後のＨＬＥトランザクションを完了することに基づき、前記ＨＬＥ予測器内の前記ＨＬＥトランザクションの前記ロックのアドレスと関連付けられた成功したＨＬＥトランザクション実行の前記カウントをインクリメントすることと、
    をさらに実行させるためのものであり、前記無効化を行うか前記無効化を行わないかの予測は、前記成功したＨＬＥトランザクション実行のカウントおよび前記失敗したＨＬＥトランザクション実行のカウントを考慮して行われる、請求項７ないし１０のいずれかに記載のコンピュータ・プログラム。
12. 時間窓内の前記成功したＨＬＥトランザクション実行のカウント及び前記失敗したＨＬＥトランザクション実行のカウントを追跡することと、
    前記失敗したＨＬＥトランザクション実行のカウントを、前記時間窓の間の失敗の閾値数と比較することと、
    前記失敗したＨＬＥトランザクション実行のカウントが前記失敗の閾値数を上回ることに基づき、前記時間窓の残りについて非トランザクション・モードにデフォルト設定することと、
    をさらに実行させるための、請求項１１に記載のコンピュータ・プログラム。
13. 前記時間窓の期間満了に基づき、前記成功したＨＬＥトランザクション実行のカウント及び前記失敗したＨＬＥトランザクション実行のカウントをゼロにリセットすることをさらに実行させるための、請求項１２に記載のコンピュータ・プログラム。
14. Ｈａｒｄｗａｒｅ Ｌｏｃｋ Ｅｌｉｓｉｏｎ（ＨＬＥ）環境において、ＨＬＥトランザクションが実際にロックを取得し、非トランザクション的に実行すべきかどうかを予測的に決定するためのコンピュータ・システムであって、前記コンピュータ・システムは、
    メモリと、
    前記メモリと通信するプロセッサと、を含み、かつ、
    ＨＬＥトランザクション実行のためのＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令に遭遇することに基づき、ＨＬＥ予測器に基づいて、前記ロックを無効化し、ＨＬＥトランザクションとして進行させるか、又は前記ロックを取得して非トランザクションとして進行させるかを決定することと、
    ＨＬＥ予測器が無効化を行うと予測することに基づき、前記ロックのアドレスを前記ＨＬＥトランザクションの読み取りセットとして設定し、前記ｌｏｃｋ−ａｃｑｕｉｒｅ命令による前記ロックへのあらゆる書き込みを抑止し、前記ロックを解放するｘｒｅｌｅａｓｅ命令に遭遇するまで又は前記ＨＬＥトランザクションがトランザクション競合に遭遇するまで、ＨＬＥトランザクション実行モードで進行させることと、
    ＨＬＥ予測器が無効化を行わないと予測することに基づき、前記ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令を非ＨＬＥ ｌｏｃｋ−ａｃｑｕｉｒｅ命令として扱い、非トランザクション・モードで進行させることと、
    を含む方法を実施するように構成され、前記ＨＬＥ予測器は、前記ロックに関する以前の前記無効化を行わないとした予測の成否を考慮して、前記無効化を行うか前記無効化を行わないかの予測を行う、コンピュータ・システム。
15. 前記コンピュータ・システムが実施する前記方法は、
    前記ＨＬＥトランザクションの予測の成功に基づき、前記ＨＬＥ予測器を更新することであって、前記ＨＬＥ予測器は、ＨＬＥトランザクションがアボートする可能性が高いかどうかを予測する、更新することをさらに含む、請求項１４に記載のコンピュータ・システム。
16. 前記コンピュータ・システムが実施する前記方法は、
    別のプロセスによる前記ロックへのアクセスの試行を非トランザクション・モードで監視することと、
    前記別のプロセスによる前記アクセスの試行を検出したとき、前記ロックのアドレスと関連付けられた失敗したＨＬＥトランザクション実行のカウントをインクリメントすることと、
    をさらに含む、請求項１４又は１５に記載のコンピュータ・システム。
17. 前記コンピュータ・システムが実施する前記方法は、
    別のプロセスによる、前記ロックにより保護されるメモリ領域へのアクセスの試行を非トランザクション・モードで監視することと、
    前記別のプロセスによる前記アクセスの試行を検出したとき、前記ロックのアドレスと関連付けられた失敗したＨＬＥトランザクション実行のカウントをインクリメントすることと、
    をさらに含む、請求項１４ないし１６のいずれかに記載のコンピュータ・システム。
18. 前記コンピュータ・システムが実施する前記方法は、
    前記ロックのアドレスを有するＨＬＥトランザクションに初めて遭遇することに基づき、前記ロックのアドレスと関連付けられた成功したＨＬＥトランザクション実行のカウントをゼロに初期化することと、
    前記ロックのアドレスを有するあらゆる後のＨＬＥトランザクションをアボートすることに基づき、前記予測器内の前記ＨＬＥトランザクションの前記ロックのアドレスと関連付けられた失敗したＨＬＥトランザクション実行のカウントをインクリメントすることであって、失敗したＨＬＥトランザクション実行のカウントが高いことはアボートの可能性が高いことを示す、前記インクリメントすることと、
    前記ロックのアドレスを有するあらゆる後のＨＬＥトランザクションを完了することに基づき、前記ＨＬＥ予測器内の前記ＨＬＥトランザクションの前記ロックのアドレスと関連付けられた成功したＨＬＥトランザクション実行の前記カウントをインクリメントすることと、
    をさらに含み、前記無効化を行うか前記無効化を行わないかの予測は、前記成功したＨＬＥトランザクション実行のカウントおよび前記失敗したＨＬＥトランザクション実行のカウントを考慮して行われる、請求項１４ないし１７のいずれかに記載のコンピュータ・システム。
19. 前記コンピュータ・システムが実施する前記方法は、
    時間窓内の前記成功したＨＬＥトランザクション実行のカウント及び前記失敗したＨＬＥトランザクション実行のカウントを追跡することと、
    前記失敗したＨＬＥトランザクション実行のカウントを、前記時間窓の間の失敗の閾値数と比較することと、
    前記失敗したＨＬＥトランザクション実行のカウントが前記失敗の閾値数を上回ることに基づき、前記時間窓の残りについて非トランザクション・モードにデフォルト設定することと、
    をさらに含む、請求項１８に記載のコンピュータ・システム。
20. 前記コンピュータ・システムが実施する前記方法は、
    前記時間窓の期間満了に基づき、前記成功したＨＬＥトランザクション実行のカウント及び前記失敗したＨＬＥトランザクション実行のカウントをゼロにリセットすることをさらに含む、請求項１９に記載のコンピュータ・システム。

Images