A process control block (PCB) is a data structure that an operating system creates to store everything it needs to know about a single running process. Every time you launch a program, the OS generates a PCB for it, tracking details like where the program left off executing, what memory it’s using, and what files it has open. The PCB is sometimes called a process descriptor, and it’s one of the most fundamental structures in how an operating system manages work.
Why the PCB Exists
Modern operating systems run dozens or hundreds of processes at the same time, but most computers have far fewer CPU cores than active processes. The OS constantly juggles which process gets CPU time, pausing one to let another run. To pull this off, it needs a reliable place to record each process’s full state so it can pause and resume processes without losing any work. That’s exactly what the PCB does.
The PCB is created the moment a process is initialized and destroyed when the process terminates. In between, it’s read and modified by nearly every core OS utility: the scheduler checks it to decide which process runs next, memory management updates it when pages are allocated, and I/O systems reference it to track which devices and files belong to which process.
What a PCB Contains
A PCB packs a lot of information into a single structure. The exact fields vary between operating systems, but the core categories are consistent.
Process ID and state. Every process gets a unique numeric identifier (PID). The PCB also records the process’s current state: new, ready, running, waiting, or terminated. A “ready” process is loaded in memory and waiting for CPU time. A “running” process is actively assigned to a CPU core. A “waiting” (or sleeping) process is paused until some event occurs, like data arriving from a disk read. When that event happens, the OS sends a wakeup signal and moves the process back to the ready state.
CPU register values. When a process is paused, the OS needs to snapshot the exact contents of the CPU’s registers so it can restore them later. This includes the stack pointer (which tracks the top of the process’s call stack), the frame pointer (which helps navigate function calls), and the program counter (which records the exact instruction the process was about to execute). Other general-purpose register values are typically saved on the process’s own kernel stack.
Scheduling information. The PCB holds the process’s priority level, how much CPU time it has consumed, and any other data the scheduler needs. In a priority-based system, the scheduler reads this field to decide which ready process should run next. The PCB may also store which scheduling queue the process currently sits in.
Memory management information. This includes pointers to the process’s page table or segment table, which map the virtual addresses the program uses to physical locations in RAM. It also tracks how much memory the process has been allocated. If a process’s address space gets swapped out to disk (secondary memory), the OS updates this information so it knows where to find the data when the process needs to run again.
I/O and file information. The PCB tracks which files the process has open, which I/O devices are allocated to it, and any pending I/O requests. Separate queues exist for different resources: one for a terminal device, another for interprocess communication (IPC) messages, and so on.
Accounting data. Some implementations track CPU time used, wall-clock time since process creation, and resource usage limits. This data is useful for system monitoring and enforcing quotas.
How the PCB Enables Context Switching
Context switching is the mechanism that lets an OS stop one process on a CPU and start another. The PCB is what makes this possible, because it holds the complete snapshot of a process’s execution state. The sequence works like this:
- The OS saves the currently running process’s execution state (registers, program counter, stack pointer) into its PCB.
- It updates that PCB’s status, for example changing it from “running” to “ready.”
- The scheduler selects the next process to run.
- The OS updates the chosen process’s PCB status to “running.”
- It restores that process’s saved execution state from its PCB into the CPU’s actual registers.
At the hardware level, this involves pushing register values onto the outgoing process’s kernel stack and popping them from the incoming process’s stack. Each process typically gets a dedicated 4 KB page for its kernel stack, which is only used when the process is executing in kernel mode. The entire swap happens in a matter of microseconds, fast enough that users perceive all their programs as running simultaneously.
Context switches happen constantly. Every time your OS’s scheduler decides a process has used its time slice, or a process voluntarily waits for I/O, a context switch occurs. On a busy system, this can happen thousands of times per second, and every single one reads from and writes to a PCB.
PCBs in Real Operating Systems
Different operating systems implement the PCB concept under different names, but the core idea is identical. In the Linux kernel, the PCB is a C structure called task_struct. It’s one of the largest data structures in the kernel, containing hundreds of fields that cover everything from scheduling priority to signal handling to filesystem context. Linux creates one task_struct for every process and every thread on the system.
Windows takes a slightly different architectural approach. It separates process and thread information into distinct structures. The process-level data lives in a structure called EPROCESS, while thread-specific execution state sits in a separate structure linked to it. This split reflects the fact that a single process can contain multiple threads, each with its own register state and stack, but all sharing the same memory space and open files.
Despite these structural differences, both systems use their PCB equivalents for the same purposes: tracking state, enabling context switches, and giving the scheduler the information it needs to manage CPU time.
How PCBs Are Organized
The OS doesn’t just create PCBs in isolation. It organizes them into linked lists and queues that reflect process states. There’s a ready queue containing the PCBs of all processes waiting for CPU time, ordered by priority or arrival time depending on the scheduling algorithm. There are device queues holding PCBs of processes waiting on specific I/O operations. And there’s a list of all PCBs on the system, which the OS traverses when it needs to find a process by its ID.
Each PCB contains a link field (essentially a pointer) that threads it into whatever queue it currently belongs to. When a process changes state, the OS removes its PCB from one queue and inserts it into another. A process finishing a disk read, for instance, gets its PCB moved from the disk’s device queue into the ready queue. This queue-based organization is what lets the scheduler quickly find the next process to run without searching through every process on the system.
PCBs live in kernel memory, which is protected from user-space programs. No regular application can read or modify its own PCB or anyone else’s. Only the kernel has access, which prevents a buggy or malicious program from corrupting process management data and crashing the system.