Threading in .Net – Part I – The Basics.

The Problems with Single Threaded Systems

In early days of computers the entire operating system was executed on a single thread. The problem with these kind of systems back then was the long running tasks would prevent the execution of other tasks causing the other applications and OS to stop responding, And if the long running task has some bug in it, or if it goes to an infinite loop then the end user has no choice but to reset the system. This was a common problem for the 16-bit systems, as they were able to access only 1MB of memory. Microsoft knew that 16-bit Windows would not be a good enough operating system to keep Microsoft relevant in the industry, so they created a new OS to address the needs of Corporations and individual. Microsoft designed the new OS (Windows NT), they decided to run each instance of an application in its own Process. A Process is nothing but a collection of resources that is used by a single instance of an application. Each Process in windows has given its own virtual address space. This made applications on windows robust, as the code and data used by one process cannot be accessed or corrupted by any other application process. This is all good, but what about the CPU time? What if an application gets CPU time and enters the infinite loop, or if introduces a bug? The system could still stop responding, to all these problems Thread were the answer.

What is Thread?

A Thread is a windows concept whose job is to virtualize the CPU, Windows gives each process its own thread, which acts as a CPU for that process. So if the process goes in to an infinite loop or it gets any bug while executing, it will not halt the entire operating system or any other applications but itself. The operating system and other application keeps running.

CPU Trends

 In past CPU speeds used to increase with time, so the applications ran slow on one machine ran faster on another machine. However CPU manufacturers unable to continue this trend of making CPU faster, because the faster the CPU gets the more heat it is going to produce. There were common cases where after running the computer for a while the CPU and motherboard melted. Since CPU manufactures can’t continuously produce higher speed CPUs they had instead turned their focus to make the multicore CPUs. Today it’s very common to have a single silicon chip that contains two or more CPU cores.

Threads are awesome to achieve maximum throughput out of the CPU, if we care to achieve raw performance, then the optimum number of threads to have on any machine is identical to the number of CPUs on that machine. If you have more threads than the CPU, then context switching is introduced by the OS and the performance decreases. Although Microsoft designed Windows in a way which assigns at least one thread to each process for improved OS responsiveness. They preferred reliability and responsiveness over the raw performance.

If you look at below image, my machine is currently executing 168 Process, which means there are at least 168 threads. It also shows there are total 2170 threads currently working on my machine. Which also means that 2170 MB of memory is allocated just for the thread stack. My CPU usage are currently at 4 %. Which also means out of those 2170 threads only 4% of threads are working, rest of all are just sitting there doing nothing. From this data we can conclude that all of the application running inside my OS are not using threads effectively, or we can blame the developers of those application.

Below are some reasons why someone should use threads.

To get concurrent execution: If you know you are working on a machine with multicore CPU, you should take advantage of those extra CPU by executing multiple Threads on it simultaneously. Although make sure you don’t overdo it, it is equally bad.

To make UI Responsive:  It is common approach followed by UI applications these days to have a separate UI thread whose job is to render the UI. If you are performing any CPU intensive task you can execute that task on some other thread, which will help keep the application UI responsive. 

As a developer it is quite difficult to create and manage the lifecycle of the threads. Microsoft was well aware of this problem, and for a developer who is using windows threads via CLR i.e. .Net framework, Microsoft introduced Threadpool. We will discuss Threadpool in the next Part.

Refernces  : CLR Via C# by Jeffrey Richter