Process Manager State Transitions

- processes can be in a number of states (build state diagram incrementally)
	- first has to come into existence: create process - called "admission"
	- ready: ready to be run by processor but currently, no free processors
	- running: currently being executed by a processor
	- blocked: waiting for some resource (eg. memory or a disk read)
		
				 exit
		   RUNNING -----------> EXITED
		    ^     \	   
		    |      \______ request
	   dispatch |             \_____
		    |    		\
      admit	    |  	complete 	 v
NEW ----------> READY <----------- BLOCKED

- simple transition diagram #1
	- running process can exit directly
	- new process must wait for current process to be blocked
	- other processes could wait forever if process never requests resource!
	- OS needs mechanism to force running process to ready state
		- add another state transition: timeout

				 exit
		   RUNNING -----------> EXITED
		    ^   | \	   
		    |   |  \______ request
	   dispatch |   |timeout  \_____
		    |   |		\
      admit	    |   v complete	 v
NEW ----------> READY <----------- BLOCKED

- simple transition diagram #2
	- problem: could be many processes blocked on I/O 
	  (keep in mind time scale)
	- not enough memory to store SDT for each of these!
	- make use of secondary storage while processes not running (swapping)
	- OS can perform suspend on blocked process
		- swap to disk (out of $$$ RAM)
		- bring in previously suspended process (activate) to RAM

				 exit
		   RUNNING -----------> EXITED
		    ^   | \	   
		    |   |  \______ request
	   dispatch |   |timeout  \_____
		    |   |		\
      admit	    |   v complete	 v
NEW ----------> READY <----------- BLOCKED
				    ^   |
			   activate |   |susp
				    |   |
				    |   |
				    |   v
				   SUSPEND

- simple transition diagram #3
	- isn't this silly? using I/O (swapping) to alleviate problem of
	  too many processes blocked on I/O!
	- OS could be swapping back process that is still blocked
	- what are we gaining?
	- note: I/O event might occur while process sits in secondary storage
	- in that case, process shouldn't return to blocked state after activate
	- instead, move to parallel "suspend-ready" on complete

				 exit
		   RUNNING -----------> EXITED
		    ^   | \	   
		    |   |  \______ request
	   dispatch |   |timeout  \_____
		    |   |		\
      admit	    |   v complete	 v
NEW ----------> READY <----------- BLOCKED
		^ 		    ^   |
		|	   activate |   |susp
       activate |		    |   |
		|		    |   |
		| 	   complete |   v
		SUSP READY <-------- SUSP BLOCKED

- simple transition diagram #4
	- during swap, OS can now select from "suspend-ready" pool 
	- also, provides OS or another process (e.g. parent) 
	  mechanism to suspend execution from ready state

				 exit
		   RUNNING -----------> EXITED
		    ^   | \	   
		    |   |  \______ request
	   dispatch |   |timeout  \_____
		    |   |		\
      admit	    |   v complete	 v
NEW ----------> READY <----------- BLOCKED
		^   |		    ^   |
		|   |	   activate |   |susp
       activate |   | susp	    |   |
		|   |		    |   |
		|   v	   complete |   v
		SUSP READY <-------- SUSP BLOCKED


Process Creation
	- create image in user address space
		- loads executable code from secondary storage into T area
	- create and intialize PCB
		- assign a PID
		- put it in appropriate queue (e.g. "ready")

Process Switching
	- OS responsible for deciding which process gets CPU at any time
	- according to policy, suspends process and starts or resumes another
		- must save process registers including PC
		- restore registers from next process to run
		- restoring PC causes automatic resumption of process
	- steps are transparent to processes 
		- they don't know about execution context
		- they aren't aware of being suspended and resumed
	- how does OS get control of CPU for scheduling?
		- hardware interrupts (timer, I/O, memory fault, DMA) 
			- asynchronous
		- traps	(fatal conditions, ALU error) 
			- asynchronous
		- supervisor calls (explicit requests to OS routines) 
			- synchronous
	- context switch:
		- process interrupted: OS sevice performed, same proc resumed
		- similar to subroutine call
		- only need to save processor state data for call to OS routine
	- process switch:
		- process is interrupted: OS gives control to another process
		- much more expensive than context switch
		- have to update process tables, queues, load new process, etc.
	- therefore, try to perform OS services within process
		- kernel within process (70's style)
		- microkernels (80's style)
	- and try to minimize unwanted process switching
		- threads: lightweight processes