BCS401 Operating System Semester IV · AY 2025-26 onward
Unit 2 · Concurrent Processes

Lecture 1: Process concept & creation

Back to contents Next →

Learning outcomes

  • Define a process and differentiate it from a program.
  • Explain what information the OS maintains to manage a process (PID, state, PCB, queues).
  • Describe how processes are created (parent–child model) and how the OS manages them until termination.

Prerequisites

Unit 1 basics: OS role as resource manager and service provider. Basic idea of CPU scheduling (CPU gives time to one program at a time). Basic memory terms: code, data, stack, heap. Helpful (not mandatory): simple C program idea and the meaning of a system call.

Lecture Notes

Main content

1) Program vs Process

Program (Passive)
  • A file on disk that contains instructions (executable).
  • It does nothing by itself until it is loaded and run.
Process (Active)
  • A program in execution.
  • Has an execution state: Program Counter + CPU registers.
  • Owns resources: memory, open files, I/O status, etc.
Key idea: You can run the same program multiple times → you get multiple processes. The code may be identical, but each process has its own data/heap/stack and its own CPU context.

2) What a process contains

Think of a process as: (Address Space) + (Execution Context) + (OS bookkeeping).

2.1 Address space (memory layout)

A typical process memory is divided into parts. Two parts are mostly fixed (Text/Code and Data), and two grow or shrink at runtime (Heap and Stack).

Fig 1.1: Typical Process Memory Layout (Low → High Address) Low High Text / Code (instructions) Data (global/static variables) Heap (dynamic allocation) — grows up Free space / gap Stack (calls/locals) — grows down up down
Text and Data are mostly fixed; Heap and Stack grow during execution. The OS ensures they do not collide.
2.2 Execution context (CPU state)
  • Program Counter (PC): the address of the next instruction to run.
  • CPU registers: store intermediate results, stack pointer, flags, etc.
  • CPU context must be saved/restored when the OS switches between processes.

3) Process Control Block (PCB): the OS “record file” for a process

The OS maintains a data structure per process, commonly called the Process Control Block (PCB). It contains everything required to manage the process and to pause/resume it correctly.

PCB Field What it stores Why it matters
Process state New, Ready, Running, Waiting/Blocked, Terminated Helps OS place the process in correct queue and schedule it.
Program counter Next instruction address Process resumes exactly where it stopped.
CPU registers General registers, stack pointer, flags Required for correct execution after switching.
Scheduling info Priority, queue pointers, time slice parameters Used by CPU scheduler to decide “who runs next”.
Memory info Page table / segment info, address space details Defines the process’s memory view and protection.
I/O status Open files, devices, pending I/O Required for I/O handling and cleanup.
Accounting CPU time used, IDs, usage statistics Monitoring, limits, debugging, fairness.

4) Process states (how the OS manages execution)

From the OS perspective, a process keeps moving through a small set of states. Only one process per CPU core can be Running at a time; others wait in queues.

Fig 1.2: Five-State Process Model NEW READY RUNNING WAITING / BLOCKED TERMINATED admit dispatch I/O or event wait I/O complete interrupt / time slice exit
New → Ready → Running → (Waiting/Ready) → Terminated. The scheduler moves processes between queues.

5) Process creation (how a new process is born)

A process is created when the OS receives a request to start execution of a program. Conceptually, process creation follows these steps:

  1. Request arrives: user runs a command, double-clicks an app, or another process asks to start a new program.
  2. OS allocates a PID and creates a new PCB entry (process table record).
  3. Address space is prepared: code/data loaded (or mapped), stack and heap initialized.
  4. Initial CPU context is prepared: entry point set, registers initialized.
  5. Process is placed in the Ready queue and later scheduled to run.
5.1 Parent–child relationship

In many systems, a running process can create another process. The creating process is the parent and the new one is the child. The OS tracks this using identifiers like PID and parent PID.

Why create child processes?
  • Modularity: split work into separate programs (e.g., editor + compiler + browser).
  • Fault isolation: crash in one process does not necessarily crash others.
  • Security: processes can run with different privileges.
5.2 UNIX / Linux model (fork → exec → wait)

A common conceptual model is: the parent uses a call like fork() to create a child process. The child can then use exec() to replace its memory image with a new program. The parent can use wait() to wait until the child finishes.

Fig 1.3: Parent–Child Creation Flow (fork → exec → wait) Parent Process (e.g., Shell) 1) Calls fork() 2) Gets child PID (parent side) 3) Optionally calls wait() 4) Continues after child terminates Child Process 1) Created as a new process (child side) 2) Often calls exec() to run a new program 3) Executes until exit() fork() parent waits (optional)
The parent creates a child; the child typically runs a new program using exec; the parent may wait for completion.
5.3 Process termination (how the OS cleans up)
  • Normal exit: process completes successfully and calls exit.
  • Error exit: process ends due to an error condition.
  • Abnormal termination: killed by another process or OS (e.g., protection violation).
  • Cleanup: OS releases memory, closes files, and removes PCB entry when safe.

6) Context switch (what the OS really does while “switching”)

When the OS stops one process and runs another, it performs a context switch. It saves the current process’s CPU state into its PCB and loads the next process’s CPU state from its PCB. This time is overhead because the CPU is not executing user code during save/restore.

Exam point: Frequent context switches reduce useful CPU time. Scheduling aims to balance responsiveness and overhead.

Worked Example

fork–exec–wait idea

Scenario: A student runs gcc hello.c in a terminal. The shell (parent) must create a child process to run the compiler.

Step-by-step OS view

  1. Shell is already a running process (has its own PID and PCB).
  2. Shell creates a child process (new PID, new PCB).
  3. Child replaces its program image with the compiler program (exec-style behavior).
  4. Child runs the compiler; may block for file I/O (Waiting state) and return to Ready/Running.
  5. Child exits after finishing compilation.
  6. Parent shell waits (optional) and then prints prompt again.

Where state transitions occur

  • Child: New → Ready → Running
  • During disk read: Running → Waiting
  • After I/O completes: Waiting → Ready
  • When finished: Running → Terminated
What is “created” during process creation? A PID, a PCB entry, an address space (code/data/heap/stack), and an initial CPU context so the scheduler can run it.

One-Page Summary

  • Program vs Process: Program is passive on disk; Process is the program executing with CPU context and resources.
  • Process components: Address space (Text/Code, Data, Heap, Stack) + Execution context (PC, registers) + OS bookkeeping.
  • PCB (Process Control Block): OS data structure holding state, PC, registers, scheduling info, memory info, I/O status, accounting.
  • Five states: New, Ready, Running, Waiting/Blocked, Terminated. Processes move among these via scheduler and I/O events.
  • Creation idea: OS allocates PID + PCB, prepares memory and initial context, places process in Ready queue.
  • Parent–child model: A process can create another process (child). Parent may wait for the child to finish.
  • Termination: normal exit / error / killed. OS releases resources and removes process entry when safe.
  • Context switch: save old process context to PCB and load new context from PCB; it is overhead but necessary for multitasking.