1. CSCI2413 Lecture 10 Operating Systems (OS) Inter-process communication phones off (please)

2. csci2413 - L112 © De Montfort University, 2004/5 Lecture Outline Concurrency Resources Deadlocks  conditions for deadlock  deadlock modeling Deadlock strategies  deadlock avoidance  deadlock prevention  deadlock detection & recovery  the ostrich algorithm

3. csci2413 - L113 © De Montfort University, 2004/5 Concurrency issues Communication among processes Sharing resources Synchronization of multiple processes Allocation of processor time Difficulties with Concurrency Facilitate sharing of global resources Management of allocation of resources Programming errors difficult to locate

4. csci2413 - L114 © De Montfort University, 2004/5 Shared Resources Physical resources processor, memory, I/O devices, disks, etc. Logical resources message queues, inodes, records in a d-base system, etc. Different resources that can be acquired  several identical instances may be available  e.g. multiple printers or tape drives the OS may choose any of them to satisfy a request A resource is anything that can only be used by a single process at any instant of time

5. csci2413 - L115 © De Montfort University, 2004/5 Deadlocks All operating systems have the ability to grant (temporary) exclusive access to certain resources Often exclusive access is needed to more than 1 resource Suppose there are two processes, A and B, and two shared resources, printer and tape A allocates the printer B allocates the tape  then A requests the tape and blocks until B releases it  and then B requests the printer and blocks until A releases it  both processes block forever - this is a deadlock

6. csci2413 - L116 © De Montfort University, 2004/5 Bridge Crossing Example Traffic only in one direction. Each section of a bridge can be viewed as a resource. If a deadlock occurs, it can be resolved if one car backs up (preempt resources and rollback). Several cars may have to be backed up if a deadlock occurs. Starvation is possible.

7. csci2413 - L117 © De Montfort University, 2004/5 Resource Classification Pre-emptable resources such a resource can be temporarily taken away from the process owning it with no ill effects  e.g. processor, memory Non-pre-emptable resources once allocated to a process, removing such a resource (even temporarily) could cause the computation to fail  e.g. printers Deadlocks occur with non-preemptable resources  pre-emptable resources can be reallocated to avoid DL

8. csci2413 - L118 © De Montfort University, 2004/5 Resource Allocation Sequence of events needed to use a resource is  request the resource  use the resource  release the resource If the resource is not available when it’s requested, the requesting process is forced to wait  in some systems, the process is automatically blocked  in others, the allocation fails and returns an error the process decides whether to wait some time and try again in most cases the process will sit in a tight loop requesting the resource until it is available (as no other work can be done) in which case, the process is effectively blocked

9. csci2413 - L119 © De Montfort University, 2004/5 Deadlock Definition Deadlock can be defined formally as  a set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause In most cases, the event that each process is waiting for is the release of a resource currently held by another member of the set  e.g. suppose there are three processes A, B & C  one form of deadlock is A waits for B, B waits for C, C waits for A  another may be A waits for B, B waits for A, C waits for B

10. csci2413 - L1110 © De Montfort University, 2004/5 Addressing Deadlock Prevention : Design the system so that deadlock is impossible Avoidance : Construct a model of system states, then choose a strategy that, when resources are assigned to processes, will not allow the system to go to a deadlock state Detection & Recovery : Check for deadlock (periodically or sporadically), then recover Manual intervention : Have the operator reboot the machine if it seems too slow

11. csci2413 - L1111 © De Montfort University, 2004/5 Conditions for Deadlock A deadlock can only occur if the following four conditions hold simultaneously in a system  mutual exclusion  hold and wait  no pre-emption  circular wait

12. csci2413 - L1112 © De Montfort University, 2004/5 “Mutual exclusion” condition  only one process may use a resource at a time To prevent deadlock  do not require “mutual exclusion”  If this is a resource constraint, then mutual exclusion must hold at all times. (i.e. you can’t do anything about it!)

13. csci2413 - L1113 © De Montfort University, 2004/5 “Hold and Wait” condition To prevent deadlock  avoid hold and wait! Need to be sure a process does not hold one resource while requesting another Approach 1: Force a process to request all resources it needs at one time Approach 2: If a process needs to acquire a new resource, it must first release all resources it holds, then reacquire all it needs

14. csci2413 - L1114 © De Montfort University, 2004/5 “No preemption” condition To prevent deadlock  allow preemption!  If a process holding certain resources is denied a further request, that process must release its original resources (  inefficiency in resource use)  If a process requests a resource that is held by another process, the OS may preempt the second process and require it to release its resources (  waste of CPU and other resources)  Can only be used in certain cases

15. csci2413 - L1115 © De Montfort University, 2004/5 “Circular wait” condition To prevent deadlock  don’t go into a circular wait situation!

16. csci2413 - L1116 © De Montfort University, 2004/5 Deadlock! P2 have resource A and need resource B to get its job done. P1 have resource B and need resource A to get its job done.

17. csci2413 - L1117 © De Montfort University, 2004/5 Example Scenario Imagine there are three processes: A, B & C and three resources: R, S, & T The resource allocations are as follows process A request R request S release R release S process B request S request T release S release T process C request T request R release T release R If the operating system runs the processes to completion in order A, B then C  all requests can be satisfied: no deadlock occurs But, suppose there is pre-emptive multi-tasking

18. csci2413 - L1118 © De Montfort University, 2004/5 Unpredictable Results? A & C run in round-robin, then B ABC RST A requests R C requests T A requests S C requests R A releases R C releases T A releases S C releases R B requests S B requests T B releases S B releases T A, B, & C all run in round-robin ABC RST A requests R B requests S C requests T A requests S B requests T C requests R DEADLOCK!

19. csci2413 - L1119 © De Montfort University, 2004/5

20. csci2413 - L1120 © De Montfort University, 2004/5 Potential Deadlock Example As a potential deadlock example in UNIX  UNIX has a finite maximum size to its process table usually around 32,000 processes  if a fork fails (because the process table is full), then a reasonable strategy (used in practice by most UNIX programmers) is to wait a short time and try again Suppose there are 100 slots free in process table  ten processes run, each creates 12 (sub-)processes each loops 12 times, forking and / or waiting  the scheduler starts them all running in round-robin  each forks 9 child processes - the process table is full all ten processes wait forever to create the required children

21. csci2413 - L1121 © De Montfort University, 2004/5 Deadlock Prevention Necessary conditions for deadlock  Mutual exclusion  Hold and wait  No preemption  Circular waiting Ensure that at least one of the necessary conditions is false at all times

22. csci2413 - L1122 © De Montfort University, 2004/5 Deadlock Avoidance Define a model of system states, then choose a strategy that will guarantee that the system will not go to a deadlock state Requires extra information, e.g., the maximum claim for each process Resource manager tries to see the worst case that could happen. It does not grant an incremental resource request to a process if this allocation might lead to deadlock

23. csci2413 - L1123 © De Montfort University, 2004/5 Resource Allocation Denial Referred to as the Banker’s algorithm State of the system is the current allocation of resources to processes Safe state is where there is at least one sequence that does not result in deadlock

24. csci2413 - L1124 © De Montfort University, 2004/5 The Banker’s Algorithm The banker’s algorithm  initialise an array with the number of each resource  for each process keep an array of resources in use and resources still needed  whenever a resource request is made by a process look for a process that can run to completion  resources still needed are less than the available number assume this process runs and frees it’s resources continue, until all processes are verified to be runnable if all processes can complete: safe, grant the request else: unsafe, deny the request Unfortunately, this depends on future knowledge!  and so is ‘impossible’ in practice

25. csci2413 - L1125 © De Montfort University, 2004/5 Deadlock Detection In the detection and recovery approach, the system does not try to prevent deadlock occurring  it simply detects when a deadlock has occurred and then (automatically) takes some action to recover The first step is, obviously, to detect the deadlock  if there is a single instance of each resource type a resource allocation graph can be constructed there are many published algorithms for finding cycles (deadlocks) in such directed graphs  if there are multiple instances of resource types an algorithm very similar to the banker’s algorithm is used (but it does not require future knowledge to detect deadlock)

26. csci2413 - L1126 © De Montfort University, 2004/5 Deadlock Recovery Deadlock recovery methods include  recovery through pre-emption a deadlocked resource is taken away  again this causes big problems for resources such as printers  may be possible to carefully choose the pre-emption to make this work  recovery through rollback each resource allocation causes some form of checkpoint for the process to be saved by the operating system  similar to a process table entry for a pre-empted process on deadlock, processes ‘rewound’ to free required resources  may be very difficult & costly, if e.g. files have been written to  recovery through process termination crudest method is to kill one or more deadlocked processes with luck the deadlock with cease, if not kill more processes! but how can processes be killed without causing ‘damage’?

27. csci2413 - L1127 © De Montfort University, 2004/5 The Ostrich Algorithm Surprisingly, perhaps, ignoring the problem altogether is a popular choice of algorithm!  this is the ‘ostrich algorithm’: stick your head in the sand and pretend that there is no problem at all Is this acceptable?  mathematicians say ‘no’  engineers say ‘calculate how often it’s likely to occur, and if that is infrequent enough, then it’s tolerable’  computer scientists say ‘sure... everyone expects a computer to hang or crash occasionally’! Most contemporary OS’s, including both UNIX and Windows NT, use the ostrich algorithm

28. csci2413 - L1128 © De Montfort University, 2004/5 The following slides are supplements, not covered in the lecture session Also see chapter 6 pages 275 – 279, Stallings

29. csci2413 - L1129 © De Montfort University, 2004/5 Dining Philosophers Problem

30. csci2413 - L1130 © De Montfort University, 2004/5 Dining Philosophers Problem 5 Philosophers 5 forks Each philosopher needs two forks to eat with Devise a deadlock free strategy

31. csci2413 - L1131 © De Montfort University, 2004/5 Dining Philosophers Problem 1. Each Philosopher picks up L fork then R, eats and replaces forks – possible starvation. 2. Each philosopher picks up L fork. If R fork available takes it and eats; else puts L fork back ? 3. Buy 5 more forks ! 4. Teach philosophers to eat spaghetti with 1 fork ! 5. Allow only four philosophers at a time into the room. 6. Have at least one philosopher who is left handed in (2) above (R fork first).

32. csci2413 - L1132 © De Montfort University, 2004/5 UNIX Signals UNIX uses signals for IPC synchronisation A UNIX signal is similar to a software interrupt  a process may send a signal to another process  when a signal arrives, the receiving process stops what it is doing and immediately services the signal A signal is sent by using the kill system call kill(process_id, signal_number);

33. csci2413 - L1133 © De Montfort University, 2004/5 Signals … The action taken when a signal is received by a process is specified by the signal system call  it can (usually) be ignored  it can terminate the process  it can be ‘caught’ by a special signal handling function

34. csci2413 - L1134 © De Montfort University, 2004/5 Signal List Signal NameCauseSignal NameCause SIGHUP hangup on controlling terminal or death of control process SIGINT interrupt from keyboard (usually CTRL-C) SIGQUIT quit from keyboard (usually CTRL-\) SIGILL illegal instruction SIGABRT abort signal from debugger SIGFPE floating point exception SIGKILL kill signal (cannot be caught or ignored) SIGSEGV segmentation violation SIGPIPE broken pipe: write to pipe with no readers SIGALRM timer signal from alarm system call SIGCHLD child process stopped or terminated SIGTERM used to request that a process terminates gracefully SIGUSR1 user-defined signal 1 SIGUSR2 user-defined signal 2 SIGPWR power failure SIGWINCH window resize signal

35. csci2413 - L1135 © De Montfort University, 2004/5 Signal Examples SIGKILL sent to a process to immediately kill it this signal cannot be caught or ignored typically used by the system to stop processes at shutdown or by root to kill runaway processes via the ‘kill’ command SIGFPE floating point error SIGSEGV illegal or invalid memory reference these can be caught by a program, to take appropriate action

36. csci2413 - L1136 © De Montfort University, 2004/5 Signal …. SIGPIPE write on a pipe with no readers can be caught to allow the ‘earlier’ processes in a pipe-line to exit when a ‘later’ process has exited abnormally SIGINT/QUIT two levels of keyboard interrupt SIGINT is ‘gentler’: interpreted as a request to stop SIGQUIT is ‘harder’: an instruction to stop

37. csci2413 - L1137 © De Montfort University, 2004/5 Effect of a signal on a process A program should be terminated, either normally exit executed, or abnormally - abort executed, depending on the signal received. Other options :- ignore the signal; the arrival of the signal has no effect. catch the signal; an exception routine called.

38. csci2413 - L1138 © De Montfort University, 2004/5 To ignore or catch a signal A system call signal is used. e.g. to ignore signals :- #include signal(SIGINT, SIG_IGN); /* to ignore SIGINT */ signal(SIGINT, SIG_DFL); /* to change back to default */