Click here to Skip to main content
11,705,451 members (47,759 online)
Click here to Skip to main content

Understanding BackgroundWorker and Encapsulating your own Thread Class

, 30 Mar 2011 CPOL 5.9K 2
Rate this:
Please Sign up or sign in to vote.
Understanding BackgroundWorker threads and how to encapsulate your own thread class.

Introduction

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 into a single data set to bind to a grid. Launching several worker threads and waiting for them to return 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 I put the above trace in the code, I could clearly see that the identity of my main thread was identical to the thread identity in the RunWorkerCompleted event. Once the code tried to acquire 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:

/// <span class="code-SummaryComment"><summary>
</span>

My generic ThreadBase class is a lightweight base class 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.

/// <span class="code-SummaryComment"><summary>
</span>

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

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Chris_Green
Architect Avaya Inc.
Ireland Ireland
Formerly a C++ client developer, nowadays I'm all about C# and ASP.NET. Over the years I have mastered some and played with many aspects of .NET.

Follow my blog as I catalogue the more arcane problems I encounter and their solutions at CodingLifestyle.com

You may also be interested in...

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.150819.1 | Last Updated 30 Mar 2011
Article Copyright 2011 by Chris_Green
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid