NETW 3005 Monitors and Deadlocks

Reading For this lecture, you should have read Chapter 7. NETW3005 (Operating Systems) Lecture 06 - Deadlocks2

Last Lecture: synchronisation Critical sections Synchronisation hardware Semaphores NETW3005 (Operating Systems) Lecture 06 - Deadlocks3

This lecture Monitors (more on synchronisation) Deadlock –Deadlock concept –Resource allocation graphs –Deadlock prevention –Deadlock avoidance –Deadlock detection –Deadlock recovery NETW3005 (Operating Systems) Lecture 06 - Deadlocks4

Problems with low-level synch. tools It’s fairly easy for programmers to misuse a synchronisation tool such as a semaphore. Consider the semaphore solution to the critical section problem: NETW3005 (Operating Systems) Lecture 06 - Deadlocks5

Problems with low-level synch. tools What happens if we swap signal and wait? Or omit one of them? NETW3005 (Operating Systems) Lecture 06 - Deadlocks6 repeat wait(mutex) critical section signal(mutex) remainder section until false

Monitors A monitor is a high-level language construct to make synchronisation easier for programmers. A monitor is an abstract data type. In other words, it encapsulates private data with public methods that operate on that data. NETW3005 (Operating Systems) Lecture 06 - Deadlocks7

Monitors The methods provided by a monitor are guaranteed by the language to operate with mutual exclusion. –Only one process/thread can be active within a monitor at any one time. –So no two methods can be executed simultaneously by two different processes/threads. NETW3005 (Operating Systems) Lecture 06 - Deadlocks8

The Java synchronized keyword Java doesn’t use monitors. But it provides a similar service through the synchronized keyword. Every object in Java is associated with something called a lock. Normally, when an object has one of its methods invoked, this lock is ignored. NETW3005 (Operating Systems) Lecture 06 - Deadlocks9

The Java synchronized keyword If you declare a method as synchronized a thread calling the method needs to own the lock for the object. If a thread calls a synchronized method and the lock for the object is unowned, it becomes the owner, and can enter the method. When it exits the method, it releases the lock. NETW3005 (Operating Systems) Lecture 06 - Deadlocks10

Entry sets If a thread calls a synchronized method and another thread already owns the lock, the thread blocks, and is put into the entry set for the object. When the lock is released by the thread currently using it, the JVM checks the entry set for the object associated with the method. NETW3005 (Operating Systems) Lecture 06 - Deadlocks11

Entry sets If this set is nonempty, the JVM selects an arbitrary thread from the set to be the next owner of the lock. NETW3005 (Operating Systems) Lecture 06 - Deadlocks12

Synchronised methods example NETW3005 (Operating Systems) Lecture 06 - Deadlocks13 public synchronized void enter(Object item){ while (count == BUFFER_SIZE) Thread.yield(); ++count; buffer[in] = item; in = (in + 1) % BUFFER_SIZE; } Thread.yield() makes the thread give the CPU to another thread but will not release the object lock. This is better than busy waiting. Another option we have is Thread.sleep() however it also does not release the object lock but prevents busy waiting

Synchronised methods example NETW3005 (Operating Systems) Lecture 06 - Deadlocks14 public synchronized Object remove() { Object item; while (count == 0) Thread.yield; --count; item = buffer[out]; out = (out + 1) % BUFFER_SIZE; return item; }

A problem Assume that the buffer is full, and the consumer is sleeping. –If the producer calls the enter() method, it will be allowed to, because the lock is available. –Once the producer is in the method, it will see that the buffer is full, and yield. –When the consumer wakes up and tries to call the remove() method, it doesn’t have the lock— so it has to block. NETW3005 (Operating Systems) Lecture 06 - Deadlocks15

A problem Now neither process can progress further. This kind of situation is called deadlock. NETW3005 (Operating Systems) Lecture 06 - Deadlocks16

The solution: wait and notify We need to have a way for the producer thread to ‘yield’ without holding onto the lock. We also need a way for the consumer to let any yielding producers know that the situation has changed. We use wait() and notify() to do these two things. wait() and notify() are in Java’s Object class which is the super class for every class NETW3005 (Operating Systems) Lecture 06 - Deadlocks17

The solution: wait and notify As well as a lock, every object also has a wait set of waiting threads. If a thread needs to wait after entering a synchronized method, it can call the wait method. It is then placed in this wait set, and it releases the object’s lock. NETW3005 (Operating Systems) Lecture 06 - Deadlocks18

The solution: wait and notify If another thread using a method associated with the object calls notify, this picks an arbitrary thread from the object’s wait set, and places it in the object’s entry set. NETW3005 (Operating Systems) Lecture 06 - Deadlocks19

Deadlock We’ve just seen one example of deadlock, which was solved by a programmer making changes to her code. It would be useful for the operating system to be able to monitor the processes currently executing, and –to detect if a deadlock has occurred; or –to prevent deadlocks from ever occurring. NETW3005 (Operating Systems) Lecture 06 - Deadlocks20

Resources of a computer system A computer system can be thought of as a finite collection of resources: –Memory space –CPU cycles –I/O devices –Files NETW3005 (Operating Systems) Lecture 06 - Deadlocks21

Resources of a computer system There’s a distinction between resource types and individual instances of these types. The processes in the system are competing for these resources, however some resources are sharable. NETW3005 (Operating Systems) Lecture 06 - Deadlocks22

Operations on resources Processes can: –request a resource type; –be granted a resource; –use a resource; –release a resource. NETW3005 (Operating Systems) Lecture 06 - Deadlocks23

How are these implemented? Different ways. –System calls (for devices, files, memory). –Semaphores. NETW3005 (Operating Systems) Lecture 06 - Deadlocks24

Deadlocked Processes A set of processes is in a deadlocked state if every process is waiting for an event that can only be caused by another process in the set. An small Example: Let S and Q be two semaphores initialized to 1 which are used by P0 and P1 P0P1 S.acquire(); Q.acquire(); Q.acquire(); S.acquire();. S.release(); Q.release(); Q.release(); S.release(); NETW3005 (Operating Systems) Lecture 06 - Deadlocks25

The dining philosophers problem NETW3005 (Operating Systems) Lecture 06 - Deadlocks26

Necessary conditions for deadlock Mutual exclusion: at least one of the held resources must be non-sharable. Hold and wait: there must be at least one process that’s holding a resource and waiting for another resource. No preemption: a resource can only be released by the process that’s holding it. Circular Wait: see next slide NETW3005 (Operating Systems) Lecture 06 - Deadlocks27

Circular wait P 1 is waiting on a resource held by P 2 ; P 2 is waiting on a resource held by P 3 ;... P n is waiting on a resource held by P 1. NETW3005 (Operating Systems) Lecture 06 - Deadlocks28

Resource-allocation graph A graph containing two kinds of node, and two kinds of edge. NETW3005 (Operating Systems) Lecture 06 - Deadlocks29 PR request edge A resource of type R has been requested by process P PR assignment edge An instance of re- source type R has been allocated to P

Resource-allocation graphs When a request is granted, the request edge is transformed instantaneously into an assignment edge. When a resource is released, the assignment edge is deleted. NETW3005 (Operating Systems) Lecture 06 - Deadlocks30

Resource-allocation graphs NETW3005 (Operating Systems) Lecture 06 - Deadlocks31 P1P2 P3 R1 R3 R2 R4

Resource-allocation graphs If the graph contains no cycles, the system is not deadlocked. If the graph contains a cycle, –if there is only one instance of each re- source involved, the system is deadlocked; –otherwise, it might be deadlocked (and might not be). NETW3005 (Operating Systems) Lecture 06 - Deadlocks32

Cyclic resource allocation graphs NETW3005 (Operating Systems) Lecture 06 - Deadlocks33 P1P2 P3 R1 R3 R2 R4 Deadlocked? Yes. See p

Cyclic resource allocation graphs NETW3005 (Operating Systems) Lecture 06 - Deadlocks34 P1 P2 P4 R1 R2 P3 Deadlocked? No. See p

Methods for Handling Deadlock Deadlock prevention. Deadlock avoidance. Deadlock detection and recovery. The ostrich approach. NETW3005 (Operating Systems) Lecture 06 - Deadlocks35

Deadlock prevention 1 Prevent mutual exclusion Stipulate that all resources are sharable. –a sharable resource? –A non-sharable resource? Not feasible to force resources to be sharable. NETW3005 (Operating Systems) Lecture 06 - Deadlocks36

Deadlock prevention 2 Hold and wait Force a process to be allocated all its resources before it starts execution, Only allowing a process to request resources when it has none. Problems: –resource utilisation is low. –Starvation is a problem. NETW3005 (Operating Systems) Lecture 06 - Deadlocks37

Deadlock prevention 3 Preemption. Allowing a process which wants a re- source that’s being held by some other process to preempt it. Problems: –In general, there are some resources which can’t be preempted, as preemption requires saving a state that can be returned to. NETW3005 (Operating Systems) Lecture 06 - Deadlocks38

Deadlock prevention 4 Circular Wait Impose a total ordering of all resource types. Require that a process requests resources in increasing order. NETW3005 (Operating Systems) Lecture 06 - Deadlocks39

Deadlock prevention 4 Problems: –It’s hard to specify an order. Some programs want the disk drive then the printer; others want the printer then the disk drive. –If you need something lower down, you have to release the higher ones, which is the same problem as above. NETW3005 (Operating Systems) Lecture 06 - Deadlocks40

Deadlock Avoidance Deadlock prevention techniques don’t make the most of the information that’s available. We know what programs are being run by the processes. We can require that each process declare in advance what resources it may use (in the worst case). NETW3005 (Operating Systems) Lecture 06 - Deadlocks41

Safe State A system is in a safe state if there exists a sequence of processes P 1,..., P n such that the system can allocate all the resources still to be demanded by each process P i, using only –the resources currently free, and –the collection of resources requested by all P j (j < i). NETW3005 (Operating Systems) Lecture 06 - Deadlocks42

Safe State In the worst case, we’ll be safe if we execute the processes in this ‘safe sequence’. But it might also be that the processes could all run at once. How do we impose an ordering on processes? NETW3005 (Operating Systems) Lecture 06 - Deadlocks43

Answer If you’re in a safe state, you don’t need to worry. However, if a new process comes along that would put the system into an unsafe state, then you should make it wait until some processes have terminated, and check again. NETW3005 (Operating Systems) Lecture 06 - Deadlocks44

Deadlocks and unsafe states The system can be in an unsafe state without necessarily being in a deadlock. NETW3005 (Operating Systems) Lecture 06 - Deadlocks45 deadlock unsafe state safe state Why?

It’s because the concept of safe state is expressed in terms of the maximum set of resources claimed by each process. It’s up to the actual processes them- selves to determine whether to ask for these resources. NETW3005 (Operating Systems) Lecture 06 - Deadlocks46

Algorithm for deadlock avoidance Only works for a situation where there is only one instance of each resource type. We add a new kind of edge called a claim edge to the resource allocation graph. A claim edge P i → R j means that process P i may request resource R j at some point in the future. NETW3005 (Operating Systems) Lecture 06 - Deadlocks47

Deadlocks and unsafe states - 2 We draw claim edges with dashed lines. If P i actually requests R j, we turn the claim edge into a request edge, (only) if that does not result in a cycle. NETW3005 (Operating Systems) Lecture 06 - Deadlocks48

Deadlock detection If a system isn’t operating an algorithm for dead-lock avoidance, it may still want to check periodically to see whether any deadlocks have occurred. If they have, it’ll want to recover from them. If there is just one instance of each resource, we can use the resource- allocation graph to detect a deadlock. NETW3005 (Operating Systems) Lecture 06 - Deadlocks49

How often do we want to? A good idea is to do it whenever CPU utilisation falls below some threshold. Because we know that CPU utilisation goes down if there’s a deadlock. NETW3005 (Operating Systems) Lecture 06 - Deadlocks50

Recovery from deadlock Process termination –Abort all deadlocked processes. –Abort one process at a time Resource preemption: –Preempt resources one at a time (but in what order?) see p266. –Affected processes need to be restarted. (or rolled back). NETW3005 (Operating Systems) Lecture 06 - Deadlocks51

Next Lecture Memory Management Chapter 8 (Sections 1-6)