Processes and Threads

A process and a thread are both units of execution, but they operate at different levels. A process is an independent running program with its own virtual address space and operating system resources. A thread is an execution path inside a process. Multiple threads in the same process share the same memory and most of the same resources, but each thread has its own program counter, stack, and scheduling state.

This distinction matters because it shapes both performance and failure behaviour. Processes are isolated from one another. If one process crashes, the operating system can usually clean it up without corrupting the memory of another process. That isolation is why browsers, databases, and operating systems often use separate processes for security or fault containment.

Threads are lighter weight. Creating a new thread is generally cheaper than creating a new process, and switching between threads in the same process usually involves less overhead than switching between fully isolated processes. Because threads share memory directly, they are a natural fit for parallel work over shared data structures.

The benefit of shared memory is also the danger. Threads can see and modify the same data at the same time, so concurrency bugs become possible: race conditions, deadlocks, visibility problems, and corruption from unsynchronised writes. Processes avoid many of these issues because they communicate through more explicit mechanisms such as sockets, pipes, or shared memory segments with deliberate coordination.

Communication patterns therefore differ. Inter process communication is slower and more explicit, but the boundaries are clearer. Intra process thread communication is fast because it happens through ordinary memory reads and writes, but it requires disciplined synchronisation using locks, atomics, channels, or other coordination primitives. When teams say threads are "hard", they usually mean that shared mutable state is hard.

Language runtimes add another layer. Some runtimes map language threads directly to OS threads. Others use green threads, coroutines, or schedulers that multiplex many tasks onto fewer OS threads. That means the user level abstraction is not always identical to the operating system's primitive, even though the same conceptual tradeoffs remain.

A practical rule is this: choose processes when you need isolation, security boundaries, independent deployment, or different failure domains. Choose threads when you need low overhead parallelism inside one application and are prepared to manage shared state correctly. Many systems use both. A web server may run multiple worker processes for isolation, and each worker may use a thread pool for concurrency.

The difference is therefore not academic. It affects memory sharing, startup cost, crash impact, debugging style, and how a system scales across CPUs. Processes buy safety through separation. Threads buy efficiency through shared context. Good system design comes from knowing when the efficiency is worth the coordination cost and when the boundary is the more valuable resource.