0

あまりにも多くのタスクが既にキューに入れられている場合、TaskFactory がタスクを長時間実行しない可能性はありますか? その場合、より多くのタスクをより迅速に実行できるように taskfactory を構成する方法があります。

また、同じプロセス内で TaskFactory と Threadpool.QueueUserWorkItem の両方を使用すると問題が発生しますか? まだ Threadpool クラスを使用している古いライブラリがいくつかあります。

4

2 に答える 2

2

アルヴィン。実行するタスクをキューに入れると、ThreadPool のスレッドを使用して実行するようにスケジュールされます。実行されるタスクの数と実行速度は、使用可能なスレッドの数と特定のタスクの実行にかかる時間に基づいています。キュー タスクが多数ある場合、スレッドプールは必要に応じて新しいスレッドをスピンアップできますが、これは利用可能なリソースと CPU に大きく依存します。スレッドプールはデフォルトのスレッド数を設定するように構成できますが、ほとんどの場合、これは推奨されません。

デフォルトのタスク スケジューラは同じスレッドプールを使用するため、タスクと Threapool.QueueUserWorkItem の両方を一緒に使用しても問題はありません。発生するのは、同じスレッドプールによる処理を待っているキューに入れられたタスクが増えることだけです。

于 2012-07-12T11:21:52.673 に答える
0

TPL を使用すると、タスクは自動的にスレッド プールに入ります。スレッドプールは、同時に実行される実行中のスレッドの数を監視します。アクティブなスレッドが多すぎると、OS に管理上の負担がかかり、パフォーマンスが低下します。スレッド数が事前に定義された制限に達すると、スレッドはキューに入れられます。いくつかの背景...

スレッド プールは、そのプール内の 1 つのスレッドから開始され、プール マネージャーは、追加の非同期ワークロードに対処するために新しいスレッドを「注入」します。非アクティブ状態が一定期間続くと、プール マネージャーは、スレッドを「リタイア」することでスループットが向上すると判断した場合に、スレッドを「リタイア」することがあります。上記の場合、プールマネージャーは同時スレッドの数を制限しています。

を呼び出して、プールが作成するスレッド数の上限を設定できますThread.Pool.SetMaxThread;。デフォルトは次のとおりです。

1023 in Framework 4.0 in a 32-bit environment.
32768 in Framework 4.0 in a 64-bit environment.
250 per core in Framework 3.5.
25 per core in Framework 2.0.

[これらの数値は、ハードウェアと OS によって異なる場合があります]。

これらの膨大な数の理由 (少なくとも .NET 4.0 の場合) は、一部のスレッドがブロックされている場合でも (いくつかの集中的な作業を実行している場合など)、進行が確実に行われるようにするためです。

で下限を設定できますThreadPool.SetMinThreads。このリミッターの役割は、最大リミッターの役割よりも微妙です。これは、プール マネージャーに対して、この数の下限に達するまでスレッドの作成を遅らせないように指示します。この数を設定すると、ブロックされたスレッドがある場合の同時実行性が向上します。

Framework 4.0 より前のバージョンを使用している場合、TPL は使用できません。4.0 を使用して呼び出すことができますQueueUserWorkItem。これは (一見すると) 問題を引き起こすことはありません。

これが役立つことを願っています。

于 2012-07-12T11:25:08.830 に答える