Beginners Guide To Threading In .NET Part 4 of n

• Download demo project - 65 Kb

Introduction

I'm afraid to say that I am just one of those people, that unless I am doing something, I am bored. So now that I finally feel I have learnt tha basics of WPF, it is time to turn my attention to other matters.

I have a long list of things that demand my attention such as (WCF/WF/CLR Via C# version 2 book), but I recently went for a new job (and got, but turned it down in the end) which required me to know a lot about threading. Whilst I consider myself to be pretty good with threading, I thought yeah I'm ok at threading, but I could always be better. So as a result of that I have decided to dedicate myself to writing a series of articles on threading in .NET.

This series will undoubtely owe much to an excellent Visual Basic .NET Threading Handbook that I bought that is nicely filling the MSDN gaps for me and now you.

I suspect this topic will range from simple to medium to advanced, and it will cover a lot of stuff that will be in MSDN, but I hope to give it my own spin also. So please forgive me if it does come across a bit MSDN like.

I dont know the exact schedule, but it may end up being something like

• Introduction into threading in .NET
• Lifecycle Of Threads/Threading Opportunities/Traps
• Synchronization (last article)
• Thread Pools (this article)
• Threading in UIs (Winforms / WPF / Silverlight)
• The Future Of Threading (Task Parallel Library)

I guess the best way is to just crack on. One note though before we start, I will be using C# and Visual Studio 2008.

What I'm going to attempt to cover in this article will be

• The Need For Thread Pooling
• Thread Pooling Concept
• Thread Pooling Glitches
• Exploring The ThreadPool
• Demo Code
• Further Reading

This article will be all about how to control the synchronization of different threads.

The Need For Thread Pooling

There is a real need for thread pooling, if we remember the previous articles we discovered there was certainly an overhead incurred by having a new thread. This is something that the ThreadPool addresses. Here are some reasons why thread pooling is essential

• Thread pooling improves the responsive time of an application. As threads are actually available within a pool of threads and as such dont need to be created.

• Thread pooling saves the overhead of creating a new thread and claiming back its resources when the thread is finished

• Thread pooling optimizes the current time slices, according to the current process running

• Thread pooling allows us to create several tasks without having to assign a priority for each task (though this could be something we want to do, more on this later)

• Thread pooling enables us to pass state information as an object to the procedure arguments for the task that is being executed

• Thread pooling can be used to fix a maximum number of threads within the client application.

Thread Pooling Concept

One of the major problems affecting the responsiveness of multi-threaded applications, is the time spent spawning threads for new tasks.

For example imagine a web server is a multi threaded application that can service several client requests simultaneously. For arguments saek lets assume that 10 clients are accessing the web server at the same time:

If the server operates a thread per client polciy, it will create 10 new threads to service the 10 clients. There is the overhead of firstly creating the threads and then managing the threads and their associated resources through their entire lifecycle. It is also a consideration that the machine may actually run out of resources at some point.

As an alternative, if the web server used a pool of threads to satisfy client requests, then it would save the time involved with spawning a new thread each time a client request is seen.

This is the exact pricinple behind thread pooling.

The Windows OS, maintains a pool of threads for servicing requests. if our application requests a new thread, Windows will try and fetch it from the pool. If the pool is empty, it will spawn a new thread and give it to us. Windows will dynamically manipulate the thread pool size to increase the response time for our application.

Once a thread completes its assigned task, it returns to the pool and waits for the next assignment.

The Size Of The Thread Pool

The .NET framework provides the ThreadPool class located in the System.Threading namespace for using thread pools in our applications. if at any time, one of the threads in the pool is idle, then the thread pool will induce worker keep all processors busy. If all threads in the pool are busy and work is pending, the the ThreadPool will spawn new threads to complete the pending work. However the number of threads created can not exceed the maximum number specified. You can alter the size of the pool using the ThreadPool.SetMaxThreads() and ThreadPool.SetMinThreads() methods

In case of additional thread requirement, the requests are queued until some thread finishes its assigned task and returns to the pool.

Thread Pooling Glitches

There is no doubt that the ThreadPool is a useful class that will certainly be useful when developing multi threaded applications. There are however some things that should be consuidered before using a ThreadPool, these are as follows:

• The CLR assigns the threads from the ThreadPool to the tasks and realeases them back to the ThreadPool when the task is completed. There is no way to cancel a task once is starts.
• Thread pooling is effective for short lived tasks. A ThreadPool shouldnt really be used for long living tasks, as you would effectively be tying up one of the available ThreadPool threads for a long time, which is one of the reasons that makes the ThreadPool so appealing in the first place.
• All the threads in the ThreadPool are muli threaded apartments. If we want to place our threads in a single threaded apartment, ThreadPools are not the way to go.
• If we need to identify the thread and peform tasks such as start/suspend/abort it, then ThreadPool is not the way to do this.
• There can only be 1 ThreadPool associated with a given process.
• If a task within the ThreadPool becomes locked, then the thread is never realeased back to the ThreadPool.

Exploring The ThreadPool

The main methods of the ThreadPool class are listed below.

Name	Description
BindHandle	Overloaded. Binds an operating system handle to the ThreadPool
GetAvailableThreads	Retrieves the difference between the maximum number of thread pool threads returned by the GetMaxThreads method, and the number currently active
GetMaxThreads	Retrieves the number of requests to the thread pool that can be active concurrently. All requests above that number remain queued until thread pool threads become available
GetMinThreads	Retrieves the number of idle threads the thread pool maintains in anticipation of new requests
QueueUserWorkItem	Overloaded. Queues a method for execution. The method executes when a thread pool thread becomes available
RegisterWaitForSingleObject	Overloaded. Registers a delegate that is waiting for a WaitHandle
SetMaxThreads	Sets the number of requests to the thread pool that can be active concurrently. All requests above that number remain queued until thread pool threads become available
SetMinThreads	Sets the number of idle threads the thread pool maintains in anticipation of new requests
UnsafeQueueNativeOverlapped	Queues an overlapped I/O operation for execution
UnsafeQueueUserWorkItem	Registers a delegate to wait for a WaitHandle
UnsafeRegisterWaitForSingleObject	Overloaded. Queues the specified delegate to the thread pool

From MSDN

By far the most common methods that I think you will see used are the following methods:

• QueueUserWorkItem
• RegisterWaitForSingleObject
  

So the demo code will focus on these 2 methods

Demo Code

Like I say the 2 most common methods of the ThreadPool are

• QueueUserWorkItem
• RegisterWaitForSingleObject

So lets consider these in turn.

QueueUserWorkItem(WaitCallback)

Queues a method for execution. The method executes when a thread pool thread becomes available.

Is an overloaded method that allows you to create a new ThreadPool task, either using a state object or without a state object.

This first example puts a new task on the ThreadPool, but doesnt use any state object.

using System;
using System.Threading;

namespace QueueUserWorkItemNoState
{
    /// <summary>
    /// Queues a method for execution. 
    /// The method executes when a thread pool thread becomes available
    /// 
    /// This example was taken directly from MSDN
    /// </summary>
    class Program
    {
        static void Main(string[] args)
        {

            // Queue the task.
            ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadProc));

            Console.WriteLine("Main thread does some work, then sleeps.");
            // If you comment out the Sleep, the main thread exits before
            // the thread pool task runs.  The thread pool uses background
            // threads, which do not keep the application running.  (This
            // is a simple example of a race condition.)
            Thread.Sleep(1000);

            Console.WriteLine("Main thread exits.");
            Console.ReadLine();

        }

        // This thread procedure performs the task.
        static void ThreadProc(Object stateInfo)
        {
            // No state object was passed to QueueUserWorkItem, so 
            // stateInfo is null.
            Console.WriteLine("Hello from the thread pool.");
        }

    }
}

Which is about as simple as it gets. This results in the following:

The 2nd overload of the QueueUserWorkItem allows us to pass state to the task. Lets see that now shall we

QueueUserWorkItem(WaitCallback, Object)

Queues a method for execution, and specifies an object containing data to be used by the method. The method executes when a thread pool thread becomes available.

This example uses a simple ReportData state object to pass to the ThreadPool worker item (task)

using System;
using System.Threading;

namespace QueueUserWorkItemWithState
{


    // ReportData holds state information for a task that will be
    // executed by a ThreadPool thread.
    public class ReportData
    {
        public int reportID;

        public ReportData(int reportID)
        {
            this.reportID = reportID;
        }
    }


    /// <summary>
    /// Queues a method for execution with a ReportData state object
    /// </summary>
    class Program
    {
        static void Main(string[] args)
        {

            // Queue the task with a state object
            ReportData rd = new ReportData(15);
            ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadProc), rd);

            Console.WriteLine("Main thread does some work, then sleeps.");
            // If you comment out the Sleep, the main thread exits before
            // the thread pool task runs.  The thread pool uses background
            // threads, which do not keep the application running.  (This
            // is a simple example of a race condition.)
            Thread.Sleep(1000);

            Console.WriteLine("Main thread exits.");
            Console.ReadLine();

        }

        // This thread procedure performs the task.
        static void ThreadProc(Object stateInfo)
        {
            //get the state object
            ReportData rd = (ReportData)stateInfo;
            Console.WriteLine(string.Format("report {0} is running", rd.reportID));
        }

    }
}

Which results in the following:

So this demonstrated how to create simple tasks that can be managed by the ThreadPool. But as we know from Part3 of this series, we sometimes need to synchronize threads to make sure that they are well behaved and run in the correct order. This was fairly easy to do with threads that we manually created, we could use WaitHandles to ensure that our threads were run as expected. But how does all this work when working with the ThreadPool.

Well luckily the ThreadPool, also has another method (the ThreadPool.RegisterWaitForSingleObject()) that allows us to provide a WaitHandle, such that we can esnure the ThreadPool worker items (tasks) are well behaved and run in a certain order.

The RegisterWaitForSingleObject method has the following overloads.

Method	Description
RegisterWaitForSingleObject(WaitHandle, WaitOrTimerCallback, Object, Int32, Boolean)	Registers a delegate to wait for a WaitHandle, specifying a 32-bit signed integer for the time-out in milliseconds.
RegisterWaitForSingleObject(WaitHandle, WaitOrTimerCallback, Object, Int64, Boolean)	Registers a delegate to wait for a WaitHandle, specifying a 64-bit signed integer for the time-out in milliseconds.
RegisterWaitForSingleObject(WaitHandle, WaitOrTimerCallback, Object, TimeSpan, Boolean)	Registers a delegate to wait for a WaitHandle, specifying a TimeSpan value for the time-out.
RegisterWaitForSingleObject(WaitHandle, WaitOrTimerCallback, Object, UInt32, Boolean)	Registers a delegate to wait for a WaitHandle, specifying a 32-bit unsigned integer for the time-out in milliseconds.

I shall not be looking at all of these, but shall look at the one of them just to outline the principle. The reader is encouraged to read around the rest of these overloads and also the other ThreadPool methods.

The attached demo project covers usage of the following overload.

RegisterWaitForSingleObject(WaitHandle, WaitOrTimerCallback, Object, Int32, Boolean)

For this example I will create 2 tasks within a ThreadPool, one of which will be a simple task with a state object, which is enqueued using the ThreadPool.QueueUserWorkItem() which we saw earlier, and the 2nd will be the RegisterWaitForSingleObject(WaitHandle, WaitOrTimerCallback, Object, Int32, Boolean) where it will be enqueued to the ThreadPool, but will not be able to execute until a WaitHandle on which it is waiting is signalled.

using System;
using System.Threading;

namespace RegisterWaitForSingleObject
{


    // ThreadIdentity holds state information for a task that will be
    // executed by a ThreadPool thread.
    public class ThreadIdentity
    {
        public string threadName;

        public ThreadIdentity(string threadName)
        {
            this.threadName = threadName;
        }
    }


    /// <summary>
    /// Queues both a normal task using the ThreadPool.QueueUserWorkItem
    /// and a task for execution but waits for a signal from a WaitHandle
    /// before proceeding to execute
    /// 
    /// The later is done using the ThreadPool.RegisterWaitForSingleObject
    /// ThreadPool method
    /// </summary>
    class Program
    {

        static AutoResetEvent ar = new AutoResetEvent(false);

        static void Main(string[] args)
        {


            
            //Registers a task that will wait for a WaitHandle and will wait forever (-1 means
            //never expire) and has a state object, and should execute only once
            ThreadIdentity ident1 = new ThreadIdentity("RegisterWaitForSingleObject");
            ThreadPool.RegisterWaitForSingleObject(ar, new WaitOrTimerCallback(ThreadProc), 
                ident1, -1, true);

            // Queue the task as normal with a state object
            ThreadIdentity ident2 = new ThreadIdentity("QueueUserWorkItem");
            ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadProc), ident2);

            Console.WriteLine("Main thread does some work, then sleeps.");
            // If you comment out the Sleep, the main thread exits before
            // the thread pool task runs.  The thread pool uses background
            // threads, which do not keep the application running.  (This
            // is a simple example of a race condition.)
            Thread.Sleep(5000);

            Console.WriteLine("Main thread exits." + DateTime.Now.ToLongTimeString());
            Console.ReadLine();

        }

        // This thread procedure performs the task specified by the 
        // ThreadPool.QueueUserWorkItem
        static void ThreadProc(Object stateInfo)
        {
            ThreadIdentity ident1 = (ThreadIdentity)stateInfo;
            Console.WriteLine(string.Format("Hello from thread {0} at time {1}",
                ident1.threadName,DateTime.Now.ToLongTimeString()));

            Thread.Sleep(2000);
            //set the AutoResetEvent to allow the waiting ThreadPool task
            //which we added using the RegisterWaitForSingleObject to proceed
            ar.Set();
        }


        // This thread procedure performs the task specified by the 
        // ThreadPool.RegisterWaitForSingleObject
        static void ThreadProc(Object stateInfo, bool timedOut)
        {
            ThreadIdentity ident1 = (ThreadIdentity)stateInfo;
            Console.WriteLine(string.Format("Hello from thread {0} at time {1}",
                ident1.threadName, DateTime.Now.ToLongTimeString()));
        }

    }
}

Which results in the following, where is can be seen that although the 1st work item (task) that was enqueud was the one done by using the RegisterWaitForSingleObject() method. As it was started with a WaitHandle being passed into the ThreadPool method, it is not able to start until such a time that the WaitHandle is signalled, which is only done when the other work item enqueued using the QueueUserWorkItem() method, completes.

Using this code it should be pretty easy to see how the rest of the overloads for the RegisterWaitForSingleObject() methods actually work.

Further Reading

There is an excellent article right here at codeproject which is "The Smart Thread Pool" project, by Ami Bar, which has thye following features

* The number of threads dynamically changes according to the workload on the threads in the pool.
* Work items can return a value.
* A work item can be cancelled if it hasn't been executed yet.
* The caller thread's context is used when the work item is executed (limited).
* Usage of minimum number of Win32 event handles, so the handle count of the application won't explode.
* The caller can wait for multiple or all the work items to complete.
* Work item can have a PostExecute callback, which is called as soon the work item is completed.
* The state object, that accompanies the work item, can be disposed automatically.
* Work item exceptions are sent back to the caller.
* Work items have priority.
* Work items group.
* The caller can suspend the start of a thread pool and work items group.
* Threads have priority.

Its really good actually.

The "The Smart Thread Pool" project by Ami Bar, can be found at this Url : Smart Thread Pool

We're Done

Well that's all I wanted to say this time. I just wanted to say, I am FULLY aware that this article borrows a lot of material from various sources, I do however feel that it could alert a potential threading newbie, to classes/objects that they simply did not know to look up. For that reason I still maintain there should be something useful in this article. Well that was the idea anyway. I just hope you agree, if so tell me, and leave a vote.

Next Time

Next time we will be looking at Threading in UIs.

Could I just ask, if you liked this article could you please vote for it. I thank you very much

Bibilography

1. Threading in C#, Joseph Albahari
2. System.Threading MSDN page
3. Threading Objects and Features MSDN page
4. Visual Basic .NET Threading, Wrox

You must Sign In to use this message board.

FAQ    Noise Tolerance Very HighHighMediumLowVery Low   Layout Expand Posts & RepliesThread ViewNo JavascriptNo JS + Preview   Per page 102550

Msgs 1 to 23 of 23 (Total in Forum: 23) (Refresh) FirstPrevNext

Nice! woelig 10:47 25 Sep '08   A very nice article! Helped me a lot! Sign In·View Thread·PermaLink Addendum goldfinger 20:28 25 Aug '08   Great article! I used the ThreadPool class in my last project and run into two problems: First there is a bug in Net 2.0 SP1 (not NET 2.0 RTM) because only two concurrent threads are running at startup. The ThreadPool.SetMinThreads statement has no effect. http://www.michaelckennedy.net/blog/2008/03/03/FollowUpOnNET20SP1ThreadPoolBug.aspx[^] ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadProc), myObject); // ThreadPool Bug only occurs with NET 2.0 Sp1 // Only two concurrent threads at startup // ThreadPool.SetMinThreads don't work // Fixed NET 2.0 Sp2 (2.0.50727.3053) Thread.Sleep(1); // Fix from MS for NET 2.0 SP1 Second the number of wait handles are hardcoded to 64 in Net 2.0. If you need more wait handles you have to break it into chunks of 64. WaitHandle.WaitAll method is limited to 64 threads: System.NotSupportedException: The number of WaitHandles must be less than or equal to 64. at System.Threading.WaitHandle.WaitAll(WaitHandle[] Sign In·View Thread·PermaLink Re: Addendum Sacha Barber 22:51 25 Aug '08   ah cool thanks for this extra info. Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Re: Addendum manfbraun 10:31 28 Jul '09   Hi All ! Thanks first:A really good one!!! BTW:I am working on an app which needs a higher number of synchronization object [minimum > 64]. Are there any way to circumvent the default net's limit?????? Any help would be great!!! br--mabra Ciao, mb Sign In·View Thread·PermaLink Re: Addendum Sacha Barber 10:37 28 Jul '09   Been a while, but I think the ThreadPool has MaxThreads limit which you can change. Sacha Barber Microsoft Visual C# MVP 2008/2009 Codeproject MVP 2008/2009 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Re: Addendum manfbraun 7:14 29 Jul '09   Thanks Sacha! But I think you confuse the number of threads with the number of synchronization objects?!! Or:Will the number of sync objects also increase, if I increase the nr. of threads?? Thanks--mabra Sign In·View Thread·PermaLink Re: Addendum Sacha Barber 23:02 29 Jul '09   Yeah you are right sorry. Sacha Barber Microsoft Visual C# MVP 2008/2009 Codeproject MVP 2008/2009 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Take a look at my articles & library when you get a chance P.Adityanand 8:29 17 Aug '08   Hi Sacha, I like your articles. I created an article series and a .NET library way back (3 years back) on .NET Threading, ThreadPools & asynchronous programming. Below are the links. Take a look when you get a chance. BTW, Microsoft's Task Parallel Library is VERY MUCH similar to my library and approach towards threading and task based asynchronous programming. 1. http://www.codeproject.com/KB/cs/AsynchronousCodeBlocks.aspx[^] 2. http://www.codeproject.com/KB/cs/managediocp-part-2.aspx[^] 3. http://www.codeproject.com/KB/cs/managediocp.aspx[^] Regards, Aditya.P Sign In·View Thread·PermaLink Re: Take a look at my articles & library when you get a chance Sacha Barber 22:37 18 Aug '08   Yep I saw them when you did them, and they were excellent I thought. I was aware of them, but its good to have them in this forum to. Thanks for that Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Great Series, 1 question though Keith Vinson 9:23 12 Aug '08   Sorry, but I haven't had the time to read every word. But while skimming the series I was wondering about something I had seen back in the day, and I bet you know... If a thread pool thread is terminated for bad behavior, can you starve the thread pool of threads aka kill them all off leaving the TP without any threads, or was it fixed? Cheers, Keith Sign In·View Thread·PermaLink Re: Great Series, 1 question though Sacha Barber 1:22 13 Aug '08   AFAIK there is no way to abort a started thread pool thread, as its not in your control. Using the better thread pool that I mention in this article you might be able to. But you will have to try that Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Nice Article As Always! final_zero 7:20 9 Aug '08   Man This series ROCKS! I am looking forward for the next parts. Best Regards. Aamer A. Alduais ( final_zero ) Sign In·View Thread·PermaLink Re: Nice Article As Always! Sacha Barber 22:13 9 Aug '08   Thanks man....should have part5 up today also Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Re: Nice Article As Always! Sacha Barber 1:17 10 Aug '08   Here is part5, as promised http://www.codeproject.com/KB/threads/ThreadingDotNet5.aspx Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Re: Nice Article As Always! final_zero 0:30 17 Aug '08   Thank you man this series is so helpful, 5 stars goes for part 5 too. ^_^ Aamer A. Alduais final_zero Sign In·View Thread·PermaLink Re: Nice Article As Always! Sacha Barber 22:35 18 Aug '08   Thanks man Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Is there some magic numbers to use as min and max number of threads in the ThreadPool? hamel98 6:42 7 Aug '08   What should be considered when deciding what those values should be? Should I use the ThreadPool with the defaults values? Thanks for you help! Really nice series by the way! hamel98 Sign In·View Thread·PermaLink Re: Is there some magic numbers to use as min and max number of threads in the ThreadPool? Sacha Barber 9:45 7 Aug '08   it really all depeneds on your needs. Sorry to be vague, but it does depend on what you need Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Excellent Articles merlin981 5:25 21 Jul '08   Yet another great article on threading. Keep up the great work ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LINQ Exchange - Learn about LINQ and Lambda Expressions Rhabot - World of Warcraft Bot Make long URLs short with NeatURL.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: Excellent Articles Sacha Barber 6:03 21 Jul '08   Thanks man Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net Sign In·View Thread·PermaLink Threadpool and multiple application N a v a n e e t h 8:49 20 Jul '08   Sacha, Thanks for the article. Assume I am running multiple .NET applications which uses thread pool on the same system. So will there be independent pools for each application, or only one pool will be available and all these applications will share it. Thanks All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions Sign In·View Thread·PermaLink Re: Threadpool and multiple application [modified] Sacha Barber 8:59 20 Jul '08   1 ThreadPool per application (assuming they are in seperate process (AppDomain really) per app) Glad you like it man. Sacha Barber Microsoft Visual C# MVP 2008 Codeproject MVP 2008 Your best friend is you. I'm my best friend too. We share the same views, and hardly ever argue My Blog : sachabarber.net modified on Monday, July 21, 2008 3:45 AM Sign In·View Thread·PermaLink Re: Threadpool and multiple application N a v a n e e t h 17:20 20 Jul '08   Thanks sacha. It's a wonderful article, no second thoughts. All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions Sign In·View Thread·PermaLink

Last Visit: 20:47 7 Nov '09     Last Update: 20:47 7 Nov '09 1