optional · CSS study notes
Process Management
CSS Optional — Paper-II, Section-A · P-II.III.II · One of the two highest-yield OS subtopics (with Deadlocks) — expect at least one full numerical.
1. Process vs Program
A program is a passive entity — code sitting on disk. A process is a program in execution: an active entity with its own program counter, register values, and memory (code, data, heap, stack). One program can spawn several processes (e.g. opening two browser windows).
2. Process States
graph LR
New --> Ready
Ready -->|"dispatch"| Running
Running -->|"time-slice expiry / preemption"| Ready
Running -->|"I/O or event wait"| Waiting
Waiting -->|"I/O or event completion"| Ready
Running --> Terminated
- New: process is being created. Ready: waiting to be assigned the CPU. Running: instructions being executed. Waiting/Blocked: waiting for an event (I/O completion, signal). Terminated: finished execution.
3. Process Control Block (PCB)
The PCB is the data structure the OS maintains per process, holding everything needed to manage and later resume it — it is the process's representation inside the OS.
Components: Process ID (PID) · Process State · Program Counter · CPU registers · CPU scheduling info (priority, queue pointers) · Memory management info (base/limit registers or page tables) · Accounting info (CPU time used) · I/O status info (allocated devices, open file list).
On a context switch, the OS saves the running process's state into its PCB and loads the next process's state from its own PCB — this save/restore cost (pure overhead, no useful work done) is why excessively frequent switching hurts throughput.
Worked Numerical (context-switch overhead, CSS 2018 Paper-I): time slice = 50 ms, context switch = 1 microsecond. How many processes can the machine service in one second?
- Convert to the same unit: time slice = 50 ms = 50,000 μs.
- Time spent per process per turn = time slice + context switch = 50,000 + 1 = 50,001 μs.
- Processes serviced in 1 second (= 1,000,000 μs) = 1,000,000 ÷ 50,001 ≈ 19.9996.
- Since a partial turn doesn't count as a fully serviced process, answer ≈ 19 processes per second (20 full turns would need 1,000,020 μs, just over the 1-second budget).
This is the concrete numeric version of the "quantum too small → context-switch overhead dominates" trade-off named in the CPU Scheduling Algorithms table below — here the overhead is tiny (1 μs vs a 50 ms slice) so it barely dents throughput, but shrinking the time slice while keeping the same 1 μs switch cost would eat into it fast.
4. CPU Scheduling Algorithms
| Algorithm | Rule | Preemptive? | Weakness |
|---|---|---|---|
| FCFS | First come, first served (queue order) | No | Convoy effect — short jobs stuck behind one long job |
| SJF | Shortest burst time next | Can be either | Needs to know burst time in advance; can starve long jobs |
| Priority Scheduling | Highest priority runs next | Can be either | Starvation of low-priority jobs (fixed by aging) |
| Round Robin (RR) | Fixed time quantum, cyclic queue | Yes | Too-large quantum → behaves like FCFS; too-small quantum → excessive context-switch overhead |
| Multilevel Queue | Several permanent queues (e.g. foreground/background), each with its own algorithm | Depends on queue | Rigid — a process cannot move between queues; can starve low queues |
| Multilevel Feedback Queue (MLFQ) | Like Multilevel Queue, but processes can be promoted/demoted between queues based on behaviour | Yes | Most complex to design/tune correctly |
📐 Every algorithm above, worked through a full Gantt-chart numerical:
5. Threads vs Processes
A thread is a lightweight unit of execution within a process, needing only its own program counter, registers, and stack, while sharing the parent's code, data, heap, and open files with sibling threads. A process needs a completely independent address space, its own PCB, page tables, and file descriptors.
Consequence: thread creation/switching is cheap ("lightweight") since little new state is allocated; process creation/switching is expensive ("heavyweight") since an entire address space and OS bookkeeping structure is built from scratch. Threads also communicate trivially via shared memory, while processes need explicit IPC.
Threading models: user-level threads are mapped onto a smaller/equal/larger number of kernel-level threads (M:N mapping); only kernel threads can actually be scheduled onto physical cores — this caps real parallelism regardless of how many user threads exist (worked numerically on the companion page below).
6. Scheduling Criteria (what a scheduler is actually optimizing for)
| Criterion | Meaning | Usually want it... |
|---|---|---|
| CPU Utilization | % of time the CPU is doing useful work, not idle | Maximized |
| Throughput | Number of processes completed per unit time | Maximized |
| Turnaround Time | Total time from submission to completion | Minimized |
| Waiting Time | Total time spent waiting in the ready queue | Minimized |
| Response Time | Time from submission until the FIRST response (not completion) — critical for interactive systems | Minimized |
Note Turnaround Time is not the same as Response Time — a long-running interactive process can have excellent response time (starts responding immediately) but poor turnaround time (takes long to fully finish); this distinction is a favourite MCQ trap.
7. Process Creation and Termination
- fork() (UNIX-style): creates a new process (the child) as a near-exact duplicate of the calling process (the parent) — same code, a copy of the data/memory (via copy-on-write for efficiency — see [Virtual Memory Management]).
- exec(): replaces the calling process's memory image with a new program — commonly called immediately after fork() in the child, so the pattern "fork then exec" is how UNIX-family systems launch a brand-new program from an existing one.
- wait(): a parent calls this to block until a specific child terminates, collecting its exit status.
- Orphan process: a child whose parent terminated before it did — usually re-parented to
init/PID 1. - Zombie process: a child that has terminated but whose exit status hasn't yet been collected by
wait()— it still occupies a PCB/process-table entry until reaped, which is why an accumulation of zombies is a real resource leak worth naming in a "process lifecycle" answer.
8. Inter-Process Communication (IPC)
Cooperating processes need a mechanism to exchange data. Two fundamental models:
| Model | How it works | Trade-off |
|---|---|---|
| Shared Memory | A region of memory is mapped into both processes' address spaces; they read/write it directly | Very fast (no kernel involvement after setup) but the processes themselves must implement synchronization (see [Process Synchronization]) to avoid race conditions |
| Message Passing | Processes exchange data via OS-mediated send()/receive() calls (directly, or via a shared mailbox/port) | Simpler to get correct (the OS can serialize access), but slower due to kernel-mediated system-call overhead on every message |
Pipes (a common concrete example of message passing on UNIX-family systems): an ordinary/anonymous pipe allows one-directional communication between a parent and its child (e.g. shell command piping, ls | grep); a named pipe (FIFO) persists as a filesystem object and can connect unrelated processes.
📐 Worked Numericals
This topic's past questions are almost entirely Gantt-chart/scheduling arithmetic. They're split onto their own page so the concepts above stay quick to review on their own:
Round Robin avg WT/TAT (2017), preemptive-priority + RR Gantt chart (2022, 10 marks), threading-model parallelism (2025).
🎯 CSS Exam Angle
Process Management numericals are almost always Gantt-chart-based (compute CT/TAT/WT) or PCB/thread-conceptual. Always draw the Gantt chart explicitly even when not asked — examiners award partial marks for a correct chart even when the final averages have an arithmetic slip.
📌 Past CSS Paper Frequency
| Year | Question | Marks |
|---|---|---|
| 2016 | Multilevel Queue vs Multilevel Feedback Queue scheduling (pros/cons) | 6 |
| 2016 | Process Control Block components | 6 |
| 2018 Paper-I | Context-switch overhead numerical (processes serviced per second) | 2 |
| 2017 | Resource allocation during runtime (short note) | 5 |
| 2017 | Round Robin numerical (avg WT/TAT) | 6 |
| 2019 | Flow chart of process scheduling using multiple queues | 6 |
| 2022 | Preemptive priority + Round-Robin Gantt chart numerical | 10 |
| 2022 | Thread vs process resource creation | 4 |
| 2024 | Process management concept & role in multitasking | 6 |
| 2025 MCQ | Which module hands CPU control to the process the short-term scheduler picked? | 1 (Ans: Dispatcher) |
⚠️ MCQ Traps
- Scheduler vs Dispatcher: the (short-term) scheduler selects which process runs next; the dispatcher is the module that actually gives it the CPU (context switch, mode switch, jump to the right program counter). A 2025 MCQ tested exactly this.
- RR quantum too large ≈ FCFS; quantum too small ⇒ throughput collapses from context-switch overhead — don't say "smaller quantum is always better for responsiveness" without this caveat.
- A cycle in scheduling ties: when two processes share the same priority, don't assume FCFS by default — check whether the question specifies Round-Robin among equals.
- Thread creation is cheap because it shares the parent's address space; it is not because threads "do less work."
- Turnaround Time ≠ Response Time — see section 6; a favourite way to lose marks in a "define these criteria" question.
- fork() copies, exec() replaces — mixing these up is a common short-note error; and a zombie is not the same as an orphan (a zombie has exited but is unreaped; an orphan is still running but parentless).
📜 Past-Paper Questions & MCQs (CSS 2016–2026)
2016 · Paper-II · Q4(c) · 6 marks
Q. What do you know about the Process Control Block? Discuss its components in detail.
Ans.
- The PCB (also called the task control block) is the data structure the OS keeps for each process. It holds everything needed to stop and later resume the process, so it is central to context switching.
- Components:
- Process ID (PID) and parent process ID
- Process state: new, ready, running, waiting, terminated
- Program counter: address of the next instruction
- CPU registers: accumulators, index registers, stack pointer, status flags, saved on a switch
- CPU-scheduling information: priority, pointers to queues, scheduling parameters
- Memory-management information: base and limit registers, page or segment tables
- Accounting information: CPU time used, time limits, job numbers
- I/O status information: open files, allocated devices
2018 · Paper-I · Q2(g) · 2 marks
Q. If the time slice is 50 ms and a context switch takes 1 microsecond, how many processes can the machine service in a second?
Ans.
- Time per turn = 50 ms + 0.001 ms = 50.001 ms.
- Processes serviced per second = 1000 ms / 50.001 ms ≈ 19.99, about 20 processes. The context-switch overhead is negligible (about 0.002%).
2019 · Paper-II · Q4(a)(b) · 8 and 6 marks
Q. Demonstrate the step-by-step procedure for process swapping between main memory and secondary memory. Show a flow chart of a process scheduling mechanism using various queues.
Ans.
- Swapping steps:
- Step 1: The memory manager finds that memory is short, or a high-priority process needs space.
- Step 2: It chooses a victim (usually a blocked or low-priority process) and saves its PCB state.
- Step 3: It writes the victim's memory image to the swap area on disk (swap out), and marks its memory free.
- Step 4: It loads the needed process image from disk into the freed memory (swap in).
- Step 5: It updates the process table and memory maps, and the process returns to the ready queue.
- Queues and flow:
New → [Job queue] → (long-term scheduler) → [Ready queue] → (short-term scheduler) → CPU
CPU → I/O request → [Device queue] → I/O done → Ready queue
CPU → time slice expires → Ready queue
CPU → waits for event → [Waiting queue] → event → Ready queue
Ready/Waiting → (medium-term scheduler) → [Swapped-out queue] → swap in → Ready
CPU → exit → Terminated
- Long-term scheduler: admits jobs. Short-term scheduler: picks the next process for the CPU. Medium-term scheduler: performs swapping.
2024 · Paper-II · Q5(c) · 6 marks
Q. What is process management in the context of operating systems? How does the OS handle processes, and what role does it play in multitasking?
Ans.
- Process management covers creating, scheduling, running, synchronising and terminating processes (programs in execution).
- How the OS handles processes:
- creates a PCB for each process and tracks its state (new, ready, running, waiting, terminated)
- the scheduler picks the next process, and the dispatcher performs the context switch
- provides inter-process communication and synchronisation
- handles deadlocks and terminates processes
- Multitasking: the CPU switches rapidly among ready processes, using time slices, so many programs seem to run at the same time. The OS saves and restores each process's state (context switching), so each can continue exactly where it stopped. This gives good CPU utilisation and responsiveness.