どのLinux IPC=使用するテクニック？
私たちはまだプロジェクトの設計段階にありますが、組み込みLinuxカーネル上で3つの別個のプロセスを持つことを考えています。プロセスの1つは、さまざまな媒体を介したデバイスとのすべての通信を処理する通信モジュールです。
他の2つのプロセスは、通信プロセスを介してメッセージを送受信できる必要があります。 Linuxが提供するIPCテクニックを評価しようとしています。他のプロセスが送信するメッセージのサイズは、デバッグログから最大5 Mbitレートのストリーミングメディアまでさまざまです。同時にストリーミングすることもできます。
どのIPCこのアプリケーションにテクニックを提案しますか？ http://en.wikipedia.org/wiki/Inter-process_communication
何か変更があった場合、プロセッサは約400〜500 Mhzで実行されています。クロスプラットフォームである必要はありません。Linuxで十分です。 CまたはC++での実装が必要です。
私はUnixドメインソケットに行きます：IPソケットよりもオーバーヘッドが少ない（つまり、マシン間通信がない）が、それ以外は同じ利便性です。
IPCを選択するときは、転送バッファサイズ、データ転送メカニズム、メモリ割り当てスキーム、ロックメカニズムの実装、さらにはコードの複雑さなどのパフォーマンスの違いの原因を考慮する必要があります。
利用可能なIPCメカニズムのうち、パフォーマンスの選択はしばしば Unixドメインソケット または 名前付きパイプ（FIFO） 。 プロセス間通信のさまざまなメカニズムのパフォーマンス分析に関する論文を読みました/ IPCは最高のパフォーマンス：競合する結果 elsewhere を見ましたが、これはパイプの方が良いかもしれないことを示しています。
少量のデータを送信するときは、簡単にするために名前付きパイプ（FIFO）を好みます。これには、双方向通信のために名前付きパイプのペアが必要です。 Unixドメインソケットは、セットアップ（ソケットの作成、初期化、接続）に少しオーバーヘッドがかかりますが、より柔軟性があり、パフォーマンスが向上する（スループットが向上する）場合があります。
特定のアプリケーション/環境に対していくつかのベンチマークを実行して、最適なものを判断する必要がある場合があります。提供された説明から、Unixドメインソケットが最適かもしれません。
Beij's Guide to Unix IPCは、Linux/Unix IPCを使い始めるのに適しています。
誰もdbusに言及していないとは信じられない。
http://www.freedesktop.org/wiki/Software/dbus
http://en.wikipedia.org/wiki/D-Bus
アプリケーションのアーキテクチャが単純な場合は、パフォーマンスが重要な制御された組み込み環境で共有メモリを上回ることはできません。
パフォーマンスが本当に問題になる場合は、共有メモリを使用できます-しかし、他の方法よりもはるかに複雑です-データの準備ができたことを通知するためのシグナリングメカニズム（セマフォなど）と、構造への同時アクセスを防ぐためのロックが必要です修正中です。
利点は、メモリにコピーせずに大量のデータを転送できることです。これにより、場合によってはパフォーマンスが確実に向上します。
おそらく、共有メモリを介してより高いレベルのプリミティブを提供する使用可能なライブラリがあります。
共有メモリは通常、MAP_SHAREDを使用して同じファイルをmmapすることで取得されます（永続化したくない場合はtmpfs上にあります）。多くのアプリはSystem V共有メモリも使用します（愚かな歴史的理由から私見。同じものに対するニースのインターフェースははるかに少ないです）
この記事の執筆時点（2014年11月）で、KdbusとBinderはLinuxカーネルのステージングブランチを離れました。現時点でどちらかが成功するという保証はありませんが、Outlookは両方に対してある程度前向きです。バインダーは、Androidの軽量なIPCメカニズムです。Kdbusは、コンテキストスイッチを削減し、メッセージングを大幅に高速化するカーネルのdbusのようなIPCメカニズムです。
また、「Transparent Inter-Process Communication」またはTIPCがあります。これは堅牢で、クラスタリングおよびマルチノードのセットアップに役立ちます。 http://tipc.sourceforge.net/
Unixドメインソケットは、ほとんどのIPC要件に対応します。カーネルはこのIPC機能を提供するため、この場合、専用の通信プロセスは本当に必要ありません。私の意見ではLinuxで最も活用されていないIPCの1つですが、n：1の通信が必要な多くの場合に非常に便利です。