0% found this document useful (0 votes)
2 views19 pages

Operating System Notes

The document provides comprehensive study notes on operating systems, covering their functions, classification, structure, services, and key concepts such as processes, threads, and CPU scheduling. It explains the roles of system calls, process control blocks, context switching, and synchronization mechanisms like semaphores and critical section problems. Additionally, it discusses the benefits of multithreading, various scheduling algorithms, and the importance of concurrency and interprocess communication.

Uploaded by

vivekberma01780
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views19 pages

Operating System Notes

The document provides comprehensive study notes on operating systems, covering their functions, classification, structure, services, and key concepts such as processes, threads, and CPU scheduling. It explains the roles of system calls, process control blocks, context switching, and synchronization mechanisms like semaphores and critical section problems. Additionally, it discusses the benefits of multithreading, various scheduling algorithms, and the importance of concurrency and interprocess communication.

Uploaded by

vivekberma01780
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 19

Operating System Topics Study Notes

1. Operating System and Functions

An operating system (OS) is system software that manages computer hardware and provides an interface
for users and applications. It acts as an intermediary, making the computer environment more convenient
and efficiently using resources. The OS handles core responsibilities such as process management,
memory management, and device control, providing a platform for user programs. Its goals include
maximizing CPU utilization, providing a user-friendly interface, and ensuring reliable execution of
applications. Key functions include:

Resource management: allocating CPU, memory, and I/O devices to processes.

Process coordination: creating, scheduling, and terminating processes, and handling context switches.

Memory management: allocating/deallocating main memory and tracking memory usage.

File management: organizing files and directories and controlling access.

I/O control: managing device drivers and handling input/output operations.

User interface: providing a command-line or graphical shell for user interaction.

The OS hides hardware complexity and offers system calls and system programs (utilities) for applications,
ensuring efficient and secure operation of all software on the machine.

2. Classification of Operating System

Operating systems can be classified by various criteria, such as how they manage processes and resources.
Common categories include:

Batch OS: Executes batches of jobs with little or no interaction (e.g. early IBM mainframes).

Multiprogrammed OS: Keeps multiple jobs in memory; CPU switches among them to maximize utilization.

Time-Sharing (Multitasking) OS: Allows many users to interact concurrently, giving each a small time slice
of the CPU (e.g. modern desktop OS).

Real-Time OS: Provides guaranteed response times for critical tasks (hard real-time systems) or best-effort
timing (soft real-time).

Distributed OS: Manages a collection of independent computers and makes them appear as a single
coherent system.

Network OS: Provides file and printer sharing among multiple machines (e.g. NOS such as Windows
Server).
Mobile/Embedded OS: Designed for mobile devices or embedded systems with constraints (e.g. Android,
VxWorks).

Each type addresses different trade-offs in throughput, interactivity, and resource use. For example, time-
sharing OS emphasize responsiveness, whereas multiprogrammed batch OS focus on maximizing
throughput.

3. Operating System Structure

Operating systems have various architectural structures:

Monolithic: The entire OS works in kernel space; all services run in one address space (e.g., early UNIX). It
provides good performance but low modularity.

Layered: OS is divided into layers (hardware at bottom, user interface at top). Each layer only interacts
with adjacent layers; common in teaching OS (e.g., THE OS).

Microkernel: Minimal kernel in kernel space (handles communication, memory, scheduling); other
services (file system, drivers) run in user space. This increases modularity and reliability (e.g., Minix, QNX).

Modular/Server-based: Kernel consists of core services; additional components are dynamically loadable
modules or servers (e.g., Linux modules, Windows services).

Virtual Machine (VM): OS runs as a process under a hypervisor; each VM appears as a complete system
(e.g., VMware, KVM). The hypervisor provides resource isolation.

Each structure affects performance and complexity. For example, microkernels improve fault isolation but
may incur overhead from inter-process messaging.

4. Operating System Services

An OS provides common services to programs and users, including:

Program execution: Loading and running applications, creating processes.

I/O operations: Managing input/output devices via drivers and I/O management routines.

File system support: Creating, reading, writing, and organizing files and directories.

Communication: Providing mechanisms (IPC) for processes to exchange information.

Error handling: Detecting and responding to hardware or software errors in processes or devices.

Resource allocation: Assigning hardware resources to competing processes (CPU time, memory, devices).
Accounting/Protection: Monitoring usage for billing or logging; enforcing access control to protect user
data and system resources.

For example, when a process requests disk I/O, the OS handles the request, queues it, and returns control
once the operation completes. The OS abstracts complexity so that applications need not manage hardware
directly.

5. System Calls

A system call is a controlled entry point by which a user program requests a service from the OS kernel.
They form the interface between application software and hardware. For example, common system calls
include: process control (e.g. fork(), exit()), file operations (open(), read(), write(), close()), device
management (ioctl()), and communication (pipe(), shmget()). Internally, a system call switches the CPU to
kernel mode so the OS can safely perform the requested operation. In short, a system call lets a program
“invoke” OS services .

6. System Programs

System programs are utilities and programs provided by the OS that perform tasks related to managing
resources and users’ work. They are not part of the kernel but often reside in the OS distribution (e.g.,
compilers, editors, shells, file management tools). Examples include: file browsers, compilers, linkers,
debuggers, network daemons, and disk management tools. System programs provide a user interface to
OS services and simplify routine tasks, but run in user space rather than kernel space.

7. Process Concept

A process is a program in execution. It is a dynamic entity that includes the program code and its current
activity (e.g. values of registers, variables). A single program may correspond to multiple processes (if run
multiple times or as threads). Processes have states, resources (CPU, memory, I/O), and an identifier. The
OS maintains information about each process to schedule and manage execution. In summary, a process is
an instance of a running program, distinguished from the passive program code itself.

8. Process State

Processes transition through a series of states during their life cycle. A simple model has five states:

New: Process is being created.

Ready: Process is prepared to run and waiting for CPU allocation.

Running: Process is currently executing on the CPU.

Blocked (Waiting): Process is waiting for an event (I/O completion, semaphore, etc.) and cannot continue.

Terminated: Process has finished execution or been killed.


Some systems use two-state (running/not running) or other variations. Transitions between states occur
on events like dispatch (Ready→Running), timer interrupt/preemption (Running→Ready), I/O request
(Running→Blocked), and I/O completion (Blocked→Ready).

9. Process Control Block

The Process Control Block (PCB) is the OS’s data structure for each process. It contains all context
information needed to manage the process. Key PCB fields include:

Process state: current state (e.g., Running, Ready).

Program counter: address of next instruction.

CPU registers: values of CPU registers when process was last running.

Memory management info: pointers, page tables, segment tables.

Process ID (PID): unique identifier.

Accounting information: CPU time used, job or process number.

I/O status: list of open files or I/O devices allocated.

When a context switch occurs, the OS saves the current CPU context into the PCB of the outgoing process
and loads the context from the PCB of the next process.

10. Context Switching

Context switching is the procedure where the OS saves the context (CPU registers, program counter, etc.) of
the currently running process and restores the context of another process. This involves storing the old
process’s PCB and loading the new process’s PCB. Context switches are triggered by timer interrupts
(preemptive multitasking), I/O operations, or blocking calls. Although necessary for multitasking, context
switches incur overhead (saving/restoring state) and cause a delay before the next process can run.

11. Operations on Processes

Common operations performed by the OS on processes include:

Process creation: Initiating a new process (e.g. via fork() in UNIX).

Process scheduling/dispatch: Deciding which process to run next.

Process termination (kill/exit): Ending a process normally or abnormally.

Blocking: Temporarily suspending a process (e.g., waiting for I/O or an event).

Waking/Resuming: Moving a blocked process back to ready when its event occurs.
Inter-process communication and synchronization: Sending/receiving data, signaling.

Context switching: Switching CPU from one process to another.

Each operation may be invoked by system calls (create, wait, kill) or by the OS scheduler (dispatch).

12. Threads and Concurrency

A thread is a single sequential flow of control within a process. Modern OSes allow a process to have
multiple threads (multithreading), each with its own program counter and stack but sharing the process’s
code and data. This is sometimes called a “lightweight process.” Threads enable concurrent execution of
tasks within the same process context. Compared to separate processes, threads have lower overhead for
context switching and inter-thread communication because they share memory. The OS provides kernel
threads (managed by the kernel) and user threads (managed by libraries) to schedule and multiplex
threads on the CPU.

13. Benefits of Multithreading

Multithreading offers several advantages:

Responsiveness: Long-running tasks can be split so that one thread handles I/O or user interaction,
keeping the program responsive.

Resource sharing: Threads in the same process share memory and resources, enabling efficient
communication and resource use.

Improved performance: On multi-core systems, threads can run in parallel on different CPU cores,
increasing throughput. Even on single-core, overlapping I/O waits can improve total execution.

Modularity: Programs can be structured into separate threads for different tasks, simplifying design (e.g., a
server thread per client).

For example, a web browser uses separate threads for rendering, networking, and user input to improve
user experience.

14. Types of Threads

Threads are generally classified as:

User-Level Threads (ULT): Managed by a user-level library; the kernel is unaware of them. Context
switching among ULTs is fast, but blocking system calls or scheduling by the OS can block all threads in a
process.
Kernel-Level Threads (KLT): Managed directly by the OS kernel. Each user thread maps to a kernel thread.
The OS schedules threads independently, avoiding the above limitation. However, KLTs have higher
overhead for creation and context switching.

Hybrid models (Many-to-One, One-to-One, Many-to-Many) describe how user threads map to kernel
threads. Most modern systems (e.g., Linux pthreads) use one-to-one mapping (each user thread is a kernel
thread).

15. Threading Issues

While threads improve concurrency, they introduce challenges:

Race conditions: When threads access shared data without proper synchronization, the timing of
operations can produce incorrect results.

Deadlocks: Multiple threads may each hold resources and wait indefinitely for others, causing system stall
(see Deadlock section).

Livelock/Starvation: Improper synchronization can cause threads to never make progress (e.g., one thread
repeatedly yielding to another).

Debugging complexity: Concurrent behavior is non-deterministic and hard to test/reproduce.

Overhead: Excessive threading can lead to context-switch overhead or contention for CPU.

Overall, coordination mechanisms (locks, semaphores) are required to avoid these issues.

16. CPU Scheduling

CPU scheduling is the OS function of deciding which of the ready processes gets the CPU next. Because
multiple processes can be ready to run at once, the scheduler uses algorithms to select a process, aiming to
optimize criteria like CPU utilization, throughput, and response time. The scheduler may use preemptive
(interrupt-driven) or non-preemptive modes. The dispatcher then performs the actual context switch to
start the selected process. Efficient CPU scheduling is crucial because only one process can use the CPU at a
time.

17. Scheduling Criteria

Common scheduling criteria used to compare algorithms include:

CPU Utilization: Keep CPU busy (maximize percent busy).

Throughput: Number of processes completed per time unit (higher is better).

Turnaround Time: Time from submission to completion of a process (minimize average).


Waiting Time: Total time a process spends in ready queue (minimize average).

Response Time: Time from request to first response/output (minimize for interactive systems).

Fairness: Ensure no process is starved; all get CPU time.

For example, in a time-sharing system, low response time is critical, whereas a batch system might focus on
maximizing throughput.

18. Scheduling Algorithms

Popular CPU scheduling algorithms include:

First-Come, First-Served (FCFS): Processes are queued and executed in arrival order. Simple but can have
long waiting times.

Shortest Job First (SJF): Selects the process with the smallest execution time next. It yields minimum
average waiting time but can cause starvation of long jobs.

Round Robin (RR): Each process is given a fixed time slice (quantum) in cyclic order. Fair for time-sharing,
responsive for interactive jobs if quantum is short.

Priority Scheduling: Each process has a priority; CPU goes to highest-priority process. Can be preemptive
or not. Risk of starvation if priorities are static (addressed by aging).

Multilevel Queue and Multilevel Feedback Queue: Processes are partitioned into queues (e.g., system,
interactive, batch) with different scheduling policies; processes may move between queues based on
behavior.

Most schedulers are preemptive in modern OS, except SJF and FCFS (which are typically non-preemptive).
Each algorithm has trade-offs between efficiency, fairness, and overhead.

19. Concurrent Processes

Concurrency occurs when multiple processes (or threads) execute in overlapping time periods, potentially
interacting or competing for resources. Concurrency can happen even on a single CPU (through time-
slicing) or on multiple CPUs (parallelism). Processes may be independent (no shared data) or cooperating
(share data and need synchronization). Concurrent execution improves resource utilization and
throughput, but requires careful coordination to ensure correctness. Concurrency is an abstraction: even
if hardware is single-core, the OS can interleave execution of processes to give the appearance of
parallelism.

20. Interprocess Synchronization

Process synchronization refers to coordinating the execution of processes to avoid conflicts, especially
when accessing shared resources. Key goals are:
Mutual Exclusion: Ensure that only one process enters a critical section (code segment accessing shared
data) at a time.

Progress and Bounded Waiting: Ensure that waiting processes eventually proceed and no starvation
occurs.

Without synchronization, race conditions can occur (as in Section 15) where the final result depends on
the unpredictable interleaving of processes. Common synchronization mechanisms include locks,
semaphores, monitors, and condition variables. These allow processes to explicitly wait for or signal
events so that shared resources are accessed safely.

21. Producer/Consumer (Bounded Buffer) Problem

The Producer-Consumer (bounded buffer) problem is a classic synchronization scenario: producers


generate data and put it into a fixed-size buffer, and consumers remove data for processing. Proper
synchronization is needed to ensure: producers wait if the buffer is full, and consumers wait if it is empty.
Semaphores or condition variables are typically used: one semaphore for buffer capacity (or count of
items) and another for mutual exclusion on the buffer. This problem illustrates the need for coordinating
multiple processes with limited shared resource.

22. Critical Section Problem

The critical section problem involves designing a protocol to allow processes to access shared data safely.
A critical section is a piece of code where a shared resource is accessed. The solution must satisfy three
conditions:

1. Mutual Exclusion: Only one process may be in its critical section at any time.

2. Progress: If no process is in the critical section and some want to enter, one of them must be able to
enter (no unnecessary delay).

3. Bounded Waiting: A bound exists on how many times other processes can enter their critical
sections before a waiting process is allowed in (no starvation).

Various algorithms solve the critical section problem under different assumptions (two-process case,
hardware support, etc.).

23. Peterson’s Solution

Peterson’s solution is a classic two-process mutual exclusion algorithm using only shared memory (two
flags and a turn variable). Each process sets its own flag to “want-in” and sets turn to the other process,
then waits until either the other’s flag is false or it is its turn. This ensures both mutual exclusion and
progress. It’s mainly of theoretical interest, demonstrating how two processes can synchronize correctly
without special hardware. Its essence: each process signals intent and defers to the other if needed,
guaranteeing one enters the critical section at a time.

24. Synchronization Hardware

Modern architectures provide hardware primitives to implement synchronization at the atomic level.
Examples include the Test-and-Set instruction and Compare-and-Swap. For instance, TestAndSet(lock)
atomically reads and sets a lock variable; if the old value was 0, the caller acquires the lock. Such atomic
instructions avoid race conditions by ensuring that checking and setting a value is indivisible. They form
the basis of spinlocks, mutexes, and other low-level synchronization tools.

25. Semaphores

A semaphore is a synchronization tool defined by an integer counter and two atomic operations, usually
called wait (P) and signal (V). There are two types: a counting semaphore (counter can range over
unrestricted values) and a binary semaphore (counter is 0 or 1, acting like a mutex). The wait operation
decrements the counter and may block the process if the count becomes negative (meaning the resource
isn’t available). The signal increments the counter and wakes a waiting process if any. Semaphores allow
multiple processes to synchronize access to a finite number of identical resources or to coordinate in
producer-consumer scenarios. They prevent race conditions when used correctly.

26. Classical Synchronization Problems

Some well-known synchronization problems include:

Bounded-Buffer (Producer-Consumer): Producers and consumers share a fixed-size buffer.

Readers-Writers: Multiple readers can read a shared database simultaneously, but writers require
exclusive access. Synchronization ensures no reader reads while a writer is writing.

Dining Philosophers: A set of philosophers alternately thinking and eating, each needing two forks (shared
with neighbors). The problem models resource locking to avoid deadlock and starvation.

Sleeping Barber: A barbershop with one barber, chairs, and clients arriving at random times. Ensures
proper queuing and notification.

These problems (often solved with semaphores or locks) illustrate different aspects of process
synchronization and mutual exclusion.

27. Deadlock

A deadlock is a situation in which a group of processes are each waiting indefinitely for events or resources
held by the others. In effect, none of the deadlocked processes can proceed because each is waiting for
another. For example, if Process A holds Resource 1 and waits for Resource 2, while Process B holds
Resource 2 and waits for Resource 1, both processes are stuck. Deadlock is a form of permanent blocking
where interlocked processes cannot make progress, and special handling is required to resolve or avoid it.
28. Deadlock Characterization

Deadlocks are characterized by the four Coffman conditions, which must hold simultaneously for deadlock
to occur:

1. Mutual Exclusion: At least one resource must be held in a non-sharable mode (only one process can
use the resource).

2. Hold and Wait: A process is holding at least one resource and waiting to acquire additional
resources that are currently held by other processes.

3. No Preemption: Resources cannot be forcibly taken from a process; a resource can only be released
voluntarily by the process holding it.

4. Circular Wait: There exists a set of processes {P1, P2, …, Pn} such that P1 waits for a resource held
by P2, P2 waits for a resource held by P3, and so on, with Pn waiting for a resource held by P1.

All four conditions must hold for a deadlock to exist; breaking any one of them will prevent deadlock.

29. Deadlock Prevention

Deadlock prevention ensures that at least one of the necessary conditions is never allowed to hold.
Strategies include:

Eliminate Hold-and-Wait: Require processes to request all needed resources at once or to release all
resources before requesting more. For example, a process must declare its maximum needs up-front.

Eliminate No-Preemption: If a process holding some resources requests another that cannot be
immediately allocated, then that process must release its held resources (possibly repeatedly).

Eliminate Circular-Wait: Impose a strict ordering on resource types and require processes to request
resources in increasing order of that ordering. This prevents cycles in the wait-for graph.

Eliminate Mutual Exclusion: Make resources shareable if possible. (Often impossible for exclusive devices
like printers, though techniques like spooling can help.)

By designing allocation policies that violate one of the Coffman conditions, a system can prevent deadlock.
For example, by making processes declare their maximum resource needs in advance, the OS ensures hold-
and-wait never occurs.

30. Deadlock Avoidance


Deadlock avoidance requires the OS to make resource allocation decisions dynamically based on future
needs. The system must know or be able to estimate each process’s future requests. One classic scheme is
the banker’s algorithm. Before granting a request, the OS simulates the allocation and checks if the system
would remain in a safe state. A safe state is one in which there is an ordering of all processes such that each
can finish with the available resources. If the request leads to an unsafe state (potential for deadlock), it is
denied. In other words, “avoidance” means only granting resource requests that keep the system in a state
where no deadlock is possible. Banker’s algorithm is the most well-known avoidance algorithm.

31. Resource Allocation Graph Algorithm

A Resource Allocation Graph (RAG) is a directed graph used to model resource allocation and detect
deadlocks. In the RAG, processes and resource types are nodes; a request edge (process→resource) or
assignment edge (resource→process) shows current status. For single-instance resources, the presence of
a cycle in the RAG is both necessary and sufficient for a deadlock. Specifically, “if there is a cycle in the RAG
and each resource in the cycle has only one instance, then the processes are deadlocked”. For multiple-
instance resources, a cycle may indicate potential deadlock but is not conclusive; further analysis (like
algorithms) is needed.

32. Banker’s Algorithm

The Banker’s algorithm is a deadlock avoidance algorithm that treats resource allocation like a banker
granting loans. It requires that each process declare in advance its maximum requirement for each
resource. When a process requests resources, the OS tentatively allocates them and then checks whether
the system will still be in a safe state after allocation. If safe, the request is granted; otherwise, the process
is made to wait. In effect, the algorithm “plays out” future scenarios to ensure the system never enters an
unsafe (deadlock-prone) state. The main data structures include matrices of current allocation, maximum
need, and available resources, and the safety check involves simulating process completions. While
powerful, it requires knowing maximal resource needs in advance and can be costly to compute.

33. Deadlock Detection

If the OS does not prevent or avoid deadlock, it must detect deadlocks at runtime. Detection involves
identifying cycles or unsafe conditions. For single-instance resources, detection can be done by searching
the RAG for cycles (which imply deadlock). For multiple instances, the OS can use algorithms similar to the
bankers’ safety check to see if a set of processes can finish. A simpler model is the wait-for graph, where
edges go directly between processes. If a cycle is found in the wait-for graph, those processes are
deadlocked. In practice, the OS periodically runs detection algorithms to check for deadlocks among
processes.

34. Recovery from Deadlock

Once a deadlock is detected, the system must recover. Common recovery strategies include:

Process termination: Abort one or more deadlocked processes to break the cycle. Options are to terminate
all involved processes or terminate them one by one, possibly based on priority or cost.
Resource preemption: Temporarily take resources away from some processes to satisfy others. This
involves rolling back processes to previous safe states, if supported.

Process rollback: Restart processes from a checkpoint with fewer resources, hoping not to deadlock again.

In any case, recovery often involves freeing resources or killing processes, which can be costly. Therefore,
many systems aim to avoid or prevent deadlock rather than rely on recovery.

35. Memory Management

Memory management is the OS function that handles allocation and deallocation of main memory (RAM) to
processes. The OS keeps track of which parts of memory are in use and which are free, and maps processes’
logical addresses to physical addresses. The main goal is to use memory efficiently, enabling multiple
processes to run simultaneously while protecting their address spaces from each other. Memory
management involves techniques like partitioning, paging, segmentation, and virtual memory. It also deals
with fragmentation (both internal and external) and swapping or paging data between RAM and disk.

36. Multiprogramming with Fixed Partitions

In fixed-partition (static partitioning) memory allocation, the OS divides memory into a fixed number of
partitions (either equal or different sizes) at boot time. Each partition can hold at most one job. When a
process needs memory, the OS finds a free partition large enough and loads the process there. Advantages
include simplicity and low allocation overhead. However, it suffers from internal fragmentation (if a
process is smaller than its partition, the leftover space is wasted) and limits the number of concurrent
processes to the number of partitions. It also cannot easily adjust to changing process memory needs.

37. Multiprogramming with Variable Partitions

Variable-partition (dynamic partitioning) allocation does not predefine partition sizes. Instead, when a
process arrives, the OS allocates exactly enough contiguous memory to fit it. After processes finish, their
memory is freed and may form external fragmentation over time. To manage free space, techniques like
compaction (shuffling memory contents to create a large free block) may be used. Variable partitioning is
more flexible (no internal fragmentation except for small leftover within the allocated block) but can lead
to external fragmentation as processes come and go.

38. Paging

Paging is a memory-management scheme that eliminates the need for contiguous allocation of physical
memory. The OS divides physical memory into fixed-size blocks called frames and logical memory into
blocks of the same size called pages. When a process is loaded, its pages can be placed into any available
frames in memory (possibly non-contiguously). A page table is maintained for each process to map logical
page numbers to physical frame numbers. When a process generates an address, the page number and
offset are looked up in the page table to form the physical address. Paging avoids external fragmentation
(since any free frame can be used) but can suffer internal fragmentation (unused space in the last page of a
process). It also requires a translation lookaside buffer (TLB) to speed up address translation.

39. Segmentation
Segmentation is a memory allocation scheme where a process’s address space is divided into variable-
sized segments, each corresponding to a logical unit (e.g., code module, array, stack). Each segment has a
base and length. Unlike paging, segments reflect the program’s logical structure. In a segmented system,
processes have segment tables with (base, limit) pairs. Segmentation provides a user-view segmentation
(like multiple address spaces per process) and prevents internal fragmentation since segments fit their
content exactly. However, it can cause external fragmentation because segments are different sizes. (Some
systems combine segmentation and paging to get benefits of both.)

40. Paged Segmentation

Paged segmentation is a hybrid memory scheme combining paging and segmentation. In this scheme, the
process’s address space is first divided into segments (each with a logical size), and then each segment is
further divided into fixed-size pages. The physical memory is divided into frames. Each segment has its
own page table. This provides segmentation benefits (logical division) and paging benefits (no external
fragmentation within segments). Address translation is two-level: first using the segment number to find
the segment’s page table, then the page number to find a frame.

(A related concept is segmented paging, where logical addresses consist of a segment and an offset, and
segment tables map to sets of pages.)

41. Virtual Memory Concepts

Virtual memory gives the abstraction of a large contiguous memory space, even if physical RAM is limited.
Programs can be larger than physical memory; only needed parts (pages or segments) are loaded. Virtual
memory uses disk space (the swap area) to hold parts of processes that are not currently in RAM. The main
idea is demand loading: bring a page into memory only when it is actually needed (on a memory access).
This allows more processes to be resident and enables multiprogramming. The OS, using paging or
segmentation, translates virtual (logical) addresses into physical addresses, often via a page table. The
result is that each process can behave as if it has a large private memory space.

42. Demand Paging

With demand paging, pages are loaded into memory only when referenced by the process, rather than all
at process start. When a process tries to access a page not in memory, a page fault occurs, and the OS brings
the required page from disk into a free frame (possibly evicting another page if needed). Demand paging
reduces initial load time and memory usage, since only needed pages occupy RAM. It’s a lazy loading
technique. The steps on a page fault include: save the faulting process’s state, locate and read the page from
disk, update the page table, and resume the process. Demand paging can greatly increase the effective
memory available but requires page-fault handling.

43. Performance of Demand Paging

Demand paging introduces overhead from page faults. The effective memory access time becomes a
weighted average: if the page fault rate is p, memory reference time is m, and page fault service time is s,
then $$T_{\text{effective}} = (1-p)\times m + p \times s$$. Because s (reading from disk) is much larger
than m, even a small page fault rate can severely slow performance. If p is high, the system may spend most
of its time swapping (thrashing). Thus, minimizing page faults via good algorithms and having sufficient
RAM are crucial for demand paging performance.

44. Page Replacement Algorithms

When memory is full, the OS must choose which resident page to evict to load a new page. Common page
replacement algorithms include:

FIFO (First-In, First-Out): Evict the page that has been in memory the longest. Simple but can be suboptimal
(Belady’s anomaly).

Optimal: Replace the page that will not be used for the longest future time. (Impossible in practice, used as
a benchmark.)

LRU (Least Recently Used): Evict the page that has not been used for the longest time, approximating
Optimal.

Second-Chance Clock: A practical approximation of LRU using a circular buffer and a “referenced” bit.

Others: LFU (least frequently used), MRU, etc.

Each algorithm balances overhead (tracking usage) against miss rate. For example, LRU minimizes faults
under many workloads but requires hardware or software support for access tracking. Page replacement
is critical to virtual memory efficiency.

45. Thrashing

Thrashing occurs when a system spends more time servicing page faults than executing processes, due to
insufficient physical memory for active processes. In this state, processes continually swap pages in and
out (due to a high working set size or too many processes), causing very low CPU utilization and
performance. The system can even become effectively deadlocked on paging. Thrashing is typically
detected by low CPU utilization despite high paging activity, and is addressed by reducing
multiprogramming level (suspending or swapping out some processes) to restore a healthy working set
size.

46. Process Communication

Interprocess communication (IPC) allows processes to exchange data and coordinate execution.
Independent processes have no IPC, but cooperating processes need communication channels. IPC
techniques provide mechanisms so processes can communicate without interfering with each other. The
OS typically implements two fundamental models:

Shared Memory: A segment of memory is mapped into the address space of cooperating processes. They
can read and write to this shared segment for communication. Requires synchronization (e.g., locks or
semaphores) to avoid race conditions. It is fast, since processes communicate by simple memory
reads/writes.
Message Passing: Processes communicate by sending and receiving messages through the OS (e.g., using
pipes, sockets, or system calls). This can be either synchronous (blocking) or asynchronous, and can use
direct (explicit process IDs) or indirect (mailboxes or ports) addressing. The OS provides primitives such
as send() and receive() to implement this model.

Both models can be implemented by an OS; choice depends on system design (distributed systems often
use message passing, while multi-threaded programs may prefer shared memory).

47. Models and Schemes of IPC

In practice, IPC schemes include variations of the above models:

Direct vs Indirect Messaging: Direct message passing means processes must know each other’s identifiers.
Indirect means messages go to named mailboxes or ports.

Blocking (Synchronous) vs Non-Blocking (Asynchronous): In blocking mode, a send waits until the receiver
has received the message, and/or a receive waits until a message is available. In non-blocking mode,
send/receive return immediately (possibly with a status).

Uni/Multicast: Message can be sent to a single recipient (unicast) or broadcast to multiple processes.

Shared Memory Synchronization: Within shared memory, processes use synchronization primitives
(mutexes, semaphores) to coordinate access to shared data.

For example, in UNIX, pipes and sockets implement message passing, while mmap() or SysV shared
memory provide shared memory IPC. The OS ensures that communication methods are reliable and
respect protection (one process cannot read another’s memory without permission).
48. File System Structure

A file system organizes data on storage (disk) into files and directories in a logical hierarchy. Typically,
there is a single root directory, and everything else is a subtree. The structure includes:

Files: Named collections of related data. Each file has metadata (size, timestamps, permissions, etc.) and
data blocks.

Directories: Special files that list other files and directories. They form a tree (or directed acyclic graph)
structure.

Inodes (or File Control Blocks): Data structures that store metadata for each file (owner, access rights, and
pointers to data blocks). UNIX-like systems use inodes, while others may use a File Allocation Table (FAT)
or master file table (MFT).

Superblock/Volume Header: Contains info about the file system layout (size, free space pointers, etc.).
In summary, the file system provides a name space, mapping file names (paths) to data on disk, and defines
how files, directories, and their metadata are structured and accessed.

49. File System Implementation

File system implementation covers how the OS actually manages on-disk data structures. Key aspects
include:

Directory Implementation: How directories (the mapping from names to files/inodes) are stored (linked
lists, hash tables, B-trees) and accessed. (See next section.)

File Allocation: Techniques to map files to disk blocks: contiguous (a file occupies consecutive blocks),
linked (each block points to the next), or indexed (an index block lists all block locations).

Free Space Management: Tracking which disk blocks are free (bitmaps, free lists, etc.; see later).

Caching and Buffering: The OS uses memory buffers to cache file data and metadata for performance,
writing back to disk later.

Permissions and Security: Enforcing access controls (user/group IDs, ACLs) stored with inodes.

Performance: Optimizations like cluster allocation (grouping blocks into clusters) to reduce overhead.

The OS’s file system code handles system calls (open, read, write, close) by consulting these structures. For
instance, to open a file, the OS parses the directory structure to find the file’s inode, then loads or prepares
the first data blocks as needed.

50. Directory Implementation and Allocation Methods

Directory implementation: OSs can implement directories in several ways:

Linked List: Store file names in a simple list (or linear array) with pointers to data blocks. Easy to
implement but slow to search, especially for large directories.

Hash Table: Hash file names to buckets, with entries pointing to files. Speeds up lookup but can waste
space or require handling collisions.

Tree or B-tree: Used in many modern systems (e.g., NTFS, ext4) to allow faster insert and lookup.

Each directory scheme affects lookup and maintenance cost.

File allocation methods: Determining how file data is laid out on disk:

Contiguous Allocation: A file’s blocks are stored contiguously. The directory entry records a starting block
and length. Fast sequential access and easy indexing, but causes external fragmentation and difficulty
growing files.
Linked Allocation: Each file is a linked list of disk blocks (each block contains a pointer to the next). No
fragmentation, but random access is slow (must follow pointers).

Indexed Allocation: Each file has an index block containing pointers to all its data blocks. Allows direct
access to any block (like an inode pointing to blocks). Managing the index adds overhead, but it’s a flexible
general scheme.

Choosing a method involves trade-offs in speed versus space efficiency and complexity.

51. Free Space Management

Free space management keeps track of unused disk blocks so the OS can allocate them to files. Common
techniques include:

Bitmap (Bit Vector): A bitmap or bit vector where each bit represents a disk block. A 1 might indicate free,
and 0 used (or vice versa). To allocate, the OS scans for a free bit. This is simple and allows quickly
counting free blocks, but scanning for a free bit can be slow. Modern OSs use bitmaps (e.g., ext file systems)
due to simplicity.

Linked List: Free blocks are linked together (often with a pointer in each free block to the next free block).
The free blocks form a linked list, and the OS keeps a pointer to the first free block. This saves space for the
free list but can be slower to search or update.

Grouping: A variation of linked list. The first free block contains pointers to several subsequent free blocks,
and the last block in that group points to another group, and so on. This reduces the pointer overhead
compared to simple linking each block.

Counting: Also called a free-block list with counts. One entry consists of a pointer to a free block and a
count of how many contiguous free blocks follow it. This is efficient when many contiguous free blocks
exist; the OS need only update one entry for an allocation of several blocks.

Each method has trade-offs: bitmaps use space for the map but make counting free space easy, while lists
save space but can be slower. For example, the Linux ext4 filesystem uses a bitmap, whereas older systems
like FAT use a linked list (FAT table) approach.

The OS updates the free space data structure on file creation/deletion. For instance, when a file is deleted,
its freed blocks are added back to the free list or bitmap. Using a bitmap, setting a bit to 1 marks it free. All
of these schemes allow the OS to find free blocks for new or extending files efficiently.

52. Kernel I/O Subsystem

The kernel I/O subsystem is the OS component that manages all input/output operations and devices. It
provides a uniform interface to device drivers so that applications can perform I/O without knowing
hardware details. Key roles include:
Device Drivers: Kernel code specific to each device (disk, network card, etc.) that implements control and
communication (often via interrupts or polling).

I/O Scheduling and Buffering: Managing I/O request queues and caching/buffering data (read-ahead,
write-behind) to improve throughput.

Spooling: Managing devices like printers via queues so multiple jobs can share a single device seamlessly.

Error Handling: Detecting and handling device errors to maintain system stability.

Unified Interface: Offering system calls (e.g. read(), write()) that device drivers implement, so applications
use simple calls regardless of device specifics.

In essence, the kernel I/O subsystem translates application I/O requests into low-level hardware
commands and ensures data is transferred reliably between the system and external devices.

53. Disk Structure

A disk is composed of one or more rotating platters (surfaces) with read/write heads that move radially.
Each platter surface is divided into concentric tracks, and each track is divided into sectors (usually 512
bytes). A cylinder is the set of tracks at the same radius on all platters (i.e., tracks aligned vertically). For
example, “tracks of all discs which have the same track value are called a cylinder”. Disk geometry
(cylinder/head/sector) was used for addressing, though modern drives often use logical block addressing.
Disks may also have surfaces (platter sides) enumerated by “head” number. Understanding this structure
helps optimize disk scheduling: accessing blocks on the same cylinder avoids seek delays, and sectors
allow transferring blocks in a burst while the head is over the track.

54. Disk Scheduling

Disk scheduling algorithms determine the order in which disk I/O requests are serviced to minimize seek
time and rotational latency. Key performance terms include seek time (moving the head) and rotational
latency (waiting for the sector). Common disk scheduling algorithms are:

FCFS: Simple queue order; fair but can incur long seeks.

SSTF (Shortest Seek Time First): Select the request closest to current head position; reduces seek distance
but can starve requests far away.

SCAN (Elevator): The disk arm moves in one direction, servicing all requests until it reaches the end, then
reverses direction (like an elevator). Good overall performance.

C-SCAN: Similar to SCAN, but when reaching the end, the arm quickly returns to the beginning without
servicing requests on the return trip, providing more uniform wait time.

LOOK/C-LOOK: Like SCAN/C-SCAN but the arm only goes as far as the last request in each direction before
reversing (not to the physical end). This avoids unnecessary travel to end cylinders.
These algorithms optimize different criteria (minimizing total head movement, providing fairness, etc.).
For example, SCAN and C-SCAN reduce the variance in response time compared to FCFS.

55. Disk Management

Disk management involves all activities to initialize and maintain storage media. Key tasks include:

Partitioning: Dividing a physical disk into one or more partitions (each treated as a separate disk). Each
partition can have its own file system. This provides organization and protection (a crash in one partition
doesn’t affect others). For example, the OS “partitions the disk into one or more groups of cylinders” and
treats each partition as separate.

Formatting: Creating a file system on a partition (e.g., making an empty FAT or ext4). This involves writing
boot records, superblocks, and initializing free space structures. The OS may group disk blocks into
clusters (e.g., 512-byte sectors vs 4KB clusters) for efficiency.

Boot Blocks: The first block (or few) of a bootable partition contains the bootstrap loader. On startup, the
BIOS/firmware loads this boot block to begin loading the OS.

Volume Mounting: Associating file systems with directory trees (in multi-user OSes).

Error Checking and Recovery: Tools like fsck inspect and repair file system inconsistencies.

Space Management: Managing logical blocks, bad block remapping, and ensuring data reliability with
mirroring or RAID in some systems.

In summary, disk management includes creating partition tables, initializing file systems, handling boot
processes, and ensuring data integrity. Its goal is to “efficiently utilize the available storage space and
ensure data integrity”.

56. Swap Space Management

Swap space (or swap file/partition) is disk space used to extend physical memory. The OS moves entire
processes or pages out of RAM into swap when memory is overcommitted. Swapping is the act of moving a
process from RAM to swap (swap-out) and back (swap-in). By using disk as extra memory, the OS increases
the number of processes that can be in memory (multiprogramming). Swap management thus tracks free
areas of the swap space and allocates them for pages or processes being swapped out. While swap allows
more processes to run, accessing swap is much slower than RAM (leading to latency), so excessive
swapping (thrashing) is undesirable. Proper swap management (and choosing swap size) helps balance
memory demands against performance.

You might also like