(57)【要約】      （修正有）【課題】マルチコア処理システムにおいてデータ並列負荷及びタスク並列負荷の両方をスケジューリングする技術を提供する。【解決手段】実行ユニットが、１つ又は複数のコマンド・キューからのコマンドを処理する。コマンドがキュー上で利用可能になると、各々のユニットが、ワークグループの予約サイズだけ、コマンドのワークグループの残りのカウンタをアトミックにデクリメントし、ワークグループの範囲内にある対応するワークグループ数を処理する。ある範囲内にある全てのワークグループが処理されると、実行ユニットは、処理されたワークグループのカウンタをインクリメントする。処理済みワークグループのカウンタを、実行予定のワークグループのカウンタ内に格納された値にインクリメントするユニットが、コマンドの完了を知らせる。コマンドにアクセスする各々の実行ユニットはまた、見終わったワークグループのカウンタにマーク付けする。【選択図】図７
2011054161.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ装置へのコマンドをキューに入れるために第１のコマンド・キューを生成することと、
複数のワークグループを含むコマンドを前記第１のコマンド・キューにポストすることと、
前記複数のワークグループを識別するデータ構造体、前記コマンドに対応する予約サイズ、ワークグループの数を格納するカウンタ、及びまだ処理されていない前記ワークグループの数を格納するカウンタを前記コマンドと関連付けることと、
複数の実行ユニットの各々の実行ユニットによって、前記予約サイズに対応する、前記複数のワークグループの別個のN次元範囲を予約することと、
前記複数の実行ユニットの各々によって、前記対応するN次元範囲を処理することと、
各々の実行ユニットが処理した前記ワークグループの数だけ、まだ処理されていない前記ワークグループの数を格納する前記カウンタをデクリメントすることと、
まだ処理されていない前記ワークグループの数を格納する前記カウンタが「０」の値より小さいか又は「０」の値と等しくなるまで、前記予約すること、前記処理すること、及び前記デクリメントすることを繰り返すことと、
まだ処理されていない前記ワークグループの数を格納する前記カウンタが「０」の値より小さいか又は「０」の値と等しいとき、前記コマンドの完了を示すよう知らせることと、
を含む方法。
【請求項２】
前記複数の実行ユニットの１つの実行ユニットによって、まだ処理されていない前記ワークグループの数を格納する前記カウンタが「０」の値より小さいか又は０の値と等しいこと、及び、まだ処理されていない前記ワークグループの数を格納する前記カウンタの絶対値が、前記予約サイズの絶対値より小さいか又はこれと等しいことを検出することをさらに含み、
前記知らせることは、前記１つの実行ユニットによってのみ実行される、請求項１に記載の方法。
【請求項３】
前記データ構造体はまた、前記コマンドを見ることになっている実行ユニットの数を格納するカウンタと、前記コマンドを確認した実行ユニットの数を格納するカウンタとを含み、前記方法は、まだ処理されていない前記ワークグループの数を格納する前記カウンタが「０」より小さいか又は「０」と等しく、かつ、前記コマンドを確認した前記実行ユニットの数を格納する前記カウンタが、前記コマンドを見ることになっている前記実行ユニットの数を格納する前記カウンタとも等しいとき、前記第１のコマンド・キューから前記コマンドに対応するエントリを解放することさらに含む、請求項１に記載の方法。
【請求項４】
前記複数の実行ユニットの各々の実行ユニットは、処理コア、プロセッサ、処理スレッド、及び完全なコンピューティング・システムを含む、コマンドを実行するいずれかのコンピュータ装置とすることができる、請求項１に記載の方法。
【請求項５】
前記コマンド・キュー内に入ってくるコマンドのエントリについて少なくとも２つの利用可能なスロットが存在するかどうかを判断することと、
前記コマンド・キュー内に前記入ってくるコマンドのエントリについて少なくとも２つの利用可能なスロットが存在すると判断された場合、前記コマンド・キュー内に前記入ってくるコマンドを入力することと、
前記第１のコマンド・キュー内に前記入ってくるコマンドのエントリについて少なくとも２つの利用可能なスロットは存在しないと判断された場合、第２のコマンド・キューを生成することと、
前記第１のコマンド・キューを前記第２のコマンド・キューに置き換えることと、
をさらに含む、請求項１に記載の方法。
【請求項６】
前記置き換えることは、
前記第１のキュー内にキュー・サイズ変更の表示を入力することと、
前記入ってくるコマンドを前記第２のコマンド・キュー内に入力することと、
前記第１のキューからのコマンドの実行中に前記キュー・サイズ変更の表示が検知されたとき、前記第１のキューを前記第２のキューに置き換えることと、
を含む、請求項５に記載の方法。
【請求項７】
前記置き換えることが完了すると、前記第１のキューを削除することをさらに含む、請求項６に記載の方法。
【請求項８】
プロセッサと、
前記プロセッサに結合された物理メモリと、
複数の実行ユニットと、
前記実行ユニットへのコマンドをキューに入れるために第１のコマンド・キューを生成し、
複数のワークグループを含むコマンドを前記第１のコマンド・キューにポストし、
前記複数のワークグループを識別するデータ構造体、前記コマンドに対応する予約サイズ、ワークグループの数を格納するカウンタ、まだ処理されていない前記ワークグループの数を格納するカウンタ、及び処理された前記ワークグループの数を格納するカウンタを前記コマンドと関連付け、
前記複数の実行ユニットの各々の実行ユニットによって、前記予約サイズに対応する、前記複数のワークグループの別個のN次元範囲を予約し、
前記複数の実行ユニットの各々によって、前記対応するN次元範囲を処理し、
各々の実行ユニットが予約した前記ワークグループの数だけ、まだ処理されていない前記ワークグループの数を格納する前記カウンタをデクリメントし、
各々の実行ユニットが処理した前記ワークグループの数だけ、処理された前記ワークグループの数を格納する前記カウンタをインクリメントし、
まだ処理されていない前記ワークグループの数を格納する前記カウンタが「０」の値より小さいか又は「０」の値と等しくなるまで、前記予約すること、前記処理すること、及び前記デクリメントすることを繰り返し、
処理された前記ワークグループの数を格納する前記カウンタが前記ワークグループの数を格納するカウントと等しいとき、前記コマンドの完了を示すように知らせる、
ための、前記メモリ上に格納され、かつ、前記プロセッサ上で実行される論理と、
を含む装置。
【請求項９】
前記論理は、
前記複数の実行ユニットの１つの実行ユニットによって、まだ処理されていない前記ワークグループの数を格納する前記カウンタが「０」の値より小さいか又は０の値と等しいこと、及び、まだ処理されていない前記ワークグループの数を格納する前記カウンタの絶対値が、前記予約サイズの絶対値より小さいか又はこれと等しいことを検出し、
前記１つの実行ユニットによって、あらゆる残りのワークグループを処理する、
ための論理をさらに含む、請求項８に記載の装置。
【請求項１０】
前記データ構造体はまた、前記コマンドを見ることになっている実行ユニットの数を格納するカウンタと、前記コマンドを確認した実行ユニットの数を格納するカウンタとを含み、前記方法は、処理された前記ワークグループの数を格納する前記カウンタが、前記ワークグループの数を格納するカウントと等しく、かつ、前記コマンドを確認した前記実行ユニットの数を格納する前記カウンタが、前記コマンドを見ることになっている実行ユニットの数を格納するカウンタと等しくもあるとき、前記第１のコマンド・キューから前記コマンドに対応するエントリを解放することさらに含む、請求項８に記載の装置。
【請求項１１】
前記複数の実行ユニットの各々の実行ユニットは、処理コア、プロセッサ、処理スレッド、及び完全なコンピューティング・システムを含む、コマンドを実行するいずれかのコンピュータ装置とすることができる、請求項８に記載の装置。
【請求項１２】
前記論理は、
前記コマンド・キュー内に入ってくるコマンドのエントリについて少なくとも２つの利用可能なスロットが存在するかどうかを判断し、
前記コマンド・キュー内に前記入ってくるコマンドのエントリについて少なくとも２つの利用可能なスロットが存在すると判断された場合、前記コマンド・キュー内に前記入ってくるコマンドを入力し、
前記第１のコマンド・キュー内に前記入ってくるコマンドのエントリについて少なくとも２つの利用可能なスロットは存在しないと判断された場合、第２のコマンド・キューを生成し、
前記第１のコマンド・キュー内に前記第２のコマンド・キューに置き換える、
ための論理をさらに含む、請求項８に記載の装置。
【請求項１３】
前記置き換えるための前記論理は、
前記第１のキュー内にキュー・サイズ変更の表示を入力し、
前記入ってくるコマンドを前記第２のコマンド・キュー内に入力し、
前記第１のキューからのコマンドの実行中に前記キュー・サイズ変更の表示が検知されたとき、前記第１のキューを前記第２のコマンド・キューに置き換える、
ための論理を含む、請求項１２に記載の装置。
【請求項１４】
前記置き換えることが完了すると、前記第１のキューを削除することをさらに含む、請求項１３に記載の装置。
【請求項１５】
物理メモリと、
前記複数の実行ユニットへのコマンドをキューに入力するために第１のコマンド・キューを生成し、
複数のワークグループを含むコマンドを前記第１のコマンド・キューにポストし、
前記複数のワークグループを識別するデータ構造体、前記コマンドに対応する予約サイズ、ワークグループの数を格納するカウンタ、まだ処理されていない前記ワークグループの数を格納するカウンタ、及び処理された前記ワークグループの数を格納するカウンタを前記コマンドと関連付け、
前記複数の実行ユニットの各々の実行ユニットによって、前記予約サイズに対応する、前記複数のワークグループの別個のN次元範囲を予約し、
前記複数の実行ユニットの各々によって、前記対応するN次元範囲を処理し、
各々の実行ユニットが予約した前記ワークグループの数だけ、まだ処理されていない前記ワークグループの数を格納する前記カウンタをデクリメントし、
各々の実行ユニットが処理した前記ワークグループの数だけ、処理された前記ワークグループの数を格納する前記カウンタをインクリメントし、
まだ処理されていない前記ワークグループの数を格納する前記カウンタが「０」の値より小さいか又は「０」の値と等しくなるまで、前記予約すること、前記処理すること、及び前記デクリメントすることを繰り返し、
処理された前記ワークグループの数を格納する前記カウンタが前記ワークグループの数を格納するカウントと等しいとき、前記コマンドの完了を示すように知らせる、
ための、前記プロセッサ上で実行するように前記メモリ上に格納された論理と、
を含むコンピュータ・プログラム。
【請求項１６】
前記論理は、
前記複数の実行ユニットの１つの実行ユニットによって、まだ処理されていない前記ワークグループの数を格納する前記カウンタが「０」の値より小さいか又は「０」の値と等しいこと、及び、まだ処理されていない前記ワークグループの数を格納する前記カウンタの絶対値が、前記予約サイズの絶対値より小さいか又はこれと等しいことを検出し、
前記１つの実行ユニットによって、あらゆる残りのワークグループを処理する、
ための論理をさらに含む、請求項１５に記載のコンピュータ・プログラム。
【請求項１７】
前記データ構造体はまた、前記コマンドを見ることになっている実行ユニットの数を格納するカウンタと、前記コマンドを確認した実行ユニットの数を格納するカウンタとを含み、前記方法は、処理された前記ワークグループの数を格納する前記カウンタが、前記ワークグループの数を格納するカウントと等しく、かつ、前記コマンドを確認した前記実行ユニットの数を格納する前記カウンタが、前記コマンドを見ることになっている実行ユニットの数を格納するカウンタと等しくもあるとき、前記第１のコマンド・キューから前記コマンドに対応するエントリを解放することさらに含む、請求項１５に記載のコンピュータ・プログラム。
【請求項１８】
前記複数の実行ユニットの各々の実行ユニットは、処理コア、プロセッサ、処理スレッド、及び完全なコンピューティング・システムを含む、コマンドを実行するいずれかのコンピュータ装置とすることができる、請求項１５に記載のコンピュータ・プログラム。
【請求項１９】
前記論理は、
前記コマンド・キュー内に入ってくるコマンドのエントリについて少なくとも２つの利用可能なスロットが存在するかどうかを判断し、
前記コマンド・キュー内に前記入ってくるコマンドのエントリについて少なくとも２つの利用可能なスロットが存在すると判断された場合、前記コマンド・キュー内に前記入ってくるコマンドを入力し、
前記第１のコマンド・キュー内に前記入ってくるコマンドのエントリについて少なくとも２つの利用可能なスロットが存在しないと判断された場合、第２のコマンド・キューを生成し、
前記第１のコマンド・キュー内に前記第２のコマンド・キューに置き換える、
ための論理をさらに含む、請求項１５に記載のコンピュータ・プログラム。
【請求項２０】
前記置き換えるための前記論理は、
前記第１のキュー内にキュー・サイズ変更の表示を入力し、
前記入ってくるコマンドを前記第２のコマンド・キュー内に入力し、
前記第１のキューからのコマンドの実行中に前記キュー・サイズ変更の表示が検知されたとき、前記第１のキューを前記第２のコマンド・キューに置き換える、
ための論理を含む、請求項１９に記載のコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
特許請求される主題は、一般に、コンピュータ・リソースの割り当てに関し、より具体的には、マルチコア処理システムにおいてデータ並列負荷及びタスク並列負荷の両方をスケジューリングするための技術に関する。
【背景技術】
【０００２】
コンピューティング・システムのスケジューリングでは、データ並列性又はタスク並列性、或いはこの２つの何らかの組み合わせのために構造化されたジョブを必要とすることがある。データ並列ジョブ又は負荷は、これらに限定されるものではないが、プロセッサ又は処理コアのような多数のユニットによりデータを並行して操作できる計算である。このタイプの処理の例は、ビデオデータを処理するグラフィックス処理ユニット（ＧＰＵ）によって行なわれ、そこで、ビットマップが領域に分離され、各領域を同時に動作させることができる。タスク並列負荷は、多数の実行ユニットがデータのセットに関する異なるタスクを並行して別個に実行する計算である。このタイプのタスクの例は、データのセットを１つのフィルタに通し、その結果を第２のフィルタに通す、データのフィルタリングである。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明の目的は、マルチコア処理システムにおいてデータ並列負荷及びタスク並列負荷の両方をスケジューリングするための技術を提供することにある。
【課題を解決するための手段】
【０００４】
コンピュータ装置へのコマンドをキューに入れるために第１のコマンド・キューを生成することと、複数のワークグループを含むコマンドを第１のコマンド・キューにポストすることと、複数のワークグループを識別するデータ構造体、コマンドに対応する予約サイズ、ワークグループの数を格納するカウンタ、及びまだ処理されていないワークグループの数を格納するカウンタをコマンドと関連付けることと、複数の実行ユニットの各々の実行ユニットによって、予約サイズに対応する、複数のワークグループの別個のＮ次元範囲（N-dimensional range）を予約することと、複数の実行ユニットの各々によって、対応するＮ次元範囲を処理することと、各々の実行ユニットが処理したワークグループの数だけ、まだ処理されていないワークグループの数を格納するカウンタをデクリメントすることと、まだ処理されていないワークグループの数を格納するカウンタが「０」の値より小さいか又は「０」の値に等しくなるまで、予約すること、処理すること、及びデクリメントすることを繰り返すことと、まだ処理されていないワークグループの数を格納するカウンタが「０」の値より小さいか又は「０」の値に等しいとき、コマンドの完了を示すよう知らせることと、を含む技術が提供される。
【０００５】
この概要は、特許請求される主題の包括的な説明であることを意図するものではないが、寧ろ、これと関連した機能の一部の概要を提供することを意図する。以下の図面及び詳細な説明を検討したとき、当業者には、特許請求される主題の他のシステム、方法、機能、特徴及び利点が明らか又は明らかになるであろう。
開示される実施形態の以下の詳細な説明を以下の図面と併せて考慮するとき、特許請求される主題のより良い理解を得ることができる。
【図面の簡単な説明】
【０００６】
【図１】特許請求される主題を実施することができるコンピューティング・システム・アーキテクチャの一例である。
【図２】最初に図１に導入された中央処理装置の例のブロック図である。
【図３】特許請求される主題に従った、コマンド・キューを実施するのに用いることができるコマンド・デスクリプタ・メモリ・オブジェクトの例である。
【図４】ホスト、コマンド・キュー、複数の処理コア及びそれらの間の関係の例を示すブロック図である。
【図５】カウンタ・ブロック、Ｎ次元範囲（ＮＤＲ）コマンド、タスク、処理コア及びそれらの間の関係の例を示すブロック図である。
【図６】ホスト制御プロセスの例を示すフローチャートである。
【図７】特許請求される主題を実施するのに用いることができる実行コマンド・プロセスの例を示すフローチャートである。
【図８】特許請求される主題の態様を実施するコマンド完了プロセスの例を示すフローチャートである。
【発明を実施するための形態】
【０００７】
提供されるのは、実行コマンドが、データ並列処理要件又はタスク並列処理要件を含み得るコマンドを効率的に実行し、その作業負荷を均衡させるのに必要な情報を含む技術である。各々のコマンドは、実行されるコマンド内のワークグループの総数、まだ計算されていないワークグループの数、既に処理されたワークグループの数、一度に処理するワークグループの数（予約サイズ）、コマンド内で処理する実行スレッドの数、及びコマンドを見た実行スレッドの数に対応する情報を含む。
【０００８】
実行ユニットは、１つ又は複数のコマンド・キューからのコマンドを処理する。実行ユニットは、これらに限定されるものではないが、処理コア、スレッド、又はネットワークにわたるコンピューティング・システムを含む、コマンドを実行できるいずれのものであってもよい。各々の実行ユニットは、割り当てられたキュー内の現在の位置を管理する。コマンドがキュー上で利用可能になると、コマンドの実行に関与する各ユニットは、ワークグループの予約サイズだけ、コマンドのワークグループの残りのカウンタをアトミックに（atomically）デクリメントし、処理のためにワークグループ範囲内の対応する数のワークグループを予約する。実行ユニットが要求されたワークグループを実行すると、ユニットは、それ以上を予約しようと試みる。これは、ワークグループの総数が処理されるまで続く。全てのワークグループが処理されると、各々の実行ユニットは、処理済みワークグループのカウンタ（work group processed counter）をインクリメントする。例えば、特定の実行ユニットが、一度に１０個のワークグループを３回処理し、次いで全てのワークグループが処理されたと判断した場合には、実行ユニットは、３０だけ処理済みワークグループのカウンタをインクリメントする。処理済みワークグループのカウンタを、実行予定のワークグループのカウンタ（work group to be executed counter）内に格納された値にインクリメントするユニットが、コマンドの完了を知らせる。
【０００９】
コマンドにアクセスする各々の実行ユニットはまた、見終わったワークグループのカウンタ（workgroup seen counter）にマーク付けする。処理済みワークグループのカウンタが実行予定のワークグループのカウントと等しくなり、かつ、見終わったワークグループのカウンタが実行ユニットの数に等しくなった時点で、コマンドを除去すること又はコマンド・キュー上に上書きすることが可能になる。
【００１０】
当業者により理解されるように、本発明の態様は、システム、方法、又はコンピュータ・プログラムとして具体化ことができる。従って、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、又はソフトウェアの態様とハードウェアの態様とが組み合わされた実施形態の形を取ることができ、これらは全て、本明細書において一般的に「回路」、「モジュール」又は「システム」と呼ばれる。さらに、本発明の態様は、コンピュータ可読プログラム・コードがその上に具体化された１つ又は複数のコンピュータ可読媒体において具体化されるコンピュータ・プログラムの形を取ることもできる。
【００１１】
特許請求される主題に従った１つの実施形態が、データ並列ジョブ及びタスク並列ジョブの両方の効率的なキューイングのためのプログラム・メソッドに向けられる。ここで用いられる「プログラム・メソッド（programmed method）」という用語は、現在実行されている１つ又は複数のプロセス・ステップ、或いは代替的に、将来の時点で実行されることが可能な１つ又は複数のプロセス・ステップを意味するように定義される。この「プログラム・メソッド」という用語は、３つの代替的な形を予期する。第１に、プログラム・メソッドは、現在実行されているプロセス・ステップを含む。第２に、プログラム・メソッドは、コンピュータによって実行されたとき、１つ又は複数のプロセス・ステップを実行するコンピュータ命令を具体化するコンピュータ可読媒体を含む。最後に、プログラム・メソッドは、１つ又は複数のプロセス・ステップを実行するために、ソフトウェア、ハードウェア、ファームウェア、又はこれらの任意の組み合わせによりプログラムされたコンピュータ・システムを含む。「プログラム・メソッド」という用語は、１つより多い代替的な形態を同時に有するものとして解釈されるべきではなく、寧ろ、任意の所与の時点で、複数の代替的な形態のうちの１つだけが存在するという、代替的な形態の最も適正な意味で解釈されるべきであることを理解すべきである。
【００１２】
１つ又は複数のコンピュータ可読媒体の任意の組み合わせを利用することができる。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体とすることができる。コンピュータ可読記憶媒体は、例えば、これらに限定されるものではないが、電子的、磁気的、光学的、電磁的、赤外線、又は半導体のシステム、装置若しくはデバイス、或いは上記の任意の適切な組み合わせとすることができる。コンピュータ可読記憶媒体のより具体的な例（網羅的ではないリスト）は、以下のもの、すなわち、１つ又は複数の配線を有する電気的接続、ポータブル・コンピュータ・ディスケット、ハードディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能なプログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶装置、又は上記の任意の適切な組み合わせを含む。本文書の文脈において、コンピュータ可読記憶媒体は、命令実行システム、装置又はデバイスによって使用するため、又はそれらと接続して使用するために、プログラムを収容又は保存できる任意の有形媒体とすることができる。
【００１３】
コンピュータ可読信号媒体は、コンピュータ可読プログラム・コードが内部に具体化された、例えばベースバンド内の又は搬送波の一部としての伝搬されたデータ信号を含むものとすることができる。このような伝搬信号は、これらに限定されるものではないが、電磁式、光学式、又はこれらの任意の適切な組み合わせを含む、様々な形態のいずれかを取ることができる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではなく、命令実行システム、装置又はデバイスによって使用するため、又はそれらと接続して使用するために、プログラムを伝達し、伝搬し、又は移送することができる任意のコンピュータ可読媒体とすることができる。
【００１４】
コンピュータ可読媒体上で具体化されるプログラム・コードは、これらに限定されるものではないが、無線、有線、光ファイバ・ケーブル、ＲＦ等、又は上記の任意の適切な組み合わせを含む、任意の適切な媒体を用いて伝送することができる。
【００１５】
本発明の態様の動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のようなオブジェクト指向プログラミング言語、及び、「Ｃ」プログラミング言語又は同様のプログラミング言語のような従来の手続き型プログラミング言語を含む、１つ又は複数のプログラミング言語の任意の組み合わせで記述することができる。プログラム・コードは、完全にユーザのコンピュータ上で実行される場合もあり、一部がユーザのコンピュータ上で実行される場合もあり、独立したソフトウェア・パッケージとして実行される場合もあり、一部がユーザのコンピュータ上で実行され、一部がリモート・コンピュータ上で実行される場合もあり、又は完全にリモート・コンピュータ若しくはサーバ上で実行される場合もある。一番最後のシナリオの場合、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続される場合もあり、又は外部のコンピュータへの接続がなされる場合もある（例えば、インターネット・サービス・プロバイダを用いたインターネットを通じて）。
【００１６】
本発明の実施形態に従った方法、装置（システム）及びコンピュータ・プログラムのフローチャート図及び／又はブロック図を参照して、本発明の態様を以下に説明する。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図内のブロックの組み合わせは、コンピュータ・プログラム命令によって実施できることが理解されるであろう。これらのコンピュータ・プログラム命令は、機械を製造するために、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能なデータ処理装置のプロセッサに与えられるものとされ、その結果、コンピュータ又は他のプログラム可能なデータ処理装置のプロセッサによって実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実施するための手段を作り出すようにすることができる。
【００１７】
これらのコンピュータ・プログラム命令はまた、コンピュータ、他のプログラム可能なデータ処理装置、又は他のデバイスを特定の方法で機能させるように指図することができるコンピュータ可読媒体内に格納するものとし、その結果、コンピュータ可読媒体内に格納された命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実施する命令を含む製造物品を製造するようにさせることもできる。
【００１８】
コンピュータ・プログラム命令はまた、コンピュータによって実施されるプロセスを生成するために、コンピュータ、他のプログラム可能な装置、又はデバイス上で実行されるべき一連の動作ステップを生じさせるために、コンピュータ、他のプログラム可能な装置、又はデバイス上にロードされるものとされ、その結果、コンピュータ又は他のプログラム可能な装置上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実施するためのステップを提供するようにさせることができる。
【００１９】
ここで発明者らが認識したように、セル・ブロードバンド・エンジン・アーキテクチャ（ＣＢＥＡ）のようなアーキテクチャは、柔軟性を提供するように設計されているが、スケジューリング・モデルがハードウェア内に組み込まれていないので不都合である。ソフトウェアの機能として提供されるスケジューリングと比較して、ハードウェア・スケジューラと競うために、性能が重要な問題である。
【００２０】
ここで図面を参照すると、図１は、特許請求される主題を実施できるコンピューティング・システム・アーキテクチャ１００の一例である。クライアント・システム１０２は、中央処理装置（ＣＰＵ）１０４を含む。ＣＰＵ１０４は、複数のプロセッサ（図示せず）を含むことができ、これらの各々が、複数の処理コアを含むことができる（図２を参照されたい）。コンピューティング技術分野の当業者であれば、ＣＰＵ１０４に可能な多くの異なる構成を認識するはずである。
【００２１】
クライアント・システム１０２及びプロセッサ１０４は、協働して人間とコンピューティング・システム１００及びクライアント・システム１０２との対話を容易にするモニタ１０６、キーボード１０８及びマウス１１０に結合される。ＣＰＵ１０４に組み込むことができ、すなわち内部装置とすることができ、或いは、これに限定されるものではないが、ユニバーサル・シリアル・バス（ＵＳＢ）ポート（図示せず）のような一般的に利用可能な種々の接続装置によってＣＰＵ１０４に外部から取り付けることができる、データ・ストレージ・コンポーネント１１２も、クライアント・システム１０２内に含められ、かつ、ＣＰＵ１０４に取り付けられている。データ・ストレージ１１２は、クライアント・システム１０２の動作を制御するオペレーティング・システム１１４と、特許請求される主題を実施するコマンド・キューイング・システム（Ｃｏｍｍａｎｄ  Ｑｕｅｕｉｎｇ  Ｓｙｓｔｅｍ、ＣＱＳ）１１６の例とを格納するように示されている。ＣＱＳ１１６と関連した機能は、図２−図８と関連して以下により詳細に説明される。
【００２２】
クライアント・システム１０２及びＣＰＵ１０４は、ローカル・エリア・ネットワーク（ＬＡＮ）１２０に接続され、ローカル・エリア・ネットワーク（ＬＡＮ）１２０はまた、サーバ・コンピュータ１２２に接続されている。この例では、ＣＰＵ１０４及びサーバ１２２は、ＬＡＮ１２０を介して通信可能に結合されるが、これらは、これに限定されるものではないが、インターネット（図示せず）のような任意の数の通信媒体を介して結合することもできる。さらに、特許請求される主題を実施できる多くの可能なコンピューティング・システム構成が存在すること、及び、コンピューティング・システム１００は、その１つの簡単な例にすぎないことに留意すべきである。
【００２３】
図２は、最初に図１において導入されたＣＰＵ１０４の構成の例のブロック図である。ＣＰＵ１０４は、この例では、コア＿０  １３１、コア＿１  １３２等からコア＿Ｎ  １３３までの処理コアである、Ｎ個の実行ユニットを含むプロセッサ１３０を含む。プロセッサ１３０の処理コアの正確な数は重要ではなく、特許請求される主題は、数に関係なく等しくうまく機能する。付加的なプロセッサとすることができるプロセッサ１３０に加えて、便宜上、１つのプロセッサだけが示されることに留意すべきである。特許請求される主題に従ってスケジューリングされる実行ユニットの例として、コア１３１−１３３が明細書全体を通して用いられる。上述のように、実行ユニットは、これらに限定されるものではないが、処理コア、ＣＰＵ、スレッド、及び完全なコンピューティング・システムさえも含む、コマンドを実行する任意のデバイスとすることができる。
【００２４】
プロセッサ１３０は、コア１３１−１３３と、メモリ・コントローラ１４２と、入力／出力（Ｉ／Ｏ）コントローラ１４６と間の通信経路を提供するデータ・バス１４０に通信可能に結合される。メモリ・コントローラ１４２は、データ・ストレージ１１２（図１）のようなクライアント・システム１０２（図１）のメモリ・デバイス１４４の制御を担っている。Ｉ／Ｏコントローラは、モニタ１０６（図１）、キーボード１０８（図１）及びマウス１１０（図１）のようなＩ／Ｏデバイス１４８の制御を担っている。当業者であれば、図２は、典型的なＣＰＵを非常に簡単に示したものであり、便宜上、図示されていない多くの他のコンポーネントを含むことを認識すべきである。
【００２５】
図３は、特許請求される主題に従った、コマンド・キューを実施するのに用いることができるコマンド記述子メモリ・オブジェクト（ＣＤＭＯ）１５０の例である。ＣＤＭＯ１５０は、単にオブジェクト２００の名前、すなわち「ＣｏｍｍａｎｄＤｅｓｒｉｐｔｏｒＯｂｊｅｃｔ」を記載するにすぎないタイトル・セクション１５２と、ＣＤＭＯ１５０と関連したメモリ要素又は属性を含む属性セクション１５４と、ＣＤＭＯ１５０と共に実行することができる機能又はメソッドを含むメソッド・セクション１５６とを含む。説明される属性及びメソッドは、例示のみを目的として用いられることに留意すべきである。付加的な及び／又は異なる属性及びメソッドを用いて、特許請求される主題を実施することもできる。
【００２６】
属性セクション１５４は、「ｃｄｏＩＤ」属性１５８と、「ｗｏｒｋＧｒｏｕｐｓ」属性１６０と、「ａｔｏｍｉｃＷＧＲｅｍａｉｎｉｎｇ」属性１６２と、「ａｔｏｍｉｃＷＧＰｒｏｃｅｓｓｅｄ」属性１６４と、「ｒｅｓｅｒｖａｔｉｏｎＳｉｚｅ」属性１６６と、「ｅｘｅｃｕｔｉｏｎＵｎｉｔｓ」属性１６８と、「ａｔｏｍｉｃＵｎｉｔｓＳｅｅｎ」属性１７０とを含む。
【００２７】
ｃｄｏＩＤ属性１５８は、ＣＤＭＯ１５０の特定のインスタンスへの参照を含むタイプＣＤＯｂｊｅｃｔＩＤの変数である。オブジェクト１５０の各インスタンスは、各インスタンスを一意的に特定することを可能にする、属性１５８についての固有の値を有する。ｗｏｒｋＧｒｏｕｐｓ属性１６０は、ＣＤＭＯ１５０の特定のインスタンシエーションによって参照される対応するコマンド内で計算されるワークグループの総数を格納する、整数型（type INTEGER）の変数である。
【００２８】
ａｔｏｍｉｃＷＧＲｅｍａｉｎｉｎｇ属性１６２は、まだ処理されていないワークグループの数を格納する整数型の変数である。対応するコマンドについての処理を開始する前、属性１６２は、属性１６０の値に等しい値を格納する。対応するコマンドについての処理を開始すると、属性１６２の値は、処理のためにまだコアに割り当てられていないワークグループの数と等しくなる。処理が完了すると、属性１６２は、「０」より小さい又は０に等しい値に設定される。図７と併せて以下に詳細に説明されるように、値が「０」より小さく又は「０」に等しくなるように属性１６２をデクリメントする実行ユニットは、残っているワークグループが、対応するコマンドについて処理されることになる最後のワークグループであることを知っており、従って、不完全なセットを処理することが必要とされるか、又はワークグループを処理する必要はない。
【００２９】
ａｔｏｍｉｃＷＧＰｒｏｃｅｓｓｅｄ属性１６４は、処理を完了した対応するコマンドのワークグループの数を格納する整数型の変数である。対応するコマンドについての処理を開始する前に、属性１６４は、「０」又はＮＵＬＬの値に等しい値を格納する。処理が完了すると、属性１６４は、属性１６０の値と等しくなり、オリジナルの割り当てられたワークグループの各々が処理を完了したことを示す。属性１６４はまた、実行ユニットが属性１６４をインクリメントし、全てのワークグループが完了したことを知らせるようにも使用される。代替的な実施形態においては、属性１６２及び１６４と関連した機能を逆にし、ワークグループが引き続き処理を必要としていたことを知らせるために属性１６４を使用し、全てのワークグループが完了したことを判断するために属性１６２を使用することができることに留意すべきである。
【００３０】
ｒｅｓｅｒｖａｔｉｏｎＳｉｚｅ属性１６６は、一度に各コアに割り当てるべきワークグループの数を格納する整数型の変数である。もちろん、コマンドが完了に近づくにつれて、処理されることになる残りのワークグループの数は、属性１６６の値より小さくなり得る。ｅｘｅｃｕｔｉｏｎＵｎｉｔｓ属性１６８は、特定のコマンドを見ることになっている、すなわちワークグループに特定のコマンドの処理を要求する実行ユニットの数を格納する整数型の変数である。特定のスレッドがコマンドと関連したワークグループを処理していること、又は、スレッドが処理可能な状態になったときに全てのワークグループが既に割り当てられていることから、ａｔｏｍｉｃＵｎｉｔｓＳｅｅｎ属性１７０は、コマンドを確認した実行スレッドの数を格納する整数型の変数である。
【００３１】
ＣＤＭＯ１５０のメソッド・セクション１５６は、２つの例示的な機能又はメソッドを含む。便宜上、２つのメソッドだけが示されている。プログラミング技術分野の当業者であれば、オブジェクト１５０のようなオブジェクトは、一般的に、これらに限定されるものではないが、コンストラクタ（constructor）、デストラクタ（destructor）、及び特定の属性について値を設定し獲得するためのメソッドを含む、多くの付加的なメソッドを含むことを認識すべきである。
【００３２】
例えば、どちらも図７と併せて以下により詳細に説明される「設定サイズを決定する」ブロック３１２及び「ＷＧが残っているか？」ブロック３１６の際に、「ｇｅｔＶａｌｕｅｓ」メソッド１７２が呼び出される。メソッド１７２を呼び出して、ＣＤＭＯ１５０のインスタンシエーション内に格納される属性の値を取り出す。この例では、メソッド１７２は、１つのパラメータ：「ｖａｌｕｅＳｔｒｕｃｔｕｒｅ」、すなわち属性１５４のための記憶空間を含むタイプＣＤＯＶａｌｕｅＳｔｒｕｃｔｕｒｅの変数と共に呼び出される。
【００３３】
例えば、図７と併せて以下により詳細に説明される「完了したＷＧの数をインクリメントする」ブロック３２２の際に、「ｕｐｄａｔｅＣＤＯ」メソッド１７４が呼び出される。メソッド１７４を呼び出して、対応するコンポーネントの属性１５８、１６０、１６２、１６４、１６６、１６８及び１７０を更新する。この例では、メソッド１７４は、１つのパラメータ：上述のような「ｖａｌｕｅＳｔｒｕｃｔｕｒｅ」、すなわち属性１５４のための記憶空間を含むタイプＣＤＯＶａｌｕｅＳｔｒｕｃｔｕｒｅの変数と共に呼び出される。
【００３４】
ＣＤＭＯ１５０は、特許請求される主題を実施するために用いることができるメモリ・オブジェクトの一例にすぎないことを理解すべきである。より少ない、より多い、及び／又は異なる属性及びメソッドを有する他のメモリ・オブジェクトを用いることもできる。さらに、特許請求される主題の機能及びデータ・ストレージを実施するために、オブジェクト１５０を用いる以外の多くの方法が存在する。例えば、特許請求される主題は、リレーショナル・データベースと共にコンピュータ・プログラムによって実施することができる。
【００３５】
図４は、ホスト２０２、コマンド・キュー２０４、コア＿０  ２１０、コア＿１  ２１１、コア＿２  ２１２、コア＿３  ２１３の例、及びこれらの間の関係の種々の例を示すブロック図である。コマンド・キュー２０４が循環式であることに留意すべきである。ホスト２０２は、コマンドを、これらに限定されるものではないが、クライアント・システム１０２（図１）、サーバ１２２（図１）、処理コア、実行スレッド等のような、キューにポストする任意のコマンド実行デバイスとすることができる。コア２１０−２１３は、コア１３０−１３３（図２）のような、ホスト２０２と関連付けられた処理コアとすることができる。ホスト２０２がクライアント・システム１０２であると想定される場合、コマンド・キュー２０４は、データ・ストレージ１０２（図１）又はＣＰＵ１０４（図１及び図２）と関連した揮発性メモリ（図示せず）上に格納することができる。
【００３６】
コマンド・キュー２０４は、幾つかのキュー要素（ＱＥ）、具体的には、ＱＥ＿１  ２２１、ＱＥ＿２  ２２２、ＱＥ＿３  ２２３、ＱＥ＿４  ２２４、ＱＥ＿５  ２２５、ＱＥ＿６  ２２６、ＱＥ＿７  ２２７及びＱＥ＿８  ２２８を含むように示される。ＱＥ２２１−２２８と関連した陰影付けは、種々の可能な状態を表し、ＱＥ２２１及び２２２は完了したコマンドを表し、ＱＥ２２３−２２５は、現在のところ必ずしも処理されていないが、全ての実行ユニットが見ていないコマンドを表す。ＱＥ２２６−２２８は、コマンド・キュー２０４における空の又は利用可能なキュー・スロットを表す。コマンド・キュー２０４内の空間２２９は、現在のところ処理されていないが、コア＿２  ２１２が既にそれらを越えて進んでいるので、完了していると想定できる付加的なＱＥを表すにすぎない。この場合、コア２１０、２１１及び２１３は、空間２２９によって表されるＱＥをまだ見ていない。空間２２９と関連したＱＥに関して処理が完了しても、コア２１０、２１１及び２１３によって「見られる（seen）」まで、ＱＥに新しいコマンドを上書きすることはできない。このことは、コア２１０、２１１及び２１３が、上書きされたＱＥにアクセスし、従って、予想されるものとは異なる情報を格納するのを防止する。
【００３７】
この例では、ホスト２０２は、次の利用可能なキュー要素のスロットＱＥ＿６  ２２６を指し示す。コア＿０  ２１０及びコア＿１  ２１１は、ＱＥ＿３  ２２３と関連付けられたコマンドを指し示すか又はこれを実行するプロセスにおいて示され、コア＿２  ２１２は、ＱＥ＿５  ２２５と関連付けられたコマンドを実行するように示され、コア＿３  ２１３は、ＱＥ＿４  ２２４と関連付けられたコマンドを実行するように示される。種々のポインタの重要性及びコマンド・キュー２０４内に格納されたコマンドの実行は、図５−図８と併せて以下により詳細に説明される。
【００３８】
ＮＤＲは、多次元のワークグループ／アイテムで構成されるコマンドであることに留意すべきである。ＮＤＲは、特定のコマンドと関連付けられており、全てがＱＥ２２１−２２８のような単一のＱＥ内に含まれてもよいが、それは必須ではない。ＱＥは、これらに限定されるものではないが、ＮＤＲ、タスク、又はキュー・サイズ変更の表示とすることができるコマンドを含む。開示される技術はまた、複数のＱＥ内に複数のワークグループを有する単一のコマンドを配置し、複数の処理グループ間でのコマンドのインターリーブ（図５を参照されたい）を可能にする。図４の例示は、１つの処理グループだけを含む単純化された例と考えることができる。
【００３９】
図５は、図４のコマンド・キュー２０４とは異なる視点からのコマンド・キュー２３０の例を示すブロック図である。具体的には、コマンド・キュー２３０は、Ｎ次元範囲（ＮＤＲ）コマンド及びタスク・コマンドに分割された状態で示される。言い換えれば、多数のワークグループを含むように指定されたコマンドが、１又は複数のＮ次元範囲に分割される。１つの特定のコマンドが、２つのＮＤＲ、すなわちＮＤＲ＿Ａ１  ２３１及びＮＤＲ＿Ａ２  ２３２に分割される。ＮＤＲ＿Ａ１  ２３１及びＮＤＲ＿Ａ２  ２３２の両方とも、単一のコマンドを表し、よって、カウンタ・ブロックＣＢ＿１  ２４１を共有する。１つのコマンドは、コマンド・キュー２３０内の２つのエントリを有し、処理グループ間でのキュー２３０におけるコマンドのインターリーブを可能にする。図５において、コア１３１−１３３によって表される処理グループは、奇数のエントリを処理し、処理グループ２５０は、偶数のエントリを処理している。このような責任の分担は、共有されるタスク・カウンタ・ブロックにわたる競合を軽減するのに役立つ。単一のコマンドを２つのエントリ、この例では、ＮＤＲ＿Ａ１  ２３１及びＮＤＲ＿Ａ２  ２３２に分割することにより、両方の処理グループがコマンドを実行することが可能になる。別のコマンドも、２つのＮＤＲ、すなわちＮＤＲ＿Ｂ１  ２３６及びＮＤＲ＿Ｂ２  ２３７に分割される。さらに、タスク・コマンドは、１つのワークグループを有するＮＤＲと考えることができる。
【００４０】
対応するコマンドと関連付けられた単一のタスク、すなわちタスク＿Ａ  ２３３、タスク＿Ｂ  ２３４、タスク＿Ｃ  ２３５も示される。各々のタスク２３３−２３５は、対応するＱＥと関連付けられる。カウンタ・ブロック（ＣＢ）、具体的には、ＣＢ＿１  ２４１、ＣＢ＿２  ２４２、ＣＢ＿３  ２４３、ＣＢ＿４  ２４４及びＣＢ＿５  ２４５を用いて、関連したＮＤＲに対応する各々のブロックによりコマンドの実行を追跡する。この例では、ＣＢ＿１  ２４１は、ＮＤＲ２３１及び２３２と関連したコマンドの実行を追跡しており、ＣＢ＿５  ２４５は、ＮＤＲ２３６及び２３７と関連したコマンドの実行を追跡している。
【００４１】
処理コア１３１−１３３（図２）、並びに、処理グループ２５０と関連したコア＿Ｎ＋１  １３４からコア＿２Ｎ  １３５までの付加的なコアも、図５内に含まれる。処理グループ２５０は、ＣＰＵ１０４（図１及び図２）内の、又はＣＰＵ１０４に通信可能に結合されたサーバ１２２（図２）のような別のコンピュータ装置内の付加的なプロセッサとすることができる。２つの処理グループが示されるが、処理グループの数は制限されていない。処理グループは、処理コア、スレッド、又はさらにネットワークにわたるシステムからなることができる。プロセッサのグループ化は、性能及び／又は局所性又は要素のような要因によって決まり得る。この例では、コア＿０  １３１は、ＮＤＲ＿Ａ１  ２３１を実行しており、コア＿Ｎ  １３３は、タスク＿Ａ  ２３３を実行しており、コア１３４及び１３５は、ＮＤＲ＿Ａ２  ２３２を処理している。カウンタ・ブロック、ＮＤＲ、タスク、及び処理コアと関連した処理は、図６及び図７と併せて以下により詳細に説明される。
【００４２】
図６は、ホスト制御プロセス２８０の例を示すフローチャートである。この例では、プロセス２８０と関連した論理は、データ・ストレージ（図１）上に格納され、ＣＱＳ１１６（図１）と共にＣＰＵ１０４（図１及び図２）上で実行される。プロセス２８０は、「ホスト制御を開始する」ブロック２８２で始まり、直ちに「コマンドを受け取る」ブロック２８４に進む。
【００４３】
ブロック２８４の際、プロセス２８０は、以下の例においてはコマンド・キュー２３０であるコマンド・キュー上にポストするために、コマンドを受け取る。コマンドは、これらに限定されるものではないが、ＯＳ１１４（図１）、並びに、この例ではクライアント・システム１０２上で実行されるいずれかのアプリケーション（図示せず）及びユーティリティ（図示せず）等の種々のソースから伝送することができる。さらに、コマンドは、サーバ１２２のようなリモート・ソースから伝送することができる。「２つのスロットが利用可能か？」ブロック２８６の際、プロセス２８０は、コマンド・キュー２３０が少なくとも２つの利用可能なスロットを有するかどうかを判断する。この例においてはホスト２０２（図４）であるコマンド・キュー・ホストがストールするのを回避するために、２より少ないエントリが新しいコマンドのエントリに利用可能であるときはいつでも、コマンド・キュー２３０をサイズ変更する。将来を見越すことによって、ホスト２０２は、ブロックを次のエンキュー上に押し込むことなく、コマンド・キュー２３０が新しいコマンドを収容するのに十分な空間を有するかどうかを判断することができる。
【００４４】
新しいコマンドをキューに入れる（エンキューする）よう要求を受け取ったとき、２つより少ないブロックが利用可能である場合には、プロセス２８０は、新しいより大きいキュー（図示せず）を作成する「新しいキューを作成する」ブロック２８８に進む。コマンド・キュー２３０上で少なくとも２つのスポットが利用可能である場合には、１つのブロックは、ブロック２８４の際に受け取ったコマンドをキューに入れるために使用し、１つの空間は、次のコマンドを受け取ったときにブロックを防止するために残す。
【００４５】
「サイズ変更コマンドを付加する」ブロック２９０の際、サイズ変更コマンドが、実行ユニットが新しいキューにアクセスするのに必要な情報と共に、最後の残っているスポットとして現在のキュー内に挿入される。このように、コマンド・キュー・プロセス（図７のプロセス３００を参照されたい）は、新しいキューを用いるのに必要なステップを通知し、必要な措置を取ることができる（図７の３１０を参照されたい）。以下の説明における連続性のために、新しいキューは、依然としてコマンド・キュー２３０と呼ばれる。サイズ変更コマンドがブロック２９０の際に挿入されたことが分かると、又はブロック２８６の際に、少なくとも２つのキュー・スポットが利用可能であるとプロセス２８０が判断した場合には、プロセス２８０は、「コマンドをキューに付加する」ブロック２９２に進む。ブロック２９２の際、ブロック２８４の際に受け取ったコマンドは、第１のエントリとして新しいキュー内に付加されるか（ブロック２９０から）、又は現在のコマンド・キュー２３０内に挿入される（ブロック２８６から）。「ポインタをインクリメントする」ブロック２９４の際、プロセス２８０は、ホスト２０２から次の利用可能なＱＥにポインタをインクリメントする。
【００４６】
最後に、プロセス２８０は、非同期割り込み２９８によって停止され、制御を「ホスト制御を終了する」ブロック２９９に渡し、そこで、プロセス２８０が完了する。割り込み２９８は、典型的には、プロセス２８０がその一部であるＯＳ１１４又はＣＱＳ１１６（図１）それ自体が停止されるときに生じる。公称動作中、プロセス２８０は、ブロック２８４、２８６、２８８、２９０、２９２及び２９４を経由して連続的にループし、コマンドを受け取ったときにコマンドを処理する。
【００４７】
図７は、特許請求される主題を実施するために用いることができる実行コマンド・プロセス３００の例を示すフローチャートである。この例では、プロセス３００と関連した論理が、データ・ストレージ１１２（図１）上に格納され、ＣＱＳ１１６（図１）と併せてＣＰＵ１０４（図１及び図２）上で実行される。
【００４８】
プロセス３００は、「実行コマンドを開始する」ブロック３０２で始まり、直ちに「作業を待つ」ブロック３０４に進む。ブロック３０４の際、プロセス３００は、コマンド・キュー２０４（図４）又は２３０（図５）のようなコマンド・キュー上に１つ又は複数のコマンドが存在するという、ＣＱＳ１１６からの信号を待っているサスペンド状態にある。この説明を目的として、コマンド・キュー２３０が用いられる。コア１３１−１３５（図５）のような実行ユニットに通知するための機構、従って、コマンドが利用可能であるプロセス３００は、システム構成及び作業負荷に応じて変わり得る。次の利用可能なコマンドの状態をうまくポーリングすることにより、システムに高い効率性がもたらされ、そのため、リソースのポーリングに大きな消費はなされない。例えば、ＳＰＵユニットは、処理されることになる次のコマンドを含むコマンド・キュー２３０のエントリのアトミック・ポーリング行なうことができる。ポーリングが貴重な計算サイクルを消費するＣＰＵにおいては、条件変数を用いることができる。コマンドがキュー２３０上にあるという信号を受け取ると、プロセス３００は、次の利用可能なコマンドを表すコマンド・キュー２３０内の位置から第１のコマンドを取り出す、「コマンドをフェッチする」ブロック３０６に進む。コマンドに関連した情報（図３のＣＤＭＯ１５０を参照されたい）は、ＣＢ２４１−２４５（図５）のようなカウンタ・ブロック内に格納される。
【００４９】
「コマンドをサイズ変更するか？」ブロック３０８の際、プロセス３００は、ブロック３０６の際にフェッチされたコマンドが、コマンド・キュー２３０がサイズ変更された（図６のプロセス２８０を参照されたい）という表示を表すかどうかを判断する。表す場合には、プロセス３００は、古いキュー（図６を参照されたい）ではなく新しいキュー又はサイズ変更されたキューを用いるように処理を実行する、「サイズ変更を処理する」ブロック３１０に進む。次に、プロセス３００は、ブロック３０６に戻り、新しいキューから次のコマンドをフェッチし、上述のように処理が続く。
【００５０】
ブロック３０８の際、実行されることになる次のコマンドが、サイズ変更されたコマンド・キュー２３０の表示ではないとプロセス３００が判断した場合、制御は「設定サイズを決定する」ブロック３１２に進む。ブロック３１２の間、プロセス３００は、対応するコマンドについての構成されたワークグループのサイズ（図３のＣＤＭＯ１５０の１６６を参照されたい）を決定する。もちろん、コマンドは、１つだけのワークグループを有し、かつ、１つの予約サイズをも有すると考えることができる、タスクとすることができる。「ワークグループ（ＷＧ）の設定サイズをデクリメントする」ブロック３１４の際、ブロック３０６の際にフェッチされたコマンドの実行と関連した各々の実行ユニットは、依然として処理する必要があるコマンド内のワークグループの数（図３のＣＤＯ１５０の１６２を参照されたい）を格納する変数をデクリメントする。この例のために、実行ユニット１３１−１３５（図２及び図５）が用いられる。各々の実行ユニット１３１−１３５はブロック３１４をアトミックに実行し、その結果、別のユニットが変数にアクセスし、これをデクリメントする前に、１つのユニットにより、変数が完全に更新される。デクリメント値は、特定のユニットによって実行されることになる特定のコマンド内のＮＤＲの範囲に基づいて、対応する実行ユニット１３１−１３５を提供する。このように、各々の実行ユニットは、ホストの関与を最小にした状態で、これがＮＤＲから実行するワークグループの数を制御することができる。言い換えれば、コマンドは、実行ユニット間で分割されるので、各々の実行ユニットは、必要に応じて作業を要求し、かつ、次のコマンドにいつ進むかを完全に知ることができる。
【００５１】
「ＷＧが残っているか？」ブロック３１６の際、プロセス３００は、（現在の実行ユニットが実行された時点で）いずれかのワークグループ・ユニットがまだ処理されていないかどうか、すなわち、ブロック３１４の動作の結果として、変数１６２の値がゼロ又はそれより小さいかどうかを判断する。属性がゼロ又はそれより小さく、また、ｒｅｓｅｒｖａｔｉｏｎＳｉｚｅ１６６（図３）の絶対値よりも小さい絶対値を有する場合、実行ユニットは、処理するコマンドの最後のワークグループ、及び潜在的には不完全なセットを有する。この場合、プロセス３００は、ブロック３１４の際に取り出された基本範囲によって識別された残りのワークグループを処理する、「部分的なＷＧを処理する」ブロック３２０に進む。属性１６２がゼロ又はそれより小さく、また、ｒｅｓｅｒｖａｔｉｏｎＳｉｚｅ１６６（図３）の絶対値よりも大きいか又はこれと等しい絶対値を有する場合、実行ユニットは、全てのワークグループが処理されたことを知り、ブロック３２０に進むが、ワークグループを処理しない。
【００５２】
ブロック３１６の際、属性１６２がゼロより大きいと判断された場合には、プロセス３００は、「ＷＧアイテムを処理する」ブロック３１８に進む。ブロック３１８の際、対応する実行ユニット１３１−１３５は、ブロック３１４の際に判断されたＮＤＲの基本範囲から開始する予約サイズのワークグループの実行を担っている。次に、プロセス３００は、ブロック３１４に戻り、上述のように処理が続く。
【００５３】
「完了したＷＧの数をインクリメントする」ブロック３２２の際、各々の実行ユニットは、ブロック３１４、３１６、３１８及び３２０を通じた繰り返しの間、特定の実行ユニット１３１−１３５がブロック３０６の際に受け取ったコマンドに対して処理したワークグループの数だけ、完了したワークグループの総数（図３の１６４を参照されたい）を示す変数をアトミックにインクリメントする。
【００５４】
「完了したＷＧ＝総数か？」ブロック３２４の際、各々の実行ユニットは、完了したワークグループの数（図３の１６４を参照されたい）が、コマンド内のワークグループの数（図３の１６０を参照されたい）と等しいどうかを判断する。等しい場合には、対応する実行ユニット１３１−１３５は、「完了を知らせる」ブロック３２６に進む。ブロック３２６の際、実行ユニット１３１−１３５は、コマンドと関連した全てのワークグループが処理されたことをＣＱＳ１１６に知らせる。このように、コマンドを終了する実行ユニットだけが、ＣＱＳ１１６に信号を送り、その結果、二重に信号を送るのを防止する。
【００５５】
上述の処理に加えて、コマンド・キュー２３０上で動作する各実行ユニット１３１−１３５は、「見られたコマンドにマーク付けする」ブロック３２８を実行する。ブロック３２８の際、各々の実行ユニット１３１−１３５は、特定のコマンドを見た実行ユニットの数（図３の１７０を参照されたい）を追跡する変数をインクリメントする。例えば、特定のコマンドに割り当てられたスレッドの数（図３の１６８を参照されたい）がコマンドを完了するのに実際に必要なユニットの数を上回る場合には、実行ユニットが実際に特定のコマンドに取り組み、コマンドを見る必要はないことに留意されたい。ブロック３２８の際にコマンドを見たものとしてマーク付けすると、各々の実行ユニット１３１−１３５は、ブロック３０４に戻り、上述のように処理が続く。
【００５６】
最後に、プロセス３００は、非同期割り込み３３８によって停止され、制御を「実行コマンドを終了する」ブロック３３９に渡し、そこで、プロセス３００が完了する。割り込み３３８は、典型的には、プロセス３００がその一部であるＯＳ１１４（図１）又はＣＱＳ１１６それ自体が停止されるときに生じる。公称動作中、プロセス３００は、ブロック３０２、３０４、３０６、３０８、３１０、３１２、３１４、３１６、３１８、３２０、３２２、３２４、３２６及び３２８を経由して連続的にループし、コマンドを受け取ったときにコマンドを処理する。
【００５７】
図８は、特許請求される主題の態様を実施するコマンド完了プロセス３５０の例を示すフローチャートである。この例では、プロセス３５０と関連した論理は、データ・ストレージ１１２（図１）上に格納され、ＣＱＳ１１６（図１）と併せてＣＰＵ１０４（図１及び図２）上で実行される。
【００５８】
プロセス３５０は、「コマンド完了を開始する」ブロック３５２で始まり、直ちに「作業を待つ」ブロック３５４に進む。ブロック３５４の際、プロセス３５０は、コマンドが実行されたという信号（図７の３２６を参照されたい）を待っているサスペンド状態にある。
【００５９】
信号を受け取ると、プロセス３５０は、「プロセス実行が完了したか？」ブロック３５６に進む。ブロック３５６の際、プロセス３５０は、ブロック３５４の際に受け取った信号がコマンドの完了を表すコマンドであるかどうかを判断する。コマンドの完了を表すコマンドではない場合、プロセス３５０は、「プロセスのサイズ変更が完了したか？」ブロック３５８に進み、そこで、プロセス３５０は、ブロック３５４の際に受け取った信号が、コマンド・キュー２３０のサイズ変更を完了したという表示を表すかどうかを判断する。具体的には、各々の実行ユニットがサイズ変更コマンドを見て、サイズ変更されたキューに切り替えられたかどうかについて判断を行なう。図６と併せて上述したように、コマンド・キュー２３０は、コマンドと、場合によってはコマンド・キュー２３０のサイズ変更が実行されたという表示との両方を含む。サイズ変更コマンドが全ての適切な実行ユニットにより見られた場合には、プロセス３５０は、サイズ変更されたキューに置き換えられたキューを削除する「古いキューを削除する」ブロック３６０に進む。
【００６０】
プロセス３５０は、ブロック３５６の際に、受け取った信号が完了したコマンドを表すと判断した場合、制御は、対応する実行ユニットによってコマンドが完了したことをＣＱＳ１１６に通知する「完了をポストする」ブロック３６２に進む。「完了したキュー・エントリ（ＱＥ）にマーク付けする」ブロック３６４の際、プロセス３５０は、コマンドが対応する実行ユニットによって完了されたという表示で対応するキュー・エントリにマーク付けする。
【００６１】
ブロック３６２の際にコマンド・キュー２３０内の適切なエントリが完了されたものとマーク付けされると、又は処理がブロック３５８及び３６０に対して完了した時点で、プロセス３５０は、ブロック３５４に戻り、別の信号を待ち、上述のように処理が続く。最後に、プロセス３５０は、非同期割り込み３６８によって停止され、制御を「コマンド完了を終了する」ブロック３６９に渡し、そこでプロセス３５０が完了する。割り込み３６８は、典型的には、プロセス３５０がその一部であるＯＳ１１４（図１）又はＣＱＳ１１６それ自体が停止されるときに生じる。公称動作中、プロセス３５０は、ブロック３５２、３５４、３５６、３５８、３６０、３６２及び３６４を経由して連続的にループし、コマンドを受け取ったときにコマンドを処理する。
【００６２】
ここで用いられる用語は、特定の実施形態を説明することのみを目的とし、本発明を限定することを意図していない。ここで用いられる単数形の「１つの（ａ）」、「１つの（ａｎ）」及び「その（ｔｈｅ）」という用語は、複数形も同様に含むことが意図される。「含む（ｃｏｍｐｒｉｓｅ）」及び／又は「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」という用語は、本明細書で用いられるときには、述べられた特徴、整数、ステップ、操作、要素、及び／又はコンポーネントの存在を特定するが、１つ又は複数の他の特徴、整数、ステップ、操作、要素、コンポーネント、及び／又はそれらのグループの存在又は付加を排除するものではないことが、さらに理解されるであろう。
【００６３】
以下の特許請求の範囲における全ての機能付き手段（ミーンズ・プラス・ファンクション）又は機能付き工程（ステップ・プラス・ファンクション）の対応する構造、材料、動作及び均等物は、具体的に請求される他の請求要素と組み合わせて本機能を実施するためのいずれかの構造、材料、又は動作を含むことを意図している。本発明の記載は、例示及び説明目的で提示されたが、網羅的であることを意図するものでも、本発明を開示された形態に限定することを意図するものでもない。当業者であれば、本発明の範囲及び精神から逸脱することなく、多くの修正及び変形が明らかであろう。実施形態は、本発明の原理及び実際の適用を最も良く説明し、その他の当業者が企図される特定の使用に適した種々の修正を伴う種々の実施形態について本発明を理解できるように、選択され、説明された。
【００６４】
図面内のフローチャート及びブロック図は、本発明の種々の実施形態によるシステム、方法及びコンピュータ・プログラムの可能な実装のアーキテクチャ、機能、及び動作を例証する。この点で、フローチャート又はブロック図内の各ブロックは、指定された論理機能を実装するための１つ又は複数の実行可能な命令を含むコードのモジュール、セグメント又は部分を表すことができる。幾つかの代替的な実装においては、ブロック内に記載さされた機能は、図面内に記載された順序とは異なる順序で行われる場合があることにも留意すべきである。例えば、逐次的に図示された２つのブロックは、実際には、実質的に同時に実行される場合もあり、又は、これらのブロックは、関与する機能に応じて、ときとして逆順で実行される場合もある。ブロック図及び／又はフローチャート図の各ブロック、並びにブロック図及び／又はフローチャート図内のブロックの組み合わせは、指定された機能又は動作を実行する専用ハードウェア・ベースのシステム、又は専用ハードウェアとコンピュータ命令との組み合わせによって実装できることも留意される。
【符号の説明】
【００６５】
１００：コンピューティング・システム・アーキテクチャ
１０２：クライアント・システム
１０４：中央処理装置（ＣＰＵ）
１０６：モニタ
１０８：キーボード
１１０：マウス
１１２：データ・ストレージ
１１４：オペレーティング・システム
１１６：コマンド・キューイング・システム（ＣＱＳ）
１２０：ローカル・エリア・ネットワーク（ＬＡＮ）
１２２：サーバ・コンピュータ
１３０：プロセッサ
１３１〜１３５：コア
１４０：データ・バス
１４２：メモリ・コントローラ
１４６：入力／出力（Ｉ／Ｏ）コントローラ
１４８：Ｉ／Ｏ装置
１５０：コマンド記述子メモリ・オブジェクト（ＣＤＭＯ）
２０２：ホスト
２０４、２３０：コマンド・キュー
３００、３５０：プロセス
【図１】
2011054161.tif 000003
【図２】
2011054161.tif 000004
【図３】
2011054161.tif 000005
【図４】
2011054161.tif 000006
【図５】
2011054161.tif 000007
【図６】
2011054161.tif 000008
【図７】
2011054161.tif 000009
【図８】
2011054161.tif 000010