JP2012506581A - 複数のメモリ要素に分配されたメモリ空間内でデータ・バッファを管理する装置 - Google Patents

Abstract

本発明の主題はとりわけ、複数のメモリ要素にわたり分配されたメモリ空間内でデータ・バッファを管理する装置である。
メモリ空間はメモリ・ページによって割り当て可能であり、各バッファは１つ以上のメモリ・ページを含む。
バッファはアプリケーション実行用の少なくとも１つの処理ユニットによって使用可能であり、アプリケーションはタスクを並列に実行する複数の処理ユニット（３）により実行され、メモリ要素は処理ユニットにより並列にアクセス可能である。
装置はアプリケーションの実行中にバッファをタスクに割り当てる手段と、バッファへのアクセス権を管理する手段とを含む。
バッファへのアクセス権を管理する手段は、前記バッファを非同期のタスク間で共有するような方法で、所与のページへの書き込みが、前記ページから現在読み込まれているデータを修正しないこと、又は所与のページからの読み取りが、前記ページに現在書き込まれているデータにアクセスしないことを確認するために、所与のバッファ内のページへのアクセス権を管理する手段を含む。
用途：高い計算能力を有する組み込みシステム
【選択図】 図１

Description

本発明は、複数のメモリ要素に分配されたメモリ空間内でデータ・バッファを管理する装置に関する。それは例えば、高い計算能力を有する組み込みシステムの領域において適用される。

現行の組み込みシステムは、常により複雑な処理を実行する傾向がある。例として、携帯電話は完全な遠隔通信チャネルを実装しなければならない。機上のビデオ監視装置は、画像処理用の完全なチャネルを実装しなければならない。このアプリケーションの複雑さの増加と並列に、同一の装置内に組み込まれるアプリケーションの数は同様に絶え間なく増加している。これはとりわけ、例えば「スマートフォン」タイプの携帯電話、又は「携帯情報端末」において、遠隔通信機能、マルチメディア機能、ゲーム、あるいは衛星測位機能と組み合わせることによって、常により多目的のオブジェクトを作ろうという望みにより説明される。常により高い計算能力を提供するニーズに加えて、特に現在の実施環境に応じ、アーキテクチャを最適化できることもまた必要である。これは本発明が解決するために提案する技術的問題の１つを構成する。

さらに、多くの組み込みシステムは、より広い問題解決の手立てを提案する傾向があり、ユーザーが彼ら自身のアプリケーションを実行するため、ユーザーに自分の流儀でそれらを自由に使用させる。このより広い手立ては、アプリケーションのコンテクストが設計段階では完全に決められないため、一般に「未実行」又は「オフライン」解決策と称されている、システム構成を最適化するための静的解の有効性を損なう。とりわけ、ビデオセンサー及び高速変換器の容量における進歩を考慮すると、取り扱われるデータのタイプと量を決定するのは困難である。さらに、多くの優れたアプリケーションにおいて、実行されるべき処理は入力データに応じて変化する。例として、ビデオ監視のアプリケーションは、一般的に或るシーンにおけるオブジェクトの検索を目的とし、１つ以上のオブジェクトが検出されたとき、アプリケーションは検出されたオブジェクトの追跡段階、さらに解析段階へと移行する。これは本発明が解決するために提案する技術的問題の１つを再度構成する。

一般に「実行中」又は「オンライン」解決策と称されている、システム構成を最適化するための非静的解は、使用の全てのシナリオを予測する必要はない。それらはアプリケーションのコンテクストに素早く適合するような方法で、例えば資源を制御するための動的メカニズム、例えば計算資源を割り当てるための、又は記憶資源を割り当てるためのメカニズムを実装することが基本的に重要である。そのとき計算集約型タスクが、相互に通信するこれらのタスク間の非常に強い相互作用と共に、制御により支配されるタスクに沿って実行される。しかしながら、そのような制御メカニズムをしかるべき場所に置くことは、性能の観点から高価であり得る。これは本発明が解決するために提案する技術的問題の１つを再度構成する。

事実、タスクはとりわけデータ・バッファを介して通信する。バッファはそこに単一のプロデューサ・タスクが書き込み可能で、そこから幾つかのコンシューマ・タスクが潜在的に読み取れる、メモリの領域である。非常に複雑なアプリケーションの枠組み内では、アプリケーションの実行に必要なメモリバッファの数が、それゆえコンピュータ・マシンの記憶容量を超過し得る。これは本発明が解決するために提案する技術的問題の１つを再度構成する。

今日の解決策は、アプリケーションによって現在使用されているバッファを、動的に割り当て、そして割り当てを解除することである。メモリの割り当ては、プログラム内で取り扱われる所与のオブジェクトを記憶するための、十分な大きさのメモリ空間を用意しておくこと、及び次にその使用後に前記メモリ空間を解放することを主な目的とする。しかしアロケータはまた、メモリのどの部分が使われ、どの部分が空いているかを指定する情報を更新する役目を持ち、それを時間的不利益と引き換えに行っている。先行技術は時間的不利益を最小化する一方で、メモリの占有を最適化するための技術に富む。最も良く知られる技術は、３つのタイプのアプローチ："Ｓｅｑｕｅｎｔｉａｌ Ｆｉｔ"（「逐次はめ込み」）、"Ｓｅｇｒｅｇａｔｅｄ Ｆｒｅｅ Ｌｉｓｔｓ"（「分離フリー・リスト」）、及び"Ｂｕｄｄｙ Ｓｙｓｔｅｍ"（「バディシステム」）による、隣接するメモリ領域の割り当てに基づく。

"Ｓｅｑｕｅｎｔｉａｌ Ｆｉｔ"（「逐次はめ込み」）タイプのアロケータは、メモリ内の全ての空きブロックの線形リストに基づく。従って、ｎｂページのメモリのオブジェクトの割り当て段階は、ｎｂページの空きメモリブロックが見出されるまで、このリストを逐次走査することにある。このアルゴリズム及びその様々な最適化は、実施が非常に容易である。しかし、それは割り当て可能なメモリ領域を見出す前に、逐次的なやり方で全体のリストが走査される必要が潜在的にあり得るため、極度に不利益をもたらす。これは"Ｓｅｑｕｅｎｔｉａｌ Ｆｉｔ"（「逐次はめ込み」）アプローチの主要な欠点を構成する。

割り当てを加速させるため、"Ｓｅｇｒｅｇａｔｅｄ Ｆｒｅｅ Ｌｉｓｔｓ"（「分離フリー・リスト」）タイプのアロケータは、メモリ内の全ての空きブロックの単一のリストでなく、各々のリストが或る大きさの空きブロックのみを含む、幾つかの空きブロックのリストを考慮する。例えば、１つのリストは１０〜２０ページの空きブロックを含むことができ、別のリストは２０〜４０ページの空きブロックを含むことができる、等々。割り当て段階の間、空き領域の検索は適切な大きさのブロックを含むリスト内においてのみ実行される。このアプローチは検索を大幅に加速するが、多数のリストの保持を必要とする。これは"Ｓｅｇｒｅｇａｔｅｄ Ｆｒｅｅ Ｌｉｓｔｓ"（「分離フリー・リスト」）アプローチの主要な欠点を構成する。

割り当てを更に加速するため、"Ｂｕｄｄｙ Ｓｙｓｔｅｍ"（「バディシステム」）タイプのアロケータは、大きさが２の累乗の空きブロックを含むリストを考慮する。或るブロックが２の累乗で表わされる大きさを持たない場合、その大きさは２の１つ高い累乗に近似される。この制約はメモリ空間を、実質的に半分の大きさの２セットへと切り分けることを可能にする。各セットは限界の大きさに達するまで、順々に２つのより小さい実体へと分解される。このアプローチはリストの数を減少させるが、それは著しいメモリの断片化を生じる。事実、２の更に高い累乗に丸めることは、メモリブロックの過少利用を引き起こす。これは"Ｂｕｄｄｙ Ｓｙｓｔｅｍ"（「バディシステム」）アプローチの主要な欠点を構成する。

しかしながら、更に割り当てを加速するため、それらがソフトウェアにおいて実施されようと、あるいはそれらが特定のハードウェアのオペレータにおいて実施されようと、動的にメモリを割り当て、及び割り当て解除するためのこれら３つのタイプの解決策は常に、割り当てられるメモリ領域の隣接関係の制約に悩む。事実、この隣接関係の制約はあらゆる場合にメモリの過少利用をもたらし、割り当て要求は、利用可能なメモリ空間の不足のためでなく、十分に広い隣接するメモリ領域が存在しないために失敗し得る。これは本発明が解決するために提案する技術的問題の１つを再度構成する。

様々なソフトウェアの解決策は、不連続なメモリ領域を動的に割り当て、及び割り当て解除することを可能にする。例えば、論文"Ｐａｇｅ−Ｂａｓｅｄ Ｎｏｎ−Ｃｏｎｔｉｇｕｏｕｓ Ｄｙｎａｍｉｃ Ｍｅｍｏｒｙ Ａｌｌｏｃａｔｏｒ"（「ページに基づく不連続な動的メモリ・アロケータ」）（Ｊ．Ｃｈｅｎら）において、ハードウェア・アロケータは、空きメモリ・ページの集合を保持するために、"Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ"（ＦＩＦＯ）(「先入れ先出し」)タイプのデータ構造を用いる。各割り当ての際、それはＦＩＦＯ構造からページを引き出す。割り当て解除の間、それは空きページをＦＩＦＯ構造内へ入力する。この単純な解決策は良好な反応性を可能にする。しかしそれは、その大きさがシステム内のメモリのページ数に直接比例する、ＦＩＦＡデータ構造を必要とする。従ってそれは高いシリコン・コストを有し得る。さらに、この解決策はメモリ空間が、より一般的には"ｂａｎｋｅｄ ｍｅｍｏｒｙ ｓｐａｃｅ"（「バンク化されたメモリ空間」）と称される、幾つかのメモリバンクにわたって分配されている場合、アクセスの並列性の利用を最大化するための、メモリ空間内のページ分配の最適化を可能にしない。これは主要な欠点を構成する。別の例として、論文"ＳＯＣＤＭＭＵ Ｄｙｎａｍｉｃ Ｍｅｍｏｒｙ Ｍａｎａｇｅｍｅｎｔ Ｆｏｒ Ｅｍｂｅｄｄｅｄ Ｒｅａｌ−Ｔｉｍｅ Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ Ｓｙｓｔｅｍ ｏｎ ａ Ｃｈｉｐ"（「組み込みリアルタイム・マルチプロセッサ・システムオンチップ用ＳＯＣＤＭＭＵの動的メモリ管理」）（Ｍ．Ｓｈａｈａｌａｎ）において、ＳＯＣＤＭＭＵと呼ばれるモジュールは、それらが空であろうと一杯であろうと、全てのメモリ・ページの状態を記述する表を用いる。空きページの検索は、表において利用できる最初のページを検索する"Ｆｉｒｓｔ−ｆｉｔ"（「先行一致」）アルゴリズムにより実行され、このページがその後に割り当てられる。空きページの検索を可能にするデータ構造は、ＦＩＦＯ構造よりもずっと量が少ないが、最悪の場合、空きページを突き止める前にメモリ状態の表全体が走査される必要があり得るため、空きページの検索はやはり長時間となり得る。さらに、この解決策もまたバンク化されたメモリの場合に、アクセスの並列性を最も良く利用するための、メモリ空間内のページ分配の最適化を可能にしない。これは本発明が解決するために提案する技術的問題の１つを再度構成する。

さらに、１つのプロデューサ・タスク及び１つ以上のコンシューマ・タスクによって同時に取り扱われるデータ・バッファの管理は、現行のシステムにおいては最適化されない。"ｒｅａｄ−ａｆｔｅｒ−ｗｒｉｔｅ"（「リード・アフター・ライト」）タイプ又は「ライト・アフター・リード」（ｗｒｉｔｅ−ａｆｔｅｒ−ｒｅａｄ）タイプの従属関係への適合を保証するため、現行のシステムは、データのプロデューサ・タスク及びコンシューマ・タスクが明確に同期されるものと、大まかに仮定している。従って、ページはそれが完全に消費されたときにのみ解放される。これは本発明が解決するために提案する技術的問題の１つを再度構成する。

本発明の目的は特に、幾つかのメモリ要素にわたって分配されているメモリ空間を動的に管理するための革新的な解決策を提案することにより、前述の欠点を軽減することである。バッファを全てのメモリ要素にわたって広げることにより、これらの要素が並列にアクセス可能なとき、それはとりわけ有効である。このため、本発明の主題は特に、複数のメモリ要素にわたって分配されているメモリ空間内のデータ・バッファを管理する装置である。メモリ空間はメモリ・ページにより割り当て可能であり、各バッファは１つ以上のメモリ・ページを含む。バッファはアプリケーションの実行のための、少なくとも１つの処理ユニットによって使用可能であり、アプリケーションはタスクを並列に実行する、複数の処理ユニット（３）により実行され、メモリ要素は処理ユニットにより並列にアクセスできる。装置はアプリケーションの実行中にバッファをタスクに割り当てる手段、及びバッファへのアクセス権を管理する手段を備える。バッファへのアクセス権を管理する手段は、非同期のタスク間で前記バッファを共有するような方法で、所与のページへの書き込みが、前記ページから現在読み取られているデータを変更しないこと、又は所与のページからの読み取りが、前記ページに現在書き込まれているデータにアクセスしないことを確認するために、所与のバッファ内のページへのアクセス権を管理する手段を含む。

有利なことに、バッファを割り当てる手段は、同一のメモリ要素に割り当てられるバッファの最大の数を最小化するような方法で、バッファを割り当てることができる。

好適な実施形態において、バッファを割り当てる手段は、所与のレジスタ内の所与のビットが、所与のメモリ・ページの空き状態又は空きでない状態を特徴付ける、メモリ・ページの充填状態レジスタを含むことができ、バッファを割り当てる手段は又、所与のレジスタ内の所与のビットが、所与のメモリ要素の部分的に一杯の状態又は部分的に一杯でない状態を特徴付ける、メモリ要素の空き状態レジスタと同様に、所与のレジスタ内の所与のビットが、所与のメモリ要素の空き状態又は空きでない状態を特徴付ける、メモリ要素の充填状態レジスタを含むことができる。バッファを割り当てる手段は次に、メモリ要素の空き状態レジスタの更新を加速するための、メモリ・ページの充填状態レジスタ上における排他的なＯＲタイプの論理演算と同様に、メモリ要素の充填状態レジスタの更新を加速するための、メモリ・ページの充填状態レジスタ上におけるＡＮＤタイプの論理計算を行う手段を含むことができる。バッファを割り当てる手段は、１周期で最初のビットを１に決定可能にする優先度付き符号化器を、メモリ要素の充填状態レジスタ及び空き状態レジスタ内に含むことができる。

例えば、装置はアプリケーションの実行中にバッファの割り当てを解除する手段を備えることができ、バッファ内に含まれるデータの物理アドレスは、前記バッファがアプリケーションの実行途上で割り当てを解除され、次に再度割り当てられる場合に可変である。処理ユニットは次に、アプリケーションを実行するために不変の仮想アドレスを使うことができ、装置は仮想アドレスを物理アドレスに変換する手段を備え得る。仮想アドレスを物理アドレスに変換する手段は、仮想アドレスと物理アドレス間の対応を記憶するための、少なくとも１つの構造を含むことが可能である。所与のバッファ内に含まれるデータの、仮想アドレスと物理アドレス間の対応は、前記バッファ専用の１つ以上の構造内に記憶され得る。仮想アドレスを物理アドレスへ変換する手段は又、各処理ユニットにおける記憶構造のコピーも含み得る。

有利なことに、バッファへのアクセス権を管理する手段は、所与のタスクがデータを所与のバッファに書き込むのを認可されていることを確認する手段を含み得る。それらは又、所与のバッファから読み取られるタスクの数が、所定のしきい値を超えないことを確認する手段も備える。それらは更にタスクからバッファに書き込む権限を取り下げ、そして前記バッファに書き込む別のタスクを認可するための手段も含む。

有利なことに、バッファを割り当てる手段は、利用できるメモリ空間が所与のバッファを割り当てるのに十分であることを確認する手段を含み得る。バッファを割り当てる手段及び、ページへのアクセス権の管理手段は、１つの割り当て要求で、所与のバッファ内において所与のタスクに幾つかのページを割り当てることを可能にし得る。

本発明の主な利点はさらに、それがメモリ空間全体の占有を許容し、それがシステムの全体性能に対して無視できる時間的な影響を持ち、そしてそれが最小のシリコン・コストとエネルギー・コストにおいて実行され得ることである。

本発明の別の特徴及び利点は、添付図に関連して提供された以下に続く記述の助けで明らかになるであろう。

本発明による例示的アーキテクチャを機能図で表わす。 本発明による仮想アドレスの例示的な形式を構造図で表わす。 本発明による例示的メモリ空間の予約要求を構造図で表わす。 本発明による例示的データ配置要求を構造図で表わす。 本発明による例示的バッファ開放要求を構造図で表わす。 本発明による例示的変換テーブル取得要求を構造図で表わす。 本発明による例示的データ利用可能性要求を構造図で表わす。 本発明による、データを利用可能にする例示的要求を構造図で表わす。 本発明による例示的ページ開放要求を構造図で表わす。 本発明によるバッファの所有者変更の例示的要求を構造図で表わす。 データ・バッファの配置要求を処理するための、本発明によるメモリマネージャの例示的動作をアクティビティ図で表わす。 本発明の実施を可能にするメモリ領域の一例を構造図で表わす。 データ・バッファの開放要求を処理するための、本発明によるメモリマネージャの例示的動作をアクティビティ図で表わす。 データ・バッファの所有者変更要求を処理するための、本発明によるメモリマネージャの例示的動作をアクティビティ図で表わす。 本発明による例示的変換ユニットを構造図で表わす。 変換テーブル移動要求を処理するための、本発明によるメモリマネージャの例示的動作をアクティビティ図で表わす。 利用可能性の依頼要求を処理するための、本発明によるメモリマネージャの例示的動作をアクティビティ図で表わす。 ページを利用可能にする要求を処理するための、本発明によるメモリマネージャの例示的動作をアクティビティ図で表わす。 ページの開放要求を処理するための、本発明によるメモリマネージャの例示的動作をアクティビティ図で表わす。

図１は本発明によるメモリマネージャ１、タスクマネージャ２、及び処理ユニットの集合３の間の可能なやり取りの一例を機能図で例証している。本例示的実施形態において、タスクマネージャ２は特定の実体である。しかしながら、タスクマネージャは、処理ユニット３上で実行するシステム・ソフトウェアにより実装されることが考えられる。タスクマネージャ２は１つの処理ユニットから別のユニットへ、大きな移送容量でタスクを処理ユニット３に割り当てる。本例示的実施形態において、メモリマネージャ１はデータ・バッファをメモリの「クラスタ」内に割り当て及び割り当て解除する役目を持ち、クラスタは３２のメモリバンクを備え、各バンクは３２のメモリ・ページを含み、各ページは６４ワードを含み、そして各ワードは４バイトを備える。以下に続く記述において言及される全ての数値は、与えられた例示的実施形態のみに対応し、これらの値は全く限定的ではないことが明確に理解されなければならない。次に続く記述において、及び明確化の理由で、メモリバンクは時に「メモリ資源」又は単に「メモリ」のいずれかで称され得る。例えばプロセッサであり得る集合３を形成する処理ユニットは、アプリケーションを並列に実行するためにメモリのクラスタを使うことがあり、複数の処理ユニットは有利にも並列にメモリバンクにアクセス可能である。従って、メモリマネージャ１はタイプ：Ｄａｔａ＿Ａｓｓｉｇｎｍｅｎｔ， Ｆｒｅｅ＿ｄａｔａ， Ｇｅｔ＿Ｍｅｍｏｒｙ＿Ｍａｐ，Ａｓｋ＿ａｖａｉｌ， Ｓｅｎｄ＿ａｖａｉｌ， Ｓｅｎｄ＿ｆｒｅｅの最低限の要求として、また同様に、望ましくはタイプ：Ｄａｔａ＿Ｒｅｓｅｒｖａｔｉｏｎ及びＣｈｏｗｎ＿ｄａｔａの要求として処理する。これらの要求の内容はこの後に詳細が記述されている。本例示的実施形態において、タスクマネージャ２はＤａｔａ＿Ｒｅｓｅｒｖａｔｉｏｎタイプの要求１０をメモリマネージャ１に送り、一方で処理ユニット３はＤａｔａ＿Ａｓｓｉｇｎｍｅｎｔ， Ｆｒｅｅ＿ｄａｔａ， Ｇｅｔ＿Ｍｅｍｏｒｙ＿Ｍａｐ， Ａｓｋ＿ａｖａｉｌ， Ｓｅｎｄ＿ａｖａｉｌ， Ｓｅｎｄ＿ｆｒｅｅ，及びＣｈｏｗｎ＿ｄａｔａのそれぞれのタイプの要求１１、１２、１３、１４，１５、１６、及び１７をメモリマネージャ１に送る。

以下に続く記述において、アプリケーションはデータ・バッファを介して通信するタスクのグラフ形式でモデル化可能であり、単一のプロデューサ・タスクは所与のバッファに書き込むことができ、一方で幾つかのコンシューマ・タスクはそれを読む潜在的能力を有し得る。

メモリ内へのバッファの動的配置は、メモリマネージャ１により提供される他の機能性の中で、１つの基本的機能性に過ぎないことが理解されなければならない。例えば、メモリマネージャ１により確実にされる第２の機能性は、タスク内で取り扱われる仮想アドレスの、物理アドレスへの変換であり得る。事実、タスクに対して透過的なやり方で、利用可能なメモリ上でデータ・バッファを動的に割り当て／割り当て解除するためには、バッファの仮想のアドレス指定が好ましい。従って、メモリ内におけるバッファの物理アドレスは、タスクにより取り扱われるそれらの仮想アドレスにおいて何ら変化なく、割り当て／割り当て解除により命令されるように変化し得る。有利なことに、データへのアクセス権を管理する第３の機能性は、とりわけバッファのプロデューサ及び１つ以上のコンシューマが、物理的に分配されたメモリ空間上で同時にアクティブである、データフロー・アプリケーションのコンテクストにおける、データ依存性の順守を確実にし得る。例えば、これはデータ項目が作られた後のみに確実に読み取られ得ることを含む。一般に、プロデューサ・タスク及び１つ以上のコンシューマ・タスクにより同時に取り扱われるデータ・バッファの管理は、"ｒｅａｄ−ａｆｔｅｒ−ｗｒｉｔｅ" （「リード・アフター・ライト」）タイプの依存性の順守を保証するように、そして或るページが完全に消費されると直ちにそのページを自動的に解放するように、データのプロデューサ・タスクとコンシューマ・タスクが明確に同期すると仮定する、現行のシステムにおいては最適化されないことに注意されたい。

図２は本発明による仮想アドレスの例示的な形式を、構造図で例証している。これに続いて、処理タスクは仮想的にアドレス指定されたデータを、図２に記述される形式に従って取り扱うことが考えられるであろう。本例示的実施形態において、１４ビットのｉｄ＿ｄａｔａ領域は取り扱われたバッファの識別を可能にし、それにより１６３８４のバッファをアドレス指定することを可能にする。１０ビットのＮｕｍ＿ｐａｇｅ＿ｖ領域は、バッファ内で取り扱われるページを明確にすることを可能にし、それによって単一のバッファが、メモリ空間の２^１８バイト全体を占有することを認可する。８ビットのオフセット領域は、バイト毎にページ内で動かすことを可能にする。

メモリマネージャ１は、システムのメモリ資源上に可変サイズのバッファを動的に置く役目を有する。処理タスクにより取り扱われる仮想メモリ空間内で、バッファは隣接するメモリ領域として見なされる。利用可能なメモリ空間を最もうまく占有するために、データ配置はそれに関して何ら隣接の制約を想定せず、バッファに物理的に割り当てられるメモリ空間の断片化を許容する。バッファに物理的に割り当てられるメモリ空間の大きさは、ページ数の形でメモリマネージャ１に指定される。本例において、バッファの大きさはそれゆえ６４×４＝２５６バイトの倍数であり、それによりメモリ空間の最適化された分配を許す。

図３はメモリ空間の予約を可能にする、本発明によるＤａｔａ＿Ｒｅｓｅｒｖａｔｉｏｎタイプの例示的要求１０を構造図で例証する。事実、バッファをメモリ内に配置する前に、十分な空間が用意されなければならない。要求Ｄａｔａ＿Ｒｅｓｅｒｖａｔｉｏｎはタスクマネージャ２の主導になる。この要求を受けると、本例示的実施形態において、メモリマネージャ１はその要求タイプ識別子００００のおかげで、それを最初の４ビットにおいて認識する。次に、メモリマネージャ１は、タスクｉｄ＿ｔａｓｋにより作り出された全てのバッファに対して、十分なメモリがあることを確認する。それが当てはまる場合、ｎｂ＿ｐａｇｅｓのメモリ・ページが予約される。それらはデータ配置要求の間に、タスクｉｄ＿ｔａｓｋと関連する様々なバッファに物理的に割り当てられる。要求が十分なページ数の不足により失敗した場合、要求の送信者は、例えばタスクの一時停止あるいはサービス品質の低下のような、状況に応じた適切な手段を取るように、それに関して通知される。この予約機能が存在しない場合、メモリ空間がこれらのバッファを格納するのを待つ間は、タスクは無効とされ得る。ｘとマークされた最後の１６ビットは使用されない。後に続き、そして要求を表わす図４〜１０において、最初の４ビットは要求のタイプを識別することを可能にし、ｘとマークされた最後のビットは使用されない。

図４はデータ配置を可能にする、本発明によるＤａｔａ＿Ａｓｓｉｇｎｍｅｎｔタイプの例示的要求１１を構造図で例証している。メモリ内のバッファ配置は、例えばタスクの初期化の間に行われる。バッファの仮想ページの各々に対して、この配置は物理的メモリ空間内で空きメモリ・ページを探すこと、及びそれをそこに割り当てることを可能にする。これ以降、この機能を加速する適用可能な最適化が議論されるであろう。割り当て要求Ｄａｔａ＿Ａｓｓｉｇｎｍｅｎｔは、望ましくはタスクの初期化段階の間に、あるいは少なくともバッファを取り扱う前に、タスクを実行する処理ユニットによって送られる。それらは、例えば図４に例証されている形をとる。この要求の最初の４ビット０００１は、そのタイプの識別を可能にする。次の１４ビットはバッファの識別子ｉｄ＿ｄａｔａを含む。次の１０ビットはページ数で表わされるバッファのサイズｎｂ＿ｐａｇｅｓを含む。空きメモリ・ページの検索及びバッファへの割り当てに加えて、メモリマネージャ１はそれに続いてアドレス変換段階、及びアクセス権確認の段階の間に使用されるであろう、コンシューマの数あるいは所有者の識別子のような、バッファに関連する情報を記憶する。従って、次の１０ビットはバッファ所有者のタスク、すなわちバッファへの書き込みを認められたタスクの識別子ｉｄ＿ｔａｓｋを含む。次の１０ビットはバッファのコンシューマｎｂ＿ｃｏｎｓｕの数を含む。次の１０ビットは、それに基づいてメモリマネージャ１がバッファの充填状態をタスクマネージャ２に知らせる、充填率ｑｕｏｔａを示す。空きメモリ・ページの検索及びバッファへの割り当てに加えて、メモリマネージャ１は、それに続いてアドレス変換段階及びアクセス権の確認段階の間に使われるであろう、コンシューマの数あるいは所有者の識別子のような、バッファに関連する情報を記憶する。

図５はバッファの開放を可能にする、本発明によるＦｒｅｅ＿ｄａｔａタイプの例示的要求１２を構造図で例証している。メモリ空間の動的管理は、バッファがアプリケーションの実行中を通して使用されない場合のみ有意義であり、バッファを出来る限り早く開放することがさらに望ましい。この開放はバッファと関連する全てのメモリ・ページの検索、及びそれら各々の開放を可能にする。バッファのこれらの開放は、バッファの各潜在的コンシューマｎｂ＿ｃｏｎｓｕが、前記バッファの使用をそれが終了したと宣言したときに行われる。これは例えば図５の形式に適合する、要求タイプの識別子００１０の要求Ｆｒｅｅ＿ｄａｔａを介して行われ、そのタスクｉｄ＿ｔａｓｋの使用が終了したバッファｉｄ＿ｄａｔａの識別を可能にする。

変換機能は、例えば図２に表わされている形式を有する仮想アドレスを、メモリに送られ得る物理アドレスへ変換する。これらの変換はメモリから読み取るとき、又はメモリに書き込むとき、システム的及び自動的に行われる。有利なことに、これは取り扱われる仮想アドレスに対応する、物理アドレス用の適切な記憶構造を通じた検索を含み得る。全ての処理ユニットは並列に動作し、共有データに高速でアクセスし、そのとき記憶構造へのアクセスの衝突を避けるように、この変換機能性を各処理ユニットのレベルで分配することが望ましい。本例示的実施形態において、各処理ユニットは変換テーブルを用いる局所変換ユニットを採用し、これらのテーブルは、有利なことに連合したチャートタイプの記憶構造である。従って変換ユニットは最初に、タスク内で取り扱われるデータ項目と、変換テーブルを関連付けることが可能である。次に、この変換テーブルのおかげで、変換ユニットは仮想ページとその物理アドレスとの間の対応が確実にできる。有利なことに、タスクの移送能力及びバッファが幾つかのコンシューマを持ち得るという事実を考慮すると、使用される変換テーブルは、単に保持されてメモリマネージャ１により利用可能な変換テーブルのコピーであり得る。

図６は変換テーブルの取得を可能にする、本発明によるＧｅｔ＿Ｍｅｍｏｒｙ＿Ｍａｐタイプの例示的要求１３を構造図で例証している。事実、タスク内で取り扱われるデータの各々に関して、処理ユニットは全てのページ変換を検索する。要求Ｇｅｔ＿Ｍｅｍｏｒｙ＿Ｍａｐは、１４ビット上にその変換テーブルが要望される、バッファの識別子ｉｄ＿ｄａｔａを含む。これに引き続いて議論される最適化の理由のため、変換テーブルは有利にも縮小された大きさの、幾つかのテーブルへと分割され、各々はコンテクスト番号と関連付けられる。本例において、１０２４個の変換まで含み得るテーブルは、６４回の変換×１６個のコンテクストへと分割される。１８ビット上の領域ｉｄ＿ｃｔｘは、コンテクスト番号の識別を可能にする。メモリマネージャ１は、Ｔｒａｎｓｌａｔｉｏｎ＿ｔａｂｌｅタイプのメッセージ１９により要求された変換テーブルを、処理ユニットへ返す。

データアクセス権を管理する機能性は、例えば一方で、全体としてデータ・バッファの取り扱いの正当性を確認すること、及び他方でデータ・ページへのアクセスの有効性を検証することを可能にする。最初の場合、これはその時タスクがデータをバッファに書き込むのを確かに許可されているという確認に関し、又は場合によりバッファを消費するタスクの数が、オフラインにおいて定義される数を超えないという確認に関することである。データ・ページへのアクセスの有効性確認は、現在書き込まれているページに対して読み取りが生じないこと、又は現在そこから読み取られているページを書き込みが変更しないことの確認により、それに関してデータの完全性の保証を可能にする。アクセス権のこれらの確認は、処理ユニットによりメモリマネージャ１に対して送られる、明確な要求のおかげで行われ得る。これらの要求は新しいページの各々の取り扱いの前に送られる。従って、バッファｉｄ＿ｄａｔａのページｉｄ＿ｐａｇｅのデータを取り扱う前に、読取りか書き込みかに関わらず、タスクｉｄ＿ｔａｓｋを実行する処理ユニットは、その利用可能性を確認するため、メモリマネージャ１に要求Ａｓｋ＿ａｖａｉｌを送る。読み取り利用可能性の要求について、これはデータ項目が既に作られており、もはや変更されないという確認に関することである。書き込み要求について、それはページがもはや読み取られないであろうという確認に関することである。従って、バッファを非同期のタスク間で共有することが可能である。

図７はデータの利用可能性を要求することを可能にする、本発明によるＡｓｋ＿ａｖａｉｌタイプの例示的要求１４を構造図で例証している。既に述べた領域Ｉｄ＿ｄａｔａ、ｉｄ＿ｐａｇｅ、及びＩｄ＿ｔａｓｋに加えて、ビットＲＷは要求が読取りが利用可能か又は書き込みが利用可能かを示す。最後のビットＬａｓｔは最適化のために、要求が一連の利用可能性要求の最後かどうかを示すことを可能にする。これらの要求はタスクのコードにおいて明確であり得る。しかしながら、性能に関する影響力が著しい場合、それらが変換テーブルへの無効なアクセスに続いて、自動的に生成されることが考えられ得る。メモリマネージャ１はＡｓｋ＿ａｖａｉｌ＿ａｃｋタイプの受け取り通知１８を通じて処理ユニットに応答する。

図８はデータの利用を可能にする、本発明によるＳｅｎｄ＿ａｖａｉｌタイプの例示的要求１５を構造図で例証している。配置段階に続いて、メモリバッファの全てのページは、バッファの所有者のタスクに関して書き込みアクセス権を用いて、自動的に初期化される。実行段階の間、これらのページへのアクセス権の展開は他方で、ページを読取りアクセス可能に又は書き込みアクセス可能にするように、明確に管理される。要求Ｓｅｎｄ＿ａｖａｉｌは、処理ユニットがもはやバッファｉｄ＿ｄａｔａのページｉｄ＿ｐａｇｅのデータを変更しないであろうことを示すために、タスクｉｄ＿ｔａｓｋを実行する処理ユニットにより送られる。メモリマネージャ１は次に、バッファｉｄ＿ｄａｔａのｎｂ＿ｃｏｎｓｕ読取り装置に読取りアクセス権を与え、処理ユニットの変換ユニットは、このページと関連する変換行を無効にする要求を送る。

図９はページの開放を可能にする、本発明によるＳｅｎｄ＿ｆｒｅｅタイプの例示的要求１６を構造図で例証している。Ｓｅｎｄ＿ｆｒｅｅ要求は、処理ユニットがもはやバッファｉｄ＿ｄａｔａのページｉｄ＿ｐａｇｅにアクセスしないであろうことを示すために、タスクｉｄ＿ｔａｓｋを実行する処理ユニットにより送られる。ページのコンシューマｎｂ＿ｃｏｎｓｕの数は、そのとき減少する。後者が０に達したとき、このページの潜在的なコンシューマはもはや存在せず、メモリマネージャ１は書き込むために、再度それを利用できるようにする。

図１０はバッファの所有者のタスク変更を可能にする、本発明によるＣｈｏｗｎ＿ｄａｔａタイプの例示的要求１７を構造図で例証している。消費タスクが大きな集合内で非常に少ない数のデータ、例えば画像内の僅か数画素のみを変更する場合、先行技術の基本的な実行モデルは、しばしば全体のデータの集合の完全なコピーを新しいバッファ内へ生じさせる。データコピーの時間を最小化するため、変更されたデータのみを書き直すように、開始バッファを再使用することが考えられる。この場合、コンシューマ・タスクは何ら新たなバッファを作らないが、プロデューサ・タスクはそれが終了するとき、バッファｉｄ＿ｄａｔａの最初の所有者のｉｄ＿ｔａｓｋ及び、１０ビット上でこのバッファの新たな所有者のｉｄ＿ｎｅｗ＿ｔａｓｋを指定する、要求Ｃｈｏｗｎ＿ｄａｔａを介してそれに書き込みアクセス権を与える。このタイプのメカニズムは、それが注意深く使用されない場合は、ロックアップをもたらす傾向があることに注意されたい。コードの生成環境が、問題を生じる場合の無いことを保証するとき、それは局所的にのみ使用されるべきである。

図１は又その割り当てを最適化するように、タスクマネージャ２に返された情報を例証している。例えば、２つのブロック２０及び２１はタスクマネージャ２に返されたエラーメッセージを１つにまとめる。処理ユニット３のレベルで待機を制限するように、一定のメッセージがタスクマネージャ２によって利用され得る。情報の最も有用な項目は要求Ａｓｋ＿ａｖａｉｌの後に続く待機、あるいはバッファの充填の割り当て数量である。しかし、例えば不正アクセス、異常に長い待機、メモリ容量オーバーフロー、あるいは識別されていないバッファにアクセスする試みのような、潜在的エラーは非常に多くある。

メモリマネージャ１はメモリのクラスタにおける、データ転送活動の核にある。結果として、その性能はシステム全体の性能に対して一番の影響力を有する。メモリマネージャ１のアーキテクチャは、結果としてその処理時間を最適化するように定義される。特に、データ・ページへのアクセス権の管理のような頻繁な動作は、望ましくは１周期のオーダーの反応性を認可するように処理される。システムの全体性能において、あまり重大な条件ではないが、割り当て作業は又それらの処理が、処理ユニットにおけるタスクの初期化に必要な時間（数百周期のオーダー）の大幅な増加をもたらさないように、最適化される。

本発明によるメモリ内の動的データ配置はさらに、クラスタのメモリ空間を十分に利用することを可能にする。このために、メモリマネージャ１は、計算タスクに対して完全に透過的な方法でデータの断片化を可能にする。メモリのアクセス時間はさらに、メモリに同時にアクセスしている集合３内の処理ユニット数に依存しており、割り当てはメモリを共有しているバッファの数を最小化することにより、メモリへの並列アクセスのリスクを最小限にする。従って、メモリへの競合するアクセスの数は、アプリケーションによって誘起されるデータへのアクセスの最大の並列性（バッファのコンシューマの数）を一般に超えない。

メモリマネージャ１に関連する性能の制約にも関わらず、このモジュールの複雑さ及びシリコン・コストを抑制することが重要である。メモリマネージャ１のアーキテクチャは、従って取り扱われるデータの量を最小化し、標準のメモリ要素の使用を促進するように定義される。

メモリマネージャ１の核心である、バッファ管理用のモジュールは、データ・バッファを動的に利用できるメモリ資源内に置く。動的メモリ管理の解決策における文献は豊富であるが、本発明はデータ近接性の制約に悩むことのない独自の状況を考慮している。事実、文献に記述されている全ての解決策は、十分に大きな隣接メモリ空間内にデータの集合を置くように試みる。配置モジュールの目的はそれゆえ、一般的な場合、割り当ての性能とメモリ占有との良好な妥協を見出すことを含む。本発明のコンテクストにおいて、データ・バッファは、幾つかの不連続なメモリ領域にわたって分布するように容易に分割され得る。これは従ってメモリ空間の完全な利用を保証することを可能にする。

従来のやり方において、メモリ内のｎｂ＿ｐａｇｅのバッファの配置は、ｎｂ＿ｐａｇｅの回数の繰り返し、メモリ内の空きページを探す演算、そして次にこの空きページをデータ・バッファに割り当てることを含む。この演算は空きページ・リスト又はメモリ空間のページ用の状態レジスタに基づく。第１の場合、二重連結リストは、各演算に対して大量のメモリを費やして、利用できる最初のページを迅速に検索することを可能にする。状態レジスタの場合、メモリの量は最小であるが、空きページ検索加速演算子（優先度付き符号化器）が存在しない場合、空きページを探す演算は長くなり得る。両方の場合において、配置時間は配置されるページ数に比例し、バッファの記憶を可能にするページは、クラスタの様々なバンクにわたって分配される。

このように生み出されるメモリデータの断片化は、しかしながら、幾つかのデータ・バッファ間のメモリの共有をもたらす。それゆえ、バッファはもはやバッファのコンシューマ／プロデューサの数（アプリケーションデータ項目）によって大きさを決められないため、バッファへのアクセスにかかる時間を予測するのは難しくなる。今や、データ項目へのアクセスにかかる時間は、前記データを記憶するメモリからの／への、読み込み側／書き込み側の数に依存し、従ってもはや実行時点では正確に知られ得ない。しかるべき場所に置かれる割り当ての方策は、それゆえ単一のデータ・バッファのみを記憶するメモリの数を最大にすることにより、メモリの断片化を遅らせることを目的とする。好適なやり方において、この配置段階を加速するようにメモリ内に幾つかのページを同時に置くことにより、データはさらにブロックとして割り当てられるであろう。

メモリ内のバッファの独自性を特別扱いするために、採用される方策は特にクラスタのバンクの部分が幾つかのデータ・バッファ間で共有されるのを受け入れることである。バッファが完全なメモリを用意しておくことが出来ないとき、バッファは従って、幾つかのバッファを収容できるメモリの量を増加させないように、これらのメモリ上に優先的に置かれるであろう。一定のメモリのこの犠牲は従って、幾つかのバッファと関連するメモリの数の増加を避け、それゆえメモリ空間の漸進的な断片化を防止することを可能にする。この方策はバッファ識別子ｉｄ＿ｄａｔａ及び、付録（ＡＮＮＥＸ）に示すようなバッファｎｂ＿ｐａｇｅｓのページ数をパラメータとして取る、メモリバッファ配置アルゴリズムにより変換される。

前述のアルゴリズムはバッファが有効であるか、又は配置が正しく進んでいるかどうかを確かめるためのテストを何ら行わない、単純化されたバージョンである。最初に、バッファｉｄ＿ｄａｔａのデータのｎｂ＿ｐａｇｅｓはＮｂＭ＋１組のページとして分配され、ここでＮｂＭはバッファの一部分により完全に満たされ得るメモリの数に相当する。Ｎｂｐはそれ自体でメモリを満たすには不十分な、ＮｂＭ＋１番目の集合内に残るページ数である。その後に、３２ページ（我々の例におけるメモリの大きさ）の各組に対して、アルゴリズムは空きメモリを探し、成功した場合はＡｓｓｉｇｎ＿Ｐａｇｅ機能を介して、メモリの各々のページをバッファに割り当てる。完全に空きメモリが利用できない場合、集合の各ページは完全に満たされていないメモリの空きページ内に別々に置かれる。メモリを完全に満たせないＮｂｐページは、部分的に満たされた（又は完全に満たされていない）メモリ上へ好都合なやり方で逆にマッピングされる。部分的に満たされたメモリがもはや存在しない場合、空きメモリが用いられるであろう。

図１１はデータ・バッファ配置用の要求Ｄａｔａ＿Ａｓｓｉｇｎｍｅｎｔを処理するための、本発明によるメモリマネージャ１の例示的動作をアクティビティ図で例証している。有利なことに、本例において３２のメモリバンクの各々に対し、３２ビットのレジスタはそれが含む３２ページの各々の充填状態を特徴付けることができ、１つのビットは空きに対して「１」に等しく、そうでなければ「０」に等しい。有利なことにここで再び、３２ビットのレジスタは３２のメモリバンクの各々に対し充填状態を特徴付けることができ、１つのビットは空きに対して「１」に等しく、そうでなければ「０」に等しい。有利なことにここで再び、３２ビットのレジスタは３２のメモリバンクの各々の空き状態を特徴付けることができ、１つのビットは部分的な充填に対して「１」に等しく、そして（そうでなければ）「０」に等しい。従って３２ビットのレジスタ３４個が本例示的実施形態において全体として使用される。バンクに関する充填状態レジスタ及び空き状態レジスタに含まれる情報は、ページ状態レジスタの内容に基づいて、有利なことにそれぞれＡＮＤ関数及びＸＯＲ関数のおかげで自動的に更新され得る。空きである又は部分的に満たされたメモリの検索はそのとき、バンク状態レジスタにおいて１周期で最初のビットを１に決定できる、３２ビットの優先度付き符号化器を介して行われ得る。

この情報に加えて、メモリマネージャ１はまたバッファに関連する全ての情報：その所有者、それに基づいてメモリマネージャ１がバッファの状態をタスクマネージャ２に知らせなければならない、そのコンシューマの数及び場合によりページ数：を記憶する、ＩＮＦＯ＿ｂｕｆと呼ばれるメモリを取り扱う。このメモリは、バッファ識別子ｉｄ＿ｄａｔａのおかげでアドレス指定され、そして「連想メモリ」を表わす頭字語によるＣＡＭタイプの連想メモリＣＡＭ＿ｂｕｆと関連し、ＣＡＭ＿ｂｕｆはバッファの識別子と、ＩＮＦＯ＿ｂｕｆ内でそれと関連する情報を記憶するためのアドレスとの間のリンクを形成する。メモリＳｈａｒｅｄ＿Ｔｓｌ＿Ｍｅｍもまた、仮想のページ番号に従って命令される連結リストの形で、物理アドレスへ仮想アドレスの変換に有用な情報を記憶するために使用される。

図１２は本発明の実施を可能にするメモリ領域の一例を、構造図で例証している。変換リストの開始アドレスは、データ・バッファと関連する情報項目であり、図１２に例証されるようにＩＮＦＯ＿ｂｕｆメモリ内に記憶される。この変換リスト内の幾つかの入り口点は、データ項目と関連する変換リストが幾つかのコンテクストへと分割される場合、ＩＮＦＯ＿ｂｕｆにおいて指定され得ることに注意されたい。最後に、書き込みアクセス権を用いてデータ・ページへのアクセス権を初期化するために、最終メモリＲｉｇｈｔ＿Ｍｅｍが取り扱われる。

配置要求が失敗した場合、すなわち配置要求がまだ確認応答されていないが、空きページがそれ以上存在しない場合、エラーはタスクマネージャ２に知らされることに注意されたい。この場合の発生する主なリスクは、メモリ予約要求がバッファ配置要求に先行していないかどうかである。バッファを格納するために十分なメモリ空間がタスクｉｄ＿ｔａｓｋ用に用意されているかを、より早期に確かめることが可能であろう。これは、データ配置要求を待っている保留タスクのリストが、メモリマネージャ１により更新され続けていることを想定している。

メモリ空間の予約は、メモリマネージャ１に対して局所的であって、クラスタ上で利用できるメモリ・ページの数を示す、変数ａｖａｉｌａｂｌｅ＿ｐａｇｅｓを用いて非常に簡単に行われる。タスクｉｄ＿ｔａｓｋ用のｎｂ＿ｐａｇｅｓに関する予約要求を受けて、メモリマネージャ１は利用できるページが十分あることを確かめ、可能ならばそれらを予約する。ａｖａｉｌａｂｌｅ＿ｐａｇｅｓからのｎｂ＿ｐａｇｅｓの単純な減算は、任意の配置要求に予約要求が先行する限り、この予約を可能にする。

図１３はデータ・バッファを開放する要求Ｆｒｅｅ＿ｄａｔａを処理するための、本発明によるメモリマネージャ１の例示的動作を、アクティビティ図で例証している。バッファ開放要求Ｆｒｅｅ＿ｄａｔａ（ｉｄ＿ｄａｔａ、ｉｄ＿ｔａｓｋ）を受けて、メモリマネージャ１は最初に、メモリＩＮＦＯ＿ｂｕｆ内のこのバッファに関係する情報を読み取る。データ識別子ｉｄ＿ｄａｔａが未知の場合、又はバッファの読み取りアクセスが出来ない場合、エラーがタスクマネージャ２に返される。逆の場合、このバッファと関連するコンシューマｎｂ＿ｃｏｎｓｕの数は減少する。それが０に達した場合、このデータ・バッファと関連するメモリ・ページはそのとき
バッファ用に使用される物理ページのＳｈａｒｅｄ＿Ｔｓｌ＿Ｍｅｍ内に記憶されたリストを走査することにより、１つずつ解放される。リストの各要素と関連する領域は、リストの最後の要素の識別と、それゆえ開放ループを終了させることを可能にする。

図１４はデータ・バッファの所有者を変えるための要求Ｃｈｏｗｎ＿ｄａｔａを処理するための、本発明によるメモリマネージャ１の例示的動作を、アクティビティ図で例証している。ここで、バッファが確実に参照され、要求の送信者が確かにバッファの所有者であることを注意することにより、これは単に要求の妥当性確認に関することである。要求が妥当である場合、それはＩＮＦＯ＿ｂｕｆメモリ所有者領域の変更によって処理される。

図１５は集合３の処理ユニット３ａ用の物理アドレスへの、仮想アドレスの変換を確実にする、本発明による例示的変換ユニットを構造図で例証している。これらの変換は、図１５に例証されるメカニズムに従ってメモリから読み取り、メモリに書き込むとき、システム的且つ自動的に行われる。変換を行うために使用される基本要素は、本例示的実施形態においては１０２４個の入力を含む変換テーブルであり、これはページ数で表わされたクラスタの記憶容量に相当する。このテーブルは、現在処理ユニットにおいて実行されているタスク内で取り扱われる各アドレスに有用な変換を含む。変換テーブルは標準メモリＴｓｌ＿＄に基づいて構築される。この変換テーブルのローディングは、読み取りモードと書き込みモードの両方で、タスク内において取り扱われる各バッファ用に送られる要求Ｇｅｔ＿Ｍｅｍｏｒｙ＿Ｍａｐ（ｉｄ＿ｄａｔａ、ｉｄ＿ｃｔｘ）に続いて、タスクの初期化の際に行われる。この要求を送る際、処理ユニットの変換ユニットは、バッファがＣＡＭタイプの連想メモリ内に連続的に保存されることを知っているので、そこからバッファの変換テーブルがメモリＴｓｌ＿＄内に保存されるであろう、アドレスをバッファｉｄ＿ｄａｔａ用に指定することにより、ＣＡＭタイプの連想メモリを満たす。

図１６は変換テーブル移動要求Ｇｅｔ＿Ｍｅｍｏｒｙ＿Ｍａｐを処理するための、本発明によるメモリマネージャ１の例示的動作を、アクティビティ図で例証している。要求Ｇｅｔ＿Ｍｅｍｏｒｙ＿Ｍａｐ（ｉｄ＿ｄａｔａ）を受けて、メモリマネージャ１は一方で要求の有効性を確認し、他方でバッファｉｄ＿ｄａｔａ用に使われる物理ページの順序付けられたリストを走査する。要求のｉｄ＿ｃｔｘ領域は、用いられているこの例にはないが、最適化の枠組み内にあり得ることに、ここで注意されたい。これらの演算と並列に、要求を開始した処理ユニットの変換ユニットは、新たな物理ページ番号の各受信の際に書き込みアドレスを増加させることにより、メモリＴｓｌ＿＄を満たす。従って、メモリＴｓｌ＿＄は仮想アドレス番号に従って順序付けられた変換のリストを含む。それゆえ、メモリＴｓｌ＿＄の各ワードは、メモリ内のワード位置に等しい仮想アドレスに対応する物理ページ番号を含む。この仮想アドレスは、バッファｉｄ＿ｄａｔａの変換テーブルのメモリＴｓｌ＿＄内の基本アドレスを、このバッファ内で取り扱われるページを記述する仮想ページ番号Ｎｕｍ＿ｐａｇｅ＿ｖに加えることにより得られる。このレベルにおける可能な最適化は、この追加をコンパイル時に行うことである。処理ユニット内で取り扱われるアドレスの高次重みは、そのときデータ項目の識別子の合計及び仮想ページ番号の合計であり、それによってこの追加をハードウェア的に行うのを控えることを可能にする。ＣＡＭタイプのメモリはそれ自体として、タスク内の操作可能なバッファと同じだけの入力を含む。

メモリマネージャ１の最後の要素は、データへのアクセス権の管理を可能にし、従って取り扱われるデータの完全性の保証を可能にする。それはデータ項目が作られる前に読み込まれず、逆にその読み込み中に変更されないことを確実にするために用いられる。それは取り扱われるデータ・ページの現在の権限に応じて、処理ユニットから発行された要求Ａｓｋ＿ａｖａｉｌに対処する。それはまた要求Ｓｅｎｄ＿ｆｒｅｅ及びＳｅｎｄ＿ａｖａｉｌに続く、これらのページへのアクセス権を更新する。本例示的実施形態において、ブロッキング要求が考えられることに注意されたい。しかしながら、全体的な利用可能性の要求の処理は最適化の枠組み内で考慮され得る。

図１７は利用可能性を依頼する要求Ａｓｋ＿ａｖａｉｌを処理するための、本発明によるメモリマネージャ１の例示的動作を、アクティビティ図で例証している。これは単に、データ・ページａｄｄｒ＿ｄａｔａに要望されるアクセスのモードと、メモリＲｉｇｈｔＭｅｍ内に記憶されたこのページへのアクセス権との比較に関することである。ページにアクセスできない場合、例えばページが書き込み要求中に読み取られている場合又はその逆の場合、要求を送る処理ユニットは待機状態に置かれ、要求は待ち行列の要求ｐｅｎｄｉｎｇ＿ｒｅｑｕｅｓｔ内に置かれる。逆の場合、データ・バッファに関連するページ数は更新され、場合によってはバッファを割り当て数量超過に至らせる。後者の場合、バッファの充填状態が、場合によっては可能性のある使用の観点から、タスクマネージャ２に補充される。書き込みに関しては、要求Ａｓｋ＿ａｖａｉｌのＲＷ領域は１に等しく、さもなければ０に等しい。

図１８はページを読み取り利用可能にする要求Ｓｅｎｄ＿ａｖａｉｌを処理するための、本発明によるメモリマネージャ１の例示的動作を、アクティビティ図で例証している。要求Ｓｅｎｄ＿ａｖａｉｌを受けて、データ・バッファｉｄ＿ｄａｔａが既知であり、そして要求がこのバッファの所有者ｉｄ＿ｔａｓｋによって送られていることが最初に確認される。ページがまだ読み取り利用可能でないことも又確認され、その場合ページａｄｄｒ＿ｐａｇｅにアクセス権を変更する前に、エラーがタスクマネージャ２に返される。このバッファと関連する書き込みページ数もまた減少し、割り当て数量の確認は、バッファの充填状態を場合によってはタスクマネージャ２に事前警告するために行われる。最後に、待機要求のリストは、タスクが既にページの読み取り利用可能性について依頼されたかどうかを確認するために走査され、その場合、その要求は確認応答され得る。この待機要求リストの走査は、それが逐次的であるため比較的長くなり得ることにこれ以降注意されたい。３２のタスクが同時にアクティブであり得ると想定される場合、少なくとも３２周期の最悪の場合における走査時間が、実際に考慮されなければならない。この検索は最適化の枠組み内で加速され得る。

図１９はページを開放し、それゆえ書き込み利用可能にすることを目指す、ページの開放要求Ｓｅｎｄ＿ｆｒｅｅを処理するための、本発明によるメモリマネージャ１の例示的動作を、アクティビティ図で例証している。要求Ｓｅｎｄ＿ｆｒｅｅを受けて、メモリマネージャ１はデータ・バッファｉｄ＿ｄａｔａが既知であり、そしてページがまだ書き込み利用可能でないことをそれ自体で確実にすることにより、要求の妥当性を確認し、その場合エラーがタスクマネージャ２に返される。これ以降、ページと関連するコンシューマの数は減少する。それが０に達した場合、ページは解放され、書き込みアクセスに関して利用可能になる。待機要求のリストは、待機タスクがアドレスａｄｄｒ＿ｐａｇｅにおいて、書き込みに対し利用可能なページを待っているかどうか確認するため次に走査され、その場合、その要求は確認応答され得る。

タスクが幾つかのページに対してアクセス権を連続して要求するとき、不要なプロセッサの再開を避けるため、全ての要求されたページが利用可能なときのみ確認応答される、「全体的な」すなわちバッファの幾つかのページに関する、利用可能性要求をしかるべき場所に置くことが可能である。そのようなメカニズムは、タスクの利用可能性に関する要求を逐次的よりもむしろ全体的に処理することを可能にし、要求のＬａｓｔ領域により識別される一連の最後の要求Ａｓｋ＿ａｖａｉｌのみをブロックする状態にする。メモリマネージャ１のレベルにおいて、このタイプの要求をしかるべき場所に置くことは、最後の要求Ａｓｋ＿ａｖａｉｌの処理がＬａｓｔビットを１に設定した間に、ｐｅｎｄｉｎｇ＿ｒｅｑｕｅｓｔリストの走査を必要とする。これはタスクｉｄ＿ｔａｓｋの別の要求Ａｓｋ＿ａｖａｉｌが、何ら誤っていないこと及び、従ってタスクｉｄ＿ｔａｓｋが、待ち行列の要求ｐｅｎｄｉｎｇ＿ｒｅｑｕｅｓｔから欠けていることの確認を含む。確認応答される前に、要求Ａｓｋ＿ａｖａｉｌは待機要求の１つが、要求を送っているタスクに属さないかどうかを確認するために、それゆえ全ての待機要求のリストを走査する必要があるであろう。最適化が無ければ、３２のアクティブなタスク、及び全体の利用可能性要求当り１６までの要求Ａｓｋ＿ａｖａｉｌを考えた場合、５１２周期以上が考慮される必要があるため、この時間は非常に長くなり得る。これら５１２周期は要求Ｓｅｎｄ＿Ｆｒｅｅ及び要求Ｓｅｎｄ＿ａｖａｉｌの間と同様に、最後の要求Ａｓｋ＿ａｖａｉｌの各々に対して発生する。従って、データアクセス権の管理に関連する時間的不利益を阻止するために、確認応答を待っているこの待機要求リストの走査は最適化されるべきである。追加のシリコン・コストを伴わない第１の最適化は、読み取り要求と書き込み要求の行列を単純に切り離すことである。検索をさらに加速するため、要求を送るタスクに応じて検索行列を識別することが可能である。走査されるべき適切な検索行列に対する検索に必要なロジックは、そのとき更に付け加えられる。これは全体の利用可能性要求が確認応答され得るかどうかを殆ど瞬時に決定可能にするが、しかし他方で要求Ｓｅｎｄ＿ａｖａｉｌ及びＳｅｎｄ＿Ｆｒｅｅの処理を加速しない。加速されるためには、取り扱われるデータ・バッファに応じて別の利用可能性要求リストが更新され続ける必要があり、そしてデータ識別子に応じた適切なリストを検索するロジックが実行される必要がある。

上述の本発明の主要な利点は、非同期の生産タスクと消費タスクとの間で、バッファを共有するための最適化されたメカニズムを提案することである。

Claims (15)

1. 複数のメモリ要素にわたり分配されたメモリ空間内でデータ・バッファを管理する装置であって、
   前記メモリ空間がメモリ・ページによって割り当て可能であり、各バッファが１つ以上のメモリ・ページを含み、前記バッファがアプリケーション実行用の少なくとも１つの処理ユニット（３ａ）によって使用可能であり、前記アプリケーションがタスクを並列に実行する複数の処理ユニット（３）により実行され、メモリ要素が前記処理ユニットにより並列にアクセス可能であり、前記装置が前記アプリケーションの実行中にバッファ（１）を前記タスクに割り当てる手段と、前記バッファへのアクセス権を管理する手段とを含み、前記装置は、前記バッファを非同期のタスク間で共有するような方法で、所与のページへの書き込みが、前記ページから現在読み込まれているデータを修正しないこと、又は所与のページからの読み取りが、前記ページに現在書き込まれているデータにアクセスしないことを確認するために、前記バッファへの前記アクセス権を管理する前記手段が、所与のバッファ内のページへのアクセス権を管理する手段を含むことを特徴とする装置。
2. バッファ（１）を割り当てる前記手段が、同一のメモリ要素に割り当てられたバッファの最大の数を最小限にするような方法で、前記バッファを割り当てることを特徴とする請求項１に記載の装置。
3. バッファ（１）を割り当てる前記手段が、メモリ・ページの充填状態レジスタを含み、所与のレジスタ内の所与のビットが、所与のメモリ・ページの空き状態又は空きでない状態を特色付けることを特徴とする、請求項１に記載の装置。
4. バッファ（１）を割り当てる前記手段が：
   − 所与のレジスタ内の所与のビットが、所与のメモリ要素の空き状態又は空きでない状態を特徴付ける、メモリ要素の充填状態レジスタ及び／又は、
   − 所与のレジスタ内の所与のビットが、所与のメモリ要素の部分的に満たされた状態又は部分的に満たされていない状態を特徴付ける、メモリ要素の空き状態レジスタ
   を含むことを特徴とする請求項１に記載の装置。
5. バッファ（１）を割り当てる前記手段が、
   − 前記メモリ要素の充填状態レジスタの更新を加速するような、メモリ・ページの充填状態レジスタにおける、ＡＮＤタイプ及び／又は、
   − 前記メモリ要素の空き状態レジスタの更新を加速するような、メモリ・ページの充填状態レジスタにおける、排他的なＯＲタイプ
   の論理演算を行う手段を含むことを特徴とする、請求項３または４のいずれか一項に記載の装置。
6. バッファ（１）を割り当てる前記手段が、前記メモリ要素の充填状態レジスタ及び空き状態レジスタ内に、１周期で最初のビットを１に決定可能にする、優先度付き符号化器を含むことを特徴とする請求項４に記載の装置。
7. バッファ内に含まれるデータの物理アドレスが、前記バッファが割り当てを解除されて次にアプリケーションの実行の過程で再度割り当てられる場合に可変であり、前記処理ユニット（３ａ）が前記アプリケーションを実行するために不変の仮想アドレスを使用し、そして装置が仮想アドレスを物理アドレスへと変換する手段を含むことを特徴とする、前記アプリケーションの実行中にバッファ（１）を割り当て解除する手段を備えた、請求項１に記載の装置。
8. 前記仮想アドレスを物理アドレスへと変換する前記手段が、仮想アドレスと物理アドレスとの間の対応を記憶するための、少なくとも１つの構造を含むことを特徴とする、請求項７に記載の装置。
9. 所与のバッファ内に含まれるデータの、前記仮想アドレスと前記物理アドレスとの間の対応が、前記バッファに専用の１つ以上の構造内に記憶されることを特徴とする、請求項８に記載の装置。
10. 前記仮想アドレスを物理アドレスへと変換する前記手段が、各処理ユニット内の記憶構造のコピーを含むことを特徴とする、請求項７に記載の装置。
11. 前記バッファへのアクセス権を管理する手段が、所与のバッファへのデータ書き込みを所与のタスクが認可されていることを確認する手段を含むことを特徴とする、請求項１に記載の装置。
12. 前記バッファへのアクセス権を管理する手段が、所与のバッファから読み取るタスクの数が所定のしきい値を超えない旨を確認する手段を含むことを特徴とする、請求項１に記載の装置。
13. 前記バッファへのアクセス権を管理する手段が、バッファに書き込む権限をタスクから引き出す手段と、前記バッファに書き込むための別のタスクを認可する手段とを含むことを特徴とする、請求項１に記載の装置。
14. バッファを割り当てる前記手段が、利用可能なメモリ空間が所与のバッファを割り当てるのに十分であると確認する手段を含むことを特徴とする、請求項１に記載の装置。
15. バッファを割り当てる前記手段、及びページへのアクセス権を管理する前記手段が、単一の割り当て要求で、所与のバッファ内の数ページを所与のタスクへと割り当て可能にすることを特徴とする、請求項１に記載の装置。

Images