JP5809366B2 - ポータブルコンピューティングデバイスにおいて要求をスケジューリングするための方法およびシステム - Google Patents

ポータブルコンピューティングデバイスにおいて要求をスケジューリングするための方法およびシステム Download PDF

Info

Publication number
JP5809366B2
JP5809366B2 JP2014558799A JP2014558799A JP5809366B2 JP 5809366 B2 JP5809366 B2 JP 5809366B2 JP 2014558799 A JP2014558799 A JP 2014558799A JP 2014558799 A JP2014558799 A JP 2014558799A JP 5809366 B2 JP5809366 B2 JP 5809366B2
Authority
JP
Japan
Prior art keywords
resource
request
processor
requests
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2014558799A
Other languages
English (en)
Other versions
JP2015513735A (ja
Inventor
ノーマン・エス・ガルガッシュ
グラディ・エル・キャラウェイ
ヴィノド・ヴィジャヤラジャン
トレイシー・エー・ウルマー
ジョシュア・エイチ・スタッブス
アンドリュー・ジェイ・フランツ
ガブリエル・ワトキンス
Original Assignee
クアルコム，インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2015513735A publication Critical patent/JP2015513735A/ja
Application granted granted Critical
Publication of JP5809366B2 publication Critical patent/JP5809366B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/329—Power saving characterised by the action undertaken by task scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4893—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues taking into account power or heat criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0216—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0261—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level
    • H04W52/0274—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof
    • H04W52/0277—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof according to available power supply, e.g. switching off when a low battery condition is detected
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Sources (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Multi Processors (AREA)

Description

優先権および関連出願の陳述
本出願は、「METHOD AND SYSTEM FOR SCHEDULING REQUESTS IN A PORTABLE COMPUTING DEVICE」と題する2012年2月23日に出願された米国仮特許出願第61/602,287号に対する米国特許法第119条(e)項に基づく優先権を主張する。その内容全体が、参照により本明細書に組み込まれる。
ポータブルコンピューティングデバイス(「PCD」)はますます普及しつつある。これらのデバイスは、セルラー電話、携帯情報端末(「PDA」)、ポータブルゲームコンソール、ポータブルナビゲーションユニット、パームトップコンピュータ、および他のポータブル電子デバイスを含み得る。これらのデバイスの各々は主要機能を有し得る。たとえば、セルラー電話は一般に、電話を受けたりかけたりする主要機能を有する。
これらのデバイスの多くは主要機能に加えて、周辺機能を含む。たとえば、セルラー電話は、上述したようにセルラー電話をかけるという主要機能、およびスチールカメラ、ビデオカメラ、全地球測位システム(GPS)ナビゲーション、ウェブブラウジング、電子メールの送受信、テキストメッセージの送受信、およびプッシュツートーク機能などの周辺機能を含み得る。PCDの機能が増加するにつれて、そのような機能をサポートために必要な計算能力または処理能力も増大する。処理能力は、PCD内のプロセッサの数を増やすことによって増大し得る。計算能力およびプロセッサの数が増大するにつれて、プロセッサを効果的に管理する必要性が増す。
上述したような機能は、リソースと呼ばれ得る様々な対応するハードウェア要素およびソフトウェア要素で具現化され得る。プロセッサは、アプリケーションプログラムなどのソフトウェアの制御下で様々な時間に様々なリソースを要求し得る。マルチプロセッサPCDにおいて、第1のプロセッサは、第2のプロセッサによって制御されるリソースとは異なるリソースを制御し得る。従来技術では、これらのリソースにより消費される電力を節減するために複数のプロセッサにわたってリソースを効率的に管理することは、非常に複雑で困難であり得る。
ポータブルコンピューティングデバイス内のリソースの間の要求を管理するための方法およびシステムが開示される。方法およびシステムは、複数の要求をスケジューリングするためのデータをクライアントから受信するスケジューラを含む。各要求は、少なくとも1つのリソースおよび要求される期限を特定する。次に、クライアントからのデータがスケジューラによってデータベースに記憶される。スケジューラは次いで、要求において要求された期限に基づき、かつ、ポータブルコンピューティングデバイス内のリソースの現在の状態に基づき、要求を処理するための時間および順序を決定する。スケジューラは次いで、決定された時間に、決定された順序に従って、要求をリソースに伝える。
スケジューラは、自身の裁量で、クライアントからの新たな要求コマンドを受信したことに応答して、要求された期限の後に要求をスケジューリングすることができる。プロセッサがスリーププロセッサ状態から出たときにプロセッサが1つまたは複数のスケジューリングされた要求について作業を続けることができるように、スケジューラは、スリーププロセッサ状態に対応するスリープセットが、プロセッサのパワーオフすることを可能にし得る。スケジューラがスケジューリングされたスリープ状態の間に予想されない要求を受信すると、スケジューラは、予想されない要求に応答するために1つまたは複数のスケジューリングされた要求が必要であるかどうかを判断することができる。スケジューリングされたスリープ状態の間に予想されない要求に応答するために1つまたは複数のスケジューリングされた要求が必要ではない場合、スケジューラは、1つまたは複数のスケジューリングされた要求を取り消し、次いで、取り消されたスケジューリングされた要求の1つまたは複数を、次のスケジューリングされたアクティブ状態において発生するようにスケジューリングすることができる。
図中、別段規定されていない限り、同様の参照番号は、様々な図の全体を通じて、同様の部分を指す。「102A」または「102B」のような文字指定を伴う参照番号について、文字指定は、同じ図に存在する2つの同様の部分または要素を区別し得る。参照番号の文字指定は、参照番号が、すべての図において同じ参照番号を有するすべての部分を包含することが意図される場合には、省略されることがある。
ポータブルコンピューティングデバイス(「PCD」)における分散リソース管理のためのシステムの例示的な要素を示す機能ブロック図である。 第1のプロセッサが第2のプロセッサによって制御されるリソースを要求する必要がある場合の一例を示す機能ブロック図である。 PCDのリソースを管理するノードアーキテクチャの第1の態様の図である。 PCDの例示的なリソースのグループに関する無閉路有向グラフである。 PCDのリソースを管理するノードアーキテクチャの第2の態様の一般的な図である。 PCDのリソースを管理するノードアーキテクチャの第2の態様の具体的な図である。 PCDのリソースを管理するためのノードアーキテクチャを作成するための方法を示すフローチャートである。 PCDのリソースを管理するためのノードアーキテクチャを作成するための方法を示す図7の続きのフローチャートである。 PCD向けのソフトウェアアーキテクチャにおけるノード構造データを受信するための図7〜図8のサブ方法またはルーチンを示すフローチャートである。 PCD向けのソフトウェアアーキテクチャにおけるノードを作成するための図7〜図8のサブ方法またはルーチンを示すフローチャートである。 PCDのソフトウェアアーキテクチャにおけるクライアントを作成するための図10のサブ方法またはルーチンを示すフローチャートである。 PCD向けのソフトウェアアーキテクチャにおけるリソースに対するクライアント要求を作成するための方法を示すフローチャートである。 各プロセッサがそれ自体のリソースグラフのリソースを制御する、2つのプロセッサ間の通信経路を示す図である。 コントローラ、リソース電力マネージャ、マスタプロセッサ、低レベルドライバ、共用リソース、およびローカルリソースの間の関係を示す機能ブロック図である。 コントローラおよびトリガセットに関する詳細を示す機能ブロック図である。 プロセッサの例示的なアクティブ/スリープトリガセットを示す図である。 トリガセットを管理し、別途プロセッサをアウェイク状態のような第1のアプリケーション状態からスリープ状態のような第2のアプリケーション状態に移行させるための方法を示す論理フローチャートである。 トリガセットを管理し、別途プロセッサをスリープ状態のような第2のアプリケーション状態からアウェイク状態のような第3のアプリケーション状態に移行させるための方法を示す論理フローチャートである。 コントローラバッファメモリの機能ブロック図である。 プロセッサをアウェイク状態のような第1のアプリケーション状態からスリープ状態のような第2のアプリケーション状態に移行させるための代替方法を示す論理フローチャートである。 ノードスケジューラ、スケジューラデータベース、およびリソース電力マネージャと、他のノードアーキテクチャシステム要素との間の関係を示す機能ブロック図である。 スケジューラデータベースの例示的なコンテンツを示す図である。 クライアント、クライアント要求、スケジューラ、およびタイマーの間の関係を示す例示的なタイミング図である。 クライアント、クライアント要求、スケジューラ、タイマー、およびスリープセットを記録するコントローラの間の関係を示す例示的なタイミング図である。 1つまたは複数のユーザスレッド2301がスケジューラ2101を呼び出すことによってブロック1205A、1205Bにおいて2つの要求675を作成するときの例示的なタイミング図である。 ユーザスレッドが特定の要求を処理させスケジューリングされない要求コマンドを出すことをもはや望まないと、ユーザスレッドがクライアントを介して決断し得るときの、例示的なタイミング図である。 要求がスケジューリングされておりユーザスレッドが要求を出したが、スケジューリングされていない要求コマンドが出されたときにスケジューラが要求の処理を開始しなかった、例示的なタイミング図である。 要求がスケジューリングされておりユーザスレッド2301が要求を出し、スケジューリングされていない要求コマンドが出されたときにスケジューラ2101が要求の処理を開始した、例示的なタイミング図である。 単一のアプリケーションプログラムが実行されており、アクティブ状態の間に1つまたは複数の要求を処理した後で、スケジューラが新たな要求機能/機構を使用するスリープ状態にCPUが入り得る、単純なシナリオを示す図である。 スケジューリングされたスリープ状態の間の予想されないウェイクアップまたは割り込みをスケジューラがどのように管理するかの例示的なシナリオを示す図である。
「例示的な」という言葉は、「一例、実例または例として」を意味するように本明細書で使用される。「例示的な」ものとして本明細書で説明する態様は、必ずしも他の態様よりも好ましい、または有利であると解釈されるわけではない。
本明細書では、「アプリケーション」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能コンテンツを有するファイルを含むこともある。加えて、本明細書で言及する「アプリケーション」は、開封される必要があり得るドキュメント、またはアクセスされる必要がある他のデータファイルなど、本質的に実行可能ではないファイルを含むこともある。
「コンテンツ」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能コンテンツを有するファイルを含むこともある。加えて、本明細書で言及する「コンテンツ」は、開封される必要があり得るドキュメント、またはアクセスされる必要がある他のデータファイルなど、本質的に実行可能ではないファイルを含むこともある。
本明細書で使用される場合、「構成要素」、「データベース」、「モジュール」、「システム」などの用語は、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、実行中のソフトウェアを問わず、コンピュータ関連のエンティティを指すことが意図されている。たとえば構成要素は、プロセッサ上で作動しているプロセス、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラムおよび/またはコンピュータであってよいが、これらであることに限定されない。例を挙げると、コンピューティングデバイス上で作動しているアプリケーションとコンピューティングデバイスの両方が構成要素であり得る。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つ以上のマルチコアプロセッサが含まれ得る。
図1に示すように、ディスプレイコントローラ128およびタッチスクリーンコントローラ130が、マルチコアCPU110Aに結合される。オンチップシステム102の外部にあるタッチスクリーンディスプレイ132が、ディスプレイコントローラ128およびタッチスクリーンコントローラ130に結合される。また、PCD100には、マルチコア中央処理装置(「CPU」)110Aに結合された、ビデオコーダ/デコーダ(「コーデック」)134、たとえば位相反転線(「PAL」)エンコーダ、順次式カラーメモリ(「SECAM」)エンコーダ、全米テレビジョン方式委員会(「NTSC」)エンコーダ、または任意の他のタイプのビデオエンコーダ134も含まれる。ビデオ増幅器136が、ビデオエンコーダ134およびタッチスクリーンディスプレイ132に結合される。ビデオポート138がビデオ増幅器136に結合される。図2に示すように、ユニバーサルシリアルバス(「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は、高周波(「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電源を含む。
PCD100の上記の要素の中には、ハードウェアを含み得るものがある一方、ソフトウェアを含み得るものもあり、さらに、ハードウェアとソフトウェアの組合せを含み得るものもある。「リソース」という用語は、本明細書において、ハードウェアであるか、ソフトウェアであるか、それらの組合せであるかを問わず、プロセッサによって制御可能な任意のそのような要素を指すために使用される。リソースは、一態様において、そのような要素の機能のカプセル化として定義され得る。別途示される場合を除いて、「プロセッサ」または「マスタプロセッサ」という用語は、本明細書において、CPU110、グラフィックスプロセッサ110B、アナログ信号プロセッサ126のようなプロセッサを指すために、またはソフトウェア、ファームウェアまたは同様の制御論理の支配下で動作する任意の他のプロセッサ、コントローラまたは同様の要素を指すために使用される。
以下でさらに詳細に説明するように、リソースの一例は、プロセッサ上で実行するソフトウェア要素である。たとえば、実行アプリケーションプログラムに関係するスレッドなどのプロセッサ上での実行のスレッドが、リソースに対する「要求」を出させることによって、リソースにアクセスすることができる。以下で説明するように、リソース要求は、本開示において「フレームワーク」と呼ばれるソフトウェアベースのシステムを通じて処理される。
「クライアント」という用語は、本開示において、リソースを要求する機能をもたらす要素を指すために広く使用される。したがって、これらの用語が本明細書で使用される中、スレッドはリソース要求を出す目的で、クライアントを作成または利用することができる。場合によっては、リソースは、別のリソースに対するリソース要求を出させることができるように、クライアントを作成または使用できることに留意されたい。以下でさらに詳細に説明するように、そのような他のリソースを、要求側リソースと被要求側リソースとの間の従属関係により、本明細書では「従属」リソースと呼ぶことがある。リソースおよびクライアントは、メモリにおいてデータ構造によって表され得る。
リソースはマルチプロセッサPCD100内の特定のプロセッサによって制御されるので、PCD100内のすべてのプロセッサがPCD100内のすべてのリソースにアクセスできるわけではない。図2は、PCD100内の第1のプロセッサ202が、PCD100内の第2のプロセッサ206によって制御されるリソース電力マネージャ157に対するリソース要求203を出すのが望ましい場合の一例を示している。第1のプロセッサ202が複数のリソース105A1、105A2を制御することもできることに留意されたい。同様に、第2のプロセッサ206が複数の追加リソース105B1、105B2を制御することができることに留意されたい。
第1のプロセッサ202がたとえばビデオプレーヤアプリケーションプログラムに関係するスレッド208を実行している場合、スレッド208は、第1のプロセッサ202のパフォーマンスを高める第1のプロセッサ202の1つまたは複数の動作パラメータの調整を求めることがある。(明快にするために、スレッド208およびリソース電力マネージャ157はそれらのそれぞれのプロセッサ202および206に常駐するものとして概念的に示されているが、当業者は、そのような要素が、十分に理解されているコンピューティング原理に従ってプロセッサのメモリスペースにおいてプロセッサによって実行されるか、あるいは動作することを理解する。)そのような動作パラメータは、たとえば、クロック速度およびバス速度を含み得る。
たとえば、様々なプロセッサが、同じバスクロックを使用し得るが、プロセッサのうちのたった1つが、バスクロックの直接(ハードウェアレベル)制御を有し得る。ビデオの再生は一般に、いくつかの他のタスクよりも処理能力集中度の高いタスク(more processing power-intensive task)であるので、クロック速度を上げると、たとえばビデオプレーヤアプリケーションプログラムによるパフォーマンスが向上することがある。処理能力は一般に百万命令毎秒(「MIPS」)で表現されるので、スレッド208は、一定数のMIPSを求めることができる。リソース電力マネージャ157は、指定された数のMIPSに対する要求に応答して、第1のプロセッサ202が要求されたMIPSレベルで動作するのを促進するクロック速度、バス速度または他のパラメータを表し得る信号210の変更をもたらすアルゴリズムを含み得る。
第1のプロセッサ202が第2のプロセッサ206と通信する場合の手段であるバスまたはプロトコルに固有のアプリケーションプログラムインターフェース(API)を通じて、スレッドがリソース電力マネージャ157にアクセスすることが可能な場合がある。しかしながら、以下で説明するフレームワークは、リソース固有およびバス固有のAPIよりも均一なリソース要求処理方法を提供することができる。後述のように、フレームワークを介して、リソース要求が出され、要求がリソース要求の発信元プロセッサと同じプロセッサによって制御されるリソースに対するものであるか、それとも異なるプロセッサによって制御されるリソースに対するものであるかにかかわらず、均一に応じられる。リソース要求の発信元プロセッサと同じプロセッサによって制御されるリソースは「ネイティブ」リソースと呼ばれ得る。リソース要求の発信元プロセッサとは異なるプロセッサによって制御されるリソースは、本明細書において「リモートリソース」または「分散リソース」と呼ばれ得る。
加えて、リモートリソースに対して要求を出すと、時間遅延または待ち時間の形の処理オーバーヘッドが生じる。すなわち、リソース要求に関する1つまたは複数のメッセージをプロセッサ間で送るにはある長さの時間が必要である。いくつかの例では、単一のリソース要求によって複数のプロセッサ間メッセージが生成されることがある。
図3は、PCD100のソフトウェアまたはハードウェア(または両方)を表す機能ブロックを含む図である。線「A」の左側のブロックは、CPU110Aによって制御されるPCD100のリソースを表す。そのようなリソースは、一般に第1のハードウェア要素(ハードウェア要素#1)とも呼ばれるCPU110A自体、一般に第2のハードウェア要素(ハードウェア要素#2)とも呼ばれるCPU110Aのクロック442、一般に第3のハードウェア要素(ハードウェア要素#3)とも呼ばれるバスアービタまたはスケジューラ422、一般に第1のソフトウェア要素(ソフトウェア要素#1)とも呼ばれるバスプログラムA-444A、一般に第2のソフトウェア要素(ソフトウェア要素#2)とも呼ばれるバスプログラムB-444B、一般に第3のソフトウェア要素(ソフトウェア要素#3)とも呼ばれるクロックプログラムAHB、および一般にキープレスとして示されるソフトウェア要素によって監視されるアクションまたは機能448を含み得る。
CPU110Aは、上記のリソースを制御するか、または上記のリソースにアクセスすることができ、その理由は、それらのリソースがCPU110Aのメモリスペース内にあり、CPU110Aがそれらのリソースにアクセスするのを阻むセキュリティ上の制限などの他の制限が存在しないことにある。たとえば、CPU110Aは、それらのリソースのハードウェアレジスタを制御すること、または当該ハードウェアレジスタにアクセスすることが可能であり得る。PCD100は、上記のリソース以外のリソースを制御するか、または当該リソースにアクセスすることができる他のCPU110(たとえば、図2参照)を含み得ることに留意されたい。
フレームワーク管理プログラム440は、コンピュータ命令のライブラリを含むことができ、リソースの機能をカプセル化するノードを管理する。すなわち、リソースに間接的にアクセスするようにノードにアクセスすることができる。便宜上、本明細書では、リソースを含むもの、備えるもの、有するものなどとして、リソースの機能をカプセル化するノードに言及することがある。各ノードは、1つまたは複数のリソースを含み得る。ノードは、ソフトウェアコード、ファームウェア、または同様の媒体において定義されることがあり、データ構造として、たとえばメモリ112(図1)においてPCD100の動作中にインスタンス化され得る。
ノード601は、起動、電源投入、初期化、立上げなどのシーケンス中、またはPCD100の動作中における任意の他の適切な時間にインスタンス化され得る。本明細書における、リソースをインスタンス化すること、リソースに対する要求を出すこと、または別のやり方でリソースと対話することへの言及は、そのリソースを含むノードと対話することを意味するものとして理解されるべきことに留意されたい。本開示の残りについては、一般的なノードまたは不特定のノードが、図5に関して以下で説明するように参照番号601により指定される。
ノード601は、たとえば、第1のハードウェア要素または中央処理装置110に概ね対応する単一のリソースを有する第1のノード602を含み得る。本開示で説明するソフトウェアアーキテクチャでは、ノード601の各リソースは、1つまたは複数の英数字文字を含む一意の名前を与えられ得る。図3に示す例示的な実施形態では、第1のノード602のリソースは、「core/cpu」というリソース名を割り当てられている。この例示的なリソース名は、当業者に知られている従来型のファイル命名構造に概ね対応する。ただし、当業者が認識するように、英数字文字および/または記号の任意の他の組合せを含む他のタイプのリソース名も、本開示の範囲内に十分に入る。
ノード601は、たとえば、複数のリソースを有する第2のノード622をさらに含み得る。この例示的な実施形態では、第2のノード622は、バスアービタまたはスケジューラ422に対応する単一のハードウェア要素を含む第1のリソースを有する。第2のノード622の第2のリソースは、バスプログラムA 444Aの第1のソフトウェア要素に概ね対応するソフトウェア要素を含む。第2のノード622の第3のリソースは、バスプログラムB 444Bの第2のソフトウェア要素に概ね対応する別のソフトウェア要素を含む。当業者は、所与のノード601に関するリソースおよびリソースタイプの任意の組合せおよび任意の数が本開示の範囲内に十分に入ることを認識する。
図3はまた、2つのソフトウェア要素448、450のアクションまたは機能に概ね対応する第1のクライアント648を示している。図3に示す例示的な実施形態では、第1のクライアント648は、ポータブルコンピューティングデバイス100によってサポートされる特定のアプリケーションプログラムモジュール105内で生じ得るキープレスアクションに概ね対応する。ただし、キープレス以外のソフトウェア要素の他のアクションおよび/または機能が本開示の範囲内に十分に入ることを、当業者は認識する。クライアント648およびそれらのそれぞれの作成については、図11に関連して以下でさらに詳しく説明する。
図3はまた、特定のアーキテクチャの要素間の関係を示している。たとえば、図3は、クライアント648と第1のノード602との間の関係を示している。詳細には、第1のクライアント648は、破線で示されているクライアント要求675Aを生成することができ、この要求は、リソース「/core/cpu」を含む第1のノード602によって管理または処理される。一般に、所定のまたは決められた数のタイプのクライアント要求675がある。クライアント要求675については、図12に関連して以下でさらに詳しく説明する。
図3に表示されている他の関係は、破線で示されている従属性680を含む。従属性は、別のノード601のそれぞれのリソースの間の関係である。従属関係は通常、第1のリソース(A)に情報を提供し得る第2のリソース(B)に第1のリソース(A)が依存していることを示す。この情報は、第2のリソース(B)によって実行された動作の結果である場合、またはそれは、第1のリソース(A)が必要とするステータス情報を含むにすぎない場合、またはそれらの任意の組合せである場合がある。第1のリソース(A)および第2のリソース(B)は、同じノード601の一部である場合、または異なるノード601の一部である場合がある。クライアント要求675が、上記のキープレスアクションの例のような実行のスレッドからだけではなく、他のノード601からも生じ得ることに留意されたい。従属ノード601から情報を取得するために、ノード601は、クライアント要求675をその従属ノード601に出すことができる。したがって、従属性を示す破線680は、潜在的なクライアント要求675の方向を示すこともできる。
図3では、第1のノード602で始まり、第2のノード622まで延びている従属性矢印680Bによって示されるように、第1のノード602は第2のノード622に従属している。図3はまた、従属性矢印680Aによって示されるように、第1のノード602が第3のノード642にも従属していることを示している。図3はまた、従属性矢印680Cによって示されるように、第2のノード622が第4のノード646に従属していることを示している。当業者は、図3の破線矢印で示されている従属性680が本質的に例にすぎないこと、およびそれぞれのノード601間の従属性の他の組合せが本開示の範囲内にあることを認識する。
フレームワーク管理プログラム440は、限定はしないが、図3に示すクライアント要求675、および従属性680を含む上述の関係を維持することを担当する。従属性などのいくつかのそのような関係は、PCD起動時(すなわち、電源投入、初期化、立上げなど)に、ノードインスタンス化プロセスを開始するためにそのような起動時にフレームワーク管理プログラム440がアクセスするPCD100内のソフトウェアコードにおいてリソースおよびそれらのノード601が定義されている方法によって存在する。クライアント要求675などの他のそのような関係は、アプリケーションプログラムがリソースを呼び出すアプリケーションプログラムスレッドの実行中など、ノード601がインスタンス化された後に生じる。クライアント要求675がノード601以外のアプリケーションプログラムスレッドまたは同様の要素の実行から生じる(たとえば、クライアント要求675A)か、それともノード601から生じるかを問わず、クライアント要求675は、フレームワーク管理プログラム440を通じて方向付けられる。フレームワーク管理プログラム440は、ノード601間の情報の移転を方向付ける。概念的に、フレームワーク管理プログラム440は、複数のスレッドがノード601と本質的に同時に通信する場合の手段である行列として働く。スレッドによって伴うデータは異なることがあるが、同じフレームワーク管理プログラムソフトウェアコードが複数のスレッドに応じ得る。
以下でさらに詳しく説明するように、フレームワーク管理プログラム440はノード601を、そのノードの従属ノードがインスタンス化され次第、すなわち、任意の所与のノード601の従属性680が解決されたとき、インスタンス化することができる。フレームワーク管理プログラム440は、PCD100のソフトウェアアーキテクチャにおいて定義されているすべてのノード601をインスタンス化しようと試みる。従属性をサポートするリソースが、存在するか、従属性680に関係する情報を処理する準備ができた状態にあるときに、従属性680は完全になるか、または解決される。
たとえば、第1のノード602と第3のノード642との間に存在する従属関係680Aを理由に、単一のリソース「/clk/cpu」を含む第3のノード642がインスタンス化されていない場合には、単一のリソース「/core/cpu」を含む第1のノード602がフレームワーク管理プログラム440によってインスタンス化され得ない。第3のノード642がフレームワーク管理プログラム440によってインスタンス化されると、従属関係680Aを理由に、フレームワーク管理プログラム440は第1のノード602をインスタンス化することができる。
フレームワーク管理プログラム440が特定のノード601を、その従属性680のうちの1つまたは複数が不完全または未解決であるためにインスタンス化することができない場合、フレームワーク管理プログラム440は、うまくインスタンス化されたノード601に対応するステップを引き続き実行する。フレームワーク管理プログラム440は通常、従属リソースが作成されていない不完全な従属性のために存在し得ない特定のノード601に対するコールを飛ばし、不完全なステータスを反映する当該コールに対するメッセージを返信する。
図1に示すようなマルチコア環境では、フレームワーク管理プログラム440は、図1の第0のコア222、第1のコア224、および第Nのコア226のような別個のコアでノード601を作成またはインスタンス化することができる。ノード601は一般に、ノード601が互いに従属していない限り、かつ後述するように特定のノードの対応する従属性のすべてが完全である場合に、マルチコア環境において別個のコアで並行して作成され得る。マルチプロセッサ環境において、ノード601は、図1のCPU110A、グラフィックスプロセッサ110Bなどのような様々なプロセッサ上で作成またはインスタンス化され得る。すなわち、あるプロセッサのメモリスペース内に存在するノード601もあれば、別のプロセッサのメモリスペース内に存在するノード601もある。ただし、一方のプロセッサ上のノード601に、他方のプロセッサ上のノード601がフレームワーク管理プログラム440のみを介してアクセスすることは可能ではない場合があることに留意されたい。
上述の(メイン)フレームワーク管理プログラム440に類似した遠隔フレームワーク管理プログラム300が、フレームワーク管理プログラム440と並行して存在し得る。遠隔フレームワーク管理プログラム300は、フレームワーク管理プログラム440に協力するか、またはフレームワーク管理プログラム440と協働して、様々なプロセッサ上のノード601間のプロセッサ間情報転送を調整する。すなわち、遠隔フレームワーク管理プログラム300は、関係するノード601が様々なプロセッサ上に存在する場合に、フレームワーク管理プログラム440が従属性およびクライアント要求などの上述の関係を維持するのを助ける。
したがって、フレームワーク管理プログラム440および300の複合効果によって、あるプロセッサ上のノード601に、別のプロセッサ上のノード601がアクセスすることはできないようになる。さらに、関係するノード601が同じプロセッサ上に存在するか、それとも異なるプロセッサ上に存在するかを問わず、フレームワーク管理プログラム440および300の組合せは、本開示においてフレームワーク管理プログラム440に起因する機能のすべてを実行することができる。そのようなマルチプロセッサの実施形態では、フレームワーク管理プログラム300および440が含むソフトウェアの個々のコピーは、プロセッサの各々のドメインに常駐し得る。したがって、各プロセッサは同じフレームワーク管理プログラムソフトウェアにアクセスできる。
図4は、上述のノード602、622、642、および646を無閉路有向グラフ(「DAG」)400の形式で好都合に再構成している。グラフ400は、上述のソフトウェアアーキテクチャを定義する別の方法である。グラフ理論の語彙では、グラフ400の頂点はノード601に対応し、グラフ400の端はクライアント要求675に対応し、隣接するノードまたは頂点はリソース従属性を表す。当業者は、グラフ400が従属性の結果として有向グラフであり、フレームワーク管理プログラム440が、リソースAがリソースBに従属し、リソースBがリソースAに従属する閉路が定義されるのを防止するので、無閉路であることを認識しよう。すなわち、フレームワーク管理プログラム440は、互いに従属するように(誤って)定義される2つのノード601をインスタンス化しない。
以下で説明するように、各ノード601はアクセスされるときに(トランザクション処理の意味で)ロックされるので、グラフの無閉路特性は、デッドロックを防止するうえで重要である。第1のスレッドが2つのノード601のうちの一方にアクセスしロックするのと同時に第2のスレッドがこれら2つのノード601のうちの他方にアクセスしロックした場合に、これら2つのノード601が互いに従属するならば、両方のスレッドが立往生することになる。
一方、ソフトウェア開発者またはソフトウェアアーキテクチャを定義することに関与する他のそのような人が、互いに従属する2つのリソースをソフトウェアアーキテクチャで定義するのが望ましいと考える比較的まれな場合には、2つの(またはそれよりも多い)リソースを互いに同じノード601に含めることができる。同じノードにおける2つのリソースは、同じロック状態を共有する。少なくとも部分的にはこの理由により、ソフトウェア開発者または他のそのような人は、ノード622などの複数リソースノードをアーキテクチャで定義することを選択し得る。
本開示は明快にするために、かつ便宜上、ノード601の「リソース」ではなく「ノード」601に言及しているが、クライアント要求はノードではなく特定のリソースに方向付けられ得ることを理解されたい。言い換えれば、ノード601は、上述のように、1つまたは複数のリソースの機能をカプセル化するデータ構造であってよく、クライアントまたはクライアント要求の他の要求側、たとえば別のノード601から見て透過であり得る。クライアントから見て、要求はノードではなくリソースに対して出される。同様に、クライアントから見て、状態クエリ、イベント、またはアーキテクチャの他の要素は、ノードではなくリソースに関連付けられる。
例示的なグラフ400などのリソースグラフは、図6〜図10に以下で関して説明するように、従属性に従ったノード601のインスタンス化を理解するうえで有用である。ノード642および646などのリーフノードは、リーフノードには従属性がないので、非リーフノードの前にインスタンス化される。一般に、ノード601は、それに従属するノードがインスタンス化され得る前にインスタンス化されなければならない。さらに、リソース要求に応じることは、無閉路有向グラフをトラバースすることに対応し、無閉路有向グラフでは頂点がノード601に対応し、端がクライアント要求675に対応し、隣接するノードまたは頂点がリソース従属性に対応することがわかる。
マルチプロセッサPCD100において、第1のプロセッサは第1のリソースグラフにおけるノード601の第1のセットにアクセスすることができ、当該セットを制御することが可能であり得る一方、第2のプロセッサは第2のリソースグラフにおけるノード601の第2のセットにアクセスすることができ、当該セットを制御することが可能であり得、この場合に第1のリソースグラフおよび第2のリソースグラフはいかなるリソースも共有しない、すなわち、これらは相互に排他的なリソースである。すなわち、そのような環境では、各プロセッサは、他のプロセッサがアクセスできないリソースおよび他の要素の間の関係を定義するそれ自体のリソースグラフを有する。本開示の分散リソース管理は、2つ以上のプロセッサがそれぞれ、それら自体のリソースグラフにおけるリソースにアクセスでき、他のプロセッサのリソースグラフにおけるリソースにアクセスできない場合に、従属性およびクライアント要求などの上述の関係を維持することに関係する。
リソースへのアクセスに対する上記の制限は、いくつかの実施形態では、ハードウェア構成によって制限され得る。すなわち、プロセッサは、レジスタなどのハードウェアデバイスにプロセッサが影響を与え得る手段を有さないことがあり、その理由は、ハードウェアデバイスが別のプロセッサのメモリスペースによって、または当該メモリスペースにおいて制御されることにある。代替的に、または追加として、リソースへのアクセスに対する制限は、ソフトウェアで課せられ、その理由は、プロセッサをセキュリティリスク(たとえば、別のプロセッサに感染し得るウイルス)にさらすのを最小化することなどである。
図5は、図1のPCD100のリソースを管理するシステム向けのソフトウェアアーキテクチャの別の態様の一般的な図500B1である。この態様は、明快にするために、PCD100ならびに関係するすべてのリソースおよび他の要素が同じプロセッサによって制御される、すなわちそれらが同じリソースグラフに含まれるアーキテクチャの文脈で記述している。この一般的な図では、各ノード601の1つまたは複数のリソースは、一意の名前を与えられていない。図5のノードまたはリソースグラフ500B1は、アーキテクチャまたはフレームワーク管理プログラム440によってサポートされるノード601、クライアント648、イベント690、および照会機能695のみ含む。各ノード601は、卵形およびノード601内のリソース間のそれぞれの従属性を表す特定の方向を有する矢印680により示されている。
図5はまた、第1のノード601Aのクライアント648がどのようにしてクライアント要求675を第1のノード601Aに出し得るかを示している。これらのクライアント要求675が出された後、第2のノード601Bは、イベント690をトリガするか、応答を照会695に提供することができ、この場合、イベント690および照会695に対応するメッセージがクライアント648に還流する。
図6は、図1のPCD100のリソースを管理するシステム向けのソフトウェアアーキテクチャの前述の態様のより具体的な図500B1である。図6は、具体的でありながらも例示的なリソース名を有するノード601、ならびにクライアント648、イベント690、および照会機能695(図3のそれらに対応するもの)のみ含むノードまたはリソースグラフ500B2を示している。各ノード601は、卵形およびノード601内のリソース間のそれぞれの従属性を表す特定の方向を有する矢印680により示されている。
たとえば、第1のノード602は、第1のノード602が第2のノード622の3つのリソースに従属していることを示す従属性矢印680Bを有する。同様に、第2のソフトウェア要素444Bを含み、図11Cにおいて全体的に参照文字「C」で表される第3のリソース「/bus/ahb/sysB/」は、第3のリソース(C)が第4のノード646の単一の「/clk/sys/ahb」リソースに従属していることを示す従属性矢印680Cを有する。
図6はまた、1つまたは複数のイベント690または照会機能695を含み得るノード601からの出力データを示している。照会機能695は、イベント690と類似している。照会機能695は、固有であるか固有でない照会ハンドルを有し得る。照会機能は一般的に、外部では識別されず、一般的に照会機能は状態を有さない。照会機能695を使用して、ノード601の特定のリソースの状態を判断することができる。照会機能695およびイベント690は、既存クライアント648との関係を有することがあり、これらの関係は、それぞれのイベント690および照会機能695からの情報が特定のクライアント648に渡されることを示す方向矢印697によって表されている。
図5〜図6のノードまたはリソースグラフ500Bは、プロセッサの制御下のメモリに存在し、フレームワーク管理プログラム440によって管理される関係を表している。ノードまたはリソースグラフ500Bは、フレームワーク管理プログラム440によって管理されるそれぞれの要素間の関係を識別するための、およびソフトウェアチームによるトラブルシューティングのための有用なツールとして、フレームワーク管理プログラム440によって自動生成され得る。
図7は、PCD100のリソースを管理するためのソフトウェア構造を作成またはインスタンス化するための方法1000Aを示すフローチャートである。この方法は、明快にするために、関係するすべてのリソースおよび他の要素が同じプロセッサによって制御される、すなわちそれらが同じリソースグラフに含まれるアーキテクチャの文脈で記述している。
ブロック1005は、PCD100のリソースを管理するための方法またはプロセス1000の第1のルーチンである。ブロック1005において、ノード構造データを受信するためにフレームワーク管理プログラム440によってルーチンが実行され得る。ノード構造データは、特定のノード601が他のノード601との間で有し得る従属性を略述する従属性配列を含むことができる。ノード構造データおよびこのルーチンまたはサブ方法1005に関するさらなる詳細は、図9に関連して以下でより詳細に説明する。
次に、ブロック1010において、フレームワーク管理プログラム440は、ブロック1005において受信されたノード構造データの一部である従属性データをレビューすることができる。決定ブロック1015において、フレームワーク管理プログラム440は、ノード構造データがリーフノード601を定義しているか否かを判断することができる。リーフノード601は一般に、図3〜図4のノード642および646のように、ノード構造データに基づいて作成されるノードが従属性をまったく有さないことを意味する。決定ブロック1015への照会が肯定である場合、最新ノードを作成するためのノード構造データが従属性をまったく有さないことを意味し、フレームワーク管理プログラム440はルーチンブロック1025に続く。
決定ブロック1015への照会が否定である場合、「いいえ」の分岐が決定ブロック1020に至り、フレームワーク管理プログラムがノード構造データ内のハードな従属性のすべてが存在するか否かを判断する。ハードな従属性は、リソースがそれなしでは存在できないものを含むことができる。一方、ソフトな従属性は、リソースが随意のステップとして従属リソースを使用できるものを含むことができる。ソフトな従属性は、ソフトな従属性を有するノード601またはノード601のリソースが、ソフトな従属性が存在しないときでもノードアーキテクチャ内に作成またはインスタンス化され得ることを意味する。
ソフトな従属性の一例として、複数のリソースを含むリソース指向ノード601の動作に不可欠ではない最適化特徴が挙げられる。フレームワーク管理プログラム440は、存在するすべてのハードな従属性に関して、作成されないソフトな従属性を有するノードまたはリソースに関してソフトな従属性が存在しないときでも、ノードまたはリソースを作成またはインスタンス化することができる。コールバック特徴を使用してソフトな従属性を参照することができ、それにより、ソフトな従属性をフレームワーク管理プログラム440が利用できるようになったとき、フレームワーク管理プログラム440は、ソフトな従属性が現在利用可能であるという、ソフトな従属性を参照する各コールバックを知らせる。
決定ブロック1020への照会が否定である場合、「いいえ」の分枝がブロック1027に至り、ノード構造データがフレームワーク管理プログラム440によってメモリなどの一時記憶装置に記憶され、フレームワーク管理プログラム440はこのインスタンス化されないノードに関連するコールバック特徴を作成する。
決定ブロック1015への照会が肯定である場合、「はい」の分枝はルーチン1025に至り、ルーチンブロック1005において受信されたノード構造データに基づいてノード601が作成またはインスタンス化される。ルーチンブロック1025のさらなる詳細については、図9に関連して以下で説明する。次に、ブロック1030において、フレームワーク管理プログラム440は、新規作成されたノード601を、その一意のリソース名を使用して公開し、それにより他のノード601が、新規作成されたノード601に情報を送ること、または新規作成されたノード601から情報を受信することができるようになる。
次に図7の続きのフローチャートである図8を参照すると、ブロック1035において、フレームワーク管理プログラム440は、新規作成されたノード601に従属する他のノード601に対し、新規作成されたノード601がインスタンス化されており、情報を送受信する準備ができていることを通知する。例示的な一態様によれば、図5のノード601Bのような従属ノードが作成されたときにただちに通知が開始される、すなわち、通知が再帰的に実行される。したがって、図5のノード601Bが構築された場合、ノード601Aはただちに通知される。この通知により、(ノード601Bはノード601Aが最後に従属するものであったので)ノード601Aを構築することができる。ノード601Bの構築により他のノード601が通知される、といった状況が生じ得る。ノード601Bに従属する最後のリソースが完成するまで、ノード601Bは完成しない。
第2の、前記実装形態よりも若干複雑な実装形態では、通知のすべてを個別の通知キューに配置し、次いで一時点で開始するキューを通読する(run through)、すなわち、通知は反復的に実行される。したがって、図5のノード601Bが構築されたとき、ノード601Aに対する通知がリストに渡される。次いで、そのリストが実行され、ノード601Aが通知を受ける。これにより、(図5に示されていない、ノード601A以外の)他の追加ノード601に対する通知が同じリストに掲載され、次いでその通知は、ノード601Aに対する通知が送られた後に送られる。(ノード601Aに対する通知以外の)他のノード601に対する通知は、ノード601Bおよびノード601Aに関連する作業がすべて完了するまで生じない。
論理的には、これら2つの実装形態は同等であるが、実施されたときのメモリ消費特性が異なる。再帰的実現は単純であるが、恣意的なスタックスペース量を消費する可能性があり、スタック消費は従属性グラフの深さの関数である。反復的実装形態はこれよりも若干複雑になっており、これよりも若干多くのスタックメモリ(通知リスト)を必要とするが、図5に示すように従属性グラフの深さにかかわりなくスタック使用は一定である。
また、ブロック1035におけるノード作成の通知は他のノードに限定されない。これはエイリアス構築に内部使用できる。他のノードにとどまらず、システム500Ａにおける任意の恣意的な要素が同じ機構を使用して、ノードが利用可能になったときの通知を要求することができる。ノードと非ノードの両方が同じ通知機構を使用することができる。
決定ブロック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における活動のログ記録は固有のものであり、デバッギングおよび誤りトラブルシューティングで使用されるような、大きい利点をもたらすことができる。ノードアーキテクチャ500Ａの別の固有の態様は、別個のチームが互いに独立して異なるハードウェア要素および/またはソフトウェア要素に取り組めることであり、この場合、各チームは、他のチームおよび/または相手先商標製造会社(OEM)によって割り当てられたさほど有意義ではなく一般にまぎらわしいリソース名を翻訳するためのテーブルを作成する必要なく、一意で追跡しやすいリソース名を使用することができる。
次に、決定ブロック1055において、フレームワーク管理プログラム440は、フレームワーク管理プログラム440によって記録された活動のログが要求されているか否かを判断する。決定ブロック1055への照会が否定である場合、「いいえ」の分枝はプロセスの最後に至り、プロセスはルーチン1005に戻る。決定ブロック1055への照会が肯定である場合、「はい」の分枝はブロック1060に至り、フレームワーク管理プログラム440は、有意義なリソース名およびリソース名によって実行されるそれぞれの活動を含む活動ログを、プリンタまたはディスプレイスクリーンおよび/または両方などの出力デバイスに送る。次いで、プロセスは上述のルーチンブロック1005に戻る。
図9は、PCD100のソフトウェアアーキテクチャを定義するノード構造データを受信するための図7のサブ方法またはルーチン1005を示すフローチャートである。受信方法は、たとえば、PCD100の起動時または初期化時など、任意に適切な時間に生じ得る。そのような場合、アーキテクチャに従ってノード601をインスタンス化するのに備えてメモリから対応するソフトウェアコードをプロセッサが読み取るときに、ノード構造データが受信される。
ブロック1105は、図7のサブ方法またはルーチン1005における第1のステップである。ブロック1105において、フレームワーク管理プログラム440は、図3のCPU110およびクロック442のようなソフトウェア要素またはハードウェア要素の一意の名前を受信することができる。前に説明したように、ノード601は少なくとも1つのリソースを参照しなければならない。各リソースはシステム500Aにおいて一意の名前を有する。システム500A内の各要素が一意の名前により識別され得る。各要素は、文字の観点から一意の名前を有する。言い換えれば、一般に、同じ名前を有する2つの要素はシステム500A内に存在しない。システムの例示的な態様によれば、ノード601のリソースは一般にシステム全体で一意の名前を有することができるが、クライアントまたはイベントの名前は、要望に応じて一意であってもよいが、一意である必要はない。
便宜上、限定はしないが、CPU110の「/core/cpu」およびクロック442の「/clk/cpu」のような、一意の名前を作成するための前スラッシュ「/」文字を用いる従来型のツリーファイル命名構造またはファイル命名「メタファー」を用いることができる。ただし、当業者が認識するように、英数字文字および/または記号の任意の他の組合せを含む他のタイプのリソース名も、本開示の範囲内に十分に入る。
次に、ブロック1110において、フレームワーク管理プログラム440は、作成されるノード601の1つまたは複数のリソースに関連する1つまたは複数のドライバ機能に関するデータを受信することができる。ドライバ機能は一般に、特定のノード601に関する1つまたは複数のリソースによって完了するアクションを含む。たとえば、図6において、ノード602のリソース/core/cpuに関するドライバ機能は、要求されている所要量の処理を提供するために必要とする量のバス帯域幅およびCPUクロック周波数を要求することができる。これらの要求は、ノード642およびノード622におけるリソースのクライアントを介して行われる。ノード642における/clk/cpuに関するドライバ機能は通常、ノード602の/core/cpuリソースから受信した要求に従って物理クロック周波数を実際に設定することを担当する。
ブロック1115において、フレームワーク管理プログラム440はノード属性データを受信することができる。ノード属性データは一般に、安全性(ユーザ空間アプリケーションを介してノードにアクセスできるか)、遠隔性(システムにおいて他のプロセッサからノードにアクセスできるか)およびアクセス可能性(リソースは複数の並列クライアントをサポートできるか)などのノードポリシーを定義するデータを含む。フレームワーク管理プログラム440はまた、要求評価またはログ記録ポリシーなど、リソースがデフォルトフレームワーク行動を無効にすることを許容する属性を定義することができる。
その後、ブロック1120において、フレームワーク管理プログラム440は、作成される特定のノード601に関するカスタマイズされたユーザデータを受信することができる。ユーザデータは、「C」プログラミング言語に関して当業者によって理解されている空の「スター(star)」フィールドを含むことができる。ユーザデータはまた、「トラストミー(trust me)」フィールドとして当業者に知られている。例示的なカスタマイズされたユーザデータは、限定はしないが、テーブル、たとえば周波数テーブル、レジスタマップなどを含むことができる。ブロック1120において受信されたユーザデータは、システム500Bによって参照されないが、リソースのカスタマイズを、カスタマイズがフレームワーク管理プログラム440によって認識されていないか、十分にサポートされていない場合に許容する。このユーザデータ構造は、特別な使用または特定の使用のために拡張されることが意図された「C」プログラミング言語における基本クラスである。
当業者は、特定のクラスの特定の使用を拡張するための他の種類のデータ構造が、本開示の範囲内にあることを認識する。たとえば、プログラミング言語「C++」(C-プラス-プラス)において、同等の構造が、ノード601内のリソースの拡張機構になるキーワード「パブリック(public)」を含むことができる。
次に、ブロック1125において、フレームワーク管理プログラム440は従属性配列データを受信することができる。従属性配列データは、作成されるノード601が従属する1つまたは複数のリソース601の一意かつ特定の名前を含むことができる。たとえば、図6の第1のノード602が作成されている場合、このブロック1125において、従属性配列データは、第1のノード602が従属する第2のノード622の3つのリソースのリソース名および第3のノード642の単一のリソース名を含むことができる。
続いて、ブロック1130において、フレームワーク管理プログラム440はリソース配列データを受信することができる。リソース配列データは、作成される最新ノードに関するパラメータ、たとえば、図7B〜図7Cの第1のノード602が作成されている場合にこの第1のノード602に関連するパラメータを含むことができる。リソース配列データは、以下のデータのうちの1つまたは複数を含むことができる。他のリソースの名前、ユニット、最大値、リソース属性、プラグインデータ、およびブロック1120のカスタマイズユーザデータに類似した任意のカスタマイズされたリソースデータ。プラグインデータは、一般に、ソフトウェアライブラリから取り出された機能を識別し、通常、作成される特定のノードまたは複数のノードによってサポートされ得るクライアントタイプを列挙する。プラグインデータはまた、クライアントの作成および破壊のカスタマイズを可能にする。ブロック1130の後、プロセスは図7のブロック1010に戻る。
図9において、属性データブロック1115、カスタマイズされたユーザデータブロック1120、および従属性配列データブロック1125は、これらの特定のステップが随意であり、所与のノード601に必要なものではないことを示すために破線で示されている。一方、一意の名前ブロック1105、ドライバ機能ブロック1110、およびリソース配列データブロック1130は、ルーチン1005のこれらのステップがノード601を作成するために一般に重要であることを示すために実線で示されている。
図10は、PCD100向けのソフトウェアアーキテクチャにおけるノードを作成するための図7のサブ方法またはルーチン1025を示すフローチャートである。ルーチンブロック1205は、例示的な一実施形態によるノード601をインスタンス化または作成するためのサブ方法またはルーチン1025における第1のルーチンである。ルーチンブロック1205において、インスタンス化されているノード601に関連する1つまたは複数のクライアント648が、このステップで作成される。ルーチンブロック1205に関するさらなる詳細については、図11に関連して以下でさらに詳しく説明する。
ブロック1210において、フレームワーク管理プログラムは、ブロック705のノード構造データに対応する1つまたは複数のリソースを作成またはインスタンス化することができる。次に、ブロック1215において、フレームワーク管理プログラム440は、ルーチンブロック1005のルーチンブロック1110において受信されたドライバ機能をアクティブ化することができる。例示的な一態様によれば、ドライバ機能は、ルーチンブロック1005のリソース配列データブロック1130において受信された最大値を使用してアクティブ化され得る。別の好ましい例示的な態様によれば、各ドライバ機能は、ルーチン1005からノード構造データとともに渡された随意の初期値によりアクティブ化され得る。初期データが提供されない場合、ドライバ機能は最小値0に初期設定される。ドライバ機能はまた、通常は、初期設定されていることがわかるようにアクティブ化される。これによりリソースは、初期設定に固有であるが、通常動作またはルーチン動作中に実行される必要のない動作を実行することができる。そして、プロセスは図7のステップ1030に戻る。
図11は、PCD100のソフトウェアアーキテクチャにおけるクライアント648を作成する、または初期設定するための図10のサブ方法またはルーチン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は、スレッドに対するコールバックを作成することができ、コールバックがそれぞれのスレッドによって実行されているときに値を戻すことができる。当業者は、同期クライアント648のタスクが実行されているときに同期クライアント648がリソースをロックするように、非同期クライアント648がリソースをロックすることはないことを認識する。
ブロック1320の後、決定ブロック1325において、フレームワーク管理プログラム440は、クライアント648によって識別されるリソースが利用可能であるか否かを判断する。決定ブロック1325への照会が否定である場合、「いいえ」の分岐がブロック1330に至り、クライアント648をこの時点で作成できないことを示すヌル値またはメッセージがユーザに返信される。
決定ブロック1325への照会が肯定である場合、「はい」の分岐が決定ブロック1335に至り、フレームワーク管理プログラム440は、クライアント648によって識別される各リソースがブロック1315において提示されたクライアントタイプをサポートするか否かを判断する。決定ブロック1335への照会が否定である場合、「いいえ」の分岐がブロック1330に戻り、クライアント648をこの時点で作成できないことを示すヌル値またはメッセージが返信される。
決定ブロック1335への照会が肯定である場合、「はい」の分岐がブロック1340に至り、フレームワーク管理プログラム440はメモリ内にクライアント648を作成またはインスタンス化する。次に、ブロック1345において、随意の引数のような任意のカスタマイズされたユーザデータがブロック1310において受信された場合、これらの随意の引数が特定のノード601にそれぞれのリソースを使ってマップされ得る。次に、ブロック1350において、新規作成されたクライアント648が、アイドル状態において、または上記したように要求された状態において、その対応する1つまたは複数のリソースに結合される。そして、プロセスは図10のブロック1210に戻る。
図12は、PCD100向けのソフトウェアアーキテクチャにおけるリソース601に対するクライアント要求675を作成するための方法1400を示すフローチャートである。方法1400は一般に、図7〜図11に関連して上述したようにクライアント作成およびノード作成（初期化）の後、実行される。
ブロック1405は、リソース601に対するクライアント要求675を作成するための方法1400における第1のステップである。方法1400は、以下の3つのタイプのクライアント要求675がフレームワーク管理プログラム440によってどのように処理されるかを表している。(a)必須、(b)インパルス、および(c)ベクトル。第4のタイプの要求675、すなわち(d)等時性要求の処理については、図15に関連して後述する。前記の要求675の名前が示唆するように、クライアント要求675は、作成され、図14に関連して上述したクライアントタイプに概ね対応する。
ブロック1405において、フレームワーク管理プログラム440は、上述した3つ、すなわち(a)必須、(b)インパルス、および(c)ベクトルのうちの1つのような特定のクライアント要求675に関連するデータを受信することができる。必須要求に関連するデータは一般に、必須クライアント648から特定のリソース601に渡されるスカラー値を含む。たとえば、必須要求は、数百万命令毎秒(MIPS)を含むことができる。インパルス要求は、開始時間または停止時間の指定のない一定期間内に何らかの活動を完了させるよう求める要求を含む。
ベクトル要求に関するデータは一般に、直列または並列に完了することが求められる複数のアクションの配列を含む。ベクトル要求は、値の任意の長さを含むことができる。ベクトル要求は通常、サイズ値および値の配列を有する。ノード601の各リソースは、ベクトル要求をサポートするためにポインタフィールドを有するように拡張され得る。「C」プログラミング言語では、ポインタフィールドは、当業者によって理解されているように、統合機能(union function)によってサポートされている。
次に、ブロック1410において、フレームワーク管理プログラム440は、図11に関連して上述した方法によって作成されたクライアント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は、図9のブロック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に戻る。
上記の方法およびデータ構造は本質的に、単一プロセッサPCD100に適用可能なように、マルチプロセッサPCD100にも適用可能である。ただし、遠隔フレームワーク300(図3)は、マルチプロセッサの実施形態における動作を向上させ得る追加の特徴を提供することができる。
たとえば、遠隔フレームワーク300は有利なことに、プロセッサ間通信の詳細を、アプリケーションプログラマーまたは同様の人には透過にすることができる。それにより、アプリケーションプログラムは、たとえば、ターゲットリソースを制御するプロセッサドメインの任意の識別情報をクライアント定義に含める必要なしに、そのリソースに対する要求を出すクライアントを定義することができる。むしろ、遠隔フレームワーク300は、どのプロセッサがクライアントを制御するか、およびどのプロセッサがターゲットリソースを制御するかにかかわらず、要求がターゲットリソースに到着するようにする。
さらに、遠隔フレームワーク300は、たとえば、アプリケーションプログラムがプロトコルまたはプロセッサ間の通信経路(たとえば、バス)の他の態様に関係するいかなる命令も含む必要がないように、プロセッサ間通信を管理する。さらに、プロセッサ間通信経路によって使用するプロトコルが異なり得るので、遠隔フレームワーク300は、リソース定義がリソースの他の態様とともにプロトコルを指定できるようにする。分散リソース管理に関係するこれらおよび他の特徴について、図13に関して以下で説明する。
図13は、第1のプロセッサ(図示せず)によって制御される第1のリソース1302が、第2のプロセッサ(図示せず)によって制御される第2のリソース1304に対応する分散リソースまたはリモートリソースとして働く例または場合を示している。「分散リソース」または「リモートリソース」という用語は、本開示において、あるプロセッサ上の、別のプロセッサ上の「ネイティブ」リソースに対応するリソースを指すために使用される。この例における第2のリソース1304は、第2のプロセッサに対するネイティブリソースとして働く。
分散リソースは、対応するネイティブリソースにアクセスする手段として使用される。この例では、リソースがノードに含まれ得ることを理解すべきであり、「リソース」という用語は「ノード」という用語と互換的に使用され得る。
破線1301は、(線1301の左側の)第1のプロセッサによって制御されるリソースと(線1301の右側の)第2のプロセッサによって制御されるリソースとの間の区分を示している。第1のリソース1302は、第1のプロセッサによって制御される2つ以上のリソースのうちの1つである。1つのそのようなリソースは、第1のリソース1302が従属するプロトコルリソース1306であり得る。同様に、第2のリソース1304は、第2のプロセッサによって制御される2つ以上のリソースのうちの1つである。1つのそのようなリソースは、第2のリソース1304が従属するプロトコルリソース1308であり得る。
第1のリソース1302および第2のリソース1304は、全般的にリソースまたはノードに関して上述したのと同様に、追加リソースに従属することもあるが、そのような追加リソースは、明快にするために図13には示されていない。第1のプロセッサによって制御されるリソースが、第1のリソースグラフ(すなわち、無閉路有向グラフ)によって定義され、第2のプロセッサによって制御されるリソースが、第1のリソースグラフとリソースをまったく共有しない第2のリソースグラフによって定義されることに留意されたい。
第1のリソース1302および第2のリソース1304は、それらのそれぞれのプロセッサの制御下にあり、通信経路1303を介して情報を通信することが可能である。通信経路1303は、第1のプロセッサと第2のプロセッサとの間の物理媒体と、その媒体を介して通信するために使用されるトランスポートプロトコルの1つまたは複数の層との組合せを表す。したがって、第1のリソース1302と第2のリソース1304との間のいかなる通信も、そのプロトコルに準拠しなければならない。プロトコルリソース1306および1308は、プロトコルを定義するか、またはライブラリ(図示せず)内のプロトコル定義を指し得る。遠隔フレームワーク300および(メイン)フレームワーク440は、互いに連携して動作して、リソースおよびリソース間の通信を管理する。以下で説明するように、クライアント1312は、第1のプロセッサの制御下にあり、第1のリソース1302に対する1つまたは複数のリソース要求を出すことができる。第1のリソース1302は、対応する第2のリソース1304の機能を使用して、リソース要求に応じる。
異なるアプリケーション状態では、リソースの様々な構成または状態を要求することがプロセッサにとって必要であること、または望ましいことがある。たとえば、バスリソースは、バスクロックの速度を制御することができる。あるアプリケーション状態では、プロセッサは、たとえば100MIPS(MIPS:100万命令毎秒)の速さでプロセッサが動作することを可能にするバスクロックを要求することができる一方、別のアプリケーション状態では、プロセッサは、たとえば150MIPSの速さでプロセッサが動作することを可能にするバスクロックを要求することができる。スリープ状態であるアプリケーション状態に入る準備をしているプロセッサの場合、プロセッサは0MIPSのバスクロックを要求することができる。
同様に、第1のアプリケーションプログラムを実行するプロセッサによって定義される1つのアプリケーション状態では、プロセッサは100MIPSを要求することができる一方、第2のアプリケーションプログラムを実行するプロセッサによって定義される別のアプリケーション状態では、プロセッサは150MIPSを要求することができる。同様に、ある数のアプリケーションプログラムを同時に実行するプロセッサによって定義されるあるアプリケーション状態では、プロセッサは100MIPSを要求することができる一方、異なる数のアプリケーションプログラムを同時に実行するプロセッサによって定義される第2のアプリケーション状態では、プロセッサは150MIPSを要求することができる。上記のバスクロックは、リソース要求を出すプロセッサによって構成され得るリソースの一例としてのみ意図されていること、また、数字「100」および「150」は、処理速度の任意の例として意図されていることを理解されたい。
リソース構成または状態は、リソース状態セットにグループ化され得る。リソース状態セットは、あるプロセッサアプリケーション状態においてプロセッサによって一緒に使用される1つまたは複数のリソースの構成または状態を定義する。たとえば、あるリソース状態セットは、一定数のMIPSの処理速度をプロセッサに与えるバスクロックリソースの構成情報または状態情報、およびプロセッサに復号機能を提供するデコーダ(すなわち、リソースの別の例)の構成情報または状態情報を含み得る。
図14は、システム103を形成するコントローラ101、リソース電力マネージャ157、マスタプロセッサ110、126、低レベルドライバ103、共用リソース105A〜C、およびローカルリソース105D〜Hの間の関係を示す機能ブロック図である。図14はまた、どのようにタッチスクリーン132がタッチスクリーンドライバ/コントローラ130に結合され得るかを示している。タッチスクリーンドライバ/コントローラ130は、第1のマスタプロセッサ110Aのクロックコード113Aに結合され得る。
システム103は、リソース待ち時間を最小化するように、プロセッサ110によって望まれるリソース状態セットを切り替えることができる。「リソース待ち時間」という用語は、マスタプロセッサ110、126が別のリソース状態セットに移行するためにコントローラ101およびリソース電力マネージャ157を準備し始めた時間から、当該セットのリソースが指定の状態に設定されるようになり、プロセッサによる使用に対して準備できるまでの時間に生じる遅延または待ち時間を指す。後述のように、リソース状態セットは、プロセッサがアプリケーションプログラムを実行し別の方法で処理能力を提供するのを支援するように構成されたリソースをプロセッサが提供される、アクティブリソース状態セットと、プロセッサがスリープ状態、すなわちプロセッサがアプリケーションプログラムを実行していないか、または別の方法で処理能力を提供していない状態を維持するのを支援するリソースのみを、プロセッサが提供される、スリープリソース状態とに大別され得る。スリープ状態にあるプロセッサは、低レベル機能を維持し得るが、プロセッサは、当業者によってアプリケーションプログラムであると理解されるソフトウェアを実行しない。後述する「次のアクティブ状態」の特徴は、アクティブセットであるか、またはスリープセットであるかにかかわらず、任意のリソース状態セット間の移行に当てはまり得ることを理解されたい。
図14に示す例示的な実施形態では、第1のマスタプロセッサ110Aは、リソース電力マネージャ157およびコントローラ101に結合され得る。コントローラ101は、第1のマスタプロセッサ110Aのクロックコード113Aに結合され得る。コントローラ101は、1つまたは複数の低レベルドライバ103を含み得る。1つまたは複数の低レベルドライバ103は、1つまたは複数の共用リソース105A〜Cと通信することを担い得る。共用リソース105A〜Cは、マスタプロセッサ110のタスクまたは機能をサポートする任意のタイプのデバイスを含み得る。共用リソース105A〜Cは、他のプロセッサのクロックのようなデバイス、さらには、グラフィカルプロセッサ、デコーダなどのような単一の機能要素を含み得る。
共用リソース105A〜Cは、1つまたは複数のローカルリソース105D〜Hに結合され得る。1つまたは複数のローカルリソース105D〜Hは、マスタプロセッサ110のタスクまたは機能をサポートまたは支援する任意のタイプのデバイスを含み得るという点で、共用リソース105A〜Cに類似し得る。ローカルリソース105D〜Hは、他のプロセッサのクロックのようなデバイス、さらには、グラフィカルプロセッサ、デコーダなどのような単一の機能要素を含み得る。ローカルリソース105D〜Hは、リーフノードを含み得る。リーフノードは、他の従属リソース105を通常は参照せず、または含まないローカルリソース105D〜Hとして当業者によって理解される。
コントローラ101は、1つまたは複数のマスタプロセッサ110、126から出される要求を管理することを担い得る。たとえば、コントローラ101は、第1のマスタプロセッサ110Aから生じる要求を管理することができる。第1のマスタプロセッサ110Aは、操作者がタッチスクリーン132を操作したことに応答して、この要求を出すことができる。タッチスクリーン132は、タッチスクリーンドライバ/コントローラ130に信号を出すことができる。そして、タッチスクリーンドライバ/コントローラ130は、第1のマスタプロセッサ110Aのクロックコード113Aに信号を出すことができる。
コントローラ101はまた、特定のプロセッサ110のスリープ状態を管理することを担い得る。スリープ状態に入る前に、プロセッサ110は、スリープ状態を管理するための情報を提供する。スリープ状態を管理するための情報は、スリープ状態に入ること、およびスリープ状態から出ることを含む。スリープ状態を管理するためのこの情報は、以下ではトリガおよびリソース状態と呼ばれる。リソース状態セットは、プロセッサのスリープ状態をサポートするように1つまたは複数のリソースを構成するためのリソース情報を含み得る。
トリガは、スリープ状態に入ること、またはスリープ状態から出ることのいずれかをプロセッサ110に行わせるイベントを定義することができる。トリガは一般に、コントローラ101内に含まれている、またはコントローラ101によってアクセス可能な、リソース状態を参照する。リソース状態は、特定のプロセッサ110が必要とするリソース105の所望の状態を定義する。例示的な実施形態では、各プロセッサ110はコントローラ101に対し、リソース状態のアクティブセットおよびリソース状態のスリープセットという、少なくとも2つのリソース状態セットを提供することができる。
ただし、他の実施形態では、プロセッサ110は、単一のアクティブセットおよび単一のスリープセットに加えてリソース状態セットを、または単一のアクティブセットおよび単一のスリープセットとは異なるリソース状態セットを提供することができる。そのような他のリソース状態セットは、上述のプロセッサアプリケーション状態のうちの1つまたは複数に対応し得る。すなわち、任意のアプリケーション状態について、プロセッサは対応するリソース状態セットを提供することができる。
例示的な実施形態では、リソース状態のアクティブセットは、プロセッサ110がアクティブに処理機能を実行し、リソース105からのアクション/機能を要求しているときの、リソース105の状態を定義することができる。リソース状態のスリープセットは、プロセッサ110がスリープ状態またはアイドル状態にあるときのリソース105の状態を定義することができる。トリガおよびリソース状態については、図15に関連して以下でさらに詳しく説明する。
図15は、コントローラ101、リソースセット304、およびトリガセット314に関する詳細を示す機能ブロック図である。前述のように、コントローラ101は、PCD100のプロセッサ110、126のうちの1つまたは複数によって実行されるソフトウェアを含み得る。当業者によって理解されるように、コントローラ101は、メモリ112に、またはローカルストレージのようなコントローラ101内のエリアに、情報を記憶することができる。この情報は、コントローラ101によってサービスされる各マスタプロセッサ110に割り当てられるリソースセット304を含むリソーステーブル302を含み得る。この情報はまた、同じく各マスタプロセッサ110に割り当てられる、各マスタプロセッサ110に固有であり得るトリガセット314を含み得る。
各リソースセット304は一般に、特定のマスタプロセッサ110によって望まれるリソース105の状態に関係する情報を含む。特定のマスタプロセッサ110に割り当てられる各リソースセット304は、アクティブリソースセット306およびスリープリソースセット308を含み得る。アクティブリソースセット306は、特定のマスタプロセッサ110がアクティブであるとき、または正常に機能しているときのリソース105の状態を定義または記述することができる。スリープリソースセット308は、特定のマスタプロセッサが当業者によって理解されるようにスリープ状態または休止状態にあるときのリソース105の状態を定義または記述することができる。各リソースセット304はまた、図15に示す例示的な実施形態において、第1のマスタプロセッサ110に割り当てられる「セット1」および「セット2」のような追加セットを含み得る。
一例として、図15に示す第1のマスタプロセッサ(A)110Aのアクティブリソースセット306は、リソース105の各々に以下の値を割り当てている。第1の共用リソース(SR#1)105Aの場合には値は1であり、第2の共用リソース(SR#2)105Bの値は1であり、第Nの共用リソース(SR#N)105Cの値は1である一方、第1のローカルリソース(LR#1)105Dの4つの値は1、0、1、および1である。
前述のように、リソース105の状態は単一の値に限定されず、複数の値を含み得る。さらに、リソースの状態は、いくつかの異なるタイプのパラメータのいずれかを含み得る。たとえば、状態は、リソース105として機能することができる特定のクロックのクロック速度の量について数百メガヘルツを指定することができる。
別の例として、図15に示す第1のマスタプロセッサ(A)110Aのスリープリソースセット308Aは、リソース105の各々に以下の値を割り当てている。第1の共用リソース(SR#1)105Aの場合、このリソースは0という値を割り当てられており、第2の共用リソース(SR#2)105Bは0という割当て値を有する一方、第Nの共用リソース(SR#N)105Cは0という割当て値を有する。第1のローカルリソース(LR#1)105Dは、0、1、0および0という割当て値を有し得る。
特定のマスタプロセッサ110に割り当てられる各トリガセット314は、割込みフィールド316、「セットから」318、および「セットへ」320という、少なくとも3つのフィールドを含み得る。トリガセット314のこれら3つのフィールドの各々はまた、トリガ開始列322、クリア列324、およびタイマー列326という、3つの列の対応するセットを含み得る。
割込みフィールド316は、リソース電力マネージャ157によって生成および/または検出され得るアクションまたは活動を記述する。割込みフィールド316は一般に、「トリガイベント」として特徴付けられてよく、トリガイベントは、コントローラ101がRPM157によって検出されるトリガイベントに基づいて特定のプロセッサ110によって望まれる特定のリソースセット304を選択することを可能にし得る。コントローラ101によるリソースセット304の選択は、背景技術セクションで上述した時間のかかるソフトウェアハンドシェイクを回避することができる。
第1のマスタプロセッサ(A)110Aについて図15の第1のトリガセット(トリガセット#1)を検討するにあたり、セットのフィールドが列ごとに順に論じられる。トリガセット314Aの第1の列から始めると、トリガ開始列322は割込みフィールド316に対応する第1の行に「復号割込み」と記載されたアクションを有する。
前述のように、割込みフィールド316は、トリガ開始フィールド322の検出に応答してリソースセット304の状態をコントローラ101にアクティブ化させるパラメータを定義することができる。図15に示す例示的な実施形態では、割込みフィールド316Aは、「復号割込み」と定義または記述されており、これは、リソース電力マネージャ110が「復号割込み」を検出したとき、たとえば、PCD100がビデオを復号しているとき、このイベントがコントローラ101に対し、「トリガ開始」列の下の第1の列322A1における「セットから」フィールド318を調べるように警告し得ることを意味する。
「セットから」フィールド318は、コントローラ101によって調べられている特定のマスタプロセッサ110に対して現在のリソースセット304が何であるべきかを示す値を含み得る。このフィールド318は、リソースセット304をその識別子、たとえば「アクティブセット」、「スリープセット」、または「セット1」もしくは「セット2」のようなセット番号によって記載することができる。フィールド320は、アスタリスクのような「ワイルドカード」を含むこともある。
「セットから」フィールド318におけるワイルドカード指定により、コントローラ101は、特定のマスタプロセッサ101によって使用されていた最後の既知のアクティブリソースセット304を取り出すことが可能になり得る。図15に示す例示的な実施形態では、「セットから」行318Aおよびトリガ開始列322A1は、アスタリスクまたはワイルドカードの値を有する。
「セットへ」320は、「セットから」318と同様に、識別子、たとえば「アクティブセット」、「スリープセット」、または「セット1」もしくは「セット2」のようなセット番号によるリソースセット304の記載を含み得る。フィールド320はまた、プロセッサ110によって利用されている最後のリソースセット304を意味するアスタリスクのような「ワイルドカード」を含み得る。図15に示す例示的な実施形態では、「セットへ」フィールド320Aおよびトリガ開始列322A1は、第1のリソースセット304Aの列310Aに記載されているリソースセット1である「セット1」という値を有する。
図15に示す例では、復号割込みイベントがRPM157によって検出されると、RPM157はコントローラ101に警告する。コントローラ101は、第1のマスタプロセッサ110の第1のトリガセットを調べる。トリガ開始列322A1は、一致する値(復号割込み)を記載しているので、コントローラ101は、「セットから」フィールド318Aを調べて、値がワイルドカード値またはアスタリスクであると判断する。次いでコントローラ101は、特定のリソースセット304Aを指定する「セット1」という値を有する「セットへ」フィールド320Aを調べる。コントローラ101によって調べられたこの情報に基づき、コントローラ101は、第1のマスタプロセッサ110Aの現在のリソースセット304Aを、現在のセットからリソースセット「セット1」に切り替える。リソースセット1は、第1のマスタプロセッサ110Aに割り当てられているリソースセット304Aの列310Aに記載されている。
さらに、RPM157またはコントローラ101が、第1のトリガセットのクリア列324A1に示すような「非復号」イベントを検出すると、コントローラ101は次いで「セットから」フィールド318Aを調べ、この値が「セット1」を含むと判断する。次いで、コントローラ101は、この例ではワイルドカードまたはアスタリスクという値を有する「セットへ」フィールド320を調べる。これは、コントローラ101が、第1のマスタプロセッサ110Aのリソースセット304Aを、「セット1」のリソースセットから、プロセッサ110Aによって使用された最後のアクティブリソースセットに切り替えることを意味する。
トリガセットのタイマーフィールド326は、特定のリソースセット304がコントローラ101によって使用され得る時間の量を示すことができる。そのため、図15に示す例示的な実施形態では、第1のトリガセットのタイマーフィールド326A1の場合、このフィールドは3ミリ秒の値を有する。これは、復号割込みイベントが第1のトリガセットのトリガ開始フィールド322A1と一致したときに、コントローラ101が、「セットへ」フィールド320Aで指定されたリソースセット304を3ミリ秒間だけ利用することを意味する。他の例示的な実施形態では、タイマーフィールド326に情報がない状況、またはこの移行のためのタイマートリガ326がないこと、および移行が非復号フィールドにのみ適用されることを示す値に対応するように値が定義される状況が、発生または存在し得る。図15に示すようなタイマーフィールド、すなわちタイマーフィールド326A1および326A2が定義される状況では、タイマーフィールド326とクリアフィールド324との間でどちらのイベントが最初に発生しても、通常は移行が始まる。
図16は、プロセッサ110の例示的なアクティブ-スリープトリガセット314を示している。この例示的な実施形態では、第1の列322における割込みフィールド316は、「シャットダウン」イベントを、特定のプロセッサ110のスリープセット308(図15)を開始するアクションと定義する。「シャットダウン」イベントは、操作者がPCD100をシャットダウンするためにオン/オフボタンを選択するようなアクションを含み得る。
図16の例示的な実施形態では、「シャットダウン」イベントが検出されたとき、コントローラ101は、現在のアクティブリソースセット306をスリープセット308に移行させる。スリープセット308は、図15のテーブル302のマスタリソースセット304に記載されている。
コントローラ101が、PCD100の操作者によって開始されるパワーオンイベントのような「起動」イベントが発生したというメッセージをRPM157から受信すると、コントローラは、トリガセット314の「セットへ」フィールド320に記載されているワイルドカードまたはアスタリスク値に基づいて、プロセッサ110をスリープセット308から最後のアクティブリソースセット304に移行させる。
上記のように、システム103は、アクティブセット306およびスリープセット308に限定されない。システム103は、図15に示すように、スリープ状態に入ることまたはスリープ状態から出ること以外のイベントに対する、リソースセット304の切替えに使用され得る。
図17は、プロセッサ110をスリープ状態にするためのトリガセット314を管理するための方法1700を示す論理フローチャートである。ブロック1705が、方法1700の最初のステップである。ブロック1705において、各プロセッサ110は、PCD100の以前の使用事例からのデータに基づいて必要に応じて、リソースセット304、さらには、コントローラ101(図1〜図2)中のトリガセット314を更新することができる。
ブロック1710において、プロセッサ110はRPM157(図14)に対し、コントローラ101へのシャットダウン信号を生成するように要求することができる。ブロック1715において、RPM157はシャットダウン信号をコントローラ101に送ることができる。
コントローラ101は、ブロック1720においてシャットダウン信号を受信することができ、図16に示すようにシャットダウンイベントに割り当てられ得るトリガセット314をアクティブ化することができる。図16に示す例示的な実施形態では、シャットダウン信号は、トリガセット314の割込みフィールド316と照合される。トリガセット314はコントローラ101に対し、「セットへ」フィールド320に示されているようにスリープセット308にアクセスするように指示する。ブロック1725において、コントローラ101はただちに、確認応答信号をRPM157に送ることができ、コントローラ101は引き続き、シャットダウン信号イベントと一致するトリガセット314によって参照されるリソースセット304をアクティブ化することができる。
ブロック1730において、図16に示す対応する割込みフィールド316に「シャットダウン」イベントを記載している一致するトリガセット314のような各々の一致するトリガセット314について、コントローラ101は、現在のリソースセット304を、図15のマスタプロセッサ110Aの第1のリソースセット305Aのスリープセット308Aのようなスリープセット308に切り替えることができる。
次に、ブロック1735において、コントローラ101は、図14に示すような低レベルドライバ103にスリープ要求状態を伝えることができる。低レベルドライバ103は、要求された状態を、対応するリソース105に渡すことができる。
ブロック1740において、各リソース105はシャットダウン信号確認応答をコントローラ101およびRPM157に出すことができる。そして、方法1700は終了することができる。
図18は、プロセッサ110をスリープ状態からアクティブ状態にするためのトリガセット314を管理するための方法1800を示す論理フローチャートである。ブロック1805が、方法1800の最初のステップである。ブロック1805において、ウェイクアップ条件またはウェイクアップイベントがRPM157により検出され、または、ウェイクアップイベントが固有の割込みコントローラ(図示せず)を有し得るコントローラ101によって直接検出される。例示的な実施形態は、ウェイクアップ割込みがRPM157によって検出可能であり得ないように設計され得る。そのような例示的な実施形態では、コントローラ101はその割込みコントローラを使用して、ウェイクアップ割込みを検出し、それらをマスタプロセッサ110のスリープセット要件に「マッピング」させることができる。
次に、ブロック1810において、RPM157はウェイクアップ信号をコントローラ101に送ることができる。ブロック1815において、コントローラ101は、RPM157からウェイクアップ信号を受信し、ウェイクアップ信号と一致した1つまたは複数のトリガセット314をアクティブ化することができる。たとえば、コントローラ101はウェイクアップ信号を、図16のトリガセット314の「アクティブ」列内の割込みフィールド316に記載されている「起動」イベントと照合することができる。図16の例示的な実施形態では、アクティブ列324内の「セットへ」フィールド320は、現在のプロセッサ110によって使用された最後のリソースセット304にコントローラを向ける。
そのため、ブロック1820において、コントローラ101は、この一致するトリガセット314に基づいて、プロセッサ110の現在のリソースセット304を変更する。当業者は、図15に示すように、コントローラ101が維持するそのトリガセットのすべてを、コントローラ101が巡回することを認識する。
次に、ブロック1825において、コントローラ101は、どのマスタプロセッサ110がスリープ状態からアウェイクしたかを識別するウェイクアップ確認応答を、RPM157に送ることができる。次に、ブロック1830において、一致するウェイクアップトリガセット314を有する各プロセッサ110は、スリープ状態から解放され、RPM157によって電力を供給されてアクティブ状態に戻される。そして、方法1800は終了する。
図19〜20は、本明細書では「次のアクティブリソース状態セット」または「次のアクティブセット」と呼ばれる別の特徴を示している。次のアクティブセットの一例は、次のアウェイクセットである。次のアウェイクセットまたは他の次のアクティブセットは、図18およびウェイクアップイベントに伴うコントローラ101による切替え後のリソースセット304に関して上述したのと同じ方法で使用され得る。
図19は、コントローラ101に記憶された情報を表すという点で、図15と類似している。例示的な実施形態では、コントローラ101は、本明細書では便宜的に「A」メモリバッファ702、「B」メモリバッファ704および「C」メモリバッファ706と呼ばれる3つのメモリバッファを含み得る。
図20は、プロセッサをスリープ状態にするための方法800を示しているという点で、図17に類似した論理フローチャートである。ブロック2005が、方法800の最初のステップであり、図17に関して上述したブロック1705に類似している。ブロック2005は、プロセッサ110がアクティブリソース状態セットまたはアウェイクリソース状態セットおよびスリープリソース状態セットだけでなく、次のアウェイクリソース状態セットも更新し得ることを示している。図20に示すように、プロセッサは、アクティブセットをコントローラ101の「A」バッファ702(図19)に記憶させ、スリープセットをコントローラ101の「B」バッファ704(図19)に記憶させ、次のアウェイクセットをコントローラ101の「C」バッファ706(図19)に記憶させることができる。ブロック2005の他の態様は、ブロック1705に関して上述したものと同じであるので、ここでは説明されない。
ブロック2010、2015、2020、2025、2030、2035および2040は、それぞれ図17のブロック1710、1715、1720、1725、1730、1735および1740と同じであるので、ここでは説明されない。プロセッサは、シャットダウンを始めるとき、「A」バッファ702(図19)に記憶されているアウェイクセットに対応するアウェイクアプリケーション状態にあることに留意されたい。次いでプロセッサは、図17に関して上述したのと同様に、「B」バッファ704(図19)に記憶されているスリープセットに対応するスリープアプリケーション状態に入る。プロセッサは、「C」バッファ706(図19)に記憶されている次のアウェイクセットに対応する次のアウェイクアプリケーション状態においてスリープアプリケーション状態からアウェイクする(図18)。「C」バッファ706に次のアウェイクセット更新を事前に記憶し、それらをできるだけ早く適用することによって、コントローラ101はウェイクアップイベントに伴い、かかる次のアウェイクセットによって指定されたリソースをただちに構成し始めることが可能であり、それによってリソース待ち時間を最小化する。
図21は、ノードスケジューラ2101、リソース電力マネージャ(「RPM」)157、および他のノードアーキテクチャシステム要素の関係を示す機能ブロック図である。詳細には、スケジューラ2101は、スケジューラデータベース2103、リソース電力マネージャ157、CPUビジー監視(「CBM」)リソース2109、スリープ低電力リソース2107、タイマー2105、図3のフレームワークマネージャ440、および様々なリソース105A〜Nに結合される。RPM157は、図14〜図15に関連して上述されてきた。RPM157は、PCD100の様々なプロセッサ110の状態を維持するためのアクティブセットおよびスリープセットを含むリソースセット304を維持し監視するためのコントローラ101(図15参照)とともに動作する。
リソース105A〜105Nは、図3〜図6および図14〜図16に関連して上述される。リソース105は、ハードウェアおよび/またはソフトウェアを含み得る。リソース105は、スケジューラ2101によって管理される要求675を受信し得る。
スケジューラ2101は、図3に関して上述されたようなフレームワークの一部である。スケジューラ2101は、フレームワークマネージャ440に結合される。スケジューラ2101は、リソース105に宛てられるクライアント648によって出された要求675(フレームワークマネージャ440に関連して上述されるクライアント648および要求675の詳細を示す図3〜図5を参照されたい)が適用される時間を、要求において規定されたタイミング期限に基づいて規定する、キュー機能を提供する。スケジューラ2101のタイミングは、タイマー2105によって記録される。
スケジューリングされた要求675がクライアント648により行われた後、発呼アプリケーションまたはエンティティは次いで、自身固有の処理を続けることができる。スケジューラ2101は次いで、クライアント648により与えられた期限に基づいて要求675を実行するための最良の方法を決定する。
スケジューラ2101は、各々のスケジューリングされた要求675を見て、スケジューリングされた要求675を実行するのにどれだけの時間がかかるかを判断する。スケジューラ2101はまた、バックオフ計算を実行する。スケジューラ2101は、どのスケジューリングされた要求675が適用され得るか、および、クライアント648または発呼エンティティによって規定されたような要求された期限を満たすためにスケジューリングされた要求675がいつ発生するべきかを理解するために、タイマー2105および/またはプロセッサ110のスリープ周期とともに動作する。
当業者によって理解されるように、タイマー2105は、ティック時間Tで動作する32ビットタイマーを含む、クロックを含み得る。本開示から逸脱することなく、他のクロックが利用され得る。たとえば、当業者によって理解されるように、64ビットタイマーシステムが使用されてもよい。32ビットタイマーでは、スケジューラ2101は、タイマー2105によって記録される現在の時間と、スケジューリングされた要求675において規定される要求された時間との差を見ることによって、要求675の時間が過去であるか未来であるかを判断することができる。
32ビットタイマーシステムで遠い未来の要求に対して遅い要求675を検出するためには、上記の差がUINT_MAX(0X80000000)より小さい場合は所望の時間が時間の分解能の半分より小さくなければならず、要求675は未来にあるものとしてスケジューラ2101により見なされる。要求される時間がUINT_MAX以上である場合、要求される時間は、過去にあるものとしてスケジューラ2101により見なされ、スケジューラ2101は通常、そのような要求675をただちに処理する。
スケジューラ2101により決定される上述のタイミングは、スケジューラ2101によってスケジューラデータベース2103に記憶される。スケジューラデータベース2103は、要求675が実行され得る様々な方法と、要求675が特定の順序で発生するときに要求675に対して必要とされるそれぞれのタイミングとに関連し得る情報を保持する。言い換えると、スケジューラ2101は、様々な選択肢と、異なるシナリオに従ってスケジューラ2101が要求675にサービスするのにかかり得るそれぞれの時間とを記録し、スケジューラデータベース2103にこれらの値を記憶することができる。スケジューラデータベース2103については、図22に関して以下でさらに説明する。
スリープ低電力リソース(「LPR」)2107は、システム100がスリープ状態からウェイクアップするときにどのリソース105がトリガされる必要があるかを、データベース2103を調べることによって決定する。スリープLPR2107は、アプリケーションプログラミングインターフェース(API)として特徴付けられ得る。スリープLPR2107は、コントローラ101およびRPM157によって管理されるリソースセット304の次のアウェイクセット中に存在すべきであると判断した要求675を出す。
CPUビジー監視(「CBM」)リソース2109は、スケジューラ2101によって確立される。CBMリソース2109は、スケジューラ2101によって管理される要求675にサービスするすべてのCPU110の状態を追跡する。CBMリソース2109に対する任意の0ではない要求675は、要求675を出すクライアント648またはユーザスレッド2301(図23参照)が、要求675の実行の間CPU110がビジー状態にとどまると予測しているということを示す。CBMリソース2109はバイナリリソースであり、これは、任意のクライアント648がビジーである限りCPU110がCBMリソース2109によってビジーであると見なされ、かつ最後の要求675が0ではない要求またはビジー要求を完了するまで、CPU110がフリーまたは非ビジーであるとは特徴付けられないということを意味する。スケジューラ2101とCBMリソース2109との間の動作および関係については、図29に関連して以下でさらに詳細に説明する。
図22は、スケジューラデータベース2103の例示的なコンテンツを示す図である。図21に関連して上述したように、スケジューラデータベース2103は、要求675が実行され得る様々な方法と、要求675が特定の順序で発生するときに要求675に対して必要とされるそれぞれのタイミングとに関連し得る情報を保持する。言い換えると、スケジューラ2101は、様々な選択肢と、異なるシナリオに従ってスケジューラ2101が要求675にサービスするのにかかり得るそれぞれの時間とを記録し、スケジューラデータベース2103にこれらの値を記憶することができる。
スケジューラデータベース2103は、限定はされないが、スレッド構成データ2205、スケジューラ待ち時間2210、最小スケジューラデルタ2215、要求待ち時間2220、分岐先読みデルタ2225、分岐待ち時間2230、参加待ち時間2235、スリープウェイク移行待ち時間2240、時間キュー待ち時間2245、低電力リソース(「LPR」)開始待ち時間2250、LPR終了待ち時間2255、LPR現在デルタ2260、スケジューリングされたリンクされたリスト2270、要求状態2275、要求時間2280、開始時間2285、遅延可能性2287、コールバック通知2290、最新通知状態2293、および要求遅延2295という情報を含み得る。
スレッド構成データ2205は、クライアント648および要求675を生じさせるスレッドからの様々な情報を記録することができる。スケジューラ待ち時間2210は、タイマー2105によって測定される、スケジューラコードを処理するのにかかる時間をティック単位で評価することができる。最小スケジューラデルタ2215は、要求675が現在のタイムアウトにより処理されるには未来にありすぎるので、要求675が再スケジューリングされる時間を評価することができる。
要求待ち時間2220は、スケジューリングされた要求675がリソース105上で出される場合に使用される、デフォルトのスケジューリングされた要求の待ち時間を評価することができる。要求待ち時間2220は、完全に非同期の要求675を出してから完了までに予測される時間を含み得る。分岐先読みデルタ2225は、どの要求675が分岐するのに適格であり得るかを判断する、スリープウェイク時間に追加すべき時間を評価することができる。このデルタ2225は、スリープセットがスリープ状態からウェイクアップするときに実行する必要があり得る作業を補償するために使用され得る。
分岐待ち時間2230は、スケジューリングされた要求がリソース105上で出されるが、リソース105が分岐要求待ち時間クエリをサポートしない場合に使用され得る、デフォルトのスケジューリングされた分岐待ち時間である。分岐待ち時間2230は、分岐された要求675を出してからそれが戻ってくるまでの時間を含む。分岐待ち時間2230に対する要求は、分岐可能なリソース105のみに対して有効である。
参加待ち時間2235は、リソース105が参加し分岐された要求が退くまでの、分岐動作が完了する時間を含み得る。参加待ち時間2235はまた、スケジューリングされた要求675がリソース105上で出されるが、リソース105が参加待ち時間クエリをサポートしない場合に使用され得る、デフォルトのスケジューリングされた分岐待ち時間である。
スリープアウェイク移行待ち時間2240は、スリープセットがスリープ状態から出るのにかかる時間、タイマー2105が発動するのに必要な時間、および、複数の要求675が加わるときに必要な任意の時間を評価する。時間キュー待ち時間2245は、タイマー2105がタイマー機能を呼び出すのにかかる時間を評価することができる。
低電力リソース(「LPR」)開始待ち時間2250は、LPR開始機能を使用するときのオーバーヘッドのためのデフォルトの時間を含み得る。LPR終了待ち時間2255は、LPR終了機能を使用するときのオーバーヘッドのためのデフォルトの時間を含み得る。LPR現在デルタ2260は、LPR開始機能がタイマー2105を再スケジューリングするためのデフォルトの時間を含み得る。
スケジューラデータベース2103の残りのデータは、図22に示すような要求の定義2265として特徴付けられ得る。スケジューリングされたリンクされたリスト2270は、実行を待機しているクライアント648を記録することができる。要求状態2275は、待機、処理、分岐、参加などのような様々な要求675の状態を記録することができる。要求時間2280は、要求675が完了されなければならない時間を含み得る。開始時間2285は、クライアント648から出された要求675を開始するのに必要な時間を記録することができる。
遅延可能性パラメータ2287は、スケジューラ2101が要求675をスケジューリングする時間になったときに、スケジューラ2101に柔軟性を与える。遅延可能性パラメータ2287が0に等しく設定されている場合、これは、要求675が、スケジューラ2101によるスケジューリングに関する遅延にまったく耐えられないことを意味する。それが1に等しく設定されている場合、スケジューラ2101が要求675の現在のセットを処理することを遅延が助けるのであれば、スケジューラ2101は、要求675がそのように遅延することを許容し得る。スケジューラ2101はまた、許容可能な遅延の程度として、0と1の間の値を記録することができる。したがって、要求の半分が遅れることをクライアントが受け入れるように、0と1の間の値が設定され得る。すべての要求が遅延を受け入れられ得るように、0と1の間の別の値が設定され得る。以下同様である。
コールバック通知2290は、要求675を出したクライアント648へのコールバックが完了したときを記録する。最新通知状態2293は、コールバック通知が時間通りに出されたか、遅れて出されたか、または要求がスケジューリングされなかったかを記録する。そして要求遅延2295は、要求675が遅れなかったときの時間、要求675が遅れたときの時間、および/または、遅れた要求675が終了したときとそれが要求されたときとの間の時間の合計を記録することができる。スケジューラデータベース2103は、これらのパラメータには限定されない。当業者によって理解されるように、他のパラメータがスケジューラデータベース2103により記録され得る。
ここで図23を参照すると、この図は、クライアント648、クライアント要求675、スケジューラ2101、およびタイマー2105の関係を示す例示的なタイミング図2300を示す。図23のY軸は時間に対応する。クライアント648および要求675の基本的な議論については、図3〜図6の以前の議論を参照されたい。
ユーザスレッド2301によって確立されるクライアント648は、リソース105に対するスケジューリングされた要求675(図示せず)を、特定の要求された時間の期限Xに行うことを望む。ユーザスレッド2301は、クライアント648がフレームワーク300内で作成された後に、要求675を出す。
要求675は、限定はされないが、ベクトル要求、スカラー要求、または、以前に説明されたような任意の他の標準的な同期要求のような、任意のタイプの要求を含み得る。スケジューラ2101は、要求675からの情報をデータベース2103に置く。要求675からの情報は、限定はされないが、データベース2103に関連して図22で上述した情報を含み得る。
詳細には、スケジューラ2101は、すべての要求675がそれぞれの期限までに終了または実行されるように、各要求675がどの時間に実行されるべきかを決定する。スケジューラ2101はまた、各要求675に対するバックオフを計算することができる。スケジューラ2101は、データベース2103にこの情報を保持する。前述のように、データベース2103は、要求675が実行され得る様々な方法と、要求675が特定の順序で発生するときに要求675に対して必要とされるそれぞれのタイミングとに関連し得る情報を保持する。言い換えると、スケジューラ2101は、様々な選択肢と、異なるシナリオに従ってスケジューラ2101が要求675にサービスするのにかかり得るそれぞれの時間とを記録し、スケジューラデータベース2103にこれらの値を記憶することができる。
その後、クライアントブロック675において、ユーザスレッド2301または要求エンティティは、他のデータまたは機能の固有の処理を続けることができる。スケジューラ2101は、1つまたは複数のリソース105が1つまたは複数の要求675を処理するためにアウェイクされるべきである時間を決定し、次いでスケジューラ2101は、段階2305Aにおいて、タイミングコマンドをタイマー2015に出す。
段階2310において、タイマー2105は、スケジューラ2101によって規定された時間を満了し、またはそれに到達し、信号をスケジューラ2101に出す。段階2310において、スケジューラ2101は、データベース2103に問い合わせ、処理する必要のある1つまたは複数の要求675を決定する。スケジューラ2101が、特定の段階2310のためにデータベース2103に記載された要求675を実行している間、スケジューラ2101は、要求675が時間通りに処理されているか、または遅れて実行されているかを評価し記録している。スケジューラ2101はまた、この段階2310において、要求675が完了するための要求675のそれぞれの期間を決定し、この情報をデータベース2103に記録する。
スケジューラ2101はまた、段階2310において、いくつかの要求675の処理または実行を遅らせることを決定することができ、スケジューラ2101は次いで、データベース2103に記載されたようなこれらの他の要求675が後の時間に発生し得るように、追加のタイミングコマンドをタイマー2105に出すことができる(「セットアップ所望タイマーイベント」)。
スケジューラ2101は、ユーザスレッド2301に従ってクライアント648によって規定されるような要求された期限よりも遅くいくつかの要求675を実行する必要がある場合でも、データベース2103中のすべての要求675を優先し実行することを試みる。
リソース105が要求675Aを完了したとスケジューラ2101が判断すると、スケジューラ2101は、クライアント通知またはコールバック2315Aを生成する。このクライアント通知2315Aでは、スケジューラ2101は、要求675Aが(要求された期限までに)時間通りに実行されたかどうか、または、要求された期限よりも遅く実行されたかどうかを、クライアント648に知らせる。
各要求675はまた、図22に関して上述したような、遅延の可能性2287のような追加の情報を含み得る。この遅延の可能性パラメータ2287は、スケジューラ2101が要求675をスケジューリングする時間になったときに、スケジューラ2101に柔軟性を与え得る。
遅延の可能性パラメータ2287が0に等しく設定されている場合、これは、要求675が、スケジューラ2101によるスケジューリングに関する遅延にまったく耐えられないことを意味する。一方、遅延の可能性パラメータ2287が0xffffffffのうちの0x80000000(50パーセント)に等しく設定されている場合、これは、要求675がスケジューラ2101によって100回(1パーセント)処理されるごとに、要求675が50回の遅延を許容し得ることを意味する。遅延の可能性パラメータ2287は、スケジューラ2101が何らかの柔軟性を伴って要求675をスケジューリングすることを可能にする。
たとえば、要求675は、リソース105により完了されるのに少なくとも10ミリ秒(ms)かかり得ると仮定する。いくつかの状況では、要求675は、99%の場合、リソース105により完了されるのに1msしかかからないことがある。この要求675の遅延の可能性パラメータが0に等しく設定されている場合、スケジューラ2101は、要求675が時間通りに完了するように、要求された期限から少なくとも10ミリ秒に、この要求をスケジューリングしなければならない。
ただし、遅延の可能性パラメータ2287が0x2900000(1%を意味する)に等しく設定されている場合、スケジューラ2101は、期間が1m秒しか続かない場合に要求675が時間通りに完了し得るように、自身の裁量で、要求された期限から1ミリ秒に、この要求675をスケジューリングすることができる。しかし、要求675は、上述の最悪の場合の10msのシナリオのように、期間が1msを超えた場合、要求された期限よりもはるかに遅く終了し得る。
データベース2103はまた、各要求675に対する最悪の場合の値を保持することができる。最悪の場合の値は通常、要求675が規定された期限までに完了するように、要求開始時間2285(図22に関連して上で論じられたデータベースパラメータ参照)の最も保守的な推定を含む。前述のように、各要求675は、ユーザスレッド2301を介してクライアント648によって規定される期限を有する。デフォルトとして、遅延の可能性パラメータ2287は規定されず、または要求675において値を与えられず、スケジューラ2101は常に、要求675の最悪の場合の値を使用する。
ここで図24を参照すると、この図は、クライアント648、クライアント要求675、スケジューラ2101、タイマー2105、およびスリープセットを記録するコントローラ101の間の関係を示す例示的なタイミング図2400を示す。図24のY軸は時間に対応する。クライアント648および要求675の説明については、図3〜図6の以前の議論を参照されたい。以前に上述されたようなスリープセットを記録するコントローラ101のさらなる詳細を示す、図15も参照されたい。
クライアント648は、ユーザスレッド2301を介して、リソース105に対する要求675(図示されず)を行うことを望む。クライアント648は、要求675が規定された時間に発生することを望む。要求675は、限定はされないが、ベクトル要求、スカラー要求、または、任意の他の標準的な同期要求のような、任意のタイプの要求198を含み得る。
スケジューラ2101は、要求675からの情報をデータベース2103に置く。上述のように、スケジューラ2101は、すべての出された要求675がそれぞれの期限までに終了しまたは実行されるように、各要求675がどの時間に実行されるべきかを解明する。スケジューラ2101は、この段階で、バックオフを計算する。
その後、要求ブロック675において、ユーザスレッド2301または要求エンティティは、他のデータまたは機能の固有の処理を続けることができる。スケジューラ2101は、1つまたは複数のリソース105(図示されず)が要求675を処理するためにアウェイクされるべきである時間を決定し、次いでスケジューラ2101は、段階2305Aにおいて、タイミングコマンドをタイマー860に出す。
スリープイベントは、段階2427において発生するようにスケジューリングされる。段階2410において、コントローラ101(または、コントローラ101のリソース状態304を調べるスケジューラ2101)は、段階2427におけるスリープイベントの期間またはスリープ周期および段階2430における予測されるウェイクアップ時間をデータベース2103に記憶する。段階2415において、スケジューラ2101は、段階2427におけるスリープ周期が終了したときにどのアウェイクセットが使用されるべきかをリソース電力マネージャ(「RPM」)157が知るように、リソースセット304の次のアウェイクセット(図15参照)をRPM157に通信することができる。
スケジューラ2101は、現在リソースセット304の次のアウェイクセットの一部にされるべき1つまたは複数の要求675を含み得るので、これらの要求675は、システムが段階2430においてスリープ状態から出るときに実行される。次のアウェイクセットがRPM157に通信される、段階2415におけるRPM通信の後で、段階2420において、スケジューラ2101は、コマンド「処理要求」675を出す。コマンド処理要求675によって、RPM157は、コントローラ101によって管理されるリソースセット304の次のアウェイクセットの一部となるべき、任意の後続の要求675をこの段階に含めるようになる。
前述のように、データベース2103は、高レベルにおいて、クライアント648、リソース105、および要求675を記録する。データベース2103はまた、要求675の一部である要求された期限を記録する。
データベース2103はまた、各要求675が完了されなければならない時間、各要求675が開始されなければならない時間、各要求675の終了時間、要求675を実行するための期間、発信側クライアントまたはユーザスレッド2301への通知またはコールバックを実行するのに必要な期間、すべての処理の期間、および、要求675が実行される前の任意のタイマー2015の期間を含む、スケジューラ2101によって行われる計算を保持し得る。
複数の要求675がある場合、データベース2103は、複数の要求675の間に発生し得るタイミングの任意の重複についてスケジューラ2101により行われる計算、およびこの重複が原因のタイミングの任意のシフトを記録する。詳細には、上で言及された高レベルデータは、上述の図22に記載されるような情報によって記録され得る。
リソース105は、そのリソース105および別のリソース105による実行のために、待ち時間とも呼ばれる、ある要求675がどの程度の時間がかかり得るかについての情報をデータベース2103に提供することができる。スケジューラ2101は、図22に関連して上述したような少なくとも3つのタイプの待ち時間データ、すなわち、要求待ち時間2220、分岐待ち時間2230、および参加待ち時間2235について、リソース105に問い合わせることができる。リソース105が待ち時間の値を何ら与えない場合、リソースのデフォルトの値が使用される。
リソース105がスケジューラ2101を関与させるのではなくむしろ要求675を直接処理する場合、リソース105は、スケジューラ2101からの要求待ち時間コマンドに応答して、0という待ち時間の値を返すことができる。この0という待ち時間の値を受信すると、スケジューラ2101は次いで、リソース105が要求675を直接処理するように、要求675の処理をやめることができる。
リソース105は、スケジューラ2101からの待ち時間要求において要求されること以上の、追加の情報を提供することができる。たとえば、リソース105は、リソース105によってサービスされる実際の要求(ユーザスレッド2301を介してクライアント648によって出される)に関する少なくとも2つの動作のモードをリソースがサポートすることを、スケジューラ2101に知らせることができる。リソース105は、2つの動作のモードの各々について、待ち時間についてのデータをスケジューラ2101に提供することができる。
段階2427におけるスリープ状態のすぐ前の段階2425において、スケジューラ2101は、スリープ状態を処理するコントローラ101を介して、スリープスケジューラ低電力リソース(「LPR」)2107を呼び出す。スリープLPR2107は、システムが段階2427においてスリープ状態からウェイクアップするときにどのリソース105がトリガされる必要があるかを、データベース2103を調べることによって決定する。スリープLPR2107は、アプリケーションプログラミングインターフェース(API)として特徴付けられ得る。
スリープLPR2107は、コントローラ101によって管理されるリソースセット304の次のアウェイクセット中に存在すべきであると判断した要求675を出す。この段階で、大量のエネルギーの節減が実現され得る。それは、スリープLPR2107が、プロセッサ110を含むシステムが段階2430においてスリープ状態から出たときに処理される必要のある要求675を事前に計画しているからである。
詳細には、段階2425におけるスリープ状態のすぐ前に、スリープLPR2107は、段階2430においてスリープ状態から出ると進められ処理され得るとともにリソースセット304の次のアウェイクセットに配置され得る要求675を、どのリソース105がスケジューリングしたかを識別する。
要求675は、分岐可能な要求675として出され、スリープLPR2107は次いで、スケジューラ2101の新たな期限をコントローラ101およびスケジューラ2101に通知して、参加機能を実行する。そして段階2427におけるスリープ状態は、普通に進行し得る。システムまたはプロセッサ110が段階2430においてウェイクアップすると、RPM157は、参加をシグナリングし、LPRの終了機能は、要求675に参加するようにスケジューラ2101にシグナリングする。スリープ状態が段階2430において終了すると、スケジューラ2101は、リソース105の使用の前に必要な任意の最後の作業を完了し、次いで、スケジューリングされたクライアントの完了のコールバックまたはクライアント通知2315Aを呼び出すことができる。
図25は、1つまたは複数のユーザスレッド2301がスケジューラ2101を呼び出すことによってブロック1205A、1205Bにおいて2つの要求675を作成するときの例示的なシナリオを示す。要求675を作成するための上述の図12を参照されたい。
第1の要求は第1のクライアント648Aとしてのブロック1205Aにおいて作成されるが、第2の要求は第2のクライアント648Bとしてのブロック1205Bにおいて作成される。ユーザスレッド2301は、クライアント648A、648Bからのこれらの2つの要求675A1、675Bがスケジューリングされた要求675であることと、第1のクライアント648Aからの第1の要求675A1が第2のクライアント648Bからの第2の要求675Bに対して時間的に早く完了する予定であることとを、スケジューラ2101に示す。
ユーザスレッド2301は次いで、ブロック675A1、675Bによって表されるような要求675A1、675Bを出す。第1のクライアント648Aからの第1の要求675A1は、第2のクライアント648Bからの第2の要求675Bよりも前に発生する予定であるが、ユーザスレッド2301は、任意の順序で要求675を出すことができる。したがって、図25に示すように、第2のクライアントからの第2の要求675Bは、段階2502における第1のクライアントからの第1の要求675A1よりも前に、段階2501において出される。
スケジューラ2101は、この段階において、出された要求675からのデータ157B1、157B2をデータベース2103に記録し、タイマー2105とともに動作することによって要求675が処理される時間を確定する。詳細には、スケジューラ2101は、図15〜図16に関連して上述したように、いくつかのトリガ314をタイマー2105に知らせる。トリガ314は、各要求675A1、675Bがいつ開始されるべきかを示す。
タイマーが段階2505Aにおいて満了すると、このことは、上述のスケジューラ2101によってタイマー314に伝えられたトリガに対応することがあり、スケジューラ2101は、ブロック2101Aにおいて、ブロック2510A1における第1の要求675A1を処理することができる。次いでブロック2515Aにおいて、スケジューラ2101は、第1の要求675A1がスケジューラ2101によって完了されたというクライアント通知を出すことができる。
ブロック2510Bにおいて、スケジューラ2101は次いで、第2の要求675Bを処理することができる。次いでブロック2515Bにおいて、スケジューラ2101は、第2の要求675Bがスケジューラ2101によって完了されたというクライアント通知を出すことができる。前述のように、第1の要求675A1は、第2の要求675Bよりも前に処理された。それは、第1の要求675A1が、第2の要求675Bの完遂時間または終了時間よりも早い完遂時間または終了時間を有していたからである。
ある例示的な実施形態によれば、スケジューラ2101は、最初に来たものが最初にサービスされるように、要求675を管理する。これは、2つ以上の要求675が同じ所望の終了時間または完了時間を有する場合、スケジューラ2101が、スケジューリングのために最初にスケジューラ2101に到達した要求675を処理し完了し得るということを意味する。スケジューラ2101に遅く到達した要求675は、両方の要求675が同じ完了期限を有し得る場合でも、最初にスケジューラ2101に到達した要求675より時間的に後に完了する。
よって、図25に示す例示的な実施形態では、第1の要求675A1と第2の要求675Bの両方が同じ所望の完了時間を有していた場合、第2の要求675Bは第1の要求675A1よりも前に完了したであろう。それは、第2の要求675Bが、第1の要求675A1よりも前に最初にスケジューラ2101に到達したからである。すると、ブロック2510A1および2515Aならびにブロック2510Bおよび2515Bは、第1の要求675A1の完了よりも前の第2の要求675Bの完了を反映するように、逆にされたことになる。
ただし、スケジューラ2101は、最初に来たものが最初にサービスされるというプロトコルのこの例示的な実施形態に限定されない。他の例示的な実施形態では、スケジューラ2101は、要求675がどれだけ速く完了し得るか、および/または、その完了がポータブルコンピューティングデバイス100の電力節減にどの程度影響を与え得るかに従って、要求675をスケジューリングすることを可能にする機能を与えられ得る。
いくつかの例示的な実施形態では、要求675間のタイミングには重複が存在しないことがある。たとえば、第1の要求675A1が10msというバックオフを伴い100という仮定的な時間期限に完了することが求められ、第2の要求675Bが10msというバックオフを伴い時間150に完了することが求められるとすると、これらのタイミングを伴うこれらの2つの要求675A1、675Bのスケジューリングにおいて重複は存在しない。そのような例示的なシナリオにおける各要求675は、2つのタイマーイベントがこれらの2つの重複しない要求675A1、675Bを処理するために確立されるように、固有のタイマーイベントを与えられる。
通常、複数の要求675の間に何らかの時間的な重複がある場合、複数の要求675は、スケジューラ2101によって折りたたまれ処理され得る。要求675間の重複は、タイミング、さらには、要求675を処理するために必要なシステムオーバーヘッドに関して、定義され得る。
たとえば、スケジューラ2101は、2つの要求675の要求される期限が互いに大きく離れている場合、2つの別個のタイマーイベントを作成するのではなく、2つの要求675を同時にまたは順番に処理するのがより効率的かどうかを、判断することができる。言い換えると、スケジューラ2101は、2つの要求675を同時にまたは順番にスケジューリングすることが、タイマー2105によって2つの別個のタイマーイベントを作成することよりも効率的であると判断すると、要求された完了期限を上書きすることができる。
要求675が要求された期限よりも前にいつ処理されるべきかという、スケジューラ2101によるこの効率的な判断は、PCD100の電力消費を考慮し得る。スケジューラ2101は、1つまたは複数の要求675を処理するためのPCD100の能力がより低い可能性がある場合の要求された期限と比較して、PCD100が要求675を処理するのに十分な能力を有すると判断すると、要求された期限よりも早く要求675をスケジューリングすることができる。スケジューラ2101は、特定の要求675が「オン」状態に関連するかどうか、または、特定の要求675が「オフ」状態に関連するかどうかを判断することによって、要求675の電力消費を記録することができる。
図26は、ユーザスレッド2301がもはや特定の要求675を処理させることを望まないと、ユーザスレッド2301がクライアント648Aを介して決断し得るときの、例示的なタイミング図2600を示す。そのような所望されない要求または望まれない要求675は、スケジューリングされない要求675として特徴付けられる。
スケジューリングされない要求675に関して、(a)スケジューラ2101によって処理されていない要求675、および(b)スケジューラ2101によって現在処理されている要求675という、2つの状況がある。図26〜図27は、スケジューラ2102によって作成されたが処理されていない要求675を示す。一方、図28は、スケジューラ2101によって作成され処理されている要求675を示し、次いでクライアント648は後で、要求675が処理されている間にスケジューリングされていない要求コマンドを出す。
図26に戻って参照すると、クライアント648Aは、ブロック648Aによって表されるように、段階1205Aにおいて作成される。要求675がクライアント648Aによって出されるよりも前に、スケジューリングされない要求コマンドが段階2610において出される。このシナリオでは、スケジューラ2101は通常、データベース2103に記憶されているスケジューリングされた要求675のリストから、所望されない要求675を単に除去することができる。段階2615において、新たな即刻の要求が、(示されたように)スケジューリングされることなく出されてよく、または、別のスケジューリングされた要求が開始されてよい(クライアント上で1205Aおよび648Aを繰り返す)。
図27は、要求675がスケジューリングされておりユーザスレッド2301が段階2705において要求675を出したが、スケジューリングされていない要求コマンド2605が出されたときにスケジューラ2101が要求675の処理を開始していない、タイミング図2700を示す。詳細には、スケジューリングされたクライアント648Aは、上述のように、図12に対応するブロック1205Aにおいて作成される。
次いで段階2705において、クライアント648Aは要求675を出す。段階2305Aにおいて、1つまたは複数の要求675の開始時間を伴うデータベース2103が次いで更新される。次いで段階2305Bにおいて、スケジューリングされない要求コマンド2605が、クライアント648Aによって出されている。この時点で、データベース2103はスケジューラ2102によって更新されてよく、このとき、要求675がデータベース2103から除去され得る。要求675はスケジューラ2101によって処理されていない(すなわち、要求675は要求されたリソース105に送信されていない)ので、要求675はデータベース2103から除去され得る。この段階において、別の即刻の要求またはスケジューリングされた要求が開始され得る。
図28は、要求675がスケジューリングされておりユーザスレッド2301が要求675を出し、スケジューラ2101が要求675の処理を開始した、例示的なタイミング図2800を示す。言い換えると、スケジューラ2101は、現在はクライアント648またはユーザスレッド2301によって望まれない要求675の処理をすでに開始している。
この例示的な実施形態によれば、ユーザスレッド2301またはクライアント648が段階2805においてスケジューリングされていない要求コマンド2605を出すと、スケジューラ2101は、ブロック2810によって示されるようなスケジューリングされていない要求コマンドを遮断するブロック2815によって示されるようなリソース105上でロックを出す。このようにして、スケジューラ2101は、段階2805において出されたスケジューリングされていない要求コマンド2605とは無関係に、ブロック2505においてスケジューリングされた要求675を完了する。
よって、図28のこの例示的な実施形態では、段階2805におけるスケジューリングされていない要求コマンド2605に応答して、ユーザスレッド2301またはクライアント648は、クライアント通知2510、さらには、要求675が処理/完了されたというスケジューリングされていない要求コマンド2605の戻り値を受信することができる。
要求675がスリープLPR2107により完了されるべきリソースセット304の次のアウェイクセット中に置かれ、ユーザスレッド2301がスケジューリングされていない要求コマンド2605を出しており、システムがウェイクアップするまでクライアント通知2510が出されないシナリオでは、スケジューラ2101は、スケジューラ2101が要求675に対してただちに動作することを可能にする、要求675の優先度を受け継ぐことができる。
これは、ユーザスレッド2301およびスケジューラ2101が、要求された期限を待つのではなくただちに要求675を終了することを可能にする、同期点になる。スケジューラ2101は、要求675が完了したのでスケジューリングされていない要求コマンド2605も完了したことを示す通知を、ユーザスレッド2301に返す。
図29は、単一のアプリケーションプログラムが実行されており、アクティブ状態の間に1つまたは複数の要求675を処理した後で、スリープ状態2902にCPU110が入り得る、単純なシナリオを示す。Y軸は電圧または電流を表し得るが、X軸はミリ秒などの単位で時間を表し得る。
段階1と2の間では、単一のアプリケーションが実行されており、CPU110はアクティブであり5ミリボルトのような電圧を有する。そして、CPU110は、0電圧が存在するX軸の時間軸上の段階2と3の間でスリープ状態2902に入る。同様に、X軸の時間軸上の段階3と4の間では、CPU110はアクティブであり、やはり5ミリボルトのような電圧を有する。
段階1.1において、ユーザスレッド2301(図示せず)は、図21で上述したように、要求をCPUビジー監視(「CBM」)リソース2109に出すことができる。CBMリソース2109は、スケジューラ2101の一部であり、かつ/またはスケジューラ2101によって確立される。CBMリソース2109に対する任意の0ではない要求675は、要求675を出すクライアント648またはユーザスレッド2301が、要求675の実行の間CPU110がビジー状態にとどまると予測しているということを示す。CBMリソース2109はバイナリリソースであり、これは、任意のクライアント648がビジーである限りCPU110がCBMリソース2109によってビジーであると見なされ、CPU110は、最後のクライアント675が0ではない要求またはビジー要求を完了するまで、フリーまたは非ビジーであるとは特徴付けられないということを意味する。
段階1.2において、抑制可能なリソース要求675は、スケジューラ2101によってリソース105に出され得る。抑制可能な要求675は、抑制可能なクライアント648から出されるリソース要求675であり、これらの要求675は、CPU110がアイドル状態になったときまたはスリープ状態2902に入ったときに優先される必要がないという、性質を有する。言い換えると、抑制可能な要求675は、CPU110がスリープ状態2902に入ると「シャットオフ」され得る。
抑制可能な要求675は、CPU110により常に優先される必要のある、必要とされる要求とは正反対である。段階2において抑制可能な要求675を出すことによって、スリープ状態2902に入る前に要求675を明示的に取り消すための要件はない。
RPM157によってサービスされるリソース105の特定の場合には、抑制可能な要求675は、リソースセット304のスリープセットに追加されず、リソースセット304のアクティブセットにのみ追加される。一方、当業者が理解するように、必要とされる要求675は、リソースセット304のアクティブセットとスリープセットの両方に追加される(図15参照)。
段階2.1において、要求675がリソース105により完了すると、リソース105は、スケジューラ2101のCBMリソース2109に通知を返し、リソース105が「まもなく」アイドル状態になると予想されることを示す。リソースは、段階2.1において、要求675の完了と関連するクリーンアップ作業の実行を始める。
スリープ状態2902のすぐ前の段階2.2において、クライアント648またはユーザスレッド2301は、裁量的な機能/特徴を使用して新たな要求2111をスケジューリングし、新たな要求2111がX軸上の段階3において処理されることを必要とすると、スケジューラ2101に示すことができる。この裁量的な機能または特徴は、新たな要求2111の一部であるデータを含み得る。
裁量的な機能は、前の要求675または現在の要求675が完了するという予想をクライアント648が有さないという状態が、新たな要求2111が実施されるまで続くことを、スケジューラ2101に知らせる。言い換えると、新たな要求2111の一部であるこの追加の裁量的な機能または特徴により、スケジューラ2101は、処理されている現在のクライアント要求675が完了する必要がないこと、または、新たなスケジューリングされた要求2111が実施されるとその要求の処理を続ける必要がないことを、認識する。この裁量的な機能により、スケジューラ2101は、スケジューラ2101の裁量で現在の要求675を完了するための、要件ではなく自由を得る。
段階2において、スケジューラ2101は、CBMリソース2109によって記録されているCPU110の現在の状態を調べることができる。CPU110がCBMリソース2109によって記録されるようにビジー状態ではないことにスケジューラ2101が気付くと、スケジューラ2101は、スリープ状態が(図15のコントローラ101およびそのリソースセットを介して)、裁量的な機能によって出された新たな要求2111を取り消す必要なく、段階2と3の間でアイドル状態またはスリープ状態のためにCPU110をオフすることを可能にし得る。このようにして、RPM157は、リソースセット304のスリープセット(図15参照)を介して、実際のスリープ状態2902に入る前に何ら取消し要求675を出さなくてよい。
要約すると、スケジューラ2101は、CBMリソース2109によって記録されたビジー状態を調査して、CPU110についてスリープ状態がまもなく予想されるかどうかを判断することができる。新たな要求2111の裁量的な機能によって、スケジューラ2101は、スリープがまもなく発生すると予測する場合、現在の要求675を終了し/取り消し、新たな要求2111をスケジューリングするかどうかを決めることができる。
あるいは、スケジューラ2101は、現在の要求675および新たな要求2111が同様または同一であると認識する場合、現在の要求675を取り消さず/終了せず、新たな要求2111を優先しないと決めることができる。これにより、CPU110がオンであるときに現在の要求675が処理されるように、RPM157が、コントローラ100のスリープセットを介して、CPU110をオフし次いでCPU110をオンすることを可能にする。
新たな要求2111のこの裁量的な機能/特徴は、スケジューラ2101が、現在の要求675を取り消すかどうか、または新たな要求2111を出すかどうかを決めることを可能にする。CBMリソース2109によって記録されるビジー状態を調べることによる、スリープ状態を予測するためのスケジューラ2101のこの裁量的な機能および能力は、システム2100の効率を改善し電力を節減する。クライアント648から受信する要求675に関する裁量を有することをスケジューラ2101に許容しないシステムと比較して、スケジューラ2101はより多くの作業を実行する必要がないので、電力が節減され得る。
CBMリソース2109を使用するスケジューラ2101および新たな要求2111における裁量的な機能によって、作業が減る。それは、スケジューラ2101が、RPM157およびコントローラ101(図15参照)によって管理されるリソースセットのスリープセットおよびアクティブセットに対して、何らパラメータを調整しなくてよいからである。スケジューラ2101は、CPU110の連続するアクティブ状態が互いに同様であり、アクティブセットまたはスリープセットに対する変更を何ら必要としないと、判断することが可能なので、スリープセットおよびアクティブセットのパラメータに対する調整は何ら必要とされない。
RPM157およびコントローラ101によって管理されるリソースセットのアクティブセットまたはスリープセットを調整することなく、15%のオーダーの効率化が本発明のシステム2100によって実現されている(すなわち、現在の要求および新たな要求675の優先/取消しに関してスケジューラ2101が裁量を有することを許容しないシステムと比較して、45msのうちの7ms以上のオーダーの時間の節減が実現されている)。
前述のように、スケジューラ2101は、CBMリソース2109によってシステム2100の効率を改善することが可能である。CBMリソース2109は、スリープ状態が比較的直近には起きないとスケジューラ2101が推測することを可能にする、システム2100において何かが起きているかどうかのバイナリインジケータである。
システム要素の大半またはすべてが「ビジー」ではないことをCBMリソース2109が示す場合、これは通常、大量の作業がリソース105に対してスケジューリングされておらず、そうしたリソース105が要求675から完全に自由になりそうであるということを意味し、スケジューラ2101は、スリープ状態2902が比較的直近に発生すると予測することができる。CBMリソース2109によって記録される状態に注目することによって、スケジューラ2101は、スリープ状態2902が発生するかどうかをスケジューラ2101が予測するかどうかに応じて、リソースがパワーオフされるべきかどうかについての決断を行うことができる。
たとえば、すべてのリソース105が現在非ビジー状態に入っていることにスケジューラ2101が気付くと、スケジューラ2101は、スリープ状態2902が発生すると予測することができ、スケジューラ2101は、スリープ状態2902が(リソースセットを伴うRPM157およびコントローラ101を介して)1つまたは複数のリソース101をパワーオフすることを可能にし得るので、スケジューラ2101は、これらのタスクを実行する必要がなく、したがって作業が少なくなる。
別の例では、第1のリソース105Aは非ビジー状態に入っている(すなわち、第1のリソース105Aが非アクティブである)が、第2のリソース105Bはビジー状態に入っていることにスケジューラ2101が気付き、第1のリソース105Aが今後来る要求675に対して何らスケジューリングされていないとスケジューラ2101が判断する場合、スケジューラ2101は、電力を節減するために、非ビジー状態の第1のリソース105Aをパワーダウンすることができる。非ビジー状態の第1のリソース105Aをパワーダウンするというこの動作は、第2のリソース105Bがビジー状態に入っているのでスリープ状態2902が予測されないため、全体の電力を節減することができる。非ビジー状態の第1のリソース105Aが非アクティブ状態で「オン」にとどまることが許されると、電力は浪費され得る。
図30は、スケジューラ2101が、段階3015と3030の間に発生するはずであったスケジューリングされたスリープ状態の間の、予測されないウェイクアップまたは割込み3002Bをどのように管理するかの、例示的なシナリオを示す。X軸はミリ秒単位で時間を表し得るが、Y軸は電流または電圧を表し得る。
スケジューラ2101は、CPU110のビジー状態またはアクティブ状態3002Aの段階3005の始めにおいて、1つまたは複数のリソース105のための1つまたは複数の要求675を管理する。段階3015においてスリープ状態に入る前に、スケジューラ2101は、データベース2103を調べた後で、段階3030のためにスケジューリングされた次のスケジューリングされたビジー状態またはアクティブ状態3002Cにおいて、現在アクティブであるリソースの現在の状態は変化しない可能性が高いことを認識する。
したがって、段階3015の前に、スケジューラ2101は、リソース105をシャットダウンまたはシャットオフしリソースセット304のそれぞれのスリープセットおよびアクティブセットを更新するプロセスを行わないことによって、追加の作業を回避し、エネルギーを節減する。よって、段階3015において、スケジューラ2101は、すべてのリソース105がスリープ状態に入ることを可能にし、各リソース105のスリープセットがそれぞれのリソース105をパワーダウンすることを可能にする。段階3015に入ると、スケジューラ2101は、システムが段階3030においてウェイクアップすると予想している。
言い換えると、スケジューラ2101は、段階3020においてウェイクアップ3002Bを予想していない。ただし、段階3020において、スケジューラ2101は、段階3020におけるウェイクアップまたは予想されないアクティブ状態3002Bを引き起こす、予想されない割込みを受信する。スケジューラ2101は、データベース2103中に存在するタイミングデータを比較することによって、アクティブ状態3002Bが予想されないと判断することができる。詳細には、現在のアクティブ状態3002Bが、段階3030におけるスケジューリングされたウェイクアップ時間よりもはるかに時間的に早く発生したことにスケジューラ2101が気付くと、この第2のアクティブ状態3002Bがシステムによって予想または予測されていないことを、スケジューラ2101は認識する。
この段階3020において、段階3015において開始した、以前にスケジューリングされたスリープ状態からシステムが出たときにアクティブになるようにスケジューリングされたリソース105は、現在の割込みまたはウェイクアップイベント3002Bのために必要とされないと、スケジューラ2101は判断する。したがって、リソース105が使用されていないこの予測されない第2のアクティブ状態3002Bの間はリソース105がオフされるように、スケジューラ2101は、取消し要求3007をリソース105に出すことができる。
次に、段階3025における第2の予想されないアクティブ状態3002Bの終わりにおいて、スケジューラ2101は、リソース105をオンするための新たな要求2111をスケジューリングするために、スリープLPR2107と通信することができるので、要求2111は、第3のアクティブ状態3002C(スケジューラ2101によって事前に予測/スケジューリングされていた)における次のアクティブアウェイクセット304の一部となる。このようにして、スケジューラ2101は、図30の予想されない第2のアクティブ状態3002Bのような割込み状態に対して必要とされない可能性のある要求675を保留または再スケジューリングするための知能を有する。
たとえば、図30のリソース105がRFモデムであると仮定する。RFモデムが段階3030に対してスケジューリングされた次の予測されるアクティブ状態3002Cのためにただちにアクティブになるように、スケジューラ2101は、自身の裁量で、リソース105のスリープセットがRFモデムをオフすることを許容すると決めている。
ただし、スケジューラ2101は、段階3020において、この段階3020における予想されないウェイクアップを引き起こした割込みが、RFモデムを必要としないアプリケーションプログラムと関連することを知る。スケジューラ2101は次いで、段階3020におけるこの予測されないアクティブ状態3002Bの間、前の要求675に対応するスケジューリングされた作業をRFモデムが実行しないように、RFモデムに対する取消し要求2111を出すことができる。スケジューラ2101は次いで、スリープLPR2107を使用して、段階3030における予想され事前にスケジューリングされたアクティブ状態3002Cにおいて、次のアウェイクセット(「NAS」)304のためのRFモデムと関連する新たな要求2111をスケジューリングする。
上記の開示に鑑みて、当業者は、たとえば本明細書のフローチャートおよび関連する説明に基づいて、コンピュータコードを書くか、または適切なハードウェアおよび/または他の論理もしくは回路を特定して、分散リソース管理システムおよび方法を容易に実施することができる。したがって、特定の1組のプログラムコード命令または詳細なハードウェアデバイスの開示が、分散リソース管理システムおよび方法をどのように製作し使用すべきかについて適切に理解するうえで必要であるとは見なされない。コンピュータによって実施される特許請求されるプロセスの発明性のある機能が、上の説明において、および、様々なプロセスの流れを示し得る各図面に関連して、より詳細に説明される。さらに、プロセッサ110、126、202、206などは、メモリ112およびその中に記憶された命令との組合せにおいて、本明細書で説明する方法ステップのうちの1つまたは複数を実行するための手段として働き得る。
1つまたは複数の例示的な態様では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶され、または送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスすることができる任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の光記憶デバイスもしくは磁気記憶デバイス、あるいは、命令またはデータ構造の形式で所望のプログラムコードを搬送または記憶するために使用され得、かつコンピュータによってアクセスされ得る任意の他の媒体を備えることができる。「ディスク(disk)」または「ディスク(disc)」という用語は、本明細書で使用される場合、限定はしないが、コンパクトディスク(disc)(「CD」)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(「DVD」)、フロッピー(登録商標)ディスク(disk)およびブルーレイディスク(disc)を含む。上記の組合せもコンピュータ可読媒体の範囲の中に含まれるべきである。
選択された態様が詳細に示され説明されてきたが、以下の特許請求の範囲によって定義されるような本開示の趣旨および範囲から逸脱することなく、本明細書において様々な置換および改変を実施できることが理解されよう。
100 PCD
101 システム、コントローラ
102 オンチップシステム、リソース電力マネージャ、RPMノード、RPM
103 低レベルドライバ
105A 共用リソース#1
105B 共用リソース#2
105C 共用リソース#N
105D ローカルリソース#1
105E ローカルリソース#2
105F ローカルリソース#3
105G ローカルリソース#4
105H ローカルリソース#N
110A 中央処理装置(「CPU」)、第1のマスタプロセッサ
110B 第2のマスタプロセッサ
110C 第Nのマスタプロセッサ
113A クロックコード
113B クロックコード
126 アナログ信号プロセッサ、プロセッサ
130 タッチスクリーンドライバ/コントローラ
132 タッチスクリーンディスプレイ
134 ビデオエンコーダ
136 ビデオ増幅器
138 ビデオポート
140 ユニバーサルシリアルバス(「USB」)コントローラ
142 USBポート
146 加入者識別モジュール(SIM)カード
148 デジタルカメラ
150 ステレオオーディオコーデック
152 オーディオ増幅器
154 第1のステレオスピーカー
156 第2のステレオスピーカー
157 リソース電力マネージャ
158 マイクロフォン増幅器
160 マイクロフォン
162 周波数変調(「FM」)無線チューナー
164 FMアンテナ
166 ステレオヘッドフォン
168 高周波(「RF」)トランシーバ
170 RFスイッチ
172 RFアンテナ
174 キーパッド
176 マイクロフォンを備えたモノヘッドセット、モノヘッドセット
178 バイブレータデバイス
180 電源
202 第1のプロセッサ
203 リソース要求
204 電力マネージャリソース、リソース
205 リソース
206 第2のプロセッサ
207 追加リソース
208 スレッド
210 信号
300 遠隔フレームワーク管理プログラム
302 リソーステーブル
304A マスタAリソースセット
304B マスタBリソースセット
306 アクティブリソースセット
308 スリープリソースセット
314 トリガセット
316A 割込みフィールド
316B 割込みフィールド
318A セットからフィールド
318B セットからフィールド
320A セットへフィールド
320B セットへフィールド
322 トリガ開始列
324 クリア列
326 タイマー列
440 フレームワーク管理プログラム、フレームワークマネージャ
422 バスアービタまたはスケジューラ
442 クロック
444A バスプログラムA
444B バスプログラムB
448 アクションまたは機能
601 ノード
601A 第1のノード
601B 第2のノード
602 ノード
622 ノード、第2のノード
642 ノード
646 ノード
648 クライアント
675 クライアント要求
675A クライアント要求
680A 従属性矢印
680B 従属性矢印
680C 従属性矢印
680D 従属性矢印
690 イベント
695 照会機能
697 方向矢印
702 Aバッファ
704 Bバッファ
706 Cバッファ
2101 NPAスケジューラ
2103 スケジューラデータベース
2105 タイマー
2107 スリープ低電力リソース
2109 CPUビジー監視(CBM)リソース
2111 新たな要求
2205 スレッド構成データ
2210 スケジューラ待ち時間
2215 最小スケジューラデルタ
2220 要求待ち時間
2225 分岐先読みデルタ
2230 分岐待ち時間
2235 参加待ち時間
2240 スリープウェイク移行待ち時間
2245 時間キュー待ち時間
2250 LPR開始待ち時間
2255 LPR終了待ち時間
2260 LPR現在デルタ
2265 スケジュールリソース定義
2270 スケジューリングされたリンクされたリスト
2275 要求状態
2280 要求時間
2285 開始時間
2287 遅延可能性
2290 コールバック通知
2293 最新通知状態
2295 要求遅延
2315 コールバック

Claims (32)

  1. ポータブルコンピューティングデバイス内のリソース間の要求を管理するための方法であって、
    複数の要求をスケジューリングするためのデータをクライアントから受信するステップであって、各要求が少なくとも1つのリソースおよび要求された期限を特定する、ステップと、
    データベースに前記クライアントからの前記データを記憶するステップと、
    前記要求において要求された期限に基づき、かつ、前記ポータブルコンピューティングデバイス内のリソースの現在の状態に基づき、前記要求を処理するための時間および順序を決定するステップと、
    前記決定された時間に、前記決定された順序に従って、前記要求を対応するリソースに伝えるステップと、
    以前にスケジューリングされた要求と関連するスケジューリングされていない要求コマンドをクライアントから受信したことに応答して、対応するリソースをロックするステップと
    を含む、方法。
  2. 新たな要求コマンドを受信したことに応答して、要求された期限の後に、複数の要求のうちの少なくとも1つをスケジューリングするステップをさらに含む、請求項1に記載の方法。
  3. プロセッサがスリープモードから出たときに前記プロセッサが複数の要求のうちの少なくとも1つについて作業を続けることができるように、前記スリープモードにおいてプロセッサをパワーオフすることを可能にするステップをさらに含み、前記スリープモードにあるプロセッサは、アプリケーションプログラムを実行しない、請求項1に記載の方法。
  4. スケジューリングされたスリープモードの間に割込みを受信するステップと、
    前記割込みを受信したことに応答して、複数の要求のうちの1つまたは複数が前記割込みに応答するために必要であるかを判断するステップとをさらに含む、請求項1に記載の方法。
  5. 複数の要求のうちの1つまたは複数が、前記スケジューリングされたスリープモードの間の前記割込みに応答するために必要ではない場合、前記複数の要求のうちの1つまたは複数を取り消すステップをさらに含む、請求項4に記載の方法。
  6. 前記取り消された要求のうちの1つまたは複数を、次のスケジューリングされたアクティブモードにおいて発生するように再スケジューリングするステップをさらに含む、請求項5に記載の方法。
  7. 前記スケジューリングされていない要求コマンドを受信したことに応答して、対応するリソースによる対応する要求の処理を終了するステップをさらに含む、請求項1に記載の方法。
  8. 前記ポータブルコンピューティングデバイスが、携帯電話、携帯情報端末、ページャ、スマートフォン、ナビゲーションデバイス、およびワイヤレス接続またはワイヤレスリンクを含むハンドヘルドコンピュータのうちの少なくとも1つを含む、請求項1に記載の方法。
  9. ポータブルコンピューティングデバイス内のリソース間の要求を管理するためのコンピュータシステムであって、
    プロセッサを備え、前記プロセッサが、
    複数の要求をスケジューリングするためのデータをクライアントから受信するステップであって、各要求が少なくとも1つのリソースおよび要求された期限を特定する、ステップと、
    データベースに前記クライアントからの前記データを記憶するステップと、
    前記要求において要求された期限に基づき、かつ、前記ポータブルコンピューティングデバイス内のリソースの現在の状態に基づき、前記要求を処理するための時間および順序を決定するステップと、
    前記決定された時間に、前記決定された順序に従って、前記要求を対応するリソースに伝えるステップと、
    以前にスケジューリングされた要求と関連するスケジューリングされていない要求コマンドをクライアントから受信したことに応答して、対応するリソースをロックするステップと
    を行うように動作可能である、コンピュータシステム。
  10. 前記プロセッサがさらに、
    新たな要求コマンドを受信したことに応答して、要求された期限の後に、複数の要求のうちの少なくとも1つをスケジューリングするステップを行うように動作可能である、請求項9に記載のシステム。
  11. 前記プロセッサがさらに、
    プロセッサがスリープモードから出たときに前記プロセッサが複数の要求のうちの少なくとも1つについて作業を続けることができるように、前記スリープモードにおいてプロセッサをパワーオフすることを可能にするステップを行うように動作可能であり、前記スリープモードにあるプロセッサは、アプリケーションプログラムを実行しない、請求項10に記載のシステム。
  12. 前記プロセッサがさらに、
    スケジューリングされたスリープモードの間に割込みを受信するステップと、
    前記割込みを受信したことに応答して、複数の要求のうちの1つまたは複数が前記割込みに応答するために必要であるかを判断するステップとを行うように動作可能である、請求項9に記載のシステム。
  13. 前記プロセッサがさらに、
    複数の要求のうちの1つまたは複数が、前記スケジューリングされたスリープモードの間の前記割込みに応答するために必要ではない場合、前記複数の要求のうちの1つまたは複数を取り消すステップを行うように動作可能である、請求項12に記載のシステム。
  14. 前記プロセッサがさらに、
    前記取り消された要求のうちの1つまたは複数を、次のスケジューリングされたアクティブモードにおいて発生するように再スケジューリングするステップを行うように動作可能である、請求項13に記載のシステム。
  15. 前記プロセッサがさらに、
    前記スケジューリングされていない要求コマンドを受信したことに応答して、対応するリソースによる対応する要求の処理を終了するステップを行うように動作可能である、請求項9に記載のシステム。
  16. 前記ポータブルコンピューティングデバイスが、携帯電話、携帯情報端末、ページャ、スマートフォン、ナビゲーションデバイス、およびワイヤレス接続またはワイヤレスリンクを含むハンドヘルドコンピュータのうちの少なくとも1つを含む、請求項9に記載のシステム。
  17. ポータブルコンピューティングデバイス内のリソース間の要求を管理するためのコンピュータシステムであって、
    複数の要求をスケジューリングするためのデータをクライアントから受信するための手段であって、各要求が少なくとも1つのリソースおよび要求された期限を特定する、手段と、
    データベースに前記クライアントからの前記データを記憶するための手段と、
    前記要求において要求された期限に基づき、かつ、前記ポータブルコンピューティングデバイス内のリソースの現在の状態に基づき、前記要求を処理するための時間および順序を決定するための手段と、
    前記決定された時間に、前記決定された順序に従って、前記要求を対応するリソースに伝えるための手段と、
    以前にスケジューリングされた要求と関連するスケジューリングされていない要求コマンドをクライアントから受信したことに応答して、対応するリソースをロックするための手段と
    を含む、コンピュータシステム。
  18. 新たな要求コマンドを受信したことに応答して、要求された期限の後に、複数の要求のうちの少なくとも1つをスケジューリングするための手段をさらに含む、請求項17に記載のシステム。
  19. プロセッサがスリープモードから出たときに前記プロセッサが複数の要求のうちの少なくとも1つについて作業を続けることができるように、前記スリープモードにおいてプロセッサをパワーオフすることを可能にするための手段をさらに含み、前記スリープモードにあるプロセッサは、アプリケーションプログラムを実行しない、請求項18に記載のシステム。
  20. スケジューリングされたスリープモードの間に割込みを受信するための手段と、
    前記割込みを受信したことに応答して、複数の要求のうちの1つまたは複数が前記割込みに応答するために必要であるかを判断するための手段とをさらに含む、請求項17に記載のシステム。
  21. 複数の要求のうちの1つまたは複数が、前記スケジューリングされたスリープモードの間の前記割込みに応答するために必要ではない場合、前記複数の要求のうちの1つまたは複数を取り消すための手段をさらに含む、請求項20に記載のシステム。
  22. 前記取り消された要求のうちの1つまたは複数を、次のスケジューリングされたアクティブモードにおいて発生するように再スケジューリングするための手段をさらに含む、請求項21に記載のシステム。
  23. 前記スケジューリングされていない要求コマンドを受信したことに応答して、対応するリソースによる対応する要求の処理を終了するための手段をさらに含む、請求項17に記載のシステム。
  24. 前記ポータブルコンピューティングデバイスが、携帯電話、携帯情報端末、ページャ、スマートフォン、ナビゲーションデバイス、およびワイヤレス接続またはワイヤレスリンクを含むハンドヘルドコンピュータのうちの少なくとも1つを含む、請求項17に記載のシステム。
  25. コンピュータ可読プログラムコードを含むコンピュータプログラムであって、前記コンピュータ可読プログラムコードが、ポータブルコンピューティングデバイス内のリソース間の要求を管理するための方法を実施するように実行されるように適合され、前記方法が、
    複数の要求をスケジューリングするためのデータをクライアントから受信するステップであって、各要求が少なくとも1つのリソースおよび要求された期限を特定する、ステップと、
    データベースに前記クライアントからの前記データを記憶するステップと、
    前記要求において要求された期限に基づき、かつ、前記ポータブルコンピューティングデバイス内のリソースの現在の状態に基づき、前記要求を処理するための時間および順序を決定するステップと、
    前記決定された時間に、前記決定された順序に従って、前記要求を対応するリソースに伝えるステップと、
    以前にスケジューリングされた要求と関連するスケジューリングされていない要求コマンドをクライアントから受信したことに応答して、対応するリソースをロックするステップと
    を含む、コンピュータプログラム。
  26. 前記方法を実施するプログラムコードがさらに、
    新たな要求コマンドを受信したことに応答して、要求された期限の後に、複数の要求のうちの少なくとも1つをスケジューリングするステップを含む、請求項25に記載のコンピュータプログラム。
  27. 前記方法を実施するプログラムコードがさらに、
    プロセッサがスリープモードから出たときに前記プロセッサが複数の要求のうちの少なくとも1つについて作業を続けることができるように、前記スリープモードにおいてプロセッサをパワーオフすることを可能にするステップを含み、前記スリープモードにあるプロセッサは、アプリケーションプログラムを実行しない、請求項25に記載のコンピュータプログラム。
  28. 前記方法を実施するプログラムコードがさらに、
    スケジューリングされたスリープモードの間に割込みを受信するステップと、
    前記割込みを受信したことに応答して、複数の要求のうちの1つまたは複数が前記割込みに応答するために必要であるかを判断するステップとを含む、請求項25に記載のコンピュータプログラム。
  29. 前記方法を実施するプログラムコードがさらに、
    複数の要求のうちの1つまたは複数が、前記スケジューリングされたスリープモードの間の前記割込みに応答するために必要ではない場合、前記複数の要求のうちの1つまたは複数を取り消すステップを含む、請求項28に記載のコンピュータプログラム。
  30. 前記方法を実施するプログラムコードがさらに、
    前記取り消された要求のうちの1つまたは複数を、次のスケジューリングされたアクティブモードにおいて発生するように再スケジューリングするステップを含む、請求項29に記載のコンピュータプログラム。
  31. 前記方法を実施するプログラムコードがさらに、
    前記スケジューリングされていない要求コマンドを受信したことに応答して、対応するリソースによる対応する要求の処理を終了するステップを含む、請求項25に記載のコンピュータプログラム。
  32. 前記ポータブルコンピューティングデバイスが、携帯電話、携帯情報端末、ページャ、スマートフォン、ナビゲーションデバイス、およびワイヤレス接続またはワイヤレスリンクを含むハンドヘルドコンピュータのうちの少なくとも1つを含む、請求項25に記載のコンピュータプログラム。
JP2014558799A 2012-02-23 2013-02-20 ポータブルコンピューティングデバイスにおいて要求をスケジューリングするための方法およびシステム Expired - Fee Related JP5809366B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261602287P 2012-02-23 2012-02-23
US61/602,287 2012-02-23
US13/418,597 US8793697B2 (en) 2012-02-23 2012-03-13 Method and system for scheduling requests in a portable computing device
US13/418,597 2012-03-13
PCT/US2013/026873 WO2013126415A2 (en) 2012-02-23 2013-02-20 Method and system for scheduling requests in a portable computing device

Publications (2)

Publication Number Publication Date
JP2015513735A JP2015513735A (ja) 2015-05-14
JP5809366B2 true JP5809366B2 (ja) 2015-11-10

Family

ID=49004762

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014558799A Expired - Fee Related JP5809366B2 (ja) 2012-02-23 2013-02-20 ポータブルコンピューティングデバイスにおいて要求をスケジューリングするための方法およびシステム

Country Status (6)

Country Link
US (1) US8793697B2 (ja)
EP (1) EP2817717A2 (ja)
JP (1) JP5809366B2 (ja)
KR (1) KR101551321B1 (ja)
CN (1) CN104303149B (ja)
WO (1) WO2013126415A2 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9179169B2 (en) * 2012-03-14 2015-11-03 Imagine Communications Corp. Adaptive media delivery
US8843936B2 (en) * 2012-05-30 2014-09-23 International Business Machines Corporation Automatically identifying critical resources of an organization
US9619286B1 (en) * 2014-03-20 2017-04-11 EMC IP Holding Company LLC Using request service time as fairness heuristic in locking techniques
US9418348B2 (en) * 2014-05-05 2016-08-16 Oracle International Corporation Automatic task assignment system
US20150339275A1 (en) * 2014-05-20 2015-11-26 Yahoo! Inc. Rendering of on-line content
US10178688B2 (en) 2015-10-06 2019-01-08 Motorola Solutions, Inc. Method of scheduling short uplink transmissions
CN105550032A (zh) * 2015-10-27 2016-05-04 深圳市美贝壳科技有限公司 基于Android系统的CPU优化方法、系统
CN105893120B (zh) * 2016-04-21 2019-07-30 北京京东尚科信息技术有限公司 一种线程同步资源的获取方法和装置
US10542100B2 (en) * 2016-09-16 2020-01-21 Oracle International Corporation Systems and methodologies for defining and scheduling custom actions as cloud operations
JP2019175292A (ja) 2018-03-29 2019-10-10 東芝メモリ株式会社 電子機器、コンピュータシステム、および制御方法
CN109491765B (zh) * 2018-10-09 2021-07-30 创新先进技术有限公司 对跨域业务请求的处理方法及装置
CN113168334A (zh) * 2019-02-22 2021-07-23 深圳市欢太科技有限公司 数据处理方法、装置、电子设备及可读存储介质
CN111861114A (zh) * 2020-06-15 2020-10-30 新智机器人技术服务(江阴)有限公司 一种基于智能制造的产品生产流程调度方法及系统

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6791992B1 (en) * 1999-10-07 2004-09-14 The Regents Of The University Of California Earliest-deadline-first queuing cell switching architecture and method
US6937561B2 (en) * 2000-06-02 2005-08-30 Agere Systems Inc. Method and apparatus for guaranteeing data transfer rates and enforcing conformance with traffic profiles in a packet network
US7137117B2 (en) * 2000-06-02 2006-11-14 Microsoft Corporation Dynamically variable idle time thread scheduling
US6578117B2 (en) 2001-10-12 2003-06-10 Sonics, Inc. Method and apparatus for scheduling requests using ordered stages of scheduling criteria
US7093256B2 (en) * 2002-12-13 2006-08-15 Equator Technologies, Inc. Method and apparatus for scheduling real-time and non-real-time access to a shared resource
JP2005149312A (ja) 2003-11-18 2005-06-09 Toyota Motor Corp タスク管理システム
US8782654B2 (en) * 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
US8156500B2 (en) * 2005-07-01 2012-04-10 Microsoft Corporation Real-time self tuning of planned actions in a distributed environment
GB0518516D0 (en) * 2005-09-10 2005-10-19 Ibm Managing a resource lock
JP4377369B2 (ja) 2005-11-09 2009-12-02 株式会社日立製作所 リソース割当調停装置およびリソース割当調停方法
WO2007125942A1 (ja) * 2006-04-26 2007-11-08 Nippon Telegraph And Telephone Corporation 負荷制御装置およびその方法
JP4971676B2 (ja) * 2006-04-28 2012-07-11 ルネサスエレクトロニクス株式会社 割り込み制御回路及び割り込み制御方法
US20080046888A1 (en) 2006-08-15 2008-02-21 Appaji Anuradha K Framework for Rule-Based Execution and Scheduling of Tasks in Mobile Devices
FI122301B (fi) * 2006-08-25 2011-11-30 Atomia Oy Piiri, menetelmä ja järjestely yksinkertaisen ja luotettavan hajautetun väyläarbitroinnin toteuttamiseksi
US7669081B2 (en) 2006-09-27 2010-02-23 Raytheon Company Systems and methods for scheduling, processing, and monitoring tasks
GB2443277B (en) * 2006-10-24 2011-05-18 Advanced Risc Mach Ltd Performing diagnostics operations upon an asymmetric multiprocessor apparatus
US8136113B2 (en) * 2006-12-20 2012-03-13 International Business Machines Corporation Method and apparatus for adjusting sleep time of fixed high-priority threads
US20090182802A1 (en) 2008-01-10 2009-07-16 Microsoft Corporation Mobile device management scheduling
US8077638B2 (en) * 2008-06-26 2011-12-13 Qualcomm Incorporated Methods and apparatus for providing quality of service in a peer to peer network
US8407440B2 (en) * 2008-07-08 2013-03-26 HGST Netherlands B.V. Techniques for scheduling requests for accessing storage devices using sliding windows
GB0816551D0 (en) 2008-09-10 2008-10-15 Omnifone Ltd Mobile helper application & mobile handset applications lifecycles
EP2214100A1 (en) * 2009-01-30 2010-08-04 BRITISH TELECOMMUNICATIONS public limited company Allocation of processing tasks
US20110161963A1 (en) * 2009-12-31 2011-06-30 Nokia Corporation Methods, apparatuses, and computer program products for generating a cyclostationary extension for scheduling of periodic software tasks
US20110252423A1 (en) 2010-04-07 2011-10-13 Apple Inc. Opportunistic Multitasking

Also Published As

Publication number Publication date
WO2013126415A3 (en) 2014-10-16
KR101551321B1 (ko) 2015-09-08
JP2015513735A (ja) 2015-05-14
EP2817717A2 (en) 2014-12-31
CN104303149A (zh) 2015-01-21
US8793697B2 (en) 2014-07-29
KR20140127341A (ko) 2014-11-03
US20130227583A1 (en) 2013-08-29
CN104303149B (zh) 2017-11-17
WO2013126415A2 (en) 2013-08-29

Similar Documents

Publication Publication Date Title
JP5809366B2 (ja) ポータブルコンピューティングデバイスにおいて要求をスケジューリングするための方法およびシステム
US10949249B2 (en) Task processor
JP5969610B2 (ja) ポータブルコンピューティングデバイスにおける分散リソース管理
US9047120B2 (en) Virtual queue processing circuit and task processor
US10268609B2 (en) Resource management in a multicore architecture
TWI233545B (en) Mechanism for processor power state aware distribution of lowest priority interrupts
US20020007387A1 (en) Dynamically variable idle time thread scheduling
US8286169B2 (en) Dynamic scheduling an interval for polling devices based on a current operational power mode in an extensible firmware interface architecture
JP5864754B2 (ja) ポータブルコンピューティングデバイスのリソースを管理するためのシステムおよび方法
US20070074219A1 (en) Dynamically Variable Idle Time Thread Scheduling
US20120066391A1 (en) System and method for managing resources of a portable computing device
JP2013516711A (ja) 電子デバイスにおける電力を制御するシステムおよび方法
JPH06250853A (ja) プロセス・スケジューリングの管理方法およびシステム
WO2013154706A1 (en) Method and system for tracking and selecting optimal power conserving modes of a pcd
JP2005519393A (ja) 仮想直接メモリ・アクセスのための方法及び装置
JP2015503167A (ja) ポータブルコンピューティングデバイスにおけるリソース要求のバッチングおよびフォーク

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150209

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150511

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150817

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150910

R150 Certificate of patent or registration of utility model

Ref document number: 5809366

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees