Without an operating system, every application would need to understand the details of the processor, memory, disks and input/output devices. The OS hides those differences behind standard abstractions such as processes, files, sockets and virtual memory.

It also decides how limited resources are shared. The scheduler distributes CPU time, the memory manager assigns RAM, the file system organises persistent data and device drivers communicate with hardware. Protection mechanisms prevent one program from reading or damaging another program's data.

A useful way to remember the OS is as both a resource manager and an abstraction provider. It manages the physical machine while presenting simpler logical views to programs, allowing applications to remain portable and users to run many tasks safely at the same time.

Modern processors provide privilege levels so an ordinary application cannot directly change page tables, disable interrupts or access devices. This restriction limits the damage caused by a faulty or malicious program.

When an application needs a protected service, it makes a system call. The CPU switches to kernel mode at a predefined entry point, the OS validates the request, performs the operation and returns to user mode. Kernel failures are more serious because the kernel is shared by the whole system.

For example, a text editor may request that a file be saved, but it cannot write arbitrary disk sectors itself. It enters the kernel through a system call, the kernel checks the request, performs the protected operation and then returns control to the editor in user mode.

A program normally calls a library function such as read(), open() or fork(). The wrapper places the system-call number and arguments where the operating system expects them, then executes a special trap instruction.

The CPU saves the current user context, changes privilege level and jumps to the kernel's system-call handler. The kernel checks the call number, permissions, addresses and arguments before performing the work. It then stores the return value, restores user execution and continues after the original call.

The important interview point is that a system call is not an ordinary function call. It crosses a protection boundary and therefore requires validation and a privilege transition. This extra work makes it safer, but also more expensive than calling a function entirely within user space.

The executable stored on disk does not have a program counter, CPU registers or allocated runtime memory. When it is launched, the OS creates a process, maps the executable into an address space and prepares the stack, heap and other runtime structures.

The same program can create many processes. Opening a browser several times may run multiple process instances from the same executable, but every process has its own identifier and protected execution state.

For example, a browser executable is a program stored on disk. When you launch it, the OS creates a process with its own PID, address space, open files and scheduling information. Launching it again can create another independent process from the same program file.

Processes provide isolation. A failure in one process normally does not corrupt another process because their virtual address spaces are separate. Communication between processes therefore needs an IPC mechanism.

Threads are lighter because threads in the same process share code, heap and open files. This makes communication fast, but it also creates synchronization problems: one faulty thread can corrupt shared data or crash the complete process.

A web server illustrates the trade-off well. Multiple threads can handle requests efficiently because they share cached data, but access to that data must be synchronized. Separate processes provide stronger isolation, although communication and context switching are generally more expensive.

Overview

A process state is an abstraction the operating system uses to track what a process is doing and what resources it needs. States let the OS make scheduling and resource decisions without inspecting process code.

Understanding states and transitions is key for reasoning about scheduling, context switches, blocking behavior and process lifecycle management.

Purpose

The operating system creates and maintains a PCB for each process. It uses this record to track the process throughout its lifetime, including creation, scheduling, blocking for an event or I/O, and termination.

The exact PCB layout is operating-system-specific. In systems that schedule threads independently, some execution-context and scheduling information may be kept in a separate thread control block rather than solely in the process PCB.

Kernel storage

PCBs are kernel data structures and are protected from direct modification by ordinary user programs. Operating systems organize them using process tables and scheduling or wait queues, with the exact organization depending on the implementation.

Their size, fields, and relationships with other kernel structures vary by operating system and hardware architecture.

The OS saves registers, program counter and scheduling state for the outgoing task, chooses another runnable task and restores its saved context. Depending on the switch, address-space and privilege-related state may also change.

The direct save-and-restore cost is only part of the overhead. The incoming task may suffer cold CPU caches, branch-predictor disruption and TLB misses. Excessive switching therefore reduces useful throughput even when each individual switch appears short.

The cost comes from saving and restoring registers, changing memory mappings and disturbing CPU caches or translation buffers. A thread switch within one process is often cheaper because the address space may remain unchanged, although it still has scheduling overhead.

Preemption improves responsiveness and lets high-priority or interactive work run quickly, but it causes more context switches and requires careful synchronization around shared data.

Non-preemptive scheduling is simpler and has lower switching complexity, but one long task can delay every task behind it. Round Robin and SRTF are common preemptive algorithms; FCFS and non-preemptive SJF are common non-preemptive examples.

Preemption improves responsiveness because a long-running task cannot keep the CPU indefinitely. Non-preemptive scheduling is simpler and can reduce switching overhead, but one slow or blocked task may delay others. Modern general-purpose systems therefore normally use preemptive scheduling.

After fork(), parent and child continue from the next instruction but receive different return values. The child gets a new process ID. Modern systems initially share physical pages using copy-on-write, so memory is copied only when one process modifies a shared page.

exec() does not normally create another process. It replaces the current code, data, heap and stack with a new executable while keeping the same process identity. If exec succeeds, it does not return to the old program.

The key distinction is that fork() preserves the current program image in a new process, whereas exec() replaces the caller's image. A command shell commonly forks, lets the child call exec() for the requested command, and keeps the parent shell available for the next command.

When a child terminates, the kernel keeps a small record containing its PID and exit status until the parent calls wait() or a related function. During this period the child is a zombie: it executes no instructions and consumes no CPU, but too many zombies can exhaust process-table entries.

An orphan has not terminated. The operating system reparents it to a designated system process, which later collects its exit status. Orphans can continue doing normal work; zombies cannot because their execution has already ended.

The OS must still retain enough information to report the child's termination status to its parent, which creates a zombie. An orphan is different because it is still running; the system simply gives another process responsibility for eventually collecting its status.

A single CPU core can support concurrency by rapidly interleaving tasks. Only one instruction stream may execute at a moment, but switching between tasks allows an application to remain responsive while other work waits for input or output.

Parallelism normally requires multiple cores, processors or execution units. It can reduce completion time when work can be divided into independent parts, but it also introduces coordination, synchronization and load-balancing costs.

Concurrency is possible even on one CPU because tasks can be interleaved, while parallelism requires simultaneous execution resources such as multiple cores. A concurrent design may become parallel when hardware permits, but it must still be correct when operations are only interleaved.

Consider two threads incrementing the same counter. An increment is usually a read-modify-write sequence rather than one indivisible action. If both threads read the old value before either writes the new value, one update can be lost.

Mutual exclusion, semaphores, atomic operations or carefully designed lock-free algorithms can protect the critical section. Synchronization should cover the smallest correct region because an unnecessarily large critical section reduces concurrency.

Suppose two threads increment the same counter by reading, adding and writing. If both read the old value before either write occurs, one increment is lost. Protecting that read-modify-write sequence as a critical section makes the operation appear indivisible to competing threads.

A mutex normally has two states: locked and unlocked. The thread that locks it is expected to unlock it. This ownership rule makes a mutex suitable for protecting shared data and lets implementations provide features such as priority inheritance.

A counting semaphore can allow up to N users of a resource, while a binary semaphore has values similar to zero and one. Semaphores do not require the same task to perform wait and signal, so they can also coordinate producer-consumer and event-notification workflows.

A mutex is normally preferred when a specific thread must own and release a lock. A semaphore is useful when access is controlled by a count, such as allowing only five tasks to use a resource pool. Both require careful use to avoid deadlock and starvation.

Definition

A deadlock occurs when a group of processes or threads cannot make progress because each is waiting on another member of the group. Progress requires an external action, such as terminating a process, releasing a resource, or otherwise breaking the wait cycle.

Why the conditions cause blocking

Mutual exclusion makes a resource unavailable to other processes while it is held, and no preemption prevents the operating system from simply reclaiming it. Hold and wait allows processes to retain resources while requesting more, and circular wait creates a closed dependency cycle. As a result, no process in the cycle can obtain what it needs and continue.

Prevention structurally breaks a Coffman condition, for example by enforcing a global lock order. Avoidance examines each request and grants it only if the system remains in a safe state; Banker's algorithm is the textbook example but requires advance knowledge of maximum demands.

Detection allows requests normally and periodically searches wait-for or resource-allocation graphs for deadlock. Recovery can terminate one or more processes, roll back work, or preempt resources. General-purpose systems often combine practical prevention rules with timeouts and application-level recovery.

A practical system may combine strategies: impose lock ordering to prevent common cycles, use timeouts for selected operations and run detection for resources that cannot be strictly ordered. Recovery may then terminate a task, roll it back or preempt a resource where safe.

In deadlock, the involved tasks cannot move because each is waiting. In starvation, the system as a whole may be healthy while unfair scheduling or allocation prevents one task from progressing for an unbounded time.

In livelock, tasks keep changing state, often to be polite to each other, but those changes repeatedly recreate the conflict. Fair queues and aging help starvation; consistent lock ordering helps deadlock; randomized backoff is a common livelock remedy.

These problems differ in their dependency. Deadlock involves a closed waiting relationship, starvation comes from unfair allocation, and livelock contains continuous activity without useful progress. The remedy must match the cause: ordering, fairness or randomized/back-off behaviour respectively.

Message-passing mechanisms such as pipes, queues and sockets copy or transfer data through a kernel-managed interface. They provide clear ownership and isolation, and sockets can communicate across machines, but system calls and copying may add overhead.

Shared memory maps the same physical pages into multiple processes and is often the fastest method for large local data. Because the kernel does not automatically coordinate every access, processes must add synchronization such as mutexes, semaphores or atomic operations.

Pipes are simple for related processes, queues preserve message boundaries, shared memory offers high throughput and sockets work across machines. The correct IPC mechanism depends on data volume, relationship between processes, required isolation and whether communication is local or distributed.

With paging, any virtual page can be placed in any free physical frame. This avoids external fragmentation and makes allocation predictable, although the unused space in the final page of an allocation can cause internal fragmentation.

Segmentation matches the programmer's logical view and can apply protection or sharing to meaningful regions. Because segments have different sizes and traditionally require suitable contiguous placement, free space can become scattered into external holes. Modern systems mainly rely on paging, sometimes combined with architectural segmentation support.

Paging is widely used because fixed-size units simplify allocation and remove external fragmentation, although unused space inside the final page creates internal fragmentation. Segmentation matches logical program regions more naturally but makes free-space management and compaction more difficult.

Virtual addresses let the OS relocate processes, isolate their memory and selectively share pages without requiring each program to know where physical RAM is located. Page tables store the mappings and access permissions used by the processor's memory-management unit.

With demand paging, executable and data pages can remain on storage until needed. An access to a valid but non-resident page causes a page fault; the OS loads the page, updates the page table and restarts the instruction. This reduces initial memory use but excessive faults can severely reduce performance.

Demand paging works because programs usually use only a portion of their address space at a given moment. The OS can therefore keep active pages in RAM and leave inactive pages on storage, giving each process the illusion of more memory while paying page-fault cost only when needed.

Every ordinary load or store uses a virtual address. Without a cached translation, the processor may need several additional memory accesses to walk a multilevel page table before it can reach the requested data. A TLB hit supplies the frame number and permission bits quickly.

A TLB miss means the translation was not cached; it does not necessarily mean the page is absent from RAM. Hardware or the operating system can fill the TLB from a valid page-table entry. Only an invalid or non-resident mapping that requires OS handling becomes a page fault.

Without a TLB, every memory reference could require one access to read the page-table entry and another to access the actual data. A TLB hit avoids that extra lookup, which is why its hit rate has a large effect on effective memory-access time.

The fault may represent a valid demand-paged access, a write to a copy-on-write page, a permissions violation or an invalid address. The CPU records the faulting address and transfers control to the kernel's page-fault handler.

For a valid non-resident page, the OS finds a free frame or selects a victim, schedules storage I/O, updates the page table and invalidates any stale TLB entry. The blocked process later restarts the same instruction. An invalid or forbidden access normally causes a signal, exception or process termination.

Not every page fault is an error. A valid demand-page fault is part of normal virtual-memory operation, while an invalid address fault indicates that the process accessed memory outside its permitted mappings and normally leads to a protection signal or termination.

Stack algorithms and the inclusion property

A stack algorithm has the inclusion property: for a given reference string, the pages resident with m frames are always a subset of those resident with m+1 frames. Therefore, adding a frame cannot increase its number of page faults.

OPT and LRU are stack algorithms. FIFO is not. This distinction is important because stack algorithms cannot exhibit Belady’s anomaly; a non-stack algorithm can, although it does not necessarily do so for every reference string.

Belady’s anomaly

Belady’s anomaly is the counterintuitive result that giving a page-replacement policy more frames can produce more page faults. It is most commonly demonstrated with FIFO.

For the reference string 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5, FIFO produces 9 page faults with 3 frames and 10 page faults with 4 frames. The additional frame changes FIFO’s eviction order in an unfavorable way.

The key lesson is that more memory does not automatically imply fewer faults for every replacement policy. It does imply no increase in faults for stack algorithms such as OPT and LRU.

Practical perspective

Real operating systems generally use policies that approximate recency rather than exact OPT or exact LRU. The appropriate choice depends on available hardware reference information, implementation overhead, and workload locality.

Working-set concepts are also important to know: they describe a process’s recent locality and can guide resident-set and replacement decisions, rather than being a single replacement algorithm in the same sense as FIFO or LRU.

When a process repeatedly evicts pages it will need again soon, page-fault frequency rises and storage activity becomes very high. CPU utilization may fall, which can mislead a naive scheduler into admitting even more processes and making the problem worse.

The OS can reduce the degree of multiprogramming, allocate more frames, prefer local replacement or suspend processes. Working-set models estimate the pages actively used during a recent window, while page-fault-frequency control adjusts allocation when a process crosses configured thresholds.

The OS responds by reducing the number of competing processes, allocating more frames or using a working-set style policy that protects actively used pages. The objective is to restore locality so processes spend most of their time executing rather than repeatedly faulting.

The virtual file system walks path components from the starting directory, consults cached metadata or the concrete file system, follows mount points and symbolic links when allowed, and verifies access permissions. The returned descriptor is an index in the process's descriptor table referencing a kernel open-file description with flags and a current offset.

A read first checks the page cache. If data is present, the kernel copies it to the validated user buffer and advances the file offset. On a cache miss, the file system maps the logical offset to storage blocks, submits I/O through a device driver, blocks the caller if necessary and completes the copy when data arrives.

The pathname lookup is only the start. The kernel must also enforce permissions and maintain a per-process file descriptor that refers to a system open-file entry. Later reads and writes use that descriptor, avoiding a complete path lookup on every operation.

Fixed-size allocation rounds requests up to an available block or page size. The unused portion remains reserved for that allocation and creates internal fragmentation. Smaller size classes or block sizes can reduce it, although they may add management overhead.

Variable-size contiguous allocation can leave holes as objects are created and freed. The total free memory may be sufficient but not contiguous, producing external fragmentation. Coalescing adjacent holes, compaction, relocation or non-contiguous paging can address it.

Internal fragmentation wastes space inside an allocated unit and cannot be recovered without changing that allocation. External fragmentation leaves usable free space split across the system. Paging addresses external fragmentation by using fixed frames, but may still waste part of the last page.

A monolithic kernel keeps core services such as scheduling, memory management, file systems and many drivers in kernel space, enabling efficient direct calls but increasing the trusted code base. A microkernel keeps only essential mechanisms privileged and moves services to isolated user-space processes, improving fault isolation at the cost of more IPC and context transitions.

Hybrid kernels combine microkernel ideas with selected services in kernel space for performance. Modular monolithic kernels can load and unload drivers or subsystems while retaining a common kernel address space. Exokernel-style designs expose protected hardware resources and let application libraries build higher-level abstractions.

Kernel design is a trade-off between performance, isolation and maintainability. Monolithic kernels keep many services together for efficient calls, microkernels move services out for stronger isolation, and hybrid designs retain a larger kernel while borrowing modular ideas from both.

In multiprogramming, the CPU switches to another resident job when the current one waits for I/O, improving utilization. Multitasking extends this idea with frequent preemptive switching so interactive users perceive several applications running together.

Multiprocessing adds hardware execution units, allowing work to run simultaneously. Modern operating systems use all three ideas: many programs are resident, tasks are time-sliced on each core and multiple cores execute separate tasks in parallel.

A single modern operating system can demonstrate all three ideas: many programs are kept in memory, tasks appear to run together through rapid switching, and multiple cores execute selected tasks at the same instant. The terms describe different aspects of the same workload.

Timers, keyboards, network devices and storage completion signals can interrupt the processor independently of the instruction being executed. The CPU saves enough state, identifies the interrupt source and runs the registered kernel handler.

Exceptions are directly related to execution: examples include divide-by-zero, invalid opcodes, page faults and system-call traps. Some are recoverable and allow the instruction to restart, while others cause a signal or process termination. Both use controlled CPU entry mechanisms, but their sources and timing differ.

A timer interrupt can arrive between instructions regardless of the current program, while a divide-by-zero exception is caused by the instruction being executed. In both cases the CPU saves controlled state and transfers execution to an appropriate kernel handler.

After fork(), duplicating every page immediately would consume time and memory even though the child often calls exec() soon afterwards. With copy-on-write, parent and child page tables point to the same physical frames, and the mappings are protected from writing.

A write causes a protection fault. The kernel allocates a new frame, copies that page, updates the writer's mapping and restarts the instruction. Pages that are never modified remain shared. The same idea supports efficient snapshots, zero pages and memory deduplication designs.

The optimization is especially valuable after fork() because the child often calls exec() before changing most inherited pages. Instead of copying the complete address space, the system copies only pages that are actually modified, reducing both launch time and temporary memory use.