プロセス間のデータ交流問題

[新緑]

こんにちは

例えば、
親プロセスA(某関数)よりCreateProcess(...)関数で新しいプロセスBが生成されたとします。
それからプロセスA(関数A)がプロセスBに処理すべきデータをどんどん送りたいし、Bの処理結果も見たいという場合、
どうすればいいでしょうか。
ネット上いろいろ探してみましたが、
不思議なことに、
プロセス間のデータ交流に関する議論はほとんど無いですね。

ご存知の方ぜひお願い申し上げます。

[h2so5]

ネット上いろいろ探してみましたが、
不思議なことに、
プロセス間のデータ交流に関する議論はほとんど無いですね。

「プロセス間通信」で検索をすれば色々出てきますよ。

[softya（ソフト屋)]

Windowsであれば、メモリマップドファイルとプロセス間同期処理を併用するといてはあります。

[YuO]

データ通信をストリーム的に行いたいなら，名前付パイプとかSocketとか。
どちらにしても非同期I/Oやスレッドを使うので，面倒ではあります。
# ウィンドウ持っているなら，WM_COPYDATA投げ合うのが一番楽な気もしますが……。

[新緑]

ありがとうございます。

「通信」という言葉ですね。

同じコンピューター中のプログラム間のデータやり取りで
自分の頭の中に「通信」という概念はなかったんです。

「通信」といえば、基本は距離のある異なるPC間のデータやり取りで、
高速で多量データを同じPCの中で転送する手法に関してはまだ分かっていません。
ファイル経由だと明らかに速度が落ちますし、
pipeやら、send messageやら 実際多量で高速データ転送可能なのかどうか不明です。
もしかして全部ファイル経由かな？

[h2so5]

「通信」といえば、基本は距離のある異なるPC間のデータやり取りで、
高速で多量データを同じPCの中で転送する手法に関してはまだ分かっていません。
ファイル経由だと明らかに速度が落ちますし、
pipeやら、send messageやら 実際多量で高速データ転送可能なのかどうか不明です。
もしかして全部ファイル経由かな？

高速データ転送といっても、どれくらいの速度が要求されるのかによって方法は変わります。
メインメモリ並の速度が必要ならば同一プロセスにするしかないでしょう。

[新緑]

みなさんご指導ありがとうございます。

環境は MS windows 7 64bit
MS visual studio VC++ 2010

> メインメモリ並の速度が必要ならば同一プロセスにするしかないでしょう。

できれば、メモリ共用のレベルの速度がほしいですね。
親プロセスが一つ、それより生成された子プロセスが三つ、互いに処理データが見えるようにしたいです。

ネットを調べたら、プロセス間確かに「メモリ共用」という方式がありますが、
やり方を記述されるところ見つかりませんでした。

Q１．どうやってこのような「メモリ共用」を確保します？
Q２．複数のプロセス間共用できるメモリのサイズは？　----計算方法があります？
Q３．VC++の何関数でプロセス間の共有メモリを操ります？

どなたかご教授いただければ幸いです。

[softya（ソフト屋)]

Q1 私の回答がスルーされてますが、それがメモリマップドファイルなのです。
「ファイルマッピング」
http://wisdom.sakura.ne.jp/system/winap ... in150.html
「メモリマップドファイルを使ってアプリケーション間でデータを共有する - C++Builder Tips」
http://www.gesource.jp/programming/bcb/82.html

Q2 物理メモリ量でサイズは考えたほうが良いと思います。つまり、メモリスワップを起こさない前提で考えないと速度低下が起きます。
無茶なサイズを指定したこと無いので他にも制限はあるかもしれません。

Q3 メモリマップドファイルは、上にリンク先を見てください。

[新緑]

softya　様
お世話になっております。
情報ありがとうございます。
ご提供されたページを学習させていただきましたが、
どうも共有ファイルの読み書きのテクニックばかりであって、
「共有メモリ」の話ではありませんね。

ファイルの読み書きだと途轍もない遅いでしょう。
とかく、ある程度のリアルタイム性が要求される検査分野に不向きでは？

誤解しましたら、ご指摘いただきたいです。

[h2so5]

ご提供されたページを学習させていただきましたが、
どうも共有ファイルの読み書きのテクニックばかりであって、
「共有メモリ」の話ではありませんね。

ファイルを経由していますが、マッピングによって仮想メモリと同じようにアクセスできるので実質的に共有メモリです。

ファイルの読み書きだと途轍もない遅いでしょう。
とかく、ある程度のリアルタイム性が要求される検査分野に不向きでは？

ファイルの保存先をSSDやRAMディスクにすれば速度に関してはある程度改善できそうです。
そもそもそんなに高速なデータ共有を必要としているにも関わらずプロセスを分けているという設計がおかしいのでは？

主にデバッグ向けのようですが、
WindowsではReadProcessMemory, WriteProcessMemoryという関数を使って他プロセスのメモリにアクセスできるようです。

[ISLe]

メモリマップドファイルは仮想記憶の仕組みを使うので、物理メモリが足りていればキャッシュの更新だけが行われると思います。
絶対確実ではないですが。
#明示的にファイルを更新することもできます。
それから、ファイルをマッピングしないで、物理メモリ上のキャッシュのみを扱うこともできます。

自分の作ったプロセス間でメモリしかアクセスしなくても、ウィンドウズの仮想記憶がいつディスクにアクセスするかは予測不能かと。

リアルタイム性が要求される分野向けにリアルタイムOSというものがあります。

[新緑]

皆さん有難うございます。

> メモリマップドファイルは仮想記憶の仕組みを使うので、物理メモリが足りていればキャッシュの更新だけが行われると思います。

これで
ふっと良いアイデア( ? ) が頭に浮かんだけれども、
プロセス間共有データを確実に物理的なメモリに駐留させるために、
その「共有ファイル」を「メモリ仮想ファイル」= 「メモリによる仮想デスク」にすればいいでしょう。
これは「ファイルを仮想メモリにする」とはまったく逆発想ですね。

皆さんのご見解を教えていただけませんか。

[YuO]

その「共有ファイル」を「メモリ仮想ファイル」= 「メモリによる仮想デスク」にすればいいでしょう。
これは「ファイルを仮想メモリにする」とはまったく逆発想ですね。

仮想デスクが何者かがわかりませんが，既に

それから、ファイルをマッピングしないで、物理メモリ上のキャッシュのみを扱うこともできます。

とISLeさんが述べられていることと何か違うのでしょうか。
ref) Sharing Files and Memory (Windows)

ところで，共有メモリ形式ではスレッドと同じく同期や排他制御が必要になりますが，そのあたりの知識は十分ですか。
書き込み中における読み込みによるDirty-Readが起きても構わず，さらには同時書き込みによるデータ破損があってもよいならば無視して良いですが，
そうでないならば同期・排他の話がつきまといます。
ref) Interprocess Synchronization
おそらく，実メモリアクセス速度よりも，プロセス間同期の速度の方が全体を律すると思います。
# 共有メモリへのアクセスのたびに排他制御が必要になるため。

[新緑]

ご教授ありがとうございます

ISLe さんが書きました:
＞　それから、ファイルをマッピングしないで、物理メモリ上のキャッシュのみを扱うこともできます。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
「物理メモリ上のキャッシュのみを扱う」
これを保証するやり方を教えてくださいませんか。
物理メモリ上のキャッシュのサイズを自由設定によって解決できる問題でしょうか。

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
「Sharing Files and Memory (Windows)」に関して
結局ハードディスクなど二次媒体の利用を前提にされていますね。

なので、確実にデータの格納場所をメインメモリ(RAM)に駐留するために、
例えば、Ramdisk　のようなソフトツールを使って、
ramでdiskなど外部媒体二次媒体を模擬すれば、
その「共有ファイル」をramdisk上に生成して、良いかと思って、
前回「逆発想」と呼びました。

ramメモリ共用のために------> ファイル化（＝　二次媒体化 )------> ファイルを高速アクセスするためにramメモリ化。
こうすると、プロセス間の「メモリ共有」は必ずメインメモリ内で済ませるのを保障されますね！
という願望なんですけれども、どうでしょうか、
また皆さんのご見解を拝見させていただきたいです。


YuOさんが書きました:
＞　おそらく，実メモリアクセス速度よりも，プロセス間同期の速度の方が全体を律すると思います。
# 共有メモリへのアクセスのたびに排他制御が必要になるため。

大変重要なアドバイスで本当にありがとうございます。
また宜しくお願い致します。

[softya（ソフト屋)]

RAMディスクも、それなりのペナルティがあります。
許される速度限界や、実行環境など状況を限定していないので、かもな～ぐらいしか言えません。

[ISLe]

ウィンドウズを使う限り、スワップの可能性を完全に排することはできないですよね。
プロセスAやプロセスB、RAMディスクがスワップされない方法は考えなくて良いのですか？
共有メモリがスワップされる前にプロセスがスワップされる可能性のほうが高い気がしますけど。

[新緑]

softya様が書かれました：
> RAMディスクも、それなりのペナルティがあります。
> 許される速度限界や、実行環境など状況を限定していないので、かもな～ぐらいしか言えません。

環境は
CPU Intel(R) Core(TM) i7 CPU 980 @ 3.33GHz 3.33GHz
OS windows 7 64bit

MS visual studio VC++ 2010

[ 許される速度限界]
100 ns に近いほどいいと思いますが。
数倍も超えたら好ましくないですね。

メモリ関連の指標(参照のため)
L1 cache reference: 0.5 ns
Branch mis-predict: 5 ns
L2 cache reference: 7 ns
Mutex lock/unlock: 25 ns
Main memory reference 100 ns


**************************************************************
ISLe様が書かれました：
> プロセスAやプロセスB、RAMディスクがスワップされない方法は考えなくて良いのですか？

えっ、こんな事もあるんですか！
回避方法はないでしょうか？
困りますねーーー

[softya（ソフト屋)]

WindowsOSを使っている時点でプロセス切り替えがns台は無理ですね。
あとＯＳのプロセスがバックグラウンドで走るので、それもｍｓ単位で実行時間を奪います。
一般的なWindows/Liunx/MacOSを使わないか、要求を満たせるリアルタイムOSを探すべきです。
OSなしなら確実に処理できそうです。
OSありだと場合によっては２つのプロセスを別ハードにしないと実現できないかもしれません。
32bitマイコンの利用も視野に入れたほうが良いでしょう。

[YuO]

100ns台の応答速度が必要なプログラムって，いったいなんでしょう。
通常の案件ではないとしか思えませんが……。
その応答速度を必要とするのであれば，最初からプロセス分離とかしないでしょうし……。

[新緑]

皆さんご指導ありがとうございます。

> 100ns台の応答速度が必要なプログラムって，いったいなんでしょう。

お互いに誤解だったようです。
100ns台というのは共有メモリに対するアクセスの理想値です。
RAMの物理的な可能性を目安にしています。
ようはハードdiskという「共有ファイル」経由での「共有メモリ」は不向きと強調したいわけで、
プロセス自体の処理時間やプロセスの切り替え時間とは別物。

[softya（ソフト屋)]

いや、お互いにも何も新緑さんが出した情報を元にしてしか、こちらは情報を出せません。
で、元の質問に戻るわけです。

> 許される速度限界や、実行環境など状況を限定していないので、かもな～ぐらいしか言えません。
って事で同じ事聞きます。このループを終わらせるには要件定義を明確にしてもらうことです。

[新緑]

お世話になっております。
実行環境をもう一度申し上げます。
CPU Intel(R) Core(TM) i7 CPU 980 @ 3.33GHz 3.33GHz
OS windows 7 64bit

です。

共有メモリのアクセス速度として word/400ns 以上であればokです。
なお、プロセス間の切り替え時間に制限要求はございません。


またどうぞ宜しくお願い致します。

[softya（ソフト屋)]

> 共有メモリのアクセス速度として word/400ns 以上であればokです。
> なお、プロセス間の切り替え時間に制限要求はございません。

それだと「共有メモリのアクセス速度」を制限する意味が殆どないと思います。
全体的な速度はプロセス切り替えを含めての時間ですから、word/400nsを絶対値として守る必要性が出た時点でWindowsOSは失格です。
平均値としてword/400nsを守るなら出来るかもしれません。その場合、当然ながら時間によってはword/10msとかになると思います。

[新緑]

ご指導ありがとうございます。

＞全体的な速度はプロセス切り替えを含めての時間ですから、
複数プロセス並行に実行されて、お互いに時にはデータ交流をしますが、
プロセスの切り替えはしません。

それから、一つだけ確認させていただきたいですが、
プロセス間の「メモリ共有」と言えば、必ず２次媒体経由を或いは潜在的に経由する事を意味するのでしょうか。
即ち、
main memory としてのRAM領域には異なるプロセスが共にアクセスできる処は絶対ないでしょうか。

実行環境
CPU Intel(R) Core(TM) i7 CPU 980 @ 3.33GHz 3.33GHz
OS windows 7 64bit

[softya（ソフト屋)]

>　複数プロセス並行に実行されて、お互いに時にはデータ交流をしますが、
> プロセスの切り替えはしません。

それは、マルチタスク・マルチプロセスの動作を理解していると思えない意見です。
自動で発生するのがマルチタスク・マルチプロセス対応ＯＳなんですよ。
Windowsを使っている限り完全には避けれません。
どれだけのシステムプロセスがバックグラウンドで動作しているか理解されていますか？

ちゃんとＯＳの勉強されたほうが良いと思います。

> プロセス間の「メモリ共有」と言えば、必ず２次媒体経由を或いは潜在的に経由する事を意味するのでしょうか。
> 即ち、
> main memory としてのRAM領域には異なるプロセスが共にアクセスできる処は絶対ないでしょうか。

それは、ISLeさんとかが散々書かれていますが実体ファイルは必ずしも必要ありません。よく読みなおしてみてください。
ちゃんと実験していれば分かっているはずの事です。

LinuxOSであれば、文字通りの共有メモリがあるのでイメージ的に拘るのであればLinuxOSに移れば良い事ですね。
「[C言語]共有メモリ(shm)を読み書きするサンプルコード」
http://blog.majide.com/2009/03/c-shared-memory-program/
※　移る必要性など皆無なんですけどね。

[新緑]

皆さん
親切にご指導本当にありがとうございました。
詳しく勉強になりました！
これからいろいろ実験や学習しなければならないことが多いと良く分かりました。