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