\input{myLectHead}

%\title{Mon Sep 17, 2007\\
%	Lecture 3: Process Management}

\setcounter{lecture}{2}
\lecture{Process management}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\lectpart{Basic Issues in Multiprogramming}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

	We could begin with the simple view of an OS as
	{\em a software to manage a set of processes}.

	A \dt{process} (or \dt{job} or \dt{task})
	is a program in execution.   As such,
	it has source code, current state, memory and files, resources
	such as printers and I/O.

	A closely related, more modern concept is \dt{thread}.
	There are many variants of the thread concept, and
	its relation to processes.  Here are some views:

	(1) Threads as a executional unit of a process.
	
	(2) Threads as a light-weight process.

	(3) Threads as kernel objects, or as process objects.

	In any case, an extended notion of OS is that
	``an OS manages a collection of processes and their threads''.

	The OS, as a manager of processes/threads, has to provide these
	functions:

	\bitem
	\item
	Process Management:

	(1) Create/delete, schedule, synchronize and provide
	communication among processes.

	(2) Process scheduling 

	\item
	Memory management:
 
	(1) Main Memory Management
	
	(2) File management
	
	(3) Memory hierarchy issues

	\item
	Resources management:
	
	e.g., Deadlock management.

	e.g., Networking

	e.g., I/O management

	\item
	Security and Protection:

	\eitem

	Just as there is some hierarchy involving threads and processes,
	we may also have hierarchy among the processes.  E.g., in Unix,
	each process (except the root) has a parent process.
	The OS has to manage this hierarchy.


\lectpart{Memory Management for Multiprogramming}

	KEY FUNCTION:
		provides multiprogramming environment

	Usefulness of multiprogramming:
		I/O bound vs CPU bound processes
		User processes vs Kernel processes
		When useful?

	What is needed for multiprogramming?
		Process management (process table)
		Memory management
		Interrupts (and ability to turn on/off interrupts)
		...


	Requirements: 
		to isolate processes from each other,
		to isolate processes from kernel,
		to relocate programs.

	Relocation problem: when a program is compiled, it must be
		assumed that each instruction is placed in some
		location, and the locations conventionally start at 0.
		When this program is LOADED, it will begin at some
		address determined at runtime.  Also, a certain
		amount of space is allocated for data.

	THE CDC MODEL (CDC is an early computer, one of the first
	models was delivered to Courant Institute in NYU in the
	70s):

	\bitem
	\item
		Each process occupies a contiguous chunk of memory.

	\item
		THIS CALLS for a BASE REGISTER and a LIMIT REGISTER:
			Limit register tells the size of the program+data.
			Chunk = [base, base + limit]
			These registers are protected from users
	\item
		How does this modify our execution cycle?
			Each instruction or data fetch is checked
			to be within the limit, and then "offset" by base.
			But actually, it is done by the MMU.
	\item	
		THIS illustrates 
			--virtual address vs physical address.
			--context switching: the values of the register
				pair is a context!

	\item
		Drawback: we need to predict how much data is needed.
			So everyone overestimates.

	\item
	MODIFIED CDC MODEL:
		Have two pairs of Base+Limit registers.
		Pair 1 for program, Pair 2 for data.
		ADVANTAGE: processes can share program!
	\eitem

\lectpart{Processes}

	Our first programming effort will involve multi-processes. So...

	We will examine processes in Unix and Windows!

	\paragraph{How are processes created?}

	\bitem
	\item
		At system initialization
			(foreground process, e.g., login shells),
			(background, e.g., email, http daemons)

	\item 
		Users can create them (e.g., multiple window processes)

		E.g., 
			$>$ cat chap1.txt chap2.txt | grep process

		Current process creates two new process,
		one to run "cat" (which contenates 2 files),
		the other to run "grep" (to look for word "process").

	
	\item
		UNIX: "fork" (creates a clone of caller process!
			but the the child can next do some
			manipulation and ultimately execute
			a "execve" to do its job)

			BUT both have different address spaces.

			THEY CAN share resources like open files.

	\item
		Windows: "CreateProcess" with 10 parameters!
			and lots of related functions.
	\eitem
	
	\paragraph{Process Hierarchies}

	\bitem
	\item
		Windows: no hierarchy!
		The parent process has only one special
		advantage: it has the "token" or "handle"
		to control the child, but can give the handle away!

	\item
		Unix: from fork, get parent-child relation.
			ALL PROCESSES are descendents of the
			"init" process!
			
		The hierarchy
			cannot change except through process creation
			or process termination:
			when a parent process exits, all its children
			will have the "init" process as parent!

	\item
		Unix: Process group -- a process and all its
			descendents.  If a signal is sent
			to root of group,
			it is delivered to all.
		
	\eitem

	\paragraph{How are Processes terminated?}

	\bitem
	\item
		Normal exit (voluntary),

		Error exit (voluntary),

		Fatal error exit (involuntary),

		Killed by another process exit (involuntary),

	\item  Unix: normal termination is
		achieved by a process executing the
		{\tt exit()} system call.  The exiting process
		may return a status value to parent.

	\item Unix: a process can terminate another process by
		calling {\tt abort()}.  E.g., a parent process aborts
		a child process if it is
		taking too long, or its services is no longer needed.

	\eitem

	\paragraph{EXAMPLE: Unix Fork}

	\bitem
	\item The main interface to unix is the \dt{shell}
		(there are many variants, \dt{bash} being
		our default in cygwin).
	\item Each shell controls a window (assuming
		a multi-window GUI)
	\item The shell sits in a loop to process use commands.
	\item Suppose we type "ls" (list current directory).
	\item The shell would execute a "fork()" system call.
	\item This creates a new process, a CHILD of the current
		process.
	\item The PARENT process then executes a "wait()" for
		the CHILD to terminate.
	\item After the CHILD does its job (listing current directory),
		it terminates and sends the parent a signal.
	\item The parent receives the signal and continues.

	\item HERE IS THE CODE to SIMULATE the process:

		\begin{progb}{
		\#include $<stdio.h>$\\
		\#include $<unistd.h>$\\
		int main (int argc, char *argv[])\{\\
		\> int pid; \\
		\> pid = fork(); \\
		\> if (pid $<$ 0) \{\\
		\>\>	fprintf(stderr, "fork failed"); exit(-1);\}\\
		\> else if (pid == 0) \{\\
		\>\>	execlp("/bin/ls", "ls", NULL);\}\\
		\> else \{\\
		\>\>	wait(NULL); printf("child completed"); exit(0);\}\\
		\}\\
		}\end{progb}

	\eitem


\lectpart{Process States and Transition}

  \myfignew{process-transition}{Process States and their transitions}{trans}{.5}

	\bitem
	\item
		\dt{Cyclic States:} Ready, Running, Blocked.

		\dt{Transitory States:} New, Terminated.

		\dt{Refinements:}
		Ready-suspended, blocked-suspended.
		(suspension is related to process swapping)

		NOTE: there is at most ONE process in the
		Running state (for each CPU).

	\item
		Possible state transitions (draw a transition diagram) 

			Ready $\leftrightarrow$
			Running $\to$
			Blocked $\to$ Ready.

		Also:  New $\to$ Ready,
			Running $\to$ Terminated.

	\item
		Names of transitions:

		\bitem
		\item (1) create (New $\to$ Ready)
		\item (1) terminate (Running $\to$ Terminated)
		\item (2) preempt (Running $\to$ Ready) caused by scheduler
		\item (2) run (Ready $\to$ Running) caused by scheduler
		\item (3) block (Running $\to$ Blocked) 
		\item (3) unblock (Blocked $\to$ Ready) caused by event 
		\eitem
	\eitem


\lectpart{Process Scheduler}

	\bitem
	\item OBJECTIVES OF SCHEDULING:

		\bitem
		\item Efficient use of resources (e.g., CPU usage).
			That is the reason for "blocking" a process.
		\item Fairness among processes (time-to-completion
			should be proportional to job size).
			That is the reason for "preempting" a process
			at the end of a quantum.
		\eitem
	\item
		(running $\rightarrow$ ready) and
		(ready $\rightarrow$ running)

		are done by process scheduler!

		These 2 transitions requires \dt{context switching},
		which is hardware supported.
		
	\item
		Scheduler [p.142-3].  Round Robin is simplest
		preemptive scheduler:

		(1) Ready processes are in FIFO queue (ready queue)

		(2) Each process runs in a fixed quantum (e.g. 50ms)

		(3) Current process P runs till it BLOCKS,
			in which case it is moved to  "blocked queue",
			or it finished its quantum, and put in
			end of "ready queue".

		(4) Next process at top of FIFO queue is next running.

	\item
		Scheduler Queues:

		Job Queue: all current jobs

		Ready Queue: jobs in main memory in Ready state
		
		Device Queue: jobs waiting for a particular device

		See DIAGRAM of transitions between queues. 
		[Silberschatz, Fig 4.5, p.109]

	\item
		REFINEMENTS of Schedulers (Silbershatz, p.109):

		CPU Scheduler (or short-term scheduler): manages
		the ready queue

		JOB Scheduler (or long-term scheduler): manages
		the Job Queue on disk (swaps processes in/out of main memory)
		It decides on how to admit New processes into
		the ready queue.

	\eitem

\lectpart{Process Management}

	We now look a bit into the nitty-gritty for process management.

	\bitem
	\item
		Datastructure called
		\dt{Process Table} (one entry/process).
		Each entry is called a
		\dt{Process Control Block} (PCB).

	\item
		Each entry or PCB:

		\bitem
		\item Process ID
		\item Process State
		\item Registers: PC, SP, PSW, etc
		\item memory allocation
		\item files and their status
		\item accounting (CPU usage, memory usage, etc)
		\item scheduling info
		\item I/O status
		\item info for context switching
		\eitem

	\item OTHER INFORMATION: % (p.80, tanenbaum)
		% process:
		priority, parent process, process group,
		signals, time when process started, 
		children's CPU time, time of next alarm;
		% memory:
		pointer to text segment, data segment, stack segment;
		% file:
		root directory, working directory, file descriptors,
		user ID, group ID.

	\item
		Process Image: memory must be organized
		to store each current process (in any state).

		TYPICAL LAYOUT IN MEMORY:

		text section (code),

		data section (global variables),

		stack section (params of calls, return addr, local vars)

		% WHERE DOES HEAP BELONG?  Heap (via malloc() or new())
		% is allocated
		% from the OS, but we need to keep track of it in the process...

		% What is "bss" section?

	\item
		Each I/O Class (floppy, hard disk, timers, terminals,...)
		has a location called an \dt{interrupt vector}.
		It has the address of the interrupt routine.

		If process 3 is running when a disk interrupt
		occurs: then HARDWARE causes
		process 3's PC, registers, etc to be
		pushed onto the current stack, and
		make CPU jumps to the interrupt vector.

		That is all the hardware does.  From then on,
		the interrupt service procedure takes over.

		When done, returns to the scheduler.
		
	\eitem


\lectpart{THREADS}
	What is a THREAD?

	\bitem

	\item View a traditional process as a single thread.

	\item A process can have SEVERAL threads of execution.

		The threads all SHARE the same address space.

	\item
		The reason for threads are similar to the ones
		for processes BUT:

		easy to create and destroy

		the need to share data

		useful when threads are I/O bound

	\item
		E.g. Process running an editor: the process
		can run several threads at the same time:

		(1) thread for backup of file in background

		(2) thread for reformatting of file while we 
		continue to edit the file

		(3) thread for reading from keyboard
		
		(4) thread for writing to screen

		(5) thread to do spell checking in background

		WHAT IS THE POINT?  WHY DON'T WE JUST HAVE
		JUST HAVE 5 PROCESSES?

	\item
	Processes share resources, but threads are executional
	units, that does not have independent resources.
	So sharing among threads within a process is very cheap.

	\item
	Thread can be implemented in kernel or user space
	% [Tanenbaum p.93ff.]

	\eitem


\lectpart{Buses}

It is useful to know about an essential piece of
hardware in all modern computers: the bus.

	Various hardware devices talk to each other using buses.
	A \dt{bus} is a set of wires with a well-defined protocol for 
	sending and receiving messages along the wires.
	Various devices (monitor, procesor, keyboard, disk, etc)
	can be attached to the bus.  Usually, devices have
	a dedicated unit called \dt{controller} to interface
	with the bus.

	PC's have 8 BUSES.

	\begin{itemize}
	\item
		original IBM:

			ISA (ISA bridge $\leftrightarrow$ various devices)
				Rate of 16 MB/sec.

	\item
		successor to ISA:

			PCI (PCI bridge $\leftrightarrow$ various slots, inc.ISA Bridge)
				Rate of 528 MB/sec.
		
	\item
		Newer buses:

			cache (CPU$\leftrightarrow$Level 2 cache)

			local (CPU$\leftrightarrow$PCI bridge)

			memory (PCI bridge$\leftrightarrow$ Main Memory)

			SCSI (high performance bus for fast disks, scanners, etc)
				Rate of 160 MB/sec.

			USB (for slow I/O devices like keyboard, mouse)
				Rate of 1.5 MB/sec.  Convenient
				to add devices, without reboot.

				Since 2001, USB 2.0 (Hi-Speed USB)
				introduced with rate of 60 MB/sec.
				
			IDE (for peripherals such as CD ROMs, disks)
				
	\item New: FireWire (a.k.a. i.Link or IEEE 1394) (50 MB/sec)
			like USB but much faster
			(useful for audio/video devices like camcorders, etc)
		Partly viewed as replacement for USB.

	\end{itemize}


\input{myTail}
