Thread vs ThreadPool

Thread pool will provide benefits for frequent and relatively short operations by

• Reusing threads that have already been created instead of creating new ones (an expensive process)

• Throttling the rate of thread creation when there is a burst of requests for new work items (I believe this is only in .NET 3.5)

• If you queue 100 thread pool tasks, it will only use as many threads as have already been created to service these requests (say 10 for example). The thread pool will make frequent checks (I believe every 500ms in 3.5 SP1) and if there are queued tasks, it will make one new thread. If your tasks are quick, then the number of new threads will be small and reusing the 10 or so threads for the short tasks will be faster than creating 100 threads up front.

• If your workload consistently has large numbers of thread pool requests coming in, then the thread pool will tune itself to your workload by creating more threads in the pool by the above process so that there are a larger number of thread available to process requests

///////////////////

 

스레드풀은 스레드풀에 생성되어 있는 스레드를 재사용하기 때문에,

새로운 스레드 객체를 생성할 때 따르는 오버헤드를 대폭 줄일 수 있다.

 

일반적인 방식으로 스레드를 생성하게 되면

OS 레벨에서는 kernel 객체의 초기화, 그리고 쓰레드에서 사용되는 stack 메모리의 할당 및 초기화, Windows 운영 체제가 새로운 쓰레드가 생성 될 때 로드 된 assembly에게 DLL_THREAD_ATTACH라는 메시지를 보내기 위해 메모리에 로드 된 페이지의 손실 발생등의 비 효율적인 일들이 벌어집니다.

라고 한다.

 

그러한 비효율을 감소시키는 것이 스레드풀 사용의 목적이라 하겠다.

여기서 한가지 문제가 제기될 수 있다.

 

어플리케이션에서 처리하고자 하는 작업의 수가 시간이 경과하여 줄어든다면, 스레드풀에 있는 필요 이상의 스레드들은 어떻게 될것인가? 하는 문제이다.

하지만 이러한 경우, 스레드풀은 일정 시간동안 휴면상태에 있는 스레드를 반환한다고 한다.

 

즉, 사용상 어떠한 비효율을 일으킬만한 소지는 없어 보인다.

 

스레드풀에서 사용 가능한 스레드의 개수는 cpu spec에 따라 지정되어있고,

사용자가 임의 변경 가능하다.

 

다음과 같은 코드를 통하여,

 

/////

 

maxsync = 100;

 

System.Threading.ThreadPool.SetMaxThreads(maxsync, maxAsync);

 

System.Threading.ThreadPool.GetMaxThreads(out maxsync, out maxAsync);

 

Console.WriteLine("{0},  {1}", maxsync, maxAsync);

 

Console.Read();

 

/////

[출처] Thread vs ThreadPool|작성자 에스이오케이