/wiki / io

cpu

2026-09-02T00:00:00.000Z

The Problem

Auto-created stub for broken link [[cpu]] — needs human content.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation.

How It Works

To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example

Connections

Related: Index — auto stub, needs proper links

Edge Cases & Gotchas

To be written.

critical-section

2026-09-02T00:00:00.000Z

The Problem

Auto-created stub for broken link [[critical-section]] — needs human content.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation.

How It Works

To be written.

Visual Explanation

digraph critical-section {
  rankdir=LR
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica"]
  A [label="Stub: critical-section"]
  B [label="To be written"]
  A -> B [label="needs content"]
}

Semantic Network

graph semantic_critical-section {
  layout=neato
  node [shape=ellipse fontname="Helvetica" fontsize=11 style=filled]
  THIS [label="critical section" fillcolor="#ffd700" fontsize=13 style="filled,bold"]
  REL1 [label="Related" fillcolor="#f0f0f0"]
  THIS -- REL1 [label="related"]
}

Key Properties

To be written.

Real-World Example

# TODO: add example

Connections

Related: Index — auto stub, needs proper links

Edge Cases & Gotchas

To be written.

Io — Map of Content

2026-09-02T00:00:00.000Z

Map of Content for Io — 54 concepts. Start here to navigate io.

Core Concepts

Binary Semaphore — concept
Block Driver — concept
Buffering — concept
Character Driver — concept
C-LOOK — concept
Collision Resolution — concept
Counting Semaphore — concept
C-SCAN — concept
Demand Paging — concept
Device Controller — concept
Device Driver — concept
O Software — concept
Disk Management — concept
disk-scheduling-compared — concept
Disk Scheduling — concept
Disk Structure — concept
DMA — concept
Double Hashing — concept
FCFS — concept
Hash Function — concept
Hashing — concept
hashing-performance — concept
Interrupt Handler — concept
O Devices — concept
O Request to Hardware Operation — concept
O Software Structure — concept
O System — concept
Linear Probing — concept
Load Factor — concept
LOOK Scheduling — concept
Network Driver — concept
Page Fault — concept
Page Table — concept
Paging — concept
paging-vs-segmentation — concept
Polling — concept
Producer-Consumer Problem — concept
Quadratic Probing — concept
RAID — concept
Reader-Writer Problem — concept
SCAN Scheduling — concept
Segmentation — concept
Semaphore — concept
semaphore-types — concept
Separate Chaining — concept
signal Operation — concept
SSTF — concept
Swap Space — concept
System Bus — concept
Thrashing — concept
TLB — concept
O Software — concept
Virtual Memory — concept
wait Operation — concept

Mechanisms & How Things Work

Auto-generated — edit to curate. Pages that explain processes/flows.

Comparisons & Tradeoffs

(No synthesis yet — create via ingest or query —save)

memory

2026-09-02T00:00:00.000Z

The Problem

Auto-created stub for broken link [[memory]] — needs human content.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation.

How It Works

To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example

Connections

Related: Index — auto stub, needs proper links

Edge Cases & Gotchas

To be written.

mutex

2026-09-02T00:00:00.000Z

The Problem

Auto-created stub for broken link [[mutex]] — needs human content.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation.

How It Works

To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example

Connections

Related: Index — auto stub, needs proper links

Edge Cases & Gotchas

To be written.

race-condition

2026-09-02T00:00:00.000Z

The Problem

Auto-created stub for broken link [[race-condition]] — needs human content.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation.

How It Works

To be written.

Visual Explanation

digraph race-condition {
  rankdir=LR
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica"]
  A [label="Stub: race-condition"]
  B [label="To be written"]
  A -> B [label="needs content"]
}

Semantic Network

graph semantic_race-condition {
  layout=neato
  node [shape=ellipse fontname="Helvetica" fontsize=11 style=filled]
  THIS [label="race condition" fillcolor="#ffd700" fontsize=13 style="filled,bold"]
  REL1 [label="Related" fillcolor="#f0f0f0"]
  THIS -- REL1 [label="related"]
}

Key Properties

To be written.

Real-World Example

# TODO: add example

Connections

Related: Index — auto stub, needs proper links

Edge Cases & Gotchas

To be written.

segment-table

2026-09-02T00:00:00.000Z

The Problem

Auto-created stub for broken link [[segment-table]] — needs human content.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation.

How It Works

To be written.

Visual Explanation

digraph segment-table {
  rankdir=LR
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica"]
  A [label="Stub: segment-table"]
  B [label="To be written"]
  A -> B [label="needs content"]
}

Semantic Network

graph semantic_segment-table {
  layout=neato
  node [shape=ellipse fontname="Helvetica" fontsize=11 style=filled]
  THIS [label="segment table" fillcolor="#ffd700" fontsize=13 style="filled,bold"]
  REL1 [label="Related" fillcolor="#f0f0f0"]
  THIS -- REL1 [label="related"]
}

Key Properties

To be written.

Real-World Example

# TODO: add example

Connections

Related: Index — auto stub, needs proper links

Edge Cases & Gotchas

To be written.

binary-semaphore

2026-04-30T00:00:00.000Z

The Problem

When only one process can access a shared resource at a time (mutual exclusion), we need a semaphore with only two states: locked and unlocked.

Core Idea

A binary semaphore can only take values 0 (locked) and 1 (unlocked), used for mutual exclusion of critical sections.

How It Works

Initialize semaphore to 1 (unlocked)
Process enters critical section: wait(S) → S becomes 0 (locked)
Other processes calling wait(S) block (S becomes negative)
Process exits: signal(S) → S becomes 1 (unlocked), wake up one waiter

Key Properties

Only two values: 0 (locked) and 1 (unlocked)
Provides mutual exclusion (mutex)
Initialized to 1 for mutex use
Can be used as a lock/mutex

Connections

Built from: Semaphore, Critical Section
Builds into: Mutex, Race Condition
Related: Counting Semaphore
Contrasts with: Counting Semaphore (one bit vs N values)

Edge Cases & Gotchas

Busy-waiting implementation wastes CPU (better to block/sleep)
Must be acquired and released by same process
Forgetting signal() causes deadlock

block-driver

2026-04-30T00:00:00.000Z

The Problem

Block devices (disks, SSDs) transfer data in fixed-size blocks and support seeking to arbitrary positions. The OS needs a driver type that understands block addressing and buffering.

Core Idea

A block driver handles block-oriented devices, managing block-sized data transfers (typically 512B or 4KB), supporting random access and buffering.

How It Works

OS sends block read/write request (block number, count)
Driver translates block number to disk address (cylinder, head, sector)
Driver sets up DMA for bulk data transfer
Driver handles completion interrupt
Driver may do elevator sorting (disk scheduling) for multiple requests

Key Properties

Transfers fixed-size blocks (512B, 4KB typical)
Supports random access (seek to any block)
Uses buffering/caching heavily (buffers are block-sized)
Examples: hard disk driver, SSD driver, USB mass storage

Connections

Built from: Device Driver, O Devices
Builds into: Disk Structure, Disk Scheduling
Related: Character Driver, DMA, Buffering
Contrasts with: Network Driver (packet-based, not block-based)

Edge Cases & Gotchas

Block size must match device’s physical block size (or be properly translated)
Misaligned block accesses hurt performance on some devices
Some “block” devices are actually flash-backed and have different characteristics

buffering

2026-04-30T00:00:00.000Z

The Problem

Devices operate at different speeds (CPU is fast, disk is slow, keyboard is very slow). Data transfer between them needs temporary storage to bridge the speed gap.

Core Idea

Buffering is the use of temporary storage (in memory) to hold data while it’s being transferred between devices or between a device and an application.

How It Works

Data from slow device stored in buffer (memory)
Fast device/CPU can read from buffer at its own speed
Buffer decouples producer and consumer of data
Can be single buffer, double buffer, or circular buffer

Key Properties

Decouples speed differences between devices
Can be single, double, or circular buffer
Block devices use buffer cache (disk blocks)
Character devices use line buffers or raw mode

Connections

Built from: O System, O Software
Builds into: O Request to Hardware Operation
Related: Device Driver, DMA
Contrasts with: No Buffering (unbuffered I/O is slow)

Edge Cases & Gotchas

Buffer overflow if consumer too slow
Buffer too small = frequent I/O operations
Buffer too large = wasted memory

c-look

2026-04-30T00:00:00.000Z

The Problem

C-SCAN wastes time on the return jump (no service), and always goes to disk end. Can we combine C-SCAN and LOOK?

Core Idea

C-LOOK combines C-SCAN (one direction only) with LOOK (stop at last request), giving uniform wait times without unnecessary travel.

How It Works

Move in one direction, service requests
Stop at last request (don’t go to disk end)
Jump back to first request
Continue in same direction (circular)

Key Properties

Uniform wait times (like C-SCAN)
No unnecessary travel to disk end (like LOOK)
Most efficient of the SCAN family
Default in many modern systems

Connections

Built from: Disk Scheduling, C-SCAN, LOOK
Related: SCAN
Contrasts with: C-SCAN (stops at last request vs goes to end)

Edge Cases & Gotchas

Needs to track first and last request
Most practical for real-world workloads
Often the default disk scheduler

c-scan

2026-04-30T00:00:00.000Z

The Problem

SCAN has uneven wait times — requests just passed when the arm reverses have to wait a full cycle. Can we make wait times more uniform?

Core Idea

C-SCAN (Circular SCAN) services requests in one direction only, then jumps back to the beginning without servicing requests on the return trip.

How It Works

Move disk arm in one direction (e.g., inward)
Service all requests in that direction
When reaching end, jump back to start
Continue in same direction (no reverse)
Circular — never reverses direction

Key Properties

More uniform wait times than SCAN
No reversal = simpler logic
Wastes time on return jump (no service)
Better for systems needing predictable latency

Connections

Built from: Disk Scheduling, SCAN
Builds into: LOOK, C-LOOK
Related: Disk Structure
Contrasts with: SCAN (one direction vs reverse)

Edge Cases & Gotchas

Return jump wastes time (no requests serviced)
Still may not be optimal for all workloads
Good for real-time systems (predictable)

character-driver

2026-04-30T00:00:00.000Z

The Problem

Character devices (keyboard, mouse, serial port) transfer data as a stream of bytes, one at a time, with no random access. The driver must handle sequential, unbuffered transfers.

Core Idea

A character driver handles byte-stream devices, managing sequential data transfer one character/byte at a time, without seeking or block structure.

How It Works

OS sends read/write request for character data
Driver reads/writes bytes sequentially from device
Typically uses small buffers (one character or small FIFO)
Interrupt per character (or small group) is common
No seeking — data is a sequential stream

Key Properties

Transfers one byte or small buffers at a time
No seeking — sequential access only
Examples: keyboard, mouse, serial port, printer
Often uses interrupts per character (can be high overhead)

Connections

Built from: Device Driver, O Devices
Builds into: O Software Structure
Related: Block Driver, Interrupt Handler
Contrasts with: Block Driver (random access vs sequential)

Edge Cases & Gotchas

High interrupt rate for fast character streams (use FIFO buffers)
Some character devices support limited “seek” (e.g., tape drives)
Character devices don’t support memory-mapped I/O typically

collision-resolution

2026-04-30T00:00:00.000Z

The Problem

Two different keys may hash to the same index (collision). The hash table needs a strategy to store both values at the same index.

Core Idea

Collision resolution techniques handle cases where multiple keys map to the same hash table index, using either chaining (linked lists) or probing (search for next available slot).

How It Works

Two main approaches:

1. Separate Chaining: Each index has a linked list of all key-value pairs that hashed there 2. Open Addressing (Probing): Find another empty slot using a probe sequence

Key Properties

Separate Chaining: Simple, performance degrades with long chains
Linear Probing: Fast when table isn’t full, but causes clustering
Quadratic Probing: Reduces clustering, but may not probe all slots
Double Hashing: Uses second hash function, best open addressing method

Connections

Built from: Hashing, Hash Function
Builds into: Separate Chaining, Linear Probing
Related: Double Hashing, Quadratic Probing
Contrasts with: Hash Function (prevents vs handles collisions)

Edge Cases & Gotchas

Long chains in chaining → degrades to O(n) search
Clustering in probing → many consecutive occupied slots
Deletion in open addressing is tricky (can’t just remove, need tombstones)
Load factor > 0.7 → performance drops sharply

counting-semaphore

2026-04-30T00:00:00.000Z

The Problem

Some resources have multiple identical instances (e.g., 3 printers, 5 buffer slots). Binary semaphore can’t handle this — we need to track how many instances are available.

Core Idea

A counting semaphore can take values 0 to N, where N is the number of available resources in the pool.

How It Works

Initialize semaphore to N (number of available resources)
Process requests resource: wait(S) → S—
If S becomes negative, process blocks (no resources available)
Process releases: signal(S) → S++, wake up a blocked process

Key Properties

Value range: 0 to N (N = resource count)
Used for resource management (buffer slots, printer pool)
Negative value = number of blocked processes
Classic use: producer-consumer bounded buffer

Connections

Built from: Semaphore, Producer-Consumer Problem
Builds into: Reader-Writer Problem
Related: Binary Semaphore
Contrasts with: Mutex (mutex is just binary semaphore)

Edge Cases & Gotchas

Initializing to wrong N causes resource leaks or errors
Must ensure signal() is called exactly once per wait()
Priority inversion can happen with multiple priority levels

demand-paging

2026-04-30T00:00:00.000Z

The Problem

Loading an entire process into RAM at startup is wasteful — many pages may never be used. We need a way to load pages only when they’re actually needed.

Core Idea

Demand paging loads pages from disk only when they are first accessed (on-demand), reducing RAM usage and startup time.

How It Works

Process starts, page table marked with all pages “not present”
Process runs, accesses first page → page fault
OS loads that page from disk into RAM
Subsequent accesses hit RAM (no fault)
If RAM is full, evicts a page (LRU, FIFO, etc.)

Key Properties

Lazy loading: pages loaded only when needed
Reduces initial RAM usage
First access is slow (disk read), subsequent fast
Basis for virtual memory systems

Connections

Built from: Paging, Page Fault
Builds into: Virtual Memory, Thrashing
Related: Swap Space, Page Replacement
Contrasts with: Prepaging (load pages before needed)

Edge Cases & Gotchas

Too many page faults = thrashing
Page fault handling overhead (~1ms for disk read)
Critical processes may need pages locked in RAM (mlock)

device-controller

2026-04-30T00:00:00.000Z

The Problem

The CPU cannot directly manipulate hardware signals (move disk arm, read magnetic flux). It needs a hardware intermediary that understands both the CPU’s bus interface and the device’s physical interface.

Core Idea

A device controller is a hardware component that interfaces between the system bus and the physical I/O device, containing registers for commands, data, and status, plus local buffers for data transfer.

How It Works

CPU (via driver) writes commands and parameters to controller’s registers
Controller parses registers to determine operation (read/write/seek)
Controller executes operation on the physical device
Data transfers to/from controller’s local buffer
Controller raises interrupt when operation completes
CPU reads status register to check success/failure

Key Properties

Contains three types of registers: control, data, and status
Has local buffer to hold data during transfer
Can operate asynchronously from CPU (using DMA)
Sits on the system bus, addressed like memory (memory-mapped I/O)

Connections

Built from: System Bus, O System
Builds into: O Request to Hardware Operation
Related: Device Driver, DMA, Interrupt Handler
Contrasts with: Device Driver (software vs hardware)

Edge Cases & Gotchas

Register addresses vary by device — driver must know the correct addresses
Local buffer size limits transfer size per operation
Status register must be read before another command is issued
Some controllers have buggy implementations causing race conditions

device-driver

2026-04-30T00:00:00.000Z

The Problem

Each hardware device has unique control mechanisms, register layouts, and command sets. The OS cannot contain code for every possible device — it would be enormous and impossible to maintain.

Core Idea

A device driver is a software module that translates generic OS I/O commands into device-specific instructions, acting as the intermediary between the OS and hardware.

How It Works

OS sends a generic I/O request (e.g., “read sector 120”) to the driver
Driver translates this into device-specific commands and register writes
Driver writes commands to the device controller’s registers
Driver may set up DMA transfers or prepare for interrupt notification
On completion, driver processes the interrupt and updates OS state

Key Properties

Runs in kernel mode with privileged access
Device-specific but presents uniform interface to OS
Handles device initialization, error detection, and status reporting
Four main types: character, block, network, and virtual drivers

Connections

Built from: O System, Device Controller
Builds into: O Request to Hardware Operation, O Software Structure
Related: Character Driver, Block Driver, Network Driver
Contrasts with: O Software (lives in user space, not kernel)

Edge Cases & Gotchas

A buggy driver can cause kernel panics or system crashes
Driver must handle concurrent requests properly (reentrant code)
Missing drivers result in “unknown device” errors
Driver version must match kernel version exactly

device-independent-io-software

2026-04-30T00:00:00.000Z

The Problem

Different devices have different characteristics (block vs character, seekable vs sequential), but applications want a uniform interface. The OS needs a layer that handles common I/O concerns regardless of device type.

Core Idea

The I/O software layer that provides a uniform interface to user-level software, handling device naming, protection, buffering, and error reporting independent of specific hardware.

How It Works

Receives I/O request from user-level software
Identifies which device to use based on file/device name
Manages buffering and caching for efficiency
Handles device allocation/deallocation (e.g., exclusive printer access)
Reports errors in a consistent way
Passes request to the appropriate device driver

Key Properties

Makes all devices look the same to upper layers
Handles naming (/dev/sda, COM1, etc.)
Manages buffer cache for block devices
Enforces access control (permissions)

Connections

Built from: O Software Structure, O Software
Builds into: O Request to Hardware Operation
Related: O System, Device Driver, Buffering
Contrasts with: Interrupt Handler (lower layer, device-specific events)

Edge Cases & Gotchas

Buffer cache size affects performance — too small means frequent disk reads
Error reporting must be consistent across device types
Device naming conventions vary by OS (Linux vs Windows)

disk-management

2026-04-30T00:00:00.000Z

The Problem

A raw disk is just a collection of sectors — the OS needs to organize it into usable storage: divide it into partitions, create file systems, and handle errors.

Core Idea

Disk management encompasses partitioning (dividing disks), formatting (creating file systems), and error handling (bad block management).

How It Works

Partitioning: Divide disk into logical sections, each can have different file system
Formatting: Create file system structures (superblock, inodes, bitmaps)
Bad Block Management: Detect and remap damaged sectors
Free Space Management: Track unused sectors for new allocations

Key Properties

Partition table types: MBR (old, 2TB limit) vs GPT (modern, no practical limit)
Formatting writes file system metadata (superblock, inode tables)
Bad blocks detected at format time or during runtime
File system choice affects performance and features

Connections

Built from: Disk Structure, Disk Scheduling
Builds into: Swap Space, RAID
Related: Partitioning, Formatting, Bb Block Management
Contrasts with: O System (higher-level abstraction)

Edge Cases & Gotchas

Formatting erases all data — always backup first
Some file systems (ZFS) do their own bad block management
Partition alignment matters for SSD performance (4K alignment)

Disk Scheduling Algorithms — Performance and Trade-offs

2026-04-30T00:00:00.000Z

Framing

Compare disk scheduling algorithms — FCFS, SSTF, SCAN, C-SCAN, LOOK, and C-LOOK — analyzing seek time reduction, fairness, and practical performance.

Comparison

Algorithm	Avg Seek	Starvation	Wait Time Uniformity	Notes
FCFS	Worst	No	Poor	Simple, fair, but slow
SSTF	Better	Yes (edge tracks)	Poor	Greedy, may starve
SCAN	Good	No	Medium	Elevator, reverses at end
C-SCAN	Good	No	Better	One direction only
LOOK	Good	No	Medium	Stops at last request
C-LOOK	Good	No	Best	One direction, stops at last

Key Insights

FCFS is fair but slow — no optimization, serves as baseline
SSTF minimizes seek but can starve requests at disk edges (greedy = not globally optimal)
SCAN (elevator) eliminates starvation by sweeping back and forth, like an elevator serving floors
C-SCAN improves uniformity — always goes in one direction, jumps back (no service on return)
LOOK is practical SCAN — doesn’t go to physical disk end if no requests there
C-LOOK is best practical — combines C-SCAN uniformity with LOOK efficiency

Synthesis

Modern systems typically use LOOK or C-LOOK (often called “deadline” or “noop” schedulers). The SCAN family beats FCFS and SSTF by eliminating starvation while maintaining good performance. Modern disks also do internal scheduling (NCQ) that may override OS scheduling.

Connections

Disk Scheduling — overview of all algorithms
FCFS — first come first serve
SSTF — shortest seek time first
SCAN — elevator algorithm
C-SCAN — circular SCAN
LOOK — SCAN variant
C-LOOK — C-SCAN variant
Disk Structure — why seek time matters

disk-scheduling

2026-04-30T00:00:00.000Z

The Problem

Disk access is slow (milliseconds) compared to CPU/RAM (nanoseconds). The mechanical seek time (moving the disk arm) dominates. With multiple I/O requests, the order of servicing them greatly affects performance.

Core Idea

Disk scheduling algorithms decide the order to service pending I/O requests to minimize seek time and improve throughput.

How It Works

Common algorithms:

FCFS: Process requests in arrival order (simple, but can be slow)
SSTF: Pick closest request first (minimizes seek, but may starve)
SCAN (Elevator): Move in one direction, service requests, reverse at end
C-SCAN: Like SCAN but only services in one direction, jumps back
LOOK/C-LOOK: Like SCAN/C-SCAN but stops at last request (not end of disk)

Key Properties

SSTF reduces average seek but can starve distant requests
SCAN gives uniform wait times (like elevator algorithm)
C-SCAN provides more uniform wait than SCAN
LOOK is more efficient (doesn’t go to disk end unnecessarily)

Connections

Built from: Disk Structure, O System
Builds into: Disk Management
Related: FCFS, SSTF, SCAN, C-SCAN
Contrasts with: Swap Space (different disk usage pattern)

Edge Cases & Gotchas

SSTF can cause starvation for requests at disk edges
Request merging (adjacent sectors) can improve throughput
Modern disks do their own scheduling (NCQ) — OS scheduling may be ignored

disk-structure

2026-04-30T00:00:00.000Z

The Problem

Data on a hard disk isn’t stored as a linear sequence — it’s physically organized on spinning platters with magnetic surfaces. The OS needs to understand this geometry to efficiently locate and access data.

Core Idea

A hard disk consists of platters, tracks, sectors, cylinders, and read/write heads — the physical organization that determines how data is addressed and accessed.

How It Works

A hard disk is organized as:

Platters: Circular magnetic disks stacked on a spindle
Tracks: Concentric rings on each platter surface
Sectors: Smallest storage unit on a track (typically 512B or 4KB)
Cylinder: Set of aligned tracks across all platters
Read/Write Head: Moves across platters to access data
Disk Arm: Moves heads to the correct track

Key Properties

Data addressed by CHS: Cylinder, Head, Sector
Access time = seek time + rotational delay + transfer time
Tracks are numbered from outer (0) to inner
Multiple platters increase capacity without increasing form factor

Connections

Built from: O Devices, Block Driver
Builds into: Disk Scheduling, Disk Management
Related: Cylinder, Track, Sector
Contrasts with: SSD (no moving parts, different structure)

Edge Cases & Gotchas

Sectors aren’t always 512B — modern disks use 4KB physical sectors
Zone bit recording: outer tracks have more sectors than inner tracks
Bad sectors must be remapped (handled by disk firmware)

dma

2026-04-30T00:00:00.000Z

The Problem

In normal I/O, the CPU must transfer each byte/word between device and memory. For large transfers (disk reads, network packets), this wastes CPU cycles on simple copy operations.

Core Idea

DMA allows I/O devices to transfer data directly to/from memory without CPU intervention, freeing the CPU for other tasks during data transfer.

How It Works

CPU programs the DMA controller: memory address, transfer size, direction (read/write)
DMA controller takes control of the system bus
Device transfers data directly to/from memory via DMA
DMA controller increments address and decrements count for each transfer
When transfer completes, DMA raises an interrupt to notify CPU

Key Properties

Transfers data at memory bus speeds (very fast)
CPU is free during transfer (can run other processes)
Requires DMA controller hardware (additional cost)
Best for high-speed, large block transfers

Connections

Built from: O System, System Bus, Device Controller
Builds into: O Request to Hardware Operation
Related: Polling, Interrupt Handler
Contrasts with: O Software (CPU still involved in non-DMA I/O)

Edge Cases & Gotchas

DMA and CPU both need system bus — bus arbitration required
Wrong DMA setup (bad address/size) can corrupt memory
Some systems have limited DMA channels (resource contention)
Cache coherency issues — CPU cache may not see DMA-written data

double-hashing

2026-04-30T00:00:00.000Z

The Problem

Quadratic probing still has secondary clustering (keys with same initial hash follow same probe sequence). We need a way to give each key a unique probe sequence.

Core Idea

Double hashing uses two hash functions: the second hash determines the step size for probing, giving each key a unique probe sequence.

How It Works

Compute h₁(k) = initial position
Compute h₂(k) = step size (must be non-zero)
Probe sequence: h₁(k), h₁(k)+h₂(k), h₁(k)+2h₂(k), …
Each key has different step size → different probe sequence

Key Properties

Best open addressing method (least clustering)
Probes all slots if table size is prime and h₂(k) is non-zero
More computation (two hash functions)
Step size must be non-zero and relatively prime to table size

Connections

Built from: Hashing, Hash Function
Builds into: Collision Resolution
Related: Linear Probing, Quadratic Probing
Contrasts with: Quadratic Probing (two hashes vs one quadratic)

Edge Cases & Gotchas

h₂(k) must never be 0 (would infinite loop)
Table size should be prime for complete coverage
Most complex to implement of the three probing methods

fcfs

2026-04-30T00:00:00.000Z

The Problem

When multiple I/O requests arrive for disk access, we need a simple, fair way to decide the order of servicing them.

Core Idea

FCFS (First Come First Serve) processes disk I/O requests in the exact order they arrive, like a queue at a store.

How It Works

Request queue maintains arrival order
Disk arm services requests in FIFO order
No reordering or optimization

Key Properties

Simplest disk scheduling algorithm
Fair (no starvation)
Can be very inefficient (long seek times)
Example: queue [100, 50, 150, 30] → services in that order

Connections

Built from: Disk Scheduling, Disk Structure
Builds into: SSTF, SCAN
Related: Disk Structure
Contrasts with: SSTF (optimizes vs simple FIFO)

Edge Cases & Gotchas

Can cause wild swings across disk (poor performance)
No consideration of seek distance
Simple but often impractical for real systems

hash-function

2026-04-30T00:00:00.000Z

The Problem

We need a deterministic way to convert arbitrary-sized keys (strings, numbers) into fixed-size array indices for O(1) lookup.

Core Idea

A hash function maps keys to integer values (array indices) such that equal keys always produce the same hash value, and the distribution is as uniform as possible.

How It Works

Take input key (string, number, object)
Apply mathematical transformation (e.g., modulo, multiplication, bit shifting)
Output is an integer in range [0, table_size-1]
Good hash functions minimize collisions

Key Properties

Deterministic: same key → same hash always
Uniform distribution minimizes collisions
Fast to compute (shouldn’t be slower than the data structure it serves)
Examples: division method, multiplication method, universal hashing

Connections

Built from: Hashing
Builds into: Separate Chaining, Linear Probing
Related: Collision Resolution, Load Factor
Contrasts with: Random Number Generator (hash is deterministic, not random)

Edge Cases & Gotchas

Poor hash functions cause clustering (many collisions)
String hashing must handle variable lengths
Cryptographic hash functions are overkill for hash tables (too slow)
Changing hash function requires rehashing entire table

Hashing Performance — Collision Resolution Techniques Compared

2026-04-30T00:00:00.000Z

Framing

Compare four collision resolution techniques for hash tables: separate chaining, linear probing, quadratic probing, and double hashing — analyzing their performance, clustering behavior, and practical trade-offs.

Comparison

Technique	Best Case	Average Case	Worst Case	Clustering	Deletion
Separate Chaining	O(1)	O(1)	O(n)	None	Easy
Linear Probing	O(1)	O(1)	O(n)	Primary clustering	Tombstones
Quadratic Probing	O(1)	O(1)	O(n)	Secondary clustering	Tombstones
Double Hashing	O(1)	O(1)	O(n)	Minimal	Tombstones

Key Insights

Separate chaining is simplest — each slot has a linked list; performance depends on chain length (load factor α)
Linear probing causes primary clustering — long runs of occupied slots form, increasing probe lengths
Quadratic probing reduces primary clustering but causes secondary clustering (same initial hash = same probe sequence)
Double hashing is best — different step size per key eliminates most clustering, probes all slots if table size is prime
Load factor α ≤ 0.7 is critical — all methods degrade rapidly above this threshold
Open addressing (probing) uses less memory (no linked list pointers) but requires more careful load factor management

Synthesis

The choice depends on use case: separate chaining for simplicity and easy deletion; double hashing for best theoretical performance; linear probing only for very low load factors. All methods require good hash functions and load factor monitoring.

Connections

Hashing — the fundamental technique
Separate Chaining — linked lists at each slot
Linear Probing — probe next slot
Quadratic Probing — probe with i² skip
Double Hashing — two hash functions
Load Factor — critical for all methods
Hash Function — quality affects all methods

hashing

2026-04-30T00:00:00.000Z

The Problem

Searching an array or list takes O(n) time. For large datasets, we need O(1) average-case lookup by “scattering” data to computed positions.

Core Idea

Hashing uses a hash function to map keys to array indices, providing O(1) average-case insert, search, and delete operations.

How It Works

Hash function computes index: hash(key) % table_size
Key-value pair is stored at that index
To search: compute hash of key, go directly to index
Collisions (two keys → same index) handled by collision resolution

Key Properties

Best/average case: O(1) for insert, search, delete
Worst case: O(n) when all keys collide
Performance depends on hash function quality and load factor
Load factor α = elements / table_size (keep α ≤ 0.7)

Connections

Built from: Hash Function, Collision Resolution
Builds into: Separate Chaining, Linear Probing
Related: Load Factor, Double Hashing
Contrasts with: Binary Search Tree (O(log n) vs average O(1))

Edge Cases & Gotchas

Bad hash function causes many collisions → degrades to O(n)
High load factor (>0.7) dramatically increases collisions
Rehashing needed when table gets too full
Worst case: all keys hash to same index

interrupt-handler

2026-04-30T00:00:00.000Z

The Problem

If the CPU polls devices (checks repeatedly if they’re done), it wastes cycles when devices are slow. The CPU should be free to do other work while waiting for I/O, and only handle the device when it’s actually ready.

Core Idea

A special function that executes when a device raises an interrupt, allowing the CPU to respond asynchronously to I/O completion without busy-waiting.

How It Works

Device completes operation and raises an interrupt signal on the control bus
CPU pauses current work, saves context (registers, program counter)
CPU jumps to the interrupt handler (addressed by interrupt vector)
Handler reads device status register to confirm completion
Handler copies data from device buffer to memory (or vice versa)
Handler wakes up any process waiting for this I/O
CPU restores context and resumes previous work

Key Properties

Runs in kernel mode with high priority
Must execute quickly (other interrupts may be masked)
Can’t block or sleep (would hang the system)
Shares data with the interrupted process via kernel structures

Connections

Built from: O Software Structure, Device Controller
Builds into: O Request to Hardware Operation
Related: O System, Polling, DMA
Contrasts with: O Software (runs in user space, not in interrupt context)

Edge Cases & Gotchas

Interrupt handlers can’t allocate memory or sleep (leads to deadlock)
Nested interrupts require careful stack management
Lost interrupts (device interrupts before handler is registered) cause hangs
Interrupt storms (too many rapid interrupts) can freeze the system

io-devices

2026-04-30T00:00:00.000Z

The Problem

The CPU needs to interact with many different types of external hardware — keyboards, disks, printers, network cards — each with different speeds, data formats, and interfaces. The OS must classify and manage them appropriately.

Core Idea

I/O devices are classified by their function (input/output/storage/communication) and data transfer mode (block vs character vs stream), determining how the OS handles them.

How It Works

Devices are classified into:

By function: Input (keyboard), Output (monitor), Storage (disk), Communication (NIC)
By data transfer: Block devices (disk, fixed-size blocks), Character devices (keyboard, stream of bytes), Stream devices (audio/video)
By speed: Slow (keyboard), Medium (disk), Fast (GPU, network)

Key Properties

Block devices transfer fixed-size blocks (512B, 4KB), seekable
Character devices transfer bytes sequentially, not seekable
Speed varies from very slow (keyboard) to very fast (10GbE NIC)
Hybrid devices exist (touchscreen = input + output)

Connections

Built from: O System, Device Driver
Builds into: Block Driver, Character Driver, Network Driver
Related: Device Controller, System Bus
Contrasts with: CPU (computes, not I/O)

Edge Cases & Gotchas

Some devices are both input and output (touchscreen, modem)
Block devices may emulate character devices for certain operations
Device classification blurs with modern hardware (GPU does both compute and output)

io-request-to-hardware

2026-04-30T00:00:00.000Z

The Problem

When an application calls read("data.txt"), how does this high-level request end up causing a disk head to move and data to appear in memory? The journey from software request to hardware action is complex.

Core Idea

Transforming an I/O request into hardware operation is a multi-step process where the request flows down through I/O software layers, gets translated into hardware commands, executes on the device, and returns data via interrupts.

How It Works

Application calls fopen("data.txt", "r") or read(fd, buf, size)
OS checks file permissions, locates file on disk, allocates buffer
Device-Independent Layer determines which device and driver to use, handles buffering
Device Driver translates “read sector 120” into register writes for the disk controller
Device Controller executes: seeks to track, waits for sector, reads data
Interrupt signals completion; CPU processes interrupt, copies data to user buffer
Application resumes with data available

Key Properties

Each step adds appropriate abstraction or translation
DMA can bypass CPU involvement in data transfer (steps 5-6)
The process is asynchronous — application may block until interrupt arrives
File system layer maps logical file operations to physical disk blocks

Connections

Built from: O System, Device Driver, Device Controller
Builds into: DMA, Interrupt Handler
Related: O Software Structure, Polling, System Bus
Contrasts with: O Software (only handles step 1)

Edge Cases & Gotchas

Page fault can occur during copy to user buffer, complicating the flow
Disk may return errors (bad sector) that must be handled at each layer
Concurrent I/O requests require proper queue management
DMA setup failure falls back to programmed I/O (very slow)

io-software-structure

2026-04-30T00:00:00.000Z

The Problem

I/O operations involve many concerns: buffering, error handling, device-specific commands, interrupt processing. Putting all this in one place creates unmaintainable code and makes the OS dependent on hardware details.

Core Idea

I/O software is organized into four layers, each handling a specific abstraction level — from user-facing system calls down to hardware interrupt handling.

How It Works

The four layers (top to bottom):

User-Level I/O Software: System calls (read(), write(), fopen()), buffering in user space
Device-Independent OS Software: Naming, protection, buffering, caching, error reporting
Device Drivers: Translate generic requests to device-specific commands
Interrupt Handlers: Process device interrupts and signal completion

Key Properties

Each layer only communicates with adjacent layers
Device-independent layer makes all devices look uniform to applications
Drivers can be loaded/unloaded without changing the OS
Modularity enables portability across hardware platforms

Connections

Built from: O System, O Software
Builds into: O Request to Hardware Operation
Related: Device Driver, Interrupt Handler, O Software
Contrasts with: Device Controller (hardware, not software)

Edge Cases & Gotchas

Too many layers can impact performance due to context switches
Device-independent layer must know enough about devices to do buffering correctly
Error handling must propagate correctly up through all layers
Some devices bypass layers (e.g., memory-mapped I/O)

io-system

2026-04-30T00:00:00.000Z

The Problem

The CPU needs to communicate with external hardware devices (keyboards, disks, printers, network cards), but each device speaks a different “language” with different speeds, data formats, and control mechanisms. Without a unified system, every program would need device-specific code.

Core Idea

The I/O System is the OS subsystem that manages communication between the CPU and external devices, providing abstraction layers so applications can perform I/O without knowing hardware details.

How It Works

Applications make I/O requests via system calls (read(), write(), open())
The request flows through layered I/O software (user-level → device-independent → device driver → interrupt handler)
The device driver translates generic OS commands into device-specific instructions
The device controller executes the operation on the physical hardware
Completion is signaled via interrupt, and data is returned to the application

Key Properties

Provides uniform interface to diverse hardware through abstraction layers
Handles buffering, caching, and error reporting at device-independent layer
Uses interrupts to avoid CPU busy-waiting
Supports multiple I/O techniques: polling, interrupt-driven, DMA

Connections

Built from: System Bus, Device Driver, Interrupt Handler
Builds into: O Request to Hardware Operation, O Software Structure
Related: Device Controller, DMA, Polling
Contrasts with: O Software (one layer in the system)

Edge Cases & Gotchas

Device drivers run in kernel mode — a buggy driver can crash the entire OS
Interrupt storms can overwhelm the CPU if devices generate too many interrupts
Some devices don’t support interrupts and require polling
DMA conflicts can occur if the DMA controller isn’t properly programmed

linear-probing

2026-04-30T00:00:00.000Z

The Problem

In separate chaining, we need extra memory for linked lists. Can we store everything in the hash table array itself by finding the next empty slot?

Core Idea

On collision, linear probing checks the next slot (index+1, +2, …) until an empty slot is found, wrapping around to the beginning if needed.

How It Works

Hash key to get initial index
If slot is empty, insert there
If occupied, check next slot (index+1)
Continue until empty slot found (wrap around if needed)
Search: check slots sequentially until key found or empty slot

Key Properties

No extra memory for linked lists (all in array)
Causes primary clustering (consecutive occupied slots)
Probe sequence is: h(k), h(k)+1, h(k)+2, …
Deletion tricky: need tombstone markers

Connections

Built from: Hashing, Collision Resolution
Builds into: Quadratic Probing, Double Hashing
Related: Load Factor
Contrasts with: Separate Chaining (in-table vs chains)

Edge Cases & Gotchas

Primary clustering: long runs of occupied slots form
Performance drops sharply when load factor > 0.7
Deletion needs tombstones (can’t just clear slot)
Table must be resized when getting full

load-factor

2026-04-30T00:00:00.000Z

The Problem

How do we know when a hash table is “too full” and performance will degrade? We need a metric to decide when to resize.

Core Idea

Load factor (α) is the ratio of elements stored to the total table size: α = number_of_elements / table_size. It predicts hash table performance.

How It Works

Calculate α = n / m (n = elements, m = table size)
α ≤ 0.7: good performance, few collisions
α > 0.7: performance drops, consider resizing
α close to 1.0: many collisions, O(n) worst case likely

Key Properties

α = 0.0: empty table (wasted space)
α = 0.5-0.7: sweet spot for performance
α > 0.7: collisions increase sharply
α = 1.0: table full, must resize

Connections

Built from: Hashing, Hash Function
Builds into: Separate Chaining, Linear Probing
Related: Collision Resolution
Contrasts with: Big O Notation (load factor affects actual O(1) performance)

Edge Cases & Gotchas

Low load factor wastes memory (too many empty slots)
High load factor causes performance collapse
Resizing requires rehashing ALL elements (expensive)
Chaining tolerates higher load factors than probing

look-scheduling

2026-04-30T00:00:00.000Z

The Problem

SCAN goes all the way to the disk end even if there are no requests there, wasting time. Can we optimize this?

Core Idea

LOOK is a variant of SCAN that only goes as far as the last request in each direction, then reverses — doesn’t go to disk end unnecessarily.

How It Works

Move disk arm in current direction
Service requests along the way
When past the last request in that direction, reverse
Don’t go to physical disk end (unlike SCAN)

Key Properties

More efficient than SCAN (no unnecessary travel to disk end)
Still no starvation (like SCAN)
Only goes as far as the furthest request
C-LOOK is the C-SCAN version of LOOK

Connections

Built from: Disk Scheduling, SCAN
Builds into: C-LOOK
Related: C-SCAN
Contrasts with: SCAN (stops at last request vs goes to end)

Edge Cases & Gotchas

Must track the furthest request in each direction
Slightly more complex than SCAN
Default in many modern OSs

network-driver

2026-04-30T00:00:00.000Z

The Problem

Network devices transfer data in packets (variable-sized frames) and must handle addressing (MAC), protocol headers, and often checksum offloading. Standard block/character drivers don’t fit.

Core Idea

A network driver manages network interface cards (NICs), handling packet send/receive, DMA for packet buffers, and often hardware acceleration (checksum, TSO).

How It Works

OS passes packet (with headers) to driver for transmission
Driver sets up DMA descriptor for packet buffer
NIC DMAs packet from memory, adds PHY header, transmits
On receive, NIC DMAs packet to memory, raises interrupt
Driver passes packet up to network stack

Key Properties

Packet-based (variable size, unlike fixed blocks)
Often uses DMA rings (multiple packet buffers queued)
Hardware acceleration: checksum offload, TSO, RSS
Examples: Ethernet driver, Wi-Fi driver, InfiniBand driver

Connections

Built from: Device Driver, O Devices
Builds into: System Bus (connects to network)
Related: DMA, Interrupt Handler
Contrasts with: Block Driver (packets vs blocks)

Edge Cases & Gotchas

Packet drop under high load (driver must handle ring exhaustion)
DMA mapping must handle scattered packet buffers (SG DMA)
Some NICs have buggy offload features — may need disabling

page-fault

2026-04-30T00:00:00.000Z

The Problem

In paged virtual memory, a process may reference a page that isn’t currently in RAM. The CPU needs to know this page isn’t present so the OS can fetch it from disk.

Core Idea

A page fault occurs when a program accesses a page not loaded in RAM, triggering the OS to fetch the page from disk (swap space) into a free frame.

How It Works

CPU accesses a virtual address
MMU looks up page table, finds page not present (valid bit = 0)
CPU raises a page fault exception
OS checks if access is legal, finds free frame
OS schedules disk read to load page from swap
Page loaded, update page table, restart instruction

Key Properties

Minor page fault: page is in memory but not in process’s page table
Major page fault: page must be loaded from disk (slow!)
Too many page faults = thrashing (system slow)
Handled by OS, transparent to process

Connections

Built from: Paging, Page Table
Builds into: Demand Paging, Thrashing
Related: Swap Space, Virtual Memory
Contrasts with: Segmentation (different memory model)

Edge Cases & Gotchas

Invalid access (segfault) raises SIGSEGV, not page fault
Copy-on-write: page fault used to duplicate pages
Page fault handling is expensive (disk I/O)

page-table

2026-04-30T00:00:00.000Z

The Problem

In paging, processes use virtual (logical) addresses, but RAM uses physical addresses. The CPU needs to know which physical frame corresponds to each virtual page.

Core Idea

A page table is a data structure maintained by the OS that maps each virtual page of a process to its physical frame in RAM.

How It Works

CPU generates logical address: page number + page offset
Page number is used as index into page table
Page table entry gives frame number
Physical address = frame number × page size + offset

Key Properties

One page table per process
Stored in RAM (not in CPU registers — too large)
Accessed on every memory reference (needs caching → TLB)
Can be single-level, multi-level, or inverted

Connections

Built from: Paging, Virtual Memory
Builds into: TLB, Demand Paging
Related: Multi-Level Page Table, Inverted Page Table
Contrasts with: Segment Table (variable sizes vs fixed pages)

Edge Cases & Gotchas

Single-level page table can be huge (1M entries for 4GB process with 4KB pages)
Multi-level page tables add levels of indirection
Page table walks are slow (4 memory accesses for 4-level paging)

Paging vs Segmentation — Memory Management Compared

2026-04-30T00:00:00.000Z

Framing

Compare two memory management schemes: paging (fixed-size chunks) vs segmentation (variable-size logical units). Both enable virtual memory but with different trade-offs.

Comparison

Feature	Paging	Segmentation
Size	Fixed (e.g., 4KB pages)	Variable (code, data, stack)
Fragmentation	Internal (last page wasted)	External (gaps between segments)
Addressing	Page number + offset	Segment number + offset
Table	Page table (one per process)	Segment table (base + limit)
Sharing	Harder (page-granularity)	Easier (share entire segment)
Protection	Per-page bits	Per-segment (code=read/exec, data=rw)
Growth	Automatic (new pages)	Explicit (segment grow/shrink)

Key Insights

Paging eliminates external fragmentation but wastes space inside pages (internal fragmentation)
Segmentation matches program structure (code, data, stack are natural segments) but causes external fragmentation
Paging is transparent to the programmer; segmentation is visible (segment registers)
Modern OSs combine both: outer segmentation (for protection) with inner paging (for no external fragmentation) — this is called paged segmentation
x86 architecture uses paged segmentation: segment selector → linear address → page table → physical

Synthesis

No single scheme wins — paging solves fragmentation but loses program semantics; segmentation preserves semantics but fragments memory. The best systems (like modern x86) use both: segmentation for protection and logical structure, paging for efficient physical memory use.

Connections

Paging — fixed-size memory management
Segmentation — variable-size logical units
Page Table — used in paging
Segment Table — used in segmentation
Virtual Memory — both enable virtual memory
Internal Fragmentation — paging’s weakness
External Fragmentation — segmentation’s weakness

paging

2026-04-30T00:00:00.000Z

The Problem

Contiguous memory allocation requires a process to be loaded in one continuous block of RAM, causing external fragmentation (wasted gaps between processes). We need non-contiguous allocation.

Core Idea

Paging divides processes into fixed-size pages and RAM into page frames, allowing non-contiguous allocation and eliminating external fragmentation.

How It Works

Process is divided into pages (e.g., 4KB each)
RAM is divided into page frames of same size
Page table maps each page to a frame in RAM
CPU generates logical address = page number + offset
MMU uses page table to translate to physical address = frame number + offset

Key Properties

Eliminates external fragmentation (pages can be anywhere)
Fixed-size pages simplify allocation
Page table overhead per process
Internal fragmentation within pages (last page may not be full)

Connections

Built from: Virtual Memory, Page Table
Builds into: Page Fault, Demand Paging
Related: Segmentation, TLB
Contrasts with: Segmentation (fixed vs variable size)

Edge Cases & Gotchas

Internal fragmentation: last page partially filled wastes space
Page table size grows with process size (use multi-level page tables)
Every memory access needs page table lookup (slow → use TLB)

polling

2026-04-30T00:00:00.000Z

The Problem

Interrupts require hardware support and can be complex to handle. For simple systems or when a quick response is needed, there must be a simpler way for the CPU to check if a device is ready.

Core Idea

A technique where the CPU repeatedly checks (polls) a device’s status register in a loop until the device is ready or operation completes, instead of using interrupts.

How It Works

CPU writes command to device controller registers
CPU enters a loop: read status register repeatedly
If status indicates “busy” or “not ready”, keep looping
When status changes to “ready” or “complete”, proceed
Read/write data as needed

Key Properties

Simple to implement, no interrupt hardware needed
CPU is fully occupied during polling (can’t do other work)
Gives predictable timing for real-time systems
Wasteful for slow devices (CPU spins doing nothing)

Connections

Built from: O System, Device Controller
Builds into: Interrupt Handler (alternative to polling)
Related: DMA, O Request to Hardware Operation
Contrasts with: Interrupt Handler (event-driven vs poll-driven)

Edge Cases & Gotchas

Can waste enormous CPU cycles for slow devices
May miss events if polling interval is too long
Useful for small embedded systems without interrupt controllers
High throughput for bulk transfers (once polled, transfer quickly)

producer-consumer

2026-04-30T00:00:00.000Z

The Problem

A producer generates data and puts it into a buffer, while a consumer takes data from the buffer. The buffer has limited size — producer must wait if full, consumer must wait if empty.

Core Idea

A classic synchronization problem solved using three semaphores: empty (counts free slots), full (counts filled slots), and mutex (protects buffer access).

How It Works

Producer waits on empty semaphore (decrements)
Producer waits on mutex (enters critical section)
Producer adds item to buffer
Producer signals mutex (exits critical section)
Producer signals full (increments)
Consumer does the reverse

Key Properties

Uses 3 semaphores: empty (N), full (0), mutex (1)
Producer waits on empty, signals full
Consumer waits on full, signals empty
Mutex protects buffer data structure

Connections

Built from: Semaphore, Counting Semaphore
Builds into: Reader-Writer Problem
Related: Wait Operation, Signal Operation
Contrasts with: Reader-Writer (producer-consumer vs readers-writers)

Edge Cases & Gotchas

Wrong semaphore order can cause deadlock (always mutex last in, first out)
Buffer must be protected by mutex during access
Can be extended to multiple producers/consumers

quadratic-probing

2026-04-30T00:00:00.000Z

The Problem

Linear probing causes primary clustering (long runs of occupied slots). We need a probing sequence that skips more slots each time to reduce clustering.

Core Idea

Quadratic probing uses a quadratic function (i²) to determine probe sequence: h(k), h(k)+1², h(k)+2², h(k)+3², …

How It Works

Hash key to get initial index
If collision, check index + 1²
If still occupied, check index + 2²
Continue: index + 3², index + 4², …
Wrap around table as needed

Key Properties

Reduces primary clustering compared to linear probing
May not probe all slots (depends on table size)
Works best when table size is prime number
Load factor should be < 0.7 for good performance

Connections

Built from: Hashing, Collision Resolution
Builds into: Double Hashing
Related: Linear Probing
Contrasts with: Linear Probing (quadratic vs linear skip)

Edge Cases & Gotchas

May not probe all table slots (unlike linear probing)
Table size should be prime for best coverage
Secondary clustering: same initial hash = same probe sequence

raid

2026-04-30T00:00:00.000Z

The Problem

Disks fail — and when they do, data is lost. Single disks also have performance limits. We need techniques to combine multiple disks for reliability and/or speed.

Core Idea

RAID combines multiple physical disks into a logical unit to provide redundancy (data safety) and/or improved performance.

How It Works

RAID levels:

RAID 0 (Striping): Data split across disks, no redundancy, fast but risky
RAID 1 (Mirroring): Data duplicated to 2+ disks, full redundancy
RAID 5 (Striping + Parity): Data + parity distributed, 1 disk failure tolerance
RAID 6 (Striping + Double Parity): Tolerates 2 disk failures
RAID 10 (1+0): Mirror pairs striped, best of both worlds

Key Properties

RAID 0: Performance ↑, Reliability ↓ (no redundancy)
RAID 1: Reliability ↑, Cost ↑ (100% overhead)
RAID 5: Balanced (1 disk overhead for parity)
RAID 6: More reliable than 5 (2 disk failures)
RAID 10: Best performance + reliability, but expensive

Connections

Built from: Disk Management, Disk Structure
Builds into: Disk Reliability
Related: Parity, Striping, Mirroring
Contrasts with: Swap Space (different purpose — performance vs capacity extension)

Edge Cases & Gotchas

RAID is not backup — accidental deletion still propagates
RAID rebuild after failure is I/O intensive (risky if another disk fails)
Software RAID vs Hardware RAID (hardware has battery-backed cache)

reader-writer

2026-04-30T00:00:00.000Z

The Problem

Multiple processes want to read or write a shared resource. Readers can access concurrently, but writers need exclusive access. We need to coordinate them.

Core Idea

A synchronization problem where multiple readers can read simultaneously, but a writer requires exclusive access (no readers or other writers).

How It Works

Readers: increment readCount (atomically), if first reader, wait on writeLock
Readers: read data, decrement readCount, if last reader, signal writeLock
Writers: wait on writeLock (exclusive access), write, signal writeLock
Mutex: protects readCount variable

Key Properties

Readers can proceed concurrently
Writers need exclusive access
Starvation possible: writers may starve if readers keep coming
Uses readCount, mutex, writeLock semaphores

Connections

Built from: Semaphore, Producer-Consumer Problem
Builds into: Race Condition
Related: Mutex, Wait Operation
Contrasts with: Producer-Consumer (readers concurrent vs producer-consumer serialized)

Edge Cases & Gotchas

Writer starvation: readers keep arriving, writer never gets access
Reader starvation: writer locks resource, new readers blocked
readCount must be protected by mutex (it’s a shared variable)

scan-scheduling

2026-04-30T00:00:00.000Z

The Problem

SSTF can starve requests at the edges of the disk. We need a fair algorithm that still performs well.

Core Idea

SCAN (Elevator Algorithm) moves the disk arm in one direction, servicing requests along the way, then reverses direction at the end and repeats.

How It Works

Disk arm starts moving in one direction (e.g., outward)
Service all requests in the current direction
When reaching the end, reverse direction
Service requests in the new direction
Continue like an elevator

Key Properties

No starvation (all requests eventually serviced)
More uniform wait times than SSTF
Can waste time going to disk end (even if no requests there)
Like an elevator serving floors

Connections

Built from: Disk Scheduling, SSTF
Builds into: C-SCAN, LOOK
Related: Disk Structure
Contrasts with: SSTF (no starvation vs possible starvation)

Edge Cases & Gotchas

High response time for requests at the edges (must wait for full sweep)
May go to disk end unnecessarily (solved by LOOK)
Better for heavy load than SSTF

segmentation

2026-04-30T00:00:00.000Z

The Problem

Paging uses fixed-size pages, which don’t match program structure (code, data, stack are different logical units). We need variable-size chunks that match program semantics.

Core Idea

Segmentation divides memory into variable-size logical units (segments) like code, data, stack, each with a segment table mapping to physical memory.

How It Works

Program divided into segments (code, data, stack, heap)
Each segment has: base address, limit (size)
Segment table maps segment number → (base, limit)
Address = segment number + offset within segment
Hardware checks offset < limit (protection)

Key Properties

Variable-size segments (no internal fragmentation)
Matches program structure (logical units)
External fragmentation (gaps between segments)
Easier sharing (share entire segment)

Connections

Built from: Virtual Memory, Paging
Builds into: Paging vs Segmentation
Related: Segment Table, External Fragmentation
Contrasts with: Paging (variable vs fixed size)

Edge Cases & Gotchas

External fragmentation: gaps between segments
Segment table overhead per process
Segment bounds checking required (hardware)

Semaphore Types — Binary vs Counting Semaphores Compared

2026-04-30T00:00:00.000Z

Framing

Compare binary semaphores (mutex) versus counting semaphores (resource pools) — their use cases, behavior, and when to use each.

Comparison

Feature	Binary Semaphore	Counting Semaphore
Values	0 or 1 only	0 to N (N = resource count)
Use Case	Mutual exclusion (critical section)	Resource pool management
Initial Value	1 (unlocked)	N (available resources)
Negative Value	Never negative	Negative = number of waiters
Example	File lock, mutex	Buffer slots, printer pool

Key Insights

Binary semaphore = mutex — ensures only one process enters critical section
Counting semaphore = resource counter — tracks pool of identical resources
Both use same wait()/signal() operations — the difference is initialization and interpretation
Binary semaphores can be implemented with counting (just set N=1), but not vice versa
Classic use: producer-consumer — uses counting (empty, full) + binary (mutex)
Priority inversion affects both types — high-priority process blocked by lower-priority holder

Synthesis

Binary semaphores are a special case of counting semaphores (N=1). Use binary for mutual exclusion, counting for resource pools. The producer-consumer problem elegantly combines both: counting semaphores (empty, full) manage buffer slots, while a binary semaphore (mutex) protects the buffer data structure.

Connections

Semaphore — the general concept
Binary Semaphore — mutex use case
Counting Semaphore — resource pool use case
Producer-Consumer Problem — uses both types
Mutex — binary semaphore synonym
wait() Operation — used by both
signal() Operation — used by both

/wiki / io

cpu

The Problem

Formal Definition

Explanation

How It Works

Visual Explanation

Semantic Network

Key Properties

Real-World Example

Connections

Edge Cases & Gotchas

critical-section

The Problem

Formal Definition

Explanation

How It Works

Visual Explanation

Semantic Network

Key Properties

Real-World Example

Connections

Edge Cases & Gotchas

Io — Map of Content

Core Concepts

Mechanisms & How Things Work

Comparisons & Tradeoffs

Suggested Reading Order

memory

The Problem

Formal Definition

Explanation

How It Works

Visual Explanation

Semantic Network

Key Properties

Real-World Example

Connections

Edge Cases & Gotchas

mutex

The Problem

Formal Definition

Explanation

How It Works

Visual Explanation

Semantic Network

Key Properties

Real-World Example

Connections

Edge Cases & Gotchas

race-condition

The Problem

Formal Definition

Explanation

How It Works

Visual Explanation

Semantic Network

Key Properties

Real-World Example

Connections

Edge Cases & Gotchas

segment-table

The Problem

Formal Definition

Explanation

How It Works

Visual Explanation

Semantic Network

Key Properties

Real-World Example

Connections

Edge Cases & Gotchas

binary-semaphore

The Problem

Core Idea

How It Works

Key Properties

Connections

Edge Cases & Gotchas

block-driver