JP2010026729A - プロセス間通信装置、プロセス間通信方法 - Google Patents

Abstract

【課題】実行速度の低下や過分なバッファ容量の消費をもたらさずに、また、プロセス間通信のリソース管理に伴う負荷が低減されるプロセス間通信装置等を提供すること。
【解決手段】パーティションメモリ毎にメモリを管理するメモリ管理ユニットを備えたプロセス間通信装置であって、スレッドＡが使用したデータを用いて、スレッドＢを実行する際、スレッドＡがデータを記憶するためのバッファメモリ８０のエントリを、スレッドＡに対応するパーティションメモリＡのテーブルＡ１１に登録して、該エントリの仮想アドレスをスレッドＡに通知するページ確保手段２１と、テーブルＡからバッファメモリのエントリを削除し、スレッドＢに対応するパーティションメモリＢのテーブルＢ１２に、バッファメモリのエントリを登録するエントリ付け替え手段２２と、テーブルＢに登録されたエントリの仮想アドレスをスレッドＢに通知するアドレス通知手段２３と、を有することを特徴とする。
【選択図】図４

Description

本発明は、プログラムから生成された複数のスレッドをCPUコアがそれぞれ実行するプロセス間通信装置等に関し、特に、スレッド間が通信することができるプロセス間通信装置及びプロセス間通信方法に関する。

実行時間の保証が求められるアプリケーションは、予め定められた実行順に従って処理される逐次実行より、複数の処理が並列に実行できるように設計される。この処理の処理単位はスレッド、タスク又はプロセス等（以下、単にスレッドという）と呼ばれ、リアルタイムＯＳ等のＯＳが実行の同期、共有リソースに対する排他制御、プロセス間通信等を提供することで、複数のタスクが並行に処理されている。

プロセス間通信として、共有メモリ、メッセージキュー及びパイプ等（以下、単にＩＰＣ（Inter Process Communication）という）通信が知られている（例えば、特許文献１参照。）。特許文献１には、一方のスレッドの実行結果が保存された実行結果を他方のスレッドを実行するスレッド実行部のバッファに転送することで、スレッド間で実行結果を共用するマルチスレッド実行方法が記載されている。

また、このようなＯＳが提供するＩＰＣ通信を利用せずにＩＰＣ通信する技術が提案されている（例えば、特許文献２参照。）。特許文献２には、メモリ上に、スレッドが直接マッピング可能な直接マップ領域を獲得し、そのスレッドが指定する直接マップ領域内の領域を示す物理アドレスによって、該プロセスの仮想メモリ領域から直接マップ領域に直接マップすることができるメモリマップ方法が開示されている。仮想メモリから物理メモリに直接マッピングできるので、スレッド間で直接マップ領域を共有することができる。

ところで、スレッド間で共用したいデータを除けば、スレッド間で制約なしにメモリにアクセスすることは好ましくない。このため、計算機には、スレッドが要求するメモリアクセスを処理するメモリ管理ユニットが搭載されており、メモリ管理ユニットが仮想アドレスから物理アドレスへの変換、メモリ保護等を実現している。

メモリ管理ユニットでは例えばメモリをページ単位に分割しページ単位毎に、更新禁止など属性を設定するなどして、複数のタスクによる同じページへのアクセスを制限している（例えば、特許文献３参照。）。特許文献３には、タスク毎にテキストセグメント、データセグメントのアドレス空間を割り当てることで、メモリ管理ユニットによるアクセス保護を実現するタスク管理装置が開示されている。
特開２００３−３００５０号公報 特開２００３−３３７７１４号公報 特開平１０−２８９１５８号公報

しかしながら、特許文献１に記載されたコピー方式のＩＰＣでは、ＯＳのマイクロカーネル（汎用性の高い機能だけを含むＯＳの中核部分）がコピーを実行するため、カーネル処理時間がスレッドの実行速度に影響を及ぼすという問題がある。また、コピー方式ではコピー元とコピー先に同じ容量のバッファが必要になるため、計算上、通信データ量の２倍のバッファ容量が必要になるという問題がある。

また、特許文献２記載のような共有メモリ方式の場合、プロセス間通信にマイクロカーネルは関与せず、また、バッファ容量は通信データ量と同程度であるが、別途、イベント通知機能などを併用したリソース管理を行わないと、送り元と送り先でデータの不一致が発生するおそれがあるという問題がある。

本発明は、上記課題に鑑み、実行速度の低下や過分なバッファ容量の消費をもたらさずに、また、プロセス間通信のリソース管理に伴う負荷が低減されるプロセス間通信装置及びプロセス間通信方法を提供することを目的とする。

上記課題に鑑み、本発明は、メモリの１ページ単位で物理アドレスと仮想アドレスとを対応づけるエントリを、プログラムから生成された複数のスレッドに対応するパーティションメモリ毎のテーブルに登録して管理する、プロセス間通信装置であって、スレッドＡが使用したデータを用いて、スレッドＢを実行する際、スレッドＡがデータを記憶するためのバッファメモリのエントリを、スレッドＡに対応するパーティションメモリＡのテーブルＡに登録して、該エントリの仮想アドレスをスレッドＡに通知するページ確保手段と、テーブルＡからバッファメモリのエントリを削除し、スレッドＢに対応するパーティションメモリＢのテーブルＢに、バッファメモリの前記エントリを登録するエントリ付け替え手段と、テーブルＢに登録されたエントリの仮想アドレスをスレッドＢに通知するアドレス通知手段と、を有することを特徴とする。

エントリを付け替えバッファメモリのデータをコピーすることなくＩＰＣ通信するので、実行速度の低下することなくまた消費するバッファ容量も１ページ分に限定できる。また、共用メモリにデータを格納したわけでないので、イベント通知などのリソース管理も不要である。

実行速度の低下や過分なバッファ容量の消費をもたらさずに、また、プロセス間通信のリソース管理に伴う負荷が低減されるプロセス間通信装置及びプロセス間通信方法を提供することができる。

以下、本発明を実行するための最良の形態について図面を参照しながら説明する。
図１は、本実施形態のプロセス間通信装置１００によるプロセス間通信方法の概略を説明する図の一例である。プロセス間通信装置１００は、メモリ管理ユニット（以下、ＭＭＵ（Memory Management Unit）という）５０により仮想メモリと物理メモリ６０のマッピングを行う。ＭＭＵ５０は、各スレッドが出力する仮想メモリ空間のアドレスである仮想アドレスを、ＴＬＢ（Translation Lookaside Buffer）７０を参照して物理メモリ６０の物理アドレスに変換する。各スレッドは物理メモリ６０の構成を意識することなく、所望のデータにアクセスすることができる。

図のパーティションＡはスレッドＡに対応して確保されたメモリ領域であり、パーティションＢはスレッドＢに対応して確保されたメモリ領域である。各パーティションは、各スレッドの起動時にＯＳ２０が割り当て、一方のスレッドＡが他方のスレッドＢのパーティションにアクセスできないよう、ＭＭＵ５０はパーティション毎に物理メモリ６０を管理する。

ＭＭＵ５０はスレッド毎（パーティション毎）にメモリ管理するので、スレッドＡが物理メモリ６０へのアクセスを要求した場合、ＭＭＵ５０はパーティションＡ用ＴＬＢ１１を参照し、スレッドＢが物理メモリ６０へのアクセスを要求した場合、パーティションＢ用ＴＬＢ１２を参照する。

本実施形態では、ＭＭＵ５０のこの特徴を利用し、ＩＰＣ（Inter Process Communication）通信の際にＩＰＣ用バッファ８０を確保し、ＩＰＣ用バッファ８０を用いてスレッド間でデータを送受信する。例えばスレッドＡがスレッドＢにデータを送信する場合、スレッドＡがＩＰＣ用バッファ８０を確保すると、ＭＭＵ５０が仮想メモリと物理メモリ６０をマッピングするためのＩＰＣ用エントリをパーティションＡ用ＴＬＢ１１に登録する。

スレッドＡが送信用のデータをＩＰＣ用バッファ８０に格納した後、ＩＰＣ用エントリをパーティションＢのパーティションＢ用ＴＬＢ１２に付け替えるようＭＭＵ５０に要求すると、ＭＭＵ５０はＩＰＣ用エントリを付け替える。これにより、ＭＭＵ５０がパーティションＢ用ＴＬＢ１２を参照することで、スレッドＢはＩＰＣ用バッファ８０にアクセスでき、スレッドＡからデータを受け取ることができる。

スレッドＢがデータを受け取るまでの間、スレッドＡが送信用のデータをＩＰＣ用バッファ８０に格納したのみでデータのコピーは行われていない。また、スレッドＡは共用メモリにデータを格納したわけでないので、イベント通知などのリソース管理も不要である。すなわち、通信コストを抑制しながらデータの整合性を確保してＩＰＣ通信することができる。また、送信するデータが多い場合には複数のページのＩＰＣ用エントリを登録することもできる。

図２は、プロセス間通信装置１００の概略構成図の一例を示す。ＭＭＵ５０はＣＰＵコア１３と一体に構成されることが多いが、図では別に示した。また、図ではＣＰＵコア１３は１つであるが、ＣＰＵコア１３は単数でもよく複数（マルチコア）でもよい。物理メモリ６０は、キャッシュメモリを含んだ主記憶メモリであり、例えばＤＲＡＭやＳＲＡＭ等の高速メモリで構成される。

ＣＰＵコア１３は、仮想アドレスとスレッドを識別するスレッドＩＤをＭＭＵ５０に出力する。仮想アドレスは例えばＮビット（例えば３６ビット）であり、このうち上位ａビット（例えば、２４ビット）はＭＭＵ５０に供給され、下位ｂビット（例えば１２ビット）はページ内オフセットとしてアドレス変換の前後で変化しない。

ＭＭＵ５０は、ＣＰＵコア１３から出力された上位ａビットに基づき、ＴＬＢ７０の仮想アドレスを参照し、比較照合され一致した物理アドレスを出力する。この物理アドレスは、ＣＰＵコア１３によって供給される上位ｂビットのオフセットと合成され、物理メモリ６０にアクセスするためのアクセスアドレスとなる。

ＭＭＵ５０は、パーティション毎に区分されたＴＬＢ７０を有し、スレッドＩＤに応じて参照するＴＬＢ７０を切り替える。ＴＬＢ７０は、高速なメモリに展開された例えば連想メモリとして実装される。

図３は、ＴＬＢ７０を模式的に説明する図の一例を示す。ＴＬＢ７０は、パーティションＡ用ＴＬＢ１１，パーティションＢ用ＴＬＢ１２等、パーティション毎に用意され、パーティション毎に仮想アドレスと物理アドレスを対応づけて記憶している。ＴＬＢ７０はページ単位毎にメモリ管理するので、図３の１エントリが１ページ（例えば、４ｋバイト）分のメモリのマッピング情報となる。

ＴＬＢ７０は、参照の局所性を利用して参照頻度の高いエントリ（物理メモリ領域）のみＭＭＵ５０に記憶しており、キャッシュミスが生じると無効ビットを立て、また、所定のロジック（例えば、ＦＩＦＯ、ＬＵＲ）でエントリを置き換える。

図示するように本実施形態では、いずれかのエントリ（例えば、置き換えのためにその時、退避されたエントリ）に、ＩＰＣバッファの仮想アドレス（ＩＰＣ用バッファ仮想アドレス）と物理アドレス（ＩＰＣ用物理アドレス）を対応づけるＩＰＣ用エントリが登録される。

図４は、プロセス間通信装置１００の機能ブロック図の一例を、図５は、パーティションＡ、ＢとＴＬＢ７０の遷移を模式的に示す図の一例である。なお、後述するようにＭＭＵ５０はＯＳ２０（マイクロカーネル）を介して取り扱われるので、図５ではＯＳ２０とＴＬＢ７０を一体に示した。

プロセス間通信装置１００は、複数のスレッドＡ、Ｂが提供する機能と、ＯＳ２０がＭＭＵ５０を制御するために提供する機能と、を有する。図４ではスレッドＡとＢが提供する機能ブロックをそれぞれ示したが、スレッドＡ及びスレッドＢは共通の機能ブロックを備える。

ＭＭＵ５０を制御するのはＯＳ２０のうちでもマイクロカーネルの部分であるので、スレッドＡ、ＢがＯＳ２０に処理を要求する際にはシステムコールを利用する。図４には、システムコールのいくつかの模擬コードを示したが、かかるシステムコードを除けばＯＳ２０がＭＭＵ５０の制御のために本来備える機能を利用できるので、ＩＰＣ通信のためにＯＳ２０が新たに備える機能にかかるコストを最小限に抑制できる。また、スレッドＡ、Ｂが備える機能ブロックは、スレッドＡ、Ｂの実体であるオブジェクトコードに含まれる。

まず、スレッドＡの機能ブロックについて説明する。ＩＰＣ用バッファ確保要求部３１は、ＩＰＣ用バッファ８０を用いてプロセス間通信する際、ＯＳ２０にＩＰＣメモリ用バッファを確保するよう要求する。このシステムコール用のＡＰＩは例えば「Ｉｐｃ_ａｌｏｃ（ｂｕｆ）」である。なお、システムコールの際には、ＯＳ２０にスレッドＡのスレッドＩＤが通知される。

ＯＳ２０が物理メモリ６０にＩＰＣ用バッファ８０を確保すると、スレッドＡのデータ格納部３２はＩＰＣ用バッファ仮想アドレスによりＩＰＣ用バッファ８０を指定して、スレッドＢに送信したいデータを格納する。

データを格納するとデータ送信要求部３３は、ＯＳ２０にデータを送信するよう要求する。このシステムコール用のＡＰＩは例えば「Ｉｐｃ_ｓｅｎｄ（ＤＳＴ、ｂｕｆ）」であり、「ＤＳＴ」に送信先のスレッドＢのスレッドＩＤが格納され、「ｂｕｆ」にプロセス間通信用に確保したＩＰＣ用バッファ８０のＩＤが格納される。

続いて、ＯＳ２０の機能ブロックについて説明する。ＯＳ２０のページ確保部２１は、システムコール「Ｉｐｃ_ａｌｏｃ（ｂｕｆ）」により呼び出されると割込みを発生させ、ＭＭＣ５０に物理メモリ６０の１ページを確保させる。ＭＭＵ５０はパーティションＡ用ＴＬＢ１１の適当なエントリに、確保した物理メモリ６０の物理アドレスと仮想アドレスを登録する。この物理アドレスがＩＰＣ用バッファ物理アドレスとなり、仮想アドレスがＩＰＣ用仮想アドレスとなる。ページ確保部２１はＭＭＵ５０から、ＩＰＣ用バッファ仮想アドレスを取得し、ＩＰＣ用バッファ確保要求部３１に返す。

図５（ａ）に示すように、パーティションＡ用ＴＬＢ１１にはＩＰＣ用バッファ８０のＩＰＣ用エントリが登録されるので、パーティションＡはＩＰＣ用バッファ８０が装着された状態と同等になり、スレッドＡがＩＰＣ用バッファ８０にアクセスすることができるようになる。なお、物理メモリ６０内ではパーティションＡとＩＰＣ用バッファ８０は隣接してない場合が多い。

また、スレッドＡは複数のＩＰＣ用バッファ８０の確保を要求することができる。この場合、「Ｉｐｃ_ａｌｏｃ（ｂｕｆ）」の「ｂｕｆ」により複数のＩＰＣ用バッファ８０を識別する。この複数のＩＰＣ用バッファ８０は、物理メモリ６０の１ページごとに独立に取り扱うことができるので、全てのＩＰＣ用バッファ８０のデータを同一のスレッドＢに送信してもよいし、それぞれを異なるスレッドに送信してもよい。

ＯＳ２０のエントリ付け替え部２２は、システムコール「Ｉｐｃ_ｓｅｎｄ（ＤＳＴ、ｂｕｆ）」に呼び出されると割込みを発生させ、パーティションＡ用ＴＬＢ１１のＩＰＣ用エントリを、スレッドＢが使用するパーティションＢ用ＴＬＢ１２に付け替える。したがって、ＩＰＣ用バッファ仮想アドレスとＩＰＣ用バッファ物理アドレスには変更がない。以降は、アドレス通知部２３がパーティションＢ用ＴＬＢ１２を参照することで、スレッドＢはＩＰＣ用バッファ８０の仮想アドレスを取得することができる。

図５（ｂ）に示すように、パーティションＢ用ＴＬＢ１２にはＩＰＣ用エントリが登録され、パーティションＢはＩＰＣ用バッファ８０が装着された状態と同等になるので、スレッドＢがＩＰＣ用バッファ８０にアクセスすることができるようになる。なお、物理メモリ６０内ではパーティションＢとＩＰＣ用バッファ８０は隣接してない場合が多い。

ＯＳ２０のアドレス通知部２３は、スレッドＢが使用するパーティションＢ用ＴＬＢ１２を参照し、ＩＰＣ用バッファ８０の仮想アドレスであるＩＰＣ用バッファ仮想アドレスをスレッドＢに返す。

ＯＳ２０のページ開放部２４は、次述するシステムコール「Ｂｕｆ＝Ｉｐｃ_ｒｅｃｖ（ＳＲＣ）」に呼び出されると割込みを発生させ、パーティションＢ用ＴＬＢ１２からＩＰＣ用エントリを削除する。これにより、ＩＰＣ用バッファ８０が物理メモリ６０から解放されるので、ＩＰＣ通信が終了した後は物理メモリ６０を占有することもない。

続いて、スレッドＢの機能ブロックについて説明する。スレッドＢが、スレッドＡが送信したデータを必要とした場合、スレッドＢのＩＰＣ用バッファアドレス要求部３４は、ＯＳ２０にＩＰＣ用バッファ８０の仮想アドレスを要求する。このシステムコール用のＡＰＩは例えば「Ｂｕｆ＝Ｉｐｃ_ｒｅｃｖ（ＳＲＣ）」であり、「ＳＲＣ」には送信元であるスレッドＡのスレッドＩＤが、「Ｂｕｆ」にはＩＰＣバッファ８０のＩＰＣ用バッファ仮想アドレスが格納されている。

これにより、スレッドＢのデータ読み込み部３５はＩＰＣ用バッファ仮想アドレスによりＩＰＣ用バッファ８０を指定して、スレッドＡから受け取りたいデータを物理メモリ６０から読み出すことができる。

データを読み出すとスレッドＢのＩＰＣ用バッファ開放要求部３６は、ＯＳ２０にＩＰＣ用バッファ８０を開放するよう要求する。このシステムコール用のＡＰＩは例えば「Ｉｐｃ_ｆｒｅｅ（ｂｕｆ）」であり、「ｂｕｆ」がプロセス間通信用に確保したＩＰＣ用バッファ８０であることを示す。

以上の構成に基づき、プロセス間通信装置１００がプロセス間通信する手順を図６のフローチャート図に基づき説明する。まず、ＩＰＣ用バッファ確保要求部３１は、ＯＳ２０のマイクロカーネルにシステムコール（ＩＰＣ＿ａｌｏｃ（ｂｕｆ））を発行することで、ＩＰＣ用バッファ８０を確保するよう要求する（Ｓ１０）。

ＯＳ２０のページ確保部２１は、物理メモリ６０にＩＰＣ用バッファ８０を確保し、そのＩＰＣ用バッファ仮想アドレスをスレッドＡに返し（Ｓ２０）、スレッドＡのＩＰＣ用バッファ確保要求部３１はそれを取得する（Ｓ３０）。

スレッドＡのデータ格納部３２は、ＩＰＣ用バッファ仮想アドレスで指定されるＩＰＣ用バッファ８０にスレッドＢに送信するためのデータを格納する（Ｓ４０）。そして、データ送信要求部３３は、ＩＰＣ用バッファ８０に格納したデータをスレッドＢに送信するようＯＳ２０に要求する（Ｓ５０）。

ＯＳ２０のエントリ付け替え部２２は、パーティションＡ用ＴＬＢ１１からＩＰＣ用バッファ８０に相当する物理メモリ６０のＩＰＣ用エントリを取り出し、パーティションＢ用ＴＬＢ１２に付け替える（Ｓ６０）。

そして、スレッドＢがスレッドＡから送信されたデータを必要とすると、スレッドＢのＩＰＣ用バッファアドレス要求部３４はＯＳ２０に、ＩＰＣ用バッファ８０の仮想アドレスを要求するので（Ｓ７０）、ＯＳ２０のアドレス通知部２３はＩＰＣ用バッファ仮想アドレスをスレッドＢに返す（Ｓ８０）。

スレッドＢのデータ読み込み部３５は、ＩＰＣ用バッファ仮想アドレスで指定されるＩＰＣ用バッファ８０からスレッドＡが送信したデータを読み出す（Ｓ９０）。読み出しによりＩＰＣ用バッファ８０が不要になると、ＩＰＣ用バッファ開放要求部３６はＯＳ２０に、ＩＰＣ用バッファ８０を開放するよう要求する（Ｓ１００）。

ＯＳ２０のページ開放部２４は、パーティションＢ用ＴＬＢ１２からＩＰＣ用エントリを削除する（Ｓ１１０）。

以上説明したように、ＭＭＵ５０のメモリ管理の仕組みを利用して、データをコピーすることなくスレッド間でＩＰＣ通信することができる。コピーすることがないので、リソース管理することなく送信元と送信先でデータの整合性をとることができる。

プロセス間通信装置によるプロセス間通信方法の概略を説明する図の一例である。 プロセス間通信装置の概略構成図の一例である。 ＴＬＢを模式的に説明する図の一例である。 プロセス間通信装置の機能ブロック図の一例である。 パーティションＡ、ＢとＴＬＢの遷移を模式的に示す図の一例である。 プロセス間通信装置がプロセス間通信する手順を示すフローチャート図の一例である。

符号の説明

１１ パーティションＡ用ＴＬＢ
１２ パーティションＢ用ＴＬＢ
１３ ＣＰＵコア
２０ ＯＳ
５０ ＭＭＵ
６０ 物理メモリ
７０ ＴＬＢ
１００ プロセス間通信装置

Claims (5)

1. メモリの１ページ単位で物理アドレスと仮想アドレスとを対応づけるエントリを、プログラムから生成された複数のスレッドに対応するパーティションメモリ毎のテーブルに登録して管理する、プロセス間通信装置であって、
   スレッドＡが使用したデータを用いて、スレッドＢを実行する際、
   スレッドＡが前記データを記憶するためのバッファメモリの前記エントリを、スレッドＡに対応するパーティションメモリＡのテーブルＡに登録して、該エントリの仮想アドレスをスレッドＡに通知するページ確保手段と、
   テーブルＡから前記バッファメモリの前記エントリを削除し、スレッドＢに対応するパーティションメモリＢのテーブルＢに、前記バッファメモリの前記エントリを登録するエントリ付け替え手段と、
   テーブルＢに登録された前記エントリの仮想アドレスをスレッドＢに通知するアドレス通知手段と、
   を有することを特徴とするプロセス間通信装置。
2. スレッドＡが前記バッファメモリに前記データを格納してから、前記データを用いてスレッドＢを実行するまでの間、前記データは前記バッファメモリに記憶された状態を維持する、
   ことを特徴とする請求項１記載のプロセス間通信装置。
3. スレッドＢからの要求に応じて、テーブルＢから前記バッファメモリの前記エントリを削除するページ開放手段、を有する、
   ことを特徴とする請求項１又は２記載のプロセス間通信装置。
4. スレッドＡ及びスレッドＢは、システムコールによりスレッドＡが使用したデータをスレッドＢに送信する、
   ことを特徴とする請求項１〜３いずれか１項記載のプロセス間通信装置。
5. メモリの１ページ単位で物理アドレスと仮想アドレスとを対応づけるエントリを、プログラムから生成された複数のスレッドに対応するパーティションメモリ毎のテーブルに登録して管理する、計算機のプロセス間通信方法であって、
   スレッドＡが使用したデータを用いて、スレッドＢを実行する際、
   ページ確保手段が、スレッドＡが前記データを記憶するためのバッファメモリの前記エントリを、スレッドＡに対応するパーティションメモリＡのテーブルＡに登録して、該エントリの仮想アドレスをスレッドＡに通知するステップと、
   エントリ付け替え手段が、テーブルＡから前記バッファメモリの前記エントリを削除し、スレッドＢに対応するパーティションメモリＢのテーブルＢに、前記バッファメモリの前記エントリを登録するステップと、
   アドレス通知手段が、テーブルＢに登録された前記エントリの仮想アドレスをスレッドＢに通知するステップと、
   を有することを特徴とするプロセス間通信方法。

Images