Operating Systems

Course Code: CS211

Instructor: Dr. Sarah Iqbal

Lecture # 6
Agenda for Today
 Process management in UNIX/Linux— system calls:
fork, exec, wait, exit
 The wait and exit system calls

2
 Process Creation
 During execution, a process may create several new processes.
 The creating process is called a parent process, and the new processes
are called the children of that process.
 Each of these new processes may in turn create other processes,
forming a tree of processes.
 Most operating systems (including UNIX, Linux, and Windows) identify
processes according to a unique process identifier (or pid), which is
typically an integer number.
 The pid provides a unique value for each process in the system, and it
can be used as an index to access various attributes of a process
within the kernel.

3
 fork()
 When the fork() system call is executed, a new process is created
which consists of a copy of the address space of the original
process (parent).
 This mechanism allows the parent process to communicate
easily with its child process.

SYNOPSIS
#include <sys/types.h>
#include <unistd.h>
pid_t fork(void);
4
 fork() ...
 The return code for fork() is zero for the new (child)
process and the process identifier of child is returned
to the parent process.
 On success, both processes continue execution at the
instruction after the fork call.
 On failure, -1 is returned to the parent process and
errno is set appropriately to indicate the reason of
failure; no child is created
 After a fork() system call, one of the two processes
typically uses the exec() system call to replace the
process’s memory space with a new program.
5
 wait()
 The parent can then create more children
 Or, if it has nothing else to do while the child runs, it
can issue a wait() system call to move itself off the
ready queue until the termination of the child.
 The call to exec() overlays the process’s address space
with a new program, exec() does not return control
unless an error occurs.

6
fork()—Sample Code

7
 We have two different processes running copies of the same program.
 The only difference is that the value of the variable pid for the child process is zero,
while for the parent it is an integer value greater than zero.
 The child process inherits privileges and scheduling attributes from the parent, as
well certain resources, such as open files.
 The child process then overlays its address space with the UNIX command /bin/ls
using the execlp() system call (execlp() is a version of the exec() system call).
 The parent waits for the child process to complete with the wait() system call
 When the child process completes, the parent process resumes from the call to
wait(), where it completes using the exit() system call.
8
fork()—Inherits from the Parent
 The child process inherits the following attributes from
the parent:
 Environment
 Open file descriptor table
 Signal handling settings
 Nice value
 Current working directory
 Root directory
 File mode creation mask (umask) etc.

9
fork()—Child Differs from the Parent
 The child process differs from the parent process:
 Different process ID (PID)
 Different parent process ID (PPID)
 Return value from fork()
 Child times for CPU usage are reset to ‘0’
 File locks held by parent are not inherited to child
 Set of pending alarms in the parent are cleared in
child
 Child has its own copy of parent’s file descriptors etc.

10
11
fork()—Reasons for Failure

 Maximum number of processes allowed to execute

under one user has exceeded
 Maximum number of processes allowed on the system
has exceeded
 Not enough swap space

12
 exit()
 A process terminates when it finishes executing its final statement and
asks the operating system to delete it by using the exit() system call.
 At that point, the process may return a status value (typically an
integer) to its waiting parent process (via the wait() system call).
 A parent process may wait for the termination of a child process by
using the wait() system call. This system call is passed a parameter that
allows the parent to obtain the exit status of the child.
 This system call also returns the process identifier of the terminated
child so that the parent can tell which of its children has terminated.

13
 exit()…
 All the resources of the process—including physical and virtual
memory, open files, and I/O buffers—are deallocated and reclaimed by
the operating system.
• However, after exit, its entry in the process table must remain there
until the parent calls wait(), because the process table contains the
process’s exit status.
• A process that has terminated, but whose parent has not yet called
wait(), is known as a zombie process.
• All processes transition to this state when they terminate, but
generally they exist as zombies only briefly.
• Once the parent calls wait(), the process identifier of the zombie
process and its entry in the process table are released.
14
 exit()…

 If a parent did not invoke wait() and instead terminated, thereby leaving its
child processes as orphans.
 Traditional UNIX systems addressed this scenario by assigning the init
process as the new parent to orphan processes.
 The init process periodically invokes wait(), thereby allowing the exit status
of any orphaned process to be collected and releasing the orphan’s process
identifier and process-table entry.
 Although most Linux systems have replaced init with systemd, the latter
process can still serve the same role, although Linux also allows processes
other than systemd to inherit orphan processes and manage their
termination

15
 Cascading Termination
 Some systems do not allow a child to exist if its parent has
terminated.
 In such systems, if a process terminates (either normally or
abnormally), then all its children must also be terminated.
 This phenomenon, referred to as cascading termination, is
normally initiated by the operating system.

16
 Reference & Reading Material
• “Operating Systems Concepts”,
Chapter 3 “Processes”
• “Operating Systems: Three Easy Pieces”, Remzi H. and Andrea C.
Arpaci-Dusseau
Chapter 5
Interlude: Process API
Section 5.1, 5.2, 5.3

17