1. Unix Process Elements Reading Reference: Textbook: Chapter 3
Tanzir Ahmed CSCE 313 FALL 2018

2. Fork() Example 1 How many lines will be printed?
First, we have to unroll the loop:
#include <stdio.h>
int main (){
printf ("PID: %d\n", getpid());
for (int i=0; i<3; i++){
fork(); }
printf ("Done");
int main (){
printf ("PID: %d\n", getpid());
fork();
printf ("Done"); }

3. Fork Example 1 Let’s redraw the process for convenience:
#include <stdio.h>
int main (){
printf("PID:%d\n",getpid());//print1:P1
fork();
printf ("Done"); //print2:P2 }
Fork Example 1
Let’s redraw the process for convenience:
Then, let’s draw the other child processes: P1
fork() P2 P1
fork() P2
Child 1
fork() P2
Child 2 P2
Child 3 P2
fork() P2 P2 P2 P2 P2 P2 P2 P2 P2 P2 P2

4. Example. 2 Command prompt shows up
Shell does not wait for “grand children”

5. Example 3 Reference: http://www.makelinux.net/books/lkd2/ch03lev1sec2
Process Creation
Process creation in Unix is unique. Most operating systems implement a spawn mechanism to create a new process in a new address space, read in an executable, and begin executing it. Unix takes the unusual approach of separating these steps into two distinct functions: fork() and exec()[8]. The first, fork(), creates a child process that is a copy of the current task. It differs from the parent only in its PID (which is unique), its PPID (parent's PID, which is set to the original process), and certain resources and statistics, such as pending signals, which are not inherited. The second function, exec(), loads a new executable into the address space and begins executing it. The combination of fork()followed by exec() is similar to the single function most operating systems provide.
[8] By exec() I mean any member of the exec() family of functions. The kernel implements the execve() system call on top of which execlp(),execle(),execv() , and execvp() are implemented.
Copy-on-Write
Traditionally, upon fork() all resources owned by the parent are duplicated and the copy is given to the child. This approach is significantly naïve and inefficient in that it copies much data that might otherwise be shared. Worse still, if the new process were to immediately execute a new image, all that copying would go to waste. In Linux, fork() is implemented through the use of copy-on-write pages. Copy-on-write (or COW) is a technique to delay or altogether prevent copying of the data. Rather than duplicate the process address space, the parent and the child can share a single copy. The data, however, is marked in such a way that if it is written to, a duplicate is made and each process receives a unique copy. Consequently, the duplication of resources occurs only when they are written; until then, they are shared read-only. This technique delays the copying of each page in the address space until it is actually written to. In the case that the pages are never writtenfor example, if exec() is called immediately after fork()they never need to be copied. The only overhead incurred by fork() is the duplication of the parent's page tables and the creation of a unique process descriptor for the child. In the common case that a process executes a new executable image immediately after forking, this optimization prevents the wasted copying of large amounts of data (with the address space, easily tens of megabytes). This is an important optimization because the Unix philosophy encourages quick process execution.
fork()
Linux implements fork() via the clone() system call. This call takes a series of flags that specify which resources, if any, the parent and child process should share (see the section on "The Linux Implementation of Threads" later in this chapter for more about the flags). The fork(), vfork(), and __clone() library calls all invoke the clone() system call with the requisite flags. The clone() system call, in turn, calls do_fork().
The bulk of the work in forking is handled by do_fork(), which is defined in kernel/fork.c. This function calls copy_process(), and then starts the process running. The interesting work is done by copy_process():
It calls dup_task_struct(), which creates a new kernel stack, thread_info structure, and task_struct for the new process. The new values are identical to those of the current task. At this point, the child and parent process descriptors are identical.
It then checks that the new child will not exceed the resource limits on the number of processes for the current user.
Now the child needs to differentiate itself from its parent. Various members of the process descriptor are cleared or set to initial values. Members of the process descriptor that are not inherited are primarily statistically information. The bulk of the data in the process descriptor is shared.
Next, the child's state is set to TASK_UNINTERRUPTIBLE, to ensure that it does not yet run.
Now, copy_process() calls copy_flags() to update the flags member of the task_struct. The PF_SUPERPRIV flag, which denotes whether a task used super-user privileges, is cleared. The PF_FORKNOEXEC flag, which denotes a process that has not called exec(), is set.
Next, it calls get_pid() to assign an available PID to the new task.
Depending on the flags passed to clone(), copy_process() then either duplicates or shares open files, filesystem information, signal handlers, process address space, and namespace. These resources are typically shared between threads in a given process; otherwise they are unique and thus copied here.
Next, the remaining timeslice between the parent and its child is split between the two (this is discussed in Chapter 4).
Finally, copy_process() cleans up and returns to the caller a pointer to the new child.
Back in do_fork(), if copy_process() returns successfully, the new child is woken up and run. Deliberately, the kernel runs the child process first[9]. In the common case of the child simply calling exec() immediately, this eliminates any copy-on-write overhead that would occur if the parent ran first and began writing to the address space.

6. Zombies
Idea
When process terminates, still consumes system resources
Various tables maintained by OS (to store exit status)
Called a “zombie”
Living corpse, half alive and half dead
Reaping
Performed by parent on terminated child by calling wait() function
Parent is given exit status (i.e., wait (&status))
Kernel discards process

7. Zombie Example ps shows child process as “defunct”
void main () {
if (fork() == 0){ // child process
// exiting the child process right away
printf ("Child PID: %d\n", getpid ()); }
else{// parent process
printf ("Parent PID: %d\n", getpid ());
// do nothing
while (1);
ps shows child process as “defunct”
Terminated child continue to take resources in Zombie state
This state is over when
Parent is killed, or
Parent performs wait ()
Killing parent allows child to be reaped

8. States of a Process User view: A process is executing continuously
In reality: Several processes compete for the CPU and other resources
A process may be
Running: it holds the CPU and is executing instructions
Blocked(waiting): it is waiting for some I/O event to occur
Ready: it is waiting to get back on the CPU
Usually Interrupts
preempt
UNIX: ps to get process information
ready
running
Create
(new)
Exit
(terminated)
dispatch
I/O or
Event complete
DMA Interrupts
I/O or event wait
System Calls
blocked

9. Questions
How many processes can be in the running state simultaneously?
What state do you think a process is in most of the time?
Check out: /etc/security/limits.conf

10. Process Data Structures
How does the OS represent a process in the kernel?
Using a data structure called Process Control Block (PCB)
The PCB is where the OS keeps all of a process’ hardware execution state (PC, SP, regs, open file handlesetc.) when the process is not running
This state is everything that is needed to restore the hardware to the same configuration

11. Process Control Block (PCB)
process identification
process id
parent process id
user id
etc…
processor state information
register set
All general regs
Specials (e.g., PC, SP, EFLAGS)
condition codes
Overflow, jump to take or not
processor status
process control information
process state
scheduling information
event (wait-for)
memory-mgmt information
owned resources (e.g., list of opened files)

12. Process Context Switch
Mechanism of a process switch:
Process A
Process B
process identification
Preempt Process A and store
all relevant information.
(idle)
Load information about
Process B and continue execution
processor state
information
(idle)
Context switch
Preempt Process B and store
all relevant information.
process control
information
Load information about
Process A and continue execution
(idle)
Process Control Block

13. Process Scheduling Queues
Job queue – set of all processes in the system
Ready queue – set of all processes residing in main memory, ready and waiting to execute
Device queues – set of processes waiting for an I/O device
Processes migrate among the various queues

14. Example for the Use of PCBs: Process Queues
ready
running
executing process
waiting
ready queue
disk 1
I/O device queues
disk 2
serial I/O

15. Types of Process
Based on which queue a process spends most of its time, we can classify processes to 2 types:
I/O-bound Processes
Spend most time in I/O queues
Example: A web-server reading requests from network (I/O), reading files from disk (I/O), writing response back to network (I/O), and some request parsing (CPU)
CPU-bound Processes
Spend most time in ready queue or as running
Example: A program computing large prime numbers – a lot of computations involving CPU, but no/less I/O

16. Basis of Process Scheduling
CPU is a scarce resource (only 1 instruction at a time)
No limit to the number of processes that want to run simultaneously (# of CPUs or cores/CPU is always limited)
The same is true for each I/O device (1 operation at a time)
So, we have 2 resources working independently – CPU and I/O devices
DMA makes sure that I/O does not involve CPU (i.e., except the initiation and completion)
If a process needs I/O, another process can pick up the CPU
Idea came from multi-programming
Efficient use of these 2 resources is necessary
If all processes are CPU-bound, there is a lot more competition
The same is true for I/O bound processes – every process trying to read the same disk will lead to slow performance
Luckily, in reality, we have a mix of I/O- and CPU-bound processes

17. Schedulers Long-term scheduler (or job scheduler)
Selects which processes should be brought into the ready queue
Must select a good mix of I/O-bound and CPU-bound processes
Main motivation: keeping the CPU and I/O devices busy simultaneously
Short-term scheduler (or CPU scheduler)
selects which process should be executed next and allocates CPU
executes at least every 100ms, therefore must be very fast
Medium-term scheduler (swapper)
sometimes processes are removed temporarily from memory (suspended)

18. CPSC 410 / 611 : Operating Systems
Schedulers
start
long-term (admission) scheduler
short-term (CPU) scheduler
suspended
ready
ready
running
suspended
blocked
blocked
medium-term (memory) scheduler
Long-term scheduler (job scheduler)
controls degree of multiprogramming
must select a good process mix of I/O-bound and CPU-bound processes
Short-term scheduler:
allocates the CPU
executes at least every 100ms, therefore must be very fast
Medium-term scheduler (swapper):
in some OSs
sometimes good to temporarily remove processes from memory

19. Summary What are the units of execution? Processes
How are those units of execution represented?
Process Control Blocks (PCBs)
How is work scheduled in the CPU?
Process states, process queues, context switches
What are the possible execution states of a process?
Running, ready, waiting
How does a process move from one state to another?
Scheduling, I/O, creation, termination
How are processes created?
fork/exec (Unix)