1 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:

1 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL: http://kovan.ceng.metu.edu.tr/ceng334 Peterson’s Algorithm Monitors, Condition variabless Topics: Monitors Condition Variables

2 Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P1: do{ flag[1] = 1; turn = 0; while (flag[0] == 1 && turn == 0) { // busy wait } // critical section flag[1] = 0; // remainder section } while(1); turn : indicates whose turn is it to enter critical section. If turn==i process Pi is allowed to get in. flag[2]: indicates if process Pi is ready to enter critical section. If flag[i]is set, then Pi is ready to enter critical section.

3 Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P1: do{ flag[1] = 1; turn = 0; while (flag[0] == 1 && turn == 0) { // busy wait } // critical section flag[1] = 0; // remainder section } while(1); Mutual Exclusion: Only one process Pi (the one which set turn=i last) enters the critical section.

4 Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P1: do{ flag[1] = 1; turn = 0; while (flag[0] == 1 && turn == 0) { // busy wait } // critical section flag[1] = 0; // remainder section } while(1); Progress: If process P1 is not in critical section then flag[1] = 0. Therefore while loop of P0 quits immediately and P0 can get into its critical section. And vice versa.. Bounded waiting: Process Pi keeps waiting in spinlocking only while the other process is in its critical section.

5 Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P1: do{ flag[1] = 1; turn = 0; while (flag[0] == 1 && turn == 0) { // busy wait } // critical section flag[1] = 0; // remainder section } while(1); Uses spinlocking for waiting. No strict alternation is required between processes. That is, P0,P0,P0,P1,P1 is doable. Requires that processes alternate between critical and remainder sections. Can be extended to n processes, only if n is known apriori (in advance). HOW?

6 Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P1: do{ flag[1] = 1; turn = 0; while (flag[0] == 1 && turn == 0) { // busy wait } // critical section flag[1] = 0; // remainder section } while(1); Prone to priority inversion: Assume that P0 has a higher priority than P1. When P1 is in its critical section, P0 may get scheduled to do spinlocking. P1 never gets scheduled to finish its critical section and both processes end up waiting.

7 Issues with Semaphores Much of the power of semaphores derives from calls to down() and up() that are unmatched See previous example! Unlike locks, acquire() and release() are not always paired. This means it is a lot easier to get into trouble with semaphores. “More rope” Would be nice if we had some clean, well-defined language support for synchronization... Java does! Adapted from Matt Welsh’s (Harvard University) slides.

8 Monitors A monitor is an object intended to be used safely by more than one thread. The defining characteristic of a monitor is that its methods are executed with mutual exclusion. That is, at each point in time, at most one thread may be executing any of its methods. also provide Condition Variables (CVs) for threads to temporarily give up exclusive access, in order to wait for some condition to be met, before regaining exclusive access and resuming their task. Use CVs for signaling other threads that such conditions have been met.

9 Condition Variables Conceptually a condition variable (CV) is a queue of threads, associated with a monitor, upon which a thread may wait for some assertion to become true. Threads can use CV’s to temporarily give up exclusive access, in order to wait for some condition to be met, before regaining exclusive access and resuming their task. for signaling other threads that such conditions have been met.

10 Monitors This style of using locks and CV's to protect access to a shared object is often called a monitor Think of a monitor as a lock protecting an object, plus a queue of waiting threads. Shared data Methods accessing shared data Waiting threads At most one thread in the monitor at a time How is this different than a lock??? Adapted from Matt Welsh’s (Harvard University) slides.

11 Monitors Shared data Methods accessing shared data unlocked Adapted from Matt Welsh’s (Harvard University) slides.

12 Monitors Shared data Methods accessing shared data locked zzzz... Sleeping thread no longer “in” the monitor. (But not on the waiting queue either! Why?) Adapted from Matt Welsh’s (Harvard University) slides.

13 Monitors Shared data Methods accessing shared data locked Monitor stays locked! (Lock now owned by different thread...) zzzz... notify() Adapted from Matt Welsh’s (Harvard University) slides.

14 Monitors Shared data Methods accessing shared data locked notify() Adapted from Matt Welsh’s (Harvard University) slides.

15 Monitors Shared data Methods accessing shared data locked No guarantee which order threads get into the monitor. (Not necessarily FIFO!) Adapted from Matt Welsh’s (Harvard University) slides.

16 Bank Example monitor Bank{ int TL = 1000; condition haveTL; void withdraw(int amount) { if (amount > TL) wait(haveTL); TL -= amount; } void deposit(int amount) { TL += amount; notify(haveTL); }

17 Bank Example monitor Bank{ int TL = 1000; condition haveTL; void withdraw(int amount) { while (amount > TL) wait(haveTL); TL -= amount; } void deposit(int amount) { TL += amount; notifyAll(haveTL); }

18 Hoare vs. Mesa Monitor Semantics The monitor notify() operation can have two different meanings: Hoare monitors (1974) notify(CV) means to run the waiting thread immediately Causes notifying thread to block Mesa monitors (Xerox PARC, 1980) notify(CV) puts waiting thread back onto the “ready queue” for the monitor But, notifying thread keeps running Adapted from Matt Welsh’s (Harvard University) slides.

19 Hoare vs. Mesa Monitor Semantics The monitor notify() operation can have two different meanings: Hoare monitors (1974) notify(CV) means to run the waiting thread immediately Causes notifying thread to block Mesa monitors (Xerox PARC, 1980) notify(CV) puts waiting thread back onto the “ready queue” for the monitor But, notifying thread keeps running What's the practical difference? In Hoare-style semantics, the “condition” that triggered the notify() will always be true when the awoken thread runs For example, that the buffer is now no longer empty In Mesa-style semantics, awoken thread has to recheck the condition Since another thread might have beaten it to the punch Adapted from Matt Welsh’s (Harvard University) slides.

20 Hoare Monitor Semantics Hoare monitors (1974) notify(CV) means to run the waiting thread immediately Causes notifying thread to block The signaling thread must wait outside the monitor (at least) until the signaled thread relinquishes occupancy of the monitor by either returning or by again waiting on a condition.

21 Mesa Monitor Semantics Mesa monitors (Xerox PARC, 1980) notify(CV) puts waiting thread back onto the “ready queue” for the monitor But, notifying thread keeps running Signaling does not cause the signaling thread to lose occupancy of the monitor. Instead the signaled threads are moved to the e queue.

22 Hoare vs. Mesa monitors Need to be careful about precise definition of signal and wait. while (n==0) { wait(not_empty); // If nothing, sleep } item = getItemFromArray(); // Get next item Why didn’t we do this? if (n==0) { wait(not_empty); // If nothing, sleep } removeItemFromArray(val);// Get next item Answer: depends on the type of scheduling Hoare-style (most textbooks): Signaler gives lock, CPU to waiter; waiter runs immediately Waiter gives up lock, processor back to signaler when it exits critical section or if it waits again Mesa-style (Java, most real operating systems): Signaler keeps lock and processor Waiter placed on ready queue with no special priority Practically, need to check condition again after wait

23 Revisit: Readers/Writers Problem Correctness Constraints: Readers can access database when no writers Writers can access database when no readers or writers Only one thread manipulates state variables at a time State variables (Protected by a lock called “lock”): int NReaders: Number of active readers; initially = 0 int WaitingReaders: Number of waiting readers; initially = 0 int NWriters: Number of active writers; initially = 0 int WaitingWriters: Number of waiting writers; initially = 0 Condition canRead = NIL Conditioin canWrite = NIL

24 Readers and Writers Monitor ReadersNWriters { int WaitingWriters, WaitingReaders,NReaders, NWriters; Condition CanRead, CanWrite; Void BeginWrite() { if(NWriters == 1 || NReaders > 0) { ++WaitingWriters; wait(CanWrite); --WaitingWriters; } NWriters = 1; } Void EndWrite() { NWriters = 0; if(WaitingReaders) Signal(CanRead); else Signal(CanWrite); } Void BeginRead() { if(NWriters == 1 || WaitingWriters > 0) { ++WaitingReaders; Wait(CanRead); --WaitingReaders; } ++NReaders; Signal(CanRead); } Void EndRead() { if(--NReaders == 0) Signal(CanWrite); }

25 Readers and Writers Monitor ReadersNWriters { int WaitingWriters, WaitingReaders,NReaders, NWriters; Condition CanRead, CanWrite; Void BeginWrite() { if(NWriters == 1 || NReaders > 0) { ++WaitingWriters; wait(CanWrite); --WaitingWriters; } NWriters = 1; } Void EndWrite() { NWriters = 0; if(WaitingReaders) Signal(CanRead); else Signal(CanWrite); } Void BeginRead() { if(NWriters == 1 || WaitingWriters > 0) { ++WaitingReaders; Wait(CanRead); --WaitingReaders; } ++NReaders; Signal(CanRead); } Void EndRead() { if(--NReaders == 0) Signal(CanWrite); }

26 Readers and Writers Monitor ReadersNWriters { int WaitingWriters, WaitingReaders,NReaders, NWriters; Condition CanRead, CanWrite; Void BeginWrite() { if(NWriters == 1 || NReaders > 0) { ++WaitingWriters; wait(CanWrite); --WaitingWriters; } NWriters = 1; } Void EndWrite() { NWriters = 0; if(WaitingReaders) notify(CanRead); else notify(CanWrite); } Void BeginRead() { if(NWriters == 1 || WaitingWriters > 0) { ++WaitingReaders; Wait(CanRead); --WaitingReaders; } ++NReaders; Signal(CanRead); } Void EndRead() { if(--NReaders == 0) notify(CanWrite); }

27 Readers and Writers Monitor ReadersNWriters { int WaitingWriters, WaitingReaders,NReaders, NWriters; Condition CanRead, CanWrite; Void BeginWrite() { if(NWriters == 1 || NReaders > 0) { ++WaitingWriters; wait(CanWrite); --WaitingWriters; } NWriters = 1; } Void EndWrite() { NWriters = 0; if(WaitingReaders) notify(CanRead); else notify(CanWrite); } Void BeginRead() { if(NWriters == 1 || WaitingWriters > 0) { ++WaitingReaders; Wait(CanRead); --WaitingReaders; } ++NReaders; notify(CanRead); } Void EndRead() { if(--NReaders == 0) notify(CanWrite); }

28 Understanding the Solution A writer can enter if there are no other active writers and no readers are waiting

30 Understanding the Solution A reader can enter if There are no writers active or waiting So we can have many readers active all at once Otherwise, a reader waits (maybe many do)

32 Understanding the Solution When a writer finishes, it checks to see if any readers are waiting If so, it lets one of them enter That one will let the next one enter, etc… Similarly, when a reader finishes, if it was the last reader, it lets a writer in (if any is there)

34 Understanding the Solution It wants to be fair If a writer is waiting, readers queue up If a reader (or another writer) is active or waiting, writers queue up … this is mostly fair, although once it lets a reader in, it lets ALL waiting readers in all at once, even if some showed up “after” other waiting writers

35 The Big Picture The point here is that getting synchronization right is hard How to pick between locks, semaphores, condvars, monitors??? Locks are very simple for many cases. Issues: Maybe not the most efficient solution For example, can't allow multiple readers but one writer inside a standard lock. Condition variables allow threads to sleep while holding a lock Just be sure you understand whether they use Mesa or Hoare semantics! Semaphores provide pretty general functionality But also make it really easy to botch things up. Adapted from Matt Welsh’s (Harvard University) slides.

36 Barbershop problem A barber shop consists of a waiting room with N chairs, and the barber room containing the barber chair. If there are no customers to be served, the barber goes to sleep. If a customer enters the barber shop and all chairs are occupied, then the customer leaves the shop. If the barber is busy, but chairs are available, then the customer sits in one of the free chairs. If the barber is asleep, the customer wakes up the barber.

37 Monitor template monitor BarberShop{ condition waitingForCustomers, waitingForBarbers; int waiting = 0; // number of waiting customers in chairs void barber(){ …………………. cutHair(); ………………. } void customer(){ …………………. getHairCut(); // may not be executed if all chairs are full. ……………… } void barberThread(){ while(1) BarberShop.barber(); } void customerThread(){ BarberShop.customer(); }

38 Semaphore template semaphore customer = 0; // number of customers waiting for service semaphore barber = 0; // number of barbers waiting for customers semaphore mutex = 1; // for mutual exclusion int waiting = 0; //customers who are sitting in chairs void barberThread(){ while (1) { ………………. cutHair(); ……………. } void customerThread(){ ……………….. getHairCut(); // may not be executed if all chairs are full. ……………… }

39 Checking your code B: Does the Barber sleep when there are no customers. BC: Does the first customer wake up the sleeping barber and have his haircut. BCC: Does the second customer waits for the barber while he is giving a haircut to the first customer. BCCCCCCC: Does the 7 th customer (first customer having a haircut, the next 5 customers waiting), exits without getting a haircut? BCCCCC: Does the barber wake up a waiting customer after finishing the haircut of the first customer? Finally, is the solution efficient? Sending more notify signals than needed, or using more variables is not good practise.

40 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL: http://kovan.ceng.metu.edu.tr/~erol/Courses/ceng334 Deadlocks Topics: Deadlocks Dining philosopher problem

41 What’s a deadlock?

42 Deadlock A deadlock happens when Two (or more) threads waiting for each other None of the deadlocked threads ever make progress Mutex 1 Thread 1Thread 2 Mutex 2 holds waits for Adapted from Matt Welsh’s (Harvard University) slides.

43 Deadlock Definition Two kinds of resources: Preemptible: Can take away from a thread e.g., the CPU Non-preemptible: Can't take away from a thread e.g., mutex, lock, virtual memory region, etc. Why isn't it safe to forcibly take a lock away from a thread? Starvation A thread never makes progress because other threads are using a resource it needs Deadlock A circular waiting for resources Thread A waits for Thread B Thread B waits for Thread A Starvation ≠ Deadlock Adapted from Matt Welsh’s (Harvard University) slides.

44 Dining Philosophers Classic deadlock problem Multiple philosophers trying to lunch One chopstick to left and right of each philosopher Each one needs two chopsticks to eat Adapted from Matt Welsh’s (Harvard University) slides.

45 Dining Philosophers What happens if everyone grabs the chopstick to their right? Everyone gets one chopstick and waits forever for the one on the left All of the philosophers starve!!! Adapted from Matt Welsh’s (Harvard University) slides.

46 Deadlock Characterization Mutual exclusion: only one process at a time can use a resource. Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes. No preemption: a resource can be released only voluntarily by the process holding it, after that process has completed its task. Circular wait: there exists a set {P 0, P 1, …, P 0 } of waiting processes such that P 0 is waiting for a resource that is held by P 1, P 1 is waiting for a resource that is held by P 2, …, P n–1 is waiting for a resource that is held by P n, and P 0 is waiting for a resource that is held by P 0. Deadlock can arise if four conditions hold simultaneously. Adapted from Operating System Concepts (Silberschatz, Galvin, Gagne) slides.

47 Deadlock Prevention Restrain the ways request can be made to ensure that at least one of the four conditions DO NOT HOLD! Mutual Exclusion not required for sharable resources; must hold for non-sharable resources, such as a printer. Hold and Wait must guarantee that whenever a process requests a resource, it does not hold any other resources. Require process to request and be allocated all its resources before it begins execution, or allow process to request resources only when the process has none. low resource utilization; starvation possible.

48 Deadlock Prevention (Cont.) No Preemption If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released. Preempted resources are added to the list of resources for which the process is waiting. Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting. Can be applied to resources whose state can be saved such as CPU, and memory. Not applicable to resources such as printer and tape drives. Circular Wait impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration.

49 Circular Wait - 1 Each resource is given an ordering: F(tape drive) = 1 F(disk drive) = 2 F(printer) = 3 F(mutex1) = 4 F(mutex2) = 5 ……. Each process can request resources only in increasing order of enumeration. A process which decides to request an instance of Rj should first release all of its resources that are F(Ri) >= F(Rj).

50 Circular Wait - 2 For instance an application program may use ordering among all of its synchronization primitives: F(semaphore1) = 1 F(semaphore2) = 2 F(semaphore3) = 3 ……. After this, all requests to synchronization primitives should be made only in the increasing order: Correct use: down(semaphore1); down(semaphore2); Incorrect use: down(semaphore3); down(semaphore2); Keep in mind that it’s the application programmer’s responsibility to obey this order.

51 Methods for Handling Deadlocks How should we handle deadlocks Ensure that the system will never enter a deadlock state. Allow the system to enter a deadlock state and then recover. Ignore the problem and pretend that deadlocks never occur in the system; used by most operating systems, including UNIX. Adapted from Operating System Concepts (Silberschatz, Galvin, Gagne) slides.

52 Dining Philosophers How do we solve this problem?? (Apart from letting them eat with forks.)‏ Adapted from Matt Welsh’s (Harvard University) slides.

53 How to solve this problem? Solution 1: Don't wait for chopsticks Grab the chopstick on your right Try to grab chopstick on your left If you can't grab it, put the other one back down Breaks “no preemption” condition – no waiting! Solution 2: Grab both chopsticks at once Requires some kind of extra synchronization to make it atomic Breaks “multiple independent requests” condition! Solution 3: Grab chopsticks in a globally defined order Number chopsticks 0, 1, 2, 3, 4 Grab lower-numbered chopstick first Means one person grabs left hand rather than right hand first! Breaks “circular dependency” condition Solution 4: Detect the deadlock condition and break out of it Scan the waiting graph and look for cycles Shoot one of the threads to break the cycle Adapted from Matt Welsh’s (Harvard University) slides.

54 Deadlock Avoidance Requires that the system has some additional a priori information available. Simplest and most useful model requires that each process declare the maximum number of resources of each type that it may need. Is this possible at all? The deadlock-avoidance algorithm dynamically examines the resource-allocation state to ensure that there can never be a circular-wait condition. When should the algorithm be called? Resource-allocation state is defined by the number of available and allocated resources, and the maximum demands of the processes.

55 System Model Resource types R 1, R 2,..., R m CPU, memory, I/O devices disk network Each resource type R i has W i instances. For instance a quad-core processor has 4 CPUs Each process utilizes a resource as follows: request use release Adapted from Operating System Concepts (Silberschatz, Galvin, Gagne) slides.

56 Resource-Allocation Graph V is partitioned into two types: P = {P 1, P 2, …, P n }, the set consisting of all the processes in the system. R = {R 1, R 2, …, R m }, the set consisting of all resource types in the system. request edge – directed edge P 1  R j assignment edge – directed edge R j  P i A set of vertices V and a set of edges E. Adapted from Operating System Concepts (Silberschatz, Galvin, Gagne) slides.

57 Resource Allocation Graph With A Deadlock If there is a deadlock => there is a cycle in the graph. However the reverse is not true! i.e. If there is a cycle in the graph =/> there is a deadlock Adapted from Operating System Concepts (Silberschatz, Galvin, Gagne) slides.

58 Resource Allocation Graph With A Cycle But No Deadlock However the existence of a cycle in the graph does not necessarily imply a deadlock. Overall message: If graph contains no cycles  no deadlock. If graph contains a cycle  if only one instance per resource type, then deadlock. if several instances per resource type, possibility of deadlock. Adapted from Operating System Concepts (Silberschatz, Galvin, Gagne) slides.

59 Resource-Allocation Graph Algorithm Claim edge P i  R j indicated that process P j may request resource R j ; represented by a dashed line. Claim edge converts to request edge when a process requests a resource. When a resource is released by a process, assignment edge reconverts to a claim edge. Adapted from Operating System Concepts (Silberschatz, Galvin, Gagne) slides.

60 Resource-Allocation Graph Algorithm Claim edge P i  R j indicated that process P j may request resource R j ; represented by a dashed line. Claim edge converts to request edge when a process requests a resource. When a resource is released by a process, assignment edge reconverts to a claim edge. Resources must be claimed a priori in the system. Note that the cycle detection algorithm does not work with resources that have multiple instances. Adapted from Operating System Concepts (Silberschatz, Galvin, Gagne) slides. Cycle => Unsafe

61 Safe, unsafe and deadlock states If a system is in safe state  no deadlocks. If a system is in unsafe state  possibility of deadlock. Avoidance  ensure that a system will never enter an unsafe state. Adapted from Operating System Concepts (Silberschatz, Galvin, Gagne) slides.

62 Safe State When a process requests an available resource, system must decide if immediate allocation leaves the system in a safe state. System is in safe state if there exists a safe sequence of all processes. Sequence is safe if for each P i, the resources that P i can still request can be satisfied by currently available resources + resources held by all the P j, with j < i. If P i resource needs are not immediately available, then P i can wait until all P j have finished. When P j is finished, P i can obtain needed resources, execute, return allocated resources, and terminate. When P i terminates, P i+1 can obtain its needed resources, and so on. Adapted from Operating System Concepts (Silberschatz, Galvin, Gagne) slides.

63 Banker’s Algorithm While giving credits, a banker should ensure that it never allocates all of its cash in such a way that none of its creditors can finish their work and pay back the loan.

64 Example 29P2 24P1 510P0 Current NeedsMaximum Needs The system has three processes and 12 tape drives. t=t0 The system at t0 is safe since the sequence exists.

65 Example 29P2 24P1 510P0 Current NeedsMaximum Needs The system has three processes and 12 tape drives. t=t0 The system at t1 is no longer safe since P1 requests 2 more tape drives, finishes and releases 4 drives. However 4 drives are not sufficient for P0 or P2 complete its operation and would result in a deadlock. P2 requests one more drive 39P2 24P1 510P0 Current NeedsMaximum Needs t=t1

1 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:

Similar presentations

Presentation on theme: "1 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

1 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:

Similar presentations

Presentation on theme: "1 CENG334 Introduction to Operating Systems Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL:"— Presentation transcript:

Similar presentations

About project

Feedback