ユーザーがバーコードをスキャンするたびに起動するスレッドがあります。
ほとんどの場合、かなり短い実行スレッドです。ただし、非常に長い時間がかかる場合があります (GUI スレッドへの呼び出しを待機するため)。
スキャンごとに独自のスレッドを作成するのではなく、ThreadPool を使用することをお勧めします。
しかし、ThreadPool がスレッドを使い果たした場合、他のスレッドが終了するまで待機することも読みました (私がやっていることは問題ありません)。
では、スレッドが不足する可能性はどれくらいありますか? そして、ThreadPool のメリットは本当に価値があるのでしょうか? （スキャンすると、スキャンがスレッドロジックを「実行」するのにそれほど時間がかからないようです。）
「非常に長い時間」の意味と、そのシナリオがどれほど一般的かによって異なります。
MSDN のトピック「The Managed Thread Pool 」には、スレッド プール スレッドを使用しない場合の適切なガイドラインが示されています。
スレッド プール スレッドを使用する代わりに、独自のスレッドを作成して管理することが適切なシナリオがいくつかあります。
- フォアグラウンド スレッドが必要です。
- 特定の優先度を持つスレッドが必要です。
- スレッドが長時間ブロックされる原因となるタスクがあります。スレッド プールには最大数のスレッドがあるため、多数のスレッド プール スレッドがブロックされると、タスクの開始が妨げられる可能性があります。
- スレッドをシングルスレッド アパートメントに配置する必要があります。すべての ThreadPool スレッドはマルチスレッド アパートメントにあります。
- スレッドに関連付けられた安定した ID を持つか、スレッドをタスク専用にする必要があります。
スレッドプールのポイントは、スレッドを作成するコストを償却することです。スレッドは、スピンアップおよびティアダウンするのに安価ではありません。実行時間の短いタスクがある場合、スレッドの作成/破棄のコストは、実行時間全体のかなりの部分を占める可能性があります。スレッドプール内のスレッドの最大数は、.NET Frameworkのバージョンによって異なり、通常、プロセッサごとに数十から数百になります。スレッドの数は、利用可能な作業に応じてスケーリングされます。
スレッドが不足し、スレッドが使用可能になるまで待つ必要がありますか？それはあなたのワークロードに依存します。ThreadPool.GetMaxThreads（）を介して、使用可能なスレッドの最大数を取得できます。（問題の説明に基づいて）この数が十分に高い可能性があります。
http://msdn.microsoft.com/en-us/library/system.threading.threadpool.getmaxthreads.aspx
もう1つのオプションは、スキャンごとに新しいスレッドを作成するのではなく、スキャンスレッドの独自のプールを管理し、それらに作業を割り当てることです。個人的には、最初にスレッドプールを試し、必要であることが判明した場合にのみ独自のスレッドを管理します。さらに良いことに、私は.NETの非同期プログラミング手法を調べます。メソッドはスレッドプールで実行されますが、手動のスレッド管理よりもはるかに優れたプログラミングエクスペリエンスを提供します。
ユーザーが一度に複数のバーコードをスキャンすることは決してないので、スレッドプールのメモリコストはそれだけの価値がないかもしれません-私はバックグラウンドで待機している単一のスレッドに固執します。
ほとんどの場合、実行時間の短いスレッドの場合は、スレッドプールまたはプールからスレッドを描画するBackgroundWorkerを使用できます。
.net (および一般的な Windows) では、「このシナリオで新しいスレッドを作成する価値はありますか?」という質問は常に逆にする必要があります。
新しいスレッドの作成にはコストがかかり、何度も何度も作成する価値はほとんどありません。スレッド プールは安価であり、新しいスレッドが必要になったときに最初に参照する必要があります。
新しいスレッドをスピンアップすることに決めた場合、すぐにスレッドが既に実行されている場合にそのスレッドを再利用することについて心配し始めるでしょう。次に、スレッドが実行されているのに時間がかかりすぎているように見えることがあるので、新しいスレッドを作成する必要があるのではないかと心配し始めます。次に、作業が終了してもすぐにスレッドを終了させず、新しい作業が入ってきた場合に備えてしばらく待機することにします。独自のスレッド プールを作成しました。その時点で、システム提供のものをバックアップして使用する必要があります。
スレッドプールが「スレッドを使い果たす」可能性があると述べた人々は善意でしたが、あなたに不利益をもたらしました。スレッド プール内のスレッド数の制限は非常に大きいです。それに出くわすと、他の問題が発生します。
(もちろん、.net 2.0 以降では、スレッドの最大数を設定できるため、どうしても必要な場合は数を微調整できます。)
他のユーザーは、MSDN の「The Managed Thread Pool」に誘導しました。記事は良いので、その方向を繰り返しますが、私の考えでは、スレッドプールを十分に販売していません。:)
あなたのケースで私が見ることができる利点は、スレッドプールクラスがアクティブなスレッドの量に上限を設定することです。システム リソースを使い果たすかどうかは、アプリケーションのコンテキストによって異なります。最新のデスクトップ システムを使い果たすことは、実際には非常に困難です。
ソフトウェアがスーパーマーケットで使用されるまで、5 つ以上のバーコードが同時に分析される可能性はほとんどありません。スーパーマーケットのレジの列全体のバックエンドサーバーで実行されている場合。その場合、おそらく 30 ～ 100 の同時要求がアクティブになる可能性があります。
この種の理論作成では、組み込みハードウェアであっても、スレッドが不足する可能性はほとんどありません。一度に 12 ほどのリクエストがアクティブで、コードが機能する場合は、そのままにしておいてかまいません。
ただし、スレッドプールは単なる抽象化であり、リクエストをスレッドプールにキューイングするキューを真ん中に置くことができます。上記の行の例のこのシナリオでは、100-1000 のリクエストを10 スレッドのスレッドプール。