I’ve decided to take the Microsoft C# exam (code 70-483), mainly because I’ve been working in C# for 6 or so years now and it would be great to see how much knowledge I have of the language. Also, we’re all taking exams at work and I don’t want to be the one left in the dust.
Because of that, I’m going to be posting my revision notes here as I prepare for the test.
I don’t have an exam date yet, but I’ll be updating once I have one.
To prepare for this exam, I’m going to be using both of the following books:
- “Programming in C# – Exam Ref 70-483” by Wouter de Kort (ISBN: 978-0-7356-7682-4)
- MCSD Certification Toolkit (Exam 70-483): Programming in C# by Tiberiu Covaci and Rod Stephens (ISBN: 978-1-1186-1209-5)
Along with the Microsoft Virtual Academy series: “Programming in C# – Jump Start”
That video series is free, by the way
Today’s topic is Threads and Parallelism, but first a little Computer Science for those who don’t know what a Thread is.
The following is going to be an over simplification of what Processes and Threads are. For a more in depth description, see the Wikipedia article on Threading [LINK]
Threads, Processes and Applications
Without Threads (more on what they are in a second), a single long running program or Application would chew up CPU time until it was complete. This would mean that your computer would be completely unresponsive until the Application was closed.
Imagine that you’re listening to an MP3 (maybe it’s a podcast, or maybe it’s just a song). Without threads, your computer/phone/whatever (delete as appropriate) wouldn’t be able to do ANYTHING else whilst the song is playing.
Lighting up the screen? Can’t be done. Moving the mouse pointer? It wont budge. Receiving a WhatsApp message? You’ll have to wait.
What modern operating systems have is a concept called a Process. A Process is a container around a single Application (in almost all instances). This means that every application on your computer/phone/toaster oven/whatever, is running inside of it’s own process.
Processes
A Process has it’s own Vistualised Memory (a virtual version of the memory in your computer). This means that each application running on your computer has it’s own memory space – so no two applications can read each others memory.
So, when you are running the application that shows you cat pictures and a separate application that’s playing a song, neither one can see the contents of the others memory. The music player can’t see the cat pictures and the cat pictures app can’t see the music that you’re playing.
This helps to avoid situations where one application will overwrite or corrupt the data used by another application. This was a common problem back in the early days of computing, because you had to manually map the memory space for your application (putting data in a space that you think wont be used by some other application) and you had no way of protecting that memory. Another application could come along and overwrite the data that you were processing in memory.
That’s a gross over simplification, but it’ll do for now.
If an Application, which is contained within a Process, crashes or locks up then only that Process crashes or locks up, rather than the whole computer.
If you’ve ever seen a program window go pale and your mouse pointer is replaced with a spinning timer, then you’ve seen a process lock up. Did you notice that you can still use all the other applications that are running on your computer, and even start new ones?
That’s Processes.
Well, technically it’s Threads.
Each Process runs on it’s own Thread. So what’s a Thread?
Threads
A Thread is a container for each Process. A Thread is similar to a Virtualised CPU, in that it’s completely self contained.
You can imagine a Virtualised CPU as an imaginary CPU that can be started and stopped by your operating system, and that’s (almost) exactly how they work.
The real (sometimes called Physical) CPU in your computer runs a thread for a short amount of time, before pausing it and starting another one.
Let’s say that you’re running a cat picture application, a music player and a file downloader. Your physical CPU might do something like this:
- Start or resume the thread that the cat picture application is running on
- Run the cat application for a short time
- Pause the thread that the cat picture application is running on
- Start or resume the thread that the music application is running on
- Run the music application for a short time
- Pause the thread that the music application is running on
- Start or resume the thread that the file downloader is running on
- Run the file downloader for a short time
- Pause the thread that the file downloader is running on
- …
- etc
It does this constantly, giving you the illusion that your computer can run all three applications at the same time.
How long a thread runs for before it is paused depends on a lot of things, but it’s going to be in the somewhere in the hundreds of micro seconds for most desktop computers.
When a thread is Paused, it’s state (what the CPU was doing, the contents of the Vistualised Memory from the thread, and a bunch of other things) are saved before resuming another thread.
This process is called Context Switching, because the CPU is switching the current execution context (a cat pictures application, for example) for another (the music player application, for example).
Parallelism
Threads are what the operating system on your computer/phone/car/light bulb uses to utilise Parallelism.
Multiple threads (usually in the thousands) running on a single CPU is what makes this happen.
That’ll do for a basic intro to the theoretical background on Threads. I’ll post my notes for the Thread class in another blog post.
