(57)【特許請求の範囲】
【請求項１】
複数のトランザクションモードを有する無限トランザクショナルメモリ（UTM）システムにおいて第一のトランザクションを開始するため第一のトランザクション実行モードを選択するステップと、前記トランザクション実行モードは、プロセッサのキャッシュメモリ内で実行する複数のハードウェアモードと、前記プロセッサとソフトウェアバッファとのトランザクショナルハードウェアを使用して実行する少なくとも１つのハードウェア支援モードと、前記トランザクショナルハードウェアなしに実行する少なくとも１つのソフトウェアトランザクショナルメモリ（STM）モードとを含み、前記第一のトランザクション実行モードは、保留のトランザクションが前記少なくとも１つのSTMモードで実行していない場合に前記複数のハードウェアモードのうちの最も効率の高いモードとなるように選択され、さもなければ前記第一のトランザクショナル実行モードは、前記複数のハードウェアモードのうちの効率の低いモードとなるように選択され、
前記第一のトランザクション実行モードにおいて前記第一のトランザクションの実行を開始するステップと、
前記第一のトランザクションが終了し、前記キャッシュメモリをオーバフローしていないか又はトランザクションセマンティックに違反していない場合、前記第一のトランザクションをコミットするステップと、
前記第一のトランザクションをアボートし、新たなトランザクション実行モードを選択して前記第一のトランザクションを実行するステップと、
を含むことを特徴とする方法。
【請求項２】
前記最も効率が高いモードは、ロッキング又はバージョン管理処理が行われない暗黙的なモードである、
請求項１記載の方法。
【請求項３】
前記効率の低いモードは、ロッキング処理が行われる明示的なモードである、
請求項２記載の方法。
【請求項４】
前記第一のトランザクションが前記キャッシュメモリをオーバフローさせた場合に、前記少なくとも１つのハードウェア支援モードのうちの１つとなるように前記新たなトランザクション実行モードを選択するステップを更に含む、
請求項１記載の方法。
【請求項５】
前記最も効率が高いモードにおいて前記第一のトランザクションの実行の間に、第二のトランザクションが前記少なくとも１つのSTMモードで開始したかを判定するステップと、前記第一のトランザクションをロールバックして、前記効率の低いモードにおいて前記複数のハードウェアモードのうちの１つを再実行するステップを更に含む、
請求項１記載の方法。
【請求項６】
前記第一のトランザクションのハードウェア特性の損失が生じた場合に、前記第一のトランザクション実行モードにおける前記第一のトランザクションをアボートするステップを更に含む、
請求項１記載の方法。
【請求項７】
ハードウェアトランザクション実行モードを使用した第一のトランザクションと、ソフトウェアトランザクション実行モードを使用した第二のトランザクションとを同時に実行するステップと、
前記第二のトランザクションにおいて、前記第二のトランザクションにおいて使用されるグローバルバージョンカウンタに対応する前記第二のトランザクションの読取り値をインクリメントすることで、前記読取り値が、前記第一のトランザクションにおいて使用されるハードウェアグローバルバージョンカウンタを超えるかを判定し、超えると判定した場合、適応的なバッチサイズだけ前記ハードウェアグローバルバージョンカウンタをアップデートするステップと、
を含むことを特徴とする方法。
【請求項８】
前記第一のトランザクションにおける前記ハードウェアグローバルバージョンカウンタに対応するスタンプ値をモニタし、前記ハードウェアグローバルバージョンカウンタの値が変化する場合に前記第一のトランザクションをアボートするステップを更に含み、前記ハードウェアグローバルバージョンカウンタの変化は、前記モニタリングにより検出される、
請求項７記載の方法。
【請求項９】
書き込みログを維持することなしに前記第一のトランザクションを実行するステップを更に含む、
請求項７記載の方法。
【請求項１０】
前記ハードウェアグローバルバージョンカウンタは、前記グローバルバージョンカウンタよりも大きい、
請求項７記載の方法。
【請求項１１】
前記第一のトランザクションと前記第二のトランザクションとの間の競合に応じて、前記適応的なバッチサイズを低減するステップを更に含む、
請求項１０記載の方法。
【請求項１２】
前記適応的なバッチサイズにより前記ハードウェアグローバルバージョンカウンタをインクリメントすることに応じて、前記適応的なバッチサイズを調節するステップを更に含む、
請求項１１記載の方法。
【請求項１３】
前記適応的なバッチサイズは、第一の量だけ増加され、前記適応的なバッチサイズは、第二の量だけ減少され、前記第二の量は前記第一の量よりも大きい、
請求項１２記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無限トランザクショナルメモリ（UTM：Unbounded  Transactional  Memory）システムにおけるモード切り替えの実行に関する。
【背景技術】
【０００２】
現代のコンピューティングシステムでは、複数のプロセッサが存在することができ、それぞれの係るプロセッサは、共通のアプリケーションの異なるコードのスレッドを実行する場合がある。一貫性を維持するため、データ同期メカニズムが使用される場合がある。１つの係る技術は、トランザクショナルメモリ（TM：Transactional  Memory）の使用を含む。トランザクションの実行（transactional  execution）は、複数のマイクロ処理、処理又は命令のグループ化を含むことがある。複数のスレッドのそれぞれは、メモリ構造内の共通データを実行及びアクセスする。両方のスレッドがこの構造内の同じエントリにアクセス／変更する場合、データの有効性を保証するために競合の解決が実行される。トランザクションの実行の１つのタイプは、ソフトウェアトランザクショナルメモリ（STM：Software  Transactional  Memory）を含み、この場合、メモリアクセスの追跡、競合の解決、アボートタスク及び他のトランザクショナルタスクは、一般にハードウェアのサポートなしにソフトウェアで実行される。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
トランザクションの実行の別のタイプは、ハードウェアトランザクショナルメモリ（HTM：Hardware  Transactional  Memory）システムを含み、この場合、アクセストラッキング、競合の解決、及び他のトランザクショナルタスクをサポートするためにハードウェアが含まれる。以前は、現実のメモリデータアレイは、読出し、書込み及びバッファリングを追跡するためにハードウェア属性のような情報を保持するための更なるビットで拡張され、結果として、データは、プロセッサからメモリへのデータと共に移動する。この情報は、持続性（persistent）であると呼ばれ、すなわちキャッシュ立ち退き（cache  eviction）に応じて失われない。これは、情報が記憶階層を通してデータと共に移動するためである。さらに、この持続性は、記憶階層システムを通して多くのオーバヘッドを課す。
【０００４】
更に別のタイプのTMモデルは、無限トランザクショナルメモリ（UTM）と呼ばれ、このUTMは、時間的且つメモリフットプリントにおいて任意の大きなトランザクションが、ハードウェア及びソフトウェアを使用したハードウェアアクセラレーション（hardware  acceleration）の組み合わせを通して行われるのを可能にする。UTMトランザクションを実行及び実現することは、UTMハードウェアアクセラレーションインタフェースによる同時処理制御メカニズムを実現するための特別のコンパイルされたコードを一般に必要とする。結果として、UTMトランザクションは複雑になる可能性があり、既存のハードウェア及びSTMトランザクショナルシステムと正しく相互作用しない場合がある。
【特許文献１】US  2009-0172306  A1
【特許文献２】US  2009-0006767  A1
【特許文献３】US  2008-0162886  A1
【特許文献４】US  2007-0143741  A1
【課題を解決するための手段】
【０００５】
様々な実施の形態では、TM実現は、異なるモードにおける異なるスレッドトランザクションを実行し、ソフトウェアの競合の管理、又は（ネスト化されたトランザクション、リトライ、デバッグ、又は外部のトランザクションのような）サポートされない動作又は処理の使用を含めて、様々な理由のためにモードを切り替えることができる。本発明の実施の形態に係るUTMシステムは、異なるパフォーマンス、フレキシビリティ（セマンティックリッチネス（semantic  richness））及びキャパシティの配慮により、より大きな実行モードのデザインスペースを提供する。モードは、一般に、トランザクショナル、コード生成、プロセッサ及び共通言語ランタイム（CLR：Common  Language  Runtime）モードの組み合わせである。これは大きなスペースを構築する一方、議論に最も関連する特定のモードが導入される。
【０００６】
トランザクショナルメモリコード（transactional  memory  code）は、様々なトランザクショナルモードにおいて実行される。異なるトランザクショナルモードは、異なるコード生成ストラテジを必要とするか、又は異なるコード生成ストラテジからの利益を受ける。トランザクションの実行モードは、以下を含む。ノントランザクショナル（NT）は、分離（isolation）又は故障の原子性（failure  atomicity）をもたない古典的な実行モードであり、トランザクションロギング（transaction  logging）又はトランザクションロッキング（transaction  locking）を必要としない。キャッシュ常駐・非ロッキング（CRNL：Cache  Resident  Non-locking）モードは、キャッシュ常駐・暗黙的なトランザクショナルモード（CRITM：Cache  Resident  Implicit  Transactional  Mode）とも呼ばれ、全体のトランザクションの読出し／書込みのセットは、キャッシュメモリで維持され、トランザクションの競合は、ハードウェアで検出される。このモードでは、ロギング又は他のインスツルメンテーション（instrumentation）が必要とされず、ソフトウェアコンパチブルのロック（software-compatible  locks）が取得されない。CRNLは、１実施の形態では、そのデータセットがプロセッサキャッシュにおいて完全に適合する比較的小さなトランザクションのみをサポートする。別のモードは、キャッシュ常駐（CR：Cache  Resident）モード（又はキャッシュ常駐・明示的なトランザクションモード（CRESTM：Cache  Resident,  Explicit  Transaction  Mode）とも呼ばれる）であり、この場合、全体のトランザクションの読出し／書込みのセットは、キャッシュに記憶され、トランザクションの競合は、ハードウェアで検出される。ロギング又は他のインスツルメンテーションがこのモードでは必要とされないが、ソフトウェアコンパチブルのロックが取得される。先のCRNLモードのようなCRは、様々な実施の形態では、そのデータセットがプロセッサキャッシュで完全に適合する比較的小さなトランザクションのみをサポートする。
【０００７】
更に別のモードは、ハードウェア支援モニタリング及びフィルタリング（HAMF：Hardware-Assisted  Monitoring  and  Filtering）によるソフトウェアモードであり、このHAMFは、フィルタリングと同様に、トランザクションの競合を検出するUTMモニタリング機能を使用するソフトウェアモードである。このモードでは、ソフトウェアコンパチブルなロックが取得される。別のモードは、ハードウェア支援フィルタリング（HAF）をもつソフトウェアモードであり、フィルタリングのためにのみUTM機能が使用される。このモードにおいてソフトウェアロギングが実行され、ソフトウェアコンパチブルなロックが取得される。一般に、これら少なくとも２つのモードは、ハードウェア支援STM（HASTM）モードと呼ぶことができる。最後に、ソフトウェアトランザクションメモリ（STM）モードは、UTMリソースを使用しない純粋なソフトウェアモードである。
【０００８】
異なるトランザクションモードをサポートするため、ソースコードの特定のチャンクは、異なるトランザクションモードに変換される。NK（Naked）は、特定のトランザクションのインスツルメンテーションをもたない古典的なコードを示す。TV（Transaction  VTable）は、適切なトランザクションロギング及びロッキングを可能にするため、個々のオブジェクトフィールドのアクセスのために間接的なファンクションコールを埋め込むコード生成モードである。ディスパッチテーブル（vtable）は、この生成されたコードが様々なトランザクションモードをサポートするために使用されるのを可能にするため、異なるファンクションをディスパッチするために使用される。
【０００９】
つぎに、プロセッサは、トランザクションに関連するモニタリング及びバッファリングのUTM特性に関して、３つの基本モードのうちの１つにおいて実行する。第一のモードであるMB_ALLが選択され、このモードでは、全てのロード（load）及びストア（store）はハードウェアのモニタリング及びバッファリングを誘導する。これは、UTM機能を使用するための一般に最も簡単なやり方であるが、（リードオンリ状態又はスタックのような）モニタリング及びバッファリングを必要としないメモリの範囲に適用されるモニタリング及びバッファリングに繋がる場合がある。第二のモードであるMB_DATAが選択され、このモードでは、ハードウェアトランザクションがセグメントレジスタに対して相対的にメモリアクセスを行う全てのロード及びストアは、デフォルトでバッファリング／モニタリングされる。このモードでは、全てのスタックのアクセスは、PUMOV（Potentially  Unmonitored  Move）動作を有し、すなわちあるロードがバッファリングされたキャッシュラインを読み出す場合、バッファリングされたコンテンツを読出し、あるストアがバッファリングされていないキャッシュラインに書き込む場合、通常の書込みのように動作し、該ストアがバッファリングされたキャッシュラインに書き込む場合、バッファリングされたコピー及びメインコピーの両者が更新される。このモードは、ハードウェアがバッファリング及びモニタリングするものに対するきめの細かい制御を提供し、複雑なコード生成の決定という代償を払って、MB_ALLモードよりも有効なデータをトランザクションが保持するのを可能にする。第三のモードであるMB_NONEが選択され、このモードでは、ロード及びストアの自動的なバッファリング及びモニタリングが行われない。代わりに、UTM  ISAは、特定のメモリ位置のバッファリング又はモニタリングを誘発するため、特別な指示を提供する。なお、実行モードは、プロセッサキャッシュ内のUTM状態を設定するために使用される指示を制御する。ひとたび状態がキャッシュで設定されると、そのモードが状態を設定するために使用されるかを判定することができない。
【００１０】
共通言語ランタイム（CLR）におけるネイティブコードは、以下を含む異なるモードで呼び出される。非トランザクションは、CLRのネイティブコードが呼び出される古典的な方法であり、暗黙的なトランザクションモードは、現在のスレッドがハードウェアトランザクションを実行し、プロセッサがMB_DATAについて設定される間に、CLRコードが呼び出されたときに行われ、明示的なトランザクションモードは、現在のスレッドがハードウェアトランザクションを実行し、プロセッサがMB_NONEについて設定される間に、CLRコードが呼び出されたときに行われるか、又は現在のスレッドがソフトウェアトランザクションを実行しているときに行われる。CLRが呼び出される異なるやり方は、管理される環境の現在の状態にアクセスするため、ネイティブコードが何を行うのを必要とするかを判定する。非トランザクション及び暗黙的なモードでは、CLRは、妨げられた管理された状態を直接に読み出すことができる。明示的なトランザクションモードでは、CLRは、管理された状態にアクセスするためのヘルパー機能を採用する場合がある。
【図面の簡単な説明】
【００１１】
【図１】本発明の１実施の形態に係るプロセッサのブロック図である。
【図２】本発明の１実施の形態に係るプロセッサにおけるデータアイテムのメタデータを保持するブロック図である。
【図３】本発明の実施の形態に係るTMトランザクションを実行するトランザクションモードを選択する方法のフローダイアグラムである。
【図４】特定のモードにおけるトランザクションの実行の失敗の結果として、モード切替えを処理する方法のフローダイアグラムである。
【図５】本発明の実施の形態に係る、ハードウェアトランザクションとソフトウェアトランザクションを同時に処理する方法のフローダイアグラムである。
【図６】本発明の実施の形態に係る、システムのブロック図である。
【発明を実施するための形態】
【００１２】
制限のないTM（UTM）で使用することができる実現の背景として、UTMトランザクションについて使用することができる例示的なハードウェアを見ることが有益である。一般に、UTMトランザクションは、ハードウェアで十分に実現することができるトランザクション、すなわちキャッシュ常駐トランザクション、及びハードウェアとソフトウェアの組み合わせを使用して実行する制限のないトランザクションと共にハードウェアの使用を可能にする。
【００１３】
図１を参照して、複数のスレッドを同時に実行可能なプロセッサの実施の形態が例示される。なお、プロセッサ１００は、ハードウェアトランザクションの実行のためにハードウェアサポートを含む。ハードウェアトランザクションの実行と共に、又は、ハードウェアトランザクションの実行とは別に、プロセッサ１００は、STMのハードウェアアクセラレーション、STMの個別の実行、又は、例えば本発明の実施の形態に係るUTMといったこれらの組み合わせについてのハードウェアサポートを提供する。プロセッサ１００は、マイクロプロセッサ、埋め込みプロセッサ、デジタルシグナルプロセッサ（DSP）、ネットワークプロセッサ、又はコードを実行する他の装置のような、任意のタイプのプロセッサである場合がある。例示されるプロセッサ１００は、複数の処理エレメントを含む。
【００１４】
図１で例示される物理的なプロセッサ１００は、２つのコアであるコア１０１及び１０２を含んでおり、２つのコアは、上位のキャッシュ１１０へのアクセスを共有する。プロセッサ１００は、非対称なコア、すなわち異なるコンフィギュレーション、機能ユニット及び／又はロジックをもつコアを含む場合があるが、対称なコアが示される。結果として、コア１０１と同じように例示されるコア１０２は、繰返しの説明を回避するために詳細に説明されない。さらに、コア１０１は、２つのハードウェアスレッド１０１ａ及び１０１ｂを含むが、コア１０２は、２つのハードウェアスレッド１０２ａ及び１０２ｂを含む。従って、オペレーティングシステムのようなソフトウェアエンティティは、プロセッサ１００を４つの個別のプロセッサ、すなわちソフトウェアスレッドを同時に実行可能な４つの論理プロセッサ又は処理エレメントとして潜在的に見る。
【００１５】
ここで、第一のスレッドは、アーキテクチャ状態レジスタ１０１ａと関連付けされ、第二のスレッドは、アーキテクチャ状態レジスタ１０１ｂと関連付けされ、第三のスレッドは、アーキテクチャ状態レジスタ１０２ａと関連付けされ、第四のスレッドは、アーキテクチャ状態レジスタ１０２ｂと関連付けされる。例示されるように、アーキテクチャ状態レジスタ１０１ａは、アーキテクチャ状態レジスタ１０１ｂで複製され、従って個々のアーキテクチャ状態／コンテクストは、論理プロセッサ１０１ａ及び論理プロセッサ１０１ｂについて記憶可能である。アーキテクチャ状態レジスタは、１実施の形態では、例えばトランザクション状態レジスタ（TSR）、トランザクション制御レジスタ（TCR）といった、UTMトランザクションの実現における使用向けのレジスタ、及び、（トランザクションのアボート（abort）のような）トランザクションの間にイベントを処理するために使用するイジェクションハンドラの位置を識別するイジェクションインストラクションポインタレジスタを含む。
【００１６】
インストラクションポインタ及びリネームアロケータ（rename  allocator）ロジック１３０におけるリネーミングロジックのような他の小さなリソースもスレッド１０１ａ及び１０１ｂについて複製される。リオーダ（reorder）／リタイアメント（retirement）ユニット１３５におけるリオーダバッファ、インストラクショントランスレーション・ルックアサイドバッファ（ITLB：Instruction  Translation  Lookaside  Buffer）１２０、ロード／ストアバッファ、及びキューのような幾つかのリソースは、パーティションを通して共有される。汎用内部レジスタ、ページテーブルベースレジスタ、低水準データキャッシュ及びデータ−TLB１１５、実行ユニット１４０、及びアウトオブオーダ（out-of-order）ユニット１３５の一部のような他のリソースは、潜在的に十分に共有される。
【００１７】
例示されるように、プロセッサ１００は、システムメモリ１７５、チップセット、ノースブリッジ又は他の集積回路のような、プロセッサ１００の外部の装置と通信するバスインタフェースモジュール１０５を含む。メモリ１７５は、プロセッサ１００の専用であるか、又はシステムにおける他の装置と共有される。高水準又は更なるキャッシュ１１０は、高水準キャッシュ１１０から最近フェッチされたエレメントをキャッシュする。なお、高水準又は更なるとは、実行ユニットから増加又は更に離れるキャッシュレベルを示す。１実施の形態では、高水準キャッシュ１１０は、第二レベルのデータキャッシュである。しかし、高水準キャッシュ１１０は、インストラクションキャッシュに関連されるか又はインストラクションキャッシュを含むとき、その様に限定されるものではない。トレースキャッシュ、すなわちあるタイプのインストラクションキャッシュは、最近デコードされたトレースを記憶するためにデコーダ１２５の後に結合される。また、モジュール１２０は、実行／採用されるべき分岐を予測するブランチターゲットバッファと、命令についてアドレス変換エントリを記憶するITLBを潜在的に含む。
【００１８】
デコードモジュール１２５は、フェッチされたエレメントをデコードするためにフェッチ（fetch）ユニット１２０に結合される。１実施の形態では、プロセッサ１００は、プロセッサ１００で実行可能な命令を定義／指定するISAに関連される。ここで、ISAにより認識されるマシンコード命令は、実行されるべき命令又は動作を参照／指定する命令コード（opcode）と呼ばれる命令の一部を含む。
【００１９】
１例として、アロケータ及びリネーマブロック１３０は、命令処理結果を記憶するレジスタファイルのような、リソースを予約するアロケータを含む。しかし、スレッド１０１ａ及び１０１ｂは、順不同実行（out-of-order  execution）が潜在的に可能であり、この場合、アロケータ及びリネーマブロック１３０が、命令の結果を追跡するリオーダバッファのような他のリソースを予約する。また、ユニット１３０は、プロセッサ１００の内部にある他のレジスタにプログラム／命令参照レジスタの名前を変えるレジスタリネーマを含む。リオーダ／リタイアメントユニット１３５は、上述されたリオーダバッファ、順不同実行及び順不同で実行された命令の後のインオーダ（in-order）リタイアメントをサポートするため、ロードバッファ及びストアバッファのようなコンポーネントを含む。
【００２０】
スケジューラ及び実行ユニットブロック１４０は、１実施の形態では、実行ユニットでの命令／動作をスケジュールするスケジューラユニットを含む。例えば、浮動小数点命令は、利用可能な浮動小数点実行ユニットを有する実行ユニットの位置でスケジュールされる。また、実行ユニットに関連されるレジスタファイルは、情報命令の処理結果を記憶するために含まれる。例示的な実行ユニットは、浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、記憶実行ユニット、及び他の公知の実行ユニットを含む。
【００２１】
下位レベルのデータキャッシュ及びデータ変換バッファ（D-TLB）１５０は、実行ユニット１４０に結合される。データキャッシュは、メモリの一貫性の状態で潜在的に保持される、データオペランドのようなエレメントについて最近に使用／処理されたものを記憶する。D-TLBは、物理アドレス変換に最近のバーチャル／リニアを記憶する。特定の例として、プロセッサは、複数のバーチャルページに物理メモリを分割するページテーブル構造を含む。１実施の形態では、プロセッサ１００は、ハードウェアトランザクションの実行、ソフトウェアトランザクションの実行、又はこれらの組み合わせ又は混成が可能である。コードのクリティカル又はアトミックセクション（atomic  section）とも呼ばれるトランザクションは、アトミックグループとして実行される命令、処理又はマイクロ処理のグループを含む。例えば、命令又は処理は、トランザクションセクション又はクリティカルセクションを定めるために使用される。１実施の形態では、これらのセクションは、上述されたデコーダのようなプロセッサ１００のハードウェアにより認識可能である、ISAのような命令のセットの一部である。これらの命令は、高水準言語からハードウェア認識可能なアセンブリ言語にひとたびコンパイルされると、デコードステージの間のデコーダが認識する、命令コード（オペコード）又は命令の他の部分を含む。
【００２２】
典型的に、トランザクションの実行の間、メモリに対するアップデートは、トランザクションが関与されるまで、グローバルに見えるようにされない。例として、あるロケーションへのトランザクション・ライト（transactional  write）は、ローカルスレッドに対して潜在的に見ることができ、更に、別のスレッドからの読取りに応答して、書込みデータは、トランザクション・ライトを含むトランザクションがコミットされる（committed）まで送出されない。トランザクションがなお保留である間、以下の更に詳細に記載されるように、メモリからロードされたデータアイテム／エレメント及びメモリに書き込まれたデータアイテム／エレメントが追跡される。トランザクションがコミットポイントにひとたび到達すると、トランザクションについて競合が検出されない場合、トランザクションがコミットされ、トランザクションの間に行われるアップデートは、グローバルに見ることができる。
【００２３】
しかし、トランザクションがその係属の間に無効にされる場合、トランザクションはアボートされ、アップデートをグローバルに見ることなしに潜在的に再スタートされる。結果として、本明細書で使用されるとき、トランザクションの係属は、実行を開始したトランザクションであって、コミット又はアボートされていない、すなわち係属しているトランザクションを示す。
【００２４】
１実施の形態では、プロセッサ１００は、ハードウェア／ロジックを利用して、すなわちハードウェアトランザクションメモリ（HTM）システムにおいて、トランザクションを実行可能である。HTMを実現するとき、アーキテクチャの視点及びマイクロアーキテクチャの視点の両者から様々な特定の実現の詳細が存在する。それらの大部分は、本発明の実施の形態を不必要に曖昧にするのを回避するため、本明細書では説明されない。しかし、幾つかの構造及び実現は、例示する目的で開示される。さらに、これらの構造及び実現は、必要とされないか、増補されるか、及び／又は異なる実現の詳細を有する他の構造で置き換えられる。
【００２５】
一般に、プロセッサ１００は、STM及びHTMシステムの両者の利益の利用するのを試みる、UTMシステムにおいてトランザクションを実行可能である。例えば、HTMは、小さなトランザクションを実行するために高速且つ効率的であることがある。これは、HTMは、アクセスの追跡、競合の検出、妥当性検証、及びトランザクションのコミットの全てを実行するためにソフトウェアに依存しないためである。しかし、HTMは、小さなトランザクションのみを扱うことができる一方、STMは、制限されないサイズのトランザクションを扱うことができる。従って、１実施の形態では、UTMシステムは、小さなトランザクションを実行するためにハードウェアを使用し、ハードウェアにとって大きすぎるトランザクションを実行するためにソフトウェアを利用する。以下の説明から理解されるように、ソフトウェアがトランザクションを扱うときでさえ、ハードウェアは、ソフトウェアを支援及び加速するために利用される。また、純粋なSTMシステムをサポート及び加速するために同じハードウェアが利用される場合がある。
【００２６】
上述されたように、トランザクションは、プロセッサ１１０内のローカル処理エレメントと同様に、他の処理エレメントにより潜在的に、データアイテムへのメモリアクセスであるトランザクションを含む。トランザクショナルメモリシステムにおけるセーフティメカニズムがなければ、これらのアクセスの幾つかは、無効なデータ及び実行となり、すなわち読取りを無効にするデータの書込み、又は無効なデータの読取りとなる。結果として、プロセッサ１００は、以下に記載されるリードモニタ（read  monitors）及びライトモニタ（write  monitors）のような、潜在的な競合の識別のためにデータアイテムへのメモリアクセス及びデータアイテムからのメモリアクセスを追跡又はモニタするロジックを含む。
【００２７】
１実施の形態では、プロセッサ１００は、データアイテムに関連される、アクセス及び潜在的なその後の競合を検出又は追跡するモニタを含む。１つの例として、プロセッサ１００のハードウェアは、モニタされるように決定されたロード及びストアを追跡するためにリードモニタ及びライトモニタを含む。ハードウェアのリードモニタ及びライトモニタは、基本的な記憶構造の粒度に係らず、データアイテムの粒度でデータアイテムをモニタする。１実施の形態では、データアイテムは、少なくとも全体のデータアイテムが適切にモニタされることを保証するため、記憶構造の粒度で関連するメカニズムを追跡することで境界付けされる。
【００２８】
特定の例として、リードモニタ及びライトモニタは、下位レベルのデータキャッシュ内のロケーションに関連するアドレスからのロードをモニタし、該アドレスへのストアをモニタするため、下位レベルのデータキャッシュ１５０内のロケーションのようなキャッシュロケーションに関連する属性を含む。ここで、データキャッシュ１５０のキャッシュロケーションについてのリードの属性は、同じアドレスへの潜在的な競合する書込みをモニタするため、キャッシュロケーションに関連するアドレスへの読取りイベントに応じて設定される。この場合、書込み属性は、同じアドレスへの潜在的に競合する読取り及び書込みをモニタするため、書込みイベントについて同様のやり方で動作する。この例を更に進めるため、キャッシュロケーションがモニタされることを示すために設定された読取り及び／又は書込みの属性によるキャッシュロケーションへの読取り及び書込みのスヌープに基づいて、ハードウェアは競合を検出可能である。逆に、リードモニタ及びライトモニタの設定、又はバッファリングされた状態へのキャッシュロケーションの更新は、１実施の形態において、検出されるべき他のキャッシュにおいてモニタされるアドレスとの競合を可能にする、読取り要求又はオーナシップの読み取り（read  for  ownership）の要求のようなスヌープとなる。
【００２９】
従って、デザインに基づいて、キャッシュのコヒーレンシーの要求とキャッシュラインのモニタリングされたコヒーレンシーの状態との異なる組み合わせにより、共有される読取のモニタされた状態においてデータアイテムを保持するキャッシュラインと、データアイテムへの書込み要求を示すスヌープとのような、潜在的な競合となる。逆に、バッファリングされた書込み状態にあるデータアイテムを保持するキャッシュラインと、データアイテムへの読取り要求を示す外部スヌープとは、潜在的に競合していると考えられる場合がある。１実施の形態では、アクセス要求と属性の状態との係る組み合わせを検出するため、スヌープロジックは、競合を報告する状態レジスタと同様に競合の検出／報告のためにモニタ及び／又はロジックのような競合の検出／報告ロジックに結合される。
【００３０】
しかし、条件及びシナリオの組み合わせは、コミット命令のような命令により定義される、トランザクションを無効にすると考えられる。トランザクションのノンコミットについて考えられるファクタの例は、トランザクションによりアクセスされるメモリロケーションへの競合を検出し、モニタ情報を失い、バッファリングされたデータを失い、トランザクションによりアクセスされるデータアイテムに関連されるメタデータを失い、アボート、リングトランジション、又は（再開されたトランザクションが係属されないことを想定）明示的なユーザインストラクション、のような他の無効にするイベントを検出することを含む。
【００３１】
１実施の形態では、プロセッサ１００のハードウェアは、バッファリングされたやり方で、トランザクション・アップデート（transaction  update）を保持する。上述されたように、トランザクション・ライトは、トランザクションのコミットまでグローバルに見えない。しかし、トランザクション・ライトに関連するローカルソフトウェアスレッドは、その後のトランザクション・アクセス（transaction  access）についてトランザクション・アップデートにアクセス可能である。第一の例として、個別のバッファ構造は、他の外部スレッドではないローカルスレッドへの更新を提供可能な、バッファリングされたアップデートを保持するためにプロセッサ１００において提供される。さらに、個別のバッファ構造を包含することは、潜在的に高価且つ複雑である。
【００３２】
対照的に、別の例として、データキャッシュ１５０のようなキャッシュメモリは、同じトランザクションの機能を提供する間に、アップデートをバッファリングするために利用される。ここで、キャッシュ１５０は、バッファリングされたコヒーレンシーの状態においてデータアイテムを保持可能であり、１つのケースでは、新たにバッファリングされたコヒーレンシーの状態は、MESIBプロトコルを形成するため、MESI（Modified  Exclusive  Shared  Invalid）プロトコルのようなキャッシュコヒーレンシープロトコルに追加される。バッファリングされたデータアイテム、すなわちバッファリングされたコヒーレンシー状態で保持されているデータアイテムのローカル要求に応答して、キャッシュ１５０は、シーケンシャルオーダリング（sequential  ordering）の内部トランザクションを保証するため、データアイテムにローカル処理エレメントを提供する。しかし、外部アクセス要求に応答して、コミットまで、更新されたデータアイテムのトランザクションがグローバルに見えるのを保証するため、ミスレスポンスが提供される。さらに、キャッシュ１５０のラインがバッファリングされたコヒーレンシーの状態において保持され、立ち退きのために選択されるとき、バッファリングされたアップデートは、上位のキャッシュメモリに書き込まれない。バッファリングされたアップデートは、メモリシステムを通して増加せず、すなわちコミットの後までグローバルに見えない。コミットに応じて、バッファリングされたラインは、データアイテムをグローバルに見えるようにするため、変更された状態に遷移される。
【００３３】
用語「内部」及び「外部」は、キャッシュを共有するトランザクション又は処理エレメントの実行に関連するスレッドの視点に関する。例えば、あるトランザクションの実行に関連するソフトウェアスレッドを実行する第一の処理エレメントは、ローカルスレッドと呼ばれる。従って、先の説明において、バッファリングされたコヒーレンシー状態で保持されているアドレスのためのキャッシュラインとなる、第一のスレッドにより前に書き込まれたアドレへのストア又は該アドレスへのロードが受信された場合、バッファリングされたバージョンのキャッシュラインは、第一のスレッドに提供される。これは、第一のスレッドがローカルスレッドであるためである。対照的に、第二のスレッドは、同じプロセッサ内の別の処理エレメントで実行しているが、外部スレッドであるバッファ状態で保持されているキャッシュラインに関与するトランザクションの実行に関連しない。従って、第二のスレッドからアドレスへのロード又はストアは、バッファリングされたバージョンのキャッシュラインを欠き、上位のメモリからバッファリングされないバージョンのキャッシュラインを検索するため、通常のキャッシュの置換えが利用される。
【００３４】
ここで、内部／外部／遠隔のスレッドは、同じプロセッサで実行され、幾つかの実施の形態では、キャッシュへのアクセスを共有する同じプロセッサのコアにおける個別の処理エレメントで実行される。しかし、これらの用語の使用は限定されるものではない。上述されたように、ローカルは、トランザクションの実行に関連する単一のスレッドに固有である代わりに、あるキャッシュへのアクセスを共有する複数のスレッドを示し、外部又は遠隔は、キャッシュへのアクセスを共有しないスレッドを示す。
【００３５】
図１を最初に参照して先に述べたように、プロセッサ１００のアーキテクチャは、説明のために純粋に例示するものである。例えば、他の実施の形態では、UBTハードウェアは、複雑なリネーム／アロケータ及びリオーダ／リタイアメントユニットを含まない、より簡単なインオーダの実行プロセッサの設計をもつプロセッサについて実現される。同様に、同じメモリの個別のエントリにおけるメタデータとデータを関連付けする方法が利用されるとき、メタデータを参照するデータアドレスを変換する特定の例もまた例示するものである。
【００３６】
図２を参照して、プロセッサにおいてデータアイテムのメタデータを保持する実施の形態が例示される。図示されるように、データアイテム２１６のメタデータ２１７は、メモリ２１５にローカルに保持される。メタデータは、データアイテム２１６に関連するトランザクションの情報のような、データアイテム２１６に関連されるプロパティ又は属性を含む。幾つかの例示的なメタデータが以下に含まれ、開示されるメタデータの例は、単に例示するものである。係るように、メタデータのロケーション２１７は、データアイテム２１６の情報と他の属性との組合せを保持する。
【００３７】
第一の例として、トランザクションにおいてデータアイテム２１６が前にアクセス、バッファリング及び／又はバックアップされている場合、メタデータ２１７は、トランザクションで書き込まれたデータアイテム２１６のバックアップ又はバッファロケーションへのリファレンスを含む。ここで、幾つかの実現では、前のバージョンのデータアイテム２１６のバックアップコピーは、異なるロケーションで保持され、結果として、メタデータ２１７は、バックアップロケーションへのアドレス又は他のリファレンスを含む。代替的に、メタデータ２１７自身は、データアイテム２１６のバックアップ又はバッファロケーションとしての役割を果たす。
【００３８】
別の例として、メタデータ２１７は、データアイテム２１６へのリピートトランザクショナルアクセス（repeat  transactional  access）をアクセラレートする第一の値を含む。ソフトウェアを利用したトランザクションの実行の間、アクセスのバリアは、一貫性及びデータの有効性を保証するためにトランザクショナルメモリアクセス（transactional  memory  access）で実行される。トランザクショナルロードオペレーション（transactional  load  operation）の前に、データアイテム２１６がアンロックされているかを検査し、トランザクションの現在のリードセットがなお有効であるかを判定し、フィルタ値をアップデートし、後の検証を可能にするためにトランザクションのリードセットにおけるバージョンの値のロギングのような、リードバリア処理を実行するためにリードバリアが実行される。しかし、そのロケーションの読取りがトランザクションの実行の間に既に実行されている場合、同じリードバリアオペレーションは潜在的に不要である。
【００３９】
結果として、１つのソリューションは、リードフィルタを利用して、データアイテム２１６又はアドレスがトランザクションの実行の間に読み取られていないことを示す第一のデフォルト値を保持し、データアイテム２１６又はアドレスがトランザクションの係属の間に既にアクセスされていることを示す第二のアクセス値を保持するリードフィルタを利用することを含む。本質的に、第二のアクセスされた値は、リードバリアをアクセラレートすべきかを示す。この例では、トランザクショナルロードオペレーションが受信され、メタデータのロケーション２１７におけるリードフィルタ値が、データアイテム２１６が既に読み取られたことを示す場合、１実施の形態では、リードバリアが無視され、実行されず、不要な、冗長なリードバリアオペレーションを実行しないことで、トランザクションの実行をアクセラレートする。なお、書き込みフィルタ値は、書き込み動作に関して同じ方式で動作する。しかし、１実施の形態では、書き込み又は読取りであろうと、アドレスが既にアクセスされるかを示すために単一のフィルタ値が利用されるように、個々のフィルタ値は単に例示するものである。ここで、ロード及びストアの両者について、データアイテム２１６のメタデータ２１７をチェックするメタデータアクセスオペレーションは、メタデータ２１７は個別のリードフィルタ値及びライトフィルタ値を含む先の例とは対照的である、単一のフィルタ値を利用する。特定の例示的な実施の形態では、４ビットのメタデータ２１７は、関連されるデータアイテムに関してリードバリアをアクセラレートすべきかを示すリードフィルタ、関連されるデータアイテムに関してライトバリアをアクセラレートすべきかを示すライトフィルタ、ｕｎｄｏ処理をアクセラレートすべきかを示すｕｎｄｏフィルタ、及びフィルタ値としてソフトウェアにより何れかのやり方で利用されるその他のフィルタ（miscellaneous  filter）に割り当てられる。メタデータの幾つかの他の例は、ハンドラのアドレスの示唆、ハンドラのアドレスの表現又はハンドラのアドレスへの参照を含み、データアイテム２１６に関連するトランザクション、データアイテム２１６に関連するトランザクションの取り消し不能／頑強な性質、データアイテム２１６の損失、データアイテム２１６のモニタリング情報の損失、データアイテム２１６について検出されている競合、データアイテム２１６と関連するリードセットにおけるリードセット又はリードエントリのアドレス、データアイテム２１６の前にログされたバージョン、データアイテム２１６の現時のバージョン、データアイテム２１６へのアクセスを許可するロック、データアイテム２１６のバージョン値、データアイテム２１６に関連するトランザクションのトランザクション記述子、他の公知のトランザクションに関連する記述情報、にとって一般的又は個別的である。さらに、先に記載されたように、メタデータの使用は、トランザクショナル情報に限定されない。当然の結果として、メタデータ２１６は、トランザクションに関与しない、データアイテム２１６に関連する情報、特性、属性又は状態を含む。
【００４０】
UTMシステムのこの背景によれば、トランザクションをどの様に開始するかに関する次の考慮が説明される。スレッドがトランザクションに入ったとき、スレッドは、TM実行モードのうちの１つに遷移する。スレッドが何れかのタイプのSTMモードではない場合（一般に、何れかのSTMモードが*STMモードと呼ばれる）、現在のスレッドは、暗黙のモードCRITMを使用する。多くのスレッドは、CRITMモードにある。スレッドがハードウェアの境界付けされた容量をオーバフローするか、又は現在のモードにおいて行うことができない幾つかのセマンチックアクションを実行する場合、CRITMトランザクションは、幾つかの*STMモードでロールバック及び再実行する。何れかのスレッドがひとたび*STMモードになると、全ての他のスレッドは、CRITMモードから離れ（ロールバック）、CRESTMのようなSTMロックに関するモードにおいて再実行する。例えばCRITM及びCRESTMといった幾つかの可能性のある実行が可変である組み合わせ（execution  variant  combination）が存在する。説明のため、このモードの組み合わせは、本明細書で使用される。
【００４１】
表１は、２つの例示的なトランザクション・実行モードを互いに比較し、２つの例示的なトランザクション・実行モードを最新のプレインなノントランザクショナルモードと比較する。
【００４２】
【表１】
0005635620.tif 000002
例えばバッファリングされたデータの損失又は競合のために、幾つかのトランザクションが失敗すること、そのためにトランザクションがアボートすることは避けられない。幾つかの例では、トランザクションのモードは、再実行の時間で変化する場合がある。トランザクションは、低いパフォーマンスモードに「フォールバック」するか又は高いパフォーマンスのモードに「アップグレード」する。すなわち、パフォーマンスの視点から全てのモードが等しくない。一般に、CRITMは、最も効率のよい実行モードである。それは、ソフトウェアロックに対処するオーバヘッドを回避するためである。次に効率のよいモードは、CRESTMであり、続いてHASTMであり、次いでSTMである。STM及びHASTMモードは、これらが提供する機能において等価であり、従ってSTMは、以下に記載されるこれらの両方のモードを表すために使用される。
【００４３】
しかし、全てのトランザクションは、CRITMモードで実行することができない。それは、CRITMモードは、キャッシュ常駐トランザクションでのみ動作するためである。CRESTMモードもキャッシュ常駐トランザクションに制限されるので、キャッシュ非常駐トランザクションは、STMモードの下で実行される必要がある。CRITMモードは、STMモードと互換性がないので、あるトランザクションがSTMモードの下で動作するのを開始するとすぐ、CRITMモードの下でトランザクションは実行されない。従って、現段階では、全てのキャッシュ常駐トランザクションは、CRESTMモードに移行する。
【００４４】
トランザクションがどのモードの下で実行されるかに関する広義の制約は、以下の通りである。全てのトランザクションは、CRITMモードで開始するが、STMトランザクションが実行されている場合、全てのトランザクションは、CRESTMモードで開始する。トランザクションがキャッシュをオーバフローする場合、トランザクションはロールバックし、STMモードの下で実行を再開する。トランザクションがSTMモードの下で実行されている場合、全てのCRITMトランザクションは、ドゥーム処理され（doomed）、CRESTMモードの下で実行を再開する。
【００４５】
１実施の形態では、「リトライ“retry”」プリミティブのサポートの周辺で幾つかの更なる制約が存在する。トランザクションが「リトライ」プリミティブを使用する場合、トランザクションは、STMモードでのみ実行することができる。それは、CRITM及びCRESTMがリトライを待つことをサポートしないためである。システムにおける何れかのシステムが「リトライ」で待っている場合、全ての他のトランザクションは、CRESTM又はSTMモードで実行する必要がある。それは、CRITMは、通知（notification）をサポートしないためである。
【００４６】
図３を参照して、本発明の実施の形態に係る、TMトランザクションを実行するトランザクション・実行モードを選択する方法のフローダイアグラムが示される。１実施の形態では、方法３００は、UTMシステムのランタイムにより実現される。この通り、図３は、他のトランザクションがシステムにおいてアクティブであるかを判定することで開始する（ひし形３１０）。これは、所定のハードウェアトランザクションモードがSTMトランザクションと互換性がないときに行われる。他の係るトランザクションがアクティブでない場合、制御はブロック３２０に進み、ブロック３２０で、トランザクションは、最も効率の良い利用可能なモードで開始する。本明細書で記載されるコンテクストでは、最も高い効率の良いモードは、ハードウェアインプリシット・トランザクションモード（hardware  implicit  transaction  mode）（例えばCRITM）である場合がある。勿論、異なる実現では、異なるモード又は変更されたモードが利用可能な場合がある。
【００４７】
代わりにひし形３１０で、他のトランザクションがアクティブであると判定された場合、制御はひし形３２５に進み、ひし形３２５で、これらのトランザクションの何れかがSTMモードにあるかが判定される。これらのトランザクションの何れかがSTMモードにある場合、新たなトランザクションは、STMモードと一致する最も効率の高いモードで開始する（ブロック３３０）。例えば、本明細書で説明される実現では、この最も高い互換性のあるモードは、ハードウェアエクスプリシットモード（hardware  explicit  mode）（例えばCRESTM）である場合があり、このモードでは、プロセッサキャッシュ内に完全に内在する場合があるハードウェアがトランザクションを支援するが、ソフトウェアロックが尊重される。
【００４８】
従って、トランザクションが開始され、動作が継続する。次いで、オーバフローが生じるかが判定される（ひし形３３５）。すなわち、全てのトランザクションが幾つかのタイプのキャッシュ常駐・ハードウェア支援モード（cache  resident  hardware  assisted  mode）で開始するとき、キャッシュスペースは、完全なトランザクションを扱うために不十分である。従って、ひし形３３５で判定されたときにオーバフローが生じた場合、以下に更に記載されるようにブロック３７５に制御が進む。代わりに、トランザクションがオーバフローしない場合、次に、トランザクションが終了したかが判定される（ひし形３４０）。トランザクションが終了していない場合、継続される実行が行われる。トランザクションが終了した場合、制御はひし形３５０に進み、ひし形３５０で、トランザクションのハードウェア特性が維持されているかが判定される。すなわち、トランザクションがコミットする前に、例えばバッファリング、モニタリング及びメタデータのUTM特性といった様々なハードウェア特性は、これらの特性が損失なしになおアクティブであるかを判定するためにチェックされる。アクティブではない場合、幾つかのハードウェア特性の損失が生じており、ブロック３６０に制御が進み、ブロック３６０で、トランザクションがアボートされる。さもなければ、トランザクションが上手く終了し、且つハードウェア特性が残されている場合、ブロック３５５に制御が進み、ブロック３５５で、トランザクションがコミットされる。
【００４９】
図３を更に参照して、代わりにキャッシュ常駐トランザクションの実行の間、（ひし形３３５で判定されたときに）トランザクションがキャッシュをオーバフローさせた場合、ブロック３７５に制御が進む。そこでトランザクションはロールバックされ、STMモードで再実行される。STMモードでの実行の間、セマンティックが違反されたかが判定される（ひし形３８０）。セマンティックが違反された場合、ブロック３８２に制御が進み、ブロック３８２で、トランザクションがロールバックされ、例えば純粋なSTMモードといった下位の効率の良いモードで再実行される。ハードウェア支援トランザクションに関して説明されたように、トランザクションが終了したか、及び上手くコミットされたか又はアボートが必要とされるかにを判定することに関する同様の動作が行われる（ブロック３８５、３９０、３９２、３９５）。図３の実施の形態におけるこの特定の実現により記載される一方、あるトランザクションを実行する所与のモードの制御は、異なる実現において変わる場合があることを理解されたい。
【００５０】
このように図３の方法は、あるトランザクションを開始するため、どのように適切なモードを決定するかを一般に説明している。しかし、トランザクションの間、キャッシュのオーバフロー又はSTMの失敗以外の理由のため、失敗が生じる場合がある。様々な実施の形態では、先に記載された制約が満たされ、且つシステムが最適なパフォーマンスを達成するように、新たな（又は再実行されている）トランザクションがどのモードで実行されるかを判定するため、フォールバック及びアップグレードメカニズムが実現される。表２は、トランザクションをドゥーム処理（終了）する理由のセットを示す。表２における第一の列は、トランザクションをドゥーム処理する様々な理由を記載し、第二の列及び第三の列は、前に保留しているCRITM又はCRESTMトランザクションが再実行される新たなモードをそれぞれ示す。ブランクにされているセルは、トランザクションが所与の理由のためにドゥーム処理されないことを示す。
【００５１】
【表２】
0005635620.tif 000003
図２に関して、第一の優先事項は、CRITMモードで再実行することである。しかし、トランザクションがCRITMモードで利用可能ではない機能を必要とする場合、又はSTMトランザクションが進行中である場合、トランザクションは、CRESTMモードで再実行される。この理由のためにCRESTMを終了する決定は、経験則に基づく。また、CRITMトランザクションは、現時点で実行されるべきではない。
【００５２】
なお、表２に示される設計上の選択における自由度が存在する。例えば、キャッシュ常駐であるモードを設計することは可能であるが、ソフトウェアに基づく失敗の原子性（software  based  failure  atomicity）を提供する。係るモードは、ネスト化されたトランザクションの失敗に対処するために使用される。
【００５３】
ここで図４を参照して、特定のモードにおいて実行しているトランザクションの失敗の結果として、モード切り替えを扱う方法のフローダイアグラムが示される。図４の方法４００は、１実施の形態では、第一のモードにおけるトランザクションの失敗に応じて制御を受けるイジェクションハンドラにより実現される。この通り、方法４００は、トランザクションの失敗の理由を判定することで開始する（ブロック４１０）。この決定は、受信された様々な情報に基づいて行われる。例として、TCR及び／又はTSRの情報は、失敗の理由を示す。同様に、トランザクション制御ブロックは、失敗の理由を示す。更に、他の実現では、この情報を取得する他のやり方が使用される場合がある。
【００５４】
さらに、図４を参照して、一般に、トランザクションをドゥーム処理する理由に基づいて、例えばトランザクションを再実行する異なるパスといった異なるリカバリパスが選択される。さらに、図４の実施の形態における特定の順序で記載及び図示される一方、これは説明の便宜のためであって、行われる様々な決定は、様々な実現において異なる順序で（及び異なるやり方で）行われることを理解されたい。この通り、ひし形４１５で、必要とされる機能は、現在のトランザクションモードによりサポートされなかったかが判定される。係るサポートされない機能の例は、以下に記載される。これがトランザクションの失敗についての原因であると判定された場合、ブロック４２０に制御が進み、ブロック４２０で、この機能をサポートする別のモードの選択が行われる。従って、トランザクションは、この新たなモードへのモード切り替えに従ってトランザクションが再実行される。
【００５５】
トランザクションをドゥーム処理する更に別の理由は、ひし形４２５で決定されるように、トランザクションがそれ自身をドゥーム処理することである。トランザクションがそれ自身をドゥーム処理した場合、トランザクションがそれ自身をドゥーム処理した回数が判定される。この数は、閾値に比較される（ひし形４３０）。数がこの閾値を超える場合、トランザクションがそれ自身をドゥーム処理し続けることを示し、トランザクションは、異なるモードに切り替えられる（ブロック４３５）。閾値に一致しない場合、再実行は、同じモードで行われる（ブロック４４０）。
【００５６】
トランザクションをドゥーム処理する更なる理由は、外部システムのアクティビティがドゥーム処理を引き起こしたかである。これが判定された場合（ブロック４５０）、この外部のアクティビティが保留のSTMトランザクションにおいて増加したかが判定される（ダイアモンド４５５）。この外部のアクティビティが保留のSTMトランザクションにおいて増加した場合（及び現在のトランザクションがハードウェアインプリシット・モードトランザクションである場合）、トランザクションは、ハードウェアエクスプリシットモードで再実行される（ブロック４６０）。STMトランザクションの数における増加の代わりに、（ひし形４６２で判定されるように）保留のSTMトランザクションにおける減少があると判定された場合、保留のハードウェアエクスプリシットトランザクションがより効率が良いときに、ハードウェアインプリシットモードにおいて保留のハードウェアエクスプリシットトランザクションを再開すべきかに関する判定が行われる（ブロック４６５）。この判定をなすことにおける異なる考慮は、STMトランザクションにおける変化が外部システムのアクティビティではない場合、トランザクションは、その現在のモードで再実行される（ブロック４７０）。同様に、例えば競合又は別の係る理由のため、トランザクションの失敗の幾つかの他の理由が存在する場合、トランザクションは、同じモードで再実行される（ブロック４８０）。この特定の実現が図４の実施の形態において示されているが、本発明の範囲はこの点に限定されないことを理解されたい。
【００５７】
表２において先に記載され、図４において説明された理由は、４つの広いカテゴリに分類される。それぞれのカテゴリについて、フォールバック及びアップグレードメカニズムが記載される。第一の失敗の原因のカテゴリは、所与の実行モードによりサポートされない機能である。理由１〜５は、CRITMについてこのバケットに分類される。CRESTMについて、理由２〜５は、このバケットに分類される。これらの理由は、トランザクションに不可欠であり、現在の実行モードにおいて制限を露呈する。従って、トランザクションの再実行は、前に実行されたのと同じモードにあるべきではなく、代わりに、必要とされるサポートを有するモードへの切り替えが行われる場合がある。この機能をサポートするため、（トランザクションがドゥーム処理されたとき）持続性のある書き込み（durable  write）がトランザクションコンテクストに実行され、トランザクションが再実行されたときに使用されるべきモードを指定する。
【００５８】
第二の失敗の原因のカテゴリは、トランザクションが自殺する（自身をドゥーム処理する）場合である。理由６及び理由７は、このカテゴリに分類される。理由６について、トランザクションはロールバックされ、必要とされるブロックの編集（例えばジャストインタイム（JIT））が実行され、次いで、トランザクションは、同じモードで再実行される。これは、ある機能をJITすることは非常に高価であるためであり、従って、ロールバック及び再実行のオーバヘッドは、顕著ではないからである。理由７について、トランザクションは、同じモードで再実行される。これは、第一に、モニタリングされた／バッファリングされたラインは、オブジェクトヘッダを次からは含まない場合があり、第二に、オブジェクトヘッダへの書き込みのために、モニタリング（又はバッファリング）の損失が生じたことを知る方法がないからである。幾つかの実現において、オブジェクトヘッダへの書き込みのためにトランザクションがそれ自身をドゥーム処理し続けるシナリオについて、予防手段が提供される。１つの例として、（幾つかの予め決定された閾値よりも大きい）Ｎ回だけ再実行するCRITM／CRESTMトランザクションは、STMモードで再実行されるというルールが設定される。
【００５９】
第三の失敗の原因のカテゴリは、現在のトランザクションの外部にあるシステムアクティビティがそれをドゥーム処理する場合である。理由８〜理由１０は、このカテゴリに分類される。理由８について、ガーベージコレクション（GC）の停止のためにトランザクションがロールバックされ、同じモードにおいてリトライしない理由が存在せず、従って、トランザクションは、前に実行していたモードで再実行される。理由９について、現在実行しているSTMトランザクションのグローバルカウンタは、メモリに保持される。新たなSTMトランザクションが開始するときは何時でも、このカウンタは（例えばInterlockedIncrement）インクリメントされ、STMトランザクションがロールバック／アボート／コミットするとき、（例えばInterlockedDecrementを介して）対応するデクリメントがカウンタで行われる。また、CRITMトランザクションは、STMトランザクションが開始したときは何時でも、全てのCRITMトランザクションがドゥーム処理され、CRESTMモードで再実行されるように、このグルーバルカウンタに関してモニタリングされる読取り（monitored  read）を実行する。
【００６０】
CRITMは、最も効率の良いモードであり、従って、CRITMトランザクションを積極的にドゥーム処理するこは、回避されることが求められる。１つのソリューションは、STMがまさに開始しようとしているときは何時でも、はじめに、システムが実行しているCRITMトランザクションを現在含んでいるかをチェックする。システムがCRITMトランザクションを含む場合、STMトランザクションは、開始前に有限の時間量について待つように制御される。係る待ち時間は、現在実行されているCRITMトランザクションがSTMトランザクションを過度に遅延することなしに実行を終了するのを可能にする。
【００６１】
理由１０について、システムにおける全てのSTMトランザクションが終了するときは何時でも、１つの実現は、全てのCRESTMトランザクションをドゥーム処理し、それらをCRITMモードで再開することである。しかし、CRESTMトランザクションがドゥーム処理する前にまさに終了しようとしている場合に、スピンメカニズムが実行される場合がある。ここでの最終的な決定は、CRITMに比較してCRESTMのオーバヘッドに基づいており、平均で、CRESTMトランザクションはCRITMトランザクションと２倍を超えて遅い場合、CRESTMトランザクションをドゥーム処理し、それらをCRITMモードで再開することがより効率が良く、さもなければ、CRESTMモードで継続することがより効率が良い。更に他の実現では、CRESTMモードからCRITMモードに実行しているトランザクションを遷移することが可能である。
【００６２】
有効なリード−ライト（r-w）又はライト−ライト（w-w）の競合は、バッファリングされた／モニタリングされたブロックで生じる。理由１０及び理由１１は、このカテゴリに属する。トランザクションがキャッシュラインでモニタリング又はバッファリングを失ったために、トランザクションがドゥーム処理される場合、トランザクションは、前と同じモードでリトライすることができる。ここでの１つの懸案事項は、あるキャッシュラインにアクセスしている新たなトランザクションが古いトランザクションをドゥーム処理する場合、古いトランザクションは、新たなトランザクションが再始動するときに新たなトランザクションをドゥーム処理する。これは、どちらのトランザクションも終了しないピンポン効果につながる。係る状況を扱うため、競合管理ロジックが使用される場合がある。
【００６３】
幾つかの実現では、あるトランザクションがまさに実行を開始又は再開しようとしているときの最適化は、CRESTMモードで開始する必要がある理由が「システムが１以上のSTMトランザクションを含む」ことである場合、リトライの前に待つためにスピンメカニズムが使用される。待った後、STMトランザクションがなお実行されている場合、現在のトランザクションは、CRESTMモードで開始され、さもなければ、トランザクションは、CRITMモードで開始され、CRESTMオーバヘッドは、回避される。同様のロジックは、再始動しているCRESTMトランザクションに適用される。従って、先に説明において、トランザクションが同じモードで再始動されるべきとき、そのモードがCRESTMである場合に、はじめに、トランザクションがCRITMモードの下で実行することができるかが判定される場合があるという警告（caveat）が存在する。
【００６４】
説明のため、CRESTMは、TVコード生成スタイル、例外に基づいたロールバックを使用する一方、CRITMは、NKコード生成スタイルを及びlongjmpに基づいたロールバックを使用する。
【００６５】
レキシカルアトミックブロック（lexical  atomic  block）（一般に“s”と呼ばれる）がどのように変換されるかを考える。（この説明のため、あるトランザクションに関する全ての状態が現在のトランザクションオブジェクトにおいて保持され、トランザクションのコンテクストを無視するものと想定する。）“CreateTx”プリミティブは、“ConstantSiteId”を取り、固有の小さな、難解な整数IDは、語彙のトランザクションを識別する。このIDは、語彙のトランザクションに関する競合の管理情報を含むグローバルデータ構造に索引を作るために使用される。また、この構造は、どの実行モードにおいてトランザクションを開始すべきかを示す永続性のある情報を記憶するために使用される。プリミティブは、この情報をトランザクションの属性として設定する。
【００６６】
以下、表３〜表５において、TMサポートコードへのコードブロックの３つの変換が与えられる。表３の擬似コードは、CRESTM及びSTMが実行モードのみであることを想定し、表４の擬似コードは、CRITMが実行モードのみであることを想定し、表５の擬似コードは、全ての３つの可能性を可能にすることを試みる。
【００６７】
CRESTM及びSTMは、実行モードのみである場合、変換は、表３における擬似コードにおいて説明される。
【００６８】
【表３】
0005635620.tif 000004
表３において分かるように、トランザクションは、“createTx”プリミティブを使用して作成される。そのSiteIDは、現在使用しているトランザクションvtableを含む最初の属性のセットを決定する。全てのモードにおいて、ライブのローカル変数（又はまさにトランザクションにおいて変更される変数）は、スタックロケーションに保存される。その後、現在の実行モードがハードウェアアクセラレーションを使用している場合にハードウェアトランザクションが開始される。トランザクションが実行される。トランザクションがロールバックされる場合、catch節（catch  clause）に到達する。それは、ハンドラの例外に基づくロールバックが発せられるためである。はじめに、ローカル変数の値が回復される。これは、ハンドラ（HandleEx）が（リターンにより）再実行するのを決定しようと、又はアボートするユーザ実行をマーシャリング（marshal）及びリスロー（rethrow）するのを決定しようと必要であり、ローカル変数は、スローされた例外を捕捉するcatch節においてライブ（live）である。ハンドラが再実行するのを決定した場合、ハンドラは、トランザクション“curtx”の属性を変更する。例えば、CRESTMの代わりにSTMを使用するためにトランザクションvtableを変える。
【００６９】
CRITMが実行のみのモード（only  execution  mode）である場合、変換は、表４の擬似コードで説明される。
【００７０】
【表４】
0005635620.tif 000005
表４において分かるように、“SaveSetjmpState”演算は、スタックポインタ、ベースポインタ及び命令ポインタ（ESP）、（EBP）及び（IP）を保存するだけでなく、先に説明された理由のために全ての呼出先退避レジスタ（callee-save  registers）をも保存することが想定される。“SaveSetjmpState”演算が保存するIPは、SaveSetjmpStateへのコールの直後であり、演算は、コールからリターンされたかのように再開する。イジェクタは、保存されたレジスタ値を回復し、保存されたIPにジャンプする。なお、制御フローがSを離れるときに、トランザクションをコミットするために幾つかの明示的なアクションが存在するとき、Sの「ありのままの“naked”」変換は、正確にSに等しくない。Longjmpに基づくロールバックが生じるので、スローされたユーザレベルの例外のみがcatch節に到達する。CRESTMにおけるように、（幾つかの理由のため）保存されたローカル変数は回復される。HandleExは、例外をディープクローンし（deep-clone）、ハードウェアトランザクションをアボートし、次いでクローンされた例外をリスローする。第一の例外に関して、curtx.IsRexec()が偽（false）であり、従ってロケーションは回復されない。所与のトランザクションの例について第二及びその後の例外に関して、この条件が真（true）である場合、従ってローカル変数が回復される。これは、catch節におけるlocalを回復することに加えて、longjmpを介した再実行がcathchハンドラを通過しないために行われる。イジェクタが再実行するために入力されたとき、再実行が実行されるべきモードに関する判定は、トランザクションデータ構造において記録される。これはイジェクタにおいて行われるが、有意コードがそこで実行される場合、スタックのオーバフローが生じる場合がある。別の代替は、判定がトランザクションデータ構造において基づくイジェクタレコードの関連データを有すること、このIsRexec()テスト後に新たな実行モードを決定及びインストールすることであり、この可能性は、コメントを介して表４において示される。
【００７１】
CRITM、CRESTM及びSTMモードの可能性を想定する結合された変換は、表５の擬似コードにおいて述べられる。
【００７２】
【表５】
0005635620.tif 000006
表５の擬似コードに関して、CRITMモードにおいて開始し、競合又はリソースの制限に遭遇し、CRESTMにおいて再実行するために競合の管理の決定をなし、さらに競合又はリソースの制限に遭遇し、及び従ってSTMにおいて今度は上手く再実行するトランザクションの実行を考える。
【００７３】
ConstantSiteIdに関連する情報は、CRITMモードにおいてトランザクションがはじめに実行することができることを決定する。全てのモードにおいて、ライブの及び変更されたlocalsは、はじめに、スタックフレームにおいて変数をシャドウ（shadow）するために保存される（これが上位のトランザクションである場合、永続的にそのように行う）。LongjmpRollbackが真をリターンするように、トランザクションがセットアップされ、従ってsetjmp-equivalentを行う。前に記載されたように、（この例においてではない）これが再実行である場合、保存されたlocalsが回復される。次いで、ハードウェアトランザクションは開始され、SのSTM変換のCGSTYLE_NKバージョンが実行される。CRITM実行は、モニタリング又はバッファリングを失い、イジェクタに入り、従って現在のハードウェアトランザクションがアボートされる。
【００７４】
トランザクションは、競合の管理の決定を行い、CRESTMモードにおいて再実行することを決定する。トランザクションは、トランザクションvtableを含めて、トランザクションの幾つかの属性を変更する。トランザクションは、保存されたレジスタの値を回復し、保存されたIPにジャンプし、従ってまるでSaveSetjmpStateがちょうどリターンされたかのように再始動する。（前に説明されたように、必要に応じて、イジェクタにおいて競合の管理の作業をせず、“IsRexec()”テスト後の新たな実行モードの設定を実行する。）
新たなハードウェアトランザクションが開始され、コードのCGSTYLE_TV変換が実行される。ある時点で、モニタリング又はバッファリングの損失が検出され、内部のReExecuteExceptionが生じ、従って例外のハンドラに到達し、それらのシャドウコピーからローカル変数が回復される。保存されたローカル変数の値が回復され、HandleExが呼び出され、HandleExは、生じた例外がReExecuteExceptionであることを判定する。ある時点で、例外を生じる前に、次の実行モードを決定する競合の管理の決定が行われ、現在のトランザクションの属性が適切に調節される。この場合、決定はSTMモードで再実行することであると想定する。再実行が生じたので、HandleExは、リレイジング（re-raising）ではなくリターンし、従って制御はラベルLを再びリターンする。この実行に関して、StartHWTxは、no-opである。これは、ハードウェアアクセラレーションが使用されず、ボディのCGSTYLE_TV変換及びSTMバリアが実行されたためである。今度は、トランザクションが成功し、コミットされる。
【００７５】
表６は、本発明の実施の形態に係る、TM実行の様々な特性の比較を与える。
【００７６】
【表６】
0005635620.tif 000007
このように、様々な実施の形態では、暗黙的及び明示的なキャッシュ常駐、HASTM及びSTMを含めて、複数のモードでトランザクションを実行するため、スイッチングステートマシンが使用される。例えば、トランザクションは、CRITMで開始し、次いでオーバフローに関して切り替わる。さらに、幾つかのスレッドがSTMロックモードに入るときに、他のスレッドのトランザクションを切り替えることができる。決定論的なコミットの順序又はリトライのようなリッチなセマンティクス又は特徴に関する切り替えモードが行われる場合があり、STMスレッドが残されていないときに、CRITMモードへのスイッチバックを行うことができる。
【００７７】
実施の形態は、ロギング又はシャドウコピーのバッファリングなしに、小さく簡単なトランザクションを効率的に実行するため、明示的なモニタリング及びバッファリング制御命令のUTMサポートを使用する一方、ソフトウェアのロッキング及びロギングの規律を使用する制限されないパブリケーション−プライバチゼーションが正確な（publication-privatization-correct）STM/HASTMトランザクションと正しく共存する。従って、UTMシステムは、高速なキャッシュ常駐のトランザクションがSTMトランザクション（更にはコア（cores）にスケジュールされないソフトウェアスレッドのトランザクション）を同時に実行するのを可能にする。ハードウェアインプリシットモードでは、特に管理されるコードについて、内部のランタイムデータ構造へのアクセス及びスタックは、キャッシュにより管理されるトランザクションのリード及びライトのセットに不必要に加わる。キャッシュモニタリング及びバッファリングのインストラクションファシリティ（instruction  facilities）のCRESTMの暗黙的でないモードの（ソフトウェアによる）使用では、トランザクションは、トランザクションのセマンティクスを必要とするユーザデータのみをモニタ及びバッファリングする。スタック、CLRヘルパーコードへの滞在の間に生じるデータアクセス又はCLRランタイム自身は、キャッシュモニタリング及びバッファリングを使用せず、従って、立ち退き（容量ミス）に基づくキャッシュ常駐のトランザクションのアボートに寄与しない。
【００７８】
先に記載されたように、トランザクションは、ハードウェアで実現されないキャッシュ容量又はセマンティクスの使用のため、HASTM又はSTMにフォールバックする前に、CRITM及びCRESTMのような様々なハードウェアアクセラレートモードで実行される。CRESTMにより、STM及びCRITMトランザクションの両者と相互運用することができる、キャッシュ常駐のSTMを順守する明示的なトランザクションのメモリモードが提供される。次いで、STMへのフォールバックが１つのトランザクションについて生じたとき、他のトランザクションは、CRESTMに切り替えることができるが、全てのトランザクションは、最も非効率なSTMモードにまで進む必要はない。同様に、アップグレードは徐々に行うことができ、最初に、STMトランザクションは、CRESTMモードにおけるシステムワークの残りの間で終了し、次いで、CRESTMトランザクションは、最も効率的なCRITMモードにおいてシステムの残りが既にある間に終了する。
【００７９】
本発明の実施の形態に係るアクセラレートされたメモリバリアを使用して、実行の特性は、ライトログのオーバヘッドを除き、グローバルプールからタイムスタンプを割り当てるためにハードウェアトランザクションの必要を除き、CRESTMトランザクションの間、及びCRESTMとSTMトランザクションとの間の同時並行性を増加し、CRESTMトランザクションとSTMトランザクションとの間の競合に適応的に反応することで改善される。
【００８０】
オブジェクトヘッダ（OH）は、CRITM及びCRESTMトランザクションモード内で使用される。これらのモードは、全てのOHの使用がTMの切り替えることができないとき、ハードウェアはオープンでネスト化されたトランザクションをサポートすることができないので、システムの他の部分により使用されるOHに関して比較及び保存（CAS：Compare  And  Save）プロトコルと相互作用する。OHへの所定の変更は永続性がある。ハッシュコード（HC）は、この観点で最も有名である。あるオブジェクトの安定したHCの要件は、SyncBlockIndex（SBI）への変更も永続性があることを更に含む。CRESTMについて、トランザクションがトランザクション・リード又はライトを使用してSyncBlock管理データ構造にアクセスしないため、抑圧（suppress）及び再入力（re-enter）する必要がない。トランザクション内で作成されたオブジェクトは、グローバルに見えないので、それらのヘッダへの変更もバッファリングされる。
【００８１】
CRESTMのSTMとの相互運用性は、グローバルバージョンのクロックシステムにおけるロックに関するハードウェアモードを提供する。以下の最も重要な想定が行われる。パブリケーションの正確さ（publication  correctness）を提供するためにグローバルバージョンのクロックスキームが使用され、プライバチゼーションの正確さ（privatization  correctness）を提供するためにコミットチケットプロトコル及びバッファリングされたライトの幾つかの形式が使用され、ライトロックは、（例えばOpenForWrite()を介して）エンカウンタタイムで取得され、コミットチケットを取得した後に、楽観的なリードがコミットタイムで認証される。
【００８２】
グローバルバージョンのクロックインテグレーションは、ハードウェアトランザクションにライトログを保持させることで、及び適切なコミットのフェーズの間にライト変数（WV：Write  Variable）でメタデータ（例えばトランザクションレコード又はトランザクションメタデータワード（TMW：Transaction  Metadata  Word））を更新するために実現される。ハードウェアアルゴリズムは、以下の通りである。ハードウェアトランザクションを開始し、書き込みの前にライトバリアを実行する。１実施の形態では、このバリアは、o.tmw=“locked  by  me”についてバッファリングされたライトであり、オブジェクトのアドレスは、トランザクション・ローカルライトログにログされ、TMWがモニタされる。リードバリアは、ロックされたビットがチェックされる各リードの前に実行され、（“locked  by  me”でない場合）ロックが存在する間にトランザクションはアボートされ、TMWがモニタされる。ボディ（body）が行われた後、WVは、抑圧領域におけるロジックを使用してこのトランザクションについて取得される。次いで、書き込まれたアドレスのリストは、バッファリングされたライトによりo.tmwをWVに更新するために使用され、ハードウェアトランザクションがコミットされる。従って、全てのライトロックが取得された後にWVが取得される。ハードウェアモードにおいて、“acquire  write  lock”は、モニタリングが適切なTMWに関して存在することを意味する。
【００８３】
このスキームは、ライトログを維持する必要のために乏しいパフォーマンスを有する。幾つかの実施の形態では、ライトログをもたないロックリスペクト（lock  respecting  without  a  write  log）となるようにすることが可能であり、従ってライトログを保持する必要が除かれる。グローバルバージョンのナンバリングの実現の最適化は、２つの想定を使用して行われる。第一に、STMトランザクションよりもCRESTMトランザクションが遥かに多いことが想定され、第二に、実際のデータ衝突がまれであることが想定される。第一の想定は、あるトランザクションのSTMへのフォールバックが、他のトランザクションがSTMに移行することを必要としないという事実により動機付けされる。STMへのフォールバックはまれであって、従って「被害者」は１つのトランザクションである一方、他のトランザクションは、CRESTMで実行し続ける。十分に並列なシステムでは、これは、STMトランザクションよりも多くのCRESTMトランザクションが存在することを意味する。第二の想定は、作業負荷に依存するが、一般に良好な設計のホールマークであり、従って成功したプログラムにおいて普及している。
【００８４】
CRESTMトランザクションは、ハードウェアグローバルバージョンナンバー（HGV）により示される共通のバージョン番号を使用し、トランザクションが変更しているオブジェクトをスタンプする。同時のCRESTMトランザクションによるライトが競合として正しく現れるように、STMトランザクションは、HGVがソフトウェアに基づくグローバルバージョンのナンバー（GV）よりも厳密に大きいことを保証する。HGVは、最大の同時並行性がデータの競合が生じない限り保証されるように、バッチで増加される。データの競合は、最も基本的なポリシーに退化させ、次いでより積極的なパスを徐々に再始動することで対処される。
【００８５】
ライトログをもたないロックリスペクトとなるため、ハードウェアトランザクションにおいて以下の動作が行われる。GV及びHGVの両者が０で開始すると想定する。それぞれのハードウェアトランザクションは、はじめに、スタンプ値（SV）＝HGVを設定する。HGVは、モニタリングで読み取られ、従ってHGVに対する書き込みは、全てのハードウェアトランザクションをドゥーム処理する。ライトバリアは、例えばo.tmw=SVについてバッファリングされたライトを使用して、書き込みの前に実行され、TMWがモニタされる。リードバリアは、ロックされたビットがチェックされ、ロックが存在する場合に関数がアボートされる各読み取りの前に実行され、TWMは、モニタされ、トランザクションは、チケットプロトコルでコミットする。従って、ハードウェアトランザクションについて、暫定的に変化したオブジェクトのログは保持されず、代わりに、暫定的に変化しているオブジェクトは、HGVでスタンプされ、トランザクションがコミットした場合、タイムスタンプは、データの変化と共に永続的となる。
【００８６】
それぞれのソフトウェアのトランザクションは、リード変数（RV）＝GVを設定する。（HGV<RV＋1）である場合、（CAS）（HGV，RV/*expected*/，GV＋1/*new*/）を比較及び設定する。ここでハードウェアが将来にスタンプすると、全ての現在のハードウェアトランザクションがドゥーム処理される。トランザクションの実行は、トランザクションがコミットする用意があるとき、例えばエンカウンタタイム等で取得されるロックといった、STMについてコンベンショナルである。ライト変数がインクリメント後のGVに等しいように、ライト変数（WV）が設定される。GVに対するインクリメントは、インフライトのハードウェアトランザクションがドゥーム処理され、このトランザクションがロールバックし、次いで再実行する場合に将来にスタンプされることを保証する。リードセットは、RVを使用して認証され、次いで全てのライトロックはWVを使用してリリースされる。ライトロックは保持されないが、マイナス面は、ソフトウェアトランザクションが別のソフトウェアトランザクションが終了した後に開始するたびに（コミット又はロールバックのため）、全てのハードウェアトランザクションがドゥーム処理されることである。この動作は、一度に１以上だけHGVを進めることで軽減される。例えば１０だけ進められる場合、全てのハードウェアトランザクションがドゥーム処理される前に幾つか他のソフトウェアトランザクションが終了した後に、更に１０のソフトウェアトランザクションが開始される。
【００８７】
従って、ソフトウェアトランザクションが開始したとき、ソフトウェアトランザクションは、GVをサンプリングし、回収された値をローカル変数RVに記憶する。ソフトウェアトランザクションは、プログラムで指定されたようにリード及びライトに作用するように続行する。トランザクションがコミットする用意があるとき、GVは、はじめに、インクリメントがGVにHGVの値に到達させるかを判定するためにチェックされる。インクリメントがGVにHGVの値に到達させると判定した場合、HGVは、（その値は以下に記載される）量Bによりインクリメントされる。
【００８８】
これらのルールは、競合が常に検出されることを保証するために必要な安全性を与える。一般に、競合の検出は、以下のように行われる。CRESTM対CRESTMの競合は、原データアクセス（raw  data  access）での競合としてハードウェアレベルで検出される。また、CRESTM対CRITMの競合は、原データアクセスでの競合としてハードウェアレベルで検出される。CRESTMトランザクションにより現在モニタ及び／又はバッファリングされているオブジェクトに対する競合するアクセスを偶然受けるSTMトランザクションは、CRESTMトランザクションにロールバックさせる。STMトランザクションによりアクセスされるデータを検証しているCRESTMトランザクションは、STMの検証フェーズの間までにSTMトランザクションにより検出される。オブジェクトにスタンプされたHGVがSTMトランザクションの開始で調べられるGVよりも必然的に大きい。
【００８９】
上述されたように、Bの値又は「バッチサイズ」は、HGVがGVからそれるのを許容される量である。先に説明されたように、GVがHGVの値に到達するときは、HGVはBだけインクリメントされる。これが発生するときは何時でも、全ての現在実行されているCRESTMトランザクションは、これらのトランザクションがHGVの位置を関ししているのでロールバックされる。従って、Bが大きいと、係る検証が行われる頻度が少ない。他方で、ひとたびSTMトランザクションが現在のGVよりも大きいバージョン番号をもつオブジェクトを観察すると、その次の再実行に関して、STMトランザクションは、オブジェクトを上手く読み取ることができるのを保証するため、GVをその高い番号に進める必要がある。Bが大きい場合、バージョンスペースを通した係る「スキップ」により、バージョンスペースは高速に使い果たされ、これは、バージョンスペースが制限され、ラップアラウンドが費用がかかるシステムについて懸案事項である（たとえばヒープにおける全てのオブジェクトの番号を付け直す場合がある）。
【００９０】
実施の形態は、異なるトランザクションによりアクセスされるデータがばらばらである限り、Bは大きくなることが許容されるが、シェアリングが検出されるとすぐ、Bの値が減少されるように、Bの値を調節する。このメカニズムにおける第一の要因は、効果的な検出方法である。すなわち、STMトランザクションは、「高い」HGV番号をもつハードウェアトランザクションにより生成された値を確かに読み取った高い確率で、区別することができる必要がある。これを実現するため、トランザクションは、オブジェクトが含むバージョンをGVに比較する。オブジェクトのバージョンが高い場合、オブジェクトは、HGVでスタンプされる。何れの場合であっても、トランザクションは、現在のGVよりも高いバージョン番号をもつオブジェクトを観察し、トランザクションは、該トランザクションが見た少なくともバージョンにGVを進める。
【００９１】
競合の状況が対処されるとすぐ、Bの値は、（非常に大きなバージョン空間をもつシステムについて、これは大した懸念ではない場合があるが）係る状況の再発がバージョン空間の消費の観点でコストが低いことを保証するために低減される。「高速の圧縮（shrink）／低速の成長（growth）」を許容する任意のポリシーを許容可能である。例えば、競合の状況が検出されたときは何時でも、Bの値が半分にされるが、１よりも小さくされず、HGVをBだけ増加するときは何時でも、Bの値も同様に、例えば１といった固定された量により、予め決定された上限値にまでインクリメントされる。
【００９２】
ここで図５を参照して、本発明の実施の形態に係る、ハードウェアトランザクションとソフトウェアトランザクションを同時に処理する方法のフローダイアグラムが示される。図５に示されるように、本方法５００は、ハードウェアトランザクションとソフトウェアトランザクションの両者についてコードパスを含む。はじめに、ハードウェアトランザクションに関して、HGVに等しいスタンプ値が設定される（ブロック５１０）。さらに、HGVがアップデートされるかについてハードウェアトランザクションが通知されるように、このスタンプ値のロケーションについてモニタリングが設定される（ブロック５１５）。ハードウェアトランザクションの実行の間、様々なリード及びライト動作が実行され、それらのそれぞれは、対応するリード又はライトバリアを使用して実現される。（ブロック５２０）。それぞれの係るバリアについて、例えば読取り又は書き込みされるロケーションに存在するロックのため、バリア処理が失敗したかが判定される（ひし形５２３）。バリア処理が失敗した場合、トランザクションがアボートされる（ブロック５３５）。所与のバリア処理が書き込み動作について成功した場合、書き込みデータは、バリアにおいて更新され、データは現在のHGVと関連される（ブロック５２５）。トランザクションの終わりで、HGVが変化したかが判定される（ひし形５３０）。HGVが変化した場合、これは、このハードウェアトランザクションとソフトウェアトランザクションとの間で競合が生じたことを示し、ハードウェアトランザクションはアボートする（ブロック５３５）。さもなければ、ブロック５４０に制御が進み、ブロック５４０で、それぞれ更新された値がメモリに記憶され、更新されたバージョン番号を示すためにHGVと関連付けされるように、アップデートがコミットされる。
【００９３】
ソフトウェアトランザクションについて、最初に、現在のGVNに対応する読取り値が設定される（ブロック５５０）。次いで、この読取り値のインクリメントにより、結果がHGVの現在の値よりも大きくなるかが判定される（ひし形５５５）。結果がHGVの現在の値よりも大きくなる場合、HGVがアップデートされ、このアップデートにより、全ての保留のハードウェアトランザクションは、ドゥーム処理される。具体的には、ダイアモンド５５５からブロック５６０に制御が移り、HGV値は、適応的なバッチサイズBにより更新される。ダイアモンド５５５及びブロック５６０の処理は、アトミックにcompare-exchangeを行う命令を使用してハードウェアでアトミックに行われる。ダイアモンド５５５又はブロック５６０の何れかから、ブロック５６５に制御が移り、ブロック５６５で、STMトランザクションが実行される。一般に、任意の書き込まれた値のオーナシップを得るためにソフトウェアロックを使用して、様々なデータが読み取られ、処理が実行され、値が更新される。係る処理の終わりで、トランザクションはコミットする用意があるかが判定される（ひし形５７０）。トランザクションがコミットする用意がある場合、ブロック５７５に制御が移り、GVNがインクリメントされる（ブロック５７５）。１実施の形態では、このインクリメンとは１である。この更新されたGVNは、ソフトウェアトランザクションに関連する書き込み値に記憶される（ブロック５８０）。なお、ブロック５７５及び５８０の処理は、例えばGVNの新たな値を書き込み値に戻すアトミックにインクリメントを行う命令を使用して、ハードウェアでアトミックに行われる。次いで、全ての読取りオブジェクトが読取り値よりも小さいか又は読取り値に等しいバージョン値を有するかが判定される（ひし形５８５）。全ての読取りオブジェクトが読取り値よりも小さいか又は読取り値に等しいバージョン値を有さない場合、トランザクションは、アボートされる（ブロック５９５）。代わりにひし形５８５の検証が成功した場合、ブロック５９０に制御が進み、ブロック５９０で、トランザクションがコミットされ、書き込み値は、書き込みセットにおける全てのオブジェクトについて新たなバージョン番号として使用される。言い換えれば、書き込みセットにおけるオブジェクトのライトロック（write  lock）は、これらにWVに等しい新たなバージョン番号を与えることでリリースされる。図５の実施の形態において特定の実現により示されているが、本発明の範囲は、この点に限定されない。
【００９４】
コード生成は、互いにトランザクション実行モードになる２つの最も独立な判定に分解する。第一に、コード生成スタイルは、NK（NaKed）モード又はトランザクショナルVTable（TV）を使用して行われる。第二に、ロールバックメカニズムについて、トランザクションを再実行するために判定が行われたとき、行われる変更がどのようにロールバックされるか、トランザクションの開始に制御がどのように移されるかが決定される。
【００９５】
コード生成スタイルについて、（同じシーケンシャルネストのメンバにより共有される）トランザクションコンテクスト構造は、トランザクションvtableと呼ばれるサブ構造で増大される。これは、そのエレメントが関数ポインタである構造であり、STMモードのSTM  JITヘルパーのそれぞれの種類について１つである。他のモードは、トランザクションvtableを動的に変えることで、同じTV生成コードが複数のモードについて使用されるように作成される。
【００９６】
トランザクションが不一致を検出するか又はアボートを明示的に検出したとき、全ての状態の変化がロールバックされ、トランザクションの開始に制御が戻る。CRESTM及び純粋なソフトウェアの例外に基づくメカニズムは、ロールバックを達成するために内部例外（internal  exception）を引き起こす。この例外は、コード生成の間にトランザクションの変換の一部として挿入された例外を除いて、ハンドラにより捕捉することができない。
【００９７】
トランザクションのネスト化が生じる場合がある。クロースのネスト化されたトランザクションの説明がはじめに与えられ、オープンのネスト化されたトランザクションの文脈でSuppressの動作が説明される。所与のハードウェアアーキテクチャは、ネスト化の任意の形式をサポートしない。代わりに、フラットモデルがサポートされる。フラットモデルがサポートされ、この場合、タッチされたキャッシュラインがバッファリング及びモニタリングされて、メモリにアトミックにコミットされるか、又はそれらの一時的な影響によりロールバックされ、トレースなしに消滅する。しかし、ネスト化されたトランザクションの失敗のアトミック性は、ネスト化されたトランザクションがロールバックした場合、その影響のみが取り消され、親のトランザクションの影響は（それでもまだ一時的に）保持される。
【００９８】
平坦化は、最適化技術であり、トランザクションがロールバックする可能性がなく、従ってネスト化された取り消し情報の収集が行われないことを想定する。一般的なアルゴリズムは以下の通りである。ネスト化されたアトミックブロックに入ったとき、ネスト化された閉じたトランザクションがセットアップされ、try/catchブロックがその実行の周りに配置される。ネスト化されたトランザクションがコミットした場合、これはよくある例であり、親の実行が再開され、子供の影響は親に組み込まれ、それらを選択的に取り消す必要が決して生じない。他方で、ネスト化されたトランザクションコードが例外を処理するために拒否する（percolate）場合、真のネスト化のサポートをもつシステムにおいて、ネスト化されたトランザクションのみがロールバックされ、例外は、親の環境において再び現れる。子のトランザクションが独立にロールバックすることができない実現において、全体のトランザクションのネストは、ロールバックされ、真のネスト化をサポートするモードで再実行される。
【００９９】
キャッシュ常駐のトランザクションのロールバックが行われる他の状況と同様に、以下のメカニズムが採用される場合がある。ネストのドゥーム判定が行われる時点で、何故トランザクションがロールバックされたか及びどのような種類の再実行が次に必要とされるかを本質的に示して、トランザクションのコンテクストに対して持続性書き込みが行われる。次いで、実行スタックがロールバックされ、全体のネストを囲んでいる例外のハンドラ（enclosing  exception  handler）は、例えば通常の例外を使用して実行される。平坦化の失敗からの回復は、HASTMモードにおける再実行により行われる。
【０１００】
大まかに言えば、CRESTMは、小さく且つ簡単なトランザクションが、他の制限されないSTMトランザクションの存在下でさえ、ロッキング又はロギングなしに実行するのを可能にし、高速且つリッチ、フル機能、制限されたウィークリ・アトミック・コレクト（limited-weakly-atomic-correct）TMプログラミングモデルを全体として提供する。明示的なモードトランザクションの使用により、ソフトウェアは、プライベートキャッシュのUTMトランザクショナルファシリティの重要な制限された状態の使用を最適化することができ、これにより、STMに対してオーバフローする前に、トランザクションを長く及び大きく実行することができる。例えば、スタックアクセス及び新たに割り当てられたオブジェクトは、モニタリング又はバッファリングを必要としない。実施の形態は、制限されたウィークリ・アトミック・コレクトな実現（バッファリング、ロギング、ロッキング）の最大のオーバヘッドを加速するため、効果的なキャッシュ常駐モードを提供する。様々な実施の形態では、ソフトウェア命令は、所定のユーザプログラムのデータアクセスのみを明示的に処理する。
【０１０１】
実施の形態は、多くの異なるシステムタイプにおいて実現される。図６を参照して、本発明の実施の形態に係るシステムのブロック図が示される。図６に示されるように、マイクロプロセッサシステム１０００は、ポイントツーポイント相互接続システムであり、ポイントツーポイント相互接続１０５０を介して結合される第一のプロセッサ１０７０及び第二のプロセッサ１０８０を含む。図６に示されるように、プロセッサ１０７０及び１０８０のそれぞれは、マルチコアプロセッサであり、潜在的に多くのコアがプロセッサに存在するが、第一及び第二のプロセッサコア（すなわちプロセッサコア１０７４ａ及び１０７４ｂ、並びにプロセッサコア１０８４ａ及び１０８４ｂ）を含む。プロセッサコアは、効果的な制限されないトランザクションを可能にするため、ハードウェア、ソフトウェア、又はその組み合わせを使用してTMトランザクションを実行する。
【０１０２】
更に図６を参照して、第一のプロセッサ１０７０は、メモリコントローラハブ（MCH）１０７２及びポイントツーポイント（P-P）インタフェース１０７６及び１０７８を更に含む。同様に、第二のプロセッサ１０８０は、MCH１０８２及びP-Pインタフェース１０８６及び１０８８を含む。図６に示されるように、MCH１０７２及び１０８２は、プロセッサをそれぞれのメモリ、すなわち、それぞれのプロセッサにローカルに取り付けられる（例えばダイナミックランダムアクセスメモリ（DRAM）といった）メインメモリの一部であるメモリ１０３２及びメモリ１０３４に結合する。第一のプロセッサ１０７０及び第二のプロセッサ１０８０は、P-P相互接続１０５２及び１０５４をそれぞれ介してチップセット１０９０に結合される。図６に示されるように、チップセット１０９０は、P-Pインタフェース１０９４及び１０９８を含む。
【０１０３】
さらに、チップセット１０９０は、P-P相互接続１０３９により、チップセット１０９０を高性能グラフィックエンジン１０３８に結合するインタフェース１０９２を含む。チップセット１０９０は、インタフェース１０９６を介して第一のバス１０１６に結合される。図６に示されるように、様々な入力／出力（I/O）装置１０１４は、第一のバス１０１６を第二のバス１０２０に結合するバスブリッジ１０１８と共に第一のバス１０１６に結合される。様々な装置は、１実施の形態では、例えばキーボード１０２２、通信装置１０２６、及びコード１０３０を含むディスクドライブ又は他の大容量ストレージ装置のようなデータストレージユニット１０２８を含む。さらに、オーディオI/O１０２４は、第二のバス１０２０に結合される。
【０１０４】
実施の形態は、コードで実現される場合があり、命令を実行するようにシステムをプログラムするために使用される命令を記憶した記憶媒体に記憶される。記憶媒体は、限定されるものではないが、フロプティカルディスク、光ディスク、固体ドライブ（SSD）、コンパクトディスクリードオンリメモリ（CD−ROM）、コンパクトディスクリライタブル（CD-RW）、及び光磁気ディスクを含む何れかのタイプのディスク、リードオンリメモリ（ROM）、ダイナミックランダムアクセスメモリ（DRAM）のようなランダムアクセスメモリ（RAM）、スタティックランダムアクセスメモリ（SRAM）、消去可能なプログラマブルリードオンリメモリ（EPROM）、フラッシュメモリ、電気的消去可能なプログラマブルリードオンリメモリ（EEPROM）のような半導体装置、磁気又は光カード、或いは電子的な命令を記憶するために適した他のタイプの媒体を含む。
【０１０５】
本発明は制限された数の実施の形態に関して記載されたが、当業者であれば、これらの実施の形態から様々な変更及び変形を理解されるであろう。特許請求の範囲は、本発明の真の精神及び範囲に含まれるものとして全ての係る変更及び変形をカバーすることが意図される。
【図１】
0005635620.tif 000008
【図２】
0005635620.tif 000009
【図３】
0005635620.tif 000010
【図４】
0005635620.tif 000011
【図５】
0005635620.tif 000012
【図６】
0005635620.tif 000013