An operating-system process is an execution instance of a program, with an address space, one or more software threads carrying execution contexts, and operating system resources such as file descriptors. A program describes instructions; an executable file stores a form that can be loaded for execution. Starting the same executable twice can create two operating-system processes, each with its own evolving state. A operating-system process can be waiting for input-output or waiting for a turn on the CPU, rather than executing at every instant. ^[ref]

For example, start the same counter program as operating-system processes A and B. In this toy mapping, both use virtual address 0x1234 for a counter x, but A reads x = 7 while B reads x = 42. The number 0x1234 is interpreted through the current address space, so it need not denote the same contents in both operating-system processes. Writing A's ordinary private counter does not change B's counter. Compare virtual memory for an explicit mapping to different physical addresses.

Separate virtual memory address spaces provide a usual default isolation boundary, not a claim that all computer memory is universally private. Deliberately shared mappings let operating-system processes communicate through the same stored data. Even logically private contents need not occupy distinct page frames at every moment: read-only program code can be shared, and copy-on-write can keep a common memory page until a write requires a private copy. The distinction is between which accesses and changes are permitted and which physical storage is currently reused. ^[ref][ref]

This abstraction lets independent activities reuse the same executable while keeping their changing state separate. Process scheduling distributes CPU time; virtual memory interprets and protects addresses; file descriptors connect an execution to open resources. The useful design is controlled independence with explicit ways to share. Creating operating-system processes, maintaining their mappings and performing context switches require time and computer memory; isolation alone gives no universal performance guarantee.

Process scheduling chooses which runnable operating-system process or software thread uses a CPU next, and when it gives up that CPU. Runnable means able to execute now; work waiting for an input-output operation is not eligible until that wait ends. A ready queue records eligible work. The policy chooses a recipient; a context switch supplies the mechanism for transferring execution. Sharing a single CPU lets a long calculation and an interactive program both make progress, although only one execution stream runs on that CPU at an instant.

Consider three single-software thread operating-system processes on one CPU, with abstract time units, zero context switch or scheduler overhead, and no input-output blocking. Their arrival times and CPU bursts are $(a_A,b_A)=(0,5)$, $(a_B,b_B)=(1,3)$ and $(a_C,b_C)=(2,1)$. Each CPU burst is all the execution that its task needs. With FCFS, the current task runs to completion: A occupies $[0,5)$, B $[5,8)$ and C $[8,9)$. With round-robin scheduling and scheduling quantum $q=2$, the intervals are A $[0,2)$, B $[2,4)$, C $[4,5)$, A $[5,7)$, B $[7,8)$ and A $[8,9)$. At a boundary, arrivals join the ready queue before the unfinished task whose scheduling quantum has expired; this fixes the otherwise ambiguous ordering at time 2.

The following triples always list A, B, C. Completion is an absolute time; scheduling turnaround time, scheduling waiting time and scheduling response time are durations measured from the relevant events.

For example, B first runs at time 2 under round-robin scheduling, so its scheduling response time is $2-1=1$. It finishes at time 8, giving scheduling turnaround time $8-1=7$ and scheduling waiting time $7-3=4$. Under FCFS, C waits $8-2=6$ before its sole execution interval. Under round-robin scheduling, A waits during $[2,5)$ and $[7,8)$, totaling $3+1=4$. Both timelines do exactly $5+3+1=9$ units of useful CPU work; changing the order changes who benefits first.

The appeal is that shared progress can improve responsiveness: B and C get their first CPU service sooner under round-robin scheduling, while A completes later. The arithmetic mean of the scheduling response times falls from $10/3$ to $1$; the arithmetic mean of the scheduling turnaround times is $19/3$ for both policies in this particular example. These are different goals, and this workload establishes no universal ranking. Giving each continuously runnable task repeated turns is a practical form of fairness. A smaller scheduling quantum can shorten waits between turns, but makes context switches more frequent when competitors remain runnable. If each full slice performs $q$ units of useful work and incurs a fixed switching cost $s$, the overhead fraction in that simplified repeated cycle is $s/(q+s)$. Real costs and workloads determine the choice. ^[ref]

The operating-system kernel is the core of an operating system, controlling access to resources and supplying mechanisms used by operating-system processes. Processor privilege levels let it enforce boundaries that ordinary programs cannot simply overwrite. The operating-system kernel connects process scheduling, virtual memory and file system operations; a system call requests a service across that boundary. A monolithic kernel and a microkernel divide services differently, so the location of every file system service is a design choice.

For the toy file system, opening a resolves its directory entry to inode 42, establishes an open file description, and returns file descriptor 3. Later reads use that file descriptor to reach the existing open file description, without resolving the spelling a again. This explains how unlinking an open file preserves access: the open reference survives the directory entry. The per-operating-system process table interpreting 3 is maintained by the operating-system kernel; 3 itself is the small integer passed by the program, not inode 42. ^[ref]

Communication between operating-system processes, including controlled message delivery and deliberately shared computer memory. A microkernel supplies IPC across protection domains, allowing user-space services to cooperate without making all their private computer memory accessible to each other.

Distinguishing the operations a system can enforce from the choices about how to use them. In a microkernel, a protected IPC operation can deliver requests while a user-space service decides which files a caller may read. The division is a design choice: every real mechanism still has rules and limits.

An operating system service executing at an application's processor privilege level, outside the operating-system kernel. A microkernel can host a file system or device driver this way. Its granted security capabilities and memory protection determine its authority; the label user-space service does not imply that it has little authority.

A boundary within which code exercises a particular set of permissions. An address space describes accessible virtual addresses; a protection domain also concerns authority over other objects, such as software threads and IPC endpoints. Two address spaces may deliberately share a writable memory page, so separation of address spaces alone does not make their contents independent.

Execution of a suitable executable with effective user identity set to its owner. A privileged executable writable by untrusted users permits code replacement and privilege escalation.

// Target: computer-science.bigb

Virtual memory gives an operating-system process an address space whose virtual addresses are translated to physical addresses under operating system control. In a system using paging, each resident memory page maps to a page frame; page tables describe the mappings and access permissions, while the memory management unit enforces them. The same virtual address in two operating-system processes can refer to different page frames. A deliberate shared mapping can instead make different virtual addresses refer to the same page frame. ^[ref]

For example, with 256-byte memory pages, let process A map virtual page 0x12 to page frame 0x07, and process B map virtual page 0x12 to page frame 0x09. Their identical virtual address 0x1234 then denotes physical address 0x0734 in A and 0x0934 in B. The address acquires meaning from the current address space, not just its numerical value. See paging for the calculation.

This separation makes programs easier to place in computer memory: consecutive virtual addresses need not occupy consecutive page frames. It also provides isolation and controlled sharing. Virtual memory does not require secondary storage: a system can translate and protect virtual addresses while keeping every allocated memory page resident in computer memory. Demand paging adds allocation or loading on first use, and can support an address space larger than available computer memory; the amount that can be used at once is still limited. Keeping a working set resident avoids memory thrashing.

An early concrete implementation was Manchester's Atlas. Kilburn, Edwards, Lanigan and Sumner's April 1962 paper describes automatically combining fast core storage with drum storage, transferring 512-word blocks and translating their addresses through page address registers. Its attraction was to spare programmers explicit transfers between these storage levels. This historical use of secondary storage is one application of virtual memory, rather than a requirement of every virtual memory system. The accessible text below is a reprint of the paper. ^[ref]

Keeping several operating-system processes available so process scheduling can run another when one waits. Increasing their number can increase the combined working set demand beyond the available page frames, producing memory thrashing rather than more useful CPU work.

Multics is a time-sharing operating system developed from a research project begun in 1965. It provided an interactive computing service to multiple users through terminals, sharing the underlying computer while protecting users' work. Its surviving documentation and source make it a concrete historical case for studying operating system design and protection. The participants' archive records its transition into a commercial system and operational use until 2000.^[ref]

// Target: computer-science.bigb

A processor privilege level controls which instructions and resources executing code may access. Operating-system kernels use a more privileged context than ordinary user programs, and a controlled trap or system call changes context to request protected operations. In x86, protection rings are numbered zero through three, with zero most privileged; common systems use rings zero and three for kernel and userspace. Other architectures use different mode systems. A privilege level is enforced by processor state and memory-access rules, rather than being a convention programs may ignore.

// Target: computer-science.bigb

An interrupt redirects CPU execution to an interrupt handler in response to an event. Here the main case is an asynchronous hardware interrupt: a timer or device requests attention independently of the instruction currently being executed. A device completing a receive operation can announce that its data is ready while the CPU is running another program. Interrupt-driven input-output illustrates this with an explicit timeline. ^[ref]

A synchronous processor exception, such as a page fault caused by a particular memory access, is tied to instruction execution. A system call is an intentional program request for an operating-system kernel service. These routes can share entry machinery, and an instruction named a software interrupt can implement a system call, but this does not make that request an asynchronous device event. For example, the Linux kernel on x86 documents separate entries for external interrupts, divide exceptions, syscall and int 0x80. ^[ref]

The usual device route is a request through an interrupt controller, architecture-specific entry, and dispatch to an interrupt handler. In the Linux kernel, generic handling separates controller operations from flow handling and device driver callbacks. Requests can arrive through a pin or a message, and several devices can share a request source. Routing, priorities and interrupt masking determine which requests can be delivered; notification therefore need not mean immediate execution of the interrupt handler. ^[ref][ref]

The CPU and entry code preserve the state needed to resume interrupted execution, including the instruction pointer. Handling may enter a higher processor privilege level when interrupting ordinary program execution, but an interrupt can also arrive while privileged code is already running. The protected entry route and handler placement depend on the architecture and operating system; a microkernel need not place all device driver work where a monolithic kernel does. An interrupt entry is also distinct from a context switch to another operating-system process. ^[ref][ref]

// Target: computer-science.bigb

Software supplying device-specific operations behind an operating system interface. For these examples its responsibilities include DMA setup and completion handling, or checking status for polled input-output. ^[ref]

A processor event attributable to instruction execution, such as a page fault during a memory access or a divide exception on x86. This causal connection distinguishes it from the asynchronous device interrupts discussed here. It also differs from a programming language's exception handling, which specifies how program-level exceptions propagate. ^[ref]

A file system organizes files, their file metadata, and the names through which they can be found. In the Unix model used here, a file-system directory contains directory entries associating names with inodes; an inode describes the underlying file and how to locate its contents. The file-system namespace answers "what does this name reach?", while the inode answers "which file is it?". These are distinct responsibilities, even though they cooperate on every lookup.

For a computed toy example, let one file-system directory contain names a and b, both referring to inode 42 in the same file system. That inode has size 6 bytes and two hard links. Its direct references lead to four-byte file data blocks 7 and 9: block 7 holds hell, while block 9 holds o followed by a newline, with two unused slots. Reading either name therefore obtains the same six-byte contents hello followed by a newline. There is one file with two names, not two copies. This direct-reference layout and tiny block size are teaching choices, not requirements on every file system.

The separation is useful because a rename within this file system, from a to a previously unused name c, can change a directory entry without copying the six bytes of contents. The remaining name b still reaches inode 42. A successful write changing the first byte through either name changes what both names subsequently read, to jello followed by a newline. This sharing is the attraction of hard links, and also why a hard link is not an independent backup. A program that replaces a named file with a different file can instead make the names diverge. ^[ref]

An authorization table with subjects or protection domains as rows, objects as columns, and sets of allowed operations as entries. An access control list stores an object column; a capability list stores a subject row. This representation is not a numerical linear map and has no ordinary floating-point matrix inverse.

// Destination: computer-science.bigb

In polled input-output, the CPU explicitly checks a device's status to discover whether work is ready or an operation has completed. Repeatedly checking in a tight loop is busy polling; periodic checks can instead leave time for other work. Interrupt-driven input-output changes how readiness is discovered, while DMA changes how payload data moves. ^[ref]

Use the model drawn under interrupt-driven input-output: device events occur at times $2,5,9$, while polls occur at $0,2,4,6,8,10,12$. Assume each event remains pending until detected and an event simultaneous with a poll is visible to that poll. The detection times are $2,6,10$, giving delays $0,1,1$. Four of the seven checks find no new event. These are event-detection delays, not completion times for servicing the events.

More generally, for polls at $0,\Delta ,2\Delta ,\dots$ with $\Delta >0$, an event at time $t\ge 0$ is first detected atThe ceiling function chooses the first poll at or after the event. To verify the bound, that poll is less than one interval beyond $t$; if $t$ is itself a poll time, the delay is zero by the stated visibility convention. This argument assumes instantaneous checks, persistent pending status and an uninterrupted poll schedule. It does not describe missed transient events or a CPU too busy to maintain that schedule.

The attraction of polled input-output is simple control and the possibility of processing several ready items in one visit. Busy polling spends CPU time even when nothing is ready, but short waits or frequent events can make avoiding repeated interrupt entry worthwhile. The right choice depends on actual checking, notification and service costs. See interrupt-driven input-output for a documented combination of both strategies. ^[ref]

// Destination: computer-science.bigb

A member of the Windows NT operating-system family. Executive services such as object, memory and input-output management execute in privileged kernel mode. Its object-level access control lists and subject tokens permit finer authorization policies than traditional owner-group-other file permissions.

// Destination: computer-science.bigb

An operating-system family with process, file and pipe abstractions. The traditional discretionary file-permission model separates owner, group and other users and read, write and execute rights. Individual Unix systems can add richer access control lists and other protection mechanisms.

// Destination: computer-science.bigb