PPL Concurrency::TaskSchedulerを使用して、メディア パイプラインからサブスクライブしたクライアント (通常は GUI アプリ) にイベントをディスパッチします。
これらのイベントは、 Concurrency::TaskScheduler::ScheduleTask()に渡される C++ ラムダです。
ただし、負荷がかかると、パイプラインは、クライアントがそれらを消費できるよりも速い速度でイベントを生成できます。
スケジュールされたタスクの「キュー」が N より大きい場合、イベント ディスパッチャーがイベント (実際にはスケジュールされたタスク) をキューに入れないようにするために使用できる PPL 戦略はありますか? そうでない場合、どうすれば自分で転がすことができますか？
API を見ると、スケジューラが高負荷にさらされているかどうかを知る方法がないように見えます。また、そのような状況でどのように動作するかを指示する方法もありません。ポリシーを使用してスケジューラ内で実行できる同時実行スレッドの数に制限を設定することは可能ですが、スケジューラが新しいタスクを受け入れまたは拒否するプロトコルは明確ではありません。
私の賭けは、スケジューラーに既にいくつのタスクがあるかを数えることによって、そのメカニズムを自分で実装し、スケジューラーの前にサイズ制限されたキューを用意して、着信タスクの流れを軽減するのに役立つことです。
ラムダに単純な std::queue を使用できると思います。新しいイベントが発生するたびに、実行中のタスクの数を確認し、実行中のタスクの最大数に達するまでキューからできるだけ多くのタスクを追加します。その後もキューがいっぱいの場合は、新しいタスクを拒否します。
実行中のタスクのアカウンティングを処理するには、完了時にカウンターをデクリメントする関数でタスクをラップし (競合を避けるためにミューテックスを使用します)、新しいタスクをスケジュールするときにカウンターをインクリメントします。