Aller au contenu principal
Processes, IPC (including semaphores), scheduling, memory, I/O, file systems, virtualization, concurrency models, performance profiling, and the hardware-software interface.

Operating Systems

Processes, IPC (including semaphores), scheduling, memory, I/O, file systems, virtualization, concurrency models, performance profiling, and the hardware-software interface.

Hardware Story

Follow the path from instruction to process

This walkthrough makes the hardware roles behind process execution feel tangible. Each step highlights whether the machine is computing, moving data, storing state, or waiting on input.

Current focus

Machine state
Signal
Key ideas

    Computer Hardware Fundamentals

    Beginner (1/5) ~1–2 hours CPU Memory Storage Input/Output Bus Interrupts Processes

    Why Hardware Matters

    Every program you run is only useful because hardware can execute it. A process is not just “code on disk” — it is a living sequence of instructions, data, and state that the machine moves through a set of hardware components.

    The best way to understand this is to ignore brand names and focus on roles:

    • CPU does computation and control
    • Memory holds data and instructions that are actively used
    • Storage preserves data for the long term
    • Input/output devices let the machine interact with the world

    Once you see these roles clearly, you can reason about nearly any computer system, from a phone to a server to an embedded controller.

    This topic is about what the parts are and how a process uses them. The mechanics of how the CPU actually runs an instruction (the fetch-decode-execute loop, pipelining, superscalar execution) and the quantitative cost of reaching across the storage hierarchy are the subject of Computer Architecture Fundamentals — read this one first for the vocabulary, then that one for the engineering pressure that motivates most OS design decisions.

    CPU: The Executor

    The CPU is the component that performs computation. It is often described as the “brain,” but that is a simplification. It is better thought of as a very fast controller for a small set of operations.

    A CPU typically has:

    • Registers — tiny, very fast storage locations for immediate work
    • Arithmetic/logic units — circuits that add, compare, shift, and combine values
    • Control logic — decides which instruction to run next
    • Cache — small, fast memory near the core for recently used values

    The CPU does not work on the whole world at once. It works on a small working set of data that has been brought close to it. Why caches exist (latency), how that hierarchy is structured, and how the CPU steps through instructions are the engineering part of the model — see Computer Architecture Fundamentals for the latency table and the fetch-decode-execute loop.

    Memory and Storage: Two Roles, One Hierarchy

    A common point of confusion is the difference between memory and storage as roles:

    • Memory is the active workspace for current computation — what the CPU is touching right now.
    • Storage is the durable place where files and programs live when they are not actively being used.

    When you launch an application, the operating system loads parts of it from storage into memory. The CPU then works from memory. If the machine needs more data, it may fetch it from storage or swap it in from a backing store.

    Both are part of a single tiered store that reaches from registers all the way down to network-attached disks. The ordering (registers → cache → main memory → SSD → HDD → network), the latency ratios between tiers, and the principle of locality that makes the hierarchy work are the subject of Computer Architecture Fundamentals. For this topic, keep the role distinction: memory is the active workspace, storage is the durable vault.

    Input and Output: The Interface to the World

    A computer is not isolated. It receives input from devices such as keyboards, mice, microphones, cameras, or networks, and it produces output through displays, speakers, printers, storage, or network interfaces.

    These devices are connected through a bus or network of interconnects. They are often slower than the CPU, so the system uses buffering and interrupts to avoid wasting time.

    Buses and Coordination

    Hardware components do not operate independently. They need a way to exchange addresses, data, and control signals. That role is served by a bus.

    A bus can be thought of as the computer’s highway system:

    • Address bus tells the hardware where data should go or come from
    • Data bus carries the values themselves
    • Control bus carries signals such as read/write commands and timing directives

    Without these channels, the CPU, memory, and devices would have no shared way to coordinate their work.

    Interrupts and Asynchronous Work

    Many hardware events happen while the CPU is busy with something else.

    An interrupt is a signal that says, “something important happened; pause and handle it.” Examples include:

    • a keyboard key press
    • a network packet arriving
    • a disk read completing
    • a timer firing

    The CPU can then switch attention briefly to the new event. This is one of the key mechanisms that makes modern systems feel responsive — and the same mechanism the OS later uses to multiplex many processes onto one CPU (see Process Management & Scheduling).

    How a Process Fits Into This

    A process is an abstraction: it is a running program plus its own memory, state, and execution context. The hardware does not directly “know” about your Python program or your web server as a human concept, but it can execute the instructions that implement them.

    At a practical level, a process needs:

    • CPU time to execute instructions
    • memory to hold its data and stack
    • access to files or devices for input and output
    • coordination with the OS so it can be scheduled and managed

    When the operating system runs a process, it gives it a slice of CPU time, a region of memory, and access to the resources it needs. When the process waits on I/O, the CPU can work on something else instead of idling.

    The Process Flow in Hardware Terms

    A useful way to think about process execution is as a chain of roles the parts play — not a chronological trace of one instruction (that is the fetch-decode-execute loop in Computer Architecture Fundamentals), but the roles whose participation makes a process real:

    1. The OS loads program instructions from storage into memory.
    2. The CPU consumes those instructions over time, with memory feeding each step and caches/registers keeping the working set close.
    3. Input/output requests may trigger device activity and interrupts.
    4. The OS schedules another process on the CPU when the current one must wait on I/O.

    That role view is why understanding hardware is so important for understanding process behavior. The seemingly abstract idea of a process is implemented through very concrete movement of instructions and data across hardware components.

    The Mental Model to Keep

    If you remember one thing, remember this:

    • the CPU executes work
    • memory holds what is active
    • storage preserves what is not active
    • I/O connects the system to the outside world
    • the operating system coordinates all of these so many processes can share the machine

    This is the general foundation behind every modern computer, regardless of manufacturer, architecture, or operating system.

    Practice Trajectory

    1. Trace a simple action such as opening a file or launching a program and identify the roles — where the CPU, memory, storage, and I/O each participate.
    2. Explain why a program that is waiting on I/O can still let the computer do other work, using the words interrupt and scheduling.
    3. Use the terms register, bus, interrupt, and process in a short explanation of how a computer runs software.
    4. List the parts the CPU works with directly (registers, cache) versus the ones the OS mediates (memory, storage, devices) and explain the difference.

    When This Topic Helps

    SituationTakeaway
    Learning operating systemsYou will see why scheduling, memory management, and I/O matter
    Debugging performanceYou will understand where bottlenecks usually appear (the architecture topic gives the latency numbers)
    Reading low-level docsThe CPU/memory/I/O model makes the terminology less mysterious
    Understanding processesYou will have a better grasp of why process execution is not just code running by itself