C# Dev Connect 1: Intro to Threading

In my last post, I mentioned we’d be hosting a C# Dev Connect meetup at our Magnet Forensics HQ in Waterloo. I figured I’d post to talk about how the event went so that if you couldn’t make it, you’ll have an idea for next time (and if you did make it, maybe you can comment on how you thought the event went). Our first Dev Connect was lead by a colleague of mine, Chris Sippel, who wanted to give a talk on threading basics in C#. Threading can quickly become a really complex topic, so Chris wanted to keep it high level and talk about the different approaches you can use to start threading in your C# applications.

Dev Connect: Before the Talk

Before Chris gave his talk on threading, we had our attendees slowly streaming in. Sure, we had a lot of our Magnet development team show up to offer support for Chris, but I was still pleasantly surprised to see others from the area that I’ve never met before showing an interest in C#. Our colleague Amaris had done an awesome job coordinating the first event for us, and even got us stocked up with pizza and pop. For the first hour or so, we had our guests fed and introduced to each other. A great start to the evening!

Dev Connect: The Talk

After everyone was settled in, we had our attendees pull up some chairs at tables or post up in our comfy soft seating to listen to what Chris had to say. Chris walked us through various slides and coding examples and was able to show us working examples of code to back up what he was saying. I was really proud of Chris for taking the leap to be our first speaker, and I think he did a great job. His slides and sample code are available at the Dev Connect git hub if you’re interested in taking a peek.

Dev Connect: The Aftermath

Once Chris was done talking, we had a few attendees leave to carry on with the rest of their evening, but it was great to see the majority hang back for further discussion. Some people were trying out the threading exercises that Chris had put together, others had tried it beforehand and had questions on it, and a bunch of people were sticking around just to talk .NET. When I envisioned what Dev Connect might have looked like, this was it. It felt great to help facilitate a positive discussion around using the .NET framework and C#, especially because people were clearly benefiting from it.

If you came for our first meetup, then thanks! If you couldn’t make it or you’re interested in the next one, be sure to check out our meetup page. We’ll see you next time!

Background

There are two classes available in the .NET framework that sometimes have some confusion around them: The Thread and the BackgroundWorker. They’re both used to do some heavy lifting for you on a separate thread of execution (so you can keep on keepin’ on), so why do we have two different things to accomplish the same end result

Enter The Thread Class

The Thread class is available in the System.Threading namespace. Surprising, right? It’s the basic unit for spawning off work to be done. Threads let you provide them with a name, which could be one advantage to using them. A thread can either operate as “background” which means it will be killed when the application exists, or not as background, which will actually keep the application alive until the thread is killed off.

An instance of the Thread class is relatively lightweight. It’s quick to set up for developers and all you need to do is provide it a method to run. You can put a loop in your thread body to keep it alive and do all sorts of fun stuff. Threads are great for setting up queuing, dequeing, scheduling, monitoring, receiving, and listening logic. Well, there are really countless uses for them, but those are some of the big ones I find I do a lot of.

Enter The BackgroundWorker

The BackgroundWorker class is available in the System.ComponentModel namespace. This is slightly different from the Thread class already, and for what it’s worth, I generally only have this namespace around if I’m dealing with a UI. That is, if I’m in the equivalent to a data layer or application layer, I usually don’t have these guys around (usually, but not necessarily always). So is that it then? Just the namespace is different?

The BackgroundWorker class is essentially built on top of the Thread class. The Thread part of the BackgroundWorker is sort of hidden from you. You get to work with two very important parts of the BackgroundWorker though, the DoWork and RunWorkerCompleted events (There’s a progress one too, but because I actually don’t use this much I’ll omit it for you to take on as homework). So… What are these events all about?

The DoWork event is invoked on a separate thread. This is where you want to do your heavy lifting, and you can pass in any object you want when you start up the BackgroundWorker–Simply pull it off of the event args in your DoWork event handler and cast it back to the necessary type. Presto! The RunWorkerCompleted event is what’s triggered when your DoWork event handler finishes up… but the big difference here is that RunWorkerCompleted runs on the thread that started the BackgroundWorker. This is extremely important when you’re working with UIs. Why? Because of cross thread exceptions! UI stuff is generally only run on the UI thread and nothing else. It’s important to note that the DoWork event handler can pass more state to the RunWorkerCompleted event handler by setting a result property on the event args. The RunWorkerCompleted event handler can then take advantage of this data!

My Guidelines

In the end, both of these classes can be used to do work on a different thread than the one you’re currently on. That’s great news. So what are my guidelines for picking one over the other?

If you have a long running task that persists, or perhaps something that is running that conceivable have stop/running/paused states (regardless of whether or not you implemented them) you may want a Thread.

If you have a task you want to run with the result handled and cleaned up afterward (i.e. a clear distinction between go do this stuff and let me handle the result) then you may want a background worker.

If you have a task to be done that you don’t want to block the UI but want to show the result afterward (i.e. loading tons of data to put in a list) then you probably want a background worker.

Summary

Threads and background workers can often be used to accomplish the same thing: offloading work to be done on a different thread of execution. I’ve tried to provide my own personal guidelines for when to use either, but there is no law to stop you from doing it as you see fit. As long as you understand what either option provides you, you can make your own decision based on your needs.

I work as a team lead of software engineering at Magnet Forensics (http://www.magnetforensics.com). I'm into powerlifting, bodybuilding, and blogging about leadership/development topics over at http://www.devleader.ca.