# OPerating system imp. topics # ⚡ Purpose of Operating System (with Example) * **Purpose**: To act as a **bridge between hardware and user/programs**, managing resources efficiently. * **Example**: Without OS → To type a letter, you’d need to write raw instructions for keyboard, monitor, and printer. With OS → Windows/Linux handles keyboard input, stores file, and sends it to printer automatically. --- # ⚡ Types of Operating Systems (with Examples) 1. **Batch OS** * Jobs collected and executed in batches, no user interaction. * **Example**: IBM mainframes (early punch card systems). 2. **Time-Sharing OS** * CPU switches between tasks rapidly → multiple users feel like they have dedicated system. * **Example**: **UNIX, Linux, Windows Server** (multi-user environments). 3. **Real-Time OS (RTOS)** * Strict timing → tasks must finish within deadline. * **Hard RTOS**: Pacemakers, flight control systems. * **Soft RTOS**: Video streaming, online gaming. * **Examples**: **QNX, VxWorks, FreeRTOS**. 4. **Distributed OS** * Manages multiple computers as a single system. * **Example**: **Google File System, Amoeba OS, Hadoop Distributed File System (HDFS)**. 5. **Embedded OS** * Runs on small devices with limited resources. * **Examples**: **Smart TV OS, Router OS, Android Wear OS, iOS in iPhones**. # ⚡ Process vs Thread vs Program | Aspect | **Program** | **Process** | **Thread** | | --- | --- | --- | --- | | **Definition** | A passive set of instructions (code stored on disk). | An active execution of a program (running instance). | A lightweight execution unit within a process. | | **State** | Static (does nothing until executed). | Dynamic (has state: running, waiting, ready). | Dynamic (shares state with other threads of same process). | | **Memory** | Stored on secondary storage (disk). | Has its own memory space (Code, Data, Heap, Stack). | Shares code, data, and heap of the process but has its own stack & registers. | | **Resource** | Needs CPU + memory only when executed. | Needs resources (CPU, memory, files, I/O devices). | Shares resources of its parent process. | | **Overhead** | No overhead (just stored file). | High overhead (context switching between processes is heavy). | Low overhead (context switch between threads is faster). | | **Example** | `chrome.exe` file on your disk. | Opening Chrome (process created). | Chrome tabs (each tab is a thread). | --- ### **Example Analogy** * **Program** → A recipe written in a cookbook (instructions). * **Process** → A chef actually following the recipe to cook. * **Thread** → Multiple assistants working on different parts of the recipe simultaneously (cutting veggies, boiling water). # ⚡ Multiprogramming vs Multiprocessing vs Multitasking vs Multithreading | Feature | **Multiprogramming** | **Multiprocessing** | **Multitasking** | **Multithreading** | | --- | --- | --- | --- | --- | | **Definition** | Multiple programs kept in memory, CPU switches between them to improve utilization. | System with **multiple CPUs/cores** working simultaneously. | Multiple tasks (processes) handled by **one CPU** by switching fast. | Multiple threads run within a single process concurrently. | | **Key Idea** | Increases CPU utilization. | True parallelism using many CPUs. | User can do many tasks at once (illusion of parallelism). | Lightweight parallelism inside a process. | | **Execution Unit** | Processes | Processes across CPUs | Tasks (processes) | Threads within a process | | **Hardware** | Single CPU | Multiple CPUs | Single CPU (time-sharing) | Single or multi-core CPU | | **Example** | Running **MS Word + Browser + Music Player** loaded into memory, CPU executes one at a time. | A **server with 8 cores** handling 8 requests truly in parallel. | On your **PC**, you type in Word while a song plays (OS switches tasks fast). | In Chrome, each **tab** is a thread inside Chrome’s process. | --- ### ✅ Quick One-Liners (Interview Mode): * **Multiprogramming** → CPU switches between programs → improves utilization. * **Multiprocessing** → Multiple CPUs → true parallelism. * **Multitasking** → One CPU runs many tasks by time-sharing → gives illusion of parallelism. * **Multithreading** → Multiple threads inside one process share resources but run independently. --- ### ⚡Analogy (Easy to Remember): * **Multiprogramming** → A single cook has many dishes on the counter → works on one at a time. * **Multiprocessing** → Multiple cooks in the kitchen → each can cook a dish at the same time. * **Multitasking** → One cook chopping veggies, then stirring soup, then checking oven → switching fast. * **Multithreading** → One dish (say pizza) being prepared by multiple assistants → one kneads dough, one cuts toppings, one preheats oven. --- # ⚡ Various States of a Process A **process** (running program) goes through different **states** during execution. --- ## **1\. New (Created State)** * Process is **just created**, not yet admitted into the ready queue. * **Example**: You double-click on `chrome.exe`, OS creates PCB (Process Control Block). --- ## **2\. Ready State** * Process is in **main memory**, waiting for CPU. * Not running yet, but ready to run. * **Example**: Chrome is waiting for CPU time, but CPU is currently busy with Spotify. --- ## **3\. Running State** * Process is being **executed by CPU**. * Only **one process per CPU core** can be in running state at a time. * **Example**: CPU executing Chrome’s rendering engine. --- ## **4\. Waiting / Blocked State** * Process cannot continue until an **I/O operation completes** or an event occurs. * **Example**: Chrome waiting for data from the internet (I/O). --- ## **5\. Terminated (Exit State)** * Process has finished execution and resources are released. * **Example**: You close Chrome tab → process ends. --- ## 🔄 **State Transition Diagram** ```plaintext New → Ready → Running → Terminated ↑ ↓ Waiting ←---- ``` * **New → Ready** → admitted into memory. * **Ready → Running** → CPU scheduler picks it. * **Running → Waiting** → needs I/O. * **Running → Ready** → preempted by higher priority process. * **Running → Terminated** → finished execution. # ⚡ CPU Scheduling Algorithms --- ## **1\. First Come First Serve (FCFS)** * **Idea**: Process that arrives first gets CPU first (like a queue). * **Type**: Non-preemptive. * **Example**: If processes arrive in order **P1(5), P2(3), P3(8)** → execution order: P1 → P2 → P3. * **Pros**: Simple, fair. * **Cons**: *Convoy effect* (short jobs wait behind long jobs). --- ## **2\. Shortest Job First (SJF)** * **Idea**: Process with **smallest CPU burst** is scheduled first. * **Type**: Can be Non-preemptive or Preemptive (Shortest Remaining Time First → SRTF). * **Example**: P1(8), P2(4), P3(2) → order: P3 → P2 → P1. * **Pros**: Optimal average waiting time. * **Cons**: Requires knowing burst time (hard in real life). --- ## **3\. Shortest Remaining Time First (SRTF)** * **Idea**: Preemptive SJF → if a new process arrives with shorter burst, it **preempts** current. * **Example**: P1(8) running, then P2(4) arrives → CPU switches to P2. * **Pros**: Better response time. * **Cons**: More context switching. --- ## **4\. Priority Scheduling** * **Idea**: Process with **highest priority** runs first. * **Type**: Can be Preemptive or Non-preemptive. * **Problem**: **Starvation** (low-priority may never run). * **Solution**: **Aging** → increase priority over time. * **Example**: P1(priority 3), P2(priority 1), P3(priority 2) → order: P2 → P3 → P1. --- ## **5\. Round Robin (RR)** * **Idea**: Each process gets a **fixed time quantum** in rotation. * **Type**: Preemptive. * **Example**: Time quantum = 2, processes P1(5), P2(3), P3(4) → order: P1(2), P2(2), P3(2), P1(2), P2(1), P3(2), P1(1). * **Pros**: Good for time-sharing (interactive systems). * **Cons**: Too large quantum → like FCFS, too small → many context switches. --- ## ✅ Short Interview Answer: * **FCFS** → Fair but bad for short jobs. * **SJF** → Best avg wait time but needs burst info. * **SRTF** → Preemptive SJF, better response but costly. * **Priority** → Based on priority, but may starve → solved by Aging. * **Round Robin** → Best for time-sharing systems, fair response time. --- # ⚡ Critical Section Problem ### **What is a Critical Section?** * A **critical section** is a piece of code where a **shared resource** (like a variable, file, or database) is accessed. * Only **one process/thread** should execute inside the critical section at a time → otherwise **data inconsistency** may occur. **Example:** * Two people withdrawing money from the same bank account at the same time. * If both read balance = ₹1000 at once and withdraw ₹700 each, without synchronization the final balance may incorrectly become ₹3000 or -₹400. --- ### **Critical Section Problem** The problem is **how to ensure that when one process is in its critical section, no other process can enter it**. --- ## ✅ Solution must satisfy 3 conditions: 1. **Mutual Exclusion** → Only one process in the critical section at a time. 2. **Progress** → If no process is in the critical section, some waiting process should be allowed to enter. 3. **Bounded Waiting** → No process should wait forever to enter (avoid starvation). --- ## **Ways to Solve It** * **Software solutions** → Peterson’s Algorithm, Dekker’s Algorithm. * **Hardware solutions** → Test-and-Set, Compare-and-Swap instructions. * **Synchronization tools** → * **Semaphores** → `wait()` and `signal()` for access control. * **Mutex Locks** → Ensures mutual exclusion. * **Monitors** (in Java/C#) → High-level synchronization. --- ## **Real-Life Analogy** Imagine a **public washroom with one key** 🔑: * If one person has the key (mutex lock), others must wait outside. * When they leave, they return the key (signal). * This ensures mutual exclusion, progress, and fairness. --- ## ✅ Short Interview Answer: The **critical section problem** arises when multiple processes access shared resources. A solution must ensure **mutual exclusion, progress, and bounded waiting**. It is solved using **locks, semaphores, or monitors** in operating systems. --- # ⚡ Process Synchronization ### **What is it?** * **Process Synchronization** is a way to **coordinate multiple processes/threads** so they don’t interfere with each other when accessing **shared resources**. * Goal: **Avoid race conditions** (when output depends on the timing of processes). --- ### **Why do we need it?** * Suppose two threads access a shared variable `counter = 5`. * Thread A reads `5`, increments → `6`. * Thread B reads `5`, increments → `6`. * Final result should be `7`, but we got `6`. This is a **race condition**. Synchronization prevents it. --- ## ✅ Conditions for Correct Synchronization (Critical Section Problem rules) 1. **Mutual Exclusion** → Only one process executes in critical section at a time. 2. **Progress** → If no one is in the critical section, some waiting process must get a chance. 3. **Bounded Waiting** → No process should wait indefinitely. --- ## 🔧 **Synchronization Mechanisms** ### **1\. Locks (Mutex)** * Only one thread can hold the lock → others wait. * Example (Bank ATM): Only one person withdraws at a time. --- ### **2\. Semaphores** * Integer variable used for signaling. * **Binary Semaphore (0/1)** → like a mutex (lock/unlock). * **Counting Semaphore** → allows limited number of processes. * Example: A parking lot with **10 slots** → semaphore initialized to 10 → each car reduces count. --- ### **3\. Monitors** * High-level synchronization construct (used in Java, C#). * Only one process can execute a monitor procedure at a time. * Example: `synchronized` keyword in Java. --- ### **4\. Classical Problems (Interview Favorites)** * **Producer-Consumer Problem** → producer generates items, consumer uses them → solved with semaphores. * **Dining Philosophers Problem** → philosophers need 2 forks → deadlock if not synchronized. * **Readers-Writers Problem** → many readers allowed, but only one writer at a time. --- ## ✅ Short Interview Answer: Process synchronization ensures **safe and coordinated execution of concurrent processes**, preventing race conditions. It is implemented using **locks, semaphores, and monitors**, and must satisfy **mutual exclusion, progress, and bounded waiting**. Perfect Rahul 🚀 — **Deadlocks** are a **core OS concept** and interviewers love to ask both **theory + examples**. Let’s make this simple and crisp. --- # ⚡ Deadlock in OS ### **What is a Deadlock?** A **deadlock** is a situation where a set of processes are **permanently blocked**, each waiting for a resource held by another process. **Example:** * Process P1 holds **Printer**, wants **Scanner**. * Process P2 holds **Scanner**, wants **Printer**. 👉 Both wait forever = **Deadlock**. --- ## ✅ Conditions for Deadlock (Coffman’s Conditions) A deadlock occurs if **all 4 conditions** hold simultaneously: 1. **Mutual Exclusion** → Only one process can use a resource at a time. 2. **Hold and Wait** → Process holds one resource while waiting for another. 3. **No Preemption** → A resource can’t be forcibly taken. 4. **Circular Wait** → A circular chain of processes exists, each waiting for the next. --- # ⚡ Deadlock Handling Techniques We can handle deadlocks in **4 ways**: --- ## **1\. Deadlock Prevention** 👉 Ensure that at least one of the 4 conditions never holds. * Remove **Hold and Wait** → request all resources at once. * Remove **Circular Wait** → enforce ordering of resources (e.g., always request Printer before Scanner). * Remove **No Preemption** → allow OS to preempt resources. **Pros**: Ensures deadlock won’t happen. **Cons**: Wastes resources, reduces concurrency. --- ## **2\. Deadlock Avoidance** 👉 Use extra info (like max resources needed) and decide safely. * **Banker’s Algorithm** → Checks if granting resources keeps the system in a **safe state**. **Pros**: Efficient, avoids deadlock. **Cons**: Needs prior info of resource needs. --- ## **3\. Deadlock Detection & Recovery** 👉 Allow deadlock, but detect and fix it. * Use **resource allocation graph** to detect cycles. * Recovery methods: * Kill a process (abort). * Preempt resources from processes. **Pros**: No need to restrict requests. **Cons**: Overhead of detection + recovery may cause performance loss. --- ## **4\. Deadlock Ignorance** 👉 Just **ignore** deadlock and assume it rarely happens. * Used in **Windows, Linux**. * If system hangs, user must restart process/OS. **Pros**: Simple, no overhead. **Cons**: Risk of system hang. Nice pick Rahul 🙌 — **Memory Management** is a key OS interview topic. Let me break it down **step by step, with examples**, so you can explain clearly in interviews. --- # ⚡ Memory Management in Operating System ### **What is Memory Management?** * Memory management is the process of **allocating and deallocating memory** to programs, and keeping track of each location in memory. * It ensures **efficient utilization of RAM** while providing **isolation between processes**. --- # ✅ Functions of Memory Management 1. **Allocation** → Assign memory to processes. 2. **Deallocation** → Free memory after process terminates. 3. **Protection** → Prevent one process from accessing another’s memory. 4. **Address Translation** → Convert logical addresses (used by programs) into physical addresses (actual RAM). 5. **Swapping** → Move processes between main memory and disk (virtual memory). --- # ⚡ **Fixed Partitioning vs Dynamic Partitioning** Two approaches that we used in the memory management : ## **1\. Fixed Partitioning (Static Partitioning)** * Memory is divided into **fixed-size partitions** at system startup. * Each partition holds exactly one process. * Size of partitions **cannot change**. ✅ **Advantages:** * Simple to implement. * Easy to allocate because partition sizes are predefined. ❌ **Disadvantages:** * **Internal Fragmentation** → if a partition is 100MB but process needs 60MB → 40MB wasted. * Limited number of partitions → limits multiprogramming. 📌 **Example:** Suppose 1GB RAM divided into 4 partitions of 256MB each. * Process A = 200MB → occupies 1 partition (56MB wasted). * Process B = 300MB → cannot fit in any partition → **rejected**. --- ## **2\. Dynamic Partitioning** * Memory is divided **dynamically based on process size** at runtime. * No fixed partitions → partitions are created when a process arrives. ✅ **Advantages:** * Reduces **internal fragmentation** (since partition matches process size). * Better memory utilization. ❌ **Disadvantages:** * **External Fragmentation** → free memory is scattered into small holes between processes. * Requires **compaction** (rearranging processes to combine free space). 📌 **Example:** Suppose 1GB RAM. * Process A = 200MB → allocated 200MB partition. * Process B = 300MB → allocated 300MB partition. * Process A finishes → leaves 200MB free in between. * New Process C = 250MB → cannot fit in 200MB gap even though enough total memory exists → **external fragmentation**. # ⚡ **First-Fit, Best-Fit, Worst-Fit Algorithms** When a process requests memory, the OS looks into the **free memory blocks (holes)** and allocates based on these strategies. --- ## **1\. First-Fit** * Allocate the **first free block** that is large enough. * Searching starts from the beginning of memory and stops once a suitable block is found. ✅ **Advantage:** Fast, simple. ❌ **Disadvantage:** May leave small unused gaps near the beginning (external fragmentation builds up quickly). 📌 **Example:** Free blocks = \[100MB, 500MB, 200MB, 300MB\] Process needs 180MB → allocated to **200MB block** (first fit). Remaining: \[100MB, 500MB, (20MB free), 300MB\] --- ## **2\. Best-Fit** * Allocate the **smallest block that is large enough**. * Searches the entire list of free blocks → to minimize leftover space. ✅ **Advantage:** Reduces wasted space in each allocation. ❌ **Disadvantage:** Time-consuming (must search all), leaves many very small unusable gaps → external fragmentation. 📌 **Example:** Free blocks = \[100MB, 500MB, 200MB, 300MB\] Process needs 180MB → best-fit is **200MB block** (since it’s the smallest that fits). Remaining: \[100MB, 500MB, (20MB free), 300MB\] --- ## **3\. Worst-Fit** * Allocate the **largest free block available**. * Idea: Leave big leftovers, so that other processes can use them later. ✅ **Advantage:** Fewer, but larger holes (can fit future processes). ❌ **Disadvantage:** May waste large memory blocks unnecessarily. 📌 **Example:** Free blocks = \[100MB, 500MB, 200MB, 300MB\] Process needs 180MB → worst-fit is **500MB block**. Remaining: \[100MB, (320MB free), 200MB, 300MB\] --- # ⚡ **Paging in Operating Systems** 📌 **Definition:** Paging is a memory management technique where the **logical address space** (process) is divided into fixed-size blocks called **pages**, and the **physical memory** is divided into fixed-size blocks called **frames**. * Pages ↔ Frames (same size) * A page of the process can be placed into **any available frame**. --- ## 🔹 **Key Concepts** 1. **Page (Process side)** → Fixed-size block of the logical address space. 2. **Frame (Memory side)** → Fixed-size block of physical memory. 3. **Page Table** → Maintains the mapping between **pages** and **frames**. 👉 This allows **non-contiguous allocation** of memory while avoiding external fragmentation. --- ## 🔹 **How Paging Works** 1. A process is divided into pages (say 4 KB each). 2. Main memory is divided into frames (also 4 KB each). 3. When a process is executed, its pages are loaded into **available frames** (not necessarily contiguous). 4. The **Page Table** maps each page number to its corresponding frame number. --- ## 🔹 **Address Translation** A logical address consists of: * **Page number (p)** → Index into page table. * **Page offset (d)** → Location within the page. Physical address = **Frame number + Offset** --- ## 📌 **Example** Suppose: * Logical address space = 8 pages (0–7), each of **1 KB** * Physical memory = 32 frames, each of **1 KB** A process needs 4 pages → loaded into **random free frames**: | Page | Frame | | --- | --- | | 0 | 5 | | 1 | 9 | | 2 | 1 | | 3 | 7 | If the CPU generates **logical address (page 2, offset 100)** → * Page 2 → Frame 1 * Physical address = (Frame 1 start address + offset 100) --- ## 🔹 **Advantages** ✅ Eliminates **external fragmentation** ✅ Allows efficient and flexible memory use ✅ Supports demand paging (used in Virtual Memory) --- ## 🔹 **Disadvantages** ❌ Introduces **internal fragmentation** (last page may not be fully used) ❌ Extra overhead due to **Page Table lookups** (solved by TLB – Translation Lookaside Buffer) --- # ⚡ Virtual Memory in Operating System ## 🔹 What is Virtual Memory? * **Virtual Memory** is a memory management technique that gives an **illusion of a very large main memory** to processes, even though the system has **limited physical RAM**. * Implemented using **paging** or **segmentation**. * It allows programs to be **larger than physical memory** by storing parts of the program on **disk (secondary storage)** and loading them into RAM only when needed. --- ## 🔹 How it Works 1. Each process thinks it has a large continuous block of memory (called **virtual address space**). 2. The OS + **MMU (Memory Management Unit)** translates **virtual addresses → physical addresses**. 3. If required data is not in RAM, a **page fault** occurs, and OS loads that page from disk into RAM. --- ## 🔹 Example Suppose: * RAM = 4 GB * Process requires 8 GB memory 👉 With **Virtual Memory**, OS loads only the **active (currently used) pages** of the process into RAM, and the rest stays in the disk (swap space). So, the process **runs as if 8 GB is available**, even though RAM is just 4 GB. --- ## 🔹 Advantages of Virtual Memory 1. **Run larger programs** than physical memory. 2. **Efficient multiprogramming** → more processes can be in memory. 3. **Isolation & security** → each process gets its own address space. 4. **No external fragmentation** (because of paging). --- ## 🔹 Disadvantages 1. **Slower performance** (disk access is much slower than RAM). 2. **Thrashing**: If too many page faults occur, CPU spends more time swapping pages than executing processes. # ⚡ Page Replacement Algorithms in OS When **virtual memory** is used and RAM is full, the OS must decide: 👉 **Which page to replace** in RAM to load the new page (on a page fault). This decision is made using **Page Replacement Algorithms**. --- ## 🔹 1. **FIFO (First-In-First-Out)** * The page that **entered RAM first** is removed first. * Works like a **queue**. **Example:** Frames = 3 Reference string = 7, 0, 1, 2, 0, 3, 0, 4 Step by step (FIFO order): * Insert 7 → \[7\] * Insert 0 → \[7, 0\] * Insert 1 → \[7, 0, 1\] * Insert 2 → Replace 7 → \[2, 0, 1\] * Insert 0 → Already present → \[2, 0, 1\] * Insert 3 → Replace 0 → \[2, 3, 1\] * Insert 0 → Replace 1 → \[2, 3, 0\] * Insert 4 → Replace 2 → \[4, 3, 0\] 👉 **Page Faults = 7** ✔️ Simple ❌ May replace frequently used pages --- ## 🔹 2. **Optimal Page Replacement** * Replace the page that will **not be used for the longest time in future**. * Gives **minimum page faults** (but needs future knowledge → used for comparison, not real OS). **Example (same as above):** Reference string = 7, 0, 1, 2, 0, 3, 0, 4 Step by step: * First 3 → \[7, 0, 1\] * Next is 2 → Need to replace one. Looking ahead: * 7 is never used again → Replace 7 → \[2, 0, 1\] * Next is 0 → Already present * Next is 3 → Looking ahead, 1 is not used for longest time → Replace 1 → \[2, 0, 3\] * Next is 0 → Already present * Next is 4 → Looking ahead, 2 is not used again → Replace 2 → \[4, 0, 3\] 👉 **Page Faults = 6** (better than FIFO). --- ## 🔹 3. **LRU (Least Recently Used)** * Replace the page that has **not been used for the longest time in the past**. * Uses **past history** instead of future. * Implemented with counters or stack. **Example (same string):** Reference = 7, 0, 1, 2, 0, 3, 0, 4 * First 3 → \[7, 0, 1\] * Next 2 → Replace 7 (least recently used) → \[2, 0, 1\] * Next 0 → Already present * Next 3 → Replace 1 (least recently used) → \[2, 0, 3\] * Next 0 → Already present * Next 4 → Replace 2 (least recently used) → \[4, 0, 3\] 👉 **Page Faults = 6** ✔️ More practical than Optimal ❌ Needs extra bookkeeping --- ## 🔹 4. (Bonus) **Other Algorithms** * **Clock / Second Chance** → Approximation of LRU, uses a circular buffer with a reference bit. * **MRU (Most Recently Used)** → Rarely used, replace the most recently used page. --- # 📊 Quick Comparison | Algorithm | Idea | Page Faults (example) | Pros | Cons | | --- | --- | --- | --- | --- | | FIFO | Replace oldest | 7 | Simple | Bad in some cases (Belady’s Anomaly) | | Optimal | Replace farthest in future | 6 | Minimum page faults | Not practical | | LRU | Replace least recently used | 6 | Practical & good | Needs tracking | --- # 🔹 **Thrashing in Operating System** ### **Definition:** Thrashing occurs when a process spends **more time swapping pages in and out of memory (page faults)** than actually executing instructions. 👉 In simple words: The CPU is busy bringing pages from disk instead of doing useful work. --- ### **Why does it happen?** * If a process **does not have enough frames (physical memory)**, it will continuously page fault. * When many processes compete for limited memory, the OS keeps swapping pages in and out → system performance drops drastically. --- ### **Example of Thrashing:** Imagine you are studying from a **single notebook**, but only allowed to keep **1 page open** at a time. * To read topic A (page 1), you open it. * Then for topic B (page 2), you must close page 1 and open page 2. * If you need page 1 again, you must swap back. ➡️ You keep flipping pages more than actually studying = **Thrashing**. --- ### **Causes of Thrashing:** 1. **High degree of multiprogramming** → Too many processes in memory. 2. **Insufficient physical memory (RAM).** 3. **Poor page replacement algorithms** (frequent replacement of useful pages). --- ### **How to Handle Thrashing?** 1. **Reduce Degree of Multiprogramming** * Suspend some processes so that active processes get more memory frames. 2. **Working Set Model** * Allocate enough frames to each process based on its **working set** (set of pages actively used). 3. **Page Fault Frequency (PFF) Control** * Monitor page fault rate. * If it is too high → allocate more frames. * If it is low → take away some frames. # 🔹 **Segmentation in OS** ### **Definition:** Segmentation is a **memory management technique** in which a program is divided into different **logical segments** (functions, arrays, data, stack, etc.) rather than fixed-size blocks like paging. 👉 Each segment is **variable in length** and represents a logical unit of the program. --- ### **Example:** Think of a **book**: * Chapter 1 → Introduction * Chapter 2 → Story Part 1 * Chapter 3 → Story Part 2 * Chapter 4 → Index Here, each **chapter = segment**. Chapters have **different lengths**, but each one is a **logical unit**. --- ### **How Segmentation Works:** * Each process is divided into segments (Code, Data, Stack, Heap, etc.). * OS maintains a **Segment Table** for each process. * Each entry in the table contains: * **Base** → starting physical address of the segment * **Limit** → length of the segment 👉 Logical address = (Segment Number, Offset) 👉 Physical address = Base + Offset (checked against Limit). --- ### **Example of Address Translation:** Suppose: * Segment Table Entry for Segment 2: Base = 1000, Limit = 400. * Logical Address = (2, 50). ➡️ Physical Address = 1000 + 50 = **1050**. --- ### **Advantages:** 1. Matches **user’s view of memory** (functions, arrays, etc.). 2. Eliminates **internal fragmentation** (unlike paging). 3. Enables **protection and sharing** of segments (read-only code segment can be shared). --- ### **Disadvantages:** 1. Suffers from **external fragmentation** (because segments are variable-sized). 2. Complex memory allocation (finding free holes for variable-sized segments). 3. Slower compared to paging. --- ### **Segmentation vs Paging:** | Feature | Paging | Segmentation | | --- | --- | --- | | Division | Fixed-size pages | Variable-size segments | | Fragmentation | Internal fragmentation | External fragmentation | | View of memory | Physical (blocks) | Logical (functions, arrays) | | Translation | Page table | Segment table | --- Great question 👍 Let’s go through **Disk Management in Operating Systems** step by step. --- # 🔹 **Disk Management in OS** ### **Definition** Disk Management in OS refers to how the operating system **organizes, stores, retrieves, and manages data** on secondary storage devices (like HDDs, SSDs). It ensures **efficient use of storage**, fast access, and reliability. --- ## 🔸 1. **Disk Structure** * Disks are divided into **platters** → divided into **tracks** → further divided into **sectors**. * Each sector usually stores **512 bytes to 4KB** of data. * OS uses **logical block addressing (LBA)** → treats disk as a linear array of blocks (ignoring physical geometry). --- ## 🔸 2. **Disk Scheduling (I/O Scheduling)** When multiple processes request disk access, the OS decides the **order of requests**. This is important because disk access time = **Seek Time + Rotational Latency + Transfer Time**. ### **Common Disk Scheduling Algorithms** 1. **FCFS (First Come First Serve)** * Serve requests in order of arrival. ✅ Fair, simple. ❌ High average seek time. Example: Requests → \[98, 183, 37, 122\] Head at 53 → Service order is the same → Long travel. --- 2. **SSTF (Shortest Seek Time First)** * Serve the request closest to current head. ✅ Faster than FCFS. ❌ Can cause starvation. --- 3. **SCAN (Elevator Algorithm)** * Head moves in one direction, serves requests until end, then reverses. ✅ Fair, avoids starvation. ❌ More seek time than LOOK. --- 4. **C-SCAN (Circular SCAN)** * Like SCAN, but after reaching one end, head jumps to other end and continues in one direction. ✅ Provides uniform wait time. --- 5. **LOOK and C-LOOK** * Similar to SCAN/C-SCAN, but head only goes as far as last request (doesn’t go to the physical end unnecessarily). --- ✅ **Example (SSTF vs SCAN):** Head at 53, Requests = \[98, 183, 37, 122, 14, 124\] * SSTF → 53 → 37 → 14 → 98 → 122 → 124 → 183 * SCAN (moving right) → 53 → 98 → 122 → 124 → 183 → then reverses → 37 → 14