共有メモリIPCとメモリ同期の落とし穴

なぜ共有メモリが最速なのか──コピーが消える

プロセス間通信 の手段の中で、共有メモリが最速とされる理由は単純です。データのコピーが一切起きないからです。

パイプやソケットでは、送信側のユーザバッファ → カーネルバッファ → 受信側のユーザバッファ、と最低2回のコピーとシステムコールが各転送で発生します。これに対し共有メモリは、同じ物理ページを送受信両プロセスの仮想アドレス空間に対応づけることで、書いた瞬間に相手から見える状態を作ります。確立後のデータ転送経路にカーネルは介在せず、システムコールもコピーもゼロです。

仕組みの核は 仮想記憶 のページテーブルにあります。各プロセスは独立した仮想アドレス空間を持ちますが、ページテーブルのエントリ（PTE）が指す物理フレームを共通にすれば、別々の仮想アドレスから同一の物理メモリを触れます。

プロセスA: 仮想 0x7f00_1000 ─┐
                            ├─→ 同一の物理フレーム 0x12345000
プロセスB: 仮想 0x55a0_2000 ─┘

カーネルは整合を保証しない──同期はすべてアプリの責任

ここが最大の落とし穴です。カーネルが提供するのは「同じ物理ページを両者に見せる」ことだけで、いつ・どの順で・どこまで書き込みが相手に見えるかについては何も約束しません。パイプには暗黙の順序とアトミックな境界（PIPE_BUF以下の書き込みは分断されない）がありますが、共有メモリにはそれすらありません。

つまり「Aが構造体を書き終えてからBが読む」という当たり前の前提を、アプリ側が明示的に作らねばなりません。これを怠ると、Bが書きかけの中途半端な状態を読む、あるいは後述の並べ替えでフラグだけ先に見えてデータが見えないといった破綻が起きます。

共有メモリの速さは「カーネルが手を引いた」ことの裏返しです。最速と引き換えに、同期の正しさという最も難しい部分が丸ごとアプリ側に降ってきます。

メモリバリアが要る理由──フラグとデータの順序

排他制御（同時に1つしか触らせない）だけでなく、書き込みが相手に見える順序も問題になります。よくある生産者・消費者パターンを考えます。

生産者: data = 42;        // ① データを書く
        ready = 1;        // ② 完成フラグを立てる

消費者: while (ready==0); // ③ フラグ待ち
        use(data);        // ④ データを使う

直感では①→②の順なので、③でフラグが見えたら④では必ず42が読めそうです。ところがそうとは限りません。CPUのストアバッファやコンパイラの最適化により、①と②の見える順序が入れ替わりうるからです。消費者側でも③と④の読み込みが投機的に並べ替えられえます。結果、フラグは1なのにdataは古い値という状態が観測されます。

これを防ぐのがメモリバリア（フェンス）です。生産者は②の前にreleaseバリア、消費者は③の後にacquireバリアを置くことで、「フラグが見えたならそれ以前の書き込みもすべて見える」順序を確立します。

実務では生バリアを自分で書くより、後述の 共有ミューテックス／セマフォを使うのが安全です。ロックの獲得・解放操作は内部で適切なバリアを発行するため、ロックで囲んだ区間の可視性は自動的に保証されます。

ロックは共有領域の中に置く──PROCESS_SHARED属性

共有メモリの同期で初学者が必ず踏むのが、ロックの配置です。pthreadミューテックスを普通に宣言すると、それはそのプロセスのヒープ／スタック上に作られ、相手プロセスからは見えません。各プロセスが「自分だけのロック」を取り合うので、排他はまったく機能しません。

正しくは、ミューテックス自体を共有メモリ領域の中に置き、かつ「複数プロセスで共有する」と宣言します。

pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
// このミューテックスはプロセス間で共有されると宣言
pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);

// shm の中（共有領域）にミューテックスを構築する
pthread_mutex_init(&shared->mutex, &attr);

PTHREAD_PROCESS_SHARED 属性が肝です。これがあると、ロックの待機・起床に使うfutex のキーが物理ページ基準で計算され、別プロセスからでも同じ待ち行列に合流できます。デフォルトの PTHREAD_PROCESS_PRIVATE ではプロセス内限定のキーになり、プロセスをまたいだ待ち合わせが成立しません。

POSIX shm_openとSysV shmget──同じ目的、違う流儀

共有メモリの作り方には大きく2系統あります。新規開発ならファイル的に扱えるPOSIX系（shm_open + mmap）が推奨されますが、既存システムでは古いSysV系（shmget）も現役です。原理上の違いを押さえます。

POSIXの shm_open が返すのはファイルディスクリプタで、その実体は /dev/shm（tmpfs）上のファイルです。だから mmap でアドレス空間に張れ、ftruncate でサイズを変えられ、ls /dev/shm で存在を確認できます。close してもファイルは残り、shm_unlink で名前を消します。「名前」と「マッピング」を分けて参照カウントで管理するのがファイル流の利点です。

SysVの shmget はカーネル内に常駐オブジェクトを作り、shmat でアタッチします。明示的に IPC_RMID で削除しない限りカーネルに残り続けるため、異常終了でゴミが溜まりやすいのが弱点です。ipcs -m で残骸が見えるのはこのためで、運用では ipcrm での掃除が要ります。

落とし穴を避ける設計チェックリスト

まとめ──速さの代償は同期の全責任