2. Computing Environments and Interrupts¶

The same handful of OS ideas — processes, scheduling, protection — show up whether the machine in front of you is a laptop, a phone in your pocket, or a server you will never physically touch, sitting in a data center on the other side of the world. What changes is the environment that OS has to operate in, and the constraints that environment imposes. The first half of this lecture surveys those environments. The second half returns to a mechanism Lecture 1 only introduced briefly — the interrupt — because almost nothing else an OS does would be possible without it, and it deserves a much closer look.

In This Lecture¶

The major computing environments in use today, and how each one's constraints shape the OS running inside it
Why interrupt-driven operation, not polling, is the mechanism that lets an OS react instead of constantly check
The interrupt vector table, and how the CPU locates the right handler without searching for it
Software interrupts (traps) vs. hardware interrupts, and the main categories of interrupt an OS has to handle: I/O completion, timer, program error, and system call

Computing Environments¶

Traditional (Desktop) Computing¶

For a long time, "a computer" meant a standalone PC: one box, one user, running programs loaded from local disks. That picture has blurred steadily — most desktops and laptops are now always connected to a network, reach services through a browser, and increasingly behave like thin clients that lean on remote servers for storage and computation rather than doing everything locally. The traditional environment hasn't disappeared, but the line between it and the client-server and cloud environments below has mostly dissolved.

Mobile Computing¶

Smartphones and tablets run general-purpose operating systems — Android, iOS — capable of most of what a laptop OS can do, but the hardware they run on imposes constraints a desktop OS never had to take seriously:

Battery power — every scheduling and I/O decision has a direct, measurable energy cost, so a mobile OS has to actively manage power, not just performance.
Limited memory — mobile devices typically carry far less RAM than a comparable laptop, so the OS aggressively suspends or kills background apps under memory pressure rather than letting them accumulate indefinitely.
Reliance on wireless networking — Wi-Fi, cellular data, Bluetooth, and NFC replace the wired connections a desktop could assume were always available and always fast.
A different sensor and interaction model — GPS, accelerometers, gyroscopes, and touchscreens are first-class inputs a desktop OS simply doesn't have to manage.

Client-Server Computing¶

Client-server computing centralizes a service on one or more powerful server systems that satisfy requests generated by many client machines — a compute server responds to requests for computation ("run this query") and a file server responds to requests to fetch or store files. This architecture, not the old dumb-terminal/mainframe model, is what most of today's internet actually runs on: the client is itself a capable computer, but it deliberately delegates specific services to a server over the network.

Peer-to-Peer Computing¶

Peer-to-peer (P2P) computing removes the client/server distinction entirely: every node is a peer, capable of acting as both a client requesting services and a server providing them to others. A peer wanting a particular service first has to locate it among potentially thousands of other peers — either by broadcasting a request and waiting for a reply, or by registering with, and querying, a centralized lookup service that then hands off to direct peer-to-peer communication once the right peer is found. File-sharing protocols like BitTorrent are the canonical real-world example.

Cloud Computing¶

Cloud computing delivers computing, storage, and application services over a network as an on-demand, metered utility rather than as hardware you own. It comes in three flavors:

Public cloud — made available to anyone willing to pay, over the open internet (the model behind AWS, Azure, and similar providers).
Private cloud — run by an organization strictly for its own internal use, on hardware it controls.
Hybrid cloud — combines both, typically keeping sensitive workloads on a private cloud while bursting less sensitive or more elastic workloads out to a public cloud as demand requires.

Underneath all three, cloud computing depends on virtualization: a cloud environment is built from physical hardware running a virtual machine manager, plus additional management software (for provisioning, billing, and monitoring) that can carve out exactly the resources an application asked for — a web server here, a database server there — each potentially its own virtual machine, created and destroyed on demand.

Five computing environments

Traditional Standalone desktop/laptop, now almost always networked

Mobile Battery, memory, and wireless constraints shape every decision

Client-Server Capable clients delegate specific services to a central server

Peer-to-Peer No fixed server — every node can be both client and server

Cloud Public, private, or hybrid — built on virtualization underneath

These environments overlap constantly in practice

A mobile app is almost always also a client-server app, talking to a backend that is itself running in a public or hybrid cloud. Treat these five as lenses for describing where computation happens and who controls it, not as mutually exclusive categories a real system must pick exactly one of.

Interrupts in Depth¶

Interrupt-Driven Operation: Why Not Just Poll?¶

Lecture 1 introduced the interrupt briefly; it is worth being completely explicit about why it exists, because it is the single mechanism that makes an OS reactive rather than constantly busy. Without interrupts, the only way for software to notice that a device had finished something would be polling — a loop that repeatedly reads a device's status register, asking "are you ready yet?" over and over, until the answer is yes. Every one of those checks that comes back "not yet" is a CPU cycle spent accomplishing nothing, and for a device as slow as a disk relative to the CPU, that waste is enormous.

Interrupt-driven operation inverts the relationship: instead of the CPU repeatedly asking, the device tells the CPU, by asserting a signal on an interrupt-request line that the CPU's control unit checks after every instruction it executes. Until that signal appears, the CPU is completely free to run other work — which is exactly what makes multiprogramming and multitasking (Lecture 1) possible at all. If the CPU had no choice but to poll a device in a tight loop, it could never meaningfully be handed to a different process in the meantime; the whole point of giving the CPU to someone else while a device is busy depends on the device being able to interrupt the CPU later, rather than the CPU having to keep checking on it.

The Interrupt Vector Table¶

When an interrupt line is asserted, the CPU needs to find, immediately, the correct routine to handle it — and it cannot afford to search through every possible handler to find the right one. The hardware solves this with an interrupt vector: a table of addresses, one entry per distinct interrupt type, indexed by a small integer (the interrupt number). The instant interrupt number N occurs, the CPU reads entry N of this table and jumps directly to the address stored there — a constant-time lookup no matter how many different kinds of interrupt the system supports. This design is deliberately uniform across operating systems precisely so that dispatch stays fast regardless of how much functionality is layered on top of it.

A simplified interrupt vector table

Vector 0 Timer ISR

Vector 1 Keyboard ISR

Vector 14 Disk ISR

Vector 0x80 System-call gate

Alongside the interrupt number, the hardware also preserves enough context to resume afterward — typically the address of the instruction that was executing when the interrupt arrived, pushed onto a stack (or saved in dedicated registers) before control transfers to the handler, so that once the handler finishes, execution can continue exactly where it was interrupted.

Software Interrupts (Traps) vs. Hardware Interrupts¶

Not every interrupt comes from a physical device. It is useful to split interrupts into two sources:

A hardware interrupt is an electrical signal from a device controller, a timer chip, or similar hardware, arriving asynchronously — completely independent of whatever instruction the CPU happens to be executing at that moment.
A software interrupt, usually called a trap, is generated synchronously by the currently running program itself, through a dedicated trap instruction. Traps come in two distinct flavors: a deliberate request for a kernel service (a system call — "please do this on my behalf") or an error condition the hardware detects while executing an instruction, such as division by zero, an invalid memory reference, or an attempt to execute a privileged instruction from user mode.

Either way, the underlying mechanism is identical to a hardware interrupt: the CPU halts its normal instruction flow, switches to kernel mode, and transfers control to a handler found through the very same interrupt vector — the source of the interrupt differs, but the hardware's response to it does not.

Every trap is software-sourced — not every trap is a system call

It's easy to assume "trap" always means "the program asked the kernel for something." Plenty of traps are the opposite: the hardware itself caught the program doing something illegal (dividing by zero, touching memory it doesn't own) and forced a trap on the program, not for it. Both are traps; only one is a system call.

Types of Interrupts¶

Putting the pieces together, four categories account for almost every interrupt an OS has to service:

Interrupt type	Raised by	Typical example	Synchronous?
I/O completion	A device controller	A disk read finishes; a network packet arrives	Asynchronous (hardware)
Timer	A hardware clock, ticking at a fixed interval	The scheduler's quantum expires, forcing a context switch	Asynchronous (hardware)
Program error / trap	The CPU itself, detecting a fault during execution	Divide-by-zero; illegal memory reference; privileged instruction attempted in user mode	Synchronous (software)
System call	The running program, deliberately	A program calls `read()` and needs the kernel to perform it	Synchronous (software)

The timer interrupt deserves special attention: it is what makes preemptive multitasking possible at all. Without a periodic, unavoidable timer interrupt forcing the OS back into control, a process that never performs I/O and never voluntarily yields the CPU could simply run forever, starving every other process on the system.

Connecting this back to Lecture 1

Lecture 1's dual-mode execution model and this lecture's interrupt types are two halves of the same story: an interrupt (of any of the four kinds above) is precisely the event that flips the hardware's mode bit back to kernel mode, which is how the OS regains control from a running user program in the first place.

Key Takeaways¶

Five computing environments — traditional, mobile, client-server, peer-to-peer, and cloud (public, private, or hybrid, built on virtualization) — cover most of where software runs today, and real systems routinely combine several at once.
Interrupt-driven operation replaces wasteful polling: devices signal the CPU when ready, instead of the CPU repeatedly checking them, which is what frees the CPU to do other work in the meantime.
The interrupt vector table gives the CPU constant-time dispatch to the correct handler, indexed by interrupt number.
Hardware interrupts arrive asynchronously from devices; software interrupts (traps) are synchronous and software-generated — either a deliberate system call or a hardware- detected program error.
The four main interrupt categories — I/O completion, timer, program error, and system call — together explain almost everything that forces the CPU out of whatever it was doing and back into the OS's hands.

Next: Lecture 3 — Operating System Services and Interfaces.