Review: Process Management Objective: –Enable fair multi-user, multiprocess computing on limited physical resources –Security and efficiency Process: running.
Published byModified over 6 years ago
Presentation on theme: "Review: Process Management Objective: –Enable fair multi-user, multiprocess computing on limited physical resources –Security and efficiency Process: running."— Presentation transcript:
Review: Process Management Objective: –Enable fair multi-user, multiprocess computing on limited physical resources –Security and efficiency Process: running program + context Process Control Block: Contains Process Context Register content Memory address space PC I/O Status
Review: Process Management Multicomputing is achieved by timeslicing: Every process runs for a while until time is up Interrupt driven(2 Types), PCB is stored and retrieved 5 State model: new, running, ready, waiting,terminated multiple queues in which processes reside during lifetime
Diagram of Process States newterminated Queue: waiting Queue: readyrunning I/O or event wait I/O or event completion interrupt admitted exit scheduler
Review UNIX Commands telnet machine: login to UNIX computer ps: show all processes that were started –ps -u username : all processes started by user top: show all processes running on the computer kill id : Stop running process with id nohup: make process immune to high level interrupts nice +int process: change the priority of a process man command: get information about command
Inter Process Communication Passing information sequentially between 2 processes (simplest case) –Result of P1 becomes at termination the input to P2 Passing information concurrently between 2 running processes Use of shared resources (such as printer queue)
Tools for sequential communication Redirect –> saves the output (whatever would come to the screen) into a file –>> appends the output to a file –Example: print >tmp Pipe –| hands the output directly to the next process
Example See the 9823th line of a file –head -n file: command that shows the first n lines of file –head -n file: command that shows the last n lines of file 1) Store the first 9823 temporarily in a file and than look at the last line –head -9823 file>tmp –tail -1 tmp 2)Pass results directly using pipe –head -9823 file|tail -1
Communication between processes: Sharing Simplest method: any 2 processes can use shared file that both processes can access However, only one process at a time can have write access Parent-child processes can have shared variables –a C program can start of new processes (fork) that have access to all global variables
Use of shared resources Example: 2 unrelated processes want to print to the same printer Printer collects jobs in a printer queue (lpq -Pprinter shows you all entries in the queue) A queue works like an array. Each entry is a file that has to be printed. Processes can submit a file by appending it to the array. The printer takes jobs out from the lower end of the array. Global variable LAST keeps track of end of the array
Problem of Sharing: Inconsistency Multiprogramming can lead to inconsistency in case of shared resources P1 and P2 want to print, P1 is running and P2 is next in the ready queue P1 loads the current value of LAST into register R1 P1 gets interrupted by scheduler because time is up P2 starts running and loads LAST into R3 P2 stores filename in array(R3), increments R3 and stores R3 into LAST
Inconsistency II P2 gets interrupted by scheduler and P1 starts running (remember, OS will restore all register values) P1 will store its filename at array(R1) believing that R1 is the current value of LAST and overwrite the filename stored by P2 P1 increments R1 and saves the value to LAST P2’s file will never be printed!
Problems of Sharing: Deadlock Deadlock: Processes are waiting for resources held by another P1: lock(x) lock(y) P2: lock(y) lock(x) P1 can’t finish since it is waiting for resource y P2 can’t finish since it is waiting for resource x Neither of both ever unlocks the one it has
Race Conditions Whenever sharing of resources can lead to inconsistencies or deadlock Problem: Very hard to debug, not reproducible Heart of the problem is that between a test/load of a resource and the update there could be an interrupt Solution: atomic instruction or “uninterruptable” parts of code
Philosophers 5 Philosophers either think or eat If a philosopher gets hungry he tries sequentially to obtain 2 forks, one from his right, one from the left How do you make sure that they don’t starve?
Solutions 1: Test and Set Many processors offer a TSL instruction TSL R1, LOCKLAST It reads the value and during the same instruction sets it to 1. Now there can’t be an interrupt between the load and the store as we had in the printer queue If R1 is 1, the process will wait, if it is 0 it means that the resource is available and now locked by P1 This simple test can be used before altering LAST
Solution 2: Semaphores The concept of semaphores extends the idea of test and set to an integer value. A semaphore is a variable that can be incremented or decremented without interrupt
Solution 3: Critical Block If multiple resources are needed as in the deadlock case, we have to ensure, that either all resources are allocated or if only one missing none of them. This operation of locking all has to be immune to interrupts A critical block is a clock of instruction during which a program is immune to interrupts Note: this is a dangerous game and you don’t want to leave this to the user to implement! What happens if it contains a infinite loop?
Solution 4: Detect and Recover All previous attempts aimed at prevention Sometimes it is easier and safer to allow for the possibility of deadlocks Deadlock detection: Dependency graph of resources has cycles Graph for example: In case of deadlock, OS prevents second process to allocate resource that produces a cycle X Y P1 P2
Summary Solutions Inconsistency can be avoided by ensuring uninterrupted blocks of instructions Solutions might involve hardware support (if there is a test and set instruction that is supported by the CPU design) Software support can avoid an interrupt by changing the responsiveness to interrupts in critical sections Software can detect deadlock cases and resolve them
Appendix: More UNIX more file: show content of file ls: show all files in that directory head -n file: Show first n lines of file tail -n file: Show last n lines of file > redirect output into new file >> append redirected output to new file | pipe output into process