関数 msgctl() 、 msgget() 、 msgrcv() 、および msgsnd() 'System V IPC' メッセージ キュー関数です。それらはあなたのために働きますが、かなり重いです。これらは POSIX によって標準化されています。
POSIX は、より最新の関数セット mq_close() も提供します。 、 mq_getattr() 、 mq_notify() 、 mq_open() 、 mq_receive() 、 mq_send() 、 mq_setattr() 、および mq_unlink() どちらがあなたにとってより良いかもしれません (富の恥)
ただし、いずれかがデフォルトでターゲット プラットフォームにインストールされているかどうかを確認する必要があります。特に組み込みシステムでは、デフォルトでは存在しないため、それらを構成したり、インストールしたりする必要がある場合があります (共有メモリとセマフォについても同じことが言えます)。
どちらのメッセージ機能セットの主な利点も、(おそらく) 事前にデバッグされているため、同時実行性の問題が既に解決されていることです。一方、共有メモリとセマフォを使用して自分でそれを行う場合は、多くの利点があります。同じレベルの機能を実現するために必要な作業の量。
したがって、可能な場合は (再) 使用してください。それがオプションである場合は、独自のメッセージ キュー システムを再発明するのではなく、2 つのメッセージ キュー システムのいずれかを使用してください。最終的にパフォーマンスのボトルネックなどがあることに気付いた場合は、独自の代替案を作成して調査できますが、それまでは 再利用してください!
System V メッセージ キュー (msg* システム コールによって操作されるもの) には、多くの奇妙な癖や落とし穴があります。新しいコードについては、UNIX ドメイン ソケットを使用することを強くお勧めします。
そうは言っても、共有メモリ スキームよりもメッセージ パッシング IPC を強くお勧めします。共有メモリは間違いを犯しやすく、壊滅的な間違いを犯す傾向があります。
メッセージ パッシングは、小さなデータ チャンクや、メッセージ キューがデータをコピーするため、不変性を維持する必要がある場合に最適です。
共有メモリ領域は、送受信時にデータをコピーせず、クリーンでないプログラミング モデルと引き換えに、より大きなデータ セットに対してより効率的になる可能性があります。