Threads in C# : Part 1

New to C# ? Start from the beginning : Kick-Start C# : Your first program
Previous Post : Exception Handling : The use of Try and Catch

Well this is my first post in 5 months! And this is one piece of a topic to start writing again.

Understanding threads in C# require a bit of concepts from Delegates. You can brush up your delegate knowledge in my earlier post: Delegates and Events.

If you are a programmer and there's one single topic that bites you every time you encounter it, its Thread. Threads can be termed as lightweight Processes. If you are yet to take an Operating System course in your undergrad, you are probably not familiar with "Process". But don't worry, we don't need this concept here.

Let us try to understand why threads are necessary. Consider the case where you have developed a downloader software. Your software is the next big thing that people talk about! Y is a user and he is trying to download a 1 GB movie. Remember that your software is really good! So what does a good software do? It shows its user whats happening inside, intuitively, has a nice User Interface, right? Let us think simple from this point. Your machine is downloading data from a remote server, so your CPU must be busy processing that task, right? If your CPU is busy with that, then how do you show an intuitive progress bar? More importantly, if your user doesn't want to download it anymore, he should be able to cancel the operation with a Stop or Pause button. If the CPU is busy with grabbing data, your GUI will not interact with the user.

Threads make sure that critical parts of your program stay alive and interactive. Typically, threads are implemented when programs are CPU and memory intensive. Often threads are used to improve the response time of the software.

So lets get started with threads. The simplest way to create a thread is to create a new instance of the Thread class. The .NET framework provides us with the System.Threading namespace for creating and managing threads. The Thread constructor takes a single argument: a delegate type. The Common Language Runtime (CLR) provides a delegate class called ThreadStart. It points to the method that we want to run when the thread starts. Its more like "hey when you start, run this method".

public delegate void ThreadStart();

The delegate looks like the above. As you know from your knowledge on delegates, the methods that this delegate would point to should have the same signature as the delegate.

Here is a complete code using Threads in C#.

It may look a bit long and unnecessarily huge. But its always best to learn in simple manners.

Line 19 and 20 are the ones that we have been talking about. t1 is an object of type Thread. The Thread constructor takes as argument a ThreadStart type delegate. In this case, ThreadStart delegate points to the Increment method. Take a good note at the signature of Increment method. The method signature tells us that this method takes nothing as argument and returns nothing to the caller.

Finally, we need to tell the compiler when to start scheduling them. Line 22 and 23 does that for each of the thread objects. You can put t2 before t1. Basically it is up to the programmer which one to put first, but honestly it matters less.

Run 1

Run 2

I have put two screenshots of the program running on my machine. If you run it yourself, you may see a similar one, slightly different, or entirely the same.

Threads are more or less difficult to grab. They are also difficult to picture in the brain. The two screenshots merely points out that we cannot correctly anticipate the order of how two or more threads are running and switching. At least, it points out an idea; for example, if one thread is a grabbing data from the server and another is updating the UI, we will see an interactive thing going on in our screen. We know computers operate very fast. Our CPU lets each of the thread run for a while, and we get the illusion of a super interactive software on our screen.

Thanks for reading!