Coding Lifestyle

Understanding BackgroundWorker and Encapsulating your own Thread Class February 22, 2011

You may have come across this page if you were searching for any of the following:

• BackgroundWorker events not firing
• BackgroundWorker RunWorkerCompleted event not firing
• BackgroundWorker threads frozen
• Encapsulate thread class

Yesterday my web page was launching several worker threads and waiting for them to return to amalgamate the results in to a single data set to bind to a grid. Launching several worker threads and waiting for a join is a common pattern. To nicely encapsulate the thread itself I derived a class from BackgroundWorker. BackgroundWorker has many advantages such as using an event model, thread pool, and all the thread plumbing built right in. All you have to do is override OnDoWork and off you go. The RunWorkerCompleted event was used, in conjunction with a lock, to collect the data once the worker thread finished.

Everything looked good but for some reason the event never fired. The problem was that I had gotten myself in to a deadlock scenario. The expectation is that when the event fires the delegate method will run in the context of the thread which fired it. If this were true, this would have allowed my synchronization logic to operate normally and not deadlock. The reality is that BackgroundWorker goes out of its way to run this event in the calling thread’s identity. It did this so when using BackgroundWorker in conjunction with the UI no invoke will be required (an exception will be thrown if a thread tries to touch the UI’s controls requiring you to check InvokeRequired).

When in doubt, use something like this to check the identity of the thread executing the code:

Trace.WriteLine(string.Format(“Thread id {0}”, System.Threading.Thread.CurrentThread.ManagedThreadId));

Once putting the above trace in the code I would clearly see that the identity of my main thread was identical to the thread identity in the RunWorkerCompleted event. Once the code tried to aquire the lock it was all over.

So the solution in my case was not to use the RunWorkerCompleted event. I added an alternative event to my thread class and called that at the end of OnDoWork. The event executed in the context of the thread, as expected, and my synchronization logic worked fine. But I couldn’t help feeling it was a bit of a kludge and pondered whether I should be deriving from BackgroundWorker at all. However, what’s the alternative? There really aren’t other alternatives to BackgroundWorker built in to the framework but it is easy to create your own.  See below:

 /// <summary>
 /// Abstract base class which performs some work and stores it in a data property
 /// </summary>
 /// <typeparam name="T">The type of data this thread will procure</typeparam>
 public abstract class ThreadBase<T>
 {
 #region Public methods
 /// <summary>
 /// Does the work asynchronously and fires the OnComplete event
 /// </summary>
 public void DoWorkAsync()
 {
     DoWorkAsync(null);
 }

 /// <summary>
 /// Does the work asynchronously and fires the OnComplete event
 /// </summary>
 /// <param name="arguement">The arguement object</param>
 public void DoWorkAsync(object arguement)
 {
 ThreadPool.QueueUserWorkItem(DoWorkHelper, arguement);
 }

 /// <summary>
 /// Does the work and populates the Data property
 /// </summary>
 public void DoWork()
 {
 DoWork(null);
 }

 /// <summary>
 /// Does the work and populates the Data property
 /// </summary>
 /// <param name="arguement">The arguement object</param>
 /// <remarks>
 /// Can be called to run syncronously, which doesn't fire the OnComplete event
 /// </remarks>
 public abstract void DoWork(object arguement);
 #endregion

#region Private methods
 private void DoWorkHelper(object arguement)
 {
 DoWork(arguement);
 if (OnComplete != null)
     OnComplete.Invoke(this, Data);
 }
 #endregion

#region Properties
 public T Data { get; protected set; }
 #endregion

#region Events

 /// <summary>
 /// Delegate which is invoked when the thread has completed
 /// </summary>
 /// <param name="thread">The thread.</param>
 /// <param name="data">The data.</param>
 public delegate void ThreadComplete(ThreadBase<T> thread, T data);

 /// <summary>
 /// Occurs when the thread completes.
 /// </summary>
 /// <remarks>This event operates in the context of the thread</remarks>
 public event ThreadComplete OnComplete;
 #endregion
 }

My generic ThreadBase class is a lightweight baseclass substitute for BackgroundWorker providing the flexibility to call it synchronously or asynchronously, a generically typed Data property, and an OnComplete event. The OnComplete will execute in the thread’s context so synchronization of several threads won’t be a problem. Take a look at it in action:

 public class MyThread : ThreadBase<DateTime>
 {
 public override void DoWork(object arguement)
 {
 Trace.WriteLine(string.Format("MyThread thread id {0}", System.Threading.Thread.CurrentThread.ManagedThreadId));

Data = DateTime.Now;
 }
 }

What a nicely encapsulated thread! Below we can see how cleanly a MyThread can be used:

 MyThread thread = new MyThread();
 thread.OnComplete += new ThreadBase<DateTime>.ThreadComplete(thread_OnComplete);
 thread.DoWorkAsync();

 void thread_OnComplete(ThreadBase<DateTime> thread, DateTime data)
 {
 Trace.WriteLine(string.Format("Complete thread id {0}: {1}", Thread.CurrentThread.ManagedThreadId, data));
 }

Then I got to thinking what if I wanted the best of both worlds? Thanks to reflector I found out how BackgroundWorker’s RunWorkerCompleted event executes in the context of the calling thread. My generic ThreadBaseEx class offers two events: OnCompleteByThreadContext and OnCompleteByCallerContext.

 /// <summary>
 /// Abstract base class which performs some work and stores it in a data property
 /// </summary>
 /// <typeparam name="T">The type of data this thread will procure</typeparam>
 public abstract class ThreadBaseEx<T>
 {
 #region Private variables
 private AsyncOperation _asyncOperation;
 private readonly SendOrPostCallback _operationCompleted;
 #endregion

#region Ctor
 public ThreadBaseEx()
 {
 _operationCompleted = new SendOrPostCallback(AsyncOperationCompleted);
 }
 #endregion

#region Public methods
 /// <summary>
 /// Does the work asynchronously and fires the OnComplete event
 /// </summary>
 public void DoWorkAsync()
 {
 DoWorkAsync(null);
 }

 /// <summary>
 /// Does the work asynchronously and fires the OnComplete event
 /// </summary>
 /// <param name="arguement">The arguement object</param>
 public void DoWorkAsync(object arguement)
 {
 _asyncOperation = AsyncOperationManager.CreateOperation(null);
 ThreadPool.QueueUserWorkItem(DoWorkHelper, arguement);
 }

 /// <summary>
 /// Does the work and populates the Data property
 /// </summary>
 public void DoWork()
 {
 DoWork(null);
 }

 /// <summary>
 /// Does the work and populates the Data property
 /// </summary>
 /// <param name="arguement">The arguement object</param>
 /// <remarks>
 /// Can be called to run syncronously, which doesn't fire the OnComplete event
 /// </remarks>
 public abstract void DoWork(object arguement);
 #endregion

#region Private methods
 private void DoWorkHelper(object arguement)
 {
 DoWork(arguement);
 if (OnCompleteByThreadContext != null)
 OnCompleteByThreadContext.Invoke(this, Data);
 _asyncOperation.PostOperationCompleted(this._operationCompleted, arguement);
 }

private void AsyncOperationCompleted(object arg)
 {
 OnCompleteByCallerContext(this, Data);
 }
 #endregion

#region Properties
 public T Data { get; protected set; }
 #endregion

#region Events
 /// <summary>
 /// Delegate which is invoked when the thread has completed
 /// </summary>
 /// <param name="thread">The thread.</param>
 /// <param name="data">The data.</param>
 public delegate void ThreadComplete(ThreadBaseEx<T> thread, T data);

 /// <summary>
 /// Occurs when the thread completes.
 /// </summary>
 /// <remarks>This event operates in the context of the worker thread</remarks>
 public event ThreadComplete OnCompleteByThreadContext;

 /// <summary>
 /// Occurs when the thread completes.
 /// </summary>
 /// <remarks>This event operates in the context of the calling thread</remarks>
public event ThreadComplete OnCompleteByCallerContext;
 #endregion
 }

Your encapsulated thread will be the same as above, but now with two events allowing either scenario, depending on what suits.