Don't Panic: Processes, Threads, and Scheduling

A process is what a program becomes when the operating system starts it: a running instance with resources, including an address space, open files, credentials, and one or more execution paths. The program on disk is not busy. It is, in fact, spectacularly inactive. The process is the operating system's answer to the question, "which running work owns these things?"

Those execution paths are threads. They run the instructions, share the process resources, and become the units waiting for CPU time. This split exists because one activity often has more than one thing to do. A server can wait for network input while handling ready work. An application can keep one activity moving while another waits. Before that distinction, every wait would make the entire program wait, which is a poor use of a perfectly good processor.

The useful three-word state map is running, runnable, blocked. Runnable means a thread could execute but is waiting for a processor. Blocked means it is waiting for an event, such as a lock, input and output completion, a timer, or another dependency. This is the surprise that saves a great deal of misplaced tuning: a large thread count does not say that CPUs are busy. Many threads may be asleep, which is not laziness. It is coordination.

The scheduler chooses among runnable threads according to operating-system policy and priority. It tries to balance latency, throughput, fairness, and sometimes power use. That is not a magic speed dial. Higher priority does not create processor capacity, and more threads do not dissolve one lock, one storage device, or one serial piece of work. They merely give the scheduler more candidates for the same finite resource, which is an administrative achievement rather than a performance improvement.

Threads share state, and this is where the paperwork becomes physics. A mutex keeps conflicting changes out of the same critical section. A condition or event tells a waiting thread that progress may be possible. Use threads when work needs close coordination and you can name who owns the shared data. Use processes when independent ownership and isolation matter. The operating system is not being fussy about boundaries. It is trying to stop one accident from becoming several.

Start with the Cheatsheet for the states, policy terms, and diagnostic sequence. Use the Reference tab for POSIX and Linux scheduler detail. The Practice material turns the model into evidence on a Linux process. Read Field Notes before treating CPU percentage, affinity, or scheduler traces as self-explanatory. The Timeline shows why the interfaces and scheduler models behind these familiar words have kept changing.