15

共有メモリを使用する場合、キーの作成を気にする必要があるのはなぜですか

key_t ftok(const char *path, int id);

次のコードで？

key_t key;
int shmid;

key = ftok("/home/beej/somefile3", 'R');
shmid = shmget(key, 1024, 0644 | IPC_CREAT);

私が理解したことから、特定の共有メモリにアクセスするために必要なのはshmid、キーではなく です。それとも私が間違っていますか？必要なshmidものが .

編集

@ Beej's Guide to Unix IPCを読むことができます：

このkeyナンセンスはどうですか？どのように作成しますか？タイプ key_tは実際にはただの であるためlong、任意の数値を使用できます。しかし、番号をハードコードし、別の無関係なプログラムが同じ番号をハードコードしたが、別のキューが必要な場合はどうなるでしょうか? 解決策はftok() 、2 つの引数からキーを生成する関数を使用することです。

これを読むと、共有メモリブロックに何を付けるかが鍵だという印象を受けます。しかし、これは真実ではありませんね。

4

3 に答える 3

16

System V IPC システム全体は、このような悪い設計でいっぱいです。ftok(悪い設計とは、キーを取得し、使用中の他のキーと競合しないように祈るなどの愚かなトリックに頼らなければならない、共有リソース用の小さな名前空間を意味します。)

可能であれば、存在しないふりをして、可能であれば常に POSIX 共有メモリを代わりに使用します (同様に、System V セマフォの代わりに POSIX スレッド同期プリミティブを使用します)。System V 共有メモリが必要な場所として私が思いつく唯一の例は、X 共有メモリ イメージ拡張機能と、おそらく他の X 拡張機能です。

編集: :ftokの目的に関するOPの質問によりよく答えるにkey_tは、通常32ビットであり、32ビットの数値を自分で選択することもできますが、問題は、人間がすべての数値を選択する可能性が等しくなく、衝突の可能性があることですは高すぎる。ftokファイル (アプリケーションに固有のファイル) と整数を選択し、選択した整数でファイルの inode 番号をハッシュできます。これにより、キー空間全体でキーの選択がより均等に分散されます。もちろんrand、共有メモリをアタッチする必要がある他のプロセスに結果を渡す方法がある限り、キーを選択することもできます。

于 2010-11-14T06:12:11.823 に答える
14

shmat()はい、を使用して共有メモリを開いた後、（を使用して）共有メモリにアクセスするには、shmidを使用する必要がありますshmget()。ただし、アクセスする共有メモリの特定のブロックは、使用しているキーに基づいています。つまり、shmを介して通信する別のプロセスでは、同じキーを使用する必要があります。乱数をキーとして使用しただけの場合、他の無関係なプログラムと衝突する可能性があります。

BeejのIPCガイドをご覧になることをお勧めしますが、すでに見つけていると思います:)

于 2010-11-14T00:32:11.303 に答える
1

shmid値は単一のプロセスのコンテキストでのみ有効ですが、key_t異なるプロセスで同じ値を使用すると、同じ共有メモリ セグメントを開くことができます。

key_tこれが本質的に、共有メモリセグメントに名前を付けるクロスプロセスの方法として -が必要な理由です。についてftok()は、他の回答が指摘しているように、2 つの無関係なプロセス グループが同じkey_t値を使用する可能性を減らすために使用されます。

于 2010-11-14T10:03:45.310 に答える