JP4964243B2 - プロセッサ方法と装置 - Google Patents

Description

［関連出願との相互参照］
本出願は、本願と同日に出願された、本出願と譲受人が共通する特許文献１に関連し、その開示内容全体をここに援用する。
本出願はまた、本願と同日に出願された、本出願と譲受人が共通する特許文献２に関連し、その開示内容全体をここに援用する。
本出願はまた、本願と同日に出願された、本出願と譲受人が共通する特許文献３に関連し、その開示内容全体をここに援用する。
本出願はまた、本願と同日に出願された、本出願と譲受人が共通する特許文献４に関連し、その開示内容全体をここに援用する。
US patent application 11/238,087 entitled "SPU TASK MANAGER FOR CELL PROCESSOR" to John P. Bates, Payton R. White, Richard Stenson, Howard Berkey, Attila Vass and Mark Cerny. US patent application 11/238,095 entitled "CELL PROCESSOR TASK AND DATA MANAGEMENT" to Richard B. Stenson and John P. Bates. US patent application 11/238,086 entitled "OPERATING CELL PROCESSORS OVER A NETWORK" to Tatsuya Iwamoto. US patent application 11/238,085 entitled "METHOD AND SYSTEM FOR PERFORMING MEMORY COPY FUNCTION ON A CELL PROCESSOR" to Antoine Labour John P. Bates and Richard B. Stenson.

［技術分野］
本発明は一般には並列処理に関し、特にセルプロセッサにおける様々のプログラミングモデルにわたるスケジューリングに関する。

電子計算における主な進歩は、同時に複数の演算を実行することができるシステムが開発されてきたことである。そのようなシステムは、並行処理の実行と称されている。最近では、ハンドヘルド・ゲームデバイスからメインフレームコンピュータに至るまで、電子デバイス上で並列処理を実行するために、セルプロセッサが開発されている。典型的なセルプロセッサはパワープロセッサユニット（ＰＰＵ；Power processor unit）と８個までのシナジスティックプロセッシングユニット（ＳＰＵ；synergistic processing units）と呼ばれる付加的なプロセッサをもつ。各ＳＰＵは典型的には、メインプロセッサとコプロセッサを含むシングルチップまたはシングルチップの一部である。すべてのＳＰＵとＰＰＵは、たとえばメモリフローコントローラ（ＭＦＣ）を通して、メインメモリにアクセスすることができる。ＳＰＵはメインプロセッサ上で走るプログラムと連結して演算を並列処理することができる。ＳＰＵは小さなローカルメモリ（典型的には２５６キロバイト）をもつ。ローカルメモリはソフトウエアコードで管理しなければならず、データは手動でローカルＳＰＵメモリへ、あるいは、ローカルＳＰＵメモリから転送されなければならない。高性能化のためには、このコードとデータはＳＰＵソフトウエアから管理されなければならない（ＰＰＵソフトウエアの関与は最小限にとどめなければならない）。ＳＰＵからコードとデータを管理するための多くの技術がある。しばしば、ＳＰＵからコードとデータを管理するための異なる技術をセルプロセッサ上で同時に実行する必要がある。ＳＰＵ駆動型のタスク管理のためのプログラミングモデルもたくさんある。残念ながら、すべてのアプリケーションにとって正しい一つのタスクシステムというものはない。

セルプロセッサで使用された従来のタスク管理システムはＳＰＵスレッドとして知られている。「スレッド」とは他の部分とは独立して実行できるプログラムの一部のことである。マルチスレッドをサポートするオペレーティングシステムによれば、プログラマはスレッド化された部分が並列に実行されるようにプログラムを設計することができる。ＳＰＵスレッドは、セルにおけるＳＰＵをスレッドのためのプロセッサとみなすことで動作する。コンテクストスイッチにより、ＳＰＵのローカルストレージの内容がメインメモリにスワップされることがある。２５６キロバイトのデータやコードがメインメモリからローカルストレージに差し替えられ、差し替えデータおよびコードはＳＰＵによって処理される。コンテクストスイッチは、複数の処理が単一のリソースを共有できるように、ＳＰＵまたはＰＰＵのステート（コンテクスト）を格納し、復元する計算処理である。コンテクストスイッチは、通常は計算量が多く、オペレーティングシステムの設計の大部分は、コンテクストスイッチの使用を最適化することに割かれる。

残念ながら、ＳＰＵスレッドとインターオペレートすることは、高性能アプリケーションにとっての選択肢ではない。ＳＰＵスレッドにもとづくアプリケーションは、大きなバンド幅要求をもち、ＰＰＵから処理される。したがってＳＰＵスレッドベースのアプリケーションは自律的ではなく、遅くなる傾向がある。ＳＰＵスレッドはＰＰＵから管理されるため、ＳＰＵコンテクストスイッチ（あるＳＰＵ上で現在実行中のプロセスを他のウエイト中のプロセスにスワップする）は時間がかかり過ぎる。ＳＰＵの管理にＰＰＵが関与するのを避けることができれば、あるアプリケーションに対してはもっとよい性能を与えることができる。

これらの問題を克服するために、ＳＰＵランタイムシステム（ＳＰＵＲＳ）と呼ばれるシステムが開発された。ＳＰＵＲＳでは、各ＳＰＵのメモリには、ＳＰＵによって扱われるタスクのスケジューリングを実行するカーネルがロードされる。残念ながら、ＳＰＵＲＳは、ＳＰＵスレッドと同様、コンテクストスイッチを使ってＳＰＵへ、あるいはＳＰＵから仕事（ワーク）をスワップする。ワークは、ＰＰＵではなくＳＰＵ上で実行されるため、ＳＰＵスレッドとは違って、処理の自律性はある。しかし、ＳＰＵＲＳはＳＰＵスレッドと同じようにコンテクストスイッチのオーバーヘッドを受ける。このように、ＳＰＵＲＳは自律性を提供するが、多くの利用形態に対してはあまり好ましいものではない。

ＳＰＵＲＳはＳＰＵタスクシステムの一例に過ぎない。ミドルウエアおよびアプリケーションには、多様な目的に応じて多様なタスクシステムが求められる。現在、ＳＰＵＲＳはＳＰＵスレッドのグループとして実行され、他のＳＰＵスレッドとインターオペレートすることができる。残念ながら、上述のように、ＳＰＵスレッドには好ましくないオーバーヘッドがあり、ＳＰＵタスクシステムのインターオペレーションのためにＳＰＵスレッドを用いることは、特定の高性能アプリケーションにとっての選択肢ではない。

セルプロセッシングでは、ミドルウエアとアプリケーションが多様なタスクシステムを用いてＳＰＵを共有することが望ましい。多くのタスククラス、たとえば、オーディオ、グラフィックス、人工知能や、布モデリング、流体モデリング、剛体運動のような物理に対して、リソースを提供することが望ましい。これを効率的に実行するために、プログラミングモデルはコードとデータの両方を管理する必要がある。ＳＰＵミドルウエアが共通のタスクシステムとインターオペレートしないようにすることが、一つの努力目標である。残念ながら、ＳＰＵスレッドとＳＰＵＲＳは同じプログラミングモデルに従っており、このモデルもあまり多くの利用ケースにとって十分な性能を提供しない。このように、アプリケーションの開発者は、コードとデータの間でＳＰＵ上の限られたメモリスペースをいかに共有するかについて、依然として答えを見つけなければならない。

そのため、上述の不利な点を克服するセルプロセッサ方法および装置が技術的に求められている。

上述の不利な点を克服するために、本発明の実施の形態は、一つ以上の中央プロセッサと一つ以上のシナジスティックプロセッシングユニット（ＳＰＵ）とを含み、各ＳＰＵがプロセッサとローカルメモリを含むセルプロセッサにおいて、一つ以上のＳＰＵ上のコードとデータを管理するための方法に関する。本発明のある実施の形態によれば、一つ以上のＳＰＵ上でのコードとデータの管理は、独創的な方法により実装することができる。この方法によれば、ポリシーモジュールは、一つ以上のＳＰＵ上で実行されるＳＰＵポリシーモジュールマネージャ（ＳＰＭＭ）の制御下で、メインメモリから、一つの選択されたＳＰＵのローカルメモリにロードされる。このポリシーモジュールは、メインメモリからＳＰＵのローカルメモリにワークキューをロードするように構成されてもよい。前記ポリシーモジュールの制御下で、一つ以上のタスクが、メインメモリから、前記選択されたＳＰＵのローカルメモリにロードされる。ポリシーモジュールは、ＳＰＵ上のワークキューから一つ以上のタスクを解釈して処理するように構成されてもよい。

本発明の実施の形態は、ＳＰＵポリシーモジュールの効率的なインターオペレーションに対する解決を提供する。

これから述べる詳細な説明には、例示のために特定の詳細な内容が多く含まれるが、当業者であれば、これらの詳細な内容にいろいろなバリエーションや変更を加えても、本発明の範囲を超えないことは理解できよう。したがって、以下で説明する本発明の例示的な実施の形態は、権利請求された発明に対して、一般性を失わせることなく、また、何ら限定をすることもなく、述べられたものである。

図１は、セル・プロセッサ１００の概略図である。本発明の実施の形態によれば、セル・プロセッサ１００は一般にパワープロセッサユニット（ＰＰＵ）１０２といくつかのシナジスティックプロセッシングユニット（ＳＰＵ）１０４を含む。図１では、一つのＰＰＵ１０２と８個のＳＰＵ１０４が例示される。２つ以上のＰＰＵや、８より多いか少ないＳＰＵをもつセルプロセッサが本発明の実施の形態において使われてもよい。

ＰＰＵ１０２は、大部分の計算上の作業負荷を取り扱うＳＰＵ１０４に対してコントローラとして働く。ＰＰＵ１０２が他の６４ビットＰｏｗｅｒＰＣプロセッサと十分に類似しており、ＳＰＵ１０４がベクトル浮動小数点コードを実行するために設計されているならば、ＰＰＵ１０２を、従来のオペレーティングシステムを走らせるために用いてもよい。一例として、ＰＰＵ１０２は、３２ＫｉＢのインストラクション（命令）とＬ１データキャッシュと５１２ＫｉＢのＬ２キャッシュを含んでもよい。

ＰＰＵ１０２とＳＰＵ１０４は、交換インタフェースバス（ＥＩＢ）１０３上で互いにコードとデータを交換し合うことがでる。ＰＰＵ１０２とＳＰＵＳ１０４は、ＥＩＢ１０３およびメモリ・フロー・コントローラ（ＭＦＣ）（たとえば、ダイレクトメモリアクセス（ＤＭＡ）ユニットのようなもの）を介して、メインメモリ１０６に格納されたコードとデータを交換し合うこともできる。ＥＩＢ１０３は、反対方向に２本のチャネルをもつ循環バスであってもよい。ＥＩＢ１０３は、Ｌ２キャッシュ、ＭＦＣ１０８およびシステムインタフェース１０５（例えば外部通信のためのＦｌｅｘＩＯのようなもの）に接続されてもよい。

各ＳＰＵ１０４は、ローカルメモリー１１０をもつ。メインメモリ１０６から取得されたコードとデータはローカルメモリー１１０へロードすることができ、その結果、ＳＰＵ１０４はタスクを処理することができる。図示されているように、ＳＰＵポリシーモジュール（ＳＰＭＭ）１１２として参照される、小さなソフトウェア・マネージャが、各ＳＰＵ１０４のローカルメモリ１１０に存在する。好ましくは、ＳＰＭＭ１１２は、各ローカルメモリ１１０の利用可能な総メモリ空間のほんの小さい部分（例えば、各ＳＰＵメモリのおよそ１％未満）だけを占める。ＳＰＭＭ１１２の中心部分は「ＳＰＭＭカーネル」と称され、典型的には各ＳＰＵ上のおよそ２ＫＢを占めている。２５６Ｋのローカルストレージの場合、これはおよそ０．８％のＳＰＵローカルストアを使用したことを意味する。

ＳＰＭＭカーネルは、優先度にもとづくワークキュースケジューリングを提供する。ここで、「ワークキュー」という用語は、メモリ内のある場所で定義された仕事（例えばメインメモリ１０６で定義されたＳＰＵワーク）を意味するものとして使われる。これは、多くの場合、タスク定義のキューである。ワークキューと関連づけられたポリシモジュールは、この仕事（ワーク）がどのように解釈されて実行されるかを決定する。ここで、「ポリシーモジュール」とは、プログラミングモデルとタスク実行方式を定義するＳＰＵ上の小さなマネージャオブジェクトのことである。与えられたポリシーモジュールは、ＳＰＵワークを実行するために残りのＳＰＵメモリ内のコードおよび／またはデータを管理することができる。ポリシーモジュールは、現在のワークキューを実行するために必要なら、メインＲＡＭからＳＰＵローカルストレージへ転送されてもよい。ＳＰＵからＳＰＵへポリシーモジュールを転送する他の方式があることは本発明者も認めるところである。ＳＰＭＭカーネルは、実行されるときはいつでも、一般に新しいワークキューを選ぶ。

ＳＰＭＭ１１２は、ＳＰＵワークのスケジューリングができるように、最も単純な機能セットを実装する。したがって、ポリシーモジュールは自分のコンテクストデータを管理しなければならない。ポリシーモジュールは、ＳＰＵワークへのポインターから、自分のコンテクストデータを決定しなければならない。ポリシーモジュールイメージは、ステート・データとともに前処理されてもよい。たとえば、実行時のオプションに基づいてポリシーモジュールＥＬＦイメージの中のグローバルデータを初期化する。ポリシーモジュールを実行する間、ステート・データはＳＰＵによって変更され、ＳＰＵで実行中のポリシーモジュールからメインメモリへ渡されてもよい。ＰＰＵは、ポリシーモジュールのステート・データのステートを変更してもよい。ポリシーモジュールは典型的にはＥＬＦイメージとして格納される。ＥＬＦイメージとは、実行可能なリンク可能なファイル形式のことである。ＥＬＦが処理され、イメージにリンクされると、そのイメージは実行の準備が整う。

ＳＰＵ１０４上で実行中のポリシーモジュールの制御下でワークがロードされるため、本発明の実施の形態は、コンテクストスイッチを避けることができる。コンテクストスイッチは、一般に、ＳＰＭＭカーネルによって実行されることはないが、ポリシーモジュールは、コンテクストスイッチを実行してもよい。なぜならポリシーモジュールの実装は完全に開発者次第であるからである。しかし、多くのタスクシステムは、ＳＰＵローカルストア１１０において既にコード／データを管理しているため、自分のコンテクストを切り替えることを必要としない。たとえば、ＳＰＵＲＳは、ＳＰＵＲＳタスクをコンテクストスイッチしてローカルストアに出し入れするが、ＳＰＵＲＳカーネルは自分自身のコンテクストを保存または取り出す必要がない。

たとえば、ポリシーモジュールとワークキューは次のように関連づけられてもよい。図１の下側に示すように、メインメモリ１０６は一組のワーク定義１１６を持つワークキューアレイ１１４を含んでもよい。表Ｉは、ワークキューアレイ１１４に格納されるワーク定義１１６のデータ構造の例を示す。

表１は、１つのありうるワーク定義を代表して示す。ワーク定義データ構造の特定の内容は、表１の内容とは異なっていてもよい。一般に、各ワーク定義１１６は、対応するワークキュー（ＷＱ）１１８に対するメモリアドレスへのポインターを含む。メモリアドレスは、ＲＡＭで定義されたＳＰＵワークを含み、ＳＰＵワークは、ワークキュー１１８に対するコードとデータの両方を含んでもよい。ワークキューの例はタスクセットとタスクキューを含む。ワークキュー定義１１６は、対応するＷＱ１１８のステートに対する値を含んでもよい。ワークキューのステートは、ＰＰＵ１０２またはＳＰＵ１０４から設定することができる。ステートの例として、（ａ）ＳＰＭ＿ＲＥＡＤＹ−：ＷＱ１１８はレディ（準備完了）ワークを含む、（ｂ）ＳＰＭ＿ＥＭＰＴＹ−ＷＱ：ＷＱ１１８はレディワークをもたない、および（ｃ）ＳＰＭ＿ＦＲＥＥ−ＷＱ：ＷＱ１１８はもはや使用されていない、といったものがある。

競合度は、与えられたＷＱ１１８の作業に取り組んでいるＳＰＵ１０４の数のことである。ワークのタイプによっては、与えられたＷＱ１１８に取り組むことができるＳＰＵ１０４の最大数が設けられてもよい。この数をワーク定義１１６の一部として格納してもよい。ワークの特定のタイプは、効率的な処理のために２つ以上のＳＰＵを必要とする。そのような場合、１つのＳＰＵの出力は、更なる処理のために第２のＳＰＵに転送されてもよい。そのような事例を扱うために、最小競合度（すなわちそのワークを処理するために必要なＳＰＵの最小数）を定めることは、役に立つ。この数をワーク定義１１６の一部として格納することもできる。

各ワークキュー１１８は、一つのポリシーモジュールと関連づけられる。表Ｉに示したケースでは、ワークキューとその対応するポリシーモジュールの間の関連付けはポリシーモジュール定義１２０のメモリアドレスへのポインターの形で与えられる。ポリシーモジュールは、複数のワークキューと関連付けられてもよい。表ＩＩは、ポリシーモジュール定義の例を示す。

表２において、コードイメージオフセットは、最初のファンクションコールに対する入力ポイントアドレスのことである。

この例では、ポリシーモジュール定義１２０は、ポリシーモジュールのコード・イメージ１２２が含まれるメモリアドレスへのポインターを含む。ＳＰＭＭ１１２によってローカルストレージ１１０へロードされるのは、このコード・イメージである。ロードされたイメージは、ＳＰＵ１０４をポリシーモジュール１２４として動作させる。ポリシーモジュールは、ワークのローディング（例えばコードまたはデータの形式のコンテクスト・データ１２６をメインメモリ１０６のワークキュー１１８からローカルストレージ１１０にロードする）を制御する。

図２Ａは、図１のセルプロセッサ１００による処理方法２００を例示するフローチャートである。図１と図２Ａを参照してセルプロセッサ１００の動作を理解する。ステップ２０２で、ＳＰＵ１０４のうちの１つの上で実行されているＳＰＭＭ１１２は、処理すべきＷＱ１１８を選ぶ。（１）以前のワークが完了したか、（２）以前のワークがプリエンプトされたならば、ＳＰＭＭ１１２は新しいワークキューを選ぶ。新しいキューを選ぶアルゴリズムは、たとえば、単純な線形探索であってもよい（たとえば、合致するものが見つかるまで、ワークキューアレイのすべてのワーク定義を探索する）。もっとも、その特定のアルゴリズムに多様に変化をつけてもよい。ワークキューを獲得する間、最大競合ルールに従うべく、アトミック・ミューテックスをロックしてもよい。もっとも、ロックフリー（ｌｏｃｋ−ｆｒｅｅ）のような、他の同期技術であっても動作する。

図２Ｂは、ステップ２０２におけるワークキューを選ぶためのアルゴリズム２２０の例を示すフローチャートである。アルゴリズム２２０は、ＳＰＭＭ１１２によって実行される。まず最初に、パラメータＣＨＯＩＣＥは、ステップ２２２で無し（ｎｏｎｅ）に設定される。パラメータＣＨＯＩＣＥは、ＳＰＭＭ１１２が処理するために選ぶワークキューを表す。ポインターＷは、ステップ２２４でＷＱアレイ１１４の第１のワークキュー定義を指すように設定される。ステップ２２６で、ＳＰＭＭは、そのワークキュー定義が有効なワークキューを表すかどうか調べる。もしそうでないなら、アルゴリズムは終了する。無効なＷＱ定義の例として、ワークキューアレイ１１４がサイズＮを持つケースを考える。ワークキュー定義のインデックスがＮ以上であるならば、それは無効である。アルゴリズムは、全ての有効なワークキュー定義を繰り返し処理する。ワークキュー定義が有効であるならば、ステップ２２８でＳＰＭＭ１１２は、第１のワークキューが処理の準備ができている（レディ）かどうか調べる。たとえば、ＳＰＭＭ１１２はワークキュー定義のステート属性が「ＲＥＡＤＹ」に設定されているかどうか調べてもよい。第１のＷＱがレディでないならば、ステップ２３０でＷの値はＷＱアレイ１１４の次のＷＱ定義を指すように設定され、アルゴリズムはステップ２２６に戻る。ＷＱがレディならば、ステップ２３２でＳＰＭＭ１１２はＷＱの競合度（すなわち現在それに取り組んでいるＳＰＵの数）を最大競合度ｍａｘ＿ｃｏｎｔｅｎｔｉｏｎ（すなわちそれに取り組むことができる最大数のＳＰＵ）と比較する。ＷＱの競合度が最大競合度ｍａｘ＿ｃｏｎｔｅｎｔｉｏｎ以上であるならば、ステップ２３０でＷの値は、ＷＱアレイ１１４の次のＷＱ定義を指すように設定され、アルゴリズムはステップ２２６に戻る。

ＷＱの競合度が最大競合度ｍａｘ＿ｃｏｎｔｅｎｔｉｏｎの値より小さいなら、ステップ２３４でＳＰＭＭ１１２は次にＣＨＯＩＣＥの値が有効かどうか調べる。たとえば、ＣＨＯＩＣＥの初期値が無し（ｎｏｎｅ）であるならば、それは無効である。ＣＨＯＩＣＥが無効であるならば、ステップ２３６でＣＨＯＩＣＥの値はＷの値と等しく設定され、Ｗの値に対応するワークがＳＰＵ１０４で処理するために選ばれる。ステップ２３０でＷの値は、ＷＱアレイ１１４の次のＷＱ定義を指すように設定され、アルゴリズムはステップ２２６に戻る。

再び図２Ａを参照すると、いったんあるＷＱ１１８がＷＱアレイ１１４のワーク定義１１６の中から選ばれると、ステップ２０４でＳＰＭＭ１１２は、対応するポリシーモジュール１２４をメインメモリ１０６からＳＰＵ１０４のローカルストレージ１１０へロードする。上述のように、メインメモリ１０６からポリシーモジュールをロードすることは、ワークキューアレイ１１４のワーク定義１１６から、メインメモリ１０６におけるポリシーモジュール・コード・イメージ１２２のメモリアドレスを読むことを含んでもよい。ＳＰＭＭ１１２は、ＳＰＵ１０４上でワークのスケジューリングを可能にするために、最も単純な機能セットを実装する。ＳＰＭＭ１１２は、ＷＱ１１８の内容について何も仮定しない。その代わりにポリシーモジュール１２４は、ＷＱの内容と用い方を決定し、自分のコンテクスト・データを管理する。

あるＷＱ１１８が選ばれるとき、その競合値はインクリメントされ、そのポリシーモジュール・コード・イメージ１２２は、ローカルストレージ１１０へ転送され（それがすでに存在する場合を除く）、ポリシーエントリファンクションがＷＱ１１８へのポインタで呼び出される。ステップ２０６で、ポリシーモジュールの制御下で、選ばれたＷＱが処理される（例えば、ワークキュー１１８から一つ以上のタスクがメインメモリー１０６からローカルメモリー１１０にロードされる）。

実際には、ワーク・キューの内容は、しばしば、共有タスクキューを保護するアトミック・ミューテックスか一組のタスクに関連したロックフリーデータである。ＷＱアレイのアクセスは、ＷＱ競合のバランスが取られることを保証するため、かつ／または、最大競合ルールに従うことを保証するために、アトミックロックを使って順番に並べられてもよい。ワークキュー１１８にロックフリーでアクセスすることもまた可能でもある。しかしながら、コードはより複雑になる。ある事例では、ワークキュー定義の１２８バイトのセクションだけを一度に調べることができる。さらに、セルプロセッサ１００の性能が異なるかどうかは定かではない。ワークキューの数が少ない方が性能はよく、ワークキューの数が多ければ性能は悪くなる。

ステップ２０８でＳＰＵはワークキュー１１８から一つ以上のタスクを実行する。一つ以上のＳＰＵ１０４によって同時にワークキューを処理することができる。上述のように、競合するＳＰＵの最大数（最大競合度）を各ＷＱ１１８に対して設定してもよい。以前のワークが完了するか、以前のワークが横取りされた場合、ステップ２１０でポリシーモジュール１２４は、ＳＰＭＭカーネル１１２にＳＰＵ１０４の制御を返す。

ＳＰＭＭ１１２は、優先度と準備完了性（readiness）に基づいて複数のＳＰＵワークキュー１１８をスケジュールする。より高い優先度のワークが利用可能になると、ＳＰＭＭ１１２は利用可能なＳＰＵに高い優先度のタスクを割り当てることができる。本発明の実施の形態は、協調的なプリエンプションを実装することもできるという点で、準プリエンプティブであると言ってもよい。具体的には、ポリシーモジュール１２４はプリエンプションを決定するために、ＳＰＵイベント・チャネルを定期的にチェックすることができる。もしプリエンプションが起こるならば、ポリシーモジュール１２４は仕事を片付けて、ＳＰＭＭ１１２にＳＰＵ１０４の制御を返すことができる。より高い優先度のワークがレディ（準備完了）になると、低い優先度のＳＰＵにプリエンプションのイベントが送られる。ポリシーモジュールはより高い優先度のワークの処理を許可するためにリターンする。与えられたタスクまたはワークキューの優先度と競合度は、ワークキューアレイのワーク定義の一部として格納されてもよい。

選ばれたＷＱ定義から、ポリシーモジュール１２４は、一つの要求された関数：ｅｘｅｃｕｔｅ（ＥＡ ｗｏｒｋ＿ｑｕｅｕｅ）｛｝を有する。ここで、ＥＡは「実効アドレス」−ＷＱのメインメモリアドレスを表す。この関数は呼び出されて「実行（ｅｘｅｃｕｔｅ）」される必要はないが、３２ビットのパラメータを一つ取らなければならない。そのパラメータのサイズ（たとえば、３２ビット）は実装次第で変わってもよいが、当該パラメータは選ばれたワークキューのアドレスである。このｅｘｅｃｕｔｅ関数はポリシーモジュールのエントリポイントを表す。この関数はｗｏｒｋ＿ｑｕｅｕｅパラメータによって渡されたワークキューを処理する。ポリシーモジュールの特定のコンフィギュレーションによっては、ｅｘｅｃｕｔｅ関数がＰＰＵのメインメモリに渡すことのできるステート情報を返すように構成してもよい。もっとも、ワークキューを処理するためのｅｘｅｃｕｔｅ関数は、典型的には値を返さない。

ＷＱの処理を終えるために、ポリシーモジュール１２４はｓｐｍｍ＿ｒｅｌｅａｓｅ＿ｗｏｒｋ（ｎｅｗ ｓｔａｔｅ）という関数を呼び出す。この関数はＷＱ１１８に対する競合値をデクリメントし、ＷＱステートの値をｎｅｗ＿ｓｔａｔｅ（典型的には、処理終了が完了またはプリエンプションのどちらに起因するかによって、ＳＰＭＭ＿ＲＥＡＤＹまたはＳＰＭＭ＿ＥＭＰＴＹのいずれかの値をとる）に設定する。ＳＰＭＭ１１２にＳＰＵの制御を返すために、ポリシーモジュール１２４はｓｐｍｍ＿ｅｘｉｔという関数を呼び出す。この関数は、スタックポインタをＬＳ１１０のトップにリセットし、新しいＷＱを選ぶものである。ポリシーモジュール１２４は次に選ばれたＷＱによって再利用される場合があるので、ポリシーモジュールのスタックサイズは一般的に少なくとも４ＫＢである。

本発明の実施の形態において、ｓｐｍｍ＿ｒｅｌｅａｓｅ＿ｗｏｒｋは通常ｓｐｍｍ＿ｅｘｉｔの直前に呼び出される。これらが一つの関数ではないことには重要な理由がある。しばしば、ＷＱには新しいワーク（仕事）がいかなるときにでも追加されることがある。新しいワークがＷＱに加えられるとき、そのステートはＳＰＭ＿ＲＥＡＤＹに設定しなければならない。ポリシーモジュール１２４は、適切なアトミックスをもたせて、好ましくない競合状態（出力がイベントの相対的なタイミングに予想もしない重大な依存関係を見せるというプロセス上の欠陥）を防がなければならない。

たとえば、ＳＰＵ１０４は、ＷＱ１１８の最後のタスクを処理した後、ＷＱ１１８のステートをチェックしてもよい。ポリシーモジュールがｓｐｍｍ＿ｒｅｌｅａｓｅ＿ｗｏｒｋ（ｎｅｗ＿ｓｔａｔｅ）を呼ぶ前に、ＰＰＵ１０２はワークをＷＱ１１８に追加し、そのステートをＳＰＭ＿ＲＥＡＤＹに設定してもよい。ポリシーモジュール１２４がその後、ｓｐｍｍ＿ｒｅｌｅａｓｅ＿ｗｏｒｋ（ＳＰＭ＿ＥＭＰＴＹ）を呼び出すならば、ポリシーモジュールが続いてｓｐｍｍ＿ｅｘｉｔ（）を呼び出したとき、ＷＱ１１８のステートは正しくなくなっているだろう。

そのような無効なＷＱステートを防ぐための好ましい技術は、以下の通りに進む。ＳＰＵ１０４がＷＱ１１８の最後のタスクを処理した後、ポリシーモジュール１２４がＷＱ１１８に対するアトミック・ミューテックスをロックし、ＷＱ１１８にさらにタスクがあるかチェックする。もしこれ以上タスクがないなら、ポリシーモジュール１２４はｓｐｍｍ＿ｒｅｌｅａｓｅ＿ｗｏｒｋ（ＳＰＭ＿ＥＭＰＴＹ）を呼び出し、ＷＱ１１８のステートはＳＰＭ＿ＥＭＰＴＹに設定される。次にポリシーモジュール１２４はＷＱ１１８に対するアトミック・ミューテックスのロックを解除する。ＰＰＵ１０２がＷＱ１１８にワークを追加したいならば、ＰＰＵ１０２はＷＱ１１８に対するアトミック・ミューテックスをロックして、そのワークを追加し、ＷＱ１１８のステートをＳＰＭ＿ＲＥＡＤＹに設定し、ＷＱ１１８に対するアトミック・ミューテックスのロックを解除する。ポリシーモジュール１２４がｓｐｍｍ＿ｅｘｉｔ（）を呼ぶことができるようになる前にワークが加えられたとしても、ＷＱ１１８のステートは正しい。

たとえＷＱ１１８が決して再利用されない（ステートがタスク完了時にＰＭによってＳＰＭ＿ＦＲＥＥに設定される）としても、アトミックスがなければ、潜在的な競合状態がまだある点に留意する必要がある。具体的には、第１のＳＰＵ上で実行中のポリシーモジュールがＷＱ１１８の最後のタスクを処理し、ＷＱ１１８にさらにタスクがあるか調べ、何もないと決定したとすると仮定する。それからそのＳＰＵはＷＱ１１８が完全であることをＰＰＵ１０２に信号を出して知らせる。ＰＰＵ１０２はその信号を受け取った後、ＷＱ１１８に割り当てられたメモリスペースを開放するか、再利用する。いずれの場合でもＷＱ１１８に割り当てられたメモリ空間がガーベッジデータを含む場合がある。第１のＳＰＵ上のポリシーモジュールがｓｐｍｍ＿ｒｅｌｅａｓｅ＿ｗｏｒｋ（ＳＰＭ＿ＦＲＥＥ）を呼ぶことができるようになる前に、ＳＰＭＭ１１２の制御下にある第２のＳＰＵがＷＱ１１８を選ぶならば、その第２のＳＰＵは、ＷＱ１１８に割り当てられたメモリ空間からガーベッジデータを処理しようとするとき、クラッシュするかもしれない。

アトミックス有りの競合状態を回避するにあたり、ｓｐｍｍ＿ｒｅｌｅａｓｅ＿ｗｏｒｋ（ＳＰＭ＿ＦＲＥＥ）を呼び出す前に、第１のＳＰＵがＰＰＵにＷＱ１１８が完了したことを信号で通知しないことが重要である。ミューテックスがロックされた後であるがｓｐｍｍ＿ｒｅｌｅａｓｅ＿ｗｏｒｋを呼び出す前に第２のＳＰＵがＷＱ１１８を選ぶ可能性があることについて対処するため、第１のＳＰＵ上のポリシーモジュールはＷＱ１１８の競合をチェックすることができる。もし第２のＳＰＵがＷＱ１１８を既に選び、そのポリシーモジュールをロードしていたなら、競合度はゼロ（完了したワークに対して期待されるであろう値）に等しいことはないであろう。ワークが完了していることをＰＰＵにシグナルで伝える代わりに、第１のＳＰＵはミューテックスを解除し、ｓｐｍｍ＿ｅｘｉｔを呼び出す。第２のＳＰＵ上で実行中のポリシーモジュールは、ＷＱ１１８にもっとワークがあるか調べ、何もない場合は、ｓｐｍｍ＿ｒｅｌｅａｓｅ＿ｗｏｒｋ（ＳＰＭ＿ＦＲＥＥ）を呼び出し、ＷＱ１１８の競合度をゼロに設定し、ＰＰＵ１０２に信号を送って、ＷＱ１１８が完了し、ミューテックスを解除したことを伝える。

上記の議論では、競合状態を回避するためのアトミック・ミューテックス・ロックを扱ったが、そのような状態はロック・フリー方式で回避することも可能である。一般に、ポリシーモジュールが、与えられたＷＱにはこれ以上タスクが含まれないと判定すると、ポリシーモジュールは、ＷＱステートがエンプティに設定される間にタスクステートが変わるのを防ぐ必要がある。あるいは、ワークを追加したり、ワークを完了する処理をアトミックにしなければならない。本発明の実施の形態の文脈でいえば、ワークを追加することには、ポリシーモジュール空間でタスク状態を「レディ」に設定し、ＳＰＭＭ ＷＱステートを「レディ」に設定することが含まれる。ワークを完了するとは、最後のタスクが取られるか、ｎｏｔ＿ｒｅａｄｙステートに設定される状況を言う。ワークを完了することには、タスクステートをノット・レディ（まだ準備できていない）に更新し、ＳＰＭＭのＷＱステートを「ノット・レディ」に設定することが含まれる。

ＳＰＭＭ１１２は、異なる優先度をもつ複数のワークキューをスケジューリングすることができてもよい。高い優先度のキューは、低い優先度のキューより前に処理することができる。等しい優先度のキューを処理するとき、ＳＰＵは競合度とのバランスを取ることができる。もし最も高い優先度のキューがそれ以上の競合を許さないなら、他のＳＰＵが次に優先度が最も高いキューの作業をする。ＳＰＭＭ１１２によるプリエンプションの例は、図２Ｂを再び参照することで理解されよう。ＳＰＵ１０４上でＷＱ１１８を処理しているポリシーモジュールは、ワークキューアレイ１１４で（ポインタＷによって表された）他のＷＱを分析し続ける。この時点で、アルゴリズム２２０の各ステップは、ＳＰＵ１０４上でプロセスを実行しているポリシーモジュールの一部として実装されてもよい。前に述べたように、ステップ２３４で、ＳＰＭＭは、ＣＨＯＩＣＥの値（それは、ＳＰＵ１０４によって現在処理されているＷＱ１１８を示す）が有効かどうかを調べた。ＣＨＯＩＣＥの値がまだ有効であるならば、ステップ２３８でＳＰＭＭは選ばれたＷＱの優先度をＷの優先度と比較する。Ｗの優先度の方が高いなら、これはプリエンプションのイベントを表しており、ＳＰＵ１０４の制御はＳＰＭＭ１１２に戻る。ステップ２３６でＣＨＯＩＣＥの値はＷの値（それは、異なるワークキューを代表する）に設定され、アルゴリズム２２０はステップ２３０に戻り、ポインタＷをインクリメントする。

プリエンプションはまた、ステップ２４０でＷとＣＨＯＩＣＥが等しい優先度である場合に特定の状況下で起こることがある。たとえば、ステップ２４２でポリシーモジュール１２４が、ＷとＣＨＯＩＣＥは等しい優先度をもち、Ｗの競合度がゼロより大きいが、最小競合値（ｍｉｎ＿ｃｏｎｔｅｎｔｉｏｎ）より小さいことを発見した場合、ステップ２３６でＳＰＵの制御はＳＰＭＭ１１２に戻る。そのような場合、Ｗは「緊急」であるという。最小競合の概念は、ワークがあるＳＰＵから一つ以上の他のＳＰＵへカスケードする状況において有益である。たとえば、多くの物理学アプリケーション（例えば布のシミュレーション）では、１つのＳＰＵの出力は、所与のワークキューをインプリメントするプロセスの異なる部分を実行しているもう一つのＳＰＵに対する入力として用いられる。そのようなワークキューが処理中の他のワークと等しい優先度をもつとき、アルゴリズム２２０はＳＰＵをそのようなプロセスに利用できるようにすることにより、競合のバランスを取ろうと試みる。もし十分な数のＳＰＵがワークを処理するために利用可能であるならば、出力は直接次のＳＰＵへロードしてもよい。あるいは、さらなるＳＰＵが出力を処理するために利用可能になるまでの間、出力は一時的にメモリ１０６に格納してもよい。

ステップ２４２でもしＷが「緊急」ではないと判定されるならば、ポリシーモジュールはステップ２４４でＣＨＯＩＣＥが緊急のワークを表すかどうかを調べることができる。たとえば、ＣＨＯＩＣＥの競合度がゼロより大きいがその最小競合値ｍｉｎ＿ｃｏｎｔｅｎｔｉｏｎよりも小さいかどうかを判定することによって、それを調べることができる。もしＣＨＯＩＣＥが緊急であるならば、ポリシーモジュール１２４は、例えば、アルゴリズムをステップ２３０に戻すことによって他のワークを調べ続ける。ＣＨＯＩＣＥが緊急でないならば、ポリシーモジュール１２４はステップ２４６でＷの競合度がＣＨＯＩＣＥの競合度より小さいかどうかを調べ、もしそうならば、ステップ２３６でＣＨＯＩＣＥをＷと等しい値に設定し、ＳＰＭＭ１１２に制御を戻すことにより、競合のバランスを取ることができる。Ｗの競合度がＣＨＯＩＣＥの競合度より小さくないならば、ポリシーモジュール１２４はステップ２４８でＷとＣＨＯＩＣＥが等しい競合度をもつかどうか調べることができる。もしそうでないなら、ポリシーモジュール１２４は、例えば、アルゴリズムをステップ２３０に戻すことによって他のワークを調べ続ける。ＷとＣＨＯＩＣＥが等しい競合度をもつならば、ポリシーモジュール１２４は、ステップ２５０でアフィニティ（親和性）があるかどうか、すなわち、Ｗのポリシーが既にＳＰＵ１０４にロードされているかどうかを調べる。もしアフィニティがあるならば、ポリシーモジュールはステップ２３６でＣＨＯＩＣＥをＷに等しい値に設定し、ＳＰＭＭ１１２にＳＰＵ１０４の制御を返す。

本発明の実施の形態において、ＳＰＭＭ１１２はインタオペラビリティのために最適化されてもよい。そのようなインタオペラビリティの例を図３Ａ〜３Ｆに概略で示す。たとえば、ＳＰＭＭ１１２は図３Ａに示すように、特に有利なタイプの通常のＳＰＵスレッドとして実装することができる。このように、ＳＰＭＭを実装する処理システムは、ＳＰＵスレッドとインターオペレートすることができる。あるいは、その逆も同様である。そのような実施の形態において、ＳＰＵスレッドはまれな高い優先度のプリエンプションに対応するために役立つ。

さらに図３Ｂに示されるように、ＳＰＵＲＳはＳＰＭＭのコンテクスト内の一つのありうるポリシーモジュールとして実装してもよい。このように、ＳＰＵＲＳは特定のタスクに作用することができ、そこでは、ＳＰＭＭは、他のタスクについて作業するためにＳＰＵＲＳコードを何か他のものと入れ替えることができる。ＳＰＭＭは、複数のＳＰＵＲＳタスクセットを優先度に従いつつ、他のＳＰＵタスクシステムの次にスケジュールすることができる。さらに、ＳＰＵスレッドがＳＰＵＲＳとＳＰＭＭを異なるＳＰＵスレッドとして実装することも可能である。このように、本発明の実施の形態は、ＳＰＵＲＳとＳＰＵスレッドのどちらとも完全にインターオペレートすることができる。いろいろなプログラミングモデルを通じてスケジューリングの機能が重要である。この機能は、類似した特徴をもつセル（Ｃｅｌｌ）プロセッサや他の並列プロセッサデバイスにとって特に役立つ。

図３Ｃ−３Ｄは、異なるプログラミングモデルを実装するＳＰＵ上のローカルストレージ３００に対するメモリーマップを示す。図３Ｃは、ＳＰＭＭを実装するＳＰＵのローカルストレージ３１０に対するメモリーマップを示す。ここで、ＳＰＭＭカーネル３１２はポリシー３１４をロードし、その後、ＳＰＵオペレーションは、ワークが完了するか、プリエンプトのイベントが起こるまでは、そのポリシーによって管理される。ポリシー３１４は、カスタム・ポリシー、すなわち特定のアプリケーションまたはオペレーションのクラス用に特別に設計されたものであってもよい。開発者は、特別なアプリケーションに合った、そのようなカスタムポリシーを作成することができる。図３Ｄは、ローカルストレージ３２０に対するメモリーマップを示し、ここではＳＰＵＲＳ３２２がＳＰＭＭ３１２支配下のポリシーとして実装されている。ＳＰＵＲＳポリシー３２２は、ＳＰＵＲＳタスクセット３２４を管理する。ＳＰＵＲＳが複数のＳＰＵＲＳタスクに対して同じプログラムスタートアドレスでＳＰＭＭ上で走るように、ＳＰＵＲＳを修正することができる。ＳＰＭＭ３１２下で走っているときは、ＳＰＵＲＳポリシー３２２は複数のタスクセットを管理する必要はない。

ＳＰＭＭの長所は、ワークの性質の要求に応じて、ＳＰＵＲＳおよび他のポリシーを簡単に切り替えることができることである。たとえば、図３Ｅは、ローカルストレージ３２０に対するメモリーマップを示し、ここでは、ＳＰＵタスクマネージャ（ＳＴＭ）３２２はＳＰＭＭ３１２支配下のポリシーとしてを実装されている。ＳＴＭポリシー３３２は、タスク・コード３３４とタスクデータ３３６、３３８のセットをもつＳＴＭタスクセットを管理する。ＳＴＭポリシー３３２は、メインメモリに格納された一つ以上のタスク定義をローカルストレージ３２０に読み出す。タスク定義に含まれる情報に基づいて、ＳＰＵはタスク定義に関連したコードやデータをメインメモリーから、選択されたＳＰＵに関連づけられたローカルメモリーにロードする。選択されたＳＰＵはそのコードやデータを用いて一つ以上のタスクを実行する。ＳＴＭが複数のＳＴＭタスクに対して同じプログラムスタートアドレスでＳＰＭＭ上を走るように、ＳＴＭを修正することができる。ＳＰＭＭ３１２下で走っているときは、ＳＴＭポリシー３３２は複数のタスクセットを管理する必要はない。ＳＴＭは、本出願と譲受人が共通する米国特許出願１１／２３８，０８７号、"SPU TASK MANAGER FOR CELL PROCESSOR", John P. Bates, Payton R. White, Richard Stenson, Howard Berkey, Attila Vass and Mark Cernyに詳しく記載されている。この出願は本願と同日に出願されており、その開示全体は参照によりここに取り込まれる。

ＳＰＭＭ下でロードされることがあるもう一つのありうるポリシーは、セルプロセッサタスク・データ管理（ＣＴＤＭ）として知られている。図３Ｆは、ローカルストレージ３２０に対するメモリーマップを示し、ここではＣＴＤＭ３４２がＳＰＭＭ３１２支配下のポリシーとして実装されている。ＣＴＤＭポリシー３４は、ＳＰＵが、ローカルストレージ３２０に入れるには大きすぎるデータをより小さなセグメント３４４に分割することを許し、これにより、データはＳＰＵ上で走るコード３４６によって処理できるようになる。データは、グラフィックカードのような後段のプロセッサ上での処理にふさわしいサイズのグループに分割することもできる。ＣＴＤＭは、本出願と譲受人が共通する米国特許出願１１／２３８，０９５号、"CELL PROCESSOR TASK AND DATA MANAGEMENT", Richard B. Stenson and John P. Batesに詳しく記載されている。この出願は本願と同日に出願されており、その開示全体は参照によりここに取り込まれる。

本発明の実施の形態は、既存のＳＰＵプログラミングモデルの幅広い理解の結果である。一つのモデルが全てのアプリケーションに対して完全であるはずがないことは、多くの場合、本当である。従って、エンジニアはカスタムメイドのプログラミングモデルを開発する傾向がある。全てのＳＰＵコードが同じ会社によって書かれるなら、インタオペラビリティは問題にはならない。しかし、ミドルウェアが必要とされ、ＳＰＵコードが効率良く相互運用しなければならない場合は、インタオペラビリティは問題となりうる。

上述のように動作する図１に示したタイプの並列処理ユニットは、図４に示したより大きなプロセッシングシステム４００の一部として実装されてもよい。システム４００は、セルプロセッサモジュール４０１とメモリ４０２（たとえば、ＲＡＭ、ＤＲＡＭ、ＲＯＭのようなもの）を含む。さらに、プロセッシングシステム４００は複数のセルプロセッサモジュール４０１を有してもよい。セルプロセッサモジュール４０１は一般に一つ以上のプロセッサＰＰＵと一つ以上のＳＰＵ（ＳＰＵ１、ＳＰＵ２、…、ＳＰＵＮ）を有する。ＳＰＵは上述のようにＳＰＭＭの制御下で動作するように構成されてもよい。プロセッサモジュール４０１はメモリフローコントローラ（ＭＦＣ）を有してもよい。セルプロセッサモジュール４０１は、たとえば図１で示したタイプのセルプロセッサであってもよい。メモリ４０２は上述のように構成されたデータとコードを含む。具体的には、メモリには、ワークキューアレイ４０４、ワークキュー４０６およびポリシーモジュール４０８が含まれる。各ポリシーモジュール４０８には、上述のように、コード、データ、あるいはコードとデータの結合が含まれる。

システム４００には、周知の支援機能４１０として、たとえば、入出力（Ｉ／Ｏ）エレメント４１１、電源（Ｐ／Ｓ）４１２、クロック（ＣＬＫ）４１３およびキャッシュ４１４が含まれる。システム４００はオプションとして、プログラムおよび／またはデータを格納するためのディスクドライブ、ＣＤ−ＲＯＭドライブ、テープドライブ、あるいはマスストレージデバイス４１５などが含まれる。コントローラはオプションとして、コントローラ４００とユーザ間の相互作用を容易にするためのディスプレイユニット４１６やユーザインタフェースユニット４１８を含んでもよい。ディスプレイユニット４１６は、テキスト、数字、グラフィカルシンボルまたはイメージを表示するＣＲＴ（cathode ray tube）やフラットパネルスクリーンの形態を取ってもよい。ユーザインタフェース４１８はキーボード、マウス、ジョイスティック、ライトペンその他のデバイスを含んでもよい。セルプロセッサモジュール４０１、メモリ４０２、およびシステム４００の他の構成要素は、図４に示すシステムバス４２０を介して、信号（たとえばコードインストラクションやデータ）を互いにやりとりしてもよい。

ここでは、Ｉ／Ｏという用語は、システム４００や周辺デバイスへ／からデータを転送する任意のプログラム、オペレーションあるいはデバイスのことをいう。転送とは、一つのデバイスからの出力や別のデバイスへの入力のことである。周辺デバイスには、キーボードやマウスのような入力のみのデバイス、プリンタのような出力のみのデバイス、書き込み可能ＣＤ−ＲＯＭのような入力デバイスと出力デバイスのどちらにもなるデバイスが含まれる。「周辺デバイス」という用語は、マウス、キーボード、プリンタ、モニタ、外部Ｚｉｐドライブ、スキャナなどの外部デバイスだけでなく、ＣＤ−ＲＯＭドライブ、ＣＤ−Ｒドライブ、内部モデムのような内部デバイスや、フラッシュメモリリーダ／ライタ、ハードドライブのような他の周辺機器を含む。

プロセッサモジュール４０１は、メモリ４０２に格納され、読み出され、プロセッサモジュール４０１によって実行されるメインプログラム４０３のデータとプログラムコードインストラクションに応じて、ワークキュー４０６のタスクの性能を管理してもよい。プログラム４０３のコード部分は、アセンブリ、Ｃ＋＋、ＪＡＶＡ（登録商標）あるいはその他の数多くの言語のような、数ある異なるプログラミング言語の任意の一つに適合するものであってもよい。プロセッサモジュール４０１は汎用コンピュータを形成し、プログラムコード４０３のようなプログラムを実行するときは、特定用途のコンピュータになる。プログラムコード４０３はここではソフトウエアで実装され、汎用コンピュータ上で実行されるものとして記述したが、当業者であれば、タスク管理の方法は、特定用途向け集積回路（ＡＳＩＣ）や他のハードウエア回路のようなハードウエアを用いて実装してもよいことは理解されよう。このように、本発明の実施の形態は、全体あるいは一部が、ソフトウエア、ハードウエア、あるいはそれらの組み合わせで実装されてもよいことが理解されよう。ある実施の形態では、プログラムコード４０３は、図２Ａの方法２００および／または図２Ｂのアルゴリズム２２０に共通する特徴をもつ方法を実行する、プロセッサ読み込み可能なインストラクションセットを含んでもよい。

上述の議論はセルプロセッサについてなされたが、本発明の実施の形態は任意のマルチプロセッサ方式を用いて実装してもよい。具体的には、本発明の実施の形態は、並列プロセッサのいろいろな構成で実装してもよい。たとえば、本発明は、ＳＰＵライクなプロセッサをもつが、ＰＰＵライクなプロセッサをもたない構成で実装されてもよい。実施の形態は、一つ以上のプロセッサと、８よりも多いか少ない数のＳＰＵ（あるいはローカルメモリをもつ類似のプロセッサ）とをもつ並列プロセッサ環境で実装されてもよい。本発明の実施の形態は、ＳＰＵローカルストレージ空間の利用が少ないＳＰＵ駆動型の高性能ＳＰＵ管理の解決策を提供する。上述のように、本発明の実施の形態によれば、複数のＳＰＵ上のワークを並列のＳＰＵが処理することが可能になる。さらに、ＳＰＭＭモデルのモジュラ型の性質は、それがいろいろなプログラミングモデルやタスクシステムがインターオペレートするのを可能にしている点、好ましいものである。

本発明の好ましい実施の形態を完全な形で説明してきたが、いろいろな代替物、変形、等価物を用いることができる。したがって、本発明の範囲は、上記の説明を参照して決められるものではなく、請求項により決められるべきであり、均等物の全範囲も含まれる。ここで述べた特徴はいずれも、好ましいかどうかを問わず、他の特徴と組み合わせてもよい。請求項において、明示的に断らない限り、各項目は１またはそれ以上の数量である。請求項において「〜のための手段」のような語句を用いて明示的に記載する場合を除いて、請求項がミーンズ・プラス・ファンクションの限定を含むものと解してはならない。

本発明の実施の形態に係るセルプロセッサの概略図である。 本発明の実施の形態に係るセルプロセッサ方法の実施例を示すフローチャートである。 本発明の実施の形態に係るセルプロセッサにおいてワークキューを選ぶアルゴリズムを示すフローチャートである。 本発明の実施の形態を実装するためのソフトウエアアーキテクチャを例示する概略図である。 本発明の実施の形態を実装するためのソフトウエアアーキテクチャを例示する概略図である。 本発明の実施の形態に係るセルプロセッシングのＳＰＭＭベースの実装を例示するメモリマップである。 本発明の実施の形態に係るセルプロセッシングのＳＰＭＭベースの実装を例示するメモリマップである。 本発明の実施の形態に係るセルプロセッシングのＳＰＭＭベースの実装を例示するメモリマップである。 本発明の実施の形態に係るセルプロセッシングのＳＰＭＭベースの実装を例示するメモリマップである。 本発明の実施の形態に係るセルプロセッシングシステムのブロック図である。

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