0

キューがあります (実際には 3 つの異なるキューですが、違いがあるとは思いません)。キューには個別の作業単位が含まれています。

QueueManager新しいスレッドを生成して返す があります。新しいスレッドはキューを見て、作業の一部を取得し、それを処理するために新しいスレッドを生成します。

私は明らかに同時スレッドの数に制限が必要であり、ジョブが終了したらスレッドを再利用しない理由はありません。

一部のジョブは実行に時間がかかります (分/時間) ThreadPool。これは、数秒以上かかるものには適していないことを読みました。

事実上、ThreadPool を実装したいのですが、もう少し制御したいと思います。

それで...これを達成するための標準的なベストプラクティスの方法は何ですか?

する必要があるようです (キューの長さ > を想定MaxThreadCount)

  • ヒットするまで新しいジョブを作成するMaxThreadCount
  • いずれかのスレッドが完了するまで待機する
  • キューから次のジョブを取得し、スレッドに割り当てます
  • 繰り返す
  • キューが空になったら、しばらくスリープしてから再チェックする

(この場合のキューはデータベース内にあるため、アイテムが追加されたときのイベントはありません。ポーリングする必要があると思います)

多くのジョブには、リモート サイト/API からのページの取得が含まれ、多くの場合、繰り返し行われます。そのため、コアよりもかなり多くのスレッドを使用することでメリットが得られると思います (ほとんどのスレッドはネットワークを待機するため)。そのため、64スレッドの制限があるため、適切ではないと思います。 WaitHandle

これは明らかにかなり一般的なパターンなので、それを実装するための確立された方法があるに違いないと思いますか?

誰かが私に良い例を示すことができれば、それは素晴らしいでしょう.

4

1 に答える 1

2

TPL（タスク並列ライブラリ）を使用します。それはまさにこの目的のために設計されています。

http://msdn.microsoft.com/en-us/library/dd460717.aspx

具体的には、MaximumConcurrencyLevelが必要なスレッド数に設定されているTaskSchedulerインスタンスを使用してTaskFactoryを作成する必要があるようです。次に、作業項目をキューに入れる代わりに、TaskFactory.StartNewを呼び出します。それはあなたのために仕事の待ち行列を処理します。

于 2012-06-15T15:26:14.227 に答える