JP4712876B2 - 並列プロセッサ方法と装置 - Google Patents

Description

［関連出願との相互参照］
本出願は、２００５年９月２７日に出願された米国特許出願第11/238,077号、"CELL PROCESSOR METHODS AND APPARATUS"（代理人整理番号SCEA05009US00）、John P. Batesの一部継続出願でありその優先権を主張し、参照によりその開示内容全体をここに援用する。
本出願はまた、２００５年９月２７日に出願された米国特許出願第11/238,087号、"SPU TASK MANAGER FOR CELL PROCESSOR"（代理人整理番号SCEA05015US00）、John P. Bates, Payton R. White, Richard Stenson， Howard Berkey， Attila Vass, Mark Cernyの一部継続出願でありその優先権を主張し、参照によりその開示内容全体をここに援用する。
本出願はまた、２００５年９月２７日に出願された米国特許出願第11/238,095号、"CELL PROCESSOR TASK AND DATA MANAGEMENT"（代理人整理番号SCEA05013US00）、Richard B. Stenson， John P. Batesの一部継続出願でありその優先権を主張し、参照によりその開示内容全体をここに援用する。
本出願はまた、２００５年９月２７日に出願された米国特許出願第11/238,085号、"METHOD AND SYSTEM FOR PERFORMING MEMORY COPY FUNCTION ON A CELL PROCESSOR"（代理人整理番号SCEA05018US00）、Antoine Labour, John P. Bates, Richard B. Stensonの一部継続出願でありその優先権を主張し、参照によりその開示内容全体をここに援用する。
本出願はまた、２００５年９月２７日に出願された本願と譲受人が共通する米国特許出願第11/238,086号、"OPERATING CELL PROCESSORS OVER A NETWORK"（代理人整理番号SCEA05014US00）、Tatsuya Iwamotoに関連し、参照によりその開示内容全体をここに援用する。
本出願はまた、２００５年１０月２４日に出願された本願と譲受人が共通する米国特許出願第11/257,761号、"SECURE OPERATION OF CELL PROCESSORS"（代理人整理番号SCEA05014CIP US00(SCEA05014US01)）、Tatsuya Iwamotoに関連し、参照によりその開示内容全体をここに援用する。

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

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

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

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

これらの問題を克服するために、ＳＰＵランタイムシステム（ＳＰＵＲＳ）と呼ばれるシステムが開発された。ＳＰＵＲＳでは、各ＳＰＵのメモリには、ＳＰＵによって扱われるタスクのスケジューリングを実行するカーネルがロードされる。これらタスクのグループはタスクセットと呼ばれる。ＳＰＵＲＳは、２００６年５月３１日に出願されたＰＣＴ出願PCT/JP2006/310907、"METHOD AND APPARATUS FOR SCHEDULING IN A MULTI-PROCESSOR SYSTEM"、Keisuke Inoue and Seiji Murata、２００４年２月２０日に出願された米国特許出願公開第20050188373号、"METHOD AND APPARATUS FOR TASK MANAGEMENT IN A MULTI-PROCESSOR SYSTEM"、Keisuke Inoue, Tatsuya Iwamoto, Masahiro Yasue、２００４年２月２０日に出願された米国特許出願公開第20050188372、"METHOD AND APPARATUS FOR PROCESSOR TASK MIGRATION IN A MULTI-PROCESSOR SYSTEM"、Keisuke Inoue, Tatsuya Iwamoto、２００５年２月４日に出願された米国仮特許出願第60/650153号、"PROCESSOR TASK MIGRATION OVER A NETWORK IN A MULTI-PROCESSOR SYSTEM"、Keisuke Inoue, Masahiro Yasueで説明されており、参照によりこれら４つの開示内容を本明細書に援用する。残念ながら、ＳＰＵＲＳは、ＳＰＵスレッドと同様、コンテクストスイッチを使ってＳＰＵへ、あるいはＳＰＵから仕事（ワーク）をスワップする。ワークは、ＰＰＵではなくＳＰＵ上で実行されるため、ＳＰＵスレッドとは違って、処理の自律性はある。しかし、ＳＰＵＲＳはＳＰＵスレッドと同じようにコンテクストスイッチのオーバーヘッドを受ける。このように、ＳＰＵＲＳは自律性を提供するが、多くの利用形態に対してはあまり好ましいものではない。

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

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

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

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

本発明の実施の形態は、ＳＰＵポリシーモジュールの効率的な相互運用に対する解決を提供する。

本発明の教示は、添付図面とともに以下に述べる説明を考慮することで直ちに理解可能である。

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

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

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

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

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

ＳＰＭＭ１１２はポリシーモジュールを管理する。ＳＰＭＭカーネルは、優先度に基づくワークキュースケジューリングを提供する。ここで、「ワークキュー（「ワークロード」と呼ばれることもある）」という用語は、メモリ内のある場所で定義されたワーク（例えばメインメモリ１０６で定義されたＳＰＵワーク）を意味するものとして使われる。これは、多くの場合、タスク定義のキューである。しかしながら、ワーク定義の他の態様も使用可能である。ワークキューと関連づけられたポリシーモジュールは、このワークがどのように解釈されて実行されるかを決定する。したがって、ポリシーモジュールはワークキュー１１８を解釈する。通常、ワークキューは、複数のＳＰＵによって処理可能である一群のタスクまたはジョブである。ＳＰＵＲＳタスクセット、またはＳＰＵタスク管理（ＳＴＭ）ジョブリストは、ワークロードの例である。

ここで、「ポリシーモジュール」とは、プログラミングモデルとタスク実行方式を定義するＳＰＵ上の小さなマネージャオブジェクトのことである。ワークキュー１１８を処理するためのＳＰＵバイナリコードとしてポリシーモジュールを実装してもよい。本発明の実施形態にしたがって実装される所与のアプリケーション用のソフトウェア開発キット（ＳＤＫ）は、与えられたワークキューの実装の仕方に応じて異なるポリシーを使用できる。例えば、マルチタスキングのためにあるポリシーを使用し、ジョブストリーミングのための別のポリシーを使用してもよい。ジョブストリーミングは、ＳＴＭ処理モデルでは一般的な用語である。所与のポリシーモジュールは、ＳＰＵワークを実行するために残りのＳＰＵメモリ内のコードおよび／またはデータを管理することができる。現在のワークキューを実行するために必要なら、メインＲＡＭからＳＰＵローカルストレージにポリシーモジュールを転送してもよい。ＳＰＵからＳＰＵへポリシーモジュールを転送する他の方式があることは本発明者らも認めるところである。ＳＰＭＭカーネルは、実行されるときはいつでも、一般に新しいワークキューを選ぶ。

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

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

例えば、ポリシーモジュールとワークキューは次のように関連づけられてもよい。図１の下側に示すように、メインメモリ１０６は一組のワーク定義１１６を持つワークキューアレイ１１４を含んでもよい。ワークキューアレイは、任意の数の対応するワークキュー１１８に対して任意の数のワーク定義１１６を備えてもよい。ワークキューアレイ１１４が収容可能なワークキューの数は、ワークキュー処理の有用性に基づき決められてもよい。一部の実施形態では、ワークキューアレイ１１４内に１６個のワークキューについての定義がある場合、ＳＰＵ１０４の間で非常に効率的にワークキュー１１８をスケジュールすることができる。例えば、ＳＰＭＭカーネル１１２が限られた量（例えば約２キロバイト）のオーバーヘッドを有し、セルプロセッサ１００が８個のＳＰＵを有する場合、１６個のワークキューのスケジューリングを特に効率的にすることができる。

表Ｉは、ワークキューアレイ１１４に格納されるワーク定義１１６のデータ構造例を示す。

表１は、一つのありうるワーク定義を代表して示す。ワーク定義データ構造の特定の内容は、表１の内容とは異なっていてもよい。一般に、各ワーク定義１１６は、対応するワークキュー（ＷＱ）１１８に対するメモリアドレスへのポインタを含む。メモリアドレスは、ＲＡＭで定義されたＳＰＵワークを含み、ＳＰＵワークは、ワークキュー１１８に対するコードとデータの両方を含んでもよい。ワークキューの例は、タスクセットまたはタスクキュー等で特徴づけられるタスクと、ジョブチェーンにより特徴づけられるジョブとを含む。タスクとジョブの両方が、関連するワークを実行することに関連するコードおよび／またはジョブを含んでもよい。タスクは以下のようにしてジョブと区別されてもよい。本明細書では、タスクとは、関連するコンテクストを有するという点でスレッドと類似するワークのことを指す。そのようなものとして、タスクは完了の中間段階である時点でＳＰＵへと、およびＳＰＵからスワップすることができる。対照的に、ジョブはコンテクストとは関連しない。結果として、ジョブは完全に実行される。すなわち、一旦ＳＰＵがジョブの作業を開始すると、ジョブが完了するまでＳＰＵは動作する。ジョブに関連するデータは、そのジョブを完了するのに必要であるＳＰＵローカルメモリ１１０の空間の量を定義してもよい。

ワークキュー定義１１６は、対応するＷＱ１１８のステートに対する値を含んでもよい。ワークキューのステートは、ＰＰＵ１０２またはＳＰＵ１０４から設定することができる。ステートの例として、（ａ）ＳＰＭ＿ＲＥＡＤＹ−：ＷＱ１１８はレディ（準備完了）ワークを含む、（ｂ）ＳＰＭ＿ＥＭＰＴＹ−ＷＱ：ＷＱ１１８はレディワークをもたない、および（ｃ）ＳＰＭ＿ＦＲＥＥ−ＷＱ：ＷＱ１１８はもはや使用されていない、といったものがある。

競合度は、与えられたＷＱ１１８の作業に取り組んでいるＳＰＵ１０４の数のことである。ワークのタイプによっては、与えられたＷＱ１１８に取り組むことができるＳＰＵ１０４の最大数が設けられてもよい。この数をワーク定義１１６の一部として格納してもよい。ワークの特定のタイプは、効率的な処理のために二つ以上のＳＰＵを必要とする。そのような場合、一つのＳＰＵの出力は、更なる処理のために第２のＳＰＵに転送されてもよい。そのような事例を扱うために、最小競合度（すなわちそのワークを処理するために必要なＳＰＵの最小数）を定めることは、役に立つ。この数をワーク定義１１６の一部として格納することもできる。特定のワークキューについての最小競合値は、そのワークキュー内のワークの性質に基づいて選択されてもよい。例えば、タスクワークキューはタスク間で相互依存性を有していることが多く、二つ以上のＳＰＵをそれらワークに割り当てることが利益になることがある。したがって、一つのタスクワークキューに対する最小競合度の値を、セルプロセッサ１００内のＳＰＵの総数（例えば、図１のシステムでは８個）に等しく設定することが望ましい。対照的に、ジョブワークキューは、ワークについての競合度がＳＰＵ１０４間で均衡している場合に、より良く機能する傾向がある。したがって、ジョブワークキューについての最小競合度の値を１に等しく設定することがさらに望ましい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上述の議論から、図２Ａのステップ２０２において、優先権の階層にしたがってワークキュー１１８がＳＰＵ１０４に割り当てられることが分かる。例として、図２Ｂに関して述べたワーク割り当ての優先権順序についての５層の階層を、以下のように要約することができる。

１．スケジュール可能性（schedulability）。スケジュール可能なワークは、スケジュール不可能であるワークよりも高い優先度を持つ。上述のように、ワークがスケジュール可能でない状況の例には、
ａ．優先度＝０、
ｂ．ワークキュー状態＝ＳＰＭエンプティ、すなわち、ステップ２２８においてＷがレディ（準備完了）でない、
ｃ．競合度が最大競合度以上、がある。

２．優先度。二つ以上のワークキューがスケジュール可能であると仮定すると、より高い優先度のワークを持つワークキューは、低い優先度を持つワークキューよりも好ましい。例として、高い優先度を低い（ゼロでない）優先度の値と関連づけてもよい。例えば、優先度１のワークは優先度２のワークに対して優先する。

３．緊急度。二つ以上のスケジュール可能なワークキュー１１８が同じ優先度を持つ場合、緊急であるワークキューが緊急でないワークキューよりも好まれる。例えば、競合度がゼロより大きいが最小競合度よりも小さいワークキューを、そうでないワークよりも緊急度が高く優先するとみなしてもよい。

４．バランスの取れた競合度。二つ以上のスケジュール可能なワークキュー１１８の優先度が等しく緊急度が等しい場合、可能な限り競合度のバランスを取るために、競合度の小さいワークキューが好まれる。

５．ポリシーモジュールのアフィニティ。二つ以上のスケジュール可能なワークキュー１１８の優先度が等しく、緊急度が等しく、それらの競合度がバランスの取れている場合、特定のＳＰＵにワークを割り当てるときに、自身のポリシーモジュールが既にその特定のＳＰＵ１０４のローカルストア１１０にロードされているワークキューが、そうでないワークキューよりも好まれる。

本発明の実施形態では、優先権を決定する際にさらなる考慮をすることで、様々なＳＰＵ１０４間でのより均一なワークの分配を通じてパフォーマンスを強化してもよい。特に、以下の表ＩＩＩに示すようにワーク定義１１６を構成してもよい。

表ＩＩＩにおいて、レディカウントはワークキュー１１８によって要求されるＳＰＵの数のことを言う。特定のワークキュー１１８に処理するものがないことを意味するために、値０のレディカウントを用いることができる。例えば、特定のワークキュー内に処理するものがないとポリシーモジュールが決定すると、ポリシーモジュールはレディカウントを０にリセットしてもよい。０より大きいレディカウント値は、与えられたワークキューを処理するために生じるＳＰＵ数の推定である。レディカウント値は、特定のワークキュー上で作業するのに最適なＳＰＵの数である必要はない。代わりに、レディカウント値は、特定のワークキュー１１８上で作業するために受け入れ可能なＳＰＵの数を表してもよい。

ある状況においては、特定のワークロード１１８は、レディカウント値に加えてある数の利用可能なＳＰＵにそのワークを割り当て可能である場合、特定のワークキュー１１８に割り当てるＳＰＵの数をさらに最適化することで利益を得ることができる。このような状況に対処するため、ワークキュー定義１１６はアイドルＳＰＵリクエストカウント（アイドルカウントとしても知られる）を含んでもよい。アイドルのＳＰＵがある場合、アイドルカウントは、ワークキュー１１８の処理を助けることができる、レディカウント値の他のＳＰＵの数を表している。アイドルカウントの利点は、利用可能であるＳＰＵの数が理想値より少ない場合でさえも、ＳＰＵがワークキュー１１８の処理を開始できる点である。例えば、ワークキュー１１８は理想的には４個のＳＰＵで処理されるべきだが、１個のＳＰＵでの処理も許容可能であると仮定する。このようなワークキューに対するワーク定義は、レディカウント値が１でありアイドルカウント値が３であってもよい。アイドルカウントを使用すると、１個のＳＰＵが利用可能になったが最大３個の追加のＳＰＵが利用可能になるまでそれらのＳＰＵを割り当てる可能性を開いたままにしている場合に、このようなワークキューの処理を開始することができる。

ワーク定義１１６は、２以上のレベルのアイドルカウントを持ってもよいことに注意する。例えば、ワーク定義１１６が第１、第２、第３レベルのアイドルカウントを有し、それぞれが３、２、１であってもよい。この場合、利用可能であれば３個の追加のＳＰＵが要求され、それが不可の場合、利用可能であれば２個のＳＰＵが要求され、それも不可の場合、利用可能であれば１個のＳＰＵが要求される。

表３に示すように、ワーク定義１１６は、優先権を割り当てるときに、与えられたワークキュー１１８内のワークのタイプを考慮に入れてもよい。例えば、他の全ての検討事項が等しいとした場合、実行されるべきタスクまたはジョブの性質に基づき、あるタイプのワークキュー１１８を他に優先させてもよい。この状況に対処するために、ワーク定義１１６は、実行されるべきワークのタイプに関連するワークキューＩＤを含んでもよい。ワークキューＩＤは、実行されるべきワークのタイプ（例えばメモリ管理ワーク対アプリケーション特有の計算）によってワークキュー１１８を分類する。

レディカウント、アイドルカウントおよびワークキューＩＤを考慮に入れる場合、上述したような特定のＳＰＵ１０４に対してワークキューからワークを割り当てる際の優先権の階層を、８層の階層を形成するように修正することができる。これは、以下のように要約できる。

１．スケジュール可能性。スケジュール可能なワークのみがＳＰＵによりアクセス可能である。上述したように、ワークがスケジュール可能でない状況の例は、以下を含む。
ａ．優先度＝０
ｂ．レディカウント＝０
ｃ．競合度が最大競合度以上
ｄ．競合度が（レディカウント＋アイドルカウント）以上。これにより、過剰のＳＰＵが特定のワークキュー１１８に割り当てられることが防止される。

２．レディネス。スケジュール可能なワークに対して、他の全ての条件よりもレディネスが優先される。特に、競合度がレディカウントよりも小さいワークキュー１１８は、そうでない別のワークキューよりも優先する。代わりに、あるアプリケーションでは、レディカウントと競合度の間の差分に応じた「レディネス」の階層があることが望ましい。例えば、競合度＝１、レディカウント＝３のワークロードが、競合度＝１、レディカウント＝２のワークロードより優先してもよい。

３．優先度。二つ以上のワークキュー１１８がスケジュール可能であり等しく準備可能である（例えば、レディカウント＜競合度）であると仮定した場合、優先度の高いワークを有するワークキューは、優先度の低いワークキューよりも好ましい。上の例で述べたように、より高い優先度を低い（ゼロでない）優先度の値と関連させてもよい。例えば、優先度１のワークは優先度２のワークよりも優先する。

４．ワークキューのアフィニティ。二つ以上のスケジュール可能なワークキュー１１８が等しいレディネスと等しい優先度を持つ場合、特定のＳＰＵにワークを割り当てるとき、その特定のＳＰＵ１０４のローカルストア１１０内に自身のコードおよび／またはデータが既にロードされているワークキューは、そうでないワークキューよりも好ましい。

５．緊急度。二つ以上のスケジュール可能なワークキュー１１８が等しいレディネス、等しい優先度および等しいワークキューアフィニティを持つ場合、緊急度の高いタスクを有するワークキューは、緊急度の低いワークキューよりも優先する。例えば、競合度が０以上であるが最小競合度よりも小さいワークキューを、そうでないワークよりも緊急度が高く優先権を持つとみなしてもよい。

６．バランスの取れた競合度。二つ以上のスケジュール可能なワークキュー１１８が等しいレディネス、等しい優先度、等しいワークキューアフィニティおよび等しい緊急度を持つ場合、可能な限り競合度のバランスを取るために、特定のＳＰＵ１０４に対してワークを割り当てるとき、競合度の小さいワークキューが好まれる。

７．ポリシーモジュールのアフィニティ。二つ以上のスケジュール可能なワークキュー１１８が等しい優先度、等しいワークキューアフィニティ、等しい緊急度を持ち、かつ競合度のバランスが取れている場合、特定のＳＰＵにワークを割り当てるとき、その特定のＳＰＵ１０４のローカルストア１１０内に自身のポリシーモジュールが既にロードされているワークキューは、そうでないワークキューよりも好ましい。

８．ワークロードＩＤ。二つ以上のスケジュール可能なワークキュー１１８が等しい優先度、等しいワークキューアフィニティ、等しい緊急度、等しいポリシーモジュールアフィニティを持ち、かつ競合度のバランスが取れている場合、特定のＳＰＵ１０４にワークを割り当てるとき、より好ましいワークロードＩＤを有するワークキューは、好適度の低いワークロードＩＤを有するワークキューよりも好ましい。例えば、あるワークロードＩＤが別のワークロードＩＤよりも小さい数値を有する場合、それは好ましい。

上述のスケジューリング優先権は、多くの可能性のあるスケジューリング優先権の階層の一例である。優先権の順序を再配置することも可能であり、また異なる挙動を達成するために項目を取り除くこともできる。例えば、第４項目（ワークキューアフィニティ）を取り除くと、デベロッパにより好ましい態様でワークキューがスケジュールされるが、（レディ状態になる他のワークキューおよびレディ状態から出る他のワークキューを産み出すとき）ワークキューのスラッシング（thrashing）がより多くなる結果となりうる。

本発明の実施形態によると、特定のプログラム上で作業する異なるデベロッパが、異なるスケジューリングパラメータに対しての責任を持ってもよい。例えば、ポリシーモジュールデベロッパがポリシーモジュール（ＰＭ）コードを実装する責任を有し、および／またはＰＭアプリケーション・プログラミング・インタフェース（ＡＰＩ）を収集して（library）、ＰＭコードを使用するためのワークキュー１１８を作成および操作してもよい。ポリシーモジュールデベロッパは、ワークキュー１１８に関連するポリシーモジュールについて最小競合度の値を決定してもよい。選択的に、ポリシーモジュールデベロッパは、レディカウント値およびアイドルカウント値を決定してもよい。

ワークキューデベロッパは、ポリシーモジュールデベロッパにより作成されたＰＭ ＡＰＩを通じてワークキュー１１８を作成および操作してもよい。ワークキューデベロッパは、ポリシーモジュールデベロッパにより決定された対応するポリシーモジュールによって許可される範囲で、ワークキュー１１８についてのレディカウントおよび／またはアイドルカウントを決定してもよい。ワークキューデベロッパは、コードおよび／またはデータライブラリの形態でワークキュー１１８を実装してもよい。

インテグレータは、上記デベロッパからコードおよび／またはライブラリを受け取り、それらを結合して、単一のＳＰＵタスクシステムインスタンスを共有するアプリケーションを形成する。本明細書では、ＳＰＵタスクシステムインスタンスとは、アプリケーション内でのＳＰＵタスクシステムの一つのインスタンス化のコンテクストのことを指す。ＳＰＵタスクシステムインスタンスは、関連するＳＰＵスレッドグループ、例えばセルプロセッサ１００内のＳＰＵ間におけるワークキューの特定の割り当てを含んでもよい。典型的なアプリケーションでは、セルプロセッサ１００は通常（しかし常にではなく）、一度に一つのＳＰＵタスクシステムインスタンスを実装する。インテグレータは、各ワークキュー１１８について最大競合度の値を決定し、各ワークキュー１１８についてＳＰＵ毎の（Per-SPU）優先度を含むＳＰＵ優先度リストを作成してもよい。ＳＰＵ優先度リストは、ワークロードスケジューリングに対する優れた制御をインテグレータに与える。

表ＩＩＩの優先権階層を使用したセルプロセッサの動作は、図２Ｃないし図２Ｈを参照することで理解できる。図２Ｃに示すように、８個のＳＰＵ１０４による実装のために、複数のワークキュー１１８_０、．．．、１１８_１５をスケジュールすることができる。図２Ｃでは、説明のためにＳＰＵスレッドグループ内に６個のＳＰＵのみが描かれている。例として、限定ではなく、ＳＰＭＭカーネル１１２は、アトミック通知器（Atomic Notifier）１１９を使用して、ワークキュー１１８_０、．．．、１１８_１５のスケジュールをすることができる。アトミック通知器１１９は、関連するワークキュースケジューリングパラメータを含む例えば１２８バイトのデータ構造であってもよい。ワークキュー１１８_０、．．．、１１８_１５は、タスクポリシーモジュール（図中のタスクモジュール）とタスクセット１１８_Ｔにより定義されるワークとを有するタスクワークキュー１１８_０を備えてもよい。一部の実施形態では、タスクワークキュー１１８_０内のタスク数に上限があってもよい。例えば、メインメモリ１０６が上限値以上を収容可能であったとしても、与えられたタスクワークキューについて１２８個のタスクの上限があってもよい。ワークキュー１１８_０、．．．、１１８_１５は、ジョブポリシーモジュール（図中のジョブモジュールjob mod）とジョブチェーン１１８_Ｊにより定義されるワークとを有するジョブワークキュー１１８_１をさらに備えてもよい。ジョブチェーン内のジョブの数は、ほとんど上限がなくてもよい。例えば、ジョブの数は、メインメモリ１０６内で利用可能なメモリ空間への配慮のみによって制限される。ワークキュー１１８_０、．．．、１１８_１５は、カスタムポリシーモジュール（図中のＸモジュール）と、例えばある種のコードおよびデータであるカスタムワーク１１８_Ｘとを有するカスタムワークキュー１１８_１５をさらに備えてもよい。カスタムワークキュー１１８_１５は、本明細書で定義している「タスク」または「ジョブ」のいずれの記述にも当てはまらないカテゴリに分類されてもよい。

ワークキュー１１８_０、．．．、１１８_１５のそれぞれは、ＳＰＵ毎の優先度の値を有し、レディカウント（レディ）、最大競合度（最大）、最小競合度（最小）の値を格納する、対応するワーク定義１１６_０、．．．、１１６_１５を含む。競合するワークキュー１１８_０、．．．、１１８_１５の優先度の値の組合せが、優先度テーブル１１７を形成する。図２Ｃにおいて、優先度テーブル１１７の各列は、セルプロセッサ１００内の特定のＳＰＵに対応する。優先度テーブルの各行は、特定のワークキューに対応する。図２Ｃに示す例では、全てのワークキュー１１８_０、．．．、１１８_１５は、「レディネス」が等しい、例えば競合度＜レディカウントが成立する。したがって、ＳＰＵ割り当てにおける優先権は、低い優先度の値を有するワークキューに与えられる。図２Ｃから分かるように、ＳＰＵの列内で最小の優先度値に基づき、優先度テーブルから選択されるＳＰＵにワークが割り当てられる。例えば、ＳＰＵ０とＳＰＵ１に対して、タスクワークキュー１１８_０が最小の優先度値を有し、優先される。したがって、ＳＰＵ０およびＳＰＵ１がワークキュー１１８_０に割り当てられる。ＳＰＵ２、ＳＰＵ４およびＳＰＵ５に対しては、ジョブワークキュー１１８_１が最小の優先度値を有し、他の全てに対して優先する。したがって、ＳＰＵ２、ＳＰＵ４およびＳＰＵ５がジョブワークキュー１１８_１に割り当てられる。ＳＰＵ３については、カスタムワークキュー１１８_１５が最小の優先度値を有し、ＳＰＵ３がカスタムワークキュー１１８_１５に割り当てられる。

図２Ｃは、スケジュール可能性および緊急度のコンセプトも示している。全てのワークキュー１１８_０、．．．、１１８_１５について、優先度テーブル１１７は、ＳＰＵ６とＳＰＵ７に対して優先度値０を示していることに注意する。これは、ＳＰＵ６とＳＰＵ７に対してワークが割り当てられないことを意味する。さらに、ワークキュー１１８_０について、最小競合度（最小）が８に等しく、これは他のワークキューについての値よりも大きい。これは、ワークキュー１１８_０が他よりも緊急度が高いことを示している。しかしながら、優先度は緊急度よりも優先するので、ＳＰＵは、ＳＰＵ毎の優先度をベースにしてワークキューに割り当てられる。

図２Ｄは、競合度のバランシングの一例を示す。この例では、３つのジョブワークキュー１１８_Ａ、１１８_Ｂおよび１１８_Ｃが、６個の利用可能なＳＰＵを求めて競争する。優先度テーブル１１７から分かるように、３つ全てのワークキューが全てのＳＰＵに対して同じ優先度を有している。さらに、３つ全てのワークキューが、同一値のレディカウント、最小競合度および最大競合度を有している。この例では、さらにワークキュー１１８_Ａ、１１８_Ｂおよび１１８_Ｃに関連する各ジョブチェーンについて、アイドルカウントが８に等しいという仮定もされている。さらに、全てのワークキューが最初に同一のポリシーモジュールアフィニティを有するという仮定もされている。例えば、ＳＰＵのいずれもが、自身のローカルストアにロードされたポリシーモジュールを最初に有していなくてもよい。代わりに、全てのＳＰＵが、ワークキュー１１８_Ａ、１１８_Ｂおよび１１８_Ｃについてのポリシーモジュールとは異なるポリシーモジュールを有していてもよい。さらに、ワークキュー１１８_Ａ、１１８_Ｂおよび１１８_Ｃのそれぞれが同一のポリシーモジュールを有しており、このポリシーモジュールが各ＳＰＵに前もってロードされているとしてもよい。

上述の階層の基準１および２に基づき、最初に、レディカウントが競合度よりも小さいワークキューにＳＰＵが割り当てられる。３つ全てのワークキューのスケジュール可能性およびレディが等しくなると、基準３（優先度）が優先する。しかしながら、この例では、全てのワークキューが全てのＳＰＵについて等しい優先度を持つ。さらに、全てのワークキューのポリシーモジュールアフィニティと緊急度が等しいので、残りのＳＰＵは、基準６にしたがって、すなわち競合度をバランスさせる態様でワークキューに割り当てられる。よって、ＳＰＵ０とＳＰＵ２はワークキュー１１８_Ａ上のワークに割り当てられ、ＳＰＵ３とＳＰＵ５はワークキュー１１８_Ｂ上のワークに割り当てられ、ＳＰＵ４とＳＰＵ６はワークキュー１１８_Ｃ上のワークに割り当てられる。したがって、この例では、利用可能なＳＰＵを求めて競争するワークキューの間でできるだけ競合度がバランスするように、優先度テーブルが構成されている。

図２Ｅは、ＳＰＵの割り当てにおいてレディカウントの値が異なることによる影響の例を示す。この例では、優先度テーブルは図２Ｄのものと同一である。しかしながら、ワークキュー１１８_Ａについてのレディカウントは８に等しいが、ワークキュー１１８_Ｂおよび１１８_Ｃについてのレディカウント値はそれぞれ１に等しい、最初に、ＳＰＵ０がワークキュー１１８_Ａに割り当てられ、ＳＰＵ１がワークキュー１１８_Ｂに割り当てられ、ＳＰＵ２がワークキュー１１８_Ｃに割り当てられる。この最初の割り当てが生じると、ワークキュー１１８_Ｂおよび１１８_Ｃについて、レディカウント＝競合度＝１が成り立つ。しかしながら、ワークキュー１１８_Ａは、自身の競合度よりも小さいレディカウントを有するので、ＳＰＵ３、ＳＰＵ４およびＳＰＵ５は優先的にワークキュー１１８_Ａに割り当てられる。

階層内でのレディカウントの位置を使用して、セルプロセッサ１００内の利用可能なＳＰＵの全てを特定のワークキューが独占できないように保証してもよい。例えば、図２Ｆにおいて、全てのＳＰＵについてワークキュー１１８_Ａが優先度１を有し、ワークキュー１１８_Ｂ、１１８_Ｃは優先度２を有するように優先度テーブル１１７が構成される。さらに、ワークキュー１１８_Ａ、１１８_Ｂ、１１８_Ｃの全てが、レディカウント＝１、最大競合度＝８、最小競合度＝１、アイドルリクエストカント＝８である。最初に、「レディネス」に基づき、すなわち競合度がレディカウント以下であるかに基づき、ワークキュー１１８_Ａ、１１８_Ｂ、１１８_ＣにＳＰＵが割り当てられる。最初は「レディネス」が「優先度」よりも優先するので、ＳＰＵ０がワークキュー１１８_Ａに割り当てられ、ＳＰＵ１がワークキュー１１８_Ｂに割り当てられ、ＳＰＵ２がワークキュー１１８_Ｃに割り当てられる。この時点で、３つ全てのワークキューが等しい「レディネス」を有する。したがって、上述の階層に基づいて、より低い優先度値に基づきＳＰＵ３、ＳＰＵ４およびＳＰＵ５が続けてワークキュー１１８_Ａに割り当てられる。ワークキュー１１８_Ａについての競合度＝４であり、依然として（レディカウント＋アイドルリクエストカウント＝９）よりも小さいので、この割り当ては「スケジュール可能性」の要件に違反しない。

ワークキューについてのレディカウント値に応じて、より多くのＳＰＵをより低い優先度のワークに割り当てることが可能である。例えば、図２Ｇは図２Ｆにおける状況を示しており、全てのＳＰＵについてワークキュー１１８_Ａが優先度１を有し、ワークキュー１１８_Ｂ、１１８_Ｃが優先度２を有するように優先度テーブル１１７が構成される。しかしながら、ワークキュー１１８_Ａはレディカウント「１」を有する一方、ワークキュー１１８_Ｂ、１１８_Ｃはレディカント「８」を有する。したがって、最初にＳＰＵ０がワークキュー１１８_Ａに割り当てられ、ＳＰＵ１がワークキュー１１８_Ｂに割り当てられ、ＳＰＵ２がワークキュー１１８_Ｃに割り当てられる。この時点で、ワークキュー１１８_Ａについてのレディネスは満足しているが、ワークキュー１１８_Ｂ、１１８_Ｃについては満足していない。したがって、上述の階層に基づき、たとえ優先度の観点からは好適度が低くても、競合度がレディカウントよりも小さいワークキューに残りの利用可能なＳＰＵが割り当てられる。ポリシーモジュールアフィニティが等しいと仮定すると、ワークキュー１１８_Ｂおよびワークキュー１１８_Ｃの間で競合度のバランスを試みる方法で利用可能なＳＰＵの割り当てがなされる。これは、レディネス、優先度、ポリシーモジュールアフィニティおよび緊急度が等しい場合、基準６（バランスの取れた競合度）が適用されるからである。

上述したように、単一のワークキューによるＳＰＵの独占を防止するように、一般的には階層パラメータ、特に優先度テーブル１１７を構成することができる。しかしながら、この階層の文脈の範囲内で、一つのワークキューが全ての利用可能なＳＰＵを独占するようにパラメータおよび優先度テーブルを構成することも可能である。例えば、図２Ｈに示すように、優先度テーブル１１７を以下のように構成することができる。ワークキュー１１８_Ａ、１１８_Ｂ、１１８_Ｃの全てが、レディカウント＝８、最大競合度＝８、最小競合度＝１、アイドルリクエストカウント＝８を有する。ワークキュー１１８_Ａが全てのＳＰＵについて優先度＝１を有する一方で、ワークキュー１１８_Ｂ、１１８_Ｃは全てのＳＰＵについて優先度＝２を有する。この例では、レディカウントが競合度に等しくなるまで、全てのワークキューが等しいレディネスを有する点に注意する。しかしながら、レディカウントが利用可能なＳＰＵの数以上であるため、３つ全てのワークキュー１１８_Ａ、１１８_Ｂ、１１８_Ｃについてこのことが当てはまる。他よりも「レディ」が大きいワークキューがないので、基準３にしたがい優先度に基づきＳＰＵが割り当てられ、全ての利用可能なＳＰＵがワークキュー１１８_Ａに割り当てられる。

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

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

図３Ｂから分かるように、ＳＰＵＲＳ等のＳＰＵタスクシステム内にＳＰＭＭが組み込まれていてもよい。この場合、上述のＳＰＵタスクシステムインスタンスは、ＳＰＵＲＳインスタンス、すなわち、関連するＳＰＵスレッドグループを含むＳＰＵＲＳの一つのインスタンス化のコンテクストを指定してもよい。ＳＰＭＭ１１２をＳＰＵＲＳカーネルとみなしてもよい。ＳＰＵＲＳカーネルは、例えば、ワークキュー１１８をスケジュールしポリシーモジュールをＳＰＵローカルストア１１０にロードする全てのＳＰＵＲＳ ＳＰＵスレッド上に常駐する比較的小さなバイナリコードである。

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

ＳＰＭＭの長所は、ワークの性質の要求に応じて、ＳＰＵＲＳおよび他のポリシーを簡単に切り替えることができることである。例えば、図３Ｅは、ローカルストレージ３２０に対するメモリマップを示し、ここでは、ＳＰＵタスクマネージャ（ＳＴＭ）３２２はＳＰＭＭ３１２支配下のポリシーとしてを実装されている。ＳＴＭポリシー３３２は、タスク・コード３３４とタスクデータ３３６、３３８のセットをもつＳＴＭタスクセットを管理する。ＳＴＭポリシー３３２は、メインメモリに格納された一つ以上のタスク定義をローカルストレージ３２０に読み出す。タスク定義に含まれる情報に基づいて、ＳＰＵはタスク定義に関連したコードやデータをメインメモリから、選択されたＳＰＵに関連づけられたローカルメモリにロードする。選択されたＳＰＵはそのコードやデータを用いて一つ以上のタスクを実行する。ＳＴＭが複数のＳＴＭタスクに対して同じプログラムスタートアドレスでＳＰＭＭ上を走るように、ＳＴＭを修正することができる。ＳＰＭＭ３１２下で走っているときは、ＳＴＭポリシー３３２は複数のタスクセットを管理する必要はない。ＳＴＭは、本出願と譲受人が共通する米国特許出願１１／２３８，０８７号、"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 (47)

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. 各ワーク定義はワークキューのメモリアドレスとポリシー定義のメモリアドレスを含む請求項２８または２９に記載のプロセッサ。
31. 各ワーク定義は第２処理要素毎の優先度の値を含む請求項３０に記載のプロセッサ。
32. 各ワーク定義はレディカウント値を含む請求項３０または３１に記載のプロセッサ。
33. 各ワーク定義は最大許容競合値を含む請求項３０ないし３２のいずれかに記載のプロセッサ。
34. 各ワーク定義は最小競合値を含む請求項３０ないし３３のいずれかに記載のプロセッサ。
35. 各ワーク定義はアイドルリクエストカウント値を含む請求項３０ないし３４のいずれかに記載のプロセッサ。
36. 前記ポリシー定義はポリシーモジュール第２処理要素コードイメージのアドレスを含む請求項３０ないし３５のいずれかに記載のプロセッサ。
37. 前記ワークキューの前記メモリアドレスはコードとデータの両方を含む請求項３０ないし３６のいずれかに記載のプロセッサ。
38. 前記選択された一つ以上のワークキューを前記メインメモリから前記選択された一つ以上の第２処理要素に割り当てる際に、ワークキューのスケジュール可能性が他の全ての検討事項よりも優先するように前記優先権の階層が構成される請求項２７ないし３７のいずれかに記載のプロセッサ。
39. 前記選択された一つ以上のワークキューを前記メインメモリから前記選択された一つ以上の第２処理要素に割り当てる際に、ワークキューのスケジュール可能性が該ワークキューのレディネスよりも優先し、かつ該ワークキューのレディネスが他の全ての検討事項よりも優先するように前記優先権の階層が構成される請求項２７ないし３８のいずれかに記載のプロセッサ。
40. 前記選択された一つ以上のワークキューを前記メインメモリから前記選択された一つ以上の第２処理要素に割り当てる際に、ワークキューのスケジュール可能性がレディネスよりも優先し、該ワークキューのレディネスが該ワークキューの第２処理要素毎の優先度に優先し、該ワークキューの第２処理要素毎の優先度が他の全ての検討事項よりも優先するように前記優先権の階層が構成される請求項２７ないし３９のいずれかに記載のプロセッサ。
41. 前記選択された一つ以上のワークキューを前記メインメモリから前記選択された一つ以上の第２処理要素に割り当てる際に、ワークキューのスケジュール可能性が該ワークキューのレディネスよりも優先し、該ワークキューのレディネスが該ワークキューの第２処理要素毎の優先度に優先し、該ワークキューの優先度が該ワークキューのワークキューアフィニティよりも優先し、該ワークキューのワークキューアフィニティが他の全ての検討事項よりも優先するように前記優先権の階層が構成される請求項２７ないし４０のいずれかに記載のプロセッサ。
42. 前記選択された一つ以上のワークキューを前記メインメモリから前記選択された一つ以上の第２処理要素に割り当てる際に、ワークキューのスケジュール可能性が該ワークキューのレディネスよりも優先し、該ワークキューのレディネスが該ワークキューの第２処理要素毎の優先度に優先し、該ワークキューの第２処理要素毎の優先度が該ワークキューのワークキューアフィニティよりも優先し、該ワークキューのワークキューアフィニティが前記一つ以上の選択されたワークキューのバランスの取れた競合度よりも優先し、前記一つ以上の選択されたワークキューのバランスの取れた競合度が他の全ての検討事項よりも優先するように前記優先権の階層が構成される請求項２７ないし４１のいずれかに記載のプロセッサ。
43. 前記選択された一つ以上のワークキューを前記メインメモリから前記選択された一つ以上の第２処理要素に割り当てる際に、ワークキューのスケジュール可能性が該ワークキューのレディネスよりも優先し、該ワークキューのレディネスが該ワークキューの第２処理要素毎の優先度に優先し、該ワークキューの第２処理要素毎の優先度が該ワークキューのワークキューアフィニティよりも優先し、該ワークキューのワークキューアフィニティが前記一つ以上の選択されたワークキューのバランスの取れた競合度よりも優先し、前記一つ以上の選択されたワークキューのバランスの取れた競合度が該ワークキューのポリシーモジュールアフィニティよりも優先し、該ワークキューのポリシーモジュールアフィニティが他の全ての検討事項よりも優先するように前記優先権の階層が構成される請求項２７ないし４２のいずれかに記載のプロセッサ。
44. 前記選択された一つ以上のワークキューを前記メインメモリから前記選択された一つ以上の第２処理要素に割り当てる際に、ワークキューのスケジュール可能性が該ワークキューのレディネスよりも優先し、該ワークキューのレディネスが該ワークキューの第２処理要素毎の優先度に優先し、該ワークキューの第２処理要素毎の優先度が該ワークキューのワークキューアフィニティよりも優先し、該ワークキューのワークキューアフィニティが前記一つ以上の選択されたワークキューのバランスの取れた競合度よりも優先し、前記一つ以上の選択されたワークキューのバランスの取れた競合度が該ワークキューのポリシーモジュールアフィニティよりも優先し、該ワークキューのポリシーモジュールアフィニティが該ワークキューのワークロードＩＤよりも優先し、該ワークキューのワークロードＩＤが他の全ての検討事項よりも優先するように前記優先権の階層が構成される請求項２７ないし４３のいずれかに記載のプロセッサ。
45. ユーザインタフェースをさらに備え、該ユーザインタフェースは、前記選択された一つ以上のワークキューの一つ以上のパラメータをユーザが調整できるように構成されている請求項２７ないし４４のいずれかに記載のプロセッサ。
46. データプロセッシングシステムであって、
    一つ以上のプロセッサを含み、
    各プロセッサは、メインメモリと、中央プロセッサユニットと、一つ以上の第２処理要素とを含み、
    各第２処理要素は、プロセッサとローカルメモリを有し、
    前記メモリ、前記中央プロセッサユニット、前記第２処理要素は互いにデータバスで結合されており、
    前記メインメモリまたは前記ローカルメモリは、一つ以上の第２処理要素上でコードとデータを管理する方法を実行するためのプロセッサで実行可能なインストラクションを含み、
    当該方法は、
    一つ以上の第２処理要素上で実行されるポリシーモジュールマネージャが、優先権の階層にしたがって、選択された一つ以上のワークキューを、メインメモリから、選択された一つ以上の第２処理要素に割り当てるステップと、
    前記ポリシーモジュールマネージャが、選択された一つ以上のワークキュー用のポリシーモジュールを、前記選択された一つ以上の第２処理要素にロードするステップであって、前記ポリシーモジュールが自身のコンテクストデータを管理するように構成されている、ステップと、
    前記ポリシーモジュールが、前記選択された一つ以上のワークキューのうち選択された一つまたは複数を解釈するステップと、
    前記ポリシーモジュールが、前記選択された一つ以上のワークキューのうちの一つまたは複数からのワークを、前記選択された一つ以上の第２処理要素のローカルメモリにロードするステップと、
    前記選択された一つ以上の第２処理要素が、前記一つ以上のタスクを実行するステップと、
    前記タスクの完了後またはプリエンプションが起きたとき、前記ポリシーモジュールが、前記選択された一つ以上の第２処理要素の制御権を前記ポリシーモジュールマネージャに戻すステップと、
    を含むことを特徴とするデータプロセッシングシステム。
47. 中央プロセッサユニットと、それぞれがプロセッサとローカルメモリを有する一つ以上の第２処理要素とを含むプロセッサにおいて、前記一つ以上の第２処理要素上でコードとデータを管理する方法を実行するためのプロセッサ読み込み可能なインストラクションセットが具体化された非一時的なプロセッサ読み込み可能な記憶媒体であって、
    当該方法は、
    一つ以上の第２処理要素上で実行されるポリシーモジュールマネージャが、優先権の階層にしたがって、選択された一つ以上のワークキューを、メインメモリから、選択された一つ以上の第２処理要素に割り当てるステップと、
    前記ポリシーモジュールマネージャが、選択された一つ以上のワークキュー用のポリシーモジュールを、前記選択された一つ以上の第２処理要素にロードするステップであって、前記ポリシーモジュールが自身のコンテクストデータを管理するように構成されている、ステップと、
    前記ポリシーモジュールが、前記選択された一つ以上のワークキューのうち選択された一つまたは複数を解釈するステップと、
    前記ポリシーモジュールが、前記選択された一つ以上のワークキューのうちの一つまたは複数からのワークを、前記選択された一つ以上の第２処理要素のローカルメモリにロードするステップと、
    前記選択された一つ以上の第２処理要素が、前記一つ以上のタスクを実行するステップと、
    前記タスクの完了後またはプリエンプションが起きたとき、前記ポリシーモジュールが、前記一つ以上の第２処理要素の制御権を前記ポリシーモジュールマネージャに戻すステップと、
    を含むことを特徴とする媒体。

Images