Review: Process Management

1. 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

2. 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

3. Diagram of Process States exit new admitted terminated interrupt Queue: ready running scheduler I/O or event wait I/O or event completion Queue: waiting

4. 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

5. 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)

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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!

12. 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

13. 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

14. The Dining Philosophers Plate with food Fork

15. 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?

16. 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

17. 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

18. 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?

19. P2 Y X P1 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

20. 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

21. 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