特許 5964382 無限トランザクション型メモリ（ＵＴＭ）システムにおけるモード切り替えの実行

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5964382

(24)【登録日】2016年7月8日

(45)【発行日】2016年8月3日

(54)【発明の名称】無限トランザクション型メモリ（ＵＴＭ）システムにおけるモード切り替えの実行

(51)【国際特許分類】

   G06F 9/46 20060101AFI20160721BHJP

   G06F 9/34 20060101ALI20160721BHJP

   G06F 12/08 20160101ALI20160721BHJP

【ＦＩ】

   G06F9/46 430

   G06F9/34 350A

   G06F12/08 519E

【請求項の数】28

【全頁数】34

(21)【出願番号】特願2014-211479(P2014-211479)

(22)【出願日】2014年10月16日

(62)【分割の表示】特願2012-544520(P2012-544520)の分割

【原出願日】2010年11月10日

(65)【公開番号】特開2015-53062(P2015-53062A)

(43)【公開日】2015年3月19日

【審査請求日】2014年10月16日

(31)【優先権主張番号】12/638,181

(32)【優先日】2009年12月15日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】593096712

【氏名又は名称】インテル コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】アドゥル−タバタバイ，アリ−レザ

(72)【発明者】

【氏名】サハ，ブラティン

(72)【発明者】

【氏名】バッシン，ヴァディム

(72)【発明者】

【氏名】シーファー，ガッド

(72)【発明者】

【氏名】グレイ，ジャン

(72)【発明者】

【氏名】グローヴァー，ヴィノド

(72)【発明者】

【氏名】タイレファー，マーティン

(72)【発明者】

【氏名】レヴァノニ，ヨッシ

(72)【発明者】

【氏名】デトレフス，デイヴ

(72)【発明者】

【氏名】マグルーダー，マイク

(72)【発明者】

【氏名】トルトン，マット

【審査官】 篠塚 隆

(56)【参考文献】

【文献】 米国特許出願公開第２００９／０１７２３０６（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ９／３０

９／３０５−９／３０８

９／３１５−９／３４

９／３５−９／４２

９／４４

９／４５−９／４６

９／４８

９／５０−９／５２

９／５４

１２／００−１２／１２

１３／１６−１３／１８

(57)【特許請求の範囲】

【請求項1】

第一のトランザクション実行モードにおいて実行される第一のトランザクションが失敗したことの通知を受信するステップであって、前記第一のトランザクション実行モードは、完全にハードウェアにおいてトランザクションの競合を検出するための複数のハードウェア・モードと、ソフトウェアロックが取得されるようにプロセッサ及びソフトウェアバッファのトランザクションのハードウェアを利用してトランザクションの競合を検出するための少なくとも１つのハードウェア支援モードと、前記トランザクションのハードウェアなしに完全にソフトウェアにおいてトランザクションの競合を検出するための少なくとも１つのソフトウェアトランザクショナルメモリ（ＳＴＭ）モードとを含む複数のトランザクション実行モードの１つである、ステップ、
前記第一のトランザクションの失敗の理由を判定するステップと、
前記失敗の理由の少なくとも一部に基づいて、前記第一のトランザクションが前記第一のトランザクション実行モードにおいて再度実行されるべきかに関する判定を含めて、前記第一のトランザクションの再実行のために新たなトランザクション実行モードを決定するステップと、
をシステムに実行させるためのプログラムであって、
前記失敗の理由が、メモリ階層構造内の動作レベルにおいてハードウェア的に制限される記憶容量をオーバーフローしたこと、又は前記第一のトランザクション実行モードによってサポートされていない機能に関してトランザクション・セマンティクス違反が発生したことの何れか一つである場合、前記第一のトランザクション実行モードは、より性能の低いトランザクション実行モードへとフォールバックされるか、さもなければ、前記第一のトランザクション実行モードは、最適な性能を達成するために、最も高い可能な性能のトランザクション実行モードへとアップグレードされるプログラム。

【請求項2】

前記失敗の理由の判定は、前記通知と共に受信されるトランザクションレコードへのアクセスを含み、前記トランザクションレコードは、前記第一のトランザクションの失敗の時点でのトランザクションステータスレジスタ（TSR）の値を含む、
請求項１記載のプログラム。

【請求項3】

前記第一のトランザクションを実行する前記新たなトランザクション実行モードを示すため、前記トランザクションレコードに持続性のある書き込みを行うステップを前記システムに更に実行させる、請求項２記載のプログラム。

【請求項4】

前記第一のトランザクションの失敗に応じて前記第一のトランザクションのコードのブロックのジャストインタイム（ＪＩＴ）コンパイルを実行し、前記ジャストインタイムコンパイル後に前記第一のトランザクション実行モードにおいて前記第一のトランザクションを再実行するステップを前記システムに更に実行させる、請求項１記載のプログラム。

【請求項5】

前記第一のトランザクションが失敗した回数のカウンタが閾値未満である場合に、前記第一のトランザクション実行モードにおいて前記第一のトランザクションを再実行するステップを前記システムに更に実行させる、請求項１記載のプログラム。

【請求項6】

STMモードで動作している保留のトランザクションの数における変化のため、前記第一のトランザクションが失敗した場合、第二のトランザクション実行モードにおいて前記第一のトランザクションを再実行するステップを前記システムに更に実行させる、
請求項１記載のプログラム。

【請求項7】

前記第一のトランザクション実行モードにおいて前記第一のトランザクションの実行を継続し、予め決定された期間について前記少なくとも１つの第二のトランザクション実行モードにおいて実行する少なくとも１つの他のトランザクションの開始を保留するステップを前記システムに更に実行させる、請求項６記載のプログラム。

【請求項8】

複数のトランザクション実行モードを有する無限トランザクショナル・メモリ（UTM）システムにおいて第１のトランザクションを開始するために第１のトランザクション実行モードを選択するステップであって、前記複数のトランザクション実行モードは、プロセッサのキャッシュ・メモリ内において実行するべき複数のハードウェア・モード、前記プロセッサ及びソフトウェアバッファのトランザクションのハードウェアを使用して実行される少なくとも１つのハードウェア支援モードおよび前記トランザクションのハードウェアなしで実行するべき少なくとも１つのソフトウェア・トランザクション実行モード（STM）モードを含む、ステップと、
前記第１のトランザクション実行モードにおいて前記第１のトランザクションの実行を開始するステップと、
前記第１のトランザクションが完了し、前記キャッシュ・メモリをオーバーフローさせないか、又はトランザクションのセマンティクス違反が無い場合には、前記第１のトランザクションをコミット処理し、そうでなければ前記第１のトランザクションを異常終了して、前記第１のトランザクションの処理を実行するために新しいトランザクション実行モードを選択するステップと、
をシステムに実行させるためのプログラム。

【請求項9】

実行された際に、他のトランザクションがペンディング状態であるか否かを判断し、そうでなければ、複数のハードウェア・モードの中で最も高い処理性能を有するモードを第１のトランザクション実行モードとして選択する動作をシステムが実施可能にする命令コードをさらに含む、請求項８記載のプログラム。

【請求項10】

前記最も高い処理性能を有するモードは、ロック動作やバージョン管理動作が全く発生しない暗黙的なモードである、請求項９記載のプログラム。

【請求項11】

ペンディング状態にある何れのトランザクションも少なくとも１つのＳＴＭモードで実行していないならば、複数のハードウェア・モードの中で最も高い処理性能を有するモードを第１のトランザクション実行モードとして選択するステップを前記システムに更に実行させる、請求項８記載のプログラム。

【請求項12】

ペンディング状態にあるトランザクションの中の少なくとも一つが少なくとも１つのＳＴＭモードで実行している場合には、複数のハードウェア・モードの中からより低い処理性能を有するモードを第１のトランザクション実行モードとして選択するステップを前記システムに更に実行させる、請求項１１記載のプログラム。

【請求項13】

前記より低い処理性能を有するモードは、ロック動作が発生する明示的なモードである、請求項１２記載のプログラム。

【請求項14】

最も高い処理性能を有するモードにおいて前記第１のトランザクションを実行している間に、第２のトランザクションが少なくとも１つのＳＴＭモードで開始された旨を判定し、複数のハードウェア・モードの中のより低い処理性能を有するモードにおいて再実行するために前記第１のトランザクションをロールバック処理するステップを前記システムに更に実行させる、請求項１３記載のプログラム。

【請求項15】

第１のトランザクションによってキャッシュ・メモリがオーバーフローする場合には、少なくとも１つのハードウェア支援モードの中の１つとなるよう新しいトランザクション実行モードを選択するステップを前記システムに更に実行させる、請求項８記載のプログラム。

【請求項16】

前記第１のトランザクションのハードウェア特性の損失が生じる場合には、前記第１のトランザクション実行モードにおける前記第１のトランザクションの実行を異常終了するステップを前記システムに更に実行させる、請求項８記載のプログラム。

【請求項17】

第１のトランザクション実行モードにおいて実行された第１のトランザクションが失敗した旨を示す通知を受信するステップであって、前記第１のトランザクション実行モードは、プロセッサのキャッシュ・メモリ内において実行される複数のハードウェア・モード、プロセッサ及びソフトウェアバッファのトランザクションのハードウェアを使用して実行される少なくとも１つのハードウェア支援モードおよび前記トランザクションのハードウェアなしで実行するべき少なくとも１つのソフトウェア・トランザクション（STM）モードを含む複数のトランザクション実行モードのうちの１つである、ステップと、
前記第１のトランザクションが失敗した理由を判定するステップと、
少なくとも部分的に前記失敗した理由に基づいて、第１のトランザクションの再実行のための新しいトランザクション実行モードを決定するステップであって、前記第１のトランザクションは、前記第１のトランザクション実行モードあるいは前記第１のトランザクション実行モードより高い性能レベルを有する第２のトランザクション実行モードにおいて再実行されるべきであるかの決定を含んでいる、ステップと、
を具備する方法。

【請求項18】

前記失敗した理由を判定するステップは、前記通知と共に受信されたトランザクション・レコードにアクセスするステップを含み、前記トランザクション・レコードは、前記第１のトランザクションが失敗した時点におけるトランザクション状態レジスタ（ＴＳＲ）の値を含んでいる、請求項１７記載の方法。

【請求項19】

前記第１のトランザクションが実行されるべき新たなトランザクション実行モードを示すために、トランザクション・レコードに対して永続的書き込み操作を実行するステップをさらに具備する請求項１８記載の方法。

【請求項20】

前記第１のトランザクションが失敗したことに応じて、前記第１のトランザクションのコードのブロックをジャストインタイム（ＪＩＴ）コンパイルする処理を実行し、前記ＪＩＴコンパイルの後に、前記第１のトランザクション実行モードにおいて前記第１のトランザクションを再実行するステップをさらに具備する、請求項１７記載の方法。

【請求項21】

前記第１のトランザクションが失敗した回数を示すカウンタの値が所定の閾値よりも小さい場合には、前記第１のトランザクション実行モードにおいて前記第１のトランザクションを再実行するステップをさらに具備する、請求項１７記載の方法。

【請求項22】

ＳＴＭモードで動作するペンディング状態にあるトランザクションの個数が変化したことに起因して前記第１のトランザクションが失敗した場合には、前記第２のトランザクション実行モードにおいて前記第１のトランザクションを再実行するステップをさらに具備する、請求項１７記載の方法。

【請求項23】

前記第１のトランザクション実行モードにおいて前記第１のトランザクションの実行を継続し、所定の時間期間にわたって、その他のトランザクション実行モードにおいて実行される少なくとも一つの他のトランザクションの開始を保留するステップをさらに具備する、請求項１７記載の方法。

【請求項24】

複数のコアおよびキャッシュ・メモリを含むプロセッサおよび前記プロセッサと結合されたダイナミック・ランダムアクセス・メモリ（ＤＲＡＭ）を具備するシステムであって、
前記プロセッサはさらにトランザクション状態レジスタ、トランザクション制御レジスタおよびイジェクション・ハンドラの位置を識別するためのイジェクション命令ポインタ・レジスタを含んでおり、前記プロセッサは、
ハードウェア・トランザクション実行モードを使用して、第１のトランザクションを実行するのと同時並行して、ソフトウェア・トランザクション実行モードを使用して、第２のトランザクションを実行し、
前記第２のトランザクション中で使用されるグローバル・バージョン・カウンタに対応する前記第２のトランザクションの読み出し値をインクリメントすることが、前記読み出し値を前記第１のトランザクションの中で使用されたハードウェア・グローバル・バージョン・カウンタを超過させるか否かを判定し、超過する場合には、前記ハードウェア・グローバル・バージョン・カウンタを適応的なバッチ・サイズによって更新する、
ように構成されている、システム。

【請求項25】

前記プロセッサは、前記第１のトランザクション内の前記ハードウェア・グローバル・バージョン・カウンタに対応するスタンプ値をモニタリングし、前記ハードウェア・グローバル・バージョン・カウンタが変化したならば、前記第１のトランザクションを異常終了し、
前記ハードウェア・グローバル・バージョン・カウンタの変化は、前記モニタリングにより検出される、請求項２４記載のシステム。

【請求項26】

前記プロセッサは、書き込みログを維持すること無しに前記第１のトランザクションを実行する、請求項２４記載のシステム。

【請求項27】

前記プロセッサは、前記ハードウェア・グローバル・バージョン・カウンタを前記適応的なバッチ・サイズによって更新したことに応じて、前記適応的なバッチ・サイズを調整する、請求項２４記載のシステム。

【請求項28】

請求項１乃至１６何れか一項記載のプログラムを記憶するためのコンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、無限トランザクション型メモリ（ＵＴＭ：Unbounded Transactional Memory）システムにおけるモード切り替えの実行に関する。

【背景技術】

【0002】

現代のコンピューティングシステムでは、複数のプロセッサが存在することができ、それぞれの係るプロセッサは、共通のアプリケーションの異なるコードのスレッドを実行する場合がある。一貫性を維持するため、データ同期メカニズムが使用される場合がある。１つの係る技術は、トランザクション型メモリ（TM：Transactional Memory）の使用を含む。トランザクションの実行（transactional execution）は、複数のマイクロ処理、処理又は命令のグループ化を含むことがある。複数のスレッドのそれぞれは、メモリ構造内の共通データを実行及びアクセスする。両方のスレッドがこの構造内の同じエントリにアクセス／変更する場合、データの有効性を保証するために競合の解決が実行される。トランザクションの実行の１つのタイプは、ソフトウェアトランザクション型メモリ（STM：Software Transactional Memory）を含み、この場合、メモリアクセスの追跡、競合の解決、アボートタスク及び他のトランザクショナルタスクは、一般にハードウェアのサポートなしにソフトウェアで実行される。

【発明の概要】

【発明が解決しようとする課題】

【0003】

トランザクションの実行の別のタイプは、ハードウェアトランザクション型メモリ（HTM：Hardware Transactional Memory）システムを含み、この場合、アクセストラッキング、競合の解決、及び他のトランザクショナルタスクをサポートするためにハードウェアが含まれる。以前は、現実のメモリデータアレイは、読出し、書込み及びバッファリングを追跡するためにハードウェア属性のような情報を保持するための更なるビットで拡張され、結果として、データは、プロセッサからメモリへのデータと共に移動する。この情報は、持続性（persistent）であると呼ばれ、すなわちキャッシュ立ち退き（cache eviction）に応じて失われない。これは、情報が記憶階層を通してデータと共に移動するためである。さらに、この持続性は、記憶階層システムを通して多くのオーバヘッドを課す。

【0004】

更に別のタイプのTMモデルは、無限トランザクション型メモリ（UTM）と呼ばれ、このUTMは、時間的且つメモリフットプリントにおいて任意の大きなトランザクションが、ハードウェア及びソフトウェアを使用したハードウェアアクセラレーション（hardware acceleration）の組み合わせを通して行われるのを可能にする。UTMトランザクションを実行及び実現することは、UTMハードウェアアクセラレーションインタフェースによる同時処理制御メカニズムを実現するための特別のコンパイルされたコードを一般に必要とする。結果として、UTMトランザクションは複雑になる可能性があり、既存のハードウェア及びSTMトランザクショナルシステムと正しく相互作用しない場合がある。

【特許文献1】US 2009-0172306 A1

【特許文献2】US 2009-0006767 A1

【特許文献3】US 2008-0162886 A1

【特許文献4】US 2007-0143741 A1

【課題を解決するための手段】

【0005】

様々な実施の形態では、TM実現は、異なるモードにおける異なるスレッドトランザクションを実行し、ソフトウェアの競合の管理、又は（ネスト化されたトランザクション、リトライ、デバッグ、又は外部のトランザクションのような）サポートされない動作又は処理の使用を含めて、様々な理由のためにモードを切り替えることができる。本発明の実施の形態に係るUTMシステムは、異なるパフォーマンス、フレキシビリティ（セマンティックリッチネス（semantic richness））及びキャパシティの配慮により、より大きな実行モードのデザインスペースを提供する。モードは、一般に、トランザクショナル、コード生成、プロセッサ及び共通言語ランタイム（CLR：Common Language Runtime）モードの組み合わせである。これは大きなスペースを構築する一方、議論に最も関連する特定のモードが導入される。

【0006】

トランザクション型メモリコード（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は、様々な実施の形態では、そのデータセットがプロセッサキャッシュで完全に適合する比較的小さなトランザクションのみをサポートする。

【0007】

更に別のモードは、ハードウェア支援モニタリング及びフィルタリング（HAMF：Hardware-Assisted Monitoring and Filtering）によるソフトウェアモードであり、このHAMFは、フィルタリングと同様に、トランザクションの競合を検出するUTMモニタリング機能を使用するソフトウェアモードである。このモードでは、ソフトウェアコンパチブルなロックが取得される。別のモードは、ハードウェア支援フィルタリング（HAF）をもつソフトウェアモードであり、フィルタリングのためにのみUTM機能が使用される。このモードにおいてソフトウェアロギングが実行され、ソフトウェアコンパチブルなロックが取得される。一般に、これら少なくとも２つのモードは、ハードウェア支援STM（HASTM）モードと呼ぶことができる。最後に、ソフトウェアトランザクションメモリ（STM）モードは、UTMリソースを使用しない純粋なソフトウェアモードである。

【0008】

異なるトランザクションモードをサポートするため、ソースコードの特定のチャンクは、異なるトランザクションモードに変換される。NK（Naked）は、特定のトランザクションのインスツルメンテーションをもたない古典的なコードを示す。TV（Transaction VTable）は、適切なトランザクションロギング及びロッキングを可能にするため、個々のオブジェクトフィールドのアクセスのために間接的なファンクションコールを埋め込むコード生成モードである。ディスパッチテーブル（vtable）は、この生成されたコードが様々なトランザクションモードをサポートするために使用されるのを可能にするため、異なるファンクションをディスパッチするために使用される。

【0009】

つぎに、プロセッサは、トランザクションに関連するモニタリング及びバッファリングのUTM特性に関して、３つの基本モードのうちの１つにおいて実行する。第一のモードであるMB_ALLが選択され、このモードでは、全てのロード（load）及びストア（store）はハードウェアのモニタリング及びバッファリングを誘導する。これは、UTM機能を使用するための一般に最も簡単なやり方であるが、（リードオンリ状態又はスタックのような）モニタリング及びバッファリングを必要としないメモリの範囲に適用されるモニタリング及びバッファリングに繋がる場合がある。第二のモードであるMB_DATAが選択され、このモードでは、ハードウェアトランザクションがセグメントレジスタに対して相対的にメモリアクセスを行う全てのロード及びストアは、デフォルトでバッファリング／モニタリングされる。このモードでは、全てのスタックのアクセスは、PUMOV（Potentially Unmonitored Move）動作を有し、すなわちあるロードがバッファリングされたキャッシュラインを読み出す場合、バッファリングされたコンテンツを読出し、あるストアがバッファリングされていないキャッシュラインに書き込む場合、通常の書込みのように動作し、該ストアがバッファリングされたキャッシュラインに書き込む場合、バッファリングされたコピー及びメインコピーの両者が更新される。このモードは、ハードウェアがバッファリング及びモニタリングするものに対するきめの細かい制御を提供し、複雑なコード生成の決定という代償を払って、MB_ALLモードよりも有効なデータをトランザクションが保持するのを可能にする。第三のモードであるMB_NONEが選択され、このモードでは、ロード及びストアの自動的なバッファリング及びモニタリングが行われない。代わりに、UTM ISAは、特定のメモリ位置のバッファリング又はモニタリングを誘発するため、特別な指示を提供する。なお、実行モードは、プロセッサキャッシュ内のUTM状態を設定するために使用される指示を制御する。ひとたび状態がキャッシュで設定されると、そのモードが状態を設定するために使用されるかを判定することができない。

【0010】

共通言語ランタイム（CLR）におけるネイティブコードは、以下を含む異なるモードで呼び出される。非トランザクションは、CLRのネイティブコードが呼び出される古典的な方法であり、暗黙的なトランザクションモードは、現在のスレッドがハードウェアトランザクションを実行し、プロセッサがMB_DATAについて設定される間に、CLRコードが呼び出されたときに行われ、明示的なトランザクションモードは、現在のスレッドがハードウェアトランザクションを実行し、プロセッサがMB_NONEについて設定される間に、CLRコードが呼び出されたときに行われるか、又は現在のスレッドがソフトウェアトランザクションを実行しているときに行われる。CLRが呼び出される異なるやり方は、管理される環境の現在の状態にアクセスするため、ネイティブコードが何を行うのを必要とするかを判定する。非トランザクション及び暗黙的なモードでは、CLRは、妨げられた管理された状態を直接に読み出すことができる。明示的なトランザクションモードでは、CLRは、管理された状態にアクセスするためのヘルパー機能を採用する場合がある。

【図面の簡単な説明】

【0011】

【図1】本発明の１実施の形態に係るプロセッサのブロック図である。

【図2】本発明の１実施の形態に係るプロセッサにおけるデータアイテムのメタデータを保持するブロック図である。

【図3】本発明の実施の形態に係るTMトランザクションを実行するトランザクションモードを選択する方法のフローダイアグラムである。

【図4】特定のモードにおけるトランザクションの実行の失敗の結果として、モード切替えを処理する方法のフローダイアグラムである。

【図5】本発明の実施の形態に係る、ハードウェアトランザクションとソフトウェアトランザクションを同時に処理する方法のフローダイアグラムである。

【図6】本発明の実施の形態に係る、システムのブロック図である。

【発明を実施するための形態】

【0012】

制限のないTM（UTM）で使用することができる実現の背景として、UTMトランザクションについて使用することができる例示的なハードウェアを見ることが有益である。一般に、UTMトランザクションは、ハードウェアで十分に実現することができるトランザクション、すなわちキャッシュ常駐トランザクション、及びハードウェアとソフトウェアの組み合わせを使用して実行する制限のないトランザクションと共にハードウェアの使用を可能にする。

【0013】

図１を参照して、複数のスレッドを同時に実行可能なプロセッサの実施の形態が例示される。なお、プロセッサ１００は、ハードウェアトランザクションの実行のためにハードウェアサポートを含む。ハードウェアトランザクションの実行と共に、又は、ハードウェアトランザクションの実行とは別に、プロセッサ１００は、STMのハードウェアアクセラレーション、STMの個別の実行、又は、例えば本発明の実施の形態に係るUTMといったこれらの組み合わせについてのハードウェアサポートを提供する。プロセッサ１００は、マイクロプロセッサ、埋め込みプロセッサ、デジタルシグナルプロセッサ（DSP）、ネットワークプロセッサ、又はコードを実行する他の装置のような、任意のタイプのプロセッサである場合がある。例示されるプロセッサ１００は、複数の処理エレメントを含む。

【0014】

図１で例示される物理的なプロセッサ１００は、２つのコアであるコア１０１及び１０２を含んでおり、２つのコアは、上位のキャッシュ１１０へのアクセスを共有する。プロセッサ１００は、非対称なコア、すなわち異なるコンフィギュレーション、機能ユニット及び／又はロジックをもつコアを含む場合があるが、対称なコアが示される。結果として、コア１０１と同じように例示されるコア１０２は、繰返しの説明を回避するために詳細に説明されない。さらに、コア１０１は、２つのハードウェアスレッド１０１ａ及び１０１ｂを含むが、コア１０２は、２つのハードウェアスレッド１０２ａ及び１０２ｂを含む。従って、オペレーティングシステムのようなソフトウェアエンティティは、プロセッサ１００を４つの個別のプロセッサ、すなわちソフトウェアスレッドを同時に実行可能な４つの論理プロセッサ又は処理エレメントとして潜在的に見る。

【0015】

ここで、第一のスレッドは、アーキテクチャ状態レジスタ１０１ａと関連付けされ、第二のスレッドは、アーキテクチャ状態レジスタ１０１ｂと関連付けされ、第三のスレッドは、アーキテクチャ状態レジスタ１０２ａと関連付けされ、第四のスレッドは、アーキテクチャ状態レジスタ１０２ｂと関連付けされる。例示されるように、アーキテクチャ状態レジスタ１０１ａは、アーキテクチャ状態レジスタ１０１ｂで複製され、従って個々のアーキテクチャ状態／コンテクストは、論理プロセッサ１０１ａ及び論理プロセッサ１０１ｂについて記憶可能である。アーキテクチャ状態レジスタは、１実施の形態では、例えばトランザクション状態レジスタ（TSR）、トランザクション制御レジスタ（TCR）といった、UTMトランザクションの実現における使用向けのレジスタ、及び、（トランザクションのアボート（abort）のような）トランザクションの間にイベントを処理するために使用するイジェクションハンドラの位置を識別するイジェクションインストラクションポインタレジスタを含む。

【0016】

インストラクションポインタ及びリネームアロケータ（rename allocator）ロジック１３０におけるリネーミングロジックのような他の小さなリソースもスレッド１０１ａ及び１０１ｂについて複製される。リオーダ（reorder）／リタイアメント（retirement）ユニット１３５におけるリオーダバッファ、インストラクショントランスレーション・ルックアサイドバッファ（ITLB：Instruction Translation Lookaside Buffer）１２０、ロード／ストアバッファ、及びキューのような幾つかのリソースは、パーティションを通して共有される。汎用内部レジスタ、ページテーブルベースレジスタ、低水準データキャッシュ及びデータ−TLB１１５、実行ユニット１４０、及びアウトオブオーダ（out-of-order）ユニット１３５の一部のような他のリソースは、潜在的に十分に共有される。

【0017】

例示されるように、プロセッサ１００は、システムメモリ１７５、チップセット、ノースブリッジ又は他の集積回路のような、プロセッサ１００の外部の装置と通信するバスインタフェースモジュール１０５を含む。メモリ１７５は、プロセッサ１００の専用であるか、又はシステムにおける他の装置と共有される。高水準又は更なるキャッシュ１１０は、高水準キャッシュ１１０から最近フェッチされたエレメントをキャッシュする。なお、高水準又は更なるとは、実行ユニットから増加又は更に離れるキャッシュレベルを示す。１実施の形態では、高水準キャッシュ１１０は、第二レベルのデータキャッシュである。しかし、高水準キャッシュ１１０は、インストラクションキャッシュに関連されるか又はインストラクションキャッシュを含むとき、その様に限定されるものではない。トレースキャッシュ、すなわちあるタイプのインストラクションキャッシュは、最近デコードされたトレースを記憶するためにデコーダ１２５の後に結合される。また、モジュール１２０は、実行／採用されるべき分岐を予測するブランチターゲットバッファと、命令についてアドレス変換エントリを記憶するITLBを潜在的に含む。

【0018】

デコードモジュール１２５は、フェッチされたエレメントをデコードするためにフェッチ（fetch）ユニット１２０に結合される。１実施の形態では、プロセッサ１００は、プロセッサ１００で実行可能な命令を定義／指定するISAに関連される。ここで、ISAにより認識されるマシンコード命令は、実行されるべき命令又は動作を参照／指定する命令コード（opcode）と呼ばれる命令の一部を含む。

【0019】

１例として、アロケータ及びリネーマブロック１３０は、命令処理結果を記憶するレジスタファイルのような、リソースを予約するアロケータを含む。しかし、スレッド１０１ａ及び１０１ｂは、順不同実行（out-of-order execution）が潜在的に可能であり、この場合、アロケータ及びリネーマブロック１３０が、命令の結果を追跡するリオーダバッファのような他のリソースを予約する。また、ユニット１３０は、プロセッサ１００の内部にある他のレジスタにプログラム／命令参照レジスタの名前を変えるレジスタリネーマを含む。リオーダ／リタイアメントユニット１３５は、上述されたリオーダバッファ、順不同実行及び順不同で実行された命令の後のインオーダ（in-order）リタイアメントをサポートするため、ロードバッファ及びストアバッファのようなコンポーネントを含む。

【0020】

スケジューラ及び実行ユニットブロック１４０は、１実施の形態では、実行ユニットでの命令／動作をスケジュールするスケジューラユニットを含む。例えば、浮動小数点命令は、利用可能な浮動小数点実行ユニットを有する実行ユニットの位置でスケジュールされる。また、実行ユニットに関連されるレジスタファイルは、情報命令の処理結果を記憶するために含まれる。例示的な実行ユニットは、浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、記憶実行ユニット、及び他の公知の実行ユニットを含む。

【0021】

下位レベルのデータキャッシュ及びデータ変換バッファ（D-TLB）１５０は、実行ユニット１４０に結合される。データキャッシュは、メモリの一貫性の状態で潜在的に保持される、データオペランドのようなエレメントについて最近に使用／処理されたものを記憶する。D-TLBは、物理アドレス変換に最近のバーチャル／リニアを記憶する。特定の例として、プロセッサは、複数のバーチャルページに物理メモリを分割するページテーブル構造を含む。１実施の形態では、プロセッサ１００は、ハードウェアトランザクションの実行、ソフトウェアトランザクションの実行、又はこれらの組み合わせ又は混成が可能である。コードのクリティカル又はアトミックセクション（atomic section）とも呼ばれるトランザクションは、アトミックグループとして実行される命令、処理又はマイクロ処理のグループを含む。例えば、命令又は処理は、トランザクションセクション又はクリティカルセクションを定めるために使用される。１実施の形態では、これらのセクションは、上述されたデコーダのようなプロセッサ１００のハードウェアにより認識可能である、ISAのような命令のセットの一部である。これらの命令は、高水準言語からハードウェア認識可能なアセンブリ言語にひとたびコンパイルされると、デコードステージの間のデコーダが認識する、命令コード（オペコード）又は命令の他の部分を含む。

【0022】

典型的に、トランザクションの実行の間、メモリに対するアップデートは、トランザクションが関与されるまで、グローバルに見えるようにされない。例として、あるロケーションへのトランザクション・ライト（transactional write）は、ローカルスレッドに対して潜在的に見ることができ、更に、別のスレッドからの読取りに応答して、書込みデータは、トランザクション・ライトを含むトランザクションがコミットされる（committed）まで送出されない。トランザクションがなお保留である間、以下の更に詳細に記載されるように、メモリからロードされたデータアイテム／エレメント及びメモリに書き込まれたデータアイテム／エレメントが追跡される。トランザクションがコミットポイントにひとたび到達すると、トランザクションについて競合が検出されない場合、トランザクションがコミットされ、トランザクションの間に行われるアップデートは、グローバルに見ることができる。

【0023】

しかし、トランザクションがその係属の間に無効にされる場合、トランザクションはアボートされ、アップデートをグローバルに見ることなしに潜在的に再スタートされる。結果として、本明細書で使用されるとき、トランザクションの係属は、実行を開始したトランザクションであって、コミット又はアボートされていない、すなわち係属しているトランザクションを示す。

【0024】

１実施の形態では、プロセッサ１００は、ハードウェア／ロジックを利用して、すなわちハードウェアトランザクションメモリ（HTM）システムにおいて、トランザクションを実行可能である。HTMを実現するとき、アーキテクチャの視点及びマイクロアーキテクチャの視点の両者から様々な特定の実現の詳細が存在する。それらの大部分は、本発明の実施の形態を不必要に曖昧にするのを回避するため、本明細書では説明されない。しかし、幾つかの構造及び実現は、例示する目的で開示される。さらに、これらの構造及び実現は、必要とされないか、増補されるか、及び／又は異なる実現の詳細を有する他の構造で置き換えられる。

【0025】

一般に、プロセッサ１００は、STM及びHTMシステムの両者の利益の利用するのを試みる、UTMシステムにおいてトランザクションを実行可能である。例えば、HTMは、小さなトランザクションを実行するために高速且つ効率的であることがある。これは、HTMは、アクセスの追跡、競合の検出、妥当性検証、及びトランザクションのコミットの全てを実行するためにソフトウェアに依存しないためである。しかし、HTMは、小さなトランザクションのみを扱うことができる一方、STMは、制限されないサイズのトランザクションを扱うことができる。従って、１実施の形態では、UTMシステムは、小さなトランザクションを実行するためにハードウェアを使用し、ハードウェアにとって大きすぎるトランザクションを実行するためにソフトウェアを利用する。以下の説明から理解されるように、ソフトウェアがトランザクションを扱うときでさえ、ハードウェアは、ソフトウェアを支援及び加速するために利用される。また、純粋なSTMシステムをサポート及び加速するために同じハードウェアが利用される場合がある。

【0026】

上述されたように、トランザクションは、プロセッサ１１０内のローカル処理エレメントと同様に、他の処理エレメントにより潜在的に、データアイテムへのメモリアクセスであるトランザクションを含む。トランザクション型メモリシステムにおけるセーフティメカニズムがなければ、これらのアクセスの幾つかは、無効なデータ及び実行となり、すなわち読取りを無効にするデータの書込み、又は無効なデータの読取りとなる。結果として、プロセッサ１００は、以下に記載されるリードモニタ（read monitors）及びライトモニタ（write monitors）のような、潜在的な競合の識別のためにデータアイテムへのメモリアクセス及びデータアイテムからのメモリアクセスを追跡又はモニタするロジックを含む。

【0027】

１実施の形態では、プロセッサ１００は、データアイテムに関連される、アクセス及び潜在的なその後の競合を検出又は追跡するモニタを含む。１つの例として、プロセッサ１００のハードウェアは、モニタされるように決定されたロード及びストアを追跡するためにリードモニタ及びライトモニタを含む。ハードウェアのリードモニタ及びライトモニタは、基本的な記憶構造の粒度に係らず、データアイテムの粒度でデータアイテムをモニタする。１実施の形態では、データアイテムは、少なくとも全体のデータアイテムが適切にモニタされることを保証するため、記憶構造の粒度で関連するメカニズムを追跡することで境界付けされる。

【0028】

特定の例として、リードモニタ及びライトモニタは、下位レベルのデータキャッシュ内のロケーションに関連するアドレスからのロードをモニタし、該アドレスへのストアをモニタするため、下位レベルのデータキャッシュ１５０内のロケーションのようなキャッシュロケーションに関連する属性を含む。ここで、データキャッシュ１５０のキャッシュロケーションについてのリードの属性は、同じアドレスへの潜在的な競合する書込みをモニタするため、キャッシュロケーションに関連するアドレスへの読取りイベントに応じて設定される。この場合、書込み属性は、同じアドレスへの潜在的に競合する読取り及び書込みをモニタするため、書込みイベントについて同様のやり方で動作する。この例を更に進めるため、キャッシュロケーションがモニタされることを示すために設定された読取り及び／又は書込みの属性によるキャッシュロケーションへの読取り及び書込みのスヌープに基づいて、ハードウェアは競合を検出可能である。逆に、リードモニタ及びライトモニタの設定、又はバッファリングされた状態へのキャッシュロケーションの更新は、１実施の形態において、検出されるべき他のキャッシュにおいてモニタされるアドレスとの競合を可能にする、読取り要求又はオーナシップの読み取り（read for ownership）の要求のようなスヌープとなる。

【0029】

従って、デザインに基づいて、キャッシュのコヒーレンシーの要求とキャッシュラインのモニタリングされたコヒーレンシーの状態との異なる組み合わせにより、共有される読取のモニタされた状態においてデータアイテムを保持するキャッシュラインと、データアイテムへの書込み要求を示すスヌープとのような、潜在的な競合となる。逆に、バッファリングされた書込み状態にあるデータアイテムを保持するキャッシュラインと、データアイテムへの読取り要求を示す外部スヌープとは、潜在的に競合していると考えられる場合がある。１実施の形態では、アクセス要求と属性の状態との係る組み合わせを検出するため、スヌープロジックは、競合を報告する状態レジスタと同様に競合の検出／報告のためにモニタ及び／又はロジックのような競合の検出／報告ロジックに結合される。

【0030】

しかし、条件及びシナリオの組み合わせは、コミット命令のような命令により定義される、トランザクションを無効にすると考えられる。トランザクションのノンコミットについて考えられるファクタの例は、トランザクションによりアクセスされるメモリロケーションへの競合を検出し、モニタ情報を失い、バッファリングされたデータを失い、トランザクションによりアクセスされるデータアイテムに関連されるメタデータを失い、アボート、リングトランジション、又は（再開されたトランザクションが係属されないことを想定）明示的なユーザインストラクション、のような他の無効にするイベントを検出することを含む。

【0031】

１実施の形態では、プロセッサ１００のハードウェアは、バッファリングされたやり方で、トランザクション・アップデート（transaction update）を保持する。上述されたように、トランザクション・ライトは、トランザクションのコミットまでグローバルに見えない。しかし、トランザクション・ライトに関連するローカルソフトウェアスレッドは、その後のトランザクション・アクセス（transaction access）についてトランザクション・アップデートにアクセス可能である。第一の例として、個別のバッファ構造は、他の外部スレッドではないローカルスレッドへの更新を提供可能な、バッファリングされたアップデートを保持するためにプロセッサ１００において提供される。さらに、個別のバッファ構造を包含することは、潜在的に高価且つ複雑である。

【0032】

対照的に、別の例として、データキャッシュ１５０のようなキャッシュメモリは、同じトランザクションの機能を提供する間に、アップデートをバッファリングするために利用される。ここで、キャッシュ１５０は、バッファリングされたコヒーレンシーの状態においてデータアイテムを保持可能であり、１つのケースでは、新たにバッファリングされたコヒーレンシーの状態は、MESIBプロトコルを形成するため、MESI（Modified Exclusive Shared Invalid）プロトコルのようなキャッシュコヒーレンシープロトコルに追加される。バッファリングされたデータアイテム、すなわちバッファリングされたコヒーレンシー状態で保持されているデータアイテムのローカル要求に応答して、キャッシュ１５０は、シーケンシャルオーダリング（sequential ordering）の内部トランザクションを保証するため、データアイテムにローカル処理エレメントを提供する。しかし、外部アクセス要求に応答して、コミットまで、更新されたデータアイテムのトランザクションがグローバルに見えるのを保証するため、ミスレスポンスが提供される。さらに、キャッシュ１５０のラインがバッファリングされたコヒーレンシーの状態において保持され、立ち退きのために選択されるとき、バッファリングされたアップデートは、上位のキャッシュメモリに書き込まれない。バッファリングされたアップデートは、メモリシステムを通して増加せず、すなわちコミットの後までグローバルに見えない。コミットに応じて、バッファリングされたラインは、データアイテムをグローバルに見えるようにするため、変更された状態に遷移される。

【0033】

用語「内部」及び「外部」は、キャッシュを共有するトランザクション又は処理エレメントの実行に関連するスレッドの視点に関する。例えば、あるトランザクションの実行に関連するソフトウェアスレッドを実行する第一の処理エレメントは、ローカルスレッドと呼ばれる。従って、先の説明において、バッファリングされたコヒーレンシー状態で保持されているアドレスのためのキャッシュラインとなる、第一のスレッドにより前に書き込まれたアドレへのストア又は該アドレスへのロードが受信された場合、バッファリングされたバージョンのキャッシュラインは、第一のスレッドに提供される。これは、第一のスレッドがローカルスレッドであるためである。対照的に、第二のスレッドは、同じプロセッサ内の別の処理エレメントで実行しているが、外部スレッドであるバッファ状態で保持されているキャッシュラインに関与するトランザクションの実行に関連しない。従って、第二のスレッドからアドレスへのロード又はストアは、バッファリングされたバージョンのキャッシュラインを欠き、上位のメモリからバッファリングされないバージョンのキャッシュラインを検索するため、通常のキャッシュの置換えが利用される。

【0034】

ここで、内部／外部／遠隔のスレッドは、同じプロセッサで実行され、幾つかの実施の形態では、キャッシュへのアクセスを共有する同じプロセッサのコアにおける個別の処理エレメントで実行される。しかし、これらの用語の使用は限定されるものではない。上述されたように、ローカルは、トランザクションの実行に関連する単一のスレッドに固有である代わりに、あるキャッシュへのアクセスを共有する複数のスレッドを示し、外部又は遠隔は、キャッシュへのアクセスを共有しないスレッドを示す。

【0035】

図１を最初に参照して先に述べたように、プロセッサ１００のアーキテクチャは、説明のために純粋に例示するものである。例えば、他の実施の形態では、UBTハードウェアは、複雑なリネーム／アロケータ及びリオーダ／リタイアメントユニットを含まない、より簡単なインオーダの実行プロセッサの設計をもつプロセッサについて実現される。同様に、同じメモリの個別のエントリにおけるメタデータとデータを関連付けする方法が利用されるとき、メタデータを参照するデータアドレスを変換する特定の例もまた例示するものである。

【0036】

図２を参照して、プロセッサにおいてデータアイテムのメタデータを保持する実施の形態が例示される。図示されるように、データアイテム２１６のメタデータ２１７は、メモリ２１５にローカルに保持される。メタデータは、データアイテム２１６に関連するトランザクションの情報のような、データアイテム２１６に関連されるプロパティ又は属性を含む。幾つかの例示的なメタデータが以下に含まれ、開示されるメタデータの例は、単に例示するものである。係るように、メタデータのロケーション２１７は、データアイテム２１６の情報と他の属性との組合せを保持する。

【0037】

第一の例として、トランザクションにおいてデータアイテム２１６が前にアクセス、バッファリング及び／又はバックアップされている場合、メタデータ２１７は、トランザクションで書き込まれたデータアイテム２１６のバックアップ又はバッファロケーションへのリファレンスを含む。ここで、幾つかの実現では、前のバージョンのデータアイテム２１６のバックアップコピーは、異なるロケーションで保持され、結果として、メタデータ２１７は、バックアップロケーションへのアドレス又は他のリファレンスを含む。代替的に、メタデータ２１７自身は、データアイテム２１６のバックアップ又はバッファロケーションとしての役割を果たす。

【0038】

別の例として、メタデータ２１７は、データアイテム２１６へのリピートトランザクショナルアクセス（repeat transactional access）をアクセラレートする第一の値を含む。ソフトウェアを利用したトランザクションの実行の間、アクセスのバリアは、一貫性及びデータの有効性を保証するためにトランザクション型メモリアクセス（transactional memory access）で実行される。トランザクショナルロードオペレーション（transactional load operation）の前に、データアイテム２１６がアンロックされているかを検査し、トランザクションの現在のリードセットがなお有効であるかを判定し、フィルタ値をアップデートし、後の検証を可能にするためにトランザクションのリードセットにおけるバージョンの値のロギングのような、リードバリア処理を実行するためにリードバリアが実行される。しかし、そのロケーションの読取りがトランザクションの実行の間に既に実行されている場合、同じリードバリアオペレーションは潜在的に不要である。

【0039】

結果として、１つのソリューションは、リードフィルタを利用して、データアイテム２１６又はアドレスがトランザクションの実行の間に読み取られていないことを示す第一のデフォルト値を保持し、データアイテム２１６又はアドレスがトランザクションの係属の間に既にアクセスされていることを示す第二のアクセス値を保持するリードフィルタを利用することを含む。本質的に、第二のアクセスされた値は、リードバリアをアクセラレートすべきかを示す。この例では、トランザクショナルロードオペレーションが受信され、メタデータのロケーション２１７におけるリードフィルタ値が、データアイテム２１６が既に読み取られたことを示す場合、１実施の形態では、リードバリアが無視され、実行されず、不要な、冗長なリードバリアオペレーションを実行しないことで、トランザクションの実行をアクセラレートする。なお、書き込みフィルタ値は、書き込み動作に関して同じ方式で動作する。しかし、１実施の形態では、書き込み又は読取りであろうと、アドレスが既にアクセスされるかを示すために単一のフィルタ値が利用されるように、個々のフィルタ値は単に例示するものである。ここで、ロード及びストアの両者について、データアイテム２１６のメタデータ２１７をチェックするメタデータアクセスオペレーションは、メタデータ２１７は個別のリードフィルタ値及びライトフィルタ値を含む先の例とは対照的である、単一のフィルタ値を利用する。特定の例示的な実施の形態では、４ビットのメタデータ２１７は、関連されるデータアイテムに関してリードバリアをアクセラレートすべきかを示すリードフィルタ、関連されるデータアイテムに関してライトバリアをアクセラレートすべきかを示すライトフィルタ、ｕｎｄｏ処理をアクセラレートすべきかを示すｕｎｄｏフィルタ、及びフィルタ値としてソフトウェアにより何れかのやり方で利用されるその他のフィルタ（miscellaneous filter）に割り当てられる。メタデータの幾つかの他の例は、ハンドラのアドレスの示唆、ハンドラのアドレスの表現又はハンドラのアドレスへの参照を含み、データアイテム２１６に関連するトランザクション、データアイテム２１６に関連するトランザクションの取り消し不能／頑強な性質、データアイテム２１６の損失、データアイテム２１６のモニタリング情報の損失、データアイテム２１６について検出されている競合、データアイテム２１６と関連するリードセットにおけるリードセット又はリードエントリのアドレス、データアイテム２１６の前にログされたバージョン、データアイテム２１６の現時のバージョン、データアイテム２１６へのアクセスを許可するロック、データアイテム２１６のバージョン値、データアイテム２１６に関連するトランザクションのトランザクション記述子、他の公知のトランザクションに関連する記述情報、にとって一般的又は個別的である。さらに、先に記載されたように、メタデータの使用は、トランザクショナル情報に限定されない。当然の結果として、メタデータ２１６は、トランザクションに関与しない、データアイテム２１６に関連する情報、特性、属性又は状態を含む。

【0040】

UTMシステムのこの背景によれば、トランザクションをどの様に開始するかに関する次の考慮が説明される。スレッドがトランザクションに入ったとき、スレッドは、TM実行モードのうちの１つに遷移する。スレッドが何れかのタイプのSTMモードではない場合（一般に、何れかのSTMモードが*STMモードと呼ばれる）、現在のスレッドは、暗黙のモードCRITMを使用する。多くのスレッドは、CRITMモードにある。スレッドがハードウェアの境界付けされた容量をオーバフローするか、又は現在のモードにおいて行うことができない幾つかのセマンチックアクションを実行する場合、CRITMトランザクションは、幾つかの*STMモードでロールバック及び再実行する。何れかのスレッドがひとたび*STMモードになると、全ての他のスレッドは、CRITMモードから離れ（ロールバック）、CRESTMのようなSTMロックに関するモードにおいて再実行する。例えばCRITM及びCRESTMといった幾つかの可能性のある実行が可変である組み合わせ（execution variant combination）が存在する。説明のため、このモードの組み合わせは、本明細書で使用される。

【0041】

表１は、２つの例示的なトランザクション・実行モードを互いに比較し、２つの例示的なトランザクション・実行モードを最新のプレインなノントランザクショナルモードと比較する。

【0042】

【表1】

例えばバッファリングされたデータの損失又は競合のために、幾つかのトランザクションが失敗すること、そのためにトランザクションがアボートすることは避けられない。幾つかの例では、トランザクションのモードは、再実行の時間で変化する場合がある。トランザクションは、低いパフォーマンスモードに「フォールバック」するか又は高いパフォーマンスのモードに「アップグレード」する。すなわち、パフォーマンスの視点から全てのモードが等しくない。一般に、CRITMは、最も効率のよい実行モードである。それは、ソフトウェアロックに対処するオーバヘッドを回避するためである。次に効率のよいモードは、CRESTMであり、続いてHASTMであり、次いでSTMである。STM及びHASTMモードは、これらが提供する機能において等価であり、従ってSTMは、以下に記載されるこれらの両方のモードを表すために使用される。

【0043】

しかし、全てのトランザクションは、CRITMモードで実行することができない。それは、CRITMモードは、キャッシュ常駐トランザクションでのみ動作するためである。CRESTMモードもキャッシュ常駐トランザクションに制限されるので、キャッシュ非常駐トランザクションは、STMモードの下で実行される必要がある。CRITMモードは、STMモードと互換性がないので、あるトランザクションがSTMモードの下で動作するのを開始するとすぐ、CRITMモードの下でトランザクションは実行されない。従って、現段階では、全てのキャッシュ常駐トランザクションは、CRESTMモードに移行する。

【0044】

トランザクションがどのモードの下で実行されるかに関する広義の制約は、以下の通りである。全てのトランザクションは、CRITMモードで開始するが、STMトランザクションが実行されている場合、全てのトランザクションは、CRESTMモードで開始する。トランザクションがキャッシュをオーバフローする場合、トランザクションはロールバックし、STMモードの下で実行を再開する。トランザクションがSTMモードの下で実行されている場合、全てのCRITMトランザクションは、ドゥーム処理され（doomed）、CRESTMモードの下で実行を再開する。

【0045】

１実施の形態では、「リトライ“retry”」プリミティブのサポートの周辺で幾つかの更なる制約が存在する。トランザクションが「リトライ」プリミティブを使用する場合、トランザクションは、STMモードでのみ実行することができる。それは、CRITM及びCRESTMがリトライを待つことをサポートしないためである。システムにおける何れかのシステムが「リトライ」で待っている場合、全ての他のトランザクションは、CRESTM又はSTMモードで実行する必要がある。それは、CRITMは、通知（notification）をサポートしないためである。

【0046】

図３を参照して、本発明の実施の形態に係る、TMトランザクションを実行するトランザクション・実行モードを選択する方法のフローダイアグラムが示される。１実施の形態では、方法３００は、UTMシステムのランタイムにより実現される。この通り、図３は、他のトランザクションがシステムにおいてアクティブであるかを判定することで開始する（ひし形３１０）。これは、所定のハードウェアトランザクションモードがSTMトランザクションと互換性がないときに行われる。他の係るトランザクションがアクティブでない場合、制御はブロック３２０に進み、ブロック３２０で、トランザクションは、最も効率の良い利用可能なモードで開始する。本明細書で記載されるコンテクストでは、最も高い効率の良いモードは、ハードウェアインプリシット・トランザクションモード（hardware implicit transaction mode）（例えばCRITM）である場合がある。勿論、異なる実現では、異なるモード又は変更されたモードが利用可能な場合がある。

【0047】

代わりにひし形３１０で、他のトランザクションがアクティブであると判定された場合、制御はひし形３２５に進み、ひし形３２５で、これらのトランザクションの何れかがSTMモードにあるかが判定される。これらのトランザクションの何れかがSTMモードにある場合、新たなトランザクションは、STMモードと一致する最も効率の高いモードで開始する（ブロック３３０）。例えば、本明細書で説明される実現では、この最も高い互換性のあるモードは、ハードウェアエクスプリシットモード（hardware explicit mode）（例えばCRESTM）である場合があり、このモードでは、プロセッサキャッシュ内に完全に内在する場合があるハードウェアがトランザクションを支援するが、ソフトウェアロックが尊重される。

【0048】

従って、トランザクションが開始され、動作が継続する。次いで、オーバフローが生じるかが判定される（ひし形３３５）。すなわち、全てのトランザクションが幾つかのタイプのキャッシュ常駐・ハードウェア支援モード（cache resident hardware assisted mode）で開始するとき、キャッシュスペースは、完全なトランザクションを扱うために不十分である。従って、ひし形３３５で判定されたときにオーバフローが生じた場合、以下に更に記載されるようにブロック３７５に制御が進む。代わりに、トランザクションがオーバフローしない場合、次に、トランザクションが終了したかが判定される（ひし形３４０）。トランザクションが終了していない場合、継続される実行が行われる。トランザクションが終了した場合、制御はひし形３５０に進み、ひし形３５０で、トランザクションのハードウェア特性が維持されているかが判定される。すなわち、トランザクションがコミットする前に、例えばバッファリング、モニタリング及びメタデータのUTM特性といった様々なハードウェア特性は、これらの特性が損失なしになおアクティブであるかを判定するためにチェックされる。アクティブではない場合、幾つかのハードウェア特性の損失が生じており、ブロック３６０に制御が進み、ブロック３６０で、トランザクションがアボートされる。さもなければ、トランザクションが上手く終了し、且つハードウェア特性が残されている場合、ブロック３５５に制御が進み、ブロック３５５で、トランザクションがコミットされる。

【0049】

図３を更に参照して、代わりにキャッシュ常駐トランザクションの実行の間、（ひし形３３５で判定されたときに）トランザクションがキャッシュをオーバフローさせた場合、ブロック３７５に制御が進む。そこでトランザクションはロールバックされ、STMモードで再実行される。STMモードでの実行の間、セマンティックが違反されたかが判定される（ひし形３８０）。セマンティックが違反された場合、ブロック３８２に制御が進み、ブロック３８２で、トランザクションがロールバックされ、例えば純粋なSTMモードといった下位の効率の良いモードで再実行される。ハードウェア支援トランザクションに関して説明されたように、トランザクションが終了したか、及び上手くコミットされたか又はアボートが必要とされるかにを判定することに関する同様の動作が行われる（ブロック３８５、３９０、３９２、３９５）。図３の実施の形態におけるこの特定の実現により記載される一方、あるトランザクションを実行する所与のモードの制御は、異なる実現において変わる場合があることを理解されたい。

【0050】

このように図３の方法は、あるトランザクションを開始するため、どのように適切なモードを決定するかを一般に説明している。しかし、トランザクションの間、キャッシュのオーバフロー又はSTMの失敗以外の理由のため、失敗が生じる場合がある。様々な実施の形態では、先に記載された制約が満たされ、且つシステムが最適なパフォーマンスを達成するように、新たな（又は再実行されている）トランザクションがどのモードで実行されるかを判定するため、フォールバック及びアップグレードメカニズムが実現される。表２は、トランザクションをドゥーム処理（終了）する理由のセットを示す。表２における第一の列は、トランザクションをドゥーム処理する様々な理由を記載し、第二の列及び第三の列は、前に保留しているCRITM又はCRESTMトランザクションが再実行される新たなモードをそれぞれ示す。ブランクにされているセルは、トランザクションが所与の理由のためにドゥーム処理されないことを示す。

【0051】

【表2】

図２に関して、第一の優先事項は、CRITMモードで再実行することである。しかし、トランザクションがCRITMモードで利用可能ではない機能を必要とする場合、又はSTMトランザクションが進行中である場合、トランザクションは、CRESTMモードで再実行される。この理由のためにCRESTMを終了する決定は、経験則に基づく。また、CRITMトランザクションは、現時点で実行されるべきではない。

【0052】

なお、表２に示される設計上の選択における自由度が存在する。例えば、キャッシュ常駐であるモードを設計することは可能であるが、ソフトウェアに基づく失敗の原子性（software based failure atomicity）を提供する。係るモードは、ネスト化されたトランザクションの失敗に対処するために使用される。

【0053】

ここで図４を参照して、特定のモードにおいて実行しているトランザクションの失敗の結果として、モード切り替えを扱う方法のフローダイアグラムが示される。図４の方法４００は、１実施の形態では、第一のモードにおけるトランザクションの失敗に応じて制御を受けるイジェクションハンドラにより実現される。この通り、方法４００は、トランザクションの失敗の理由を判定することで開始する（ブロック４１０）。この決定は、受信された様々な情報に基づいて行われる。例として、TCR及び／又はTSRの情報は、失敗の理由を示す。同様に、トランザクション制御ブロックは、失敗の理由を示す。更に、他の実現では、この情報を取得する他のやり方が使用される場合がある。

【0054】

さらに、図４を参照して、一般に、トランザクションをドゥーム処理する理由に基づいて、例えばトランザクションを再実行する異なるパスといった異なるリカバリパスが選択される。さらに、図４の実施の形態における特定の順序で記載及び図示される一方、これは説明の便宜のためであって、行われる様々な決定は、様々な実現において異なる順序で（及び異なるやり方で）行われることを理解されたい。この通り、ひし形４１５で、必要とされる機能は、現在のトランザクションモードによりサポートされなかったかが判定される。係るサポートされない機能の例は、以下に記載される。これがトランザクションの失敗についての原因であると判定された場合、ブロック４２０に制御が進み、ブロック４２０で、この機能をサポートする別のモードの選択が行われる。従って、トランザクションは、この新たなモードへのモード切り替えに従ってトランザクションが再実行される。

【0055】

トランザクションをドゥーム処理する更に別の理由は、ひし形４２５で決定されるように、トランザクションがそれ自身をドゥーム処理することである。トランザクションがそれ自身をドゥーム処理した場合、トランザクションがそれ自身をドゥーム処理した回数が判定される。この数は、閾値に比較される（ひし形４３０）。数がこの閾値を超える場合、トランザクションがそれ自身をドゥーム処理し続けることを示し、トランザクションは、異なるモードに切り替えられる（ブロック４３５）。閾値に一致しない場合、再実行は、同じモードで行われる（ブロック４４０）。

【0056】

トランザクションをドゥーム処理する更なる理由は、外部システムのアクティビティがドゥーム処理を引き起こしたかである。これが判定された場合（ブロック４５０）、この外部のアクティビティが保留のSTMトランザクションにおいて増加したかが判定される（ダイアモンド４５５）。この外部のアクティビティが保留のSTMトランザクションにおいて増加した場合（及び現在のトランザクションがハードウェアインプリシット・モードトランザクションである場合）、トランザクションは、ハードウェアエクスプリシットモードで再実行される（ブロック４６０）。STMトランザクションの数における増加の代わりに、（ひし形４６２で判定されるように）保留のSTMトランザクションにおける減少があると判定された場合、保留のハードウェアエクスプリシットトランザクションがより効率が良いときに、ハードウェアインプリシットモードにおいて保留のハードウェアエクスプリシットトランザクションを再開すべきかに関する判定が行われる（ブロック４６５）。この判定をなすことにおける異なる考慮は、STMトランザクションにおける変化が外部システムのアクティビティではない場合、トランザクションは、その現在のモードで再実行される（ブロック４７０）。同様に、例えば競合又は別の係る理由のため、トランザクションの失敗の幾つかの他の理由が存在する場合、トランザクションは、同じモードで再実行される（ブロック４８０）。この特定の実現が図４の実施の形態において示されているが、本発明の範囲はこの点に限定されないことを理解されたい。

【0057】

表２において先に記載され、図４において説明された理由は、４つの広いカテゴリに分類される。それぞれのカテゴリについて、フォールバック及びアップグレードメカニズムが記載される。第一の失敗の原因のカテゴリは、所与の実行モードによりサポートされない機能である。理由１〜５は、CRITMについてこのバケットに分類される。CRESTMについて、理由２〜５は、このバケットに分類される。これらの理由は、トランザクションに不可欠であり、現在の実行モードにおいて制限を露呈する。従って、トランザクションの再実行は、前に実行されたのと同じモードにあるべきではなく、代わりに、必要とされるサポートを有するモードへの切り替えが行われる場合がある。この機能をサポートするため、（トランザクションがドゥーム処理されたとき）持続性のある書き込み（durable write）がトランザクションコンテクストに実行され、トランザクションが再実行されたときに使用されるべきモードを指定する。

【0058】

第二の失敗の原因のカテゴリは、トランザクションが自殺する（自身をドゥーム処理する）場合である。理由６及び理由７は、このカテゴリに分類される。理由６について、トランザクションはロールバックされ、必要とされるブロックの編集（例えばジャストインタイム（JIT））が実行され、次いで、トランザクションは、同じモードで再実行される。これは、ある機能をJITすることは非常に高価であるためであり、従って、ロールバック及び再実行のオーバヘッドは、顕著ではないからである。理由７について、トランザクションは、同じモードで再実行される。これは、第一に、モニタリングされた／バッファリングされたラインは、オブジェクトヘッダを次からは含まない場合があり、第二に、オブジェクトヘッダへの書き込みのために、モニタリング（又はバッファリング）の損失が生じたことを知る方法がないからである。幾つかの実現において、オブジェクトヘッダへの書き込みのためにトランザクションがそれ自身をドゥーム処理し続けるシナリオについて、予防手段が提供される。１つの例として、（幾つかの予め決定された閾値よりも大きい）Ｎ回だけ再実行するCRITM／CRESTMトランザクションは、STMモードで再実行されるというルールが設定される。

【0059】

第三の失敗の原因のカテゴリは、現在のトランザクションの外部にあるシステムアクティビティがそれをドゥーム処理する場合である。理由８〜理由１０は、このカテゴリに分類される。理由８について、ガーベージコレクション（GC）の停止のためにトランザクションがロールバックされ、同じモードにおいてリトライしない理由が存在せず、従って、トランザクションは、前に実行していたモードで再実行される。理由９について、現在実行しているSTMトランザクションのグローバルカウンタは、メモリに保持される。新たなSTMトランザクションが開始するときは何時でも、このカウンタは（例えばInterlockedIncrement）インクリメントされ、STMトランザクションがロールバック／アボート／コミットするとき、（例えばInterlockedDecrementを介して）対応するデクリメントがカウンタで行われる。また、CRITMトランザクションは、STMトランザクションが開始したときは何時でも、全てのCRITMトランザクションがドゥーム処理され、CRESTMモードで再実行されるように、このグルーバルカウンタに関してモニタリングされる読取り（monitored read）を実行する。

【0060】

CRITMは、最も効率の良いモードであり、従って、CRITMトランザクションを積極的にドゥーム処理するこは、回避されることが求められる。１つのソリューションは、STMがまさに開始しようとしているときは何時でも、はじめに、システムが実行しているCRITMトランザクションを現在含んでいるかをチェックする。システムがCRITMトランザクションを含む場合、STMトランザクションは、開始前に有限の時間量について待つように制御される。係る待ち時間は、現在実行されているCRITMトランザクションがSTMトランザクションを過度に遅延することなしに実行を終了するのを可能にする。

【0061】

理由１０について、システムにおける全てのSTMトランザクションが終了するときは何時でも、１つの実現は、全てのCRESTMトランザクションをドゥーム処理し、それらをCRITMモードで再開することである。しかし、CRESTMトランザクションがドゥーム処理する前にまさに終了しようとしている場合に、スピンメカニズムが実行される場合がある。ここでの最終的な決定は、CRITMに比較してCRESTMのオーバヘッドに基づいており、平均で、CRESTMトランザクションはCRITMトランザクションと２倍を超えて遅い場合、CRESTMトランザクションをドゥーム処理し、それらをCRITMモードで再開することがより効率が良く、さもなければ、CRESTMモードで継続することがより効率が良い。更に他の実現では、CRESTMモードからCRITMモードに実行しているトランザクションを遷移することが可能である。

【0062】

有効なリード−ライト（r-w）又はライト−ライト（w-w）の競合は、バッファリングされた／モニタリングされたブロックで生じる。理由１０及び理由１１は、このカテゴリに属する。トランザクションがキャッシュラインでモニタリング又はバッファリングを失ったために、トランザクションがドゥーム処理される場合、トランザクションは、前と同じモードでリトライすることができる。ここでの１つの懸案事項は、あるキャッシュラインにアクセスしている新たなトランザクションが古いトランザクションをドゥーム処理する場合、古いトランザクションは、新たなトランザクションが再始動するときに新たなトランザクションをドゥーム処理する。これは、どちらのトランザクションも終了しないピンポン効果につながる。係る状況を扱うため、競合管理ロジックが使用される場合がある。

【0063】

幾つかの実現では、あるトランザクションがまさに実行を開始又は再開しようとしているときの最適化は、CRESTMモードで開始する必要がある理由が「システムが１以上のSTMトランザクションを含む」ことである場合、リトライの前に待つためにスピンメカニズムが使用される。待った後、STMトランザクションがなお実行されている場合、現在のトランザクションは、CRESTMモードで開始され、さもなければ、トランザクションは、CRITMモードで開始され、CRESTMオーバヘッドは、回避される。同様のロジックは、再始動しているCRESTMトランザクションに適用される。従って、先に説明において、トランザクションが同じモードで再始動されるべきとき、そのモードがCRESTMである場合に、はじめに、トランザクションがCRITMモードの下で実行することができるかが判定される場合があるという警告（caveat）が存在する。

【0064】

説明のため、CRESTMは、TVコード生成スタイル、例外に基づいたロールバックを使用する一方、CRITMは、NKコード生成スタイルを及びlongjmpに基づいたロールバックを使用する。

【0065】

レキシカルアトミックブロック（lexical atomic block）（一般に“s”と呼ばれる）がどのように変換されるかを考える。（この説明のため、あるトランザクションに関する全ての状態が現在のトランザクションオブジェクトにおいて保持され、トランザクションのコンテクストを無視するものと想定する。）“CreateTx”プリミティブは、“ConstantSiteId”を取り、固有の小さな、難解な整数IDは、語彙のトランザクションを識別する。このIDは、語彙のトランザクションに関する競合の管理情報を含むグローバルデータ構造に索引を作るために使用される。また、この構造は、どの実行モードにおいてトランザクションを開始すべきかを示す永続性のある情報を記憶するために使用される。プリミティブは、この情報をトランザクションの属性として設定する。

【0066】

以下、表３〜表５において、TMサポートコードへのコードブロックの３つの変換が与えられる。表３の擬似コードは、CRESTM及びSTMが実行モードのみであることを想定し、表４の擬似コードは、CRITMが実行モードのみであることを想定し、表５の擬似コードは、全ての３つの可能性を可能にすることを試みる。

【0067】

CRESTM及びSTMは、実行モードのみである場合、変換は、表３における擬似コードにおいて説明される。

【0068】

【表3】

表３において分かるように、トランザクションは、“createTx”プリミティブを使用して作成される。そのSiteIDは、現在使用しているトランザクションvtableを含む最初の属性のセットを決定する。全てのモードにおいて、ライブのローカル変数（又はまさにトランザクションにおいて変更される変数）は、スタックロケーションに保存される。その後、現在の実行モードがハードウェアアクセラレーションを使用している場合にハードウェアトランザクションが開始される。トランザクションが実行される。トランザクションがロールバックされる場合、catch節（catch clause）に到達する。それは、ハンドラの例外に基づくロールバックが発せられるためである。はじめに、ローカル変数の値が回復される。これは、ハンドラ（HandleEx）が（リターンにより）再実行するのを決定しようと、又はアボートするユーザ実行をマーシャリング（marshal）及びリスロー（rethrow）するのを決定しようと必要であり、ローカル変数は、スローされた例外を捕捉するcatch節においてライブ（live）である。ハンドラが再実行するのを決定した場合、ハンドラは、トランザクション“curtx”の属性を変更する。例えば、CRESTMの代わりにSTMを使用するためにトランザクションvtableを変える。

【0069】

CRITMが実行のみのモード（only execution mode）である場合、変換は、表４の擬似コードで説明される。

【0070】

【表4】

表４において分かるように、“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()テスト後に新たな実行モードを決定及びインストールすることであり、この可能性は、コメントを介して表４において示される。

【0071】

CRITM、CRESTM及びSTMモードの可能性を想定する結合された変換は、表５の擬似コードにおいて述べられる。

【0072】

【表5】

表５の擬似コードに関して、CRITMモードにおいて開始し、競合又はリソースの制限に遭遇し、CRESTMにおいて再実行するために競合の管理の決定をなし、さらに競合又はリソースの制限に遭遇し、及び従ってSTMにおいて今度は上手く再実行するトランザクションの実行を考える。

【0073】

ConstantSiteIdに関連する情報は、CRITMモードにおいてトランザクションがはじめに実行することができることを決定する。全てのモードにおいて、ライブの及び変更されたlocalsは、はじめに、スタックフレームにおいて変数をシャドウ（shadow）するために保存される（これが上位のトランザクションである場合、永続的にそのように行う）。LongjmpRollbackが真をリターンするように、トランザクションがセットアップされ、従ってsetjmp-equivalentを行う。前に記載されたように、（この例においてではない）これが再実行である場合、保存されたlocalsが回復される。次いで、ハードウェアトランザクションは開始され、SのSTM変換のCGSTYLE_NKバージョンが実行される。CRITM実行は、モニタリング又はバッファリングを失い、イジェクタに入り、従って現在のハードウェアトランザクションがアボートされる。

【0074】

トランザクションは、競合の管理の決定を行い、CRESTMモードにおいて再実行することを決定する。トランザクションは、トランザクションvtableを含めて、トランザクションの幾つかの属性を変更する。トランザクションは、保存されたレジスタの値を回復し、保存されたIPにジャンプし、従ってまるでSaveSetjmpStateがちょうどリターンされたかのように再始動する。（前に説明されたように、必要に応じて、イジェクタにおいて競合の管理の作業をせず、“IsRexec()”テスト後の新たな実行モードの設定を実行する。）
新たなハードウェアトランザクションが開始され、コードのCGSTYLE_TV変換が実行される。ある時点で、モニタリング又はバッファリングの損失が検出され、内部のReExecuteExceptionが生じ、従って例外のハンドラに到達し、それらのシャドウコピーからローカル変数が回復される。保存されたローカル変数の値が回復され、HandleExが呼び出され、HandleExは、生じた例外がReExecuteExceptionであることを判定する。ある時点で、例外を生じる前に、次の実行モードを決定する競合の管理の決定が行われ、現在のトランザクションの属性が適切に調節される。この場合、決定はSTMモードで再実行することであると想定する。再実行が生じたので、HandleExは、リレイジング（re-raising）ではなくリターンし、従って制御はラベルLを再びリターンする。この実行に関して、StartHWTxは、no-opである。これは、ハードウェアアクセラレーションが使用されず、ボディのCGSTYLE_TV変換及びSTMバリアが実行されたためである。今度は、トランザクションが成功し、コミットされる。

【0075】

表６は、本発明の実施の形態に係る、TM実行の様々な特性の比較を与える。

【0076】

【表6】

このように、様々な実施の形態では、暗黙的及び明示的なキャッシュ常駐、HASTM及びSTMを含めて、複数のモードでトランザクションを実行するため、スイッチングステートマシンが使用される。例えば、トランザクションは、CRITMで開始し、次いでオーバフローに関して切り替わる。さらに、幾つかのスレッドがSTMロックモードに入るときに、他のスレッドのトランザクションを切り替えることができる。決定論的なコミットの順序又はリトライのようなリッチなセマンティクス又は特徴に関する切り替えモードが行われる場合があり、STMスレッドが残されていないときに、CRITMモードへのスイッチバックを行うことができる。

【0077】

実施の形態は、ロギング又はシャドウコピーのバッファリングなしに、小さく簡単なトランザクションを効率的に実行するため、明示的なモニタリング及びバッファリング制御命令のUTMサポートを使用する一方、ソフトウェアのロッキング及びロギングの規律を使用する制限されないパブリケーション−プライバチゼーションが正確な（publication-privatization-correct）STM/HASTMトランザクションと正しく共存する。従って、UTMシステムは、高速なキャッシュ常駐のトランザクションがSTMトランザクション（更にはコア（cores）にスケジュールされないソフトウェアスレッドのトランザクション）を同時に実行するのを可能にする。ハードウェアインプリシットモードでは、特に管理されるコードについて、内部のランタイムデータ構造へのアクセス及びスタックは、キャッシュにより管理されるトランザクションのリード及びライトのセットに不必要に加わる。キャッシュモニタリング及びバッファリングのインストラクションファシリティ（instruction facilities）のCRESTMの暗黙的でないモードの（ソフトウェアによる）使用では、トランザクションは、トランザクションのセマンティクスを必要とするユーザデータのみをモニタ及びバッファリングする。スタック、CLRヘルパーコードへの滞在の間に生じるデータアクセス又はCLRランタイム自身は、キャッシュモニタリング及びバッファリングを使用せず、従って、立ち退き（容量ミス）に基づくキャッシュ常駐のトランザクションのアボートに寄与しない。

【0078】

先に記載されたように、トランザクションは、ハードウェアで実現されないキャッシュ容量又はセマンティクスの使用のため、HASTM又はSTMにフォールバックする前に、CRITM及びCRESTMのような様々なハードウェアアクセラレートモードで実行される。CRESTMにより、STM及びCRITMトランザクションの両者と相互運用することができる、キャッシュ常駐のSTMを順守する明示的なトランザクションのメモリモードが提供される。次いで、STMへのフォールバックが１つのトランザクションについて生じたとき、他のトランザクションは、CRESTMに切り替えることができるが、全てのトランザクションは、最も非効率なSTMモードにまで進む必要はない。同様に、アップグレードは徐々に行うことができ、最初に、STMトランザクションは、CRESTMモードにおけるシステムワークの残りの間で終了し、次いで、CRESTMトランザクションは、最も効率的なCRITMモードにおいてシステムの残りが既にある間に終了する。

【0079】

本発明の実施の形態に係るアクセラレートされたメモリバリアを使用して、実行の特性は、ライトログのオーバヘッドを除き、グローバルプールからタイムスタンプを割り当てるためにハードウェアトランザクションの必要を除き、CRESTMトランザクションの間、及びCRESTMとSTMトランザクションとの間の同時並行性を増加し、CRESTMトランザクションとSTMトランザクションとの間の競合に適応的に反応することで改善される。

【0080】

オブジェクトヘッダ（OH）は、CRITM及びCRESTMトランザクションモード内で使用される。これらのモードは、全てのOHの使用がTMの切り替えることができないとき、ハードウェアはオープンでネスト化されたトランザクションをサポートすることができないので、システムの他の部分により使用されるOHに関して比較及び保存（CAS：Compare And Save）プロトコルと相互作用する。OHへの所定の変更は永続性がある。ハッシュコード（HC）は、この観点で最も有名である。あるオブジェクトの安定したHCの要件は、SyncBlockIndex（SBI）への変更も永続性があることを更に含む。CRESTMについて、トランザクションがトランザクション・リード又はライトを使用してSyncBlock管理データ構造にアクセスしないため、抑圧（suppress）及び再入力（re-enter）する必要がない。トランザクション内で作成されたオブジェクトは、グローバルに見えないので、それらのヘッダへの変更もバッファリングされる。

【0081】

CRESTMのSTMとの相互運用性は、グローバルバージョンのクロックシステムにおけるロックに関するハードウェアモードを提供する。以下の最も重要な想定が行われる。パブリケーションの正確さ（publication correctness）を提供するためにグローバルバージョンのクロックスキームが使用され、プライバチゼーションの正確さ（privatization correctness）を提供するためにコミットチケットプロトコル及びバッファリングされたライトの幾つかの形式が使用され、ライトロックは、（例えばOpenForWrite()を介して）エンカウンタタイムで取得され、コミットチケットを取得した後に、楽観的なリードがコミットタイムで認証される。

【0082】

グローバルバージョンのクロックインテグレーションは、ハードウェアトランザクションにライトログを保持させることで、及び適切なコミットのフェーズの間にライト変数（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に関して存在することを意味する。

【0083】

このスキームは、ライトログを維持する必要のために乏しいパフォーマンスを有する。幾つかの実施の形態では、ライトログをもたないロックリスペクト（lock respecting without a write log）となるようにすることが可能であり、従ってライトログを保持する必要が除かれる。グローバルバージョンのナンバリングの実現の最適化は、２つの想定を使用して行われる。第一に、STMトランザクションよりもCRESTMトランザクションが遥かに多いことが想定され、第二に、実際のデータ衝突がまれであることが想定される。第一の想定は、あるトランザクションのSTMへのフォールバックが、他のトランザクションがSTMに移行することを必要としないという事実により動機付けされる。STMへのフォールバックはまれであって、従って「被害者」は１つのトランザクションである一方、他のトランザクションは、CRESTMで実行し続ける。十分に並列なシステムでは、これは、STMトランザクションよりも多くのCRESTMトランザクションが存在することを意味する。第二の想定は、作業負荷に依存するが、一般に良好な設計のホールマークであり、従って成功したプログラムにおいて普及している。

【0084】

CRESTMトランザクションは、ハードウェアグローバルバージョンナンバー（HGV）により示される共通のバージョン番号を使用し、トランザクションが変更しているオブジェクトをスタンプする。同時のCRESTMトランザクションによるライトが競合として正しく現れるように、STMトランザクションは、HGVがソフトウェアに基づくグローバルバージョンのナンバー（GV）よりも厳密に大きいことを保証する。HGVは、最大の同時並行性がデータの競合が生じない限り保証されるように、バッチで増加される。データの競合は、最も基本的なポリシーに退化させ、次いでより積極的なパスを徐々に再始動することで対処される。

【0085】

ライトログをもたないロックリスペクトとなるため、ハードウェアトランザクションにおいて以下の動作が行われる。GV及びHGVの両者が０で開始すると想定する。それぞれのハードウェアトランザクションは、はじめに、スタンプ値（SV）＝HGVを設定する。HGVは、モニタリングで読み取られ、従ってHGVに対する書き込みは、全てのハードウェアトランザクションをドゥーム処理する。ライトバリアは、例えばo.tmw=SVについてバッファリングされたライトを使用して、書き込みの前に実行され、TMWがモニタされる。リードバリアは、ロックされたビットがチェックされ、ロックが存在する場合に関数がアボートされる各読み取りの前に実行され、TWMは、モニタされ、トランザクションは、チケットプロトコルでコミットする。従って、ハードウェアトランザクションについて、暫定的に変化したオブジェクトのログは保持されず、代わりに、暫定的に変化しているオブジェクトは、HGVでスタンプされ、トランザクションがコミットした場合、タイムスタンプは、データの変化と共に永続的となる。

【0086】

それぞれのソフトウェアのトランザクションは、リード変数（RV）＝GVを設定する。（HGV<RV＋1）である場合、（CAS）（HGV，RV/*expected*/，GV＋1/*new*/）を比較及び設定する。ここでハードウェアが将来にスタンプすると、全ての現在のハードウェアトランザクションがドゥーム処理される。トランザクションの実行は、トランザクションがコミットする用意があるとき、例えばエンカウンタタイム等で取得されるロックといった、STMについてコンベンショナルである。ライト変数がインクリメント後のGVに等しいように、ライト変数（WV）が設定される。GVに対するインクリメントは、インフライトのハードウェアトランザクションがドゥーム処理され、このトランザクションがロールバックし、次いで再実行する場合に将来にスタンプされることを保証する。リードセットは、RVを使用して認証され、次いで全てのライトロックはWVを使用してリリースされる。ライトロックは保持されないが、マイナス面は、ソフトウェアトランザクションが別のソフトウェアトランザクションが終了した後に開始するたびに（コミット又はロールバックのため）、全てのハードウェアトランザクションがドゥーム処理されることである。この動作は、一度に１以上だけHGVを進めることで軽減される。例えば１０だけ進められる場合、全てのハードウェアトランザクションがドゥーム処理される前に幾つか他のソフトウェアトランザクションが終了した後に、更に１０のソフトウェアトランザクションが開始される。

【0087】

従って、ソフトウェアトランザクションが開始したとき、ソフトウェアトランザクションは、GVをサンプリングし、回収された値をローカル変数RVに記憶する。ソフトウェアトランザクションは、プログラムで指定されたようにリード及びライトに作用するように続行する。トランザクションがコミットする用意があるとき、GVは、はじめに、インクリメントがGVにHGVの値に到達させるかを判定するためにチェックされる。インクリメントがGVにHGVの値に到達させると判定した場合、HGVは、（その値は以下に記載される）量Bによりインクリメントされる。

【0088】

これらのルールは、競合が常に検出されることを保証するために必要な安全性を与える。一般に、競合の検出は、以下のように行われる。CRESTM対CRESTMの競合は、原データアクセス（raw data access）での競合としてハードウェアレベルで検出される。また、CRESTM対CRITMの競合は、原データアクセスでの競合としてハードウェアレベルで検出される。CRESTMトランザクションにより現在モニタ及び／又はバッファリングされているオブジェクトに対する競合するアクセスを偶然受けるSTMトランザクションは、CRESTMトランザクションにロールバックさせる。STMトランザクションによりアクセスされるデータを検証しているCRESTMトランザクションは、STMの検証フェーズの間までにSTMトランザクションにより検出される。オブジェクトにスタンプされたHGVがSTMトランザクションの開始で調べられるGVよりも必然的に大きい。

【0089】

上述されたように、Bの値又は「バッチサイズ」は、HGVがGVからそれるのを許容される量である。先に説明されたように、GVがHGVの値に到達するときは、HGVはBだけインクリメントされる。これが発生するときは何時でも、全ての現在実行されているCRESTMトランザクションは、これらのトランザクションがHGVの位置を関ししているのでロールバックされる。従って、Bが大きいと、係る検証が行われる頻度が少ない。他方で、ひとたびSTMトランザクションが現在のGVよりも大きいバージョン番号をもつオブジェクトを観察すると、その次の再実行に関して、STMトランザクションは、オブジェクトを上手く読み取ることができるのを保証するため、GVをその高い番号に進める必要がある。Bが大きい場合、バージョンスペースを通した係る「スキップ」により、バージョンスペースは高速に使い果たされ、これは、バージョンスペースが制限され、ラップアラウンドが費用がかかるシステムについて懸案事項である（たとえばヒープにおける全てのオブジェクトの番号を付け直す場合がある）。

【0090】

実施の形態は、異なるトランザクションによりアクセスされるデータがばらばらである限り、Bは大きくなることが許容されるが、シェアリングが検出されるとすぐ、Bの値が減少されるように、Bの値を調節する。このメカニズムにおける第一の要因は、効果的な検出方法である。すなわち、STMトランザクションは、「高い」HGV番号をもつハードウェアトランザクションにより生成された値を確かに読み取った高い確率で、区別することができる必要がある。これを実現するため、トランザクションは、オブジェクトが含むバージョンをGVに比較する。オブジェクトのバージョンが高い場合、オブジェクトは、HGVでスタンプされる。何れの場合であっても、トランザクションは、現在のGVよりも高いバージョン番号をもつオブジェクトを観察し、トランザクションは、該トランザクションが見た少なくともバージョンにGVを進める。

【0091】

競合の状況が対処されるとすぐ、Bの値は、（非常に大きなバージョン空間をもつシステムについて、これは大した懸念ではない場合があるが）係る状況の再発がバージョン空間の消費の観点でコストが低いことを保証するために低減される。「高速の圧縮（shrink）／低速の成長（growth）」を許容する任意のポリシーを許容可能である。例えば、競合の状況が検出されたときは何時でも、Bの値が半分にされるが、１よりも小さくされず、HGVをBだけ増加するときは何時でも、Bの値も同様に、例えば１といった固定された量により、予め決定された上限値にまでインクリメントされる。

【0092】

ここで図５を参照して、本発明の実施の形態に係る、ハードウェアトランザクションとソフトウェアトランザクションを同時に処理する方法のフローダイアグラムが示される。図５に示されるように、本方法５００は、ハードウェアトランザクションとソフトウェアトランザクションの両者についてコードパスを含む。はじめに、ハードウェアトランザクションに関して、HGVに等しいスタンプ値が設定される（ブロック５１０）。さらに、HGVがアップデートされるかについてハードウェアトランザクションが通知されるように、このスタンプ値のロケーションについてモニタリングが設定される（ブロック５１５）。ハードウェアトランザクションの実行の間、様々なリード及びライト動作が実行され、それらのそれぞれは、対応するリード又はライトバリアを使用して実現される。（ブロック５２０）。それぞれの係るバリアについて、例えば読取り又は書き込みされるロケーションに存在するロックのため、バリア処理が失敗したかが判定される（ひし形５２３）。バリア処理が失敗した場合、トランザクションがアボートされる（ブロック５３５）。所与のバリア処理が書き込み動作について成功した場合、書き込みデータは、バリアにおいて更新され、データは現在のHGVと関連される（ブロック５２５）。トランザクションの終わりで、HGVが変化したかが判定される（ひし形５３０）。HGVが変化した場合、これは、このハードウェアトランザクションとソフトウェアトランザクションとの間で競合が生じたことを示し、ハードウェアトランザクションはアボートする（ブロック５３５）。さもなければ、ブロック５４０に制御が進み、ブロック５４０で、それぞれ更新された値がメモリに記憶され、更新されたバージョン番号を示すためにHGVと関連付けされるように、アップデートがコミットされる。

【0093】

ソフトウェアトランザクションについて、最初に、現在のGVNに対応する読取り値が設定される（ブロック５５０）。次いで、この読取り値のインクリメントにより、結果がHGVの現在の値よりも大きくなるかが判定される（ひし形５５５）。結果がHGVの現在の値よりも大きくなる場合、HGVがアップデートされ、このアップデートにより、全ての保留のハードウェアトランザクションは、ドゥーム処理される。具体的には、ダイアモンド５５５からブロック５６０に制御が移り、HGV値は、適応的なバッチサイズBにより更新される。ダイアモンド５５５及びブロック５６０の処理は、アトミックにcompare-exchangeを行う命令を使用してハードウェアでアトミックに行われる。ダイアモンド５５５又はブロック５６０の何れかから、ブロック５６５に制御が移り、ブロック５６５で、STMトランザクションが実行される。一般に、任意の書き込まれた値のオーナシップを得るためにソフトウェアロックを使用して、様々なデータが読み取られ、処理が実行され、値が更新される。係る処理の終わりで、トランザクションはコミットする用意があるかが判定される（ひし形５７０）。トランザクションがコミットする用意がある場合、ブロック５７５に制御が移り、GVNがインクリメントされる（ブロック５７５）。１実施の形態では、このインクリメンとは１である。この更新されたGVNは、ソフトウェアトランザクションに関連する書き込み値に記憶される（ブロック５８０）。なお、ブロック５７５及び５８０の処理は、例えばGVNの新たな値を書き込み値に戻すアトミックにインクリメントを行う命令を使用して、ハードウェアでアトミックに行われる。次いで、全ての読取りオブジェクトが読取り値よりも小さいか又は読取り値に等しいバージョン値を有するかが判定される（ひし形５８５）。全ての読取りオブジェクトが読取り値よりも小さいか又は読取り値に等しいバージョン値を有さない場合、トランザクションは、アボートされる（ブロック５９５）。代わりにひし形５８５の検証が成功した場合、ブロック５９０に制御が進み、ブロック５９０で、トランザクションがコミットされ、書き込み値は、書き込みセットにおける全てのオブジェクトについて新たなバージョン番号として使用される。言い換えれば、書き込みセットにおけるオブジェクトのライトロック（write lock）は、これらにWVに等しい新たなバージョン番号を与えることでリリースされる。図５の実施の形態において特定の実現により示されているが、本発明の範囲は、この点に限定されない。

【0094】

コード生成は、互いにトランザクション実行モードになる２つの最も独立な判定に分解する。第一に、コード生成スタイルは、NK（NaKed）モード又はトランザクショナルVTable（TV）を使用して行われる。第二に、ロールバックメカニズムについて、トランザクションを再実行するために判定が行われたとき、行われる変更がどのようにロールバックされるか、トランザクションの開始に制御がどのように移されるかが決定される。

【0095】

コード生成スタイルについて、（同じシーケンシャルネストのメンバにより共有される）トランザクションコンテクスト構造は、トランザクションvtableと呼ばれるサブ構造で増大される。これは、そのエレメントが関数ポインタである構造であり、STMモードのSTM JITヘルパーのそれぞれの種類について１つである。他のモードは、トランザクションvtableを動的に変えることで、同じTV生成コードが複数のモードについて使用されるように作成される。

【0096】

トランザクションが不一致を検出するか又はアボートを明示的に検出したとき、全ての状態の変化がロールバックされ、トランザクションの開始に制御が戻る。CRESTM及び純粋なソフトウェアの例外に基づくメカニズムは、ロールバックを達成するために内部例外（internal exception）を引き起こす。この例外は、コード生成の間にトランザクションの変換の一部として挿入された例外を除いて、ハンドラにより捕捉することができない。

【0097】

トランザクションのネスト化が生じる場合がある。クロースのネスト化されたトランザクションの説明がはじめに与えられ、オープンのネスト化されたトランザクションの文脈でSuppressの動作が説明される。所与のハードウェアアーキテクチャは、ネスト化の任意の形式をサポートしない。代わりに、フラットモデルがサポートされる。フラットモデルがサポートされ、この場合、タッチされたキャッシュラインがバッファリング及びモニタリングされて、メモリにアトミックにコミットされるか、又はそれらの一時的な影響によりロールバックされ、トレースなしに消滅する。しかし、ネスト化されたトランザクションの失敗のアトミック性は、ネスト化されたトランザクションがロールバックした場合、その影響のみが取り消され、親のトランザクションの影響は（それでもまだ一時的に）保持される。

【0098】

平坦化は、最適化技術であり、トランザクションがロールバックする可能性がなく、従ってネスト化された取り消し情報の収集が行われないことを想定する。一般的なアルゴリズムは以下の通りである。ネスト化されたアトミックブロックに入ったとき、ネスト化された閉じたトランザクションがセットアップされ、try/catchブロックがその実行の周りに配置される。ネスト化されたトランザクションがコミットした場合、これはよくある例であり、親の実行が再開され、子供の影響は親に組み込まれ、それらを選択的に取り消す必要が決して生じない。他方で、ネスト化されたトランザクションコードが例外を処理するために拒否する（percolate）場合、真のネスト化のサポートをもつシステムにおいて、ネスト化されたトランザクションのみがロールバックされ、例外は、親の環境において再び現れる。子のトランザクションが独立にロールバックすることができない実現において、全体のトランザクションのネストは、ロールバックされ、真のネスト化をサポートするモードで再実行される。

【0099】

キャッシュ常駐のトランザクションのロールバックが行われる他の状況と同様に、以下のメカニズムが採用される場合がある。ネストのドゥーム判定が行われる時点で、何故トランザクションがロールバックされたか及びどのような種類の再実行が次に必要とされるかを本質的に示して、トランザクションのコンテクストに対して持続性書き込みが行われる。次いで、実行スタックがロールバックされ、全体のネストを囲んでいる例外のハンドラ（enclosing exception handler）は、例えば通常の例外を使用して実行される。平坦化の失敗からの回復は、HASTMモードにおける再実行により行われる。

【0100】

大まかに言えば、CRESTMは、小さく且つ簡単なトランザクションが、他の制限されないSTMトランザクションの存在下でさえ、ロッキング又はロギングなしに実行するのを可能にし、高速且つリッチ、フル機能、制限されたウィークリ・アトミック・コレクト（limited-weakly-atomic-correct）TMプログラミングモデルを全体として提供する。明示的なモードトランザクションの使用により、ソフトウェアは、プライベートキャッシュのUTMトランザクショナルファシリティの重要な制限された状態の使用を最適化することができ、これにより、STMに対してオーバフローする前に、トランザクションを長く及び大きく実行することができる。例えば、スタックアクセス及び新たに割り当てられたオブジェクトは、モニタリング又はバッファリングを必要としない。実施の形態は、制限されたウィークリ・アトミック・コレクトな実現（バッファリング、ロギング、ロッキング）の最大のオーバヘッドを加速するため、効果的なキャッシュ常駐モードを提供する。様々な実施の形態では、ソフトウェア命令は、所定のユーザプログラムのデータアクセスのみを明示的に処理する。

【0101】

実施の形態は、多くの異なるシステムタイプにおいて実現される。図６を参照して、本発明の実施の形態に係るシステムのブロック図が示される。図６に示されるように、マイクロプロセッサシステム１０００は、ポイントツーポイント相互接続システムであり、ポイントツーポイント相互接続１０５０を介して結合される第一のプロセッサ１０７０及び第二のプロセッサ１０８０を含む。図６に示されるように、プロセッサ１０７０及び１０８０のそれぞれは、マルチコアプロセッサであり、潜在的に多くのコアがプロセッサに存在するが、第一及び第二のプロセッサコア（すなわちプロセッサコア１０７４ａ及び１０７４ｂ、並びにプロセッサコア１０８４ａ及び１０８４ｂ）を含む。プロセッサコアは、効果的な制限されないトランザクションを可能にするため、ハードウェア、ソフトウェア、又はその組み合わせを使用してTMトランザクションを実行する。

【0102】

更に図６を参照して、第一のプロセッサ１０７０は、メモリコントローラハブ（MCH）１０７２及びポイントツーポイント（P-P）インタフェース１０７６及び１０７８を更に含む。同様に、第二のプロセッサ１０８０は、MCH１０８２及びP-Pインタフェース１０８６及び１０８８を含む。図６に示されるように、MCH１０７２及び１０８２は、プロセッサをそれぞれのメモリ、すなわち、それぞれのプロセッサにローカルに取り付けられる（例えばダイナミックランダムアクセスメモリ（DRAM）といった）メインメモリの一部であるメモリ１０３２及びメモリ１０３４に結合する。第一のプロセッサ１０７０及び第二のプロセッサ１０８０は、P-P相互接続１０５２及び１０５４をそれぞれ介してチップセット１０９０に結合される。図６に示されるように、チップセット１０９０は、P-Pインタフェース１０９４及び１０９８を含む。

【0103】

さらに、チップセット１０９０は、P-P相互接続１０３９により、チップセット１０９０を高性能グラフィックエンジン１０３８に結合するインタフェース１０９２を含む。チップセット１０９０は、インタフェース１０９６を介して第一のバス１０１６に結合される。図６に示されるように、様々な入力／出力（I/O）装置１０１４は、第一のバス１０１６を第二のバス１０２０に結合するバスブリッジ１０１８と共に第一のバス１０１６に結合される。様々な装置は、１実施の形態では、例えばキーボード１０２２、通信装置１０２６、及びコード１０３０を含むディスクドライブ又は他の大容量ストレージ装置のようなデータストレージユニット１０２８を含む。さらに、オーディオI/O１０２４は、第二のバス１０２０に結合される。

【0104】

実施の形態は、コードで実現される場合があり、命令を実行するようにシステムをプログラムするために使用される命令を記憶した記憶媒体に記憶される。記憶媒体は、限定されるものではないが、フロプティカルディスク、光ディスク、固体ドライブ（SSD）、コンパクトディスクリードオンリメモリ（CD−ROM）、コンパクトディスクリライタブル（CD-RW）、及び光磁気ディスクを含む何れかのタイプのディスク、リードオンリメモリ（ROM）、ダイナミックランダムアクセスメモリ（DRAM）のようなランダムアクセスメモリ（RAM）、スタティックランダムアクセスメモリ（SRAM）、消去可能なプログラマブルリードオンリメモリ（EPROM）、フラッシュメモリ、電気的消去可能なプログラマブルリードオンリメモリ（EEPROM）のような半導体装置、磁気又は光カード、或いは電子的な命令を記憶するために適した他のタイプの媒体を含む。

【0105】

本発明は制限された数の実施の形態に関して記載されたが、当業者であれば、これらの実施の形態から様々な変更及び変形を理解されるであろう。特許請求の範囲は、本発明の真の精神及び範囲に含まれるものとして全ての係る変更及び変形をカバーすることが意図される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】