タスクvs ThreadPool

Question

私はC＃で作業するリストを持っています。できるだけ多くの作業を並行してやろうとしています。しかし、私は並列タスクの最大量を制御できる必要があります。

私はこれがスレッドプールまたはタスクで可能であると理解しています。私が使っているものに違いはありますか？私の主な関心事は、一度にアクティブになっているスレッドの数を制御できることです。

Answer 1

TaskのためParallelOptions.MaxDegreeOfParallelismをご覧ください。

Tasksを使用することをお勧めします。これは、ThreadPoolよりも高いレベルの抽象化を提供するためです。

非常によく読まれたトピックはhereです。実際には必読書があり、その上に自由にあります。

Answer 2

セマフォを作成して、一度に実行できるスレッド数を制御することもできます。新しいセマフォを作成し、そのセマフォを一度に使用できる同時スレッドの数をコンストラクタで指定できます。どのようにスレッドを使用するのか分からないので、これは良い出発点になります。

MSDN Article on the Semaphore class

-Wesley

Answer 3

このarticle on msdnでは、なぜ彼らは並列性のためにThreadPoolの代わりにTasksを推奨するのかを説明しています。

Answer 4

タスクには私にとって非常に魅力的な機能があります。タスクのチェーンを構築できます。これは前にタスクの特定の結果で実行されます。 よく使う機能は次のとおりです。タスクAはバックグラウンドで実行され、長時間実行されています。私はそれの後にタスクBを連鎖し、タスクAが定期的に終了してフォアグラウンドで実行するように設定したので、タスクAを長時間実行した結果、コントロールを簡単に更新できます。

Answer 5

TPLでは、 ParallelEnumerableまたはParallelOptions.MaxDegreeOfParallism

上WithDegreeOfParallelismも、あなただけのカスタムスレッドやタスクを使用している場合は、より良い選択肢であることができるCountdownEventがあります。

ThreadPoolではAppDomainのグローバル番号SetMaxThreadsを使用すると、関連性のないコードを不必要に制限する可能性があります。

ワーカースレッド数またはI/O完了スレッド数を、コンピュータ内のプロセッサ数よりも小さい数に設定することはできません。

インターネットインフォメーションサービス（IIS）やSQL Serverなどで共通言語ランタイムがホストされている場合、ホストはスレッドプールサイズの変更を制限または防止できます。

スレッドプール内の最大スレッド数を変更する場合は注意が必要です。コードが有益な場合がありますが、その変更は使用するコードライブラリに悪影響を与える可能性があります。

スレッドプールのサイズを大きくしすぎると、パフォーマンス上の問題が発生する可能性があります。あまりに多くのスレッドが同時に実行されている場合は、タスクの切り替えのオーバーヘッドが重要な要素になります。

私はあなたが両方に欲しいものを達成するためにマルチスレッドのその優れた抽象化としてThreadPool上TPLを使用しますが、その可能性すべき他の回答に同意します。