RTOSのキューの置換

タスク間通信またはRTOSの2つのタスク間でデータを共有するために、キューを使用します。しかし、キューの問題は、処理が遅いことです。...バッファ内のデータをコピーし、次にミューテックス処理を行い、次にデータ転送を行います。大きなデータを転送する必要がある場合、イライラするほど遅くなります。別の問題は、複数のタスクが同じキューにアクセスする場合です。次に、画像は次のようになります。-最初にキューへのアクセスを待機してから、内部ミューテックス処理をキューに入れ、データ転送を行います。

これにより、システムのオーバーヘッドが増加します。キューの効率的な代替品は何ですか？

（この質問は、使用しているRTOSに依存しないと思います。ほとんどのRTOSは、この方法でのみキューを処理します）

キューは、タスク間通信のスレッドセーフなトランザクションモデルであるため、そのように動作します。厳密性の低いスキームでは、データの破損や所有権の問題が発生します。

データをメモリ内のバッファにコピーしてから、キュー要素にポインターを渡すのですか、それともキュー要素内のすべてのデータを渡そうとしているのですか？ポインターを渡さない場合は、キュー要素を一度に1バイトずつ渡す代わりに、ポインターを渡すとパフォーマンスが向上します。

1つの簡単な方法は、キューにデータへのポインターを置き、ポインターを使用してデータを消費することです。

次のことを確認する必要があるため、パフォーマンスと安全性の両方を犠牲にしていることに注意してください。

1. バッファは、コンシューマがデータを消費するまで有効のままです
2. 誰かがバッファの割り当てを解除します

動的に割り当てられたメモリを使用していない場合、メモリの割り当てを解除する必要はありませんが、データが消費される前にメモリ領域が再利用されないようにする必要があります。

ロックフリーキューは、単一生産者/単一消費者の場合に実装でき、多くの場合、ソフトウェアを設計して、複数生産者または複数消費者のキューの数を最小限に抑えることができます。

ロックフリーキューは次のように構築できます。通信する要素の配列と2つの整数を割り当て、それらをHeadおよびTailと呼びます。Headは、次の項目が追加される配列へのインデックスです。末尾は、次の項目を削除できる配列へのインデックスです。プロデューサータスクはHとTを読み取り、アイテムを追加する余地があるかどうかを判断します。Hインデックスにアイテムを書き込み、Hを更新します。コンシューマタスクはHとTを読み取り、利用可能なデータがあるかどうかを判断し、インデックスTからデータを読み取り、Tを更新します。操作の順序（挿入、更新H、削除、更新T）により、データ破損が発生しないようにします。

複数のプロデューサーと単一のコンシューマー、または単一のプロデューサーと複数のコンシューマーが存在する場合、事実上何らかのリソース制限があり、パフォーマンスリミッターはより多くの可能性があるため、同期を使用する以外には何もありませんロックメカニズムを使用したOSオーバーヘッドよりも、単独のプロデューサ/コンシューマになります。

しかし、複数のプロデューサーとコンシューマーがある場合は、より調整されたコミュニケーションメカニズムを取得できないかどうかを確認するために（デザインスペースで）時間を費やす価値があります。このような場合、単一のキューを介してすべてをシリアル化すると、キューの効率がパフォーマンスの中心的な決定要因になります。

キュー自体が、ロードストア専用、比較交換、または同様のプリミティブで動作するのに十分小さいアイテムを保持している場合、ロックフリーのマルチプロデューサーシングルコンシューマキューで効率的な操作を得ることができ、空のキュースロットの予約値または予約値。キューに書き込むとき、ライターはデータを次の空のスロットに保存するために比較交換を行います。それが失敗した場合、ライターは次のスロットを試します。キューは次の空のスロットへのポインターを維持しますが、ポインター値は「助言」です。システムがload-store-exclusiveではなくcompare-exchangeを使用する場合、異なる「空のスロット」値の「ファミリー」が必要になる場合があることに注意してください。それ以外の場合、ライターが空のキュースロットを見つけて書き込みを試みると、別のライターがスロットを書き込み、リーダーがそれを読み取ります。最初のライターは、知らないうちにデータをリーダーが見えない場所に置きます。この問題は、load-store-exclusiveを使用するシステムでは発生しません。これは、store-exclusiveが古い値に書き戻されたにもかかわらず、データが書き込まれたことを検出するためです。

キューの先頭に書き込むことで、キューにもっと効率的にアクセスできます。通常、RTOSのほとんどは、ミューテックスの取得を必要としないキューの先頭への追加をサポートしています。ただし、データをより高速に実行したい場合は、キューの先頭への追加をできるだけ最小限に抑えてください。通常、キュー構造には最大サイズ制限があるため、すべてのデータをキューに入れることができないため、ポインターを渡すのは常に簡単です。

乾杯！！

キューは本質的に低速ではありません。それらの実装があります。

盲目的にデータをコピーし、同期キューを使用している場合、パフォーマンスが低下します。

他のポスターが示しているように、ロックフリーの代替手段があります。単一の生産者/単一の消費者の場合は簡単です。複数のプロデューサーとコンシューマーの場合、マイケルとスコットによるロックフリーキューアルゴリズム（姓）は標準であり、JavaのConcurrentLinkedQueueの基礎として使用されます。

特定のケースでキューの必要性を最適化することは可能ですが、タスクを分離できるようにすることで、システムに大幅な簡素化の利点をもたらす並行性の保証を提供します。