複数のマルチスレッドプロセスを使用して、やや複雑なソフトウェアをプログラミングしています。そのうちの 1 つでリアルタイム機能が必要なので (基本的に堅牢性のために)、ターゲット カーネルに Xenomai 用のパッチを適用し、Xenomai のネイティブ スキンを使用してプログラムしました。
ここで、2 つのプロセスを通信する必要があります。1 つはリアルタイム タスクを実行し、もう 1 つは単にpthreadを実行します(後者は Xenomai のリアルタイム ライブラリ/スキンなしでコンパイルされます)。
私の質問は、どうにかしてそれらを伝えることができますか? たとえば、共有メモリ オブジェクト ( shm_open) を作成し、そのうちの 1 つが RT 環境にある場合でもミューテックスを共有できますか?
などの名前付きパイプを作成するには、Xenomai のネイティブ API を使用することをお勧めしますrt_pipe_create()。
使用できるものがもう 1 つあります。メッセージ キューです。ただし、私は常にメッセージ キューよりも名前付きパイプを選択してきました。
共有メモリとメッセージ キューの両方を使用して、プロセス間で情報を交換できます。違いは、それらの使用方法にあります。
共有メモリは、まさにあなたが考えているものです。それは、複数のプロセスで読み書きできるストレージ領域です。固有の同期は提供しません。つまり、あるプロセスが別のプロセスのデータを破壊しないようにするのは、プログラマの責任です。ただし、スループットの点では効率的です。読み取りと書き込みは比較的高速な操作です。
メッセージ キューは一方向のパイプです。1 つのプロセスがキューに書き込み、別のプロセスが書き込まれた順にデータを読み取ります。これは、データの終わりの状態が発生するまで続きます。キューが作成されると、メッセージ サイズ (メッセージあたりのバイト数、通常はかなり小さい) とキューの長さ (保留中のメッセージの最大数) が設定されます。各読み取り/書き込み操作は通常 1 つのメッセージであるため、アクセスは共有メモリよりも遅くなります。ただし、キューは、各操作がメッセージ全体を正常に処理するか、キューを変更せずに失敗することを保証します。したがって、部分的なメッセージのみを書き込んだ後にライターが失敗することは決してなく、リーダーは完全なメッセージを取得するか、まったくメッセージを取得しないかのいずれかになります。
基本的に、パイプは、名前付きか匿名かにかかわらず、メッセージ パッシングのように使用されます。誰かが受信者に情報を送信し、受信者はそれを受け取ることができます。共有メモリは、データの公開に似ています。誰かがデータを共有メモリに配置すると、リーダー (多くの可能性があります) は、たとえばセマフォを介して同期を使用して、新しいデータがあるという事実を知る必要があり、情報を見つけるためにメモリ領域を読み取る方法を知っている必要があります。 .
パイプを使用すると、同期は単純で、パイプ メカニズム自体に組み込まれています。興味深いことが起こると、読み取りと書き込みがアプリをフリーズおよびフリーズ解除します。共有メモリを使用すると、非同期で作業し、新しいデータをたまにしかチェックしない方が簡単ですが、コードがはるかに複雑になります。さらに、多対多の通信を行うことができますが、さらに多くの作業が必要になります。また、上記の理由により、共有メモリのデバッグよりもパイプベースの通信のデバッグの方が簡単です。
小さな違いは、fifo がファイル システムで直接表示されるのに対して、共有メモリ セグメントを作成した場合などに備えて、共有メモリ領域には ipcs などの特別なツールが必要であるということです。セマフォや、共有メモリと一緒に使用する必要がある他の多くの同期メカニズム)。
また、共有メモリを使用すると、バッファリングとリソースの使用をより詳細に制御できます。OS で許可されている制限内で、割り当てるメモリの量とその使用方法を決定するのはユーザーです。パイプを使用すると、OS が自動的に制御するため、柔軟性は失われますが、多くの作業から解放されます。
最も重要なポイントの要約: 1 対 1 の通信用のパイプ、コーディングの削減と OS による処理、多対多用の共有メモリ、手動による制御の増加、ただしより多くの作業とより困難なデバッグのコストがかかる