JP5789072B2 - マルチコアアーキテクチャにおけるリソース管理 - Google Patents

Description

本発明は、マルチコアアーキテクチャにおけるリソース管理の方法および装置に関する。

今日、複雑な異種混合マルチコアアーキテクチャを組み込んだ半導体デバイスが、ユビキタスなデスクトップコンピュータから、携帯電話機、携帯情報端末、高速電気通信／ネットワーク交換装置などといった最新型の電子機器に至るまで、多種多様なシステムおよび機器で利用されている。

任意のコンピュータプロセッサの使用目的がどのようなものであれ、プロセッサ製造者は、現在のプロセッサの性能を高めると同時に、それらの単位「コスト」を維持し、または低減しようと努力し続ける。

プロセッサの「コスト」は、様々なパラメータを使って評価され得る。多くの場合、コストは、純粋に、金銭的コストであるが、多くの適用分野、特に組み込み式プロセッサ市場において、コスト計算は、電力消費、冷却要件、効率、商品化に要する時間などの付随的考慮事項も含む。

任意のプロセッサが有用な機能を果たす絶対的能力は、達成可能なＭＩＰＳ（１００万命令／秒）比として特徴付けることができ、よって、任意のプロセッサの「価格／性能」比は、例えば、ＭＩＰＳ／ｍｍ^２、ＭＩＰＳ／＄、あるいはＭＩＰＳ／ｍＷなどによって特徴付けることができる。

しかしながら、実際には、すべての命令が同量の有用な作業を達成するとは限らず、したがって、「純粋な」ＭＩＰＳ評価は、容易に比較することができない。よって、ディジタル信号プロセッサ（ＤＳＰ）は、携帯電話機の無線インターフェースの近くにおける数学的な集中処理の解決には適しているが、その電話機の画面上で実行されるＷｅｂブラウザの実行においては極めて効率が悪い。事実上、これは、プロセッサが、「アプリケーション利用可能」価格／性能の観点からの方がより有効に分類され得ることを意味している。

しかも、プロセッサを制御し、カスタマイズして個々のアプリケーションを実施するのに使用されなければならないプログラミング、すなわちソフトウェアツールの非効率性によって、有効性能のさらなる低下が引き起こされ得る。よって、個々のアプリケーションのためにプロセッサから抽出され得る最終的な性能レベルは、使用可能な、または「達成可能なアプリケーション利用可能」価格／性能のレベルとみなされ得る。

半導体企業による、プロセッサのアプリケーション利用可能価格／性能を改善しようとする取り組みにおいて、新しいクラスのプロセッサ、すなわち、マルチコアデバイスが開発されている。マルチコアデバイスは、プロセッサによって実行され得るアプリケーションの特定の態様での最大レベルの有効価格／性能比を提供するために、それぞれが高度に特化されていてもよい、様々な要素（コア）から構築される高度に集積されたプロセッサである。そのようなデバイスは、「異種混合」、すなわち複数の、異種のコアを組み込んだものとすることも、「同種」、すなわち複数の類似のコアを組み込んだものとすることもできる。

また、ほとんどのマルチコアデバイスは、システムオンチップ（ＳｏＣ）デバイスとして分類することができる。というのは、その集積が、複数のプロセッシングコアのみならず、任意の個別製品のハードウェア要件の（全部ではないにしろ）大部分を処理するのに必要とされるメモリ、入出力およびその他のシステム（コア）も含むからである。すべてのＳｏＣデバイスが複数のプロセッシングコアを有するとは限らないが、複数のコアとＳｏＣという用語は、しばしば、互いに入れ替えて使用される。マルチコアＳｏＣの好例を多くの携帯電話機に見ることができ、それらには、無線インターフェースを実行するための１つ以上のＤＳＰを含む単一のプロセッサと、電話機でユーザアプリケーションを実行するための汎用プロセッサが搭載されている。

マルチコアデバイスの出現は、ムーアの法則によって可能となったものであり、この法則によれば、シリコンの任意の所与の面積に組み込まれ得るトランジスタの数は、製造工程の改善により１８ヶ月ごとに倍増することになる。したがって、ムーアの法則は、シリコンダイ上の任意の所与の面積により多くの個別トランジスタを組み込むことを可能にし、単一のシリコン片上により一層複雑なデバイスを製作することを、技術的にも経済的にも実行可能にする。同様に、各トランジスタのサイズを縮小することにより、トランジスタは、より一層高速で切り換わることができる。

従来、ムーアの法則は、基礎となるアーキテクチャに大きな変更を加えずに、より高速な、または使用されるシリコンの点でより費用対効果の高い、より小型の新世代プロセッサを製作するのに使用された（すなわち、改善は、デバイスの論理的マクロアーキテクチャの改善ではなく、製造工程およびデバイスの物理的マイクロアーキテクチャの改善であった）。

事実上、マルチコア／ＳｏＣプロセッサに向かう傾向は、より高レベルの集積へのマクロアーキテクチャ的移行とみなすことができ、これは、まず、シリコンダイ自体への入出力（通信）機能の導入から始まった。今や、入出力、メモリ、および複数の処理装置、ＤＳＰおよびコプロセッサの機能を同じシリコンダイ上に集積することができる。これらのプロセッサは、個々のアプリケーションクラスに最低コストで、最高性能のプロセッサを提供することによって、最終製品の製造コストを低減するはずである。また、システム構成部品の大部分を単一プロセッサ上に集積することにより、部品点数も削減され、したがって、信頼性を高め、電力消費を低減することができる。

重要な問題は、可能な限り高い「アプリケーション利用可能」価格／性能を達成するために、そのようなマルチコアデバイスにおける基礎的なハードウェアの使用をどのようにして最適化し得るかである。

プロセッサおよびシステムの設計者らが、アプリケーションソフトウェア内での並列処理（アプリケーションレベルの並列処理）および命令ストリーム内での並列処理（命令レベルの並列処理）を利用することのできる多くのやり方がある。それら様々な発現では、並列処理がどこで管理されるか、および並列処理が、システムが実行しているとき／実行時に管理される（動的システム）か、それともアプリケーションソフトウェアがコンパイルされているとき／コンパイル時に管理される（静的システム）かが異なる。実際には、動的システムと静的システムおよびハードウェア集約的解決とソフトウェア集約的解決の間の区分は明確なものではなく、ある分野からの技法が、しばしば、その他の分野によって流用される。

個別プロセッシングコアレベルにおいて、単一ストリームからの並列の多数命令で動作する複数発行プロセッサまたはマシンの概念は、当分野では十分に確立している。これらは、スーパースカラプロセッサと超長命令語（ＶＬＩＷ）プロセッサという２つの基本的種類で供給される。スーパースカラプロセッサは、実行時（動的にスケジュールされる）またはコンパイル時（静的にスケジュールされる）のどちらかに識別される、様々な数の１クロックサイクル当たりの命令を発行する。ＶＬＩＷプロセッサは、コンパイラによって定義されるように、非常に長い命令語を形成する固定数の命令を発行する。通常、プログラマは、このプロセスに全く気付かない。というのは、システムのプログラミングモデルが、標準的なシングルプロセッサ抽象化であるからである。

スーパースレッディングとハイパースレッディングは、両方とも、複数の仮想プロセッサの間で複数の実行スレッドを多重化することによって複数のプロセッサをエミュレートする技術である。通常、これらの仮想プロセッサは、統計的に、単一のスレッドによって常に使用されるとは限らないはずのいくつかのリソースを共用する。スーパスレッディングアーキテクチャおよびハイパースレッディングアーキテクチャは、複数の独立のプロセッサの役割を演じ、したがって、効率よく働くために、あるレベルのアプリケーション並列処理が存在することを必要とする。通常、プロセッサコアのハードウェア制約条件により、サポートされ得るスレッド数が、実質上１００未満に制限される。

さらに、多くのアプリケーションにおける固有の並列処理の利用では、いくつかのシステムアーキテクチャ上の選択肢が存在する。各プロセッサが、なんらかの共用リソース（例えば、メモリおよび／または相互接続など）を介してそのピアと協働しながら、独自の命令を実行し、独自のデータセットに基づいて動作する多重命令多重データ（ＭＩＭＤ）マシンは、それらが多種多様なアプリケーションに対処することができるために普及している。

性能需要が高まるにつれて、組み込みシステムは、ますます、複数の異種または同種の処理リソースを使用する、マルチコアＭＩＭＤアーキテクチャを利用して、必要なレベルのシリコン効率を提供するようになってきている。通常、これらは、集中型共用メモリアーキテクチャと呼ばれるＭＩＭＤマシンのクラスであり、複数の処理リソース間で単一のアドレス空間（またはその一部）が共用されるが、よりアプリケーション特有のハイブリッドアーキテクチャもよく見られる。

ＭＩＭＤアレイの各処理リソースは、命令レベルの並列処理（ＩＬＰ）を利用することができるが、ＭＩＭＤマシンは、スレッドレベルの並列処理（ＴＬＰ）を利用して、基礎となるハードウェアの潜在的性能を実現することもできる。実行時に（特定のハードウェアによって）、またはコンパイル時に（コンパイルツールを最適化することによって）識別されるＩＬＰに対して、ＴＬＰは、アプリケーション設計時に高水準プログラミングソフトウェア内で定義される。

スレッディングは、長年にわたり、ソフトウェア業界内で、並列処理の高レベル表現として使用されてきた概念である。スレッドとは、定義上、他のスレッドと同時に実行され得る実行状態、命令ストリームおよびデータセットを含む自律的作業パッケージを定義するものである。命令ストリームの複雑度は重要ではない。スレッドは、単純なデータ転送から複雑な数学的変換に至るまで何でも記述することができる。

従来から、オペレーティングシステムは、ソフトウェア技術者が基礎となるデバイスアーキテクチャを詳細に理解することを必要とせずにマルチコアアーキテクチャのある一定の構成上でアプリケーションが実行されることを可能にするスレッド割り振り機能を含めて、システム管理の提供を支援している。しかしながら、ユニコアデバイス内のスレッド管理のための既存のソフトウェア技術は、マルチコアアーキテクチャに一貫して容易に適合することができない。これまでの解決策は、設計ごとにカスタマイズされた解決策を必要とする、専用のものであり、通常は、性能および拡張性を損なうものであった。

従来、異種混合マルチコアシステム（すなわち、ほぼ異種の処理リソースを有するシステム）の場合には、多種多様な手法を用いて異なる処理リソースが協働することを可能にしている。しかしながら、これらは、大まかに、「プロキシホスト」と「連携」（「ピアツーピア」ともいう）という２つのカテゴリに分けられる。前者の場合、指定された汎用ホストプロセッサ（バスベースのシステムでは、しばしば、ＣＰＵと呼ばれる）は、システム全体を統括し、システム全体のタスクを仲介し、メモリやデバイスなどのリソースへのアクセスを同期させる。そのようなシステム統括管理は、通常、オペレーティングシステムのカーネルで操作され、システムアプリケーションおよびホストプロセッサ上の非同期イベントの処理とタイムスライスを求めて競合する。言い換えると、この汎用プロセッサは、マルチコアデバイス上のすべての処理リソースのための集中型プロキシスレッドマネージャとして働くと共に、主要なアプリケーションプロセッサとしても働かなければならない。

この構成で使用されるとき、汎用プロセッサは、事前設定のスケジューリングポリシに応じた各処理リソースごとの実行可能なスレッドの待ち行列、すなわち、スレッドの優先度（すなわちディスパッチまたは作動可能待ち行列）、ならびに、スレッド自体が実行され始める前に、何らかのイベント、または別のスレッドの結果を待ち受けるスレッドの待ち行列（すなわち保留およびタイミング待ち行列）を維持しなければならない。これらが、スレッド実行前のプロセッサ構成など、他のシステムオーバーヘッドに加えられる。

汎用プロセッサが、例えば、スレッドの完了のために発行された割り込み（したがって、そのスレッドを完了したばかりの処理リソースの解放）の結果として、その処理時間を、プロセッサが現在実行しているスレッドから、（スレッド管理を含む）システムの管理に転じるときにはいつでも、汎用プロセッサは、コンテキスト変更を行わなければならない。

コンテキスト変更には、休止されるスレッドの現在の進捗状況をメモリに格納し、その他のスレッド／処理リソースのサービス提供のための管理ルーチンに関連する命令をフェッチし、次いで、任意の構成要件を含めてそれらの命令を実行することを伴う。元の、休止されたスレッドに戻るには、さらなるコンテキスト変更が実行されなければならない。これらのコンテキスト変更は、通常、割り込みを受け取り時に実行され、組み込みシステムでは、これらの割り込みが、汎用プロセッサ上で実行中のアプリケーションコードにとって、頻繁、かつ非同期的であることがしばしばある。したがって、システム全体として、著しい性能劣化を呈する。また、コンテキスト切換えは、ホストプロセッサキャッシュに悪影響を及ぼす（いわゆる「コールドキャッシュ」効果）。

連携システムの場合、各処理リソースは、オペレーティングシステムの別々のインスタンスを実行し、その一部が、リソース間通信を可能にする。したがって、そのような構成は、ピア間の割り込みの特定の経路指定の結果として、比較的厳格なアーキテクチャ上の区分化を有する。この種のシステムは、アプリケーションを生成するのに必要なプリミティブを提供するが、実施性能は、依然として、オペレーティングシステムのカーネルアクティビティに関連付する頻繁なコンテキスト切換えによって損なわれる。

要約すると、従来のアーキテクチャ（汎用プロセッサ、ソフトウェアエグゼクティブなど）でのシステム管理実現の現在の設計および方法は、複雑な異種混合マルチコアアーキテクチャのシステムおよびスレッド管理には適さない。実際、汎用プロセッサは、マイクロ（命令セット）アーキテクチャレベルでも、マクロ（キャッシュ、レジスタファイル管理）アーキテクチャレベルでも、十分に最適化されない。マルチコアプロセッサの相互接続は、別々の処理リソース間の相互運用のための物理的媒体を提供するが、システム管理の一貫性した手法を可能にする、すべての処理リソース間で共用される、システム規模のタスク管理通信層がない。最悪の場合、これは、従来から、それぞれが、随時、ソフトウェアにおいて別々に解決されなければならない、あらゆる処理リソース間のあらゆる可能な通信チャネルに関連付けられる明確な問題をもたらしかねない。

よって、これらの非常に複雑なマルチコアアーキテクチャの効率的なシステム管理の方法が求められている。ソフトウェア抽象化だけでは、複雑なマルチコアアーキテクチャの必要なレベルの性能を提供することができない。

発明の概要

本発明の第１の態様によれば、請求項１で定義されるマルチコアプロセッサのリソース管理／タスク割り振りコントローラが提供される。

好ましい実施形態では、請求項１のコントローラは、リソース管理およびタスク割り振り専用であり、それ以上の処理リソースを提供しない。

本発明の実施形態において、「従来の」マスタ処理装置（すなわち、本発明のリソース管理／タスク割り振りコントローラがない場合に、タスク割り振りを実行すると共に、利用可能な処理リソースの１つとしても働くはずの一般的な処理リソース）は、システムの電源投入時にマスタとして始動することができ、リソース管理／タスク割り振りコントローラは、初期設定シーケンスの間のＭＰＵからマスタステータスを引き受ける。

また、本発明の実施形態は、通常は、個々のタスクを処理する際の使用で無視されるはずの処理リソースへのタスクの割り振りを可能にする異種混合マルチコアプロセッサの機能も提供する。そのようにして、本発明のコントローラは、利用可能なリソースのより効率のよい使用を可能にする。

別個のリソース管理／タスク割り振りコントローラを設けることによって、本発明は、マルチコアプロセッサのための改善されたタスク割り振り／管理システムを提供し、利用可能な処理リソース間でのより効率のよいタスク割り振りを可能にする。コントローラは、システム管理および例外処理の要素を、専用の、効率のよい、ハードコードされた実施形態に抽象化する。

本発明の実施形態は、「プロキシエージェント」の役割を強制するのではなく、コントローラと共にコントローラクライアントを用いる。コントローラクライアントは、ハードウェアまたはソフトウェアとして実施され得る。そのような構成は、基礎となるシステムの「実行時」アクティビティを効率よく制御する。特に、コントローラは、事前定義された割り振りパラメータの範囲に基づいて、システムスレッドの状態およびスケジューリング決定の正確さを絶えず（「貪欲に」）維持する。

したがって、好ましい実施形態のアーキテクチャは、複雑度を問わずに、構成コンポーネント間の作業分配、および個々の処理リソースの自律性の点で、大きなメリットを提供する。すべての処理リソースが、デフォルトでは「怠惰」であるスレーブデバイスになる。すなわち、好ましい実施形態では、専用の割り込みを介して、リソース管理／タスク割り振りコントローラによってタスクを実行するよう明示的に指示されるのを待つ。同様に、他の実施形態では、リソース管理／タスク割り振りコントローラと処理リソースの間で、ポーリングベースの通信が使用されてもよい。

本発明のコントローラを用いるシステムでは、アーキテクチャ外部から引き起こされるすべての非同期イベントは、直接ピンを介してであれ、間接的に処理リソースの１つ（すなわち入出力装置）の外部操作によってであれ、好ましくは、コントローラに経路指定され、そこで、「ブート時」に構成された１組のスケジューリングポリシを使って、ターゲット処理リソース上で現在実行されているタスクと比較される。処理リソースは、外部イベントに関連付けられた割り込みサービススレッド（ＩＳＴ）が、現在実行中のトランザクション（スレッドまたはタスク）を統括する場合に限って割り込まれ、それによって、当分野で問題であった、任意の処理リソースにおける不必要なコンテキスト切換えを未然に防ぐ。さらに、好ましい実施形態のコントローラクライアントは、任意の複雑度の処理リソースが、共用リソースおよびコントローラ自体で基本的なシステム管理操作を行う（スレッドを作成する、同期プリミティブを発行する、スレッドを削除する、メモリコピーなど）ことを可能にし、命令セットベースのマシンが、これらのタスクをプロキシによって実行する必要を回避する。

本発明のさらなる態様では、そのようなコントローラを備えるマルチコアプロセッサが提供される。

また、本発明は、請求項４０で定義される、マルチコアプロセッサ内のリソースを制御し、割り振る方法にも適用される。

添付の従属請求項には、さらなる利点および特徴が定義されている。

本発明は、いくつかのやり方で実施することができ、次に、例としてあげるにすぎないが、添付の図面を参照していくつかの実施形態を説明する。

好ましい実施形態の詳細な説明

図１に、本発明の一実施形態による機構を組み込んだシステムフレームワーク１０の論理図を示す。フレームワーク１０は、それぞれが他の処理リソース１５０と同種であっても、異種であってもよく、それぞれが任意の複雑度のものとすることのできる複数の処理リソース１５０を備える。各処理リソースは、相互接続１６０を介して共用データが格納される共通のシステムメモリ１４０へのアクセスを共用する。当然ながら、すべてのシステムメモリ１４０が必ずしもすべての処理リソース１５０に共通であるとは限らないことが理解されるであろう。

また、システムフレームワークは、本発明の一実施形態による、集中型タスク割り振り／管理システム２０も備える。集中型タスク割り振り／管理システム２０は、システム管理コントローラ１３０と、専用の密結合メモリ１９０に接続された専用の密結合メモリインターフェース１８０とを含む。各処理リソース１５０は、相互接続１１５を介してコントローラ１３０にアクセスすることができる。図１の構成の実施においては、どんな特定の相互接続戦略（すなわち、コントローラ１３０が各処理リソース１５０と、またその逆方向に通信するための構成、および各処理リソース１５０がシステムメモリ１４０と通信するための構成）も必要とされないことを理解すべきである。特に、処理リソースのそれぞれが、コントローラ１３０と直接的または間接的に（すなわち、他の処理リソースを介して、または別のやり方で）通信することができる必要があることだけを別として、ポイントツーポイントリンク、中央システムバスまたはパイプライン型アーキテクチャでさえも等しく用いることができる。

図２に、やはり一例にすぎないが、図１の論理構成を実施するマルチコアプロセッサを示す。図２のマルチコアプロセッサは、それぞれがシステム相互接続１６０を介して接続された、複数の処理リソース１５０を用いる。システム相互接続１６０は、さらに、入力インターフェース１００、および出力インターフェース１１０を介して、システム管理コントローラ１３０と通信する。図２の例で、システム相互接続１６０は、処理リソース１５０のそれぞれを相互に接続し、コントローラ１３０と接続すると共に、システムメモリ１４０などの共用システムリソースとも接続する従来の中央バスとして配置される。メモリ１４０とのインターフェースは、いくつかの現在利用可能なインターフェース技術のいずれか１つによって達成されてもよい。メモリは、例えば、静的ランダムアクセスメモリ（ＳＲＡＭ）や、２倍速ランダムアクセスメモリ（ＤＤＲ ＲＡＭ）といった、現在利用可能な中央コンピュータメモリ技術のいずれで構成されてもよい。

図２にみられるように、複数の処理リソース１５０のそれぞれは、中央コントローラ１３０から制御情報を受け取り、受け取った制御情報に従って処理リソース１５０を管理するように構成された、関連付けられたシステム管理コントローラクライアント１２０を有する。コントローラクライアント１２０の機能および目的は、以下で、図７および８に関連してより詳細に説明する。また、各処理リソースは、システム相互接続１６０を介したコントローラ１３０との通信のための、関連付けられた相互接続エージェント１７０も有する。相互接続エージェント１７０は、システム相互接続１６０上で使用される基礎となる相互接続プロトコルから独立の、コントローラクライアント１２０への汎用インターフェースを提供する。すなわち、相互接続エージェント１７０は、システム相互接続１６０上で使用される通信プロトコルとコントローラクライアント１２０によって使用される通信プロトコルの間のプロトコル変換を提供する。相互接続エージェント１７０の使用により、本発明の実施形態のコントローラクライアント１２０は、現在利用可能な任意のシステム相互接続プロトコルと共に使用することができる。

マルチコアプロセッサは、全体として、スレッドと呼ばれるいくつかの個別タスクに分割することのできるターゲットアプリケーションを実行するように構成される。各処理リソース１５０は、それだけに限らないが、当該のスレッドの優先度、各処理リソース１５０の利用可能性および個々のスレッドの実行への個々の処理リソースの適合性を含むいくつかのパラメータに従い、コントローラ１３０によって適切なスレッドに割り振られる。これについても、やはり、以下でより詳細に説明する。

しかしながら、システム管理コントローラ１３０およびその専用メモリ１９０の追加は、その他の点ではプロセッサ１０の配置の再設計を必要としないことを理解すべきである。

図３に、１つの具体的な構成を示す。図３には、ブロック図の形で、典型的なシステムオンチップ（ＳｏＣ）アーキテクチャが示され、実際のアプリケーションにおいてコントローラ１３０のリソース管理下に置かれ得る様々な処理リソースが説明されている。処理リソースは、具体的には、ＤＳＰなど、比較的一般的な機能のものとすることもでき、周辺入出力など、比較的限定された機能のものとすることもできることが認められる。

システム管理コントローラインターフェースグループ
図４に、コントローラ１３０と、コントローラ１３０の周辺に位置する、コントローラ１３０に関連付けられたインターフェースグループ２００〜２５０を示す。

システム制御グループ２００は、システム管理コントローラ１３０の正しい動作を保証するのに必要な２つのシステム入力信号を備える。２つのシステム入力信号は、システムクロックに接続されるＣＬＫ入力と、ＲＳＴ入力からなる。システム管理コントローラ１３０からのすべての出力信号がシステムクロックに同期し、システム管理コントローラ１３０へのすべての入力信号が、このクロックを使ってサンプリングされる。ＲＳＴ入力は、システム管理コントローラ１３０をリセットするための同期リセット信号である。

外部割り込みグループ２１０は、システム管理システム外部から供給される同期外部割り込みのグループからなる。これらの信号は、システム管理コントローラ１３０周辺に接続される前にＣＬＫに同期されなければならない。外部割り込みグループ２１０内の信号は、例えば、外界との入力インターフェースから、またはピンを介してマルチコアプロセッサ外部から直接駆動され得る。外部割り込み入力の数は、マルチコアプロセッサ１０設計段階において定義される。

内部制御グループ２２０は、各コントローラクライアント１２０およびそれに関連付けられた処理リソース１５０ごとの単一の同期割り込みからなる。したがって、信号のグループの数は、通常、システム内の処理リソース１５０の数に対応し、マルチコアプロセッサ１０設計段階において定義される。内部割り込み信号は、そのコントローラクライアント１２０に関連付けられた特定の処理リソース１５０に割り当てられている、実行可能なスレッドを示す。

密結合メモリインターフェースグループ１８０は、システム管理コントローラ１３０を、独自の専用密結合メモリリソース１９０にインターフェースする。図５に、専用密結合メモリ１９０の典型的な構造を示す。アドレスパスおよびデータパスの幅は、マルチコアプロセッサ１０設計段階において定義される。専用密結合メモリインターフェースは、メモリアドレスバス１９１、メモリ読取りデータバス１９２、メモリ書込みデータバス１９３、ならびに書込み１９４および読取り１９６イネーブル信号を含む。

接続されるメモリは、同期ＳＲＡＭデバイスであるものとする。専用密結合メモリ１９０は、ターゲットアプリケーションの必要に従って、マルチコアプロセッサ１０設計段階において定義される、整数個のコントローラメモリ要素１９５を含む。現在の好ましい実施形態において、各コントローラメモリ要素１９５は、２５６ビットのメモリ空間を消費する。やはり現在の好ましい実施形態において、コントローラは、最大６５５３６個のコントローラメモリ要素（すなわち、１６ＭＢメモリ）をサポートする。後述するように、待ち行列記述子はコントローラメモリ要素１９５を消費するが、典型的なシステムにおいて、必要なコントローラメモリ要素１９５の数は、スレッドサポート要件によって決まるはずである。例えば、システム管理コントローラ１３０内で同時に４００スレッドをサポートすることのできるシステムは、おおよそ１２８ＫＢの接続メモリを必要とするはずである。

図４の相互接続インターフェースグループ２３０は、マルチコアプロセッサ１０と、マルチコアプロセッサ設計段階において定義される相互接続エージェント１７０で使用される選択された相互接続プロトコルに従う。

コントローラサブブロック記述および機能
図６に、システム管理コントローラ１３０の主要な論理コンポーネントを示す。コントローラ１３０の機能は、以下の各機能を実行する４つの１次内部並列処理サブブロック間で分担される。

１．専用密結合メモリ１９０内の空いているコントローラメモリ要素１９５のリストを維持し、コントローラメモリ要素１９５回復を監視するように構成されたスレッド入力マネージャ（ＴＳＩＭ）３００。

２．専用密結合メモリ１９０内の保留リストおよびタイマ待ち行列を維持し、スレッド間の同期を実行し、必要に応じて、専用密結合メモリ１９０内の作動可能待ち行列構造へのスレッドの格上げを行うように構成されたスレッド同期マネージャ（ＴＳＰＭ）３１０。スレッド同期マネージャ３１０は、専用密結合メモリ１９０内での保留スレッド記述子の挿入および抽出によって、保留およびタイマ待ち行列構造の保全性を維持する。

３．専用密結合メモリ１９０内の作動可能待ち行列構造と、専用密結合メモリ１９０内の各処理リソース１５０ごとのディスパッチ待ち行列とを維持するように構成されたスレッド出力マネージャ（ＴＳＯＭ）３２０。スレッド出力マネージャ（ＴＳＯＭ）３２０は、さらに、コントローラクライアント１２０に送られる割り込み２２０を生成するように構成される。作動可能待ち行列構造の保全性の維持は、専用密結合メモリ１９０内のコントローラメモリ要素１９５で保持されるスレッド記述子の挿入および抽出によって行われる。

４．専用密結合メモリ１９０内に位置する作動可能待ち行列構造内の各処理リソース１５０ごとにスケジューリング決定を提供するように構成されたスレッドスケジュールマネージャ（ＴＳＳＭ）３３０。

さらに、いくつかの２次処理サブブロックが、以下のサポート機能を提供する。

５．相互に排他およびロッキングを含む、接続された専用密結合メモリ１９０への集約アクセスを提供するように構成されたスレッドメモリマネージャ（ＴＳＭＭ）３４０。

６．入力される外部システム割り込みを内部同期プリミティブに変換するように構成された割り込みマネージャ（ＴＳＩＣ）３５０。

７．各処理リソース１５０に同期のためのタイマ機能および監視タイマ機能を提供するように構成されたタイムマネージャ（ＴＳＴＣ）３６０。

８．処理リソース１５０に相互接続インターフェースおよび構成および実行時アクセスを提供するように構成されたシステムインターフェース（ＴＳＩＦ）３８０。

続いて、システム管理コントローラ１３０内の上記１次および２次処理サブブロックの対話の詳細な説明を行う。

各サブブロックは、他のサブブロックに１組の関数を提示し、それぞれが、そのピアに、専用密結合メモリ１９０内のそれぞれに維持される構造に対する操作を実行するよう指示することができるようにする。各関数は、コントローラソフトウェアのアプリケーションプログラミングインターフェース（ＡＰＩ）において受け取られたのと類似のコマンドを受け取り次第、個々のサブブロックによって呼び出される。

スレッド入力マネージャ関数
スレッド入力マネージャ３００は、システム管理コントローラ１３０内の他のサブブロックに３つの共通関数を提供する。

ＦｒｅｅＬｉｓｔＳｔａｔｕｓ関数は、コントローラメモリ要素１９５フリーリスト内の先頭ポインタおよび要素数を返す。フリーリストは、現在未使用のコントローラメモリ要素１９５のリストである。この関数は、コントローラ１３０ソフトウェアＡＰＩにおける類似コマンドの受け取り時に、システムインターフェース３８０によってのみ呼び出され得る。

ＰｕｓｈＦｒｅｅＩｎｄｅｘ機能は、解放されたコントローラメモリ要素１９５インデックスをフリーリスト上にプッシュバックするのに使用される。この関数は、スレッドスケジュールマネージャ３３０によってのみ呼び出され得る。

ＰｏｐＦｒｅｅＩｎｄｅｘ関数は、フリーリストから空いているコントローラメモリ要素１９５インデックスをポップするのに使用される。これは、通常、システムインターフェース３８０内のＡＰＩ呼び出しサービスルーチン内から呼び出される。

スレッド同期マネージャ関数
スレッド同期マネージャ３１０は、システム管理コントローラ１３０内の他のサブブロックに７つの共通関数を提供する。

以下の５つの関数は、コントローラ１３０ソフトウェアＡＰＩによって受け取られた類似のコマンドに応答して、システムインターフェース３８０によってのみ呼び出され得る。

ＰｕｓｈＰｅｎｄｉｎｇＤｅｓｃｒｉｐｔｏｒ関数は、ブートプロセスの間に、保留待ち行列記述子のリストに保留待ち行列記述子を加えるのに使用される。

ＰｕｓｈＴｈｒｅａｄ関数は、実行時に、所与の保留待ち行列に従属スレッドを加えるのに使用される。

ＳｅｔＴｉｍｅｒＳｔａｔｕｓは、タイマ待ち行列内の先頭ポインタおよび要素数を設定する。

ＧｅｔＴｉｍｅｒＳｔａｔｕｓ関数は、タイマ待ち行列内の先頭ポインタおよび要素数を返す。

ＳｅｔＰｅｎｄｉｎｇＳｔａｔｕｓ関数は、保留待ち行列記述子リストの状況を設定する。

ＧｅｔＰｅｎｄｉｎｇＳｔａｔｕｓ関数は、保留記述子待ち行列内の先頭ポインタおよび要素数を返す。

ＳｙｎｃＥｖｅｎｔ関数は、所与の保留待ち行列に同期プリミティブを発行するのに使用される。この関数は、スレッド割り込みマネージャ３５０およびシステムインターフェース３８０によって呼び出される。

ＴｉｍｅＥｖｅｎｔ関数は、タイマ待ち行列に、タイマベースの同期プリミティブを発行するのに使用される。この関数は、タイムマネージャ３６０によってのみ呼び出される。

スレッド出力マネージャ関数
スレッド出力マネージャ３２０は、システム管理コントローラ１３０内の他のサブブロックに５つの共通関数を提供する。

Ｐｕｓｈ関数は、作動可能待ち行列構造内にスレッド記述子を配置する。このメソッドは、（例えば、割り込みを処理するなどの）処理速度を速めるために、高い優先度で呼び出され得る。スレッドが独立である（即座に作動可能である）場合、呼び出しは、システムインターフェース３８０から行われ、スレッド記述子が元々依存関係を有していた場合、呼び出しは、スレッド同期マネージャ３１０から行われる。

以下の３つの関数は、コントローラ１３０ソフトウェアＡＰＩにおける類似コマンドの受け取りに応答して、システムインターフェース３８０によってのみ呼び出され得る。

ＧｅｔＤｉｓｐａｔｃｈＱｕｅｕｅＳｔａｔｕｓ関数は、ディスパッチ待ち行列リスト内の先頭ポインタおよび要素数を返す。

ＳｅｔＤｉｓｐａｔｃｈＱｕｅｕｅＳｔａｔｕｓ関数は、ディスパッチ待ち行列リスト内の先頭ポインタおよび要素数を設定する。

ＤｉｓｐａｔｃｈＱｕｅｕｅＰｏｐ関数は、ディスパッチ待ち行列の先頭からスレッド記述子をポップする。

ＤｉｓｐａｔｃｈＷｏｒｋＱｕｅｕｅＰｕｓｈ関数は、スレッド出力マネージャ３２０作業待ち行列上にディスパッチ待ち行列をプッシュする。この関数は、スレッドスケジュールマネージャ３３０によってのみ呼び出され、スレッドスケジュールマネージャ３３０は、この関数を使って、出力マネージャ３２０に、スケジュール更新の結果としてディスパッチ待ち行列内で必要とされる変更を知らせる。

スレッドスケジュールマネージャ関数
スレッドスケジュールマネージャ３３０は、システム管理コントローラ１３０内に位置するスレッド出力マネージャ３２０およびシステムインターフェース（ＴＳＩＦ）３８０に３つの共通関数を提供する。

ＰｕｓｈＰｕｓｈＷｏｒｋＥｖｅｎｔ関数は、スレッド出力マネージャ３２０が作動可能待ち行列構造にスレッド記述子を加えた直後に、スレッド出力マネージャ３２０によって呼び出される。

ＰｕｓｈＰｏｐＷｏｒｋＥｖｅｎｔは、スレッド出力マネージャ３２０が作動可能待ち行列構造からスレッド記述子を除去した直後に、スレッド出力マネージャ３２０によって呼び出される。

ＦｒｅｅＩｎｄｅｘ関数は、コントローラメモリ要素１９５の解放が、スレッドスケジュールマネージャ３３０内で進行中のスケジューリングアクティビティと適正に同期されることを可能にする。呼び出しは、コントローラ１３０ソフトウェアＡＰＩにおいて類似のコマンドを受け取り次第、またはスレッド出力マネージャ３２０内のポップ操作の結果として発行されてもよい。

コントローラクライアント
前述のように、処理リソース１５０という用語は、命令がどれほど初歩的なものであるかに関わらず、その命令を実行し得る任意のリソースに適用される。したがって、入出力モジュールなど、固定機能を有するリソースも含まれる。処理リソース１５０の種類に応じて、システム管理コアクライアント１２０を介した、システム相互接続１６０と処理リソース１５０の間の接続は、単方向とすることも、双方向とすることもできる。

図７に、システム管理コントローラ１３０と共に使用するためのコントローラクライアント１２０の概略的ブロック図の一例を示す。

例えば、汎用プロセッサやディジタル信号プロセッサなどの適切な処理リソース１５０上で、コントローラクライアント１２０は、通常、ソフトウェアとして実施される。しかしながら、処理リソース１５０が限定された機能のものである場合、コントローラクライアント１２０は、ハードウェアコンポーネントを必要とすることもある。

システム相互接続１６０と処理リソース１５０の間でハードウェアコンポーネントが使用されるとき、コントローラクライアント１２０は、やはり、同じインターフェースを使って処理リソース１５０にインターフェースする。すなわち、コントローラクライアントは、処理リソース１５０のコントローラクライアントへのインターフェースと同一のインターフェースを相互接続エージェント１７０に提示する。場合によっては、例えば、入出力装置の場合には、処理リソースへのデータパスを、処理リソースからのデータパスと異なるものとして処理するのが妥当なこともある。

主要なインターフェースに加えて、コントローラクライアント１２０は、実行時およびデバッグイベントの出力として使用するために帯域外インターフェースも提供する。ソフトウェアコントローラクライアント１２０が使用される場合、これらは、適切なサービスルーチンを呼び出す標準割り込みを使って提供される。

コントローラクライアント動作モード
各コントローラクライアント１２０は、完全に割り込み駆動型である。コントローラ１３０から内部割り込みを受け取り次第、コントローラクライアント１２０は、専用密結合メモリ１９０内に保持されているその特定の処理リソース１５０に関連付けられたディスパッチ待ち行列の先頭から、スレッド記述子をポップする。次いで、スレッド記述子内の一意の参照を使って、メインメモリリソース１４０さらなるスレッド制御情報、スレッド制御ブロック（ＴＣＢ）が読み取られる。ＴＣＢ内に含まれる情報は以下のいずれかとすることができる。

１．コントローラクライアント１２０構成内容。この情報は、コントローラクライアント１２０システムリソース使用ポリシング、データプレゼンテーションモードなどを構成するのに使用され得る。

２．処理リソース１５０構成内容。これは、個々のスレッドの実行のために処理リソース１５０を準備するのに必要とされる情報である。これは、このスレッド前の部分実行からの回復、または、オーディオＣＯＤＥＣなどの、専用ハードウェアアクセラレータの構成を含んでいてもよい。

３．命令内容。固定機能ハードウェアアクセラレータの場合、例えば、処理リソース１５０が出力モジュールであるときの出力命令など、「命令」は、目的のハードウェア処理リソース１５０では暗黙的となり、任意の必要な専門化または構成が、構成情報内に収容されることになる。ソフトウェアコントローラクライアント１２０の状況では、これは、通常、スレッドに関連付けられた機能コードを指示すポインタになる。

４．データ内容。この内容は、システムメモリ１４０内の開始アドレスまたは複数のアドレス、およびスレッドが動作し得るデータ範囲を定義することができる。

５．コントローラクライアント１２０後処理内容。この内容は、スレッド実行完了後のコントローラクライアント１２０のアクションを決定する。

コントローラクライアント１２０の３つの異なる動作段階がある。

１．処理リソース１５０およびコントローラクライアント１２０が個々のスレッドの実行のために準備される構成段階。最も単純な場合、構成段階はヌルになる。

２．スレッドが実行され、コントローラクライアント１２０がデータを供給し、かつ／またはリソース利用を監視し得る実行段階。

３．完了段階。処理の完了は、結果として、アクションなし、別のスレッドの作成、同期プリミティブの発行、またはスレッド作成と同期の組み合わせを生じ得る。さらに、コントローラクライアント１２０は、スケジューラメトリックを設定または更新し、スレッドを終了させるように要求されることもある。スレッド実行時に、結果を格納するためにさらなるメモリが必要とされる場合、コントローラクライアント１２０は、このメソッドも実行しなければならない。

個別のハードウェアコントローラクライアント１２０ｂが、アクティブ期間において利用可能なシステム相互接続１６０帯域幅を完全に利用する状況において、１つの最適化された解決策は、コントローラクライアント１２０ｂが、複数のハードウェア処理リソース１５０のプロキシとして動作するのを可能にすることであろう。そのような構成を図７ｂに示す。前述の場合と同様に、プロキシコントローラクライアント１２０ｂは割り込み駆動型である。しかしながら、前述の例では、コントローラ１３０から単一の割り込みだけが経路指定されたが、プロキシコントローラクライアントモデルでは、処理リソース１５０ごとの割り込みがある。コントローラ１３０から受け取られる割り込みのインデックスに従って、プロキシコントローラクライアント１２０ｂは、識別された処理リソース１５０で同じステップを実行する。システム相互接続１６０使用ポリシングが必要とされるプロキシコントローラクライアントモデルでは、ハードウェアアダプタ１２０ｃが、処理リソース１５０とシステム相互接続１６０の間に残る。

前述のように、コントローラクライアント１２０は、ソフトウェアとして実施されてもよい。この場合、コントローラクライアント１２０の機能の一部、例えば、共用リソース使用ポリシングは、通常、処理リソース１５０ハードウェア（例えば、メモリ管理ユニット（ＭＭＵ）など）にすでに存在する既存のハードウェアコンポーネントを利用することになる。

結果として、ソフトウェアコントローラクライアント１２０アーキテクチャおよび実施は、処理リソース１５０特有のものになる。

また、ハードウェアコントローラクライアント１２０は、関連付けられた処理リソース１５０の特質による専門要件を有することもある。以下の項では、大部分の場合に好適となる汎用アーキテクチャを説明する。

ハードウェアコントローラクライアントの一般例
図８に、ハードウェアコントローラクライアント１２０の基本構造を示す。設計の機能的中心にあるのは、コントローラクライアント有限状態機械（ＦＳＭ）５００である。この有限状態機械（ＦＳＭ）５００は、３段階すべてにおいてアクティブとすることができる。コントローラクライアントＦＳＭ５００は、コントローラ１３０からの割り込み２２０によって活動化される。

まず、コントローラクライアントＦＳＭ５００は、システム相互接続１６０を制御して、独自の命令への参照を含む共用メモリリソース１４０からＴＣＢを読み取らせる。構成段階の間、コントローラクライアント１２０は、処理リソースを制御して、構成コマンドを解釈し、コマンドを、処理リソース１５０に発行される書込みサイクルに変換することができる。さらに、コントローラクライアント１２０は、独自のリソースポリシングを構成する。構成状態から実行状態への遷移の仕方は処理リソース１５０特有のものであるが、明示的な実行プリミティブによってマークされてもよく、単に、データ転移状態に入ることとしてもよい。

コントローラクライアント１２０から見て、最も単純なアーキテクチャは、処理リソース１５０とシステム側の両方で同一のインターフェースプロトコルを有する。この場合、実行段階の間に、処理リソース１５０読取り／書込みサイクルが、適切な場合にはチェックを伴って、単に、システムインターフェースにマップされるだけである。

最も単純なコントローラクライアント１２０実施は、システムから処理リソースへのパス５１０と処理リソースからシステムへのパス５２０の両方でＦＩＦＯスタイルのインターフェースを必要とするはずである。この性質のコントローラクライアント１２０の実行段階の間、データは、メッセージまたはストリーミングモードによって処理リソース１５０に提示され得る。データセット全体が、処理の前にコントローラクライアント１２０内においてローカルで蓄積されるメッセージモードは、より複雑な相互接続アービタを円滑化し得る、より粗くむらのある相互接続挙動を生じさせる。データがシステムメモリから処理リソース１５０に直接ストリーミングされるストリーミングモードは、ハンドシェークのより慎重な考察を必要とし、細かい相互接続トランザクションおよび相互接続への密結合を呈する、よりシリコン効率の高い解決策を提示する。

実行段階から完了段階への遷移は、処理リソース１５０へのデータの提示を測定することによって推断されてもよく、処理リソース１５０自体によって明示的に通知されてもよい。完了段階の間、コントローラクライアント１２０は、再度、元のスレッド制御ブロックによって提供される命令セットから実行する。

場合によっては、処理リソース１５０に入るディスパッチ（例えば、入出力装置など）と処理リソース１５０から出るパスとを区別して扱うことが妥当であることに留意されたい。これに対して、同じコントローラクライアント１２０フレームワーク内でデータの消費側と生成側を結合すべき場合（例えば、ＤＳＰなどのアルゴリズム的アクセラレータ）もある。

処理リソース１５０とその他のシステムリソースの間で減結合のレベルを提供するために、コントローラクライアント１２０によって、以下のようないくつかの追加機能が提供され得る。
ａ）処理リソース１５０によって生成されるアドレスが、比較器５３０および比較アドレスレジスタ５４０を使って、基底アドレスおよびオフセット定義によって定義される期待される挙動に照らしてチェックされてもよい。
ｂ）処理リソース１５０によって生成されるアドレスが、減算機５５０およびオフセットアドレスレジスタ５６０を使ってオフセットされ、処理リソース１５０が、通常、アドレス０×０前後に正規化される、任意の所与のスレッドのアドレスマップの正規化ビューを有することを可能にする。

オブジェクト
システム管理コントローラ１３０内で使用されるデータ型のインスタンスは、公開（システム一般から見ることができ、システム一般によって操作される）と専用可視（システム管理コントローラ１３０内でのみ見ることができ、システム管理コントローラ１３０サブブロックによってのみ操作される）とに分けられる。複数のエンドアプリケーションにまたがる設計の移植性を保証するために、すべてのスレッド、待ち行列および集約待ち行列記述子が、共通基底クラスを使用する専用密結合メモリ１９０、コントローラメモリ要素１９５内に格納される。

コントローラメモリ要素
各コントローラメモリ要素１９５は、以下の７つの記述子型のいずれかを表すことができる。

１．フリーリスト要素。この要素は、その他の記述子型のいずれによっても自由に利用される。ユーザ初期設定も実行時操作も必要とされない。

２．スレッド記述子（ＴＤ）。これは、アプリケーション／ＯＳスレッドのデータ構造表現である。この記述子は、専用密結合メモリ１９０内の保留待ち行列、作動可能待ち行列またはディスパッチ待ち行列に存在し得る。ユーザ初期設定は必要とされないが、実行時操作は必要である。

３．スケジューラルート記述子（ＳＲＤ）。これは、スケジューラ階層の最上位の記述子である。ユーザ初期設定は必要であるが、実行時操作は必要とされない。ルート記述子は親を持たないが、子は、ＳＳＴＤ、ＤＳＴＤまたはＴＤのいずれかとすることができる。

４．静的スケジューラ層記述子（ＳＳＴＤ）。これは、ＳＲＤまたは別のＳＳＴＤを親とすることのできる静的スケジューラ層記述子である。ＳＳＴＤの子は、別のＳＳＴＤ、ＤＳＴＤまたはＴＤのいずれかとすることができる。

５．動的スケジューラ層記述子（ＤＳＴＣ）。これは、動的スケジューラ層記述子である。ユーザ初期設定は必要とされないが、実行時操作は必要である。ＤＳＴＤの親は、ＳＲＤまたはＳＳＴＤのどちらかとすることができるが、ＤＳＴＤは、ＴＤの子だけしか持つことができない。

６．ディスパッチ待ち行列記述子。この種の記述子は、関連付けられた処理リソース１５０からのポップ操作を待ち受けるスレッド記述子のリストを記述する。ユーザ初期設定は必要であるが、実行時操作は必要とされない。

７．保留待ち行列記述子。この種の記述子は、同期イベントを待ち受けるスレッド記述子のリストを記述する。ユーザ初期設定は必要であるが、実行時操作は必要とされない。

以下の各項では、これらの記述子をより詳細に説明する。

コントローラメモリ要素１９５の様々な形、およびそのそれぞれを、図９ａから９ｌに示す。

スレッド表現
記述子が初期設定または実行時操作を必要とする場合、操作は、コントローラ１３０ＡＰＩを介して行われる。集中型タスク割り振り／管理システムは、リアルタイム対話が、ハードウェア実施に十分適する／ハードウェア実施に十分なほど単純化されるように設計される。

図１０に、スレッド記述子と、システム管理コントローラ１３０と、処理リソース１５０と、共用システムメモリ１４０の間の典型的な関係を示す。各スレッドプリミティブは、一意の参照、ｐＲｅｆｅｒｅｎｃｅを含む。この参照は、システム管理コントローラ１３０によって解釈も、変更もされない。ｐＲｅｆｅｒｅｎｃｅは、実行されるべきタスクを定義するシステムメモリ１４０内のデータ構造を指し示すポインタを提供する。通常、これは、コントローラクライアント制御ブロック１２５であり、少なくとも、（図１０に処理リソース命令ブロック１４５として示す）関数ポインタ、スタックポインタおよび（図１０にデータブロック１３５として共に示す）引数ポインタという要素を含むはずである。帯域内構成または共用システムリソースのセキュリティを提供する追加フィールドが定義されてもよい。

しかしながら、アプリケーションおよび／またはターゲット処理リソース１５０によって、コントローラクライアント制御ブロック１２５の複雑度は異なり得る。特に、適切な「制御」命令コードおよび対応する「ディスパッチ」コードが与えられた場合に、異なる処理リソース１５０が、一定の状況下で、同じデータに対して同じ関数を実行することを可能にし得る別のレベルの間接化も含まれ得ることに留意されたい。

図１１に、スケジューリング階層が、２つの異種の処理リソース（図１１のタイプIおよびタイプII）１５０ａと１５０ｂにまたがってタスクを負荷均衡化する一例を示す。（この階層の待ち行列に入れられるスレッド記述子内の）ｐＲｅｆｅｒｅｎｃｅフィールドは、前述のようにコントローラクライアント制御ブロック１２５を参照するが、この場合、それぞれの異種の命令セットによって必要とされる個々の命令ストリームに対応する処理リソースの種類ごとにポインタがある。コントローラクライアント１２０は、コントローラクライアント制御ブロック１２５内のフラグに従って適切な命令ストリーム（命令ブロック１４５ａまたは１４５ｂ）を選択する。

この機能は、例えば、いくつかの処理リソースの電源遮断機能と関連させると役立つことがある。所与のタスクに最適なプロセッサが電源遮断された場合、高くつくリブートサイクルを発生させるのではなく、次善のプロセッサがそのタスクを実行する方が望ましいことがある。さらに、例外的な負荷の状況下では、例えば、負荷の軽い汎用プロセッサが、負荷の思いＤＳＰの負担を軽減することができるようにしてもよい。

処理リソース１５０がスレッドを処理することが可能な状態になると、スレッドは、その処理リソース１５０と一意に関連付けられた適切なディスパッチ待ち行列からポップされる。ポップ操作は、ｐＲｅｆｅｒｅｎｃｅ、スケジューリングイベントを生じたスケジューラメトリック、およびスレッドが作動可能になったのはタイムアウトによるものか、それとも同期プリミティブによるものかを示す指示を含む１組のフラグを含むオブジェクトを返す。スレッド記述子に使用されるコントローラメモリ要素１９５は、後のスレッド記述子が使用するためにフリーリストに自動的に返される。

共用オブジェクト
この項では、コントローラ１３０ＡＰＩを介してシステムから見ることのできるオブジェクトを説明する。通常、これらのオブジェクトは、実行時に、コントローラ１３０とクライアント１２０とそれらに関連付けられた処理リソース１５０とを備える集中型タスク割り振り／管理システムによって操作される。

実行時コントローラ１３０ＡＰＩは、アプリケーションが、新しいスレッドを導入し、新しい動的スケジューラ要素を導入し、同期プリミティブを発行し、スケジュールされたスレッドをポップし、割り込みされたスレッドをプッシュし、またはスレッドを除去することを可能にする。

図１２に、システム管理コントローラ１３０内のスレッド管理の典型的な全体図を示す。

スレッドプリミティブ
図９ｃおよび９ｄにスレッドプリミティブのフォーマットを示す。その依存関係に従って、スレッド記述子は、保留待ち行列構造に、または直接作動可能待ち行列構造に配置され得る。スレッドが保留待ち行列構造内に配置されるべきである場合、アプリケーションは、スレッドの依存関係を定義しなければならない。外部イベントへの依存性は、依存参照として現れる。コントローラ１３０は、この依存参照を解釈しない。これは、スレッド記述子を作動可能待ち行列構造にいつ移行させるべきか決定する、入力同期プリミティブとの比較のために維持される。

従属スレッドでは、タイムアウトを指定することができ、ヌル依存参照と関連させて、この機能をスレッドベースのハードウェアタイミング機能として使用することができる。依存関係と関わりなく、タイムアウトは、スレッドを、特定の時刻にスケジュールさせる。

スレッドは、スレッドを作動可能待ち行列構造に格上げさせる同期イベント（タイマまたはプリミティブ）に従ってタグ付けされる。

同期プリミティブ
同期プリミティブは、保留待ち行列とインターフェースし、１つ以上のスレッド記述子の保留待ち行列構造から作動可能待ち行列構造への移行を生じさせることができる。

各同期プリミティブは、識別された保留待ち行列内の各スレッド記述子内に格納された依存参照と比較される一意の参照を含む。比較は、スレッドプリミティブによって識別される優先度の順に進められる。

その種類に従って、同期は、保留待ち行列内の最高優先度のマッチングスレッド記述子またはすべてのマッチングスレッド記述子を稼動状態にすることができる。さらに、特殊なブロードキャストプリミティブが、すべての保留待ち行列内のすべてのマッチングスレッド記述子を活動化する。

割り込み処理
割り込みサービススレッド（ＩＳＴ）法は、非同期イベントによって処理リソース１５０に課される負荷を最小限に抑える有益な手段を提供する。さらに、本発明に基づくシステムにおける加速されたリアルタイム応答は、小さなシステム変更を加えるだけでＩＳＴのさらなる普及を可能にする。

コントローラ１３０は、コントローラ周辺での外部割り込み入力２１０から自動的に同期プリミティブを作成する。保留待ち行列内の事前に構成された割り込みサービススレッド記述子が、これらの割り込み同期プリミティブの受け取り時に、作動可能待ち行列構造に格上げされる。

アプリケーションは、通常、システム初期設定時に、外部割り込み２１０に関連付けられたスレッド記述子を構成し、関連付けられた割り込みサービススレッドの各実行内でも構成する。

この機能は、事実上、システム内の他の任意の専用割り込みサービス提供処理リソース１５０の必要をなくす。さらに、この機能は、これらの外部割り込み２１０を、同じ優先度構造により、すべてのプロセッサタスクに使用される同じポリシに従って処理し、すでにより優先度の高いタスクを実行している処理リソース内でのコンテキスト切換えの必要をなくす。通常の優先使用ルーチンを使って現在実行中のスレッドを作動可能待ち行列にプッシュバックすることができるために、任意の数のネストされた割り込みがサポートされる。

タイマベースの割り込み（ウォッチドッグおよび周期的イベント）も同様のやり方で処理される。（周期的または１回限りの）タイムベースのタスクは、タイマ待ち行列に挿入されなければならず、タイムアウト依存関係を有するスレッドと類似のやり方で処理される。設計により、この方法は、有用な処理要件を持たないタイムベースの例外を除外する。

割り込み優先度は、応答時間を速くするために、割り込みルーチンが現在実行中のタスクに取って代わることを許されるように設定される。

専用オブジェクト
専用オブジェクトは、通常、ブート時、すなわち、電源遮断サイクル後のシステム初期設定時に構成される。処理リソース１５０が、実行時に内部オブジェクトと直接対話することはまれである。

内部オブジェクトは、主として、待ち行列構造である。システム管理コントローラ１３０は、保留待ち行列、タイマ待ち行列、作動可能待ち行列およびディスパッチ待ち行列という４種類の主要な待ち行列を管理する。

システム管理コントローラ１３０内には、内部操作を円滑化するために、さらに２次的待ち行列が存在する。待ち行列間のスレッド記述子の移動は、ポインタ操作のみで行われる。スレッド記述子は、絶対にコピーされることはない。

保留待ち行列構造
スレッドは、同期イベントまたはタイマイベントによって、保留待ち行列構造から作動可能待ち行列構造に格上げされ得る。スレッドは、これらのイベントクラスの両方に反応しても、一方だけに反応してもよい。スレッドが両方に反応する場合、そのスレッドは、保留待ち行列とタイマ待ち行列の両方に存在する。

保留待ち行列は、同期イベントを待ち受ける従属スレッドを保持する。スレッドは、処理リソース１５０からの同期プリミティブによって、またはタイムマネージャ３６０によって内部で生成されたタイマイベントによってこれらの構造から除去される。複数の競合有効範囲および割り込みサービススレッドをサポートするために、アプリケーションプログラマが、構成可能な数の保留待ち行列を利用することができる。各保留待ち行列内の要素は、それらの優先度に従って処理されなければならない。優先度に従った処理には、挿入時のソートと抽出時のソートという２つの選択肢がある。挿入時のソートは、保留リストを厳密な優先順位で格納し、新しいスレッドをその優先度に従ってリスト内の位置に挿入するためのプロセスを定義する。抽出時のソートは、新しいスレッドをどこに挿入すべきかの任意の選択を行い、同期後の適格なスレッド記述子の優先度に基づくソートを行う。本発明の好ましい実施形態は、挿入時ソートの技法を用いる。

図１３に、保留待ち行列の典型的な構造を示す。各エントリは、厳密な優先順位で格納される。新しいスレッドの挿入が達成され得る速度は、スキップリストの使用によって加速される。図１４に、典型的な保留待ち行列スキップリストを示す。

前述のように、スレッドは、ブロックされて、同期またはタイマイベントを待ち受けてもよい。スレッドの中には、排他的に同期イベントを待ち受けるものもあり、同様に、排他的にタイマイベントを待ち受けるものもある。その都度、スレッドは、単一の待ち行列にのみ存在することになる。各スレッドは、名目上、保留待ち行列とタイマ待ち行列の両方に関連付けられた、２組のポインタを含む。これらの場合、設けられるタイマ待ち行列および保留待ち行列のポインタは、それぞれ、スペアである。スキップリストは、これらのスペアポインタを利用することができる。すなわち、例えば、スレッドがタイマ待ち行列内に見当たらない場合、これらのポインタを再利用して、保留待ち行列内における可能な前方ジャンプが指示されてもよい。これは、通常は逐次のサーチが、新しい従属スレッドの正しい挿入点に反復的に接近しながら、スレッド記述子のブロックをジャンプすることを可能にする。

一代替方法が、スキップノード記述子であり、この一例を、関連付けられたフィールド（図９ｌ）と共に図９ｋに示す。スキップノード記述子は、事前定義されたメトリックに従って、保留およびタイマ待ち行列構造に周期的に挿入され得る。スキップノード記述子は、スキップノード記述子間の、または関与するスレッド記述子間の、定義された最大観測数のスレッド記述子に従って挿入される。スキップノード記述子は、保留待ち行列とタイマ待ち行列のスキップリストの一部を同時に形成することができる。

それぞれの新しい従属スレッドが、その優先度に従って挿入されなければならない。このプロセスでは、典型的に、始めに、新しいスレッドの優先度がスキップリストノードの優先度より高くなるまでスキップリストをトラバースする。その後、サーチは、そのスキップリストノードから、スレッド記述子ごとに、正しい挿入点が見つかるまで続けられる。これは、通常は線形のサーチが、新しい従属スレッドの正しい挿入点に向かって進むときに、保留スレッドのブロックをスキップすることを可能にする。

同期イベントには、以下の３つの異なる種類がある。
ユニキャスト：同期イベントは、指定された保留待ち行列で見つかった最初の（最高優先順位の）適切な従属スレッドで状態遷移をトリガする。
マルチキャスト：同期イベントは、指定された保留待ち行列内のすべての適切な従属スレッドで状態遷移をトリガする。
ブロードキャスト：同期イベントは、すべての保留待ち行列内のすべての適切な従属スレッドで状態遷移をトリガする。

保留待ち行列は、図９ｉおよび９ｊに示すように、保留待ち行列記述子によって定義される。保留待ち行列記述子は、システム初期設定時に一度構成され、単一のコントローラメモリ要素１９５を消費する。保留待ち行列は、従属スレッド記述子とスキップリストノードをだけを含む。

タイマ待ち行列構造
タイムアウトイベントを待ち受けるスレッド記述子を格納する単一システム規模のタイマ待ち行列が設けられる。図１５に、タイマ待ち行列の例示的実施形態を示す。

また、スキップリストは、前述のタイマ待ち行列構造へのスレッドの挿入を迅速化するためにも使用される。しかしながら、この場合、それは、スキップリストに使用される、時間的依存関係（もしあるとすれば）だけを有するスレッドである。

タイマ待ち行列記述子は、レジスタ内に格納され、同時比較が、タイマ待ち行列の先頭と現在時刻の間で進行することを可能にする。これは、タイマティックのメモリ帯域幅に対する影響を大幅に低減する。

作動可能待ち行列構造
作動可能待ち行列構造は、実行可能な状態のスレッドを保持する。これらのスレッドは、独立のスレッドプリミティブを用いて作成されたスレッドであり、または依存対象とする同期プリミティブを受け取っているスレッドである。同期スレッドは、あらかじめ保留待ち行列構造から移行している。

作動可能待ち行列構造は、スケジューラノード記述子と、独立の同期されたスレッド記述子を含むことができる。この構造は、システム初期設定時におおむね定義されるが、スレッド記述子および動的スケジューラ層記述子は、リアルタイムで出入りすることを許される。

作動可能待ち行列は、スレッドを特定の処理リソース１５０、または処理リソース１５０のプールに対してスケジュールすることができる。これは、特定のタスクを特定の処理リソース１５０、例えば、ハードウェアアクセラレータや入出力装置などに向けることができる状態を維持しつつ、複数の処理リソース１５０にまたがる負荷均衡化を可能にする。

図１６に、２つの処理リソース１５０での典型的な作動可能待ち行列構造を示す。動的スケジューラ層２は、両方のルートスケジューラ層から利用可能であることに留意されたい。これは、システム管理コントローラ１３０が、ルート層１および２と関連付けられた処理リソース１５０の間の動的な層２の下でスレッドを負荷均衡化することができるようにする。

スケジューラ層
スケジューラ層は、スレッド記述子をスケジュールするのに使用される階層を定義する。各スケジューラ層は、通常、スケジューリングアルゴリズム、スケジューリング決定を行うのに使用されるいくつかのメトリック、および別のスケジューラ層またはスレッド記述子とすることのできる子要素のリストを定義する。ルート、静的および動的の３種類のスケジューラ層記述子がある。スケジューラ層メモリ要素のフォーマットを図９ｅおよび９ｆに示す。

ルートスケジューラ記述子は、ディスパッチ待ち行列と１対１マッピングを有する。これらは、作動可能待ち行列構造における最終ノードを表す。スケジューラルート記述子は、システム初期設定時に構成され、永久に存在する。

静的スケジューラ記述子は、スケジューリング階層内のルートノードの下に存在する。静的スケジューラ記述子の親は、他の静的スケジューラ記述子とすることも、ルート記述子とすることもできる。静的スケジューラ記述子は、その親の定義するスケジューラアルゴリズムおよびそのスケジューラメトリックに従って、兄弟ノードと競合する。静的スケジューラ記述子は、システム初期設定時に構成され、永久に存在する。動作時に、システム管理コントローラ１３０は、選択されたスケジューリングアルゴリズム、例えば、ラウンドロビンスケジューリングなどに従ってスケジューラメトリックを維持する。

動的スケジューラ記述子は、スケジューリング階層内のルートおよび、おそらく、静的ノードの下に存在する。動的スケジューラ記述子の親は、静的スケジューラ記述子またはルート記述子とすることができる。動的スケジューラ記述子は、その親の定義するスケジューラアルゴリズムおよび独自のスケジューラメトリックに従って兄弟ノードと競合する。動的スケジューラ記述子は、いつでも構成することができ、特定の状況下において廃棄することができる。これは、システムが、純粋に静的な条件で可能なはずの数よりずっと多くのスケジューリング層をサポートすることを可能にする。システム管理コントローラ１３０は、多数の多様なスレッドおよび動的スケジューラ層が常に使用されるが、ある有限期間の間、一時要求がより小さいくなる可能性を利用することによってこれを実現する。例えば、最大４０００の動的要素（スレッドおよび動的スケジューラ記述子）をサポートするメモリが接続されたネットワークシステムでは、１６０００接続をサポートすることが可能であると考えられる。というのは、任意の瞬間に、コントローラには、全接続空間のほんの一部からのデータ単位だけがあるからである。この柔軟性は、性能をわずかに犠牲にして達成される。というのは、動的スケジューラ記述子が存在しない場合、それが子スレッド記述子の追加の前に作成されなければならないからである。

動作時に、システム管理コントローラ１３０は、選択されたスケジューリングアルゴリズムに従ってスケジューラメトリックを維持する。いくつかの状況下では、動的スケジューラ記述子は、コントローラメモリ要素１９５フリーリストに戻される。これは、動的スケジューラ層記述子にその層内で処理されるべき最後のスレッドからのｐＲｅｆｅｒｅｎｃｅを格納することによって達成される。コントローラ１３０ＡＰＩは、動的スケジューラ記述子が後続の類似のスレッドの間に持続するかどうか判定するために、コントローラメモリ要素１９５の問合せをサポートする。

ディスパッチ待ち行列
ディスパッチ待ち行列は、関連付けられた処理リソース１５０からのサービスを待ち受ける先入れ先出し（ＦＩＦＯ）待ち行列としてスケジュールされたスレッド記述子を保持する。現在の好ましい実施形態では、最大３２のディスパッチ待ち行列が許容される。ディスパッチ待ち行列は、図９ｇおよび９ｈに示すディスパッチ待ち行列記述子によって定義される。ディスパッチ待ち行列記述子は、システム初期設定時に構成される。

スレッド記述子を作動可能待ち行列構造からディスパッチ待ち行列構造に遷移させるプロセスは、ハードウェアとして実行され、コントローラ１３０ＡＰＩ対話を必要としない。

図１７に、本発明の特徴を実施する典型的な単一のディスパッチ待ち行列構造の例示的実施形態を示す。ディスパッチ待ち行列記述子は、フル閾値を定義する。ディスパッチ待ち行列長は、スレッドバンドルがスケジュールされている場合、または割り込みスレッドプッシュが行われた場合にのみフル閾値を上回ることを許される。

各要素は、処理リソースによってコントローラ１３０ＡＰＩを介して呼び出されるポップ操作によってディスパッチ待ち行列から除去される。

ディスパッチ待ち行列記述子には優先度フィールドが含まれる。ディスパッチ待ち行列からスレッドがポップされるときに、優先度フィールドに、現在実行中のスレッドの優先度が取り込まれる。別のＡＰＩ呼び出しが、優先度が実行中のプロセッサによって別の値にリセットされるようにして、優先度逆転を回避する。優先度逆転は、異なる優先度の少なくとも３つのスレッドが関与する、同期とスケジューリング要件の間の競合をいう。優先度逆転は、優先度の低いスレッドが、優先度の高いスレッドを無期限にブロックすることを可能にする。例えば、優先度の低いスレッドが共用リソースをロックし、次いで、より優先度の高いスレッドに取って代わられる。次いで、優先度の高いスレッドは、優先度の低いスレッドによってロックされているリソースでブロックする。今度は、優先度の高いスレッドがブロックされているため、通常は、ロックされているリソースから独立の、現在自由に実行できる第３の中間スレッドがなかった場合、優先度の低いスレッドが再開するはずである。優先度の低いスレッドは、決して共用リソースをロック解除する機会を得ることができず、したがって、優先度の高いスレッドは無期限にブロックされる。「優先度上限」プロトコルとは、スレッドが共用リソースを所有している間、それが指定された優先度で実行されることを意味する。これは、前述の優先度の「低い」スレッドが優先度の高いスレッドと共用されるリソースを所有している間、それが「高い」優先度を有することを保証する。

スレッドバンドルは、同じスケジューラ層を起源とするスレッド記述子のグループをいう。各スケジューラ記述子には、更新するよう求めるスケジューリング決定が強制される前に、作動可能待ち行列のその層からディスパッチ待ち行列に遷移され得るスレッドの数を定義するパラメータが存在する。この機能を利用すると共に、スケジューラ層のメンバが共通の属性を有するように構成することによって、処理リソース１５０に、通常観測されるはずのものより著しく高いキャッシュ局所性を呈するスレッドのブロックを提示することができ、その結果、キャッシュミスが低減され、システム性能が向上する。

図１８に、本発明の一実施形態による、スレッドバンドリングを含む２層のスケジューリング階層の例を示す。ルート層から最も遠い層である、子層は、ＦＩＦＯスケジューリングアルゴリズムを使う。ルート層スケジューラアルゴリズムは、ラウンドロビンとして構成される。この実施形態では、各ＦＩＦＯ待ち行列内の要素は、同じ待ち行列の他のメンバとの高レベルのキャッシュ局所性を呈する。

図１８（ａ）に、子層のスレッドバンドル限界が１に設定されているスケジューリング結果を示す。この結果は、完全にインターリーブされている。この方式は、各待ち行列に最小の待ち時間を提示するが、メモリ管理がほとんど考慮されない（すなわち、低いキャッシュ性能を呈する可能性が最も高い）。スケジュールされたスレッドごとにコンテキスト切換えが必要である。ルート層がキャッシュを使用する処理リソース１５０と関連付けられる場合、強制的なキャッシュミスがシステム性能に影響を及ぼす可能性がある。

図１８（ｂ）に、子層のスレッドバンドル限界が４に設定されているスケジューリング結果を示す。スケジューラはより粗い更新特性を呈し、それは、このスレッドバンドル限界によって設定された限界を有する同じ待ち行列からスケジュールされているスレッドのブロックとして現れる。このバースト性挙動は、状況によっては理想的ではないこともあるが、はるかに優れたキャッシュ性能を呈する。というのは、コンテキスト切換えを必要とされることが比較的まれだからである。結果として得られる効果は、きめ細かな手法の優れたプログラミングモデルを維持しつつ、粗いマルチスレッディングの優れたキャッシュ性能に匹敵するものである。

システムが外界と対話する場合には、スレッドバンドリングのバースト性が極めて有害になる可能性が高い。しかしながら、スレッドバンドリングは、ターゲット処理リソース１５０がキャッシュを使用する場合にだけ有益であり、したがって、外界と対話する専門処理リソース１５０、例えば入出力装置などは、キャッシュ技術を使用する可能性が低く、したがって、スレッドバンドリングを利用しない。

図１７に戻って、各要素は、処理リソース１５０によりコントローラ１３０ＡＰＩを介して呼び出されるポップ操作によってディスパッチ待ち行列から除去される。各要素は、優先使用の場合には、作動可能待ち行列にプッシュバックされてもよい。

ディスパッチ待ち行列記述子には、優先度上限プロトコルの実施を可能にする優先度フィールドが含まれ、共用データでの優先度逆転を防ぐ。各処理リソース１５０は、一意のディスパッチ待ち行列を有する。

スケジューリング
アプリケーションおよびシステムのスケジューリング要件は様々に異なり、実際には、実際の動作環境での試験後に初めて明らかになることもある。これに対応するために、システム管理コントローラ１３０は、使用されるスケジューリングポリシとスケジューリングアルゴリズムの両方に柔軟性を与え、これらは、マルチコアプロセッサ設計段階全体を通して変更、調整することができる。

スケジューリングポリシは、以下の３種類に分けられる。
１．連携スケジューラが現在実行中のタスクを利用して新しいタスクをスケジュールする前に処理リソース１５０を解放する。この種のシステムは、（例えば、処理リソース１５０にとってローカルのキャッシュが必要な命令を含まず、したがって、より低速の上位メモリから足りない命令をロードしなければならないなどの場合の）コールドキャッシュ効果の最小化、および固定機能ハードウェアアクセラレータと適合するが、より複雑な組み込みアプリケーションには適さないことがある。
２．静的アルゴリズム駆動型スケジューラが、より適格性の高いタスクを実行するために、現在実行中のタスクに取って代わることができる。事前定義されたスケジューリングパラメータおよびアルゴリズムによる最も適格なスレッドが、常に、これらのシステムにおける実行中のスレッドである。任意の所与のタスクの適格性は、システムが実行を開始する前に定められる。
３．動的アルゴリズム駆動型スケジューラが、実行時に適格性を再定義することができる。前述のように、現在実行中のプロセスは、依然として、適格性が最も高いものであるが、タスクが実行を開始した後で、適格性メトリックが変更されている可能性がある。

システム管理コントローラ１３０は、適切な構成およびターゲットアプリケーションとの実行時対話によって３つのスケジューリングポリシすべてを満足させる。

システム管理コントローラ１３０は、例えば、先入れ先出し待ち行列法、優先度待ち行列法または重み付き公平待ち行列法など、オペレーティングシステムおよび通信業界で見られる多くのスケジューリングアルゴリズムをサポートする。スケジューリングアルゴリズムを適切に選択すれば、特に、主観的品質メトリックが関与する場合には、明白な利点が呈示される。

スレッド記述子内では、システム管理コントローラ１３０内のスケジューリング挙動をサポートするために２つのスケジューラメトリックが設けられる。第１のメトリックは、あらゆる場合におけるスレッドの優先度を表し、保留待ち行列構造、優先度ベースのスケジューラおよびディスパッチ待ち行列構造内で使用される。必要な場合には、第２のメトリックを使って、個別スレッドとそのピアの間で選択が行われる。さらに、どちらかのメトリックを使って親記述子内のメトリックが更新されてもよい。スレッド記述子の第２のプリミティブ内に配置される値は、そのスケジューラ階層内で生じるスケジューリングの種類を反映しなければならない。

これら２つのスケジューラメトリックは、スケジューラ記述子とスレッド記述子の両方で使用される。しかしながら、スレッドメトリックは処理リソース１５０内で計算されるが、これはスケジューラ層には不可能である。したがって、スケジューラ層がそれ自体のメトリックを更新することができるようにするには、所与の層のスケジュールされたスレッドから十分なパラメータが渡されなければならない。各スケジューラ層ごとに、どのようにしてメトリックが子から親に伝播されるかを定義する１組の命令が定義される。

スケジューラ階層全体に多少注意すれば、アプリケーションシステムにおける洗練されたトラフィックおよびタスク管理機能を提供するための、スケジューラアルゴリズムの複雑な組み合わせを容易に作成することができる。

パラメータ継承例
図１９に、通信システムに一般的に見られる簡略化された待ち行列構造の例示的実施形態を示す。この構造は、入出力装置の出力待ち行列を表す。ＦＩＦＯ待ち行列を共用するすべてのスレッドが同じ接続上にあり、そのため、これは、接続ごとの待ち行列構造である。第２のスケジューリング層は、この例では重み付き公平待ち行列（ＷＦＱ）アルゴリズムを使用する。このアルゴリズムは、所与のタスクの完了時刻を、その長さと重み係数に基づいて計算する。次いで、最も早い完了時刻を有するパケットを選択する。ＷＦＱはスレッドが表すパケットの長さの知識を利用するものであるが、最初のＦＩＦＯ待ち行列は、この情報とは無関係である。この場合、アプリケーションプログラマは、パケットの長さが、各スレッドごとのスケジューラメトリックに存在するようにしなければならない。階層内の上位のスケジューラ層は、それら自体のスケジューリングアルゴリズムのためにこのパラメータを継承する。

ＷＦＱでは、以下の変数が必要とされる。
Ｐ 接続に割り振られるパイプ帯域幅の部分
Ｉ パケットの長さ
Ｂ 総パイプ帯域幅
ｃ 接続帯域幅
ｄ スケジューラ層デッドライン

接続帯域幅ｃを計算する式は以下の通りである。
Ｐ＊Ｂ＝ｃ
チャネルを帯域幅１に正規化した場合、ｐはｃに等しくなる。その場合、パケット処理の完了時刻ｔは次式で与えられる。
（１／ｐ）＊ｌ＝ｔ
その場合、必要なメトリック１／ｐとｌである。ｐは元々分数であるため、これらの値（１／ｐおよびｌ）は両方とも整数である。スケジュールされたパケットの長さは、スケジューラ階層を介して上方に渡され、その層のデッドラインを漸進的に更新する。各更新内で行われる計算は、詳細には、以下の通りである。
ｄ＝ｄ＋［（１／ｐ）＊ｌ］
式中、ｄおよび１／ｐ（重み）は、スケジューラ層記述子内に格納され、ｌはスケジュール更新の間に階層を介して渡される。この計算は、スケジューラマネージャ３３０内で実行される。

以上、本発明の具体的実施形態について説明したが、これは一例にすぎず、様々な変更が考えられることを理解すべきである。さらに、本発明は、それだけに限らないが、例えば、携帯電話機やインターネットプロトコル上の音声（ＶｏＩＰ）など、マルチコアプロセッサを用いる任意の装置またはアプリケーションにおける一般的な用途のものである。したがって、この具体的実施形態は、添付の特許請求の範囲によって決定されるべきである保護の範囲を限定するものとみなされるべきではない。

本発明の一実施形態によるリソース管理／タスク割り振りコントローラを組み込んだシステムの論理的レイアウトを示す概略的ブロック図である。 本発明を実施するコントローラが、専用メモリデバイスおよびコントローラクライアントと共に、汎用マルチコアプロセッサアーキテクチャ内に組み込まれている、図１の論理的レイアウトの１つの例示的実施を示す概略的ブロック図である。 図２の要素を組み込んだ最新のシステムオンチップ（ＳｏＣ）バスベースアーキテクチャの一例を、やはりブロック図として示す図である。 図１、２および３のコントローラへの外部接続をより詳細に示す図である。 図２および３のメモリデバイスをより詳細に示す図である。 図２、３および４のコントローラの内部構成をより詳細に示す図である。 図２および３に示すコントローラクライアントを示す概略的ブロック図である。 複数の処理リソースのプロキシとして働く単一のコントローラクライアントの場合のシステムを示す概略的ブロック図である。 ハードウェアコントローラクライアントをより詳細に示す概略的ブロック図である。 総称記述子を示す図である。 総称記述子に関連付けられるフィールドを示す図である。 スレッド記述子を示す図である。 スレッド記述子に関連付けられるフィールドを示す図である。 スケジューラ層記述子を示す図である。 スケジューラ層記述子に関連付けられるフィールドを示す図である。 ディスパッチ待ち行列記述子を示す図である。 ディスパッチ待ち行列記述子に関連付けられるフィールドを示す図である。 保留待ち行列記述子を示す図である。 保留待ち行列記述子に関連付けられるフィールドを示す図である スキップリスト記述子を示す図である。 スキップリスト記述子に関連付けられるフィールドを示す図である スレッド記述子と、システム管理コントローラと、処理リソースと、共用システムメモリの間の典型的な関係を示す図である。 ２つの異種の処理リソースが存在する、図１０の構成における間接化の原理を示す図である。 図４のコントローラ内のスレッド管理を示す典型的な全体図である。 典型的な保留待ち行列構造を示す図である。 典型的な保留待ち行列スキップリストを示す図である。 典型的なタイマ待ち行列を示す図である。 ２つの処理ソースでの典型的な作動可能待ち行列構造を示す図である。 典型的な単一ディスパッチ待ち行列構造の例示的実施形態を示す図である。 スレッドバンドリングを含む、２層スケジューリング階層を示す図である。 通信システムにおいて一般に見られる簡略化された待ち行列構造の一例を示す図である。

Claims (61)

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. 第２のコントローラクライアントを用いて、第１のコントローラクライアントの実行可能トランザクションを作成し、実行し、または削除するステップをさらに備える、請求項３９に記載の方法。
48. 事前定義されたスケジューリングパラメータセットに基づいて、前記実行可能トランザクションを前記プロセッサ要素の１つに割り振るステップをさらに備える、請求項３９〜４７のいずれか一項に記載の方法。
49. 前記スケジューリングパラメータセットがユーザ定義可能である、請求項４８に記載の方法。
50. 前記コントローラが使用するための前記スケジューリングパラメータのリストを監視するステップをさらに備える、請求項４８または４９に記載の方法。
51. 時間の経過につれて前記スケジューリングパラメータセットを変更するステップをさらに備える、請求項４８〜５０のいずれか一項に記載の方法。
52. 前記スケジューリングパラメータの前記リストを監視するステップが、前記プロセッサ要素の１つ以上によって実行され得る作動可能タスクのリストを維持する工程をさらに備える、請求項５０に記載の方法。
53. 前記マルチコアプロセッサ内のプロセッサリソースを均衡化するよう求める要件に基づいて、前記実行可能トランザクションを前記プロセッサ要素の１つに割り振るステップをさらに備える、請求項４８〜５１のいずれか一項に記載の方法。
54. 前記プロセッサ要素の１つにとって、より優先度の高いタスクを実行することが望ましいと判定されるときに、前記実行可能トランザクションのそのプロセッサ要素への前記割り振りを妨げるステップをさらに備える、請求項４８〜５１のいずれか一項に記載の方法。
55. 所定の長さの時間より長期間割り振られていない実行可能トランザクションのリストを維持するステップをさらに備える、請求項３９〜５４のいずれか一項に記載の方法。
56. 前記スケジューリングパラメータの前記リストを監視するステップが、所定のイベントを待ち受ける保留タスクのリストを維持する工程をさらに備える、請求項５０に記載の方法。
57. 前記所定のイベントがタイマイベント、同期イベントまたは両方である、請求項５６に記載の方法。
58. 相互に排他的な所定のイベントに従って、複数の保留タスクのリストを維持するステップをさらに備える、請求項５６に記載の方法。
59. 前記スケジューリングパラメータの前記リストを監視するステップが、個々の処理リソース上での実行を待ち受けるディスパッチタスクのリストを維持する工程をさらに備える、請求項５０に記載の方法。
60. タイムアウト時に、所定のイベントを待ち受ける実行可能トランザクションを作動可能待ち行列に移動させるステップをさらに備える、請求項５９に記載の方法。
61. 前記コントローラが、もっぱら、前記タスクの割り振り専用である、請求項３９〜６０のいずれか一項に記載の方法。

Images