(57)【特許請求の範囲】
【請求項１】
第一のユーザー・スレッドでの無制限トランザクショナル・メモリ（UTM）トランザクションの実行中に、前記第一のユーザー・スレッドからリング遷移を介してカーネル・モードにおいて制御を受け取る段階と；
前記カーネル・モードにある間に、前記UTMトランザクションの少なくとも一つのUTM属性をクリアし、前記第一のユーザー・スレッドに関連付けられたトランザクション状態レジスタ（TSR）の少なくとも一つのイベント・フィールドの状態を更新し、前記TSRを前記第一のユーザー・スレッドのコンテキストとともに保存する段階と；
前記TSRを含む前記第一のユーザー・スレッド・コンテキストをプロセッサに復元し、前記カーネル・モードから前記第一のユーザー・スレッドに遷移する段階とを含む方法であって、
前記カーネル・モードから前記第一のユーザー・スレッドへの遷移後に、前記TSRの前記少なくとも一つのイベント・フィールドの更新された状態に応じて、前記第一のユーザー・スレッドにおいてイジェクション・ハンドラを実行することをさらに含む、
方法。
【請求項２】
制御が前記カーネル・モードに遷移させられるとき、前記第一のユーザー・スレッドが前記UTMトランザクションをアボートしない、請求項１記載の方法。
【請求項３】
前記TSRの前記少なくとも一つのイベント・フィールドの更新された状態に基づいて、前記イジェクション・ハンドラにおける複数の復元コード経路のうちの一つを実行することをさらに含む、請求項１記載の方法。
【請求項４】
前記第一のユーザー・スレッドから前記カーネル・モードに遷移する前に前記UTMトランザクションおよび前記イジェクション・ハンドラをサスペンドさせる段階をさらに含み、該サスペンドは、前記TSRの少なくとも一つの状態インジケータを更新し、前記第一のユーザー・スレッドに関連付けられたトランザクション制御レジスタ（TCR）の制御インジケータを更新することを含む、請求項１記載の方法。
【請求項５】
前記第一のユーザー・スレッドから第二のユーザー・スレッドへの第一のコンテキスト・スイッチおよび前記第二のユーザー・スレッドからもとの前記第一のユーザー・スレッドへの第二のコンテキスト・スイッチを実行することをさらに含む、請求項１記載の方法。
【請求項６】
前記第二のユーザー・スレッドでのアプリケーションの実行中に、前記カーネル・モードにおいて、前記第二のユーザー・スレッドからリング遷移を介して制御を受け取り、前記カーネル・モードにある間に、UTMトランザクションの少なくとも一つのUTM属性をクリアし、前記第二のユーザー・スレッドがUTMトランザクションを実行していたのでない場合には、前記第二のユーザー・スレッドに関連付けられたTSR状態を更新しないことをさらに含む、請求項５記載の方法。
【請求項７】
命令を含む機械可読媒体を含む物品であって、前記命令は実行されたときに、システムに：
前記システムのユーザー・モードの第一のユーザー・スレッドで無制限トランザクショナル・メモリ（UTM）トランザクションを実行する段階と；
前記UTMトランザクションの実行中に、イベントに応答して、前記第一のユーザー・スレッドからカーネル・モードへの遷移を行なう段階と；
前記カーネル・モードに遷移する前に、前記UTMトランザクションをサスペンドするがアボートはしない段階とを実行させる、
前記イベントが例外を含み、前記システムに、前記第一のユーザー・スレッドに関連付けられたプロセッサの少なくとも一つのトランザクション・レジスタの少なくとも一つの状態フィールドを更新させる命令と、
前記システムに、前記カーネル・モードの前記例外ハンドラの実行に基づいて前記ユーザー・モードにおける複数のコード経路の一つを実行させる命令ををさらに含む、物品。
【請求項８】
前記システムに、前記例外に応答して実行される前記カーネル・モードの例外ハンドラから遷移を介して前記第一のユーザー・スレッドにおいて制御を受け取り、前記第一のユーザー・スレッドにおいて前記UTMトランザクションの実行を継続させる命令をさらに含む、請求項７記載の物品。
【請求項９】
前記複数のコード経路が、ユーザー・オペレーティング・システム（OS）ランタイム・システムのユーザー・モード例外ディスパッチャと、UTMランタイム・システムのユーザー・モード例外ディスパッチャと、前記UTMランタイム・システムのイジェクション・ハンドラとを含む、請求項７記載の物品。
【請求項１０】
前記システムに、前記少なくとも一つのトランザクション・レジスタの前記少なくとも一つの状態フィールドの更新された状態に基づいて、前記イジェクション・ハンドラ中の複数の復元コード経路の一つを実行させる命令をさらに含む、請求項９記載の物品。
【請求項１１】
それぞれ無制限トランザクショナル・メモリ（UTM）トランザクションのある側面を制御する複数のインジケータを有するトランザクション制御レジスタ（TCR）と、それぞれ前記UTMトランザクションの状態を示す複数のインジケータを有するトランザクション状態レジスタ（TSR）とを含む第一のレジスタ・セットを含むプロセッサと；
命令を含む記憶媒体とを有するシステムであって、
前記命令は、当該システムが、第一のユーザー・スレッドでのUTMトランザクションの実行中に、該UTMトランザクションの間に発生した例外に応答して、カーネル・モードにおいて、ユーザー・モードの前記第一のユーザー・スレッドから遷移を介して制御を受け取り、前記カーネル・モードにおいて前記例外に対処するかどうかを決定し、もし対処するなら、前記カーネル・モードにおいて前記例外に対処し、もしそうでないなら、前記例外の型および前記UTMトランザクションのUTM実装方式に基づいて、制御を移すべき前記ユーザー・モードの複数のコード経路のうちの一つを選択する、ことを可能にする、
システム。
【請求項１２】
前記命令がさらに、前記システムが、前記ユーザー・モードに制御を遷移させる前に、前記例外の発生を示すために、前記カーネル・モードにある間に、TSRの少なくとも一つのイベント・フィールドを更新できるようにする、請求項１１記載のシステム。
【請求項１３】
前記命令がさらに、前記システムが、UTMランタイム・システムが前記UTM実装方式について前記例外に対処するためのコード経路を含むかどうかを判定できるようにする、請求項１１記載のシステム。
【請求項１４】
前記命令がさらに、前記システムが、前記UTMランタイム・システムが前記コード経路を含まない場合に、前記UTMランタイム・システムのイジェクション・ハンドラを前記コード経路として選択できるようにする、請求項１３記載のシステム。
【請求項１５】
前記イジェクション・ハンドラが複数の実行経路を含み、各実行経路は異なるイベントに関連付けられており、さらに、前記命令は、前記システムが、前記TCRおよび前記TSRの少なくとも一方における情報の解析に基づいて前記イジェクション・ハンドラにおける実行経路の一つを実行できるようにする、請求項１４記載のシステム。
【請求項１６】
前記命令がさらに、前記システムが、前記カーネル・モードへの遷移の前に前記UTMトランザクションをサスペンドさせるがアボートはしないことをできるようにする、請求項１４記載のシステム。
【請求項１７】
前記命令がさらに、前記システムが、前記カーネル・モードにおいて複数のエントリーを含むテーブルにアクセスできるようにし、各エントリーはUTM実装方式、例外型および前記UTM実装方式および前記例外型に基づいて実行されるべき前記UTMランタイム・システムのコード経路を含む、請求項１３記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は無制限トランザクショナル・メモリ（UTM）モードでのオペレーティング・システム（OS）トランザクションの処理に関する。
【背景技術】
【０００２】
無制限トランザクショナル・メモリ（UTM:  unbounded  transactional  memory）は、ハードウェアおよびソフトウェアを使ったハードウェア加速の組み合わせを通じて、時間およびメモリ占有の点で任意に大きなトランザクションを行えるようにする。UTMトランザクションの実行および実装は、UTMハードウェア加速インターフェースとの並行制御機構を実装するために、典型的には特別にコンパイルされたコードを必要とする。結果として、UTMのコンパイルされたコードの実行がユーザー・レベルの非同期イベントおよびUTM実行のためにコンパイルされていないユーザー・ランタイム・コードのその後の実行によって介入される場合には、UTMトランザクションは、正しく動作しないことがある。
【０００３】
ユーザー・レベルの非同期イベントの主要な原因の一つは、ユーザー・レベル例外（またはシグナル）ハンドラにおけるハードウェア例外の処理である。例外とは、プログラム実行中に起こる、通常の制御の実行フロー外の、例外ハンドラと呼ばれる特別なコード経路の実行を必要とするイベントである。ハードウェア例外条件がハードウェアによって検出され、オペレーティング・システム（OS）に報告される。ハードウェア例外の例は、零による除算演算または無効なメモリ・アドレス位置にアクセスしようとする試みである。そのような例外が発生すると、制御は典型的にはユーザー・レベルのコードからOSに移る。OSがそのような例外イベントを処理するよう制御を受け取ると、OSは典型的には、その例外を、その例外を生じさせたプログラムに関連付けられた適正な例外ハンドラにディスパッチしようと試みる。
【０００４】
ハードウェア例外が検出され、ユーザー・モード・プログラムから生じさせられる場合、OSは典型的には例外情報を収集し、それをユーザー・スタックに転送し、ユーザー・モードに遷移して戻り、例外をユーザー・モード例外ハンドラにディスパッチする。ウィンドウズ（登録商標）、ユニックスおよびリナックス（登録商標）OSのような多くの現代のオペレーティング・システムにおいては、UTM実行のためにコンパイルされていない、デフォルトのユーザー・レベルのランタイム・コードが、オペレーティング・システムからのユーザー・モード例外（シグナル）のディスパッチ要求を扱うよう設けられる。したがって、UTMアプリケーションおよびそのランタイム・システムは、UTMトランザクションの間、例外処理ならびにユーザー・レベルの例外ディスパッチおよび処理コードの非同期呼び出しに対処するための深刻な技術的課題に直面する。
【０００５】
たとえば、OSユーザー・ランタイム・コードの非同期的実行の主要な原因の一つは、シグナル・プログラミング（たとえば、ユニックス・オペレーティング・システムにおけるシグナル）およびユーザー・レベルの例外処理（たとえばウィンドウズ（登録商標）・オペレーティング・システムにおけるSEH）をサポートするためにOSカーネル・コードからの例外ディスパッチ要求にサービスすることである。OSカーネルから要求を受け取ってターゲット例外ハンドラに例外をディスパッチするためのこのユーザー・モードのサービス・ルーチンは、オペレーティング・システムによって提供されるデフォルトのユーザー・ランタイム・システムの一部である。既存のOSカーネル・コードおよびOSユーザー・ランタイム・コードはUTMランタイム・システムの一部ではなく、UTM実装方式およびさまざまなUTMハードウェア動作モードについて限られた知識しかもたないか、全く知識をもたない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
結果として、UTMトランザクションの間のOSユーザー・ランタイム・コードへの非同期的ディスパッチおよびOSユーザー・ランタイムのその後の実行の結果、正しくない動作および結果を生じることがある。一つの単純な解決策は、UTM例外の間にハードウェア例外があったら常にペンティング・トランザクションのアボートを引き起こし、UTMランタイム・システムが、UTMハードウェア加速なしで、ソフトウェア・トランザクショナル・メモリ（STM:  software  transactional  memory）モードにおいて当該トランザクションをリスタートできるようにするというものである。しかしながら、この解決策は、UTMスレッドについての有意なパフォーマンスの速度低下につながる。プログラムが、浮動小数点例外フィルタリングのような頻繁な例外処理を含む場合は特にそうである。よって、UTMスレッドは高価なアボートおよびリスタート動作をしなければならず、ある種のトランザクション・コード実行について、UTMハードウェア加速が実現できない。
【課題を解決するための手段】
【０００７】
本願の課題は請求項記載の手段によって解決される。
【図面の簡単な説明】
【０００８】
【図１】本発明のある実施形態に基づくプロセッサのブロック図である。
【図２】本発明のある実施形態に基づくプロセッサにおけるデータ項目についてのメタデータの保持のブロック図である。
【図３】本発明のある実施形態に基づくソフトウェア・アーキテクチャのブロック図である。
【図４】本発明のある実施形態に基づく非同期ソフトウェア定義の（UTM）イベントを送達する方法の流れ図である。
【図５】本発明のある実施形態に基づくUTMトランザクション中の、例外またはオペレーティング・システム（OS）への他の遷移の処理についての流れ図である。
【図６】本発明のある実施形態に基づく、ユーザー・スレッドにおいてUTMトランザクション・コードおよびUTMランタイム・システム・コードを実行するための流れ図である。
【図７】本発明のある実施形態に基づく、コンテキスト切り換え動作を扱うための方法の流れ図である。
【図８】本発明のある実施形態に基づくシステムのブロック図である。
【発明を実施するための形態】
【０００９】
さまざまな実施形態において、プロセッサにおけるハードウェア・サポートと無制限トランザクショナル・メモリ（UTM）ランタイム・システムに関連付けられたコード、UTMユーザー・レベル・コードおよびオペレーティング・システム（OS）コードとの組み合わせによって、UTMトランザクションの改善された処理が可能にされうる。具体的には、諸実施形態は、UTMトランザクションの間に発生しうる例外、割り込みなどの改善された処理を可能にしうる。このようにして、例外または他の形でのUTMトランザクションからの制御の移転に際してトランザクションを自動的にアボートする必要なしに、UTMトランザクションのために行われた作業が維持されうる。のちにさらに論じるように、そのようなトランザクションを扱う種々の機構が提供されうる。一般に、これらの機構は、ユーザー・モードで実行されているUTMスレッドからカーネル・モードに抜ける際にトランザクションをサスペンドし、カーネル・モードでUTM可知（UTM-aware）処理を行うことを可能にしうる。それにより、ユーザー・レベルのUTMスレッドに戻ったとき、必ずしも当該トランザクションをアボートすることなく当該トランザクションを再開することが可能となりうる。
【００１０】
本発明の範囲はこの点で限定されるものではないが、諸実施形態は、UTM動作のためのハードウェア・サポートを提供するシステムにおいて実装されてもよい。使用される概念および用語を紹介するため、そのようなハードウェア・サポートの背景をここで与えておく。しかしながら、本発明の範囲はそのようなハードウェアに限定されるものではなく、諸実施形態はいかなるUTMシステムにおいて実装されることもできることは理解しておくものとする。
【００１１】
本稿での用法では、「スレッド」はハードウェア・スレッド（たとえば、プロセッサにおける状態記憶を含む論理的なプロセッサ）を指すことがある。「エージェント」はコヒーレントなメモリ・アクセスを行うスレッドまたは他のシステム資源である。メモリのほうは、モニタリング・ブロック（MBLK）に論理的に分割されることができる。各MBLKについて、各スレッドは専用のモニタのセット、すなわちソフトウェアが読み出しおよび書き込みすることのできる読み出しモニタ（RM:  read  monitor）および書き込みモニタ（WM:  write  monitor）をもつ。RMおよびWMは直交であり（orthogonal）、一緒になって三つの異なるMBLKモニタ・モードをエンコードする：モニタリングなし（RM＝0、WM＝0）では、MBLKは他のエージェントによるアクセスについてモニタリングされない；読み出しモニタリング（RM＝1、WM＝0）では、MBLKは他のエージェントによる書き込みについておよびモニタ喪失についてモニタリングされる；書き込みモニタリング（(RM＝0、WM＝1)および(RM＝1、WM＝1)）では、MBLKは他のエージェントによるアクセスについておよびモニタ損失についてモニタリングされる。
【００１２】
モニタ喪失が起こるのは、MBLKのモニタが自発的に、モニタリングされない状態にリセットされるときである。モニタリングされるモードからモニタリングされないモードへの遷移はモニタ喪失イベントを生成する。あるエージェントが、別のエージェントが書き込みモニタリングしたMBLKにアクセスするとき、あるいはあるエージェントが、別のエージェントが読み出しモニタリングしたMBLKに書き込むときに、衝突するアクセスが起こりうる。スレッドがモニタリングしていたMBLKに別のエージェントが衝突するアクセスを実行して、そのMBLKのモニタ・モードをモニタリングなしにリセットさせるときに、モニタ衝突が起こる。モニタ衝突は、モニタ衝突イベントとモニタ喪失イベントの両方を生成する。モニタリングされるアクセスは、命令実行に先立ってモニタリングを試験する、または実行の一環としてモニタリングを設定するアクセスである。モニタリングされないアクセスは、モニタリングを修正も試験もしないアクセスである（換言すれば、振る舞いは、メモリ・アクセスのための典型的な命令セット・アーキテクチャ（ISA:  instruction  set  architecture）のセマンティクスと同一である）。
【００１３】
メモリはまた、バッファリング・ブロック（BBLK）にも論理的に分割できる。各BBLKについて、各スレッドは、バッファリング属性（BUF）の専用のインスタンスをもつ。可視（visible）（BUF＝0）は、BBLKのメモリへのすべての書き込みがグローバルに観察されることを意味する。バッファリングされる（BUF＝1）は、BBLKのメモリ範囲へのすべての書き込みが、それらの書き込みを発したスレッドによってローカルに観察されるが、他のエージェントによってグローバルに観察されることはないことを意味する。ソフトウェアが、個々のBBLKについてバッファリングされる属性を設定してもよいし、すべてのBBLKについてバッファリングされる属性をリセットしてもよい。二つの異なるアクションにより、バッファリングされる属性が1から0に遷移させられることができる。BBLK破棄は、最後に0から1に遷移したバッファリングされる属性以来の、ローカル・スレッドによるBBLKのメモリへのいかなる書き込みをも破棄し、BBLKコミットは、そのような書き込みを、取り消し不可能な仕方でグローバルに観察可能にする。バッファリング喪失イベントは、何らかのスレッドの何らかのバッファリングされる属性が自発的に0にリセットされて、BBLK破棄を実行するときに生じる。さらに、書き込みモニタ喪失はバッファリング喪失を含意する。所与のスレッド上で、あるBMLKについて書き込みモニタ喪失が発生すると、そのMBLKアドレス範囲内のすべてのBBLKはバッファリング喪失を被る。
【００１４】
メモリはまた、さまざまなサイズのメタデータブロック（MDBLK）の諸セットにも、さまざまな使用コンテキストのために、論理的に分割できる。MDBLK、あるいはより特定的にMDBLK[CR][MDID]は、圧縮比（CR:  compression  ratio）およびメタデータ・コンテキストID（MDID:  metadata  context  ID）によってパラメータ化できる。各MDBLK[CR][MDID]について、各スレッドはメタデータ属性（META）の専用のインスタンスをもつ。
【００１５】
所与のCRについて、相異なるMDIDはいくつあってもよい。各MDIDはメタデータの一意的なインスタンスを指定する。所与のCRおよびMDIDについてのメタデータは、他のいかなるCRまたはMDIDについてのメタデータとも区別される。所与の実装は複数の並行コンテキストをサポートしてもよい。コンテキストの数はCRおよびプロセッサが一部をなす特定のシステムに関係するある種の構成設定情報に依存するであろう。ある実施形態では、圧縮されないメタデータについて、物理データの各QWORDについて、メタデータのクワッド語（quadword）QWORDがあることができる。メタデータはソフトウェアによってのみ解釈される。ソフトウェアは、特定のMDBLK[CR][MDID]についてMETAを設定、リセットまたは試験してもよく、スレッドのすべてのMDBLK[*][*]についてのMETAをリセットしてもよく、所与のMBLK(アドレス)に交わりうるスレッドのすべてのMDBLK[CR][MDID]についてのMETAをリセットしてもよい。スレッドのいかなるMETA属性も、自発的に0にリセットされて、メタデータ喪失イベントを生成してもよい。
【００１６】
モニタリング範囲は、ベースおよび広がりによって同定される、単一の仮想メモリ・ページに対応する仮想アドレスの指定された範囲である。この機能が有効にされると、スレッドによって読まれる範囲内のアドレスをもついかなるメモリも、範囲読み出しモニタリング属性を与えられる。同様に、スレッドによって書き込まれる範囲内のアドレスをもついかなるメモリも、範囲書き込みモニタリング属性を与えられる。これらの属性は、ハードウェアによって自発的に除去されてもよい。別のエージェントがそのメモリ位置に書き込む場合、両方の属性が除去される。別のスレッドが、範囲書き込みモニタリング属性をもつ位置を読み出す場合、その属性が除去される。範囲モニタリング属性が除去されるときは常に、喪失範囲モニタリング・イベントが生成される。こうして、一般に、UTMトランザクションのハードウェア加速は、モニタリング、バッファリングおよびメタデータ属性を使って実現されることができる。
【００１７】
UTMイベントは、UTMハードウェアによって捕捉されることができ、その後、該UTMハードウェアに、UTMイベント・ハンドラを呼び出すイジェクション（ejection）をトリガーさせるイベントである。イジェクションは、プロセッサのアプリケーション・レベルのトランザクション・イジェクションIP（TEJECTIP）レジスタによって指定されるイジェクション・ターゲット命令ポインタ（IP  instruction  pointer）への非同期的な制御の移転である。各スレッドは、イジェクション・ハンドラ内に関連付けられたUTMイベント・ハンドラ・エントリー点を有していてもよい。イジェクション・ハンドラは、TEJECTIPレジスタによって指定される命令ポインタ（IP）位置において与えられるコードであることを注意しておく。そのスレッドに関連付けられたUTMイベント・ハンドラは、イジェクション・ハンドラによって呼び出されてもよい。UTMランタイム・システムは、該UTMランタイム・システムの実装に依存して、TEJECTIPレジスタを、UTMイベント・ハンドラを直接ポイントするよう構成設定してもよいし、あるいはイジェクション・ハンドラがテーブル・ルックアップによってUBTイベント・ハンドラをコールできるようそのポインタを含むテーブルを生成してもよい。個々のイベントに応答して、ある種の状態レジスタ・イベント追跡ビットが設定されてもよく；それに応答して、制御がハンドラに移転してもよい。さまざまな実施形態において、この移転は、特権レベルの変更を伴わないことを注意しておく。ただし、ある種の動作の解釈は、ハンドラ内で実行するときには修正されることがある。制御は、ユーザー・レベルの制御移転命令によってUTMアプリケーションのメインラインに返されることができ、UTMアプリケーションにおける実行がプログラムの何らかの定義された再開点において再開されることができる。
【００１８】
非同期UTMイベントは、当該スレッドによって実行されるいかなる特定の命令にも帰することのできないイベントである。非同期イベントは、スレッドに関連付けられているモニタリング、バッファリングおよびメタデータ属性における変化に関係することがある。これらの変化は、他のエージェントのアクションによってトリガーされることもあるし、ハードウェアによって自発的にトリガーされることもある。例としての非同期イベントは、モニタ喪失イベント、読み出しモニタ喪失、書き込みモニタ喪失、モニタ衝突イベント、読み出しモニタ衝突、書き込みモニタ衝突、バッファリング喪失イベント、メタデータ喪失イベントおよび範囲モニタリング喪失イベントを含む。
【００１９】
同期イベントは、現在命令がリアイアしないような命令実行の通常のフローを破る障害（fault）であり、同期UTMイベント（SynchEvent）はスレッド中の特定の既知の命令を実行する（だが必ずしもリタイアしない）ことの副作用として現れるイベントである。
【００２０】
ある実施形態では、読み出し‐書き込みトランザクション制御レジスタ（TCR:  transaction  control  register）があってもよい。これは、スレッドに関連付けられた制御レジスタであり、イベントがハンドラ呼び出しを引き起こすときなどにUTM動作を制御できる複数のインジケータ（たとえばビット）を含んでいてもよい。イベントがハンドラを呼び出すのは、その状態が、スレッドに関連付けられた状態レジスタでありかつ複数のインジケータを含んでいてもよいトランザクション状態レジスタ（TSR:  transaction  status  register）において設定されており、その対応するイベント・ハンドラ・イネーブルがTCRにおいてセットされている場合のみである。イベント状態は、対応するハンドラ・イネーブルがセットされているかどうかに関わりなく、TSR中に蓄積し続けることがある。TCRの諸ビットは、特定の同期イベントが、TSRにおいて捕捉される資格があるかどうかおよびハンドラがTSRにおける対応する同期イベント状態に際して呼び出されうるかどうかをも制御してもよい。一般に、TCRは、喪失イベントまたはトランザクション中に生起する他のイベントのような対応するイベントについてのハンドラを有効にするイネーブル・インジケータを含んでいてもよい。
【００２１】
TSRのほうは、最近のUTMイベント型の蓄積を含め、UTM状態情報を提供する。例として、TSRは、トランザクション中にさまざまなUTM属性が使われているかどうかに関する状態インジケータに加えて、それぞれトランザクション中に発生する喪失イベントのようなイベントの存在を示す複数のインジケータを含んでいてもよい。このレジスタは、すべての非同期UTMイベントに加え、資格のある同期TMイベントを連続的に蓄積する。ある実施形態では、TSRを汎用レジスタ（GPR:  general  purpose  register）に読み込むことは、その時点に蓄積されている任意のイベント（非同期でも同期でも）のスナップショットを提供することができる。同期および非同期UTMイベントに加えて、諸実施形態は、ソフトウェア定義されたUTMイベントに対する備えをしていてもよい。これは、TSRの対応するインジケータまたはフィールドに値を書き込むことを通じて注入されることができる。そのような実施形態では、TSRの一つまたは複数のフィールドがソフトウェア定義されるイベントのためにリザーブされることができる。TSR中のソフトウェア・イベント・フィールドに零でない値が書き込まれるとき、ハードウェアはこれらの更新を、UTMハードウェア・イベントと同じに扱い、イジェクションをトリガーしてもよい。イジェクションがサスペンドされないとき、TSR中のソフトウェア・イベント・フィールドに零でない値をもつと、TEJECTIPレジスタによって指定されるイジェクション・ハンドラへの制御の自発的な移転につながりうる。UTMランタイム・システムによって提供されるイジェクション・ハンドラは、イジェクションの原因（単数または複数）を見出すためにTSR中の値を検査してもよい。
【００２２】
さらなる背景として、本発明のある実施形態に基づくUTMトランザクションのために使用できる例示的なハードウェアを見ておくことは有益である。図１を参照するに、並行して複数スレッドを実行できるプロセッサのある実施形態が示されている。プロセッサ１００は、ハードウェア・トランザクション実行のためのハードウェア・サポートを含んでいてもよいことを注意しておく。本発明のある実施形態によれば、ハードウェア・トランザクション実行と関連してまたは別個に、プロセッサ１００は、STMのハードウェア加速、STMの別個の実行またはそれらの組み合わせ、たとえばUTM、のためのハードウェア・サポートをも提供してもよい。プロセッサ１００は、マイクロプロセッサ、組み込みプロセッサ、デジタル信号プロセッサ（DSP）、ネットワーク・プロセッサまたはコードを実行する他のデバイスのようないかなる型のプロセッサであってもよい。図示したところでは、プロセッサ１００は複数の処理要素を含む。
【００２３】
図１に示すところでは、物理的なプロセッサ１００は、高レベル・キャッシュ１１０を共有する二つのコア、コア１０１および１０２を含む。プロセッサ１００は非対称なコア、すなわち異なる構成、機能単位および／または論理をもつコアを含んでいてもよいが、対称的なコアが図示されている。結果として、コア１０１と同一のものとして示されるコア１０２は、反復的な議論を避けるため、詳細に論じることはしない。さらに、コア１０１は二つのハードウェア・スレッド１０１ａおよび１０１ｂを含み、一方、コア１０２は二つのハードウェア・スレッド１０２ａおよび１０２ｂを含む。したがって、オペレーティング・システムのようなソフトウェア・エンティティは、潜在的に、プロセッサ１００を、四つのソフトウェア・スレッドを並行して実行できる四つの別個のプロセッサ、すなわち四つの論理的なプロセッサまたは処理要素として見る。
【００２４】
ここで、第一のスレッドはアーキテクチャ状態レジスタ１０１ａに関連付けられ、第二のスレッドはアーキテクチャ状態レジスタ１０１ｂに関連付けられ、第三のスレッドはアーキテクチャ状態レジスタ１０２ａに関連付けられ、第四のスレッドはアーキテクチャ状態レジスタ１０２ｂに関連付けられる。図示したところでは、アーキテクチャ状態レジスタ１０１ａはアーキテクチャ状態レジスタ１０１ｂに複製されており、よって、個々のアーキテクチャ状態／コンテキストが論理プロセッサ１０１ａおよび論理プロセッサ１０１ｂのために記憶されることができる。アーキテクチャ状態レジスタは、ある実施形態では、UTMトランザクションを実装するのに使うレジスタ、たとえばTSR、TCRおよびTEJECTIPレジスタを含む。命令ポインタおよび名前変更割り当て器論理１３０における名前変更論理のような他のより小さな資源も、スレッド１０１ａと１０１ｂについて複製されていてもよい。並べ替え／リタイア・ユニット１３５における並べ替えバッファ、命令トランスレーション・ルックアサイド・バッファ（ITLB:  instruction  translation  lookaside  buffer）１２０、ロード／ストア・バッファおよび待ち行列のようないくつかの資源がパーティショニング（partitioning）を通じて共有されてもよい。汎用内部レジスタ、ページ・テーブル・ベース・レジスタ、低レベルデータ・キャッシュおよびデータTLB  １１５、実行ユニット（単数または複数）１４０および順序外ユニット１３５の諸部分のような他の資源は潜在的には完全に共有される。
【００２５】
図示したところでは、プロセッサ１００は、システム・メモリ１７５、チップセット、ノースブリッジまたは他の集積回路のようなプロセッサ１００の外部の装置と通信するためのバス・インターフェース・モジュール１０５を含む。メモリ１７５はプロセッサ１００の専用であってもよいし、システム中の他のデバイスと共有されてもよい。より高レベルのまたはさらに外側の（further-out）キャッシュ１１０は、より高レベルのキャッシュ１１０からの最近フェッチされた要素をキャッシュする。より高レベルまたはさらに外側というのは、実行ユニット（単数または複数）から増大する、または遠ざかるキャッシュ・レベルをいうことを注意しておく。ある実施形態では、より高レベルのキャッシュ１１０は第二レベルのデータ・キャッシュである。しかしながら、より高レベルのキャッシュ１１０はそれに限定されず、命令キャッシュに関連付けられるまたは命令キャッシュを含むこともできる。最近デコードされたトレースを記憶するために、トレース・キャッシュ、すなわちある型の命令キャッシュが代わりにデコーダ１２５の後に結合されてもよい。モジュール１２０はまた、潜在的には、実行される／採用されるブランチを予測するためのブランチ・ターゲット・バッファ（branch  target  buffer）と、命令のためのアドレス変換エントリーを記憶するITLBとを含む。
【００２６】
デコード・モジュール１２５は、フェッチされた要素をデコードするよう、フェッチ・ユニット１２０に結合される。ある実施形態では、プロセッサ１００は、プロセッサ１００上で実行可能な命令を定義／指定するISAに関連付けられる。ここで、しばしば、ISAによって認識される機械語命令は、オペコードと称される命令部分を含む。オペコードは、実行されるべき命令または動作を参照／指定する。
【００２７】
一例では、割り当て器および名前変更器ブロック１３０は、命令処理結果を記憶するためのレジスタ・ファイルのようなレジスタをリザーブするための割り当て器を含む。しかしながら、スレッド１０１ａおよび１０１ｂは潜在的には順序外実行もでき、ここでは、割り当て器および名前変更器ブロック１３０は、命令結果を追跡するための並べ替えバッファのような他の資源をもリザーブする。ユニット１３０は、プログラム／命令参照レジスタをプロセッサ１００内部の他のレジスタに名前変更するレジスタ名前変更器をも含んでいてもよい。並べ替え／リアイア・ユニット１３５は、順序外実行およびその後の順序外実行された命令の順序内リアイアをサポートするために、上述した並べ替えバッファ、ロード・バッファおよびストア・バッファのようなコンポーネントを含む。
【００２８】
スケジューラおよび実行ユニット・ブロック１４０は、ある実施形態では、実行ユニット上での命令／動作をスケジュールするスケジューラ・ユニットを含む。たとえば、浮動小数点命令が、利用可能な浮動小数点実行ユニットをもつ実行ユニットのポート上にスケジュールされる。実行ユニットに関連付けられるレジスタ・ファイルも、情報命令処理結果を記憶するために含められる。例示的な実行ユニットは、浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、ストア実行ユニットおよび他の既知の実行ユニットを含む。
【００２９】
低レベル・データ・キャッシュおよびデータ・トランスレーション・バッファ（D-TLB）１５０が実行ユニット（単数または複数）１４０に結合される。データ・キャッシュは、データ・オペランドのような要素に対して最近使われた／作用された要素を記憶する。そうした要素は潜在的には、メモリ・コヒーレンシー状態に保持される。D-TLBは最近の仮想／線形アドレスから物理アドレスへの変換を記憶する。具体例として、プロセッサは、物理メモリを複数の仮想ページに分解するページ・テーブル構造を含んでいてもよい。
【００３０】
ある実施形態では、プロセッサ１００はハードウェア・トランザクション実行、ソフトウェア・トランザクション実行またはそれらの組み合わせもしくはハイブリッドが可能である。コードの決定的（critical）または原子的（atomic）なセクションとも称されうるトランザクション（transaction）は、原子的な群として実行されるべき命令、演算またはマイクロ演算のグループ化を含む。たとえば、命令または演算は、トランザクションまたは決定的なセクションを画定するために使われてもよい。ある実施形態では、これらの命令は、上記のデコーダのようなプロセッサ１００のハードウェアにより認識可能なISAのような命令のセットの一部である。しばしば、これらの命令は、ひとたび高レベル言語からハードウェアが認識可能なアセンブリ言語にコンパイルされると、動作コード（オペコード）またはデコード段の間にデコーダが認識する命令の他の部分を含む。
【００３１】
典型的には、トランザクションの実行中は、トランザクションがコミットされるまで、メモリへの更新はグローバルに可視にされない。たとえば、ある位置へのトランザクション書き込みは、ローカルなスレッドに対して潜在的に可視であるが、そのトランザクション書き込みを含むトランザクションがコミットされるまでは、別のスレッドからの読み出しに応答して書き込みデータは転送されない。トランザクションがいまだペンディングである間は、メモリ内からロードされ、メモリ内に書き込まれるデータ項目／要素は追跡される。これについてはのちにより詳細に論じる。ひとたびトランザクションがコミット点に達すると、そのトランザクションについて衝突が検出されていなければ、そのトランザクションはコミットされ、そのトランザクション中になされた更新がグローバルに可視にされる。
【００３２】
しかしながら、そのトランザクションがペンディング中に無効にされる場合、そのトランザクションはアボートされ、潜在的に、更新をグローバルに可視にすることなくリスタートされる。結果として、本稿で用いるところでのトランザクションのペンディング状態は、実行を開始しており、まだコミットもアボートもされていない、すなわちペンディングであるトランザクションをいう。
【００３３】
ある実施形態では、プロセッサ１００は、ハードウェア／論理を使って、すなわちハードウェア・トランザクショナル・メモリ（HTM:  Hardware  Transactional  Memory）システム内で、トランザクションを実行することができる。HTMを実装する際には、アーキテクチャおよびマイクロアーキテクチャの両方の観点から、数多くの個別的な実装の詳細が存在し、そのほとんどは本発明の実施形態を無用に埋没させることを避けるためにここでは論じない。しかしながら、いくつかの構造および実装は例示的な目的のために開示される。しかしながら、これらの構造および実装は必須ではなく、異なる実装詳細をもつ他の構造で増強および／または置換されてもよい。
【００３４】
一般に、プロセッサ１００は、STMシステムおよびHTMシステム両方の利点を活用しようと試みるUTMシステム内でトランザクションを実行することができてもよい。たとえば、HTMは、トランザクションについてのアクセス追跡、衝突検出、有効確認およびコミットのすべてを実行するためにソフトウェアに頼らないので、小さなトランザクションを実行するために高速かつ効率的である。しかしながら、STMが無制限のサイズのトランザクションを扱うことができる一方、HTMは通例、より小さなトランザクションを扱うことができるだけである。したがって、ある実施形態では、UTMシステムは、より小さなトランザクションを実行するためにハードウェアを利用し、ハードウェアにとっては大きすぎるトランザクションを実行するためにソフトウェアを利用する。以下の議論から見て取れるように、ソフトウェアがトランザクションを扱っているときでも、ハードウェアがソフトウェアを支援および加速するために利用されてもよい。同じハードウェアが純粋なSTMシステムをサポートおよび加速するために利用されてもよい。
【００３５】
上述したように、トランザクションは、プロセッサ１００内のローカルな処理要素による、また潜在的には他の処理要素による、データ項目へのトランザクショナル・メモリ・アクセスを含む。トランザクショナル・メモリ・システム内の安全機構なしでは、これらのアクセスのいくつかが、潜在的には、無効なデータおよび実行を、すなわち読み出しを無効にするデータへの書き込みまたは無効なデータの読み出しを、結果として与えることになる。これについてはのちに論じる。
【００３６】
ある実施形態では、プロセッサ１００は、データ項目に関連付けられたアクセスおよび潜在的なその後の衝突を検出または追跡するモニタを含む。一例として、プロセッサ１００のハードウェアは、ロードおよびストアがモニタリングされることが決定されたロードおよびストアを追跡するための読み出しモニタおよび書き込みモニタを含む。たとえば、ハードウェアの読み出しモニタおよび書き込みモニタが、根底にある記憶構造の粒度にもかかわらず、データ項目の粒度でデータ項目をモニタリングする。ある実施形態では、データ項目は、少なくとも該データ項目全体が適切にモニタリングされることを保証するために、記憶構造の粒度で関連付けられた追跡機構によって境を定められる。
【００３７】
個別的な例解のための例として、読み出しおよび書き込みモニタは、低レベル・データ・キャッシュ１５０内の位置のようなキャッシュ位置に関連付けられた属性を、そうした位置に関連付けられたアドレスからのロードおよび該アドレスへのストアをモニタリングするために含む。ここで、データ・キャッシュ１５０のキャッシュ位置についての読み出し属性は、該キャッシュ位置に関連付けられたアドレスへの読み出しイベントに際して、同じアドレスへの潜在的な衝突する書き込みがないかどうかモニタリングするために、設定される。この場合、書き込み属性は、同じアドレスへの潜在的な衝突する読み出しおよび書き込みがないかどうかモニタリングするために、書き込みイベントについて同様の仕方で動作する。この例をさらに進めると、ハードウェアは、しかるべくキャッシュ位置がモニタリングされることを示すよう設定された読み出しおよび／または書き込み属性をもつキャッシュ位置に対する読み出しおよび書き込みについてののぞき見（snoops）に基づいて衝突を検出することができる。逆に、読み出しおよび書き込みモニタを設定すること、あるいはあるキャッシュ位置をバッファリングされる状態に更新することは、ある実施形態では、読み出し要求または所有権要求についての読み出しのようなのぞき見につながり、これは、他のキャッシュにおけるモニタリングされるアドレスとの衝突の検出を許容する。
【００３８】
したがって、設計に基づいて、キャッシュ・ラインのキャッシュ・コヒーレンシー要求およびモニタリングされるコヒーレンシー状態の種々の組み合わせは潜在的な衝突につながる。たとえば、キャッシュ・ラインがあるデータ項目を、共有された読み出しモニタリング状態に保持し、のぞき見がそのデータ項目への書き込み要求を示す。逆に、キャッシュ・ラインがバッファリングされた書き込み状態にあるデータ項目を保持し、外部のぞき見がそのデータ項目への読み出し要求を示す場合は、潜在的に衝突すると考えてもよい。ある実施形態では、アクセス要求および属性状態のそのような組み合わせを検出するために、のぞき見論理が、衝突検出／報告のためのモニタおよび／または論理および衝突を報告するための状態レジスタのような衝突検出／報告論理に結合される。
【００３９】
しかしながら、条件およびシナリオの任意の組み合わせが、コミット命令のような命令によって定義されうるあるトランザクションにとって、無効にすると考えられてもよい。トランザクションの非コミットのために考えられうる因子の例は、トランザクション的にアクセスされるメモリ位置への衝突の検出、モニタ情報の喪失、バッファリングされたデータの喪失、トランザクション的にアクセスされるデータ項目に関連付けられたメタデータの喪失および（再開されたトランザクションが継続されることができないとして）割り込み、リング遷移もしくは明示的なユーザー命令のような他の無効にするイベントの検出を含む。
【００４０】
ある実施形態では、プロセッサ１００のハードウェアはバッファリングされた仕方でトランザクション的更新を保持する。上述したように、トランザクション書き込みはトランザクションのコミットまでグローバルに可視にされない。しかしながら、トランザクション書き込みに関連付けられるローカルなソフトウェア・スレッドは、その後のトランザクション・アクセスのためにトランザクション更新にアクセスすることができる。第一の例として、バッファリングされた更新を保持するためにプロセッサ１００内に別個のバッファ構造が設けられる。これは、該更新を、ローカルなスレッドに提供し、他の外部スレッドには提供しないことができる。それでも、別個のバッファ構造を含めることは、潜在的に、高価で複雑になる。
【００４１】
対照的に、もう一つの例として、データ・キャッシュ１５０のようなキャッシュ・メモリが、同じトランザクション的機能を提供しつつ前記更新をバッファリングするために利用される。ここで、キャッシュ１５０は、バッファリングされたコヒーレンシー状態においてデータ項目を保持することができる。ある場合には、新しいバッファリングされたコヒーレンシー状態が、キャッシュ・コヒーレンシー・プロトコルに加えられる。たとえば修正排他共有無効（MESI:  Modified  Exclusive  Shared  Invalid）プロトコルに加えられてMESIBプロトコルをなす。バッファリングされたデータ項目、つまりバッファリングされたコヒーレンシー状態に保持されているデータ項目に対するローカルな要求に応答して、内部的なトランザクション的逐次的順序付けを保証するよう、キャッシュ１５０はそのデータ項目をローカルな処理要素に提供する。しかしながら、外部アクセス要求に応答しては、トランザクション的に更新されたデータ項目がコミットまでグローバルに可視にされないことを保証するよう、ミス応答が提供される。さらに、キャッシュ１５０のあるラインがバッファリングされたコヒーレンシー状態に保持され、放逐のために選択されているとき、バッファリングされた更新はより高いレベルのキャッシュ・メモリに書き戻されない――コミット後まで、バッファリングされた更新はメモリ・システムを通じて増殖されない、すなわちグローバルに可視にされない。コミットに際して、バッファリングされたラインは、そのデータ項目をグローバルに可視にするために、修正された状態に遷移させられる。
【００４２】
内部および外部という用語はしばしば、トランザクションの実行またはキャッシュを共有する処理要素に関連付けられたスレッドの観点に対するものであることを注意しておく。たとえば、トランザクションの実行に関連付けられたソフトウェア・スレッドを実行するための第一のソフトウェア要素がローカル・スレッドと称される。したがって、上記の議論において、前記第一のスレッドによって以前に書き込まれたアドレスへのストアまたは該アドレスからのロード（この結果、そのアドレスについてのキャッシュ・ラインはバッファリングされたコヒーレンシー状態に保持される）が受領される場合、そのキャッシュ・ラインのバッファリングされたバージョンは、前記第一のスレッドに提供される。それがローカルなスレッドだからである。対照的に、同じプロセッサ内の別の処理要素で第二のスレッドが実行中であることがあるが、前記キャッシュ・ラインがバッファリングされた状態に保持される原因となった前記トランザクションの実行には関連付けられていない――外部スレッドである；したがって、この第二のスレッドから前記アドレスへのロードまたはストアは、前記キャッシュ・ラインのバッファリングされたバージョンをミスし、より高いレベルのメモリから前記キャッシュ・ラインのバッファリングされていないバージョンを取得するために、通常のキャッシュ置換が利用される。
【００４３】
ここで、内部／ローカル・スレッドおよび外部／リモート・スレッドは同じプロセッサ上で実行されており、いくつかの実施形態では、前記キャッシュへのアクセスを共有するプロセッサの同じコア内の別個の処理要素上で実行されてもよい。しかしながら、これらの用語の使用はそのように限定されるものではない。上述したように、ローカルは、当該トランザクションの実行に関連付けられた単一のスレッド固有であるのではなく、キャッシュへのアクセスを共有する複数のスレッドを指してもよいし、一方、外部またはリモートは、前記キャッシュへのアクセスを共有しないスレッドを指してもよい。
【００４４】
図１を最初に参照したときに上述したように、プロセッサ１００のアーキテクチャは、純粋に、議論の目的のために例解するものである。たとえば、他の実施形態では、UBTハードウェアは、複雑な名前変更／割り当て器および並べ替え／リタイア・ユニットを含まなくてもよい、ずっと単純な順序内実行プロセッサ設計のプロセッサのために実装されることができる。同様に、参照するメタデータのためのデータ・アドレスを変換する具体例も例示的であり、同じメモリの別個のエントリー内のメタデータにデータを関連付けるいかなる方法を利用してもよい。
【００４５】
図２に目を転じると、プロセッサ内でデータ項目のためのメタデータを保持する実施形態が示されている。描かれているところでは、データ項目２１６についてのメタデータ２１７はメモリ２１５にローカルに保持されている。メタデータは、データ項目２１６に関係するトランザクション情報のような、データ項目２１６に関連付けられた任意の属性またはアトリビュートを含む。メタデータのいくつかの例示的な例が下記に含められる。それでも、開示されるメタデータの例は純粋に例解するものである。よって、メタデータ位置２１７は、データ項目２１６についての情報および他の属性の任意の組み合わせを保持しうる。
【００４６】
第一の例として、データ項目２１６がトランザクション内で以前にアクセスされた、バッファリングされたおよび／またはバックアップされた場合、メタデータ２１７は、トランザクション的に書き込まれたデータ項目２１６についてのバックアップまたはバッファ位置への参照を含む。ここで、いくつかの実装では、データ項目２１６の以前のバージョンのバックアップ・コピーは異なる位置に保持され、結果として、メタデータ２１７は、バックアップ位置へのアドレスまたは他の参照を含む。あるいはまた、メタデータ２１７自身が、データ項目２１６についてのバックアップまたはバッファ位置として作用してもよい。
【００４７】
もう一つの例として、メタデータ２１７は、データ項目２１６への反復トランザクション的アクセスを加速するフィルタ値を含む。しばしば、ソフトウェアを利用するトランザクションの実行中、一貫性およびデータ有効性を保証するためにトランザクション的メモリ・アクセスでアクセス・バリアが実行される。たとえば、トランザクション的ロード動作の前に、読み出しバリアが実行されて、読み出しバリア動作を実行する。読み出しバリア動作とは、データ項目２１６が未ロックであるかどうかを試験すること、トランザクションの現在の読み出しセットがいまだ有効であるかどうかを判定すること、フィルタ値を更新することおよびのちの有効確認のためのトランザクションについての読み出しセット値におけるバージョン値のログ記録といったものである。しかしながら、その位置の読み出しがすでにトランザクションの実行中に行われている場合、同じ読み出しバリア動作は、潜在的には不要になる。
【００４８】
結果として、一つの解決策は、読み出しフィルタを利用して、データ項目２１６が、あるいはしたがって前記アドレスがトランザクションの実行中に読み出されていないことを示す第一のデフォルト値と、データ項目２１６あるいはしたがって前記アドレスがトランザクションのペンディング状態の間にすでにアクセスされていることを示す第二のアクセス値とを保持することを含む。本質的には、第二のアクセス値は、読み出しバリアが加速されるべきかどうかを示す。この事例では、トランザクション的ロード動作が受領されて、メタデータ位置２１７における読み出しフィルタ値が、データ項目２１６がすでに読み出されていることを示す場合、ある実施形態では、不必要な、冗長な読み出しバリア動作を実行しないことによってトランザクション的実行を加速するために、読み出しバッファは省略される――実行されない。書き込みフィルタ値は、書き込み動作に関して同じ仕方で動作しうることを注意しておく。しかしながら、個々のフィルタ値は純粋に例解するものであって、ある実施形態では、あるアドレスが――書き込まれるのであれ読み出されるのであれ――すでにアクセスされたかどうかを示すために単一のフィルタ値が利用される。ここで、ロードおよびストアの両方についての２１６のためのメタデータ２１７を検査するメタデータ・アクセス動作は、単一のフィルタ値を利用する。これは、メタデータ２１７が別個の読み出しフィルタ値および書き込みフィルタ値を含む上記の例とは対照的である。具体的な例示的な実施形態として、メタデータ２１７の四つのビットが、関連するデータ項目に関して読み出しバリアが加速されるかどうかを示す読み出しフィルタと、関連するデータ項目に関して書き込みバッファが加速されるかどうかを示す書き込みフィルタと、取り消し（undo）動作が加速されることを示す取り消しフィルタと、雑多フィルタ（a  miscellaneous  filter）に割り当てられ、ソフトウェアによって任意の仕方で利用される。
【００４９】
メタデータの若干の他の例は、以下のものの指示、表現または参照を含む。一般的なまたはデータ項目２１６に関連付けられたトランザクションに固有なハンドラについてのアドレス、データ項目２１６に関連付けられたトランザクション、データ項目２１６の喪失、データ項目２１６についてのモニタリング情報の喪失、データ項目２１６についての検出された衝突の取り消し不可能性／頑迷性、データ項目２１６に関連する読み出しセットまたは読み出しセット内の読み出しエントリーのアドレス、データ項目２１６についての以前のログ記録されたバージョン、データ項目２１６の現在のバージョン、データ項目２１６へのアクセスを許容するロック、データ項目２１６についてのバージョン値、データ項目２１６に関連付けられたトランザクションについてのトランザクション記述子および他の既知のトランザクション関係の記述情報。さらに、上記のように、メタデータの使用はトランザクション情報に限定されるものではない。系として、メタデータ２１７は、トランザクションに関わらないデータ項目２１６に関連付けられた情報、属性、アトリビュートまたは状態を含んでいてもよい。
【００５０】
このハードウェアの概観に加え、ソフトウェア編成の構成の概観も有用である。ここで図３を参照するに、本発明のある実施形態に基づくソフトウェア・アーキテクチャのブロック図が示されている。図３に示されるように、アーキテクチャ２５０はユーザー・モード・コード２６０およびカーネル・モード・コード２８０の両方を含む。一般に、ユーザー・モード・コードは、ランタイム・システム・コードに加え、根底にあるハードウェア上で実行されるさまざまなアプリケーションに関連するコードであることができる。ランタイム・システム・コードは、特定のアプリケーションやOSに関連付けられることができる。一般に、カーネル・モード・コードはOSコード自身およびカーネル・モード例外処理コードと考えることができる。
【００５１】
UTM動作のために実装する際、ユーザー・モード・コード２６０は、一つまたは複数のUTMアプリケーション２６５を含む。このコードの実行中に起こりうるある種のイベントを扱うために、ユーザー・モード・コードはさらに、ユーザー・レベルのUTMランタイム・システム・コード２７０を含んでいてもよい。このコード２７０は、UTMアプリケーション／環境をサポートするソフトウェア・ライブラリのコレクションであってもよく、UTM動作中に起こるさまざまな例外および他のイベントを扱ってもよい。図３に示した例では、そのようなコードはイジェクション・ハンドラを含んでいてもよい。UTMアプリケーションまたは他のユーザー・モード・アプリケーションの間に起こりうるより一般的な動作またはイベントを扱うために、ユーザー・レベルのOSランタイム・システム・コード２７５も、ユーザー・モード・アプリケーション／環境をサポートするソフトウェア・ライブラリのコレクションであってもよい。以下でさらに論じるように、そのようなコードは、UTM動作中に生起する少なくともいくつかの例外的なイベントについての制御フローを扱うことができうる。
【００５２】
OSコード２８０を参照するに、根底にあるアーキテクチャのためのさまざまな抽象化（たとえばメモリ・アクセスなど）をブート・アップし、扱うための通常のOSコード２８５に加えて、該OSコードはカーネル・モード例外ハンドラ２９０を含んでいてもよい。さまざまな実施形態において、このカーネル・モード・コードは、UTM可知（UTM-aware）であってもよい。それにより、所与のUTMモードおよび環境ならびにカーネル・モードへの遷移を引き起こしたイベントの知識に基づいて、例外ハンドラは、ユーザー・モードにおける適切な位置に制御フローを向けることができる。たとえば、ユーザー・ランタイム・システム例外ディスパッチャ・ハンドラ、UTMユーザー・ランタイム例外ディスパッチャ（もしあれば）および／またはイジェクション・ハンドラ。図３の実施形態ではこの特定の実装をもって示されているが、本発明の範囲はこの点に関して限定されない。
【００５３】
この背景をもとに、ここで、UTMトランザクション中に例外が発生したときの関連するハードウェア、ソフトウェアおよび例外処理動作の議論を考えることができる。例外がユーザー・レベルのUTMスレッドで遭遇されたとき、カーネル・モードへの遷移が起こる。OSはまず、該例外がページ・フォールト（#PF）であるときのように該例外を解決しようと試みる必要があるかもしれないので、OSコードは、この例外イベントをソフトウェア定義されるUTMイベントを通じてUTMランタイム・システムに通信すると決定する前に、ハードウェア例外に際して、走ってもよい。OSコードをハードウェア例外に際して走らせ、OSコードにUTMソフトウェア・イベントを生成するかどうかを決定させることにはさらなる利点があることもある。たとえば、UTMをサポートするOSおよびランタイム実装において、OSが複数の例外経路（たとえば非UTMコードについて一つ、UTM環境についてもう一つ）をもつユーザー・ランタイム環境をサポートすることが可能である（例外ハンドラ・ディスパッチ・サポートを含めて）。これは、OSが、割り込みされたユーザー・スレッドの状態に依存して適切なユーザー・レベル例外ディスパッチャ・コードを選択することを許容し、ソフトウェア定義されるイベントの使用は必要でないことがある。
【００５４】
ソフトウェア定義されるイベントは、本質的には、UTMランタイム・システム・コードに、イジェクション・ターゲット・ハンドラを通じてハードウェア例外のような個別的な非同期的イベントをインターセプトすることを許容する。そのようなイベントは、UTMランタイム・システムが、STM方式にフォールバックする、トランザクションをリスタートするおよびデフォルト・ユーザー・ランタイム例外ディスパッチ・フローを通じて例外に対処するなどといった、トランザクション的実行の中途で発生する例外を扱うための特定のポリシーを実装することを許容する。
【００５５】
図４に示されるように、方法３００は、ユーザー・スレッド、つまりスレッドAにおいてUTMトランザクションを実行するために使用されてもよい。スレッドAは、ユーザー・モードにおいて実行されるUTMアプリケーションのものであってもよい。UTMトランザクションは、UTMの種々の属性についての値を設定し、トランザクションの実行を開始することによって始まることができる（ブロック３２０）。UTMトランザクションの実行中に、ハードウェア例外が生成されることがある（ブロック３２５）。たとえば、ページ・フォールトが発生することがある。
【００５６】
したがって、図４に見られるように、カーネル・モードへのリング遷移が起こることがある（ブロック３３０）。このリング遷移は、ハードウェアに、UTMトランザクションをサスペンドさせてもよい。そのようなサスペンドは、ユーザー・スレッドについてのイジェクション機構をサスペンドすることを含んでいてもよい。ある実施形態では、サスペンドは、TSRおよび／またはTCRの一つまたは複数のインジケータ（たとえばビット）を設定することによって実現されてもよい。サスペンドでは、暗黙的な読み出しモニタリングおよび暗黙的なバッファリングといった他の活動もサスペンドされてもよい。こうして、デフォルトのメモリ読み出しおよび書き込み振る舞いはもはやUTM属性を生成、モニタリングおよびバッファリングしない。したがって、制御は、カーネル・モードで実行されているOSコードに移る（ブロック３４０）。ページ・フォールト例外のため、OS例外ハンドラは、制御を、呼び出されうるページ・フォールト・ハンドラに差し向けてもよい。このハンドラの実行において、OSメモリ・マネージャはページ・フォールトを直すよう試みてもよい。これが不成功であれば、たとえば無効なアドレスのために、OSは例外をユーザー・モードに投げ返してもよい。例外をユーザー・モードに送り返す前に、OS例外ハンドラは、トランザクション状態レジスタを含む、存在しているユーザー状態を検査してもよい。リング遷移の時点でUTMトランザクションが進行中であったので、このTSRの解析は、そのUTMトランザクションがスレッドAについてペンディングしていたことを示す。したがって、OSは、そのUTMトランザクション中にハードウェア例外が発生したことを示すため、TSRの一つまたは複数のソフトウェア・イベント・フィールドに零でない値を設定してもよい。最後に、OSは割り込み戻り命令（IRET:  interrupt  return  instruction）を実行して制御をもとのスレッドAに戻す。
【００５７】
ユーザー・モードに戻るこのリング遷移（ブロック３５０）は、ハードウェアに、たとえばTSRおよび／またはTCRにおいて一つまたは複数のインジケータを設定することによって、UTMトランザクションをサスペンド解除させる。UTMトランザクションが再開される（ブロック３６０）と、TSRの一つまたは複数のソフトウェア・イベント・フィールドに存在する零でない値のために、イジェクションがトリガーされてもよい。したがって、ユーザー・モードにある間、制御は、イジェクション・ハンドラに移る（ブロック３７０）。イジェクション・ハンドラは、TSRにおける値を検査し、TSRに存在するソフトウェア・イベント・フィールドに基づいて特定のサービス動作を実装するためのコードを含んでいてもよい。具体的には、イジェクション・ハンドラは、それぞれ特定の型のUTMイベントのための、複数のコード経路を含んでいてもよい。TSRに存在する値に基づいて、これらの経路のうちの一つが実行されてもよい。例として、非同期的UTMイベント、同期UTMイベントおよびソフトウェアUTMイベントを扱うために異なる経路が存在していてもよい。ただし、本発明の範囲はこの点に関して限定されない。それぞれのそのような経路は、所与の型のイベントを扱うためのポリシーを実装するためのコードを含んでいてもよい。図４の実施形態ではこの特定の実装で示されているが、本発明の範囲はこの点に関して限定されるものではない。
【００５８】
UTMソフトウェア・イベントの発生を識別するためのハードウェア実装が上記されているが、同じ概念のソフトウェア・エミュレーションが実行されてもよい。エミュレーションを実現するために、TSR内の一つまたは複数のソフトウェア・イベント・フィールドに零でない値を設定する代わりに、OS例外ハンドラがUTMサービス・ハンドラへの戻りIPアドレスを手動で変更し、その例外の呼び出しの理由についての情報を、ソフトウェア規約において定義されたメモリ・パラメータを通じて渡すことができる。
【００５９】
諸実施形態は、UTMトランザクション実行の過程で起こるシグナルおよび例外処理を最適にサポートするためのハードウェア・サポートおよびOSアルゴリズム向上をも提供してもよい。こうして、OSおよびそのデフォルト・ランタイム・システムはUTMプログラムへの例外ディスパッチ・フローを実装することができる。
【００６０】
種々の実施形態において、ハードウェア機構は、プロセッサがカーネル・リング0  OSコードで動作している間、UTM動作モードをサスペンドしてもよい。これは、UTMハードウェア動作モードと一緒に動作するためにコンパイルされていても（あるいはいなくても）よいOSカーネル・コードが、ユーザーUTMスレッドによって構成されたUTMハードウェア動作モードによって影響されることなく、正しく実行され、動作することを許容する。プロセッサがリング0で動作している間に、諸機構は、アボートを引き起こすことなくUTMトランザクションをサスペンドし、UTM属性の喪失を動的に追跡し、そのような喪失イベント情報を記録および蓄積してもよい。このようにして、ユーザーUTMスレッドが再開し、OSカーネル・コード実行中に記録されたUTM属性喪失がなければ、アボートすることなくUTMトランザクションを継続することができる。この機構は、カーネル・モード動作の間に発生したUTM属性喪失イベントが、のちに、OSカーネル・コードがユーザー・スレッドの実行に戻ったときに処理されることをも許容する。
【００６１】
UTMランタイム・システムおよびUTMコンパイラは、UTMハードウェアによって提供される多様なUTMモードおよび動作を使い、UTMトランザクション実行戦略を実装する。各UTMハードウェア動作モードは、UTMアーキテクチャによってサポートされる、インラインの動作またはアウトオブラインの非同期的なハンドラ呼び出し（たとえばイジェクション・ハンドラ）を通じて特定のUTM属性喪失イベントを処理するために正しくUTMトランザクション・コードを実行するために生成された特定のコード経路を使う。結果として、同じプログラム・フローについて、それぞれが特定のUTM動作モードについてのコード経路に対応する、複数のコード経路が存在することがある。UTMハードウェアは、UTMランタイム・システムおよびUTMコンパイラがUTMトランザクション実行戦略を実装できるようにする多様なUTMハードウェア動作モードを提供する。上記のように、UTMハードウェアは、幅広い範囲のトランザクショナル・メモリ設計を含む多様な洗練されたアルゴリズムを実装するために、モニタリング、バッファリングおよびメタデータを含むUTM属性を提供する。そのようなハードウェアは、UTMランタイムが、特定のUTM属性に対する喪失イベントを扱うためのソフトウェア戦略を実装することを許容するために、UTMイベントおよびイジェクション（または他のユーザー・レベルの非同期的制御移転）機構の概念をも提供してもよい。
【００６２】
このように、カーネル・モードOS例外処理コードは、TCRおよび／またはTSRを検査することによって現在のUTMトランザクション・モードを考慮に入れ、この情報に基づいて、例外を生成した点から再開すべきかどうか、例外をデフォルトのOSユーザー・モード・ランタイム・コードに投げつけるべきかどうか、あるいは制御をイジェクション・ハンドラに渡すべきかどうかの最終的な決定を行ってもよい。
【００６３】
ここで図５を参照するに、UTMトランザクションの間に例外またはOSへの他の制御の遷移に対処するためのイベントの全体的なシーケンスの流れ図が示されている。図５に見られるように、ユーザー・モードにおいて例外が発生するとき、トランザクションはサスペンドされ、制御はカーネル・モードに、より詳細にはカーネル・モード例外ハンドラ４１０のOS例外処理コードに移る。たとえば、ハードウェア例外条件（たとえば零による除算）はハードウェアによって検出されてOSカーネル・コードに報告される。ハンドラ４１０は例外をインターセプトし、例外情報を収集してもよい。見て取れるように、例外ハンドラ４１０は、OSが、その例外を引き起こしたイベントを解決するよう試みるべきかどうかを決定してもよい（菱形４１５）。OSがその例外に対処することを決定する場合、制御はブロック４２０に移り、その問題を解決しようと試みるために、所与の型の例外のためのOSサービス・ハンドラが実行されてもよい。したがって、菱形４２５では、例外が解決されたかどうかが判定されてもよい。もし解決されていれば、制御はもとのユーザー・モードに渡される。具体的には、カーネルは、例外が生成されたユーザー・スレッドの点に対応するIP位置から再開するために割り込み戻り命令（IRET）を実行してもよい。
【００６４】
引き続き図５を参照するに、例外ハンドラが、OSが例外に対処しようと試みることを許容しないことを選ぶ場合、あるいは例外が直せなかった場合、制御はブロック４３０に戻り、例外が、ユーザー・モードに投げ戻される準備がなされてもよい。この準備は、例外の型を識別し、例外情報を生成するために例外の時点でのプロセッサ状態を収集することを含んでいてもよい。したがって、制御は菱形４３５に移り、遷移の時点において、UTMモードがユーザー・スレッドにおいて有効にされていたかどうかが判定されてもよい。もし有効にされていなかった場合、制御はブロック４４０に移り、戻りIPアドレスが、デフォルトのユーザー例外ディスパッチャに更新されてもよい。したがって、制御はこのアドレス（IRET(B)）においてもとのユーザー・モードに移る。この工程の間、ある実施形態では、OSは例外情報を収集し、それをユーザー・スタックに転送し、ユーザー・モードに遷移し、例外をユーザー・モード例外ディスパッチ・ハンドラにディスパッチする。
【００６５】
OSハンドラがUTMシステムについてのさらなる知識をもたない実装では、このユーザー・モードへの戻りはUTMトランザクションについてであってもよい。しかしながら、OSハンドラがUTM可知である（UTM-aware）実装では、任意的に、カーネル・モード・コードは、UTMランタイム・システムから提供される複数のユーザー・モード例外ディスパッチ経路をサポートしてもよい。これらの複数のコード経路はそれぞれ、特定のUTMハードウェア動作モードをもつ異なるUTM実装方式に対応することができる。ディスパッチ・コード経路は、例外をターゲット・ハンドラにディスパッチするために、OSカーネルからの要求を処理してもよいが、今論じたように、UTM実装方式によって使用されるUTMハードウェア動作モードと一緒に正しく動作するための特別なコード装備（instrumenatations）を有する。
【００６６】
こうして、例外の時点でUTMトランザクション・モードが有効にされていたと判定される場合、制御は菱形４４５に移り、現在のUTMモードがコード装備を要求するかどうかが判定されてもよい。すなわち、例外ハンドラは、現在のUTMモードおよび例外の型の知識に基づいて、示された例外に対処するために特別なハンドラ・コードが必要とされるかどうかを決定してもよい。このように、カーネル・モード・コードはさらに、TCRおよび／またはTSRを検査することによって現在のUTMハードウェア・トランザクション・モードを調べて、OSユーザー・ランタイム・コードに制御を渡すことが安全であるかどうかを判定してもよい。もし安全であれば、OSユーザー・ランタイムにおけるユーザー・モード例外ディスパッチ・コードはOSカーネルからの要求を処理し、例外をターゲット・ハンドラにディスパッチする。これは、アプリケーション・プログラム実行環境における言語レベル例外構造体をサポートする。もし安全でなければ、制御は上で論じたブロック４４０に移る。
【００６７】
その代わりに、特別なハンドラ・コードが示される場合、制御は菱形４５０に移り、ここで、UTMランタイム・システムが、現在のUTMモードについてのコード経路を提供するかどうかが判定されてもよい。この判定は、OSにとって利用可能なルックアップ・テーブルの解析に少なくとも部分的に基づくことができる。該ルックアップ・テーブルは、利用可能なUTMモード、可能な例外および所与の例外に対処するためにUTMランタイム・システムにおいて特別なコード経路が存在するかどうかを示してもよい。ある実施形態では、前記テーブルは、それぞれがUTMモード、例外型および対応するコード経路を有する複数の項目を含んでいてもよい。UTMモードおよび例外型の組み合わせに基づいて、当該項目のコード経路が選択されてもよい。菱形４５０の判定が肯定的である場合、制御はブロック４５５に移り、戻りIPアドレスが、UTMランタイム・システムによって提供されるユーザー例外ディスパッチャ・コード経路に対応する位置に変更されてもよい。したがって、制御は、戻りアドレスCにおいてもとのユーザー・モードに移る（IRET(C)）。
【００６８】
それ以外の場合で、特別なUTMランタイム・コード経路が利用可能でない場合、制御はブロック４６０に移り、戻りIPはUTMイジェクション・ハンドラの位置に対応するよう更新されてもよい（ブロック４６０）。したがって、制御はもとのユーザー・モードに移る（より詳細にはIRET(D)により）。さまざまな実施形態において、のちにさらに論じるように、UTMイジェクション・ハンドラは、STMモードへのフォールバックおよびトランザクションのリスタートといった、例外に対処するためのポリシーを実装してもよい。図５の実施形態ではこの特定の実装で図示されているが、本発明の範囲はこの点で限定されるものではない。
【００６９】
図５は主として、OS例外ハンドラの観点から動作の流れを示しているのに対して、図６は、UTMトランザクションをユーザー・スレッドにおいて実行し、OSへの例外を被る動作のさらなる流れを示す。一般に、UTMトランザクションはユーザー・モードで、UTMコード装備と一緒にUTMランタイム・システムを使うことによって、実行されうる。UTMトランザクションは、選択されたハードウェア動作モードをプログラミングし（ブロック５０５）、トランザクション（ブロック５１０）の実行を開始することによって始まってもよい。そのようなモードは多様なUTM実装方式の一つを実装してもよい。UTM実装方式の例は：トランザクションがキャッシュ内に収まるキャッシュ駐在TM（CRTM:  cache  resident  TM）；トランザクションがキャッシュ内に収まらないがフィルタリングおよびモニタリングのためにハードウェアを使うことができるハードウェア加速されたSTM（HASTM:  hardware  accelerated  STM）；キャッシュ内に収まる読み出しまたは書き込みだけが実行され、フィルタリングおよびモニタリングのためにハードウェアを使う、積極的ハードウェア加速されたTM（HATM）；およびトランザクションがハードウェアを使用せず、その代わり、トランザクションを実装するためにソフトウェア方式のみを使うSTM、を含む。
【００７０】
引き続き図６を参照するに、トランザクションの実行中、例外が発生することがある（ブロック５１０）。この例外はいかなる型の例外でもよいが、議論の目的のため、ハードウェア例外であるとする。したがって、制御はブロック５２０に移り、カーネル・モードへのリング遷移が起こる。遷移前に、ハードウェアは、ユーザー・スレッドについてのイジェクション機構を含め、UTMトランザクションをサスペンドしてもよい。次いで制御はカーネル・モードに、より詳細にはカーネル・モードの例外ハンドラに移る（ブロック５３０）。
【００７１】
図５に関して上で論じたように、例外ハンドラは例外を解決することもあれば、解決しないこともある。ハンドラが例外を解決する場合、制御は、UTMトランザクションのもとのメイン・ブロック（５１０）に移る。該トランザクションの継続した実行のためである。戻りリング遷移（ブロック５３５）の間、ハードウェアは、UTMトランザクションをサスペンド解除してもよい。UTMトランザクションの属性は修正またはクリアされなかったので、トランザクションはその戻り点において自由に動作を継続できる。
【００７２】
その代わり、例外ハンドラ５３０が例外を解決できない場合、図５に関して上で論じたような、ユーザー・モードへの異なる戻り経路が提供されることができる。見たように、制御は、OSユーザー・ランタイムに関連付けられるユーザー例外ディスパッチャに渡されることができる（ブロック５４０）。その代わり、OS例外ハンドラがUTM可知である実装では、戻りは、UTMランタイム・システムによって提供されるユーザー例外ディスパッチ経路にであってもよい（ブロック５５０）。UTM可知である例外ハンドラのさらに他の実装では、制御をUTMユーザー例外ディスパッチ経路に渡す代わりに、制御は、イジェクション・ハンドラ５６０に渡されてもよい。よって、見たように、UTMモードの型、例外型およびUTMランタイム・システムにおける種々の実行経路の利用可能性に加えて、OS例外ハンドラの型に依存して、制御は、例外処理から、ユーザー・モード内の多くの異なるコード経路の一つに渡されてもよい。
【００７３】
ハードウェア例外および外部割り込みは、（時間およびメモリ占有において）UTMの任意に大きなトランザクションの間には、不可避であることがあるので、諸実施形態は、オペレーティング・システムが、UTMトランザクションに対する非常に高価なアボート動作を引き起こすことなくページ・フォールトのようなハードウェア例外を直そうと試みることができるようにしてもよい。同時に、ハードウェア例外がオペレーティング・システムによって直すことができない場合に、オペレーティング・システムは、アプリケーションに例外処理プログラミングのサポートを提供することができる。これはたとえば、ソフトウェア定義されたUTMイベントをUTMランタイム・システムに送達することによる。同様に、諸実施形態は、オペレーティング・システムが、UTMトランザクションへの非常に高価なアボート動作を引き起こすことなく、外部割り込みに対処することができるようにするとともに、UTMトランザクションの間にUTMランタイム・システムに入射したシグナルをオペレーティング・システムがソフトウェア定義されたUTMイベントを通じて通信することを許容することによって、オペレーティング・システムが、アプリケーションのためのシグナル・プログラミング（たとえばUNIX（登録商標）シグナル）のサポートを提供することを許容してもよい。
【００７４】
上で論じたように、さまざまな実施形態において、UTMアーキテクチャは、モニタリング、バッファリングおよびメタデータのようなハードウェア属性のための備えをしてもよい。これらの機能はソフトウェアに、幅広い範囲のトランザクション的メモリ設計を含む、多様な洗練されたアルゴリズムを実装する手段を提供する。各属性は、キャッシュ・メモリの既存のキャッシュ・プロトコルを拡張するまたは専用のハードウェア資源を割り当てることによって、ハードウェアにおいて実装されることができる。これらのUTM属性はあるスレッドに対する専用の属性として扱われ、管理されうるので、諸実施形態はOSコンテキスト・スイッチ・コードが、これらの属性をサポートできるようにしてもよい。
【００７５】
比較的小さな、固定した少量の資源をもつハードウェア・レジスタ状態とは異なり、UTMスレッドについてのバッファリング、モニタリングおよびメタデータ属性のサイズは動的であり、変動することができ、レジスタ状態より実質的に大きくなることがある。よって、OSが固定量のハードウェア・レジスタ資源を保存し、復元するコンテキスト・スイッチ動作の伝統的な戦略はもはや機能しないか、あるいはこれらの動的で潜在的に非常に大きなサイズのUTM属性についてそうしようと試みるならば、禁止的なほど高価になる。
【００７６】
外部割り込み、ページ・フォールトおよびOSシステム・コールを含むOSイベントに際してUTMトランザクションの無条件のアボートおよびそのようなハードウェア資源の破棄を回避するため、諸実施形態は、OSコンテキスト・スイッチ上に大量のUTM属性を効果的に管理する機構を提供する。種々の実施形態において、ハードウェア・サポートはカーネル動作中にトランザクションをサスペンドし、モニタリング、バッファリングおよびメタデータ・イベントの喪失の追跡を続けてもよい。また、ハードウェアおよびOSサポートを用いて、そのスレッドについて、バッファリングおよびモニタリングは、明示的にクリアされ、メタデータは破棄されてもよく、コンテキスト・スイッチ後にスレッド実行を再開するときに適切なバッファリングおよびモニタリング喪失イベントが生成されてもよい。次いで、バッファリング、モニタリングおよびメタデータ喪失から回復するために、ハードウェアおよびUTMランタイム・サポートが使用されることができる。UTM属性の喪失を扱うためにハードウェアおよびソフトウェア機構が提供されてもよく、喪失イベントが発生した場合にUTMランタイム・コードにおけるあらかじめ指定されたIPアドレスへの制御の移行を含んでいてもよい。
【００７７】
コンテキスト・スイッチに際してUTM属性を保存し、復元する代わりに、ハードウェアが、モニタリング、バッファリングおよびメタデータ属性の喪失を動的に追跡し、そのようなUTM属性喪失イベント情報を記録および蓄積するための機構を提供してもよい。これらのイベントを記録するためのハードウェア実装の事例は、TSRでありうる。TSRは発生した喪失イベントを反映するためのビット・フィールドを有していてもよい。複数のビット・フィールドが設けられることができ、各喪失イベント・ビットが異なるUTM属性の喪失イベントに対応する。状態レジスタにおける喪失イベント・ビットはUTM属性喪失イベント上で設定されることができ、明示的なクリア動作がソフトウェアによって実行されるまでクリアされることができない。この状態レジスタの読み出しは、その時点において蓄積されている任意のUTMイベントのスナップショットを提供する。
【００７８】
いくつかの実施形態では、UTM属性の喪失は、指定されたランタイム・アドレスへの非同期的な制御の移行を通じて、あるいはUTMソフトウェアによる状態レジスタの明示的なポーリングを通じて扱われることができる。オペレーティング・システム・コードが、予期されない非同期的な制御の移行動作をもつことなくコンテキスト・スイッチ動作を安全に実行するために、コードがカーネル・モードで動作している間、非同期的な制御移行動作のサスペンド機構が提供されていると想定される。ある実施形態では、イジェクション機構が、UTM喪失イベント検出に際してTEJECTIP位置への非同期的な制御の移行を可能にする。
【００７９】
新しいスレッドへのスレッド切り換えを実行するのに先立って、オペレーティング・システム・コードは、UTM属性の動作をクリアする。この動作によって被られるあらゆる喪失イベントは状態レジスタに反映される。ある実施形態では、この動作は、ある種のユーザー・レベル命令、たとえばトランザクション・クリア（TCA:  transaction  clear）命令（蓄積とともにバッファリングおよびモニタリングをクリアする）およびクリア・メタデータ（CLMD:  clear  metadata）命令（すべてのメタデータをクリアする）の組み合わせによって提供されることができる。これらの動作によって被られる喪失イベントは、TSRレジスタにおける対応するインジケータ（たとえば状態ビット）に反映されることができる。
【００８０】
カーネル・モードからユーザー・モードに戻るのに際して、オペレーティング・システム・コードがUTMスレッドの実行を再開するとき、UTMランタイム固有であることができる復元ポリシー・コードの実行は、UTMランタイム・コードへの特別な制御移行機構をもってトリガーされることができる。あるいはまた、オペレーティング・システム・コードは明示的に、ユーザー・スレッドの戻りIPアドレスを、UTM属性の喪失を扱う特別なユーザー・ランタイム・コードをポイントするよう変更してもよい。コンテキスト・スイッチ後のカーネルからの戻りに際してのこの代替的なUTMランタイム移行機構は、非同期的な移行ハードウェア機構が利用可能でなく、代わりにソフトウェアが、TSRレジスタをポーリングして喪失イベントを見出し、チェックポイントに対して必要なアクションを取ることに責任をもつ場合に、実装されてもよい。
【００８１】
このように、諸実施形態は、大量のスレッド毎ハードウェア・トランザクショナル状態（たとえばUTM属性）を効果的に管理し、よってUTMのハードウェア加速を可能にする機構を提供する。
【００８２】
ここで図７を参照するに、本発明のある実施形態に基づくコンテキスト・スイッチ動作を扱う方法の流れ図が示されている。図７に示されるように、方法６００は、ユーザー・モードで実行している異なるスレッド、つまりUTMアプリケーションを実行している第一のスレッド（すなわちスレッドA）および非UTMアプリケーションを実行している第二のスレッド（すなわちスレッドB）のような、いずれもユーザー・モードで実行されるさまざまな動作を示している。加えて、これらのモードの間のスレッド・スイッチの処理を含むOS動作を実行するカーネル・モードが存在する。図７に見られるように、方法６００は、第一のスレッドにおいてUTMアプリケーションの実行によって始まってもよい（ブロック６１０）。このUTMトランザクションは始まってもよく、バッファリング、モニタリングおよびメタデータのようなさまざまなUTM属性が該トランザクションのために生成されてもよい。該トランザクションの過程で、タイマー割り込みが発生してもよい。したがって、該トランザクションをアボートするのではなく、該トランザクションは、たとえば、TSRにおいてさまざまな一つまたは複数のインジケータを設定することによってサスペンドされることができる。これはイジェクション・ハンドラの実行をサスペンドすることを含む。
【００８３】
したがって、制御は、OSがコンテキスト・スイッチを扱うための活動を実行するカーネル・モードに移る（ブロック６２０）。そのような活動は、UTM属性をクリアするためのある種のユーザー・レベルのまたは他の命令の実行を含んでいてもよい。加えて、これらの動作についてのインジケータがTSRにおいて設定されてもよい（たとえば属性喪失インジケータ）。次いで、OSは第一のスレッドのコンテキストを保存してもよい。このコンテキストは、TSRレジスタを含むUTM状態を含んでいてもよい。コンテキスト・スイッチを有効にするために、OSはさらに第二のスレッドのコンテキストを機械状態に復元する。したがって、制御は、第二のスレッドのアプリケーションの実行のために第二のスレッドに移る（ブロック６２５および６３０）。したがって、このスレッドは、たとえばタイマーまたは他の割り込みに当たるまで、継続してもよい。該タイマーまたは他の割り込みは、再び、カーネル・モードに戻るリング遷移を引き起こす（ブロック６３５）。ここで、OSは、第一のスレッドに戻るコンテキスト・スイッチを可能にする動作を実行する（ブロック６４０）。これらの動作は、ブロック６２０に関して上で論じた動作を再現したものであってもよい。しかしながら、UTM属性のクリアに際して、第二のスレッドは非UTMアプリケーションを実行していたため、第二のスレッドではそのような属性は設定されていなかったため、第二のスレッドに関連するTSRについては、イベント喪失インジケータは更新されていないことを注意しておく。
【００８４】
引き続き図７を参照するに、ブロック６４５において、もう一つのリング遷移が発生して制御をもとのスレッドAに返す。ブロック６５０では、スレッドAは実行を再開しうる。ある実施形態では、このスレッドに関連付けられたTSRは失われたイベントを示すので、この再開された実行はイジェクション・ハンドラへのジャンプを含んでいてもよい。したがって、イジェクタは、失われたイベントを扱うための復元コードを実行してもよい。本発明の範囲はこの点で限定されるものではないが、そのような復元コードはトランザクションのリスタート、別のUTMモードでの実行などを含んでいてもよい。図７の実施形態ではこの特定の実装をもって示されているが、本発明の範囲はこの点で限定されるものではない。
【００８５】
諸実施形態は、多くの異なるシステム型において実装されてもよい。ここで図８を参照するに、本発明のある実施形態に基づくシステムのブロック図が示されている。図８に示されるように、マルチプロセッサ・システム７００はポイントツーポイント相互接続システムであり、ポイントツーポイント相互接続７５０を介して結合された第一のプロセッサ７７０および第二のプロセッサ７８０を含む。図８に示されるように、プロセッサ７７０および７８０のそれぞれは、第一および第二のプロセッサ・コア（すなわち、プロセッサ・コア５７４ａ、７７４ｂおよびプロセッサ・コア７８４ａ、７８４ｂ）を含むマルチコア・プロセッサであってもよい。ただし、潜在的にはずっと多くのコアがプロセッサ内に存在していてもよい。プロセッサ・コアは、さまざまなUTMスレッドを実行してもよく、カーネル・モードへの制御の遷移後に、トランザクションを維持し、潜在的に、該トランザクションをアボートする必要性を回避できてもよい。
【００８６】
引き続き図８を参照するに、第一のプロセッサ７７０はさらに、メモリ・コントローラ・ハブ（MCH:  memory  controller  hub）５７２およびポイントツーポイント（P-P）インターフェース７７６および７７８を含む。同様に、第二のプロセッサ７８０は、MCH  ７８２およびP-Pインターフェース７８６および７８８を含む。図８に示されるように、MCHの７７２および７８２はこれらのプロセッサをそれぞれのメモリ、つまりメモリ７３２およびメモリ７３４に結合する。これらのメモリは、それぞれのプロセッサにローカルに取り付けられたメイン・メモリ（たとえばダイナミック・ランダム・アクセス・メモリ（DRAM））の一部であってもよい。第一のプロセッサ７７０および第二のプロセッサ７８０はそれぞれP-P相互接続７５２および７５４を介してチップセット７９０に結合されてもよい。図８に示されるように、チップセット７９０はP-Pインターフェース７９４および７９８を含む。
【００８７】
さらに、チップセット７９０は、P-P相互接続７３９によって、チップセット７９０を高性能グラフィクス・エンジン７３８と結合させるインターフェース７９２を含む。チップセット７９０のほうは、インターフェース７９６を介して第一のバス７１６に結合されてもよい。図８に示されるように、さまざまな入出力（I/O）装置７１４がバス・ブリッジ７１８とともに第一のバス７１６に結合されてもよい。該バス・ブリッジは、第一のバス７１６を第二のバス７２０に結合する。たとえばキーボード／マウス７２２、通信装置７２６ならびにある実施形態ではコード７３０を含んでいてもよいディスク・ドライブおよび他の大容量記憶装置のようなデータ記憶ユニット７２８を含むさまざまな装置が第二のバス７２０に結合されうる。さらに、オーディオI/O７２４が第二のバス７２０に結合されてもよい。
【００８８】
諸実施形態はコードで実装されてもよく、命令を実行するようシステムをプログラムするために使われることのできる、該命令を記憶した記憶媒体上に記憶されてもよい。記憶媒体は、これに限られないが、フロッピー（登録商標）ディスク、光ディスク、光ディスク、ソリッドステート・ドライブ（SSD:  solid  state  drive）、コンパクトディスク読み出し専用メモリ（CD-ROM）、書き換え可能型コンパクトディスク（CD-RW）および光磁気ディスクを含む任意の型のディスク、読み出し専用メモリ（ROM）、動的ランダム・アクセス・メモリ（DRAM）、静的ランダム・アクセス・メモリ（SRAM）、消去可能なプログラム可能型読み出し専用メモリ（EPROM）、フラッシュメモリ、電気的に消去可能なプログラム可能型読み出し専用メモリ（EEPROM）といったランダム・アクセス・メモリ（RAM）、磁気もしくは光学式カードまたは電子的な命令を記憶するのに好適な他の任意の型のメディアを含みうる。
【００８９】
本発明について限られた数の実施形態に関して記載してきたが、それから当業者は無数の修正および変形を認識するであろう。付属の請求項は、本発明の真の精神および範囲にはいる限り、すべてのそのような修正および変形をカバーすることが意図されている。
いくつかの態様を記載しておく。
〔態様１〕
第一のユーザー・スレッドでの無制限トランザクショナル・メモリ（UTM）トランザクションの実行中に、前記第一のユーザー・スレッドからリング遷移を介して、カーネル・モードにおいて制御を受け取る段階と；
前記カーネル・モードにある間に、前記UTMトランザクションの少なくとも一つのUTM属性をクリアし、前記第一のユーザー・スレッドに関連付けられたトランザクション状態レジスタ（TSR）の少なくとも一つのイベント・フィールドの状態を更新し、前記TSRを前記第一のユーザー・スレッドのコンテキストとともに保存する段階と；
前記TSRを含む前記第一のユーザー・スレッド・コンテキストをプロセッサに復元し、前記カーネル・モードから前記第一のユーザー・スレッドに遷移する段階とを含む、
方法。
〔態様２〕
制御が前記カーネル・モードに遷移させられるとき、前記第一のユーザー・スレッドが前記UTMトランザクションをアボートしない、態様１記載の方法。
〔態様３〕
前記カーネル・モードから前記第一のユーザー・スレッドへの遷移後に、前記TSRの前記少なくとも一つのイベント・フィールドの更新された状態に応じて、前記第一のユーザー・スレッドにおいてイジェクション・ハンドラを実行することをさらに含む、態様１記載の方法。
〔態様４〕
前記TSRの前記少なくとも一つのイベント・フィールドの更新された状態に基づいて、前記イジェクション・ハンドラにおける複数の復元コード経路のうちの一つを実行することをさらに含む、態様３記載の方法。
〔態様５〕
前記第一のユーザー・スレッドから前記カーネル・モードに遷移する前に前記UTMトランザクションおよび前記イジェクション・ハンドラをサスペンドさせる段階をさらに含み、該サスペンドは、前記TSRの少なくとも一つの状態インジケータを更新し、前記第一のユーザー・スレッドに関連付けられたトランザクション制御レジスタ（TCR）の制御インジケータを更新することを含む、態様３記載の方法。
〔態様６〕
前記第一のユーザー・スレッドから第二のユーザー・スレッドへの第一のコンテキスト・スイッチおよび前記第二のユーザー・スレッドからもとの前記第一のユーザー・スレッドへの第二のコンテキスト・スイッチを実行することをさらに含む、態様１記載の方法。
〔態様７〕
前記第二のユーザー・スレッドでのアプリケーションの実行中に、前記カーネル・モードにおいて、前記第二のユーザー・スレッドからリング遷移を介して制御を受け取り、前記カーネル・モードにある間に、UTMトランザクションの少なくとも一つのUTM属性をクリアし、前記第二のユーザー・スレッドがUTMトランザクションを実行していたのでない場合には、前記第二のユーザー・スレッドに関連付けられたTSR状態を更新しないことをさらに含む、態様６記載の方法。
〔態様８〕
命令を含む機械可読媒体を含む物品であって、前記命令は実行されたときに、システムに：
前記システムのユーザー・モードの第一のユーザー・スレッドで無制限トランザクショナル・メモリ（UTM）トランザクションを実行する段階と；
前記UTMトランザクションの実行中に、前記第一のユーザー・スレッドからカーネル・モードへの遷移を引き起こすイベントを被る段階と；
前記カーネル・モードに遷移する前に、前記UTMトランザクションをサスペンドするがアボートはしない段階とを実行させる、
物品。
〔態様９〕
前記イベントが例外を含む、態様８記載の物品であって、前記システムに、前記第一のユーザー・スレッドに関連付けられたプロセッサの少なくとも一つのトランザクション・レジスタの少なくとも一つの状態フィールドを更新させる命令をさらに含む、物品。
〔態様１０〕
前記システムに、前記例外に応答して実行される前記カーネル・モードの例外ハンドラから遷移を介して前記第一のユーザー・スレッドにおいて制御を受け取り、前記第一のユーザー・スレッドにおいて前記UTMトランザクションの実行を継続させる命令をさらに含む、態様９記載の物品。
〔態様１１〕
前記システムに、前記カーネル・モードの前記例外ハンドラの実行に基づいて前記ユーザー・モードにおける複数のコード経路の一つを実行させる命令をさらに含む、態様９記載の物品。
〔態様１２〕
前記複数のコード経路が、ユーザー・オペレーティング・システム（OS）ランタイム・システムのユーザー・モード例外ディスパッチャと、UTMランタイム・システムのユーザー・モード例外ディスパッチャと、前記UTMランタイム・システムのイジェクション・ハンドラとを含む、態様１１記載の物品。
〔態様１３〕
前記システムに、前記少なくとも一つのトランザクション・レジスタの前記少なくとも一つの状態フィールドの更新された状態に基づいて、前記イジェクション・ハンドラ中の複数の復元コード経路の一つを実行させる命令をさらに含む、態様１２記載の物品。
〔態様１４〕
それぞれ無制限トランザクショナル・メモリ（UTM）トランザクションのある側面を制御する複数のインジケータを有するトランザクション制御レジスタ（TCR）と、それぞれ前記UTMトランザクションの状態を示す複数のインジケータを有するトランザクション状態レジスタ（TSR）とを含む第一のレジスタ・セットを含むプロセッサと；
命令を含む記憶媒体とを有するシステムであって、
前記命令は、当該システムが、第一のユーザー・スレッドでのUTMトランザクションの実行中に、該UTMトランザクションの間に被った例外に応答して、カーネル・モードにおいて、ユーザー・モードの前記第一のユーザー・スレッドから遷移を介して制御を受け取り、前記カーネル・モードにおいて前記例外に対処するかどうかを決定し、もし対処するなら、前記カーネル・モードにおいて前記例外に対処し、もしそうでないなら、前記例外の型および前記UTMトランザクションのUTMモードに基づいて、制御を移すべき前記ユーザー・モードの複数のコード経路のうちの一つを選択する、ことを可能にする、
システム。
〔態様１５〕
前記命令がさらに、前記システムが、前記ユーザー・モードに制御を遷移させる前に、前記例外の発生を示すために、前記カーネル・モードにある間に、TSRの少なくとも一つのイベント・フィールドを更新できるようにする、態様１４記載のシステム。
〔態様１６〕
前記命令がさらに、前記システムが、UTMランタイム・システムが前記UTMモードについて前記例外に対処するためのコード経路を含むかどうかを判定できるようにする、態様１４記載のシステム。
〔態様１７〕
前記命令がさらに、前記システムが、前記UTMランタイム・システムが前記コード経路を含まない場合に、前記UTMランタイム・システムのイジェクション・ハンドラを前記コード経路として選択できるようにする、態様１６記載のシステム。
〔態様１８〕
前記イジェクション・ハンドラが複数の実行経路を含み、各実行経路は異なるイベントに関連付けられており、さらに、前記命令は、前記システムが、前記TCRおよび前記TSRの少なくとも一方における情報の解析に基づいて前記イジェクション・ハンドラにおける実行経路の一つを実行できるようにする、態様１７記載のシステム。
〔態様１９〕
前記命令がさらに、前記システムが、前記カーネル・モードへの遷移の前に前記UTMトランザクションをサスペンドさせるがアボートはしないことをできるようにする、態様１７記載のシステム。
〔態様２０〕
前記命令がさらに、前記システムが、前記カーネル・モードにおいて複数のエントリーを含むテーブルにアクセスできるようにし、各エントリーはUTMモード、例外型および前記UTMモードおよび前記例外型に基づいて実行されるべき前記UTMランタイム・システムのコード経路を含む、態様１６記載のシステム。
【図１】
0005551269.tif 000002
【図２】
0005551269.tif 000003
【図３】
0005551269.tif 000004
【図４】
0005551269.tif 000005
【図５】
0005551269.tif 000006
【図６】
0005551269.tif 000007
【図７】
0005551269.tif 000008
【図８】
0005551269.tif 000009