Thread Pooling

I l @ ve RuBoard

Each thread you create imposes additional system overhead, so you face the inevitable tradeoff between execution efficiency and consumption of system resources. Think of the demands on a Web server. You have very predictable incoming network requests asking for files. You could create a thread to handle each incoming request to make the server perform more efficiently . This would work fine for the first 10 to 100 requests , but then your system would start to bog down because it would have to spend more and more time just switching between threads. Besides, it's not really necessary to create a thread for every incoming request. What you should do instead is create a pool of worker threads that you can reuse to execute incoming requests. You can then queue the incoming requests and dispatch those requests to a thread as soon as one is available. This approach offers a number of benefits:

• You keep new thread creation to a minimum.

• A queued item requires far fewer system resources than a waiting thread.

• You can tune the number of threads you want to create.

• You minimize the resources required by limiting the number of created threads.

You have two thread-pooling options. First, you can implement your own form of thread pooling. This requires you to implement all of the management and retirement functionality. If you need a highly specialized pooling mechanism, this is the way to go, but it's a rare case. Most developers should use the second option.

The second option is to take advantage of the ThreadPool class in the .NET Framework. This is usually the best option unless you have specific requirements that are not fulfilled by the implementation of the ThreadPool class. Otherwise, the ThreadPool class can handle all of the thread management for you.

Caution

You should use the ThreadPool class only if you have a large number of discrete tasks that need to be divided up. Do not use it for any persistent, or long running, operations or for threads where there is no expectation of their lifetime. If you need to create a thread that sticks around for monitoring or for serving requests, create your own thread. The ThreadPool class is best used when you have a large number of tasks than can be divided up and queued. Longer-running tasks should use more conventional thread management.

The ThreadPool Class

Using the ThreadPool class is fairly straightforward. The general idea is that you need to queue work items in the pool. A work item is an object that contains the information about the work that needs to be done and a method address that can satisfy that request. The method you provide to the ThreadPool must conform to the signature of a WaitCallback delegate, which looks like this:

 PublicDelegateSubWaitCallback(ByValstateAsObject) 

The state parameter is for passing information to the thread method that it needs to do its job. The following example shows a simple use of this feature by using an AutoResetEvent to synchronize the program's termination with the worker thread's completion:

 ImportsSystem.Threading ModuleModule1 SubMain() 'Weusethistosignalthethreadcompletion DimthreadDoneAsNewAutoResetEvent(False) 'Addthethreadmethodtothequeue ThreadPool.QueueUserWorkItem(AddressOfRun,threadDone) 'Waitforthethreadtocomplete threadDone.WaitOne() Console.WriteLine("Thethreadhascompleted") EndSub SubRun(ByValstateAsObject) Console.Write("Startingthethread...") DimevtAsAutoResetEvent=CType(state,AutoResetEvent) Thread.Sleep(1000) evt.Set() Console.WriteLine("done.") EndSub EndModule 

Ultimately, how you use the ThreadPool is up to you. It allows you to pass an object to your thread method, so you can pass it any data type you want, including your own custom classes. You can create a class that provides all of the information that your thread method needs to do its work. In the case of the Web server example, you can pass in the requested file path and the network port that the client is connected to.

I l @ ve RuBoard