JP2014222533A - ユーザーレベルのマルチスレッドを提供する方法およびシステム - Google Patents

Abstract

【課題】ユーザーレベルのマルチスレッドを提供する方法およびシステムが開示される。【解決手段】本技法に基づく方法は、命令セットアーキテクチャ（ISA）を介して一つまたは複数の共有リソース・スレッド（シュレッド）を実行するためのプログラミング命令を受け取ることを含む。一つまたは複数の命令ポインタがISAを介して構成設定され、前記一つまたは複数のシュレッドがマイクロプロセッサにより同時的に実行される。ここで、マイクロプロセッサは複数の命令シーケンサを含んでいる。【選択図】図１

Description

本発明のここでの諸実施形態はコンピュータシステムの分野に関する。特に、ここでの諸実施形態はユーザーレベルのマルチスレッドを提供するための方法およびシステムに関する。

マルチスレッドは、プログラムまたはOS（オペレーティングシステム）が命令のシーケンスを一時に二つ以上実行する機能である。各ユーザー（ここではユーザーは別のプログラムでもよい）からのプログラムまたはシステムサービスの要求は、別個の素性をもつスレッドとして追跡される。プログラムはそのスレッドに対する初期要求のために動作し、他の要求によって中断されるので、そのスレッドのための作業の状態は、その作業が完了するまで追跡される。

コンピュータ処理の種別には、単一命令ストリーム・単一データストリームが含まれるが、これは命令の単一のストリームを含む従来のシリアル式フォンノイマンコンピュータである。第二の処理種別は単一命令ストリーム・多重データストリーム（SIMD: single instruction stream, multiple data streams）処理である。この処理方式には、多重算術論理プロセッサおよび単一制御プロセッサが含まれる。算術論理プロセッサのそれぞれがデータに対して演算をロックステップで実行し、制御プロセッサによって同期される。第三の種別は多重命令ストリーム・単一データストリーム（MISD: multiple instruction streams, single data stream）処理であるが、これは同じデータストリームの流れを異なる命令ストリームを実行する諸プロセッサの線形配列を通じて処理することに関わる。第四の処理種別は、多重命令ストリーム・多重データストリーム（MIMD: multiple instruction streams, multiple data streams）処理であり、これは複数のプロセッサを使用し、そのそれぞれが該それぞれのプロセッサに供給されたデータストリームを処理するための独自の命令ストリームを実行する。MIMDプロセッサはいくつかの命令処理ユニット、複数の命令シーケンサ、よっていくつかのデータストリームを有しうる。

今日のマルチスレッド・マイクロプロセッサによって採用されているプログラミング・モデルは、伝統的な共有メモリ・マルチプロセッサと同じである：複数のスレッドがあたかも独立のCPUで走るかのようにプログラムされる。スレッド間の通信はメインメモリを通じて実行され、スレッド生成／破棄／スケジューリングはOSによって実行される。マルチスレッドはこれまで、プログラマーが直接スレッドにアクセスできるような、アーキテクチャ的に目に見える仕方では供給されていなかった。
本発明のここでの諸実施形態は、以下の詳細な記述を図面とともに参照することからより完全に理解され、認識されるであろう。

ユーザーレベルのマルチスレッドを提供する方法およびシステムが開示される。本技法に基づく方法は、命令セットアーキテクチャ（ISA: instruction set architecture）を介して一つまたは複数の共有リソース・スレッド（shared resource thread）（シュレッド［shred］）を実行するためのプログラミング命令を受け取ることを含む。一つまたは複数の命令ポインタがISAを介して構成設定され、前記一つまたは複数のシュレッドがマイクロプロセッサにより同時的に実行される。ここで、マイクロプロセッサは複数の命令シーケンサを含んでいる。

本発明のある実施形態に基づく、本方法および装置を利用する例示的なコンピュータシステムのブロック図である。 本発明のある実施形態に基づく、例示的なチップレベルのマイクロプロセッサを示す図である。 本発明のある実施形態に基づく、例示的な同時マルチスレッド・プロセッサを示す図である。 本発明のある実施形態に基づく、例示的な非対称マルチプロセッサを示す図である。 本発明のある実施形態に基づく、ユーザーレベルのマルチスレッド機能を提供するための例示的な実行環境を示す図である。 本発明のある実施形態に基づく、シュレッドと共有メモリ・スレッドとの間の例示的な関係を示す図である。 本発明のある実施形態に基づく、ユーザーレベルのマルチスレッド機能の例示的なプロセスの流れ図である。

以下の記述では、説明の目的で個別的な述語が述べられる。しかし、こうした個別的な詳細が必須でないことは当業者には明らかであろう。以下の詳細な記述のいくつかの部分はアルゴリズムおよびコンピュータメモリ内のデータビットに対する演算の記号表現を用いて呈示されている。これらのアルゴリズム的記述および表現は、データ処理分野の当業者が自らの仕事の内容を他の当業者に最も効率的に伝達するために使っている手段である。アルゴリズムとはここでは、そして一般にも、所望の結果に導く一連の自己完結的な処理の系列であると考えられる。前記処理は物理量の物理的な操作を要求するものである。必須ではないが通例、そうした量は、保存、転送、組み合わせおよびその他の操作ができる電気信号または磁気信号の形をとる。時には主として慣用上の理由のため、これらの信号をビット、値、要素、記号、文字、項、数などと称することが便利であることがわかっている。

しかし、これらの、そして同様の用語はすべて適切な物理量と関連しており、単にそれらの量に適用される便利なラベルにすぎないことを留意すべきである。以下の議論から明らかなように、特別に断らない限り、本記載を通じて、「処理」または「計算」または「計数」または「決定」または「表示」などといった用語を用いた議論は、コンピュータシステムのレジスタおよびメモリ内の物理的な（電子的な）量として表現されているデータを操作し、コンピュータシステムメモリまたはレジスタまたはその他のそのような情報記憶、伝送もしくは表示装置内の物理的な量として同様に表現される他のデータに変換するコンピュータシステムまたは同様の電子計算装置の動作およびプロセスを言っていることが了解される。

本発明の諸実施形態はまた、ここの動作を実行するための装置にも関する。この装置は必要とされる目的のために特別に構築されたものでもよいし、あるいは汎用コンピュータであって該コンピュータ内に保存されるコンピュータプログラムによって選択的に活性化もしくは再構成設定されるのでもよい。そのようなコンピュータプログラムはコンピュータ可読記憶媒体に保存されうる。そのような媒体としては、これに限定されるものではないが、フロッピー（登録商標）ディスク、光ディスク、CD-ROM、光磁気ディスクを含む任意の種類のディスク、読み出し専用メモリ（ROM）、ランダムアクセスメモリ（RAM）、EPROM、EEPROM、磁気もしくは光カードまたは電子的な命令を保存するのに好適な任意の種類の媒体であってそれぞれコンピュータシステムバスに結合されているものがある。

ここに呈示される動作および表示はいかなる特定のコンピュータまたはその他の装置に本来的に関係しているものでもない。さまざまな汎用システムがここの思想に従ったプログラムとともに使用されうるし、あるいは必要とされる動作を実行するためにより特化した装置を構築することが便利であると判明することもありうる。多様なこれらのシステムのための必要とされる構造は以下の記述から明らかとなろう。さらに、本発明の実施形態はいかなる特定のプログラミング言語との関連で記載されているのでもない。ここに記載される本発明の諸実施形態の思想を実現するためには多様なプログラミング言語が使用されうることは理解されるであろう。

この明細書を通じて使用される「ユーザー」は、アプリケーション・プログラム、非特権コードおよび同様なソフトウェアといったユーザーレベル・ソフトウェアのことを述べている。ユーザーレベル・ソフトウェアはOSまたは同様の特権ソフトウェアからは区別される。本発明のある実施形態によれば、以下の記述は上述したMIMDプロセッサに適用される。

図１は、本発明のある実施形態に基づく、本方法および装置を利用する例示的なコンピュータシステム１００のブロック図を示している。コンピュータシステムはプロセッサ１０５を含む。チップセット１１０がシステム１００にメモリおよびI/O機能を提供する。より具体的には、チップセット１１０はグラフィックおよびメモリ・コントローラ・ハブ（GMCH: Graphics and Memory Controller Hub）１１５を含む。GMCH１１５は、プロセッサ１０５と通信するホストコントローラとしてはたらき、さらにメインメモリ１２０のためのコントローラとしてはたらく。本発明のある実施形態によれば、プロセッサ１０５はマルチスレッドのユーザーレベルへの拡張を可能にする。GMCH１１５はまた、それに結合されている先進グラフィックポート（AGP: Advanced Graphics Port）コントローラ１２５へのインターフェースをも提供する。チップセット１１０はさらに、数多くのI/O機能を実行するI/Oコントローラ・ハブ（ICH: I/O Controller Hub）を含む。ICH１３５はシステム管理バス（SMバス：System Management Bus）１４０に結合されている。

ICH１３５は、周辺コンポーネント相互接続（PCI: Peripheral Component Interconnect）バス１５５に結合されている。スーパーI/O（S/O: super I/O）コントローラ１７０がICH１３５に結合されて、キーボードおよびマウス１７５のような入力装置への接続性を提供する。汎用I/O（GPIO: general-purpose I/O）バス１９５がICH１３５に結合されている。USBポート２００が図のようにICH１３５に結合されている。プリンタ、スキャナ、ジョイスティックなどのようなUSBデバイスはこのバス上でシステム構成に追加されることができる。IDEドライブ２１０をコンピュータシステムに接続するために統合ドライブエレクトロニクス（IDE: integrated drive electronics）バス２０５がICH１３５に結合されている。論理的にはICH１３５は、単一の物理コンポーネント内の複数PCIデバイスのように見える。

プロセッサ１０５には命令セットアーキテクチャが含まれている。命令セットアーキテクチャ（ISA: instruction set architecture）はプロセッサ１０５のようなマイクロプロセッサの抽象モデルで、状態要素（レジスタ）およびそれらの状態要素を動作させる命令からなる。命令セットアーキテクチャは、マイクロプロセッサの振る舞いの抽象的な仕様を提供することによって、プログラマーおよびマイクロプロセッサ設計者の両方に対して、ソフトウェアとハードウェアの間の境界のはたらきをする。

シリコンチップ上で利用可能なトランジスタ数の向上は、汎用マイクロプロセッサへのマルチスレッドの導入を可能にした。マルチスレッドは２つの異なる仕方で実装されうる：チップレベル・マルチプロセッサ（CMP: chip-level multiprocessor）および同時マルチスレッド・プロセッサ（SMT: simultaneous multithreaded processor）である。このどちらもプロセッサ１０５として使用されうる。

図２は、本発明のある実施形態に基づく、例示的なチップレベル・マルチプロセッサを示している。プロセッサ２００のようなチップレベル・マルチプロセッサにおいては、複数のCPUコア２１０〜２１３が単一のシリコンチップ２００に集積されている。CPUコア２１０〜２１３のそれぞれは独立した実行スレッド２２０〜２２３を実行できるが、一部のリソース（キャッシュなど）がCPUコア２１０〜２１３のうちの二つ以上によって共有されていてもよい。

図３は、本発明のある実施形態に基づく、例示的な同時マルチスレッド・プロセッサ３００を示している。プロセッサ１０５はプロセッサ３００のような同時マルチスレッド・プロセッサであることができる。同時マルチスレッド・プロセッサ３００においては、単一のCPUコア３１０が、複数の実行スレッドを実行できる。CPUコア３１０は、極度に細かい粒度でCPUリソースを共有する（しばしば各リソースでどのスレッドを処理するかをクロックごとに決定する）ことによって、ソフトウェアには二つ以上のプロセッサのように見える。

図４は、本発明のある実施形態に基づく、例示的な非対称マルチプロセッサ４００を示している。プロセッサ１０５はマルチプロセッサ４００のような非対称マルチプロセッサであることができる。CPUコア４１０〜４２７が異なるマイクロアーキテクチャを有するがISAは同じであるようなチップレベル・マルチプロセッサ４００を構築することが可能である。たとえば、少数の高性能CPUコア４１０〜４１１が多数の低パワーCPUコア４２０〜４２７と一緒に集積されてもよい。この種の設計は、高いスカラー性能とともに高い総スループットを実現できる。２つの種類のCPUコアはソフトウェアには、通常の共有メモリ・スレッドとして、あるいはシュレッドとして、あるいは両者の何らかの組み合わせとして見える。命令セットアーキテクチャ（ISA）はプロセッサ１０５のようなマイクロプロセッサの抽象モデルであり、状態要素（レジスタ）およびそれらの状態要素に作用する命令からなる。ISAはマイクロプロセッサの振る舞いの抽象的な仕様を提供することによって、プログラマーおよびマイクロプロセッサ設計者の両方に対して、ソフトウェアとハードウェアの間の境界のはたらきをする。本プログラミング・モデルは、アプリケーション・プログラムが、直接的に複数の非対称CPUコアを制御することを可能にする。

〈共有メモリ・プログラミング・モデル〉
従来のマルチスレッド・マイクロプロセッサは、従来の共有メモリ・マルチプロセッサ・システムと同じプログラミング・モデルを採用している。プログラミング・モデルは次のとおりである。マイクロプロセッサがOSに複数の実行スレッドを提供する。OSはこれらのスレッドを使って複数のアプリケーション（「プロセス」）を並行して走らせる、および／または単一のアプリケーションからの複数のスレッド（「マルチスレッド」）を並行して走らせる。いずれの場合にも、複数のスレッドはソフトウェアには独立したCPUのように見える。メインメモリはすべてのスレッドによって共有され、スレッド間の通信はメインメモリを通じて実行される。CPU内のハードウェアリソースも共有されうるが、共有はマイクロアーキテクチャによりソフトウェアからは隠されている。

伝統的な共有メモリ・マイクロプロセッサのプログラミング・モデルは広く理解され、多くのOSおよびアプリケーション・プログラムによってサポートされているものの、そのモデルはいくつかの不都合な点がある。それは：
１）スレッド間の通信がメインメモリを介して実行され、よって著しく遅い。キャッシングによって遅延の一部を軽減しうるが、共有を容易にするためにしばしばキャッシュラインをあるCPUコアから別のCPUコアに渡す必要がある。
２）スレッド間の同期がメモリベースのセマフォを使って実行され、よって著しく遅い。
３）スレッドの生成、破棄、サスペンドおよび再開がOSの介入を必要とし、よって著しく遅い。
４）CPUマルチスレッド機能の改良が上述したメモリ遅延およびOS遅延によって薄められてしまうため、マイクロプロセッサ発売元が最も効率的なマルチスレッド機能を提供できない。

〈マルチスレッド・アーキテクチャ拡張〉
従来システムに関する上に述べた理由のため、本方法およびシステムは、プロセッサのアーキテクチャを拡張して、マルチスレッド・アーキテクチャ拡張を通じてアーキテクチャ的に目に見えるマルチスレッド機能を含めるようにする。複数の同時的な実行スレッド、複数の命令ポインタ、単一の処理要素内のある種のアプリケーション状態（レジスタ）の複数のコピーが提供される。複数の実行スレッドは、既存の共有メモリ・スレッドとは区別できるものであり、シュレッド（shred）すなわち共有リソース・スレッド（shared resource thread）と称される。

本マルチスレッド・アーキテクチャ拡張（multithreading architecture extensions）（その例は以下ではMAXと称される）は、既存のアーキテクチャ機能を含み、加えて複数の同時シュレッドをサポートすることになる。各シュレッドは独自の命令ポインタ、一般レジスタ、FPレジスタ、分枝レジスタ、述語レジスタおよびある種のアプリケーションレジスタを有している。シュレッドを生成および破棄するために非特権命令が生成される。シュレッド間の通信は、共有メモリに加えて共有レジスタを通じて実行される。本マルチスレッド・アーキテクチャ拡張は共有レジスタへの原子的なアクセスを保証するため、セマフォの必要性は低下する。さらに、本マルチスレッド・アーキテクチャ拡張は、インテル（登録商標）による３２ビットアーキテクチャのような３２ビットアーキテクチャと、やはりインテル（登録商標）による６４ビットアーキテクチャのような６４ビットアーキテクチャと、あるいは１６ビットアーキテクチャとさえも使用できる。

本発明のある実施形態に基づく、従来の共有メモリ・マルチプロセッサ・スレッドとシュレッドとの比較を次の表に示す。

表１

本マルチスレッド・アーキテクチャ拡張が従来のアーキテクチャ拡張とは根本的に異なっていることに気づかれるであろう。従来のアーキテクチャ拡張がより多くの命令およびより多くのレジスタ（状態）を提供していたのに対し、マルチスレッド・アーキテクチャ拡張はより多くの実行単位を提供する。

〈アプリケーションおよびシステム状態〉
プログラマーに見えるCPU状態は、２つの範疇に分けられる：アプリケーション状態およびシステム状態である。アプリケーション状態はアプリケーション・プログラムとOSの両方によって使用され、制御される一方、システム状態はOSによってのみ制御される。

図５は、本発明のある実施形態に基づく、ユーザーレベルのマルチスレッドを提供するための例示的な実行環境を示す。実行環境６００に含まれるレジスタのアプリケーション状態は次の表のようにまとめられる。

表２

ユーザーレベル・マルチスレッド・レジスタ６５０〜６６５は、以下に、より詳細に述べる。

３２ビットアーキテクチャシステム状態は次のようにまとめられる。

表３

各シュレッドについて、アプリケーション状態は２つの範疇に分けられる：シュレッド毎アプリケーション状態および共有アプリケーション状態である。ここで述べるMAXプログラミング・モデルはシュレッド毎アプリケーション状態の特有なインスタンスを提供する一方、共有アプリケーション状態は複数のシュレッドの間で共有される。システム状態のコピーは一つしかなく、所与のスレッドに対応するすべてのシュレッドが同じシステム状態を共有する。アプリケーションおよび状態の近似的な分割は次の表に呈示されている。

表４

本マルチスレッド・アーキテクチャ拡張は、ほとんどのアプリケーション状態のプログラム可能な共有（sharing）または専有（privacy）を提供し、ソフトウェアが最良の分割を選択できる。プログラムはビットベクトルによって行われ、個々のレジスタが共有または専有のいずれかとして選択されることができる。ハードウェアの名称変更手段が、ビットベクトルによって指定される共有プールまたは専有プールのいずれかからレジスタを割り当てることができる。

MAXの全体としての記憶要求は従来の同時マルチスレッド・プロセッサおよびチップレベル・マルチプロセッサより少ない。伝統的な共有メモリ・マルチプロセッサ・プログラミング・モデルを実装する同時マルチスレッド・プロセッサまたはチップレベル・マルチプロセッサではアプリケーションおよびシステム状態全体が複製される必要があるのに対し、MAXではシュレッド毎の専有アプリケーション状態だけが複製される。

〈シュレッド／スレッド階層〉
各共有メモリ・スレッドは複数のシュレッドからなる。シュレッドと共有メモリ・スレッドは２レベルの階層をなす。別の実施形態では、３レベルの階層が共有メモリMAXプロセッサのクラスタから構築できる。クラスタはメッセージ渡しを使って通信する。OSがスレッドのスケジューリングを扱い、一方、アプリケーション・プログラムがシュレッドのスケジューリングを扱う。任意の所与のシュレッドから見た他のシュレッドがローカルまたはリモートであるという意味において、シュレッドは非一様である。シュレッド毎アプリケーション状態は各シュレッドについて複製される。共有アプリケーションおよびシステム状態はローカルなシュレッドに共通であり、各共有メモリ・スレッドについて複製される。メモリ状態は一つのコピーのみを有する。

図６は、本発明のある実施形態に基づく、シュレッドと共有メモリ・スレッドとの例示的な関係を示している。シュレッド毎アプリケーション状態５１０は各シュレッドについて複製される。共有アプリケーションおよびシステム状態５２０はローカルなシュレッドに共通であり、各共有メモリ・スレッドについて複製される。メモリ状態５３０は一つのコピーのみを有する。

MAXプログラミング・モデルではシステム状態５２０が複数のシュレッドの間で共有されるため、該複数のシュレッドは同じプロセスに属する。本マルチスレッド・アーキテクチャ拡張は、マルチスレッド・アプリケーション、ライブラリおよび仮想マシンによって使用されることが意図されている。MAXプログラミング・モデルはこの種のソフトウェアに、そのシュレッドに対する先例のない度合いの制御および共有メモリでは実現できないパフォーマンス潜在力を与える。

シュレッドはみな同じ特権レベルで走り、同じアドレス変換を共有するので、シュレッド間では保護確認は必要とされない。よって、伝統的な保護機構はシュレッド間通信の間には回避しうる。

共有システム状態のため、同じスレッド上で異なるプロセスを走らせるためにMAXプログラミング・モデルを使うことはできない。このため、MAXプログラミング・モデルおよび従来の共有メモリ・プログラミング・モデルは同じシステム内で共存する。

所与のCPUは有限個の物理シュレッドを提供するため、ソフトウェアは利用可能なシュレッド数を、ハードウェアスレッドの可視化と同様の仕方で可視化する。可視化の結果は、有限個の、並行して走っている物理シュレッドとともに潜在的には限りない数の仮想シュレッドを与える。

〈システムコール〉
OSコールは、アプリケーション・プログラムからOSに制御を移し、コンテキスト切り換えを実行することにより、従来式の仕方で処理されてもよい。MAXアーキテクチャでは、一つの主要な相違は、どのシュレッドでOSをコールしても、所与のスレッドに関連するすべてのシュレッドの実行がサスペンドされるということである。同じスレッドに属するすべてのシュレッドの状態を保存し、復元するのはOSの責任である。

追加的な状態のため、コンテキスト切り換えのオーバーヘッドが増大する。コンテキスト切り換えのメモリ・フットプリントはシュレッド数に比例して増える。しかし、コンテキスト切り換え時間はあまり増加しない。各シュレッドが、他のシュレッドと並列に自分の状態を保存／復元するからである。コンテキスト切り換え機構は、複数のシーケンサを使った並列的な、状態の保存／復元を可能にする。OSそのものは複数のシュレッドを使用する。

OSをコールするコストが増大するため、OSによって実行されていたある種の機能性はアプリケーション・プログラムに移行される。この機能性には、スレッド維持およびある種の例外および割り込みの処理が含まれる。

システムコールを実行するための代替的な実施形態は、コンテキスト切り換えが高価になりつつある一方、スレッドが安価になりつつあるという観察に基づいている。この実施形態では、あるスレッドがOSを走らせるのに専用とされ、第二のスレッドがアプリケーション・プログラムを走らせるのに専用とされる。アプリケーション・プログラムのシュレッドがシステムコールを実行すると、それはOSシュレッドに（共有メモリを介して）メッセージを送り、応答メッセージを待つ。このようにして、メッセージ交換・待機機構が、従来式の制御移行・コンテキスト切り換え機構に取って代わる。どのスレッドのアドレス変換も変更は必要とされない。恩恵は、あるシュレッドによってOSに送られたメッセージがローカルな他のシュレッドを乱さないということである。

〈例外〉
従来のアーキテクチャでは、例外はアプリケーション・プログラムの実行をサスペンドし、OSの例外ハンドラを呼び出す。MAXプログラミング・モデルのもとでは、この振る舞いは望ましくない。あるシュレッドをサスペンドしてOSを呼び出すことは、（所与のスレッドに関連する）あらゆるシュレッドもサスペンドしてしまうからである。

この問題を解決するため、多くのタイプの例外を手当てする最初の機会をアプリケーション・プログラムに与える、新しいユーザーレベルの例外機構を導入する。ユーザーレベルの例外機構は、既存の例外タイプのいくつかが究極的にはアプリケーションそのものによって手当てされているとの観察に基づいている。

ユーザーレベルの例外機構のためには、例外がどう報告されるかが、例外がどう手当てされるかから区別される。例外は次のように３つの範疇に分けられる。
１．アプリケーション・プログラムに報告され、アプリケーション・プログラムによって手当てされる例外。たとえば、０による除算例外はその例外を引き起こしたアプリケーションに報告され、手当てもそのアプリケーションによってなされる。OSの関与は必要でもないし、望ましくもない。
２．アプリケーション・プログラムに報告され、その後、アプリケーション・プログラムが手当てのためにOSをコールする必要のある例外。アプリケーションによって起こされるページフォールトはアプリケーションに報告されてもよいが、ページ内でスワップするためにはアプリケーション・プログラムはOSをコールする必要がある。
３．OSに報告され、OSによって手当てされる必要のある例外。セキュリティ上の理由で、ハードウェア割り込みはOSに報告される必要がある。システムコール（ソフトウェア割り込み）は明らかにOSに報告される必要がある。

次の表は、上記の３つの各範疇の例外を示している。「キャッシュミスに際しての読み込み例外」および「微細粒度タイマー」の例外タイプは、本発明のある実施形態に関係した例外タイプとして与えられている。

表５

アプリケーション・プログラムに報告された例外は、選択的にアプリケーション内で処理され、あるいは処理のためにOSに渡される。後者の場合、アプリケーション・プログラムは例外（ページフォールトのような）に応答してOSに手当てを明示的に要求するシステムコールを実行する。これは、暗黙のうちにOSがアプリケーションに代わってそのような手当てを実行する伝統的なアプローチとは対照的である。ネストされた例外を避けるため、例外をOSに中継するアプリケーション・コードはそれ自身が追加的な例外を招くことはないという特別な規定が設けられる。ユーザーレベルの例外機構は、影のレジスタセットにおけるCPUレジスタの最少数およびプロセッサ・ベクトルを固定位置に保存する。

〈仮想マシン〉
仮想マシンとマルチスレッド・アーキテクチャ拡張のここでの諸実施形態とは、互いに制約を課す。仮想マシンは、ソフトウェアが仮想化されているリソースにアクセスしようとするときには常に例外を発生させ、例外処理はシュレッドに対して著しいパフォーマンス上の影響をもつ。

仮想マシンでは、特権命令の実行または特権プロセッサ状態へのアクセスが例外を発生させる。例外は仮想マシン・モニタに報告される（そしてそれによって手当てされる）必要がある。MAXでは、OS（および仮想マシン・モニタ）によって手当てされる例外は、所与のスレッドに関連するあらゆるシュレッドをサスペンドさせる。仮想マシン・モニタは複数のシュレッドの存在を理解する。仮想マシンのアーキテクチャは、非特権命令およびプロセッサ・リソースについて発生される例外の数を最小化する。

〈デッドロック〉
MAXアーキテクチャではシュレッドがローカルな他のシュレッドによってサスペンドされることができるので、デッドロック回避が複雑になる。アプリケーション・ソフトウェアは、一つのシュレッドがOSに手当てされる例外またはシステムコールを被っても、ローカルなすべてのシュレッドをサスペンドしてしまうデッドロックが生じないことを保証する。

ローカルな（シュレッド間の）通信および同期は、リモートの（スレッド間の）通信および同期とは区別される。ローカルな通信は、共有レジスタ６５５（図５に示してある）または共有メモリのいずれかを使って実行される。リモートの通信は共有メモリを使って実行される。ローカルなデータ同期は原子的なレジスタ更新、レジスタ・セマフォまたはメモリ・セマフォを使って実行される。リモートのデータ同期はメモリ・セマフォを使って実行される。

ローカルおよびリモートのシュレッド制御（生成、破棄）はいずれもMAX命令を使って実行される。シュレッド制御は、wait()またはyield()のためにOSをコールすることはしない。それは所与のスレッド上のあらゆるシュレッドをサスペンドするという意図しない効果を有しうるからである。スレッド維持のために使われるOSコールは、ユーザーレベルのシュレッド・ライブラリへのコールで置き換えられる。シュレッド・ライブラリは今度は、必要に応じてスレッドを生成および破棄するためにOSをコールする。

〈シュレッドとファイバ〉
シュレッドは、従来のOSで実装されるファイバとは異なる。相違は次の表にまとめられている。

表６

〈ハードウェア実装〉
マルチスレッド・アーキテクチャ拡張をサポートするマイクロプロセッサの実装は、チップレベル・マルチプロセッサ（CMP: chip-level multiprocessor）および同時マルチスレッド・プロセッサ（SMT: simultaneous multithreaded processor）の形をとることができる。従来のCMPおよびSMTプロセッサは、CPUリソースの共有をソフトウェアから隠そうとしている。これに対し、マルチスレッド・アーキテクチャ拡張のここでの諸実施形態を実装されたときには、プロセッサは共有をアーキテクチャの一部としてさらけ出す。

MAXプロセッサをチップレベル・マルチプロセッサとして実装するため、システム状態の複数のコピーをCPUコアどうしの間で同期状態に保つために、ブロードキャスト機構が使われる。共有されるアプリケーションおよびシステム状態のために高速通信バスが導入される。オンチップ通信はオフチップのメモリに比べて高速なため、これらの通信バスはMAXプロセッサに、共有メモリ・マルチプロセッサに対するパフォーマンス上の優位性を与える。

MAXプロセッサを同時マルチスレッド・プロセッサとして実装することは、ハードウェアがすでに必要なリソース共有を提供しているので可能である。MAXの実装を、マルチスレッドの３２ビットプロセッサ上でほとんど完全にマイクロコードで行うことも可能である。

ある実施形態によれば、本方法およびシステムは、複数のシュレッドの間でシステムコールおよび例外（OSに報告されるもの）の優先順位付けを可能にする。それにより、いかなる時点においても、一つのシュレッドの要求だけが手当てされる。システム状態は一時には一つのOSサービス要求しか扱えないので、優先順位付けおよび一つの要求の選択は必要である。たとえば、シュレッド１およびシュレッド２が同時にシステムコールを行うとする。優先順位付け手段が、シュレッド１のシステムコールだけが実行されたがシュレッド２のシステムコールはまだ実行が始まっていないことを保証する。公正さへの配慮のため、優先順位付け手段はラウンドロビン選択アルゴリズムを採用するが、他の選択アルゴリズムを使ってもよい。

〈スケーラビリティ〉
MAXプログラミング・モデルのスケーラビリティは次によって決定される。
１）コンテキスト切り換えに際して保存／復元するのが実行可能である状態の量
２）コンテキスト切り換えの間に所与のスレッドに関連するあらゆるシュレッドをサスペンドすることから帰結する、並列度の減少
３）シュレッド間通信
シュレッド数が増加するにつれ、コンテキスト切り換えに際して保存／復元される必要のある状態の量が増加し、全シュレッドをサスペンドする結果として失われる潜在的な並列度が増加する。これら２つの因子が実際的なシュレッド数を制限することになる。

シュレッド間通信もスケーラビリティを制限する。該通信はオンチップリソースを使って実行されるからである。対照的に、伝統的な共有メモリ・マルチプロセッサ・モデルのスケーラビリティはオフチップ通信によって制限される。

〈共有分類〉
次の表には、シュレッドのアーキテクチャ、実装およびソフトウェア使用におけるさまざまな自由度での分類が呈示されている。

表７

MAXアーキテクチャの２つの異なる種類が区別される：均一と不均一である。均一シュレッドは、すべてのシュレッドが同じ命令セットを実行するという点で均一マルチプロセッサと同様である。不均一マルチプロセッサと同様の仕方で、不均一シュレッドも可能である。たとえば、不均一シュレッドは：
・３２ビットプロセッサとネットワークプロセッサ、
・３２ビットプロセッサと６４ビットプロセッサ、
の間で構築されうる。

同様に、根底にあるマイクロアーキテクチャは対称的または非対称的のどちらでもありうる。後者の場合の例としては、若干の大規模な高性能CPUコアと多数の小型低パワーCPUコアを含む、図４に示したようなチップレベル・マルチプロセッサがある。

〈用途モデル〉
次の表は、本マルチスレッド・アーキテクチャ拡張の諸実施形態のためのいくつかの用途モデルをまとめている。

表８

〈プリフェッチ〉
プリフェッチ用途モデルでは、メイン・スレッドは一つまたは複数のヘルパー・スレッドを生み、それがメインメモリからキャッシュラインをプリフェッチするのに使われる。ヘルパー・スレッドが生み出されるのは、メイン・スレッドでのキャッシュミスに応答してである。メインメモリへのアクセスは完了するのに数百から1000CPUクロックを必要とするので、キャッシュミスになった読み込みを失敗としてメインメモリに進むためのアーキテクチャ上の備えがされていない限り、スカラーコードの実行はメインメモリアクセスの間事実上停止することになる。

〈従来式スレッドの置き換え〉
シュレッドは、従来式スレッドの高性能な置き換えとして、マルチスレッド・アプリケーションによって使われることがありうる。ユーザーレベルのソフトウェア・ライブラリが、以前にOSによって実行されたシュレッド管理機能（生成、破棄など）を実行するために提供される。ライブラリは追加的なスレッドを要求するために、必要に応じてOSをコールするほか、シュレッド命令を使用する。ソフトウェア・ライブラリのコールは、コンテキスト切り換えが必要ないためOSコールよりもずっと高速である。

〈コンパイラのための専用実行リソース〉
コンパイラは、レジスタのようなほかのプロセッサ・リソースを使用するのと同じ仕方でシュレッドを使ってもよい。たとえば、コンパイラはプロセッサを８つの整数レジスタ、８つの浮動小数点レジスタ、８つのSSEレジスタおよび４つのシュレッドをもつものと見ることができる。シュレッドをリソースとして扱うことにより、コンパイラは、レジスタ割り当てと類似の仕方でシュレッドを割り当てる。レジスタと同様、アプリケーション・プログラムがハードウェアが提供するよりも多くの仮想シュレッドを要求する場合にシュレッドを補助記憶に散布／充填するための何らかの機構が必要である。従来のアーキテクチャでは、制御の流れは一つしかないので、通常プロセッサ・リソースとは見なされない。

〈管理されたランタイム環境のための専用スレッド〉
管理されたランタイム環境では、シュレッドはガーベッジ・コレクション、ジャストインタイム（just-in-time）コンパイルおよびプロファイリングのような機能の専用とされる。シュレッドはそのような機能を本質的に「無償で」実行する。シュレッドは命令セットアーキテクチャ（ISA）の一部として提供されているからである。ISAは、プロセッサのうち、プログラマーまたはコンパイラ作者に見える部分である。ISAはソフトウェアおよびハードウェアの間の境界のはたらきをする。

〈並列プログラミング言語〉
MAXは並列プログラミング言語およびハードウェア記述言語を直接サポートする。たとえば、iHDLまたはVerilogコンパイラは、ソースコードが明示的に並列であるため、直接的に複数シュレッドのためのコードを生成する。

チップレベル・マルチプロセッサによって可能となったスレッドの増殖はマルチスレッドのための言語サポートにつながる。そのようなサポートはOSおよびランタイム・ライブラリのコールを通じて提供される。マルチスレッドのための言語サポートはメインストリームの汎用プログラミング言語に移行される。

〈統合されたI/O機能をもつCPU〉
シュレッドはネットワーク・コプロセッサのようなI/O機能を実装するために使われる。シュレッドとして実装されるネットワーク・コプロセッサの一つの重要な相違点は、I/Oデバイスとしてではなく、CPUの一部として見えるということである。

従来システムでは、アプリケーション・プログラムが入出力を要求するとき、アプリケーション・プログラムはAPI（application program interface［アプリケーション・プログラム・インターフェース］）を使ってOSをコールする。OSは今度はデバイスドライバをコールして、そのデバイスドライバが要求をI/Oデバイスに送る。OSは複数のアプリケーション・プログラムからのI/O要求を待ち行列化またはシリアル化し、I/Oデバイスが一時には一つの（あるいは有限個の）要求のみを処理することを保証する役目を負う。これは、CPU状態が複数のアプリケーションの間で時間多重化されるのに対してI/Oデバイスの状態がシステムにとってグローバルであるため、必要なことである。

不均一シュレッドとして実装されるI/Oデバイスでは、I/Oデバイスの状態はCPUのアプリケーション状態の拡張として扱われる。アプリケーション・プログラムは、CPUのアプリケーション状態およびI/Oデバイス状態の両方を直接制御する。アプリケーション状態およびI/O状態の両方がコンテキスト切り換えに際してはOSによって保存／復元される。I/Oデバイスは、その状態がいくつかのアプリケーションの間で悪影響なしに時間多重化されることができるよう構成される。

〈同時マルチISAのCPU〉
６４ビットアーキテクチャが、３２ビットアーキテクチャ・アプリケーション・アーキテクチャならびに新しい６４ビット命令セットを「シームレス」として知られる機構を通じて含むよう定義される。３２ビットアーキテクチャの命令セットとの両立により、６４ビットアーキテクチャのプロセッサは新しい６４ビットアーキテクチャのアプリケーションのほか既存の３２ビットアーキテクチャのアプリケーションも走らせることができる。

現行の定義のもとでは、６４ビットアーキテクチャのCPUは、どの時点でも、６４ビットアーキテクチャのスレッドまたは３２ビットアーキテクチャのスレッドのいずれかを走らせる。２つのISAの間の切り換えは、６４ビットアーキテクチャbr.ia（３２ビットアーキテクチャへの分岐）および３２ビットアーキテクチャjmpe（６４ビットアーキテクチャへのジャンプ）を介して達成される。３２ビットアーキテクチャのレジスタは６４ビットアーキテクチャのレジスタにマッピングされるので、状態のコピーは一つしか必要とされない。

いかなる時点においても二つ以上の命令セットアーキテクチャが走っているマルチISAのCPUを創り出すことが可能である。これは、６４ビットアーキテクチャISAのためのシュレッドと３２ビットアーキテクチャISAのための第二のシュレッドを使うことによって達成しうる。均一シュレッドの場合のように、６４ビットアーキテクチャのシュレッドと３２ビットアーキテクチャのシュレッドの両方のために相異なるアプリケーション状態を提供する必要がある。６４ビットアーキテクチャのシュレッドと３２ビットアーキテクチャのシュレッドは同時に走る。

上記のマルチスレッド・アーキテクチャ拡張を通じたユーザーレベルのマルチスレッドを提供するための本方法およびシステムの諸特徴を述べたので、以下では３２ビットシステムのための実施形態を提供する。

〈３２ビットアーキテクチャの実施形態〉
IA-32アーキテクチャを参照しつつ記述しているが、ここに記載される方法およびシステムはIA-64アーキテクチャのような他のアーキテクチャにも適用されうることを読者は理解する。さらに、読者は、本発明のある実施形態に基づく例示的な実行環境を理解するために図５に戻るよう指示される。IA-32にユーザーレベルのマルチスレッド機能をもたらすために、いくつかのレジスタ６５０〜６６０とともに、少数の命令が、IA-32のISAに追加される。

マルチスレッド・アーキテクチャ拡張は次の諸状態からなる：
・拡張を有効／無効にするためにOSまたはBIOSによって使われるモデル固有レジスタ６５０（MAX_SHRED_ENABLE）
・プロセッサが拡張を実装しているかどうかと利用可能な物理シュレッド数とを示す、CPUID拡張機能情報の３ビット
・各シュレッドが独自に専有アプリケーション状態のコピーを有するようにする、アプリケーション状態（EAX, EBXなど）のほとんどの複製
・シュレッド間の通信および同期のために使われうる、共有レジスタSH0-SH7 ６５５の組
・シュレッド管理のために使われる制御レジスタSC0-SC4 ６６０の組

このマルチスレッド・アーキテクチャ拡張は次の命令を有する。
・シュレッドの生成／破棄：forkshred、haltshred、killshred、joinshred、getshred
・通信：共有レジスタ６５５への／からの移動（mov）、共有レジスタ６５５への／からの同期移動
・同期（セマフォ）：cmpxshgsh、xaddsh、xchgsh
・信号伝送：signalshred
・マルチシュレッドモード（multi-shredded mode）への／からの遷移：entermsm、exitmsm
・状態管理：shsave、shrestore
・雑：シュレッド制御レジスタへの／からの移動

さらに、IA-32機構には以下の機能が設けられる。
・IA-32例外機構は、例外に際して（あてはまる場合には）マルチシュレッドモードを終了して全シュレッド状態を保存する
・IA-32のIRET命令は（あてはまる場合には）全シュレッド状態を復元してマルチシュレッドモードに戻る
・ユーザーレベルの例外機構が導入されている。

〈構成設定〉
モデル固有レジスタ（MSR: model specific register）６５０はマルチスレッド・アーキテクチャ拡張を可能にするために使われる。MSRは下記に記述される。

表９

シュレッドMSR６５０のようなモデル固有レジスタは、特権レベル０でのみ書き込みおよび読み出しが行われる。マルチスレッド・アーキテクチャ拡張が有効にされていなければ、旧来のコードの実行はシュレッド番号０に制限される。

表１０

〈CPUID〉
IA-32のCPUID命令は、設けられている物理スレッド数の計数とともに、プロセッサがマルチスレッド・アーキテクチャ拡張をサポートしていることの指標を返すよう修正される。これはECXにおいて返される拡張機能情報に３ビット（NSHRED）を追加することによってなされる。CPUID命令によって返される情報は次の表に与えられている。

表１１

表１２

マルチスレッド・アーキテクチャ拡張が（MAX_SHRED_ENABLE MSRを通じて）有効にされていない場合、拡張機能情報はNSHREDについては000を返す。

〈アーキテクチャ状態〉
マルチスレッド・アーキテクチャ拡張は、全状態を３つの範疇のうちの一つに置く。
・各シュレッドの専有
・ローカルなシュレッドの間で共有
・全シュレッドの間で共有
IA-32状態の前記範疇のそれぞれの内訳は上掲の表２に示されている。シュレッドの専有という状態は、シュレッドごとに一回繰り返される。シュレッドの専有という状態は、各シュレッドにとっての完全な専有である。特に、アーキテクチャは、よそのシュレッドからあるシュレッドの専有レジスタの読み出しや書き込みを個々に行ういかなる命令も提供しない。アーキテクチャが提供するshsaveおよびshrestore命令は、全シュレッドの専有状態のメモリへの読み出しおよび書き込みを集合的に行うためのものであるが、これらの命令は単一シュレッドモードにおいてしか実行されない。シュレッドの共有状態は上掲の表３に示されている。

共有レジスタの組SH0-SH7 ６５５は、シュレッド間の通信および同期のために使われる。これらのレジスタ６５５は共有レジスタへのMOV命令および共有レジスタからのMOV命令を通じて書き込みおよび読み出しが行われる。SH0-SH7レジスタ６５５は３２ビットの整数値を保存する。ある実施形態によれば、８０ビットの浮動小数点６２５および１２８ビットのSSEデータ６４０がメインメモリを通じて共有される。

シュレッド制御レジスタの組SC0-SC4 ６６０が提供される。これらのレジスタは次のように定義される。

表１３

表１４

Yと記されたフラグはシュレッドごとに複製される。Nと記されたフラグは全シュレッドによって共有される単一のコピーを有する。

３２ビットのEFLAGSレジスタ６１５は一群の状態フラグ、一つの制御フラグおよび一群のシステムフラグを含んでいる。プロセッサ１０５の初期化（RESETピンまたはINITピンをアサートすることによる）直後のEFLAGSレジスタ６１５は00000002Hである。このレジスタ６１５のビット１，３、５、１５および２２から３１まではリザーブされており、ソフトウェアはこれらのビットのいずれの状態も使ったり依存したりするべきではない。

EFLAGSレジスタ６１５におけるフラグのいくつかは、専用の命令を使って直接修正できる。レジスタ全体を直接調査または修正できるようにするための命令はない。しかし、次の諸命令は、一群のフラグをプロシージャ・スタックまたはEAXレジスタへ、そしてそれらから移動させるのに使うことができる：LAHF、SAHF、PUSHF、PUSHFD、POPFおよびPOPFD。EFAGSレジスタ６１５の内容がプロシージャ・スタックまたはEAXレジスタに転送されたのち、フラグは、プロセッサのビット操作命令（BT、BTS、BTR、BTC）を使って調査および修正できる。

タスクをサスペンドするとき（プロセッサのマルチタスク機能を使って）、プロセッサは自動的に、EFLAGSレジスタ６１５の状態を、サスペンドされるタスクのためのタスク状態セグメント（TSS: task state segment）に保存する。プロセッサは、自らを新しいタスクにバインドするとき、EFLAGSレジスタ６１５に新しいタスクのTSSからデータをロードする。

割り込みまたは例外ハンドラ・プロシージャへのコールが行われるとき、プロセッサは自動的に、EFLAGSレジスタ６１５の状態をプロシージャ・スタックに保存する。割り込みまたは例外がタスク切り替えを用いて扱われるときは、EFLAGSレジスタ６１５の状態はサスペンドされるタスクのためのTSSに保存される。

〈シュレッド生成／破棄〉
シュレッドはforkshred命令を使って生成されうる。書式は次のとおり。

forkshred imm16, 目標IP
forkshred r16, 目標IP
２つの形が与えられている。一方はシュレッド番号を即値オペランド（immediate operand）としてもち、第二のものはシュレッド番号をレジスタオペランド（register operand）としてもつ。いずれの形についても、目標IPは即値オペランドとして指定され、その値は現在のIPではなく、コードセグメントの先頭（名目上０）を基準とする。

forkshred imm16, 目標IPというエンコードは、長距離ジャンプ（far jump）命令と同様で、シュレッド番号が16ビットのセレクタの代わりに、目標IPが16/32ビットオフセットの代わりになっている。

forkshred命令は適切な実行ビットをSC0に設定し、指定されたアドレスで実行を開始する。ユニックスのfork()システムコールとは異なり、forkshred命令は親シュレッドの状態をコピーしない。新しいシュレッドの実行は、他のすべての専有レジスタの現在の値とともに更新されたEIPを用いて開始される。新しいシュレッドがそのスタックをESPをロードすることによって初期化し、はいってくるパラメータを共有レジスタまたはメモリから取得するべきことが期待されている。forkshred命令は自動的にパラメータを渡すことはしない。

目標シュレッドがすでに走っている場合、forkshredは#SNA（シュレッド利用不能）例外を発生させる。これはのちに述べるようにユーザーレベルの例外である。ソフトウェアは、すでに走っているシュレッドを開始させようとしないことを保証するか、あるいは代替的に、既存のシュレッドを停止させる#SNAハンドラを提供して改めてforkshredの実行に戻る。シュレッド番号がハードウェアによってサポートされる最大シュレッド数より大きい場合には、#GP(0)例外が発生する。

現在のシュレッドの実行を終了させるためには、haltshred命令が使われる。haltshredはSC0における現在のシュレッドの実行ビットをクリアし、現在のシュレッドの実行を終わらせる。シュレッドの専有状態は停止中でさえも保持される。あるシュレッドが別のシュレッドの専有状態にアクセスするいかなる機構も存在しないので、停止したシュレッドの専有状態は見ることができない。しかし、その状態は持続し、そのシュレッドがforkshredを通じて再び実行を開始したときに見えるようになる。

別のシュレッドの実行を途中で打ち切るためには、killshred命令が導入される。書式は次のとおり。

killshred imm16
killshred r16

ある実施形態によれば、シュレッド番号は１６ビットのレジスタまたは即値オペランドである。killshredはSC0における指定されたシュレッドの実行ビットをクリアして、そのシュレッドの実行を打ち切る。停止中、そのシュレッドの専有状態は保持される。

目標シュレッドが走っていない場合には、killshredは黙って無視される。この振る舞いは、killshredと通常に終了するシュレッドとの間の競合を避けるために必要である。killshredを実行したのち、ソフトウェアは、目標シュレッドがもはや走っていないことを保証される。シュレッドはhaltshredを実行する代わりに自らを打ち切る（kill）こともできる。シュレッド番号がハードウェアによってサポートされる最大シュレッド数より大きい場合には、#GP(0)例外が発生する。

指定されたシュレッドが終了する（SC0ビットがクリアされることで示される）まで待つため、joinshred命令が導入される。書式は次の通り。

joinshred imm16
joinshred r16

目標シュレッドが走っていなければ、joinshredはすぐに戻る。この振る舞いが、joinshredと通常に終了するシュレッドとの間の競合を避ける。joinshredを実行したのち、ソフトウェアは、目標シュレッドがもはや走っていないことを保証される。シュレッドがjoinshredを自らに行うことも許される（役には立たないが）。シュレッド番号がハードウェアによってサポートされる最大シュレッド数より大きい場合には、#GP(0)例外が発生する。joinshred命令は自動的に戻り値を渡しはしない。

シュレッドが自らのシュレッド番号を決定できるようにするため、getshred命令が導入される。書式は次のとおり。

getshred r32

getshredは現在のシュレッドの番号を返す。getshredは、シュレッド番号によって指定されるメモリ配列にアクセスするために使われうる。getshred zeroは目的レジスタの全ビットに書き込むために１６ビットシュレッド番号を拡張する。

全シュレッド生成／破棄命令のためには、シュレッド番号はレジスタオペランドまたは即値オペランドのどちらで指定されてもよい。即値形の実行のほうがレジスタ形の実行よりも高速であることが期待される。シュレッド番号が実行時ではなくデコード時において得られるであろうからである。即値形では、コンパイラがシュレッド番号を割り当てる。レジスタ形ではランタイムの割り当てが使用される。

次の表はシュレッドの生成／破棄命令のまとめを呈示している。

表１５

forkshred、haltshred、killshred、joinshred、getshred命令はいかなる特権レベルで実行されてもよい。既存のIA-32のhlt命令が特権命令であるのに対して、haltshredは非特権命令である。

killshredまたはhaltshredの実行の結果走っているシュレッドが０個になる可能性がある。この状態（SC0に0）は既存のIA-32の停止状態とは異なる。SC0は認められている状態である。ただし、ユーザーレベルのタイマー割り込みが生成されるまで有用ではない。

〈通信〉
シュレッドは互いとの通信を、既存の共有メモリを通じて、およびその目的のために特別に導入されたレジスタの組を通じて行う。共有レジスタSH0-SH7 ６５５は同じスレッドに属するすべてのローカルシュレッドによってアクセス可能である。SH0-SH7レジスタ６５５は、はいってくるパラメータをシュレッドに渡し、シュレッドからの戻り値を通信し、セマフォ動作を実行するために使われうる。各目的のために特定の共有レジスタ６５５はソフトウェアの慣例によって割り当てられる。

各共有レジスタ６５５は対応する空き／充満ビットをSC3に有している。共有レジスタ６５５に書き込みおよび読み出しをするためには、共有レジスタ６５５にMOV、および共有レジスタ６５５からMOVの命令が使われる。これらは次のようにまとめられる。

mov r32,sh0-sh7
mov sh0-sh7,r32

命令のエンコードは既存の制御レジスタ６６０への／からのMOV、およびデバッグ・レジスタへの／からのMOVの命令と同様である。共有レジスタへの／からのMOV命令はいかなる特権レベルで実行されてもよい。これらの命令は、ソフトウェアが追加的な命令を使って同期を明示的に実行することを想定している。共有レジスタへの／からのmovは、SC3の空き／充満ビットの状態を調べることも、修正することもしない。

共有レジスタ６５５へのMOV、および共有レジスタ６５５からのMOVの遅延は、共有メモリへのロードおよび保存の遅延より低いことが期待される。ハードウェア実装は、共有レジスタ６５５を見込みで読んで、他のシュレッド書き込みをせんさくすることがありそうである。ハードウェアは、共有レジスタ６５５に書き込むときには、強い順序付けの等価物を保証しなければならない。代替的な実施形態では、共有レジスタ６５５にアクセスするためにバリア命令が生成されることができる。

あるアーキテクチャ特徴により、共有レジスタの順序付けとメモリの順序付けは互いから別個のものに保たれる。よって、あるシュレッドが共有レジスタ６５５に書き込み、次いでメモリ１２０に書き込む場合、共有レジスタ６５５の内容が共有メモリ内容より先に見える保証はない。この定義の理由は、不必要なメモリバリアを創り出すことなく、共有レジスタ６５５におけるループカウンタの高速アクセス／更新を可能にすることである。ソフトウェアが共有レジスタ６５５とメモリの両方にバリアを要求する場合、ソフトウェアは共有レジスタ・セマフォをメモリ・セマフォとともに両方実行する。メモリ・セマフォはバリアとしてはたらくことのほかは冗長である。

同期のほかに迅速な通信を提供するため、共有レジスタへの／からの同期mov命令が使われる。これらの命令は次のようにまとめられる。

syncmov r32,sh0-sh7
syncmov sh0-sh7,r32

命令エンコードは、既存の制御レジスタ６６０への／からのMOV、およびデバッグ・レジスタへの／からのMOVの命令とパラレルである。共有レジスタ６５５への同期movは、共有レジスタ６５５への書き込みの前に空き／充満ビットが空きを示すまで待つということのほかは、その非同期の対応物と同様である。共有レジスタ６５５への書き込み後、空き／充満ビットは充満に設定される。共有レジスタ６５５からの同期movは、共有レジスタ６５５から読む前に空き／充満ビットが充満を示すまで待つということのほかは、その非同期の対応物と同様である。共有レジスタ６５５から読んだのち、空き／充満ビットはクリアされて空きにされる。

空き／充満ビットは、下記に述べるようにSC3への移動を用いて初期化されうる。共有レジスタへの／からの同期MOV命令はいかなる特権レベルで実行されてもよい。共有レジスタ通信命令は次のようにまとめられる。

表１６

〈同期〉
一組の同期プリミティブが共有レジスタ６５５に作用する。同期プリミティブは、メモリでなく共有レジスタ６５５に作用するということのほかは、既存のセマフォ命令と同様である。命令は次の通り。

表１７

同期プリミティブはいかなる特権レベルでも実行される。これらの命令は、SC3の空き／充満ビットの状態を調べることも、修正することもしない。

〈マルチシュレッドモードの開始／終了〉
MAXアーキテクチャはマルチシュレッドモードと単一シュレッドモードの間の切り換えをする機構を提供する。単一シュレッドモードは、プロセッサが、一つを除いたすべてのシュレッドの実行を停止することによって秩序だった仕方でコンテキスト切り換えを実行できるようにする。SC0は現在の動作モードを次のように示す：
・どのビット位置であれちょうど一つの1を含むSC0は単一シュレッドモードを含意する。
・どのビット位置であれ一つの1という以外のパターンを含むSC0はマルチシュレッドモードを表す。

コンテキスト切り換えを実行するためには次のことが必要である：
１）単一シュレッドモードに切り換えることによって一つを除いたすべてのシュレッドをサスペンドする。
２）シュレッド状態を保存する。
３）新しいシュレッド状態をロードする。
４）マルチシュレッドモードに切り換えることによってすべてのシュレッドの実行を再開する。

マルチシュレッドモード（multi-shredded mode）および単一シュレッドモードに切り換えるためには、それぞれentermsmおよびexitmsmが使われる。entermsmはマルチシュレッドモードにはいるために使われる。この命令の実行に先立って、全シュレッドの状態がロードされる必要がある。entermsmはSC1の新しいシュレッド実行ベクトルをSC0にコピーする。entermsmは次いで指定された諸シュレッドを開始させる。

entermsmの実行後、SC1の内容が全く追加的なシュレッドの実行をもたらさないことも可能である。この場合、プロセッサは単一シュレッドモードに留まる。entermsmを実行した結果として、entermsmが実行されたシュレッドがもはや走っていなくなることも可能である。マルチシュレッドモードを終了するにはexitmsmが使われる。exitmsmはSC0の現在のシュレッド実行ベクトルをSC1にコピーする。exitmsmを実行するシュレッドに対応するもの以外のすべてのSC0実行ビットはクリアされる。exitmsmを実行するシュレッド以外のすべてのシュレッドは停止される。これらの動作は原子的なシーケンスで実行される。SC0状態は単一シュレッドモードを示す。entermsmおよびexitmsmはいかなる特権レベルで実行されてもよい。

〈状態管理〉
命令（shsaveおよびshrestore）は、集合的なシュレッド状態をそれぞれ保存および復元するため、すなわち全シュレッドの専有状態の内容をメモリに書き込むため、および全シュレッドの専有状態をメモリから読み出すために使われる。書式は次のとおり。

shsave m16384
shrestore m16384

メモリ保存領域のアドレスは、命令中の偏位によって指定される。アドレスは１６バイトの境界に整列させられる。メモリ保存領域は将来の拡張を許容するため、16キロバイトである。メモリ保存領域は、既存のFXSAVE／FXRESTOR書式を整数レジスタを追加することによって拡張する。各シュレッドのためのメモリ保存領域は次のように定義される。

表１８

全シュレッドの内容は次式で与えられるアドレスに保存／復元される：
アドレス＝512×（シュレッド番号）＋（ベースアドレス）
メモリ保存領域は現在走っているシュレッドのEIPおよびESPを含む。shsaveは現在のEIPおよびESPをメモリに書き込む。分岐を避けるため、shrestore命令は現在のシュレッドのEIPやESPを上書きすることはしない。shrestore関数は、IRETの一部として実行されたとき、現在のシュレッドのEIPおよびESPを上書きする。

shsaveおよびshrestoreはいかなる特権レベルで実行されてもよいが、単一シュレッドモードにあるときのみである。マルチシュレッドモードにあるときにshsaveまたはshrestoreが試みられると、#GP(0)例外が発生する。実装では、shsave／shrestoreの保存／ロード動作を実行するために利用可能な全ハードウェアリソースを自由に使用できる。

shrestoreは無条件に、全シュレッドの状態をメモリからロードする。この振る舞いは、シュレッドの専有状態が一つのタスクから次のタスクへ漏れないことを保証するために必要である。shsaveは、無条件にまたは条件付きで、全シュレッドの状態をメモリに保存する。ある実装では、専有状態が修正されなかった場合にshsaveの保存動作の一部または全部をスキップするよう非アーキテクチャ的可視のダーティー・ビット（dirty bits）を維持しうる。

shsaveおよびshrestore命令はシュレッドの専有状態のみを保存および復元する。共有レジスタ６５５を保存および復元することはOSの責任である。

〈シュレッド制御レジスタ６６０への／からの移動〉
シュレッド制御レジスタSC0-SC4 ６６０に書き込み、そこから読み出すための命令が提供されている。それは次のようにまとめられる。

mov r32,sc-sc4
mov sc0-sc4,r32
命令エンコードは既存の制御レジスタ６６０への／からのMOV、およびデバッグ・レジスタへの／からのMOVの命令と同様である。シュレッド制御レジスタへの／からのMOV命令はいかなる特権レベルで実行されてもよい。悪意のあるアプリケーション・プログラムがシュレッド制御レジスタに書き込むことによって自分以外の何らかのプロセスに影響できないことを保証するための安全措置が設けられる。

アプリケーション・プログラムは、SC0の内容を直接操作するのではなく、forkshredおよびjoinshredを使う。exitmsmはマルチシュレッドモードから単一シュレッドモードへの遷移を原子的な仕方で行う。現在のシュレッド実行状態を読むためにSC0からのmovを使い、次いでシュレッド実行状態を書き込むためにSC0へのmovを使うことのでは、シュレッド実行状態が読み出しと書き込みの間で変化しうるので、所望の結果が得られないのである。

〈OS例外〉
MAXは、IA-32例外機構のためにいくつかの関わりを有する。まず、ユーザーレベルの例外機構により、いくつかの型の例外がそれを発生させたシュレッドに直接報告されることが可能になる。この機構については後述する。

次に、IA-32例外機構は、コンテキスト切り換えを必要とする例外が存在する場合に複数のシュレッドを適正に処理するよう修正される。従来のIA-32例外機構に関する一つの問題は、ちょうど一つの実行中スレッドのためにCS、EIP、SS、ESP、EFLAGSを自動的に保存および復元するよう定義されているということである。

既存のIA-32例外機構は、entermsm、exitmsm、shsave、shrestore命令の機能性を含むよう拡張される。コンテキスト切り換えを必要とする割り込みまたは例外が発生させられると、例外機構は次のことをする：
１）exitmsmを実行することによりマルチシュレッドモードを終了する。exitmsmは、その割り込みまたは例外を引き起こしているもの以外のすべてのシュレッドを停止させる。OSはその割り込みまたは例外を引き起こしたシュレッドを使ってはいられる。
２）SC2によって与えられる開始アドレスでshsaveを実行することにより、全シュレッドの現在の状態をメモリに保存する。
３）現在定義されているようなIA-32コンテキスト切り換えを実行する。

マルチシュレッドプログラムに戻るためには、修正されたIRET命令は次のことを実行する：
１）現在定義されているようなIA-32コンテキスト切り換えを実行する。
２）SC2によって与えられる開始アドレスでshrestoreを実行することにより、全シュレッドの現在の状態をメモリから復元する。これはIA-32コンテキスト切り換えにおいて保存されたEIPおよびESPを上書きする。
３）entermsmを実行することによりマルチシュレッドモードにはいる。SC1の状態によっては、entermsmの実行は、プロセッサをして単一シュレッドモードに留まらせることもある。

OSは、IRETを実行するのに先立って、メモリ中にシュレッド状態の保存／復元領域を設定してそのアドレスをSC2にロードするよう要求される。OSはまた、SC1、SC3、SC4の状態を保存／復元することも要求される。

複数のシュレッドがOSのサービスを必要とする例外に同時に遭遇する可能性がある。MAXアーキテクチャは一時には一つのOS例外しか報告できないので、ハードウェアは複数のシュレッドにわたるOS例外を優先順位付けし、ちょうど一つを報告して、他のすべてのシュレッドの状態を例外を発生させた命令がまだ実行されていない時点に設定する必要がある。

〈ユーザーレベルの例外〉
MAXは、ある型の例外が完全にアプリケーション・プログラム内で処理されることを可能にする、ユーザーレベルの例外機構を導入する。いかなるOS関与、特権レベル遷移あるいはコンテキスト切り換えも必要でない。

ユーザーレベルの例外が生起すると、次の未実行命令のEIPがスタックにプッシュされ、プロセッサは指定されたハンドラに差し向けられる。ユーザーレベルの例外ハンドラはそのタスクを実行し、次いで既存のRET命令を介して戻る。ある実施形態によれば、ユーザーレベルの例外をマスクするためにいかなる機構も設けられない。アプリケーションがユーザーレベルの例外を発生させるのは、該アプリケーションがそれを手当てする用意があるときのみであると想定されるからである。

最初の二つのユーザーレベル例外を生成するために、２つの命令が提供される：signalshredおよびforkshredである。これらについて以下の節で述べる。

〈信号伝送〉
signalshred命令は、指定されたシュレッドに信号を送るために使用される。書式は次のとおり。

signalshred imm16, 目標IP
signalshred r16, 目標IP
目標シュレッドはレジスタオペランドまたは即値オペランドとして指定されうる。signalshred imm16, 目標IPという命令のエンコードは、既存の長距離ジャンプ命令と同様で、シュレッド番号が16ビットのセレクタの代わりに、目標IPが16/32ビットオフセットの代わりになっている。長距離ジャンプの場合と同様、signalshredの目標IPは、現在のIPを基準にするのではなく、コードセグメントの先頭（名目上０）を基準として指定される。

signalshredに応答して、目標シュレッドは、次の未実行命令のEIPをスタックにプッシュし、指定されたアドレスに差し向けられる。シュレッドは自分に信号を送ってもよく、その場合、効果は近距離コール（near call）命令を実行するのと同じである。目標シュレッドが走っていない場合には、signalshredは黙って無視される。シュレッド番号がハードウェアによってサポートされる最大シュレッド数より大きい場合には、#GP(0)例外が発生する。

signalshred命令はいかなる特権レベルで実行されてもよい。signalshred命令は目標シュレッドにパラメータを自動的に渡すことはしない。signalshredをブロックするためのいかなる機構も設けられていない。よって、ソフトウェアは、signalshredを発する前にブロック機構を実装するか、あるいはネスト可能なsignalshredハンドラを設けるかする必要がありうる。

〈シュレッド利用不能（SNA: Shred Not Available）〉
forkshredは、プログラムがすでに走っているシュレッドを開始させようとした場合には#SNA例外を発生させる。ソフトウェアの#SNAハンドラは既存のシュレッドに対してkillshredを実行して、forkshred命令に戻りうる。

#SNA例外は、forkshred命令のEIPをスタックにプッシュし、SC4+0によって与えられるアドレスに差し向けることによって処理される。SC4+0のところにあるコードは実際のハンドラに分岐すべきである。例外ベクトルはSC4+16、SC4+32などに置かれる。ソフトウェアは、256とおりの可能なユーザーレベル例外をカバーするためにSC4+4095までのメモリをリザーブしている。メモリ／SC4機構内の割り込み表は、のちの時刻においてよりクリーンな機構で置き換えられる。

〈サスペンド／再開とシュレッド可視化〉
マルチスレッド・アーキテクチャ拡張は、ユーザーレベルのソフトウェアが以下のような命令を使ってシュレッドをサスペンドまたは再開することを許容する。シュレッドをサスペンドするための命令：
１）メモリ中のシュレッド状態保存領域を初期化する。これは、サスペンド動作のためにアプリケーション・プログラムによって設定されたメモリ領域であって、SC2とポイントされるコンテキスト切り換えシュレッド状態領域とは異なる。
２）サスペンド・ハンドラをポイントするシュレッドに信号を送る。これはsignalshred 目標シュレッド, サスペンド・ハンドラIP を通じて行われる。
３）サスペンド・ハンドラが既存のmov, pusha, fxsave命令を使ってそのシュレッドの専有状態をメモリに保存する。
４）サスペンド・ハンドラがhaltshredを実行する。
５）オリジナルコードがjoinshredを実行してシュレッドが停止するまで待つ。

サスペンド動作の時点でシュレッドがすでに停止されているかもしれないことが可能である。この場合、signalshredは無視され、サスペンド・ハンドラは呼び出されることがなく、joinshredが待つこともない。メモリ中のシュレッド状態保存領域はその初期値を保持するが、該初期値はすぐにhaltshredを実行するダミーシュレッドをポイントする必要がある。シュレッドを再開するには、逆の動作が実行される。
１）再開ハンドラをポイントするシュレッドをフォークする。これは、forkshred 目標シュレッド, 再開ハンドラIP を通じて行われる。
２）再開ハンドラが既存のmov, popa, fxrestor命令を使ってシュレッドの専有状態をメモリから復元する。
３）再開ハンドラが既存のRET命令を通じてシュレッドに復帰する。

再開先のスレッドがすでに停止されているときには、再開ハンドラは、すぐにhaltshredを実行するダミーシュレッドにRETする。サスペンド／再開機能は、シュレッド可視化の可能性を開く。forkshredを実行する前に、ソフトウェアは同じシュレッド番号をもつ既存のシュレッドをサスペンドすることを選ぶことができる。joinshredを実行したのちに、ソフトウェアは同じシュレッド番号をもつ既存のシュレッドを再開することを選ぶことができる。サスペンド／再開シーケンスは再入可能ではないので、いかなる所与の時刻にもいかなる所与のシュレッドについても実行されているサスペンド／再開が一つだけであることを保証するための、ソフトウェアの決定的なセクションが必要である。これらの機構を使って、アプリケーション・プログラムが独自のプリエンプティブなシュレッド・スケジューラを生成することが可能である。

MAXの代替的な実施形態では、最初の利用可能なシュレッドを使ってフォークするための命令が存在する（allocforkshred r32）。ここでr32は割り当てられたシュレッド番号を用いて書かれる（forkshredではr32はフォークすべきシュレッド番号を指定する）。allocforkshredは、利用可能なハードウェア・シュレッドがあるかどうかを示すフラグをも返す。

別の実施形態では、waitshred命令が、共有レジスタを使った待機同期を提供する（waitshred sh0-sh7, imm）。wait命令は待機機能を命令として提供する。この命令がなければ、次のようなループを使う必要がある。

loop: mov eax, sh0
and eax, mask
jz loop
別の実施形態では、joinshredは、複数のシュレッド上で待機するためのビットマスクを与えられる。ビットマスクがなければ、joinshredは一つのシュレッドが終了するのを待ち、複数のシュレッド上で待機するためには複数のjoinshredが必要とされる。

ある代替的な実施形態では、killshredは使用されない。signalshredとそれに続くjoinshredがkillshredの代わりに使用されうる。signalshredハンドラはhaltshred命令からなる。

さらに別の実施形態では、forkshredとsignalshredを組み合わせることが可能である。forkshredとsignalshredは、シュレッドが現在走っているか停止しているかに関する振る舞いでしか違わない。signalshredが停止されているシュレッドを開始させることを許容されれば、signalshredは可能性としてはforkshredの代わりになることができる。

図７は、本発明のある実施形態に基づく、ユーザーレベルのマルチスレッドの例示的なプロセスの流れ図である。次に述べるプロセスはアプリケーションまたはソフトウェア・プログラムによって開始されたと想定されている。次に述べるプロセスはいかなる特定のプログラムとの関連でもなく、上記の命令およびアーキテクチャによって達成されるユーザーレベルのマルチスレッドの一つの実施形態として記述される。さらに、次に述べるプロセスは、１６ビット、３２ビット、６４ビット、１２８ビットあるいはそれ以上のいずれのアーキテクチャであろうと、マルチプロセッサのようなマイクロプロセッサのISAとの関連で実行される。マルチプロセッサ（プロセッサ１０５のような）は、共有レジスタ、たとえば上掲の表３のレジスタの値を初期化する（処理ブロック７０５）。プロセッサ１０５はシュレッドを生成するforkshred命令を実行する（処理ブロック７１０）。複数の並行動作がプロセッサ１０５によって実行される。主（親）シュレッドがプロセッサ１０５によって実行される（処理ブロック７１５）。joinshred動作が実行されて、新しい目標シュレッドが実行を完了するのを待つ（処理ブロック７３０）。その間、新しい目標シュレッドはそのスタックを初期化し、はいってくるパラメータを共有レジスタおよび／またはメモリから取得し（処理ブロック７２０）、実行する（処理ブロック７２１）。現在の目標シュレッドの実行はhaltshred命令を使って終了される（処理ブロック７２３）。プロセッサ１０５は、実行結果を、シュレッドの実行結果が保存されているレジスタからプログラムまたはアプリケーションに返す（処理ブロック７３５）。ひとたびすべての実行されたデータが返されたら、プロセスは完了する（終了ブロック７９９）。

ユーザーレベルのマルチスレッドを提供するための方法およびシステムが開示されている。本発明のここでの諸実施形態は、特定の例およびサブシステムに関連して述べられてきたが、当業者には、本発明のここでの諸実施形態がそれらの特定の例またはサブシステムに限定されるものではなく、他の実施形態にも広がることは明らかであろう。本発明のここでの諸実施形態は、付属の請求項において規定される、これらの他の諸実施形態のすべてを含むものである。

国際公開第2005/098624号の特許請求の範囲を記載しておく。
〔請求項１〕
非特権ユーザーレベルプログラミング命令に遭遇し、
前記プログラミング命令に反応して、一つまたは複数の他のシュレッド（共有リソース・スレッド）と仮想メモリアドレス空間を共有する第一のシュレッドを生成し、
前記プログラミング命令に反応して、前記シュレッドを前記一つまたは複数の他のシュレッドのうちの少なくとも一つと並行して実行する、
ことを含む方法であって、前記シュレッドの生成が、オペレーティング・システムの介入なしにハードウェアにおいて実行されることを特徴とする方法。
〔請求項２〕
請求項１記載の方法であって、さらに：
前記第一のシュレッドおよび前記一つまたは複数の他のシュレッドを含む、ある第一のスレッドに関連付けられた複数のシュレッドの間である状態を共有し、
その一方で、ある第二のスレッドに関連付けられた第二のシュレッドとは前記状態を共有しないことを特徴とする方法。
〔請求項３〕
前記のシュレッドおよび前記一つまたは複数の他のシュレッドが、現在の特権レベルを共有し、共通のアドレス変換を共有することを特徴とする、請求項１記載の方法。
〔請求項４〕
シュレッド破棄動作をエンコードする非特権ユーザーレベルプログラミング命令を受け取ることをさらに含むことを特徴とする、請求項１記載の方法。
〔請求項５〕
前記第一のシュレッドと前記一つまたは複数のシュレッドのうちの少なくとも一つとの間で通信することをさらに含むことを特徴とする、請求項１記載の方法。
〔請求項６〕
前記通信が一つまたは複数の共有レジスタを介して実行されることを特徴とする、請求項５記載の方法。
〔請求項７〕
前記通信がユーザーレベルのシュレッド信号伝送命令を介して実行されることを特徴とする、請求項５記載の方法。
〔請求項８〕
オペレーティング・システムの介入なしにユーザーレベルのアプリケーションが前記第一のシュレッドを実行のためにスケジューリングすることを特徴とする、請求項１記載の方法。
〔請求項９〕
コンテキスト切り換え要求の受領に反応して、前記一つまたは複数のシュレッドに対応する一つまたは複数のシュレッド状態を保存する、
ことをさらに含むことを特徴とする、請求項１記載の方法。
〔請求項１０〕
オペレーティング・システムの介入なしに、ユーザーレベルの例外ハンドラコードにより、前記第一のシュレッドの実行の間に発生した例外を扱う、
ことをさらに含むことを特徴とする、請求項１記載の方法。
〔請求項１１〕
複数の命令を実行する、複数の命令シーケンサを含む諸実行リソースを有する装置であって、
前記諸実行リソースが、非特権ユーザーレベル命令を受け取るものであり、
前記諸実行リソースがさらに、受け取った命令に反応して、一つまたは複数の他のシュレッドと並行してあるシュレッドの実行を開始するものである、
ことを特徴とする装置。
〔請求項１２〕
前記諸シュレッドのうちの二つ以上の間での通信を容易にするための一つまたは複数の共有シュレッド・レジスタ、
をさらに有することを特徴とする、請求項１１記載の装置。
〔請求項１３〕
前記一つまたは複数の共有レジスタがある第一のレジスタを含んでおり、該第一のレジスタによって、オペレーティング・システムまたはBIOSがユーザーレベル・マルチスレッド機能のためのマルチスレッド・アーキテクチャ拡張を有効にすることが可能となっていることを特徴とする、請求項１２記載の装置。
〔請求項１４〕
前記シュレッドおよび前記一つまたは複数の他のシュレッドが現在の特権レベルを共有しており、共通のアドレス変換を共有していることを特徴とする、請求項１１記載の装置。
〔請求項１５〕
前記諸実行リソースがさらに、前記受け取った命令に反応して、オペレーティング・システムの介入なしに、一つまたは複数の他のシュレッドと並行してあるシュレッドの実行を開始することを特徴とする、請求項１１記載の方法。
〔請求項１６〕
前記諸実行リソースが複数のシュレッドを並行して実行することのできる一つまたは複数のプロセッサコアを含むことを特徴とする、請求項１１記載の方法。
〔請求項１７〕
ある命令セットアーキテクチャ（ISA）を実装する、複数の並行シュレッドを実行できるマイクロプロセッサと、
メモリ、
とを有するシステムであって、前記ISAがユーザーレベルのマルチスレッド動作を許容するための一つまたは複数の命令を含むことを特徴とするシステム。
〔請求項１８〕
前記一つまたは複数の命令が、オペレーティング・システムの介入なしにシュレッドを生成する命令を含むことを特徴とする、請求項１７記載のシステム。
〔請求項１９〕
前記一つまたは複数の命令が、オペレーティング・システムの介入なしにシュレッドを破棄する命令を含むことを特徴とする、請求項１７記載のシステム。
〔請求項２０〕
前記ユーザーレベルのマルチスレッド動作が、同一のスレッドに関連付けられた二つ以上のシュレッドの並行的な実行を含むことを特徴とする、請求項１７記載のシステム。

７０１ 開始
７０５ 共有レジスタの値を初期化
７１０ forkshredを実行
７１５ 主シュレッドを実行
７２０ 共有レジスタから値を読む
７２１ シュレッドを実行
７２２ 共有レジスタにシュレッド実行結果を書き込む
７２３ haltshredを実行
７３０ join動作を実行
７３５ シュレッド実行から返される値をレジスタから読む
７９９ 終了

Claims (22)

1. ユーザー・レベルのマルチスレッド機能を提供するプロセッサ内の装置であって、
   第一の非特権ユーザー命令によって生成される第一のシュレッドについての、共有リソース・スレッド（「シュレッド」）毎のアプリケーション状態を保持する第一のリソースと、
   第二の非特権ユーザー命令によって生成される第二のシュレッドについての、シュレッド毎のアプリケーション状態を保持する、前記第一のリソースの複製を含む第二のリソースであって、前記第一のシュレッドは、前記アプリケーション状態の共有される部分および共有されるシステム状態を少なくとも前記第二のシュレッドと共有する、第二のリソースと、
   前記アプリケーション状態の共有される部分および前記共有されるシステム状態を共有するシュレッドに専有の複製されていない共有リソースとを含み、前記複製されていない共有リソースは、前記第一のシュレッドと前記第二のシュレッドとの間の通信を提供するために、少なくとも、前記第一のシュレッドによって第三の非特権ユーザー命令を通じて、および前記第二のシュレッドによって第四の非特権ユーザー命令を通じて、直接アクセス可能であり、前記複製されていない共有リソースの各共有される状態要素が、前記第三および第四の非特権ユーザー命令を使った同期アクセスのための対応する単一の共有される空き／充満ビットを有する、
   装置。
2. 前記第三の非特権ユーザー命令が、前記複製されていない共有リソースの共有される状態要素への書き込みの前に前記空き／充満ビットが空きを示すまで待つ同期書き込みを実行する、請求項１記載の装置。
3. 前記第四の非特権ユーザー命令が、前記複製されていない共有リソースの共有される状態要素からの読み出しの前に前記空き／充満ビットが充満を示すまで待つ同期読み出しを実行する、請求項１記載の装置。
4. 前記複製されていない共有リソースが32ビット・アーキテクチャで使うための32ビットの共有される状態要素を有する、請求項１記載の装置。
5. 前記複製されていない共有リソースが64ビット・アーキテクチャで使うための64ビットの共有される状態要素を有する、請求項１記載の装置。
6. 前記第三の非特権ユーザー命令が、前記複製されていない共有リソースの共有される状態要素への書き込みに際して対応する空き／充満ビットを充満を示すよう設定する同期書き込みを実行する、請求項１記載の装置。
7. 前記第四の非特権ユーザー命令が、前記複製されていない共有リソースの共有される状態要素からの読み出しに際して対応する空き／充満ビットを空きを示すよう設定する同期読み出しを実行する、請求項１記載の装置。
8. 前記第三の非特権ユーザー命令が、前記複製されていない共有リソースの共有される状態要素への書き込みの前に前記空き／充満ビットが空きを示すかどうかを調べない非同期書き込みを実行する、請求項１記載の装置。
9. 前記第四の非特権ユーザー命令が、前記複製されていない共有リソースの共有される状態要素からの読み出しの前に前記空き／充満ビットが充満を示すかどうかを調べない非同期読み出しを実行する、請求項１記載の装置。
10. 前記複製されていない共有リソースがレジスタである、請求項１記載の装置。
11. ユーザー・レベルのマルチスレッド機能を提供するプロセッサ・システムであって、
    第一の組の複製された専有状態リソースを有する第一のユーザー・レベルのスレッドを生成するフォーク命令を実行し、第二の組の複製された専有状態リソースを有する第二のユーザー・レベルのスレッドを生成するもう一つのフォーク命令を実行する実行ユニットであって、前記ユーザー・レベルのスレッドは、前記アプリケーション状態の共有される部分および共有されるシステム状態を少なくとも前記第二のユーザー・レベルのスレッドと共有する、実行ユニットと；
    前記アプリケーション状態の共有される部分および前記共有されるシステム状態を共有するシュレッドに専有の一組の複製されていない共有される状態リソースであって、前記第一のユーザー・レベルのスレッドによって実行される同期ユーザー・レベル命令書き込みおよび前記第二のユーザー・レベルのスレッドによって実行される同期ユーザー・レベル命令読み出しを通じて前記第一および第二のユーザー・レベルのスレッドの間の同期を提供する一組の複製されていない共有される状態リソースとを有しており、前記スレッドはいずれも前記一組の複製されていない共有される状態リソースの同じ共有される状態要素にアクセスし、前記一組の複製されていない共有される状態リソースの各共有される状態要素が、前記同期ユーザー・レベル命令書き込みおよび同期ユーザー・レベル命令読み出しを使ったそれぞれ同期書き込みアクセスおよび同期読み出しアクセスのための対応する単一の共有される空き／充満ビットに関連付けられている、
    プロセッサ・システム。
12. 前記同期ユーザー・レベル命令書き込みが、前記一組の複製されていない共有される状態リソースの共有される状態要素への書き込みの前に前記空き／充満ビットが空きを示すまで待つ、請求項１１記載のプロセッサ・システム。
13. 前記同期ユーザー・レベル命令読み出しが、前記一組の複製されていない共有される状態リソースの共有される状態要素からの読み出しの前に前記空き／充満ビットが充満を示すまで待つ、請求項１１記載のプロセッサ・システム。
14. 前記一組の複製されていない共有される状態リソースが32ビット・アーキテクチャで使うための32ビットの共有される状態要素を有する、請求項１１記載のプロセッサ・システム。
15. 前記一組の複製されていない共有される状態リソースが64ビット・アーキテクチャで使うための64ビットの共有される状態要素を有する、請求項１１記載のプロセッサ・システム。
16. 前記一組の複製されていない共有される状態リソースがまた、前記第二のユーザー・レベルのスレッドによって実行される同期ユーザー・レベル命令書き込みを通じても前記第一および第二のユーザー・レベルのスレッドの間の同期を提供する、請求項１１記載のプロセッサ・システム。
17. 前記一組の複製されていない共有される状態リソースがまた、前記第一のユーザー・レベルのスレッドによって実行される同期ユーザー・レベル命令読み出しを通じても前記第一および第二のユーザー・レベルのスレッドの間の同期を提供する、請求項１１記載のプロセッサ・システム。
18. 前記一組の複製されていない共有される状態リソースがまた、前記第二のユーザー・レベルのスレッドによって実行される非同期ユーザー・レベル命令書き込みを通じても前記第一および第二のユーザー・レベルのスレッドの間の同期を提供する、請求項１１記載のプロセッサ・システム。
19. 前記一組の複製されていない共有される状態リソースがまた、前記第一のユーザー・レベルのスレッドによって実行される非同期ユーザー・レベル命令読み出しを通じても前記第一および第二のユーザー・レベルのスレッドの間の同期を提供する、請求項１１記載のプロセッサ・システム。
20. 前記同期ユーザー・レベル命令書き込みが、前記一組の複製されていない共有される状態リソースの共有される状態要素への書き込みに際して対応する空き／充満ビットを充満を示すよう設定する、請求項１１記載のプロセッサ・システム。
21. 前記同期ユーザー・レベル命令読み出しが、前記一組の複製されていない共有される状態リソースの共有される状態要素からの読み出しに際して対応する空き／充満ビットを空きを示すよう設定する、請求項１１記載のプロセッサ・システム。
22. 前記一組の複製されていない共有される状態リソースがレジスタである、請求項１１記載のプロセッサ・システム。

Images