Processes, threads and execution states

Learning goals and prerequisites

After this lesson you should distinguish a stored program from a process, identify what threads share, trace ready/running/blocked transitions, and separate concurrency from parallel execution. You need only basic ideas of instructions, variables and function calls. This is an introductory OS lesson, not complete coverage of system calls, process creation APIs, IPC or thread implementations.

1. A program describes work; a process is an execution instance

An executable file is a description of instructions and data. Starting it creates an execution instance with changing state. Two launches of the same calculator can therefore be two processes even though their executable code came from the same file. They need not have the same current input, registers or progress.

To resume an interrupted execution, the OS must retain its execution context. Important ingredients include a program counter identifying the next instruction, register values, and bookkeeping about memory and resources. A process control block is a conceptual OS record for such management information; the exact organization varies by system. Do not assume that the PCB contains a full copy of every byte of process memory.

A process has an address space: the memory locations it can address. In the usual protected-process model, separate processes have separate virtual address spaces. The same numeric virtual address in two processes does not by itself identify shared storage. Explicit shared-memory arrangements and other IPC mechanisms are possible, but must be stated rather than assumed.

2. Threads: separate execution paths inside a process

A thread is an execution path with its own program counter, register state and stack. Threads in one process normally share its address space, including code, global data and heap objects, as well as process-level resources such as open files. Separate stacks allow two threads to be inside different function calls at the same instant.

“Each thread has its own stack” is not a memory-protection guarantee. The stacks lie in the shared address space, so another thread may access a stack object if a valid reference is shared and its lifetime permits that access. Likewise, thread-local storage is distinct from an ordinary global variable. The safe introductory rule is to ask what object is being accessed, not merely whether it has a name in the source program.

Worked example: one process has threads T1 and T2, a global count initially 4, and a heap array H. T1 changes H[0]; T2 can access the same H[0]. T1's current instruction position and T2's current instruction position can differ. A second unrelated process P2 does not automatically share H just because it also declares an array called H. Whether the shared update is correctly synchronized is a different question, covered later.

3. A deliberately small state model

For the following traces, each process has one schedulable thread and the machine has one CPU execution slot. We ignore suspended states and implementation-specific details.

• Ready: eligible to use the CPU, but not currently selected.
• Running: currently executing on the CPU.
• Blocked (waiting): cannot continue until a specified event occurs, such as completion of a blocking I/O request.

“New” and “terminated” describe creation and completion around this three-state core. A ready process is waiting for CPU selection; a blocked process is waiting for an event that makes it eligible again. Calling both simply “waiting” loses the distinction needed to solve scheduling questions.

Typical transitions are ready → running when dispatched, running → ready when preempted, running → blocked when it must wait, and blocked → ready when the required event completes. Event completion does not itself promise immediate CPU execution. A separate dispatch may happen immediately afterward, but the logical eligibility step still matters. In this model an already-ready process does not request blocking I/O before it first runs.

4. Worked timeline: reason about events, not names

Processes A and B are both ready at time 0. A is selected first. A needs 2 units of CPU, then a blocking I/O taking 3 elapsed units, then 1 final CPU unit. B needs 4 CPU units without I/O. Use a non-preemptive policy: a running process keeps the CPU until it blocks or finishes. I/O may progress while the CPU executes another process; all overhead is zero.

Interval or event	A	B	Reason
[0,2)	Running	Ready	A uses its first CPU burst
time 2	Becomes blocked	Dispatched	A begins I/O; B is eligible
[2,5)	Blocked	Running	A's I/O and B's CPU work overlap
time 5	Becomes ready	Still running	A's I/O ends; B is not preempted
[5,6)	Ready	Running	B completes its fourth CPU unit at 6
[6,7)	Running	Terminated	A uses its last CPU unit

A spends 3 units using the CPU, 3 blocked and 1 ready: 3+3+1=7 units from arrival to completion. B spends 2 units ready and 4 running: 6 units total. CPU execution is continuous from 0 to 7, so utilization over exactly this window is 7/7=100%. This does not mean A never waited. CPU utilization is a machine-level measure, not a per-process waiting-time measure.

Boundary check: if B needed only 1 CPU unit, it would finish at time 3, while A remains blocked until 5. With no other ready process, the CPU would be idle on [3,5), even though an unfinished process still exists. “A process exists” is not the same as “a process is ready.”

5. Concurrency, parallelism and switching

On one CPU execution slot, two threads can make interleaved progress without executing their instructions simultaneously. That is concurrent execution without CPU parallelism. Two execution slots can support simultaneous execution of two runnable threads, but availability alone does not guarantee that a scheduler actually runs them together.

A context switch changes the execution context being run. A system call is a controlled request for an OS service. These are not synonyms: a system call can return to the same thread without switching to another, and a timer interrupt can cause preemption even when the program did not request an OS service. A mode change alone does not establish a process switch.

For a multithreaded process, different threads can have different execution states. The simple process-level trace above works because each process was explicitly given one thread. Do not extend its “one state per process” shorthand into a claim that all threads of a process always run or block together.

Key points and common mistakes

• Count execution instances, not executable filenames, when counting processes.
• Identify shared data separately from per-thread execution context.
• Ready means eligible; blocked means an event is still required.
• I/O completion normally restores eligibility, not a guaranteed immediate run.
• One CPU can interleave tasks. Interleaving can still create synchronization problems.
• Do not conclude that every system call switches processes, that a blocked process consumes the CPU, or that separate stacks provide isolation between threads.

Original practice: six single-correct MCQs

Original questions, not previous-year questions. Choose exactly one option. All question assumptions continue to apply.

C01. Two threads belong to one ordinary process. Which item is normally separate for each thread?

A. Heap address space B. Program counter and register state C. Executable code in the process address space D. Process-level open-file resources

Answer: B

A: Threads normally share the process address space and heap objects.

B: Each thread needs its own execution position and register values so it can resume independently.

C: Threads can execute shared code at different positions; sharing code does not mean sharing one program counter.

D: Open-file resources are normally shared at process level in the model used here.

C02. A blocked process completes its I/O while another process continues running non-preemptively. What is the first process's state before its next dispatch?

A. Running B. Terminated C. Ready D. Still blocked on that completed I/O

Answer: C

A: It has not been dispatched and the other process still has the CPU.

B: Finishing an I/O request is not the same as finishing the process.

C: The required event has completed, restoring eligibility, but it still waits for CPU selection.

D: The specified I/O no longer blocks it; no other blocking condition is given.

C03. A and B arrive at time 0, and A runs first. A needs CPU 2, then blocking I/O 3, then CPU 1; B needs CPU 4. With one CPU, non-preemptive execution, overlapping I/O and zero overhead, when does A finish?

A. 5 B. 6 C. 7 D. 10

Answer: C

A: Time 5 completes A's I/O, not its final CPU burst.

B: B finishes at 6; A still needs one final CPU unit.

C: A runs 0–2, blocks 2–5, waits ready 5–6 while B finishes, then runs 6–7.

D: Adding every CPU and I/O duration ignores that A's I/O overlaps B's CPU execution.

C04. On a machine with one CPU execution slot, T1 and T2 alternate execution. Which statement follows?

A. They can be concurrent without simultaneous CPU execution. B. They must execute CPU instructions simultaneously. C. They must have separate process address spaces. D. A race condition is impossible.

Answer: A

A: Interleaving provides concurrency; the single execution slot excludes simultaneous execution on that CPU.

B: Only one thread executes on the single slot at an instant.

C: Threads of one process can also alternate, so address-space separation does not follow.

D: A switch between a shared read and later write can still produce a race.

C05. Which statement about a system call is correct?

A. It always starts a new process. B. It always terminates the caller. C. It always switches to another process. D. It may return to the same thread without a context switch to another thread.

Answer: D

A: Many services, such as obtaining information, do not create processes.

B: Process exit is one service, not the behavior of every system call.

C: A service request and a change of running execution context are different events.

D: A system call enters an OS service; another thread need not be selected before it returns.

C06. Only one unfinished process exists, and it is blocked on I/O. No other schedulable work is ready. What can the CPU do until the event completes?

A. Run that blocked process's next ordinary instruction anyway B. Be idle because no process is eligible C. Declare the process terminated D. Make the I/O duration zero by scheduling it

Answer: B

A: Blocked means the specified event is required before execution can continue.

B: An unfinished but blocked process need not keep the CPU busy.

C: Waiting for an event does not imply completion.

D: Scheduling cannot erase the given device-wait duration.

Sources and scope

This original introductory lesson aligns with Section 8, Operating System, of the official GATE 2027 CS syllabus. It does not complete OS or the full syllabus. The syllabus verifies topic relevance; the primary textbook references verify foundational concepts. Examples, timelines and practice are original.

• Official GATE 2027 CS syllabus
• OSTEP: The Abstraction: The Process
• OSTEP: Concurrency: An Introduction

Sources checked 2026-10-14.