(57)【要約】本発明は、複数の処理要素を有するデータ処理システムにおけるタスク管理に関する。そのために、データ・オブジェクトのストリームを処理するための少なくとも第１の処理要素と第２の処理要素とを備え、第１の処理要素が、データ・オブジェクトのストリームから第２の処理要素にデータ・オブジェクトを渡すように構成されているデータ処理システムが提供される。第１および第２の処理要素は、タスク群を備えるアプリケーションを並列実行するように構成され、かつ第１および第２の処理要素は、一意の識別子の受信に応答するように構成される。アプリケーションの再構成中にデータの完全性を保証するために、一意の識別子が、データ・ストリームに挿入され、１つの処理要素から別の処理要素に渡される。アプリケーション再構成は、対応する処理要素が一意の識別子を受信したときに行われ、その結果、データ空間内の一意の位置で、グローバル・アプリケーション制御が可能になる。
2006519432.tif 000002
【特許請求の範囲】
【請求項１】
データ・オブジェクトのストリームを処理するための少なくとも第１の処理要素と第２の処理要素とを備えるデータ処理システムであって、前記第１の処理要素が、前記データ・オブジェクトのストリームから前記第２の処理要素にデータ・オブジェクトを渡すように構成され、
前記第１および第２の処理要素が、アプリケーションを実行するように構成され、前記アプリケーションがタスク群を備え、
前記第１および第２の処理要素の少なくとも１つが、一意の識別子の受信に応答するように構成され、
前記データ・オブジェクトのストリームが、さらに前記一意の識別子を備えること、および
前記第１の処理要素が、さらに前記一意の識別子を前記第２の処理要素に渡すように構成されていること
を特徴とするデータ処理システム。
【請求項２】
前記処理要素の少なくとも１つが、前記一意の識別子を前記データ・オブジェクトのストリームに挿入するように構成されていることを特徴とする請求項１に記載のデータ処理システム。
【請求項３】
前記タスク群の少なくとも１つのタスクが、プログラム可能な識別子を有するように構成され、前記第１および第２の処理要素の対応する処理要素が、前記プログラム可能な識別子を前記一意の識別子と比較するように構成されていることを特徴とする請求項１に記載のデータ処理システム。
【請求項４】
前記第１および第２の処理要素の少なくとも１つの処理要素が、前記プログラム可能な識別子と前記一意の識別子との合致の際に、前記タスク群の対応するタスクを休止するように構成されていることを特徴とする請求項３に記載のデータ処理システム。
【請求項５】
前記第１および第２の処理要素の少なくとも１つの処理要素が、前記プログラム可能な識別子と前記一意の識別子との合致の際に、割込み信号を生成するように構成されていることを特徴とする請求項３に記載のデータ処理システム。
【請求項６】
前記第１および第２の処理要素の少なくとも１つの処理要素が、前記一意の識別子を記憶するように構成されていることを特徴とする請求項３に記載のデータ処理システム。
【請求項７】
前記第１および第２の処理要素の少なくとも１つの処理要素が、前記プログラム可能な識別子と前記一意の識別子との比較の結果を記憶するように構成されていることを特徴とする請求項３に記載のデータ処理システム。
【請求項８】
さらに制御処理要素を備え、前記制御処理要素が、前記割込み信号に応答して前記アプリケーションを再構成するように構成されていることを特徴とする請求項５に記載のデータ処理システム。
【請求項９】
前記データ・オブジェクトのストリームが、
データ・オブジェクトを記憶するように構成された複数のパケットと、
前記一意の識別子を記憶するように構成された専用のパケットと
を備えることを特徴とする請求項１に記載のデータ処理システム。
【請求項１０】
データ処理システムを制御する方法であって、前記データ処理システムが、データ・オブジェクトのストリームを処理するための少なくとも第１の処理要素と第２の処理要素とを備え、前記第１の処理要素が、前記データ・オブジェクトのストリームから前記第２の処理要素にデータ・オブジェクトを渡すように構成され、前記第１および第２の処理要素が、アプリケーションを実行するように構成され、前記アプリケーションがタスク群を備え、前記制御方法が、
前記第１および第２の処理要素の少なくとも１つによって一意の識別子を認識するステップを含み、
さらに、
前記一意の識別子を前記データ・オブジェクトのストリームに挿入するステップと、
前記一意の識別子を前記第１の処理要素から前記第２の処理要素に渡すステップと
を含むことを特徴とするデータ処理システムを制御する方法。
【請求項１１】
前記一意の識別子を前記データ・オブジェクトのストリームに挿入する前記ステップが、前記処理要素の少なくとも１つによって行われることを特徴とする請求項１０に記載のデータ処理システムを制御する方法。
【請求項１２】
さらに、
前記タスク群の少なくとも１つのタスクにおいて識別子をプログラムするステップと、
前記第１および第２の処理要素の対応する処理要素によって、前記一意の識別子を前記プログラムされた識別子と比較するステップと
を含むことを特徴とする請求項１０に記載のデータ処理システムを制御する方法。
【請求項１３】
さらに、
前記タスクの前記プログラム可能な識別子と前記一意の識別子との合致の際に、前記第１および第２の処理要素の対応する処理要素によって、前記タスク群のタスクを休止するステップ
を含むことを特徴とする請求項１２に記載のデータ処理システムを制御する方法。
【請求項１４】
さらに、
前記複数のタスクのうち対応するタスクの前記プログラム可能な識別子と前記一意の識別子との合致の際に、前記第１および第２の処理要素の１つの処理要素によって、割込み信号を生成するステップ
を含むことを特徴とする請求項１２に記載のデータ処理システムを制御する方法。
【請求項１５】
さらに、
前記複数のタスクのうち対応するタスクに関して、前記第１および第２の処理要素の１つの処理要素によって、前記一意の識別子を記憶するステップ
を含むことを特徴とする請求項１２に記載のデータ処理システムを制御する方法。
【請求項１６】
さらに、
前記複数のタスクのうち対応するタスクに関して、前記第１および第２の処理要素の１つの処理要素によって、前記プログラム可能な識別子と前記一意の識別子との比較の結果を記憶するステップ
を含むことを特徴とする請求項１２に記載のデータ処理システムを制御する方法。
【請求項１７】
前記データ処理システムが、さらに制御処理要素を備えること、および前記方法が、さらに、
前記割込み信号に応答して、前記制御処理要素によって前記アプリケーションを再構成するステップ
を含むことを特徴とする請求項１４に記載のデータ処理システムを制御する方法。
【請求項１８】
前記データ・オブジェクトのストリームが
データ・オブジェクトを記憶するように構成された複数のパケットと、
前記一意の識別子を記憶するように構成された専用のパケットと
を備えることを特徴とする請求項１０に記載のデータ処理システムを制御する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ・オブジェクトのストリームを処理するための少なくとも第１の処理要素と第２の処理要素とを備えるデータ処理システムであって、第１の処理要素が、データ・オブジェクトのストリームから第２の処理要素にデータ・オブジェクトを渡すように構成され、第１および第２の処理要素が、アプリケーションを実行するように構成され、アプリケーションがタスク群を備え、第１および第２の処理要素が、一意の識別子の受信に応答するように構成されているデータ処理システムに関する。
【０００２】
本発明は、さらに、データ処理システムを制御する方法であって、データ処理システムが、データ・オブジェクトのストリームを処理するための少なくとも第１の処理要素と第２の処理要素とを備え、第１の処理要素が、データ・オブジェクトのストリームから第２の処理要素にデータ・オブジェクトを渡すように構成され、第１および第２の処理要素がアプリケーションを実行するように構成され、アプリケーションがタスク群を備え、制御方法が第１および第２の処理要素の１つによって一意の識別子を認識するステップを含む制御方法に関する。
【背景技術】
【０００３】
高性能のデータ依存メディア処理、例えば高精度ＭＰＥＧ復号化のための複数処理要素アーキテクチャが知られている。メディア処理アプリケーションは、同時実行タスク群と規定することができ、このタスク群は、一方向のデータ・ストリームによってのみ情報を交換する。Ｇ．Ｋａｈｎが、１９７４年に、「The Semantics of a Simple Language for Parallel Programming」，Proc.of the IFIP congress 1974,August 5-10,Stockholm Sweden,North-Holland publ.Co,1974,pp.471-475で、そのようなアプリケーションの形式モデルを発表しており、その後、１９７７年に、ＫａｈｎおよびＭａｃＱｕｅｅｎが、「Co-routines and Networks of Parallel Programming」,Information Processing 77,B.Gilchhirst(Ed),North-Holland publ.,1977,pp.993-998で動作説明をしている。この形式モデルは、一般に、カーン・プロセス・ネットワーク（Kahn Process Network）と呼ばれる。
【０００４】
アプリケーションは、同時実行可能なタスク群として知られている。情報は、一方向のデータ・ストリームによってのみ、タスク間で交換することができる。タスクは、事前定義されたデータ・ストリームに関する読取りおよび書込み動作によって決定論的にのみ通信すべきである。データ・ストリームは、ＦＩＦＯ動作に基づいてバッファされる。バッファリングにより、ストリームを通して通信する２つのタスクが、個々の読取りまたは書込み動作を同期する必要がない。
【０００５】
ストリーム処理中、様々な処理要素によって、データ・ストリームの連続操作が行われる。例えば、第１のストリームが画像の画素値からなる場合があり、この値が、第１の処理要素によって処理されて、８×８画素ブロックの離散コサイン変換（ＤＣＴ）係数のブロックの第２のストリームが生成される。第２の処理要素は、ＤＣＴ係数のブロックを処理して、ＤＣＴ係数の各ブロックに関して、選択され圧縮された係数のブロックのストリームを生成することができる。
【０００６】
図１に、従来技術で知られている複数処理要素アーキテクチャへのアプリケーションのマッピングの例を示す。データ・ストリーム処理を実現するために、複数の処理要素（Proc1、Proc2、Proc3）が提供され、それぞれが、毎回、データ・オブジェクトのストリームからの次のデータ・オブジェクトからのデータを使用して、かつ／またはそのようなストリーム内で次のデータ・オブジェクトを生成して、特定の操作を繰り返し行うことが可能である。ストリームは、１つの処理要素から別の処理要素に渡り、したがって、第１の処理要素によって生成されたストリームを、第２の処理要素などによって処理することができる。第１の処理要素から第２の処理要素にデータを渡す１つの機構は、第１の処理要素によって生成されたデータ・ブロックをメモリに書き込むことによるものである。
【０００７】
ネットワーク内のデータ・ストリームはバッファされる。各バッファは、厳密には１つの書込み側と１つまたは複数の読取り側とを有するＦＩＦＯとして実現される。このバッファリングにより、書込み側および読取り側は、チャネル上での個々の読取りおよび書込み動作を相互に同期する必要がない。利用可能なデータが十分でない状態のチャネルからの読取りは、読取りタスクを機能停止させる。処理要素は、ほんのわずかに（only weakly)プログラム可能な専用ハードウェア機能ユニットにすることができる。全ての処理要素が並列に走り、それ自体の制御スレッドを実行する。それと共に、処理要素は、カーンスタイルのアプリケーションを実行し、各タスクが単一の処理要素上にマップされる。処理要素は、マルチタスクを可能にする。すなわち、複数のタスクを単一の処理要素上にマップすることができる。
【０００８】
アプリケーション全体の状態および進行は、時間および空間的に分散されるので、アプリケーション管理は、アプリケーション進行を解析し、かつデバッグするアプリケーション再構成の問題に直面する。特に、タスクを動的にスケジュールするマルチタスク処理要素では、グローバル・アプリケーションを制御するのが困難である。アプリケーション・モード変更を求める非要求イベントが発生する可能性がある。アプリケーション全体の進行の解析は、データ依存処理およびリアルタイム要求を伴うシステムでは継続的な問題である。さらに、マルチタスク処理要素を備えるマルチプロセッサ・システム上でのアプリケーションのデバッグは、タスク毎にブレークポイントを設定できることを必要とする。モード変更のために実行中のタスクに立ち入るには、タスク・ブレークポイントを設定するのに必要なものと同等の手段を必要とする。
【０００９】
米国特許第６４５７１１６号が、処理要素のネットワーク内で処理要素の局所制御を提供するための装置を説明している。処理要素は、複数の相互接続構造によって完全なアレイとして接合される。各相互接続構造が独立のネットワークを形成し、しかしそれらのネットワークは、処理要素の入力スイッチでつながっている。ネットワーク構造は、単一の送信元と、個々の処理要素を書き込むことができる複数の受信側とを備えるＨツリー・ネットワーク構造である。この構成ネットワークは、処理要素の構成メモリをプログラムし、さらに構成データを通信する機構である。構成ネットワークは、受信側が、同じクロック・サイクル中に同報通信を受信するように構成される。処理要素は、複数の構成メモリ・コンテキストを記憶するように構成され、選択された構成メモリ・コンテキストが処理要素を制御する。処理要素のネットワーク化アレイ内の各処理要素が、割り当てられた物理的な識別を有する。制御データと、構成データと、アドレス・マスクと、宛先識別とを備えるデータが、アレイの処理要素の少なくとも１つに伝送される。伝送されたアドレス・マスクは、物理的な識別および宛先識別に適用される。マスクされた物理的な識別とマスクされた宛先識別とが比較され、それらが合致する場合、伝送されたデータに応答して複数の処理要素の少なくとも１つが操作される。操作は、処理要素の機能を制御するために複数の構成メモリ・コンテキストの１つを選択することを含む。米国特許第６１０８７６０号が、処理要素のネットワーク内での位置独立再構成のための同等の装置を説明している。操作は、少なくとも１つの構成メモリ・コンテキストを用いて処理要素をプログラムすることを含む。
【００１０】
従来技術データ処理システムの欠点は、再構成が特定の時点で行われることである。例えば、処理要素のパイプライン化ネットワークの場合、特定の時点での再構成は、パイプライン化ネットワーク内部のデータ完全性をもはや保証することができないことを意味する。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明の目的は、カーンスタイルのデータ処理システムでのグローバル・アプリケーション制御のための包括的な解決策を提供することである。
【課題を解決するための手段】
【００１２】
この目的は、上述したようなデータ処理システムであって、データ・オブジェクトのストリームが、さらに一意の識別子を備えること、および第１の処理要素が、さらに一意の識別子を第２の処理要素に渡すように構成されていることを特徴とするデータ処理システムを用いて実現される。
【００１３】
順序付けられたデータ・ストリーム内の要素として、データ処理システム内で１つの処理要素から別の処理要素に一意の識別子を渡すことにより、単一時点の場合とは対照的に、データ空間内の一意の位置でグローバル・アプリケーション制御が可能になる。例えば、パイプライン処理を維持し、かつデータ・オブジェクトのストリーム内のデータの完全性を維持しながら、アプリケーション再構成または個別タスク再構成を行うことができる。その結果、アプリケーションの実行の終了および再始動を回避することができるので、データ処理システムの全体の性能が高まる。
【００１４】
本発明によるデータ処理システムの一実施形態は、少なくとも１つの処理要素が、一意の識別子をデータ・オブジェクトのストリームに挿入するように構成されていることを特徴とする。アプリケーションが再構成できる状態になっている場合、またはブレークポイントを導入すべき場合、既存の処理要素の１つが、任意の追加の手段を必要とせずに、一意の識別子をデータ・ストリームに挿入することが可能である。
【００１５】
本発明によるデータ処理システムの一実施形態は、タスク群の少なくとも１つのタスクが、プログラム可能な識別子を有するように構成され、第１および第２の処理要素の対応する処理要素が、プログラム可能な識別子を一意の識別子と比較するように構成されていることを特徴とする。プログラム可能な識別子の目的は、データ・ストリームを介して送られる特定の一意の識別子に対する応答を可能にすることである。一意の識別子への応答はタスク毎にプログラムされ、それにより、各タスクが個別の様式で応答することができる。このようにすると、プログラム可能な識別子は、マルチタスク処理要素の場合に、再構成すべきタスクの選択を可能にする。実行中のタスクに関するプログラム可能な識別子と一意の識別子とが合致する場合、それは、タスクが再構成できる状態になっていることを意味する。比較は、これら２つの識別子が同じ値を有するときに、または例えば、プログラム可能な識別子が、常に合致を強制する保留値を有するときに、合致の結果を与える。
【００１６】
本発明によるデータ処理システムの一実施形態は、第１および第２の処理要素の少なくとも１つの処理要素が、プログラム可能な識別子と一意の識別子との合致の際に、タスク群の対応するタスクを休止するように構成されていることを特徴とする。この実施形態の利点は、１つまたは複数のタスクの実行が、データ空間内のよく定義された点で中断されることである。後の時点で、再構成に関わるタスクがさらにその時点で当該の実行パスにない状態で、アプリケーションの再構成を行うことができる。
【００１７】
本発明によるデータ処理システムの一実施形態は、第１および第２の処理要素の少なくとも１つの処理要素が、プログラム可能な識別子と一意の識別子との合致の際に、割込み信号を生成するように構成されていることを特徴とする。割込み信号を生成することによって、対応する処理要素は、タスクが再構成できる状態になっていることを合図することができ、またはその割込み信号を使用して、タスク実行の進行を決定することができる。
【００１８】
本発明によるデータ処理システムの一実施形態は、データ処理システムが、さらに制御処理要素を備え、制御処理要素が、割込み信号に応答してアプリケーションを再構成するように構成されていることを特徴とする。タスク再構成に必要とされる情報は、一意の識別子に関係せず、一意の識別子の転送および合致の機構をタスク機能から独立させることができる。その結果、この機構は、再使用可能なハードウェアまたはソフトウェア構成要素で実施することができる。
【００１９】
本発明によるデータ処理システムの一実施形態は、データ・オブジェクトのストリームが、データ・オブジェクトを記憶するように構成された複数のパケットと、一意の識別子を記憶するように構成された専用のパケットとを備えることを特徴とする。処理要素は、例えばパケット・ヘッダに基づいて専用のパケットを識別し、データ・オブジェクトのストリームを乱すことなく、これらのパケットを変更せずに転送する。
【００２０】
本発明によれば、データ処理システムを制御する方法が、さらに、一意の識別子をデータ・オブジェクトのストリームに挿入するステップと、一意の識別子を第１の処理要素から第２の処理要素に渡すステップとを含む。この方法は、データ処理システム上を走るアプリケーションのデータ完全性を維持しながら、ランタイム再構成を可能する。再構成に加えて、一意の識別子を使用して、デバッグ・ブレークポイントを定義し、かつアプリケーション待ち時間を求めることもできる。
【００２１】
データ処理システムおよびデータ処理システムを制御する方法のさらなる実施形態は、添付された特許請求の範囲に記載されている。
【発明を実施するための最良の形態】
【００２２】
図２に、本発明によるデータ・オブジェクトのストリームを処理するための処理システムを示す。このシステムは、中央処理装置ＣＰＵと、３つのコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣと、メモリＭＥＭと、シェルＳＰ、ＳＡ、ＳＢ、およびＳＣと、通信網ＣＮとを備える。シェルＳＰ、ＳＡ、ＳＢ、およびＳＣは、それぞれ、プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣに関連付けられている。通信網ＣＮは、シェルＳＰ、ＳＡ、ＳＢ、およびＳＣとメモリＭＥＭとを結合する。プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、それらの対応するシェルＳＰ、ＳＡ、ＳＢ、およびＳＣに、それぞれインタフェースＩＰ、ＩＡ、ＩＢ、およびＩＣを介して結合される。別の実施形態では、異なる数のプロセッサおよび／またはコプロセッサをシステム内に含めることができる。メモリＭＥＭは、例えばオンチップ・メモリにすることができる。プロセッサＣＰＵは、プログラム可能なメディア・プロセッサにすることができ、コプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、好ましくは専用プロセッサであり、それぞれが、限られた範囲のストリーム処理を行うように特殊化されている。各コプロレッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、１つのストリームの連続するデータ・オブジェクトに対して同じ処理操作を繰り返し行うように構成されている。コプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、それぞれ異なるタスクまたは機能、例えば可変長復号化、ランレングス復号化、動き補償、イメージ・スケーリング、またはＤＣＴ変換を行うことができる。動作中、各コプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、１つまたは複数のデータ・ストリームに対して操作を実行する。この操作は、例えば、ストリームを受信して別のストリームを生成すること、新たなストリームを生成せずにストリームを受信すること、ストリームを受信せずにストリームを生成すること、または受信したストリームを修正することを含む場合がある。プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、他のコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣによって、またはプロセッサＣＰＵによって生成されたデータ・ストリームを処理することができ、あるいは、それ自体が生成したストリームを処理することもできる。ストリームは一連のデータ・オブジェクトを備え、データ・オブジェクトは、通信網ＣＮおよびメモリＭＥＭを介して、プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣから転送され、かつそれらへ転送される。インタフェースＩＰ、ＩＡ、ＩＢ、およびＩＣは、プロセッサ・インタフェースであり、これらは、関連付けられたプロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣに合わせてカスタマイズされて、プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣの特定の要求を取り扱うことができるようになっている。したがって、シェルＳＰ、ＳＡ、ＳＢ、およびＳＣは、プロセッサ（コプロセッサ）特定インタフェースを有し、しかしシェルＳＰ、ＳＡ、ＳＢ、およびＳＣのアーキテクチャ全体は一般的なものであり、全てのプロセッサ（コプロセッサ）に対して一様であり、したがってシステム・アーキテクチャ全体の中でのシェルの再使用が容易であり、それと同時に特定のアプリケーションのためのパラメータ化および採用が可能である。別の実施形態では、システムは、複数の接続と、複数のデータ記憶用の特殊化バッファとを用いて、プロセッサ（コプロセッサ）、シェル、およびメモリの間のより専用化されたアプリケーション特定相互接続構造を有することができる。さらに別の実施形態では、システムは、データ・オブジェクトのストリームを処理するための複数のプログラム可能なプロセッサを備えることができ、そのようなシステムでは、シェルの機能は、ソフトウェアの形で実施することができる。
【００２３】
シェルＳＰ、ＳＡ、ＳＢ、およびＳＣは、データ移送用の読取り／書込みユニットと、同期ユニットと、タスク切替えユニットとを備える。シェルＳＰ、ＳＡ、ＳＢ、およびＳＣは、関連付けられたプロセッサ（コプロセッサ）とマスタ／スレーブ・ベースで通信し、その際、プロセッサ（コプロセッサ）がマスタとして働く。したがって、シェルＳＰ、ＳＡ、ＳＢ、およびＳＣは、対応するプロセッサ（コプロセッサ）からの要求によって初期設定される。好ましくは、対応するプロセッサ（コプロセッサ）とシェルＳＰ、ＳＡ、ＳＢ、およびＳＣとの通信は、引数値を引き渡して、要求された値が返されるのを待つように、要求応答ハンドシェーク機構によって実施される。したがって、通信がブロッキングする。すなわち、当該の制御スレッドがその完了を待つ。シェルＳＰ、ＳＡ、ＳＢ、およびＳＣの機能は、ソフトウェアおよび／またはハードウェアの形で実施することができる。
【００２４】
読取り／書込みユニットは、好ましくは、２つの異なる操作、すなわち、プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣがメモリＭＥＭからデータ・オブジェクトを読み取ることができるようにする読取り操作と、プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣがメモリＭＥＭにデータ・オブジェクトを書き込むことができるようにする書込み操作とを実施する。
【００２５】
同期ユニットは、同期のための２つの操作を実施し、それぞれ、空のＦＩＦＯから読み取る、または満杯のＦＩＦＯに書き込む試みが生じる局所的なブロッキング状態に対処する。
【００２６】
図２によるシステム・アーキテクチャは、マルチタスクをサポートし、これは、複数のアプリケーション・タスクを、単一のプロセッサＣＰＵ、またはコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣ上にマップすることができることを意味する。マルチタスク・サポートは、ある範囲のアプリケーションを構成し、かつデータ処理システム内の異なる場所で同じハードウェアプロセッサを再適用することができるようにアーキテクチャの柔軟性を実現するのに重要である。マルチタスクは、適切なアプリケーション進行を得るためにどの時点でどのタスクをプロセッサ（コプロセッサ）が実行しなければならないかを決定するプロセスとして、タスク切替えユニットを必要とすることを意味する。好ましくは、固定コンパイル時間スケジュールとは対照的に、ランタイムでタスク・スケジューリングが行われる。
【００２７】
プロセッサＣＰＵは、データ処理システムを制御するための制御プロセッサを備える。データ・オブジェクトのストリームは、データを保持する複数のデータ・パケットを備える。効率の良いデータのパケット化のために、データ・ストリーム上で可変長パケットが使用される。
【００２８】
図３に、上述したストリーム・ベースの処理システム上にマップされた例示アプリケーションの概略ブロック図を示す。アプリケーションは、タスクＴＡ、ＴＢ１、ＴＢ２、ＴＣ、およびＴＰの組として実行され、これらのタスクは、データ・ストリームＤＳ＿Ｑ、ＤＳ＿Ｒ、ＤＳ＿Ｓ、およびＤＳ＿Ｔを含むデータ・ストリームを介して通信する。タスクＴＡは、コプロセッサＰｒｏｃＡによって実行され、タスクＴＢ１およびＴＢ２は、コプロセッサＰｒｏｃＢによって実行され、タスクＴＣは、コプロセッサＰｒｏｃＣによって実行され、タスクＴＰは、プロセッサＣＰＵによって実行される。代替実施形態では、アプリケーションが、プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣ上への異なるマッピングを伴う異なるタスク群からなる場合がある。データ・ストリームＤＳ＿Ｑ、ＤＳ＿Ｒ、ＤＳ＿Ｓ、およびＤＳ＿Ｔは、それぞれＦＩＦＯバッファＢＱ、ＢＲ、ＢＳ、およびＢＴを含むので、バッファされたデータ・ストリームである。ＦＩＦＯバッファＢＱ、ＢＲ、ＢＳ、およびＢＴは、メモリＭＥＭ内に物理的に割り振られる。
【００２９】
アプリケーションの実行中、タスクを、図３に示されるアプリケーション・グラフに動的に追加しなければならない、またはアプリケーション・グラフから動的に除去しなければならない場合がある。ＦＩＦＯバッファＢＱ、ＢＲ、ＢＳ、およびＢＴに記憶されたデータの不整合性の問題をもたらさずにこの操作を行うために、データ空間内の特定の位置でタスク再構成が行われる。この再構成を行うことができるように、いわゆる位置ＩＤの形での一意の識別子がデータ・ストリームに挿入され、この位置ＩＤは、専用のパケットに記憶される。データ・パケットおよび位置ＩＤパケットのための一様なパケット・ヘッダが、パケット・タイプおよびそのペイロード・サイズに関する情報を含む。位置ＩＤパケットは、それらの一意のパケット・タイプによって他のパケットから見分けることができる。シェルＳＰ、ＳＡ、ＳＢ、およびＳＣは、対応するプロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣ上にマップされた各タスクのためのプログラム可能フィールドを備えるタスク・テーブルを含む。プログラム可能フィールドは、プログラム位置ＩＤを記憶するために使用される。プログラム位置ＩＤは、メモリ・マップドＩＯ（ＭＭＩＯ）レジスタを用いて実現することができる。
【００３０】
プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、受信データ・ストリームを分析し、位置ＩＤパケットを認識することが可能である。位置ＩＤパケットを認識すると、プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、位置ＩＤパケットを、その出力データ・ストリームに転送する。位置ＩＤパケットを受信すると、プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣはさらに、パケットからのペイロード、すなわち位置ＩＤを、現在実行されている対応するタスクの識別子、すなわちタスクＩＤと共に、対応するインタフェースＩＰ、ＩＡ、ＩＢ、およびＩＣを介して、対応するシェルＳＰ、ＳＡ、ＳＢ、およびＳＣに渡す。プロセッサＣＰＵ、またはコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣから位置ＩＤおよびタスクＩＤを受信すると、対応するシェルＳＰ、ＳＡ、ＳＢ、およびＳＣは、該タスクＩＤを有するタスクに関して、受信された位置ＩＤをプログラム位置ＩＤと比較する。合致すると、シェルＳＰ、ＳＡ、ＳＢ、およびＳＣは、対応するプロセッサＣＰＵ、またはコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣに信号を送信することによって該タスクのさらなる処理を一時停止し、また制御プロセッサに割込み信号を送信する。
【００３１】
その後、制御プロセッサは、ソフトウェア制御の下で、局所的なタスク状態を解析または再構成することができる。再構成の後、制御プロセッサは、シェルＳＰ、ＳＡ、ＳＢ、およびＳＣに、対応するプロセッサＣＰＵ、またはコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣによる該タスクの再開を手配するように命令する。
【００３２】
プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、位置ＩＤパケットを生成し、それらをデータ・オブジェクトのストリームに挿入することが可能である。典型的には、これらの位置ＩＤパケットは、事前定義された位置、例えばＭＰＥＧフレームの末尾でのみデータ・ストリームに挿入される。プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、プロセッサ（コプロセッサ）からの新たなタスクを求める要求を受けて、制御プロセッサによって、または間接的には対応するシェルＳＰ、ＳＡ、ＳＢ、およびＳＣによって、そのような位置ＩＤパケットをデータ・ストリームに挿入するように命令される。
【００３３】
図４に、シェルＳＰ、ＳＡ、ＳＢ、およびＳＣをより詳細に示す。シェルＳＰは、タスク・テーブル４０１を備え、シェルＳＡは、タスク・テーブル４０３を備え、シェルＳＢは、タスク・テーブル４０５を備え、シェルＳＣは、タスク・テーブル４０７を備える。タスク・テーブル４０１は、タスクＴＰのためのプログラム可能フィールド４０９を備え、タスク・テーブル４０３は、タスクＴＡのためのプログラム可能フィールド４１１を備え、タスク・テーブル４０５は、それぞれタスクＴＢ＿１およびＴＢ＿２のためのプログラム可能フィールド４１３および４１５を備え、タスク・テーブル４０７は、タスクＴＣのためのプログラム可能フィールド４１７を備える。タスク・テーブル４０１、４０３、４０５、および４０７は、図４には示されていない、対応するプロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣ上で走る異なるタスクのためのより多くのプログラム可能フィールドを備えることができる。図４はまた、位置ＩＤパケット４１９を備えるデータ・ストリームＤＳ＿Ｑ、ＤＳ＿Ｒ、ＤＳ＿Ｓ、およびＤＳ＿Ｔを示す。位置ＩＤパケット４１９は、パケット・ヘッダＰＨを備える。また、データ・ストリームＤＳ＿Ｑ、ＤＳ＿Ｒ、ＤＳ＿Ｓ、およびＤＳ＿Ｔは、位置ＩＤパケット４１９の前後両方に、図４には示されていない複数のデータ・パケットを備える。また、データ・ストリームＤＳ＿Ｑ、ＤＳ＿Ｒ、ＤＳ＿Ｓ、およびＤＳ＿Ｔは、図４には示されていない、より多くの位置ＩＤパケットを備えることができる。
【００３４】
再び図２、３、および４を参照すると、制御プロセッサは、タスクＴＰ、ＴＡ、ＴＢ１、ＴＢ２、およびＴＣの組からのタスクＴＰの動的な除去を含意するアプリケーション再構成を行って、タスクＴＡをタスクＴＢ２に接続するという決定をすることができる。制御プロセッサは、それぞれタスクＴＰ、ＴＡ、およびＴＢ２のプログラム可能フィールド４０９、４１１、および４１５で、対応するタスク・テーブル４０１、４０３、および４０５に位置ＩＤを書き込むことによって、シェルＳＰ、ＳＡ、およびＳＢ内に位置ＩＤ  ＰＬＩＤ＿１をプログラムする。制御プロセッサは、コプロセッサＰｒｏｃＡに、位置ＩＤと、該位置ＩＤを含む位置ＩＤパケットを生成すべきときに関する情報とをシェルＳＡのタスク・テーブル内のタスクＴＡ用の専用レジスタに記憶することによって、位置ＩＤパケットを生成するように命令する。シェルＳＡに記憶された前記情報に基づいて、位置ＩＤ  ＬＩＤ＿１を含む位置ＩＤパケット４１９が、タスクＴＡの制御下で、コプロセッサＰｒｏｃＡによってデータ・ストリームＤＳ＿ＱおよびＤＳ＿Ｒに挿入される。タスクＴＡは、位置ＩＤ  ＬＩＤ＿１を作成することによって認識したことを合図し、コプロセッサＰｒｏｃＡに、そのタスクＩＤおよび位置ＩＤ  ＬＩＤ＿１をインタフェースＩＡを介してシェルＳＡに送信するように命令する。受信されたタスクＴＡのタスクＩＤを使用して、シェルＳＡは、タスクＴＡに関して、受信された位置ＩＤ  ＬＩＤ＿１をプログラム位置ＩＤ  ＰＬＩＤ＿１と比較して、これらの合致を判断する。シェルＳＡは、コプロセッサＰｒｏｃＡによるタスクＴＡのさらなる処理を停止して、制御プロセッサに割込み信号を送信する。タスクＴＰは、パケット・ヘッダＰＨに記憶されているパケットのタイプに関する情報から、その入力データ・ストリームＤＳ＿Ｒ内の位置ＩＤパケット４１９を認識して、プロセッサＣＰＵに、位置ＩＤパケット４１９をその出力データ・ストリームＤＳ＿Ｓに転送するように命令する。また、タスクＴＰは、プロセッサＣＰＵに、認識された位置ＩＤ  ＬＩＤ＿１をそのタスクＩＤと共に、インタフェースＩＰを介してシェルＳＰに渡すように命令する。受信されたタスクＴＰのタスクＩＤを使用して、シェルＳＰは、タスクＴＰに関して、受信された位置ＩＤ  ＬＩＤ＿１をプログラム位置ＩＤ  ＰＬＩＤ＿１と比較して、これらの合致を判断する。シェルＳＰは、プロセッサＣＰＵによるタスクＴＰのさらなる処理を停止して、制御プロセッサに割込み信号を送信する。タスクＴＢ２は、パケット・ヘッダＰＨに記憶されているパケットのタイプに関する情報から、その入力データ・ストリームＤＳ＿Ｓ内の位置ＩＤパケット４１９を認識して、プロセッサＰｒｏｃＢに、位置ＩＤパケット４１９をその出力データ・ストリームＤＳ＿Ｔに転送するように命令する。また、タスクＴＢ２は、コプロセッサＰｒｏｃＢに、認識された位置ＩＤ  ＬＩＤ＿１を、そのタスクＩＤと共にインタフェースＩＢを介してシェルＴＢに渡すように命令する。受信されたタスクＩＤを使用して、シェルＴＢは、タスクＴＢ２に関して、受信された位置ＩＤ  ＬＩＤ＿１をプログラム位置ＩＤ  ＰＬＩＤ＿１と比較して、これらの合致を判断する。シェルＳＢは、プロセッサＰｒｏｃＢによるタスクＴＢ２のさらなる処理を停止して、制御プロセッサに割込み信号を送信する。また、タスクＴＢ１およびタスクＴＣは、パケット・ヘッダＰＨに記憶されているパケットのタイプに関する情報から、当該の入力データ・ストリーム内の位置ＩＤパケット４１９を認識する。タスクＴＢ１およびタスクＴＣは、それらの対応するコプロセッサＴＢおよびＴＣに、位置ＩＤパケット４１９をそれぞれの出力データ・ストリームに転送するように命令し、また、認識された位置ＩＤ  ＬＩＤ＿１が、対応するタスクＩＤと共に、対応するシェルＳＢおよびＳＣに送信される。シェルＳＢおよびＳＣは、対応して受信されたタスクＩＤに関して、プログラム位置ＩＤが存在しないことを検出し、この点ではさらなる動作を行わない。別の実施形態では、別のプログラム位置ＩＤが、所与のタスクのためのシェルＳＰ、ＳＡ、ＳＢ、およびＳＣのタスク・テーブル内に存在する場合があり、この場合、そのタスクに対応する受信位置ＩＤは、全てのプログラム位置ＩＤと比較されて、合致が存在するかどうか検査される。タスクＴＡ、ＴＰ、およびＴＢ２が、データ・ストリーム内の同じ位置で処理を停止したので、ＦＩＦＯバッファＢＲおよびＢＳは空である。制御プロセッサは、アプリケーション・グラフからタスクＴＰを除去し、タスクＴＡとＴＢ２を、例えばＦＩＦＯバッファＢＲ、およびフリー・データ・ストリームＤＳ＿Ｓ、ならびにＦＩＦＯバッファＢＳを使用してデータ・ストリームＤＳ＿Ｒを介して再接続する。制御プロセッサは、対応するシェルＳＡおよびＳＢに情報を書き込むことによって、タスクＴＡおよびＴＢ２を再始動するように命令する。
【００３５】
位置ＩＤの概念は、マルチプロセッサ・システムでのアプリケーション・グラフのデータ完全性を維持しながら、ランタイム・アプリケーション再構成を可能にする。その結果、アプリケーションの実行の終了および再始動が必要なくなり、データ処理システムの全体の性能が高まる。アプリケーション再構成は、例えば、１つまたは複数のタスクのパラメータの変更、バッファのサイズまたはそれらのメモリ内での位置の修正、タスク相互接続構造の修正、プロセッサ（コプロセッサ）へのマッピングまたはタスクの修正、より多くのタスクまたはバッファのインスタンス生成および接続、タスクまたはバッファの除去および切断を伴う場合がある。マルチタスクプロセッサでは、プロセッサは、再構成を行いながら、他のタスクの処理を継続することができる。受信された任意の位置ＩＤに合致するように、または１つにも合致しないように、２つの特別なプログラム可能位置ＩＤ値が確保される。
【００３６】
別の実施形態では、位置ＩＤの概念は、マルチタスク処理要素を有するマルチプロセッサ・システム上で、アプリケーション全体の進行を解析するために、またはアプリケーションをデバッグするために使用することができる。位置ＩＤは、データ処理中に一意の位置でタスク毎にデバッグ・ブレークポイントを設定することを可能にし、または位置ＩＤを用いてアプリケーション待ち時間を求めることができる。アプリケーション全体の進行を解析する場合、アクティブ・タスクを休止する必要はなく、例えば、割込み信号の生成のみで十分である。この割込み信号を使用して、進行を決定することができる。
【００３７】
タスク再構成のために必要とされる情報は、位置ＩＤパケットの一部ではなく、そのため、位置ＩＤパケットを転送し、位置ＩＤとプログラム位置ＩＤとを合致させ、かつ制御プロセッサに割込みを合図する機構を、タスク機能から独立させることができる。その結果、前記機構の実施は、再使用可能なハードウェアまたはソフトウェア構成要素によって行うことができる。
【００３８】
別の実施形態では、プロセッサＣＰＵ、またはコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣが、それらの対応するシェルＳＰ、ＳＡ、ＳＢ、およびＳＣに、遭遇した位置ＩＤの値、ならびにその位置ＩＤとプログラム位置ＩＤとの合致の結果を記憶するように構成されている。別の実施形態では、プロセッサＣＰＵ、またはコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣが、それらの対応するシェルＳＰ、ＳＡ、ＳＢ、およびＳＣに、位置ＩＤとプログラム位置ＩＤとの合致の結果のみを記憶するように構成されている。割込み信号を受信するのではなく、制御プロセッサ自体が、後の時点で、例えばポーリング機構によって合致の結果を調査する。さらに別の実施形態では、プロセッサＣＰＵ、またはコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣが、遭遇した位置ＩＤの値のみを記憶するように構成されている。記憶された位置ＩＤ値は、この位置ＩＤが、対応するプロセッサ（コプロセッサ）にデータ・ストリームを介してすでに渡っているかどうかを示す。
【００３９】
シェルＳＰ、ＳＡ、ＳＢ、およびＳＣのタスク切替えユニットは、対応するプロセッサＣＰＵ、またはコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣ上で実行するタスクを選択する役割をする。インタフェースＩＰ、ＩＡ、ＩＢ、およびＩＣが、それぞれプロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣによって検出された位置ＩＤの受信および合致のための機構を実施する。前記機構の実施は、いわゆるレポート・インタフェースによって行うことができる。プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、レポート（task_id、report_type、report_id）を呼び出すことによって、対応するインタフェースＩＰ、ＩＡ、ＩＢ、およびＩＣを介してシェルＳＰ、ＳＡ、ＳＢ、およびＳＣのタスク切替えユニットにメッセージをレポートすることができる。ｔａｓｋ＿ｉｄは、レポート要求がそこから発行されるアクティブ・タスクのタスクＩＤに対応し、ｒｅｐｏｒｔ＿ｔｙｐｅは、エラー状態または有効な位置ＩＤを示し、ｒｅｐｏｒｔ＿ｉｄは、位置ＩＤを含む。対応するシェルＳＰ、ＳＡ、ＳＢ、およびＳＣ内のタスク・テーブル４０１、４０３、４０５、および４０７は、さらに、図４には示されていない各タスク毎の５つのプログラム可能フィールドを備え、それぞれ、許可フラグ（Enable flag）、位置使用不可フラグ（LocationDisable flag）、割込み許可フラグ（InterruptEnable flag）、レポート・タイプ（ReportType）、およびレポートＩＤ（ReportID）を記憶する。位置使用不可フラグがセットされている場合、対応するプロセッサＣＰＵ、またはコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣからの有効なｒｅｐｏｒｔ＿ｔｙｐｅを有するレポート要求の際、ｒｅｐｏｒｔ＿ｉｄがプログラム位置ＩＤに合致するときに、アクティブ・タスクが使用不可にされる。このとき、位置使用不可フラグがセットされていない場合には、対応するタスクを使用不可にすべきでない。タスクに関して許可フラグがセットされている場合、そのタスクは、対応するプロセッサＣＰＵ、またはコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣ上で実行することができる。タスクに関して許可フラグがセットされていない限り、そのタスクは、対応するプロセッサＣＰＵ、またはコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣ上で実行することができない。図５に、タスクの実行を使用不可にするための流れ図を示す。レポート要求の際、タスク切替えユニットは、ｒｅｐｏｒｔ＿ｔｙｐｅ引数がエラー状態を示すかどうか判定する（５０１）。ｒｅｐｏｒｔ＿ｔｙｐｅ引数がエラー状態を示す場合、ｒｅｐｏｒｔ＿ｉｄ引数が、ｔａｓｋ＿ｉｄを使用して、選択されたタスクのタスク・テーブル項目のレポートＩＤフィールドにエラー識別子として記憶される。さらに、ｒｅｐｏｒｔ＿ｔｙｐｅ引数がレポート・タイプ・フィールドに記憶され、タスク・テーブル内の対応する許可フラグをリセットすることによってアクティブ・タスクが使用不可にされ、割込み信号が生成される（５０５）。ｒｅｐｏｒｔ＿ｔｙｐｅ引数が有効である場合、ｒｅｐｏｒｔ＿ｉｄ引数が、正しいタスク・テーブル項目を選択するためにｔａｓｋ＿ｉｄを使用して、タスク・テーブルのレポートＩＤフィールドに受信位置ＩＤとして記憶され、ｒｅｐｏｒｔ＿ｔｙｐｅが、同様にｔａｓｋ＿ｉｄを使用して、選択されたタスクのタスク・テーブル項目のレポート・タイプ・フィールドに、有効な識別子として記憶される（５０３）。タスク切替えユニットは、有効なｒｅｐｏｒｔ＿ｔｙｐｅを受信したとき、受信されたｒｅｐｏｒｔ＿ｉｄを、タスク・テーブルのプログラム可能フィールドに記憶されたプログラム位置ＩＤと比較して（５０３）、合致するかどうか判定する（５０７）。これらが合致しない場合、さらなる動作は行われない（５０９）。受信されたｒｅｐｏｒｔ＿ｉｄがプログラム位置ＩＤに合致し、かつ位置使用不可フラグが設定されていない場合（５０９）、対応するタスクが処理を継続する。これは、タスクの進行をランタイムで判断するのに有用となる場合がある。位置使用不可フラグが設定されている場合（５１１）、タスク・テーブル内の許可フラグをリセットすることで、対応するタスクを使用不可にする（５１３）。さらに、どちらの場合でも、対応するタスクの割込み許可フラグが設定されている場合（５１５）、割込み信号が生成される（５１７）。割込み許可フラグが設定されていない場合、さらなる動作は行われない（５１９）。２つのプログラム位置ＩＤ値が特別な意味をもつ。すなわち、最初が全てゼロに設定されている場合、プログラム位置ＩＤはｒｅｐｏｒｔ＿ｉｄに合致せず、最初が全て１に設定されている場合、プログラム位置ＩＤは全てのｒｅｐｏｒｔ＿ｉｄに合致する。
【００４０】
いくつかの実施形態では、プロセッサＣＰＵ、ならびにコプロセッサＰｒｏｃＡ、ＰｒｏｃＢ、およびＰｒｏｃＣは、位置ＩＤパケットを、それらの全ての出力データ・ストリームに転送しない。アプリケーション・グラフ全体を通るデータ・パケットの流れの中での位置ＩＤパケットの意図は、各タスクが、その対応するＳＰ、ＳＡ、ＳＢ、およびＳＣ内で、位置ＩＤ値をそのプログラム位置ＩＤ値と突き合わせて一度検査して、タスク再構成を可能にすることである。いくつかの場合には、アプリケーション・グラフがサイクルを含み、このとき、これらの位置ＩＤパケットがアプリケーション・グラフ内部で周回するのを回避すべきである。アプリケーション・グラフ中での位置ＩＤパケットの継続的な循環は、当業者には明らかなように、タスク群の全ての出力データ・ストリームに位置ＩＤパケットを転送しないことによって回避することができる。
【００４１】
上述した実施形態は、本発明を限定するものではなく、例示するものであり、添付された特許請求の範囲の範囲から逸脱することなく、当業者が多くの代替実施形態を設計することができることに留意されたい。特許請求の範囲において、括弧内に記された任意の参照符号は、特許請求の範囲の限定とは解釈されないものとする。用語「備える」は、特許請求の範囲内に列挙したもの以外の要素またはステップの存在を除外しない。要素の前に付いた用語「１つの」は、複数の該要素の存在を除外しない。複数の手段を列挙する装置の請求項では、これらの手段のいくつかを、ハードウェアの同一の要素によって実施することができる。単に、いくつかの手段が互いに異なる従属請求項に記載されているということは、これらの手段の組合せを効果的に使用することができないことを示すものではない。
【図面の簡単な説明】
【００４２】
【図１】従来技術によるデータ処理システム上へのアプリケーションのマッピングの例を示す図である。
【図２】ストリーム・ベースの処理システムのアーキテクチャの概略ブロック図である。
【図３】図２に示されるストリーム・ベースの処理システム上にマップされたアプリケーションの概略ブロック図である。
【図４】図２によるストリーム・ベースの処理システムに関する、シェル内にプログラムされ、データ・ストリームに挿入された位置ＩＤの概略ブロック図である。
【図５】図２によるストリーム・ベースの処理システムに関する、タスクの実行を使用不可にするための流れ図である。
【図１】
2006519432.tif 000003
【図２】
2006519432.tif 000004
【図３】
2006519432.tif 000005
【図４】
2006519432.tif 000006
【図５】
2006519432.tif 000007
【国際調査報告】
2006519432.tif 000008
2006519432.tif 000009
2006519432.tif 000010