Processes and Scheduling
Processes and scheduling are the operating system mechanisms that turn running programs into isolated, manageable units and decide when each one gets CPU time. A process has its own memory view and kernel-tracked state; the scheduler multiplexes runnable work across cores, so code can be alive without actually executing at that instant.
The problem is that a machine normally has more runnable work than CPU cores, and that work is often written by different programs, users, or services. Without isolation, a bug in one program could corrupt another program’s memory. Without scheduling, a busy loop could occupy a core indefinitely. The operating system therefore needs both boundaries around each running program and a policy for sharing finite CPU time.
A process is the kernel’s record of a running program: its virtual address space, open file descriptors, saved registers, process ID, signal state, and other bookkeeping. Virtual memory means the same address can exist in two processes while mapping to different physical RAM. The scheduler keeps track of tasks that can run, chooses one for a core, then context switches by saving one task’s CPU state and restoring another’s.
The trade-off is that isolation and sharing are not free. Context switches take time, virtual memory adds translation and kernel bookkeeping, and scheduling fairness can make latency hard to predict under load. A process can be runnable but not running, sleeping on I/O, stopped, or already exited but waiting to be reaped as a zombie. Priority and CPU limits alter who gets served first, but they do not create extra CPU.
Engineers meet this every time they inspect `ps`, debug a stuck worker, set `nice`, fork child processes, or configure container CPU limits. In containers, namespaces change what processes can see, while cgroups constrain what they can consume. A common misunderstanding is treating a container as a complete machine: process IDs, visible CPUs, and actual schedulable CPU share may all differ from what the host is enforcing.
Common questions
- Is a process the same thing as a program?
- No. A program is code and data stored somewhere, usually as an executable file. A process is a live instance managed by the operating system, with memory mappings, file descriptors, registers, and kernel metadata. Running the same program several times creates separate processes, each with its own state and scheduling history.
- If my process is runnable, why is it slow?
- Runnable only means the process is ready to execute if a CPU core is assigned to it. It may be waiting behind other runnable tasks, constrained by a CPU quota, or given lower priority. The honest answer depends on contention, scheduler policy, cgroup limits, blocking I/O, and whether the process is CPU-bound or mostly waiting.
- Does process isolation mean processes cannot affect each other?
- Only in a narrow memory-protection sense. One process cannot directly read or overwrite another process’s private address space, but processes still compete through shared resources such as CPU, disk, network, caches, locks, and temporary files. Isolation reduces accidental memory corruption; it is not a guarantee of independent performance or complete security.
- What is a context switch?
- A context switch is when the kernel stops running one task and resumes another. It saves the outgoing task’s registers and related execution state, changes the active memory mapping if needed, and restores the incoming task. This is what makes time sharing possible, but frequent switching can waste CPU on bookkeeping instead of application work.