Process vs Thread

Task: Run the same work twice, once as processes and once as threads

Start with a program

A program sitting on your disk is just a file. It does nothing.
Double click it and the operating system loads it into memory and starts running it.
That running copy is a process.
Open the same app twice and you get two processes. Same file, two separate runs.

Open your task manager right now and you are looking at a list of processes.

What a process is given

When the operating system starts a process, it hands it a block of memory that belongs to that process and nothing else.

Four parts, and it is worth knowing their names because everything else in this chapter refers to them.

The important word is own. Another process cannot read this memory. If it tries, the operating system stops it. That isolation is not a bonus feature, it is the main thing a process is for.

So what is a thread?

The memory is just storage. Something has to actually walk through the code and run it.

A thread is a single line of execution inside a process.

It has its own stack, so it can keep track of which function called which, and its own place in the code.

Every process has at least one thread. That is the one that starts when the program starts.

So a process is not the thing that runs. A process is the box. A thread is the thing running inside the box.

Watch out

You will often see "a thread is a lightweight process". It is a rough analogy and it causes more confusion than it clears up. A thread is not a small process. It is a runner inside one.

Doing two things at once

Say you want your program to do two jobs at the same time. You have two options.

Option one: run the program twice. Two processes, two separate boxes of memory.

Option two: one process, two threads. One box, two runners inside it.

The animation at the top of this page walks through both. The difference is not speed. The difference is memory.

Two threads in one process share everything the process owns. The code, the globals, the heap, even open files and network connections. The only things each thread keeps to itself are its stack and its place in the code.

Try it

Two workers, each adding 1 to a counter three times. Press as threads to switch between the two arrangements and watch the answer change.

Try it yourself

Two workers, three additions each. The memory decides the answer

count = 0one counter each, in separate memory

0 of 6 additions

As two processes, each worker has its own counter and both end at 3.

As two threads, there is one counter between them and it ends at 6.

Same program. Same number of additions. The only thing that changed is whether the memory was shared.

Processes have separate memory. Threads in one process share memory. Almost every other difference between them follows from that one fact.

What that buys, and what it costs

Sharing memory makes threads fast. Two threads pass data by writing to the same variable, which takes no time at all. Two processes have to copy data across a boundary the operating system polices.

Sharing memory also makes threads dangerous.

If one process crashes, the other keeps running. It never even notices. If one thread crashes badly enough, it usually takes the whole process down, and every other thread with it, because they were all standing in the same memory.

There is a second danger, and it is the more common one. When two threads write to the same variable at the same time, they can tread on each other and lose an update. That is called a race condition, and it is what locks exist to prevent. It is a chapter of its own.

Side by side

Aspect	Process	Thread
Memory	Its own, isolated	Shared with other threads in the process
Own stack	Yes	Yes
Starting one	Slower, needs new memory	Faster, memory already exists
Sharing data	Needs help from the OS	Just use the same variable
If it crashes	Others keep running	Usually takes the process down

Notice that both have their own stack. That trips people up. A thread shares plenty, but never its stack, because a stack is a record of where that particular runner is up to.

When to reach for which

Use separate processes

When the jobs are independent, and one failing must not take the others with it. Your browser does this: each tab is its own process, so one bad page cannot close the window.

Use threads

When the jobs are part of one piece of work and need the same data. A game drawing frames while loading the next level is one process with several threads.

A text editor keeps typing responsive while it saves a large file in the background.

Are the two jobs better as threads or processes?
Why?

Show answer

Threads.
Saving needs the document that typing is editing. As threads they share it directly. As processes the document would have to be copied across, and the copy would be out of date the moment you typed another character.

Quick recap

A process is a running program with memory of its own
A thread is one line of execution inside a process
Every process has at least one thread
Threads share the code, globals and heap of their process
Every thread keeps its own stack
Separate processes are safer, threads are faster and closer together

A process is the box of memory. A thread is what runs inside it. Two processes cannot see each other's memory; two threads in one process share almost all of theirs.