私は主な「消費者」プロセスが、ディスクからデータを読み取り、それを「消費者」に渡して表示する一連の「リーダー」プロセス（〜16）を作り出すLinuxアプリケーションを作成しました。データは、socketpairを使用してフォークの前に作成されたソケットを介して渡されます。共有メモリを使用している場合、スレッディングよりもプロセスに利点はありますか？
私はもともと3つの理由でこのプロセス境界でそれを書いた：
消費者プロセスは、リアルタイムの制約を持っているので、私は消費者のいずれかのメモリ割り当てを避けたかったです。読者は自由にメモリを割り当てたり、別の言語（例えば、ガベージコレクション）で書かれていても、FIFOの優先順位を持つ消費者を中断させることはありません。また、読者プロセスにおけるディスクアクセスまたは他のIOは、消費者を妨害しない。私はスレッドで私はそのような保証を得ることができないと考えました。
プロセスを使用すると、プログラマは、グローバル変数を使用したり、他のプロセスのメモリを壊すような愚かなことをやめてしまいます。
複数のCPUアーキテクチャーを利用する最良の方法はたくさんありますが、スレッドの代わりにプロセスを使うのが一般的に安全だと思いました。
すべての読者が常にアクティブであるわけではありませんが、アクティブな人は常に大量のデータを送信しています。最近、私は、ソケットの書き込みと読み取りに関連するメモリコピーを避けることでこれを最適化することを考えていました。データを共有メモリバッファ（shm_open/mmap）に直接読み込むといいでしょう。この共有メモリーへの索引のみがソケットを介して渡され、消費者はそれを再び利用可能とマークする前にそれを直接読み取ることになります。
とにかく、スレッドに対するプロセスの最大の利点の1つは、へのの別のスレッドのメモリ空間の破壊です。共有メモリへの切り替えは、私がこのアーキテクチャで持っている利点を破壊すると思いますか？このコンテキストでプロセスを使用する利点はありますか？または、スレッドを使用するようにアプリケーションを切り替えるだけですか？
本当に？どういうわけか、 'malloc'が' sbrk'を使ってヒープサイズを拡張する必要があると感じると、プロセス全体が停止する可能性があるという印象を受けました。同様に、スレッドがページ違反を生成するメモリ操作を行っている場合、プロセス内のすべてのスレッドを停止させる可能性があります。多分それは間違っている？ – Steve
それは間違っています。スレッドを停止させるだけです。厳密に言えば、これは実装の詳細です（おそらくPOSIXリアルタイムオプションに準拠しているシステムを除いています）。しかし、正常な実装ではこれらの操作で他のスレッドをストールすることはできません。確かにLinux、BSD、そして他の主流のUnixでは、それは単にスレッドが停止するだけです。 –
さて、ありがとう、情報ありがとうございます。 – Steve