Multi-threading in .NET
In .NET 2.0+, if you want to have something run on another thread, you have a number of choices:
-
The classical System.Threading.Thread class
-
The not-so-known System.Threading.ThreadPool
-
The System.ComponentModel.BackgroundWorker
-
Delegates invoked asynchronously
Let's see how we would do it in each case, and what would be the benefits. Let's suppose our thread method looks like this:
private void ThreadMethod(Object state){
}
Using System.Threading.Thread
You start a new System.Threading.Thread instance and pass it a pointer to the thread method wrapped in a System.Threading.ParameterizedThreadStart (for an optional state parameter) or System.Threading.ThreadStart delegate, then, you start it, by calling Start:
Thread thread = new Thread(state => ThreadMethod(state)); thread.Start(state);As you can see, I am using the new .NET 3.5 lambda syntax for delegates.
If you want to wait for the thread to exit, do this:
thread.Join(timeout);
Using System.Threading.ThreadPool
Assuming your thread pool is properly configured (maximum number of threads, minimum number of threads before creating another one, etc), all you have to do is enqueue a method for execution, whenever a thread from the pool is free:
Boolean
result = ThreadPool.QueueUserWorkItem(ThreadMethod, state);Or, if you must wait for the result:
ManualResetEvent handle = new ManualResetEvent(false);
ThreadPool.RegisterWaitForSingleObject(handle, (s, timedout) => ThreadMethod(s), state, timeout, true);handle.WaitOne();
By the way, QueueUserWorkItem always returns true, otherwise an exception is thrown.
Using System.ComponentModel.BackgroundWorker
You create an instance of the System.ComponentModel.BackgroundWorker class, add an event handler to its DoWork event, and start the processing by calling RunWorkerAsync, with an optional state parameter:
BackgroundWorker worker = new BackgroundWorker();worker.DoWork += delegate(Object sender, DoWorkEventArgs args) { ThreadMethod(args.Argument); };worker.RunWorkerAsync(state);
Waiting for the worker to complete is accomplished this way:
ManualResetEvent
handle = new ManualResetEvent(false);ThreadPool.RegisterWaitForSingleObject(handle, (s, timedout) => ThreadMethod(s), state, timeout, true);handle.WaitOne();
The System.ComponentModel.BackgroundWorker class is available from the Windows Forms toolbox, in design view, so you can drag it into your form, and change its properties or register events through the property inspector.
Using Delegates
You declare a delegate that points to your method and you start its BeginInvoke method, passing it the state parameter and optionally a callback method, that gets called when the method terminates, and a state argument for that callback: Action<Object> action = ThreadMethod;action.BeginInvoke(state,
null, null);And waiting:
Action<Object> action = ThreadMethod;IAsyncResult result = action.BeginInvoke(state, null, null);result.AsyncWaitHandle.WaitOne(timeout);
So, what is the difference between all these methods? Let's see:
-
You would use System.Threading.Thread class when you want your task to be run exactly now; you may also want to suspend it or kill it;
-
System.Threading.ThreadPool helps preserving resources: no new threads are created, we just grab another one from the pool, if it is available, or wait for it, so the job may not start immediately; you don't have control over the actual thread that does the job;
-
If you want to have feedback from a thread, you use System.ComponentModel.BackgroundWorker. Its events allows you to set the completion status and to be notified when the task finishes. Typically you use it in a Windows Forms application. As it uses internally the thread pool, jobs may not start immediately;
-
Delegates are a fast way of launching a thread from a method delegate; it also uses the thread pool, so a task may take some time to actually start.
In all cases, starting from .NET 2.0, the spawned threads retain the same principal (System.Threading.Thread.CurrentPrincipal property), which is great for access control.
