Top 25 - Part 1

1. Process vs. Thread — what is the difference?

A process is an independent program in execution. It has its own memory space (code, data, heap, stack), its own resources, and its own PCB.

A thread is a lightweight unit of execution that lives inside a process. Threads of the same process share its memory and resources.

Visualize it:

PROCESS A
┌──────────────────────────────────────┐
│ Own Memory Space                     │
│                                      │
│  Code   Data   Heap   Stack          │
│                                      │
│  ┌──────────┐  ┌──────────┐          │
│  │ Thread 1 │  │ Thread 2 │          │
│  └──────────┘  └──────────┘          │
│       \              /               │
│        \            /                │
│         Shared Memory                │
└──────────────────────────────────────┘

PROCESS B
┌──────────────────────────────────────┐
│ Separate Memory Space                │
│                                      │
│  Code   Data   Heap   Stack          │
│                                      │
│          ┌──────────┐                │
│          │ Thread 1 │                │
│          └──────────┘                │
└──────────────────────────────────────┘

	Process	Thread
Memory	Own address space	Shares the process’s memory
Communication	Needs IPC (shared memory, pipes)	Direct, via shared memory
Overhead	Creation is heavy	Cheap to create
Crash impact	One process crash doesn’t kill others	A crashing thread can take down its process

Why threads: since they share memory, communicating between threads is trivial compared to between processes, and switching between threads is cheaper than switching processes.

---

2. Multiprogramming vs. Multitasking vs. Multiprocessing — differentiate.

Three terms that sound alike but mean different things:

• Multiprogramming — keeps multiple programs in memory simultaneously. When one waits for I/O, the CPU switches to another, keeping the CPU busy. Boosts CPU utilization, no user interaction assumed.
• Multitasking (timesharing) — rapid switching between tasks so users get the illusion that everything runs at once. Interactive and responsive.
• Multiprocessing — using multiple physical CPUs/cores at the same time, actually executing multiple processes in parallel.

Visualize the difference:

MULTIPROGRAMMING
One CPU
─────────────────────────────────────
CPU:  ███ A ███  I/O  ███ B ███  I/O  ███ A ███
          │             │
       A waits         B runs
       for I/O

Goal → Keep ONE CPU busy

MULTITASKING
One CPU
─────────────────────────────────────
Time →  1   2   3   4   5   6   7   8

CPU →   A | B | C | A | B | C | A | B
        └──┴──┴──┴──┴──┴──┴──┴──┘
             Rapid switching

Goal → Make multiple tasks feel simultaneous

MULTIPROCESSING
Multiple CPUs / Cores

CPU 1 →  █████████████████  Process A
CPU 2 →  █████████████████  Process B
CPU 3 →  █████████████████  Process C

        ↑          ↑          ↑
     Actually   Actually   Actually
     parallel   parallel   parallel

Term	What’s multiple	Key idea
Multiprogramming	Programs in memory	Keep CPU busy while one waits
Multitasking	Tasks on one CPU	Fast switching = responsive
Multiprocessing	Physical CPUs	True parallel execution

---

3. Internal vs. External Fragmentation — explain.

Both are wasted memory, but they waste it differently.

• Internal fragmentation — the allocated block is larger than needed, so the leftover space inside the block is wasted. Happens with fixed-size partitions/pages: a process needing 3KB gets a 4KB page, wasting 1KB inside.
• External fragmentation — free memory exists, but it’s split into many small non-contiguous gaps. None is big enough to satisfy a request, even though total free space is plenty.

Internal fragmentation:

Allocated 4 KB block
┌────────────────────────┐
│ Process needs 3 KB     │
│████████████████████████│
│██████████████████      │
│                  │ 1KB │
│                  │WASTE│
└────────────────────────┘
        ↑
   Waste is INSIDE
   allocated block

External fragmentation:

Memory
┌──────────┬───────┬────────────┬───────┬──────────┐
│ Process  │ FREE  │  Process   │ FREE  │  Process │
│          │ 20KB  │            │ 30KB  │          │
└──────────┴───────┴────────────┴───────┴──────────┘
             ↑                    ↑
          separate              separate
          free gaps             free gaps

Total free = 50 KB

Request = 40 KB

Cannot allocate:
No SINGLE contiguous block is 40 KB.

Example of external: free memory = 30KB, 20KB, 25KB chunks. A 40KB request fails even though 75KB is free — no single chunk fits.

Paging eliminates external fragmentation (fixed sizes); compaction and segmentation try to reduce it.

---

4. What is Inter-Process Communication (IPC)?

IPC is the set of mechanisms that let independent processes exchange data and synchronize with each other.

Visualize the problem:

PROCESS A                          PROCESS B
┌─────────────┐                    ┌─────────────┐
│             │                    │             │
│   Memory A  │                    │   Memory B  │
│             │                    │             │
└─────────────┘                    └─────────────┘
       │                                   │
       │        Cannot directly             │
       │        access each other           │
       │                                   │
       └──────────── IPC ──────────────────┘

The common methods:

• Shared memory — a region of memory both processes map and access directly. Fastest, but you need synchronization (semaphores) to avoid corruption.
• Message passing — processes send structured messages to each other (send/receive). Safe and simple, slightly slower.
• Pipes — a byte stream connecting two processes, one writes, the other reads.
• Sockets — pipes that also work across the network.
• Signals — tiny notifications sent to a process.

Why IPC matters: unlike threads, processes don’t share memory, so they need a channel to cooperate — and that’s exactly what IPC provides.

Quick mental picture:

Shared Memory:
A ───────► [ SHARED MEMORY ] ◄─────── B

Message Passing:
A ───────► [ MESSAGE ] ───────► B

Pipe:
A ───────► [ PIPE ] ───────► B

Socket:
A ◄────── NETWORK ──────► B

---

5. System Calls vs. Function Calls — differentiate.

• System call — a request for a kernel service (open a file, allocate memory, create a process). Executing one forces a mode switch from user mode to kernel mode.
• Function call — an ordinary call within a user-mode program. No kernel involvement, no mode switch.

Visualize the difference:

FUNCTION CALL

User Mode
┌───────────────────────────────┐
│ main()                        │
│   │                           │
│   └──► strlen(name)           │
│          │                    │
│          └──► return          │
└───────────────────────────────┘

No kernel involvement
No mode switch

SYSTEM CALL

User Mode                         Kernel Mode
┌───────────────┐                 ┌───────────────┐
│ Application   │                 │ Kernel        │
│               │                 │               │
│ fopen()       │ ── system ───► │ Open file     │
│               │     call       │               │
└───────────────┘                 └───────────────┘
        ▲                                │
        └────────── result ──────────────┘

          USER → KERNEL → USER
              Mode switch

// function call — stays in user mode
int x = strlen(name);

// system call — traps into the kernel
FILE *f = fopen("data.txt", "r");

Cost: mode switches are expensive (context saving, privilege change), so system calls are far slower than function calls. That’s why OS interfaces are designed to minimize them.

---

6. What is a Real-Time Operating System (RTOS)?

An RTOS is an OS that guarantees deterministic responses — critical tasks complete within strict deadlines.

The key word is guarantee. A general-purpose OS tries to be fast on average; an RTOS must be predictable in the worst case.

Visualize real-time execution:

Task
 │
 ▼
┌─────────────────────────────┐
│ Execute critical operation  │
└──────────────┬──────────────┘
               │
               ▼
        ┌──────────────┐
        │   Deadline   │
        └──────┬───────┘
               │
        Must finish
        before deadline

• Hard real-time — missing a deadline is a total failure (airbag deployment, pacemakers).
• Soft real-time — missing a deadline is bad but not catastrophic (video streaming, gaming).

Timeline:

Hard Real-Time

Start                    Deadline
 │                           │
 ▼                           ▼
[████████████████████████████]
                            ▲
                      MUST finish here
                      or failure


Soft Real-Time

Start                    Deadline
 │                           │
 ▼                           ▼
[██████████████████████████████]
                              ▲
                    Late = degraded quality

Because of this, RTOSes use priority-based, preemptive scheduling where the highest-priority ready task always runs immediately. Used in airbags, medical devices, industrial controllers, and avionics.

---

7. Logical Address vs. Physical Address — explain.

• Logical (virtual) address — generated by the CPU as the process’s reference. Each process thinks it owns a huge, clean address space starting at 0.
• Physical address — the actual location in RAM where the data lives.

The MMU (Memory Management Unit) translates logical to physical addresses on every memory access.

Visualize the translation:

PROCESS
┌───────────────────────┐
│ Logical Address       │
│                       │
│     0x1234            │
└───────────┬───────────┘
            │
            ▼
          MMU
    ┌──────────────┐
    │ Address      │
    │ Translation  │
    └──────┬───────┘
           │
           ▼
┌───────────────────────┐
│ Physical RAM          │
│                       │
│     0x8A34            │
└───────────────────────┘

Why separate them:

• Isolation — each process gets its own logical space; it can’t touch another process’s memory.
• Flexibility — the OS can place a program’s pages anywhere in RAM without the program knowing.

Two processes can even use the same logical address while pointing to different physical pages.

Process A                    Process B

Logical 0x1000               Logical 0x1000
      │                            │
      ▼                            ▼
     MMU                          MMU
      │                            │
      ▼                            ▼
Physical 0x5000               Physical 0x9000

---

8. What is Context Switching?

Context switching is the scheduler saving one process’s state and loading another’s so execution can resume exactly where it left off.

Visualize it:

CPU
 │
 │ Running Process A
 ▼
┌─────────────────┐
│ A is executing  │
└────────┬────────┘
         │
         │ Context Switch
         ▼
┌─────────────────────────────┐
│ Save A's context            │
│ - Registers                 │
│ - Program Counter           │
│ - Stack Pointer             │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Load B's context             │
│ - Registers                 │
│ - Program Counter            │
│ - Stack Pointer              │
└─────────────┬───────────────┘
              │
              ▼
       Process B runs

What gets saved/loaded:

• Registers and program counter
• Process state and scheduling info
• Stack pointer
• (and usually the MMU/TLB state)

The cost: Every switch has overhead — save context, switch kernel state, load new context, flush the TLB. With hundreds of processes, switches add up, and the CPU spends a chunk of its time just switching instead of working.

Important idea:

Useful work
██████████████████████████

Context switching
    ██      ██      ██

Too many switches
→ More overhead
→ Less useful CPU work

Fewer, longer-running processes → fewer switches → better throughput.

---

9. File System (FAT, NTFS, Inodes) — explain.

• FAT (File Allocation Table) — an old, simple file system that tracks which disk blocks belong to each file in a table. Simple and widely compatible, but no permissions or journaling, and the table can fragment.
• NTFS — Windows’ modern file system. Supports journaling (logs changes to survive crashes), security permissions (ACLs), file compression, encryption, and very large volumes.
• Inodes — Unix’s approach. Each file has an inode — a metadata record storing size, permissions, owner, timestamps, and pointers to the file’s data blocks. The directory just maps names to inode numbers.

FAT visualization:

File
 │
 ▼
File Allocation Table
┌────────────────────────┐
│ Block 10 → Block 11    │
│ Block 11 → Block 15    │
│ Block 15 → END         │
└────────────────────────┘
          │
          ▼
       Disk Blocks

Inode visualization:

Directory
┌──────────────────────┐
│ report.txt → inode 7 │
└──────────┬───────────┘
           │
           ▼
      ┌──────────────┐
      │   INODE 7    │
      ├──────────────┤
      │ Size         │
      │ Permissions  │
      │ Owner        │
      │ Timestamps   │
      │ Data pointers│
      └──────┬───────┘
             │
             ▼
        Data Blocks
      ┌────┬────┬────┐
      │ B1 │ B2 │ B3 │
      └────┴────┴────┘

	Structure	Highlights
FAT	Allocation table	Simple, compatible
NTFS	Journaled, ACLs	Durable, secure, large
Inode	Inode per file	Fast, flexible, Unix standard

---

10. What are Device Drivers?

A device driver is kernel-level software that translates generic OS requests into commands a specific hardware controller understands.

The flow:

Application
     │
     │ "Write this file"
     ▼
File System
     │
     │ Block request
     ▼
Device Driver
     │
     │ Hardware-specific commands
     ▼
Hardware Controller
     │
     ▼
Physical Device

1. An app says “write this file to disk.”
2. The file system hands a block request to the driver.
3. The driver issues the precise commands the disk controller needs (sector addressing, timing, status checks).

Why drivers exist: without them, every program would need to know the exact protocol of every device. Drivers abstract that — the OS talks to a uniform interface, and each driver knows how to speak to its own hardware.

Drivers run with high privilege, which is why a buggy driver can crash the system.

---

11. Buffering vs. Spooling — differentiate.

• Buffering — uses temporary memory to match speed differences between a data producer and consumer. E.g., keyboard input: keystrokes arrive slowly; the buffer holds them until the program reads them. It smooths the flow.
• Spooling (Simultaneous Peripheral Operation On-Line) — queues jobs for a slow shared device, using disk as the holding area. E.g., printer queue: many jobs wait on disk, printed one at a time while the system continues working.

Buffering:

Fast Producer
     │
     ▼
┌──────────────┐
│    BUFFER    │  ← Temporary memory
└──────┬───────┘
       │
       ▼
Slow Consumer

Spooling:

Process A ──┐
Process B ──┼──► [ DISK QUEUE ] ──► Printer
Process C ──┘          │
                       │
                  Jobs wait here
                  until printer
                  is available

	Buffering	Spooling
Storage	Memory	Disk
Purpose	Match speed	Manage concurrent access
Example	Keyboard buffer	Print queue

Both keep slow devices from stalling the CPU — buffering smooths data rate, spooling handles multiple jobs for one device.

---

12. What are Starvation and Aging in OS scheduling?

Starvation — a process waits indefinitely, never getting CPU time. Happens with priority or SJF scheduling: high-priority jobs keep arriving and a low-priority one never gets a turn.

Aging — the fix. Over time, the OS gradually increases a waiting process’s priority. Eventually its priority is high enough that it must run, breaking the starvation cycle.

Visualize starvation:

CPU
 │
 ├──► High Priority A ──► RUN
 │
 ├──► High Priority B ──► RUN
 │
 ├──► High Priority C ──► RUN
 │
 ├──► High Priority D ──► RUN
 │
 └──► Low Priority X ───► WAIT...
                         WAIT...
                         WAIT...
                         WAIT...

With aging:

Low Priority X

Priority
   │
   │              ┌────── RUN
   │            /
   │          /
   │        /
   │      /
   │    /
   │  /
   └──────────────────────► Time
      Waiting increases priority

Example: A low-priority batch job is perpetually postponed. Every second it waits, its priority ticks up. After long enough, it outranks everything and runs.

Starvation is the disease; aging is the medicine.

---

13. What are Interrupts?

An interrupt is a signal to the CPU — from hardware or software — demanding immediate attention.

Types:

• Hardware interrupts — devices (disk, keyboard, timer) notify the CPU that something needs handling.
• Software interrupts / traps — program faults (divide by zero) or explicit system calls.

How it works:

Device
  │
  │ Interrupt
  ▼
CPU
  │
  ├── 1. Finish current instruction
  │
  ├── 2. Save current context
  │
  ├── 3. Find correct ISR
  │
  ▼
Interrupt Service Routine
(ISR)
  │
  ├── Handle event
  │
  ▼
Restore Context
  │
  ▼
Resume Interrupted Program

1. Device raises an interrupt line.
2. CPU finishes the current instruction, saves its context.
3. Runs the Interrupt Service Routine (ISR) for that interrupt.
4. Restores context and resumes the interrupted work.

Interrupts are how the CPU stays responsive without constantly polling devices.

---

14. Page Replacement Algorithms: FIFO, LRU, Optimal — compare.

When memory is full and a page fault occurs, the OS must evict a page. The algorithms differ in which page:

Visualize the situation:

RAM is full

┌───────┬───────┬───────┬───────┐
│ Page A│ Page B│ Page C│ Page D│
└───────┴───────┴───────┴───────┘
                 ▲
                 │
            New Page E
            needs space

        Which page should go?
                │
       ┌────────┼────────┐
       ▼        ▼        ▼
     FIFO      LRU    Optimal

• FIFO (First In, First Out) — evicts the oldest loaded page. Simple, but can be fooled — and suffers Belady’s Anomaly (adding more frames can increase faults).
• LRU (Least Recently Used) — evicts the page unused the longest. Uses history as a prediction of the future. Better than FIFO, but needs tracking overhead.
• Optimal — evicts the page that will not be used for the longest time in the future. Perfect results, but impossible — you can’t know the future. It’s the theoretical benchmark to compare others against.

Simple timeline:

Pages loaded:

Oldest                              Newest
  │                                    │
  ▼                                    ▼
[A] ───── [B] ───── [C] ───── [D]
  │
  └── FIFO removes A

LRU looks at recent usage:
[A] [B] [C] [D]
 │         ▲
 │         └── Recently used
 └── Least recently used → remove A

Algorithm	Chooses	Implementable?
FIFO	Oldest loaded	Yes
LRU	Least recently used	Yes
Optimal	Used farthest in future	No (theoretical)

---

15. What is the Critical Section Problem?

The critical section is the part of a program that accesses shared mutable data. The problem: if two processes/threads run their critical sections at the same time, the shared data gets corrupted.

The problem:

Thread A                         Thread B

     │                               │
     ▼                               ▼
┌───────────┐                  ┌───────────┐
│ Read X    │                  │ Read X    │
└─────┬─────┘                  └─────┬─────┘
      │                              │
      ▼                              ▼
   X = 10                         X = 10
      │                              │
      ▼                              ▼
   X = 11                         X = 11
      │                              │
      └──────────────┬───────────────┘
                     ▼
              Expected X = 12
              Actual X = 11

              ❌ Data corruption

The critical section is the section where shared data is accessed:

Thread
  │
  ▼
┌──────────────────────────────┐
│ Non-Critical Section         │
└──────────────┬───────────────┘
               │
               ▼
       ┌───────────────────┐
       │ CRITICAL SECTION  │
       │                   │
       │ Access shared     │
       │ mutable data      │
       └─────────┬─────────┘
                 │
                 ▼
┌──────────────────────────────┐
│ Non-Critical Section         │
└──────────────────────────────┘

The three requirements for a correct solution:

1. Mutual exclusion — only one process may be in its critical section at a time.
2. Progress — if no one is in the critical section and someone wants in, the decision can’t be postponed forever.
3. Bounded waiting — no process waits indefinitely for its turn.

Visualize the correct behavior:

             Shared Resource
                   │
                   ▼
        ┌────────────────────┐
        │   CRITICAL SECTION │
        └─────────┬──────────┘
                  │
        ┌─────────┴─────────┐
        │                   │
        ▼                   ▼
    Thread A             Thread B
      WAIT                  WAIT

Only ONE enters:

Thread A ──► [ CRITICAL ] ──► EXIT
                                  │
                                  ▼
                         Thread B ──► [ CRITICAL ]

Solutions: semaphores, mutexes, and monitors — all mechanisms that guarantee mutual exclusion so concurrent access to shared data stays safe.