(57)【特許請求の範囲】
【請求項１】
第１スレッドにおいてトランザクショナルメモリ（ＴＭ）トランザクションを実行するステップと、
前記ＴＭトランザクション中、プロセッサのキャッシュメモリの第１バッファにデータのブロックをバッファリングするステップと、
前記第１バッファの前記ブロックの位置におけるデータが更新されるエンカウンタタイムに、前記ブロックのオーナシップを取得するため前記ブロックに対するライトモニタを取得するステップと、
を有する方法。
【請求項２】
前記エンカウンタタイムに前記ブロックに対するライトロックを取得するステップをさらに有する、請求項１記載の方法。
【請求項３】
前記ライトモニタを取得するステップは、前記第１スレッドによる前記ブロックに対するライトモニタのオーナシップを示すため、前記第１スレッドに対応する前記ブロックのヘッダのモニタインジケータを更新することを含む、請求項１記載の方法。
【請求項４】
ユーザレベルライトモニタ命令を用いて前記ブロックのモニタインジケータを更新する前記ライトモニタを取得するステップをさらに有する、請求項３記載の方法。
【請求項５】
前記第１スレッドが前記ブロックに対するライトモニタを消失していない場合には前記ＴＭトランザクションをコミットし、そうでない場合には前記ＴＭトランザクションを中断するステップをさらに有する、請求項３記載の方法。
【請求項６】
前記ＴＭトランザクションをコミットした後に前記ライトモニタを維持し、前記ライトモニタを第２ＴＭトランザクションにおいて利用するステップをさらに有する、請求項５記載の方法。
【請求項７】
ユーザレベルバッファリングストア命令を用いて、前記データを前記キャッシュメモリのキャッシュラインに書き込むことによって、前記ブロックの位置におけるデータを更新するステップをさらに有し、
前記ユーザレベルバッファリングストア命令は、バッファリング状態から前記キャッシュラインのキャッシュコヒーレンシ状態への更新に、前記キャッシュラインが前記第１スレッドにおいてローカルに可視的であるが、グローバルには可視的でないことを示させる、請求項１記載の方法。
【請求項８】
前記ライトロックと前記ライトモニタとを取得するため、第１ライトバリアを実行するステップをさらに有する、請求項２記載の方法。
【請求項９】
前記ブロックがバッファリングされているか決定するため、前記第１バッファに格納されている前記ブロックの第２位置に対してユーザレベルテスト命令を実行することを含む、第２ライトバリアをフィルタリングし、前記第２位置を更新するために第２ライトロック又は第２ライトモニタを取得しないステップをさらに有する、請求項８記載の方法。
【請求項１０】
前記ＴＭトランザクションのコミット後に前記ブロックに対して前記ライトモニタをモニタリングし、第２ＴＭトランザクションのライトバリアをフィルタリングし、前記第１バッファに格納されている前記ブロックの第２位置を更新するため、第２ライトロック又は第２ライトモニタを取得しないステップをさらに有する、請求項２記載の方法。
【請求項１１】
前記ＴＭトランザクションのコミットメントにおいて前記ブロックに対するライトロックを取得するステップをさらに有する、請求項１記載の方法。
【請求項１２】
実行されると、システムに、
トランザクショナルメモリ（ＴＭ）トランザクションの実行中、プロセッサのキャッシュメモリに格納されているブロックの位置におけるデータを、前記ブロックが前記キャッシュメモリにある場合、前記データを格納するため、前記データを前記キャッシュメモリに格納することを可能にするが、システムメモリに以降に書き込むすることを可能にしないユーザレベルバッファリングストア命令を用いて格納させ、
そうでない場合、第１位置に前記データを格納させ、前記格納されたデータの前記第１位置のアドレスをライトログに格納させ、
前記ＴＭトランザクションのコミットメントにおいて前記ブロックのライトモニタを取得させ、ライトモニタされたブロックのデータが消失していない場合、前記ＴＭトランザクションをコミットさせる、
命令を含むマシーンアクセス可能な記憶媒体を有する物。
【請求項１３】
実行されると、前記システムに前記コミットメントの代わりにエンカウンタタイムに前記ライトモニタを取得させる命令をさらに有し、
前記ＴＭトランザクションのイーガモードはアクティブである、請求項１２記載の物。
【請求項１４】
実行されると、前記システムに前記ライトモニタが取得されたか判断するため、前記第１位置に対してユーザレベルテスト命令を実行させる命令をさらに有する、請求項１２記載の物。
【請求項１５】
実行されると、前記システムにコミットメントにおいて何れかバッファリングされたブロックがトランザクションステータスレジスタ（ＴＳＲ）のインジケータに基づき消失したか判断させ、何れかのバッファリングされたブロックが消失した場合には前記ＴＭトランザクションを中断させ、前記ＴＭトランザクションの再実行のため、トランザクション実行モードを選択させる命令をさらに有する、請求項１２記載の物。
【請求項１６】
命令を実行する少なくとも１つのコアを含む第１プロセッサと、
前記第１プロセッサに接続されるシステムメモリと、
を有するシステムであって、
前記システムメモリは、前記第１プロセッサが、トランザクショナルメモリ（ＴＭ）トランザクション中、前記システムメモリに格納されているオブジェクトの第１の所定部分に関連するメタデータにアクセスさせ、前記メタデータが前記オブジェクトのシャドーコピーのアドレスを含むか判断させ、含まない場合には前記オブジェクトに対して第１バリア処理を実行させ、前記メタデータが前記アドレスを含む場合、前記第１バリア処理を実行せず、前記第１バリア処理が実行された場合、前記オブジェクトの第１の所定部分に関連する前記メタデータに前記オブジェクトのシャドーコピーのアドレスを格納させる命令を含むシステム。
【請求項１７】
前記オブジェクトの第１の所定部分は、前記オブジェクトのオブジェクトヘッダの第１スロットに対応する、請求項１６記載のシステム。
【請求項１８】
前記命令はさらに、前記第１プロセッサが、前記オブジェクトの第１の所定部分に関連するメタデータに含まれるアドレスを用いて、前記オブジェクトのシャドーコピーにアクセスすることを可能にする、請求項１６記載のシステム。
【請求項１９】
前記命令はさらに、前記第１プロセッサが、前記オブジェクトからのデータの読み込み前、前記アクセスと判断とを実行することを可能にする、請求項１６記載のシステム。
【請求項２０】
前記命令はさらに、前記第１プロセッサが、
前記オブジェクトの第２の所定部分に関連するメタデータにアクセスし、
前記第２の所定部分に関連するメタデータがシャドーコピーアドレスを含むか判断する、
ことを可能にする、請求項１６記載のシステム。
【請求項２１】
前記メタデータが前記シャドーコピーアドレスを含まない場合、前記命令はさらに、前記第１プロセッサが前記オブジェクトに対して第１バリア処理を実行し、前記オブジェクトの第１及び第２の所定部分に関連するメタデータに前記シャドーコピーアドレスを格納することを可能にする、請求項２０記載のシステム。
【請求項２２】
前記命令は、ナイーブコードアプリケーションが、前記システムメモリに格納されているブロックの第１の所定部分に関連するメタデータにアクセスし、前記メタデータが前記ブロックのシャドーコピーのアドレスを含むか判断し、含まない場合には前記ブロックに対してバリア処理を実行し、前記メタデータが前記アドレスを含む場合には前記バリア処理を実行せず、前記バリア処理が実行された場合、前記ブロックの第１の所定部分に関連する前記メタデータに前記ブロックのシャドーコピーのアドレスを格納することを可能にする、請求項１６記載のシステム。
【請求項２３】
第１スレッドにおいてトランザクショナルメモリ（ＴＭ）トランザクションを実行するステップと、
前記ＴＭトランザクションにおいて実行されるデータのライトがハードウェアバッファ内に適合可能であるか判断するステップと、
適合可能である場合、前記データのコピーが前記ハードウェアバッファにあるか判断し、ある場合には前記データを書き込むため、前記データが前記第１スレッドにローカルに可視的であるが、グローバルには可視的でないことを示すためのユーザレベルバッファリングストア命令を用いて、前記ハードウェアバッファにおいて前記データを更新するステップと、
前記コピーが前記ハードウェアバッファにない場合、前記ユーザレベルバッファリングストア命令を用いて、前記ハードウェアバッファの位置に前記データのバッファリングコピーを生成し、前記ユーザレベルバッファリングストア命令を用いて、前記バッファリングコピーの前記データを更新するステップと、
を有する方法。
【請求項２４】
前記ＴＭトランザクションがコミットタイムロッキングスキームに従う場合、前記位置のアドレスをライトログに格納し、前記位置に前記データを格納し、前記ＴＭトランザクションがエンカウンタタイムロッキングスキームに従う場合、前記データが前記位置に格納されるエンカウンタタイムに前記位置のオーナシップを取得するため、前記位置に対してライトモニタを取得するステップをさらに有する、請求項２３記載の方法。
【請求項２５】
コミットメントにおいて前記位置のライトモニタを取得し、前記ＴＭトランザクションが前記コミットタイムロッキングスキームに従うとき、前記位置のデータが消失していない場合、前記ＴＭトランザクションをコミットするステップをさらに有する、請求項２４記載の方法。
【請求項２６】
前記コピーが前記ハードウェアバッファにある場合、前記データがバッファリングされているか判断するため第２位置に対してユーザレベルテスト命令を実行することを含む、バリア処理をフィルタリングし、前記ハードウェアバッファにおける第２位置を更新するため第２ライトモニタを取得しない、請求項２５記載の方法。
【請求項２７】
前記ＴＭトランザクションが前記ハードウェアバッファをオーバフローする場合、前記ＴＭトランザクションを中断し、前記ＴＭトランザクションを再実行するトランザクション実行モードを選択するため、イジェクションハンドラに制御を提供するステップをさらに有する、請求項２３記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
ソフトウェアトランザクショナルメモリ（ＳＴＭ）は、トランザクション内で変更された複数バージョンのデータを維持するバージョン管理機構を要求する。それぞれがソフトウェアにより実現されるときオーバヘッドを有する２つのバージョン管理アプローチが存在する。第１アプローチは、イーガバージョニング（ｅａｇｅｒ  ｖｅｒｓｉｏｎｉｎｇ）と呼ばれ、新たなデータ値が適当な位置に書き込まれ、古い値がロールバックのケースにおいてアンドゥログをに格納される。このアプローチは、各書き込みに対してアンドゥログを維持し、ロールバックにおいてアンドゥログから値を復元するという２つのオーバヘッドを有する。いくつかの言語レベルＴＭメモリモデルは、投機的値を非トランザクショナルアクセスに可視的にするため、イーガバージョニングの利用を排除する。
【０００２】
第２アプローチは、レイジバージョニング（ｌａｚｙ  ｖｅｒｓｉｏｎｉｎｇ）と呼ばれ、新たなデータ値がソフトウェアライトバッファに書き込まれ、その後にコミットにより、それらの宛先位置にコピーされる。このアプローチは、ソフトウェアライトバッファを維持し、リードによりソフトウェアライトバッファにおいて値を検索し、コミットにより、ソフトウェアライトバッファからの値をコピーするという３つのオーバヘッドを有する。レイジバージョニングは、エンカウンタタイム又はコミットタイムにおいて書き込まれたデータをロック可能であり、イーガバージョニングは、エンカウンタタイムにのみロック可能である。何れのアプローチにおいてもわかるように、ＳＴＭシステムのバージョン管理のための有意なオーバヘッドが存在する。
【図面の簡単な説明】
【０００３】
【図１】図１は、本発明の一実施例によるプロセッサのブロック図である。
【図２】図２は、本発明の一実施例によるプロセッサへのデータアイテムのメタデータの保持のブロック図である。
【図３Ａ】図３Ａは、本発明の一実施例によるイーガライトロッキング及びモニタリングを実行する方法のフロー図である。
【図３Ｂ】図３Ｂは、本発明の一実施例によるイーガライトモニタリング及びロッキングトランザクションにおけるトランザクションコミットを実行する方法のフロー図である。
【図４Ａ】図４Ａは、本発明の一実施例によるレイジライトロッキング及びモニタリングを実行する方法のフロー図である。
【図４Ｂ】図４Ｂは、本発明の一実施例によるレイジライトモニタリング及びロッキングのためのコミット方法のフロー図である。
【図５】図５は、本発明の一実施例によるメタデータを利用してオブジェクトのシャドーコピーの位置を効率的に決定する方法のフロー図である。
【図６】図６は、本発明の一実施例によるシステムのブロック図である。
【発明を実施するための形態】
【０００４】
本発明の実施例を用いて、ハードウェアサポートが、ハードウェアバッファ（キャッシュや他の限定サイズのハードウェアバッファなど）に適合するライトセットを有するトランザクションのためのバージョン管理を高速化するためバッファ値に提供されてもよい。キャッシュにトランザクショナルライトをバッファリングすることによって、レイジバージョニングがハードウェアにより実行可能であり、ソフトウェアバージョン管理のオーバヘッドを解消し、ソフトウェアトランザクショナルメモリシステムを高速化する。
【０００５】
イーガバージョニングとレイジバージョニングとの双方を実行し、キャッシュに常駐するアンバウンドなリードセットのためのハードウェアサポートと合成可能なソフトウェアトランザクショナルメモリシステムを高速化するため、実施例がさらに利用されてもよい。一実施例では、明示的なバッファリングされたストア命令（命令セットアーキテクチャ（ＩＳＡ）のユーザレベル命令であってもよい）が、キャッシュにトランザクショナルライトを格納するのに利用されてもよい。さらに、明示的なライトモニタ命令（ＩＳＡの異なるユーザレベル命令であってもよい）が、バッファリングされたストアと同時に（エンカウンタタイムライトモニタリング）又はコミットタイムに（コミットタイムライトモニタリング）、バッファリングされたキャッシュラインの排他的なオーナシップを取得するのに利用されてもよい。いくつかの実現形態では、単一の命令が、バッファリングされたライトとライトモニタとの双方を実行するのに利用されてもよい。本発明の実施例による上記ユーザレベル命令と他の技術とが、ナイーブコードとオブジェクトベースシステムとの双方について利用可能である。
【０００６】
以下でさらに説明されるように、モニタリングは、より迅速なコンフリクトの検出、すなわち、パラレルな実行を試みている２つのトランザクションの間のコンフリクトをサポートするのにソフトウェアにより利用可能なハードウェア機能である。一般に、モニタリングは、より低コストでソフトウェアロックと同様の機能を提供する。物理的メモリの各パーティション（モニタブロック）は、各スレッドについてプライベートなリードモニタとライトモニタとを有する。あるいは、ライトバリアは、暗黙的にハードウェアにより実行されてもよい。アクセスされたデータ値のロッキング及びライトモニタリングは、異なる実現形態ではエンカウンタタイム又はコミットタイムに実行される。何れかのバッファリングされたラインの消失（キャッシュオーバフロー又は他のトランザクションによるコンフリクトするアクセスなどによる）は、トランザクションを中断及び再開させる。アンバウンディッドＴＭ（ＵＴＭ）システムにおいて利用可能な実現形態の背景として、ＵＴＭトランザクションに利用可能な一例となるハードウェアを確認することが有用である。一般に、ＵＴＭトランザクションは、ハードウェアにより完全に実現可能なトランザクション、すなわち、キャッシュ常駐トランザクションと、ハードウェアとソフトウェアとの組み合わせを用いて実行されるアンバウンディッドトランザクションとに関してハードウェアの利用を可能にする。図１を参照して、複数のスレッドを同時に実行可能なプロセッサの実施例が示される。プロセッサ１００は、ハードウェアトランザクションの実行のハードウェアサポートを含むものであってもよいことに留意されたい。ハードウェアトランザクションの実行と共に、又は別々に、プロセッサ１００はまた、本発明の実施例によるＵＴＭなど、ＳＴＭのハードウェアアクセラレーション、ＳＴＭの別々の実行又はこれらの組み合わせのためのハードウェアサポートを提供する。プロセッサ１００は、マイクロプロセッサ、埋め込みプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ又はコードを実行する他の装置などの何れかのタイプのプロセッサであってもよい。図示されるように、プロセッサ１００は、複数の処理要素を有する。
【０００７】
図１に示されるように、物理的なプロセッサ１００は、より高いレベルのキャッシュ１１０へのアクセスを共有する２つのコア１０１，１０２を有する。プロセッサ１００は、非対称的なコア、すなわち、異なるコンフィギュレーションを有するコアを有してもよいが、機能ユニット、ロジック及び／又は対称的なコアが示される。この結果、コア１０１と同一なものとして示されるコア１０２は、繰り返しの説明を回避するため詳細には説明されない。さらに、コア１０１は２つのハードウェアスレッド１０１ａ，１０１ｂを有し、コア１０２は２つのハードウェアスレッド１０２ａ，１０２ｂを有する。従って、オペレーティングシステムなどのソフトウェアエンティティは、４つの個別のプロセッサとして、すなわち、４つのソフトウェアスレッドを同時に実行可能な４つの論理プロセッサ又は処理要素としてプロセッサ１００をみなすこともできる。ここでは、第１スレッドがアーキテクチャ状態レジスタ１０１ａと関連付けされ、第２スレッドがアーキテクチャ状態レジスタ１０１ｂに関連付けされ、第３スレッドがアーキテクチャ状態レジスタ１０２ａに関連付けされ、第４スレッドがアーキテクチャ状態レジスタ１０２ｂに関連付けされる。図示されるように、アーキテクチャ状態レジスタ１０１ａは、アーキテクチャ状態レジスタ１０１ｂに複製され、このため、個々のアーキテクチャ状態／コンテクストは、論理プロセッサ１０１ａ，１０１ｂについて格納可能である。一実施例では、アーキテクチャ状態レジスタは、トランザクション中に発生するイベント（トランザクションの中断など）を処理するのに利用可能なイジェクションハンドラの位置を特定するため、トランザクションステータスレジスタ（ＴＳＲ）、トランザクションコントロールレジスタ（ＴＣＲ）及びイジェクション命令ポインタレジスタなどのＵＴＭトランザクションを実現するのに利用されるレジスタを有するものであってもよい。
【０００８】
命令ポインタやリネームアロケータロジック１３０のリネーミングロジックなどの他の小さなリソースがまた、スレッド１０１ａ，１０１ｂのために複製されてもよい。リオーダ／リタイアメントユニット１３５のリオーダバッファ、命令変換ルックアサイドバッファ（ＩＴＬＢ）１２０、ロード／ストアバッファ、キューなどのいくつかのリソースは、パーティショニングを介し共有されてもよい。汎用内部レジスタ、ページテーブルベースレジスタ、ローレベルデータキャッシュ、ローレベルデータＴＬＢ１１５、実行ユニット１４０、アウトオブオーダユニット１３５の一部などの他のリソースは、完全に共有される可能性がある。
【０００９】
図示されるように、プロセッサ１００は、システムメモリ１７５、チップセット、ノースブリッジ又は他の集積回路などのプロセッサ１００の外部の装置と通信するためのバスインタフェースモジュール１０５を有する。メモリ１７５は、プロセッサ１００に専用とされてもよく、又はシステムの他の装置と共有してもよい。より高いレベル又はファーザアウトキャッシュ１１０は、より高いレベルのキャッシュ１１０から最近フェッチされた要素をキャッシュするためのものである。より高いレベル又はファーザアウトとは、実行ユニットからより離れた又は増加したキャッシュレベルを表すことに留意されたい。一実施例では、より高いレベルのキャッシュ１１０は第２レベルデータキャッシュである。しかしながら、より高いレベルのキャッシュ１１０はこれに限定されず、命令キャッシュに関連付け又は含むものであってもよい。トレースキャッシュ、すなわち、あるタイプの命令キャッシュは、最近復号化されたトレースを格納するため、デコーダ１２５の後に接続されてもよい。モジュール１２０はまた。実行／抽出されるブランチを予測するブランチターゲットバッファと、命令のためにアドレス変換エンティティを格納するＩＴＬＢとを有する。
【００１０】
デコードモジュール１２５は、フェッチユニット１２０に接続され、フェッチされた要素を復号化する。一実施例では、プロセッサ１００は、プロセッサ１００上で実行可能な命令を規定／指定するＩＳＡと関連付けされる。ここで、ＩＳＡによりしばしば認識されるマシーンコード命令は、実行対象の命令又は処理を参照／指定するオペコードと呼ばれる命令の一部を含む。
【００１１】
一例では、アロケータ及びリネーマブロック１３０は、命令処理結果を格納するためのレジスタファイルなどのリソースを確保するためのアロケータを有する。しかしながら、スレッド１０１ａ，１０１ｂは、アロケータ及びリネーマブロック１３０がまた、命令結果をトラックするためのリオーダリネーマなどの他のリソースを確保するアウトオブオーダ実行が可能である。ユニット１０３はまた、プロセッサ１００の内部の他のレジスタにプログラム／命令リファレンスレジスタをリネームするためのレジスタリネーマを有してもよい。リオーダ／リタイアメントユニット１３５は、上述されたリオーダバッファ、ロードバッファ及びストアバッファなど、アウトオブオーダ実行と、アウトオブオーダ実行された命令の直近のインオーダリタイアメントとをサポートするためのコンポーネントを有する。
【００１２】
一実施例では、スケジューラ及び実行ユニットブロック１４０は、実行ユニット上の命令／処理をスケジューリングするスケジューラユニットを有する。例えば、浮動小数点命令は、利用可能な浮動小数点実行ユニットを有する実行ユニットのポートにスケジューリングされる。実行ユニットに関連付けされるレジスタファイルはまた、情報命令処理結果を格納するた含まれる。一例となる実行ユニットは、浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、ストア実行ユニット及び他の既知の実行ユニットを含む。
【００１３】
より低いレベルのデータキャッシュ及びデータ変換バッファ（Ｄ−ＴＬＢ）１５０は、実行ユニット１４０に接続される。データキャッシュは、メモリコヒーレンシ状態において保持されるデータオペランドなどの最近利用／実行された要素を格納するためのものである、Ｄ−ＴＬＢは、最近のバーチャル／リニアから物理アドレスへの変換を格納するためのものである。具体例として、プロセッサは、物理メモリを複数のバーチャルページに分割するためページテーブル構成を有してもよい。
【００１４】
一実施例では、プロセッサ１００は、ハードウェアトランザクショナル実行、ソフトウェアトランザクショナル実行又はこれらの組み合わせ若しくはハイブリッドが可能である。コードのクリティカル又はアトミックなセクションと呼ばれてもよいトランザクションは、アトミックグループとして実行される命令、処理又はマイクロ処理のグループ化を含む。例えば、命令又は処理は、トランザクション又はクリティカルセクションを区別するのに利用されてもよい。一実施例では、これらの命令は、上述されたデコーダなどの、プロセッサ１００のハードウェアにより認識可能なＩＳＡなどの命令セットの一部である。しばしば、これらの命令は、ハイレベル言語からハードウェア認識可能なアセンブリ言語にコンパイルされると、復号化段階中にデコーダが認識する処理コード（オペコード）又は命令の他の部分を含む。
【００１５】
典型的には、トランザクションの実行中、メモリへの更新は、トランザクションがコミットされるまでグローバルに可視的にはされない。一例として、ある位置へのトランザクショナルライトは、トランザクショナルライトを含むトランザクションがコミットされるまでライトデータが転送されない他のスレッドからのリードに応答して、ローカルスレッドに可視的である。トランザクションが依然として保留中である間、以下でより詳細に説明されるように、メモリからロード及びライとされるデータアイテム／要素が追跡される。トランザクションがコミットポイントに到達すると、当該トランザクションに対してコンフリクトが検出されなかった場合、トランザクションはコミットされ、トランザクション中に行われたアップデートはグローバルに可視的なものとされる。
【００１６】
しかしながら、トランザクションがそれの保留中に無効にされた場合、トランザクションは中断され、アップデートをグローバルに可視的にすることなく再開される。この結果、ここで用いられるようなトランザクションの保留は、実行を介したが、コミット又は中断されていない、すなわち、保留中のトランザクションを表す。
【００１７】
一実施例では、プロセッサ１００は、ＨＴＭ（Ｈａｒｄｗａｒｅ  Ｔｒａｎｓａｃｔｉｏｎａｌ  Ｍｅｍｏｒｙ）システム内のハードウェア／ロジックを利用するトランザクションを実行可能である。ＨＴＭを実現するとき、アーキテクチャの観点とマイクロアーキテクチャの観点との双方からの多数の具体的な実現形態の詳細が存在する。その大部分は、本発明の実施例を実施例を不必要に不明りょうにすることを回避するため、ここでは説明されない。しかしながら、一部の構成及び実現形態は例示のため開示される。しかしながら、これらの構成及び実現形態は不要であり、異なる実現形態の詳細を有する他の構成により拡張及び／又は置換されてもよい。
【００１８】
一般に、プロセッサ１００は、ＳＴＭシステムとＨＴＭシステムとの双方の効果を利用することを試みるＵＴＭシステム内のトランザクションを実行可能である。例えば、ＨＴＭは、しばしば小さなトランザクションを実行するのに迅速かつ効率的である。これは、アクセストラッキング、コンフリクト検出、検証及びトランザクションのコミットのすべてを実行するためソフトウェアに依拠しないためである。しかしながら、ＨＴＭは通常はより小さなトランザクションを処理することしか可能でなく、ＳＴＭはアンバウンドディッドサイズのトランザクションを処理することが可能である。従って、一実施例では、ＵＴＭシステムは、より小さなトランザクションを実行するハードウェアと、ハードウェアにとって大きすぎるトランザクションを実行するソフトウェアとを利用する。以下の説明から理解できるように、ソフトウェアがトランザクションを処理しているときでさえ、ソフトウェアを支援及び高速化するためのハードウェアが利用されてもよい。同一のハードウェアがまた、純粋なＳＴＭシステムをサポート及び高速化するのに利用されてもよい。
【００１９】
上述されるように、トランザクションは、プロセッサ１００内のローカル処理要素と他の処理要素との双方によるデータアイテムへのトランザクショナルメモリアクセスを含む。トランザクショナルメモリシステムの安全な機構がない場合、これらのアクセスの一部は、無効なデータ及び実行、すなわち、リードを無効にするデータへのライト又は無効なデータのリードを生じさせる。この結果、プロセッサ１００は、後述されるように、リードモニタ及びライトモニタなどの潜在的なコンフリクトの特定のため、データアイテムのメモリアクセスを追跡又はモニタするロジックを有する。
【００２０】
一実施例では、プロセッサ１００は、データアイテムに関連するアクセス及び潜在的な以降のコンフリクトを検出又は追跡するモニタを有する。一例として、プロセッサ１００のハードウェアは、モニタ対象と決定されたロード及びストアを追跡するためのリードモニタとライトモニタとを含む。一例として、ハードウェアリードモニタ及びライトモニタは、基礎となるストレージ構成の粒度にかかわらず、データアイテムの粒度によりデータアイテムをモニタするものである。一実施例では、データアイテムは、少なくともデータアイテム全体が適切にモニタされることを確実にするため、ストレージ構成の粒度で関連付けされるトラッキング機構により限定される。
【００２１】
具体例として、リード及びライトモニタは、より低いレベルのデータキャッシュ１５０内の位置など、これらの位置に関連付けされたアドレスにおけるロード及びストアをモニタするため、キャッシュ位置に関連する属性を含む。ここで、データキャッシュ１５０のキャッシュ位置のリード属性は、リードイベントに対して、同一のアドレスへの潜在的なコンフリクトするライトをモニタするため、キャッシュ位置に関連するアドレスに設定される。この場合、ライト属性は、同一のアドレスにおけるコンフリクトするリード及びライトの可能性をモニタするため、ライトイベントについてと同様に機能する。さらに、ハードウェアは、キャッシュ位置がモニタされることを示すよう設定されたリード及び／又はライト属性を有するキャッシュ位置へのリード及びライトのスヌープに基づき、コンフリクトを検出可能である。その反対に、一実施例では、リード及びライトモニタの設定、又はキャッシュ位置をバッファリングされた状態に更新することは、オーナシップリクエストのためのリード又はリードリクエストなどのスヌープを生じさせ、検出対象の他のキャッシュにおいてモニタされたアドレスとのコンフリクトを可能にする。
【００２２】
従って、設計に基づき、キャッシュコヒーレンシリクエストとキャッシュラインのモニタされたコヒーレンシ状態との異なる組み合わせが、共有されたリードモニタ状態でデータアイテムを保持するキャッシュラインと、データアイテムへのライトリクエストを示すスヌーピングなどの潜在的なコンフリクトを生じさせる。その反対に、バッファリングされたライト状態にあるデータアイテムを保持するキャッシュラインと、データアイテムへのリードリクエストを示す外部スヌープとは、潜在的にコンフリクトするとみなされてもよい。一実施例では、アクセスリクエストと属性状態とのこのような組み合わせを検出するため、スヌープロジックが、コンフリクト検出／報告のためのモニタ及び／又はロジックなどのコンフリクト検出／報告ロジックと共に、コンフリクトを報告するステータスレジスタとに接続される。
【００２３】
しかしながら、状態とシナリオとの何れかの組み合わせは、コミット命令などの命令により規定されるトランザクションに対する無効化とみなされてもよい。トランザクションの非コミットについて考慮されるファクタの具体例は、トランザクションのアクセスされたメモリ位置とのコンフリクトの検出、モニタ情報の消失、バッファリングデータの消失、トランザクションのアクセスされたデータアイテムに関連するメタデータの消失、及びインターラプト、リング遷移又は明示的なユーザ命令などの他の無効化イベントの検出（再開されたトランザクションが継続できなことを仮定する）を含む。
【００２４】
一実施例では、プロセッサ１００のハードウェアは、バッファリングされてトランザクションの更新を保持する。上述されるように、トランザクショナルライトは、トランザクションのコミットまでグローバルに可視的にはされない。しかしながら、トランザクショナルライトに関連するローカルソフトウェアスレッドは、以降のトランザクショナルアクセスのためトランザクションの更新にアクセス可能である。第１の例として、別のバッファ構成が、他の外部スレッドでなくローカルスレッドへの更新を提供可能なバッファリングされた更新を保持するためにプロセッサ１００に備えられる。しかしながら、別のバッファ構成を含めることは、コストがかかり複雑なものとなる可能性がある。
【００２５】
他方、他の例として、データキャッシュ１５０などのキャッシュメモリが、同一のトランザクション機能を提供しながら、更新をバッファリングするのに利用される。ここで、キャッシュ１５０は、バッファされたコヒーレンシ状態においてデータアイテムを保持可能であり、１つのケースでは、新たなバッファされたコヒーレンシ状態が、ＭＥＳＩＢプロトコルを形成するためのＭＥＳＩ（Ｍｏｄｉｆｉｅｄ  Ｅｘｃｌｕｓｉｖｅ  Ｓｈａｒｅｄ  Ｉｎｖａｌｉｄ）プロトコルなどのキャッシュコヒーレンシプロトコルに追加される。バッファリングされたデータアイテムに対するローカルリクエストに応答して、すなわち、バッファされたコヒーレンシ状態に保持されるデータアイテムに対するローカルリクエストに応答して、キャッシュ１５０は、内部的なトランザクションシーケンシャルオーダリングを確実にするため、データアイテムをローカル処理要素に提供する。しかしながら、外部のアクセスリクエストに応答して、トランザクションの更新されたデータアイテムがコミットまでグローバルに可視的にされないことを確実にするため、ミスレスポンスが提供される。さらに、キャッシュ１５０のラインがバッファされたコヒーレンシ状態に保持され、イビクションのため選択されると、バッファされた更新が、より高いレベルのキャッシュメモリには書かれず、バッファされた更新は、コミット後までメモリシステムを介して拡散されず、すなわち、グローバルに可視的なものにされない。コミットされると、バッファされたラインは、データアイテムをグローバルに可視的にするため、修正された状態に移行される。
【００２６】
内部及び外部という用語は、しばしばキャッシュを共有するトランザクション又は処理要素の実行に関連付けされるスレッドの観点に関するものであることに留意されたい。例えば、トランザクションの実行に関連するソフトウェアスレッドを実行するための第１処理要素は、ローカルスレッドと呼ばれる。従って、上記説明では、アドレスのキャッシュラインがバッファされたコヒーレンシ状態で保持される、第１スレッドにより以前に書かれたアドレスにおけるストア又はロードが受信される場合、キャッシュラインのバッファされたバージョンは、それがローカルスレッドであるため、第１スレッドに提供される。他方、第２スレッドは、同一のプロセッサ内の他の処理要素上で実行されてもよいが、キャッシュラインがバッファされた状態で保持されるためのトランザクション、すなわち、外部スレッドの実行に関連付けされない。従って、第２スレッドからアドレスへのロード又はストアは、キャッシュラインのバッファされたバージョンをミスし、通常のキャッシュ置換は、より高いレベルのメモリからのキャッシュラインのバッファされていないバージョンを抽出するのに利用される。
【００２７】
ここで、内部／ローカル及び外部／リモートスレッドは、同一のプロセッサ上で実行されており、いくつかの実施例では、キャッシュへのアクセスを共有するプロセッサの同一のコア内の別々の処理要素上で実行される。しかしながら、これらの用語の使用はこれに限定されるものでない。上述されるように、ローカルとは、トランザクションの実行に関連する単一のスレッドに固有である代わりに、キャッシュへのアクセスを共有する複数のスレッドを表し、外部又はリモートとは、キャッシュへのアクセスを共有しないスレッドを表すものであってもよい。図１を最初に参照して上述されたように、プロセッサ１００のアーキテクチャは、説明のための純粋に例示的なものである。例えば、他の実施例では、ＵＢＴハードウェアは、複雑なリネーム／アロケータ及びリオーダ／リタイアメントユニットを含まないはるかにシンプルなインオーダ実行プロセッサ設計を備えたプロセッサについて実現可能である。同様に、メタデータを参照するためデータアドレスを変換する具体例もまた例示的なものであり、同一のメモリの別のエントリのメタデータとデータとを関連付ける何れかの方法が利用されてもよい。
【００２８】
図２に移って、プロセッサにデータアイテムのメタデータを保持する実施例が示される。図示されるように、データアイテム２１６のメタデータは、メモリ２１５にローカルに保持される。メタデータは、データアイテム２１６に関連するトランザクション情報などの、データアイテム２１６に関連する何れかの性質又は属性を含む。メタデータのいくつかの例示的な具体例が以下に含まれ、開示されるメタデータの具体例は、純粋に例示的なものである。また、メタデータ位置２１７は、データアイテム２１６の情報と他の属性との何れかの組み合わせを保持するものであってもよい。
【００２９】
第１の具体例として、メタデータ２１７は、データアイテム２１６がトランザクション内で以前にアクセス、バッファリング及び／又はバックアップされている場合、トランザクションの書き込まれたデータアイテム２１６のバックアップ又はバッファ位置への参照を含む。ここで、いくつかの実現形態では、データアイテム２１６の以前のバージョンのバックアップコピーは、異なる位置に保持され、この結果、メタデータ２１７は、バックアップ位置へのアドレス又は他の参照を含む。あるいは、メタデータ２１７自体は、データアイテム２１６のバックアップ又はバッファ位置として機能する。他の例として、メタデータ２１７は、データアイテム２１６への繰り返しのトランザクションのアクセスを高速化するためのフィルタ値を含む。しばしば、ソフトウェアを利用するトランザクションの実行中、コンシスタンシ及びデータ有効性を確実にするため、アクセスバリアがトランザクションのメモリアクセスにおいて実行される。例えば、トランザクションのロード処理前に、データアイテム２１６がロック解除されているか確認し、トランザクションの現在のリードセットが依然として有効であるか判断し、フィルタ値を更新し、以降の検証を可能にするためトランザクションに対して設定されるリードにおけるバージョン値の記録など、リードバリア処理を実行するため、リードバリアが実行される。しかしながら、当該位置のリードがトランザクションの実行中にすでに実行されていた場合、同一のリードバリア処理は、不要となる可能性がある。
【００３０】
この結果、１つの手段は、リードフィルタを用いて、データアイテム２１６又はそのアドレスがトランザクションの実行中にリードされなかったことを示すための第１デフォルト値と、データアイテム２１６又はそのアドレスがトランザクションの保留中にアクセスされたことを示すための第２アクセス値とを保持することを含む。本質的には、第２アクセス値は、リードバリアが迅速化されるべきであることを示す。本例では、トランザクションのロード処理が受信され、メタデータ位置２１７のリードフィルタ値が、データアイテム２１６がすでにリードされたことを示す場合、一実施例では、不要で冗長なリードバリア処理を実行しないことによって、リードバリアが、トランザクションの実行を迅速化するため省略される、すなわち、実行されない。ライトフィルタ値はライト処理に関して同じように実行されてもよいことに留意されたい。しかしながら、一実施例では、アドレスがすでにアクセスされたか、ライト又はリードされたかに関係なく示すのに単一のフィルタ値が利用されるため、各フィルタ値は純粋に例示的なものである。ここで、ロードとストアとの双方について２１６のメタデータ２１７を確認するためのメタデータアクセス処理は、メタデータ２１７が別々のリードフィルタ値とライトフィルタ値とを含む上記の例と対照的に、単一のフィルタ値を利用する。特定の例示的な実施例では、メタデータ２１７の４ビットが、リードバリアが関連するデータアイテムに関して迅速化されるべきか示すためにリードフィルタに割り当てられ、ライトバリアが関連するデータアイテムに関して迅速化されるべきか示すためにライトフィルタに割り当てられ、アンドゥ処理が迅速化されるべきか示すためにアンドゥフィルタに割り当てられ、フィルタ値としてソフトウェアにより何れかの方法により利用されるべきミスクレイニアスフィルタに割り当てられる。
【００３１】
メタデータの他のいくつかの例は、データアイテム２１６に関連するトランザクションに汎用的又は固有であるハンドラのアドレスへの指示、表現又は参照、データアイテム２１６に関連するトランザクションの取消不能／執拗な性質、データアイテム２１６の消失、データアイテム２１６の情報のモニタリングの消失、データアイテム２１６について検出されるコンフリクト、データアイテム２１６に関連するリードセット内のリードエントリ又はリードセットのアドレス、データアイテム２１６の以前に記録されたバージョン、データアイテム２１６の現在のバージョン、データアイテム２１６へのアクセスを許可するためのロック、データアイテム２１６のバージョン値、データアイテム２１６に関連するトランザクションのトランザクション記述子、及び他の既知のトランザクションに関連する記述情報を含む。さらに、上述されるように、メタデータの使用はトランザクション情報に限定されるものでない。結果として、メタデータ２１７はまた、トランザクションに関連しない、データアイテム２１６に関連する情報、性質、属性又は状態を含むものであってもよい。
【００３２】
上述されるように、実施例は、ハードウェアバッファへのライトを実行するための明示的なライトバッファ命令を利用してもよい。一実現形態では、ライトバリアが、当該明示的なバッファストア命令を用いてハードウェアに更新をバッファリングするのに利用されてもよい。図３Ａを参照して、本発明の一実施例によるイーガライトロッキング及びモニタリングを実行する方法のフロー図が示される。より詳細には、図３Ａは、イーガライトロッキング及びモニタリングが実行されるトランザクションを実行する方法を示す。これらのイーガ処理はキャッシュに常駐するＴＭトランザクションに関するものであるが、本発明の範囲はこれに限定されるものでない。理解されるように、方法３００は、トランザクションにおける書き込み対象のデータがハードウェアバッファに適合するようサイズ調整されているか判断することによって開始される（３１０）。一例として、この判定は、トランザクションにおける書き込み対象のメモリブロックのサイズと、キャッシュメモリにおける利用可能な対応する記憶量とに基づき実行されてもよい。他の実現形態では、所与のＴＭスレッドが実行されているコアのプライベートキャッシュに当該解析を限定してもよいが、一実施例では、キャッシュは、共有キャッシュを含むプロセッサのキャッシュ階層の何れかのレベルであってもよい。もちろん、他の実施例は、別のハードウェア構成におけるハードウェアライトバッファリングを提供可能である。ライトデータがハードウェアバッファに適合するようサイズ調整されていない場合、制御はブロック３１５に移行し、アンバウンドなライトトランザクションが実行可能である。このＵＴＭトランザクションがモニタリングとバッファリングとを含むハードウェア性質からの支援を得てもよいが、図３Ａに関してここに開示される実現形態は、キャッシュ常駐トランザクションに関するものである。他の実施例は、ライトバッファリングを実現するのに利用されるハードウェアバッファ内に適合するライトセットを有するトランザクションに適用されてもよい。
【００３３】
データがハードウェアバッファに適合するようサイズ調整される場合、制御はブロック３１０からブロック３２０に移行し、書き込み対象の位置を含むブロックがキャッシュにすでにバッファリングされたか判断される。この判定は、ライトバリアを実行する犠牲を回避するため、フィルタリング機能を実行してもよい。異なる実現形態では、フィルタリングを実行する各種方法が実現されてもよい。多数の実施例では、１以上のハードウェア性質がフィルタリングを実行するため利用されてもよい。ここに開示される実現形態では、バッファされた性質が利用されてもよい。一実施例では、ユーザレベルテスト命令が、対応するライトデータのアドレスがキャッシュにバッファリングされるか判断するのに利用されてもよい。この判定は、データのアドレスを含むブロックに関連するバッファリングされたインジケータに基づき実行されてもよい。従って、ブロック３２０の判定は、ブロックがすでにキャッシュにある場合、ライトバリアを禁止又はフィルタリングする。他の実施例では、ライトモニタリングを用いてイーガライトモニタリングの実現形態においてフィルタリングを実行することが可能である。
【００３４】
そうでなく、書き込み対象のブロックがまだバッファリングされていない場合、制御はブロック３３０に移行し、ライトバリア処理が実行される。より詳細には、このライトバリア処理は、ライトロックとライトモニタとがブロックのオーナシップを取得するため獲得されるイーガライトバリアであってもよい。ライトロックとライトモニタとの異なる実現形態が実現されてもよい。しかしながら、一般化のため、ライトロックが、メモリにあって書き込み対象の特定位置に関連するライトロックなどのソフトウェアライトロックであってもよいことが理解される。他方、ライトモニタは、一実施例では、キャッシュラインサイズであってもよいモニタリングされたブロックサイズの粒度によるものであってもよいハードウェアモニタであってもよい。ライトモニタリング性質の一例として、キャッシュラインの状態情報は、所与のスレッドがキャッシュライン上でライトモニタを取得したことを示すよう設定可能なライトモニタインジケータ（モニタビットなど）を含むものであってもよい。いくつかの実施例では、複数のこのようなモニタが、それぞれが異なるスレッドに対応し、所与のキャッシュラインと関連付けされてもよい。従って、この時点において、ライトバリアが終了し、制御はブロック３４０に移行する。ブロック３４０において、バッファリングされたブロックが、書き込み対象のデータにより更新されてもよい。この更新は、ライトモニタ及びロックがブロック上で取得されると、バッファのブロックに対して直接的に行われるようにしてもよい。図３Ａには示されないが、この時点において、トランザクション中のさらなる処理が実行されてもよい。
【００３５】
図３Ｂを参照し、イーガライトモニタリング及びロッキングトランザクションにおけるトランザクションコミットを実行する方法のフロー図が示される。図３Ｂに示されるように、コミットにおいて、制御はブロック３６０に移行し、バッファリング又はモニタリングされる何れかのデータがバッファからイビクトされたか判断される。この判定はトランザクション単位であってもよく、更新されたブロックに限定されるものでないことに留意されたい。ラインがイビクトされたかの判定は、異なる形態をとりうる。しかしながら、ハードウェアにより支援されるシステムでは、トランザクションステータスレジスタなどにある情報が、モニタリング又はバッファリングの消失が、例えば、ＴＳＲの１以上の消失イベントインジケータの解析などによって実行されたか判断するため確認されてもよい。このような消失が発生した場合、トランザクションは中断されてもよい（ブロック３７０）。その後、制御は、トランザクションが再実行されるべきか判断するため、ＴＭランタイムシステム（ランタイムシステムのイジェクションハンドラなど）などに移行し、そうである場合、再実行が実行されるべきトランザクション実行モードに移行する。
【００３６】
他方、バッファリング又はモニタリングされるデータがイビクトされたと判断される場合、制御はブロック３６０からブロック３８０に移行し、バッファリングされたライトデータが可視的になるよう有効とされる（ブロック３８０）。すなわち、トランザクションがコミットし、バッファリングされたデータがグローバルに観察されるよう指示される。例えば、バッファリングされたデータのキャッシュコヒーレンシ状態に関する情報は、スレッドがトランザクションを実行することにる隠蔽された又はプライベートな使用から、他のエージェントによりアクセス可能な共有状態への移行を示すよう更新されてもよい。図３Ｂの実施例の当該実現形態により示されるが、本発明の範囲はこれに限定されるものでないことが理解される。
【００３７】
以下のテーブル１は、明示的なバッファリングストア命令（ｍｏｖｘｂ）を用いてハードウェアに更新をバッファリングする実施例によるライトバリア（ｔｍＷｒＵＴＭ）の擬似コードを示す。このバッファリングストア命令は、それがキャッシュメモリにデータを明示的に格納し、メモリへのデータの以降の書き込みを提供しない点で従来のストア命令と異なる。その代わりに、トランザクションのコミット処理中に実行される命令は、このような書き込みを有効にする。ライトバリアは、バッファリング性質を利用して、書き込まれた位置を含むバッファリングブロック（ＢＢＬＫ）がすでにバッファリングされているかまずチェックすることによって、冗長なライトバリア処理をフィルタリングする。ブロックがバッファリングされていない場合、バリアは、他のＳＴＭトランザクションとのコンフリクトを回避するため、当該位置でＳＴＭライトロックを取得し、ブロックのオーナシップを取得するためライトモニタを設定する（トランザクションがバッファリングされた更新を以降にコミットすることを可能にする）。バリアは、最初に（すなわち、エンカウンタタイムに）ＢＢＬＫを書き込みしようとするとすぐに、ＳＴＭライトロックトライトモニタとを取得する。このエンカウンタタイムスキームは、イーガロッキング及びイーガライトモニタリングと呼ばれてもよい。
【００３８】
バッファリング又はライトモニタされるキャッシュラインの消失は、トランザクションにそれの更新を消失させ、トランザクションを中断させることに留意されたい。一実施例では、トランザクションのコミットメントは、ライトモニタリングされるラインが失われた場合、バッファリングされた更新を可視的にするようユーザレベルのトランザクションコミットメント命令（ＴＸＣＯＭＷＭ）に応答する。
【００３９】
バッファリングキャッシュラインの消失は、リードを不整合なデータにアクセスさせる。リードバリア（ｔｍＲｄＵＴＭ）（テーブル１にも示される）は、それが以前にバッファリングされ、その後に消失したバッファリングされたブロックからリードしないことを確実にする。すなわち、リードバリアは、バッファリングされたブロックがリード前に消失したリード・アフター・バッファード・ライト（ｒｅａｄ−ａｆｔｅｒ−ｂｕｆｆｅｒｅｄ−ｗｒｉｔｅ）を追跡するよう動作する。このデータ不整合性は、バッファリングされたブロックが消失したときであって、リードが消失したＢＢＬＫにアクセスする前、イジェクションハンドラ（イジェクタとも呼ばれる）などのイベントハンドラにジャンプすることによって、回避できる。しかしながら、イジェクタがない場合、リードバリアは、（ライトバリアは、イーガリーにロックを取得し、トランザクションがすでにライトロックを保持するＢＢＬＫのみが、以前にバッファリングされていた可能性があるため）トランザクションがすでにライトロックを保持するバッファリングされていない位置からの各リードに対して、明示的にすテータスレジスタの確認を実行する（例えば、ＴＳＲのＴＳＲ．ＬＯＳＳ＿ＢＦビットなど）。一実施例では、トランザクションが開始されるとコンパイラ又はランタイムシステムにより設定されてもよいＣＡＣＨＥ＿ＲＥＳＩＤＥＮＴ＿ＷＲＩＴＥＳフラグは、当該確認が実行されているか制御する。他の実現形態では、バッファリングの消失を迅速に確認する命令（ＪＬＯＳＳなど）がまた、この確認に利用可能である。テーブル１の変数ＣＡＣＨＥ＿ＲＥＳＩＤＥＮＴ＿ＷＲＩＴＥＳ，ＣＡＣＨＥ＿ＲＥＳＩＤＥＮＴ＿ＲＥＡＤＳ，ＵＴＭ＿ＵＮＤＯ＿ＦＩＬＴＥＲＩＮＧ，ＥＪＥＣＴＯＲ＿ＥＮＡＢＬＥＤは、トランザクションの特定のポリシーを制御するフラグとして機能する。ＣＡＣＨＥ＿ＲＥＳＩＤＥＮＴ＿ＷＲＩＴＥＳが真である場合、トランザクションのライトセットは、バッファリングライトが利用されているため、キャッシュに適合する必要がある。ＣＡＣＨＥ＿ＲＥＳＩＤＥＮＴ＿ＲＥＡＤＳが真である場合、トランザクションのリードセットがまた、キャッシュに適合しなければならない。ＵＴＭ＿ＵＮＤＯ＿ＦＩＬＴＥＲＩＮＧが真である場合、バッファリングライトは有効とされず（ライトはアンバウンディッドである）、当該フラグは、ハードウェアメタデータを用いてアンドゥログがフィルタリングされているか制御する。最後に、ＥＬＥＣＴＯＲ＿ＥＮＡＢＬＥＤは、イジェクタが利用されるか制御する。これが偽である場合、ＪＬＯＳＳ命令（又はテーブル１のｃｈｅｃｋＴｓｒＬｏｓｓ（ＬＯＳＳ＿ＢＵＦ））が利用可能である。以下のテーブル１は、リードバリアの実行に加えて、本発明の実施例によるハードウェアライトバッファリング、イーガロッキング及びモニタリングによるライトバリアの実施例の擬似コードを示す。
【００４０】
【表１】
0005507706.tif 000002
【００４１】
上述したリード及びライトバリアがトランザクションの実行中に実行されてもよいことに留意されたい。一般に、トランザクションは、トランザクションに関連する各種コンテクストを初期化し、トランザクション内の各種処理を実行し、その後にコミットポイントに到達し、トランザクションの実行中に失敗が発生しない場合にトランザクションをコミットすることによって、実行される。コミットポイントでは、トランザクションは良好にコミットし、システムの残りにそれの更新をグローバルに可視的にすることが可能であるか、又はトランザクションがコンフリクト、ハードウェア特性の消失などの各種理由の１つのため中断する必要があるか判断されてもよい。
【００４２】
一般に、この初期化は、トランザクションの各種コンテクストの初期状態を設定することを含む。このコンテクストは、各種イベントの発生によるイジェクタなどのイベントハンドラへのジャンプを可能にするよう各種インジケータが設定されるＴＣＲの初期状態を設定することを含む。さらに、ＴＳＲは、各種インジケータがこのような何れかのイベントがないことを示すためリセット状態に設定されてもよいなど、初期状態に設定されてもよい。その後、トランザクションがスタートし、当該トランザクションに関連する処理のタイムスタンプが、グローバルタイムスタンプの値に設定されてもよい。トランザクションの実行中にイジェクションが実行されない場合、トランザクションはコミットポイントに到達する。キャッシュ常駐トランザクションの場合、トランザクションはコミットし、ユーザレベルトランザクションコミット命令が成功した場合、キャッシュバッファからの更新されたデータをメモリに書き込む。そうでない場合、トランザクションは中断する。トランザクションの中断は、イジェクションハンドラを実行させ、イジェクションハンドラの複数のコードパスの１つが、トランザクションの失敗の理由に基づき実行される。イジェクションハンドラは、新たなトランザクションモードを選択し、当初の実行モードと同一又は異なる選択されたトランザクション実行モードのユーザコードに制御をわたす。他方、トランザクションがキャッシュ常駐トランザクションでない場合、リードセットは有効とされ、トランザクションは、有効化が失敗した場合にはロールバック及び中断され、取得されたロックがリリースされる。このロールバックの一部として、各種のバッファリングライン及びモニタリングがクリアされる。他方、有効化が成功した場合、トランザクションはコミットし、グローバルタイムスタンプがインクリメントされる。実施例はキャッシュ常駐トランザクションに限定されず、リードセットがバウンドされず（例えば、キャッシュサイズにより限定されないリードセットなど）、ライトセットがバウンドされる（例えば、テーブル１においてＣＡＣＨＥ＿ＲＥＳＩＤＥＮＴ＿ＷＲＩＴＥＳが真であり、ＣＡＣＨＥ＿ＲＥＳＩＤＥＮＴ＿ＲＥＡＤＳが偽であるケースに対応する）トランザクションが実行可能であることに留意されたい。
【００４３】
以下のテーブル２は、本発明の実施例によるトランザクションスタート及びコミットにおいて実行される処理の一例となるコードを示す。
【００４４】
【表２】
0005507706.tif 000003
【００４５】
他の実施例では、ライトモニタを設定し、ＳＴＭライトロックを取得することは、コミットタイムまで遅延されてもよい。このコミットタイムスキームは、レイジロッキング及びレイジライトモニタリングと呼ばれてもよい。上述されたイーガロッキング及びモニタリングスキームと同様に、このスキームはまず、バッファリング特性を利用して冗長なライトバリア処理をフィルタリングする。イーガスキームと異なる、ライトモニタを設定し、ライトロックを取得する代わりに、ある値が更新されるべきであるとき、ライトモニタが設定され、コミットされるとライトロックが取得可能となるように、書き込み対象の位置のアドレスがライトログに付属されてもよい。更新された値は、バッファリングライト（ｍｏｖｘｂなど）命令を用いて書き込み対象の位置のアドレスに格納可能であることに留意されたい。一実施例では、コンパイラ又はランタイムシステムなどにより設定されるＬＡＺＹ＿ＬＯＣＫＩＮＧフラグは、このモードを有効にする。
【００４６】
コミットされると、トランザクションは、それのライトログの位置を繰り返し、ライトモニタを設定し、各位置についてライトロックを取得する。各位置にライトモニタを設定した後、トランザクションは、バッファリングラインの消失を確認し（例えば、ステータスレジスタのＴＳＲ．ＬＯＳＳ＿ＢＦビットなどを介し）、バッファリングラインが消失した場合に中断する。そうでない場合、トランザクションは、ＴＸＣＯＭＷＭ命令を用いて、ライトモニタされるラインが消失していない場合、バッファリングされた更新を可視的にするなどにより、コミットしてもよい。
【００４７】
リード・アフター・バッファード・ライトから消失したＢＢＬＫへのリードセット不整合を回避するため、トランザクションは、いわゆるＬＯＳＳ＿ＢＦイベントなどのバッファリングラインの消失によりイジェクトするイジェクタを利用可能であるか、又はバッファリングラインの消失の確認（ステータスレジスタのＴＳＲ／ＬＯＳＳ＿ＢＦビットなどを介し）が、バッファリングされていないＢＢＬＫからの各リードに対して明示的に実行されてもよい（トランザクションが以前にライトロックしたバッファリングされていないＢＢＬＫからの読み込み時のみ、当該ビットを明示的に確認するイーガロッキングスキームと対照的に）。
【００４８】
本発明の実施例によるレイジロッキングを実現することによって、他の同時のトランザクションが、ライトトランザクションコミット前にコミットする限り、コンフリクトなしに同一のトランザクションロックにマッピングするメモリ位置をリード可能である。このように、他のトランザクションがトランザクションを中断することなく更新されたデータを同時にリードすることを可能にすることによって、同時性が向上する。このスキームはまた、同一のトランザクションロックにマッピングする異なる位置を更新する２つのトランザクションのため、誤ったコンフリクトを低減する。
【００４９】
図４Ａを参照して、本発明の実施例によるレイジライトロッキング及びモニタリングを実行する方法のフロー図が示される。図３Ａの方法３００に関する上記説明と同様に、図４Ａの方法４００は、実施例がこれに限定されず、何れかのハードウェアバッファに適用可能であるが、キャッシュ常駐トランザクションを参照して説明される。一般に、図４Ａのフロー図は、図３Ａに関して上述されたものと同様に進捗するが、ライトバリアはコミットまでレイジ実現形態で実行されないことに留意されたい。図４Ａに具体的に示されるように、方法４００は、所与のハードウェアバッファに適合するようライトデータがサイズ調整されるか判断することによって開始されてもよい（ブロック４１０）。このライトはバッファのオーバフローを生じさせる場合、制御は、アンバウンディッドなライトトランザクションを実行するためブロック４１５に移行する。
【００５０】
ライトがキャッシュに適合するようサイズ調整される場合、制御はブロック４２０に移行し、書き込み対象のブロックが以前にバッファリングされたかに基づき、フィルタリング処理が実行されてもよい。実際に、ブロックがバッファリングされている場合、制御はブロック４３５に移行し、データはバッファの位置に直接書き込まれてもよい。従って、レイジの実現形態では、エンカウンタタイムにロック又はモニタリングを取得する必要はない。その代わりに、データは単に更新される。ライトモニタがライン上で設定されると、ハードウェアは、ラインの排他的なオーナシップを取得し、他のコアの他のコピーを無効にする。その後、ライトモニタの設定は、当該レイジケースについてコミットされると発生する。
【００５１】
他方、データがバッファにない場合、制御はブロック４２０からブロック４３０に移行し、書き込み対象のデータのアドレスがライトログに書き込まれる。その後、データ自体は、ｍｏｖｘｂ命令などを利用して（ブロック４３５）、バッファメモリにおいて更新されてもよい。このような実施例では、更新は当初のライトアドレスへのバッファリングされたストア／ライトを実行し、ライトモニタが当該アドレス上に設定された場合、コミットされるとグローバルに可視化される当該アドレスのプライベートバッファリングコピーをハードウェアに生成させる。
【００５２】
図４Ｂを参照して、本発明の一実施例によるレイジライトモニタリング及びロッキングトランザクションのためのコミット方法のフロー図が示される。図４Ｂに示されるように、方法４４０は、ライトロック及びモニタが取得されるブロック４５０に進捗する。このような処理は、ライトバリア処理のための図３Ａを参照して説明されるように進捗する。ライトロック及びモニタが取得されると、制御は、何れかのバッファリング又はモニタリングされたデータが消失したか判断するためブロック４６０に移行する。制御は、ブロック４７０又は４８０の１つに移行し、それぞれトランザクションを中断するか（消失が発生した場合）、又はトランザクションをコミットし、更新されたデータのグローバルな観察を有効にする。図４Ｂの実施例の当該実現形態により示されるが、本発明の範囲はこれに限定されるものでない。
【００５３】
以下のテーブル３は、本発明の実施例によるハードウェアライトバッファリング、レイジロッキング及びレイジモニタリングによるライトバリアの実施例の擬似コードを示す。一般に、テーブル３は、レイジロッキングを当該テーブルに追加することによって、テーブル１のコードを高度化する。ＬＡＺＹ＿ＬＯＣＫＩＮＧフラグは、トランザクションがレイジロッキング及びライトモニタリングを利用しているか制御する（テーブル１のイーガ処理に対して）。
【００５４】
【表３】
0005507706.tif 000004
【００５５】
以下のテーブル４は、本発明の実施例によるハードウェアライトバッファリング、レイジロッキング及びレイジモニタリングによるリードバリアの実施例の擬似コードを示す。
【００５６】
【表４】
0005507706.tif 000005
【００５７】
上述したライト及びリードバッファリングは、トランザクションの実行中に実行されてもよいことに留意されたい。以下のテーブル５は、レイジロッキング及びレイジモニタリングを実現する本発明の実施例によるトランザクションコミットにおいて実行される処理のための一例となるコードを示す。
【００５８】
【表５】
0005507706.tif 000006
【００５９】
レイジロッキング及びライトモニタリングスキームは、コンフリクト中のライト・ライトコンフリクトを検出することに留意されたい。すなわち、２つのトランザクションは、それらの１つがコミットステージに到達するまで、同一のブロックに書き込むことによってそれらがコンフリクトしたことを検出しない。従って、レイジコンフリクト検出は、ライト・ライトコンフリクトがあると無駄な作業を導く可能性がある。他の実施例では、このダウンサイドは、ライトモニタリングをイーガリーに設定しながら、ロックをレイジに取得することによって軽減可能である（同一のトランザクションのロックにマッピングされるデータを有するライタ又はリーダの前に同一のデータをリードするリーダを中断しない）。この技術は、イーガライトモニタリングによるレイジロッキングと呼ぶことができる。この技術では、ライトバリアは、コミットされるとライトロックをレイジに取得するが、エンカウンタタイムにはイーガリーに書き込まれたデータに対してライトモニタを設定する。一般に、図３Ａ〜４Ｂに関して上述された方法は、このジウｔげんけいたいを実現するため組み合わせ可能である。すなわち、ライトモニタは、イーガモニタリングを実現するためライトログに更新が書き込まれるのと同時に設定可能である。しかしながら、図４Ｂと同様に、レイジロッキングはコミット時に行われる。
【００６０】
以下のテーブル６は、本発明の実施例によるハードウェアライトバッファリング、レイジロッキング及びイーガモニタリングによるライトバリアの実施例の擬似コードを示す。
【００６１】
【表６】
0005507706.tif 000007
【００６２】
以下のテーブル７は、レイジロッキング及びイーガモニタリングを実現する本発明の実施例によるトランザクションスタート及びコミットにおいて実行される処理の一例となるコードを示す。
【００６３】
【表７】
0005507706.tif 000008
【００６４】
特定の実施例では、ライトモニタリング状態が維持され、トランザクションを通じて再利用されてもよい。このような実施例では、ライトモニタは、次のトランザクションがまたハードウェアバッファリングを利用する場合にキャッシュラインに維持可能である。この最適化は、ファイル他としてバッファリングされた特性の代わりに、ライトモニタを用いて修正されたイーガライトモニタリング及びライトバリアを用いて実現されてもよい。すなわち、所与の位置についてライトモニタが存在する場合、他のライトバリアを実行する必要はない。すなわち、ロッキングは継続したライトモニタについて必要とされ、この継続性は、ライトモニタが依然として設定されるラインと他の何れのトランザクションがコンフリクト（リード又はライト）しないことを保障する。図３Ａのフローチャートを参照して、ブロックがすでにバッファリングされたか判断する代わりに（ブロック３２０において）、ブロックがライトモニタリングされるか判断されてもよい。
【００６５】
上述されるように、実施例は、ライトバリア処理を迅速化するため管理された環境において見出されるものなどのオブジェクトベースＴＭシステムに関して利用されてもよい。テーブル８において、カラム“Ｓｏｕｒｃｅ”はソースを示し、第２カラムは従来のＳＴＭにより実行される処理を示し、第３カラムはＵＴＭシステムにおいてオブジェクトベーストランザクション上で実現されるようなハードウェア特性の利用を示す。テーブル８は、イーガデータモニタリングとレイジ及びイーガロッキングとの迅速化されたライトバリアを示す。
【００６６】
【表８】
0005507706.tif 000009
【００６７】
テーブル８において、ｔｘｎＯｐｅｎＦｏｒＷｒｉｔｅファンクションは、書き込まれるオブジェクトに対するライトロックを取得する。理解されるように、このファンクションの異なる変形が存在しうる。具体的には、２つの変形が示され、１つはロックを取得せず、単にオブジェクトを記録するものであり（ＮｏＬｏｃｋ）、他方はオブジェクトをロックも記録もせず、バッファリングされたストアを用いてオブジェクトのトランザクションバージョン番号をインクリメントする。
【００６８】
さらなる他の実現形態では、ライトバリアをバッファリングするハードウェアライトは、ライトロックをレイジに取得し（コミット時に）、アクセスされたデータについてライトモニタリングをレイジに設定する。これは、データの他のリーダがトランザクションを中断することなく進捗することを可能にする（すなわち、ライトモニタリングの消失を生じさせることなく）。書き込まれたＢＢＬＫのログは、コミット時にライトモニタを設定することを可能にするため設けられてもよい。ファンクションｔｘｎＬｏｇＢｂｌｋ（テーブル９の擬似コードに示される）は、一実施例では、このログ処理を実行してもよい。コミットされると、トランザクションは、この記録を繰り返し、バッファリングされたすべてのラインに対してライトモニタリングを設定する。バリアは、他のトランザクションによるコンフリクトしたライトを抽出するため、書き込まれたＭＢＬＫに対してリードモニタを設定する。トランザクションが何れかのリードモニタリング又はライトモニタリングされたＭＢＬＫを消失した場合、コミットは失敗する。そうでない場合、コミットメントは進捗し、ユーザレベルコミット命令（ＴＸＣＯＭＷＭＲＭなど）は、それのバッファリングされたデータをコミットするのに利用されてもよい。このバリアは、複数のプロセッサが同時にバッファリングされた状態で同一のラインを有し（リードモニタリング及びバッファリングされたＲ−Ｂ状態を用いて）、コミットされると、ライト・ライトコンフリクトをレイジに検出することを可能にする。
【００６９】
【表９】
0005507706.tif 000010
【００７０】
上述されるように、レイジバージョン管理を利用するＳＴＭシステムは、トランザクション内で実行されたすべての更新をバッファリングする。レイジバージョニングＳＴＭシステムは、各更新をメモリ位置にリダイレクトするか、又はオブジェクトＬをメモリにあるが、ハードウェアバッファにはないＬのシャドーコピーにリダイレクトする。このようなＳＴＭは、各メモリリード又はライトに対してＬのシャドーコピーにアクセスすることを必要とし、特にオプティミスティックなライトを実行するＳＴＭシステムにおいて大きなオーバヘッドを追加する。
【００７１】
実施例は、ハードウェアメタデータ手段を用いてメモリ位置又はオブジェクトのシャドーコピーを検出するための低コストな方法を実現してもよい。上述されるように、ハードウェアメタデータはメタデータとアドレスとを関連付けるための迅速であるが不可逆的な方法を提供しうる。ここで用いられるメタデータは、オブジェクト又はアドレスのシャドーコピーへのポインタを格納可能であり、シャドーコピーにアクセスするオーバヘッドを軽減する。
【００７２】
図５を参照して、メタデータを用いてオブジェクトのシャドーコピーの位置を効率的に決定する方法のフロー図が示される。すなわち、実施例は、メタデータ特性を用いてシャドーコピーへの効率的なマッピングを実行する。図５に示されるように、方法５００は、オブジェクトに対するアクセスリクエスト（リード又はライトリクエストなど）を第１スレッドから受信することによって開始される（ブロック５１０）。一例として、このスレッドは何れかのタイプのＴＭスキームによりトランザクションを実行してもよい。制御はブロック５２０に移行し、オブジェクトのオブジェクトヘッダの所定部分に対応するメタデータがオブジェクトのシャドーコピーのアドレスを含むか判断される（ブロック５２０）。一例として、この所定部分は、オブジェクトヘッダの第１スロットに関連付けされるメタデータ部分であってもよい。そうでない場合、これは、オブジェクトのシャドーコピーがないことを示す。従って、制御はブロック５３０に移行し、リードバリア処理が、メモリからオブジェクトを取得するため実行される。その後、オブジェクトのシャドーコピーが格納されてもよい（ライトトランザクションの場合）（ブロック５４０）。本発明の範囲はこれに限定されるものでないが、キャッシュに常駐するトランザクションについて、シャドーコピーが、プロセッサのキャッシュメモリのバッファに格納されてもよい。このアクセスリクエストを格納することに関連して、制御はまたブロック５５０に移行し、オブジェクトヘッダの当該部分に関連するメタデータが更新される。具体的には、このメタデータは、シャドーコピーアドレスを格納する。このようにして、オブジェクトの位置への以降のアクセスは、本発明の実施例によるマッピング処理を用いることによって、シャドーコピーに効率的にアクセスする。
【００７３】
図５をさらに参照して、他方、ブロック５２０において、メタデータがアドレスを有していると判断された場合、アドレスはメタデータから取得され（ブロック５６０）、シャドーコピーにアクセスするため利用される（ブロック５７０）。アクセスがリード処理であり、オブジェクトが以前に書き込まれていない場合、リード処理は、シャドーオブジェクトでなく当初のオブジェクトから直接リードする。従って、アクセスリクエストに応答して、シャドーコピーの位置が、それが存在するときにはメタデータから取得可能である。例えば、ライトトランザクションについて、シャドーにおいてアクセスされたデータが、処理の実行中に利用されてもよい（ブロック５８０）。例えば、データは、所与のトランザクションの促進において各種計算又は他の処理を実行するのに利用されてもよい。ライトトランザクションの終了時、シャドーコピーは可視的になるよう有効とされてもよい。すなわち、コミット時、トランザクションが良好に終了し、バッファリングされた情報の何れの消失もなく、競合が発生しない場合（及び他の何れのセマンティックも違反とされていない）、トランザクションはコミットし、シャドーコピーに格納されているデータは、図３Ｂ及び４Ｂのコミット処理に関して上述されたような他のスレッドに可視的にされてもよい。
【００７４】
図５に示されるものと類似した処理が、ライトバリアの一部などとしてライトリクエストに対して実行されてもよいことに留意されたい。しかしながら、複数の相違が存在することに留意されたい。第１に、ライトバリアについて、オブジェクトヘッダの異なる所定部分（第２スロットなど）に関連するメタデータが、アドレスが存在するか決定するためアクセスされてもよい。第２に、アドレスがメタデータになく、オブジェクトがアクセスされ、シャドーコピーに格納される場合、オブジェクトヘッダの第１及び第２の所定部分の双方に関連するメタデータが、リード及びライトバリアの双方が以降にフィルタリング可能となるように、シャドーデータのアドレスにより更新される。図５の実施例の当該実現形態により示されたが、本発明の範囲はこれに限定されるものでない。
【００７５】
以下のテーブル１０の擬似コードは、リードセット整合性（管理されたコードシステムのためなど）を維持せず、メタデータを利用するオブジェクトベースのレイジバージョニングＳＴＭシステムのリード及びライトバリアを示す。図示されるように、“Ｓｏｕｒｃｅ”カラムはリード及びライト処理を示す。“Ｓｏｆｔｗａｒｅ  ＴＭ”カラムは、各ＳＴＭのリード及びライトバリア擬似コードを示す。“ｔｘｎＯｐｅｎＦｏｒＷｒｉｔｅ”ファンクションは、オブジェクトのシャドーコピーを生成及び返す。このファンクションはまた、ＳＴＭシステムがエンカウンタタイムのロッキングを実行した場合、オブジェクトに対して排他的なロックを取得し、そうでない場合、それは、コミットタイムまでロックの取得を遅延する。“ｔｘｎＯｐｅｎＦｏｒＲｅａｄ”ファンクションは、トランザクションが以前にオブジェクトに書き込まれた場合、オブジェクトのシャドーコピーを返す。そうでない場合、それは共有されたオブジェクトを返す。このファンクションはまた、オブジェクトをリードセットに記録し、リードのためのオプティミスティック又はペシミスティックな同時制御を利用する。擬似コードは、オプティミスティックシステムがフィールドの読み込み後にオブジェクトを再び有効にすることを要求するため、リードのためのオプティミスティックな同時制御を利用するＳＴＭシステムにおいてリードセット整合性を維持することができない。
【００７６】
テーブル１０の“Ａｃｃｅｌｅｒａｔｅｄ  ＴＭ”カラムは、メタデータを用いてＳＴＭ処理を迅速化する擬似コードを示す。リードバッファはまず、オブジェクトヘッダの所定部分（第１スロットなど）に関連するメタデータを確認し、その後に当該メタデータがヌル値を含む場合、ｔｘｎＯｐｅｎＦｏｒＲｅａｄ処理を実行する。その後、それは、当該ファンクションにより返されたアドレスを所定部分に関連するオブジェクトのメタデータに格納し、同一オブジェクトへの以降のリードバリアにｔｘｎＯｐｅｎＦｏｒＲｅａｄ処理をスキップさせる（冗長的なリードバリアの効果的なフィルタリング）。ライトバリアは、同様にして、まずオブジェクトヘッダの異なる所定部分（第２スロットなど）に関連するメタデータを確認し、その後に、当該メタデータがヌル値を含む場合、ｔｘｎＯｐｅｎＦｏｒＷｒｉｔｅ処理を実行する。その後、それは、当該ファンクションにより返されたアドレスをオブジェクトヘッダの両方の所定部分（最初の２つのスロットなど）に関連するメタデータに格納し、同一のオブジェクトへの以降のリード及びライトバリアに各自のバリア処理をスキップさせる。このアルゴリズムは最小のオブジェクトサイズが２つのポインタ値を格納可能であることを仮定していることに留意されたい。ライトバリアの他の実現形態は、高速パスの追加的な比較により１つのみのポインタ値を格納可能な最小のオブジェクトサイズをサポート可能である。従来のＳＴＭリード及びライトバリアと比較して、迅速化されたバリアは、メタデータが“ヒット”すると、メタデータロード及び（１又は２つの）条件分岐命令のオーバヘッドを受ける。
【００７７】
【表１０】
0005507706.tif 000011
【００７８】
テーブル１０のこの擬似コードは、非トランザクションスレッドがトランザクションによりアクセスされている同一のオブジェクトを更新することが可能とされる場合、ＧＬＵ（Ｇｒａｎｕｌａｒ  Ｌｏｓｔ  Ｕｐｄａｔｅｓ）及びＧＩＲ（Ｇｒａｎｕｌａｒ  Ｉｎｃｏｎｓｉｓｔｅｎｔ  Ｒｅａｄｓ）とを生じさせることが可能である。従って、ＳＴＭシステムは、典型的には、このような問題を回避するため、又は非トランザクションスレッドによるトランザクションオブジェクトへの更新を禁止するため（分離）、非トランザクションコードの強いアトミシティバリアを利用する。本発明の他の実施例は、メタデータを用いて、ＧＬＵ又はＧＩＲ問題を回避するための強いアトミシティ又は分離を必要としないレイジバージョニングＳＴＭのオブジェクトのシャドーコピールックアップを迅速化することができる。
【００７９】
テーブル１１は、リードセット整合性を維持するハードウェアメタデータを用いたアドレスベースのレイジバージョニングＳＴＭシステム（Ｃ／Ｃ＋＋ＳＴＭシステムなど）のリード及びライトバリアの擬似コードを示す。アルゴリズムは、ＧＬＵ及びＧＩＲ問題を回避し、ナイーブコードのアクセスがブロックにわたるため、以前のオブジェクトベースアルゴリズムより複雑である。ナイーブコードでは、オブジェクトの代わりにメモリブロックがあり、システムは、オブジェクトでなくブロックのシャドーコピーを生成する。その後、メモリリード又はライトは、２つの異なるブロックにわたるメモリ値にアクセスし、アクセスは２つの異なるシャドーコピーを検出することに関する。テーブル１１のコードは、このケースを検出し、基礎となるＳＴＭ  ｔｘｎＯｐｅｎＡｄｄｒＦｏｒＲｅａｄ及びｔｘｎＯｐｅｎＡｄｄｒＦｏｒＷｒｉｔｅファンクションを単に呼ぶ。
【００８０】
【表１１】
0005507706.tif 000012
【００８１】
従って、各種実施例では、異なる技術が、ＵＴＭシステムのハードウェア特性を利用することによって、より効率的なトランザクションを実現するのに利用可能である。これらの技術は、コミットタイム（レイジ）ロッキングによるコミットタイム（レイジ）ライトモニタリング、コミットタイム（レイジ）によるエンカウンタタイム（イーガ）ライトモニタリング、又はエンカウンタタイム（イーガ）ロッキングを含む。さらに、実施例は、バッファリング又はモニタリングされたラインの消失を追跡するトランザクションステータスレジスタの明示的な確認を利用することによって（又は明示的な命令を用いて）、及び／又はイジェクタを用いて、整合性を維持することを可能にするものであってもよい。さらに、キャッシュ常駐リードとアンバウンディッドリードとの双方によるキャッシュ常駐ライトが実行可能であり、オプティミスティック（タイムスタンプベース）とペシミスティック（リーダ・ライタロックベース）との双方のリードのための同時制御が実現可能である。
【００８２】
ライトログ処理による又はよらないライトロッキングのフィルタリングを可能にするため、ライトモニタがトランザクションにおいて維持されてもよい。キャッシュ常駐ライトが、アンバウンドトランザクションのインプレース更新及びライトバッファリングＳＴＭとの双方により実行されてもよい。さらに、バッファリングされた更新とフィルタ確認とがハードウェアにより非明示的に実行される非明示的モードハンドラベースシステムに関して、フィルタの欠落は、ライトバリアを実行するハンドラを呼び出す。実施例は、ライトセットがハードウェアバッファ（キャッシュなど）に適合するトランザクションのためのバージョン管理をハードウェにより実行することによって、従来のＳＴＭシステムのオーバヘッドを低減する。
【００８３】
実施例はまた、オブジェクト又はデータアイテムのシャドーコピーを検出するためのレイジバージョニングＳＴＭシステムにおけるソフトウェアオーバヘッドを低減する。このようなオーバヘッドは、オブジェクト又は位置のシャドーコピーの位置を検出するためのハードウェアメタデータなど、ハードウェアサポートを利用して低減されてもよい。
【００８４】
実施例は、多数の異なるシステムタイプにより実現されてもよい。図６を参照して、本発明の実施例によるシステムのブロック図が示される。図６に示されるように、マルチプロセッサシステム１０００は、ポイント・ツー・ポイントインターコネクトシステムであり、ポイント・ツー・ポイントインターコネクトシステム１０５０を介し接続される第１プロセッサ１０７０と第２プロセッサ１０８０とを有する。図６に示されるように、各プロセッサ１０７０，１０８０は、潜在的にはより多くのコアがプロセッサにあってもよいが、第１及び第２プロセッサコア（すなわち、プロセッサコア１０７４ａ，１０７４ｂと、プロセッサコア１０８４ａ，１０８４ｂ）を含むマルチコアプロセッサであってもよい。プロセッサコアは、効率的なアンバウンディッドトランザクションを可能にするため、ハードウェア、ソフトウェア又はこれらの組み合わせを用いてＴＭトランザクションを実行してもよい。
【００８５】
図６を参照して、第１プロセッサ１０７０はさらに、メモリコントローラハブ（ＭＣＨ）１０７２と、ポイント・ツー・ポイント（Ｐ−Ｐ）インタフェース１０７６，１０７８とを有する。同様に、第２プロセッサ１０８０は、ＭＣＨ１０８２と、Ｐ−Ｐインタフェース１０８６，１０８８とを有する。図６に示されるように、ＭＣＨ１０７２，１０８２は、プロセッサをメインメモリの一部であってもよい各自のメモリ、すなわち、メモリ１０３２，１０３４に接続する（各プロセッサにローカルに付属されるＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｕ）など）。第１プロセッサ１０７０と第２プロセッサ１０８０とはそれぞれ、Ｐ−Ｐインターコネクト１０５２，１０５４を介しチップセット１０９０に接続されてもよい。図６に示されるように、チップセット１０９０は、Ｐ−Ｐインタフェース１０９４，１０９８を有する。
【００８６】
さらに、チップセット１０９０は、Ｐ−Ｐインターコネクト１０３９によって、ハイパフォーマンスグラフィックエンジン１０３８とチップセット１０９０とを接続するためのインタフェース１０９２を有する。さらに、チップセット１０９０は、インタフェース１０９６を介し第１バス１０１６に接続されてもよい。図６に示されるように、各種入出力（Ｉ／Ｏ）装置１０１４は、第１バス１０１６と第２バス１０２０とを接続するバスブリッジ１０１８と共に、第１バス１０１６に接続される。例えば、キーボード／マウス１０２２、通信装置１０２６、コード１０３０を含むディスクドライブ又は他の大容量記憶装置などのデータ記憶ユニット１０２８などを含む各種装置が、一実施例において第２バス１０２０に接続されてもよい。さらに、オーディオＩ／Ｏ１０２４が第２バス１０２０に接続されてもよい。
【００８７】
実施例は、コードにより実現されてもよく、システムに命令を実行するようプログラムするのに利用可能な命令を格納する記憶媒体に格納されてもよい。記憶媒体は、限定されることなく、フロッピー（登録商標）ディスク、光ディスク、ソリッドステートドライブ（ＳＳＤ）、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、光磁気ディスクを含む何れかのタイプのディスク、ＲＯＭ、ＤＲＡＭ、ＳＲＡＭ、ＥＰＲＯＭ、フラッシュメモリ、ＥＥＰＲＯＭなどのＲＡＭなどの半導体装置、磁気若しくは光カード、電子命令を格納するのに適した他の何れかのタイプの媒体を含むものであってもよい。
【００８８】
本発明が限定数の実施例に関して説明されたが、当業者は、多数の変更及び変形を理解するであろう。添付した請求項はこのようなすべての変更及び変形を本発明の真の趣旨及び範囲内に属するものとしてカバーすることが意図される。
【図１】
0005507706.tif 000013
【図２】
0005507706.tif 000014
【図３Ａ】
0005507706.tif 000015
【図３Ｂ】
0005507706.tif 000016
【図４Ａ】
0005507706.tif 000017
【図４Ｂ】
0005507706.tif 000018
【図５】
0005507706.tif 000019
【図６】
0005507706.tif 000020