(57)【特許請求の範囲】
【請求項１】
予め定められたデータ量のデータの第１の送信要求が送信先からされると共に、該第１の送信要求に対応する第２の送信要求を受信先にし、該第２の送信要求に応じて該受信先が送信したデータを該データ量となるまで受信し、該受信したデータに基づいて予め定められた第１の処理を実行した後、データを該送信先に送信する複数の第１の処理手段を備えると共に、該複数の第１の処理手段各々が、データが順に各第１の処理手段により送信されるように、予め設定され、
受信先からデータを受信し、該受信したデータに基づいて予め定められた第２の処理を実行した後、データを送信先に送信する複数の第２の処理手段を備えると共に、該複数の第２の処理手段各々が、データが順に各第２の処理手段により送信されるように、予め設定され、
前記複数の第２の処理手段のうちの特定の第２の処理手段である第２の上流側処理手段と、該第２の上流側処理手段の送信先として予定された第２の処理手段である第２の下流側処理手段と、の間に、前記複数の第１の処理手段の内の最上流に位置する第１の処理手段である第１の最上流処理手段が該第２の上流側処理手段側に位置し、該複数の第１の処理手段のうちの最下流に位置する第１の処理手段である第１の最下流処理手段が該第２の下流側処理手段側に位置するように、前記複数の第１の処理手段が予め位置され、
前記第２の上流側処理手段と前記第１の最上流処理手段との間に、前記第２の上流側処理手段の送信先となりかつ前記第１の最上流処理手段の受信先となる第１のインターフェース処理手段と、
前記第１の最下流側処理手段と前記第２の下流処理手段との間に、前記第１の最下流側処理手段の送信先となりかつ前記第２の下流処理手段の受信先となる第２のインターフェース処理手段と、
を備えたデータ処理装置であって、
前記第１のインターフェース処理手段及び前記複数の第１の処理手段は、前記第１のインターフェース処理手段が前記第２の上流側処理手段からデータ受信した場合、データ量を示すメッセージデータを、前記第１のインターフェース処理手段から前記複数の第１の処理手段を順に介して、前記第２のインターフェース処理手段へ送信し、
前記第２のインターフェース処理手段及び前記複数の第１の処理手段は、前記第２のインターフェース処理手段が該メッセージを受信した場合、前記第２のインターフェース処理手段から順に送信要求を前記第１のインターフェース処理手段までし、
前記複数の第１の処理手段及び前記第２のインターフェース処理手段は、前記第１のインターフェース処理手段が前記送信要求された場合、データを前記複数の第１の処理手段及び前記第２のインターフェース処理手段を介して、前記第２の下流側処理手段に送信すると共に、前記複数の第１の処理手段各々は、処理するデータの量が前記予め定められたデータ量でない場合には、処理するデータの量が前記予め定められたデータ量となるまで前記送信要求を前記第１のインターフェース処理手段までする
ことを特徴とするデータ処理装置。
【請求項２】
予め定められたデータ量のデータの第１の送信要求が送信先からされると共に、該第１の送信要求に対応する第２の送信要求を受信先にし、該第２の送信要求に応じて該受信先が送信したデータを該データ量となるまで受信し、該受信したデータに基づいて予め定められた第１の処理を実行した後、データを該送信先に送信する複数の第１の処理手段を備えると共に、該複数の第１の処理手段各々が、データが順に各第１の処理手段により送信されるように、予め設定され、
受信先からデータを受信し、該受信したデータに基づいて予め定められた第２の処理を実行した後、データを送信先に送信する複数の第２の処理手段を備えると共に、該複数の第２の処理手段各々が、データが順に各第２の処理手段により送信されるように、予め設定され、
前記複数の第１の処理手段のうちの特定の第１の処理手段である第１の上流側処理手段と、該第１の上流側処理手段の送信先として予定された第１の処理手段である第１の下流側処理手段と、の間に、前記複数の第２の処理手段の内の最上流に位置する第２の処理手段である第２の最上流処理手段が該第１の上流側処理手段側に位置し、該複数の第２の処理手段のうちの最下流に位置する第２の処理手段である第２の最下流処理手段が該第１の下流側処理手段側に位置するように、前記複数の第２の処理手段が予め位置され、
前記第１の上流側処理手段と前記第２の最上流処理手段との間に、前記第１の上流側処理手段の送信先となりかつ前記第２の最上流処理手段の受信先となる第１のインターフェース処理手段と、
前記第２の最下流側処理手段と前記第１の下流処理手段との間に、前記第２の最下流側処理手段の送信先となりかつ前記第１の下流処理手段の受信先となる第２のインターフェース処理手段と、
を備えたデータ処理装置であって、
前記第２のインターフェース処理手段及び前記複数の第２の処理手段は、前記第１の下流側処理手段から前記第２のインターフェース処理手段が送信要求されると、前記第２のインターフェース処理手段から前記複数の第２の処理手段を順に介して前記第１のインターフェース処理手段まで、データの量を示すメッセージを送信し、
前記第１のインターフェース処理手段は、前記メッセージを受信した場合、前記第１の上流側処理手段に送信要求をし、
前記第１の上流側処理手段は、前記送信要求がされた場合、データを前記第１のインターフェース処理手段に送信し、
前記第１のインターフェース処理手段及び前記複数の第２の処理手段は、前記第１のインターフェース処理手段が前記第１の上流側処理手段からデータを受信した場合、前記第１のインターフェース処理手段から前記複数の第２の処理手段を順に介してデータを前記第１の下流側処理手段に送信すると共に、前記第２の処理手段各々は、処理するデータの量が前記予め定められた量でない場合には、処理するデータの量が前記予め定められたデータ量となるまで順に前記第１のインターフェース処理手段まで前記メッセージを送信する
ことを特徴とするデータ処理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、プル（取り出す）タスク及びプッシュ（入れる）タスクを伴うデータ処理に関する。
【０００２】
【従来の技術】
単一処理環境を用いて多重処理パイプラインをエミュレート（模倣）するシステムにおいて、パイプラインの各セクションは、画像処理ファンクション（関数）等の１つ又は複数の所望のファンクションを実行するインスタンス生成されたファンクション、即ちタスクであり、またこのタスクの状態を自己定義するために十分なデータ構造である。
【０００３】
動作において、ホストアプリケーションが、スキャナ又は画像データファイルからの画像データ等の処理されるべきデータを生データソースから要求すると、データ処理パイプラインがデータソースとホストアプリケーションとの間に形成される。このデータ処理パイプラインは、データソースからの生データを入力し、ホストアプリケーションが使用可能な形式であるようにそのデータを処理し、このデータをホストアプリケーションに提供する。
【０００４】
画像処理パイプラインは、例えば画像処理ライブラリ内のファンクションの１つを呼出すこと及び第１のタスクを形成するために呼出されたこのファンクションをインスタンス生成することにより形成される。第１のタスクは、パイプラインの最上流のセクションとなる。この最上流のパイプラインセクションは、処理されるべきデータ要素をデータソースから取得する。画像処理システムにおいて、データ要素は、画像のラスタ走査の単一走査行であり得る。データソースは、直列又は並列データ信号、又はＲＯＭ、ＲＡＭ又はディスク駆動装置内のディスク等のメモリに格納されたデータから成るブロックを出力するスキャナ、ファクシミリ装置、遠隔コンピュータ、センサ等であってよい。また、データ要素は、第１のパイプラインセクション自体によって直接生成されることも可能である。この後者の場合には、データ要素は、初期化された変数の値、又は第１のパイプラインセクションの状態等から取得されることができる。第１のパイプラインセクションがインスタンス生成されると、ホストアプリケーションの逆方向、即ち上流リンクが第１のパイプラインセクションとして設定される。
【０００５】
次に第２のパイプラインセクションが、第１のパイプラインセクションにより取得されたデータ要素を処理するために通常必要とされる。従って、ホストアプリケーションは、ライブラリ内のファンクションの１つをインスタンス生成することによって別のタスクを生成し、第２のパイプラインセクションを形成する。この第２のパイプラインセクションが生成されると、この第２のパイプラインセクションは第１のパイプラインセクションに自動的にリンクされる。更に、ホストアプリケーションのリンクは、第２のパイプラインセクションにリセットされる。もし他の画像処理オペレーションが必要とされない場合は、ホストアプリケーションのリンクは、処理されたデータを要求するホストアプリケーションの部分と第２のパイプラインセクションとの間で保たれる。
【０００６】
【発明が解決しようとする課題】
パイプライン処理での処理タスクは、通常、データを処理するために最小限の外部制御が必要とされるように、互いに効率的にインターフェースするように設計される。しかしながら、従来より、同類の処理タスクのみが１つの処理目標を達成するために統合されている。この制限は好ましくなく、従って、パイプラインデータ処理に、より広範なフレキシビリティをもたらすための新たな技術が必要である。
【０００７】
【課題を解決するための手段】
本発明は、プッシュタイプのタスクとプルタイプのタスクを有するデータ処理ストリングを伴うデータを処理するための装置及び方法を提供する。プッシュタスクはデータを処理し、この処理の出力をリンクパスに基づいて下流のプッシュタスクにプッシュする（入れる）。他方、プルタスクは、処理のためのデータを取得するために、上流のリンクを介して上流のプルタスクにデータ要求を送信する。
【０００８】
データ処理ストリングは通常、リンクの方向における一貫性を維持するために、全てプッシュタスクか、又は全てプルタスクから構成される。本発明の好ましい実施の形態は、プルタスクのストリングにプッシュタスクを挿入する方法及び装置、及び／又はプッシュタスクのストリングにプルタスクを挿入する方法及び装置を提供する。この挿入されたプッシュ及びプルタスクは、順方向及び逆方向のメッセージリンクにより向上され、インターフェースタスクがプッシュ又はプルタスクのストリングにそれぞれ挿入されたプル又はプッシュタスク間をインターフェースするために提供される。
【０００９】
プルタスクがプッシュタスクストリングに挿入されると、第１のインターフェースタスクは上流のプッシュタスクと挿入されたプルタスクとの間に配置され、第２のインターフェースは挿入されたプルタスクと下流のプッシュタスクとの間に配置される。上流のプッシュタスクが第１のインターフェースタスクにデータをプッシュすると、第１のインターフェースタスクは、下流の挿入されたプルタスクにデータ量を示す順方向メッセージを呼出す。また、連続するプルタスクのそれぞれは、情報が第２のインターフェースタスクに伝播するまで、利用可能なデータ量を示す順方向メッセージを生成する。次に第２のインターフェースタスクがデータ要求を生成し、このデータ要求を挿入されたプルタスクを介して第１のインターフェースタスクまで遡って伝播する。第１のインターフェースタスクは、第２のインターフェースタスクが処理されたデータを受信し、この処理されたデータを下流のプッシュタスクにプッシュするまで、データを下流に送信することにより応答する。
【００１０】
プッシュタスクがプルタスクのストリングに挿入されると、第３のインターフェースタスクが上流のプルタスクと挿入されたプッシュタスクとの間に挿入され、第４のインターフェースタスクが挿入されたプッシュタスクと下流のプルタスクとの間に配置される。下流のプルタスクが第４のインターフェースタスクにデータ要求を送信すると、第４のインターフェースタスクは逆方向メッセージを上流の挿入されたプルタスクに送信する。逆方向メッセージは、逆方向メッセージが第３のインターフェースタスクに送信されるまで、挿入されたプルタスクを介して伝播される。第３のインターフェースタスクは、上流のプルタスクへデータ要求を送信することにより応答し、これは結果として第１のプルタスクがデータベースからデータをプルする（取り出す）ことをもたらす。上流のプルタスクがデータベースからのデータを処理し、このデータを第３のインターフェースタスクに戻すと、第３のインターフェースタスクはこのデータを挿入されたプッシュタスクにプッシュし、これは結果としてデータが第４のインターフェースタスクにプッシュされることをもたらす。第４のインターフェースタスクが、挿入されたプッシュタスクからプッシュされたデータを受信すると、このデータは、そもそもこのデータを要求した下流のプルタスクに戻される。
【００１１】
上記の観点から、第１、第２、第３及び第４のインターフェースタスク、並びに順方向メッセージ及び逆方向メッセージリンクは、プッシュタスクがプルタスクのストリングに挿入され、プルタスクがプッシュタスクのストリングに挿入されることを可能にする。
【００１２】
【発明の実施の形態】
単一環境でのファンクションは、プルタイプのタスク又はプッシュタイプのタスクとしてインスタンス生成され得る。プルタスクは、上流のリンクにより処理ストリングを形成する。データが処理を要求されると、プルタスクは上流のプルタスクにデータ要求を発行する。このデータ要求は、要求されたデータが上流のプルタスクにより送付されるまでアクティブなままである。従って、プルタスクのパイプラインにおいて、パイプラインの出力を受信するホストアプリケーションは、「最後の」プルタスクからデータを要求することから開始され、データ要求はパイプラインの第１のプルタスクまで伝播される。この第１のプルタスクは次に、要求されたデータを例えばデータベース等のデータソースから取り出す。従って、プルタスク処理ストリング即ちパイプラインにおいて、データ要求の方向は上流であり、データフローの方向は下流である。
【００１３】
プッシュタスク処理ストリング即ちパイプラインでは、データはプッシュタスクから、リンクされた下流のプッシュタスクに「プッシュされる」ので、データ要求は存在しない。ホストアプリケーションは、パイプラインの第１のプッシュタスクにデータをプッシュすることにより開始される。データは処理され、出力データが最後のプッシュタスクによりパイプラインの外にプッシュされるまで、リンクに基づき連続的に下流にプッシュされる。従って、プッシュタスクでは、リンクの方向及びデータフローの方向は共に下流である。
【００１４】
データは、標準の単位サイズでプル及びプッシュタスクにより処理される。例えば、デジタルカメラ、プリンタ、スキャナ及びファクシミリ装置等の装置での画像処理では、単位サイズは行であり得る。従って、プルタスクは、１度に１行のデータを上流のプルタスクから要求し得る。特定の処理のために複数の行が必要な場合は、複数のデータ要求が発行され、データは必要な行数が受信されるまでメモリにバッファリング（一時蓄積）される。プッシュタスクのために同様のメモリが必要とされ得る。上流のプッシュタスクからプッシュされたデータは、関連処理が継続されるのに十分なデータが受信されるまで、メモリにバッファリングされる。
【００１５】
例えば、プル又はプッシュタスクは、画像データを２対１のファクタで縮小し得る。従って、１行の出力をもたらすための処理が実行される前に、２つの行が必要とされ得る。プル又はプッシュタスクのパイプラインにおいて、あらゆるタスクは、処理が開始される前に複数の入力単位を必要とし得る。従って、多数の上流のプル及び下流のプッシュが、データが最終的に最後のタスクにより出力される前に発生し得る。
【００１６】
例えば、図１はプルタスク２０２から２１４を用いたデータ処理のブロック図２００を示す。ブロック図２００は、各処理ストリングが２つの直列に接続されたプルタスクを含む、３つの処理ストリングを有する。例えば、第１のストリングは、プルタスク２０２及び２０４を含み、データパス２２０及び２２２とリンクパス２４０及び２４２とを有する。第２のストリングは、プルタスク２０６及び２０８を含み、データパス２２６及び２２８とリンクパス２４６及び２４８とを有する。そして第３のストリングは、プルタスク２１０及び２１２を含み、データパス２３２及び２３４とリンクパス２５２及び２５４とを有する。
【００１７】
プルタスクの３つのストリングは、データパス２２４、２３０及び２３６とリンクパス２４４、２５０及び２５６とを介して、（最後のプルタスクである）組合せプルタスク２１４に連結される。組合せプルタスク２１４は、アプリケーション、物理装置又はそれ自体のファンクションを実行する例えば他のプルタスク２０２から２１２に類似の別のプルタスクであってよい。組合せプルタスク２１４が別のプルタスクである場合、組合せプルタスク２１４へ入力されるリンクパス（図示せず）が存在するであろう。組合せプルタスク２１４は、データパス２３８を介して出力される出力データを生成する。
【００１８】
ブロック図２００は、カラーデータを処理するためのプロセスを表し得、ストリングのそれぞれは１種類の色を処理し、組合せプルタスク２１４は３色全てを出力される最終画像に結合する。組合せプルタスク２１４が１度に１行の画像データを処理すると仮定すると、現在の行の処理が完了すると、プルタスク２１４は次の行のデータのためにリンクパス２４４、２５０及び２５６を介して上流のプルタスク２０４、２０８及び２１２からデータを要求し得る。それぞれのデータ要求を受信すると、プルタスク２０４、２０８及び２１２のそれぞれは、プルタスク２１４により要求されたデータの行を生成するために必要とされるデータのために、更に上流のプルタスク２０２、２０６及び２１０のそれぞれからリンクパス２４２、２４８及び２５４を介してデータを要求する。
【００１９】
プルタスク２０４、２０８及び２１２からのデータ要求に応じて、プルタスク２０２、２０６及び２１０もまた、それら自体よりも上流の更に別のプルタスクにそれぞれリンクパス２４０、２４６及び２５２を介してデータ要求を発行する。これは、第１のプルタスクが、それぞれの下流のプルタスクからデータ要求を受信するまで続けられる。第１のプルタスクは、そのようなデータが入手／利用可能な場合にデータベースからデータを取り出す。データベースからデータが受信されると、第１のプルタスクはこのデータを処理し、その出力をそれぞれの下流のプルタスクに戻す。下流のプルタスクはこのデータを更に処理し、更に下流のプルタスクに出力を戻し、このデータがプルタスクストリングに渡され、組合せプルタスク２１４に到達するまでこれは繰り返される。プルタスク２１４は、３つの独立したストリングから受信されたデータ全てを結合し、それに応じてデータパス２３８を介して出力されるようにデータを処理する。従って、リンクパスの方向は矢印２６０によって示されるように上流である一方、データフローの方向は矢印２６２によって示されるように下流である。
【００２０】
図２は、一般的なプルタスク１０２のブロック図をより詳細に示す。プルタスク１０２は、上流リンク１０６及びデータバッファ１０８を含む。上述されたように、上流のリンク１０６は、データが処理される必要があるときに、指定された上流のタスクにデータ要求を送信する能力を提供する。データバッファ１０８は、受信されたデータを、プルタスク処理を完了するために十分なデータ（例えば、数行）が受信されるまで記憶する。データバッファ１０８は、プルタスク処理が受信された各行ごとに処理を開始し得る場合には不要である。
【００２１】
上述されたように、プルタスク２０２から２１４は単一処理環境でインスタンス生成される。データが１つのプルタスクから別のプルタスクへ渡されると、このデータは実際にはメモリに記憶され、このデータのアドレスへのポインタが１つのインスタンス生成されたプルタスクから次のプルタスクへ渡される。従って、特定のプルタスクがデータの１ユニット（例えば、１行）を超えるデータを要求する場合、データバッファ（メモリ空間）はこの特定のプルタスクのために割り当てられねばならない。
【００２２】
図３は、プルタスク２０２、２０４及び２１４を含む第１の処理ストリングのための単一コントローラ処理環境の処理スタック４００の例を示す。処理スタック４００は、単一コントローラを制御した（処理スタック４００にプッシュされた）タスクのシーケンスを記録する。このシーケンスは、処理環境の適切な制御を維持するためにタスクを逆順に遡られねばならない。処理スタック４００に実際に配置されるデータは、命令カウンタであってよく、恐らく、例えば処理スタック４００からデータがポッピングされる（取り出される）と、制御がそのタスクに戻るように、タスクに対応するコントローラのマシン状態であり得る。
【００２３】
図１に示されるように、データ要求のシーケンスは、リンクパス２４４を介してプルタスク２０４からデータを要求するプルタスク２１４から開始される。プルタスク２１４がこのようなデータ要求を行なうと、データ要求ＤＲ（２４４）は処理スタック４００にプッシュされ、結果として処理スタック状態４０４となる。プルタスク２１４からのデータ要求に応じて、制御はプルタスク２０４に渡され、プルタスク２０４はリンクパス２４２を介してプルタスク２０２にデータ要求を行ない、データ要求ＤＲ（２４２）は処理スタック４００にプッシュされ、結果として処理スタック状態４０６となり、制御はプルタスク２０２に渡される。
【００２４】
プルタスク２０２が第１のプルタスクだと仮定すると、リンクパス２４０は、処理のためにデータが蓄積されるデータベース等のデータソースを指している。従って、プルタスク２０２は、リンクパス２４０を介してデータベースにデータ要求を送信し、データ要求ＤＲ（２４０）は処理スタック４００にプッシュされ、結果として処理スタック状態４０８となる。この時点で、制御はデータベースに渡され、処理スタック４００は、リンクパス２４０、２４２及び２４４に対応する３つのデータ要求をこの順序で含む。
【００２５】
プルタスク２０２により発行されたデータ要求に応じてデータベースがデータＤ（２２０）をデータパス２２０に沿って戻すと、データ要求ＤＲ（２４０）は処理スタック４００からポッピングされ、結果として処理スタック状態４１０をもたらし、制御はプルタスク２０２に戻される。プルタスク２０２はデータベースから受信したこのデータを処理し、その結果であるＤ（２２２）をデータパス２２２に沿ってプルタスク２０４に出力し、データ要求ＤＲ（２４２）は処理スタック状態４１２により示されるように処理スタック４００からポッピングされ、そして制御はプルタスク２０４に戻される。プルタスク２０４は次に、プルタスク２０２から受信されたデータを処理し、その結果であるＤ（２２４）をデータパス２２４に沿って組合せプルタスク２１４に出力する。組合せプルタスク２１４はデータ要求ＤＲ（２４４）をポッピングし、結果として処理スタック状態４１４により示されるように処理スタック４００を空にし、そして制御はシーケンスが開始された組合せプルタスク２１４に戻される。従って、リンクパス２４４、２４２及び２４０に沿って成されるデータ要求は、データ要求ＤＲ（２４４、２４２及び２４０）を処理スタック４００にプッシュし、データパス２２０、２２２及び２２４を介して戻されるデータは、データ要求ＤＲ（２４４、２４２及び２４０）を処理スタック４００から取り出す。制御は、組合せプルタスク２１４からプルタスク２０４へ、プルタスク２０２へ、データベースへと渡され、そしてプルタスク２０２へ、プッシュタスク２０４へと戻され、最終的に組合せプルタスク２１４へと戻される。
【００２６】
図４は、プルタスク２１４への出力がデータパス２２４を介して生成される前に、プルタスク２０４が２行のデータを必要とする状況を示す。処理スタック状態４０４から４１２は、図３に示されるそれらと同一である。しかしながら、データがデータパス２２２を介してプルタスク２０２から受信された後も、プルタスク２０４は処理を開始するために十分なデータを保有していない。従って、プルタスク２０４は、処理を開始するために必要な追加データをリンクパス２４２を介してプルタスク２０２から再度要求する。従って、ＤＲ（２４２）は、処理スタック状態４１６により示されるように再び処理スタック４００にプッシュされる。プルスタック２０２は、リンクパス２４０を介してデータベースからの追加データのためのデータ要求ＤＲ（２４０）を送信することにより応答し、これは処理スタック状態４１８により表される。プルタスク２０２がデータパス２２０を介してデータベースからデータＤ（２２０）を受信すると、データ要求ＤＲ（２４０）は処理スタック状態４２０に示されるようにスタックから取り出され、プルタスク２０２がそのデータＤ（２２２）をプルタスク２０４に出力すると、データ要求ＤＲ（２４２）もまた、処理スタック状態４２２に示されるように処理スタック４００から取り出される。この時点で、プルタスク２０４は処理を開始するために十分なデータを有する。プルタスク２０４の出力がデータパス２２４を介してプルタスク２１４に送信されると、残っているデータ要求ＤＲ（２４４）が処理スタック４００から取り出され、処理スタック状態４２４に示されるようにスタックを空にする。
【００２７】
図５は、プッシュタスク３０２から３１４から成る３つのストリングを有するプロセス３００のブロック図を示す。第１のプッシュタスク３０２は、ある上流の処理からデータを受信し、このデータを処理し、そしてこの処理の結果をデータパス３２２、３２８及び３３４を介して下流のプッシュタスク３０４、３０８及び３１２にプッシュする分岐プッシュタスクである。プッシュタスク３０２は、リンクパス３４０、３４６及び３５２を介して下流のプッシュタスクを識別する。データが下流のプッシュタスクにプッシュされると、プログラムカウンター等の上流のプッシュタスクを制御するデータもまた処理スタック４００にプッシュされる。このことは、リンクを処理スタック４００に「プッシュすること」に関する以下の記載で説明される。プッシュタスク３０４、３０８及び３１２はプッシュタスク３０２から受信されたデータを処理し、これらの処理結果をそれぞれデータパス３２４、３３０及び３３６を介して更に下流のプッシュタスク３０６、３１０及び３１４にプッシュする。プッシュタスク３０６、３１０及び３１４はそれぞれの処理結果を、それぞれリンクパス３４４、３５０及び３５６により識別される更に下流のプッシュタスク、出力バッファ及び／又はデバイスに出力する。従って、プッシュタスクストリングでは、矢印３６０により示されるリンクパスの方向は、矢印３６２により示されるデータフローの方向と等しい。
【００２８】
例えば、分岐プッシュタスク３０２がリンクパス３４０を介してプッシュタスク３０４にデータをプッシュすると、リンク３４０Ｌ（３４０）は処理スタック４００にプッシュされる。データが最終的に処理ストリングを介してプッシュされると、処理ストリング又はパイプラインの最後でアプリケーション又は装置は、処理スタック４００から最後のリンクをポッピングし、制御を上流のプッシュタスクに戻す。この上流のプッシュタスクは次に、次のリンクをポッピングし、このリンクは制御を次の上流のプッシュタスクに戻す。これは制御が分岐プッシュタスク３０２から上流のアプリケーション又は装置に戻るまで続けられる。
【００２９】
図６は、一般的なプッシュタスク１１２のブロック図を示す。プッシュタスク１１２は、データバッファ１１６、下流のリンク１１８、入力データパス１１４、及び出力データパス１２０を有する。データバッファ１１６は、上流のプッシュタスクからデータを受信し、プッシュタスク処理を実行するために十分なデータが受信されるまでこのデータを記憶する。プッシュタスク１１２が処理を完了すると、この出力は下流のリンクパス１１８により示される下流のプッシュタスクにプッシュされる。
【００３０】
上述されたように、データ処理ストリングは、リンクの方向及びデータフローの方向がデータ処理ストリングのタスク全てを通じて一貫するように、全てプルタイプのタスクか、又は全てプッシュタイプのタスクから構成される。本発明の好ましい実施の形態は、プッシュ又はプルタスクに些細な変更をもたらすこと及びインターフェースモジュールを追加することのみにより、プッシュタスクデータ処理ストリングにプルタスクを挿入する能力、又はプルタスクデータ処理ストリングにプッシュタスクを挿入する能力を提供する。
【００３１】
図７は、プッシュタスク５３０、５３２及び５４０のストリングに挿入されたプルタスク５３６及び５３８を示す。また図７は、プッシュタスクのプルタスクへの、そしてプルタスクのプッシュタスクへのインターフェースをそれぞれもたらす２つのインターフェースタスク５４２及び５４４を示す。
【００３２】
図８から１０は、インターフェースタスク５４２と５４４及びプッシュタスクストリングに挿入される一般的なプルタスク５３４のブロック図を示す。図８において、インターフェースタスク５４２はスマートバッファ６０２及び下流のプルタスクとリンクする順方向メッセージリンク６０４を含む。スマートバッファ６０２は上流のプッシュタスク５３２からプッシュされているデータを収集し、例えば上流のプッシュタスク５３２からプッシュされ、プルタスク５３６によりプルされるデータ量に基づきバッファサイズを調整する。データがデータパス５０６を介して上流のプッシュタスク５３２から受信されると、インターフェースタスク５４２は順方向リンクパス５２２を介して下流のプルタスク５３６に順方向メッセージを送信し、これは処理するためにプルタスク５３６が利用可能なデータ量（例えば、行数）を示す。この順方向メッセージＦＭ（５２２）は、処理スタック４００にプッシュされ、制御はプルタスク５３６に渡される。制御は、データ要求がプルタスク５３６から受信されるか、又は順方向メッセージＦＭ（５２２）が戻されるまで、インターフェースタスク５４２へは渡されない。このようなデータ要求が受信されると、制御はインターフェースタスク５４２に渡され、インターフェースタスク５４２は要求されたデータをデータパス５０８を介して下流のプルタスク５３６に出力する。
【００３３】
図９は、プルタスク５３４のブロック図を示している。プルタスク５３４は、上流リンク６１０及び順方向メッセージリンク６１２を含む。以下に、図７のプルタスク５３６を例として用いて、プルタスク５３４を説明する。プルタスク５３６は、インタフェースタスク５４２からの順方向メッセージを受取ると、プルタスク処理の実行を開始するのに十分なデータが存在するか否かを決定する。データが不十分な場合は、プルタスク５３６は、単に、制御を、順方向メッセージＦＭ（５２２）を処理スタック４００から取出すインタフェースタスク５４２へと戻す。しかしながら、インタフェースタスク５４２から受取られた順方向メッセージによって示されるデータ量が、プルタスク処理を実行するのに十分な数のデータ（例えば１行）を示す場合は、プルタスク５３６は、処理のためにプルタスク５３６がプルタスク５３８に供給可能な行数を示すそれ自体の順方向メッセージを、順方向リンクパス５２４を介して下流のプルタスク５３８へと送る。この順方向メッセージＦＭ（５２６）は処理スタック４００にプッシュされ、制御はインタフェースタスク５４４に渡される。プルタスク５３８は、プルタスク５３６によって示される行数が、プルタスク５３８の処理を実行するのに十分か否かを決定する。プルタスク５３６によって示される行数がプルタスク５３８を実行するのに十分な場合は、プルタスク５３８は下流のインタフェースタスク５４４に、プルタスク５３８が生成可能な行数を示す順方向メッセージを送る。
【００３４】
図１０に示されるように、インタフェースタスク５４４は、上流リンク６０６及び下流リンク６０８を含む。上流リンク６０６は、インタフェースタスク５４４が上流のプルタスクからデータをプルするのを可能にし、一方、下流リンク６０８は、インタフェースタスク５４４が下流のプッシュタスクにデータをプッシュするのを可能にする。
【００３５】
図７に戻ると、インタフェースタスク５４４は、プルタスク５３８からの順方向メッセージＦＭ（５２６）を受取ると、リンクパス５２９を介してプルタスク５３８に、プルタスク５３８の順方向メッセージＦＭ（５２６）によって示される行数（例えば１行）を要求するデータ要求ＤＲ（５２９）を送る。データ要求ＤＲ（５２９）は処理スタック４００へとプッシュされ、制御はプルタスク５３８に渡される。プルタスク５３８は、データ要求ＤＲ（５２９）を受取ると、プルタスク５３６からのデータを要求するデータ要求ＤＲ（５３１）を、リンク５３１を介してプルタスク５３６に送る。次いで、プルタスク５３６は、データがスマートバッファ６０２からプルタスク５３６に転送されるために、リンクパス５３３を介してインタフェースタスク５４２にデータ要求ＤＲ（５３３）を送る。上記のシーケンス又はイベントの後、ＤＲ（５２９）、ＤＲ（５３１）、及びＤＲ（５３３）は、全て処理スタック４００へとプッシュされ、制御はインタフェースタスク５４４並びにプルタスク５３８及び５３６を介してインタフェースタスク５４２へと渡される。
【００３６】
インタフェースタスク５４２は、要求されたデータを、データパス５０８を介してプルタスク５３６に送ることによって、データ要求ＤＲ（５３３）に応答し、プルタスク５３６が処理スタック４００からデータ要求ＤＲ（５３３）を取出し、制御はプルタスク５３６に渡される。プルタスク５３６の処理が実行可能となる前にプルタスク５３６が更なるデータ（例えば複数の行）を必要とする場合は、プルタスク５３６にプルタスク処理の実行を開始するのに十分な量のデータが転送されるまで、プルタスク５３８がインタフェースタスク５４２に複数のデータ要求を行う。プルタスク５３６は処理済データをデータパス５１０を介してプルタスク５３８に出力し、プルタスク５３８が処理スタック４００からデータ要求ＤＲ（５２９）を取出し、制御はプルタスク５３８に渡される。追加データが必要な場合は、プルタスク５３８は再びリンクパス５３１を介してプルタスク５３６にデータ要求を発し、処理が繰返される。プルタスク５３８は、十分なデータを受取るとプルタスク処理を実行し、データパス５１２を介してインタフェースタスク５４４に処理済データを出力し、インタフェースタスク５４４が処理スタック４００からデータ要求ＤＲ（５２９）を取出し、制御はインタフェースタスク５４４に渡される。
【００３７】
インタフェースタスク５４４は、データを受取ると、データをデータパス５２４を介してプッシュタスク５４０にプッシュし、リンクＬ（５２８）を処理スタック４００にプッシュする。プッシュタスク５４０はデータを更に下流へと、例えば、処理スタック４００から上流リンクを取出す処理ストリングの末端のアプリケーションに到達するまでプッシュし、制御はインタフェースタスク５４４に到達するまで上流へと流れる。次に、インタフェースタスク５４４は処理スタック４００から順方向メッセージＦＭ（５２６）を取出して制御をプルタスク５３８に移動し、次に、制御が処理ストリングの冒頭のアプリケーションに戻るまで、処理スタック４００等から順方向メッセージＦＭ（５２４）が取出される。
【００３８】
図１１は、図７に示されているデータ処理ストリングを実行してもよい例示的なプロセッサ６５０のブロック図を示している。プロセッサ６５０は、コントローラ６５１、メモリ６５２、データベース６５４、及び入出力装置インタフェース６５６を含む。上記の構成要素は信号バス６５８を介して相互に接続されている。
【００３９】
プロセッサ６５０は、例えば、プリンタ、デジタルカメラ、スキャナ、ファクシミリ装置、ＣＤＲＯＭアーカイブシステム等のためのデータプロセッサであってよい。プロセッサ６５０は、プリントやプリントモード設定等のコマンドを受取るために、入出力装置インタフェース６５６を介してオペレータとのインタフェースをしてもよい。他のプロセッサからの入力データも入出力装置インタフェース６５６を介してデータベース６５４に受取られてもよい。例えば、プロセッサ６５０がプリンタプロセッサである場合は、入出力装置インタフェース６５６は、プリンタを用いてプリントするために情報をデータベース６５４にダウンロードするコンピュータに接続されていてもよい。
【００４０】
データベース６５４にデータが受取られ、コントローラ６５１が十分な量のデータ（例えば１ページ分のデータ）が受取られたと決定したら、コントローラ６５１は、データベース６５４に記憶されているデータを、信号パス５０２を介してプッシュタスク５３０に１度に１行ずつプッシュすることによって、図７のデータ処理オペレーションを開始してもよい。前述したように、データは物理的に移動される必要はなく、コントローラ６５１が単に、プッシュタスク５３０に、データベース６５４内のデータのアドレスを示すポインタを送ってもよい。データがプッシュタスク５３０へとプッシュされたら、図７に示されているデータ処理ストリングを実行するために、制御はデータ処理ストリング制御プログラムに転送されてもよい。
【００４１】
上述のように、コントローラ６５１は、データ処理ストリングの制御を維持するために処理スタック４００を維持する。従って、順方向メッセージ又はデータ要求が生成されると、コントローラ６５１は、個々の順方向メッセージ又はデータ要求を処理スタック４００にプッシュする。リターンが生成されると、コントローラ６５１は、処理スタックから個々の順方向メッセージ又はデータ要求を取出す。
【００４２】
図１２は、プッシュタスクのストリングにプルタスクが挿入された例のフロー図を示している。このフロー図は、複数のデータプルに関係する順方向メッセージの取出し及び上流タスクへの制御のリターンに関係する、処理スタック機能だけを示している。他の処理スタック機能は上記に述べられており、議論を簡単にするためにここでは詳細を述べない。ステップＳ１０００では、コントローラ６５１は、プッシュタスク５３０及び５３２へとプッシュされたデータを受取ることによって処理を開始し、ステップＳ１００２に進む（プッシュタスク５３０及び５３２は単一プッシュタスクとして扱われる）。ステップＳ１００２では、コントローラ６５１はプッシュタスク５３０及び５３２の処理を実行し、データをインタフェースタスク５４２にプッシュし、ステップＳ１００４に進む。ステップＳ１００４では、コントローラ６５１は、プルタスク５３６のような後続のプルタスクへの順方向メッセージを呼出すことによってインタフェースタスク５４２（I1）の処理を行い、ステップＳ１００６に進む。ステップＳ１００６では、コントローラ６５１は、順方向メッセージ内に示されているデータ量がプルタスク５３６を開始するのに十分か否かを評価する。データが不十分な場合は、コントローラ６５１はステップＳ１００８に進み、そうでない場合は、コントローラ６５１はステップＳ１０１０に進む。ステップＳ１００８では、コントローラは順方向メッセージを取出し、制御をインタフェースタスク５４２に戻し、ステップＳ１００４に進む。ステップＳ１０１０では、コントローラ６５１は次の後続プルタスクへの順方向メッセージを呼出し、ステップＳ１０１２に進む。ステップＳ１０１２では、コントローラ６５１は、順方向メッセージが次の後続プルタスク（例えばプルタスク５３８）の実行開始のための十分なデータを示しているか否かを評価する。データ量が不十分な場合は、コントローラ６５１はステップＳ１０１４に進み、そうでない場合は、コントローラはステップＳ１０２２に進む（この、次の後続プルタスクが最終プルタスクであるとする）。ステップＳ１０１４では、コントローラ６５１は上流の順方向メッセージを取出し、制御を上流のタスクに戻し、ステップＳ１００８に進む。
【００４３】
ステップＳ１０２２では、コントローラ６５１は最終プルタスクからインタフェースタスク５４４（I2）への順方向メッセージを呼出し、ステップＳ１０２４に進む。ステップＳ１０２４では、コントローラ６５１は、インタフェースタスク５４４から最終プルタスクへのデータ要求を送り、データ要求を処理スタック４００にプッシュし、ステップＳ１０２６に進む。ステップＳ１０２６では、コントローラ６５１は次の上流のプルタスクにデータ要求を送り、データ要求を処理スタック４００にプッシュし、ステップＳ１０２８に進む。ステップＳ１０２８では、コントローラ６５１はインタフェースタスク５４２からデータをプルし、ステップＳ１０３０に進む。ステップＳ１０３０では、コントローラはデータを下流のプルタスクに戻すとともに、データ要求を取出し、制御を下流のプルタスクに渡し、ステップＳ１０３２に進む。
【００４４】
ステップＳ１０３２では、コントローラ６５１は、下流のプルタスクの処理を実行するのに十分なデータがあるか否かを決定する。更にデータが必要な場合は、コントローラ６５１はステップＳ１０２８に戻り、そうでない場合は、コントローラはステップＳ１０３４に進む。ステップＳ１０３４では、コントローラは、データをインタフェースタスク５４４に戻すとともに、対応するデータ要求を取出し、制御をインタフェースタスク５４４に渡し、ステップＳ１０４０に進む（この下流のプルタスクが最終プルタスクであるとする）。ステップＳ１０４０では、コントローラ６５１は、データを下流のプッシュタスク（例えばプッシュタスク５４０）にプッシュし、ステップＳ１０４２に進み、データパイプライン処理を終了する。
【００４５】
図１２のフロー図には示されていないが、最終タスクに続くアプリケーションが処理スタック４００からリンクを取出し、制御を最終プッシュタスクに戻す。リンクは、インタフェースタスク５４４に到達するまで、上流のプッシュタスクを介して続けて取出される。インタフェースタスク５４４は、上流のプルタスクから順方向メッセージを取出し、次いで上流のプルタスクは、インタフェースタスク５４２に到達するまで、処理スタック４００から次の順方向メッセージを取出す。インタフェースタスク５４２は上流のプッシュタスクからリンクを取出し、その上流のプッシュタスクは、データパイプライン処理の冒頭のアプリケーションに到達するまで、（さらに）上流のプッシュタスクからリンクを取出す。
【００４６】
点線で示されるように、ボックス１０５０で囲まれているステップは全て、インタフェースタスク５４２と５４４との間に配置された中間のプルタスクと関連している。これらのステップは、インタフェースタスク５４２と５４４との間に挿入された追加の各プルタスクについて１回繰返されてもよい。５４２と５４４との間にプルタスクが１つしかない場合は、ボックス１０５０内のプルタスクは全て消去され、最終プルタスクだけが残る。
【００４７】
図１３は、プルタスクのストリングにプッシュタスクを埋め込んだデータパイプラインを示している。このデータパイプラインは、プルタスク７３４、７３６、及び７４６を含む。２つのプッシュタスク７４０及び７４２が、このプルタスクのストリングに挿入されており、インタフェースタスク７３８及び７４４が、プルタスクをプッシュタスクから隔てている。
【００４８】
図１４から１６は、インタフェースタスク７３８及び７４４、並びに一般的なプッシュタスク７３９のブロック図を示している。図１４は、上流リンク８０２及び下流リンク８０４を含むインタフェースタスク７３８を示している。上流リンク８０２は７３８が上流のプルタスクからデータをプルするのを可能にし、一方、下流リンク８０４はインタフェースタスク７３８が下流のプッシュタスクにデータをプッシュするのを可能にする。図１５は、プッシュタスク７３９のブロック図を示している（プッシュタスク７３９は、インタフェースタスク７３８と７４４との間に配置された任意のプッシュタスクを表わす）。プッシュタスク７３９は、プッシュタスク７３９が上流のタスクにデータ要求を示すのを可能にする逆方向メッセージリンク８０８と、データバッファ８１０と、下流リンク８１２とを含む。図１６は、上流のタスクにデータ要求を示す逆方向メッセージ８０６を含むインタフェースタスク７４４を示している。
【００４９】
図１３に戻ると、プルタスク７４６は、更にデータを処理できる状態であるとき、リンクパス７２６を介してインタフェースタスク７４４にデータ要求を送る。プルタスク７４６は、下流のプルタスクからのデータ要求を受取っているか、又は出力装置からの更なるデータを要求する信号を受取っているかの、いずれでもよい。例えば、プルタスク７４６は、下流のプリント装置に応答して、インタフェースタスク７４４からの１行のデータを要求してもよい。インタフェースタスク７４４は、データ要求を受取ると、リンクパス７２５を介して上流のプッシュタスク７４２に、１行のデータが必要だという逆方向メッセージを発する。逆方向メッセージは処理スタック４００へとプッシュされ、制御は上流のプッシュタスク７４２に渡される。逆方向メッセージは、順方向メッセージのように複数の行を含むことはない。逆方向メッセージは、単に、下流の処理が更にデータを必要としていることを示すだけである。プッシュタスク７４２は、リンクパス７２４を介して次の上流プッシュタスク７４０に逆方向メッセージを送ることによって応答し、次いで上流プッシュタスク７４０がリンクパス７２３を介してインタフェースタスク７３８に逆方向メッセージを送る。従って、プルタスク７４６が発したデータ要求は、逆方向メッセージを介してインタフェースタスク７３８に伝えられ、処理スタック４００内に逆方向メッセージのシーケンスを残す。
【００５０】
インタフェースタスク７３８は、逆方向メッセージを受取ると、上流プルタスク７３６からリンクパス７２２を介してデータをプルし、次いで、プルタスク７３６が次の上流プルタスク７３４からリンクパス７２０を介してデータをプルする。プルタスク７３４が最初のプルタスクであるとすると、プルタスク７３４はリンクパス７１８を介してデータベースにデータ要求を送り、データパス７０２を介してデータを受取る。プルタスク７３４は、データパス７０２から処理するための十分なデータが受取られるまで、データベースにデータ要求を送り続け、次に、データパス７０４を介して下流のプルタスク７３６に処理出力を送る。また、プルタスク７３６は、対応するプルタスク処理が実行されてもいいように、上流のプルタスク７３４から十分な量の入力データが受取られるまで待ち、出力がデータパス７０６を介してインタフェースタスク７３８に送られる。
【００５１】
インタフェースタスク７３８がプルタスク７３６からデータを受取ると、そのデータは、リンクパス７２８で識別されるように、データパス７０８を介して下流のプッシュタスク７４０へとプッシュされる。リンク７２８は処理スタック４００へとプッシュされ、制御は下流のプッシュタスクに渡される。プッシュタスク７４０はインタフェースタスク７３８から受取ったデータを記憶する。更にデータが必要な場合は、プッシュタスク７４０は、プッシュタスク７４０の処理を実行するのに十分なデータを受取るまで、再び逆方向メッセージを送る。十分なデータが使用可能な場合は、プッシュタスク７４０はプッシュタスク処理を実行し、リンクパス７３０で識別されるように、データパス７１０を介して下流のプッシュタスク７４２に出力をプッシュし、リンク７３０を処理スタック４００にプッシュし、制御をプッシュタスク７４２に渡す。プッシュタスク７４２も、処理のために十分な量のデータが使用可能か否かを決定し、使用可能な場合はプッシュタスク処理を実行し、リンクパス７３２で識別されるように、データパス７１２を介してインタフェースタスク７４４に出力をプッシュし、リンク７３２を処理スタック４００にプッシュし、インタフェースタスク７４４に制御を渡す。
【００５２】
インタフェースタスク７４４がプッシュタスク７４２からのデータを受取ると、リンク７３２、７３０、及び７２８が続けて処理スタック４００から戻されて取出される。インタフェースタスク７３８が制御を獲得すると、逆方向メッセージ７２３、７２４、及び７２５が処理スタック４００から続けて戻されて取出され、制御はインタフェースタスク７４４に戻る。
【００５３】
インタフェースタスク７４４が制御を獲得すると、データはプルタスク７４６に進められ、先にリンクパス７２６を介して送られたデータ要求が取出され、制御はプルタスク７４６に渡される。プルタスク７４６が追加のデータ（別の行のデータ）を必要とする場合は、プルタスク７４６はリンクパス７２６を介してもう１つデータ要求を送り、プルタスク７４６がプルタスク処理を実行して処理済データをデータパス７１６を介して、例えば、下流のタスク又はパイプライン処理の末端の装置に出力するのに十分なデータを受取るまで、処理が繰返される。このように、逆方向メッセージは、プルタスク７４６のデータ要求がプルタスク７３６に伝わるのを可能にし、プッシュタスク７４０及び７４２の上流リンクの不足を克服する。
【００５４】
図１７は、図１３に示されているデータパイプラインのためにコントローラ６５１によって実行される処理のフロー図を示している。ステップＳ２０００では、コントローラ６５１は、下流のプルタスク７４６からインタフェースタスク７４４に向けられたデータ要求を受取り、ステップＳ２００２に進む。ステップＳ２００２では、コントローラ６５１は、インタフェースタスク７４４から上流のプッシュタスク７４２への逆方向メッセージを呼出し、ステップＳ２００４に進む。ステップＳ２００４では、コントローラ６５１は、プッシュタスク７４２から次の上流のプッシュタスク（例えばプッシュタスク７４０）への逆方向メッセージを呼出し、ステップＳ２００６に進む。ステップＳ２００６では、コントローラ６５１は、次の上流のプッシュタスクからインタフェースタスク７３８への逆方向メッセージを呼出し、ステップＳ２００８に進む。ステップＳ２００８では、インタフェースタスク７３８が上流のプルタスク７３６にデータ要求を送り、ステップＳ２０１０に進む。ステップＳ２０１０では、コントローラ６５１が上流のプルタスク７３６から次の上流のプルタスク（例えばプルタスク７３４）にデータ要求を送り、ステップＳ２０１２に進む。ステップＳ２０１２では、コントローラ６５１は、データベースのようなデータソースからデータをプルし（例えば、上流のプルタスク７３４が最初のプルタスクであるとする）、ステップＳ２０１４に進む。
【００５５】
ステップＳ２０１４では、コントローラ６５１は、データソースから受取られたデータが上流のプルタスク７３４を開始するのに十分か否かを決定する。データ量が十分な場合は、コントローラ６５１はステップＳ２０１６に進み、そうでない場合は、コントローラはステップＳ２０１２に戻り、データソースにもう１つデータ要求を送る。ステップＳ２０１６では、コントローラ６５１は上流のプルタスク７３４についてのデータを処理し、そのデータを、呼出している下流のプルタスク７３６に戻し、ステップＳ２０１８に進む。ステップＳ２０１８では、下流のプルタスク７３６が、プルタスク処理を実行するのに十分な量のデータが存在するか否かを決定する。十分なデータが存在する場合は、コントローラ６５１はステップＳ２０２０に進み、そうでない場合は、コントローラ６５１はステップＳ２０１０に戻り、上流のプルタスク７３４から更にデータをプルする。ステップＳ２０２０では、下流のプルタスクがプルタスク処理を実行してデータを戻すとともに、更に下流のプルタスク又はインタフェースタスク７３８にデータ要求を戻し、ステップＳ２０２２に進む。ステップＳ２０２２では、コントローラ６５１は、上流のプルタスク７３６から受取ったデータを下流のプッシュタスク７４０にプッシュし、リンク７２８を処理スタック４００にプッシュし、制御を下流のプッシュタスク７４０に戻し、ステップＳ２０２４に進む。
【００５６】
ステップＳ２０２４では、コントローラ６５１は、上流のプッシュタスク（又はインタフェースタスク７３８）から十分なデータが受取られたか否かを決定する。十分な量のデータが存在する場合は、コントローラ６５１はステップＳ２０２６に進み、そうでない場合は、コントローラはステップＳ２００６に進む。ステップＳ２０２６では、コントローラ６５１はプッシュタスク処理を実行し、データを下流のプッシュタスク７４２にプッシュし、リンク７３０を処理スタック４００にプッシュし、制御を下流のプッシュタスク７４２に戻し、ステップＳ２０３０に進む。ステップＳ２０３０では、コントローラ６５１は、下流のプッシュタスク７４２を実行するのに十分なデータが存在するか否かを決定する。十分な量のデータが存在する場合は、コントローラ６５１はステップＳ２０３２に進み、そうでない場合は、コントローラ６５１はステップＳ２００４に進む。
【００５７】
ステップＳ２０３２では、コントローラ６５１は、受取ったデータについて下流のプッシュタスク７４２の処理を行い、出力をインタフェースタスク７４４にプッシュし、リンク７３２を処理スタック４００にプッシュし、制御をインタフェースタスク７４４に戻し、ステップＳ２０３８に進む。ステップＳ２０３８では、コントローラ６５１は、リンク７３２、７３０、及び７２８、並びに逆方向メッセージ７２３、７２４、及び７２５を、個々の項目を処理スタック４００から取出しながら続けて戻し、ステップＳ２０４０に進む。ステップＳ２０４０では、コントローラ６５１は、上流プッシュタスク７４２から受取ったデータを下流のプルタスクにプッシュし、ステップＳ２０４２に進んで終了する。
【図面の簡単な説明】
【図１】有するタスクが全てプルタスクであるデータ処理パイプラインのブロック図である。
【図２】プルタスクのブロック図である。
【図３】図１に示される処理ストリングの１つの第１のセットの処理スタック状態を示す図である。
【図４】図３の同処理ストリングの第２のセットの処理スタック状態を示す図である。
【図５】有するタスクが全てプッシュスタックであるデータ処理パイプラインを示すブロック図である。
【図６】プッシュタスクのブロック図である。
【図７】プッシュタスクストリングに挿入されたプルタスクを有するパイプライン処理ストリングを示すブロック図である。
【図８】図７に示されるインターフェースタスクのブロック図である。
【図９】図７に示されるプルタスクのブロック図である。
【図１０】図７に示されるインターフェースタスクのブロック図である。
【図１１】データ処理パイプラインを処理するためのプロセッサのブロック図である。
【図１２】図７に示されるデータ処理ストリングのための処理のフローチャートである。
【図１３】プルタスクのストリングに挿入されたプッシュタスクを有するデータ処理ストリングを示すブロック図である。
【図１４】図１３に示されるインターフェースタスクのためのブロック図である。
【図１５】図１３に示されるプッシュタスクのためのブロック図である。
【図１６】図１３に示されるインターフェースタスクのためのブロック図である。
【図１７】図１３に示される処理のためのフローチャートである。
【符号の説明】
５３４    プルタスク
５４２、５４４、７３８、７４４    インターフェースタスク
７３９    プッシュタスク
【図１】
0004318806.tif 000002
【図２】
0004318806.tif 000003
【図３】
0004318806.tif 000004
【図４】
0004318806.tif 000005
【図５】
0004318806.tif 000006
【図６】
0004318806.tif 000007
【図７】
0004318806.tif 000008
【図８】
0004318806.tif 000009
【図９】
0004318806.tif 000010
【図１０】
0004318806.tif 000011
【図１１】
0004318806.tif 000012
【図１２】
0004318806.tif 000013
【図１３】
0004318806.tif 000014
【図１４】
0004318806.tif 000015
【図１５】
0004318806.tif 000016
【図１６】
0004318806.tif 000017
【図１７】
0004318806.tif 000018