c - Linuxのメッセージキューの欠点は何ですか？

Question

組み込みLinux上のプロセス間の通信に使用されるメッセージキューに取り組んでいます。Linuxが提供するメッセージキューを次のように使用しないのはなぜだろうと思います。

msgctl、msgget msgrcv、msgsnd。

共有メモリを作成する代わりに、セマフォと同期しますか？

この一連の関数をビジネス組み込み製品で直接使用することの欠点は何ですか？

Answer 1

関数msgctl()、、、、およびmsgget()は「SystemVIPC」メッセージキュー関数です。彼らはあなたのために働くでしょう、しかし彼らはかなり重いです。それらはPOSIXによって標準化されています。msgrcv()msgsnd()

mq_close()POSIXは、より最新の関数セット、、、、、、、、、も提供します。これは、あなたmq_getattr()にとってより良いかもしれません（富の恥ずかしさなど）。mq_notify()mq_open()mq_receive()mq_send()mq_setattr()mq_unlink()

ただし、どちらがデフォルトでターゲットプラットフォームにインストールされているかを確認する必要があります。特に組み込みシステムでは、それらを構成する必要があるか、デフォルトでは存在しないためにインストールする必要がある可能性があります（共有メモリとセマフォについても同じことが言えます）。

どちらのメッセージ機能セットの主な利点は、それらが（おそらく）事前にデバッグされているため、同時実行性の問題がすでに解決されていることです。一方、共有メモリとセマフォを使用して自分でそれを行う場合は、多くのことがあります。同じレベルの機能を実現するために行うべき作業の数。

したがって、可能な場合は（再）使用してください。オプションの場合は、独自のシステムを作り直すのではなく、2つのメッセージキューシステムのいずれかを使用してください。最終的にパフォーマンスのボトルネックなどがあることに気付いた場合は、独自の代替案を作成することを検討できますが、それまでは再利用してください。

Answer 2

System Vメッセージキュー（msg *システムコールによって操作されるもの）には、多くの奇妙な癖や落とし穴があります。新しいコードについては、UNIXドメインソケットを使用することを強くお勧めします。

そうは言っても、共有メモリ方式ではなくメッセージパッシングIPCを強くお勧めします。共有メモリは間違いを犯しやすく、壊滅的に失敗する傾向があります。

Answer 3

メッセージの受け渡しは、小さなデータチャンクや、メッセージキューがデータをコピーするため、不変性を維持する必要がある場合に最適です。

共有メモリ領域は、送信/受信時にデータをコピーせず、クリーンでないプログラミングモデルとのトレードオフで、より大きなデータセットに対してより効率的になる可能性があります。

Answer 4

不利な点は、メッセージキューがごくわずかであり、一部のシステムコールとコピーのオーバーヘッドであり、ほとんどのアプリケーションでは何の意味もありません。メリットはそのオーバーヘッドをはるかに上回ります。同期は自動であり、ブロッキング、非ブロッキングなどのさまざまな方法で使用できます。Linuxではメッセージキュータイプがファイル記述子として実装されてselect()いるため、多重化の呼び出しにも使用できます。SYSVキューを使用する必要が本当に強い場合を除いて、使用する必要があるPOSIXの種類では、キュー項目を処理するためのスレッドまたはシグナルを自動的に生成することもできます。そして何よりも、それらは完全にデバッグされています。

Answer 5

メッセージキューと共有メモリは異なります。そして、どちらを使用するかを選択するのはプログラマーと彼の要件次第です。共有メモリでは、読み取りと書き込みに少し注意する必要があります。そして、プロセスを同期させる必要があります。したがって、共有メモリでは実行の順序が非常に重要です。共有メモリでは、読み取り値が新しく書き込まれた値であるか、古い値であるかを確認する方法はありません。そして、待つための明確なメカニズムはありません。

メッセージキューと共有メモリは異なります。そして、どちらを使用するかを選択するのはプログラマーと彼の要件次第です。メッセージキューでの生活を楽にするための事前定義された関数があります。