(57)【要約】アプリケーションとストリーミングコンポーネントとの間で使用する通信機構であって、制御コマンドが保留中であるか否かをチェックする（ポーリングする）のに用いられ得るパッシブインタフェースを前記ストリーミング側に持つ通信機構に関する。ストリーミングアルゴリズムは、制御を実行することが意味をなす時点に待ち行列をチェックする。主な利点は、前記アプリケーションが前記ストリーミングコンポーネントと別のプロセスにおいてランする場合に、RPCタスクの起動が不要にされることにある。付加的な利点は、前記アプリケーションが前記ストリーミングコンポーネントと別のプロセッサにおいてランし、共用メモリがある場合に、制御が行なわれる際にストリーミングプロセッサに割込みがかけられる必要がないことにある。
2005506629.tif 000002
【特許請求の範囲】
【請求項１】
制御コンポーネントとストリーミングコンポーネントとの間の通信方法であって、前記ストリーミングコンポーネントが、制御コマンドが保留中である否かのポーリングのためのパッシブインタフェースを持ち、制御コマンドを実行することが意味をなす時点に前記インタフェースがポーリングされる通信方法。
【請求項２】
前記インタフェースが、前記ストリーミングコンポーネントがデータをフェッチする直前にポーリングされることを特徴とする請求項１に記載の方法。
【請求項３】
前記パッシブインタフェースがコマンド待ち行列を有することを特徴とする請求項１に記載の方法。
【請求項４】
前記パッシブインタフェースが分離待ち行列を有することを特徴とする請求項３に記載の方法。
【請求項５】
前記パッシブインタフェースが共用変数を有することを特徴とする請求項１に記載の方法。
【請求項６】
前記ストリーミングコンポーネントが、第１実行コンテキストにおいてランする制御部と、第２実行コンテキストにおいてランするストリーミング部とを有することを特徴とする請求項１に記載の方法。
【請求項７】
前記第１実行コンテキストが前記制御コンポーネントのコンテキストであることを特徴とする請求項６に記載の方法。
【請求項８】
ストリーミングデータ伝送のために構成されたコンピュータシステムであって、制御コンポーネントとストリーミングコンポーネントとを有し、前記ストリーミングコンポーネントが、制御コマンドが保留中であるか否かのポーリングのためのパッシブインタフェースを持ち、制御コマンドを実行することが意味をなす時点に前記インタフェースがポーリングされるコンピュータシステム。
【請求項９】
前記制御コンポーネントがソフトウェアモジュールであることを特徴とする請求項８に記載のコンピュータシステム。
【請求項１０】
前記ストリーミングコンポーネントがソフトウェアモジュールであることを特徴とする請求項８又は９に記載のコンピュータシステム。
【請求項１１】
前記インタフェースが、前記ストリーミングコンポーネントがデータをフェッチする直前にポーリングされることを特徴とする請求項８に記載のシステム。
【請求項１２】
前記ストリーミングコンポーネントが、第１実行コンテキストにおいてランする制御部と、第２実行コンテキストにおいてランするストリーミング部とを有することを特徴とする請求項８に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
インターネット・オーディオ、デジタルテレビ、セットトップボックス及びタイムシフト録画などのシステムのためにデータ処理が用いられる。（ディスク、インターネット、衛星などからの）入力データは、幾つかのステップで処理され、最終的にディスプレイ又はスピーカにおいて供給される。このデータ処理は、ますますソフトウェアでなされる傾向にある。ソフトウェアでのデータ処理は、接続された処理ノードのグラフに基づく。ノードが実際の処理を行う。パケットが処理される場合には、パケットはチェーン中の次のノードに渡される。
【０００２】
処理チェーンは制御されなければならない。最初に、処理チェーンが作成されなければならず、実行時の間、チェーン中のコンポーネントは、ユーザとの対話のために又はデータストリームにおける変化のために再構成される必要があり得る。この制御コードはアプリケーションと呼ばれている。
【０００３】
アプリケーションは、ストリーミングコンポーネントのパラメータを設定するためにユーザ／データストリームからの入力をコマンドに翻訳する。ストリーミングコンポーネントは、アプリケーションによって与えられる設定に基づいてデータ処理を行なう。ストリーミングコンポーネント及びアプリケーションの実行時特性は異なり、一般的に、ストリーミングコンポーネントはより多くのリアルタイム制約を持つということが成り立つ。結果として、アプリケーション及びストリーミングコンポーネントは、異なるスレッド／プロセス／プロセッサにおいてランし、アプリケーションとストリーミングコンポーネントとの間の対話のために通信機構が必要とされる。
【０００４】
アプリケーションによって発せられる制御は、ストリーミングコンポーネントのリアルタイム特性を乱す（例えば、ストリーミングコンポーネントのリアルタイム特性を妨げる又は優先順位の逆転をもたらす）べきでない。標準的な解決策は、アプリケーションとストリーミングコンポーネントとが、待ち行列、遠隔手順（全RPC）又はセマフォで保護された共用変数などのOS基本命令によって分離されるというものである。以下では、このような分離機構を示すために分離待ち行列という用語を用いる。対話は以下の通りである。
−  アプリケーションが、（例えば、異なる実行コンテキストを用いて）ストリーミングタスクとは無関係に分離待ち行列に書き込む又は分離待ち行列から読み出す。
【０００５】
ストリーミングコンポーネントを制御するためにプロセッサの境界を越えるために一般的なRPC機構を用いることの主な不利な点は、ストリーミングコンポーネントの分離待ち行列中にメッセージを入れるためにRPCタスクが起動されなければならないことにある。（高速応答を得るために高い優先順位を持つ）RPCタスクを起動することは、ストリーミングタスクが先取り(pre-empt)され得るという不利な点を持つ。結果として、プロセッサのデータ及び命令のキャッシュが部分的にクリア(flush)される。これは、キャッシュ使用について最適化されるストリーミングコンポーネントのパフォーマンスを低下させる。
【発明の開示】
【課題を解決するための手段】
【０００６】
本発明によれば、ストリーミングコンポーネントは、
１．アプリケーションの実行コンテキストにおいてランする制御部（頂部）と、
２．ストリーミングプロセスの実行コンテキストにおいてランするストリーミング部（底部）との２つの部分に分割される。
【０００７】
両部分に分割されるが、これらの２つの部分は、両方とも、各ストリーミングコンポーネントに特有のものである。この分割は、標準的なRPC機構の使用より効率的である、プロセス／プロセッサで共用される通信チャネルを使用することを可能にする。アプリケーションの機能の観点からは、あたかも、ストリーミングコンポーネントが（RPCにおけるプロキシの場合と同様に）アプリケーションと同じ実行コンテキストにおいてランするように見える。
【０００８】
図面に示されている実施例を参照して本発明のこれら及び他の特徴を説明し、明らかにする。
【発明を実施するための最良の形態】
【０００９】
これらの図を通して、同じ参照符号は同様の又は対応する特徴を示す。図面に示されている特徴の幾つかは、典型的には、ソフトウェアで実施され、それ自体、ソフトウェアモジュール又はオブジェクトなどのソフトウェアエンティティを表わす。
【００１０】
図１は、ストリーミング音楽データを処理するよう構成される例示的なデータ処理システム１００を概略的に示している。入力コンポーネント１０１は、よく知られているMP3フォーマット（米国特許公報第US 5,579,430号）のものであるストリーミングデータを受け取る。MP3復号コンポーネント１０２は、音楽データを得るためにこのストリーミングデータを復号し、これを等化コンポーネント(equalizer component)１０３に供給する。等化後、このデータは、例えばスピーカにおいて音楽データを再生することによって該データを供給する出力コンポーネント１０４に供給される。当然、容易に、MP3音楽の代わりに他のフォーマットの音楽データ、あらゆるフォーマットのビデオデータ又はあらゆる他のデータが用いられ得る。ストリーミングコンポーネント１０１乃至１０４は、アプリケーション１０５によって与えられる設定又はパラメータに基づいてそれらのデータ処理を行なう。これらの設定又はパラメータは、ユーザとの対話のために又はデータストリームにおける変化のために変化し得る。
【００１１】
アプリケーション１０５及びストリーミングコンポーネント１０１乃至１０４の実行時特性は異なり、一般的に、ストリーミングコンポーネントはより多くのリアルタイム制約を持つということが成り立つ。結果として、アプリケーション１０５及びストリーミングコンポーネント１０１乃至１０４は異なるスレッド／プロセス／プロセッサにおいてランし、アプリケーション１０５とストリーミングコンポーネント１０１乃至１０４との間の対話のために通信機構が必要とされる。
【００１２】
図２は、遠隔手順呼出し（PRC）の基本機構を図示している。RPCは、通常、別のプロセス／プロセッサ中の関数の呼出しを取り扱う。一般的に、PRC呼出しは、
１．クライアント２００がプロキシ２０１（遠隔サービスのためのローカルな代理(local representative)）を呼び出す段階と、
２．プロキシ２０１が、関数／方法IDと一緒にパケットに引数をマーシャル（パック）し、次いで、待ち行列２１０などの通信チャネルにこのパケットを付加する段階と、
３．通信チャネル２０２が、マーシャルされたデータを他のプロセス２２０又はプロセッサ（サーバ）に転送する段階と、
４．他のプロセス２２０において、スタブ２２１が、新しいパケットを通知され、引数及び関数／方法IDをアンパックする段階と、
５．スタブ２２１が、アンマーシャルされた引数でサービスの実際の関数を呼び出す段階と、
６．方法が、実行され、その戻り値及び戻り引数をスタブ２２１に戻す段階と、
７．スタブ２２１が、戻り引数をマーシャルし、戻りパケットを通信チャネル２１０に入れる段階と、
８．通信チャネル２１０が、パケットをクライアント・プロセス／プロセッサ２００に転送する段階と、
９．プロキシ２０１が、戻り値及び戻り引数を通知され、アンマーシャルする段階と、
１０．戻り値及び戻り引数が、元の呼出し元（クライアント）に戻される段階とを持つ。
【００１３】
図２においては、RPCを介して通信するプロセス２００及び２１０が、破線で示されるプロセッサの境界によって分けられるように示されている。この境界は、或るプロセッサから別のプロセッサへの通信が行なわれることを示す。２つプロセッサ２００及び２１０は、ネットワークを介して接続される２つの全く別のコンピュータシステム中のものであり得るが、単一のコンピュータシステム中のものでもあり得る。プロセッサの境界はまた仮想的なものであり得る。即ち、単一のプロセッサが、クライアントのためのタスクとサーバのためのタスクとを切り換え得る。
【００１４】
RPC機構は、スタブを介して遠隔プロセッサ上の関数を呼び出すのに用いられる１つ以上のタスクを持つプールを持つ。プロキシは遠隔関数のローカル表現(local representation)である。呼び出し元にとって、関数がローカルであるように見える（斯くして、位置透明性を供給する）。
【００１５】
図１のストリーミングシステムはアプリケーション１０５とストリーミングコンポーネント１０１乃至１０４との間の通信を可能にするためにRPCを用い得る。例えば、ユーザイベントのために等化器の設定が変化すると仮定する。結果として、アプリケーションコード１０５は、等化コンポーネント１０３の制御関数、例えばSetBassLevel(float_level)を呼び出す。前記コンポーネントにこの関数を供給するローカルプロキシがある。プロキシは、関数ID及び関数引数レベルをパケットにマーシャルし、これを等化コンポーネント１０３がランするストリーミングプロセッサに送る。
【００１６】
ストリーミングプロセッサにおいては、割込みがRPC機構のワーカタスク(worker task)を呼び起こし、前記ワーカタスクが、通信チャネルからパケットをフェッチし、このパケットをアンマーシャルし、実際のコンポーネントのSetBassLevel関数を呼び出す。等化コンポーネントは、メッセージをその分離待ち行列に入れることによって、SetBassLevel関数を実施する。等化コンポーネントがより多くのオーディオデータをフェッチする直前に、等化コンポーネントは、コマンド待ち行列をチェックし、保留中のメッセージ（pending message）を見つけ、対応ハンドラを呼び出す。このハンドラは新しいバスレベルを設定し、その後、オーディオストリーミングは新しい等化器設定を用いて処理される。
【００１７】
ストリーミングコンポーネントを制御するために一般的なRPCが用いられる場合には、図３に示されているような状況が起こる。制御コマンドがマーシャルされ、コマンド待ち行列２１０に入れられた後に、ストリーミングプロセッサにおいて、割込みが起こされ、これはISR（割込みサービスルーチン）をトリガする。このルーチンは関数呼出しを取り扱うRPCのタスクを起動する。メッセージを分離待ち行列に入れる実際のストリーミングコンポーネント３２２の関数が呼び出される。ストリーミングコンポーネント３２２は、そのアルゴリズム中の或る時点で、メッセージがあるか否かをチェックし、ある場合には、メッセージが実行される。
【００１８】
ストリーミングと一緒に一般的なRPCを用いる主な不利な点は、ストリーミングコンポーネント３２２の分離待ち行列にメッセージを入れるためにRPCタスクが起動されなければならないことにある。（高速応答を得るために高い優先順位を持つ）RPCタスクを起動することは、ストリーミングタスクに先取りされるという不利な点を持つ。結果として、データ及び命令のキャッシュが部分的にクリアされる。これは、キャッシュ使用について最適化されるストリーミングコンポーネントのパフォーマンスを低下させる。
【００１９】
図４は、２つの通信チャネル、即ち、コマンド待ち行列４１０及び従来のRPC機構４１１を示しており、コマンド待ち行列４１０及び従来のRPC機構４１１は両方とも制御のために用いられる。共用変数又は他の機構も通信チャネルとして用いられ得る。コマンド待ち行列機構４１０は、実行時制御のために用いられ、ストリーミングプロセッサにおける割込み及びコンテキスト切り替えの数を減少させ、これは、状況をより効率的にする。RPC機構４１１はアクティブチャネルである。即ち、RPC機構４１１は単独で通信を開始する。コマンド待ち行列４１０はパッシブチャネルである。即ち、コマンド待ち行列４１０は、コマンド待ち行列４１０をチェックするのにストリーミングコンポーネントタスクの活動を必要とし、それ故、ストリーミングコンポーネントがランしている場合にしか用いられ得ない。ストリーミングコンポーネントの作成、破棄(destroying)、開始及び停止は、今までどおり、従来のRPC機構のようなアクティブ通信チャネルを必要とする。幸いなことに、これらのコマンドは、典型的には、非常に低い頻度で行なわれる。
【００２０】
本発明において、ストリーミングコンポーネントは、
１．アプリケーションの実行コンテキストにおいてランする制御部Ｔ（頂部）と、
２．ストリーミングアルゴリズムの実行コンテキストにおいてランするストリーミング部
Ｂ（底部）との２つの部分に分割される。
【００２１】
両部分に分割されるが、これらの２つの部分は、両方とも、各ストリーミングコンポーネントに特有のものである。この分割は、標準的なRPC機構の使用より効率的である、プロセス／プロセッサで共用される通信チャネルを使用することを可能にする。アプリケーションの機能の観点からは、あたかも、ストリーミングコンポーネントが（RPCにおけるプロキシの場合と同様に）アプリケーションと同じ実行コンテキストにおいてランするように見える。
【００２２】
再び図１のストリーミングシステムを考察する。等化コンポーネント１０３の設定が上記のように変化する場合には、アプリケーションコード１０５がコンポーネント１０３のSetBassLevel(float_level)関数を呼び出す。コンポーネント１０３にこの関数を供給するローカル部（頂部）がある。頂部Ｔは、関数ＩＤ及び関数引数レベルをメッセージにマーシャルし、ストリーミングコンポーネント３２２のコマンド待ち行列４１０に直接的にこれを送り、ストリーミングコンポーネント３２２の底部Ｂはストリーミングプロセッサにおいてランする。ストリーミングコンポーネント３２２がより多くのオーディオデータをフェッチする直前に、ストリーミングコンポーネント３２２は、コマンド待ち行列４１０をチェックし、保留中のメッセージを見つけ、対応ハンドラを呼び出す。このハンドラは新しいバスレベルを設定し、その後、オーディオストリーミングは、新しい等化器設定を用いて処理される。
【００２３】
「従来の」ストリーミングコンポーネントと、コンポーネントのための新しい状況との間の相違点が図５に図示されている。通信機構は考慮から除外され、状況に依存する実施例が例示され得る。例：
−  アプリケーション及びストリーミングコンポーネントが同じプロセス中にある場合にはRPC機構が通常の関数呼出しに縮小され得る。
−  共用変数５０１（例えばレジスタ）が用いられ得る。
−  アプリケーション及びストリーミングが同じプロセッサ上にある（しかし、異なるスレッド又はプロセス中にある）場合にコマンド待ち行列が分離待ち行列によって簡単に実施され得る。コマンド待ち行列がプロセッサの境界を越える場合には、コマンド待ち行列は共用メモリを用いて実施され得る。
【００２４】
マルチプロセス／プロセッサシステムにおけるストリーミングコンポーネントの制御のためのパッシブ通信チャネルの使用は、少なくとも以下の利点を持つ。
１．制御及びストリーミング部がスレッド／プロセス／プロセッサの境界によって分けられるか否かとは無関係に、アプリケーションスレッドはパッシブ通信チャネルに直ちに書き込むことが出来る。
２．制御を取り扱うためにストリーミングコンテキストにおいてスレッドが起動される必要がない。ストリーミングアルゴリズムは、独立してランし、該アルゴリズム自身の規定された時点で制御が存在するか否かをチェックする。それ故、マルチプロセッサシステムの場合に、これは、パフォーマンスをそこなうであろうストリーミングプロセッサに割込みをかける必要性がないようにする。
３．介在するRPCタスクが必要とされないことから、制御における応答はより高速になる。
４．従来のアプローチにおいては、タスクプール中のRPCタスクに正しい優先順位を割り当てることは困難である。提案されているアプローチにおいては、実行時コマンドが、自動的に、ストリーミングコンポーネント（理想的な状況）と同じ優先順位において取り扱われる。
５．（時としてストリーミングプロセッサとして用いられる、フィリップスのTriMedia ICなどの）超長命令語(VLIW)プロセッサにおけるコードは、（しばしば制御プロセッサとして用いられる、MIPS又はARMチップなどの）標準的なRISCプロセッサにおけるコードよりテキストサイズが大きい。コンポーネントの制御部のコードをこのようなストリーミングプロセッサからこのような制御プロセッサに移すことによって、テキストサイズは縮小する。
６．制御コード（多数のブランチ）の実行は、VLIWがこのようなコードの命令レベル並列度を活用することが出来ないことから、VLIWにおいては、RISCプロセッサより非効率的に実行される。コンポーネントの制御部のコードをこのようなストリーミングプロセッサからこのような制御プロセッサに移すことによって、相対的なパフォーマンスは増大する。
７．多数のストリーミングコンポーネントから成るサブシステムは制御とストリーミングとの間に同様の分離を持つ。サブシステムの主要な付加される値である制御コードは制御プロセッサにおいてランする。それ故、コードのテキストサイズ及び相対的な実行パフォーマンスの利点はサブシステムに対しても成り立つ。
【００２５】
上記の実施例は、本発明を限定するものではなく、例示するものであり、当業者は、添付されている特許請求の範囲の範囲を外れない多くの別の実施例を設計することが出来るであろうことに注意されたい。
【００２６】
特許請求の範囲において、括弧内に配置された如何なる参照符号も特許請求の範囲を限定するものとして解釈されるべきでない。「有する」という用語は、特許請求の範囲において列挙されている要素又はステップ以外の要素又はステップの存在を除外しない。要素の単数形表記は、斯様な要素の複数の存在を除外しない。本発明は、幾つかの別個の素子を有するハードウェアにより実施され得るし、適当にプログラムされたコンピュータにより実施され得る。
【００２７】
幾つかのコンポーネントを列挙しているシステムクレームにおいては、これらのコンポーネントの幾つかはハードウェアの同一アイテムにより実施され得る。単に、或る方策が互いに異なる従属項において列挙されているという事実は、これらの方策の組み合わせが有利に用いられ得ないことを示さない。
【図面の簡単な説明】
【００２８】
【図１】MP3フォーマットのストリーミング音楽データを処理するよう構成される例示的なデータ処理システムを概略的に示す。
【図２】遠隔手順呼出し（RPC）の基本機構を図示する。
【図３】ストリーミングコンポーネントを制御するために用いられているRPC機構を図示する。
【図４】図２の機構に加えて各コンポーネントのために専用の通信チャネルを用いることによって、制御がどのようにより効率的に行なわれ得るかを示す。
【図５】「従来の」ストリーミングコンポーネントと、本発明に基づいて動作するストリーミングコンポーネントとの間の相違点を図示する。
【図６】図２、３、４及び５において用いられる符号の説明書きである。
【図６】
2005506629.tif 000003
【国際公開パンフレット】
2005506629.tif 000004
2005506629.tif 000005
2005506629.tif 000006
2005506629.tif 000007
2005506629.tif 000008
2005506629.tif 000009
2005506629.tif 000010
2005506629.tif 000011
2005506629.tif 000012
2005506629.tif 000013
2005506629.tif 000014
2005506629.tif 000015
2005506629.tif 000016
2005506629.tif 000017
2005506629.tif 000018
2005506629.tif 000019
【国際公開パンフレット（コレクトバージョン）】
2005506629.tif 000020
2005506629.tif 000021
【国際調査報告】
2005506629.tif 000022
2005506629.tif 000023
2005506629.tif 000024