System calls and the process API

1User mode and kernel mode

The CPU has a privilege bit. In user mode, maya may run her own editor instructions and may not touch another process's memory or talk to the disk controller directly. In kernel mode, the operating system may do those things. The bit is the fence: user code asks; kernel code is allowed.

maya spends almost all of her time in user mode. She crosses into kernel mode only when she needs a service the fence forbids — open a file, read the disk, create a process. That crossing is the system call.

Figure. maya runs in user mode. A request she is not allowed to perform herself crosses into kernel mode.

Who may do what

1. User modemaya's editor code. No raw disk, no other process's memory.
2. Kernel modeThe OS. May change page tables, talk to devices, create PIDs.
3. The fencemaya cannot flip the bit herself. She asks, through a system call.

2A system call is a request through the fence

A system call is a named request from user mode into the kernel: open, read, write, fork, exec, wait, exit. maya does not jump to kernel code like an ordinary function. She executes a trap instruction. The CPU switches to kernel mode, the kernel looks up which service she asked for, does the work (or refuses it), and returns to user mode with a result.

A library function such as printf is not itself a system call. It may end up calling write. The system call is the trap, not the C name in a textbook. If maya never needs the kernel, she never traps.

Figure. maya does not call the disk driver. She traps; the kernel runs the service and returns.

One call

1. Askmaya executes a trap with a service number — say, read.
2. SwitchThe CPU enters kernel mode. The fence is open for the OS only.
3. ReturnThe kernel finishes, puts a result in a register, and returns to user mode.

Names, not a runnable kernel

fd = open("essay.txt")   # trap: open
n  = read(fd, buf, 64)    # trap: read
pid = fork()              # trap: fork — returns twice

3One fork, two processes, two return values

fork() is the process API most people meet first. maya, PID 1420, calls fork(). The kernel copies her address space, open files and registers into a new process — say PID 1421. Then it returns in both. In 1421 the return value is 0. In 1420 the return value is 1421.

That is why textbook code writes if (pid == 0) for the child and else for the parent. There is no third return. A failed fork returns −1 in the caller and creates no child — one return, the error path.

Figure. One call. Two processes. The child sees 0; the parent sees the child's PID.

Who sees what

1. BeforeOnly maya, PID 1420, is running this line.
2. After success1420 sees pid = 1421. 1421 sees pid = 0.
3. After failureOnly 1420 remains; the return is −1.

4fork() returns twice and doubles the count

maya, still PID 1420, can ask the kernel to clone her. The call is fork(). After a successful fork the machine has two processes: the parent (still 1420) and a child with a new PID. fork() returns twice — once in each process. The child sees 0. The parent sees the child's PID, a positive number. That is how each side knows who it is.

If maya, and every child she creates, calls fork() again with no one exiting, each call doubles the crowd. After n such calls the total number of processes is 2^n, including the original. New children created along the way are 2^n - 1. Three calls in a row: 2^3 = 8 processes, 7 of them new.

Figure. Standard tree when every living process runs all three forks: P0's children are C1 (fork 1), C2 (fork 2) and leaf C4 (fork 3). Eight nodes total — 2^3.

Why the count doubles

1. Each call doublesEvery living process that reaches the next fork() becomes two.
2. n in a rowStarting from 1, after n sequential forks the total is 2^n.
3. Watch the returnsParent sees PID > 0; child sees 0 — useful when a problem asks who runs which branch.

Three forks in a row

int main(void) {
    fork();
    fork();
    fork();
    /* how many processes now? */
    return 0;
}

Coding lab. Count the processes after three forks runs in the app, with checks on your output.

5exit ends a process; wait collects it

When the child PID 1421 is done, it calls exit. That moves it to Terminated and leaves a small record — the exit status — behind so the parent can read it. Until someone collects that record, 1421 is a zombie: dead, but still occupying a PCB slot.

maya, the parent, calls wait (or waitpid). The kernel hands her the exit status and frees the child's PCB. If she calls wait before the child has exited, she blocks — Running → Waiting — until 1421 exits. If she never waits, zombies accumulate. The pair is the process API: fork creates, exit ends, wait collects.

Figure. exit without wait leaves a zombie. wait reads the status and frees the PCB.

Create, end, collect

1. fork1420 creates 1421.
2. exit1421 finishes and leaves a status. It is a zombie until collected.
3. wait1420 reads the status. The PCB slot is freed.