% !TEX TS-program = pdflatex
% !TEX encoding = UTF-8 Unicode

% This file is a template using the "beamer" package to create slides for a talk or presentation
% - Talk at a conference/colloquium.
% - Talk length is about 20min.
% - Style is ornate.

% MODIFIED by Jonathan Kew, 2008-07-06
% The header comments and encoding in this file were modified for inclusion with TeXworks.
% The content is otherwise unchanged from the original distributed with the beamer package.

\documentclass{beamer}


% Copyright 2004 by Till Tantau <tantau@users.sourceforge.net>.
%
% In principle, this file can be redistributed and/or modified under
% the terms of the GNU Public License, version 2.
%
% However, this file is supposed to be a template to be modified
% for your own needs. For this reason, if you use this file as a
% template and not specifically distribute it as part of a another
% package/program, I grant the extra permission to freely copy and
% modify this file as you see fit and even to delete this copyright
% notice. 


% \mode<presentation>
% {
%   \usetheme{Warsaw}
%   % or ...
% 
%   \setbeamercovered{transparent}
%   % or whatever (possibly just delete it)
% }
\usetheme{CambridgeUS}
\usecolortheme{beaver}

\usepackage[english]{babel}
% or whatever

\usepackage[utf8]{inputenc}
% or whatever

\usepackage{times}
%\usepackage[T1]{fontenc}
% Or whatever. Note that the encoding and the font should match. If T1
% does not look nice, try deleting the line with the fontenc.
\usepackage{color}
\beamertemplateshadingbackground{blue}{yellow}
%\usepackage{}
\title[IOSY 332C \& IOPS 332C: OS] % (optional, use only with long paper titles)
{ Lecture 3 - Process}

%\subtitle
%{Include Only If Paper Has a Subtitle}

\author [Bibhas Ghoshal]% (optional, use only with lots of authors)
{ Instructor : Bibhas Ghoshal (\textcolor{black}{bibhas.ghoshal@iiita.ac.in})} 



% - Give the names in the same order as the appear in the paper.
% - Use the \inst{?} command only if the authors have different
%   affiliation.

%\institute % (optional, but mostly needed)
%{
  %\inst{1}%
 % Department of Computer Science and Engineering\\
 % Indian Institute of Technology, Kharagpur}

%  \and
 % \inst{2}%
  %Department of Theoretical Philosophy\\
  %University of Elsewhere}
% - Use the \inst command only if there are several affiliations.
% - Keep it simple, no one is interested in your street address.

\date% (optional, should be abbreviation of conference name)
{Autumn Semester, 2015}
% - Either use conference name or its abbreviation.
% - Not really informative to the audience, more for people (including
%   yourself) who are reading the slides online

%\subject{Theoretical Computer Science}
% This is only inserted into the PDF information catalog. Can be left
% out. 



% If you have a file called "university-logo-filename.xxx", where xxx
% is a graphic format that can be processed by latex or pdflatex,
% resp., then you can add a logo as follows:

\pgfdeclareimage[height=0.75cm]{university-logo}{IIIT_logo.jpg}
 \logo{\pgfuseimage{university-logo}}



% Delete this, if you do not want the table of contents to pop up at
% the beginning of each subsection:
% \AtBeginSubsection[]
% {
%   \begin{frame}<beamer>{Outline}
%     \tableofcontents[currentsection,currentsubsection]
%   \end{frame}
% }


% If you wish to uncover everything in a step-wise fashion, uncomment
% the following command: 

%\beamerdefaultoverlayspecification{<+->}


\begin{document}

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}{Lecture Outline}
  \begin{itemize}
   \item Process Concept
   \item Process State
   \item Process Control Block
   \item Process Operation
   \item Inter Process Communication : 
   
	  \begin{itemize}
	   \item Shared Memory
	   \item Message Passing
	  \end{itemize}
   \item Producer/Consumer Problem
 \end{itemize}
        
        
\textcolor{red}{References and Illustrations have been used from:}
 \begin{itemize}
  \item lecture slides of the book - Operating System Concepts by Silberschatz, Galvin and Gagne, 2005 
  \item Modern Operating System by Andrew S. Tanenbaum
  \item lecture slides of CSE 30341: Operating Systems (Instructor : Surendar Chandra), 
 \end{itemize}

  
\end{frame}



 \begin{frame}{Process Concept}


\textbf{Process}  : Program in execution; process execution must progress in sequential fashion; a process is more than a code.\\
A process includes the following:\\
 \begin{itemize}
  \item The \emph{text} section (code),  \emph{data} section (global variables)
   \item \emph{Program counter} and contents of registers
   \item \emph{Stack} to contain function parameters and return addresses (during recursive calls)
  \item \emph{Heap} required during dynamic memory allocations
     \end{itemize}

     \begin{figure}{h}
  \centering
  \includegraphics[width=0.35\textwidth]{process.pdf}
  \caption{Process address Space}
 \end{figure}
     
\end{frame}


% \begin{frame}{Process in Memory}
%  
%  
%  
% \end{frame}


\begin{frame}{Process Concept contd.}
 \begin{figure}
  \centering
  \includegraphics[width=0.35\textwidth]{program.pdf}
  \caption{Program Execution}
 \end{figure}

\begin{itemize}
 \item Exec.c will reside in secondary storage. OS will pick it up and put it in main memory and execute.
\item When OS puts the program in main memory, a \textcolor{red}{process} is created.
\item The OS maintains a data structure for each process called a \textcolor{green}{Process Control Block}

\end{itemize}


 
\end{frame}


\begin{frame}{Process Structure}
 \begin{figure}
  \centering
  \includegraphics[width=0.55\textwidth]{pcb1.pdf}
  \caption{Process created during execution of a.out}
 \end{figure}

While executing the program, one is restricted within the process boundary, else \textbf{Segmentation Fault}

\end{frame}

\begin{frame}{Process Attributes}
\begin{itemize}
 \item Process ID : unique number assigned to each process
 \item Program Counter
 \item Process State
 \item Priority
 \item General Purpose Registers
 \item List of open files
 \item List of open devices
 \item Protection
\end{itemize}

 
\end{frame}

\begin{frame}{Process Control Block}
Information associated with each process and maintained by the operating system

\begin{itemize}
 \item Process State
 \item Program counter
 \item CPU registers
 \item CPU scheduling information
 \item Memory-management information
 \item Accounting information
 \item I/O status information
\end{itemize}
\end{frame}
\begin{frame}{Process Control Block}
\begin{figure}
  \centering
  
  \includegraphics[width=0.75\textwidth]{PCB.pdf}
  \caption{PCB}
 \end{figure}
 
 
\end{frame}



\begin{frame}{Process State}
As a process executes, it changes state
\begin{itemize}
 \item new:  The process is being created (process is in secondary memory)
 \item ready:  process is waiting to be assigned to a processor (process in main memory)
 \item running:  Instructions are being executed (process in main memory)
 \item waiting:  The process is waiting for some event to occur (process in main memory)
 \item terminated:  The process has finished execution (the PCB and all traces of process is deleted)
 \item suspend ready : processes which were in ready state, but due to lack of resources are backed up in secondary memory
 \item suspend block : suspend processes which are in blocked/waiting stste and send them to secondary memory
\end{itemize}
\end{frame}


\begin{frame}{Process State Diagram}
\begin{figure}{h}
  \centering
  \includegraphics[width=0.65\textwidth]{process_state.pdf}
  \caption{Process States}
 \end{figure}
 
 
\end{frame}




\begin{frame}{CPU switch from P0 to P1 : Context switching}
Save all state of P0, restore all state of P1, save 

\begin{figure}
  \centering
  
  \includegraphics[width=0.65\textwidth]{cpu_switch.pdf}
  \caption{PCB}
 \end{figure}
 
 
\end{frame}



\begin{frame}{Ready Queue and other Device Request}

\begin{figure}
  \centering
  
  \includegraphics[width=0.65\textwidth]{pcb_queue.pdf}
  \caption{PCB}
 \end{figure}
 
 
\end{frame}


\begin{frame}{Scheduler}

\begin{itemize}
 \item \textcolor{red}{Long-term scheduler}  (or job scheduler) – selects which processes should be brought into the ready queue
    \begin{itemize}
     \item invoked very infrequently (seconds, minutes) - (may be slow)
     \item should have mix of CPU bound process and I/O bound process
    \end{itemize}

 \item \textcolor{red}{Short-term scheduler}  (or CPU scheduler) – selects which process should be executed next and allocates CPU
    \begin{itemize}
     \item invoked very frequently (milliseconds) - (must be fast)
     \item apart from decision making, everything else is done by \emph{dispatcher}
     \item dispatcher schedules process with minimum context length
    \end{itemize}
    
 \item \textcolor {red}{Medium-term scheduler} moves some processes to disk and vice-versa - \emph{swapping}
 \item Processes can be described as either:
    \begin{itemize}
     \item I/O-bound process – spends more time doing I/O than computations, many short CPU bursts
     \item CPU-bound process – spends more time doing computations; few very long CPU bursts
    \end{itemize}
    
\end{itemize}

\end{frame}


\begin{frame}{Numerical example}
Consider a system with \textbf{N} processors and \textbf{M} processes, then\\
the number of processes that will be there in each of the following states are:\\
\begin{center}
\begin{tabular}{|c|c|c|}\hline
State & minimum & maximum\\\hline
Ready & 0 & M\\\hline
Running & 0 & N\\\hline
Block & 0 & M\\\hline
\end{tabular}
\end{center}

 
\end{frame}










\begin{frame}{Operations on Process}

\begin{itemize}
 \item Process creation
    \begin{itemize}
     \item Parent creates new process forming a tree
     \item Child process can run concurrently with parent or not
     \item Child can share all resources, some or none at all
    \end{itemize}
\item Process Scheduling
\item Process Execution
 \item Process termination
    \begin{itemize}
     \item Exit for normal termination
        \begin{itemize}
         \item Output data from child to parent (via wait)
         \item exit() and \_exit() functions
        \end{itemize}
      \item Abort for abnormal kernel initiated termination
      \item Some OS require the presence of parent to allow child
    \end{itemize}
    
 
    
\end{itemize}

\end{frame}

\begin{frame}{Process Creation}
 \begin{itemize}
  \item Parent process create children processes, which, in turn create other processes, forming a tree of processes
  \item Generally, process identified and managed via a process identifier (pid)
  \item Resource sharing options
       \begin{itemize}
        \item Parent and children share all resources
        \item Children share subset of parent’s resources
        \item Parent and child share no resources
       \end{itemize}
   \item Execution options
      \begin{itemize}
       \item Parent and children execute concurrently
       \item 
Parent waits until children terminate
      \end{itemize}

 \end{itemize}

 \end{frame}


\begin{frame}{A Tree of Processes in Linux}
 \begin{figure}
  \centering
  
  \includegraphics[width=0.65\textwidth]{tree_process_linux.pdf}
  %\caption{}
 \end{figure}
\end{frame}

\begin{frame}{Process Creation}
 \begin{figure}
  \centering
  
  \includegraphics[width=0.65\textwidth]{process_creation.pdf}
  %\caption{PCB}
 \end{figure}
\end{frame}








\begin{frame}{C program of fork}
 
 \begin{figure}
  \centering
  
  \includegraphics[width=0.75\textwidth]{fork.pdf}
 % \caption{PCB}
 \end{figure}
\end{frame}


\begin{frame}{Process Termination}

\begin{itemize}
 \item Process executes last statement and then asks the operating system to delete it using the exit() system call.
    \begin{itemize}
     \item Returns  status data from child to parent (via wait())
     \item Process’ resources are deallocated by operating system
     
    \end{itemize}
 \item Parent may terminate the execution of children processes  using the abort() system call.  Some reasons for doing so:
    \begin{itemize}
      \item Child has exceeded allocated resources
      \item Task assigned to child is no longer required
      \item The parent is exiting and the operating systems does not allow  a child to continue if its parent terminates
    \end{itemize}

\end{itemize}

\end{frame}
 
\begin{frame}{Process Termination}

\begin{itemize}
\item Some operating systems do not allow child to exists if its parent has terminated.  If a process terminates, then all its children must also be terminated.
 \begin{itemize}
  \item cascading termination.  All children, grandchildren, etc.  are  terminated.
  \item The termination is initiated by the operating system.
 \end{itemize}
\item The parent process may wait for termination of a child process by using the wait()system call. The call returns status information and the pid of the terminated process\\
      pid = wait(\&status); 
\item If parent terminated (died) without invoking wait, process is an \textbf{orphan} 
\item If no parent waiting (did not invoke wait()) process is a \textbf{zombie}
\item Zombie process - A child process has completed execution (died) (via the \emph{exit} system call) but still has an entry in the process table \\ This entry is still needed to allow the parent process to read its child's exit status (using the \emph{wait()} sys call). Then the descriptor is removed (no longer zombie).

\end{itemize}

\end{frame}

\begin{frame}{Example of Zombie process}
 \begin{figure}
  \centering
  
  \includegraphics[width=0.75\textwidth]{zombie.pdf}
 % \caption{PCB}
 \end{figure}
\end{frame}



\begin{frame}{Interprocess communications}
 \begin{itemize}
  \item \textcolor{red}{Independent process} cannot affect or be affected by the execution of another process
\item \textcolor{red}{Cooperating process} can affect or be affected by the execution of another process
\item Advantages of process cooperation
      \begin{itemize}
       \item Information sharing 
\item Computation speed-up
\item Modularity
\item Convenience
      \end{itemize}

 \end{itemize}

\end{frame}


\begin{frame}{IPC mechanisms}
 \begin{itemize}
  \item Shared memory
     \begin{itemize}
      \item Create shared memory region
      \item When one process writes into this region, the other process can see it and vice versa
      
     \end{itemize}
  \item Message passing
     \begin{itemize}
      \item Explicitly send() and receive()
     \end{itemize}

 \end{itemize}

 
\begin{figure}
  \centering
  
  \includegraphics[width=0.65\textwidth]{ipc.pdf}
 % \caption{PCB}
 \end{figure}
\end{frame}


\begin{frame}{Producer-Consumer Problem}
 \begin{itemize}
  \item Paradigm for cooperating processes, producer process produces information that is consumed by a consumer process
   \begin{itemize}
    \item  \textbf{unbounded-buffer} places no practical limit on the size of the buffer
    \item \textbf{bounded-buffer} assumes that there is a fixed buffer size
   \end{itemize}
\end{itemize}

\end{frame}

\begin{frame}{Bounded-Buffer – Shared-Memory Solution}
 \begin{itemize}
  \item Shared data :
\begin{figure}
  \centering
  
  \includegraphics[width=0.85\textwidth]{bounded_buffer.pdf}
 % \caption{PCB}
 \end{figure}	

\item Solution is correct, but can only use \textbf{BUFFER\_SIZE-1} elements

 \end{itemize}

\end{frame}

\begin{frame}{Bounded Buffer : Producer}
 
 \begin{figure}
  \centering
  \includegraphics[width=0.85\textwidth]{bounded_buffer_producer.pdf}
 % \caption{PCB}
 \end{figure}	

\end{frame}


\begin{frame}{Bounded Buffer : Consumer}
 
 \begin{figure}
  \centering
  \includegraphics[width=0.85\textwidth]{bounded_buffer_consumer.pdf}
 % \caption{PCB}
 \end{figure}	

\end{frame}


\begin{frame}{Interprocess Communication –  Shared Memory}
 \begin{itemize}
  \item An area of memory shared among the processes that wish to communicate
\item The communication is under the control of the users processes not the operating system.
\item Major issues is to provide mechanism that will allow the user processes to synchronize their actions when they access shared memory. 
 \end{itemize}

\end{frame}


\begin{frame}{Interprocess Communication – Message Passing}
\begin{itemize}
 \item Mechanism for processes to communicate and to synchronize their actions

\item Message system – processes communicate with each other without resorting to shared variables

\item IPC facility provides two operations:
 \begin{itemize}
\item \textbf{send}(message)
\item \textbf{receive}(message)
\end{itemize}

\item The message size is either fixed or variable
\end{itemize}

\end{frame}

\begin{frame}{Interprocess Communication – Message Passing}
\begin{itemize}
 \item If processes P and Q wish to communicate, they need to:
    \begin{itemize}
     \item Establish a communication link between them
     \item Exchange messages via send/receive
  \item Implementation issues:
     \begin{itemize}
      \item How are links established?
      \item Can a link be associated with more than two processes?
\item How many links can there be between every pair of communicating processes?
\item What is the capacity of a link?
\item Is the size of a message that the link can accommodate fixed or variable?
\item Is a link unidirectional or bi-directional?
     \end{itemize}

    \end{itemize}

\end{itemize}

 
\end{frame}

\begin{frame}{Wrapup}
\begin{itemize}
 \item Processes are programs in execution
   \begin{itemize}
    \item Kernel keeps track of them using process control blocks
    \item PCBs are saved and restored at context switch
   \end{itemize}
\item Schedulers choose the ready process to run
\item Processes create other processes
\item On exit, status returned to parent
\item Processes communicate with each other using shared memory or message passing
\end{itemize}







 
\end{frame}



\end{document}