自分のスレッドを作成するのではなく、スレッドプールを使用することを選択することについてはまだ少し混乱しています。
独自のスレッドを作成する(作成、作成するスレッドごとにガベージコレクターを実行する)パフォーマンスの問題を認識しているので、これを起動する必要はありません。
重要なのは、スレッドプールを使用して作成されたスレッドの数を抽象化する場合(スレッド制限は定義しません)、CLRはどのようにして十分な数を知るのでしょうか?
自分のスレッドを作成するのではなく、スレッドプールを使用することを選択することについてはまだ少し混乱しています。
独自のスレッドを作成する(作成、作成するスレッドごとにガベージコレクターを実行する)パフォーマンスの問題を認識しているので、これを起動する必要はありません。
重要なのは、スレッドプールを使用して作成されたスレッドの数を抽象化する場合(スレッド制限は定義しません)、CLRはどのようにして十分な数を知るのでしょうか?
ランタイムには、実行されるワーカースレッドの数が事前定義されています。デフォルトは10だと思います。プールに空いているスレッドができるまで、実行する作業の要求をキューに入れます。これはマルチスレッド用の非常に簡単でかなり安全なモデルですが、いくつかの同時実行モデルを利用して醜さを抽象化できるため、「async/await」を調べることをお勧めします。
.NET ランタイムは、コア数やその他の要因に基づいて適切な最大スレッド数を自動的に選択しますが、特別なニーズがある場合は、この数を自分で設定できます。
http://msdn.microsoft.com/en-us/library/system.threading.threadpool.aspx
システムがリソースを使い果たした場合、スレッドプールはクラッシュしません。スレッドプールは、次のスレッドがリクエストを実行できるようになるまで待機します (それが何であれ)。
ただし、使用可能な最大スレッドを使い果たす可能性があるコードに注意してください。99.5% は、不適切に記述されているか、正しくありません。
をご覧くださいQueueUserWorkItem
。ここでのキーワードは「キュー」です。
実行するメソッドをキューに入れます。このメソッドは、スレッド プールのスレッドが使用可能になると実行されます。
ThreadPool は、タスクの実行、作業項目の投稿、非同期 I/O の処理、他のスレッドの代わりの待機、およびタイマーの処理に使用できるスレッドのプールを提供します。
http://msdn.microsoft.com/en-us/library/system.threading.threadpool.queueuserworkitem.aspx
すなわち:ThreadPool.QueueUserWorkItem((i)=> Console.WriteLine("Hello"));