Process vs Thread

A process is a running program with its own private slice of memory — its address space, holding the program's code, its global data, and a heap it can grow. A thread is a single flow of execution *inside* a process. A process always has at least one thread; it can have many, and they all share the process's address space. That sharing is the whole trade-off: threads coordinate cheaply and switch fast, but because they share memory, that shared state must be carefully synchronized.

What each one owns

1. 1The process owns the address space — code, global data, and heap — plus OS resources like open files and sockets. All its threads share these.
2. 2Each thread owns its own stack (local variables and call history), its CPU registers, and its program counter (where it is in the code).
3. 3Shared by every thread in a process: the heap and the globals — so one thread can see and change another's data directly.

The cost of sharing — synchronization

Because threads share memory, an unlucky interleaving can corrupt it.

int counter = 0;          // global, shared by both threads

// two threads each run:
counter = counter + 1;    // read, add, write -- NOT atomic

// an interleaving that loses an update:
//   A reads 0        B reads 0
//   A writes 1       B writes 1   <- should be 2

Both threads share counter, so an unlucky overlap loses an update — a race condition, fixed with a lock or semaphore. Separate processes don't share memory by default, so they sidestep this; but to cooperate they must use inter-process communication (IPC) — pipes, sockets, or explicitly shared memory.