POSIXメッセージキュー - mq_sendスレッドウェイクオーダー

Question

メッセージキューが複数のスレッドを1つのメッセージキューでブロックされた複数のスレッドをブロックする方法を説明できますか？

私の状況は、完全なメッセージでブロックする複数のライターを持っています キュー、それぞれ優先度がスレッド と等しいメッセージを投稿しています。私は彼らが目覚めて優先順に投稿したいと思っていますが、 私のアプリケーションはFIFO順で目覚めているかのように動作しています（つまり、ブロックされた順序）。各ブロッキングスレッドはSCHED_FIFOポリシーでスケジュールされた であり、システムレベルのスコープは と異なる優先度です。

私は、これは動作するはずですし、私が見つけることができるすべては優先度スケジューリングが をサポートされている場合 複数のブロッカーは優先順位に目覚めることを記述したPOSIX manページでどのように 記述何かのためのハイとローのインターネットを検索しました。カーネルスケジューラが優先順位スケジューラであるため、I は、スレッドが優先順位で目覚めて、 にキューすると考えていますが、そうではありません。私は確かに私は ちょっと微妙な詳細が不足していると確信しています このリストは、 でこれらのスレッドが実行する準備ができているので、私は何を見ているいくつかの光を照らすのに役立つことができます。

私は必要に応じてここに投稿できる小さなテストアプリケーションを持っています。単にキューを埋めるだけで、すべてのスレッドの試行と書き込みが行われます。すべてスレッドの優先順位が異なり、メッセージの優先順位がスレッドの優先順位と同じです。その後、キューからメッセージを削除し、最も優先度の高いスレッドが起動し、そのメッセージを送信することを期待します。ただし、待機する最初のスレッドは最初にメッセージをポストします。

これの最下部に到達するために、誰でも私に指示できるヘルプやドキュメントはありますか？

ありがとうございます！

Answer 1

Linuxカーネルは、キューがいっぱいになるとタスクの優先度値を調べ、それらを待ち行列にタスクniceness order（非RTタスクの優先順位）で追加します。待ち行列は、私のアプリケーションが使用するリアルタイムの優先順位を尊重しません。非RTの優先順位（素敵な値）は適切に処理され、適切な順序で目を覚ます。

内部カーネルの待ち行列にタスクを追加する際に、カーネルが優先順位をどのように処理していたかの根本的な原因です。私は受け入れられたlinux-kernelリストにパッチを提出し、待ち行列にタスクを追加する際に優先度チェックを変更する将来のリリースにロールアップされる予定です。これは現在非RT優先度とRT優先度の両方を尊重します。デッドラインのスケジュールされたタスクの優先順位は処理されません。