Threads and Processes

Most concurrency confusion comes from blurring three words, so it’s worth pinning them down:

• A program is code sitting on disk.
• A process is a program that’s running, with its own memory space.
• A thread is a unit of execution inside a process. Threads share the process’s memory.

The three “multis”

• Multiprogramming: many processes on one CPU, interleaved so it looks like they run together.
• Multiprocessing: many CPUs or cores, so work genuinely runs in parallel.
• Multithreading: many threads in one process. They’re cheap to create and switch between because they share memory, and that sharing is exactly why they need Synchronization.

Why it matters

Shared memory is fast and dangerous: two threads updating the same value can interleave in ways nobody intended (a race condition). There are two ways out. You can guard shared state with locks, or avoid sharing altogether and use Message Passing.

In practice

• JavaScript is single-threaded with an event loop. async/await is concurrency without parallelism, and Web Workers (or Node worker threads) are how you get real threads, which communicate by message passing.
• Rust’s ownership rules make data races a compile-time error rather than a 3am incident.
• Real-time UIs live this every day: keep the main thread free for rendering and push heavy work (parsing a firehose of updates, layout calculations) somewhere else.

Related: Synchronization · Deadlock and Starvation · Message Passing