1. The Passive Blueprint

When you compile your C or assembly code, the toolchain generates an ELF binary or raw hex file.

But what actually runs when you power on the processor? Is it the program itself, or is it something else? * A Program is a static collection of instructions and data sitting passively on your flash memory or hard drive. It does nothing on its own. * A Process is the active, living instance of that program loaded into memory and running under the supervision of the Kernel.

To understand how operating systems coordinate concurrent software, we must trace this transition from passive instructions to active execution paths.

2. The Execution Hierarchy

Before we dive into the scheduling algorithms, we must establish a clear hierarchy of running software:

3. Active Execution: The Process

When the Kernel loads a Program into RAM, it creates a Process. A Process is not simply a copy of the code; it is a complete, isolated sandbox.

The Process owns all resources required for execution: * Private Memory Space: Isolated regions of RAM that other processes cannot read or modify. * Resources: File descriptors, network sockets, and hardware ports assigned to that running application. * Execution State: Status metrics tracking credentials, privileges, and context data.

Within this Process sandbox runs the actual work. This is the role of the Thread.

A Thread is the actual path of execution inside a Process. A Process represents resource ownership; a Thread represents execution state. Every Process has at least one Thread, but advanced applications can spawn multiple Threads that share the same Process memory space.

4. Inside the Container

To understand the relationship between a Process and its Threads, we can look at how resources are shared inside the container:

5. The Anatomical View

When the Kernel manages a Process, it maps out a strict layout within the system RAM. This structure contains both the program resources and the execution states of the threads:

* Program Code (Text): The compiled machine instructions read directly from flash or disk. This region is read-only to prevent programs from modifying themselves. * Stack: A fast, private memory region allocated to each thread. It tracks active function calls, parameters, local variables, and return targets. * Heap: A large dynamic memory pool used by the application during runtime. Memory is requested via malloc or new and must be freed explicitly. * Registers: High-speed hardware CPU storage slots. When a thread is executing, it writes directly to registers. When it yields, its register state must be saved. * Program Counter (PC): The specialized CPU register that holds the memory address of the next machine instruction to be executed by the active thread. * Process State: Flags and identifiers monitored by the Kernel that track process privileges, identity numbers, and current execution eligibility.

6. The Unit of Orchestration

In the previous exploration, we saw that the Kernel coordinates system resources. Now we can see the exact target of that coordination.

The Kernel does not interact with static files or programs directly. It schedules the active execution threads running within a Process sandbox. The Process acts as the boundary of resource ownership: * A crash inside one Process is isolated. Because Process RAM blocks are separated, one application cannot accidentally overwrite or crash another. * Before the Kernel can schedule clock cycles or allocate RAM space, it first needs a Process structure.

The Process is the fundamental container of running code that makes multiplexed operating systems possible.

7. The Lifecycle

The Kernel maintains a complete tracking directory of all active processes. But a process does not remain in the same execution state forever.

As it runs instructions, waits for network packets, yields to high-priority tasks, or shuts down, its execution eligibility changes. The Kernel must continuously monitor and adjust these states to maintain high performance.

The journey of execution is mapped through these changing stages.

The Lifecycle of Execution

A process is not a static container. It is a dynamic, living entity.

As it executes instructions, handles hardware inputs, and waits for memory resources, its relationship with the CPU changes.

The Kernel must continuously track this changing behavior to decide who runs next.

The journey of execution is mapped through these changing states.