JP3617852B2 - 多重処理パイプラインデータ処理エミュレート方法 - Google Patents
多重処理パイプラインデータ処理エミュレート方法 Download PDFInfo
- Publication number
- JP3617852B2 JP3617852B2 JP12526894A JP12526894A JP3617852B2 JP 3617852 B2 JP3617852 B2 JP 3617852B2 JP 12526894 A JP12526894 A JP 12526894A JP 12526894 A JP12526894 A JP 12526894A JP 3617852 B2 JP3617852 B2 JP 3617852B2
- Authority
- JP
- Japan
- Prior art keywords
- pipeline
- data
- task
- host application
- processing
- 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
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/54—Interprogram communication
- G06F9/544—Buffers; Shared memory; Pipes
Description
【０００１】
【産業上の利用分野】
本発明は、多重処理環境をエミュレートすることによる単一処理環境でのデータ処理に係り、特に、所定のオブジェクト又はデータストラクチュアのライブラリを用いたオブジェクト指向システムに関しており、当該オブジェクト指向システムは、ユニックス（登録商標）のようなパイプラインデータストラクチュアをエミュレートするストリーム指向のデータ処理ストラクチュアを作成するため、ホストアプリケーションとデータソース（源）の間でリンクされ得る。
【０００２】
【従来の技術】
真の多重処理環境でのデータ処理パイプラインの使用は周知である。公知の多重処理環境の例は、単一プロセッサが真の多重処理を支援することができる多重プロセッサシステム及び高水準（レベル）システムの両方を含む。ユニックス（登録商標）オペレーティングシステムはこのような多重処理システムにおいてしばしば使用される。
【０００３】
このような多重処理環境において、データ処理パイプラインは、画像処理、データベース処理、又はスプレッドシート（表計算）処理と対応するデータブロックのような大容量の高水準で構造化されたデータブロックを処理するのに極めて有用である。このようなデータブロックにおいて、種々のデータ処理動作は、データブロックの各データ要素上で実行されなければならない。さらに、種々のデータ処理動作は特定の順序で実行される。
【０００４】
多重処理環境において、データ処理パイプラインは、データブロックを処理するために非常に効率的な方法を提供する。これらのデータ処理パイプラインにおいて、各個別のデータ処理動作はパイプラインの一部分として定義される。各部分は、それが隣接する複数の部分（上流部分及び下流部分）の内の一つ又は両方へリンクされる。従って、データ処理動作は、データソースとホストアプリケーションの間でリンクされたパイプラインの部分同士の連鎖を形成する。多数の独立プロセッサを有するコンピュータにおいては、各パイプライン部分がこれらのプロセッサの内の一つと対応している。この場合、各プロセッサは独立して動作し、且つコンピュータオペレーティングシステムはプロセッサとメモリアロケーション（割り当て）間でデータの流れを制御する。これは、データを効率的に処理するが、プロセッサとメモリを制御するために必要なオーバーヘッドは、相当な割合でシステム資源を消費する。
【０００５】
同様に、多数の異なる独立した処理動作又は処理（プロセス）を同時に実行することができる単一プロセッサを有するコンピュータにおいて、各パイプライン部分は独立型実行処理の内の一つに対応している。この場合、オペレーティングシステムは、各処理のランタイム、各処理とメモリ間のデータのフロー、及びメモリアロケーションを割り当てる。この場合において、コンピュータを制御するために必要なオーバーヘッドは、各処理とそのデータが、プロセッサが実行される度にそのプロセッサへ、そしてそのプロセッサから、スワップ（交換）されなければならないので、より一層大きな割合でシステム資源を消費することになる。さらに、これらの処理はオペレーティングシステムを介して通信するので、それが可能であっても、ダイナミック（動的）にパイプラインを変えるのは困難である。
【０００６】
一般に、パイプラインに対するデータのソース（源）は、例えば、１）金融情報を提供するスプレッドシート、２）データベース情報を提供するデータベースファイル内の記録、及び３）オリジナル文書、コンピュータ作成画像、他から従来の画像スキャナによって生成された画像データであってもよい。これに対して、ホストアプリケーションは、処理された金融データからパイチャート、バーチャート、他を生成するためのグラフィックスプログラムか、処理されたデータベースデータを使用する棚卸し（在庫管理）、会計、又は併合プログラムか、又は処理された画像データから画像を形成するための画像形成装置であってもよい。
【０００７】
データの特別なソース又は最終的なホストアプリケーションにかかわらず、データ処理パイプラインの第１の又は最上流の部分は、一般に、パイプラインのためのデータソースである。或いは、この第１のパイプラインのためのデータソースは第２のパイプラインであってもよい。この場合、第２のパイプラインの特別なブランチング（分岐化）又は「ファンアウト（ｆａｎ−ｏｕｔ ）」パイプライン部分が、第１のパイプラインと、第２のパイプラインの下流部分の両方へデータを供給するために使用され得る。両ケースにおいて、第１のパイプライン部分は、データのソースからパイプラインに対するデータ要素を得て、且つこのデータ要素を直ぐ下流の又は第２のパイプライン部分に使用可能とする。第２のパイプライン部分は第１のパイプライン部分からデータ要素をシーケンシャル（順次）に受け取り、このデータ要素を処理し、且つそれを直ぐ次の下流又は第３のパイプライン部分へ渡す。同時に、真の多重処理環境において、第１のパイプライン部分はデータのソースから次のデータ要素を得て、且つそれを第２のパイプライン部分へ出力すると共に、データパイプラインの第２又は下流の隣接部分が第１のパイプライン部分から受け取られたデータ要素を処理し、且つそれをデータ処理パイプラインの第３の部分へ出力する。従って、各データ要素がパイプライン部分の内の一つによって処理されると、そのデータ要素はそれがホストアプリケーションへ出力されるまで次の下流部分へ出力される。
【０００８】
このように、データは、一つの処理動作又はプロセッサをパイプラインの各部分と対応させることによって、多重処理環境において効率的且つ迅速に処理され得る。これは、パイプラインが、最も効率の悪いパイプライン部分及びオーバーヘッドによって生じる非効率性によってのみ限定されるにすぎないデータスループット（処理能力）でデータブロックを処理することが可能であることを確実とする。
【０００９】
これに対して、単一処理環境においては、全ての方法が非常に非効率的であるにもかかわらず、データを処理するために様々な方法が利用可能である。例えば、各データ処理動作は、任意の他のデータ処理動作がデータブロックの任意のデータ要素へ適用されるよりも前に、データブロックの全てのデータ要素へ適用される。即ち、データブロックの全ての要素は、次のデータ処理動作が前もって処理されたデータ要素のいづれかに実行される前に処理されなければならない。従って、単一タスキングデータ処理動作の効率性は、各データ処理動作の効率性に比例する。
【００１０】
従って、データ要素は多重処理環境でのパイプラインの或るデータ処理部分から連続的に移動するので、データブロックのメモリアロケーション（割り当て）を管理する為に求められる必要オーバーヘッドは、各データ要素が何度もメモリから読み取られ、また何度もメモリへ書き込まれなければならない単一処理環境と比べると小さい。即ち、必要なメモリを管理するために要求されるオーバーヘッドは単一処理環境においては実質的である。
【００１１】
【発明が解決しようとする課題】
従って、本発明は、単一処理プロセッサを用いて多重処理データ処理パイプラインをエミュレートするための制御システムを提供する。
【００１２】
【課題を解決するための手段】
本発明の一つの方法において、データ処理動作のライブラリが提供されている。このライブラリにおける各データ処理動作、又は関数は、オブジェクト指向システム内のクラス又はサブクラスである。パイプラインの各部分は具体化された関数又はタスクであり、且つタスクの状態を自己定義するために一つ又はそれより多くのデータ処理関数と充分なデータストラクチュアを有する。動作上、ホストアプリケーションがデータのソースからの処理されたデータ入力を要求する時、データ処理パイプラインがデータのソースからホストアプリケーションへ形成される。データ処理パイプラインは、データ処理ライブラリにおける関数のうちの一つを呼び出し且つタスクを形成するためにその呼び出された関数を初期化することによって形成される。このタスクはパイプラインの第１の又は最上流の部分となる。第１のパイプラインソースはデータのソースからデータ要素を生成する。データのソースは、スキャナ、ファクシミリ装置、遠隔コンピュータ、直列又は並列データ信号を出力するセンサその他、又はＲＯＭ、ＲＡＭの一部、若しくはディスクドライブ内のディスクに記憶されたデータのブロックであることができる。このデータ要素はまた、第１のパイプライン部分それ自体によって直接発生されることができる。この最後のケースにおいて、データ要素は、初期化された変数の値や第１のパイプライン部分の状態などから得られることが可能である。最初に初期化される時、ホストアプリケーションの逆方向又は上流のリンクが第１のパイプライン部分へセットされる。
【００１３】
第２のパイプライン部分は、仮定上、第１のパイプライン部分によって得られたデータ要素を処理するために必要とされる。従って、ホストアプリケーションはライブラリにおける関数の内の一つを初期化することによって他のタスクを生成する。この第２のパイプライン部分が作成されると、この部分は、自動的に第１のパイプライン部分へリンクされる。さらに、ホストアプリケーションのリンクは第２のパイプライン部分へセットされる。他のデータ処理動作が全く要求されない場合、ホストアプリケーションの逆方向リンクは、処理されたデータを要求するホストアプリケーションの部分と第２のパイプライン部分の間に残る。
【００１４】
或いは、パイプラインが追加の部分を要求するならば、ホストアプリケーションが関数ライブラリに対して追加の呼出しを行ない、より多くのタスク又はパイプライン部分を作り出す。新しく作成されたタスクは、データ処理パイプラインの第３の、第４の、と順に続くパイプライン部分となる。各追加のパイプライン部分が作成されると、各追加のパイプライン部分と直ぐ上流のパイプライン部分間での逆方向リンクが形成される。再び、パイプラインの最後の部分が作成された後、ホストアプリケーションの逆方向リンクはパイプラインの最後の部分へセットされたままである。このように、各パイプライン部分へのアクセスは、オペレーティングシステムよりもむしろ直接下流のパイプライン部分（又は最後のパイプラインに対するホストアプリケーション）によって制御され且つ保持される。従って、メモリを保持するために必要なオーバーヘッドは最小であり、且つタスクの実行を計画するために必要なオーバーヘッドは存在していない。それゆえ、本発明の制御システムは、多重処理環境からの効率的な処理の利点を単一処理環境からの最小オーバーヘッドの利点と結び付けると共に、これらの環境の欠点を回避したのである。
【００１５】
さらに、これによって、単一処理アプリケーションは、単一タスキングプロセッサ、単一プロセッサ、自動時分割を用いて多重タスキングシステム、又は真の多重タスキングシステムにおいて実行され得るだけでなく、上記の利点を維持することができる。即ち、オペレーティングシステムよりもホストアプリケーションが、パイプラインを作成し、保持し、制御し、且つ終了するので、パイプラインストラクチュアは、処理のタイプ又はホストアプリケーションを実行することとは無関係である。従って、ホストアプリケーションは、単一プロセッサ多重タスキングシステムにおいて実行される多数の独立したアプリケーションの内の一つとなることができる。同時に、このホストは、パイプラインをスケジュールし、このパイプラインに対するメモリを割り当て、保持し、且つ割り当て解除したりする為に、オペレーティングシステムを使用せずに、パイプラインシステムを用いることによって、スキャナからパイプラインを実行することができる。このようにして、オペレーティングシステムを用いてパイプラインを実行する際に通常は付きまとう欠点が回避され得る。
【００１６】
データブロックの処理を始めるにあたって、ホストアプリケーションはパイプラインの最後の部分からデータを要求する。パイプラインの各部分はまた、それがリンクされる上流のパイプライン部分からデータを要求する。これは、上流のパイプライン部分を呼び出すために下流のパイプライン部分から手順呼出しを行なうことによって実行される。これは、下流のパイプライン部分をスタックへプッシュ（付け足すこと）することに類似している。データが各上流のパイプライン部分から要求されると、単一処理プロセッサは下流のパイプライン部分の処理を停止し且つ上流パイプライン部分の処理を開始する。一旦第１のパイプライン部分に達すると、第１のパイプライン部分はデータ要素を得るか又は生成し、且つそのデータ要素を第２のパイプライン部分へリターンする。一旦第１のパイプライン部分がデータ要素をリターンすると、ＣＰＵは第１のパイプライン部分の実行を停止し、且つ第２のパイプライン部分の実行を開始する。即ち、下流のパイプライン部分は上流のパイプライン部分を呼び出した手順呼出しからリターンされる。これは、下流のパイプライン部分をスタックからポップオフすることに類似している。一度、第２のパイプライン部分がデータ要素を処理すると、このデータ要素は第３のパイプライン部分へリターンされる。
【００１７】
次いで、第３のパイプラインは、そのデータ処理動作を、第２のパイプライン部分から受け取られた処理されたデータ要素上で実行し、この処理されたデータ要素を、第４のパイプライン部分へリターンし、且つ動作を停止する。このデータ要素は、各パイプライン部分において同じように処理される。最後のパイプライン部分がデータ要素を処理した後で、この最後のパイプライン部分は、完全に処理されたデータ要素をホストアプリケーションへリターンする。次いで、ホストアプリケーションが、他の処理されたデータ要素を望む（又は必要とする）場合、このホストアプリケーションは処理されたデータ要素を再びこの最後のパイプライン部分から要求する。このように、処理されたデータは、高い効率の低オーバーヘッド方式でパイプラインの下をリップルする。さらに、データ処理パイプラインの効率性はパイプラインの最小効率リンクのみに依存する。
【００１８】
本発明の一つの態様は、単一処理プロセッサを用いて多重処理パイプラインデータ処理をエミュレートするための方法であって、前記単一処理プロセッサ上でホストアプリケーションを実行するステップと、データソースから処理されたデータを前記ホストアプリケーションへ供給するためにデータ処理パイプラインを作成するステップと、前記パイプラインを呼び出すステップと、前記パイプラインを削除するステップとを備え、前記パイプラインを作成するステップが、（ａ）複数の所定の関数から選択された第１の関数を第１のタスクとして具体化するステップと、（ｂ）前記ホストから前記第１のタスクへのリンクを定義するステップと、（ｃ）前記複数の所定の関数から選択された第２の関数を第２のタスクとして具体化するステップと、（ｄ）前記第１のタスクから前記第２のタスクへのリンクを定義し且つ該リンクを前記ホストから前記第２のタスクへと再定義するステップとを有し、引き続くタスクに対してステップ（ｃ）と（ｄ）を繰り返すステップであって、前記ホストアプリケーションが最後のタスクへリンクされており、且つ各タスクがメモリ内に記憶され、且つ前記各タスクが前記プロセッサを制御することよりなるステップとをさらに備え、前記パイプラインを呼び出すステップが、（ｅ）前記最後のタスクからデータ要素を要求し、各タスクは各タスクがリンクされるタスクから前記データ要素を要求するステップと、（ｆ）前記第１のタスクによって前記データ要素を得るステップと、（ｇ）前記データ要素を前記要求タスクへリターンするステップと、（ｈ）前記リターンされたデータを処理するステップと、（ｉ）前記データが前記ホストアプリケーションへリターンされるまで、ステップ（ｇ）と（ｈ）を反復するステップとを有し、前記ステップ（ｅ）乃至（ｉ）が前記ホストアプリケーションによって要求されるデータごとに反復されることよりなる前記多重処理パイプラインデータ処理エミュレート方法である。
【００１９】
【実施例】
図１に示されているように、コンピュータ１００は単一処理コントローラ（ＣＰＵ−中央処理装置）２０を有する。コンピュータ１００は入力／出力（Ｉ／Ｏ）インターフェース２２、ＲＯＭ２４、及びＲＡＭ２６も有する。ＣＰＵ２０は制御信号を制御ライン２８を介してＩ／Ｏインターフェース２２、ＲＯＭ２４、及びＲＡＭ２６へ送り、且つデータバス３０を通してＩ／Ｏインターフェース、ＲＯＭ２４、ＲＡＭ２６へデータを送ったり、Ｉ／Ｏインターフェース、ＲＯＭ２４、ＲＡＭ２６からデータを受け取ったりする。タスクライブラリ１０、データソース１２、ディスプレイ１４、キーボード１６、マウス１８、及びディスクドライブ１９は、Ｉ／Ｏインターフェース２２を介してＣＰＵ２０と接続されている。マウス１８は、マウス、トラックボール、ライトペン、タッチスクリーン、タッチパッド、又はその他同種のもののようなあらゆる第２のポインティング装置を示す。ディスクドライブ１９は、ハードドライブ、ハードカード、フロッピーディスク及びフロッピーディスクドライブ、ＣＤ−ＲＯＭ及びＣＤ−ＲＡＭディスクドライブ、フラッシュメモリ、又はその他同種のもののようなあらゆる非揮発性の記憶装置を示す。
【００２０】
ＣＰＵ２０は単一処理プロセッサである。即ち、ＣＰＵは、多くても一回に一つのアプリケーションのためにデータをアクティブに処理することが可能であり、且つ前もって作動し且つ一回で単一のデータ処理動作のみを実行することが可能である。Ｉ／Ｏインターフェース２２は、ＣＰＵ２０を、直列データポート（図示されてない）及び並列データポート（図示されてない）のいずれかを介して直列又は並列のデータ入力ソース又はデータ出力ソースへ接続する。データのこれらのソースは、当然、キーボード１６及びデータソース１２だけでなく、ディスクドライブ１９及びマウス１８も含む。上記のように、データソース１２は、スキャナ、ファクシミリ装置又はその他同種のもの、遠隔コンピュータ、センサ又はその他同種のものを含む。Ｉ／Ｏインターフェース２２は、ディスプレイ１４を駆動し且つキーボード１６、マウス１８、及びディスクドライブ１９からの信号を入力するために必要なハードウェアも有する。
【００２１】
ＲＯＭ２４は、ＣＰＵ２０に対する全ての基本的なオペレーティングプログラムを記憶し、且つブートストラップ又はその他同種のものを含む。ＲＡＭ２６は、非常に多くのランダムアクセス可能なメモリ位置を備える。ＲＡＭ２６はブロック２６ａ、２６ｂ、２６ｃ、２６ｄ、２６ｅ、及び２６ｆのような割り当て可能なメモリのブロックへ分割されることができる。割り当て可能なメモリ２６ａ乃至２６ｆのブロックは、ホストアプリケーションと、タスクを形成するデータ処理データストラクチュア（即ちデータ処理パイプラインの部分）の一つ又はそれより多くの具体例を記憶する。ディスプレイ１４は目に見える情報を出力するが、キーボード１６は情報をコンピュータ１００へ入力するために使用される。
【００２２】
関数ライブラリ１０は、ＣＰＵ２０によって呼び出されるデータ処理関数を形成する初期化されないデータ処理ストラクチュア又はオブジェクトのライブラリを記憶する。関数ライブラリ１０は、Ｉ／Ｏインターフェース２２を介してアクセスされる独立した要素として示されているが、関数ライブラリ１０がＲＯＭ２４内又はディスクドライブ１９を介してアクセスされる不揮発性メモリ装置上で格納される得ることが理解されよう。さらに、ディスクドライブ１９内の非揮発性メモリ装置又は関数ライブラリ１０へまだ格納されてなかった新しく書き込まれたデータ処理オブジェクト又は関数はＲＡＭ２６内に格納され得る。
【００２３】
同様に、データソース１２はコンピュータ１００の外部にあるのが示されており、且つＩ／Ｏインターフェース２２を介してアクセスされる。しかしながら、データソース１２は、ＲＯＭ２４若しくはＲＡＭ２６内、ディスクドライブ１９内の非揮発性メモリ装置上、又はＣＰＵ２０のレジスタカウンタ若しくは内部メモリ内に格納されるデータであることができる。データソース１２は、キーボード１６を介してデータ入力を有することができる。上記のように、最後には、第１のパイプライン部分は、いくつかの外部ソースからデータ要素を得るのではなく、データ要素それ自体を発生することができる。
【００２４】
図１２に示されているように、本発明のコントローラ２０は、ホストアプリケーション手段５０、ライブラリ手段１０、メモリ管理手段５６、最後のタスク手段６０、少なくとも一つの中間タスク手段６２、及び第１のタスク手段６４を備える。コントローラはデータソース手段６６を含んでいてもよいが、含む必要もない。この場合において、第１のタスク手段６４もデータソース手段６６の関数を実行する。複数のリンク７０は、リンク７０によってホストアプリケーション手段に接続されたデータ処理パイプライン８０内の第１のタスク手段６４、少なくとも一つの中間手段６２、及び最後のタスク手段６０を接続させる。当然、簡単なパイプライン８０が、第１のタスク手段６４と最後のタスク手段６０だけを含んでもよいことは理解されるべきである。最後に、データ入力リンク７２はデータソース手段６６を第１のタスク手段６４と接続させる。
【００２５】
ホストアプリケーション手段５０は、データ処理パイプライン８０から受け取られたデータをさらに処理するためのデータ処理手段５８を含む。まず、コントローラ２０は、ホストアプリケーション手段５０、ライブラリ手段１０、及びメモリ管理手段５６を含むにすぎない。ホストアプリケーション手段５０は当該ホストアプリケーション５０内に含まれた命令によってコントローラ２０を操作する。コントローラ２０は、単一タスキングコントローラ、単一ＣＰＵ、多重タスキングコントローラ又は真の多重ＣＰＵであり得る。いづれの場合においても、ホストアプリケーション手段５０自体がコントローラ２０内で単一タスキング環境を生成する。
【００２６】
ホストアプリケーション手段５０は、それがデータソース６６から処理されたデータを必要とすると決定する時、当該ホストアプリケーション手段５０は、データ処理パイプライン８０を作成し且つ呼び出す。従って、ホストアプリケーション手段５０は初期化手段５２及び呼出し手段５４を含む。この初期化手段５２は、関数を取り且つタスクを生成する為にその関数を初期化するためにライブラリ手段１０へアクセスする。即ち、ライブラリ手段１０は多数のデータ処理関数を記憶する。データ処理関数は、ライブラリにおいて関数が初期化されなかった時、オブジェクト指向システム内のオブジェクトのクラス又はサブクラスである。
【００２７】
初期化手段５２は、初期化されない関数の内の一つを得るためにライブラリ手段１０へアクセスする。次いで、初期化手段５２は、得られた関数を初期化して、具体化された関数又はタスクをコントローラ２０内に生成する。具体化された関数又はタスクは、ホストアプリケーション手段５０又は他の前もって生成されたタスクへリンクされる。タスクがホストアプリケーション手段へリンクされている場合、それは最後のタスク６０である。タスクが他のタスクへリンクされ、他のタスクもそのタスクへリンクされている場合、それは中間タスク６２である。タスクが他のタスクへリンクされ且つデータソース手段６６からデータを受け取るか、又はそれ自体がデータを発生する場合、それは第１のタスク６４である。
【００２８】
タスクを生成するために関数を初期化するにあたって、初期化手段５２は、タスクを記憶するためにメモリ２６のメモリブロック２６ａ乃至２６ｆの内の一つを割り当てるため、コントローラのメモリ管理手段５６と共に動作する。所望されるタスクの全てが初期化手段５２によって初期化された後で、呼出し手段５４が最後のタスク手段６０からデータを要求することによってパイプライン８０を呼び出す。呼出し手段５４からの要求は、パイプライン８０の上流方向へ第１のタスク手段６４へ向けて流れる（リップルする）。その要求が第１のタスク手段６４に達した時、第１のタスク手段はデータソース６６からデータを得るか又はそれ自体がデータを発生する。次いで、第１のタスキング手段６４はデータを下流方向で中間タスク手段６２へリターンする。中間タスク手段６２はそのデータを処理し且つそれを最後のタスキング手段６０へリターンする。最後のタスク手段６０はそのデータを処理し且つそれをホストアプリケーション手段へリターンする。次いで、より多くのデータがホストアプリケーション手段によって必要とされる場合、呼出し手段５４は再びパイプライン８０を呼び出す。
【００２９】
一旦ホストアプリケーション５０が全ての所望されるデータを有すると、呼出し手段５４は、パイプライン８０からエラーコードを要求することによって、当該パイプライン８０から発生するいづれのエラーをも閉じ込め（シャットダウン）且つクリーンアップ（浄化）するために再びパイプライン８０を呼び出す。前と同じようにこの要求は上流へリップルする。各タスキング手段は、それがエラーコードを発生したかを決定し、それらのエラーコードをリターンする。これらのエラーコードが一旦リターンされると、初期化手段５２は、パイプライン８０のタスク手段６０乃至６４に割り当てられたメモリを解放するため、メモリ管理手段５６へ信号を送る。
【００３０】
図１３は、汎用化されたタスク手段６８を示し、これはタスク手段６０乃至６４のいづれかを表す。この汎用化されたタスク手段６８は、リンク手段８２、少なくとも一つのチャネル手段８４（８４ａ、８４ｂ、８４ｃ）、データ処理手段８６、データ分析手段８８、タスク状態手段９０、エラーコード発生手段９２、外部ポート手段９４、及び再構成手段９６を備える。実際のタスク手段６０乃至６４が、一つより多くの要素を欠いた、これらの要素の異なる組み合わせを有してもよいことは当然理解されよう。さらに、第１のタスク手段６４は、パイプライン８０のためにデータを受け取ったり発生したりするためのデータ受取り及び／又は発生手段９８も含む。
【００３１】
リンク手段８２は、順方向リンクが使用される時、汎用化されたタスク手段６８を次の又は上流のタスク手段６８とリンクするか、又は逆方向リンクが使用される時、汎用化されたタスク手段６８を前の又は下流のタスク手段６８とリンクする。両リンクとも一度に使用されることができる。汎用化されたタスク手段６８は、チャネル手段８４を介して次のタスク手段６８からリターンされたデータを受け取る。そのデータは、次いで、それがチャネル８４を介して前のタスク手段６８へリターンされる前にデータ処理手段８６を用いて処理される。
【００３２】
タスク状態手段９０はタスク手段６８の状態を保持する。タスク状態手段９０はまたタスク手段６８の全ての他の手段を制御する。
【００３３】
データ分析手段８８は次のタスク手段６８から受け取られたデータがデータ処理手段８６に適しているかを決定する。データが適していない場合、データ分析手段が二つの異なる可能な応答を持っている。第１のタイプの応答においては、簡単化されたタスク手段６８は、データの代わりに、エラーコード発生手段９２によって発生されたエラーコードを前のタスク手段へリターンするだけである。ホストアプリケーション手段５０がデータの代わりにエラーコードを受け取った時、アプリケーション手段５０は、そのエラーの性質（及び原因）を決定するためにエラー処理システムを使用する。次いで、ホストアプリケーション手段５０は、グレースフルに出るか又はパイプライン８０を再構成且つ／又は再初期化するとによってエラーから回復するように試みることができる。
【００３４】
第２のタイプの応答において、複雑なタスク手段６８は、エラーから回復するためにパイプライン８０をダイナミックに再構成しようとする再構成手段９６を含む。この再構成手段９６は、追加のタスク手段６８をダイナミックに初期化し且つそれらをパイプライン８０へ挿入するとによってこれを行なう。再構成手段は外部ポート手段９４を介して他のタスキング手段６８へアクセスすることによってこれを行なう。この外部ポート手段はタスキング手段６８への様々なアクセスモードを許容する。これらのモードはタスク状態手段９０を検査及び／又は変更し、エラーコード発生手段９２を検査し、即ちリンク手段８２を変更したりすることも含まれる。
【００３５】
たとえタスク手段６８が洗練された再構成手段９６有していたとしても、回復不可能又はハードエラーはまだ発生する可能性がある。この場合、タスク手段はエラーコードを発生するため、再びエラーコード発生手段９２を使用する。
【００３６】
最後に、第２の実施例において、リンク手段８２は、タスク手段６８自体でなくて、チャネル手段８４をリンクする。リンク手段８２はチャネルを次の又は前のタスク手段６８へ直接リンクする。従って、タスク手段６８が多数のチャネル手段８４ａ、８４ｂ、及び８４ｃを有する場合、各チャネル手段８４ａ乃至８４ｃは異なる次の又は前のタスク手段６８へリンクされ得る。一方、第１の実施例において、リンク手段８２はタスク手段６８をリンクしたので、タスク手段６８のすべてのチャネル手段８４ａ乃至８４ｃは同じ次のタスク手段６８とリンクされることになる。
【００３７】
図２に示されているように、各初期化関数又はタスクはデータソース１２とホストアプリケーション１２０の間で実行されるパイプライン４０の部分４０ａ、４０ｂ、及び４０ｃとしてビジュアル化され得る。ホストアプリケーションはＣＰＵ２０によって現在実行されている（且つＲＡＭ２６に格納される）アプリケーションである。パイプライン４０の各部分４０ａ、４０ｂ、及び４０ｃは、一つ又はそれより多くのデータ処理チャネル４２と、パイプライン部分の状態を定義するデータストラクチュア４４、及びゼロ、一つ又はそれより多くの外部ポート４６を備える。各パイプライン部分４０ｂ及び４０ｃ並びにホストアプリケーション１２０のそれぞれが、パイプライン部分４０ｂ及び４０ｃ又はホストアプリケーション１２０を直ぐ上流のパイプライン部分４０ａ、４０ｂ、及び４０ｃのそれぞれへリンクする逆方向リンク４８を有する。或いは、各パイプライン部分４０ａ、４０ｂ、及び４０ｃは、直ぐ下流のパイプライン部分４０ｂ及び４０ｃ又はホストアプリケーション１２０への順方向リンク４８’を有する。最後には、逆方向リンク４８と順方向リンク４８’の両方が提供されてもよい。
【００３８】
制御システムの好ましい実施例において、パイプラインは「知的な」パイプライン部分を有する。これらの知的なパイプライン部分は、それがホストコンピュータから操作される時、ホストアプリケーションによるいかなる割り込みも必要とせずに、パイプラインをダイナミックに再構成することが可能である。例えば、パイプライン４０ｂは、パイプライン部分４０ａによってリターンされたデータ要素を処理することが可能である。パイプライン４０ｂがデータ要素を処理することが不可能な場合、パイプライン部分４０ｂは、関数ライブラリ１０をダイナミックに呼び出し、且つ新たなパイプライン部分４０ｄを作成する。パイプライン部分４０ｄはパイプライン部分４０ａにリンクされる。次いで、パイプライン部分４０ｂはそれ自体のリンクを変えて、パイプライン部分４０ａよりもむしろパイプライン部分４０ｄを指し示す。
【００３９】
或いは、パイプライン部分４０ｂがそれがデータを処理することが不可能であることを決定した場合（例え、それがそのパイプラインを再構成しようとする場合でも）、当該パイプライン部分４０ｂはハードエラーを示すエラーコードをリターンする。ホストアプリケーションにおけるエラー処理システムは、ライブラリからエラーの性質を決定する。一つの実施例においては、ホストアプリケーションはそれがエラーから回復するためにパイプラインを再生することができるかを決定する。再生できる場合、ホストアプリケーションはパイプラインを再初期化する。しかしながら、ホストアプリケーションがエラーから回復することが不可能である場合又はこの能力を備えていない場合、ホストアプリケーションはグレースフルに出る。
【００４０】
この様な回復不可能エラーは、例えば、画像を処理するにあたって発生し得る。ヘッダが１０００の走査ラインが画像内にあるが、走査ライン画像データ要素が第９９８回目の呼び出しでも第１のパイプライン部分へリターンされなかったことを示した場合、システムはハードエラーへ出会う。単に処理できるデータがないために、パイプラインがそれ自体で再構成しようとする能力に関わらず、このエラーは回復することができない。この場合において、第１のパイプライン部分は”ＥＲＲ” エラーコードをリターンする。ホストアプリケーションは、次いで、エラーコードに対する理由を決定するためにエラー処理システムを使用する。このエラーの性質を決定した後、ホストアプリケーションは、システムのいかなる再構成又は再初期化も的を得てないので、グレースフルに出る。
【００４１】
パイプラインが再構成される場合、パイプライン部分４０ｂはパイプライン部分４０ｄからデータを要求する。パイプライン部分４０ｄは、データ要素を再リターンするパイプライン部分４０ａからデータを要求する。しかしながら、ここで、パイプライン部分４０ａは、データ要素を、パイプライン部分４０ｂではなくパイプライン部分４０ｄへリターンする。あるいは、関数ライブラリ１０を呼び出す時、パイプライン部分はデータ要素を提供することができ、これによってパイプライン部分４０ｄはこの部分が作成されるや否や、データ要素を有することができる。従ってパイプライン部分４０ｂがパイプライン４０ｄからデータを要求する時、パイプライン部分４０ｄはすぐに処理を行ない、且つそのデータ要素をリターンすることができる。
【００４２】
さらに、順方向リンク４８’が提供される場合、知的なパイプライン部分は、それらのデータストラクチュアにおいて、データ要素がこのパイプライン部分によって処理されるのを必要とするかを決定するための手段を含むことができる。必要としない場合、パイプライン部分は、それ自体をパイプラインラインから取り去るため、ホストアプリケーションに全く割り込まれることなく、パイプラインをダイナミックに再構成することができる。順方向リンクは必要であり、これによって、パイプラインがどの下流のパイプライン部分を変えるかを知り、これによってパイプライン部分が適切な上流のパイプライン部分とリンクされる。
【００４３】
外部ポート４６は、パイプライン部分の現在状態を検査するため、パイプライン部分のデータ構造４４へデータを書き込むため、そのパイプライン部分の現在状態を変えるか若しくはダイナミックに部分を追加するためにパイプライン部分（又は複数のパイプライン部分）の連結部分４８をダイナミックに変えるため、又はパイプライン４０から複数の部分をデリート（削除）するために使用される。一般に、外部ポート４６は、データ要素を処理するにすぎないデータチャネル４２から独立して、パイプラインを制御するために使用される。要するに、データチャネル４２は、上流のパイプライン部分から受け取られたデータを処理し、且つこの処理されたデータを下流のパイプライン部分へ出力するためだけに使用される。外部ポート４６は、データチャネル４２の動作に影響を与えずにパイプライン部分のデータストラクチュア４４へのアクセスを可能とする。
【００４４】
従って、他の実施例においては、例えば、パイプライン４０が作成された後で、パイプライン部分４０ａとパイプライン部分４０ｂの間にパイプライン部分４０ｄを追加することが必要となった場合、これは外部ポート４６を用いて達成される。この実施例において、パイプライン部分４０ｃは、そのデータストラクチュアの一部として、チャネル内でデータをテストするためのストラクチュアを有する。データの形式が、例えば、パイプライン部分４０ｃの適切な動作に必要とされる形式と互換性を持たないが、データが、例えば、パイプライン部分４０ｂの前に変更されなればならない場合、パイプライン部分４０ｃは、新しいパイプライン部分４０ｄをダイナミックに初期化し且つそれをパイプライン部分４０ａとパイプライン部分４０ｂの間に挿入する。このパイプライン部分４０ｃは、パイプライン部分４０ｂにおける外部ポート４６を介して、パイプライン部分４０ｂのデータストラクチュア４４にアクセスすることによってこれを行なう。パイプライン部分４０ｃがパイプライン部分４０ｂのリンク４８を変え、これによりパイプライン部分４０ａからのリンク４８が新しいパイプライン部分４０ｄへ変えられる。同様に、新しいパイプライン部分４０ｄのデータストラクチュア４４は、このストラクチュアが適切に初期化され且つパイプライン部分４０ａへリンクされることを確実とするためにアクセスされる。
【００４５】
動作上、図７に示されているアプリケーションのようなホストアプリケーションがデータをデータソース１２から要求する時、ホストアプリケーションは、最初、関数ライブラリ１０から関数を呼出し且つ初期化することによってパイプライン４０を形成する。図７に示されている実施例において、変数 ”ｉ” 、” ｎ” 、”ａｄｄ ｖａｌｕｅ”、及び”ｍｕｌ ｖａｌｕｅ”がホストアプリケーションの５行目で初期化される。６行目では、第１のタスク４０ａが「ヌル」タスクとして定義されている。第１のタスクは、データソース１２からデータ要素を得るために接続されることができると共に、「ヌル」コマンドを用いて第１のタスク４０ａがデータソース１２として作用するのを示すことが可能である。図７の７行目において、パイプライン４０におけるタスクの数は、図８に示されるホストアプリケーションを開始したコマンドラインによって決定される。一般に、ホストアプリケーションを実行すると、パイプライン４０のレングス（長さ）及び構成素（ｃｏｎｓｔｉｔｕｅｎｔｓ）はダイナミックに決定される。或いは、パイプライン４０のレングス及び構成素はホストアプリケーションにおいて明白に説明される。最後に、パイプライン４０の初期のレングス及び構成素がダイナミックに決定された時又は明白に説明された時のいづれであっても、パイプライン４０はデータソース１２から受け取られたデータによってそれ自体をダイナミックに再構成することができる。
【００４６】
図７に示されている実施例において、７行目に示されているように、パイプライン４０のレングスはプログラムを開始するコマンドラインにおいて明白に説明される。この場合において、パイプラインのレングスは図８が示すように５である。図７の８行目と９行目に示されているように、各関数が呼び出され且つ初期化され、且つデータソースからホストアプリケーションへ拡張される。この場合、図７の６行目に示されているように、第１のタスク４０ａもデータソースのように動作する。さらに、９行目に示されているように、パイプライン４０における各タスクは同じ関数の異なる具体化（インスタンシェーション）又はタスクである。図７の９行目と図５のの１７行目に示されているように、この例における関数”Ｍａｔｈ Ｔａｓｋ” が初期化されると、そのデータストラクチュアは、各々が現在値” ｉ” にセットされる二つのチャネルデータバッファと、パイプライン内の上流タスクを指し示すポインタを含む。さらに、パイプライン内に上流タスクが全くない場合、ポインタは「ヌル」にセットされる。
【００４７】
関数ライブラリ１０における関数がオブジェクト指向言語においてはオブジェクトとして定義されるので、図７に示されている実施例において関数が初期化される度に、同じ関数の異なる具体化が事実上行なわれる。これによって、単一パイプライン４０はあらゆる単一関数の複数のコピーを有していてもよい。従って、関数の各コピーはライブラリ内に格納されたベース関数の異なる具体化であり且つパイプライン４０の異なるタスク又は部分として動作する。これにより、関数ライブラリ１０における関数は、それらがあらゆる単一パイプラインにおいて一回以上使用されることができるので、再帰的である。
【００４８】
８行目及び９行目においてパイプライン内の各タスクが作成された後、初期化されたタスクのチャネル（この場合は二つ）が１０行目と１１行目で実行される。一旦、図６に示されたホストアプリケーションが、１０行目と１１行目で実行された複数のチャネルを介して、タスクから最後のデータを受け取ると、図８に示された出力は、図７の１２行目と１３行目に説明されているようにプリントされる。
【００４９】
図７のホストアプリケーションにおいては、上記に示されているように、８行目及び９行目において、パイプラインは、多数の関数”ＭａｔｈＴａｓｋ”の独立した具体化を有する。図５及び図６は、図７に示されているように、ホストアプリケーションによって形成されるパイプラインのために必要な各具体化を形成するため、図７の８行目及び９行目においてホストアプリケーションによって呼び出されるライブラリオブジェクト”ＭａｔｈＴａｓｋ”を示す。
【００５０】
図５に示されている”ＭａｔｈＴａｓｋ”関数の１乃至６行目において、主要データストラクチュアが定義される。１乃至６行目に示されているように、データストラクチュアは、二つのチャネル即ちチャネル１及びチャネル２並びに逆方向又は上流リンクを含む。次に、７行目乃至１２行目において、第１及び第２のチャネルのそれぞれに対するこの関数に特定のデータストラクチュア、”ａｖａｌ”及び”ｍｖａｌ”が定義される。
【００５１】
次に、１７行目で、チャネル１に対するデータ要求、”ａｖａｌｕｅ”及びチャネル２に対するデータ要求、”ｍｖａｌｕｅ”、並びに上流リンク「リンク」で、タスク”ＭａｔｈＴａｓｋ”に対して具体化手順が定義される。１８乃至２０行目において、チャネル１及びチャネル２のそれぞれに対する変数”ａｖａｌｕｅ”及び”ｍｖａｌｕｅ”並びにリンクが定義される。最後に、２１行目において、関数”ＭａｔｈＴａｓｋ”のタスクを作成し且つＲＡＭ２６のメモリブロックを割り当てるための手順が定義される。
【００５２】
次に、図６の２８乃至３７行目に示されているように、チャネル１に対応するデータ処理手順とデータストラクチュアが定義される。チャネル１のデータ処理手順は、タスクの直ぐ上流のタスクから番号を得る。さらに、図７の６行目に示されているように、パイプラインにおける第１のタスクは「ヌル」タスクである。第１のタスクに対する「ヌル」状態から生じる結果は、”ｖａｌ” の初期値をゼロに定義する３２行目で定義される。３３行目では、逆方向リンクが存在している場合、３４行目で値”ｖａｌ” はチャネル１の上流タスクの出力へセットされる。次いで、３５行目では、値”ｖａｌ” は、現在パイプライン部分のチャネル１の加数値”ａｖａｌ”をその値へ追加することによって更新される。各パイプライン部分に対するチャネル１の加数値”ａｖａｌ”は、２５行目で、図７の９行目でセットされたパイプライン部分の状態パラメータ”ａｖａｌｕｅ”へセットされた。最後に、チャネル１のデータ処理手順は、新しい値”ｖａｌ” を直ぐ下流のパイプライン部分へリターンすることによって終了する。
【００５３】
同様に、図６の３８乃至４７行目において、チャネル２のデータ処理手順が定義される。唯一の差は、図５の２２行目で初期化されたチャネル１の処理手順よりもむしろ図５の２３行目で初期化されたチャネル２の手順を使用する３９行目で発生する。さらに、４２行目では、値”ｖａｌ” は第１のパイプライン部分に対する「ヌル」データソースを補償するため、１にプリセットされる。４５行目では、新しい値”ｖａｌ” は、図７の９行目においてセットされた、図５の２６行目で状態パラメータ”ｍｖａｌｕｅ”にセットされたチャネル２の被乗数によって乗算される古い値”ｖａｌ” に等しい。
【００５４】
動作上、図７の８行目と９行目に示されているホストアプリケーションは指示された回数だけ関数”ＭａｔｈＴａｓｋ”を呼び出す。関数”ＭａｔｈＴａｓｋ”の第１の具体化はデータソースに接続されないヌルタスクとしてセットアップされる。再び、８行目と９行目をループすることによって、関数”ＭａｔｈＴａｓｋ”の第２の具体化がタスク”ＭａｔｈＴａｓｋ”の先の具体化との逆方向リンクによって形成される。その後、図７の８行目と９行目を介して各ループごとに、関数”ＭａｔｈＴａｓｋ”のさらなる具体化が形成される。図７に示されているホストアプリケーションの８行目と９行目を介して最後のループが一旦完了すると、ホストアプリケーションからのタスク”ＭａｔｈＴａｓｋ”の最後の一つへの逆方向リンクはセットされたままとなる。図４は、このようにして初期化された３−セクションパイプラインを示す。
【００５５】
次いで、１０行目と１１行目において、ホストアプリケーションは、関数”ＭａｔｈＴａｓｋ”の最後の具体化のチャネル１とチャネル２からデータを要求する。最後のタスクは回転し且つその直ぐ上流のタスクからデータを要求する。これは、その”ＭａｔｈＴａｓｋ”の第１の具体化がチャネル１とチャネル２を通してのデータに対する要求を受け取るまで続く。図３はこのタイプのデータフローの例を示す。ホストアプリケーションは図７の１０行目及び１１行目でパイプラインを呼び出した後、最後のパイプライン部分はそれがリンクされるパイプライン部分の図６の３４行目と４４行目で各チャネルを呼び出す。次いで、最後のパイプライン部分は、各々の呼び出されたパイプライン部分が、その部分がリンクされる上流のパイプライン部分を呼び出す。第１のパイプライン部分に達すると、この第１のパイプライン部分はデータソース１２からデータ要素を受け取るか、又はこの場合、データ要素を自己発生する。第１のパイプライン部分は、次いで、上記のようにそれを呼び出したパイプライン部分へそのデータ要素をリターンする。
【００５６】
関数”ＭａｔｈＴａｓｋ”の第１の具体化は、次いで、チャネル１とチャネル２に対して定義されたデータ処理手順を実行する。第１の具体化は、チャネル１に対しては０＋１に等しい値１及びチャネル２に対しては１×１に等しい値１を関数”ＭａｔｈＴａｓｋ”の第２又は具体化へリターンする。関数”ＭａｔｈＴａｓｋ”の各具体化は、引き続いて、第１の数をチャネル１で保持された値へ加算し、次いでチャネル２で保持された数を第２の数によって乗算する。図５及び図６に示されている例において、第１と第２の数は、図７の９行目でパイプラインが作成された時に初期化された加数と被乗数である。しかしながら、数はダイナミックに発生されることもできた。従って、チャネル１及びチャネル２において処理されたデータは、ホストアプリケーションへ向けて下流へリップルする。これによって、関数”ＭａｔｈＴａｓｋ”の最下流の具体化は、要求されたデータをホストアプリケーションへ提供する。
【００５７】
ＣＰＵ２０が図７に示されているホストアプリケーションを実行する時、それはホストアプリケーションをＲＡＭ２６のメモリブロック２６ａに格納する。ホストアプリケーションは、事実上、割り当て可能なメモリブロック２６ａ内に格納されたデータストラクチュアである。データストラクチュア自体は指定されたメモリの位置にわたるテンプレートを有しており、このテンプレートはＣＰＵ２０の制御動作のフロー（流れ）を定義する。割り当てられたメモリブロック２６ａの第１の部分において、種々のメモリ位置が定義され且つ／又は変数として割り当てられる。データブロック２６ａはまたホストアプリケーションの状態を定義する種々のメモリ位置、及びホストアプリケーションによって要求されたデータ又はホストアプリケーションによって処理されたデータを記憶するためのバッファとして動作する種々のメモリ位置を含む。
【００５８】
同様に、ホストアプリケーションが、例えば、関数”ＭａｔｈＴａｓｋ”の具体化を初期化するために関数ライブラリ１０を呼び出す時、他のデータブロック２６ｂがそのタスク又はパイプライン部分へ割り当てられる。ホストアプリケーションのように、初期化されたパイプライン部分は、実際に、割り当てられたメモリブロック２６ｂに対するテンプレートを備える割り当てられたメモリブロック２６ｂ内のデータストラクチュアである。割り当てられたメモリブロックは、処理されるデータ、データのタイプを定義するための種々のメモリ位置、このタスクがそのデータを受け取る場所を示す手順ポインタ、そのタスクの状態を定義するデータを記憶する種々のメモリ位置、及び関数”ＭａｔｈＴａｓｋ”の直ぐ上流の具体化から受け取られた処理されたデータを記憶するための一つ又はそれより多くのデータバッファを記憶するためのバッファを有する。
【００５９】
割り当てられたデータブロック２６ｂはチャネル１とチャネル２に対するデータ処理動作を定義するデータストラクチュアも含む。それとは別に、割り当てられたデータブロック２６ｂ内のデータストラクチュアは、データ処理を実行するための、又は関数ライブラリ１０における他の関数へのポインタルックアップテーブルとしての、ルックアップ（検索）テーブルを含む。一般に、各タスクは、それがデータブロック２６ａ乃至２６ｆの内の一つへ初期化され且つ割り当てられると、データ入力、データ出力、タスク状態、及びそのタスクによって実行される種々のデータ処理手順に充分なバッファを自動的に割り当てる。
【００６０】
図９乃至図１１は、この方法を実施する制御ルーチンに対して汎用化されたフローチャートを示す。図９に示されているように、スタートしてから、ステップＳ１０において、ホストアプリケーションは単一処理ＣＰＵ２０によって実行される。ステップＳ２０においては、コントローラが、一つのデータ処理パイプラインがコンピュータ１００の現在動作に必要とされるか否かをチェックする。必要とされない場合、制御ルーチンはステップＳ１０へ戻る。
【００６１】
しかしながら、パイプラインが必要とされる場合、制御ルーチンはステップＳ３０へ進み、このステップにおいて、関数ライブラリから関数を呼び出す。次いで、ステップＳ４０において、呼び出された関数は第１のタスク又は第１のパイプラインを形成するために初期化される。次いで、ステップＳ５０においては、コントローラは追加のパイプライン部分のいづれかが必要とされるか否かをチェックする。必要とされる場合、制御ルーチンは、ライブラリから次の関数を呼び出すためにステップＳ３０へ戻る。従って、制御ルーチンは、追加のタスクが要求されなくなるまで、ステップＳ３０乃至Ｓ５０をループする。この時点で制御ルーチンはステップＳ６０へ進む。
【００６２】
ステップＳ６０において、パイプラインが呼び出される。ステップＳ７０において、パイプラインは処理されたデータ要素をホストアプリケーションへリターンする。次いで、ステップＳ８０において、コントローラは追加のデータが必要か否かを決定する。追加のデータが必要な場合、制御ルーチンはパイプラインを再び呼び出すためにステップＳ６０へリターンする。
【００６３】
しかしながら、追加データが必要とされない場合、制御ルーチンはステップＳ９０へ進み、種々のパイプライン部分へ割り当てられたメモリを割り当て解除することによって初期化解除される。ステップＳ１００において、ホストアプリケーションの次のコマンドが実行される。次いで、ステップＳ１１０において、コントローラはホストアプリケーションの追加のパイプラインが実行される必要があるかを決定する。実行される必要がある場合、制御ルーチンはステップＳ３０へリターンする。
【００６４】
しかしながら、この時点でパイプラインが必要とされない場合、制御ルーチンはステップＳ１２０へ進み、コントローラがホストアプリケーションが完了したか否かを決定する。完了した場合、制御ルーチンはストップする。そうでない場合（完了していない場合）、制御ルーチンはステップＳ１００へ戻る。
【００６５】
図１０は初期化ステップＳ４０に対するフローチャートを示す。ステップＳ４０で初期化ルーチンへエンターした後、制御ルーチンは、タスクに対する主要データストラクチュアが作成されるステップＳ２００へ進む。次いで、ステップＳ２１０において、このタスクに対して特定であるデータストラクチュアの部分が作成される。次いで、ステップＳ２２０においては、チャネルデータストラクチュアが作成され、且つステップＳ２３０においては、逆方向リンクが作成される。順方向リンクが必要とされる場合、そのデータストラクチュアは定義されるが、順方向リンクがリンクする下流タスクがまだ作成されていないので、それはパイプラインが呼び出されるまで終了されない。リンクはリンクされたパイプライン部分を呼び出すための手順ポインタを有する。次いで、ステップＳ２４０において、制御ルーチンはステップＳ４０へ戻る。
【００６６】
図１１はステップＳ６０の呼出しルーチンに対するフローチャートを示す。ステップＳ６０からスタートして、制御ルーチンはホストアプリケーションが最後のパイプライン部分からデータを要求するステップＳ３００へ進む。次いで、ステップＳ３１０において、現在のパイプライン部分は次の上流パイプライン部分からデータを要求する。ステップＳ３２０においては、コントローラは次のパイプライン部分が最初パイプライン部分であるか否かを決定する。そうでない場合、制御ルーチンはステップＳ３１０へ戻る。
【００６７】
しかしながら、次のパイプライン部分が最初パイプライン部分である場合、制御ルーチンはステップＳ３３０へ進む。ステップＳ３３０において、コントローラは第１のパイプライン部分が「ヌル」部分であるか否かを決定する。そうでない場合、制御ルーチンは最初パイプライン部分が外部ソースからデータ要素を得るステップＳ３４０へ進む。第１のパイプライン部分が「ヌル」部分である場合、制御ルーチンは、第１のパイプライン部分がデータ要素を自己発生するステップＳ３５０へ進む。
【００６８】
両ケースにおいて、ステップＳ３４０又はステップＳ３５０のいづれかを経て、制御ルーチンはステップＳ３６０へ進み、ここで第１のパイプライン部分はデータを第２即ち次のパイプライン部分へ下流へリターンする。ステップＳ３７０において、次のパイプライン部分はデータを処理する。次いでステップＳ３８０において、次のパイプライン部分が最後のパイプライン部分である場合、処理されたデータはステップＳ３９０でホストアプリケーションへリターンされる。しかしながら、次のパイプライン部分が最後のパイプライン部分でない場合、データは新しい次のパイプライン部分へリターンされ、且つステップＳ３６０へのループバックにより示されるように、データ要素が処理される。この「ルーピング」は、最後のパイプライン部分へ至り、且つステップＳ３９０でデータがホストアプリケーションへリターンされるまで行なわれる。次いで制御ルーチンはステップＳ６０へ戻る。
【００６９】
本発明のデータ処理パイプラインの第１の実施例において、前もって定義された逆方向リンクを置換するか又はこの逆方向リンクに付け加えられる順方向リンクが提供される。この場合、タスクライブラリのタスクの内の一つの現在最下流の具体化から逆方向リンクが定義された後で、直ぐ上流のタスクから最下流タスクへの順方向リンクが定義される。或いは、順方向リンクのみが提供されなければならない。しかしながら、この場合において、パイプライン部分は、ホストアプリケーションから上流へ、存在していれば、データのデータソースへ向かって初期化され、次いで下流のデータソースからホストアプリケーションへ呼び出される。
【００７０】
さらなる実施例において、各タスクが二つ又はそれより多くのデータ処理チャネルを有する時、単一の順方向リンク及び／又は単一の逆方向リンクによって共にリンクされる。この場合において、各チャネルは、タスクライブラリからのタスクの具体化の内のいづれか一つの他の対応チャネルと逆方向又は順方向リンクされることができる。従って、第１のパイプライン部分のチャネルの内の一つは第２のパイプライン部分の対応チャネルとリンクされるが、第１のパイプライン部分の他のチャネルは第３のパイプライン部分の対応チャネルとリンクされる。
【００７１】
本発明のまた他の実施例において、特別な「ファンイン」及び「ファンアウト」のパイプライン部分が提供される。これらのパイプライン部分において、二つ又はそれより多くの上流にパイプライン部分がファンイン分岐パイプライン部分を用いて単一の下流のパイプライン部分とリンクされる。同様に、単一上流パイプライン部分がファンアウト分岐パイプライン部分を用いて二つ又はそれより多くの下流パイプライン部分と接続される。
【００７２】
【発明の効果】
単一処理プロセッサを用いて多重処理データ処理パイプラインをエミュレートするための制御システムを提供する。
【図面の簡単な説明】
【図１】本発明のシステムのブロック図を示す図である。
【図２】本発明のパイプラインのブロック図を示す図である。
【図３】本発明のパイプライン内のデータの流れを示す図である。
【図４】適例となるデータ処理プログラムのためにリンクされたパイプラインを示す図である。
【図５】サンプルタスクのための適例となるコードリスティングを示す図である。
【図６】サンプルタスクのための適例となるコードリスティングを示す図である。
【図７】パイプラインを形成するためにライブラリからタスクを呼び出す適例となるホストアプリケーションにためのコードリスティングを示す図である。
【図８】図４に示され且つ図５及び６並びに図８にリストされているパイプラインの出力のリスティングを示す図である。
【図９】主要ルーチンのフローチャートを示す図である。
【図１０】機能初期化ルーチンを示す図である。
【図１１】呼出し及び処理ルーチンのフローチャートを示す図である。
【図１２】本発明のコントローラを示す図である。
【図１３】本発明の汎用化されたタスク手段を示す図である。
【符号の説明】
１０ タスクライブラリ
１２ データソース
１３ ディスプレイ
１６ キーボード
１８ マウス
１９ ディスクドライブ
２０ 単一処理コントローラ
２２ Ｉ／Ｏインターフェース
２４ ＲＯＭ
２６ ＲＡＭ
１００ コンピュータ
【産業上の利用分野】
本発明は、多重処理環境をエミュレートすることによる単一処理環境でのデータ処理に係り、特に、所定のオブジェクト又はデータストラクチュアのライブラリを用いたオブジェクト指向システムに関しており、当該オブジェクト指向システムは、ユニックス（登録商標）のようなパイプラインデータストラクチュアをエミュレートするストリーム指向のデータ処理ストラクチュアを作成するため、ホストアプリケーションとデータソース（源）の間でリンクされ得る。
【０００２】
【従来の技術】
真の多重処理環境でのデータ処理パイプラインの使用は周知である。公知の多重処理環境の例は、単一プロセッサが真の多重処理を支援することができる多重プロセッサシステム及び高水準（レベル）システムの両方を含む。ユニックス（登録商標）オペレーティングシステムはこのような多重処理システムにおいてしばしば使用される。
【０００３】
このような多重処理環境において、データ処理パイプラインは、画像処理、データベース処理、又はスプレッドシート（表計算）処理と対応するデータブロックのような大容量の高水準で構造化されたデータブロックを処理するのに極めて有用である。このようなデータブロックにおいて、種々のデータ処理動作は、データブロックの各データ要素上で実行されなければならない。さらに、種々のデータ処理動作は特定の順序で実行される。
【０００４】
多重処理環境において、データ処理パイプラインは、データブロックを処理するために非常に効率的な方法を提供する。これらのデータ処理パイプラインにおいて、各個別のデータ処理動作はパイプラインの一部分として定義される。各部分は、それが隣接する複数の部分（上流部分及び下流部分）の内の一つ又は両方へリンクされる。従って、データ処理動作は、データソースとホストアプリケーションの間でリンクされたパイプラインの部分同士の連鎖を形成する。多数の独立プロセッサを有するコンピュータにおいては、各パイプライン部分がこれらのプロセッサの内の一つと対応している。この場合、各プロセッサは独立して動作し、且つコンピュータオペレーティングシステムはプロセッサとメモリアロケーション（割り当て）間でデータの流れを制御する。これは、データを効率的に処理するが、プロセッサとメモリを制御するために必要なオーバーヘッドは、相当な割合でシステム資源を消費する。
【０００５】
同様に、多数の異なる独立した処理動作又は処理（プロセス）を同時に実行することができる単一プロセッサを有するコンピュータにおいて、各パイプライン部分は独立型実行処理の内の一つに対応している。この場合、オペレーティングシステムは、各処理のランタイム、各処理とメモリ間のデータのフロー、及びメモリアロケーションを割り当てる。この場合において、コンピュータを制御するために必要なオーバーヘッドは、各処理とそのデータが、プロセッサが実行される度にそのプロセッサへ、そしてそのプロセッサから、スワップ（交換）されなければならないので、より一層大きな割合でシステム資源を消費することになる。さらに、これらの処理はオペレーティングシステムを介して通信するので、それが可能であっても、ダイナミック（動的）にパイプラインを変えるのは困難である。
【０００６】
一般に、パイプラインに対するデータのソース（源）は、例えば、１）金融情報を提供するスプレッドシート、２）データベース情報を提供するデータベースファイル内の記録、及び３）オリジナル文書、コンピュータ作成画像、他から従来の画像スキャナによって生成された画像データであってもよい。これに対して、ホストアプリケーションは、処理された金融データからパイチャート、バーチャート、他を生成するためのグラフィックスプログラムか、処理されたデータベースデータを使用する棚卸し（在庫管理）、会計、又は併合プログラムか、又は処理された画像データから画像を形成するための画像形成装置であってもよい。
【０００７】
データの特別なソース又は最終的なホストアプリケーションにかかわらず、データ処理パイプラインの第１の又は最上流の部分は、一般に、パイプラインのためのデータソースである。或いは、この第１のパイプラインのためのデータソースは第２のパイプラインであってもよい。この場合、第２のパイプラインの特別なブランチング（分岐化）又は「ファンアウト（ｆａｎ−ｏｕｔ ）」パイプライン部分が、第１のパイプラインと、第２のパイプラインの下流部分の両方へデータを供給するために使用され得る。両ケースにおいて、第１のパイプライン部分は、データのソースからパイプラインに対するデータ要素を得て、且つこのデータ要素を直ぐ下流の又は第２のパイプライン部分に使用可能とする。第２のパイプライン部分は第１のパイプライン部分からデータ要素をシーケンシャル（順次）に受け取り、このデータ要素を処理し、且つそれを直ぐ次の下流又は第３のパイプライン部分へ渡す。同時に、真の多重処理環境において、第１のパイプライン部分はデータのソースから次のデータ要素を得て、且つそれを第２のパイプライン部分へ出力すると共に、データパイプラインの第２又は下流の隣接部分が第１のパイプライン部分から受け取られたデータ要素を処理し、且つそれをデータ処理パイプラインの第３の部分へ出力する。従って、各データ要素がパイプライン部分の内の一つによって処理されると、そのデータ要素はそれがホストアプリケーションへ出力されるまで次の下流部分へ出力される。
【０００８】
このように、データは、一つの処理動作又はプロセッサをパイプラインの各部分と対応させることによって、多重処理環境において効率的且つ迅速に処理され得る。これは、パイプラインが、最も効率の悪いパイプライン部分及びオーバーヘッドによって生じる非効率性によってのみ限定されるにすぎないデータスループット（処理能力）でデータブロックを処理することが可能であることを確実とする。
【０００９】
これに対して、単一処理環境においては、全ての方法が非常に非効率的であるにもかかわらず、データを処理するために様々な方法が利用可能である。例えば、各データ処理動作は、任意の他のデータ処理動作がデータブロックの任意のデータ要素へ適用されるよりも前に、データブロックの全てのデータ要素へ適用される。即ち、データブロックの全ての要素は、次のデータ処理動作が前もって処理されたデータ要素のいづれかに実行される前に処理されなければならない。従って、単一タスキングデータ処理動作の効率性は、各データ処理動作の効率性に比例する。
【００１０】
従って、データ要素は多重処理環境でのパイプラインの或るデータ処理部分から連続的に移動するので、データブロックのメモリアロケーション（割り当て）を管理する為に求められる必要オーバーヘッドは、各データ要素が何度もメモリから読み取られ、また何度もメモリへ書き込まれなければならない単一処理環境と比べると小さい。即ち、必要なメモリを管理するために要求されるオーバーヘッドは単一処理環境においては実質的である。
【００１１】
【発明が解決しようとする課題】
従って、本発明は、単一処理プロセッサを用いて多重処理データ処理パイプラインをエミュレートするための制御システムを提供する。
【００１２】
【課題を解決するための手段】
本発明の一つの方法において、データ処理動作のライブラリが提供されている。このライブラリにおける各データ処理動作、又は関数は、オブジェクト指向システム内のクラス又はサブクラスである。パイプラインの各部分は具体化された関数又はタスクであり、且つタスクの状態を自己定義するために一つ又はそれより多くのデータ処理関数と充分なデータストラクチュアを有する。動作上、ホストアプリケーションがデータのソースからの処理されたデータ入力を要求する時、データ処理パイプラインがデータのソースからホストアプリケーションへ形成される。データ処理パイプラインは、データ処理ライブラリにおける関数のうちの一つを呼び出し且つタスクを形成するためにその呼び出された関数を初期化することによって形成される。このタスクはパイプラインの第１の又は最上流の部分となる。第１のパイプラインソースはデータのソースからデータ要素を生成する。データのソースは、スキャナ、ファクシミリ装置、遠隔コンピュータ、直列又は並列データ信号を出力するセンサその他、又はＲＯＭ、ＲＡＭの一部、若しくはディスクドライブ内のディスクに記憶されたデータのブロックであることができる。このデータ要素はまた、第１のパイプライン部分それ自体によって直接発生されることができる。この最後のケースにおいて、データ要素は、初期化された変数の値や第１のパイプライン部分の状態などから得られることが可能である。最初に初期化される時、ホストアプリケーションの逆方向又は上流のリンクが第１のパイプライン部分へセットされる。
【００１３】
第２のパイプライン部分は、仮定上、第１のパイプライン部分によって得られたデータ要素を処理するために必要とされる。従って、ホストアプリケーションはライブラリにおける関数の内の一つを初期化することによって他のタスクを生成する。この第２のパイプライン部分が作成されると、この部分は、自動的に第１のパイプライン部分へリンクされる。さらに、ホストアプリケーションのリンクは第２のパイプライン部分へセットされる。他のデータ処理動作が全く要求されない場合、ホストアプリケーションの逆方向リンクは、処理されたデータを要求するホストアプリケーションの部分と第２のパイプライン部分の間に残る。
【００１４】
或いは、パイプラインが追加の部分を要求するならば、ホストアプリケーションが関数ライブラリに対して追加の呼出しを行ない、より多くのタスク又はパイプライン部分を作り出す。新しく作成されたタスクは、データ処理パイプラインの第３の、第４の、と順に続くパイプライン部分となる。各追加のパイプライン部分が作成されると、各追加のパイプライン部分と直ぐ上流のパイプライン部分間での逆方向リンクが形成される。再び、パイプラインの最後の部分が作成された後、ホストアプリケーションの逆方向リンクはパイプラインの最後の部分へセットされたままである。このように、各パイプライン部分へのアクセスは、オペレーティングシステムよりもむしろ直接下流のパイプライン部分（又は最後のパイプラインに対するホストアプリケーション）によって制御され且つ保持される。従って、メモリを保持するために必要なオーバーヘッドは最小であり、且つタスクの実行を計画するために必要なオーバーヘッドは存在していない。それゆえ、本発明の制御システムは、多重処理環境からの効率的な処理の利点を単一処理環境からの最小オーバーヘッドの利点と結び付けると共に、これらの環境の欠点を回避したのである。
【００１５】
さらに、これによって、単一処理アプリケーションは、単一タスキングプロセッサ、単一プロセッサ、自動時分割を用いて多重タスキングシステム、又は真の多重タスキングシステムにおいて実行され得るだけでなく、上記の利点を維持することができる。即ち、オペレーティングシステムよりもホストアプリケーションが、パイプラインを作成し、保持し、制御し、且つ終了するので、パイプラインストラクチュアは、処理のタイプ又はホストアプリケーションを実行することとは無関係である。従って、ホストアプリケーションは、単一プロセッサ多重タスキングシステムにおいて実行される多数の独立したアプリケーションの内の一つとなることができる。同時に、このホストは、パイプラインをスケジュールし、このパイプラインに対するメモリを割り当て、保持し、且つ割り当て解除したりする為に、オペレーティングシステムを使用せずに、パイプラインシステムを用いることによって、スキャナからパイプラインを実行することができる。このようにして、オペレーティングシステムを用いてパイプラインを実行する際に通常は付きまとう欠点が回避され得る。
【００１６】
データブロックの処理を始めるにあたって、ホストアプリケーションはパイプラインの最後の部分からデータを要求する。パイプラインの各部分はまた、それがリンクされる上流のパイプライン部分からデータを要求する。これは、上流のパイプライン部分を呼び出すために下流のパイプライン部分から手順呼出しを行なうことによって実行される。これは、下流のパイプライン部分をスタックへプッシュ（付け足すこと）することに類似している。データが各上流のパイプライン部分から要求されると、単一処理プロセッサは下流のパイプライン部分の処理を停止し且つ上流パイプライン部分の処理を開始する。一旦第１のパイプライン部分に達すると、第１のパイプライン部分はデータ要素を得るか又は生成し、且つそのデータ要素を第２のパイプライン部分へリターンする。一旦第１のパイプライン部分がデータ要素をリターンすると、ＣＰＵは第１のパイプライン部分の実行を停止し、且つ第２のパイプライン部分の実行を開始する。即ち、下流のパイプライン部分は上流のパイプライン部分を呼び出した手順呼出しからリターンされる。これは、下流のパイプライン部分をスタックからポップオフすることに類似している。一度、第２のパイプライン部分がデータ要素を処理すると、このデータ要素は第３のパイプライン部分へリターンされる。
【００１７】
次いで、第３のパイプラインは、そのデータ処理動作を、第２のパイプライン部分から受け取られた処理されたデータ要素上で実行し、この処理されたデータ要素を、第４のパイプライン部分へリターンし、且つ動作を停止する。このデータ要素は、各パイプライン部分において同じように処理される。最後のパイプライン部分がデータ要素を処理した後で、この最後のパイプライン部分は、完全に処理されたデータ要素をホストアプリケーションへリターンする。次いで、ホストアプリケーションが、他の処理されたデータ要素を望む（又は必要とする）場合、このホストアプリケーションは処理されたデータ要素を再びこの最後のパイプライン部分から要求する。このように、処理されたデータは、高い効率の低オーバーヘッド方式でパイプラインの下をリップルする。さらに、データ処理パイプラインの効率性はパイプラインの最小効率リンクのみに依存する。
【００１８】
本発明の一つの態様は、単一処理プロセッサを用いて多重処理パイプラインデータ処理をエミュレートするための方法であって、前記単一処理プロセッサ上でホストアプリケーションを実行するステップと、データソースから処理されたデータを前記ホストアプリケーションへ供給するためにデータ処理パイプラインを作成するステップと、前記パイプラインを呼び出すステップと、前記パイプラインを削除するステップとを備え、前記パイプラインを作成するステップが、（ａ）複数の所定の関数から選択された第１の関数を第１のタスクとして具体化するステップと、（ｂ）前記ホストから前記第１のタスクへのリンクを定義するステップと、（ｃ）前記複数の所定の関数から選択された第２の関数を第２のタスクとして具体化するステップと、（ｄ）前記第１のタスクから前記第２のタスクへのリンクを定義し且つ該リンクを前記ホストから前記第２のタスクへと再定義するステップとを有し、引き続くタスクに対してステップ（ｃ）と（ｄ）を繰り返すステップであって、前記ホストアプリケーションが最後のタスクへリンクされており、且つ各タスクがメモリ内に記憶され、且つ前記各タスクが前記プロセッサを制御することよりなるステップとをさらに備え、前記パイプラインを呼び出すステップが、（ｅ）前記最後のタスクからデータ要素を要求し、各タスクは各タスクがリンクされるタスクから前記データ要素を要求するステップと、（ｆ）前記第１のタスクによって前記データ要素を得るステップと、（ｇ）前記データ要素を前記要求タスクへリターンするステップと、（ｈ）前記リターンされたデータを処理するステップと、（ｉ）前記データが前記ホストアプリケーションへリターンされるまで、ステップ（ｇ）と（ｈ）を反復するステップとを有し、前記ステップ（ｅ）乃至（ｉ）が前記ホストアプリケーションによって要求されるデータごとに反復されることよりなる前記多重処理パイプラインデータ処理エミュレート方法である。
【００１９】
【実施例】
図１に示されているように、コンピュータ１００は単一処理コントローラ（ＣＰＵ−中央処理装置）２０を有する。コンピュータ１００は入力／出力（Ｉ／Ｏ）インターフェース２２、ＲＯＭ２４、及びＲＡＭ２６も有する。ＣＰＵ２０は制御信号を制御ライン２８を介してＩ／Ｏインターフェース２２、ＲＯＭ２４、及びＲＡＭ２６へ送り、且つデータバス３０を通してＩ／Ｏインターフェース、ＲＯＭ２４、ＲＡＭ２６へデータを送ったり、Ｉ／Ｏインターフェース、ＲＯＭ２４、ＲＡＭ２６からデータを受け取ったりする。タスクライブラリ１０、データソース１２、ディスプレイ１４、キーボード１６、マウス１８、及びディスクドライブ１９は、Ｉ／Ｏインターフェース２２を介してＣＰＵ２０と接続されている。マウス１８は、マウス、トラックボール、ライトペン、タッチスクリーン、タッチパッド、又はその他同種のもののようなあらゆる第２のポインティング装置を示す。ディスクドライブ１９は、ハードドライブ、ハードカード、フロッピーディスク及びフロッピーディスクドライブ、ＣＤ−ＲＯＭ及びＣＤ−ＲＡＭディスクドライブ、フラッシュメモリ、又はその他同種のもののようなあらゆる非揮発性の記憶装置を示す。
【００２０】
ＣＰＵ２０は単一処理プロセッサである。即ち、ＣＰＵは、多くても一回に一つのアプリケーションのためにデータをアクティブに処理することが可能であり、且つ前もって作動し且つ一回で単一のデータ処理動作のみを実行することが可能である。Ｉ／Ｏインターフェース２２は、ＣＰＵ２０を、直列データポート（図示されてない）及び並列データポート（図示されてない）のいずれかを介して直列又は並列のデータ入力ソース又はデータ出力ソースへ接続する。データのこれらのソースは、当然、キーボード１６及びデータソース１２だけでなく、ディスクドライブ１９及びマウス１８も含む。上記のように、データソース１２は、スキャナ、ファクシミリ装置又はその他同種のもの、遠隔コンピュータ、センサ又はその他同種のものを含む。Ｉ／Ｏインターフェース２２は、ディスプレイ１４を駆動し且つキーボード１６、マウス１８、及びディスクドライブ１９からの信号を入力するために必要なハードウェアも有する。
【００２１】
ＲＯＭ２４は、ＣＰＵ２０に対する全ての基本的なオペレーティングプログラムを記憶し、且つブートストラップ又はその他同種のものを含む。ＲＡＭ２６は、非常に多くのランダムアクセス可能なメモリ位置を備える。ＲＡＭ２６はブロック２６ａ、２６ｂ、２６ｃ、２６ｄ、２６ｅ、及び２６ｆのような割り当て可能なメモリのブロックへ分割されることができる。割り当て可能なメモリ２６ａ乃至２６ｆのブロックは、ホストアプリケーションと、タスクを形成するデータ処理データストラクチュア（即ちデータ処理パイプラインの部分）の一つ又はそれより多くの具体例を記憶する。ディスプレイ１４は目に見える情報を出力するが、キーボード１６は情報をコンピュータ１００へ入力するために使用される。
【００２２】
関数ライブラリ１０は、ＣＰＵ２０によって呼び出されるデータ処理関数を形成する初期化されないデータ処理ストラクチュア又はオブジェクトのライブラリを記憶する。関数ライブラリ１０は、Ｉ／Ｏインターフェース２２を介してアクセスされる独立した要素として示されているが、関数ライブラリ１０がＲＯＭ２４内又はディスクドライブ１９を介してアクセスされる不揮発性メモリ装置上で格納される得ることが理解されよう。さらに、ディスクドライブ１９内の非揮発性メモリ装置又は関数ライブラリ１０へまだ格納されてなかった新しく書き込まれたデータ処理オブジェクト又は関数はＲＡＭ２６内に格納され得る。
【００２３】
同様に、データソース１２はコンピュータ１００の外部にあるのが示されており、且つＩ／Ｏインターフェース２２を介してアクセスされる。しかしながら、データソース１２は、ＲＯＭ２４若しくはＲＡＭ２６内、ディスクドライブ１９内の非揮発性メモリ装置上、又はＣＰＵ２０のレジスタカウンタ若しくは内部メモリ内に格納されるデータであることができる。データソース１２は、キーボード１６を介してデータ入力を有することができる。上記のように、最後には、第１のパイプライン部分は、いくつかの外部ソースからデータ要素を得るのではなく、データ要素それ自体を発生することができる。
【００２４】
図１２に示されているように、本発明のコントローラ２０は、ホストアプリケーション手段５０、ライブラリ手段１０、メモリ管理手段５６、最後のタスク手段６０、少なくとも一つの中間タスク手段６２、及び第１のタスク手段６４を備える。コントローラはデータソース手段６６を含んでいてもよいが、含む必要もない。この場合において、第１のタスク手段６４もデータソース手段６６の関数を実行する。複数のリンク７０は、リンク７０によってホストアプリケーション手段に接続されたデータ処理パイプライン８０内の第１のタスク手段６４、少なくとも一つの中間手段６２、及び最後のタスク手段６０を接続させる。当然、簡単なパイプライン８０が、第１のタスク手段６４と最後のタスク手段６０だけを含んでもよいことは理解されるべきである。最後に、データ入力リンク７２はデータソース手段６６を第１のタスク手段６４と接続させる。
【００２５】
ホストアプリケーション手段５０は、データ処理パイプライン８０から受け取られたデータをさらに処理するためのデータ処理手段５８を含む。まず、コントローラ２０は、ホストアプリケーション手段５０、ライブラリ手段１０、及びメモリ管理手段５６を含むにすぎない。ホストアプリケーション手段５０は当該ホストアプリケーション５０内に含まれた命令によってコントローラ２０を操作する。コントローラ２０は、単一タスキングコントローラ、単一ＣＰＵ、多重タスキングコントローラ又は真の多重ＣＰＵであり得る。いづれの場合においても、ホストアプリケーション手段５０自体がコントローラ２０内で単一タスキング環境を生成する。
【００２６】
ホストアプリケーション手段５０は、それがデータソース６６から処理されたデータを必要とすると決定する時、当該ホストアプリケーション手段５０は、データ処理パイプライン８０を作成し且つ呼び出す。従って、ホストアプリケーション手段５０は初期化手段５２及び呼出し手段５４を含む。この初期化手段５２は、関数を取り且つタスクを生成する為にその関数を初期化するためにライブラリ手段１０へアクセスする。即ち、ライブラリ手段１０は多数のデータ処理関数を記憶する。データ処理関数は、ライブラリにおいて関数が初期化されなかった時、オブジェクト指向システム内のオブジェクトのクラス又はサブクラスである。
【００２７】
初期化手段５２は、初期化されない関数の内の一つを得るためにライブラリ手段１０へアクセスする。次いで、初期化手段５２は、得られた関数を初期化して、具体化された関数又はタスクをコントローラ２０内に生成する。具体化された関数又はタスクは、ホストアプリケーション手段５０又は他の前もって生成されたタスクへリンクされる。タスクがホストアプリケーション手段へリンクされている場合、それは最後のタスク６０である。タスクが他のタスクへリンクされ、他のタスクもそのタスクへリンクされている場合、それは中間タスク６２である。タスクが他のタスクへリンクされ且つデータソース手段６６からデータを受け取るか、又はそれ自体がデータを発生する場合、それは第１のタスク６４である。
【００２８】
タスクを生成するために関数を初期化するにあたって、初期化手段５２は、タスクを記憶するためにメモリ２６のメモリブロック２６ａ乃至２６ｆの内の一つを割り当てるため、コントローラのメモリ管理手段５６と共に動作する。所望されるタスクの全てが初期化手段５２によって初期化された後で、呼出し手段５４が最後のタスク手段６０からデータを要求することによってパイプライン８０を呼び出す。呼出し手段５４からの要求は、パイプライン８０の上流方向へ第１のタスク手段６４へ向けて流れる（リップルする）。その要求が第１のタスク手段６４に達した時、第１のタスク手段はデータソース６６からデータを得るか又はそれ自体がデータを発生する。次いで、第１のタスキング手段６４はデータを下流方向で中間タスク手段６２へリターンする。中間タスク手段６２はそのデータを処理し且つそれを最後のタスキング手段６０へリターンする。最後のタスク手段６０はそのデータを処理し且つそれをホストアプリケーション手段へリターンする。次いで、より多くのデータがホストアプリケーション手段によって必要とされる場合、呼出し手段５４は再びパイプライン８０を呼び出す。
【００２９】
一旦ホストアプリケーション５０が全ての所望されるデータを有すると、呼出し手段５４は、パイプライン８０からエラーコードを要求することによって、当該パイプライン８０から発生するいづれのエラーをも閉じ込め（シャットダウン）且つクリーンアップ（浄化）するために再びパイプライン８０を呼び出す。前と同じようにこの要求は上流へリップルする。各タスキング手段は、それがエラーコードを発生したかを決定し、それらのエラーコードをリターンする。これらのエラーコードが一旦リターンされると、初期化手段５２は、パイプライン８０のタスク手段６０乃至６４に割り当てられたメモリを解放するため、メモリ管理手段５６へ信号を送る。
【００３０】
図１３は、汎用化されたタスク手段６８を示し、これはタスク手段６０乃至６４のいづれかを表す。この汎用化されたタスク手段６８は、リンク手段８２、少なくとも一つのチャネル手段８４（８４ａ、８４ｂ、８４ｃ）、データ処理手段８６、データ分析手段８８、タスク状態手段９０、エラーコード発生手段９２、外部ポート手段９４、及び再構成手段９６を備える。実際のタスク手段６０乃至６４が、一つより多くの要素を欠いた、これらの要素の異なる組み合わせを有してもよいことは当然理解されよう。さらに、第１のタスク手段６４は、パイプライン８０のためにデータを受け取ったり発生したりするためのデータ受取り及び／又は発生手段９８も含む。
【００３１】
リンク手段８２は、順方向リンクが使用される時、汎用化されたタスク手段６８を次の又は上流のタスク手段６８とリンクするか、又は逆方向リンクが使用される時、汎用化されたタスク手段６８を前の又は下流のタスク手段６８とリンクする。両リンクとも一度に使用されることができる。汎用化されたタスク手段６８は、チャネル手段８４を介して次のタスク手段６８からリターンされたデータを受け取る。そのデータは、次いで、それがチャネル８４を介して前のタスク手段６８へリターンされる前にデータ処理手段８６を用いて処理される。
【００３２】
タスク状態手段９０はタスク手段６８の状態を保持する。タスク状態手段９０はまたタスク手段６８の全ての他の手段を制御する。
【００３３】
データ分析手段８８は次のタスク手段６８から受け取られたデータがデータ処理手段８６に適しているかを決定する。データが適していない場合、データ分析手段が二つの異なる可能な応答を持っている。第１のタイプの応答においては、簡単化されたタスク手段６８は、データの代わりに、エラーコード発生手段９２によって発生されたエラーコードを前のタスク手段へリターンするだけである。ホストアプリケーション手段５０がデータの代わりにエラーコードを受け取った時、アプリケーション手段５０は、そのエラーの性質（及び原因）を決定するためにエラー処理システムを使用する。次いで、ホストアプリケーション手段５０は、グレースフルに出るか又はパイプライン８０を再構成且つ／又は再初期化するとによってエラーから回復するように試みることができる。
【００３４】
第２のタイプの応答において、複雑なタスク手段６８は、エラーから回復するためにパイプライン８０をダイナミックに再構成しようとする再構成手段９６を含む。この再構成手段９６は、追加のタスク手段６８をダイナミックに初期化し且つそれらをパイプライン８０へ挿入するとによってこれを行なう。再構成手段は外部ポート手段９４を介して他のタスキング手段６８へアクセスすることによってこれを行なう。この外部ポート手段はタスキング手段６８への様々なアクセスモードを許容する。これらのモードはタスク状態手段９０を検査及び／又は変更し、エラーコード発生手段９２を検査し、即ちリンク手段８２を変更したりすることも含まれる。
【００３５】
たとえタスク手段６８が洗練された再構成手段９６有していたとしても、回復不可能又はハードエラーはまだ発生する可能性がある。この場合、タスク手段はエラーコードを発生するため、再びエラーコード発生手段９２を使用する。
【００３６】
最後に、第２の実施例において、リンク手段８２は、タスク手段６８自体でなくて、チャネル手段８４をリンクする。リンク手段８２はチャネルを次の又は前のタスク手段６８へ直接リンクする。従って、タスク手段６８が多数のチャネル手段８４ａ、８４ｂ、及び８４ｃを有する場合、各チャネル手段８４ａ乃至８４ｃは異なる次の又は前のタスク手段６８へリンクされ得る。一方、第１の実施例において、リンク手段８２はタスク手段６８をリンクしたので、タスク手段６８のすべてのチャネル手段８４ａ乃至８４ｃは同じ次のタスク手段６８とリンクされることになる。
【００３７】
図２に示されているように、各初期化関数又はタスクはデータソース１２とホストアプリケーション１２０の間で実行されるパイプライン４０の部分４０ａ、４０ｂ、及び４０ｃとしてビジュアル化され得る。ホストアプリケーションはＣＰＵ２０によって現在実行されている（且つＲＡＭ２６に格納される）アプリケーションである。パイプライン４０の各部分４０ａ、４０ｂ、及び４０ｃは、一つ又はそれより多くのデータ処理チャネル４２と、パイプライン部分の状態を定義するデータストラクチュア４４、及びゼロ、一つ又はそれより多くの外部ポート４６を備える。各パイプライン部分４０ｂ及び４０ｃ並びにホストアプリケーション１２０のそれぞれが、パイプライン部分４０ｂ及び４０ｃ又はホストアプリケーション１２０を直ぐ上流のパイプライン部分４０ａ、４０ｂ、及び４０ｃのそれぞれへリンクする逆方向リンク４８を有する。或いは、各パイプライン部分４０ａ、４０ｂ、及び４０ｃは、直ぐ下流のパイプライン部分４０ｂ及び４０ｃ又はホストアプリケーション１２０への順方向リンク４８’を有する。最後には、逆方向リンク４８と順方向リンク４８’の両方が提供されてもよい。
【００３８】
制御システムの好ましい実施例において、パイプラインは「知的な」パイプライン部分を有する。これらの知的なパイプライン部分は、それがホストコンピュータから操作される時、ホストアプリケーションによるいかなる割り込みも必要とせずに、パイプラインをダイナミックに再構成することが可能である。例えば、パイプライン４０ｂは、パイプライン部分４０ａによってリターンされたデータ要素を処理することが可能である。パイプライン４０ｂがデータ要素を処理することが不可能な場合、パイプライン部分４０ｂは、関数ライブラリ１０をダイナミックに呼び出し、且つ新たなパイプライン部分４０ｄを作成する。パイプライン部分４０ｄはパイプライン部分４０ａにリンクされる。次いで、パイプライン部分４０ｂはそれ自体のリンクを変えて、パイプライン部分４０ａよりもむしろパイプライン部分４０ｄを指し示す。
【００３９】
或いは、パイプライン部分４０ｂがそれがデータを処理することが不可能であることを決定した場合（例え、それがそのパイプラインを再構成しようとする場合でも）、当該パイプライン部分４０ｂはハードエラーを示すエラーコードをリターンする。ホストアプリケーションにおけるエラー処理システムは、ライブラリからエラーの性質を決定する。一つの実施例においては、ホストアプリケーションはそれがエラーから回復するためにパイプラインを再生することができるかを決定する。再生できる場合、ホストアプリケーションはパイプラインを再初期化する。しかしながら、ホストアプリケーションがエラーから回復することが不可能である場合又はこの能力を備えていない場合、ホストアプリケーションはグレースフルに出る。
【００４０】
この様な回復不可能エラーは、例えば、画像を処理するにあたって発生し得る。ヘッダが１０００の走査ラインが画像内にあるが、走査ライン画像データ要素が第９９８回目の呼び出しでも第１のパイプライン部分へリターンされなかったことを示した場合、システムはハードエラーへ出会う。単に処理できるデータがないために、パイプラインがそれ自体で再構成しようとする能力に関わらず、このエラーは回復することができない。この場合において、第１のパイプライン部分は”ＥＲＲ” エラーコードをリターンする。ホストアプリケーションは、次いで、エラーコードに対する理由を決定するためにエラー処理システムを使用する。このエラーの性質を決定した後、ホストアプリケーションは、システムのいかなる再構成又は再初期化も的を得てないので、グレースフルに出る。
【００４１】
パイプラインが再構成される場合、パイプライン部分４０ｂはパイプライン部分４０ｄからデータを要求する。パイプライン部分４０ｄは、データ要素を再リターンするパイプライン部分４０ａからデータを要求する。しかしながら、ここで、パイプライン部分４０ａは、データ要素を、パイプライン部分４０ｂではなくパイプライン部分４０ｄへリターンする。あるいは、関数ライブラリ１０を呼び出す時、パイプライン部分はデータ要素を提供することができ、これによってパイプライン部分４０ｄはこの部分が作成されるや否や、データ要素を有することができる。従ってパイプライン部分４０ｂがパイプライン４０ｄからデータを要求する時、パイプライン部分４０ｄはすぐに処理を行ない、且つそのデータ要素をリターンすることができる。
【００４２】
さらに、順方向リンク４８’が提供される場合、知的なパイプライン部分は、それらのデータストラクチュアにおいて、データ要素がこのパイプライン部分によって処理されるのを必要とするかを決定するための手段を含むことができる。必要としない場合、パイプライン部分は、それ自体をパイプラインラインから取り去るため、ホストアプリケーションに全く割り込まれることなく、パイプラインをダイナミックに再構成することができる。順方向リンクは必要であり、これによって、パイプラインがどの下流のパイプライン部分を変えるかを知り、これによってパイプライン部分が適切な上流のパイプライン部分とリンクされる。
【００４３】
外部ポート４６は、パイプライン部分の現在状態を検査するため、パイプライン部分のデータ構造４４へデータを書き込むため、そのパイプライン部分の現在状態を変えるか若しくはダイナミックに部分を追加するためにパイプライン部分（又は複数のパイプライン部分）の連結部分４８をダイナミックに変えるため、又はパイプライン４０から複数の部分をデリート（削除）するために使用される。一般に、外部ポート４６は、データ要素を処理するにすぎないデータチャネル４２から独立して、パイプラインを制御するために使用される。要するに、データチャネル４２は、上流のパイプライン部分から受け取られたデータを処理し、且つこの処理されたデータを下流のパイプライン部分へ出力するためだけに使用される。外部ポート４６は、データチャネル４２の動作に影響を与えずにパイプライン部分のデータストラクチュア４４へのアクセスを可能とする。
【００４４】
従って、他の実施例においては、例えば、パイプライン４０が作成された後で、パイプライン部分４０ａとパイプライン部分４０ｂの間にパイプライン部分４０ｄを追加することが必要となった場合、これは外部ポート４６を用いて達成される。この実施例において、パイプライン部分４０ｃは、そのデータストラクチュアの一部として、チャネル内でデータをテストするためのストラクチュアを有する。データの形式が、例えば、パイプライン部分４０ｃの適切な動作に必要とされる形式と互換性を持たないが、データが、例えば、パイプライン部分４０ｂの前に変更されなればならない場合、パイプライン部分４０ｃは、新しいパイプライン部分４０ｄをダイナミックに初期化し且つそれをパイプライン部分４０ａとパイプライン部分４０ｂの間に挿入する。このパイプライン部分４０ｃは、パイプライン部分４０ｂにおける外部ポート４６を介して、パイプライン部分４０ｂのデータストラクチュア４４にアクセスすることによってこれを行なう。パイプライン部分４０ｃがパイプライン部分４０ｂのリンク４８を変え、これによりパイプライン部分４０ａからのリンク４８が新しいパイプライン部分４０ｄへ変えられる。同様に、新しいパイプライン部分４０ｄのデータストラクチュア４４は、このストラクチュアが適切に初期化され且つパイプライン部分４０ａへリンクされることを確実とするためにアクセスされる。
【００４５】
動作上、図７に示されているアプリケーションのようなホストアプリケーションがデータをデータソース１２から要求する時、ホストアプリケーションは、最初、関数ライブラリ１０から関数を呼出し且つ初期化することによってパイプライン４０を形成する。図７に示されている実施例において、変数 ”ｉ” 、” ｎ” 、”ａｄｄ ｖａｌｕｅ”、及び”ｍｕｌ ｖａｌｕｅ”がホストアプリケーションの５行目で初期化される。６行目では、第１のタスク４０ａが「ヌル」タスクとして定義されている。第１のタスクは、データソース１２からデータ要素を得るために接続されることができると共に、「ヌル」コマンドを用いて第１のタスク４０ａがデータソース１２として作用するのを示すことが可能である。図７の７行目において、パイプライン４０におけるタスクの数は、図８に示されるホストアプリケーションを開始したコマンドラインによって決定される。一般に、ホストアプリケーションを実行すると、パイプライン４０のレングス（長さ）及び構成素（ｃｏｎｓｔｉｔｕｅｎｔｓ）はダイナミックに決定される。或いは、パイプライン４０のレングス及び構成素はホストアプリケーションにおいて明白に説明される。最後に、パイプライン４０の初期のレングス及び構成素がダイナミックに決定された時又は明白に説明された時のいづれであっても、パイプライン４０はデータソース１２から受け取られたデータによってそれ自体をダイナミックに再構成することができる。
【００４６】
図７に示されている実施例において、７行目に示されているように、パイプライン４０のレングスはプログラムを開始するコマンドラインにおいて明白に説明される。この場合において、パイプラインのレングスは図８が示すように５である。図７の８行目と９行目に示されているように、各関数が呼び出され且つ初期化され、且つデータソースからホストアプリケーションへ拡張される。この場合、図７の６行目に示されているように、第１のタスク４０ａもデータソースのように動作する。さらに、９行目に示されているように、パイプライン４０における各タスクは同じ関数の異なる具体化（インスタンシェーション）又はタスクである。図７の９行目と図５のの１７行目に示されているように、この例における関数”Ｍａｔｈ Ｔａｓｋ” が初期化されると、そのデータストラクチュアは、各々が現在値” ｉ” にセットされる二つのチャネルデータバッファと、パイプライン内の上流タスクを指し示すポインタを含む。さらに、パイプライン内に上流タスクが全くない場合、ポインタは「ヌル」にセットされる。
【００４７】
関数ライブラリ１０における関数がオブジェクト指向言語においてはオブジェクトとして定義されるので、図７に示されている実施例において関数が初期化される度に、同じ関数の異なる具体化が事実上行なわれる。これによって、単一パイプライン４０はあらゆる単一関数の複数のコピーを有していてもよい。従って、関数の各コピーはライブラリ内に格納されたベース関数の異なる具体化であり且つパイプライン４０の異なるタスク又は部分として動作する。これにより、関数ライブラリ１０における関数は、それらがあらゆる単一パイプラインにおいて一回以上使用されることができるので、再帰的である。
【００４８】
８行目及び９行目においてパイプライン内の各タスクが作成された後、初期化されたタスクのチャネル（この場合は二つ）が１０行目と１１行目で実行される。一旦、図６に示されたホストアプリケーションが、１０行目と１１行目で実行された複数のチャネルを介して、タスクから最後のデータを受け取ると、図８に示された出力は、図７の１２行目と１３行目に説明されているようにプリントされる。
【００４９】
図７のホストアプリケーションにおいては、上記に示されているように、８行目及び９行目において、パイプラインは、多数の関数”ＭａｔｈＴａｓｋ”の独立した具体化を有する。図５及び図６は、図７に示されているように、ホストアプリケーションによって形成されるパイプラインのために必要な各具体化を形成するため、図７の８行目及び９行目においてホストアプリケーションによって呼び出されるライブラリオブジェクト”ＭａｔｈＴａｓｋ”を示す。
【００５０】
図５に示されている”ＭａｔｈＴａｓｋ”関数の１乃至６行目において、主要データストラクチュアが定義される。１乃至６行目に示されているように、データストラクチュアは、二つのチャネル即ちチャネル１及びチャネル２並びに逆方向又は上流リンクを含む。次に、７行目乃至１２行目において、第１及び第２のチャネルのそれぞれに対するこの関数に特定のデータストラクチュア、”ａｖａｌ”及び”ｍｖａｌ”が定義される。
【００５１】
次に、１７行目で、チャネル１に対するデータ要求、”ａｖａｌｕｅ”及びチャネル２に対するデータ要求、”ｍｖａｌｕｅ”、並びに上流リンク「リンク」で、タスク”ＭａｔｈＴａｓｋ”に対して具体化手順が定義される。１８乃至２０行目において、チャネル１及びチャネル２のそれぞれに対する変数”ａｖａｌｕｅ”及び”ｍｖａｌｕｅ”並びにリンクが定義される。最後に、２１行目において、関数”ＭａｔｈＴａｓｋ”のタスクを作成し且つＲＡＭ２６のメモリブロックを割り当てるための手順が定義される。
【００５２】
次に、図６の２８乃至３７行目に示されているように、チャネル１に対応するデータ処理手順とデータストラクチュアが定義される。チャネル１のデータ処理手順は、タスクの直ぐ上流のタスクから番号を得る。さらに、図７の６行目に示されているように、パイプラインにおける第１のタスクは「ヌル」タスクである。第１のタスクに対する「ヌル」状態から生じる結果は、”ｖａｌ” の初期値をゼロに定義する３２行目で定義される。３３行目では、逆方向リンクが存在している場合、３４行目で値”ｖａｌ” はチャネル１の上流タスクの出力へセットされる。次いで、３５行目では、値”ｖａｌ” は、現在パイプライン部分のチャネル１の加数値”ａｖａｌ”をその値へ追加することによって更新される。各パイプライン部分に対するチャネル１の加数値”ａｖａｌ”は、２５行目で、図７の９行目でセットされたパイプライン部分の状態パラメータ”ａｖａｌｕｅ”へセットされた。最後に、チャネル１のデータ処理手順は、新しい値”ｖａｌ” を直ぐ下流のパイプライン部分へリターンすることによって終了する。
【００５３】
同様に、図６の３８乃至４７行目において、チャネル２のデータ処理手順が定義される。唯一の差は、図５の２２行目で初期化されたチャネル１の処理手順よりもむしろ図５の２３行目で初期化されたチャネル２の手順を使用する３９行目で発生する。さらに、４２行目では、値”ｖａｌ” は第１のパイプライン部分に対する「ヌル」データソースを補償するため、１にプリセットされる。４５行目では、新しい値”ｖａｌ” は、図７の９行目においてセットされた、図５の２６行目で状態パラメータ”ｍｖａｌｕｅ”にセットされたチャネル２の被乗数によって乗算される古い値”ｖａｌ” に等しい。
【００５４】
動作上、図７の８行目と９行目に示されているホストアプリケーションは指示された回数だけ関数”ＭａｔｈＴａｓｋ”を呼び出す。関数”ＭａｔｈＴａｓｋ”の第１の具体化はデータソースに接続されないヌルタスクとしてセットアップされる。再び、８行目と９行目をループすることによって、関数”ＭａｔｈＴａｓｋ”の第２の具体化がタスク”ＭａｔｈＴａｓｋ”の先の具体化との逆方向リンクによって形成される。その後、図７の８行目と９行目を介して各ループごとに、関数”ＭａｔｈＴａｓｋ”のさらなる具体化が形成される。図７に示されているホストアプリケーションの８行目と９行目を介して最後のループが一旦完了すると、ホストアプリケーションからのタスク”ＭａｔｈＴａｓｋ”の最後の一つへの逆方向リンクはセットされたままとなる。図４は、このようにして初期化された３−セクションパイプラインを示す。
【００５５】
次いで、１０行目と１１行目において、ホストアプリケーションは、関数”ＭａｔｈＴａｓｋ”の最後の具体化のチャネル１とチャネル２からデータを要求する。最後のタスクは回転し且つその直ぐ上流のタスクからデータを要求する。これは、その”ＭａｔｈＴａｓｋ”の第１の具体化がチャネル１とチャネル２を通してのデータに対する要求を受け取るまで続く。図３はこのタイプのデータフローの例を示す。ホストアプリケーションは図７の１０行目及び１１行目でパイプラインを呼び出した後、最後のパイプライン部分はそれがリンクされるパイプライン部分の図６の３４行目と４４行目で各チャネルを呼び出す。次いで、最後のパイプライン部分は、各々の呼び出されたパイプライン部分が、その部分がリンクされる上流のパイプライン部分を呼び出す。第１のパイプライン部分に達すると、この第１のパイプライン部分はデータソース１２からデータ要素を受け取るか、又はこの場合、データ要素を自己発生する。第１のパイプライン部分は、次いで、上記のようにそれを呼び出したパイプライン部分へそのデータ要素をリターンする。
【００５６】
関数”ＭａｔｈＴａｓｋ”の第１の具体化は、次いで、チャネル１とチャネル２に対して定義されたデータ処理手順を実行する。第１の具体化は、チャネル１に対しては０＋１に等しい値１及びチャネル２に対しては１×１に等しい値１を関数”ＭａｔｈＴａｓｋ”の第２又は具体化へリターンする。関数”ＭａｔｈＴａｓｋ”の各具体化は、引き続いて、第１の数をチャネル１で保持された値へ加算し、次いでチャネル２で保持された数を第２の数によって乗算する。図５及び図６に示されている例において、第１と第２の数は、図７の９行目でパイプラインが作成された時に初期化された加数と被乗数である。しかしながら、数はダイナミックに発生されることもできた。従って、チャネル１及びチャネル２において処理されたデータは、ホストアプリケーションへ向けて下流へリップルする。これによって、関数”ＭａｔｈＴａｓｋ”の最下流の具体化は、要求されたデータをホストアプリケーションへ提供する。
【００５７】
ＣＰＵ２０が図７に示されているホストアプリケーションを実行する時、それはホストアプリケーションをＲＡＭ２６のメモリブロック２６ａに格納する。ホストアプリケーションは、事実上、割り当て可能なメモリブロック２６ａ内に格納されたデータストラクチュアである。データストラクチュア自体は指定されたメモリの位置にわたるテンプレートを有しており、このテンプレートはＣＰＵ２０の制御動作のフロー（流れ）を定義する。割り当てられたメモリブロック２６ａの第１の部分において、種々のメモリ位置が定義され且つ／又は変数として割り当てられる。データブロック２６ａはまたホストアプリケーションの状態を定義する種々のメモリ位置、及びホストアプリケーションによって要求されたデータ又はホストアプリケーションによって処理されたデータを記憶するためのバッファとして動作する種々のメモリ位置を含む。
【００５８】
同様に、ホストアプリケーションが、例えば、関数”ＭａｔｈＴａｓｋ”の具体化を初期化するために関数ライブラリ１０を呼び出す時、他のデータブロック２６ｂがそのタスク又はパイプライン部分へ割り当てられる。ホストアプリケーションのように、初期化されたパイプライン部分は、実際に、割り当てられたメモリブロック２６ｂに対するテンプレートを備える割り当てられたメモリブロック２６ｂ内のデータストラクチュアである。割り当てられたメモリブロックは、処理されるデータ、データのタイプを定義するための種々のメモリ位置、このタスクがそのデータを受け取る場所を示す手順ポインタ、そのタスクの状態を定義するデータを記憶する種々のメモリ位置、及び関数”ＭａｔｈＴａｓｋ”の直ぐ上流の具体化から受け取られた処理されたデータを記憶するための一つ又はそれより多くのデータバッファを記憶するためのバッファを有する。
【００５９】
割り当てられたデータブロック２６ｂはチャネル１とチャネル２に対するデータ処理動作を定義するデータストラクチュアも含む。それとは別に、割り当てられたデータブロック２６ｂ内のデータストラクチュアは、データ処理を実行するための、又は関数ライブラリ１０における他の関数へのポインタルックアップテーブルとしての、ルックアップ（検索）テーブルを含む。一般に、各タスクは、それがデータブロック２６ａ乃至２６ｆの内の一つへ初期化され且つ割り当てられると、データ入力、データ出力、タスク状態、及びそのタスクによって実行される種々のデータ処理手順に充分なバッファを自動的に割り当てる。
【００６０】
図９乃至図１１は、この方法を実施する制御ルーチンに対して汎用化されたフローチャートを示す。図９に示されているように、スタートしてから、ステップＳ１０において、ホストアプリケーションは単一処理ＣＰＵ２０によって実行される。ステップＳ２０においては、コントローラが、一つのデータ処理パイプラインがコンピュータ１００の現在動作に必要とされるか否かをチェックする。必要とされない場合、制御ルーチンはステップＳ１０へ戻る。
【００６１】
しかしながら、パイプラインが必要とされる場合、制御ルーチンはステップＳ３０へ進み、このステップにおいて、関数ライブラリから関数を呼び出す。次いで、ステップＳ４０において、呼び出された関数は第１のタスク又は第１のパイプラインを形成するために初期化される。次いで、ステップＳ５０においては、コントローラは追加のパイプライン部分のいづれかが必要とされるか否かをチェックする。必要とされる場合、制御ルーチンは、ライブラリから次の関数を呼び出すためにステップＳ３０へ戻る。従って、制御ルーチンは、追加のタスクが要求されなくなるまで、ステップＳ３０乃至Ｓ５０をループする。この時点で制御ルーチンはステップＳ６０へ進む。
【００６２】
ステップＳ６０において、パイプラインが呼び出される。ステップＳ７０において、パイプラインは処理されたデータ要素をホストアプリケーションへリターンする。次いで、ステップＳ８０において、コントローラは追加のデータが必要か否かを決定する。追加のデータが必要な場合、制御ルーチンはパイプラインを再び呼び出すためにステップＳ６０へリターンする。
【００６３】
しかしながら、追加データが必要とされない場合、制御ルーチンはステップＳ９０へ進み、種々のパイプライン部分へ割り当てられたメモリを割り当て解除することによって初期化解除される。ステップＳ１００において、ホストアプリケーションの次のコマンドが実行される。次いで、ステップＳ１１０において、コントローラはホストアプリケーションの追加のパイプラインが実行される必要があるかを決定する。実行される必要がある場合、制御ルーチンはステップＳ３０へリターンする。
【００６４】
しかしながら、この時点でパイプラインが必要とされない場合、制御ルーチンはステップＳ１２０へ進み、コントローラがホストアプリケーションが完了したか否かを決定する。完了した場合、制御ルーチンはストップする。そうでない場合（完了していない場合）、制御ルーチンはステップＳ１００へ戻る。
【００６５】
図１０は初期化ステップＳ４０に対するフローチャートを示す。ステップＳ４０で初期化ルーチンへエンターした後、制御ルーチンは、タスクに対する主要データストラクチュアが作成されるステップＳ２００へ進む。次いで、ステップＳ２１０において、このタスクに対して特定であるデータストラクチュアの部分が作成される。次いで、ステップＳ２２０においては、チャネルデータストラクチュアが作成され、且つステップＳ２３０においては、逆方向リンクが作成される。順方向リンクが必要とされる場合、そのデータストラクチュアは定義されるが、順方向リンクがリンクする下流タスクがまだ作成されていないので、それはパイプラインが呼び出されるまで終了されない。リンクはリンクされたパイプライン部分を呼び出すための手順ポインタを有する。次いで、ステップＳ２４０において、制御ルーチンはステップＳ４０へ戻る。
【００６６】
図１１はステップＳ６０の呼出しルーチンに対するフローチャートを示す。ステップＳ６０からスタートして、制御ルーチンはホストアプリケーションが最後のパイプライン部分からデータを要求するステップＳ３００へ進む。次いで、ステップＳ３１０において、現在のパイプライン部分は次の上流パイプライン部分からデータを要求する。ステップＳ３２０においては、コントローラは次のパイプライン部分が最初パイプライン部分であるか否かを決定する。そうでない場合、制御ルーチンはステップＳ３１０へ戻る。
【００６７】
しかしながら、次のパイプライン部分が最初パイプライン部分である場合、制御ルーチンはステップＳ３３０へ進む。ステップＳ３３０において、コントローラは第１のパイプライン部分が「ヌル」部分であるか否かを決定する。そうでない場合、制御ルーチンは最初パイプライン部分が外部ソースからデータ要素を得るステップＳ３４０へ進む。第１のパイプライン部分が「ヌル」部分である場合、制御ルーチンは、第１のパイプライン部分がデータ要素を自己発生するステップＳ３５０へ進む。
【００６８】
両ケースにおいて、ステップＳ３４０又はステップＳ３５０のいづれかを経て、制御ルーチンはステップＳ３６０へ進み、ここで第１のパイプライン部分はデータを第２即ち次のパイプライン部分へ下流へリターンする。ステップＳ３７０において、次のパイプライン部分はデータを処理する。次いでステップＳ３８０において、次のパイプライン部分が最後のパイプライン部分である場合、処理されたデータはステップＳ３９０でホストアプリケーションへリターンされる。しかしながら、次のパイプライン部分が最後のパイプライン部分でない場合、データは新しい次のパイプライン部分へリターンされ、且つステップＳ３６０へのループバックにより示されるように、データ要素が処理される。この「ルーピング」は、最後のパイプライン部分へ至り、且つステップＳ３９０でデータがホストアプリケーションへリターンされるまで行なわれる。次いで制御ルーチンはステップＳ６０へ戻る。
【００６９】
本発明のデータ処理パイプラインの第１の実施例において、前もって定義された逆方向リンクを置換するか又はこの逆方向リンクに付け加えられる順方向リンクが提供される。この場合、タスクライブラリのタスクの内の一つの現在最下流の具体化から逆方向リンクが定義された後で、直ぐ上流のタスクから最下流タスクへの順方向リンクが定義される。或いは、順方向リンクのみが提供されなければならない。しかしながら、この場合において、パイプライン部分は、ホストアプリケーションから上流へ、存在していれば、データのデータソースへ向かって初期化され、次いで下流のデータソースからホストアプリケーションへ呼び出される。
【００７０】
さらなる実施例において、各タスクが二つ又はそれより多くのデータ処理チャネルを有する時、単一の順方向リンク及び／又は単一の逆方向リンクによって共にリンクされる。この場合において、各チャネルは、タスクライブラリからのタスクの具体化の内のいづれか一つの他の対応チャネルと逆方向又は順方向リンクされることができる。従って、第１のパイプライン部分のチャネルの内の一つは第２のパイプライン部分の対応チャネルとリンクされるが、第１のパイプライン部分の他のチャネルは第３のパイプライン部分の対応チャネルとリンクされる。
【００７１】
本発明のまた他の実施例において、特別な「ファンイン」及び「ファンアウト」のパイプライン部分が提供される。これらのパイプライン部分において、二つ又はそれより多くの上流にパイプライン部分がファンイン分岐パイプライン部分を用いて単一の下流のパイプライン部分とリンクされる。同様に、単一上流パイプライン部分がファンアウト分岐パイプライン部分を用いて二つ又はそれより多くの下流パイプライン部分と接続される。
【００７２】
【発明の効果】
単一処理プロセッサを用いて多重処理データ処理パイプラインをエミュレートするための制御システムを提供する。
【図面の簡単な説明】
【図１】本発明のシステムのブロック図を示す図である。
【図２】本発明のパイプラインのブロック図を示す図である。
【図３】本発明のパイプライン内のデータの流れを示す図である。
【図４】適例となるデータ処理プログラムのためにリンクされたパイプラインを示す図である。
【図５】サンプルタスクのための適例となるコードリスティングを示す図である。
【図６】サンプルタスクのための適例となるコードリスティングを示す図である。
【図７】パイプラインを形成するためにライブラリからタスクを呼び出す適例となるホストアプリケーションにためのコードリスティングを示す図である。
【図８】図４に示され且つ図５及び６並びに図８にリストされているパイプラインの出力のリスティングを示す図である。
【図９】主要ルーチンのフローチャートを示す図である。
【図１０】機能初期化ルーチンを示す図である。
【図１１】呼出し及び処理ルーチンのフローチャートを示す図である。
【図１２】本発明のコントローラを示す図である。
【図１３】本発明の汎用化されたタスク手段を示す図である。
【符号の説明】
１０ タスクライブラリ
１２ データソース
１３ ディスプレイ
１６ キーボード
１８ マウス
１９ ディスクドライブ
２０ 単一処理コントローラ
２２ Ｉ／Ｏインターフェース
２４ ＲＯＭ
２６ ＲＡＭ
１００ コンピュータ
Claims (1)
- 単一処理プロセッサを用いて多重処理パイプラインデータ処理をエミュレートするための方法であって、
前記単一処理プロセッサ上でホストアプリケーションを実行するステップと、 データソースから処理されたデータを前記ホストアプリケーションへ供給するためにデータ処理パイプラインを作成するステップと、
前記パイプラインを呼び出すステップと、
前記パイプラインを削除するステップと、
を備え、
前記パイプラインを作成するステップが、
（ａ）複数の所定の関数から選択された第１の関数を第１のタスクとして具体化するステップと、
（ｂ）前記ホストから前記第１のタスクへのリンクを定義するステップと、
（ｃ）前記複数の所定の関数から選択された第２の関数を第２のタスクとして具体化するステップと、
（ｄ）前記第１のタスクから前記第２のタスクへのリンクを定義し且つ該リンクを前記ホストから前記第２のタスクへと再定義するステップと、
を有し、
引き続くタスクに対してステップ（ｃ）と（ｄ）を繰り返すステップであって、前記ホストアプリケーションが最後のタスクへリンクされており、且つ各タスクがメモリ内に記憶され、且つ前記各タスクが前記プロセッサを制御することよりなるステップと、
をさらに備え、
前記パイプラインを呼び出すステップが、
（ｅ）前記最後のタスクからデータ要素を要求し、各タスクはそれがリンクされるタス
クから前記データ要素を要求するステップと、
（ｆ）前記第１のタスクによって前記データ要素を得るステップと、
（ｇ）前記データ要素を前記要求タスクへリターンするステップと、
（ｈ）前記リターンされたデータを処理するステップと、
（ｉ）前記データが前記ホストアプリケーションへリターンされるまで、ステップ（ｇ）と（ｈ）を反復するステップと、
を有し、前記ステップ（ｅ）乃至（ｉ）が前記ホストアプリケーションによって要求されるデータごとに反復される
ことよりなる前記多重処理パイプラインデータ処理エミュレート方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US076679 | 1993-06-15 | ||
| US08/076,679 US5396616A (en) | 1993-06-15 | 1993-06-15 | System for emulating multi-tasking pipelines in a single tasking environment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH07105021A JPH07105021A (ja) | 1995-04-21 |
| JP3617852B2 true JP3617852B2 (ja) | 2005-02-09 |
Family
ID=22133561
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP12526894A Expired - Fee Related JP3617852B2 (ja) | 1993-06-15 | 1994-06-07 | 多重処理パイプラインデータ処理エミュレート方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US5396616A (ja) |
| EP (1) | EP0629945B1 (ja) |
| JP (1) | JP3617852B2 (ja) |
| CA (1) | CA2121154C (ja) |
| DE (1) | DE69408601T2 (ja) |
Families Citing this family (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5995996A (en) * | 1993-06-15 | 1999-11-30 | Xerox Corporation | Pipelined image processing system for a single application environment |
| US5701479A (en) * | 1993-06-15 | 1997-12-23 | Xerox Corporation | Pipelined image processing system for a single application environment |
| US5557795A (en) * | 1993-06-15 | 1996-09-17 | Xerox Corporation | Pipelined image processing system for a single application environment |
| US5379432A (en) * | 1993-07-19 | 1995-01-03 | Taligent, Inc. | Object-oriented interface for a procedural operating system |
| US5724555A (en) * | 1995-03-23 | 1998-03-03 | Canon Kabushiki Kaisha | Network interface board for digital copier |
| US5732269A (en) * | 1995-04-21 | 1998-03-24 | International Business Machines Corporation | Data adapter transparent to application I/O path |
| US5937415A (en) * | 1995-12-13 | 1999-08-10 | Sybase, Inc. | Data base development system with methods facilitating copying of data from one data source to another |
| US5809286A (en) * | 1996-05-01 | 1998-09-15 | Mci Communications Corporation | Method and apparatus for emulating a dynamically configured digital cross-connect switch network |
| US5748617A (en) * | 1996-05-01 | 1998-05-05 | Mci Corporation | Method and apparatus for emulating a digital cross-connect switch network |
| WO1997041657A1 (en) * | 1996-05-01 | 1997-11-06 | Mci Communications Corporation | Method and apparatus for emulating a digital cross-connect switch network |
| US5867689A (en) * | 1996-05-01 | 1999-02-02 | Mci Communications Corporation | Method and apparatus for emulating a digital cross-connect switch network using a flexible topology to test MCS network management |
| US5850536A (en) * | 1996-05-01 | 1998-12-15 | Mci Communications Corporation | Method and system for simulated multi-tasking |
| US5812826A (en) * | 1996-06-27 | 1998-09-22 | Mci Communications Corporation | Method and apparatus for emulating a network of state monitoring devices |
| US6035297A (en) * | 1996-12-06 | 2000-03-07 | International Business Machines Machine | Data management system for concurrent engineering |
| US6088693A (en) * | 1996-12-06 | 2000-07-11 | International Business Machines Corporation | Data management system for file and database management |
| US5826265A (en) * | 1996-12-06 | 1998-10-20 | International Business Machines Corporation | Data management system having shared libraries |
| US5954829A (en) * | 1996-12-30 | 1999-09-21 | Mci Communications Corporation | System, method, and computer program product for digital cross connect testing |
| US5854930A (en) * | 1996-12-30 | 1998-12-29 | Mci Communications Corporations | System, method, and computer program product for script processing |
| US5966515A (en) * | 1996-12-31 | 1999-10-12 | Unisys Corporation | Parallel emulation system and method |
| US6256659B1 (en) | 1997-12-09 | 2001-07-03 | Mci Communications Corporation | System and method for performing hybrid preemptive and cooperative multi-tasking in a computer system |
| US5974532A (en) * | 1997-12-09 | 1999-10-26 | Mci Communications Corporation | System and method for generating responses for inputs using a hybrid state engine table |
| US7013467B1 (en) | 1997-12-09 | 2006-03-14 | Mci Communications Corporation | System and method for managing computer system resources using command control vectors |
| US6286026B1 (en) * | 1998-08-17 | 2001-09-04 | Xerox Corporation | Method and apparatus for integrating pull and push tasks in pipeline data processing |
| US6880122B1 (en) * | 1999-05-13 | 2005-04-12 | Hewlett-Packard Development Company, L.P. | Segmenting a document into regions associated with a data type, and assigning pipelines to process such regions |
| US6728419B1 (en) | 2000-02-17 | 2004-04-27 | Xerox Corporation | Multi-tasking multi-threaded image processing system and method for image capture devices |
| JP4082051B2 (ja) * | 2002-03-19 | 2008-04-30 | 富士ゼロックス株式会社 | 画像処理装置および画像処理方法 |
| JP4407231B2 (ja) * | 2003-10-16 | 2010-02-03 | セイコーエプソン株式会社 | 印刷装置、印刷処理方法およびそのプログラム |
| US8054487B2 (en) * | 2004-12-16 | 2011-11-08 | International Business Machines Corporation | Mechanism to create a reservation against a future scheduling object instantiation |
| JP2006338506A (ja) * | 2005-06-03 | 2006-12-14 | Fujifilm Holdings Corp | コネクタ |
| JP2006338507A (ja) * | 2005-06-03 | 2006-12-14 | Fujifilm Holdings Corp | 処理装置及び処理方法 |
| US7853950B2 (en) * | 2007-04-05 | 2010-12-14 | International Business Machines Corporarion | Executing multiple threads in a processor |
| US9008464B2 (en) * | 2009-06-16 | 2015-04-14 | University-Industry Cooperation Group Of Kyung Hee University | Media data customization |
| US8983632B2 (en) * | 2011-03-29 | 2015-03-17 | Honeywell International Inc. | Function block execution framework |
| US20160328279A1 (en) * | 2015-05-07 | 2016-11-10 | Ebay Inc. | Method and System for Providing a Framework as a Service |
| US20170163732A1 (en) * | 2015-12-04 | 2017-06-08 | Vmware, Inc. | Inter-task communication within application-release-management pipelines |
| US11868206B2 (en) * | 2021-05-11 | 2024-01-09 | Sap Se | Automated mass message processing |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3909797A (en) * | 1973-12-13 | 1975-09-30 | Honeywell Inf Systems | Data processing system utilizing control store unit and push down stack for nested subroutines |
| US4296470A (en) * | 1979-06-21 | 1981-10-20 | International Business Machines Corp. | Link register storage and restore system for use in an instruction pre-fetch micro-processor interrupt system |
| JPS5617437A (en) * | 1979-07-23 | 1981-02-19 | Fujitsu Ltd | Loading system for nonresident program |
| GB2060225B (en) * | 1979-09-29 | 1983-05-25 | Plessey Co Ltd | Multi-programming data processing system process suspension |
| JPS5960651A (ja) * | 1982-09-30 | 1984-04-06 | Fujitsu Ltd | モジユ−ル間の制御遷移管理方式 |
| US4488227A (en) * | 1982-12-03 | 1984-12-11 | Honeywell Information Systems Inc. | Program counter stacking method and apparatus for nested subroutines and interrupts |
| JPS6238060A (ja) * | 1985-08-12 | 1987-02-19 | Matsushita Graphic Commun Syst Inc | 通信制御装置 |
| JPS6491260A (en) * | 1987-10-01 | 1989-04-10 | Nec Corp | Communication control system |
| JPH01193935A (ja) * | 1988-01-28 | 1989-08-03 | Nec Software Ltd | サブコマンド実行形式によるプログラム制御方式 |
| JP2792559B2 (ja) * | 1988-05-12 | 1998-09-03 | キヤノン株式会社 | カラー画像処理装置 |
| EP0357444A3 (en) * | 1988-09-02 | 1991-12-18 | Tektronix, Inc. | Dynamically configurable, demand driven data processing pipeline |
| JPH0766334B2 (ja) * | 1989-05-11 | 1995-07-19 | 松下電送株式会社 | 画像表示装置 |
| US5175854A (en) * | 1989-06-19 | 1992-12-29 | Digital Equipment Corporation | Inter-applicataion interface system |
| EP0433472B1 (de) * | 1989-12-18 | 1996-04-17 | Siemens Aktiengesellschaft | Verfahren zum gepufferten Datenaustausch zwischen Programmen einer Datenverarbeitungsanlage |
| JPH04130928A (ja) * | 1990-09-21 | 1992-05-01 | Fuji Xerox Co Ltd | 情報処理システムにおける例外処理方法 |
| JPH0797323B2 (ja) * | 1991-09-30 | 1995-10-18 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 名前付きパイプを用いるプロセス間通信の方法及びプロセス |
| US5289577A (en) * | 1992-06-04 | 1994-02-22 | International Business Machines Incorporated | Process-pipeline architecture for image/video processing |
| JPH0696212A (ja) * | 1992-09-14 | 1994-04-08 | Nippon Telegr & Teleph Corp <Ntt> | マルチプロセスを用いた動物体認識処理方法 |
-
1993
- 1993-06-15 US US08/076,679 patent/US5396616A/en not_active Expired - Lifetime
-
1994
- 1994-04-13 CA CA002121154A patent/CA2121154C/en not_active Expired - Fee Related
- 1994-06-07 JP JP12526894A patent/JP3617852B2/ja not_active Expired - Fee Related
- 1994-06-14 DE DE69408601T patent/DE69408601T2/de not_active Expired - Fee Related
- 1994-06-14 EP EP94304303A patent/EP0629945B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE69408601D1 (de) | 1998-04-02 |
| EP0629945A3 (en) | 1995-05-24 |
| CA2121154C (en) | 1999-03-09 |
| JPH07105021A (ja) | 1995-04-21 |
| US5396616A (en) | 1995-03-07 |
| CA2121154A1 (en) | 1994-12-16 |
| EP0629945A2 (en) | 1994-12-21 |
| EP0629945B1 (en) | 1998-02-25 |
| DE69408601T2 (de) | 1998-09-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3617852B2 (ja) | 多重処理パイプラインデータ処理エミュレート方法 | |
| JP3617851B2 (ja) | パイプライン化データ処理方法 | |
| USRE42444E1 (en) | Method for managing resources in a reconfigurable computer having programmable logic resources where automatically swapping configuration data between a secondary storage device and the programmable logic resources | |
| US7257816B2 (en) | Digital data processing apparatus and methods with dynamically configurable application execution on accelerated resources | |
| JPH06266683A (ja) | 並列処理装置 | |
| US20080244507A1 (en) | Homogeneous Programming For Heterogeneous Multiprocessor Systems | |
| KR970008527B1 (ko) | 고급 인스트럭션 처리 장치 및 방법 | |
| JPH0922362A (ja) | コンピュータシステムおよびコンピュータ制御方法 | |
| JPH02188833A (ja) | アプリケーションとデータベース管理システム間の相互通信システム及び方法 | |
| EP1763774A1 (en) | Multiple computer architecture with replicated memory fields | |
| US5701479A (en) | Pipelined image processing system for a single application environment | |
| CN106445656A (zh) | 一种实现线程本地存储的方法及装置 | |
| US6684395B2 (en) | Multiple image dynamic bind and load procedure for a multi-processor | |
| Gonzalez et al. | Parallel task execution in a decentralized system | |
| US8561077B1 (en) | Binder for a multi-threaded process to access an un-shareable resource | |
| JPH08263306A (ja) | パイプラインデータ処理用データ処理システムとパイプラインデータ処理方法 | |
| JPH10222381A (ja) | データ処理システム | |
| JPH07306837A (ja) | 分散処理のための装置、方法、及びプログラム製品 | |
| Machine et al. | Checkpoint & Migration of UNIX Processes in the Condor Distributed Processing System | |
| Bakkers et al. | Automatic generation of scheduling and communication code in real-time parallel programs | |
| Guzman et al. | MCC Technical Report Number: PP-163-87 | |
| Vankeerberghen et al. | Dynamic link libraries II. Development | |
| Kedem et al. | The Milan Project: A New Method for High-Assurance and High-Performance Computing on Large-Scale Distributed Platforms | |
| Hoecker | A Distributed Threads Package for Solaris 2.4 | |
| Hernandez | Parallel Programming Models |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040608 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040825 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040913 |
|
| 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: 20041102 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041105 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071119 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081119 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091119 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091119 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101119 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |