JP2007520769A - モニタメモリ待機を用いたキューされたロック - Google Patents

Abstract

モニタ−メモリ待機を用いてロックを監視する方法、装置及びシステムが提供される。一実施例によると、競合するロックに係るノードが監視され、競合するロックを求めるプロセッサは、モニタイベントが発生するまでスリープ状態にされる。

Description

発明の詳細な説明

［発明の技術分野］
本発明は、プロセッサに関し、より詳細には、１以上のプロセッサが利用可能となるまでロックを待機するため、ロックを監視するためのモニタメモリ待機を利用することに関する。
［関連技術の説明］
典型的には、ハイパースレッドまたはマルチスレッドプロセッサは、複数の命令シーケンスを同時処理することが可能である。１つのプロセッサ内での複数の命令シーケンスの実行を促進する主要な動機要因は、結果としてのプロセッサ利用性の向上である。ハイパースレッドプロセッサは、複数の命令ストリームが各実行リソースにおいて当該リソースをより良好に利用するため同時に実行することを可能にする。さらに、ハイパースレッドプロセッサは、大きな遅延に直面するか、あるいはしばしばイベントの発生を待機するプログラムに利用可能である。

典型的には、ハイパースレッドプロセッサは、すべてのスレッドまたは論理プロセッサ（プロセッサ）により共有される１つのリソース設定を有する。特に１以上のプロセッサがロックが利用可能になるのを待機しているとき、適切なリソースを有しないことは、プロセッサ間の重大なコンテンションを引き起こすかもしれない。プログラム処理効率及び複数のプロセッサ間のロックコンテンションを処理する他のリソースを消費する遅延を改善するいくつかの技術が提案されてきている。例えば、従来のＳｐｉｎ−Ｗａｉｔｉｎｇロックシステムでは、待機リストのロックが利用可能となるまで待機するため、ロック待機するプロセッサを待機リストに置くための待機キューが用いられる。しかしながら、当該待機中、プロセッサはロックのメモリ位置に連続的にアクセスし、当該メモリ位置でのメモリコンテンション、リソースのボトルネック、及びメモリ帯域幅、計算帯域幅、マイクロアーキテクチャリソース及び電力の浪費を引き起こす。このような「ビジー待機」プロセッサは、他のプロセッサのパフォーマンスに対して悪影響を及ぼし得る。
［詳細な説明］
ロックを待機する１以上のプロセッサのためロックを監視する方法及び装置が、説明される。概略的には、本発明の実施例は、ロックが利用可能となるまでロックを待機する１以上のプロセッサのため、ロックを監視するモニタメモリ待機を使用する。

ロックがプロセッサに利用可能になるなど、モニタイベントが発生するまで他のプロセッサと競合するロックを取得するため、プロセッサをスリープ状態にするシステム、装置及び方法が提供される。すなわち、プロセッサはロックが利用可能となるのを待機しているが、キューへの待機中にはスリープ状態となるようにしてもよい。一実施例によると、プロセッサをスリープ状態にする選択肢は、プロセッサがそれのリソースを解放し、他のプロセッサによる使用のため解放されたリソースを提供することを含む。一実施例によると、ロックを求めるプロセッサは、ハイパースレッドプロセッサの論理プロセッサであってもよい。典型的なハイパースレッドプロセッサは、同一のリソースを共有する論理プロセッサまたは複数のスレッドを含むものであってもよい。

一実施例によると、競合するロックを監視し、例えばロックが利用可能となるまでプロセッサをスリープ状態にするため、モニタメモリ待機（ｍｏｎｉｔｏｒ−ｍｗａｉｔ）機構が利用されてもよい。競合するロックは、１以上のプロセッサが取得要求または待機するロックを参照するものであってもよい。一実施例によると、プロセッサに対応して、ノードまたはキュー要素（ノード）が生成されてもよい。一実施例によると、ｍｏｎｉｔｏｒ−ｍｗａｉｔを用いて、ノードは初期化、競合するロックとの関連付け、及び監視されるようにしてもよい。ノードの監視は、例えば、モニタアドレスと呼ばれるロックのロックアドレスを監視することによって、ロックを監視することを含む。

一実施例によると、１以上のイベント、または設定時間はモニタイベントと呼ばれ、モニタイベントの発生により、ノードの監視が終了し、プロセッサはアウェイクしてもよい。例えば、ロック及びロックの利用性を要求するため、キューの次にプロセッサを有することは、モニタイベントと呼ばれてもよい。言い換えると、プロセッサが競合するロックを受付けるため列の次（または最初）にあって、ロックが利用可能になると、プロセッサはロックを要求し、以前に解放したリソースの一部またはすべてを再要求するかもしれない。一実施例によると、競合するロックは、当該ロックを所持する他のプロセッサにより解放されると利用可能になるかもしれない。

一実施例によると、ｍｏｎｉｔｏｒ−ｍｗａｉｔは、他のプロセッサに処理リソースを使用させながら、１つのスレッドまたはプロセッサにおいて実現されてもよい。例えば一実施例によると、プロセッサが、指定されたメモリ位置への書き込みなど特定のメモリアクセスが発生するまでスリープ状態とされるように、モニタは設定されてもよい。プロセッサは、指定されたイベントに応答して、プロセッサリソースを浪費するルーチンを実行することなくアウェイクされてもよい。一実施例によると、現在スリープ状態のプロセッサに以前は専用されていたパーティションは、プロセッサがまだスリープ状態にありながら解放されてもよい。本発明の上記及び／または他の実施例は、マシーンの全体的スループットをやや向上させるかもしれない。

以下の説明では、論理実現形態、オペコード、リソースパーティション、リソース共有、リソース重複実現形態、システムコンポーネントのタイプ及び相互関係、及び論理パーティション／統合選択などの多数の具体的詳細は、本発明の各種実施例のより完全なる理解を提供するため与えられる。しかしながら、本発明の実施例が与えられた開示に基づきそのような具体的詳細なく実現可能であるということは、当業者には理解されるであろう。他の例では、制御構成、ゲートレベル回路及びフルソフトウェア命令シーケンスは、本発明を不明りょうにしないように示されていない。含まれている説明により、当業者は、過度の実験なく適切な機能を実現することができるであろう。

本発明の実施例の各ステップが、以下において説明される。これら実施例の各ステップは、ハードウェアにより実行されてもよいし、あるいは、プログラムされた汎用または特定用途プロセッサまたはマシーンや論理回路に各ステップを実行させるのに用いられるマシーン実行可能命令により実現されてもよい。あるいは、実施例の各ステップは、ハードウェアとソフトウェアの組み合わせにより実行されてもよい。

本発明の各種実施例が、コンピュータ（または他の電子装置）に本発明の各種実施例によるプロセスを実行するようプログラムするのに用いられる命令を格納した機械可読媒体を有するコンピュータプログラムプロダクツとして提供されてもよい。機械可読媒体は、以下に限定するものではないが、フロッピー（登録商標）ディスケット、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、フラッシュメモリ、あるいは電子命令を格納するのに適した他のタイプの媒体／機械可読媒体を含むものであってもよい。さらに、本発明の各種実施例はまた、搬送波に実現されるデータ信号、または通信リンク（モデムまたはネットワーク接続など）を解した他の伝搬媒体により、リモートコンピュータから要求元コンピュータに伝送可能なプログラムを有するコンピュータプログラムプロダクツとしてダウンロードされてもよい。

図１は、メモリアクセスモニタ１１０を有するハイパースレッドプロセッサ１００の実施例を示すブロック図である。一実施例によると、プロセッサ１００は、単一の集積回路として形成されてもよい。他の実施例によると、複数の集積回路からプロセッサ１００が形成されてもよく、またさらなる他の実施例では、ハードウェア及びソフトウェアルーチン（バイナリ変換ルーチン）からプロセッサ１００が形成されてもよい。図示されるように、バス／メモリコントローラ１２０が、フロントエンド１３０に実行命令を与えるようにしてもよい。フロントエンド１３０は、命令ポインタ１７０により各種スレッドからの命令の抽出を指示するかもしれない。命令ポインタ論理が、複数のスレッドをサポートするよう複製されてもよい。

一実施例によると、フロントエンド１３０は、さらなる処理のため、命令をスレッド／プロセッサパーティション可能リソース１４０に供給するかもしれない。スレッド／プロセッサパーティション可能リソース１４０は、複数のスレッドがプロセッサ１００内でアクティブ状態であるとき、特定スレッドに専用とされる論理分離されたパーティションを有するようにしてもよい。一実施例によると、独立した各パーティションは、当該パーティションが専用とされるスレッドからの命令のみを有するようにしてもよい。スレッド／プロセッサパーティション可能リソース１４０は、例えば、命令キューを備えるようにしてもよい。シングルスレッドモードにおいて、スレッド／プロセッサパーティション可能リソース１４０のパーティションは、当該１つのスレッドに専用とされる単一の大きなパーティションを形成するよう合成されてもよい。

一実施例によると、プロセッサ１００はまた、複製された状態１８０を有するようにしてもよい。複製状態１８０は、論理プロセッサに対してコンテクストを維持するのに十分な状態変数を有するものとされてもよい。複製状態１８０により、複数のスレッドが状態変数ストレージの競合なく実行されるかもしれない。さらに、レジスタ割当論理が、各スレッドに対して複製されてもよい。複製状態に関する論理は、実行用に入力された命令を準備するため、適切なリソースパーティションにより動作可能である。

一実施例によると、スレッド／プロセッサパーティション可能リソース１４０は、共有リソース１５０に命令をわたす。共有リソース１５０は、各自のソースに関係なく命令に対して動作する。例えば、スケジューラ及び実行ユニットは、スレッドに認識されていない共有リソースであってもよい。パーティション可能リソース１４０は、アクティブ状態の各スレッドに対する継続された進捗を提供する公平な方法によりスレッド間を交代することによって、複数のスレッドから共有リソース１５０に命令を供給する。従って、共有リソース１５０は、スレッドの混合を気にすることなく、適切な状態において与えられた命令を実行する。

一実施例によると、他のスレッド／プロセッサパーティション可能リソース群１６０が共有リソース１５０に続くかもしれない。スレッド／プロセッサパーティション可能リソース１６０は、リオーダバッファなどのリタイアメントリソースを有するようにしてもよい。従って、スレッド／プロセッサパーティション可能リソース１６０は、各スレッドからの命令の実行が適切に終了し、当該スレッドの適切な状態が適切に更新されることを保証する。

一実施例によると、プログラマーには、メモリ位置の定期的ポーリングまたは命令の実行さえ必要とすることなく、モニタメモリ待機の機能を実現する機構が設けられてもよい。例えば、プロセッサ１００は、メモリアクセスモニタ１１０を有するようにしてもよい。メモリアクセスモニタ１１０は、メモリアクセスモニタ１１０が観察可能なメモリアクセスサイクルに関する情報によりプログラム可能であってもよい。従って、メモリアクセスモニタ１１０は、比較論理１１４によりバス／メモリコントローラ１２０から受信するバスサイクル情報と比較されるモニタサイクル情報レジスタ１１２を有するようにしてもよい。一致が発生すると、回復スレッド信号が、停止されているスレッドを再開するのに生成される。メモリアクセス情報が、プロセッサの内部及び／または外部バスから取得されてもよい。

モニタサイクル情報レジスタ１１２は、スレッドの再開をトリガーするアドレス及び／またはサイクルタイプを指定する詳細を有するようにしてもよい。一実施例によると、モニタサイクル情報レジスタ１１２は物理的アドレスを格納し、メモリアクセスモニタ１１０は、当該物理的アドレスへの実際または潜在的書き込みを示す任意のバスサイクルを待機する。このようなサイクルは、明示的な書き込みサイクルの形態をとるものであってもよいし、及び／または、外部バストランザクションなしにキャッシュ可能ラインに書き込みされるように、当該ラインの排他的所有を他のエージェントが試みることにより無効なサイクルまたは所有に対する読み込みであってもよい。メモリアクセスモニタ１１０は、各実施例の各種トランザクションに対してトリガーするようプログラムされてもよい。

図２は、ハイパースレッドプロセッサの動作の実施例を示すフロー図である。図１の各種実施例の動作が、図２のフロー図を参照してさらに説明される。一実施例によると、プロセッサ１００の命令セットは、モニタトランザクション情報を設定するためのＭＯＮＩＴＯＲオペコード（命令）を有するようにしてもよい。処理ブロック２００において、ＭＯＮＩＴＯＲオペコードは、第１スレッド（Ｔ１）の命令シーケンスの一部として受信される。処理ブロック２１０において、ＭＯＮＩＴＯＲオペコードに応答して、プロセッサ１００は、メモリアクセスモニタ１１０が指定されたメモリアクセスに対するメモリアクセスを監視することを可能にする。トリガーされたメモリアクセスは、明示的または非明示的オペランドとして予めレジスタまたは他の位置に格納されてもよい。従って、ＭＯＮＩＴＯＲオペコードの実行は、モニタアドレスが非明示的オペランドとしてレジスタまたは他の位置に予め格納されるとき、モニタアドレスを指定する。メモリアクセスモニタ１１０は、指定されたサイクルが判定ブロック２１５において検出されるかテストする。指定されたサイクルが検出されない場合、メモリアクセスモニタ１１０は、メモリアクセスの監視を継続する。トリガーされたサイクルが検出されると、モニタイベント保留標識が、処理ブロック２２０において設定される。

一実施例によると、ＭＯＮＩＴＯＲオペコードの実行が、メモリアクセスモニタ１１０の起動をトリガーするかもしれない。メモリアクセスモニタ１１０は、プロセッサ１００の他の動作とパラレルに実行開始する。一実施例によると、ＭＯＮＩＴＯＲ命令自体のみが、適切なメモリサイクル情報によりメモリアクセスモニタ１１０を設定し、非マスク状態のモニタイベントなしにメモリアクセスモニタ１１０を起動する。言い換えると、ＭＯＮＩＴＯＲオペコードの実行後、モニタイベントが発生するが、それらが明示的に非マスク状態とされていない場合には、認識されることはない。

処理ブロック２２５において、メモリ待機（ｍｗａｉｔ）のトリガー処理は、独立したイベントとして示されている。一実施例によると、ＭＷＡＩＴオペコードは、モニタイベントの認識及びＴ１の一時停止をトリガーするのに利用可能である。独立した２つの命令を用いてスレッドの一時停止を設定及びトリガーすることは、プログラマーに付加的なフレキシビリティを提供し、より効率的なプログラミングを可能にするかもしれない。他の実施例によると、ｍｗａｉｔは、メモリアクセスモニタ１１０を設定する第１オペコードからトリガーされてもよい。何れのケースでも、１以上の命令がメモリアクセスモニタ１１０を準備し、モニタイベントの認識を可能にする。

一実施例によると、独立したオペコードがメモリアクセスモニタ１１０を準備し、モニタイベントの認識をトリガーするのに利用される場合、判定ブロック２３０において、メモリアクセスモニタ１１０がスレッドの一時停止前に起動されたことを確認するためテストが行われてもよい。さらに、モニタイベントがすでに保留されているかテストすることにより（図示せず）、Ｔ１の一時停止は回避され、処理は処理ブロック２５０に続く。モニタ１１０がイネーブルとされ、モニタイベントがすでに保留されていない場合、Ｔ１が処理ブロック２３５において一時停止される。

Ｔ１が一時停止されるとことにより、一実施例によると、プロセッサ１００は、Ｔ１に専用とされるパーティション可能リソース１４０及び１６０のパーティションの一部またはすべてを解放するようにしてもよい。他の実施例によると、ＭＯＮＩＴＯＲオペコードの各組み合わせ、またはそれに関する設定が、あるとすれば解放するリソースを示すようにしてもよい。例えば、プログラマーがより短時間の待機を予想するとき、スレッドは一時停止されるが、それのリソースパーティションを維持するようにしてもよい。共有リソースはスレッド停止期間中に他のスレッドにより排他的に利用可能であるため、スループットは依然として向上される。長時間の待機が予想されるとき、停止されているスレッドに関するすべてのパーティションを解放することは、他のスレッドが追加的リソースを有することを可能にし、これにより、その他のスレッドのスループットが潜在的に増大することとなる。この追加的スループットは、スレッドがそれぞれ一時停止及び再開されるとき、消去及び追加されたパーティションに関するオーバヘッドのコストを犠牲にして行われるかもしれない。

一実施例によると、Ｔ１は、モニタイベントが保留されている間、一時停止状態に留まるかもしれない。前述のように、メモリアクセスモニタ１１０は、モニタイベントを検出及び通知するため、独立に動作するようにしてもよい（ブロック２１５−２２０）。プロセッサ１００によりモニタイベントが判定ブロック２４０において保留されていることが検出されると、処理ブロック２５０においてＴ１が再開される。モニタイベントがＴ１をウェークアップするのに、Ｔ１においてアクティブ状態の命令処理が行われる必要はない。むしろ、Ｔ１は一時停止されたままとされ、イネーブルにされたメモリアクセスモニタ１１０がプロセッサ１１０にイベントを通知するようにしてもよい。プロセッサ１００は、当該イベントを処理し、Ｔ１を示すイベントが再開されるべきであることを認識し、Ｔ１を再開するため適切なアクションを実行する。

図１及び２の実施例は、プログラムにより一時停止されたスレッドが指定されたメモリアクセスの発生により再開されるのを可能にする技術を提供する。一実施例によると、他のイベントがＴ１を再開させてもよい。例えば、割り込みがＴ１を再開させるようにしてもよい。このような実現形態は、メモリアクセスモニタ１１０が特定のメモリアクセスまたはスレッドを再開させるべき他の状態を見落とす（検出しない）可能性があるため、メモリアクセスモニタ１１０が完全未満であることを許容する。この結果、Ｔ１はときどき不必要にアウェイクされるかもしれない。しかしながら、このような実現形態は、Ｔ１が見逃したイベントにより永久的にフリーズする確率を低下させ、ハードウェア構成及び有効性が簡単化される。Ｔ１の不必要なアウェイク動作は、利便性に関しては些細なものであるかもしれない。なぜならば、アウェイクした条件が真に発生したか、そしてもう一度一時停止していないかＴ１にダブルチェックさせるため、ループが構成されているためである。

一実施例によると、スレッド／プロセッサパーティション可能リソース、複製リソース、及び共有リソースは、異なって構成されてもよい。一部の実施例では、共有ソースの両端にはパーティション可能リソースがなくてもよい。一実施例によると、スレッド／プロセッサパーティション可能リソースは、厳密にはパーティションされず、一部の命令は複数のパーティションにわたるようにすることも可能であり、あるいは当該パーティションで実行されているスレッドまたは実行されているスレッドの合計に依存してサイズを可変とすることも可能である。さらに、異なるリソースの組み合わせが、共有、重複及びスレッドパーティションリソースとして指定されてもよい。

図３は、ハイパースレッドプロセッサの実施例を示すブロック図である。図示されるように一実施例によると、図３は、特にコヒーレンシー関連論理３５０、一実現形態によるモニタ３１０、及び一実現形態によるスレッド一時停止／再開及びプロセッサスリープ／アウェイク論理３７７を有する。一実施例によると、バスインタフェース３００は、バスコントローラ３４０、イベント検出論理３４５、モニタ３１０及びコヒーレンシー関連論理３５０を有する。

一実施例によると、バスインタフェース３００は、マイクロ命令からｕＯＰ（マイクロオペランド）を生成するｕＯＰ生成を実行するフロントエンド３６５に命令を与える。実行リソース３７０は、フロントエンド３６５からｕＯＰを受け取り、実行後バックエンド論理３８０が各種ｕＯＰをリタイアする。一実施例によると、アウト・オブ・オーダ実行が、フロントエンド、バックエンド及び実行リソースによりサポートされる。

一実施例によると、ＭＯＮＩＴＯＲオペコードがバスインタフェース３００を介しプロセッサに入力され、フロントエンド３６５による実行のため用意されてもよい。一実施例によると、実行リソース３７０による実行のため、特殊なＭＯＮＩＴＯＲ ｕＯＰが生成されてもよい。ＭＯＮＩＴＯＲ ｕＯＰは、アドレス変換論理３７５によりモニタ３１０に提供される物理的アドレスに変換されるモニタアドレスにより、実行ユニットによるストア動作と同様に処理されてもよい。モニタ３１０は、スレッドを再開させるため、スレッド一時停止／再開及びプロセッサスリープ／アウェイク論理３７７と通信する。スレッドは、アクティブなスレッド数が変化すると、パーティションを実行し、リソースをアニールするため、論理を一時停止及び再開する。

例えば、図４は、リソースのパーティション、共有及び複製のための処理の実施例を示すブロック図である。一実施例によると、パーティションされたリソースは、マシーンのアクティブなスレッドのフローに従ってパーティション及びアニール（他のスレッドに拠る再利用のため合成される）されてもよい。一実施例によると、複製リソースは、パイプラインの命令フェッチ部分４０５に命令ポインタ論理、パイプラインのリネーム部分４１５にレジスタリネーミング論理、状態変数（図示せず）及び割込みコントローラ（図示せず）を有するようにしてもよい。一実施例によると、共有リソースは、パイプラインのスケジュール段階４２５にスケジューラ、パイプラインのレジスタリード部分４３０とレジスタライト部分４４５にレジスタ群、及びパイプラインの実行部分４３５に実行リソースを有するようにしてもよい。さらに、トレーズキャッス（Ｉ−フェッチ４０５に）とＬ１データキャッシュ（Ｌ１キャッシュ４４０に）は、スレッドコンテクストに関係なくメモリアクセスにより集められた共有リソースであってもよい。他の実施例によると、スレッドコンテクストの考慮が、キャッシュ処理判断に利用されてもよい。一実施例によると、パーティションリソースは、パイプラインのキュー処理段階４１０に２つのキュー、パイプラインのリタイアメント段階４５０にリオーダバッファ、及びストアバッファを有するようにしてもよい。スレッド選択多重化論理が、適切なアクセスを両方のスレッドに提供するため、各種重複リソースとパーティションリソースの間で交代される。

例示のため、図４に示されるように、パーティション、共有及び重複処理は、図３のプロセッサの実施例の動作のさらなる説明において、図３の実施例に関して利用されてもよい。特に、図３の実施例の動作のさらなる詳細が、図５のフロー図に関して説明される。プロセッサは、少なくとも２つのアクティブ状態のスレッドによるマルチスレッドモードにより実行されると仮定する。

図５は、スレッドの一時停止及び再開を行うためのプロセスの実施例を示すフロー図である。処理ブロック５００において、フロントエンド３６５は、第１スレッド（Ｔ１）の実行中にＭＯＮＩＴＯＲオペコードを受け取る。一実施例によると、フロントエンド３６５は、特殊なモニタｕＯＰを生成する。ＭＯＮＩＴＯＲ ｕＯＰは、実行リソース３７０にわたされる。ＭＯＮＩＴＯＲ ｕＯＰは、監視対象となるアドレスを示す関連するアドレス（モニタアドレス）を有するようにしてもよい。この関連するアドレスは、明示的亜オペランドまたは非明示的オペランドの形態をとるものであってもよい。（すなわち、関連するアドレスは、所定のレジスタまたは他の格納位置から取得される。）関連するアドレスは、それがモニタアドレスを決定するのに十分な情報を伝達するという点で、モニタアドレスを「示す」かもしれない（おそらく他のレジスタおよび情報と共に）。例えば、関連するアドレスは、適切なモニタアドレスである対応する物理的アドレスを有するリニアアドレスであってもよい。あるいは、モニタアドレスは仮想的アドレスフォーマットにより与えられてもよく、または、相対アドレスとして示されてもよく、または、他の既知または便利なアドレス指定方法により指定されてもよい。仮想アドレスオペランドが使用される場合、一般的な保護エラーがブレークイベントとして認識されるのを可能にすることが望ましい。

モニタアドレスは、モニタリング用のメモリの任意の有用なユニットを示すものであってもよい。例えば一実施例によると、モニタアドレスはキャッシュラインを示すものであってもよい。しかしながら、他の実施例によると、モニタアドレスはキャッシュラインの一部、各プロセッサのキャッシュラインサイズに対する書く関係を保持するメモリのユニットまたは指定／選択されたサイズ部分、あるいは１つのアドレスを示すものであってもよい。モニタアドレスは、オペランドにより指定されたデータ（及びさらなるデータ）を含むユニットを示し、あるいは、所望のデータユニットに対するアドレスを具体的に示すものであってもよい。

一実施例によると、図３の図を用いて、モニタアドレスがアドレス変換論理３７５に提供され、モニタアドレスレジスタ３３５に格納される場合には、モニタ３１０にわたされる。ＭＯＮＩＴＯＲオペコードに応答して、実行リソース３７０は、処理ブロック５１０に示されるように、モニタ３１０をイネーブル及び起動するようにしてもよく、図６においてさらに説明される。一実施例によると、ＭＯＮＩＴＯＲオペコード後に発生する任意のストア動作は、ストアが処理され、スレッド一時停止の発生前に検出されることを保証するため制限されるようにしてもよい。一実施例によると、一部の動作は以降の命令が実行可能となる前にモニタ３１０を起動した結果として行われる必要がある。しかしながら、処理ブロック５１０は処理ブロック５０５とパラレルに実行されるよう図示されている。なぜなら、一実施例によるＭＯＮＩＴＯＲオペコードにより起動されると、ブレークイベントが発生するまで他の動作とパラレルにモニタ３１０が動作を継続するためである。

処理ブロック５０５において、ＭＥＭＯＲＹ ＷＡＩＴ（ＭＷＡＩＴ）オペコードが、スレッド１で受信される。一実施例によると、ＭＷＡＩＴオペコードは、モニタイベントをマスク解除するため実行されてもよい。ＭＷＡＩＴオペコードに応答して、モニタイベントが保留中であるか判断するため、処理ブロック５１５においてテストが実行される。モニタイベントが保留中でない場合、モニタがアクティブ状態であるか判断するため、処理ブロック５２０においてテストが実行される。例えば、ＭＷＡＩＴがＭＯＮＩＴＯＲを以前に実行することなく実行される場合、モニタ３１０はアクティブ状態でないかもしれない。モニタがアクティブ状態でないか、あるいはモニタイベントが保留中である場合、スレッド１の実行は処理ブロック５６５において継続される。

一実施例によると、モニタ３１０がアクティブ状態であり、保留中のモニタイベントがない場合、スレッド１の実行は処理ブロック５２５において一時停止される。スレッド一時停止／再開論理３７７は、処理ブロック５３０において、すべての命令をクリアするため、プロセッサパイプラインを排出するためのパイプラインフレッシュ論理３８２を有するようにしてもよい。パイプラインが排出されると、パーティション／アニール論理３８５は、処理ブロック５３５において、スレッド１に排他的に関連付けされた任意のパーティションリソースを他のスレッドによる利用のため解放させるようにしてもよい。これら解放されたリソースは、残りのアクティブ状態のスレッドが利用するより大きなリソースを構成するためアニール処理されてもよい。例えば、図４の２スレッドの例を参照するに、スレッド１に関するすべての命令は、両方のキューから排出される。キューの各ペアは、より大きなキューを第２スレッドに与えるため合成されてもよい。同様に、レジスタプールからのさらなるレジスタが、第２スレッドに利用可能とされ、ストアバッファからのさらなるエントリが、第２スレッドに対し供給され、リオーダバッファのさらなるエントリが、第２スレッドに利用可能とされてもよい。基本的に、これらの構成は２倍のサイズの単一の専用の構成に戻される。異なる個数のスレッドを用いた実現形態から生じる異なる比率が考慮される。

一実施例によると、処理ブロック５４０、５４５及び５５０において、各種イベントは、スレッド１が再開されてもよいか判断するためテストされる。特に、これらのテストは、スレッド１の一部として命令が実行されることにより実行されなくてもよい。むしろ、これらの処理は、他のスレッドのそれの処理とパラレルに、プロセッサにより実行されてもよい。図６に関して詳細に説明されるように、モニタ自体が、モニタライトイベントが発生したかチェックし、イベント保留標識を設定することによりこれを示す。イベント保留標識は、ＥＶＥＮＴ信号を介し一時停止／再開論理３７７（マイクロコードなど）に提供されてもよい。マイクロコードは、処理ブロック５０５において、モニタイベントがＭＷＡＩＴオペコードによりマスク解除されたため、一実施例において適切な命令境界でモニタイベントを認識するかもしれない（ブロック５４０）。イベント検出論理３４５は、処理ブロック５４５において、ブレークイベントとして指定される割込みなどの他のイベントを検出する。さらに一実施例によると、処理ブロック５５０において、プロセッサがあるイベントシーケンスによりフリーズしないことを保証するため、メモリ待機状態から抜け出すため任意的なタイマーを定期的に利用するようにしてもよい。これらのイベントの何れもがｍｗａｉｔ状態への脱出を通知しない場合、スレッド１は一時停止されたままである。

一実施例によると、スレッド１が再開される場合、スレッド／一時停止再開論理３７７は、適切なイベントを検出することにより再び起動されてもよい。再び、パイプラインが処理ブロック５５５においてフラッシュされ、リソースがまもなくアウェイクされるスレッド１を収容するよう再びパーティション可能となるように、パイプラインから命令を排出する。処理ブロック５６０において、適切なリソースが再パーティションされ、スレッド１が処理ブロック５６５において再開されてもよい。

図６は、論理のモニタリングの起動及び動作のためのプロセスの実施例を示すフロー図である。処理ブロック６００において、スレッド１のフロントエンドフェッチ処理は、さらなるスレッド１の処理がマシーンに入力されるのを防ぐため停止される。処理ブロック６０５において、関連するアドレスオペランドが、リニアアドレスから物理的アドレスにアドレス変換論理３７５により変換される。処理ブロック６１０において、監視されているブロックへの書き込みの観察可能性は増大し、おそらく、モニタ３１０自体が見ることが可能なモニタアドレスに格納されている情報に影響を与えるライト動作をキャッシュ処理エージェントに実行させる。処理ブロック６１５において、モニタリングのための物理的アドレスが、当該シーケンスの以前または以降において格納される。

次に一実施例によると、処理ブロック６２０において、モニタがイネーブルとされる。モニタは、バスがモニタアドレスレジスタ３３５に格納されているモニタアドレスである物理的アドレスへの書き込みのためサイクルしていることを監視する。モニタリング動作のさらなる詳細は、図７に関して後述される。モニタがイネーブルとされた後、一実施例によると、ストアフェンス（ｓｔｏｒｅ ｆｅｎｃｅ）動作が処理ブロック６２５において実行されてもよい。ストアフェンスは、ＭＯＮＩＴＯＲオペコードが実行完了する時点で、マシーンのすべてのストアが処理されることを保証するのに利用される。モニタがマシーンから排出される前にすべてのストアにより、メモリ待機（ｍｗａｉｔ）状態が誤って入力される可能性を低下させることができる。ストアフェンス処理は、予防として機能し、時間のかかる処理であるかもしれない。

ストアフェンスは、一実施例によるｍｏｎｉｔｏｒ−ｍｗａｉｔ機構が、複数退出機構として構成されているため任意的なものであるかもしれない。言い換えると、割込み、認識、ボードタイマー上のシステムなどの各種イベントはまた、ｍｗａｉｔ状態からの退出を引き起こすかもしれない。一実施例によると、監視されているデータ値は変動するため、スレッドはアウェイクされるかもしれない。従って一実施例によると、ソフトウェアは、メモリに格納されている特定の値が変動したか否かダブルチェックするようにしてもよい。一実施例によると、アサーションＮｏｎＭａｓｋａｂｌｅ Ｉｎｔｅｒｒｕｐｔ（ＮＭＩ）及びＳｙｓｔｅｍ Ｍａｎａｇｅｍｅｎｔ Ｉｎｔｅｒｒｕｐｔ（ＳＭＩ）を含む特定イベント、マシーンチェック割込み及び不具合はブレークイベントとみなされ、パワーダウンイベントなどの他のイベントはブレークイベントはみなされない。一実施例によると、例えば、Ａ２０Ｍピンのアサーションは、ブレークイベントとしてみなされるかもしれない。

処理ブロック６３０において、一実施例によると、モニタは実行されているバスサイクルがモニタアドレスへの書き込みを示しているか、あるいは示しているようであるかテストし続ける。このようなバスサイクルが検出されると、モニタイベント保留標識が、処理ブロック６３５において設定される。ＭＷＡＩＴオペコードの実行後（図５のブロック５０５）、当該イベント保留標識は、イベントとして機能し、図５のブロック５５５〜５６５においてスレッドを再開させる。さらに、アドレス変換を発生させるイベントは、スレッド１を再開させる。例えば、変換ルックアサイドバッファ（ｌｏｏｋ−ａｓｉｄｅ ｂｕｆｆｅｒ）をフラッシュさせるイベントは、リニアから物理的アドレスへのモニタアドレスを生成するのに行われる変換がもはや有効でないため、スレッド１の再開をトリガーする。例えば、ｘ８６インテルアーキテクチャ互換的プロセッサでは、制御レジスタＣＲ０、ＣＲ３及びＣＲ４への書き込みと共に、特定のマシーン固有レジスタへの書き込みが、ｍｗａｉｔ状態の退出を発生させる。

図７は、モニタ動作を処理するためのプロセスの実施例を示すフロー図である。特に、図７は、図３のモニタ３１０の動作と図６の処理ブロック６２０のさらなる詳細を示す。一実施例によると、処理ブロック７００において、モニタ３１０は、バストランザクションのためのバスコントローラ３４０からリクエスト及びアドレス情報を受け取る。処理ブロック７１０において、モニタ３１０は、影響を受けるアドレスとバスサイクルタイプを検討する。特に、サイクル比較論理３２０は、バスサイクルが指定されたサイクルであるか判断する。一実施例によると、アドレス比較回路３３０は、バストランザクションアドレスとモニタアドレスレジスタ３３５に格納されているモニタアドレスとを比較し、ライト検出論理３２５は、書き込みが行われたか検出するため、バスコントローラ３４０からサイクルタイプ情報を復号する。モニタアドレスへの書き込みが行われると、モニタイベント保留標識が処理ブロック７２０において設定される。信号（ＷＲＩＴＥ ＤＥＴＥＣＴＥＤ）が、イベントを通知するためスレッド一時停止／再開論理３７７に与えられる（また、ＭＥＭＯＲＹ ＷＡＩＴ（ＭＷＡＩＴ）を実行することによりイネーブルとされると仮定すると機能する）。最後に、モニタ３１０は、処理ブロック７３０において停止される。モニタの停止は電力を節約するが、誤ったモニタイベントがマスクされる限り、あるいは生成されない場合には重要ではないかもしれない。モニタイベント標識はまた、この時点でリセットされる。典型的には、モニタイベントの提供は、ＭＷＡＩＴが再び実行されるまで、さらなるモニタイベントの認識をマスクする。

モニタアドレスへの読み出しの場合、一実施例によると、コヒーレンシー関連論理３５０が起動されてもよい。処理ブロック７４０において、信号（ＨＩＴ＃など）がコヒーレンシー配信なしのさらなる書き込みを可能にする権限を他のエージェントが取得するのを回避するためアサートされる。一実施例によると、モニタ３１０は、アクティブ状態を維持し、処理ブロック７００に戻り、モニタアドレスのリードにより影響を受けないままとなる。さらに、トランザクションがモニタアドレスへのリードまたはライトの何れでもない場合、モニタはアクティブ状態を維持し、処理ブロック７００に戻る。

一実施例によると、ＭＯＮＩＴＯＲ命令はあるタイプのアクセスを監視するためのものである。これらのアクセスは、効率的なプログラミング技術を示すものとして選ばれたものであってもよいし、あるいは、他の理由により選ばれたものであってもよい。例えば、一実施例によると、メモリアクセスは当然に揃えられたライトバックメモリへのキャッシュ可能ストアでなければならない。当然に揃えられた要素は、Ｎにより割り切れるアドレスにおいてスタートするＮビット要素を参照するものであってもよい。当然に揃えられた要素を利用した結果として、１つのキャッシュラインが、監視されているアドレスへの書き込みを行うため、アクセスされる必要がある（データが２つのキャッシュラインに分割される場合には、２以外のキャッシュラインが必要となるかもしれない）。従って、当然に揃えられたメモリアドレスを利用することは、バス監視を簡素化する。

図８は、モニタメモリ待機を用いたロックの取得及び監視のためのプロセスの実施例を示すフロー図である。典型的なハイパースレッドまたはマルチスレッドプロセッサは、複数のスレッドまたは複数の論理プロセッサ（プロセッサ）を備える。典型的には、複数のプロセッサは、個別の物理的プロセッサの要素を与え、同一のリソースを共有する。処理ブロック８０２において、プロセッサは他のプロセッサにより競合されるロックを取得しようとする。判定ブロック８０４において、プロセッサが取得しようとするロックが他のプロセッサと競合しているか判断される。競合するロックは、１以上のプロセッサが取得のため待機するロックを意味する。ロックが競合していない場合、処理ブロック８０６において、プロセッサは利用可能なロックの権限を主張することにより、ロックを取得する従来方法を用いてロックを取得する。

典型的には、ロックが１以上のプロセッサと競合しない場合、待機キューは、競合するロックが待機するのを求めるプロセッサを有するよう構成される。しかしながら、このようなプロセッサの待機は、典型的には待機プロセッサが利用可能なリソースを用いて、例えば、競合するロックのメモリ位置にアクセスするとき、「ビジー待機中」である。処理ブロック８０８において、一実施例によると、ロックが競合する場合、キュー要素やノードＮなどのノード（ノード）がプロセッサに対し生成される。一実施例によると、当該ノードは、処理ブロック８１０において初期化される。他の実施例によると、ノードの初期化は、ノードがすでに初期化されているときには必要ではないかもしれない。処理ブロック８１２において、初期化されたノードは、競合するロックとリンクまたは関連付けされる。一実施例によると、関連付けされると、当該ノードは競合するロックに対するテールポインタとして機能する。

一実施例によると、処理ブロック８１４において、モニタは競合するロックを監視するため、競合するロックに関連付けされたノードを監視するようノード上で設定される。競合するロックの監視は、ロックが第１プロセッサ｛Ｍｏｎｉｔｏｒ（Ｎ．ｌｏｃｋ）｝に対し利用可能となったか判断するため、ロックのロックアドレスを監視することを含む。一実施例によると、モニタの設定は、フロントエンド３６５がＭＯＮＩＴＯＲオペコードを受信し、特別なＭＯＮＩＴＯＲ ｕＯＰを生成することに応答して、モニタを起動することを含む。ＭＯＮＩＴＯＲ ｕＯＰは、実行リソース３７０にわたされる。ＭＯＮＩＴＯＲ ｕＯＰは、監視対象となるアドレス（モニタアドレス）を示す関連付けされたアドレスを有する。一実施例によると、モニタアドレスは、ノードがリンクされるロックのロックアドレスを有するようにしてもよい。関連付けされたアドレスは、それがモニタアドレスを決定するのに十分な情報を伝達するという点で、モニタアドレスを「示す」ものであるかもしれない（おそらく、他のレジスタまたは情報と共に）。

図３に示されるように、一実施例によると、モニタアドレスはアドレス変換論理３７５に与えられ、それがモニタアドレスレジスタ３３５に格納される場合にはモニタにわたされる。ＭＯＮＩＴＯＲオペコードに応答して、実行リソース３７０は、処理ブロック５１０に示され、図６においてさらに説明されるように、モニタをイネーブル及び起動する。一実施例によると、モニタは、一実施例によるＭＯＮＩＴＯＲオペコードにより起動されると、モニタイベントが発生するまで他の処理とパラレルに動作し続ける。

処理ブロック８１６において、一実施例によると、メモリ待機（ｍｗａｉｔ）命令が、競合するロックが利用可能になるのを待機しながら、プロセッサをスリープ状態にするよう実行される。一実施例によると、ＭＷＡＩＴオペコードは、受信され、実行にわたされる。一実施例によると、ＭＷＡＩＴオペコードの実行は、各種モニタイベントをマスク解除する。ＭＷＡＩＴオペコードに応答して、モニタイベントが保留中であるか判断するため、テストが実行される。保留中のモニタイベントが存在しない場合、モニタがアクティブ状態であるか判断するため、テストが実行される。例えば、ＭＷＡＩＴがＭＯＮＩＴＯＲを以前に実行することなく実行される場合、モニタはアクティブ状態でないかもしれない。一実施例によると、モニタがアクティブ状態でないか、あるいはモニタイベントが保留中である場合、プロセッサはスリープ状態にされなくてもよい。一実施例によると、モニタイベントは、モニタがノードの監視を終了する非アクティブ状態に移行し、プロセッサがアウェイク状態となることに応答したイベントを表す。例えば、モニタイベントは、それがロックの権限を主張する順番に到達すること、及び／またはロックを現在所有する他のプロセッサにより解放されるとき、ロックがプロセッサに利用可能となることを含む。

一実施例によると、プロセッサは、処理ブロック８１８において、ノード上のモニタｍｗａｉｔ機構を用いてスリープ状態にされる。一実施例によると、モニタがアクティブ状態であり、保留中のモニタイベントが存在しない場合、プロセッサはモニタイベントが発生するまでスリープ状態にされる。言い換えると、例えば、第１プロセッサは、それが競合するロックの権限を主張する１番目のプロセッサになるまでスリープ状態とされる。このような認識は、モニタイベントの発生がモニタを非アクティブ状態にし、処理ブロック８２０においてプロセッサをウェイクアップすることを表す。

一実施例によると、モニタイベントは１つのイベントに限定されず、モニタリングが終了し、プロセッサがアウェイクされてもよいか判断するため、各種イベントがテストされてもよい。図６に関して説明されるように、モニタ自体は、モニタイベントが発生し、イベント保留標識を設定することによりそれを表示しているかチェックする。イベント保留標識は、ＥＶＥＮＴ信号を介しプロセッサスリープ／アウェイク論理３７７（マイクロコードなど）に提供される。マイクロコードは、一実施例によると、モニタイベントがＭＷＡＩＴオペコードによりマスク解除されているかもしれないため、適切な命令境界においてモニタイベントを認識する。さらに、イベント検出論理３４５は、モニタイベントとして指定される各種イベントを検出するのに利用される。さらに一実施例によると、任意的なタイマーが、ハイパースレッドプロセッサの適切な動作を保証し、ハイパースレッドプロセッサをフリーズさせる特定のイベントシーケンスに対しチェックを行うため、ｍｗａｉｔ状態から退出するため定期的に利用されてもよい。これらのイベントの何れもｍｗａｉｔ状態への退出を通知するものではない場合、第１プロセッサはスリープ状態を維持する。

処理ブロック８２２において、アウェイク状態の第１プロセッサは、ロックの所有権を主張すると共に、以前に解放されたリソースを再主張する。以前に解放されたリソースとは、スリープ状態及びロックの待機中に、第１プロセッサにより解放されたリソースを表す。一実施例によると、プロセッサのスリープ状態中、プロセッサスリープ／アウェイク論理３７７は、処理ブロック５３０においてすべての命令をクリアするため、プロセッサパイプラインを排出するパイプラインフラッシュ論理３８２を備える。パイプラインが排出されると、パーティション／アニール論理３８５は、第１プロセッサに排他的に関連付けされた任意のパーティションリソースを他のプロセッサによる利用のため解放させる。これら解放されたリソースは、他のプロセッサが利用するより大きなリソース群を形成するためアニールされてもよい。例えば、図４の２スレッドの例を参照するに、スレッド１に関連するすべての命令は、双方のキューから排出される。各キューペアは、より大きなキューを第２スレッドに与えるため合成されてもよい。同様に、レジスタプールからのさらなるレジスタが、第２スレッドに利用可能とされ、ストアバッファからのさらなるエントリが第２スレッドに開放され、リオーダバッファのさらなるエントリが第２スレッドに利用可能とされてもよい。基本的には、これらの構成は２倍のサイズの単一の専用構成に戻される。各個数のプロセッサを用いた実現形態から得られる各比率が考えられる。

一実施例によると、第１プロセッサがウェイクアップまたは再開すると、プロセッサスリープ／アウェイク論理３７７は、モニタイベントの検出により再び起動されるかもしれない。再び、パイプラインがそこから命令を排出するためフラッシュされ、これにより、以前に解放されたリソースがまもなくアウェイクされるか、あるいは最近アウェイクされた第１プロセッサに適応するよう再びパーティション可能となる。

図９は、モニタメモリ待機を用いてロックをリリース及び監視するためのプロセスの実施例を示すフロー図である。図８を参照して説明されるように、一実施例によると、モニタメモリ待機（ｍｏｎｉｔｏｒ−ｍｗａｉｔ）が、ノードＮなどのノード（ノード）または対応するキュー要素を監視することにより競合するロックを監視し、例えば、競合するロックが利用可能となるまで競合するロックを求めるプロセッサをスリープ状態にするのに利用される。ロックのリリースに関してｍｏｎｉｔｏｒ−ｍｗａｉｔを利用することにより、判定ブロック９０２において、ロックが競合しているか判断される。ロックが競合しない場合、ロックは処理ブロック９０４においてリリースされる。しかしながら、ロックが競合する場合、ロックのリリースは、例えば、ロックを所有するプロセッサ（リリースプロセッサ）が１以上のモニタイベントを含む１以上のイベントに応答してリリースするまで、ロックのリリースは発生しないかもしれない。

一実施例によると、モニタイベントは、競合するロックを主張するため、ラインの次（または最初）にあるロックを求めるプロセッサ（スリーププロセッサ）を表す。例えば、リリースプロセッサは、図８に関して取得された段階に説明されるように、スリープ／ｍｗａｉｔから競合するロックを求めるスリーププロセッサをウェイクアップするため、ストア「Ｎ．ｎｅｘｔ＞Ｌｏｃｋ」を発行する（Ｎ．ｎｅｘｔ！＝０である場合、Ｎ．ｎｅｘｔ−＞ｌｏｃｋへのストア／／スリーププロセッサのウェイクアップ）。言い換えると、判定ブロック９０６において、ノードがゼロ（０）に達したか（または戻ったか）否か判定される。ノードがゼロに達すると、すなわち、Ｎ．ｎｅｘｔ！＝０である場合、リリースプロセッサはスリーププロセッサがロックを所有するためラインの次となるストアＮ．ｎｅｘｔ−＞Ｌｏｃｋを発行し、スリーププロセッサが処理ブロック９１０においてスリープからアウェイクされる。ノードがゼロに到達しない場合には、処理ブロック９０８においてロックはリリースされない。処理ブロック９１２において、ロックはリリースプロセッサによりリリースされる。一実施例によると、ＭＯＮＩＴＯＲオペコード後に行われる任意のストア処理は、ストアが処理及び検出されることを保証するため制限されてもよい。一実施例によると、以降の何れかの命令が開始可能となる前に、一部の処理はモニタを起動した結果として実行される必要があるか、あるいは、ＭＯＮＩＴＯＲオペコードにより起動されると、モニタイベントが行われるまで他の処理とパラレルに行われるようにしてもよい。

図１０は、システムの実施例を示すブロック図である。一実施例によると、図示されるように、システムは、Ｎ個のハイパースレッドプロセッサであるプロセッサ１００５−１〜１００５−Ｎを有する。ハイパースレッドプロセッサ１００５−１〜１００５−Ｎは、バス１０５０と接続される。他の実施例によると、１つのプロセッサまたはハイパースレッドプロセッサとシングルスレッドプロセッサの組み合わせが利用されてもよい。さらに、他の既知のまたは利用可能なシステム構成が利用されてもよい。例えば、プロセッサ１００５−１〜１００５−Ｎが、ポイント・ツー・ポイント（ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ）形式に接続され、メモリインタフェースなどのパーツが各プロセッサ１００５−１〜１００５−Ｎに一体化されてもよい。

一実施例によると、バス１０５０に接続されているメモリインタフェース１０１５が、メモリ１０３０及びメディアインタフェース１０２０に接続される。メモリ１０３０は、マルチプロセッシングレディーオペレーティングシステム１０３５と、第１スレッド１０４０及び第２スレッド１０４５のための命令を有する。命令１０３０は、一実施例によるアイドルループを有する。

一実施例によると、各種機能または実施例を実行するための適切なソフトウェアが、各種機械可読媒体の何れかにより提供されてもよい。一実施例によると、メディアインタフェース１０２０が、そのようなソフトウェアとのインタフェースを提供する。

一実施例によると、メディアインタフェース１０２０は、記憶媒体（ディスクドライブ、光ドライブ、テープドライブ、揮発性メモリ、不揮発性メモリなど）や、送信媒体（ネットワークインタフェースや他のデジタルまたはアナログ通信インタフェースなど）とのインタフェースである。メディアインタフェース１０２０は、媒体（記憶媒体１０９２や送信媒体１０９５など）からソフトウェアルーチンを読み出す。機械可読媒体は、マシーンインタフェースによる読み出しのため、少なくとも一時的に情報を格納する任意の媒体である。これは、信号送信（媒体として有線、光または無線を介し）、及び／または各種タイプのディスク及びメモリ記憶装置などの物理的記憶媒体１０９２を有する。

図１１は、設計のシミュレーション、エミュレーション及び製造のための各種構成表現または形式の実施例を示すブロック図である。構成を表すデータは、多数の手法により構成を表現する。まずシミュレーションで有用なように、ハードウェアは、設計されたハードウェアがどのように実行すると予想されるかのコンピュータモデルを実質的に提供するハードウェア記述言語または他の機能記述言語を用いて表現される。ハードウェアモデル１１１０は、意図された機能を実行しているか判断するため、ハードウェアモデル１１１０に適したテスト１１３０を適用するシミュレーションソフトウェア１１２０を用いてシミュレート可能となるように、コンピュータメモリなどの記憶媒体１１００に格納されてもよい。一実施例によると、シミュレーションソフトウェア１１２０は、媒体に記録、キャプチャまたは有されていなくてもよい。

一実施例によると、論理及び／またはトランジスタゲートを有する回路レベルモデルは、設計処理の一部の段階において生成される。このようなモデルは、プログラマブル論理を用いてモデルを構成する専用のハードウェアシミュレーションにより場合によっては同様にシミュレートされる。このタイプのシミュレーションは、エミュレーション技術であってもよい。一実施例によると、再構成可能なハードウェアは、開示された技術を用いたモデルを格納する機械可読媒体に関する。

さらに一実施例によると、一部の段階では、ほとんどの構成はハードウェアモデルの各種装置の物理的置換を表すデータレベルに達している。従来の半導体製造技術が利用される場合、ハードウェアモデルを表すデータは、集積回路を生成するのに用いられるマスクの異なるマスクレイヤに関する様々な特徴の有無を指定するデータであってもよい。集積回路を表すこのデータは、データの論理または回路が上記技術を実行するためシミュレートまたは製造可能であるという点で、開示された技術を有するものであってもよい。

一実施例によると、データは任意の形態のコンピュータ可読媒体に格納されてもよい。このような情報を変調または送信するため生成される光または電気波１１６０、メモリ１１５０、あるいはディスクなどの磁気または光ストレージ１１４０が、上記媒体を表す。構成を記述するビット群または構成の特定部分は、さらなる設計または製造のため他者により利用または販売される物品を表すものであってもよい。

特定の実施例が添付された図面において図示及び説明されたが、このような実施例は単なる例示であり、限定的なものではなく、本発明の実施例は図示及び説明された特定の構成に限定されるものではないということが理解されるべきである。なぜなら、他の各種変更は本開示を研究することにより当業者に想到されるかもしれないからである。

図１は、メモリアクセスモニタを有するハイパースレッドプロセッサの実施例を示すブロック図である。 図２は、ハイパースレッドプロセッサの動作の実施例を示すフロー図である。 図３は、ハイパースレッドプロセッサの実施例を示すブロック図である。 図４は、リソースのパーティション、共有及び複製のためのプロセスの実施例を示すブロック図である。 図５は、スレッドの実行を一時停止及び再開するためのプロセスの実施例を示すフロー図である。 図６は、モニタリング論理の起動及び動作のためのプロセスの実施例を示すフロー図である。 図７は、モニタ処理のためのプロセスの実施例を示すフロー図である。 図８は、モニタメモリ待機を用いたロックの取得及び監視を行うためのプロセスの実施例を示すフロー図である。 図９は、モニタメモリ待機を用いたロックのリリース及び監視のためのプロセスの実施例を示すフロー図である。 図１０は、システムの実施例を示すブロック図である。 図１１は、設計のシミュレーション、エミュレーション及び製造のための各種構成表現または形式の実施例を示すブロック図である。

Claims (30)

1. 競合するロックに係るノードを監視するステップと、
   イベントが発生するまで、前記競合するロックを取得するプロセッサをスリープ状態にするステップと、
   から構成されることを特徴とする方法。
2. 請求項１記載の方法であって、
   前記ノードを監視するステップは、前記ノードの監視を起動するモニタ命令を実行することによって、前記競合するロックに対応するロックアドレスを監視することを特徴とする方法。
3. 請求項１記載の方法であって、さらに、
   前記イベントが発生するまで前記プロセッサをスリープ状態にするメモリ待機（ｍｗａｉｔ）命令を実行するステップを有することを特徴とする方法。
4. 請求項１記載の方法であって、さらに、
   前記競合するロックが利用可能となるイベントが発生すると、前記プロセッサをウェイクアップするステップと、
   前記プロセッサに前記利用可能なロックを取得させるステップと、
   を有することを特徴とする方法。
5. 請求項１記載の方法であって、
   前記競合するロックが利用可能となることは、前記プロセッサが前記競合するロックを取得するためのキューの次にあり、前記競合するロックがリリースされることからなることを特徴とする方法。
6. 請求項１記載の方法であって、
   前記プロセッサをスリープ状態にするステップは、前記プロセッサにより他のプロセッサが利用するリソースを解放することを特徴とする方法。
7. 請求項４記載の方法であって、
   前記ウェイクアップは、前記ノードの監視を非アクティブ状態とし、前記プロセッサに前記解放されたリソースを利用させることを特徴とする方法。
8. 請求項７記載の方法であって、
   前記解放は、
   レジスタプールの複数のレジスタを解放するステップと、
   命令キューの複数の命令キューエントリを解放するステップと、
   ストアバッファの複数のストアバッファエントリを解放するステップと、
   リオーダバッファの複数のリオーダバッファエントリを解放するステップと、
   から構成されることを特徴とする方法。
9. キュー要素を監視するため、前記キュー要素に係るモニタアドレスを指定するステップから構成される方法であって、
   前記指定するステップは、モニタ命令及びメモリ待機（ｍｗａｉｔ）命令とを実行することからなることを特徴とする方法。
10. 請求項９記載の方法であって、
    前記キュー要素は、競合するロックを取得するプロセッサに対応することを特徴とする方法。
11. 請求項１０記載の方法であって、
    前記プロセッサは、監視とｍｗａｉｔの組み合わせを用いて、前記競合するロックを待機中、スリープ状態にされることを特徴とする方法。
12. 請求項１１記載の方法であって、
    前記プロセッサは、前記プロセッサが前記競合するロックを取得するためのキューの次にあって、前記競合するロックがリリースされるイベントが発生すると、アウェイクされることを特徴とする方法。
13. 競合するロックに係るノードを監視するため、監視命令及びメモリ待機（ｍｗａｉｔ）命令を実行する命令ユニットと、
    イベントが発生するまで、前記競合するロックを取得する論理プロセッサをスリープ状態にする論理と、
    から構成されることを特徴とするプロセッサ。
14. 請求項１３記載のプロセッサであって、さらに、
    前記競合するロックが利用可能になることを含む指定されたイベントを有するイベントの発生を検出する検出回路を有することを特徴とするプロセッサ。
15. 請求項１３記載のプロセッサであって、
    前記論理プロセッサをスリープ状態にすることは、前記論理プロセッサによって他のプロセッサが利用するリソースを解放するからなることを特徴とするプロセッサ。
16. 請求項１３記載のプロセッサであって、
    前記論理はさらに、前記イベントが発生すると、前記論理プロセッサをウェイクアップするためものであり、
    前記ウェイクアップは、前記モードの監視を非アクティブ状態にし、前記論理プロセッサによる前記解放されたリソースの使用からなることを特徴とするプロセッサ。
17. 請求項１６記載のプロセッサであって、
    前記解放は、
    レジスタプールの複数のレジスタを解放し、
    命令キューの複数の命令キューエントリを解放し、
    ストアバッファの複数のストアバッファエントリを解放し、
    リオーダバッファの複数のリオーダバッファエントリを解放すること、
    から構成されることを特徴とするプロセッサ。
18. 記憶媒体と、
    前記記憶媒体に接続され、競合するロックに係るノードを監視するため、モニタ命令及びメモリ待機（ｍｗａｉｔ）命令を実行する実行ユニットと、イベントが発生するまで、前記競合するロックを取得する論理プロセッサをスリープ状態にする論理とを有するプロセッサと、
    から構成されることを特徴とするシステム。
19. 請求項１８記載のシステムであって、さらに、
    前記競合するロックが利用可能になることを含む指定されたイベントを有するイベントの発生を検出する検出回路を有することを特徴とするシステム。
20. 請求項１８記載のシステムであって、
    前記論理プロセッサをスリープ状態にすることは、前記論理プロセッサによって他のプロセッサが利用するリソースを解放するからなることを特徴とするシステム。
21. 請求項１８記載のシステムであって、
    前記論理はさらに、前記イベントが発生すると、前記論理プロセッサをウェイクアップするためものであり、
    前記ウェイクアップは、前記モードの監視を非アクティブ状態にし、前記論理プロセッサによる前記解放されたリソースの使用からなることを特徴とするシステム。
22. マシーンによる実行時、前記マシーンに、
    競合するロックに係るノードを監視するステップと、
    イベントが発生するまで、前記競合するロックを取得するプロセッサをスリープ状態にするステップと、
    を実行させる命令シーケンスを表すデータを格納することを特徴とする機械可読媒体。
23. 請求項２２記載の機械可読媒体であって、
    前記ノードを監視するステップは、前記ノードの監視を起動するモニタ命令を実行することによって、前記競合するロックに対応するロックアドレスを監視することを特徴とする媒体。
24. 請求項２２記載の機械可読媒体であって、
    前記命令シーケンスはさらに、前記マシーンによる実行時、前記イベントが発生するまで前記プロセッサをスリープ状態にするため、メモリ待機（ｍｗａｉｔ）命令を前記マシーンに実行させることを特徴とする媒体。
25. 請求項２２記載の機械可読媒体であって、
    前記命令シーケンスはさらに、前記マシーンによる実行時、前記マシーンに、前記競合するロックが利用可能になるイベントが発生すると、前記プロセッサをウェイクアップさせ、前記プロセッサが前記利用可能なロックを取得することを可能にさせることを特徴とする媒体。
26. 請求項２２記載の方法であって、
    前記プロセッサをスリープ状態にするステップは、前記プロセッサによって他のプロセッサが利用するリソースを放棄させることからなることを特徴とする方法。
27. マシーンによる実行時、キュー要素を監視するため、前記キュー要素に係るモニタアドレスを前記マシーンに指定させる命令シーケンスを表すデータを格納する機械可読媒体であって、
    前記指定は、モニタ命令及びメモリ待機（ｍｗａｉｔ）命令を実行することからなることを特徴とする媒体。
28. 請求項２７記載の機械可読媒体であって、
    前記キュー要素は、競合するロックを取得するプロセッサに対応することを特徴とする媒体。
29. 請求項２８記載の機械可読媒体であって、
    前記命令シーケンスはさらに、前記マシーンによる実行時、前記マシーンによって、監視とｍｗａｉｔの組み合わせを用いて前記競合するロックの待機中、前記プロセッサをスリープ状態にすることを特徴とする媒体。
30. 請求項２９記載の機械可読媒体であって、
    前記命令シーケンスはさらに、前記マシーンによる実行時、前記マシーンによって、前記競合するロックが利用可能となるイベントが発生すると、前記プロセッサをアウェイク状態にすることを特徴とする媒体。

Images