処理対象アイテムと処理中アイテムの両方の破棄をサポートするバックグラウンド処理エンジンを構築しています。これは、いくつかの入力要素の重い処理を必要とする winforms アプリケーションで使用するためのものです。そのため、ワークロード アイテムをキューに入れることができるキュー エンジンを構築しています。それらが処理されると、結果が通知されます。
問題は、このキューにはほとんどの場合、最初から多くのアイテムが含まれているということです。すべてをスレッドプールにダンプするのではなく、最初の N 個のアイテムのみをスレッドプールに配置し、それらが存在する場合はバックフィルを続けます。処理されます。これを行う理由は、それらをスレッドプールにダンプすると処理され、破棄としてタグ付けされていても、キュー時間がかかるためです。
私が作成したバックフィルの実装を使用すると、アイテムが破棄された場合にキューからアイテムを削除し、いわば自分の順番になったときにのみキューに入れることができます。
問題は、この数 N (スレッド プール キューに配置して保持するアイテムの数) をどのように計算するかということです。
私が検討した問題：
- すべてのプロセッサが機能していることを確認するために、2 * プロセッサの数をキューに入れたいと思うかもしれません。これは典型的なアイテム数です。
- ただし、一部のアイテムの実際の処理が超高速である場合 (発生する可能性があります)、自分のクラスがより多くの作業をバックフィルする前に、スレッドプールのキューが使い果たされます。プロセッサ
- 各アイテムにかかる現在の時間に基づいて最適な数を計算するための自動調整ルーチンを作成する必要があるため、それらがすべて超高速である場合、数ははるかに高くなり、処理に少し時間がかかる場合はそのままになります。低い？
どう思いますか？
New : わかりました。回答の 1 つにより、もう少し説明します。キューに入れられるすべてのアイテムは、一意のものによってキーが付けられます。既存のアイテムと同じキーを持つ別のアイテムをキューにダンプすると、その古いアイテムは「破棄」と見なされ、削除する必要があります。アイテムが処理中の場合、ワークロード アイテムのプロパティが true に設定されます。これは、処理メソッドが呼び出す「IsDicarded」プロパティです。破棄されたアイテムを検出した場合は、結果を返さずに早期に終了する必要があります。
おそらく、もう少し実験して、すべてをスレッドプールにダンプする必要があります。
新しい質問: キューに入れることができるアイテムの数に制限はありますか? そうでない場合、これは私のクラスを簡単に簡素化します。
注: 「処理が長い」とは、1 ～ 10 秒程度のことです。スレッドプールはこれに最適ですか? 「処理は速くあるべきだ」というメモを Web のいたるところで見かけますが、「速い」とは何かについては言及されていません。ここはミリ秒単位で速いですか？