% !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 2 - Fundamental Concepts}

%\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 Operating System Overview : Re-visit
   \item Computer System Operation
   \item Storage Structure
   \item Storage Hierarchy
   \item Hardware protection
   \item Interacting with services provided by the OS
	  \begin{itemize}
	   \item System calls - link between application programs and OS
	   \item System programs - users interact using programs
	  \end{itemize}
   \item Installation, customization etc.
        \begin{itemize}
         \item booting
        \end{itemize}

  \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}


%\section{Operating System Overview : Re-visit}
\begin{frame}{Operating system Overview}
\begin{itemize} 
 
\item {Operating System allows the user to achieve the intended purpose of using the computer system in a fast and efficient manner}
 

        
\item {Operating system controls and coordinates use of hardware among various applications and users}

\end{itemize}
\underline{Key concerns of Operating System}
\begin{itemize}
\item Programs
\item Resources
\item Scheduling
\item Protection

%    \item Programs - load a program into memory, run the program, end execution, either normally or abnormally 
%                     (indicating error). A running program requires I/O, which may involve a file, an I/O device, shared with other programs or computers
%          
%     \item Resources - Ensuring availability of resources and allocating them to programs. 
% 
%     \item Scheduling - Deciding when and how long to devote the CPU to a program. Since, main memory is expensive, we use   
%           hierarchy and move stuff around to achieve cost benefits and speed
%    \item Protection - Protect data and programs against interference from other users and their programs
  \end{itemize}
\end{frame}


\begin{frame}{Computer System}
 \begin{figure}
  \centering
  \includegraphics[width=1.0\textwidth]{computer_system.pdf}
  \caption{Computer System}
 \end{figure}

\end{frame}
\begin{frame}{Operating System Overview}
\underline{Operating System Structure}
 \begin{itemize}
  \item Multiprogramming needed for efficiency
  \item Timesharing (multitasking)
  \item Multi-user 
  \item OS should protect the users/processes from each other as well as protect itself from users
  \item Dual-mode operation allows OS to protect itself and other system components
\end{itemize}
 \end{frame}

% \begin{frame}{Issues with multi-programming}
% \textbf{Problems Associated:}
%  \begin{itemize}
%   \item How to protect programs from one another and kernel from them all?
%   \item How to handle relocation?
%  \end{itemize}
% \textbf{Solution : } equip CPU with special hardware\\ For example : \emph{Base register} and \emph{Limit register} to handle relocation problem
% \end{frame}
% 
% \begin{frame}{Solution to re-location problem : Use of base-limit pair}
%  \begin{figure}
%   \centering
%   \includegraphics[width=0.9\textwidth]{relocation_problem_soln.pdf}
%   \caption{Use of base-limit pair}
%  \end{figure}
% \end{frame}


\begin{frame}{Hardware Control Aspect of the Operating System}
\begin{itemize}
  \item Acts as an intermediary between user and hardware
    
  \item Resource allocator
    
  \item Control program
  \newline 
  Operating Systems cannot make hardware \textcolor{red}{go faster}. However, OS can make hardware \textcolor{red}{appear faster}.
   
\end{itemize}
\end{frame}


\begin{frame}{Computer Hardware Review}{Hardware issues of concern to OS Designers}
\textbf{\underline{Computer System}} : CPU, Memory and I/O connected through buses to communicate among each other
 \begin{itemize}
  \item CPU : Fetches instruction from memory and executes them
       \begin{itemize}
        \item CPU has specific instruction set that it executes
        \item Registers  - General Purpose and Special Purpose (\emph{Program Counter} and \emph{Stack Pointer})
        \item \emph{Program Status Word} : contains condition code bits, CPU priority, mode (kernel/user) etc. PSW plays important role in system calls and I/O
        \item Techniques to improve performance : Pipelining, Superscalar CPU etc.
        
       \end{itemize}
  \item Memory : Should be extremely fast, abundantly large and cheap \textcolor{red}{No technology satisfies it :-(}
 \end{itemize}

\end{frame}

\begin{frame}{Storage Structure}
\begin{figure}
  \centering
  \includegraphics[width=1.0\textwidth]{storage_structure.pdf}
  \caption{Storage structure}
 \end{figure}
 
\end{frame}




\begin{frame}{Caching Principle}
\begin{itemize}
 \item Caching is an important principle, performed at many levels in a computer (in hardware, operating system, software)
 \item Information “in use” is copied from slower to faster storage temporarily
 \item Faster storage (cache) checked first to determine if information is there
       \begin{itemize}
	    \item If it is (cache hit), information used directly from the cache (fast)
	    \item If not (cache miss), data copied to cache and used there
	    \item May need to evict some other data (cache replacement)
    
       \end{itemize}
  \item Cache smaller than storage being cached
	\begin{itemize}
	 \item Cache management important design problem
	 \item Cache size and replacement policies are important
	 \item Sometimes bring data before needed (pre-fetch)
	\end{itemize}

  \end{itemize}

 
\end{frame}


\begin{frame}{Typical Computer Architecture}

 \begin{figure}
  \centering
  \includegraphics[width=0.8\textwidth]{computer_architecture.pdf}
  \caption{Computer Architecture}
 \end{figure}
\end{frame}






\begin{frame}{Computer System Operation}
\begin{itemize}
 \item I/O devices and the CPU can execute concurrently.
\item Each device controller is in charge of a particular device type.
\item Each device controller has a local buffer.
\item CPU moves data from/to main memory to/from local buffers
\item I/O is from the device to local buffer of controller.
\item Device controller informs CPU that it has finished its operation by causing an \textcolor{red}{interrupt}.
\end{itemize}

 
\end{frame}




 \begin{frame}{Common Functions of Interrupts}
 \begin{itemize}
 \item Interrupts transfers control to the interrupt service routine generally, through the \textcolor{red}{interrupt vector}, which contains the addresses of all the service routines.
 \item Interrupt architecture must save the address of the interrupted instruction.
 \item Incoming interrupts are \textcolor{red}{disabled} while another interrupt is being processed to prevent a \textcolor{red}{lost interrupt}.
 \item A \textcolor{red}{trap} is a software-generated interrupt caused either by an error or a user request.
 \item An operating system is \textcolor{red} {interrupt driven}.
% 
 \end{itemize}
% 
%  
 \end{frame}


 \begin{frame}{Interrupt Handling}
 \begin{itemize}
  \item The operating system preserves the state of the CPU by storing registers and the program counter.
\item Determines which type of interrupt has occurred:
   \begin{itemize}
    \item polling
    \item vectored interrupt system
   \end{itemize}
\item Separate segments of code determine what action should be taken for each type of interrupt
 \end{itemize}

\end{frame}

\begin{frame}{I/O Structure}
 \begin{itemize}
  \item After I/O starts, control returns to user program only upon I/O completion.
     \begin{itemize}
      \item wait instruction idles the CPU until the next interrupt
      \item wait loop (contention for memory access).
At most one I/O request is outstanding at a time, no simultaneous I/O processing.
     \end{itemize}

  
  \item After I/O starts, control returns to user program without waiting for I/O completion.
      \begin{itemize}
       \item System call – request to the operating system to allow user to wait for I/O completion.
      \item Device-status table contains entry for each I/O device indicating its type, address, and state.
      \item Operating system indexes into I/O device table to determine device status and to modify table entry to include interrupt.
      \end{itemize}

 \end{itemize}

\end{frame}


 \begin{frame}{Hardware Protection}
  \begin{itemize}
    \item Dual-Mode Operation
    \item I/O Protection
    \item Memory Protection
    \item CPU Protection
  \end{itemize}

 \end{frame}

 
 
 \begin{frame}{Dual Mode Operation}
    \begin{itemize}
     \item Sharing system resources requires operating system to ensure that an incorrect program cannot cause other programs to execute incorrectly.
    \item Provide hardware support to differentiate between at least two modes of operations.
       \begin{itemize}
        \item User mode – execution done on behalf of a user.
        \item Monitor mode (also supervisor mode or system mode) – execution done on behalf of operating system. 
       \end{itemize}
      \end{itemize}

 \end{frame}
 
 
 \begin{frame}{Dual Mode Operation contd..}
    \begin{itemize}
     \item Mode bit added to computer hardware to indicate the current mode:  monitor (0) or user (1).
    \item When an interrupt or fault occurs hardware switches to monitor mode.
    \end{itemize}
      
      \begin{figure}
	\centering
	\includegraphics[width=0.60\textwidth]{dual_mode.pdf}
	  \caption{Dual Mode}
	\end{figure}
      
      
      
 \end{frame}
 
 
 \begin{frame}{I/O Protection}
  
  \begin{itemize}
   \item All I/O instructions are privileged instructions.
    \item Must ensure that a user program could never gain control of the computer in monitor mode (I.e., a user program that, as part of its execution, stores a new address in the interrupt vector). 
  \end{itemize}

 
 \end{frame}
 
 
 \begin{frame}{Memory Protection}
  \begin{itemize}
   \item Must provide memory protection at least for the interrupt vector and the interrupt service routines.
    \item In order to have memory protection, add two registers that determine the range of legal addresses a program may access:
       \begin{itemize}
        \item \textcolor{green}{Base register : holds the smallest legal physical memory address.}
	\item \textcolor{green}{Limit register : contains the size of the range }
       \end{itemize}

	
     \item Memory outside the defined range is protected.
  \end{itemize}

 \end{frame}
 
 
 \begin{frame}{A Base And A Limit Register define A Logical Address Space}
   
    \begin{figure}
	\centering
	\includegraphics[width=0.9\textwidth]{base_limit_register.pdf}
	  \caption{Memory Protection}
	\end{figure}
  
  
 \end{frame}
 
 
 
 \begin{frame}{Protection Hardware}
    \begin{figure}
	\centering
	\includegraphics[width=0.9\textwidth]{protection_hardware.pdf}
	  \caption{Protection Hardware}
	\end{figure}
  
  \begin{itemize}
   \item When executing in monitor mode, the operating system has unrestricted access to both monitor and user’s memory.
   \item The load instructions for the \textcolor{red}{base} and \textcolor{red}{limit} registers are privileged instructions.
  \end{itemize}

  
 \end{frame}
 
 
 
 \begin{frame}{CPU Protection}
  \begin{itemize}
   \item Timer – interrupts computer after specified period to ensure operating system maintains control.
      \begin{itemize}
       \item  Timer is decremented every clock tick.
       \item  When timer reaches the value 0, an interrupt occurs.
      \end{itemize}
   \item Timer commonly used to implement time sharing.
    \item Load-timer is a privileged instruction.
  \end{itemize}

 \end{frame}
 
 
 \begin{frame}{General-System Architecture}
   \begin{itemize}
    \item Given the I/O instructions are privileged, how does the user program perform I/O?
    \item \textcolor{green}{System call} – the method used by a process to request action by the operating system.
    \end{itemize}
 \end{frame}   
   
 
 
 
 
 

% \begin{frame}{Memory management and Protection}
% \begin{itemize}
%  \item \underline{\textbf{Memory Management}:} \\ CPU $>$ memory management unit (MMU) $>$ cache $>$ main memory
%  \item \underline{\textbf{Memory Protection}:}\\ memory bound registers - LBR and UBR
% \end{itemize}
% \end{frame}
% 
% \begin{frame}{I/O Subsystem}
% \begin{itemize}
%  \item Programmed I/O
%  \item Interrrupt driven I/O
%  \item Direct Memory Access
% \end{itemize}
% 
% \underline{\textbf{Types of Interrupt: }}
%  \begin{itemize}
%   
%   \item Program Interrupt - conditions requiring supervisor attention
%   \item I/O interrrupt - I/O completion or I/O malfunction
%   \item Timer interrupt - interval timer of the system
%  \end{itemize}
% 
%  \underline{\textbf{Steps in Interrupt action: }}
%  \begin{itemize}
%   
%   \item Set interrupt code - interrupt h/w forms a code (stored in PSW) describing cause of interrupt. 
%   \item save the PSW - PSW is copied into the saved PSW information area
%   \item load interrupt vector
%  \end{itemize}
% 
% 
% \end{frame}
% 
% \begin{frame}{Interrrupt Processing}
%  \begin{figure}
%   \centering
%   \includegraphics[width=0.65\textwidth]{interrupt_driven_op_kernel.pdf}
%   %\caption{Interrupt operation}
%  \end{figure}
% \end{frame}



\begin{frame}{System Calls}
\begin{itemize}
 \item Programming interface to the services provided by the OS
\item Typically written in a high-level language (\emph{C, C++}). Maybe in assembly
\item Performs basic functions that requires communication with CPU, memory and devices
\item All activities related to file handling, memory managemnt and process management are handled by system calls
\end{itemize}
Examples : \\
getuid() - get the user ID\\


fork() - create a child process\\


exec() - executing a program \\
 
\end{frame}


\begin{frame}{System Calls contd...} 
        \begin{itemize}
         \item System call usually takes the form of a trap to a specific location in the interrupt vector. Control passes through the interrupt vector to a service routine in the OS, and the mode bit is set to monitor mode. 
	\item The OS verifies that the parameters are correct and legal, executes the request, and returns control to the     instruction following the system call. 
        \end{itemize}

  

   \begin{figure}
	\centering
	\includegraphics[width=0.8\textwidth]{user_to_kernel.pdf}
	  \caption{System Call for I/O}
	\end{figure}
   
 \end{frame}


\begin{frame}{Use of APIs in system calls}
\begin{itemize}
 
\item System calls are mostly accessed by programs via a high-level \textbf{Application Program Interface (API)} rather than direct system call use
\item Three most common APIs are \textbf{Win32 API} for \emph{Windows}, \textbf{POSIX API} for \emph{POSIX-based systems}
(including virtually all versions of \emph{UNIX, Linux, and Mac OS X}), and \textbf{Java API} for the \emph{Java virtual
machine (JVM)}
\item Why use APIs rather than system calls?
   \begin{itemize}
      \item Underlying systems calls (error codes) can be more complicated. API gives a uniform, portable interface
       \item One need not remeber I/O registers or order of I/O operation
    \end{itemize}
\end{itemize}
 
 APIs example : BOOL ReadFile c(HANDLE file, LPVOID buffer, DWORD bytes to read, LPDWORD bytes read, LPOVERLAPPED ovl); 
\end{frame}

\begin{frame}{API – System Call – OS Relationship}
 \begin{figure}
  \centering
  \includegraphics[width=0.65\textwidth]{api_system_call.pdf}
  \caption{api system call}
 \end{figure}
\end{frame}

\begin{frame}{Example of API-System call}
\begin{itemize}
 \item System call sequence to copy the contents of one file to another file (POSIX like C pseudo code) (bold are API system calls)
\end{itemize}

 \textbf{write}(1, “Input file”, 11);\\
 \textbf{read}(0, \&buffer, 100);\\
 ...........\\
 fd = \textbf{open}(buffer,O\_RDONLY);\\
 outfd = \textbf{open}(buffer,O\_WRONLY$|$O\_CREAT$|$O\_TRUNC,0666);\\
 if(outfd$<$0)\textbf{abort}(``File creation failed'');\\
 ............\\
 \textbf{closefd};\\
\end{frame}

\begin{frame}{Standard C library example}
Some library calls themselves make system calls\\
ex: C program invoking \textbf{printf} library call which calls \textbf{write} system call
 \begin{figure}
  \centering
  \includegraphics[width=0.9\textwidth]{system_call_ex.pdf}
  \caption{Example of system call}
 \end{figure}
\end{frame}


\begin{frame}{Steps in Making a System Call, Example : read call}
read(fd,buffer,nbytes)
  \begin{figure}
	\centering
	\includegraphics[width=0.7\textwidth]{system_call_steps.pdf}
	  \caption{System Call Steps}
	\end{figure}
\end{frame}




\begin{frame}{System Call Implementation}
 \begin{itemize}
  \item A number associated with each system call
      \begin{itemize}
      \item System-call interface maintains a table indexed according to these numbers\\
            Additional info: check /usr/include/sys/syscall.h
     \end{itemize}

  \item The system call interface invokes intended system call in OS kernel and returns status of the system call and any return values

  \item The caller need know nothing about how the system call is implemented
  \begin{itemize}
      \item Just needs to obey API and understand what OS will do as a result call
\item Details of OS interface hidden from programmer by API
\item Managed by run-time support library (set of functions built into libraries included with compiler)
     \end{itemize}
 \end{itemize}

 
 
\end{frame}






\begin{frame}{System Call Parameter Passing} 
 \begin{itemize}
  \item More information is required than simply identity of desired system call
  \item Three general methods used to pass parameters to the OS
     \begin{itemize}
      \item Simplest:  pass the parameters in hardware registers
 
       \item Parameters stored in a block, or table, in memory, and address of block passed as a parameter in a register 
             (This approach taken by Linux and Solaris)
        \item Parameters placed, or pushed, onto the stack by the program and popped off the stack by the operating system.
              Block and stack methods do not limit the number or length of parameters being passed
     \end{itemize}

 \end{itemize}

\end{frame}


\begin{frame}{Parameter Passing via Table}
 \begin{figure}
  \centering
  \includegraphics[width=0.9\textwidth]{parameter_passing.pdf}
  \caption{}
 \end{figure}
\end{frame}

\begin{frame}{Use of A System Call }
    \begin{figure}
	\centering
	\includegraphics[width=0.7\textwidth]{processing_sys_calls.pdf}
	  \caption{System Call Processsing}
	\end{figure}
 \end{frame}

\begin{frame}{Some System Calls For Process Management}
 \begin{figure}
  \centering
  \includegraphics[width=0.9\textwidth]{system_call_process_management.pdf}
  \caption{system\_call\_process\_management}
 \end{figure}
\end{frame}



\begin{frame}{Some System Calls For Directory Management}
 \begin{figure}
  \centering
  \includegraphics[width=0.9\textwidth]{system_call_directory_management.pdf}
  \caption{system\_call\_directory\_management}
 \end{figure}
\end{frame}

\begin{frame}{Some System Calls For Miscellaneous Tasks}
 \begin{figure}
  \centering
  \includegraphics[width=0.9\textwidth]{system_call_misc.pdf}
  \caption{system\_call\_misc}
 \end{figure}
\end{frame}


\begin{frame}{System Call Example}
 \begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{system_call_example.pdf}
  \caption{system\_call\_example}
 \end{figure}
\end{frame}
 
 
 
 
\begin{frame}{System programs}
\begin{itemize}
 \item Provide a convenient environment for program development and execution. Some of them are simply user interfaces to system calls; others are considerably more complex
   \begin{itemize}
    \item File management - Create, delete, copy, edit, rename, print, dump, list, and generally manipulate files and directories
    \item Programming-language support - Compilers, assemblers, debuggers and interpreters sometimes provided
    \item Program loading and execution- Absolute loaders, relocatable loaders, linkage editors, and overlay-loaders, debugging systems for higher-level and machine language
    \item Communications - chat, web browsing, email, remote login, file transfers
    \item Status information - system info such as date, time, amount of available memory, disk space, number of users
   \end{itemize}

\end{itemize}

 
\end{frame}

\begin{frame}{Interfacing with OS}
\underline{User Interface}
\begin{itemize}
 \item \textbf{Command Line Interface (CLI)} : The command line may itself perform functions or call other system programs to implement functions (e.g. in UNIX, /bin/rm to remove files). Examples are \textbf{shell} in \emph{UNIX} and \textbf{command.exe} in \emph{Windows} 
     
\item \textbf{Graphics User Interface (GUI)} :  Point and click interface. Examples are \emph{MS windows, MAC OS X Aqua, Unix X} \& variants. 
\item \textbf{Batch} :  Commands are given using a file/command script to the OS and are executed with little user interaction. Examples are  \textbf{.bat} files in \emph{DOS}, \textbf{shell scripts}
\end{itemize}

 
\end{frame}




\begin{frame}{Operating System Generation}
\begin{itemize}
 \item Operating systems are designed to run on any of a class of machines; the system must be configured for each specific computer site
 \item SYSGEN program obtains information concerning the specific configuration of the hardware system
 \item Booting – starting a computer by loading the kernel
 \item Bootstrap program – code stored in ROM that is able to locate the kernel, load it into memory, and start its execution
\end{itemize}

 
\end{frame}


\begin{frame}{System Boot}
Operating system must be made available to hardware so hardware can start it
 \begin{itemize}
  \item Small piece of code – bootstrap loader, locates the kernel, loads it into memory, and starts it
  \item Sometimes two-step process where boot block at fixed location loads bootstrap loader
  \item When power initialized on system, execution starts at a fixed memory location - Firmware used to hold initial boot code
 \end{itemize}

\end{frame}





\begin{frame}{Some Fundamental Concepts about OS}
\begin{itemize}
 \item Process
 \item Memory 
 \item Files
\end{itemize}

\textbf{Process}  : Program in execution\\
 \begin{itemize}
  \item Address Space - list of address locations which the process can read or write. Address space contains the following:
      \begin{itemize}
       \item program, program's data and stack
       \item registers associated with the program
       \item \emph{Program counter} and \emph{Stack Pointer}
       \item \emph{PSW}
      \end{itemize}
\item When a process is suspended temporarily (such as in time sharing system), it must be restarted in the same state in which it was stopped - information about process needs to be saved
   \begin{itemize}
    \item information of a suspended process is stored in \textbf{process table} 
   \end{itemize}

%\item Key process management system calls are those dealing with creation and termination of processes.
\textcolor{red} {Deadlock} : Two interacting process get into a stalemate position through which they cannot get out (Analogous to deadlock in traffic)
 \end{itemize}

 
\end{frame}






\end{document}