SwadhyAI Notes

All Operating Systems notes

Start here

Textbooks use 5–7 named states (new, ready, running, waiting, terminated). Real kernels expose more substates; the goal here is to learn legal transitions and what event moves you along an edge (syscall block, timer tick, signal, I/O completion).

Process states (conceptual model)

A runnable process wants CPU time but may not be on a core yet. Running means currently executing on some CPU. Waiting (blocked) means it cannot proceed until an event, disk read, lock, child exit, completes.Terminated/zombie means execution stopped but the kernel retains a minimal record until a parent reaps status.

By the end of this page you should be able to

  1. Draw ready ↔ running ↔ waiting transitions and name typical triggers.
  2. Contrast interruptible vs uninterruptible sleep at a user-visible level.
  3. Explain why a zombie still appears in `ps` output.

Linux reality check

States like D (uninterruptible sleep) show up in top: often I/O or NFS, not “extra CPU work.”

Operating systems · Processes

Process states and lifecycle

New, ready, running, waiting, terminated

TL;DR

Processes move between states driven by scheduler decisions and I/O: runnable threads sit on a runqueue; blocking syscalls move tasks to wait queues; termination leaves a zombie until reaped, diagrams must include wait queues, not just “running.”

Summary

State diagrams are bookkeeping for concurrency: they tell you which queues to inspect when debugging latency (scheduler runqueue vs device waitqueue vs lock wait).

Diagram

Use this as the picture you would redraw from memory after closing the tab.
Diagram text: the exact Mermaid definition below preserves the nodes, labels, and connections. Enable JavaScript to view the rendered diagram.
Read the diagram definition
stateDiagram-v2
  [*] --> New
  New --> Ready: admitted
  Ready --> Running: scheduled
  Running --> Ready: preempted
  Running --> Waiting: block
  Waiting --> Ready: wakeup
  Running --> Terminated: exit

Deeper narrative

Five-state models are pedagogical; Linux exposes finer states (`TASK_KILLABLE`, `D` uninterruptible sleep). Transitions are driven by syscalls, signals, scheduler decisions, and interrupt bottom halves, profiling “high system time” often maps to state thrashing.

Mechanism (step by step)

Treat each step as a sentence in the story you tell on a whiteboard.
1

New → admitted

Admission policy may limit runnable children to prevent fork bombs.

2

Ready ↔ running

Timer tick and wakeups move tasks between runqueue and CPU.

3

Waiting

Interruptible waits can return `-EINTR`; uninterruptible waits ignore non-fatal signals (classic `D` state).

4

Terminated/zombie

Resources released except PCB slot until parent `wait`s.

Key insights

Each card is a compression of the lesson, use them as spaced-repetition prompts.

Two orthogonal “waiting” reasons

Waiting for CPU (ready) vs waiting for an event (blocked): mixing them loses points on exams.

Wakeups are explicit

Drivers call `wake_up` on completion; timers wake sleepers; futex operations wake mutex waiters.

State is per-task

In a multithreaded process, individual threads can block while others run, process-level “state” is an aggregate.

Load average encodes runnable + uninterruptible

Linux load averages include `TASK_UNINTERRUPTIBLE` contributors, high load with idle CPU hints at stuck I/O.

Did you know?

Trivia with teeth: the kind of fact that changes how you reason about a design.
Linux uses `TASK_RUNNING` for runnable **or** running, distinction is which CPU holds the slice.
Interruptible vs uninterruptible sleep (`D` state) affects whether signals wake you-`D` often means stuck in unkillable I/O.
Real-time priority bands can preempt `TASK_RUNNING` normal tasks entirely.

Common pitfalls

Where smart people still trip, read slowly.

Spinning on `sched_yield`

Burns CPU; use proper blocking primitives or back-off.

Misreading `top` state

`S` vs `D` vs `R`: D often means NFS/disk driver wait, not CPU work.

Comparison

Classic 5-state model (names vary)

StateMeaning
NewBeing created
ReadyRunnable, waiting for CPU
RunningExecuting on a CPU
WaitingBlocked for I/O or synchronization
TerminatedZombie until reaped or exiting kernel bookkeeping

Glossary

Runnable

Ready to consume CPU if a core is available, on Linux runqueue.

Interruptible sleep

Can wake on signals or events; returns `-EINTR` to many syscalls.

Zombie

Exited but not reaped, still occupies a PID and kernel descriptor.

Interview follow-ups

  1. Why might a process stay in D state indefinitely?
  2. What transition occurs when `read` blocks on an empty pipe?
  3. How does cgroup freezer differ from SIGSTOP?

Callouts

Ops reality

A flood of `D` states often indicates NFS, broken storage, or driver bugs, not CPU saturation.

Walkthrough & deep dive

Left: practical “how would I use this?” threads. Right: slower, code-leaning explanations, open one panel at a time so the page does not feel like a wall of sameness.

Walkthrough

Trace a blocking read

Narrate transitions when a thread calls `read` on an empty pipe: running → interruptible sleep → runnable on writer.

Deep dive

Linux `ps` codes

`R S D T Z` etc. learn what each implies for killability and debugging steps.

Watch states

Terminal
watch -n0.5 'ps -o pid,stat,cmd -p $PID'

Self-check

Misses here are cheap; misses in an interview are not. Treat wrong answers as a patch list for tomorrow.

1A process in READY is waiting for…

2Zombie means…

3Uninterruptible sleep often indicates…