CENG 334 Introduction to Operating Systems Monitors Condition

CENG 334 Introduction to Operating Systems Monitors, Condition variabless Topics: • Monitors • Condition Variables Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL: http: //kovan. ceng. metu. edu. tr/ceng 334 1

Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P 0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P 1: 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. 2

Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P 0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P 1: 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. 3

Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P 0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P 1: 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 P 1 is not in critical section then flag[1] = 0. Therefore while loop of P 0 quits immediately and P 0 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. 4

Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P 0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P 1: 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, P 0, P 1 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? 5

Peterson’s Algorithm int flag[2] = {0, 0}; int turn; P 0: do{ flag[0] = 1; turn = 1; while (flag[1] == 1 && turn == 1) { // busy wait } // critical section flag[0] = 0; //remainder section }while(1); P 1: 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 P 0 has a higher priority than P 1. When P 1 is in its critical section, P 0 may get scheduled to do spinlocking. P 1 never gets scheduled to finish its critical section and both processes end up waiting. 6

Semaphore Implementation struct semaphore { int val; mutex mtx; // makes sure the down and ups are atomic threadlist L; // List of threads waiting for semaphore } down(semaphore S){ // Wait until > 0 then decrement while(1){ acquire(S. mtx); if (S. val <= 0) { add_this_thread(S. L); release_mutex_and)block (S. mtx); //this should be atomic }else{ S. val = S. val -1; release(S. mtx); break; } } up(semaphore S){ // Increment value and wake up next thread acquire(S. mtx); S. val = S. val + 1; remote_one_thread_and_wakeup(S. L); release(S. mutex); } Adapted from Matt Welsh’s (Harvard University) slides. 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. • • also provide Condition Variables (CVs) for threads to temporarily give up exclusive access, in order to wait for some condition to be met, • • That is, at each point in time, at most one thread may be executing any of its methods. 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 Waiting threads At most one thread in the monitor at a time Methods accessing shared data How is this different than a lock? ? ? Adapted from Matt Welsh’s (Harvard University) slides. 11

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

Monitors locked Shared data zzzz. . . Methods accessing shared data 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 Monitor stays locked! (Lock now owned by different thread. . . ) locked Shared data notify() zzzz. . . Adapted from Matt Welsh’s (Harvard University) slides. Methods accessing shared data 14

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

Monitors locked Shared data Methods accessing shared data 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 have. TL; void withdraw(int amount) { if (amount > TL) wait(have. TL); TL -= amount; } void deposit(int amount) { TL += amount; notify(have. TL); } } 17

Bank Example monitor Bank{ int TL = 1000; condition have. TL; void withdraw(int amount) { while (amount > TL) wait(have. TL); TL -= amount; } void deposit(int amount) { TL += amount; notify. All(have. TL); } } 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 = get. Item. From. Array(); // Get next item Why didn’t we do this? if (n==0) { wait(not_empty); // If nothing, sleep } remove. Item. From. Array(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 Waiting. Readers: Number of waiting readers; initially = 0 int NWriters: Number of active writers; initially = 0 int Waiting. Writers: Number of waiting writers; initially = 0 Condition can. Read = NIL Conditioin can. Write = NIL 24

Readers and Writers Monitor Readers. NWriters { int Waiting. Writers, Waiting. Readers, NWriters; Condition Can. Read, Can. Write; Void Begin. Write() { if(NWriters == 1 || NReaders > 0) { ++Waiting. Writers; wait(Can. Write); --Waiting. Writers; } NWriters = 1; } Void End. Write() { NWriters = 0; if(Waiting. Readers) Signal(Can. Read); else Signal(Can. Write); } Void Begin. Read() { if(NWriters == 1 || Waiting. Writers > 0) { ++Waiting. Readers; Wait(Can. Read); --Waiting. Readers; } ++NReaders; Signal(Can. Read); } Void End. Read() { if(--NReaders == 0) Signal(Can. Write); } 25

Readers and Writers Monitor Readers. NWriters { int Waiting. Writers, Waiting. Readers, NWriters; Condition Can. Read, Can. Write; Void Begin. Write() { if(NWriters == 1 || NReaders > 0) { ++Waiting. Writers; wait(Can. Write); --Waiting. Writers; } NWriters = 1; } Void End. Write() { NWriters = 0; if(Waiting. Readers) Signal(Can. Read); else Signal(Can. Write); } Void Begin. Read() { if(NWriters == 1 || Waiting. Writers > 0) { ++Waiting. Readers; Wait(Can. Read); --Waiting. Readers; } ++NReaders; Signal(Can. Read); } Void End. Read() { if(--NReaders == 0) Signal(Can. Write); } 26

Readers and Writers Monitor Readers. NWriters { int Waiting. Writers, Waiting. Readers, NWriters; Condition Can. Read, Can. Write; Void Begin. Write() { if(NWriters == 1 || NReaders > 0) { ++Waiting. Writers; wait(Can. Write); --Waiting. Writers; } NWriters = 1; } Void End. Write() { NWriters = 0; if(Waiting. Readers) notify(Can. Read); else notify(Can. Write); } Void Begin. Read() { if(NWriters == 1 || Waiting. Writers > 0) { ++Waiting. Readers; Wait(Can. Read); --Waiting. Readers; } ++NReaders; Signal(Can. Read); } Void End. Read() { if(--NReaders == 0) notify(Can. Write); } 27

Readers and Writers Monitor Readers. NWriters { int Waiting. Writers, Waiting. Readers, NWriters; Condition Can. Read, Can. Write; Void Begin. Write() { if(NWriters == 1 || NReaders > 0) { ++Waiting. Writers; wait(Can. Write); --Waiting. Writers; } NWriters = 1; } Void End. Write() { NWriters = 0; if(Waiting. Readers) notify(Can. Read); else notify(Can. Write); } Void Begin. Read() { if(NWriters == 1 || Waiting. Writers > 0) { ++Waiting. Readers; Wait(Can. Read); --Waiting. Readers; } ++NReaders; notify(Can. Read); } Void End. Read() { if(--NReaders == 0) notify(Can. Write); } 28

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

Readers and Writers Monitor Readers. NWriters { int Waiting. Writers, Waiting. Readers, NWriters; Condition Can. Read, Can. Write; Void Begin. Write() { if(NWriters == 1 || NReaders > 0) { ++Waiting. Writers; wait(Can. Write); --Waiting. Writers; } NWriters = 1; } Void End. Write() { NWriters = 0; if(Waiting. Readers) notify(Can. Read); else notify(Can. Write); } Void Begin. Read() { if(NWriters == 1 || Waiting. Writers > 0) { ++Waiting. Readers; Wait(Can. Read); --Waiting. Readers; } ++NReaders; notify(Can. Read); } Void End. Read() { if(--NReaders == 0) notify(Can. Write); } 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) 31

Readers and Writers Monitor Readers. NWriters { int Waiting. Writers, Waiting. Readers, NWriters; Condition Can. Read, Can. Write; Void Begin. Write() { if(NWriters == 1 || NReaders > 0) { ++Waiting. Writers; wait(Can. Write); --Waiting. Writers; } NWriters = 1; } Void End. Write() { NWriters = 0; if(Waiting. Readers) notify(Can. Read); else notify(Can. Write); } Void Begin. Read() { if(NWriters == 1 || Waiting. Writers > 0) { ++Waiting. Readers; Wait(Can. Read); --Waiting. Readers; } ++NReaders; notify(Can. Read); } Void End. Read() { if(--NReaders == 0) notify(Can. Write); } 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) 33

Readers and Writers Monitor Readers. NWriters { int Waiting. Writers, Waiting. Readers, NWriters; Condition Can. Read, Can. Write; Void Begin. Write() { if(NWriters == 1 || NReaders > 0) { ++Waiting. Writers; wait(Can. Write); --Waiting. Writers; } NWriters = 1; } Void End. Write() { NWriters = 0; if(Waiting. Readers) notify(Can. Read); else notify(Can. Write); } Void Begin. Read() { if(NWriters == 1 || Waiting. Writers > 0) { ++Waiting. Readers; Wait(Can. Read); --Waiting. Readers; } ++NReaders; notify(Can. Read); } Void End. Read() { if(--NReaders == 0) notify(Can. Write); } 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

CENG 334 Introduction to Operating Systems Synchronization patterns Topics • Signalling • Rendezvous • Barrier Erol Sahin Dept of Computer Eng. Middle East Technical University Ankara, TURKEY URL: http: //kovan. ceng. metu. edu. tr/ceng 334 37

Signalling Possibly the simplest use for a semaphore is signaling, which means that one thread sends a signal to another thread to indicate that something has happened. Signaling makes it possible to guarantee that a section of code in one thread will run before a section of code in another thread; in other words, it solves the serialization problem. Adapted from The Little Book of Semaphores. 38

Signalling Imagine that a 1 reads a line from a file, and b 1 displays the line on the screen. The semaphore in this program guarantees that Thread A has completed a 1 before Thread B begins b 1. Here’s how it works: if thread B gets to the wait statement first, it will find the initial value, zero, and it will block. Then when Thread A signals, Thread B proceeds. Similarly, if Thread A gets to the signal first then the value of the semaphore will be incremented, and when Thread B gets to the wait, it will proceed immediately. Either way, the order of a 1 and b 1 is guaranteed. semaphore sem=0; Thread A statement a 1; sem. up(); Adapted from The Little Book of Semaphores. Thread B sem. down(); statement b 1; 39

Rendezvous Generalize the signal pattern so that it works both ways. Thread A has to wait for Thread B and vice versa. In other words, given this code we want to guarantee that a 1 happens before b 2 and b 1 happens before a 2. Your solution should not enforce too many constraints. For example, we don’t care about the order of a 1 and b 1. In your solution, either order should be possible. Two threads rendezvous at a point of execution, and neither is allowed to proceed until both have arrived. Thread A statement a 1; statement a 2; Adapted from The Little Book of Semaphores. Thread B statement b 1; statement b 2; 40

Rendezvous - Hint Generalize the signal pattern so that it works both ways. Thread A has to wait for Thread B and vice versa. In other words, given this code we want to guarantee that a 1 happens before b 2 and b 1 happens before a 2. Your solution should not enforce too many constraints. For example, we don’t care about the order of a 1 and b 1. In your solution, either order should be possible. Two threads rendezvous at a point of execution, and neither is allowed to proceed until both have arrived. Hint: Create two semaphores, named a. Arrived and b. Arrived, and initialize them both to zero. a. Arrived indicates whether Thread A has arrived at the rendezvous, and b. Arrived likewise. semaphore a. Arrived=0; semaphore b. Arrived=0; Thread A statement a 1; statement a 2; Adapted from The Little Book of Semaphores. Thread B statement b 1; statement b 2; 41

Rendezvous - Solution Generalize the signal pattern so that it works both ways. Thread A has to wait for Thread B and vice versa. In other words, given this code we want to guarantee that a 1 happens before b 2 and b 1 happens before a 2. Your solution should not enforce too many constraints. For example, we don’t care about the order of a 1 and b 1. In your solution, either order should be possible. Two threads rendezvous at a point of execution, and neither is allowed to proceed until both have arrived. Hint: Create two semaphores, named a. Arrived and b. Arrived, and initialize them both to zero. a. Arrived indicates whether Thread A has arrived at the rendezvous, and b. Arrived likewise. semaphore a. Arrived=0; semaphore b. Arrived=0; Thread A statement a 1; a. Arrived. up(); b. Arrived. down(); statement a 2; Adapted from The Little Book of Semaphores. Thread B statement b 1; b. Arrived. up(); a. Arrived. down(); statement b 2; 42

Rendezvous – A less efficient solution This solution also works, although it is probably less efficient, since it might have to switch between A and B one time more than necessary. If A arrives first, it waits for B. When B arrives, it wakes A and might proceed immediately to its wait in which case it blocks, allowing A to reach its signal, after which both threads can proceed. . semaphore a. Arrived=0; semaphore b. Arrived=0; Thread A statement a 1 b. Arrived. down() a. Arrived. up() statement a 2 Adapted from The Little Book of Semaphores. Thread B statement b 1; b. Arrived. up(); a. Arrived. down(); statement b 2; 43

Rendezvous – How about? semaphore a. Arrived=0; semaphore b. Arrived=0; Thread A statement a 1 b. Arrived. down() a. Arrived. up() statement a 2 Adapted from The Little Book of Semaphores. Thread B statement b 1; a. Arrived. down(); b. Arrived. up(); statement b 2; 44

Barrier Rendezvous solution does not work with more than two threads. Puzzle: Generalize the rendezvous solution. Every thread should run the following code: rendezvous(); criticalpoint(); The synchronization requirement is that no thread executes critical point until after all threads have executed rendezvous. You can assume that there are n threads and that this value is stored in a variable, n, that is accessible from all threads. When the first n − 1 threads arrive they should block until the nth thread arrives, at which point all the threads may proceed. Adapted from The Little Book of Semaphores. 45

Barrier - Hint n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; count keeps track of how many threads have arrived. mutex provides exclusive access to count so that threads can increment it safely. barrier is locked (zero or negative) until all threads arrive; then it should be unlocked (1 or more). Adapted from The Little Book of Semaphores. 46

Barrier – Solution? n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex. down(); count = count + 1; mutex. up(); if (count == n) barrier. up(); else barrier. down(); Criticalpoint(); Since count is protected by a mutex, it counts the number of threads that pass. The first n− 1 threads wait when they get to the barrier, which is initially locked. When the nth thread arrives, it unlocks the barrier. What is wrong with this solution? Adapted from The Little Book of Semaphores. 47

Barrier – Solution? n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex. down(); count = count + 1; mutex. up(); if (count == n) barrier. up(); else barrier. down(); Criticalpoint(); Imagine that n = 5 and that 4 threads are waiting at the barrier. The value of the semaphore is the number of threads in queue, negated, which is -4. When the 5 th thread signals the barrier, one of the waiting threads is allowed to proceed, and the semaphore is incremented to -3. But then no one signals the semaphore again and none of the other threads can pass the barrier. Adapted from The Little Book of Semaphores. 48

Barrier – Solution n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex. down(); count = count + 1; mutex. up(); if (count == n) barrier. up(); else{ barrier. down(); barrier. up(); } Criticalpoint(); The only change is another signal after waiting at the barrier. Now as each thread passes, it signals the semaphore so that the next thread can pass. Adapted from The Little Book of Semaphores. 49

Barrier – Bad Solution n = thenumberofthreads; count = 0; Semaphore mutex=1, barrier=0; rendezvous(); mutex. down(); count = count + 1; if (count == n) barrier. up(); barrier. down(); barrier. up(); mutex. up(); Criticalpoint(); Imagine that the first thread enters the mutex and then blocks. Since the mutex is locked, no other threads can enter, so the condition, count==n, will never be true and no one will ever unlock. Adapted from The Little Book of Semaphores. 50