Also known as: thread, OS thread
A thread is an independent flow of execution inside a process. The operating system can give one process several threads that share the same memory and run on different CPU cores at the same time — the oldest and most direct route to parallelism.1
How it works
A process starts with one thread and can spawn more, and the OS scheduler hands each thread time on a core. Because threads in a process share its memory, they communicate simply by reading and writing the same variables — fast and powerful, but the source of the danger. When two threads touch the same data and at least one writes, with no coordination, you have a data race, and the result is undefined: a half-updated value, a counter that loses increments, a crash that appears once a week.1
Trade-offs
Threads are genuinely parallel and map directly onto hardware cores, so they suit CPU-bound work. The traditional fix for races is a lock (mutex): only one thread may hold the lock and touch the shared data at a time. Locks work but bring their own hazards — deadlock (two threads each waiting on a lock the other holds), forgotten locks, and contention that erodes performance. OS threads are also relatively heavy, so running hundreds of thousands of them is impractical.1
In practice
C, C++, Rust, and Java expose OS threads directly, with Rust’s type system preventing many data races at compile time. To avoid heavy threads and explicit locks, other models build on top of them: async/await multiplexes tasks onto a single thread, and goroutines multiplex many lightweight tasks onto a few OS threads.
Sources
-
Thread (computing) — Wikipedia, on threads as flows of execution sharing process memory, plus data races, locks, and deadlock. ↩ ↩2 ↩3