1

私たちのアプリは、.soファイルとしてロード可能な外部のサードパーティ提供の構成（カスタムの運転/意思決定機能を含む）に依存しています。

独立して、共有メモリのチャンクを使用して外部CGIモジュールと連携し、揮発性状態のほとんどすべてが保持されるため、外部モジュールはそれを読み取り、必要に応じて変更できます。

問題は、CGIモジュールが.soからの永続的な構成データを大量に必要とし、メインアプリがデータを利用可能にするために2つのメモリ領域間でまったく不要なコピーを大量に実行することです。アイデアは、共有オブジェクト全体を共有メモリにロードし、CGIで直接利用できるようにすることです。問題は：どうやって？

  • dlopenとdlsymには、SOファイルをロードする場所を割り当てるための機能はありません。
  • shmat（）を試しました。一部の外部CGIが実際に共有メモリにアクセスしようとするまでしか機能しないようです。次に、ポイントされたエリアは、共有されなかったかのようにプライベートに表示されます。多分私たちは何か間違ったことをしているのですか？
  • .soを必要とする各スクリプトに.soをロードすることは問題外です。構造のサイズは非常に大きく、呼び出しの頻度に関連しています（一部のスクリプトは、ライブ更新を生成するために1秒に1回呼び出されます）。これは、組み込みアプリであるため、使用できません。
  • .soをshmに単純にmemcpy（）することも適切ではありません。一部の構造体とすべての関数は、ポインターを介して相互接続されています。
4

4 に答える 4

4

共有メモリを使用するときに最初に覚えておくべきことは、同じ物理メモリが異なるアドレスとして2つのプロセスの仮想アドレス空間にマップされる可能性があるということです。これは、ポインタがデータ構造のどこかで使用されている場合、問題が発生することを意味します。正しく機能するには、すべてがインデックスまたはオフセットで機能する必要があります。共有メモリを使用するには、コードからすべてのポインタを削除する必要があります。

.soファイルをロードする場合、.soファイルコードのコピーが1つだけロードされます（したがって、共有オブジェクトという用語が使用されます）。

forkここであなたの友達かもしれません。最新のオペレーティングシステムのほとんどは、コピーオンライトセマンティクスを実装しています。つまり、の場合fork、1つのプロセスが特定のデータセグメントに書き込むときにのみ、データセグメントが個別の物理メモリにコピーされます。

于 2010-01-25T11:56:33.887 に答える
2

最も簡単なオプションは、ニールがすでに提案しているメモリマップトファイルを使用することだと思います。このオプションがうまく満たされない場合は、専用のアロケータを定義することもできます。これについての良い論文があります：共有メモリでのSTLコンテナの作成

優れたIonGaztañagaのBoost.Interprocessライブラリshared_memory_objectと関連機能もあります。Ionは、将来のTRのためにC ++標準化委員会にソリューションを提案しました。C++のメモリマップトファイルと共有メモリ は、検討する価値のあるソリューションを示している可能性があります。

于 2010-01-30T06:58:26.043 に答える
2

ご存知のように、実際のC++オブジェクトを共有メモリに配置することは非常に困難です。そのようにしないことを強くお勧めします。共有する必要のあるデータを共有メモリまたはメモリマップトファイルに配置する方がはるかに簡単で、はるかに堅牢になる可能性があります。

于 2010-01-25T09:58:30.950 に答える
0

オブジェクトのシリアル化を実装する必要があり ます。シリアル化関数はオブジェクトをバイトに変換します。次に、SharedMemoryにバイトを書き込み、CGIモジュールでバイトをオブジェクトに逆シリアル化することができます。

于 2010-01-29T12:41:08.250 に答える