(57)【特許請求の範囲】
【請求項１】
ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法であって、
第1の実行スレッドのコンテキストにおいて作成される第1のクライアントから第1の要求を出すステップと、
前記第1の要求をリソースに前記リソースのローカル代理を介して転送するステップであって、前記リソースは前記リソースを管理するプロセッサを備え、前記ローカル代理はクライアントとリソースとの間のインターフェースであり、前記リソースのローカル代理の状態は前記リソースの状態を反映する、前記転送するステップと、
前記リソースが非同期処理を許容するかどうかを決定することを前記第1のクライアントが許容することを前記リソースに知らせるデフォルト選好を前記第1のクライアントによって伝えるステップと、を含み、
前記非同期処理は、
前記リソースが非同期処理を許容することを決定した場合に、前記リソースによって前記第1の要求に確認応答し、非同期処理を開始するステップと、
前記リソースがフォークされたとマークして前記リソースがインコヒーレント状態にあることを示すステップであって、前記インコヒーレント状態は、前記リソースに対して出された要求がまだ応じられていないか、または応じられた場合には、前記リソースのローカル代理が新しい状態にまだ更新されていない状態である、前記示すステップと、
前記第1のクライアントが前記第1の実行スレッドにおける処理を続けることを許容する一方で、前記リソースにおいて前記第1の要求を処理するステップと、
前記リソースによって、前記第1の要求の前記処理の完了をシグナリングするステップであって、前記第1の要求の前記処理の前記完了は前記リソースをジョイン可能にすることを含み、前記ジョイン可能は、前記リソースが、前記第1の要求に応じ、新しい状態に移行し、前記新しい状態を前記リソースのローカル代理に示した状況を指す、前記シグナリングするステップと、を含み、
前記方法は、
前記リソースにおいて第2の要求を受信するステップと、
前記リソースがジョイン可能であるかどうかを判断し、
前記リソースがジョイン可能でないならば、前記リソースがジョイン可能になるのを待ち、
前記リソースがジョイン可能ならば、前記リソースが前記第2の要求に応じることが可能になるように、前記リソースのローカル代理を新しい状態に更新し、登録されたあらゆるコールバックを引き起こすステップと、
前記リソースにおいて前記第2の要求を処理するステップと
をさらに含む、方法。
【請求項２】
前記第2の要求は、前記第1のクライアントにおいて発生する、請求項1に記載の方法。
【請求項３】
前記第2の要求は、第2のクライアントにおいて発生する、請求項1に記載の方法。
【請求項４】
前記第1の要求は、リソースプロキシを介して前記リソースに転送される、請求項1に記載の方法。
【請求項５】
前記第2の要求は、前記リソースをコヒーレント状態に戻し、前記第2の要求を処理することを可能にし、前記コヒーレント状態は、前記リソースのローカル代理が新しい状態に更新され、前記リソースが新しい要求に応じることができる状態である、請求項1に記載の方法。
【請求項６】
前記第2の要求は、前記第1の実行スレッドのコンテキストにおいて作成されるクライアントから出される、請求項1に記載の方法。
【請求項７】
前記第2の要求は、第2の実行スレッドのコンテキストにおいて作成されるクライアントから出される、請求項1に記載の方法。
【請求項８】
ポータブルコンピューティングデバイスにおける並列リソース要求を管理するためのコンピュータシステムであって、
プロセッサを含み、前記プロセッサは、
第1の実行スレッドのコンテキストにおいて作成される第1のクライアントから第1の要求を出すステップと、
前記第1の要求をリソースに前記リソースのローカル代理を介して転送するステップであって、前記リソースは前記リソースを管理するプロセッサを備え、前記ローカル代理はクライアントとリソースとの間のインターフェースであり、前記リソースのローカル代理の状態は前記リソースの状態を反映する、前記転送するステップと、
前記リソースが非同期処理を許容するかどうかを決定することを前記第1のクライアントが許容することを前記リソースに知らせるデフォルト選好を前記第1のクライアントによって伝えるステップと、
前記リソースが非同期処理を許容することを決定した場合に、前記リソースによって前記第1の要求に確認応答し、非同期処理を開始するステップと
を行うように動作可能であり、
前記非同期処理は、
前記リソースがフォークされたとマークして前記リソースがインコヒーレント状態にあることを示すステップであって、前記インコヒーレント状態は、前記リソースに対して出された要求がまだ応じられていないか、または応じられた場合には、前記リソースのローカル代理が新しい状態にまだ更新されていない状態である、前記示すステップと、
前記第1のクライアントが前記第1の実行スレッドにおける処理を続けることを許容する一方で、前記リソースにおいて前記第1の要求を処理するステップと、
前記リソースによって、前記第1の要求の前記処理の完了をシグナリングするステップであって、前記第1の要求の前記処理の前記完了は前記リソースをジョイン可能にすることを含み、前記ジョイン可能は、前記リソースが、前記第1の要求に応じ、新しい状態に移行し、前記新しい状態を前記リソースのローカル代理に示した状況を指す、前記シグナリングするステップと、を含み、
前記プロセッサは、
前記リソースにおいて第2の要求を受信するステップと、
前記リソースがジョイン可能であるかどうかを判断し、
前記リソースがジョイン可能でないならば、前記リソースがジョイン可能になるのを待ち、
前記リソースがジョイン可能ならば、前記リソースが前記第2の要求に応じることが可能になるように、前記リソースのローカル代理を新しい状態に更新し、登録されたあらゆるコールバックを引き起こすステップと、
前記リソースにおいて前記第2の要求を処理するステップと
をさらに行うように動作可能である、システム。
【請求項９】
前記第2の要求は、前記第1のクライアントにおいて発生する、請求項8に記載のシステム。
【請求項１０】
前記第2の要求は、第2のクライアントにおいて発生する、請求項8に記載のシステム。
【請求項１１】
前記第1の要求は、リソースプロキシを介して前記リソースに転送される、請求項8に記載のシステム。
【請求項１２】
前記第2の要求は、前記リソースをコヒーレント状態に戻し、前記第2の要求を処理することを可能にし、前記コヒーレント状態は、前記リソースのローカル代理が新しい状態に更新され、前記リソースが新しい要求に応じることができる状態である、請求項8に記載のシステム。
【請求項１３】
前記第2の要求は、前記第1の実行スレッドのコンテキストにおいて作成されるクライアントから出される、請求項8に記載のシステム。
【請求項１４】
前記第2の要求は、第2の実行スレッドのコンテキストにおいて作成されるクライアントから出される、請求項8に記載のシステム。
【請求項１５】
ポータブルコンピューティングデバイスにおける並列リソース要求を管理するためのコンピュータシステムであって、
第1の実行スレッドのコンテキストにおいて作成される第1のクライアントから第1の要求を出す手段と、
前記第1の要求をリソースに前記リソースのローカル代理を介して転送する手段であって、前記リソースは前記リソースを管理するプロセッサを備え、前記ローカル代理はクライアントとリソースとの間のインターフェースであり、前記リソースのローカル代理の状態は前記リソースの状態を反映する、前記転送する手段と、
前記リソースが非同期処理を許容するかどうかを決定することを前記第1のクライアントが許容することを前記リソースに知らせるデフォルト選好を前記第1のクライアントによって伝える手段と、
前記リソースが非同期処理を許容することを決定した場合に、前記リソースによって前記第1の要求に確認応答し、非同期処理を開始する手段と
を含み、
前記非同期処理は、
前記リソースがフォークされたとマークして前記リソースがインコヒーレント状態にあることを示す手段であって、前記インコヒーレント状態は、前記リソースに対して出された要求がまだ応じられていないか、または応じられた場合には、前記リソースのローカル代理が新しい状態にまだ更新されていない状態である、前記示す手段と、
前記第1のクライアントが前記第1の実行スレッドにおける処理を続けることを許容する一方で、前記リソースにおいて前記第1の要求を処理する手段と、
前記リソースによって、前記第1の要求の前記処理の完了をシグナリングする手段であって、前記第1の要求の前記処理の前記完了は前記リソースをジョイン可能にすることを含み、前記ジョイン可能は、前記リソースが、前記第1の要求に応じ、新しい状態に移行し、前記新しい状態を前記リソースのローカル代理に示した状況を指す、前記シグナリングする手段と、によって実行され、
前記システムは、
前記リソースにおいて第2の要求を受信する手段と、
前記リソースがジョイン可能であるかどうかを判断し、
前記リソースがジョイン可能でないならば、前記リソースがジョイン可能になるのを待ち、
前記リソースがジョイン可能ならば、前記リソースが前記第2の要求に応じることが可能になるように、前記リソースのローカル代理を新しい状態に更新し、登録されたあらゆるコールバックを引き起こす手段と、
前記リソースにおいて前記第2の要求を処理する手段と
をさらに含む、システム。
【請求項１６】
前記第2の要求は、前記第1のクライアントにおいて発生する、請求項15に記載のシステム。
【請求項１７】
前記第2の要求は、第2のクライアントにおいて発生する、請求項15に記載のシステム。
【請求項１８】
前記第1の要求をリソースプロキシを介して前記リソースに転送する手段をさらに含む、請求項15に記載のシステム。
【請求項１９】
前記第2の要求は、前記リソースをコヒーレント状態に戻し、前記第2の要求を処理することを可能にし、前記コヒーレント状態は、前記リソースのローカル代理が新しい状態に更新され、前記リソースが新しい要求に応じることができる状態である、請求項15に記載のシステム。
【請求項２０】
前記第2の要求は、前記第1の実行スレッドのコンテキストにおいて作成されるクライアントから出される、請求項15に記載のシステム。
【請求項２１】
前記第2の要求は、第2の実行スレッドのコンテキストにおいて作成されるクライアントから出される、請求項15に記載のシステム。
【請求項２２】
コンピュータ可読プログラムコードを含むコンピュータプログラムであって、前記コンピュータ可読プログラムコードが、ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法を実施するために実行されるように適合され、前記方法は、
第1の実行スレッドのコンテキストにおいて作成される第1のクライアントから第1の要求を出すステップと、
前記第1の要求をリソースに前記リソースのローカル代理を介して転送するステップであって、前記リソースは前記リソースを管理するプロセッサを備え、前記ローカル代理はクライアントとリソースとの間のインターフェースであり、前記リソースのローカル代理の状態は前記リソースの状態を反映する、前記転送するステップと、
前記リソースが非同期処理を許容するかどうかを決定することを前記第1のクライアントが許容することを前記リソースに知らせるデフォルト選好を前記第1のクライアントによって伝えるステップと、
前記リソースが非同期処理を許容することを決定した場合に、前記リソースによって前記第1の要求に確認応答し、非同期処理を開始するステップと
を含み、
前記非同期処理は、
前記リソースがフォークされたとマークして前記リソースがインコヒーレント状態にあることを示すステップであって、前記インコヒーレント状態は、前記リソースに対して出された要求がまだ応じられていないか、または応じられた場合には、前記リソースのローカル代理が新しい状態にまだ更新されていない状態である、前記示すステップと、
前記第1のクライアントが前記第1の実行スレッドにおける処理を続けることを許容する一方で、前記リソースにおいて前記第1の要求を処理するステップと、
前記リソースによって、前記第1の要求の前記処理の完了をシグナリングするステップであって、前記第1の要求の前記処理の前記完了は前記リソースをジョイン可能にすることを含み、前記ジョイン可能は、前記リソースが、前記第1の要求に応じ、新しい状態に移行し、前記新しい状態を前記リソースのローカル代理に示した状況を指す、前記シグナリングするステップと、を含み、
前記方法は、
前記リソースにおいて第2の要求を受信するステップと、
前記リソースがジョイン可能であるかどうかを判断し、
前記リソースがジョイン可能でないならば、前記リソースがジョイン可能になるのを待ち、
前記リソースがジョイン可能ならば、前記リソースが前記第2の要求に応じることが可能になるように、前記リソースのローカル代理を新しい状態に更新し、登録されたあらゆるコールバックを引き起こすステップと、
前記リソースにおいて前記第2の要求を処理するステップと
をさらに含む、コンピュータプログラム。
【請求項２３】
前記第2の要求は、前記第1のクライアントにおいて発生する、請求項22に記載のコンピュータプログラム。
【請求項２４】
前記第2の要求は、第2のクライアントにおいて発生する、請求項22に記載のコンピュータプログラム。
【請求項２５】
前記第1の要求は、リソースプロキシを介して前記リソースに転送される、請求項22に記載のコンピュータプログラム。
【請求項２６】
前記第2の要求は、前記リソースをコヒーレント状態に戻し、前記第2の要求を処理することを可能にし、前記コヒーレント状態は、前記リソースのローカル代理が新しい状態に更新され、前記リソースが新しい要求に応じることができる状態である、請求項22に記載のコンピュータプログラム。
【請求項２７】
前記第2の要求は、前記第1の実行スレッドのコンテキストにおいて作成されるクライアントから出される、請求項22に記載のコンピュータプログラム。
【請求項２８】
前記第2の要求は、第2の実行スレッドのコンテキストにおいて作成されるクライアントから出される、請求項22に記載のコンピュータプログラム。
【発明の詳細な説明】
【背景技術】
【０００１】
ポータブルコンピューティングデバイス(「PCD」)は、ますます普及してきている。これらのデバイスは、セルラー電話、携帯情報端末(「PDA」)、ポータブルゲームコンソール、ポータブルナビゲーションユニット、パームトップコンピュータ、および他のポータブル電子デバイスを含み得る。
【０００２】
PCDは、様々な機能および特徴を提供するための様々なタイプのソフトウェアを実行することができる。たとえば、PCDは、ビデオを見ることやビデオゲームをすることなどの機能を提供し得るエンターテインメントソフトウェアを実行することができる。PCDはまた、ビジネスソフトウェアまたはライティングソフトウェア、たとえばスプレッドシート、電子メール、および/またはワード処理ソフトウェアなどの他のタイプのソフトウェアをサポートすることができる。
【０００３】
通常、PCD上で動作している上述のソフトウェアは、互いにリンクされた様々なハードウェア要素からのアクションを必要とする。ソフトウェア要素とハードウェア要素との間の対話は、リンクされたノード構造と考えられ得る全体的な動作フレームワークによって制御され得る。ある場合には、これらの要素間の対話は同期的に生じ、その場合に特定のリソースに対する要求により、要求が確認応答されて許可されるまで要素の動作は中断される。他の場合には、これらの要素間の対話は非同期的に生じ、その場合に特定のリソースに対する要求により、要求が処理される一方で要素の動作は中断されない。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、要求側要素にとっては、要求が処理される一方でリソースが動作を続けることを許容されるかどうかを判断することが可能であるのが望ましい。
【課題を解決するための手段】
【０００５】
ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムについて説明する。一実施形態では、本方法およびシステムは、第1のクライアントからの第1の要求を生成するステップであって、第1の要求は第1の実行スレッドのコンテキストにおいて出される、ステップを含む。第1の要求は、リソースに転送され得る。リソースは、第1の要求に確認応答し、非同期処理を開始する。リソースは、第1のクライアントが第1の実行スレッドにおける処理を続けることを許容する一方で、第1の要求を処理することができる。リソースは、第1の要求の処理の完了をシグナリングすることができ、第2の要求を受信することができる。第2の要求は、第1の要求の処理の完了をもたらす。第1の要求の処理の完了は、リソースのローカル代理を新しい状態に更新すること、および登録されたあらゆるコールバックを引き起こすことを含み得る。リソースは、第2の要求に応じることが可能になり、第2の要求を処理し得る。
【０００６】
図中、別段規定されていない限り、同様の参照番号は、様々な図の全体を通じて、同様の部分を指す。「102A」または「102B」のような文字指定を伴う参照番号について、文字指定は、同じ図に存在する2つの同様の部分または要素を区別し得る。参照番号の文字指定は、参照番号が、すべての図において同じ参照番号を有するすべての部分を包含することが意図される場合には、省略されることがある。
【図面の簡単な説明】
【０００７】
【図１】ポータブルコンピューティングデバイス(「PCD」)における並列リソース要求を管理するためのシステムの例示的な要素を示す機能ブロック図である。
【図２】ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムの例示的な動作環境を示す機能ブロック図である。
【図３】単一のリソース上で動作している同期スレッドを示す図である。
【図４】ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムの一実施形態の動作を示す図である。
【図５】ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムの一実施形態の動作を示すタイムライン図である。
【図６Ａ】ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムの一実施形態の動作を記述しているフローチャートを示す図である。
【図６Ｂ】ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムの一実施形態の動作を記述しているフローチャートを示す図である。
【図７Ａ】図1のポータブルコンピューティングデバイスのリソースを管理するノードアーキテクチャの第1の態様の図である。
【図７Ｂ】図1のポータブルコンピューティングデバイスのリソースを管理するノードアーキテクチャの第2の態様の一般的な図である。
【図７Ｃ】図1のポータブルコンピューティングデバイスのリソースを管理するノードアーキテクチャの第2の態様の具体的な図である。
【図７Ｄ】ポータブルコンピューティングデバイスのリソースを管理するためのノードアーキテクチャを作成するための方法を示すフローチャートである。
【図７Ｅ】ポータブルコンピューティングデバイスのリソースを管理するためのノードアーキテクチャを作成するための方法を示す図7Dの続きのフローチャートである。
【図８】ポータブルコンピューティングデバイスにおけるソフトウェアアーキテクチャにおけるノード構造データを受信するための図7Dのサブ方法またはルーチンを示すフローチャートである。
【図９】ポータブルコンピューティングデバイス向けのソフトウェアアーキテクチャにおけるノードを作成するための図7D〜図7Eのサブ方法またはルーチンを示すフローチャートである。
【図１０】ポータブルコンピューティングデバイスのソフトウェアアーキテクチャにおけるクライアントを作成するための図9のサブ方法またはルーチンを示すフローチャートである。
【図１１】ポータブルコンピューティングデバイス向けのソフトウェアアーキテクチャにおけるリソースに対するクライアント要求を作成するための方法を示すフローチャートである。
【発明を実施するための形態】
【０００８】
「例示的な」という言葉は、「一例、実例または例として」を意味するように本明細書で使用される。「例示的な」ものとして本明細書で説明する態様は、必ずしも他の態様よりも好ましい、または有利であると解釈されるわけではない。
【０００９】
本明細書では、「アプリケーション」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能コンテンツを有するファイルを含むこともある。加えて、本明細書で言及する「アプリケーション」は、開封される必要があり得るドキュメント、またはアクセスされる必要がある他のデータファイルなど、本質的に実行可能ではないファイルを含むこともある。
【００１０】
「コンテンツ」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能コンテンツを有するファイルを含むこともある。加えて、本明細書で言及する「コンテンツ」は、開封される必要があり得るドキュメント、またはアクセスされる必要がある他のデータファイルなど、本質的に実行可能ではないファイルを含むこともある。
【００１１】
本明細書で使用される場合、「構成要素」、「データベース」、「モジュール」、「システム」などの用語は、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、実行中のソフトウェアを問わず、コンピュータ関連のエンティティを指すことが意図されている。たとえば構成要素は、プロセッサ上で作動しているプロセス、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラムおよび/またはコンピュータであってよいが、これらであることに限定されない。例を挙げると、コンピューティングデバイス上で作動しているアプリケーションとコンピューティングデバイスの両方が構成要素であり得る。1つまたは複数の構成要素は、プロセスおよび/または実行スレッドの中に存在してよく、1つの構成要素を1つのコンピュータに局在化すること、および/または2つ以上のコンピュータに分散することが可能である。加えて、これらの構成要素は、様々なデータ構造を記憶している様々なコンピュータ可読媒体から実行することができる。各構成要素は、1つまたは複数のデータパケット(たとえば、信号を介してローカルシステム、分散システムにおける別の構成要素と相互作用するある構成要素からのデータ、および/または信号を介してインターネットなどのネットワーク上で他のシステムと相互作用するある構成要素からのデータ)を有する信号に従うなどしてローカルプロセスおよび/またはリモートプロセスを介して通信することができる。
【００１２】
本明細書では、「通信デバイス」、「ワイヤレスデバイス」、「ワイヤレス電話」、「ワイヤレス通信デバイス」、および「ワイヤレスハンドセット」という用語は交換可能に用いられる。第3世代(「3G」)および第4世代(「4G」)ワイヤレス技術が出現したことによって、利用可能な帯域が拡大されたので、より多くのワイヤレス機能を備えたより携帯が容易なコンピューティングデバイスが利用可能になっている。
【００１３】
本明細書では、「ポータブルコンピューティングデバイス」(「PCD」)という用語は、バッテリーなど限られた容量の電源で動作する任意のデバイスを説明するために使用される。何十年もの間バッテリー式PCDが使用されてきたが、第3世代(「3G」)および第4世代(「4G」)ワイヤレス技術の出現とともにもたらされた充電式バッテリーの技術的進歩は、複数の機能を有する多数のPCDを可能にした。したがって、PCDは、とりわけ、セルラー電話、衛星電話、ページャ、携帯情報端末(「PDA」)、スマートフォン、ナビゲーションデバイス、スマートブックまたはリーダー、メディアプレーヤ、上述のデバイスの組合せ、およびワイヤレス接続を有するラップトップコンピュータであり得る。
【００１４】
図1は、ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムを実施するための、ワイヤレス電話の形態のPCD100の、例示的で非限定的な態様の機能ブロック図である。図示のように、PCD100は、マルチコアである中央処理装置(「CPU」)110A、グラフィックスプロセッサ110B、およびアナログ信号プロセッサ126を有するオンチップシステム102を含む。これらのプロセッサ110A、110B、126は、当業者に知られているように、1つもしくは複数のシステムバスまたは別の相互接続アーキテクチャで互いに結合され得る。
【００１５】
当業者によって理解されるように、CPU110Aは、第0のコア222、第1のコア224、および第Nのコア226を含み得る。代替実施形態では、CPU110Aおよびグラフィックスプロセッサ110Bを使用する代わりに、当業者によって理解されるように1つまたは複数のデジタル信号プロセッサ(「DSP」)を用いることもできる。さらに、2つ以上のマルチコアプロセッサを使用することもできる。
【００１６】
PCD100は、プロセッサ110によって実行される内部チップバス(「ICB」)ドライバモジュール103を含み得る。当業者は、本開示から逸脱することなく、様々な部分に分割され、異なるプロセッサ110、126によって実行され得る1つまたは複数のソフトウェアモジュールを各ICBドライバモジュール103が含み得ることを認識されよう。
【００１７】
2つのタイプのICBドライバモジュール103、すなわち、上位層(「UL」)タイプ103A、および下位層(「LL」)タイプ103Bがあり得る。一般的に、UL ICBドライバタイプ103Aは通常、様々なアプリケーションモジュール105をサポートすることができる1つまたは複数のプロセッサ110、126によって実行される。LL ICBドライバタイプ103Bは通常、リソース電力マネージャ107と呼ばれる1つのハードウェア要素によって実行される。
【００１８】
LL ICBドライバ103Bを実行しているリソース電力マネージャ107は一般に、帯域幅値を適用し設定する役目を果たす。これらの帯域幅値は、リソース電力マネージャ107によって、図2に関連して以下で説明する1つまたは複数のバスおよび/またはスイッチファブリックに適用される。リソース電力マネージャ107は一般に、スイッチファブリックおよびバスのクロック速度ならびにスレーブのクロック速度を設定する役目を果たす。スレーブは一般に、アプリケーションプログラム105を実行しているマスタープロセッサ110からの要求をサポートするハードウェア構成要素である。
【００１９】
ICBドライバ103A、Bは、リソース電力マネージャ107との組合せで、同様のスイッチファブリック内および/または異なるスイッチファブリック間に存在し得るハードウェア構成要素についての実行時におけるマスタースレーブペアの動的な作成を可能にする。ICBドライバ103A、Bおよびリソース電力マネージャ107は、オンザフライまたはリアルタイムでスイッチファブリックおよびバスのための帯域幅を計算し調整することができる。
【００２０】
特定の態様では、本明細書で説明する方法ステップうちの1つまたは複数は、ICBドライバ103A、Bを含むメモリ112に記憶された実行可能命令およびパラメータによって実施され得る。ICBドライバ103A、Bを形成するこれらの命令は、CPU110A、アナログ信号プロセッサ126、およびリソース電力マネージャ107によって実行され得る。さらに、プロセッサ110A、126、リソース電力マネージャ107、メモリ112、メモリ112に記憶された命令、またはそれらの組合せは、本明細書で説明する方法ステップのうちの1つまたは複数を実行するための手段として機能し得る。
【００２１】
図1に示すように、ディスプレイコントローラ128およびタッチスクリーンコントローラ130が、マルチコアCPU110Aに結合される。オンチップシステム102の外部にあるタッチスクリーンディスプレイ132が、ディスプレイコントローラ128およびタッチスクリーンコントローラ130に結合される。
【００２２】
図1はまた、マルチコアCPU 110Aに結合された、ビデオコーダ/デコーダ(「コーデック」)134、たとえば位相反転線(「PAL」)エンコーダ、順次式カラーメモリ(「SECAM」)エンコーダ、全米テレビジョン方式委員会(「NTSC」)エンコーダ、または任意の他のタイプのビデオエンコーダ134を示している。ビデオ増幅器136が、ビデオエンコーダ134およびタッチスクリーンディスプレイ132に結合される。ビデオポート138がビデオ増幅器136に結合される。ユニバーサルシリアルバス(「USB」)コントローラ140がCPU110Aに結合される。また、USBポート142がUSBコントローラ140に結合される。加入者識別モジュール(SIM)カード146も、CPU110Aに結合され得る。さらに、図1に示すように、デジタルカメラ148がCPU110Aに結合され得る。例示的な態様では、デジタルカメラ148は、電荷結合デバイス(「CCD」)カメラまたは相補型金属酸化膜半導体(「CMOS」)カメラである。
【００２３】
図1にさらに示されるように、ステレオオーディオコーデック150が、アナログ信号プロセッサ126に結合され得る。さらに、オーディオ増幅器152が、ステレオオーディオコーデック150に結合され得る。例示的な態様では、第1のステレオスピーカー154および第2のステレオスピーカー156が、オーディオ増幅器152に結合される。図1は、マイクロフォン増幅器158もステレオオーディオコーデック150に結合され得ることを示している。加えて、マイクロフォン160が、マイクロフォン増幅器158に結合され得る。特定の態様では、周波数変調(「FM」)無線チューナー162がステレオオーディオコーデック150に結合され得る。また、FMアンテナ164がFM無線チューナー162に結合される。さらに、ステレオヘッドフォン166がステレオオーディオコーデック150に結合され得る。
【００２４】
図1は、図1は、高周波(「RF」)トランシーバ168がアナログ信号プロセッサ126に結合され得ることをさらに示している。RFスイッチ170が、RFトランシーバ168およびRFアンテナ172に結合され得る。図1に示すように、キーパッド174がアナログ信号プロセッサ126に結合され得る。また、マイクロフォンを備えたモノヘッドセット176が、アナログ信号プロセッサ126に結合され得る。さらに、バイブレータデバイス178が、アナログ信号プロセッサ126に結合され得る。図1は、たとえばバッテリーなどの電源180がオンチップシステム102に結合されることも示している。特定の態様では、電源180は、充電式DCバッテリー、または交流(「AC」)電源に接続されたAC-DC変換器から導出されたDC電源を含む。
【００２５】
図1に示されるように、タッチスクリーンディスプレイ132、ビデオポート138、USBポート142、カメラ148、第1のステレオスピーカー154、第2のステレオスピーカー156、マイクロフォン160、FMアンテナ164、ステレオヘッドフォン166、RFスイッチ170、RFアンテナ172、キーパッド174、モノヘッドセット176、バイブレータ178、および電源180は、オンチップシステム102の外部にある。
【００２６】
図2は、ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムの例示的な動作環境200を示す機能ブロック図である。動作環境200は、2つのプロセッサを含み、2つのプロセッサは、この例ではCPU110Aおよびリソース電力マネージャ107であり得る。1つのリソースは、この実施形態ではシステムバス207であってよく、リソース電力マネージャ107によって管理される。別のリソースは、この実施形態ではシステムバス207のためのリソースプロキシ207Aであってよく、CPU110A上に位置し、CPU110Aによって管理される。リソースプロキシは、リモートリソースのローカル代理と定義され、その状態はリモートリソースの状態を反映している。
【００２７】
別の実施形態では、リソースプロキシ207Aの代わりに、CPU110A上の機能のライブラリとして実装される、クライアントとリソースとの間のインターフェースとして働くフレームワークを使用し得る。そのようなフレームワークの例については、後述する。
【００２８】
上述のように、CPU110Aは、第0のコア222、第1のコア224および第Nのコア226を含む。ただし、CPU110Aは、CPU110Aが唯一のプロセッサとなる単一のコアプロセッサであってもよい。以下の説明では、CPU110Aは複数のコアを含むが、CPU110Aは単数のプロセッサと呼ばれる。同様に、リソース電力マネージャ107も1つまたは複数のコアを含み得る。
【００２９】
CPU110A上の各コアは、1つまたは複数のスレッドを実行することができる。スレッドは、プロセッサ上の実行の単位であり、所与のコア上で所与の時点において、ただ1つのスレッドがアクティブであり得る。1つまたは複数のスレッドのコンテキストにおいてクライアントが作成され、要求が出される。以下の説明では、クライアントおよびスレッドという用語は、互換的に使用される。クライアントが要求を出したとき、それは、アクティブなスレッドのコンテキストにおいて実行されているクライアントが要求を出したことを意味する。同様に、クライアントは、進む前に要求への応答を待つという意味で同期であると言われ、これは、クライアントが要求を出したスレッドが、応答が受信されるまで中断されることを意味する。単一のスレッドのコンテキストにおいて複数のクライアントが作成されてよいが、この説明の目的上、所与の時点で所与のスレッドにおいてただ1つのクライアントがアクティブであることに留意されたい。
【００３０】
図2に示す例では、第1のクライアント201および第2のクライアント202はそれぞれ、第0のコア222上で動作している。第3のクライアント204は、第1のコア224上で動作しているものとして示されており、第Nのクライアント206は、第Nのコア226上で動作しているものとして示されている。ただし、様々なコアへのクライアントの結合は任意であり、図2には単に説明のために示されている。CPU110Aが単一のコアプロセッサである一実施形態では、クライアントのすべてがCPU110A上で動作していることになる。さらに、以下の説明では、クライアントとCPU110A内の様々なコアとの間の有効な対話が、CPU110Aとそれぞれのクライアントとの間で直接生じるものとして説明されることもある。
【００３１】
CPU110Aが、リソースプロキシ207Aを介して点線211によってシステムバス207に結合されるものとして示される一方、システムバス207は、実線212を介してリソース電力マネージャ107に結合されるものとして示されている。この接続トポロジーは、リソース電力マネージャ107がシステムバス207を管理する一方、CPU110Aは、リソースプロキシ207Aを介してシステムバス207に論理的にアクセスできるが、システムバス207を積極的に管理してはいないことを示すものである。
【００３２】
リソースプロキシ207Aはまた、状況変数の状態を表すフラグ213を含むものとして示されている。状況変数は、所与の時点では真であることも真でないこともある、ある状況を表現または表示する。状況変数を、表現された状況が現在真であることを示すためにシグナリングすることがあり、その状況が真になるまで待ち続けることがある。この例では、フラグ213によって表現された状況変数は、バス207への所与の要求が応じられたかどうかを意味する。要求が応じられるとき、この状態を示すために状況変数がシグナリングされる(CV/S)(またはフラグ213が設定される)。そのときまで、状況変数はシグナリングされない(CV/NS)。フラグ213の動作については、以下でより詳細に説明する。
【００３３】
概して、ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムは、リソース、この例ではシステムバス207の要求を行っているクライアント201、202、204および206のうちのいずれか1つについての例を使用して説明される。CPU110Aは、システムバス207を積極的に管理してはいないので、CPU110Aはクライアント要求をリソースプロキシ207A経由で、システムバス207を管理するプロセッサに転送する。この例では、システムバス207を管理するプロセッサは、リソース電力マネージャ107である。したがって、線208によって示されるように、たとえばクライアント201からの要求がCPU110Aからリソース電力マネージャ107に送られる。要求が応じられるとき、参照番号209によって示されるように、返答が割込みの形態でリソース電力マネージャ107からCPU110Aに送られる。リソース電力マネージャ107からCPU110Aに送られる割込みは、CPU110A上の割込みサービスルーチン(ISR)によって対処される。ISRは、変数フラグ213の状況をシグナリングして、状態を「状況変数-シグナリングされていない」(CV/NS)から「状況変数-シグナリングされた」(CV/S)に変更する。割込みの影響については、以下でより詳細に説明する。
【００３４】
ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムの動作について、図3、図4、図5および図6を参照しながらさらに説明する。
【００３５】
図3は、プロセッサ、この例ではCPU110A上で動作しているクライアントを示す図である。216において、クライアントは動作しており、参照番号217によって示されるように、CPU110A上のリソースプロキシ207Aによってリソース電力マネージャ107に転送されるリソース要求を出す。要求は、リソース電力マネージャ107によって管理される任意のリソースに対するものであり得る。ポイント215において、クライアントがCPU110A上で動作することを中止する(または中断もしくはブロックされる)一方、参照番号218によって示されるように、リソース電力マネージャ107によって要求が処理される。リソース電力マネージャ107によって要求が処理されると、参照番号219によって示されるように、リソース電力マネージャ107からCPU110Aに確認応答が(たとえば、割込みの形態で)送られ、それにより、ポイント220において、参照番号221によって示されるように、クライアントはCPU110A上で動作することを再開する。そのような要求は同期要求と呼ばれ、その理由は、リソース電力マネージャ107によって要求が処理される一方で、CPU110A上で動作しているクライアントスレッド216が、ポイント215で中断し、確認応答219がCPU110Aによって受信されるポイント220まで再開しないことにある。しかしながら、クライアントにとって、要求が処理されるのを待っている時間に何らかの他の作業を実行するのが望ましい場合がある。クライアントがリソース電力マネージャ107からの確認応答を待つ必要がなく、単に動作し続けることができる場合もある。そのような要求は「ファイアーアンドフォーゲット」要求と呼ばれ得る。ファイアーアンドフォーゲット要求の例として、クライアントがリソースをオフにしている要求がある。クライアント(および拡大解釈して、クライアントが動作しているスレッド)は、続ける前にこのアクションが完了するまで待つ必要がない。そのような方法の例が、図4に記述されている。
【００３６】
図4は、ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムの一実施形態の動作を示す図である。図4では、CPU110Aにおいて第1のスレッド231が開始される。ポイント232において、このスレッドにおけるクライアントからの要求が、リソースプロキシ207AによってCPU110Aからリソース電力マネージャ107に転送される。一実施形態において、要求は、たとえば、システムバス207上の一定量の帯域幅を要求している第1のクライアント201からのものであり得る。たとえば、システムバス207は、100メガビット/秒(MB/s)の帯域幅で動作していることがあるが、クライアント201は、それが200MB/sで動作することを望んでいる。したがって、参照番号234によって示される要求は、第1のクライアント201がより高い帯域幅で動作できるようにシステムバス207上の追加の帯域幅を求める、システムバス207を管理するリソース電力マネージャ107への要求である。
【００３７】
ポイント232において、CPU110A上のリソースプロキシ207Aからリソース電力マネージャ107に要求が転送される。ただし、第1のクライアント201は、動作を続けるためにシステムバス207上の利用可能な帯域幅が増えるのを待つ必要がない(第1のクライアント201は、リソース電力マネージャ107がシステムバス207上で利用可能な帯域幅を増やすまで、より低い帯域幅で動作することができ、帯域幅が増えた時点で、第1のクライアント201は、より高い帯域幅の使用を自動的に開始する)ので、第1のクライアント201はこれを、CPU110A上のリソースプロキシ207Aに対し、選好を伝えることによって示すことができる。
【００３８】
選好は、第1のクライアント201によって指定でき、並列、または非同期の処理を許容するためにリソースをフォークすることができるかどうかを決定する。選好の例には、限定はしないが、ALLOWED、DISALLOWEDおよびDEFAULTがある。選好ALLOWEDおよびDISALLOWEDは、上述の並列処理を明示的に許容または拒否する。選好DEFAULTは、クライアントの行動に影響を与えない限り、リソースがフォークするかどうかを独自に決定することをクライアントが許容することをリソースに知らせる。たとえば、選好DEFAULTが指定された場合、リソースは、リソースをオフにするか、または以前求められた要求をキャンセルするすべての要求をフォークすることを選択し得る。リソースをオフにするか、または以前の要求をキャンセルする要求は通常、クライアントがそのような要求の後にリソースの状態に関心を持っていないことを示しており、リソースはこの要求をフォークして、クライアントに直ちに返信することができる。一方、要求が特定の値に関するもので、選好がDEFAULTであった場合、制御がクライアントに戻る前には(少なくとも)この特定の状態にリソースがあることをクライアントは期待し得るので、リソースはそのような要求をフォークすることができない。
【００３９】
CPU110A上のリソースプロキシ207Aは選好を使用して、リソース電力マネージャ107に要求を非同期的に転送し、それにより、要求が応じられる一方で、第1のクライアント201またはそれが動作しているスレッドが中断されないようになる。そのような場合、CPU110Aは引き続き、231で開始されたスレッドを実行することができ、参照番号237によって示されるように動作する。リソース要求がこのように出されたが、まだ応じられていないとき、または要求が出されて応じられたが、新しい状態がまだCPU110A上のリソースプロキシ207Aによって確認応答されていないか、またはクライアントにとって可視ではない(すなわち、クライアントがリソースの状態を問い合わせた場合、クライアントは依然として古い状態を「見る」ことになる)とき、要求およびリソースは「フォークされる」とマークされる。「フォークされる」という用語は、リソースに対する最後の要求が出されたが、まだ応じられていないか、または応じられた場合には、リソースプロキシ207Aによって維持されているリソースのローカル代理が新しい状態にまだ更新されていないという意味で、リソースがインコヒーレント状態にある状況を指す。リソースプロキシ207Aは、要求が実際に応じられた後に引き起こされるコールバックを登録することもできる。このコールバックでは、リソースプロキシ207Aは、リソースが新しい(要求された)状態にあることに依存する他のアクションを実行することを選択することができる。たとえば、システムバス207の帯域幅が増加した後、クロックリソース(図示せず)が新しい値に設定されるべき場合がある。そのような場合、リソースプロキシ207Aは、コールバックでクロックリソース(図示せず)に要求を出し、それにより、システムバス207への要求が応じられた後にのみ、クロックリソース(図示せず)への要求が実行されるようにする。それと同時に、リソース電力マネージャ107は、参照番号235によって示されるように要求を処理し、参照番号236によって示されるようにCPU110Aに確認応答を送る。確認応答236は、(図2に示す)接続209を介して伝えられた割込みに対応する。CPU110A上のこの割込みに対処する/応じる割込みサービスルーチン(ISR)は、フラグ213に関連する状況
変数を、「シグナリングされた」ステータス、すなわちCV/Sに設定する。このアクションは、対象リソースが今や「ジョイン可能」であることを示している。「ジョイン可能」という用語は、リソース、たとえばシステムバス207が要求に応じており、新しい状態に移行しており、この新しい状態を要求側プロセッサ上のリソースプロキシ207Aに示している状況を指す。システムバス207の後続要求がCPU110A上のクライアント201、202、204および206のうちの1つによって出されたとき、リソースが「ジョインされる」。「ジョインされる」という用語は、リソースプロキシ207Aがリソース(この例では、システムバス207)のローカル代理を新しい状態に更新し、それによりリソースをコヒーレントにし、新しい要求に応じることができるようにするアクションを指す。リソースプロキシ207Aは、上述のようにフォークで登録したコールバックも実行する。次いで、リソースプロキシ207Aは新しい要求に対処する。
【００４０】
図4にさらに示すように、参照番号241で示されるスレッドで実行されている第2のクライアント、または新しいスレッドで実行されている同じクライアント201は、ポイント242において、システムバス207への新しい要求を行う。そのため、ポイント242において、リソース(この例では、システムバス207およびそのローカルリソースプロキシ207A)は「ジョインされる」が、これは、フラグ213に関連する状況変数が設定され(CV/S)、上述のようにリソースを「ジョイン可能」とマークするので可能である。ポイント242において、第2の要求がリソースプロキシ207Aに到着したときに、システムバス207がまだ「ジョイン可能」ではない場合、要求および要求が実行されているスレッドは、リソース電力マネージャ107からの割込みがリソースを「ジョイン可能」とマークするまでブロックされる。次いで、この新しいスレッドにおける処理は、参照番号244によって示されるように続く。
【００４１】
図5は、ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムの一実施形態の動作を示すタイムライン図である。時間t0において、CPU110A上で動作している第1のクライアント201は、参照番号251を使用して示されているような作業を開始する。時間t1において、第1のクライアント201は、参照番号252で示されるように、ローカルリソースプロキシ207Aを介して、システムバス207などのリモートリソースに対する要求を出す。要求は、ローカルリソースプロキシ207Aにおいて受信され、参照番号254を使用して示されているようにCPU110A上で実行されることを開始する。時間t2において、リソースプロキシ207Aは、参照番号255を使用して示されているように、第2のプロセッサ(リソース電力マネージャ107)に要求を転送する。要求がリソース電力マネージャ107によって受信されたとき、リソース電力マネージャ107は、参照番号256を使用して示されているように要求を実行および処理することを開始する。ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムの一実施形態によれば、第1のクライアント201が要求を「フォークすること」を許容していると仮定すると、時間t3において、リソースプロキシ207Aは、要求を非同期的に(すなわち、リモートプロセッサ(リソース電力マネージャ107)に要求を出すが、要求が応じられ確認応答されるまで待たずに)処理し、参照番号257を使用して示されているように、第1のクライアント201に返信する。第1のクライアント201はここで、参照番号260を使用して示されているように作業を続ける。タイムラインに示すように、260で示す期間中に第1のクライアント201によって実行される作業は、256によって示される期間中にリソース電力マネージャ107によって実行される作業と並列に生じる。要求がリソースプロキシ207Aによって第1のクライアント201に返信されるポイント258を、「フォーク」ポイントと呼ぶ。フォークポイントは、ポイント258において、リソース電力マネージャ107とクライアント201とで同時に並列処理できるように、リソースまたは要求がフォークすることを示している。
【００４２】
時間t4において、参照番号266を使用して示されているように、第2のスレッドへのコンテキスト切替えが生じる。時間t5において、リソース電力マネージャ107は、参照番号261を使用して示されているように、CPU110A上のリソースプロキシ207Aに割込みを送る。CPU110Aにおけるこの割込みに対処する割込みサービスルーチン(ISR)は、参照番号264を使用して示されているように、状況変数フラグ213(図2)を「シグナリングされた」(CV/S)ステータスに設定する。ポイント265において、システムバス207は「ジョイン可能」と考えられ、後続要求を処理できる。
【００４３】
時間t7において、CPU110A上の第2のスレッドで実行されている第2のクライアント202は、参照番号268を使用して示されているように、リソースプロキシ207Aを介してシステムバス207に要求を出す。要求268は、システムバス207から見て「後続」要求と考えられ得る。後続要求が受信されたとき、リソースプロキシ207Aは、システムバス207がジョイン可能状態にあり、「ジョインされ」得ることをチェックし、判断する。ポイント270において、システムバス207は第2のスレッドのコンテキストにおいてジョインされる。これは、システムバス207がポイント265において「ジョイン可能」と考えられるが、第2のクライアント202からの第2のスレッドにおける後続要求268を処理するために、ポイント270において「ジョインされる」ことを意味する。リソース(この例では、システムバス207)はこのようにして、3つの状態、すなわち、フォークされる、ジョイン可能、およびジョインされるのうちの1つの状態にあり得る。リソースがフォークされるポイントから、リソースはインコヒーレント状態にあると考えられ、これは、要求が受信されたが、まだ処理されていないか、または処理された場合には、リソースのローカル代理がまだ実際の(新しい)状態に更新されていないことを意味する。そのような状態では、リソースは後続要求を処理することができない。したがって、リソースは、後続要求268を処理できるようになる前に、270において「ジョインされる」、すなわち、コヒーレントにされる。271に示す期間は、第2のクライアント202からの後続要求268がリソースプロキシ207Aによって処理される時間を示している。この要求が「フォーク」し、上述のシーケンスを繰り返すこともできることに留意されたい。
【００４４】
指摘すべきこととして、後続要求は異なるクライアントから来る必要はなく、一実施形態では、後続要求の形式で第1のクライアント201から来ることもある。重要なことには、システムバス207のどのクライアントも、時間t7において後続要求を開始し、その結果、「ジョインする」ことができる。第1のクライアント201のコンテキストにおいて(また、この実施形態では、異なるスレッドで)出された以前の要求は、上述したようにCPU110A上の任意のスレッド上の任意のクライアントから来ることがある後続要求の処理中に、このようにして(ローカルリソース代理(リソースプロキシ207A)を新しい状態に更新し、それにより、リソース(システムバス207)を再びコヒーレントにするという意味で)「完了」する。これは、追加の管理なしに生じ、システムバス207への要求により、ポイント270において、リソースは対応可能性およびアクションを回復することができる。
【００４５】
図6Aおよび図6Bは、ポータブルコンピューティングデバイスにおける並列リソース要求を管理するための方法およびシステムの一実施形態の動作を記述しているフローチャートをまとめて示している。ブロック603において、リソースに対する要求が受信される。上記の例では、要求はリソースプロキシ207Aによって受信される。ただし、要求は別のエンティティによって受信されることがある。この実施形態では、第1のクライアント201が、リソース電力マネージャ107などのリモートプロセッサによって管理されるシステムバス207に対する要求を行う。記述した例では、要求はCPU110A上のローカルリソースプロキシ207Aを介して行われる。
【００４６】
ブロック604において、要求を出した第1のクライアント201が、この要求が同期的に完了することを望んでいるのか、それとも第1のクライアント201が、リソースプロキシ207Aがこの要求を「フォーク」し、第1のクライアント201に直ちに返信することを許容しているのかが判断される。第1のクライアント201がフォークすることを拒否していて、リソース要求が同期的に完了することを望んでいる場合、ブロック606において、リソースプロキシ207Aは要求をリソース電力マネージャ107に転送し、処理スレッドをブロックし、リソース電力マネージャ107が要求に応じるまで待つ。
【００４７】
ブロック608において、第1のクライアント201が、要求をフォークすることを許容している場合、リソースプロキシ207Aは要求をリソース電力マネージャ107に転送し、要求が応じられるのを待つことなく、クライアントに直ちに返信する。
【００４８】
ブロック612において、制御が第1のクライアント201に戻り、要求がまだリソース電力マネージャ107によって応じられていないにもかかわらず、スレッドは引き続き動作する。リソースは、フォークされるとマークされ、リソースは、後続要求に応じる前にジョインされる必要がある。
【００４９】
ブロック614において、リソース電力マネージャ107は、要求の処理を完了させ、これを示す割込みをCPU110Aに送る。この割込みに対処するCPU110A上の割込みサービスルーチン(ISR)は、状況変数をシグナリングし、フラグ213を(CV/S)に設定して、リソースを「ジョイン可能」状態に設定する。ブロック614で記述したステップは、図示のように直列に、並列に、またはブロック612で記述したステップの後で、ブロック618で記述したステップの前の任意の時間に生じ得る。
【００５０】
ブロック618において、後続要求が開始される。後続要求は、同じスレッドにおいて、または第2のスレッドにおいて開始され得る。さらに、後続要求は、同じクライアントによって、または異なるクライアントによって開始され得る。この例では、後続要求は異なるクライアント、すなわち第2のクライアント202によって、異なるスレッドにおいて開始される。
【００５１】
別の実施形態では、後続要求は、第1の要求として同じスレッドから開始され得る。最初のスレッドにおける処理は第1の要求によってブロックされていないので、最初のスレッドは他の作業をし、次いでリソースに後続要求を行うことができる。たとえば、スレッドは、ローカルリソースプロキシによってフォークされる、リモートリソースをオフにする要求を出すことができる。一定時間の経過後、スレッド(またはより具体的には、スレッドにおけるクライアント)はリソースをオンにすることを望むことがある。そのような場合、後続要求は同じスレッドで開始される。
【００５２】
ブロック620において、後続要求がリソースプロキシ207Aにおいて受信される。
【００５３】
ブロック624において、リソース(システムバス207)がジョイン可能であるかどうかが判断される。ブロック624において、リソースがジョイン可能ではないと判断された場合、プロセスはブロック626に進み、ブロック626において、リソースがジョイン可能になるまでスレッドは待つ。ブロック624において、リソースがジョイン可能であると判断された場合、またはブロック626において、リソースがジョイン可能になった後、プロセスはブロック628に進み、ブロック628において、リソースは「ジョインされ」、リソースプロキシ207Aは、以前のフォークされた要求からの保留中の処理を完了させ、リソースのローカル代理を新しい状態に更新する。このようにして、リソースは「ジョインされた」状態に移行する。リソースはここで、第2の要求の処理を開始する。
【００５４】
「フォークされた」または「ジョイン可能」状態にあるリソースに後続要求が到着したときに結果として起こる暗示的ジョインに代わるものは、「明示的ジョイン」として知られている。上述のように、フォークされたリソースは、リソースへの後続要求がリソースプロキシ(またはフレームワーク)に到着したときはいつでも暗示的にジョインされる。ただし、クライアントが後続要求を出さずにリソースを明示的にジョインすることを望む場合があり得る。そのような場合、フォークされたリソースをジョインし、コヒーレントにすることができる手段は、「明示的ジョイン」と呼ばれる。そのような明示的ジョイン動作は、状況変数がシグナリングされるのを待ち、ローカルリソース代理を更新して、新しいリソース状態を反映し、クライアントに返信する。クライアントは、この発呼が戻るまで中断される。
【００５５】
リモートリソースへの「フォークされた」要求に代わるものは、フォークされた「ローカル」リソース/要求である。上記の例では、要求はリモートで応じられ、クライアント(または発呼側)は、その要求が応じられる一方で、要求側プロセッサ上で他の動作を実行すること、または場合によっては他のクライアントまたは他のスレッドが他の動作を実行するのを認めることを望むと仮定される。これは常に当てはまるとは限らない。要求がCPU110A上の別のスレッドによって応じられるシナリオを考える。そのような場合、クライアントはこのリソースに、(オペレーティングシステムによってスケジュールされるときはいつでも)他のスレッドによってピックアップされ、応じられ、発呼側スレッドに確認応答が返信される要求を出す。リモートプロセッサをこの要求処理スレッドに置き換えることによって、上記の方法およびシステムをこのシナリオに適用することは可能である。
【００５６】
「ジョイン」に代わるものは、「熱望ジョイン(eager join)」状態と呼ばれる。上記で説明した実施形態では、フォークされたリソースは、後続要求がリソース(またはそのプロキシ)に到着したときには暗示的に、クライアントがジョインを要求したときには明示的にジョインされる。別の実施形態では、後続要求、または明示的ジョインにかかわりなく、「ジョイン可能」リソースをジョインするという明示的な目的で作成された複数のワーカースレッドがあり得る。そのようなシナリオでは、リモートプロセッサから完了の通知を受信するISRは、状況変数をシグナリングしてリソースを「ジョイン可能」とマークするだけではなく、ジョインアクション(ジョインコールバック)を作業項目として待ち行列に置く。待ち行列で待っているワーカースレッドは、この作業項目を見て、それをピックアップし、それをワーカースレッドのコンテキストにおいて実行して、ジョインアクションが実行され、できるだけ早くリソースが「ジョインされた」状態に設定されるようにする。
【００５７】
上述のように、代替実施形態では、クライアントとリソースとの間のインターフェースは、リソースプロキシではなくフレームワークであり得る。そのようなフレームワークの設計および構造について、以下で説明する。
【００５８】
以下で説明する図7A〜図10は、図2のノードアーキテクチャがどのように確立され維持されるかを説明するために提供される。図7Aは、図2に示すノードアーキテクチャを確立し維持するためのソフトウェアアーキテクチャ500Aの第1の態様の図である。
【００５９】
図7Aは、ソフトウェアまたはハードウェア(または両方)を表す機能ブロックを含む図である。図7Aは、限定はしないが以下のような複数のハードウェア要素およびソフトウェア要素に結合されたアーキテクチャまたはフレームワーク管理プログラム440を示している。ICBドライバモジュール103、一般に第1のハードウェア要素(ハードウェア要素#1)とも呼ばれる中央処理装置110、一般に第2のハードウェア要素(ハードウェア要素#2)とも呼ばれるCPU110のクロック442、一般に第3のハードウェア要素(ハードウェア要素#3)とも呼ばれるバスアービタまたはスケジューラ422、一般に第1のソフトウェア要素(ソフトウェア要素#1)とも呼ばれるバスプログラムA-444A、一般に第2のソフトウェア要素(ソフトウェア要素#2)とも呼ばれるバスプログラムB-444B、一般に第3のソフトウェア要素(ソフトウェア要素#3)とも呼ばれるクロックプログラムAHB、一般にキープレスとして示されるソフトウェア要素によって監視されるアクションまたは機能448、およびソフトウェア要素またはハードウェア要素または両方を含むレガシー要素450。
【００６０】
レガシーソフトウェア要素の一例には、限定はしないが、Dynamic Environment Manager(DEM)がある。これは、プロセッサスリープイベントのプロセッサ間通知を処理するソフトウェアモジュールである。たとえば、第1のプロセッサAはDEMを使用して、第2のプロセッサBがアイドル状態になった/アイドル状態から復帰したとの通知を受信する。より新しいハードウェアでは、このソフトウェア機能は、ルートプロセッサモジュール(RPM)サブシステム/通信プロトコルに組み込まれている。他のレガシーソフトウェア要素も存在し、本発明の範囲内に含まれる。
【００６１】
レガシーハードウェア要素の一例には、限定はしないがAMBA(Advanced Microcontroller Bus Architecture)のAdvanced High-performance Bus(AHB)がある。より古いPCD100では、AHBは一次システムバスを含み得るのに対し、より新しいPCD100では、システムバス構造(system bus fabric)107は完全に異なり、AHBバスは、新しいシステムバス構造を介して通信するように更新されてはいないモジュールと通信する特別なアプリケーションにのみ使用される。他のレガシーハードウェア要素も存在し、本発明の範囲内に含まれる。
【００６２】
フレームワーク管理プログラム440は、前述のハードウェア要素およびソフトウェア要素の各々と通信するノードのようなデータ構造を管理するコンピュータ命令のライブラリを含むことができる。フレームワーク管理プログラム440は、図7Aの破線Aの右側に示されているノード602、622、642、および646を形成し得る1つまたは複数のリソースの作成を担当することができる。
【００６３】
フレームワーク管理プログラム440は、CPU110上に常駐する各ICBドライバモジュール103と直接通信することができる。図7Aの右側にある各ノード602、622、642、および646は、図7Aの破線Aの左側にある各ソフトウェア要素またはハードウェア要素の代表またはモデルである。本開示の残りについては、一般的なノードまたは不特定のノードが、図7Bに示す参照番号601により指定される。
【００６４】
すでに述べたように、図7Aの例示的な各ノード602、622、642、および646は、1つまたは複数のリソースを含むことができる。リソースは、ソフトウェア要素またはハードウェア要素または両方を含むことができる。たとえば、第1のノード602は、第1のハードウェア要素または中央処理装置110に概ね対応する単一のリソースを含む。本開示で説明するソフトウェアアーキテクチャでは、ノード601の各リソースは、1つまたは複数の英数字文字を含む一意の名前を与えられ得る。図7Aに示す例示的な実施形態では、第1のノード602のリソースは、「core/cpu」というリソース名を割り当てられている。この例示的なリソース名は、当業者に知られている従来型のファイル命名構造に概ね対応する。ただし、当業者が認識するように、英数字文字および/または記号の任意の他の組合せを含む他のタイプのリソース名も、本発明の範囲内に十分に入る。
【００６５】
図7Aの例示的な実施形態では、第2のノード622は複数のリソースを含む。詳細には、この特定の例示的な実施形態では、第2のノード622は、バスアービタまたはスケジューラ422に対応する単一のハードウェア要素を含む第1のリソースを有する。第2のノード622の第2のリソースは、バスプログラムA 444Aの第1のソフトウェア要素に概ね対応するソフトウェア要素を含む。第2のノード622の第3のリソースは、バスプログラムB 444Bの第2のソフトウェア要素に概ね対応する別のソフトウェア要素を含む。当業者は、所与のノード601に関するリソースおよびリソースタイプの任意の組合せおよび任意の数が本発明の範囲内に十分に入ることを認識する。
【００６６】
ノード601を作成することに加えて、フレームワーク管理プログラム440はマーカー650を作成またはインスタンス化することもできる。マーカーは、ハードウェア要素またはソフトウェア要素(またはこれらの要素の両方および複数のこれらの要素)などの1つまたは複数のレガシー要素を含むことができ、それらの要素は、それら自体を容易にはマップしないか、またはフレームワーク管理プログラム440によって管理されるソフトウェアアーキテクチャに容易には適合しない。マーカー650は、ノード601のリソースをサポートすることができ、これは、ノード601のリソースがマーカー650に従属し得ることを意味する。マーカー650の一例として、ストリングドライバがあり得る。ストリングドライバは、図7Aに関連して説明したアーキテクチャに容易には嵌合しないことがある。マーカー650は、ノード601および図8のブロック1125で収集されたその従属性配列データによって参照され得る。
【００６７】
図7Aはまた、2つのソフトウェア要素448、450のアクションまたは機能に概ね対応する第1のクライアント648を示している。図7Aに示す例示的な実施形態では、第1のクライアント648は、ポータブルコンピューティングデバイス100によってサポートされる特定のアプリケーションプログラムモジュール105内で生じ得るキープレスアクションに概ね対応する。ただし、キープレス以外のソフトウェア要素の他のアクションおよび/または機能が本発明の範囲内に十分に入ることを、当業者は認識する。クライアント要求648およびそれらのそれぞれの作成については、図10に関連して以下でさらに詳しく説明する。
【００６８】
図7Aはまた、特定のアーキテクチャの要素間の関係を示している。たとえば、図7Aは、クライアント648と第1のノード602との間の関係を示している。詳細には、第1のクライアント648は、破線で示されているクライアント要求675Aを生成することができ、この要求は、リソース「/core/cpu」を含む第1のノード602によって管理または処理される。一般に、所定のまたは決められた数のタイプのクライアント要求675がある。クライアント要求675については、図10に関連して以下でさらに詳しく説明する。
【００６９】
図7Aに表示されている他の関係は、破線で示されている従属性680を含む。従属性は、別のノード601のそれぞれのリソースの間の関係である。従属関係は通常、第1のリソース(A)に情報を提供し得る第2のリソース(B)に第1のリソース(A)が依存していることを示す。この情報は、第2のリソース(B)によって実行された動作の結果である場合、またはそれは、第1のリソース(A)が必要とするステータス情報を含むにすぎない場合、またはそれらの任意の組合せである場合がある。第1のリソース(A)および第2のリソース(B)は、同じノード601の一部である場合、または異なるノード601の一部である場合がある。
【００７０】
図7Aでは、第1のノード602で始まり、第2のノード622まで延びている従属性矢印680Bによって示されるように、第1のノード602は第2のノード622に従属している。図7Aはまた、従属性矢印680Aによって示されるように、第1のノード602が第3のノード642にも従属していることを示している。図7Aはまた、従属性矢印680Cによって示されるように、第2のノード622が第4のノード646に従属していることを示している。当業者は、図7Aの破線矢印で示されている従属性680が本質的に例にすぎないこと、およびそれぞれのノード601間の従属性の他の組合せが本発明の範囲内にあることを認識する。
【００７１】
アーキテクチャまたはフレームワーク管理プログラム440は、限定はしないが、図7Aに示すクライアント要求675、および従属性680を含む上述の関係を維持することを担当する。フレームワーク管理プログラム440は、所与のノード601の従属性680が完全である限り、できるだけ多くのノード601をインスタンス化または作成することを試みる。従属性をサポートするリソースが、存在するか、従属性680に関係する情報を処理する準備ができた状態にあるときに、従属性680は完全である。
【００７２】
たとえば、第1のノード602と第3のノード642との間に存在する従属関係680Aを理由に、単一のリソース「/clk/cpu」を含む第3のノード642が作成されていない場合には、単一のリソース「/core/cpu」を含む第1のノード602がフレームワーク管理プログラム440によって作成または確立され得ない。第3のノード642がフレームワーク管理プログラム440によって作成されると、従属関係680Aを理由に、フレームワーク管理プログラム440は第1のノード602を作成することができる。
【００７３】
従属性680のうちの1つまたは複数が不完全であることから、フレームワーク管理プログラム440が特定のノード601を作成またはインスタンス化することができない場合、フレームワーク管理プログラム440は、フレームワーク管理プログラム440によってうまく作成されたノード601に対応するステップを引き続き実行する。フレームワーク管理プログラム440は通常、従属リソースが作成されていない不完全な従属性のために存在し得ない特定のノード601に対するコールを飛ばし、不完全なステータスを反映する当該コールに対するメッセージを返信する。
【００７４】
図1に示すようなマルチコア環境では、フレームワーク管理プログラム440は、図1の第0のコア222、第1のコア224、および第Nのコア226のような別個のコアでノード601を作成またはインスタンス化することができる。ノード601は一般に、ノード601が互いに従属していない限り、かつ後述するように特定のノードの対応する従属性のすべてが完全である場合に、マルチコア環境において別個のコアで並行して作成され得る。
【００７５】
図7Bは、図1のPCD100のリソースを管理するシステム向けのソフトウェアアーキテクチャの第2の態様の一般的な図500B1である。この一般的な図では、各ノード601の1つまたは複数のリソースは、一意の名前を与えられていない。図7Bのノードまたはリソースグラフ500B1は、アーキテクチャまたはフレームワーク管理プログラム440によってサポートされるノード601、マーカー650、クライアント648、イベント690、および照会機能695のみ含む。各ノード601は、卵形およびノード601内のリソース間のそれぞれの従属性を表す特定の方向を有する矢印680により示されている。
【００７６】
図7A〜図7Bに示されているノードアーキテクチャ内のコールは、ノード601内のリソースのエイリアス、または実際のリソース名に対し行われ得る。例示的な一実施形態によれば、クライアント648とマーカー650との間のインターフェースがないので、マーカー650に対してクライアント要求675を行う方法がなく、そのためこれは一般に、マーカー650との間で交換される情報の発生元が通常はノード601またはリソースであり、クライアント648ではないことを意味する。
【００７７】
たとえば、図7Bの第1のノード601Aは、第1のノード601Aが第2のノード601Bの2つのリソース(リソース#2および#3)に従属していることを示す従属性矢印680Aを有する。同様に、第1のノード601Aは、第1のノード601Aが、ハードウェアまたはソフトウェアまたはそれらの組合せのレガシー要素を一般に含む第1のマーカー650にも従属していることを示す従属性矢印680Bを有する。
【００７８】
図7Bはまた、第1のノード601Aのクライアント648がどのようにしてクライアント要求675を第1のノード601Aに出し得るかを示している。これらのクライアント要求675が出された後、第2のノード601Bは、イベント690をトリガするか、応答を照会695に提供することができ、この場合、イベント690および照会695に対応するメッセージがクライアント648に還流する。
【００７９】
図7Cは、図1のPCD100のリソースを管理するシステム向けのソフトウェアアーキテクチャの第2の態様の具体的な図500B2である。図7Cは、具体的でありながらも例示的なリソース名を有するノード601、ならびにクライアント648、イベント690、および照会機能695(図7Aのそれらに対応するもの)のみ含むノードまたはリソースグラフ500B2を示している。各ノード601は、卵形およびノード601内のリソース間のそれぞれの従属性を表す特定の方向を有する矢印680により示されている。
【００８０】
たとえば、第1のノード602は、第1のノード602が第2のノード622の3つのリソースに従属していることを示す従属性矢印680Bを有する。同様に、第2のソフトウェア要素444Bを含み、図7Cにおいて全体的に参照文字「C」で表される第3のリソース「/bus/ahb/sysB/」は、第3のリソース(C)が第4のノード646の単一の「/clk/sys/ahb」リソースに従属していることを示す従属性矢印680Cを有する。
【００８１】
図7Cはまた、1つまたは複数のイベント690または照会機能695を含み得るノード601からの出力データを示している。照会機能695は、イベント690と類似している。照会機能695は、固有であるか固有でない照会ハンドルを有し得る。照会機能は一般的に、外部では識別されず、一般的に照会機能は状態を有さない。照会機能695を使用して、ノード601の特定のリソースの状態を判断することができる。照会機能695およびイベント690は、既存クライアント648との関係を有することがあり、これらの関係は、それぞれのイベント690および照会機能695からの情報が特定のクライアント648に渡されることを示す方向矢印697によって表されている。図7Cはまた、図7Cの第2のノード622がどのように従属性矢印680Dを介して第1のマーカー650に従属しているかを示している。
【００８２】
図7B〜図7Cのノードまたはリソースグラフ500Bは、メモリ内に存在する関係を表し、この関係はフレームワーク管理プログラム440およびノード601を含み得る関連データ構造によって管理される。ノードまたはリソースグラフ500Bは、フレームワーク管理プログラム440によって管理されるそれぞれの要素間の関係を識別するための、かつソフトウェアチームによるトラブルシューティングのための有用なツールとして、フレームワーク管理プログラム440によって自動生成され得る。
【００８３】
図7Dは、PCD100のリソースを管理するための図4に示すものなどのソフトウェアアーキテクチャを作成するための方法1000Aを示すフローチャートである。ブロック1005は、PCD100のリソースを管理するための方法またはプロセス1000の第1のルーチンである。ルーチンブロック1005において、ノード構造データを受信するためにフレームワーク管理プログラム440によってルーチンが実行され得る。ノード構造データは、特定のノード601が他のノード601との間で有し得る従属性を略述する従属性配列を含むことができる。ノード構造データおよびこのルーチンまたはサブ方法705に関するさらなる詳細は、図8に関連して以下でより詳細に説明する。
【００８４】
次に、ブロック1010において、フレームワーク管理プログラム440は、ブロック1005において受信されたノード構造データの一部である従属性データをレビューすることができる。決定ブロック1015において、フレームワーク管理プログラム440は、ノード構造データがリーフノード601を定義しているか否かを判断することができる。リーフノード601は一般に、ノード構造データに基づいて作成されるノードが従属性をまったく有さないことを意味する。決定ブロック1015への照会が肯定である場合、最新ノードを作成するためのノード構造データが従属性をまったく有さないことを意味し、フレームワーク管理プログラム440はルーチンブロック1025に続く。
【００８５】
決定ブロック1015への照会が否定である場合、「いいえ」の分岐が決定ブロック1020に至り、フレームワーク管理プログラムがノード構造データ内のハードな従属性のすべてが存在するか否かを判断する。ハードな従属性は、リソースがそれなしでは存在できないものを含むことができる。一方、ソフトな従属性は、リソースが随意のステップとして従属リソースを使用できるものを含むことができる。ソフトな従属性は、ソフトな従属性を有するノード601またはノード601のリソースが、ソフトな従属性が存在しないときでもノードアーキテクチャ内に作成またはインスタンス化され得ることを意味する。マーカー650は、上述のようにソフトな従属性と呼ばれ得る。
【００８６】
ソフトな従属性の一例として、複数のリソースを含むリソース指向のノード601の動作に不可欠ではない最適化特徴が挙げられる。フレームワーク管理プログラム440は、存在するすべてのハードな従属性に関して、作成されないソフトな従属性を有するノードまたはリソースに関してソフトな従属性が存在しないときでも、ノードまたはリソースを作成またはインスタンス化することができる。コールバック特徴を使用してソフトな従属性を参照することができ、それにより、ソフトな従属性をフレームワーク管理プログラム440が利用できるようになったとき、フレームワーク管理プログラム440は、ソフトな従属性が現在利用可能であるという、ソフトな従属性を参照する各コールバックを知らせる。
【００８７】
決定ブロック1020への照会が否定である場合、「いいえ」の分枝がブロック1027に至り、ノード構造データがフレームワーク管理プログラム440によってメモリなどの一時記憶装置に記憶され、フレームワーク管理プログラム440はこのインスタンス化されないノードに関連するコールバック特徴を作成する。
【００８８】
決定ブロック1015への照会が肯定である場合、「はい」の分枝はルーチン1025に至り、ルーチンブロック1005において受信されたノード構造データに基づいてノード601が作成またはインスタンス化される。ルーチンブロック1025のさらなる詳細については、図9に関連して以下で説明する。次に、ブロック1030において、フレームワーク管理プログラム440は、新規作成されたノード601を、その一意のリソース名を使用して公開し、それにより他のノード601が、新規作成されたノード601に情報を送ること、または新規作成されたノード601から情報を受信することができるようになる。
【００８９】
次に図7Dの続きのフローチャートである図7Eを参照すると、ブロック1035において、フレームワーク管理プログラム440は、新規作成されたノード601に従属する他のノード601に対し、新規作成されたノード601がインスタンス化されており、情報を送受信する準備ができていることを通知する。例示的な一態様によれば、図7Bのノード601Bのような従属ノードが作成されたときに直ちに通知が開始される、すなわち、通知が再帰的に実行される。したがって、図7Bのノード601Bが構築された場合、ノード601Aは直ちに通知される。この通知により、(ノード601Bはノード601Aが最後に従属するものであったので)ノード601Aを構築することができる。ノード601Bの構築により他のノード601が通知される、といった状況が生じ得る。ノード601Bに従属する最後のリソースが完成するまで、ノード601Bは完成しない。
【００９０】
第2の、前記実装形態よりも若干複雑な実装形態では、通知のすべてを個別の通知キューに配置し、次いで一時点で開始するキューを通読する(run through)、すなわち、通知は反復的に実行される。したがって、図7Bのノード601Bが構築されたとき、ノード601Aに対する通知がリストに渡される。次いで、そのリストが実行され、ノード601Aに通知される。これにより、(図7Bに示されていない、ノード601A以外の)他の追加ノード601に対する通知が同じリストに掲載され、次いでその通知は、ノード601Aに対する通知が送られた後に送られる。(ノード601Aに対する通知以外の)他のノード601に対する通知は、ノード601Bおよびノード601Aに関連する作業がすべて完了するまで生じない。
【００９１】
論理的には、これら2つの実装形態は同等であるが、実施されたときのメモリ消費特性が異なる。再帰的実現は単純であるが、恣意的なスタックスペース量を消費する可能性があり、スタック消費は従属性グラフの深さの関数である。反復的実装形態はこれよりも若干複雑になっており、これよりも若干多くのスタックメモリ(通知リスト)を必要とするが、図7Bに示すように従属性グラフの深さにかかわりなくスタック使用は一定である。
【００９２】
また、ブロック1035におけるノード作成の通知は他のノードに限定されない。これはエイリアス構築に内部使用できる。他のノードにとどまらず、システム500Aにおける任意の恣意的な要素が同じ機構を使用して、ノード(またはマーカー)が利用可能になったときの通知を要求することができる。ノードと非ノードの両方が同じ通知機構を使用することができる。
【００９３】
決定ブロック1040において、フレームワーク管理プログラム440は、最新ノード601の作成に基づいて作成またはインスタンス化するために他のノード601またはソフトな従属性が現在解放されているか否かを判断する。作成またはインスタンス化を最近経験している最新ノードによっていくつかの従属関係680が満たされていることを理由にリソースが作成可能であるか否かを、決定ブロック1040は一般に判断する。
【００９４】
決定ブロック1040への照会が肯定である場合、「はい」の分枝はルーチンブロック1025に戻り、作成されたばかりのノード601による従属性の充足を理由に、解放されているノード601を現在作成またはインスタンス化することができる。
【００９５】
決定ブロック1040への照会が否定である場合、「いいえ」の分枝はブロック1045に至り、フレームワーク管理プログラム440は、図2に示すようにアーキテクチャの要素間の通信を管理することができる。次に、ブロック1050において、フレームワーク管理プログラム440は、特定のリソースに関連するリソース名を使用することによって、リソースによって行われるアクションを引き続きログ記録または記録することができる。フレームワーク管理プログラム440、またはリソース、ノード601、クライアント648、イベント690、および照会機能695のような、フレームワーク管理プログラム440によって管理される要素のうちのいずれかによって行われる任意のアクションの後、フレームワーク管理プログラム440によってブロック1045が実行され得る。ブロック1045は、ノードアーキテクチャの別の態様を示し、ここではフレームワーク管理プログラム440は、ノード601のリソースのような特定の要素を作成したオーサーによって提供される一意の識別子または名前に従って各要素によって実行されるアクションを列挙する活動の実行ログを維持することができる。
【００９６】
従来技術と比較して、システムの各リソースに割り当てられた一意の名前を列挙するブロック1050における活動のログ記録は固有のものであり、デバッギングおよび誤りトラブルシューティングで使用されるような、大きい利点をもたらすことができる。ノードアーキテクチャ500Aの別の固有な態様は、別個のチームが互いに独立して異なるハードウェア要素および/またはソフトウェア要素に取り組めることであり、この場合、各チームは、他のチームおよび/または相手先商標製造会社(OEM)によって割り当てられたさほど有意義ではなく一般にまぎらわしいリソース名を翻訳するためのテーブルを作成する必要なく、一意で追跡しやすいリソース名を使用することができる。
【００９７】
次に、決定ブロック1055において、フレームワーク管理プログラム440は、フレームワーク管理プログラム440によって記録された活動のログが要求されているか否かを判断する。決定ブロック1055への照会が否定である場合、「いいえ」の分枝はプロセスの最後に至り、プロセスはルーチン1005に戻る。決定ブロック1055への照会が肯定である場合、「はい」の分枝はブロック1060に至り、フレームワーク管理プログラム440は、有意義なリソース名およびリソース名によって実行されるそれぞれの活動を含む活動ログを、プリンタまたはディスプレイスクリーンおよび/または両方などの出力デバイスに送る。次いで、プロセスは上述のルーチンブロック1005に戻る。
【００９８】
図8は、PCD100のソフトウェアアーキテクチャにおけるノード構造データを受信するための図7Dのサブ方法またはルーチン1005を示すフローチャートである。ブロック1105は、図7Dのサブ方法またはルーチン1005における第1のステップである。ブロック1105において、フレームワーク管理プログラム440は、図7DのCPU110およびクロック442のようなソフトウェア要素またはハードウェア要素の一意の名前を受信することができる。前に説明したように、ノード601は少なくとも1つのリソースを参照しなければならない。各リソースはシステム500Aにおいて一意の名前を有する。システム500A内の各要素が一意の名前により識別され得る。各要素は、文字の観点から一意の名前を有する。言い換えれば、一般に、同じ名前を有する2つの要素はシステム500A内に存在しない。システムの例示的な態様によれば、ノード601のリソースは一般にシステム全体で一意の名前を有することができるが、クライアントまたはイベントの名前は、要望に応じて一意であってもよいが、一意である必要はない。
【００９９】
便宜上、限定はしないが、CPU110の「/core/cpu」およびクロック442の「/clk/cpu」のような、一意の名前を作成するための前スラッシュ「/」文字を用いる従来型のツリーファイル命名構造またはファイル命名「メタファー」を用いることができる。ただし、当業者が認識するように、英数字文字および/または記号の任意の他の組合せを含む他のタイプのリソース名も、本発明の範囲内に十分に入る。
【０１００】
次に、ブロック1110において、フレームワーク管理プログラム440は、作成されるノード601の1つまたは複数のリソースに関連する1つまたは複数のドライバ機能に関するデータを受信することができる。ドライバ機能は一般に、特定のノード601に関する1つまたは複数のリソースによって完了するアクションを含む。たとえば、図7A〜図7Bにおいて、ノード602のリソース/core/cpuに関するドライバ機能は、要求されている所要量の処理を提供するために必要とする量のバス帯域幅およびCPUクロック周波数を要求することができる。これらの要求は、ノード642およびノード622におけるリソースのクライアント(たとえば、図2のクライアント201、202、204および206)を介して行われる。ノード642における/clk/cpuに関するドライバ機能は通常、ノード602の/core/cpuリソースから受信した要求に従って物理クロック周波数を実際に設定することを担当する。
【０１０１】
ブロック1115において、フレームワーク管理プログラム440はノード属性データを受信することができる。ノード属性データは一般に、安全性(ユーザ空間アプリケーションを介してノードにアクセスできるか)、遠隔性(システムにおいて他のプロセッサからノードにアクセスできるか)およびアクセス可能性(リソースは複数の並列クライアントをサポートできるか)などのノードポリシーを定義するデータを含む。フレームワーク管理プログラム440はまた、要求評価またはログ記録ポリシーなど、リソースがデフォルトフレームワーク行動を無効にすることを許容する属性を定義することができる。
【０１０２】
その後、ブロック1120において、フレームワーク管理プログラム440は、作成される特定のノード601に関するカスタマイズされたユーザデータを受信することができる。ユーザデータは、「C」プログラミング言語に関して当業者によって理解されている空の「スター(star)」フィールドを含むことができる。ユーザデータはまた、「トラストミー(trust me)」フィールドとして当業者に知られている。例示的なカスタマイズされたユーザデータは、限定はしないが、テーブル、たとえば周波数テーブル、レジスタマップなどを含むことができる。ブロック1120において受信されたユーザデータは、システム500Aによって参照されないが、リソースのカスタマイズを、カスタマイズがフレームワーク管理プログラム440によって認識されていないか、十分にサポートされていない場合に許容する。このユーザデータ構造は、特別な使用または特定の使用のために拡張されることが意図された「C」プログラミング言語における基本クラスである。
【０１０３】
当業者は、特定のクラスの特定の使用を拡張するための他の種類のデータ構造が、本発明の範囲内にあることを認識する。たとえば、プログラミング言語「C++」(C-プラス-プラス)において、同等の構造が、ノード601内のリソースの拡張機構になるキーワード「パブリック(public)」を含むことができる。
【０１０４】
次に、ブロック1125において、フレームワーク管理プログラム440は従属性配列データを受信することができる。従属性配列データは、作成されるノード601が従属する1つまたは複数のリソース601の一意かつ特定の名前を含むことができる。たとえば、図7Cの第1のノード602が作成されている場合、このブロック1125において、従属性配列データは、第1のノード602が従属する第2のノード622の3つのリソースのリソース名および第3のノード642の単一のリソース名を含むことができる。
【０１０５】
続いて、ブロック1130において、フレームワーク管理プログラム440はリソース配列データを受信することができる。リソース配列データは、作成される最新ノードに関するパラメータ、たとえば、図7B〜図7Cの第1のノード602が作成されている場合にこの第1のノード602に関連するパラメータを含むことができる。リソース配列データは、以下のデータのうちの1つまたは複数を含むことができる。他のリソースの名前、ユニット、最大値、リソース属性、プラグインデータ、およびブロック1120のカスタマイズユーザデータに類似した任意のカスタマイズされたリソースデータ。プラグインデータは、一般に、ソフトウェアライブラリから取り出された機能を識別し、通常、作成される特定のノードまたは複数のノードによってサポートされ得るクライアントタイプを列挙する。プラグインデータはまた、クライアントの作成および破壊のカスタマイズを可能にする。ブロック1130の後、プロセスは図7Dのブロック1010に戻る。
【０１０６】
図8において、属性データブロック1115、カスタマイズユーザデータブロック1120、および従属性配列データブロック1125は、これらの特定のステップが随意であり、所与のノード601に必要なものではないことを示すために破線で示されている。一方、一意の名前ブロック1105、ドライバ機能ブロック1110、およびリソース配列データブロック1130は、ルーチン1005のこれらのステップがノード601を作成するために一般に必須であることを示すために実線で示されている。
【０１０７】
図9は、PCD100向けのソフトウェアアーキテクチャにおけるノードを作成するための図7Dのサブ方法またはルーチン1025を示すフローチャートである。ルーチンブロック1205は、例示的な一実施形態によるノード601をインスタンス化または作成するためのサブ方法またはルーチン1025における第1のルーチンである。ルーチンブロック1205において、インスタンス化されているノード601に関連する1つまたは複数のクライアント648が、このステップで作成される。ルーチンブロック1205に関するさらなる詳細については、図10に関連して以下でさらに詳しく説明する。
【０１０８】
ブロック1210において、フレームワーク管理プログラムは、ブロック705のノード構造データに対応する1つまたは複数のリソースを作成またはインスタンス化することができる。次に、ブロック1215において、フレームワーク管理プログラム440は、ルーチンブロック1005のルーチンブロック1110において受信されたドライバ機能をアクティブ化することができる。例示的な一態様によれば、ドライバ機能は、ルーチンブロック1005のリソース配列データブロック1130において受信された最大値を使用してアクティブ化され得る。別の好ましい例示的な態様によれば、各ドライバ機能は、ルーチン1005からノード構造データとともに渡された随意の初期値によりアクティブ化され得る。初期データが提供されない場合、ドライバ機能は最小値0に初期設定される。ドライバ機能はまた、通常は、初期設定されていることがわかるようにアクティブ化される。これによりリソースは、初期設定に固有であるが、通常動作またはルーチン動作中に実行される必要のない動作を実行することができる。そして、プロセスは図7Dのステップ1030に戻る。
【０１０９】
図10は、PCD100のソフトウェアアーキテクチャにおけるクライアント648を作成するための図9のサブ方法またはルーチン1205を示すフローチャートである。ブロック1305は、1つまたは複数のリソース601のクライアント648が作成されるルーチンブロック1205の第1のステップである。ブロック1305において、フレームワーク管理プログラム440は、作成されるクライアント648に割り当てられた名前を受信する。リソース名と同様に、クライアント648の名前は、任意のタイプの英数字および/または記号を含むことができる。
【０１１０】
次に、ブロック1310において、作成されるこのクライアント648に関する特定のカスタマイズがある場合に、カスタマイズされたユーザデータがフレームワーク管理プログラム440によって受信され得る。ブロック1310は、このステップが随意であることを示すために破線で示されている。ブロック1310のカスタマイズされたユーザデータは、ノード601のリソースの作成に関連して上述したカスタマイズされたユーザデータに類似している。
【０１１１】
ブロック1315において、フレームワーク管理プログラム440は、作成される特定のクライアントに割り当てられたクライアントタイプカテゴリーを受信する。本明細書執筆時点でクライアントタイプカテゴリーは、4つのタイプのうちの1つを含むことができる。(a)必須、(b)インパルス、(c)ベクトル、および(d)等時性。クライアントタイプカテゴリーのリストは、システム101によって管理されているリソースに応じて、またノード601のリソースに依存するアプリケーションプログラムに応じて、拡大し得る。
【０１１２】
必須カテゴリーは、必須クライアント648から特定のリソース601に渡されるスカラー値の処理に概ね対応する。たとえば、必須要求は、数百万命令毎秒(MIPS)を含むことができる。一方、インパルスカテゴリーは、開始時間または停止時間の指定のない一定期間内に何らかの活動を完了させるよう求める要求の処理に概ね対応する。
【０１１３】
等時性カテゴリーは、通常は再発しており、明確な開始時間および明確な終了時間を有するアクションに対する要求に概ね対応する。ベクトルカテゴリーは、直列または並列に要求される複数のアクションの一部であるのが普通であるデータの配列に概ね対応する。
【０１１４】
続いて、ブロック1320において、フレームワーク管理プログラム440は、クライアント648が同期に指定されているか、それとも非同期に指定されているかを示すデータを受信する。同期クライアント648は、リソース601が同期クライアント648から要求されたタスクを完了したことを示すデータおよび指示をリソース601が返信するまで、ノード601のリソースをロックすることをフレームワーク管理プログラム440に対し通常要求するクライアントである。
【０１１５】
一方、非同期クライアント648は、フレームワーク管理プログラム440によってアクセスされる1つまたは複数のスレッドによって並列に処理され得る。フレームワーク管理プログラム440は、スレッドに対するコールバックを作成することができ、コールバックがそれぞれのスレッドによって実行されているときに値を戻すことができる。
【０１１６】
ブロック1320の後、決定ブロック1325において、フレームワーク管理プログラム440は、クライアント648によって識別されるリソースが利用可能であるか否かを判断する。決定ブロック1325への照会が否定である場合、「いいえ」の分岐がブロック1330に至り、クライアント648をこの時点で作成できないことを示すヌル値またはメッセージがユーザに返信される。
【０１１７】
決定ブロック1325への照会が肯定である場合、「はい」の分岐が決定ブロック1335に至り、フレームワーク管理プログラム440は、クライアント648によって識別される各リソースがブロック1315において提示されたクライアントタイプをサポートするか否かを判断する。決定ブロック1335への照会が否定である場合、「いいえ」の分岐がブロック1330に戻り、クライアント648をこの時点で作成できないことを示すヌル値またはメッセージが返信される。
【０１１８】
決定ブロック1335への照会が肯定である場合、「はい」の分岐がブロック1340に至り、フレームワーク管理プログラム440はメモリ内にクライアント648を作成またはインスタンス化する。次に、ブロック1345において、随意の引数のような任意のカスタマイズされたユーザデータがブロック1310において受信された場合、これらの随意の引数がそれぞれのリソースおよび特定のノード601にマップされ得る。次に、ブロック1350において、新規作成されたクライアント648が、アイドル状態において、または上記の図10Cで示したように要求された状態において、その対応する1つまたは複数のリソースに結合される。そして、プロセスは図12のブロック1210に戻る。
【０１１９】
図11は、PCD100向けのソフトウェアアーキテクチャにおけるリソース601に対するクライアント要求675を作成するための方法1400を示すフローチャートである。方法1400は一般に、図7D〜図7Eおよび図10に関連して上述したようにクライアント作成およびノード作成の後、実行される。
【０１２０】
ブロック1405は、リソース601に対するクライアント要求675を作成するための方法1400における第1のステップである。方法1400は、以下の3つのタイプの要求675がフレームワーク管理プログラム440によってどのように処理されるかを表している。(a)必須、(b)インパルス、および(c)ベクトル。第4のタイプの要求675、すなわち(d)等時性要求の処理については、図15に関連して後述する。前記の要求675の名前が示唆するように、クライアント要求675は、作成され、上述したクライアントタイプに概ね対応する。
【０１２１】
ブロック1405において、フレームワーク管理プログラム440は、上述した3つ、すなわち(a)必須、(b)インパルス、および(c)ベクトルのうちの1つのような特定のクライアント要求675に関連するデータを受信することができる。必須要求に関連するデータは一般に、必須クライアント648から特定のリソース601に渡されるスカラー値を含む。たとえば、必須要求は、数百万命令毎秒(MIPS)を含むことができる。一方、インパルス要求は、開始時間または停止時間の指定のない一定期間内に何らかの活動を完了させるよう求める要求を含む。ベクトル要求に関するデータは一般に、直列または並列に完了することが求められる複数のアクションの配列を含む。ベクトル要求は、値の任意の長さを含むことができる。ベクトル要求は通常、サイズ値および値の配列を有する。ノード601の各リソースは、ベクトル要求をサポートするためにポインタフィールドを有するように拡張され得る。「C」プログラミング言語では、ポインタフィールドは、当業者によって理解されているように、統合機能(union function)によってサポートされている。
【０１２２】
次に、ブロック1410において、フレームワーク管理プログラム440は、図10に関連して上述した方法によって作成されたクライアント648を通じて要求を出す。続いて、ブロック1415において、フレームワーク管理プログラム440は、要求が必須タイプまたはベクトルタイプである場合に、クライアントを通じて渡されている要求データを二重バッファする。要求がインパルスタイプである場合、ブロック1415はフレームワーク管理プログラム440によって飛ばされる。
【０１２３】
必須要求の場合、このブロック1415において、先行する要求からの値がメモリ内に維持され、それによりフレームワーク管理プログラム440は、以前の要求された値と要求された値の現在のセットとの間に差異があるか否かを判断することができる。ベクトル要求の場合、先行する要求は通常、メモリ内に維持されないが、ノード601のリソースは、特定の実装形態で望まれるように、それを維持することができる。したがって、ブロック1415はベクトルタイプの要求の場合には随意である。
【０１２４】
ブロック1420において、フレームワーク管理プログラム440は、要求された値の以前のセットと要求された値の現在のセットとの間のデルタまたは差異を計算する。決定ブロック1425において、フレームワーク管理プログラムが、要求された値の現在のセットが要求された値の以前のセットと同じであるか否かを判断する。言い換えれば、フレームワーク管理プログラム440は、要求された値の現在のセットと要求された値の以前のセットとの間に差異があるか否かを判断する。要求された値の現在のセットと以前のセットとの間に差異がない場合、「はい」の分枝が(ブロック1430〜ブロック1470を飛ばして)ブロック1475に至り、プロセスは終了する。
【０１２５】
決定ブロック1425への照会が否定である場合、要求された値のセットが以前の要求された値のセットと異なることを意味し、「いいえ」の分枝が決定ブロック1430に至る。
【０１２６】
決定ブロック1430において、フレームワーク管理プログラム440は、現在の要求が非同期要求であるか否かを判断する。決定ブロック1430への照会が否定である場合、「いいえ」の分枝がブロック1440に至り、クライアント要求675に対応するリソース601がフレームワーク管理プログラム440によってロックされる。決定ブロック1430への照会が肯定である場合、現在の要求が非同期要求タイプであることを意味し、「はい」の分枝がブロック1435に至り、図1のマルチコアシステムのようなマルチコアシステムがフレームワーク管理プログラム440によって現在管理されている場合に、要求を別のスレッドに渡すことができ、別のコアによって実行することができる。ブロック1435は、PCD100が単一コア中央処理システムである場合にこのステップが随意であり得ることを示すために破線で示されている。
【０１２７】
続いて、ブロック1440において、要求675に対応するリソース601がフレームワーク管理プログラム440によってロックされる。次に、ブロック1445において、リソース601は、図8のブロック1130において受信されたリソース配列データのプラグインデータに概ね対応する更新機能を実行する。更新機能は一般に、新しいクライアント要求に照らして新しいリソース状態を確保する機能を含む。更新機能は、クライアント要求における要求された状態と以前の状態とを比較する。要求された状態が以前の状態よりも大きい場合、更新機能はクライアント要求を実行する。一方、要求された状態が現在の状態以下であり、現在の状態でリソースが動作している場合、古い状態は要求された状態を達成しているか満たしているので、効率性を高めるためにクライアント要求を実行することはない。更新機能は、クライアントからの新しい要求を受け取り、それを他のアクティブな要求すべてと統合して、リソースの新しい状態を判断する。
【０１２８】
一例として、複数のクライアントがバスクロック周波数を要求していることがある。バスクロックの更新機能は通常、最大限のすべてのクライアント要求を受け取り、バスクロックの新しい所望の状態としてそれを使用する。すべてのリソースが同じ更新機能を使用する場合は該当しないが、複数のリソースによって使用される更新機能がいくつかある。いくつかの共通する更新機能は、最大限のクライアント要求を受け取ること、最小限のクライアント要求を受け取ること、およびクライアント要求を合算することである。あるいは、リソースは、何らかの固有の方法で要求を統合する必要がある場合に、それら自体のカスタム更新機能を定義することができる。
【０１２９】
次に、ブロック1450において、フレームワーク管理プログラム440は、クライアント要求648に対応するリソースにデータを渡して、リソースがノード601のリソースに固有のドライバ機能を実行できるようにする。ドライバ機能は、更新機能によって計算される通りにリソース状態を適用する。これは、ハードウェア設定を更新すること、従属リソースに要求を出すこと、レガシー機能を呼び出すこと、または前記の何らかの組合せを伴うことがある。
【０１３０】
前述の例では、更新機能は、要求されたバスクロック周波数を計算した。ドライバ機能は、その要求された周波数を受信することができ、クロック周波数制御ハードウェアを更新して、その周波数で作動させることができる。更新機能が計算した正確な要求された状態をドライバ機能が満たすことは不可能な場合もあることに留意されたい。この場合、ドライバ機能は、要求を最も満たす周波数を選択することができる。たとえば、バスクロックハードウェアは128MHzおよび160MHzでのみ作動できるが、要求された状態は150MHzである場合がある。この場合、ドライバ機能は、要求された状態を上回る160MHzで作動すべきである。
【０１３１】
次に、ブロック1455において、フレームワーク管理プログラム440は、ブロック1450においてドライバ機能を実行したリソースから状態制御を受信する。続いて、ブロック1460において、リソースに対して定義されている場合、イベント690をトリガすることができ、それによりデータは、イベント690に対応するクライアント648に戻される。イベントは別のスレッドで処理され得る。これにより、ロックされたリソースで費やされる時間量を最小限に抑えることができ、図1に示したようなマルチコアシステムにおける並列的な動作が可能になる。本方法1400で説明するようにリソースに対して要求を定義できる方法と同様に、リソースに対して1つまたは複数のイベント690を定義することができる。言い換えれば、イベント作成プロセスは、クライアント作成プロセスに概ね匹敵する。イベントと異なる1点は、いくつかのしきい値を超えたときのみトリガされるイベントを定義することが可能である点である。
【０１３２】
しきい値に基づいてのみトリガされるイベントのこの定義により、システムの過負荷状態を示す、リソースがオーバーサブスクライブされている(サポートできる数を超える同時ユーザを有する)時期、または他の物が断たれること、システムがオーバーサブスクライブされたときに無効になった機能を回復させることなどが可能になる、リソースが低水準/オフになる時期を通知することができる。イベント登録はしきい値により行うことができるので、システムがイベント通知に関して行わなければならない作業の量が減り、本当に必要なものがあるときのみイベント通知が生じるようになる。あらゆる状態変化に関するイベントを登録することも可能である。
【０１３３】
次に、随意のブロック1465において、処理されている要求がベクトル要求である場合、この随意のブロック1465はたいてい実行される。随意のブロック1465は一般に、ベクトルポインタが依然として、ユーザがベクトルに渡した同じデータに位置付けられているか否かを査定するチェックまたは判断を含む。この随意のブロック1465への照会が肯定である場合、ポインタは依然として、ユーザによってベクトルに渡された同じデータを指していることを意味し、古いデータの参照が維持されないようにポインタが除去される。この随意のブロック1465は一般に、インパルス要求および必須要求と比較して、ベクトル要求が処理されているときに上述の二重バッファリングブロック1415を考慮して(account for)実行される。
【０１３４】
続いて、ブロック1470において、フレームワーク管理プログラム440は、要求されたリソースのロックを解除し、それにより他のクライアント要求648は、特定のノード601の現在のものであるが今解放された要求されたリソースによって処理され得る。次いでプロセスは、次のクライアント要求を受信するために第1のブロック1405に戻る。
【０１３５】
上記の開示を考慮して、プログラミングの当業者は、たとえば本明細書のフローチャートおよび関連する説明に基づいて、コンピュータコードを書くか、または適切なハードウェアおよび/もしくは回路を特定し、開示された発明を容易に実施することができる。したがって、特定の1組のプログラムコード命令または詳細なハードウェアデバイスの開示が、本発明をどのように製作し使用すべきかについて適切に理解するうえで必要であるとは見なされない。特許請求されるコンピュータで実施される処理の発明性のある機能は、上の説明において、かつ、様々な処理の流れを示し得る図面とともに、より詳細に説明される。
【０１３６】
1つまたは複数の例示的な態様では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せで実装することができる。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体上で送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の使用可能な媒体とすることができる。限定ではなく、例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROM、または他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または、命令もしくはデータ構造の形態で所望のプログラムコードを搬送もしくは記憶するために使用され得るとともに、コンピュータによってアクセスされ得る任意の他の媒体を含み得る。
【０１３７】
また、任意の接続をコンピュータ可読媒体と呼ぶのが妥当である。たとえば、ソフトウェアが同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、またはワイヤレス技術、たとえば赤外線、無線、およびマイクロ波を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義内に含まれる。
【０１３８】
本明細書で使用する場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザディスク、光ディスク、デジタル多用途ディスク(DVD)、フレキシブルディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生し、ディスク(disc)は、レーザで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
【０１３９】
選択された態様について詳細に説明し、詳述してきたが、以下の請求項によって定義されるような本発明の趣旨および範囲から逸脱することなく、本明細書において様々な置換および改変を実施できることが理解されよう。
【符号の説明】
【０１４０】
100  PCD
101  システム
102  オンチップシステム、リソース電力マネージャ、RPMノード、RPM
103  内部チップバス(「ICB」)ドライバモジュール、ドライバモジュール、UL ICBドライバ、ICBドライバ
103A  上位層(「UL」)タイプ、UL ICBドライバタイプ、ICBドライバ、上位層(「UL」)内部チップバス(「ICB」)ドライバモジュール、ICBドライバモジュール、UL ICBドライバ
103A1  第1のUL ICBモジュール、第1のUL ICBドライバ
103B  下位層(「LL」)タイプ、LL ICBドライバタイプ、ICBドライバ、下位層(「LL」)ICBドライバ、下位層ICB(「LL ICB」)ドライバモジュール、ICBドライバモジュール
105  アプリケーションプログラムモジュール、プログラムモジュール、アプリケーションモジュール、ソフトウェアアプリケーションモジュール
105A1  第1のアプリケーションプログラムモジュール
105A2  第2のアプリケーションプログラムモジュール
107  リソース電力マネージャ、スイッチファブリック、バス
107A  第1のスイッチファブリック、スイッチファブリック、第1のファブリック
107B  第2のスイッチファブリック、スイッチファブリック
107C  第3のスイッチファブリック、スイッチファブリック
107N  第3のスイッチファブリック
109  動的メモリ割振り/アクセス(「DMA」)エンジン、マスターノードM7
110  プロセッサ、マスタープロセッサ、CPU、マスターCPU、中央処理装置(CPU)、マスター
110A  中央処理装置(「CPU」)、プロセッサ、マルチコア中央処理装置(「CPU」)、第1のCPU、第1のマスター1、第1のマスターノードM1
110B  グラフィックスプロセッサ、プロセッサ、中央処理装置(「CPU」)、第2のCPU、第2のマスター2、第2のマスターノードM2、第2のマスターM2
110C  中央処理装置(「CPU」)、第3のCPU、マスターノードM3、第3のプロセッサ
110D  モバイルディスプレイプロセッサ(「MDP」)、第5のマスターノードM5、第5のマスター、第5のマスターM5
110N  中央処理装置(「CPU」)、第4のCPU、マスターノードM4
111  構成ポート、第1のスレーブ1、第1のスレーブノードS1
112  メモリ、ダブルデータレート同期型ダイナミックランダムアクセスメモリ(「DDR SDRAM」)、DDRメモリ、第2のスレーブ2、第2のスレーブノードS2
113  外部バスインターフェース、第3のスレーブノードS3、第3のスレーブS3
114  デジタル信号プロセッサ、マスターノードM6、DSP
115  マスターハードウェア要素、マスターノードMN
117  スレーブハードウェア要素、スレーブノードSN
126  アナログ信号プロセッサ、プロセッサ
128  ディスプレイコントローラ
130  タッチスクリーンコントローラ
132  タッチスクリーンディスプレイ
134  ビデオコーダ/デコーダ(「コーデック」)、ビデオエンコーダ
136  ビデオ増幅器
138  ビデオポート
140  ユニバーサルシリアルバス(「USB」)コントローラ
142  USBポート
146  加入者識別モジュール(SIM)カード
148  デジタルカメラ、カメラ
150  ステレオオーディオコーデック
152  オーディオ増幅器
154  第1のステレオスピーカー
156  第2のステレオスピーカー
157B  熱センサ
158  マイクロフォン増幅器
160  マイクロフォン
162  周波数変調(「FM」)無線チューナー
164  FMアンテナ
166  ステレオヘッドフォン
168  高周波(「RF」)トランシーバ
170  RFスイッチ
172  RFアンテナ
174  キーパッド
176  マイクロフォンを備えたモノヘッドセット、モノヘッドセット
178  バイブレータデバイス、バイブレータ
180  電源
200  動作環境
201  第1のクライアント、クライアント
202  第2のクライアント、クライアント
204  第3のクライアント、クライアント
206  第Nのクライアント、クライアント
207  システムバス、バス
207A  リソースプロキシ
208  線
209  参照番号、接続
211  点線
212  実線
213  フラグ、変数フラグ、状況変数フラグ
215  ポイント
216  クライアントスレッド
217  参照番号
218  参照番号
219  参照番号、確認応答
220  ポイント
221  参照番号
222  第0のコア
224  第1のコア
226  第Nのコア
231  第1のスレッド
232  ポイント
234  参照番号
235  参照番号
236  参照番号、確認応答
237  参照番号
241  参照番号
242  ポイント
244  参照番号
251  参照番号
252  参照番号
254  参照番号
255  参照番号
256  参照番号
257  参照番号
258  ポイント
260  参照番号
261  参照番号
264  参照番号
265  ポイント
266  参照番号
268  参照番号、要求、後続要求
270  ポイント
307  クロスバースイッチ
307A  クロスバースイッチ
307B  クロスバースイッチ
307C  クロスバースイッチ
400  第1のゲートウェイノードG1、第1のゲートウェイG1
400A1  第1のゲートウェイノードG1、第1のゲートウェイG1
400B1  第1のゲートウェイノードG1A、第1のゲートウェイ、第1のゲートウェイG1A
400B2  ゲートウェイノードG1B、第1のゲートウェイG1B
401  第1のソフトウェア要求タイプ、第1の「バースト的」ソフトウェア要求タイプ、ソフトウェア要求タイプ、要求
401A  「バースト的」ソフトウェア要求、第1のソフトウェア要求、第1のバースト的ソフトウェア要求、ソフトウェア要求、要求
401B  「バースト的」ソフトウェア要求、第2のソフトウェア要求、第2のバースト的ソフトウェア要求、ソフトウェア要求、要求
402  第2のゲートウェイノードG2、第2のゲートウェイG2
402A  データブロック
402A1  第2のゲートウェイノードG2、第2のゲートウェイG2
402B  データブロック
402B1  第2のゲートウェイノードG2A、第2のゲートウェイG2A
402B2  ゲートウェイノードG2B、第2のゲートウェイG2B
402C1  第2のゲートウェイG2
403  ノードグラフまたはノードアーキテクチャ
404A  第1の期間P1
404B  第2の期間P2
405  アービタノード
406A  第1のウィンドウW1、ウィンドウサイズW1
406B  第2のウィンドウW2、ウィンドウサイズW2
407  スイッチファブリックノード、ファブリックノード
407A  スイッチファブリックノード
407B  スイッチファブリックノード
407C  スイッチファブリックノード
408A  第1のブロックサイズBS1
408B  第2のブロックサイズBS2
422  バスアービタまたはスケジューラ
440  フレームワーク管理プログラム
442  クロック
444A  バスプログラムA
444B  バスプログラムB
448  ソフトウェア要素によって監視されるアクションまたは機能
450  レガシー要素
500A  ソフトウェアアーキテクチャ
501  「CPU」タイプ、第2のソフトウェア要求タイプ、CPUソフトウェア要求タイプ
507  第1のルートチェックテーブル、ルートチェックテーブル、テーブル
601  ノード
601A  第1のノード
601B  第2のノード
602  ノード
607  第2のルートチェックテーブル、ルートチェックテーブル、テーブル
622  ノード、第2のノード
642  ノード
646  ノード
648  クライアント
650  マーカー、第1のマーカー
675  クライアント要求
680A  従属性矢印
680B  従属性矢印
680D  従属性矢印
690  イベント
695  照会機能
697  方向矢印
1002  配列データ構造、ハンドル
1002A  第1のハンドル
1002B  第2のハンドル
1002C  第3のハンドル
1002D  第4のハンドル
t0  時間
t1  時間
t2  時間
t3  時間
t4  時間
t5  時間
t7  時間
【図１】
0005710844.tif 000002
【図２】
0005710844.tif 000003
【図３】
0005710844.tif 000004
【図４】
0005710844.tif 000005
【図５】
0005710844.tif 000006
【図６Ａ】
0005710844.tif 000007
【図６Ｂ】
0005710844.tif 000008
【図７Ａ】
0005710844.tif 000009
【図７Ｂ】
0005710844.tif 000010
【図７Ｃ】
0005710844.tif 000011
【図７Ｄ】
0005710844.tif 000012
【図７Ｅ】
0005710844.tif 000013
【図８】
0005710844.tif 000014
【図９】
0005710844.tif 000015
【図１０】
0005710844.tif 000016
【図１１】
0005710844.tif 000017