Module 2 · Unit 3 of 5

Processes

The central abstraction of a running program. This unit develops the process model, the states a process passes through during its life, the data structure the kernel uses to track it, and the mechanism by which the CPU is switched from one process to another.

Start Lesson 3.1 See all lessons

5 lessons Lab 2 · Process management CLO2 ≈ 1 week at recommended pace

01 Unit learning outcomes

Upon completion of this unit you will be able to

U3.1 — Explain the process model.
U3.2 — Analyse process states.
U3.3 — Describe process management structures.
U3.4 — Evaluate scheduling requirements.
U3.5 — Implement process-management solutions.

This unit addresses course learning outcomes CLO2, CLO6, and CLO8.

02 Lessons in this unit

The lessons move from the conceptual model of a process to the concrete data structures and kernel mechanisms that implement it. Lab 2 in this unit has you observing and manipulating processes directly in Linux.

Lesson 3.1

Process Concept

What a process is, how it differs from a program, and how a program becomes a running process.

Lesson 3.2

Process States

The five-state model, transitions, state diagrams, and how states relate to scheduling.

Lesson 3.3

Process Control Blocks

The PCB and what it holds, its role in the scheduler, and how process context is stored.

Lesson 3.4

Process Scheduling Basics

Scheduling goals, long/medium/short-term schedulers, metrics, and how to compare approaches.

Lesson 3.5

Context Switching

What happens during a switch, where the overhead comes from, and how to measure it.

03 What you will learn, lesson by lesson

3.1 Process Concept

Define a process.
Differentiate processes and programs.
Explain process execution.
Identify process resources.
Analyse process lifecycle events.

3.2 Process States

Describe process states.
Explain state transitions.
Interpret state diagrams.
Analyse process behaviour.
Relate states to scheduling.

3.3 Process Control Blocks

Explain PCB purpose.
Identify PCB contents.
Explain scheduler use of PCBs.
Describe process context.
Analyse process management.

3.4 Process Scheduling Basics

Explain scheduling goals.
Describe schedulers.
Define scheduling metrics.
Analyse performance.
Compare approaches.

3.5 Context Switching

Define context switching.
Describe switching operations.
Explain switching overhead.
Measure switching activity.
Analyse performance impact.

04 Worked example

A short program that creates a child process — the basic operation this unit will ask you to reason about.

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

int main(void) {
    pid_t pid = fork();

    if (pid < 0) {
        perror("fork");
        return 1;
    } else if (pid == 0) {
        /* child process */
        printf("child:  pid=%d, ppid=%d\n", getpid(), getppid());
    } else {
        /* parent process */
        printf("parent: pid=%d, child=%d\n", getpid(), pid);
        wait(NULL);   /* wait for child to finish */
    }
    return 0;
}

What the kernel does, step by step

The shell runs the program. It calls fork and exec to create a process running this code. The kernel allocates a PCB, assigns a PID, and sets the initial state to New.
The kernel admits the process. Once resources (memory, file descriptors) are ready, the state becomes Ready and the process is placed on the ready queue.
The scheduler dispatches it. When the CPU is free, the scheduler selects this process and transitions it to Running. It begins executing at main.
fork() is called. The kernel duplicates the parent's address space (using copy-on-write for efficiency) and creates a new PCB for the child. The child's state is Ready. Two processes now exist; the parent continues.
Both print. Depending on scheduling, the parent, the child, or both may run in any order. The output ordering is non-deterministic — an important property to notice.
The parent calls wait(). This blocks the parent: its state transitions from Running to Blocked. The scheduler picks another ready process — the child — and dispatches it.
The child prints and exits. It calls exit implicitly on return from main. The kernel transitions the child to Terminated, releases its resources, and signals the parent.
The parent resumes. The wait call returns the child's PID and status; the parent transitions back to Running, prints, and exits.

05 Required reading

OSTEP — Chapter 4, The Abstraction: The Process, and Chapter 5, Interlude: Process API.
Operating System Concepts — Chapter 3, Sections 3.1–3.3.
Man pages: fork(2), execve(2), wait(2), exit(3).

Read the man pages carefully

The fork man page describes the exact duplication semantics — what is shared, what is copied, what is inherited. Every one of those details affects a program's behaviour.

06 Unit discussion

Discussion prompt

The fork system call creates a new process by duplicating the calling process's address space. On Linux this is implemented efficiently using copy-on-write: pages are shared until either process writes to them, at which point a private copy is made.

Why is this design chosen over a "spawn a fresh process and pass it data" model? What workloads does it favour, and what workloads does it disadvantage? Consider both a shell pipeline (ls | grep foo) and a large server (a database engine, say).

Post your response to the Unit 3 discussion forum and reply to at least two classmates. Supports CLO2 and CLO8.

07 Laboratory connection

Lab 2 — Process Management is completed at the end of this unit. It asks you to write small C programs that create, wait for, and inspect processes, and to interpret the process tree of a running Linux system.

Lab 2 coverage
Lesson	Lab 2 exercise
3.1 Process Concept	Create and identify processes with `fork` and `getpid`
3.2 Process States	Observe blocking states with `wait` and `sleep`
3.3 Process Control Blocks	Inspect a live PCB via `/proc/<pid>/status`
3.4 Scheduling Basics	Observe the effect of `nice` on CPU share
3.5 Context Switching	Measure switching activity with `vmstat` and `pidstat`

08 Knowledge check & quiz

Quick check before you begin

Question 1

What is the difference between a program and a process?

Show answer

A program is a passive file — an executable image stored on disk containing code and static data. A process is an active execution of that program, with its own address space, registers, program counter, stack, heap, and kernel-managed resources. The same program can give rise to many concurrent processes.

Question 2

A process is in the Blocked state. What must happen before it can run again, and what state will it enter first?

Show answer

The event the process is waiting for must occur — for example, an I/O operation must complete or a signal must be delivered. When it does, the kernel transitions the process from Blocked to Ready, not directly to Running. Only the scheduler can move a process from Ready to Running.

Question 3

Why does the operating system need a PCB rather than simply storing process state on the process's own stack?

Show answer

Because the PCB must be accessible when the process is not running. The kernel, not the process, owns the PCB. It is read and updated during state transitions, by the scheduler when selecting the next process, by the memory manager when mapping pages, and by the file subsystem when handling descriptors. Storing this information on the process's own stack would make it inaccessible to the kernel at exactly the moments it is needed.