(57)【要約】本発明は、複数のリーダーが同じキューを共有できるデータ処理装置およびそのようなデータ処理装置内の少なくとも２つの処理手段を同期させる方法を提供する。複数のリーダーによってキュー管理情報に同時にアクセスするためにロックや特定の命令は不要である。書き込み処理中にデータはコピーされない。また、本発明によれば、例えば実行時間にリーダーを付加し或いは除去するために、アプリケーションはシングルライター・マルチプルリーダーキューを動的に再構成することができる。これは、本発明においては、生産タスクと第１の消費タスクとの間の主ブランチのための主ブランチ記録と、上記生産タスクと更なる消費タスクとの間の副ブランチのための副ブランチ記録とを含み、ブランチ記録のリンクリストを得るために、上記ブランチ記録が上記メモリ手段と同じ記憶場所へのポインタと次のブランチへの参照とを記憶するブランチ記録手段を設けることにより達成される。
2006503361.tif 000002
【特許請求の範囲】
【請求項１】
同じ処理手段または他の処理手段による更なる処理のためにデータを供給することができる少なくとも１つの処理手段と、
第１の処理手段によって行なわれる１つの生産タスクと少なくとも１つの第２の処理手段によって実行される多数の消費タスクとの間に少なくとも２つのブランチを含むキュー構造と、
前記消費タスクによってアクセスされるデータを記憶するとともに、前記少なくとも２つのブランチ間で共有されるメモリ手段と、
前記生産タスクと第１の消費タスクとの間の主ブランチのための主ブランチ記録と、前記生産タスクと更なる消費タスクとの間の副ブランチのための副ブランチ記録とを含み、ブランチ記録のリンクリストを得るために、前記ブランチ記録が前記メモリ手段の同じ記憶場所へのポインタと次のブランチへの参照とを記憶するブランチ記録手段と、
を備えている、データ処理装置。
【請求項２】
ブランチ記録の二重リンクリストを得るために、前記副ブランチ記録が前のブランチへの参照を更に記憶する、請求項１に記載のデータ処理装置。
【請求項３】
前記各ブランチ記録は、キュー内における生産タスクの位置を示すライターポインタと、キュー内における消費タスクの位置を示すリーダーポインタとを含んでおり、前記ライターポインタが全てのブランチ記録において同じである、請求項１に記載のデータ処理装置。
【請求項４】
前記各ブランチ記録は、キュー内における生産タスクの位置を示すライターカウンタと、キュー内における消費タスクの位置を示すリーダーカウンタとを含んでおり、前記ライターカウンタが全てのブランチ記録において同じである、請求項１に記載のデータ処理装置。
【請求項５】
データ処理装置内の少なくとも２つの処理手段を同期させる方法であって、前記処理手段のうちの少なくとも１つが他の処理手段による更なる処理のためにデータを供給することができる方法において、
第１の処理手段によって行なわれる１つの生産タスクと少なくとも１つの第２の処理手段によって実行される消費タスクとの間に少なくとも２つのブランチを含むキュー構造を規定するステップと、
前記消費タスクによってアクセスされるデータを記憶するためのメモリ手段を前記少なくとも２つのブランチ間で共有するステップと、
前記生産タスクと第１の消費タスクとの間の主ブランチのための主ブランチ記録と、前記生産タスクと更なる消費タスクとの間の副ブランチのための副ブランチ記録とを含み、ブランチ記録のリンクリストを得るために、前記ブランチ記録が前記メモリ手段の同じ記憶場所へのポインタと次のブランチへの参照とを記憶するブランチ記録手段を規定するステップと、
を含む方法。
【請求項６】
前記主ブランチ記録からライターポインタまたはライターカウンタを読み取るステップと、
前記リンクリスト内の前記副ブランチ記録からリーダーポインタまたはリーダーカウンタを読み取るステップと、
前記リーダーポインタまたはリーダーカウンタと前記ライターポインタまたはライターカウンタとを比較して、前記生産タスクによる書き込みのために利用できる個々のブランチ内の使用可能バッファ空間の量を決定するステップと、
前記生産タスクによってキュー内に新たなデータ項目を書き込んだ後に主キュー記録内の前記ライターポインタまたはライターカウンタをインクリメントするステップと、
前記副ブランチ記録内で前記ライターポインタまたはライターカウンタの値を更新するステップと、
キューに帰属する消費タスクに対してキュー満杯の変化を送信し、消費者タスクがブロック状態の場合にそのブロック状態を解除するステップと、
を更に含む、請求項５に記載の方法。
【請求項７】
キュー全体で利用できる空のバッファ空間の実際の量は、全てのブランチにわたる空のバッファ空間の最小量によって示され、任意のブランチが満杯になった時に前記生産タスクがブロックされる、請求項６に記載の方法。
【請求項８】
対応するブランチ記録からライターポインタまたはライターカウンタとリーダーポインタまたはリーダーカウンタとを読み取って、対応する消費タスクにより特定のブランチ内で読み取るために利用できるキュー内の利用可能なデータ項目の数を決定するステップと、
特定の消費タスクによってキューからデータ項目を読み取った後に対応するブランチ記録内の前記リーダーポインタまたはリーダーカウンタをインクリメントするステップと、
前記生産タスクに対してキュー満杯の変化を送信することにより、前記生産タスクがブロック状態の場合にそのブロック状態を解除するステップと、
を更に含む、請求項５に記載の方法。
【請求項９】
前記消費タスクは、その対応するブランチが空の時にブロックされる、請求項８に記載の方法。
【請求項１０】
前記主ブランチのブランチ記録を新たな副ブランチのブランチ記録内にコピーするとともに、前記新たな副ブランチへの参照を前の最後のブランチのブランチ記録に対して加えることにより、前記副ブランチが前記キュー構造に対して動的に加えられる、請求項５に記載の方法。
【請求項１１】
副ブランチは、その副ブランチ記録を前記キュー記録手段から除去するとともに、その先行ブランチのブランチ記録内に記憶された次のブランチへの参照を更新して除去されたブランチの後継ブランチを参照し、その後継ブランチのブランチ記録内に記憶された前のブランチへの参照を更新して除去されたブランチの先行ブランチを参照することにより、前記キュー構造からが除去される、請求項５に記載の方法。
【請求項１２】
前記主ブランチは、その主ブランチ記録を前記キュー記録手段から除去するとともに、最初の副ブランチのブランチ記録内に記憶された主ブランチ記録への参照を削除するとともに、主ブランチの削除および最初の副ブランチが主ブランチになったという事実を生産タスクに対して知らせることにより、前記キュー構造からが除去される、請求項５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、
同じ処理手段または他の処理手段による更なる処理のためにデータを供給することができる少なくとも１つの処理手段と、
第１の処理手段によって行なわれる１つの生産タスクと少なくとも１つの第２の処理手段によって実行される多数の消費タスクとの間に少なくとも２つのブランチを含むキュー構造と、
上記消費タスクによってアクセスされるデータを記憶するとともに、上記少なくとも２つのブランチ間で共有されるメモリ手段と、
を備えるデータ処理装置に関する。
【０００２】
また、本発明は、データ処理装置内の少なくとも２つの処理手段を同期させる方法であって、上記処理手段のうちの少なくとも１つが他の処理手段による更なる処理のためにデータを供給することができる方法において、
第１の処理手段によって行なわれる１つの生産タスクと少なくとも１つの第２の処理手段によって実行される消費タスクとの間に少なくとも２つのブランチを含むキュー構造を規定するステップと、
上記消費タスクによってアクセスされるデータを記憶するためのメモリ手段を上記少なくとも２つのブランチ間で共有するステップと、
を含む方法に関する。
【背景技術】
【０００３】
現在、循環キューに関しては多くの実施が存在する。これらのキューは、高度並行処理システムにおいて必要とされる通信バッファとしての機能を果たす。そのようなキューは、通常、共有メモリ等の記憶媒体上にマッピングされる。そのようなキューの管理情報は、多くの場合、メモリ内のキューの要素のアドレス場所を参照する幾つかのリーダーポインタおよびライターポインタと、キューの満杯に関する幾つかの他の情報とから成る。この場合、キューのリーダーおよびライターを同期させるようにする、すなわち、リーダーが空のキューから読み取ることができずかつキューが満杯の時にライターがキューに対して書き込むことができないようにする幾つかの機構が存在する。しかしながら、提案された殆どのキュー構造および管理・同期機構は、１つのライターおよび１つのリーダーだけを有するキューのためのものである。シングルライター・マルチプルリーダーキューのための解決策は多く存在しない。
【０００４】
データの特定の生産者が複数の消費者を有している場合、１つの選択肢は、別個のキュー（各消費者毎に１つのキュー）を構成するとともに、生産者がそのデータをキューへコピーすることである。しかしながら、このコピーは望ましくない。なぜなら、これにより、多くのメモリおよび帯域幅を使用しなければならなくなるからである。他の選択肢は、キューの１つのコピーにこだわり、キュー構造を拡張してキューの様々なリーダーの進行の軌跡を維持することである。米国特許第６，３０４，９２４号には、キュー構造のシングルライター・マルチプルリーダーバージョンが開示されている。この場合、キューは、複数の読み取りポインタおよび対応するリーダーと、１つの書き込みポインタおよび対応するライターとを有している。また、読み取りポインタの方向（前方または後方）もリーダー毎に複製される。この構造に伴う問題は、リーダーの数が固定されているという点である。すなわち、シングルライター・マルチプルリーダーキューを例に挙げて説明すると、リーダーの数と読み取りポインタおよび方向のコピーの数とが知られており固定されている。しかしながら、益々複雑なアプリケーションが出現しており、例えばリーダーを動的に付加し或いは除去できる循環キューよりも高い自由度が求められている。これは、既知のキュー構造では不可能である。
【０００５】
したがって、基本的なキュー構造の拡張版を有していても、更なるアプリケーションのために必要な自由度を得ることはできない。固定された数のリーダーに伴う前述した問題を解決するための１つの選択肢は、最大数の考えられるリーダーのためのキュー構造内の管理フィールドを直線配列で記憶し、例えば読み取りポインタを直線配列で記憶し、その後、リーダーの実際の数を示す１つのカウンタを加えることである。この選択肢は、この最大数を幾分控えめに選択しなければならず、そのため、実行時間中におけるリーダーの実際の数がこの最大数を下回る時に絶対に必要とされるよりも多いメモリ空間をキュー構造が占めるという欠点を有している。また、リーダーを動的に加えることはこのように簡単であるが、リーダーを除去することはかなりの労力を要する。この場合、最初に、除去されるリーダーを配列内で線形探索により識別しなければならない。次に、この場所の後の配列内の要素を１つ前に移動させなければならない。最後に、リーダーカウンタが減少されることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
したがって、本発明の目的は、特に循環キュー構造に対するリーダーの付加および除去に関して更なる自由度を与えかつ取り扱いが簡単なデータ処理装置を提供することである。また、データ処理装置内の少なくとも２つの処理手段を同期させる対応する自由度の高い簡単な方法も提供される。
【課題を解決するための手段】
【０００７】
本発明によれば、これらの目的は、前述したデータ処理装置であって、
上記生産タスクと第１の消費タスクとの間の主ブランチのための主ブランチ記録と、上記生産タスクと更なる消費タスクとの間の副ブランチのための副ブランチ記録とを含み、ブランチ記録のリンクリストを得るために、上記ブランチ記録が上記メモリ手段の同じ記憶場所へのポインタと次のブランチへの参照とを記憶するブランチ記録手段、
を更に備えるデータ処理装置によって達成される。
【０００８】
また、本発明によれば、これらの目的は、前述した方法であって、
上記生産タスクと第１の消費タスクとの間の主ブランチのための主ブランチ記録と、上記生産タスクと更なる消費タスクとの間の副ブランチのための副ブランチ記録とを含み、ブランチ記録のリンクリストを得るために、上記ブランチ記録が上記メモリ手段の同じ記憶場所へのポインタと次のブランチへの参照とを記憶するブランチ記録手段を規定するステップ、
を更に含む方法によって達成される。
【０００９】
本発明は、ブランチのコレクションとしてシングルライター・マルチプルリーダー循環キューを表わすという考えに基づいている。生産タスクが同じデータを幾つかの消費タスクに対して通信する場合には、各消費タスクのためのプロセスにおいてデータが何回もコピーされない。生産タスクは、最初の消費者と通信するために最初に生成されたキューである主ブランチの構造にアクセスする。また、これは、主消費タスクによってアクセスされる構造でもある。その後、更なる副消費タスクに接続する副ブランチが生成され、この副ブランチはこれらの消費タスクのみによってアクセスされる。このようにすれば、生産タスクは消費者タスクの数に気付かず、また、消費タスクも互いに関する知識を全く持たない。
【００１０】
前述した既知の解決策とは異なり、消費タスクがキューにアクセスする際にそれ自体を特定する必要がある場合、どの読み取りポインタおよび配列方向がこの特定の消費タスクに属するかをキューは知らないため、各消費タスク毎に別個のキュー構造を有していれば、各消費タスクは、あたかもそれがキューの唯一のリーダーであるかのように、キューにアクセスすることができる。このようにすれば、キュー構造およびアクセス機構は、それがシングルリーダーまたはマルチリーダであるかどうかにかかわらず汎用を維持することができる。また、各消費者はキュー構造のそれ自身のコピーが分かるため、任意の共有データを保護するためにロックや特定の保護機構は不要である。
【００１１】
本発明においては、更に多くの消費タスクがキューに加えられるように、キュー構造が複製される。しかしながら、それらの全ての読み取り及び書き込みポインタがメモリ内の同じ記憶域を参照する。そのため、データをコピーする必要がない。
【００１２】
本発明においては、各ブランチが別個のキュー構造を有しているため、キュー構造同士をリンクさせてシングルライター・マルチプルリーダーキュー構造を形成するための機構が必要である。この目的のため、主ブランチ記録および副ブランチ記録を含むブランチ記録手段が規定される。この場合、各ブランチ記録は、次の副ブランチへの参照またはポインタである「次ブランチ」フィールドを有している。したがって、ブランチのリンクリストが得られる。
【００１３】
ここで、１つのブランチを主ブランチに加えることにより、リーダーをキューに加えることができる。リンクリストが末尾に達するまで全検索され、その後、請求項１０で提案されているように新たなブランチキュー構造がリンクリストに付加される。このようにすれば、無限の数のリーダーを加えることができる。
【００１４】
本発明の好適な実施形態が従属請求項に記載されている。リーダーまたはブランチをそれぞれシングルライター・マルチプルリーダーキューから動的に除去できるようにするための１つの選択肢は、主ブランチから開始して、ブランチ構造ポインタを検査する度にリストを再び全検索することである。除去されるブランチに出くわすと、先行ブランチの「次ブランチ」フィールドを後継ブランチへの参照によって置換することにより、リストが簡単に更新される。しかしながら、リストを全検索することなくブランチをそれがあたかも通常のキュー（シングルライター・シングルリーダー）であるかのように直接に除去できる場合には、請求項２の好適な実施形態にしたがって提案されたように、リスト内の前のブランチを示す「前ブランチ」フィールドがキュー構造内に必要となる。そのため、ブランチの二重リンクリストが得られる。
【００１５】
特定のブランチを除去する場合には、請求項１１の好適な実施形態にしたがって提案されているように、前のブランチを調べて「次ブランチ」フィールドを除去されたブランチの後継ブランチによって置換するとともに、次のブランチを調べてその「前ブランチ」フィールドを除去されたブランチの先行ブランチによって置換することにより、リストを更新することができる。請求項１２には、キュー構造から主ブランチを除去するための好適な実施形態が記載されている。
【００１６】
キュー内における生産タスクおよび消費タスクの位置を示すためにライターポインタおよびリーダーポインタまたはライターカウンタおよびリーダーカウンタを使用するデータ処理装置の好適な実施形態が請求項３および請求項４に記載されている。
【００１７】
少なくとも２つの処理手段を同期させる方法であって、生産タスクによるキュー内へのデータ項目の書き込み及び特定の消費タスクによるキューからのデータ項目の読み取りと、消費タスクおよび生産タスクに対して送信できるポインタまたはカウンタに対するこれらの読み取りおよび書き込みの影響、キュー満杯におけるこれらの影響について説明している方法の好適な実施形態が請求項６〜９に記載されている。
【発明を実施するための最良の形態】
【００１８】
図面を参照しながら、本発明について詳細に説明する。
【００１９】
図１は、本発明を適用することが好ましい処理装置の一例としての異種マルチプロセッサアーキテクチャテンプレートを示している。ここには、処理装置として、ＣＰＵ（中央演算処理装置）１、ＤＳＰ（デジタル信号プロセッサ）２、ＡＳＩＰ（特定用途向け命令セットプロセッサ）３、ＡＳＩＣ（特定用途向け集積回路）４が示されており、これらは相互接続ネットワーク５によって互いに接続されている。相互接続ネットワーク５と通信するため、ＤＳＰ２、ＡＳＩＰ３、ＡＳＩＣ４には、アドレスデコーダ６が設けられている。中央共有メモリがオーバーロードしないように、幾つかのローカルメモリ７を付加しても良い。これらのローカルメモリは、アクセス待ち時間を減少させかつ性能を向上させるため、プロセッサに近接して配置されている。命令をバッファリングするため、ＣＰＵ１およびＤＳＰ２には命令キャッシュ８が設けられており、また、ＣＰＵ１には更にデータをバッファリングするためのデータキャッシュ９が設けられている。また、上記処理装置１，２，３，４間で共有される汎用メモリ１０が設けられている。更に、相互接続ネットワーク５には周辺機器１１を接続することもできる。以下に説明する本発明に係るキュー構造はメモリ１０内に記憶されている。
【００２０】
図２は、本発明にしたがって提案されたブランチの集まり（コレクション）としてのシングルライター・マルチプルリーダー循環キューを示している。この図には、３つの消費タスクＣ１，Ｃ２，Ｃ３に対して同じデータを通信する生産タスクＰが示されている。プロセスにおいてデータは３回コピーされない。生産者Ｐは、消費者Ｃ１と通信するために最初に生成されたキューである主ブランチＢ１の構造にアクセスする。また、これはＣ１によってアクセスされる構造でもある。その後に消費者Ｃ２，Ｃ３に接続している副ブランチＢ２，Ｂ３が生成され、これらの副ブランチＢ２，Ｂ３はこれらの消費者だけによってアクセスされる。このようにすると、生産者Ｐは消費者の数に気付かず、また、消費者は互いを認識しない。各消費者毎に別個のキュー構造を有することにより、あたかも消費者がキューの唯一のリーダーであるかのように各消費者がキューにアクセスすることができる。このようにすることで、キュー構造およびアクセス機構は、それがシングルリーダーまたはマルチリーダであるかどうかにかかわらず汎用を維持することができる。
【００２１】
図３は、本発明に係るブランチの二重リンクリストを示している。幾つかのブランチ記録、特に、主ブランチ記録Ｒ１および２つの副ブランチ記録Ｒ２，Ｒ３が示されている。各ブランチ記録は、次の副ブランチへの参照（ポインタ）である「次ブランチ」フィールドｎｅｘｔを有している。また、各ブランチ記録は、リスト内の前のブランチを示す「前ブランチ」フィールドｐｒｅｖを含んでいる。そのため、ブランチの二重リンクリストが得られる。更にまた、各ブランチ記録は、キューがマッピングされる記憶域への参照を示すキューポインタＱを含んでいる。
【００２２】
ここで、１つのブランチを主ブランチに対して加えることにより、更なるリーダーをキューに加えることができる。リンクリストは末尾に達するまで全検索され、その後、新たなブランチキュー構造が形成されてリンクリストに追加される。このようにすれば、潜在的に無限の数のリーダーを加えることができる。
【００２３】
特定のブランチを除去すると、前のブランチを調べて、除去されたブランチの後継ブランチによって次ブランチフィールドを置換するとともに、次のブランチを調べて、除去されたブランチの先行ブランチによってその前ブランチフィールドを置換することにより、リストを更新することができる。
【００２４】
なお、前ブランチフィールドが空いているブランチ記録は、リスト内の最初のブランチ記録すなわち主ブランチであり、空の次ブランチフィールドを有するブランチ記録は、リスト内の最後のブランチ記録である。キューからリーダーを動的に除去できる必要がない場合、キュー構造中の前ブランチフィールドを省いてメモリを節約することができる。
【００２５】
本発明の好適な実施形態を説明するため、既存の循環バッファ実施すなわちＣ−ＨＥＡＰを例として挙げる。O. P. Gangwal, A. K. Nieuwland, P. E. R. Lippensによる「組み込みＨＷ−ＳＷ共有メモリシステムのための拡張可能でフレキシブルなデータ同期方式」（システム・シンセシス（ＩＳＳＳ）の国際シンポジウムの議事録、２００１年１０月、モントリオール）には、Ｃ−ＨＥＡＰバッファのキュー構造・同期機構について広く記載されている。これに関連して、キューが「チャンネル」と称されるが、整合性を図るため、用語「キュー」は以下のように使用されるべきである。好適な実施形態においては、提案されたキュー構造を使用するためにアプリケーションプログラマーのインタフェース（ＡＰＩ）が考慮される。
【００２６】
Ｃ−ＨＥＡＰキュー記録は、現在、以下の情報を含んでいる。
−キュー識別子。
−キュー内のバッファの数。
−キューが操作しているモード（割り込みまたはポール、静的または動的）を示すフラグ。
−生産者タスク記録および消費者タスク記録へのポインタ。
−キューバッファポインタ。
−２つのキュー同期値（ｐｃｏｍおよびｃｃｏｍ、生産者側の同期値および消費者側の同期値）。これらの値はキューの満／空を決定するために使用される。
【００２７】
（シングルライター・シングルリーダー）キューでの同期データ通信は、以下の４つの基本要素（プリミティブ）の使用から成る。
−ｃｌａｉｍ ｓｐａｃｅ（キュー）：書き込みのためキュー内の空のバッファを要求する
−ｒｅｌｅａｓｅ ｄａｔａ（キュー）：満杯になったバッファを解放して消費者に信号を送る
−ｃｌａｉｍ ｄａｔａ（キュー）：読み取りのためのキュー内の満杯のバッファを要求する
−ｒｅｌｅａｓｅ ｓｐａｃｅ（キュー）：空のバッファを解放して生産者に信号を送る
【００２８】
シングルライター・マルチプルリーダーキューはキューのコレクションとして規定される。この場合、キューは、それぞれがそれ自体のキュー記録を有するとともに、同じ生産タスクおよび属性（例えばキュー識別子、バッファ容量）を有している。物理バッファメモリ空間はこれらのキュー間で共有される。その結果、データをコピーする必要がなく、メモリ空間および帯域幅要件の両方が減少される。その他に、マルチリーダーサポートを有する１つの汎用キュー記録を規定することが挙げられる。このキュー記録は、その後、生産タスクおよび全ての消費タスクによって参照される。そのようなキュー記録は、その後、異なる消費者を示すｃｃｏｍの複数のインスタンス（例示）およびｐｃｏｍの１つのコピーを含む。キュー情報の残りは共有され、これにより、複数のキュー記録が複製される最初の選択肢よりもメモリ使用量が低くなる。しかしながら、同じキュー記録にアクセスしている異なる消費者間を区別できなければならない。このことは、特定の消費タスクを識別するために幾つかの余分な情報がｃｌａｉｍ ｄａｔａおよびｒｅｌｅａｓｅ ｓｐａｃｅ関数呼び出し（例えばタスク識別子）を通らなければならないことを意味している。これらの同期基本要素は１つの引数（すなわち、キュー構造への参照）だけを使用するため、これはＡＰＩを変更することを意味している。タスクがシングルライター・シングルリーダーキューとシングルライター・マルチプルリーダーキューとの間の任意の差に気付くことは望ましくないため、この選択肢は好ましくない。また、最初の選択肢において、特定のシングルライター・マルチプルリーダーキューの各消費者は、キューについてのそれ自体の私見を有しており、そのため、それを通常のシングルライター・シングルリーダーキューのように取り扱う。したがって、ｃｌａｉｍ ｄａｔａおよびｒｅｌｅａｓｅ ｓｐａｃｅの実施に変化がないままであることができる。
【００２９】
以下の用語が使用される（図２も参照）。
【００３０】
マルチリーダーキューの主ブランチは、このキューを介して通信する最初の消費者および生産者を特定することにより通常の方法で生成される。このステップで生成されたキュー記録が生産者にとって明らかな唯一のものである。
【００３１】
シングルライター・マルチプルリーダーキューの副ブランチが主ブランチに加えられ、更なる消費者が生産タスクに接続される。このステップは、生産者および他の消費者にとって透過的であり（生産者および他の消費者が気付かず）、実行時間中に行なうことができる。主ブランチと同じ属性（例えばバッファの数、モードフラグ）を用いて新たなブランチ記録が生成される。
【００３２】
ブランチが一度に生成されない理由は、プログラム可能性を容易にするためである。複数の消費タスクを引数として受け入れかつ多くのキュー記録ポインタを個々のブランチに戻すＡＰＩ関数（機能）を規定することができる。しかしながら、ブランチの数が固定されず無限となる場合があるため、そのような関数を使用することは難しい。主ブランチおよび副ブランチの生成については後述する。
【００３３】
様々なブランチ間を区別できるようにするため、また、タスクに関してこれらのブランチを扱うことができるようにするためには、当初のキュー記録を拡張しなければならない。チェーン内の次の（副）ブランチに対する間接化技法（indirection）を用いて、次ブランチフィールドがキュー記録内に加えられる。また、前のブランチを示す前ブランチフィールドが含まれる。これは動的なキュー認識をサポートするために行なわれる。なお、これについては後述する。動的な認識が必要ない場合には、メモリを節約するためにこのフィールドを省いても良い。このようにすれば、マルチリーダーキューの全てのブランチの二重リンクリストが図３に示されるように得られる。
【００３４】
無論、その前ブランチフィールドが空であるキューが主ブランチであり、空の次ブランチフィールドを有するキューがチェーン内の最後のキューである。この更なる情報を使用してリンクリストを全検索することにより、全てのブランチのｃｃｏｍをアクセスすることができ、これらのｃｃｏｍをｐｃｏｍと比較してキューの満杯（全てのブランチにわたって最大である）を決定することができるとともに、ｒｅｌｅａｓｅ ｄａｔａ中にバッファ空間が満たされた後に全ての消費タスクに送信することができ、バッファ空間を割り当てるためのポインタを全てのブランチにわたってコピーしてバッファを共有することができる（図４参照）。また、各消費者がそれ自体のキュー記録のコピーにアクセスするため、共有された変数をロックまたは任意の特定の保護機構によって保護する必要がない。いずれにしても、この実施により消費者の数を無限にできる。
【００３５】
ここで、同期基本要素について説明する。ｃｌａｉｍ ｓｐａｃｅは、全ての消費者側でｐｃｏｍとｃｃｏｍの値とを比較する。これは、リンクリストをリニアに全検索するとともに全てのブランチ記録から読み取ることによって行なわれる。比較処理のいずれもがキューの満杯を示していないかどうかだけがこのプリミティブリターンであっても良い。チェックの数を減らすため、ｃｌａｉｍ ｓｐａｃｅは、満杯のブランチに出くわすと直ぐにブロックする。それがブロックされかつその後にこの満杯のブランチに関して空間が自由にされたことを示す信号を受けると、それがリスト内の次のブランチに続く。先の比較を繰り返す必要はない。これは、前のブランチが一時的に変更されたかもしれないが、生産者がブロックされたことによりこれらのブランチが満杯になることができなかったためである。ポーリングモードにおいては、満杯のブランチのｃｃｏｍが繰り返し読み取られる。マルチプルリーダーの場合とシングルリーダーの場合との間の動作の違いは、行なわれる比較処理の数である。これは、シングルリーダーの場合、リスト内に１つの要素しか存在しないためである。
【００３６】
生産タスクがメモリバッファを満たしかつｒｅｌｅａｓｅ ｄａｔａ中にｐｃｏｍを更新すると、副ブランチ記録内のｐｃｏｍのコピーを更新しなければならない。また、たった１つではなく、全ての消費タスクに信号が送られる。ここで、キュー記録内のｐｃｏｍフィールドを、ｐｃｏｍが実際に記憶される幾つかの他の記憶域への参照（ポインタ）に変更することにより、最適化が可能である。このようにすれば、全てのブランチにとって明らかなｐｃｏｍのコピーがたった１つとなり、各ブランチ構造中のｐｃｏｍの全てのコピーを更新する必要がなくなる。
【００３７】
ｃｌａｉｍ ｄａｔａにおいて、消費タスクは、それ自体のブランチ記録内のｃｃｏｍと  ｐｃｏｍとを比較して、キューの満杯を決定する。このブランチに対するこの値の更新はいまだなされていないため、消費タスクが読み取るｐｃｏｍの値が僅かに古くなるといった状況が生じる場合がある。結果として、この消費者が実際よりも満たされていないバッファしか見ない場合もあるため、ｃｌａｉｍ ｄａｔａが空のバッファを誤って戻すことはない。この基本要素の作用は、シングルリーダーキューおよびマルチプルリーダーキューの両方において全く同じである。
【００３８】
ｒｅｌｅａｓｅ ｓｐａｃｅ中、各消費者は、それ自体のブランチ内のｃｃｏｍを更新するとともに、この処理の生産者に信号を送る。その結果、生産者に送られる信号の数が増大する。この基本要素の作用もシングルリーダーキューおよびマルチプルリーダーキューにおいて同じである。
【００３９】
前述したように、マルチリーダーキューは主ブランチと１または複数の副ブランチとから成る。ｑｕｅｕｅ ｃｒｅａｔｅ関数を使用することにより主ブランチが生成される。すなわち、
queueT*queue create(int id,taskT*P,taskT*C,int nbuf,int flags)
【００４０】
この関数を使用することにより、識別子ｉｄ、バッファの数ｎｂｕｆ、モードフラグｆｌａｇｓを用いて、生産者Ｐと最初の消費者Ｃとの間で１つのキューが生成される。これは、生産者にとって明らかな唯一のブランチである。このキューに副ブランチを加えるため、以下の関数が使用される。
queueT*queue add branch(queueT*ch,taskT*C)
【００４１】
この関数は、前述した関数において生成されたキュー記録（すなわち主ブランチ）を利用するとともに、その内容を副ブランチのために新たに生成されたキュー記録にコピーする（消費タスクフィールドを除く）。その後、関数は、この新たなブランチ記録の場所をリンクブラチリストの最後に加えるとともに、新たに生成されたブランチ記録に参照を戻す。
【００４２】
キューバッファメモリの割り当ては常に主ブランチで行なわれる。バッファ記憶場所が知られると、これらの記憶場所が副ブランチのキュー記録にコピーされる。このステップは、いずれにしてもバッファ記憶場所が主ブランチからコピーされるため、新たなブランチを加える前に行なうことができる。
【００４３】
Ｃ−ＨＥＡＰキューは以下のような方法で認識される。
−破壊
−再ルート付け
−属性（例えばバッファサイズ、モードフラグ）の変更
−ブランチの付加または削除
【００４４】
シングルライター・マルチプルリーダーキューの全てのブランチを一度に破壊することはおそらく望ましくない。したがって、個々のブランチを個別に破壊することが支持される。この目的のために以下の関数が使用される。
void queue destroy(queueT*queue)
【００４５】
この関数は、ブランチ記録の記憶域へのポインタを引数と見なす。なお、これは、シングルライター・シングルリーダーキューを破壊するために使用される関数と全く同じ関数である。この場合も同様に、これは、多数のリーダーに対する我々の手法の透明性（透過性）を明示する。シングルライター・マルチプルリーダーキューの副ブランチを破壊することは簡単である。そのエントリは、消費タスク記録から最初に除去される。ブランチが除去されると、図３に示されるリンクリストが破壊され、したがって、リスト参照を改めなければならない。リスト項目が除去されると、その先行者の次ブランチフィールドをその後継者へのポインタによって置換しなければならない。これは、前ブランチフィールドがキュー記録内に加えられた理由である。なぜなら、破壊されたブランチから、その先行ブランチにアクセスすることができなければならないからである。同様に、その後継者の前ブランチフィールドがその先行者へのポインタによって置換されなければならない。この後、破壊されたブランチの記録がメモリから除去される。
【００４６】
ブランチを除去するには、生産者を最初に食い止める（停止させ、あるいは、一時停止させる）ことも必要である。これは、そうしないと、リンクリストが更新される際に信号送信（シグナリング）機構が乱される場合があるからである。例えば、その先行者から参照される直前に、破壊されたブランチの記録が自由にされても良い。リスト内の次のブランチ（もはや存在しない）として読み取られて判断される値がもはや規定されないため、これが致命的な結果を招く場合がある。主ブランチを破壊することは難しい問題である。なぜなら、主ブランチは、生産者によって分かる唯一のブランチだからである。主ブランチが除去されると、副ブランチのうちの１つを主ブランチに「起用」しなければならない。この操作は、非常に簡単であり、リスト内の副ブランチの前ブランチフィールドがＮＵＬＬポインタに設定されることを単に意味している。また、この新たに選定された主ブランチへのポインタは生産タスクに通信されなければならない。これは、生産者のタスク記録を更新しかつ再びアクティブにされた後に新たなキュー記録ポインタをタスクにフェッチさせる（呼び出させる）ことにより行なうことができる。また、キューの破壊は、バッファメモリを自由にすることを含んでいる。無論、最後のブランチが破壊されると、これだけが行なわれる。
【００４７】
実行時間でｑｕｅｕｅ ａｄｄ ｂｒａｎｃｈ関数を呼び出すことにより、既存のキューに対してブランチを動的に加えることができる。この新たなブランチの記録は主ブランチからコピーされるため、その初期状態（すなわち満杯状態）は主ブランチのそれと同じである。その時、他のブランチは全く異なる満杯状態を有していても良い。新たなブランチが加えられる際に全てのブランチが同じ状態をとることが望ましい場合がある。この場合、消費者はブランチを最初に排出しなければならない。
【００４８】
以下のようにしてシングルライター・マルチプルリーダーキューを再ルート付けすることができる。この操作が副ブランチで行なわれると、消費タスクだけを変えることができる。この場合、変更はこの特定のブランチの記録に関与するだけである。主ブランチに関してはキューの生産者を変更することしかできない。これを行なうためには、ブランチのリンクリストにわたって主ブランチおよび全ての副ブランチの記録を変更しなければならない。
【００４９】
キューの属性の変更は全てのブランチに影響を与え、個々のブランチの属性を変更することはできない。したがって、この操作は常に主ブランチで行なわれる。
【００５０】
本発明は、複数のリーダーが同じキューを共有できるデータ処理装置およびそのようなデータ処理装置内の少なくとも２つの処理手段を同期させる方法を提供する。複数のリーダーによってキュー管理情報に同時にアクセスするためにロックや特定の命令は不要である。書き込み処理中にデータはコピーされない。また、本発明によれば、例えば実行時間にリーダーを付加し或いは除去するために、アプリケーションはシングルライター・マルチプルリーダーキューを動的に再構成することができる。
【図面の簡単な説明】
【００５１】
【図１】異種マルチプロセッサアーキテクチャテンプレートを示している。
【図２】主ブランチおよび副ブランチの概略図である。
【図３】ブランチの二重リンクリストの概略図である。
【図４】バッファ共有を示す幾つかのブランチ記録の概略図である。
【図１】
2006503361.tif 000003
【図２】
2006503361.tif 000004
【図３】
2006503361.tif 000005
【図４】
2006503361.tif 000006
【国際調査報告】
2006503361.tif 000007
2006503361.tif 000008
2006503361.tif 000009