(57)【要約】  共有メモリのデータ解放処理を関連技術よりも低コストで実現するため、プロセス間通信システムは、データを送信する送信プロセス１０と、データを受信する複数の受信プロセス１１〜１３と、送信プロセスが送信するデータが格納される通信データ保存領域４００と、通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブル３００と、各受信プロセスが通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブル２０１〜２０３と、管理テーブルと、読出位置管理テーブルに記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放するゴミ収集プロセス１４とを含む。
2009133722.tif 000002
【特許請求の範囲】
【請求項１】
データを送信する送信プロセスと、
データを先頭から順次受信する複数の受信プロセスと、
前記送信プロセスが送信するデータが格納される通信データ保存領域と、
前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、
前記各受信プロセスが前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルと、
前記管理テーブルと、前記読出位置管理テーブルに記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放するゴミ収集プロセスとを含むことを特徴とするプロセス間通信システム。
【請求項２】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、そのディスクリプタに関する送信プロセスＩＤと、受信プロセスＩＤの一覧とを保持し、さらにそのディスクリプタで通信される通信データを管理する通信データ管理テーブルへのポインタを保持するディスクリプタ管理テーブルと、
前記ディスクリプタに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する前記通信データ管理テーブルとを含むことを特徴とする請求項１記載のプロセス間通信システム。
【請求項３】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項２記載のプロセス間通信システム。
【請求項４】
前記ゴミ収集プロセスは、
所定のディスクリプタに関する受信プロセスＩＤの一覧を取得し、
前記読出位置管理テーブルから前記ディスクリプタに関する各受信プロセスの読出位置を収集し、
前記通信データ管理テーブルの解放可能領域を算出し、
前記通信データ管理テーブルのエントリとそれに伴う通信データ保存領域を解放し、
さらに前記ディスクリプタがクローズされており、かつ、全エントリが解放可能な場合には、前記ディスクリプタ管理テーブルのエントリと、前記通信データ管理テーブルと、前記各受信プロセスの前記読出位置管理テーブルのエントリとを解放することを特徴とする請求項２または３記載のプロセス間通信システム。
【請求項５】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、
そのディスクリプタに関する送信プロセスＩＤと、
そのディスクリプタに関する受信プロセス数が変化する単位で、フェーズに分けて管理する受信プロセス管理テーブルへのポインタとを保持するディスクリプタ管理テーブルと、
前記各ディスクリプタのフェーズ毎の受信プロセスＩＤの一覧を管理する前記受信プロセス管理テーブルと、
前記受信プロセス管理テーブルに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する通信データ管理テーブルとを含むことを特徴とする請求項１記載のプロセス間通信システム。
【請求項６】
前記受信プロセス管理テーブルは、
各ディスクリプタの受信プロセスが変化する単位で管理するフェーズと、
前記フェーズ毎の受信プロセスＩＤの一覧と、
各フェーズで送信されるデータを格納する前記通信データ管理テーブルへのポインタとを含むことを特徴とする請求項５記載のプロセス間通信システム。
【請求項７】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとそのディスクリプタからのフェーズ情報とから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項５または６記載のプロセス間通信システム。
【請求項８】
前記ゴミ収集プロセスは、
所定のディスクリプタに関する受信プロセスＩＤの一覧を取得し、
前記ディスクリプタのフェーズ情報を取得した後に、
前記読出位置管理テーブルから前記ディスクリプタに関する各受信プロセスの読出位置を収集し、
前記受信プロセス管理テーブルの解放可能領域を算出し、
前記通信データ管理テーブルの解放可能領域を算出し、
前記受信プロセス管理テーブルのエントリと前記通信データ管理テーブルのエントリとそれに伴う通信データ保存領域を解放し、
さらに前記ディスクリプタがクローズされており、かつ、全エントリが解放可能な場合には、前記ディスクリプタ管理テーブルのエントリと、前記受信プロセス管理テーブルと、前記通信データ管理テーブルと、前記各受信プロセスの前記読出位置管理テーブルのエントリとを解放することを特徴とする請求項５から７いずれかに記載のプロセス間通信システム。
【請求項９】
送信プロセスが送信するデータが格納される通信データ保存領域と、
前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、
データを先頭から順次受信する複数の受信プロセスの各々が前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルとを含み、
前記管理テーブルと前記読出位置管理テーブルに記録される各受信プロセスの読出位置とが、全ての受信プロセスが受信済みの領域を算出するのに用いられ、その算出結果に基づいてその領域が解放されることを特徴とする共有メモリ。
【請求項１０】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、そのディスクリプタに関する送信プロセスＩＤと、受信プロセスＩＤの一覧とを保持し、さらにそのディスクリプタで通信される通信データを管理する通信データ管理テーブルへのポインタを保持するディスクリプタ管理テーブルと、
前記ディスクリプタに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する前記通信データ管理テーブルとを含むことを特徴とする請求項９記載の共有メモリ。
【請求項１１】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項１０記載の共有メモリ。
【請求項１２】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、
そのディスクリプタに関する送信プロセスＩＤと、
そのディスクリプタに関する受信プロセス数が変化する単位で、フェーズに分けて管理する受信プロセス管理テーブルへのポインタとを保持するディスクリプタ管理テーブルと、
前記各ディスクリプタのフェーズ毎の受信プロセスＩＤの一覧を管理する前記受信プロセス管理テーブルと、
前記受信プロセス管理テーブルに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する通信データ管理テーブルとを含むことを特徴とする請求項９記載の共有メモリ。
【請求項１３】
前記受信プロセス管理テーブルは、
各ディスクリプタの受信プロセスが変化する単位で管理するフェーズと、
前記フェーズ毎の受信プロセスＩＤの一覧と、
各フェーズで送信されるデータを格納する前記通信データ管理テーブルへのポインタとを含むことを特徴とする請求項１２記載の共有メモリ。
【請求項１４】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとそのディスクリプタからのフェーズ情報とから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項１２または１３記載の共有メモリ。
【請求項１５】
データを送信する送信プロセスと、
データを先頭から順次受信する複数の受信プロセスと、
前記送信プロセスが送信するデータが格納される通信データ保存領域と、
前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、
前記各受信プロセスが前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルとを含むプロセス間通信システムにおける通信方法であって、
前記管理テーブルと、前記読出位置管理テーブルに記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放するゴミ収集ステップを含むことを特徴とする通信方法。
【請求項１６】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、そのディスクリプタに関する送信プロセスＩＤと、受信プロセスＩＤの一覧とを保持し、さらにそのディスクリプタで通信される通信データを管理する通信データ管理テーブルへのポインタを保持するディスクリプタ管理テーブルと、
前記ディスクリプタに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する前記通信データ管理テーブルとを含むことを特徴とする請求項１５記載の通信方法。
【請求項１７】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項１６記載の通信方法。
【請求項１８】
前記ゴミ収集ステップは、
所定のディスクリプタに関する受信プロセスＩＤの一覧を取得するステップと、
前記読出位置管理テーブルから前記ディスクリプタに関する各受信プロセスの読出位置を収集するステップと、
前記通信データ管理テーブルの解放可能領域を算出し、前記通信データ管理テーブルのエントリとそれに伴う通信データ保存領域を解放するステップと、
さらに前記ディスクリプタがクローズされており、かつ、全エントリが解放可能な場合には、前記ディスクリプタ管理テーブルのエントリと、前記通信データ管理テーブルと、前記各受信プロセスの前記読出位置管理テーブルのエントリとを解放するステップとを含むことを特徴とする請求項１６または１７記載の通信方法。
【請求項１９】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、
そのディスクリプタに関する送信プロセスＩＤと、
そのディスクリプタに関する受信プロセス数が変化する単位で、フェーズに分けて管理する受信プロセス管理テーブルへのポインタとを保持するディスクリプタ管理テーブルと、
前記各ディスクリプタのフェーズ毎の受信プロセスＩＤの一覧を管理する前記受信プロセス管理テーブルと、
前記受信プロセス管理テーブルに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する通信データ管理テーブルとを含むことを特徴とする請求項１５記載の通信方法。
【請求項２０】
前記受信プロセス管理テーブルは、
各ディスクリプタの受信プロセスが変化する単位で管理するフェーズと、
前記フェーズ毎の受信プロセスＩＤの一覧と、
各フェーズで送信されるデータを格納する前記通信データ管理テーブルへのポインタとを含むことを特徴とする請求項１９記載の通信方法。
【請求項２１】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとそのディスクリプタからのフェーズ情報とから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項１９または２０記載の通信方法。
【請求項２２】
前記ゴミ収集ステップは、
所定のディスクリプタに関する受信プロセスＩＤの一覧を取得するステップと、
前記ディスクリプタのフェーズ情報を取得するステップと、
フェーズ情報を取得した後に、前記読出位置管理テーブルから前記ディスクリプタに関する各受信プロセスの読出位置を収集するステップと、
前記受信プロセス管理テーブルの解放可能領域を算出し、前記通信データ管理テーブルの解放可能領域を算出し、前記受信プロセス管理テーブルのエントリと前記通信データ管理テーブルのエントリとそれに伴う通信データ保存領域を解放するステップと、
さらに前記ディスクリプタがクローズされており、かつ、全エントリが解放可能な場合には、前記ディスクリプタ管理テーブルのエントリと、前記受信プロセス管理テーブルと、前記通信データ管理テーブルと、前記各受信プロセスの前記読出位置管理テーブルのエントリとを解放するステップとを含むことを特徴とする請求項１９から２１いずれかに記載の通信方法。
【請求項２３】
データを送信する送信プロセスと、
データを先頭から順次受信する複数の受信プロセスと、
前記送信プロセスが送信するデータが格納される通信データ保存領域と、
前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、
前記各受信プロセスが前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルとを含むプロセス間通信システムにおける通信方法のプログラムを格納する記録媒体であって、
前記プログラムが、コンピュータに、前記管理テーブルと、前記読出位置管理テーブルに記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放するゴミ収集ステップを実行させる記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロセス間通信システム、その通信に用いる共有メモリおよび通信方法に関し、特に共有メモリを用いてプロセス間通信を行うプロセス間通信システム、その通信に用いる共有メモリおよび通信方法に関する。
【背景技術】
【０００２】
同一マシン内でのプロセス間通信においてデータをやり取りする場合、共有メモリを利用するのが低コストな通信方法の一つとして挙げられる。【０００３】
しかし、特に１つの送信プロセスから複数の受信プロセスにデータを渡すような１対多の通信の場合、共有メモリ上のデータを適切に解放しなければ、システム全体の性能に大きな影響を与える。【０００４】
そこで、たとえば、特許文献１開示のプロセス間通信方式には、データごとに制御情報部を用意し、受信すべきプロセスが受信した場合は制御情報部の未参照プロセス数をデクリメントしていき、未参照プロセス数が“０”になるとその領域を解放する、という手法が示されている。【０００５】
このため、データごとに利用する受信プロセスのＩＤを関連付けて管理している。これにより全データについて、どのプロセスが利用済みであるかを判定することができる。【０００６】
また、特許文献２開示の共有メモリ管理装置には、オンライントランザクションシステムで複数の業務プロセスが共有メモリでデータ共有を行う場合に、共有メモリに書き込まれたデータに対して業務種別と時刻情報を付与し、所定周期でエントリをチェックすることによって業務プロセスの解放漏れを検知し、共有メモリから退避および解放させる処理手段が示されている。【０００７】
一方、特許文献３開示のメモリ管理方式には本発明の「ゴミ収集プロセス」に相当する「メモリ確保解放プロセス」が開示され、「メモリ確保解放プロセス」がアドレスｘのメモリ解放要求を受けると、メモリ解放処理を行うことが示されている。【０００８】
また、特許文献４開示の共有メモリ管理方式には、以下の技術が示されている。まず、メモリ管理部が、要求されたメモリブロックＡを共有メモリ領域に確保し、メモリ管理部の受付テーブルに最終ジョブを識別するジョブＩＤを記録する。次に、メモリ管理部は、そのジョブＩＤに基づき最終ジョブの終了を検出し、メモリブロックＡを解放する。【０００９】
【特許文献１】特開平１１−０６５８５８号公報
【特許文献２】特開平１１−２０３１９３号公報
【特許文献３】特開平０３−２８２８４９号公報
【特許文献４】特開平０５−３３４１７４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかし、特許文献１開示のプロセス間通信方式のように、データごとに未参照プロセス数を管理した場合、以下に示す４つの問題がある。【００１１】
第１に、並列に実行されるプロセス数が同じ未参照プロセス数にアクセスすると、競合が発生するという欠点がある。特に、受信プロセス数が多くなればなるほど、この問題は顕著になる。【００１２】
第２に、受信プロセスが突然死亡した場合には未参照プロセス数は“０”にならず、制御情報部およびデータは解放されずに残ってしまうという欠点がある。【００１３】
第３に、未参照プロセス数を“０”にしたプロセスは通常、最も処理が低速なプロセスであって、解放処理によりさらに遅くなってしまうという欠点がある。【００１４】
第４に、データごとに利用する受信プロセスのＩＤを関連付けて管理しているため、データにアクセスする度にオーバヘッドが発生するという欠点がある。【００１５】
また、特許文献２開示の共有メモリ管理装置のようなオンライントランザクションシステムの場合、静的に確保した領域を複数の業務プロセスで共有し、その領域を確保した業務プロセスが処理を終了しても、他の業務プロセスが引き続きこの業務プロセスを利用する可能性がある。そのため、時刻情報を付与することによってタイムアウトの判定を行い、解放を行う方式となっている。【００１６】
しかし、一対多の通信においては、通常は領域を確保した送信プロセスが終了し、かつ、一度全データが受信されたことが確認できれば領域を解放することができるため、この特許文献２開示の共有メモリ管理装置よりも低いオーバヘッドで解放処理を実現することが可能である。【００１７】
また、特許文献３開示のメモリ管理方式の場合、メモリ確保解放プロセスは、ガーベージ・コレクションの多発およびガーベージ・コレクションによるアプリケーション・プログラムの長時間の停止をなくすために設けられている。したがって、特許文献３開示の発明はその目的が本発明と全く異なり、よってその構成および効果も本発明と全く異なる別発明である。【００１８】
また、特許文献４開示の共有メモリ管理方式の場合、メモリ管理部の受付テーブルに最終ジョブを識別するジョブＩＤを記録する必要があるが、本発明ではこのようなジョブＩＤに依存することなく最終ジョブの確認が可能である。【００１９】
そこで本発明の目的は、上記課題を解決し、もって共有メモリのデータ解放処理を関連技術よりも低コストで実現することが可能なプロセス間通信システム、その通信に用いる共有メモリおよび通信方法を提供することにある。
【課題を解決するための手段】
【００２０】
前記課題を解決するために本発明によるプロセス間通信システムは、データを送信する送信プロセスと、データを先頭から順次受信する複数の受信プロセスと、前記送信プロセスが送信するデータが格納される通信データ保存領域と、前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、前記各受信プロセスが前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルと、前記管理テーブルと前記読出位置管理テーブルに記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放するゴミ収集プロセスとを含むことを特徴とする。【００２１】
また、本発明による共有メモリは、送信プロセスが送信するデータが格納される通信データ保存領域と、前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、データを先頭から順次受信する複数の受信プロセスの各々が前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルとを含み、前記管理テーブルと前記読出位置管理テーブルに記録される各受信プロセスの読出位置とが、全ての受信プロセスが受信済みの領域を算出するのに用いられ、その算出結果に基づいてその領域が解放されることを特徴とする。【００２２】
また、本発明による通信方法は、データを送信する送信プロセスと、データを先頭から順次受信する複数の受信プロセスと、前記送信プロセスが送信するデータが格納される通信データ保存領域と、前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、前記各受信プロセスが前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルとを含むプロセス間通信システムにおける通信方法であって、前記管理テーブルと前記読出位置管理テーブルに記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放するゴミ収集ステップを含むことを特徴とする。【００２３】
また、本発明による記録媒体は、データを送信する送信プロセスと、データを先頭から順次受信する複数の受信プロセスと、前記送信プロセスが送信するデータが格納される通信データ保存領域と、前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、前記各受信プロセスが前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルとを含むプロセス間通信システムにおける通信方法のプログラムを格納し、前記プログラムが、コンピュータに、前記管理テーブルと、前記読出位置管理テーブルに記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放するゴミ収集ステップを実行させることを特徴とする。
【発明の効果】
【００２４】
本発明によれば、データを先頭から順次受信する受信プロセスの現在の読出位置に基づき解放対象のデータ領域を算出する構成であるため、共有メモリのデータ解放処理を関連技術よりも低コストで実現することが可能なプロセス間通信システム、その通信に用いる共有メモリおよび通信方法が得られる。
【図面の簡単な説明】
【００２５】
【図１】本発明に係るプロセス間通信システムの一例の構成図である。
【図２】第１実施形態の管理テーブル３００の一例の構成図である。
【図３Ａ】第１実施形態の読出位置管理テーブル２０１の一例の構成図である。
【図３Ｂ】第１実施形態の読出位置管理テーブル２０２の一例の構成図である。
【図４】第１実施形態のゴミ収集プロセスの解放処理の動作の一例を示すフローチャートである。
【図５】第２実施形態の管理テーブル３００の一例の構成図である。
【図６Ａ】第２実施形態の読出位置管理テーブル２０１の一例の構成図である。
【図６Ｂ】第２実施形態の読出位置管理テーブル２０２の一例の構成図である。
【図７Ａ】第２実施形態のゴミ収集プロセスの解放処理の動作の一例を示すフローチャートである。
【図７Ｂ】第２実施形態のゴミ収集プロセスの解放処理の動作の一例を示すフローチャートである。
【図８】プロセス間通信システムにおける通信方法のプログラムを実行するためのプロセス間通信システムの構成の一例を示す図である。
【符号の説明】
【００２６】
１０  送信プロセス
１１〜１３  受信プロセス
２１  ＣＰＵ
２２  メモリ
２０１〜２０３  読出位置管理テーブル
３００  管理テーブル
３１０  ディスクリプタ管理テーブル
３２０，３２１  通信データ管理テーブル
３３０  受信プロセス管理テーブル
４００  通信データ保存領域
５００  共有メモリ
【発明を実施するための最良の形態】
【００２７】
まず、本発明の実施形態の説明に先立ち、本発明の動作原理について説明しておく。【００２８】
図１は、本発明に係るプロセス間通信システムの一例の構成図である。同図を参照すると、本発明に係るプロセス間通信システムは、データを送信する送信プロセス１０と、データを先頭から順次受信する複数（一例として３個）の受信プロセス１１〜１３と、送信プロセス１０が送信するデータが格納される通信データ保存領域４００と、通信データ保存領域４００に保存されるデータのサイズと位置を管理する管理テーブル３００と、各受信プロセス１１〜１３に対して設けられ、各受信プロセス１１〜１３が通信データ保存領域４００から次に取得するデータの位置を記録する読出位置管理テーブル２０１〜２０３と、ゴミを収集するゴミ収集プロセス１４とを含んで構成される。【００２９】
本発明では、送信プロセスが１個に対し、受信プロセスが多、すなわち複数個である通信システムを対象としている。したがって、受信プロセス数は３個に限定されるものではなく、２個以上の任意の個数に対し本発明の適用が可能である。【００３０】
次に、本発明の動作について説明する。受信プロセス１１〜１３は、通信データ保存領域４００内の読出すべきデ−タを先頭から順次読出し、一度読出したデータを再度読出すことはない。ゴミ収集プロセス１４は、管理テーブル３００と読出位置管理テーブル２０１〜２０３に記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放する。【００３１】
本発明によれば、ゴミ収集プロセス１４が受信プロセスの読出位置に基づき、どのデータまで利用し終わったかを調べ、利用が終わったデータ領域からデータ解放を行う構成であるから、共有メモリのデータ解放処理を関連技術よりも低コストで実現することが可能となる。【００３２】
具体的に説明すると、特許文献１開示の発明では、データごとに利用する受信プロセスのＩＤを関連付けて管理しているためオーバヘッドが発生するが、本発明では「どのデータまで利用し終わったか」を管理することで、データにアクセスする度にオーバヘッドが発生するのを排除している。【００３３】
また、特許文献２開示の発明も結果として特許文献１開示の発明と同様のオーバヘッドが発生するが、本発明ではこの発生を防止している。【００３４】
また、特許文献３開示の発明は目的が本発明と全く相違する。【００３５】
また、特許文献４開示の共有メモリ管理方式の場合、メモリ管理部の受付テーブルに最終ジョブを識別するジョブＩＤを記録する必要があるが、本発明ではこのようなジョブＩＤを設ける必要はない。【００３６】
本発明が実現できたのは、「データが順番に利用される」という前提が存在するためである。【００３７】
次に、本発明の最良の実施形態について説明する。まず、本発明の第１実施形態について説明する。なお、本発明の第１実施形態の構成は図１に示すものと同様であるため、同実施形態の説明に図１も併せて参照する。【００３８】
図１を参照すると、本発明の第１実施形態は、データを送信する送信プロセス１０と、データを受信する複数（一例として３個）の受信プロセス１１〜１３と、共有メモリ５００と、ゴミを収集するゴミ収集プロセス１４とを含んで構成される。【００３９】
共有メモリ５００は、送信プロセス１０が送信するデータが格納される通信データ保存領域４００と、通信データ保存領域４００に保存されるデータのサイズと位置を管理する管理テーブル３００と、各受信プロセス１１〜１３に対して設けられ、各受信プロセス１１〜１３が通信データ保存領域４００から次に取得するデータの位置を記録する読出位置管理テーブル２０１〜２０３とを含んでいる。【００４０】
次に、管理テーブル３００の構成について説明する。図２は、第１実施形態の管理テーブル３００の一例の構成図である。図２は、ディスクリプタ管理テーブル３１０の構成、通信データ管理テーブル３２０の構成、通信データ管理テーブル３２１の構成を夫々示している。【００４１】
図２を参照すると、管理テーブル３００は、ディスクリプタ（ｄｅｓｃｒｉｐｔｏｒ：識別子）を管理するディスクリプタ管理テーブル３１０と、通信データを管理する通信データ管理テーブル３２０および３２１とを含んで構成される。【００４２】
ディスクリプタ管理テーブル３１０は、ディスクリプタＩＤ（ｉｄｅｎｔｉｆｉｅｒ）（ｆｄ）と、そのディスクリプタに関する送信プロセスＩＤ（Ｓｅｎｄｅｒ  ＰＩＤ）と、受信プロセスのＩＤ一覧（Ｒｅｃｅｉｖｅｒ  ＰＩＤ  Ｌｉｓｔ）とを保持し、さらにそのディスクリプタで通信される通信データを管理する通信データ管理テーブルのポインタ（不図示）を保持する。【００４３】
通信データ管理テーブル３２０および３２１は、所定のディスクリプタを用いて通信されるデータを管理しており、通信データ保存領域４００に保存されるデータ単位で、データＩＤ（ＤＩＤ）と、データ格納アドレス（Ａｄｄｒｅｓｓ）と、データ格納サイズ（ｌｅｎ）とを保持する。【００４４】
次に、読出位置管理テーブル２０１〜２０３の構成について説明する。図３Ａおよび３Ｂは、第１実施形態の読出位置管理テーブル２０１および２０２の一例の構成図である。なお、図３Ａおよび３Ｂでは、読出位置管理テーブル２０３を図示していないが、その形式は読出位置管理テーブル２０１および２０２と同様である。【００４５】
図３Ａおよび３Ｂを参照すると、読出位置管理テーブル２０１および２０２は、各受信プロセス１１〜１３が次に読み出すべきデータ位置情報を格納するために、受信プロセスＩＤ（ＰＩＤ）と、ディスクリプタＩＤ（ｆｄ）と、そのディスクリプタに関する読出し位置の情報として、読み出すべきデータＩＤ（ＤＩＤ）と、そのデータＩＤ（ＤＩＤ）の読出し位置（ｏｆｆｓｅｔ）とを保持する。【００４６】
次に、図１、図２、並びに図３Ａおよび３Ｂを参照しながら本実施形態の動作の概略について説明する。【００４７】
一例として、送信プロセス１０から受信プロセス１１へデータを送信する場合を説明する。なお、送信プロセス１０から受信プロセス１２または１３へデータを送信する場合も同様に説明することができる。【００４８】
送信プロセス１０は、データ送信の開始時にディスクリプタ（たとえば、ｆｄ＝１００）を生成し、ディスクリプタ（ｆｄ＝１００）に関する受信プロセスＩＤ一覧を取得すると、ディスクリプタ管理テーブル３１０にエントリを追加し設定する。【００４９】
送信プロセス１０がデータを送信すると、通信データ管理テーブル３２０のエントリに、通信データに関する情報が記録される。【００５０】
つまり、通信データが通信データ保存領域４００に記録され、そのデータ格納アドレス（Ａｄｄｒｅｓｓ）とデータ格納サイズ（ｌｅｎ）とが取得され、データＩＤ（ＤＩＤ）とセットでこれらデータ格納アドレスおよびデータ格納サイズがエントリに記録される。【００５１】
受信プロセス１１がディスクリプタ（ｆｄ＝１００）を受け取り、そのディスクリプタに関するデータ受信を開始すると、通信データ管理テーブル３２０のＤＩＤ＝１０００のエントリから順次データが読み出される。【００５２】
その際、共有メモリ５００上の読出位置管理テーブル２０１に読出し位置が記録される。つまり、読出位置管理テーブル２０１は、受信プロセス１１が読み込み中のデータ位置を示している。【００５３】
もし、所定のＤＩＤに関するデータ読み込みが完了した場合、ＤＩＤには、次の読み出すべきエントリのＤＩＤが設定される。【００５４】
なお、読出し位置は、読出し処理ごとに毎回記録してもよいが、数回の読出しごとに一回記録するようにしてもよい。【００５５】
次に、図１、図２、図３Ａおよび３Ｂ、並びに図４を参照しながら本実施形態のゴミ収集プロセスの解放処理の動作について詳細に説明する。図４は、第１実施形態のゴミ収集プロセスの解放処理の動作の一例を示すフローチャートである。【００５６】
まず、ゴミ収集プロセス１４は、ディスクリプタ管理テーブル３１０からディスクリプタＩＤ一覧（ｆｄＬｉｓｔ）を取得する（ステップＳ１００）。【００５７】
次に、ゴミ収集プロセス１４は、ディスクリプタＩＤ一覧から１つのディスクリプタ（ここではｆｄ＝１００とする）を取得する（ステップＳ１０１）。【００５８】
もし、ディスクリプタが取得できなかった場合は（ステップＳ１０２で“Ｎ”の場合）、ゴミ収集プロセス１４は、処理を完了する（ステップＳ２００）。【００５９】
一方、ディスクリプタが取得できた場合は（ステップＳ１０２で“Ｙ”の場合）、ゴミ収集プロセス１４は、そのディスクリプタに関する通信データ管理テーブル（ここでは通信データ管理テーブル３２０）から通信された最後のデータＩＤ（ＤＩＤ）を取得し、ｍｉｎＤＩＤに格納する（ステップＳ１０３）。【００６０】
図２を参照すると、この場合ｍｉｎＤＩＤ＝１００２である。【００６１】
次に、ゴミ収集プロセス１４は、ｆｄのディスクリプタに対応する受信プロセスＩＤ一覧（Ｒｅｃｅｉｖｅｒ  ＰＩＤ  Ｌｉｓｔ）を取得する（ステップＳ１０４）。図２を参照すると、この場合ｆｄ＝１００に対応する受信プロセスＩＤ一覧に含まれる受信プロセスは“１１”と“１２”である。【００６２】
次に、ゴミ収集プロセス１４は、受信プロセスＩＤ一覧から１つの受信プロセスＩＤ（ｐｉｄ）を取得する（ステップＳ１０５）。いま、ここではｐｉｄ＝１１とする。【００６３】
次に、ゴミ収集プロセス１４は、ｐｉｄが取得できたかどうかを確認する（ステップＳ１０６）。【００６４】
もし、ｐｉｄが取得できた場合（ステップＳ１０６にて“Ｙ”の場合）、ゴミ収集プロセス１４は、次にｐｉｄプロセスの生存確認を行う（ステップＳ１０７）。【００６５】
ここで、プロセスｐｉｄが死亡していた場合は（ステップＳ１０７にて“Ｎ”の場合）、ゴミ収集プロセス１４は、無視してステップＳ１０５に戻る。【００６６】
一方、プロセスｐｉｄが生存していた場合（ステップＳ１０７にて“Ｙ”の場合）、ゴミ収集プロセス１４は、ｐｉｄの読出位置管理テーブル２０１を参照し、ｐｉｄおよびｆｄに対応する読出し位置（ＤＩＤ）を取得して“ｄ”に格納する（ステップＳ１０８）。【００６７】
図３Ａを参照すると、この場合、ｐｉｄ＝１１、ｆｄ＝１００であるため、ｄ＝１００２となる。【００６８】
次に、ゴミ収集プロセス１４は、ｄとｍｉｎＤＩＤを比較する（ステップＳ１０９）。【００６９】
この例では、ｄ＝１００２およびｍｉｎＤＩＤ＝１００２であるため（ステップＳ１０９にて“Ｎ”の場合）、ゴミ収集プロセス１４は、ステップＳ１０５に戻る。【００７０】
ステップＳ１０５では、ゴミ収集プロセス１４は、受信プロセスＩＤ一覧から次の受信プロセスＩＤ（ｐｉｄ）を取得する（ステップＳ１０５）。ここではｐｉｄ＝１２となる。そして、ゴミ収集プロセス１４は、ｐｉｄ＝１１の場合と同様の手順（ステップＳ１０６〜Ｓ１０９）を再度実行する。【００７１】
ステップＳ１０９にてｄがｍｉｎＤＩＤよりも小さい場合（ステップＳ１０９にて“Ｙ”の場合）、ゴミ収集プロセス１４は、ｍｉｎＤＩＤ＝ｄとしてｍｉｎＤＩＤを更新し（ステップＳ１１０）、ステップＳ１０５に戻る。【００７２】
一方、ステップＳ１０６にてゴミ収集プロセス１４がｐｉｄを取得できなかった場合は（ステップＳ１０６にて“Ｎ”の場合）、そのディスクリプタ（ｆｄ＝１００）に関する全ての受信プロセスの読出し位置の取得が完了したことを意味している。【００７３】
そこで、ゴミ収集プロセス１４は、ｍｉｎＤＩＤよりも小さい（ＤＩＤ＜ｍｉｎＤＩＤ）エントリと、それに関する通信データ保存領域４００の保存領域を開放する（ステップＳ３００）。図３Ａおよび３Ｂの場合、ゴミ収集プロセス１４は、ｆｄ＝１００に関する通信データ管理テーブル３２０のエントリＤＩＤ＝１０００と、それに関するデータ保存領域を解放することができる。【００７４】
次に、ゴミ収集プロセス１４は、ｆｄのディスクリプタに関する通信が全て完了していれば、ディスクリプタ管理テーブル３１０のエントリも解放可能である。【００７５】
そこで、ゴミ収集プロセス１４は、ｍｉｎＤＩＤが通信データ管理テーブル３２０の最後のエントリで、かつ、そのディスクリプタが送信プロセス１０によって、クローズ（ｃｌｏｓｅ）されているかどうかをチェックする（ステップＳ３０１）。【００７６】
そして、チェックの結果、解放できないと判断された場合（ステップＳ３０１にて“Ｎ”の場合）、ゴミ収集プロセス１４は、ステップＳ１０１に戻り、前述のステップＳ１０１以降の手順を繰り返す。【００７７】
一方、ステップＳ３０１にて解放できると判断された場合（ステップＳ３０１にて“Ｙ”の場合）、ゴミ収集プロセス１４は、ｆｄに関するディスクリプタ管理テーブル３１０のｆｄ＝１００のエントリ、通信データ管理テーブル３２０、通信データ保存領域４００、並びに各プロセスの読出位置管理テーブル２０１および２０２のエントリを解放する（ステップＳ３０２）。【００７８】
そして、ゴミ収集プロセス１４は、ステップＳ１０１に戻り、ステップＳ１０１以降の手順を繰り返す。【００７９】
以上説明したように、本発明の第１実施形態によれば以下に示す効果が得られる。【００８０】
第１の効果は、特許文献３のように未参照プロセス数を管理した場合に比べ、受信プロセス間で競合が発生することがないことである。【００８１】
その理由は、参照カウンタの代わりに読出位置管理テーブルと、ゴミ収集プロセスとを備えたからである。【００８２】
したがって、ゴミ収集プロセスと１つの受信プロセス間で競合する可能性はあるが、同時にその２つ以上のプロセスと競合することはない。【００８３】
第２の効果は、受信プロセスが突然死亡した場合でも、管理テーブルの情報と通信データ保存領域とを正常に維持できることである。【００８４】
その理由は、ゴミ収集プロセスが、管理テーブルから受信プロセス一覧を取得して各受信プロセスの生存を確認し、死亡したプロセスは既にそのデータを読み込んだと判断するからである。【００８５】
これにより、受信プロセスの突然の死亡時にも、管理テーブルの情報と、通信データ保存領域とを正常に保つことが可能となる。【００８６】
第３の効果は、ゴミ収集プロセスが解放処理を行うために、受信プロセス自身への性能の影響が少ない点である。【００８７】
第４の効果は、特許文献４のような解放方式に比べてゴミ収集プロセスのオーバヘッドが低いことである。【００８８】
その理由は、解放可能領域の探索に必要な情報が読込み位置だけであり、これによりゴミ収集プロセスの開放可能領域の探索処理が短縮できるからである。【００８９】
次に、本発明の第２実施形態について説明する。【００９０】
本発明の第２実施形態では、あるディスクリプタが生成されてから消滅するまでの間に、受信プロセス数が変更されることを想定している。【００９１】
たとえば、ｆｄ＝１００に関して、最初の受信プロセスリストは、１１および１２であるが、次は１１、１２および１３になり、最後は１１，１３および１５になるという場合である。【００９２】
このように、あるディスクリプタについての受信プロセス数が変動する場合でも、ゴミ収集プロセスが容易に解放領域を判定することが可能となるように、第２実施形態では“フェーズ”（Ｐｈａｓｅ）を導入する。【００９３】
上記の例でいうと、
Ｐｈａｓｅ０＝１１，１２
Ｐｈａｓｅ１＝１１，１２，１３
Ｐｈａｓｅ２＝１１，１３，１５
となる。【００９４】
図５は、第２実施形態の管理テーブル３００の一例の構成図である。図５は、ディスクリプタ管理テーブル３１０の構成、受信プロセス管理テーブル３３０の構成、通信データ管理テーブル３２０の構成、通信データ管理テーブル３２１の構成を夫々示している。【００９５】
図６Ａおよび６Ｂは、第２実施形態の読出位置管理テーブル２０１および２０２の一例の構成図である。なお、図６Ａおよび６Ｂには、受信プロセス１２に対する読出位置管理テーブル２０３および受信プロセス１５（不図示）に対する読出位置管理テーブル２０４が図示されていないが、それらの形式は読出位置管理テーブル２０１および２０２と同様である。【００９６】
まず、図５の管理テーブル３００の詳細について説明する。図２に示す第１実施形態の管理テーブル３００と比較すると、ディスクリプタは、ディスクリプタＩＤと、送信プロセスＩＤと、受信プロセス管理テーブル３３０へのポインタ（不図示）とを保持している。【００９７】
この受信プロセス管理テーブル３３０は、フェーズと、各フェーズの受信プロセス１１，１２，１３および１５のリストを管理する。【００９８】
すなわち、フェーズが遷移する度に新たなエントリが生成され、それに伴って通信データ管理テーブルが生成される。【００９９】
次に、図６Ａおよび６Ｂの読出位置管理テーブル２０１および２０２の詳細について説明する。【０１００】
図６Ａおよび６Ｂを参照すると、読出位置管理テーブル２０１および２０２にもフェーズの列が追加されている。【０１０１】
これは、各受信プロセスの読出し位置を決定するのに、送信プロセスＩＤ（ＰＩＤ）、ディスクリプタ（ｆｄ）およびフェーズ（Ｐｈａｓｅ）の３つが必要であることを意味している。各受信プロセスは、この３つの情報をキーとして、読出し位置を記録する。【０１０２】
次に、図５、図６Ａ及び６Ｂ、並びに図７Ａ及び７Ｂを参照しながら本実施形態のゴミ収集プロセスの解放処理の動作について詳細に説明する。図７Ａ及び７Ｂは、第２実施形態のゴミ収集プロセスの解放処理の動作の一例を示すフローチャートである。【０１０３】
第２実施形態は、基本的に第１実施形態にフェーズに関する処理が追加されたものとなっている。【０１０４】
本実施形態の動作（図７Ａ及び７Ｂ参照）を第１実施形態のフローチャート（図４参照）と比較すると、図７ＡのステップＳ５００，Ｓ５０１，Ｓ５０２，Ｓ６００は、図４のステップＳ１００，Ｓ１０１，Ｓ１０２，Ｓ２００にそれぞれ対応する。【０１０５】
また、図７ＡのステップＳ５０８，図７ＢのＳ５０９，Ｓ５１０，Ｓ５１１，Ｓ５１２は、図４のステップＳ１０３，Ｓ１０４，Ｓ１０５，Ｓ１０６，Ｓ１０７にそれぞれ対応する。【０１０６】
また、図７ＢのステップＳ５１５，Ｓ５１７は、図４のステップＳ１０９，Ｓ１１０にそれぞれ対応する。【０１０７】
一方、ステップＳ５０３〜Ｓ５０７は新に追加されたステップで、これはゴミ収集プロセス１４がフェーズを取り出す操作を示している。【０１０８】
これは、図５の受信プロセス管理テーブル３３０が新たに追加されたためである。【０１０９】
すなわち、ゴミ収集プロセス１４は、ディスクリプタ（ｆｄ）の受信プロセス管理テーブル３３０からフェーズ一覧（ｐｈａｓｅＬｉｓｔ）を取得し（ステップＳ５０３）、ｍｉｍＰｈａｓｅにＭａｘＰｈａｓｅを設定する（ステップＳ５０４）。【０１１０】
さらに、ゴミ収集プロセス１４は、ディスクリプタ（ｆｄ）の受信プロセス管理テーブル３３０からフェーズ一覧（ｐｈａｓｅＬｉｓｔ）を取得し（ステップＳ５０５）、フェーズ一覧から１つのフェーズを取得する（ステップＳ５０６）。【０１１１】
次に、ゴミ収集プロセス１４は、フェーズが取得できたかどうかを調べ、フェーズが取得できなかった場合は（ステップＳ５０７にて“Ｎ”の場合）、ステップＳ５０１の戻り、フェーズが取得できた場合は（ステップＳ５０７にて“Ｙ”の場合）、ステップＳ５０８へ進む。【０１１２】
また、ステップＳ５０８、Ｓ５０９では、ゴミ収集プロセス１４が、ｆｄ値を用いてディスクリプタ管理テーブル３１０のエントリを求め、フェーズ値を用いて受信プロセス管理テーブル３３０のエントリを求めるように変更されている。【０１１３】
つまり、ゴミ収集プロセス１４は、ｆｄ値とフェーズ値とをもとに通信データ管理テーブル（たとえば、３２０）の最大値を取得する。【０１１４】
さらに、ステップＳ５１３，Ｓ５１４，Ｓ５１６では、各受信プロセスの読出位置管理テーブル（たとえば、２０１〜２０２）にフェーズ列が追加されたことに対応するために、ゴミ収集プロセス１４がフェーズ値を確認するように変更されている。【０１１５】
すなわち、（ｐｉｄ，ｆｄ）のフェーズ値がｍｉｎＰｈａｓｅよりも小さい場合（ステップＳ５１３にて“Ｙ”の場合）、ゴミ収集プロセス１４は、ｍｉｎＰｈａｓｅの値をｐｉｄのフェーズ値に設定し（ステップＳ５１６）、ステップＳ５１７に進む。【０１１６】
一方、（ｐｉｄ，ｆｄ）のフェーズ値がｍｉｎＰｈａｓｅと等しいかあるいはｍｉｎＰｈａｓｅよりも大きい場合（ステップＳ５１３にて“Ｎ”の場合）、ゴミ収集プロセス１４は、（ｐｉｄ，ｆｄ）のフェーズ値をｍｉｎＰｈａｓｅに設定し（ステップＳ５１４）、ステップＳ５１５に進む。【０１１７】
続いて、ステップＳ７００では、ゴミ収集プロセス１４が、先ほどのステップＳ５１６で更新した解放可能なフェーズの情報をもとに、受信プロセス管理テーブル３３０のエントリと、通信データ管理テーブル（たとえば、３２０）と、通信データ保存領域４００とを解放する。【０１１８】
続いて、ステップＳ７０１では、ゴミ収集プロセス１４が通信管理テーブル（たとえば、３２０）を特定するためにフェーズ値を用いており、ステップＳ７０２ではゴミ収集プロセス１４は解放対象領域と判定するために、フェーズ値が最大数であるかどうかを確認している。【０１１９】
そして、フェーズ値が最大数でない場合は（ステップＳ７０２にて“Ｎ”の場合）、ゴミ収集プロセス１４は、ステップＳ５０６に戻る。【０１２０】
一方、フェーズ値が最大数の場合は（ステップＳ７０２にて“Ｙ”の場合）、ゴミ収集プロセス１４は、ステップＳ７０３へ進む。【０１２１】
最後に、ステップＳ７０３では、ゴミ収集プロセス１４が解放する対象として受信プロセス管理テーブルが追加されている。すなわち、ゴミ収集プロセス１４は、ｆｄに関連するディスクリプタ管理テーブルのエントリ、受信プロセス管理テーブル、通信データ管理テーブル、通信データ保存領域、読出位置管理テーブルのエントリを解放し（ステップＳ７０３）、ステップＳ５０６に戻る。【０１２２】
以上説明したように、本発明の第２実施形態では、あるディスクリプタに関する受信プロセス数の動的変更に対応するために、受信プロセス管理テーブルを用意して、受信プロセス数が変動するたびにフェーズを設定し、各フェーズの受信プロセス数を管理するように構成されている。【０１２３】
そのため、本実施形態では、受信プロセス数の変動に対応したゴミ収集処理が可能となる。【０１２４】
次に、本発明の第３実施形態について説明する。【０１２５】
第３実施形態はプロセス間通信システムにおける通信方法のプログラムに関するものである。図８は、プロセス間通信システムにおける通信方法のプログラムを実行するためのプロセス間通信システムの構成の一例を示している。【０１２６】
なお、同図において図１と同様の構成部分については同様の番号を付し、その説明を省略する。【０１２７】
図８を参照すると、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２１が伝送路２３を介してメモリ２２と接続されている。また、ＣＰＵ２１は、ゴミ収集プロセス１４と接続されている。メモリ２２は、たとえば磁気ディスクや半導体メモリで構成される。【０１２８】
メモリ２２には、図４並びに図７Ａ及び７Ｂにフローチャートで示すプロセス間通信システムにおける通信方法のプログラムが格納されている。【０１２９】
コンピュータ（ＣＰＵ）２１は、メモリ２２からそのプログラムを読出し、そのプログラムにしたがってゴミ収集プロセス１４を制御する。その制御内容については既に述べたので、ここでの説明は省略する。【０１３０】
以上説明したように、本発明の第３実施形態によれば、共有メモリのデータ解放処理を関連技術よりも低コストで実現することが可能なプロセス間通信システムにおける通信方法のプログラムが得られる。【０１３１】
この出願は、２００８年４月３０日に出願された日本出願特願２００８−１１７９７２を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【０１３２】
本発明によれば、１対多のプロセス間通信時のゴミ収集回収といった用途に適用が可能である。
【図１】
2009133722.tif 000003
【図２】
2009133722.tif 000004
【図３Ａ】
2009133722.tif 000005
【図３Ｂ】
2009133722.tif 000006
【図４】
2009133722.tif 000007
【図５】
2009133722.tif 000008
【図６Ａ】
2009133722.tif 000009
【図６Ｂ】
2009133722.tif 000010
【図７Ａ】
2009133722.tif 000011
【図７Ｂ】
2009133722.tif 000012
【図８】
2009133722.tif 000013
【手続補正書】
【提出日】平成22年9月27日(2010.9.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データを送信する送信プロセスと、
データを先頭から順次受信する複数の受信プロセスと、
前記送信プロセスが送信するデータが格納される通信データ保存領域と、
前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、
前記各受信プロセスが前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルと、
前記管理テーブルと、前記読出位置管理テーブルに記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放するゴミ収集プロセスとを含むことを特徴とするプロセス間通信システム。
【請求項２】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、そのディスクリプタに関する送信プロセスＩＤと、受信プロセスＩＤの一覧とを保持し、さらにそのディスクリプタで通信される通信データを管理する通信データ管理テーブルへのポインタを保持するディスクリプタ管理テーブルと、
前記ディスクリプタに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する前記通信データ管理テーブルとを含むことを特徴とする請求項１記載のプロセス間通信システム。
【請求項３】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項２記載のプロセス間通信システム。
【請求項４】
前記ゴミ収集プロセスは、
所定のディスクリプタに関する受信プロセスＩＤの一覧を取得し、
前記読出位置管理テーブルから前記ディスクリプタに関する各受信プロセスの読出位置を収集し、
前記通信データ管理テーブルの解放可能領域を算出し、
前記通信データ管理テーブルのエントリとそれに伴う通信データ保存領域を解放し、
さらに前記ディスクリプタがクローズされており、かつ、全エントリが解放可能な場合には、前記ディスクリプタ管理テーブルのエントリと、前記通信データ管理テーブルと、前記各受信プロセスの前記読出位置管理テーブルのエントリとを解放することを特徴とする請求項２または３記載のプロセス間通信システム。
【請求項５】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、
そのディスクリプタに関する送信プロセスＩＤと、
そのディスクリプタに関する受信プロセス数が変化する単位で、フェーズに分けて管理する受信プロセス管理テーブルへのポインタとを保持するディスクリプタ管理テーブルと、
前記各ディスクリプタのフェーズ毎の受信プロセスＩＤの一覧を管理する前記受信プロセス管理テーブルと、
前記受信プロセス管理テーブルに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する通信データ管理テーブルとを含むことを特徴とする請求項１記載のプロセス間通信システム。
【請求項６】
前記受信プロセス管理テーブルは、
各ディスクリプタの受信プロセスが変化する単位で管理するフェーズと、
前記フェーズ毎の受信プロセスＩＤの一覧と、
各フェーズで送信されるデータを格納する前記通信データ管理テーブルへのポインタとを含むことを特徴とする請求項５記載のプロセス間通信システム。
【請求項７】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとそのディスクリプタからのフェーズ情報とから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項５または６記載のプロセス間通信システム。
【請求項８】
前記ゴミ収集プロセスは、
所定のディスクリプタに関する受信プロセスＩＤの一覧を取得し、
前記ディスクリプタのフェーズ情報を取得した後に、
前記読出位置管理テーブルから前記ディスクリプタに関する各受信プロセスの読出位置を収集し、
前記受信プロセス管理テーブルの解放可能領域を算出し、
前記通信データ管理テーブルの解放可能領域を算出し、
前記受信プロセス管理テーブルのエントリと前記通信データ管理テーブルのエントリとそれに伴う通信データ保存領域を解放し、
さらに前記ディスクリプタがクローズされており、かつ、全エントリが解放可能な場合には、前記ディスクリプタ管理テーブルのエントリと、前記受信プロセス管理テーブルと、前記通信データ管理テーブルと、前記各受信プロセスの前記読出位置管理テーブルのエントリとを解放することを特徴とする請求項５から７のいずれか一項に記載のプロセス間通信システム。
【請求項９】
送信プロセスが送信するデータが格納される通信データ保存領域と、
前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、
データを先頭から順次受信する複数の受信プロセスの各々が前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルとを含み、
前記管理テーブルと前記読出位置管理テーブルに記録される各受信プロセスの読出位置とが、全ての受信プロセスが受信済みの領域を算出するのに用いられ、その算出結果に基づいてその領域が解放されることを特徴とする共有メモリ。
【請求項１０】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、そのディスクリプタに関する送信プロセスＩＤと、受信プロセスＩＤの一覧とを保持し、さらにそのディスクリプタで通信される通信データを管理する通信データ管理テーブルへのポインタを保持するディスクリプタ管理テーブルと、
前記ディスクリプタに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する前記通信データ管理テーブルとを含むことを特徴とする請求項９記載の共有メモリ。
【請求項１１】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項１０記載の共有メモリ。
【請求項１２】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、
そのディスクリプタに関する送信プロセスＩＤと、
そのディスクリプタに関する受信プロセス数が変化する単位で、フェーズに分けて管理する受信プロセス管理テーブルへのポインタとを保持するディスクリプタ管理テーブルと、
前記各ディスクリプタのフェーズ毎の受信プロセスＩＤの一覧を管理する前記受信プロセス管理テーブルと、
前記受信プロセス管理テーブルに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する通信データ管理テーブルとを含むことを特徴とする請求項９記載の共有メモリ。
【請求項１３】
前記受信プロセス管理テーブルは、
各ディスクリプタの受信プロセスが変化する単位で管理するフェーズと、
前記フェーズ毎の受信プロセスＩＤの一覧と、
各フェーズで送信されるデータを格納する前記通信データ管理テーブルへのポインタとを含むことを特徴とする請求項１２記載の共有メモリ。
【請求項１４】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとそのディスクリプタからのフェーズ情報とから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項１２または１３記載の共有メモリ。
【請求項１５】
データを送信する送信プロセスと、
データを先頭から順次受信する複数の受信プロセスと、
前記送信プロセスが送信するデータが格納される通信データ保存領域と、
前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、
前記各受信プロセスが前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルとを含むプロセス間通信システムにおける通信方法であって、
前記管理テーブルと、前記読出位置管理テーブルに記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放するゴミ収集ステップを含むことを特徴とする通信方法。
【請求項１６】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、そのディスクリプタに関する送信プロセスＩＤと、受信プロセスＩＤの一覧とを保持し、さらにそのディスクリプタで通信される通信データを管理する通信データ管理テーブルへのポインタを保持するディスクリプタ管理テーブルと、
前記ディスクリプタに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する前記通信データ管理テーブルとを含むことを特徴とする請求項１５記載の通信方法。
【請求項１７】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項１６記載の通信方法。
【請求項１８】
前記ゴミ収集ステップは、
所定のディスクリプタに関する受信プロセスＩＤの一覧を取得するステップと、
前記読出位置管理テーブルから前記ディスクリプタに関する各受信プロセスの読出位置を収集するステップと、
前記通信データ管理テーブルの解放可能領域を算出し、前記通信データ管理テーブルのエントリとそれに伴う通信データ保存領域を解放するステップと、
さらに前記ディスクリプタがクローズされており、かつ、全エントリが解放可能な場合には、前記ディスクリプタ管理テーブルのエントリと、前記通信データ管理テーブルと、前記各受信プロセスの前記読出位置管理テーブルのエントリとを解放するステップとを含むことを特徴とする請求項１６または１７記載の通信方法。
【請求項１９】
前記管理テーブルは、ディスクリプタのＩＤを示すディスクリプタＩＤと、
そのディスクリプタに関する送信プロセスＩＤと、
そのディスクリプタに関する受信プロセス数が変化する単位で、フェーズに分けて管理する受信プロセス管理テーブルへのポインタとを保持するディスクリプタ管理テーブルと、
前記各ディスクリプタのフェーズ毎の受信プロセスＩＤの一覧を管理する前記受信プロセス管理テーブルと、
前記受信プロセス管理テーブルに対応して設けられ、前記通信データ保存領域に保存されるデータのデータＩＤと、アドレスと、長さとを管理する通信データ管理テーブルとを含むことを特徴とする請求項１５記載の通信方法。
【請求項２０】
前記受信プロセス管理テーブルは、
各ディスクリプタの受信プロセスが変化する単位で管理するフェーズと、
前記フェーズ毎の受信プロセスＩＤの一覧と、
各フェーズで送信されるデータを格納する前記通信データ管理テーブルへのポインタとを含むことを特徴とする請求項１９記載の通信方法。
【請求項２１】
前記読出位置管理テーブルは、前記受信プロセスＩＤと前記ディスクリプタとそのディスクリプタからのフェーズ情報とから、次に読み出すべきデータＩＤと読出位置が取得可能に構成されることを特徴とする請求項１９または２０記載の通信方法。
【請求項２２】
前記ゴミ収集ステップは、
所定のディスクリプタに関する受信プロセスＩＤの一覧を取得するステップと、
前記ディスクリプタのフェーズ情報を取得するステップと、
フェーズ情報を取得した後に、前記読出位置管理テーブルから前記ディスクリプタに関する各受信プロセスの読出位置を収集するステップと、
前記受信プロセス管理テーブルの解放可能領域を算出し、前記通信データ管理テーブルの解放可能領域を算出し、前記受信プロセス管理テーブルのエントリと前記通信データ管理テーブルのエントリとそれに伴う通信データ保存領域を解放するステップと、
さらに前記ディスクリプタがクローズされており、かつ、全エントリが解放可能な場合には、前記ディスクリプタ管理テーブルのエントリと、前記受信プロセス管理テーブルと、前記通信データ管理テーブルと、前記各受信プロセスの前記読出位置管理テーブルのエントリとを解放するステップとを含むことを特徴とする請求項１９から２１のいずれか一項に記載の通信方法。
【請求項２３】
データを送信する送信プロセスと、
データを先頭から順次受信する複数の受信プロセスと、
前記送信プロセスが送信するデータが格納される通信データ保存領域と、
前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、
前記各受信プロセスが前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルとを含むプロセス間通信システムにおける通信方法のプログラムであって、
コンピュータに、前記管理テーブルと、前記読出位置管理テーブルに記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放するゴミ収集ステップを実行させるためのプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００２３
【補正方法】変更
【補正の内容】
【００２３】
また、本発明によるプログラムは、データを送信する送信プロセスと、データを先頭から順次受信する複数の受信プロセスと、前記送信プロセスが送信するデータが格納される通信データ保存領域と、前記通信データ保存領域に保存されるデータのサイズと位置を管理する管理テーブルと、前記各受信プロセスが前記通信データ保存領域から次に取得するデータの位置を記録する読出位置管理テーブルとを含むプロセス間通信システムにおける通信方法のプログラムであって、コンピュータに、前記管理テーブルと、前記読出位置管理テーブルに記録される各受信プロセスの読出位置とを参照して全ての受信プロセスが受信済みの領域を算出し、その領域を解放するゴミ収集ステップを実行させることを特徴とする。
【国際調査報告】
2009133722.tif 000014
2009133722.tif 000015
2009133722.tif 000016
2009133722.tif 000017