問題タブ [ipcs]

私は共有メモリ アプリケーションを使用しており、次のコマンドを使用してセグメントを削除しています。

ipcsしかし、実行すると同じセグメントが表示されますが、キーが 0x0000000 であるため、正しいことを行っているかどうかはわかりません。では、メモリ セグメントは本当に削除されているのでしょうか。アプリケーションを数回実行すると、次のようにキー 0x000000 を持つさまざまなメモリ セグメントが表示されます。

実際に何が起こっているのですか？メモリセグメントは本当に削除されていますか?

編集：問題は、受け入れられた回答で以下に述べたように、共有メモリを使用する2つのプロセスがあり、すべてのプロセスが閉じられるまでメモリセグメントが消えないことでした。

pshared=1 の posix 共有メモリと posix の名前のないセマフォを使用して、クライアント サーバー アプリケーションを構築しました。セマフォは共有メモリ内に配置されます。プログラムは正常に実行されますが、ipcs -m または ipcs -s と入力すると、作成した共有メモリ セグメントまたはセマフォが表示されません。なぜそうなのですか？

必要に応じて個別のプロセス (.NET EXE) を開始する抽象ファクトリがあります。抽象ファクトリは、いつでもプロセスを開始し、新しく作成されたプロセスが抽象ファクトリが存在するプロセスと通信できるようにする必要があります。このプロセス間通信は、それらを作成したファクトリで行われます。これらはバックグラウンド プロセスになります (GUI は関係ありません)。この問題の可能な解決策は何ですか?

.NET リモート処理または PIPES はどちらも、プロセスが開始された後にプロセスが通信できるようにしますが、最初にオンデマンドで開始する必要があり、個別のスタンドアロン プロセスを実行します (タスク マネージャーとスタンディング プロセスに表示されます)。その後、プロセス間通信が行われます。

Boost を使用しようとしましたが、サイズ 24 のオブジェクトを 3000 回割り当てた後、segv がありました。今は sys/ipc.h と sys/shm.h を使い始めました。25 ミリオ バイトを割り当てます (これを適切に理解している場合)。

私のLinuxボックスでも適切に動作するようです ipcs -m は、割り当てられたセグメントを表示します

sysctl -p は出力します

何らかの理由で、プログラムが「43406 x 24 バイト」に達するまで動作し、それが segv になります。私の問題がどこにあるのか、いくつかのヒントを得ることができてうれしいです。これが共有メモリをオブジェクトに割り当てて使用する間違った方法であるかどうかにも注意してください。

共有メモリセグメントを削除するC++プログラムを作成しようとしています。私はそれがを使用してcmdプロンプトから行うことができることを知っています

ipcs -m | awk '{ print $2 }' | xargs ipcrm -m

しかし、共有メモリのガベージコレクターを作成するために、C++を使用してそれを実行しようとしています。

プロセス（nattach == 0）またはステータス==NULLに接続されていない共有メモリセグメントを削除するという考え方です。

引数として渡された shmid (共有メモリ ID) によって共有メモリ セグメント情報を表示するプログラムを作成しました。

このデータをコマンド ipcs によって返されたデータと比較すると、私のプログラムが共有メモリ セグメントに関する誤った情報を示していることが明らかです。

理由を理解するのを手伝ってもらえますか?

ありがとうございました。

適切なフラグを使用して共有メモリとセマフォを開きます。

呼び出しは失敗しません（私はそれらをチェックします）。実際、他のプロセスがそれらを作成しfork、exec他のプロセスがメモリとセマフォを共有し、適切な同期が行われている1つのプロセス。

ただし、コマンドを使用するとipcs、共有メモリもセマフォも表示されません。何故ですか？が表示されない場合ipcs、どこで確認できますか？

私のipcs出力では、セマフォ配列リストにエントリがなく、共有メモリ内のエントリは、skype、firefox、および（firefoxの）plugin-containerに関連しています。私はそれらをチェックしました

ファイル名とそれに渡されたゼロに基づいてキーを生成するために ftok() を使用するシステム内の既存のコードがあります。コードは 32 ビットでは問題なく動作していましたが、64 ビットに移行するとランダムにエラーが発生し始めます。more を調査したところ、これは主に下位ビットがゼロであり、 shmopen() がより良い代替手段である可能性があるためであることがわかりました。shmopen() はキーの衝突から安全ですか? キーの衝突を回避するより良い方法はありますか?

特定のパーマ「644」を使用して、いくつかの共有メモリとメッセージ キューを割り当てています。

それらを手動で削除するのは大変な作業なので、その特定のパーマ 644 ですべての行を削除する方法を知りたい.

例えば

------ 共有メモリ セグメント -------- key shmid owner perms bytes nattch status
0x00000000 0 benny 600 33554432 2 dest
0x00000000 229377 benny 644 52 0

------ セマフォ配列 -------- キー semid 所有者 perms nsems

------ メッセージ キュー -------- key msqid owner perms used-bytes メッセージ
0x2731af4c 262144 benny 644 840 30
0x0756d9c1 294913 benny 644 16380 585
0x2d1b2cc7 327682 benny 644 0 0
0x343dccc1 benny 0 0454

ありがとう。

IPC キュー内のメッセージが順序付けされているかどうかを知る必要があります。実際には、msgrvc 関数を呼び出したときに最初のメッセージがキューに入力されたのか、選択されたメッセージがランダムなのかを知る必要があります。

さて、私がこの質問をしたのは、コード msgrcv の一部の内部で、そのコードを意図していないメッセージを受け取ったときに、通常、メッセージを再キューイングし、キュー内の次のメッセージを読み取るためです。私が疑問に思っているのは、たとえば、彼がメッセージをフォローしている場合、

msgA、msgB、msgC

、キュー内に格納されています

msgB、msgC、msgA

したがって、次の msgrcv の呼び出しで msgB が返されるか、またはその順序がランダムな場合は、再度 msgA を読み取ることができます

ありがとう、エンツォ