Processes and Threads

Processes and Threads – How Your CPU Runs Multiple Programs at Once

Open your computer's task manager. You will see dozens of entries: Chrome, Spotify, Explorer, System, and many background processes. How does a single CPU with maybe 4 or 8 cores manage to run all of them simultaneously? The answer lies in two fundamental concepts: processes and threads.

1. Process: The Heavyweight Container

A process is an instance of a running program. It includes the program code, its own virtual address space (memory), open files and network connections, one or more threads of execution, and a process ID (PID).

Think of a process as a house. The house has its own address, its own rooms, and its own utilities. Multiple people can live in the house – those people are the threads.

Key property: Processes are isolated from each other. A process cannot normally read or write the memory of another process. If a web browser process crashes, it does not take down the file explorer.

2. Thread: The Lightweight Unit of Execution

A thread is the smallest unit of execution that the OS schedules. A thread belongs to exactly one process. Threads within the same process share the same memory space and open files, but each thread has its own stack (for local variables) and its own program counter.

A process is like a house; threads are the people living there. All people in the same house can see and move the furniture (shared memory). But each person has their own private notebook (stack) and their own to-do list (program counter).

3. Single-Threaded vs. Multi-Threaded Processes

Why use multiple threads?

• Responsiveness: While one thread downloads a file, another keeps the UI responsive.
• Resource sharing: Threads share memory efficiently, without the overhead of inter-process communication.
• Parallelism: On multi-core CPUs, different threads can run on different cores simultaneously.

4. How the OS Schedules Processes and Threads

The OS's scheduler uses a timer interrupt (typically every 1–10 milliseconds) to preempt the currently running thread and switch to another. This is called preemptive multitasking.

When the OS switches from one thread to another, it must save the current thread's registers and load the saved state of the next thread. A context switch between threads of the same process is relatively cheap. A context switch between different processes is more expensive because it involves switching the virtual memory mapping.

5. Process vs. Thread – Side-by-Side

6. Real-World Example: Your Web Browser

Open Chrome and look at Task Manager. You will see multiple processes: one browser process (main UI), one GPU process, one network service process, and one or more renderer processes – each tab often runs in its own process for security and stability.

Inside each renderer process, there are many threads: the main thread (handles DOM and JavaScript), a compositor thread, worker threads, and a network thread. This design gives isolation (a crash in one tab does not close the whole browser) while allowing threads within a tab to share memory efficiently.

7. Common Problems: Race Conditions and Deadlocks

When multiple threads share memory, they can interfere. Two threads incrementing the same counter might both read the original value, increment, and write back – losing one increment. This is a race condition. The solution is synchronization (mutexes, semaphores).

A deadlock occurs when Thread A holds Lock 1 and waits for Lock 2, while Thread B holds Lock 2 and waits for Lock 1. Both wait forever.

Summary

Review Questions

1. Why is it safer to run each browser tab in a separate process rather than in separate threads of the same process?
2. If a thread in Process A performs an illegal memory access, does it crash only that thread or the whole process?
3. In a video editing program, why would the developer choose to use multiple threads instead of multiple processes for tasks like rendering and UI updating?