CSE120 Principles of Operating Systems. Prof Yuanyuan (YY) Zhou Synchronization: Semaphore

Transcription

1 CSE120 Principes of Operating Systems Prof Yuanyuan (YY) Zhou Synchronization:

2 Synchronization Needs Two synchronization needs Mutua excusion Whenever mutipe threads access a shared data, you need to worry about protection for mutua excusion Coordination (one wait for the other to finish something, e.g. produce the data, free the buffer, etc) 2

3 guard is protecting goba variabe fag q Spinock.acquire(&m->guard) Spinock.reease(&m->guard) 3

4 Higher-Leve Synchronization We ooked at using ocks to provide mutua excusion Those ocks work, but they have some drawbacks when critica sections are ong Spinocks inefficient Instead, we want synchronization mechanisms that Bock waiters Leave interrupts enabed inside the critica section Look at two common high-eve mechanisms s: binary and counting Monitors and condition variabes Use them to sove common synchronization probems 4

5 s s are an abstract data type that provide mutua excusion to critica sections s can aso be used as atomic counters More ater s are integers that support two operations: P(semaphore): decrement, bock the caing thread unti semaphore is open, i.e. the integer is greater than 0 Aso Wait(), or down() V(semaphore): increment, aow another thread to enter. If there is a thread is bocked, wake up this thread. Aso Signa(), or up() That's it! No other operations not even just reading its vaue exist 5 safety property: the semaphore vaue is aways greater than or equa to 0

6 Bocking in s Associated with each semaphore is a queue of waiting processes When P() is caed by a thread: If semaphore is open (>0), thread continues If semaphore is cosed (==0), thread bocks on queue Then V() opens the semaphore: If a thread is waiting on the queue, the thread is unbocked If no threads are waiting on the queue, the signa is remembered for the next thread by increment the counter In other words, V() has history (c.f., condition vars ater) This history is a counter 6

7 Functionaity (NOT impementation) P( s){ If (s==0) bocked in a queue; /* wait unti s>0 */ s=s-1; V( s){ s=s+1; if (someone is waiting in a queue) wakeup one from the queue; 7 Init( s, int v){ s=v;

8 Types s come in two types Binary semaphore (vaue can be ony 1 or 0, some referred it as mutex) Represents singe access to a resource Guarantees mutua excusion to a critica section simiar to ocks with a subte difference: the former can remember when you do V(sem) when sem=0 vs do unock() if no thread has the ock) Counting semaphore Represents a resource with many units avaiabe, or a resource that aows certain kinds of unsynchronized concurrent access (e.g., reading) Mutipe threads can pass the semaphore Number of threads determined by the semaphore count You can use one type to impement the other 8

9 Counter 2 anes 9

10 Animation Video wlcqe In this video, wait() is P() and signa is V() 10

11 Using s Mutex is simiar to our ocks, but semantics are different struct { int vaue; Queue q; S; withdraw (account, amount) { P(S); baance = get_baance(account); baance = baance amount; put_baance(account, baance); V(S); return baance; Threads bock critica section P(S); baance = get_baance(account); baance = baance amount; P(S); P(S); put_baance(account, baance); V(S); V(S); 11 It is undefined which thread runs after a signa V(S);

12 Exercise Using semaphores to aow robots to attend an exam: Ony 10 seats, but 100 robots If a robot comes to the cassroom, if there is an avaiabe seat, it takes the seat; otherwise, wait outside uness another robot eaves the room; Every robot sits in the seat for ony 30min to finish the exam, and then eaves the room Impement the code (steps) for every robot to foow 12

13 Cassic Synchronization probems We ve ooked at a simpe exampe for using synchronization Mutua excusion whie accessing a bank account Now we re going to use semaphores to ook at more interesting exampes Readers/Writers Bounded Buffers Santa cause probem (youtube video) 13

14 Readers/Writers Probem Readers/Writers Probem: An object is shared among severa threads Some threads ony read the object, others ony write it We can aow mutipe readers but ony one writer How can we use semaphores to contro access to the object to impement this protoco? Use three variabes int readcount number of threads reading object mutex contro access to readcount w_or_r excusive writing or reading 14

15 First Attempt w_or_r=1; Reader{ P(w_or_r); // ock out writers read; V(w_or_r); // up for grabs Does it work? Why? writer { P(w_or_r); // ock out readers Write; V(w_or_r); // up for grabs 15

16 Second Attempt w_or_r=1; int readcount; //record #readers 16 Reader{ readcount++; if (readcount == 1){ P(w_or_r); // ock out writers read; readcount--; if (readcount == 0){ V(w_or_r); // up for grabs writer { P(w_or_r); // ock out readers Write; V(w_or_r); // up for grabs Does it work? Why? Is readcount a shared data? Who protects it?

17 Readers/Writers Rea Soution Use three variabes int readcount number of threads reading object mutex Guard access to readcount w_or_r excusive writing or reading 17

18 Readers/Writers // number of readers int readcount = 0; // mutua excusion to readcount mutex = 1; // excusive writer or reader w_or_r = 1; writer { P(w_or_r); // ock out readers Write; V(w_or_r); // up for grabs reader { P(mutex); // ock readcount readcount ++; // one more reader if (readcount == 1) P(w_or_r); // synch w/ writers V(mutex); // unock readcount Read; P(mutex); // ock readcount readcount --; // one ess reader if (readcount == 0) V(w_or_r); // up for grabs V(mutex); // unock readcount I wi give you 2-3 minutes to discuss it with someone next to you 18

19 Readers/Writers Notes w_or_r provides mutex between readers and writers, and aso between mutipe writers Why do readers use mutex (binary semaphore)? What if V() is above if (readcount == 1)? Why do we need if(readcount==1)? Why do we need if(readcount==0)? 19

20 But it sti has a probem // number of readers int readcount = 0; // mutua excusion to readcount mutex = 1; // excusive writer or reader w_or_r = 1; writer { P(w_or_r); // ock out readers Write; V(w_or_r); // up for grabs reader { P(mutex); // ock readcount readcount ++; // one more reader if (readcount == 1) P(w_or_r); // synch w/ writers V(mutex); // unock readcount Read; P(mutex); // ock readcount readcount --; // one ess reader if (readcount == 0) V(w_or_r); // up for grabs V(mutex); // unock readcount 20

21 Probem: Starvation What if a writer is waiting, but readers keep coming, the writer is starved 21

22 Bounded Buffer Probem: There is a set of resource buffers shared by producer and consumer threads Producer inserts resources into the buffer set Output, disk bocks, memory pages, processes, etc. Consumer removes resources from the buffer set Whatever is generated by the producer Producer and consumer execute at different rates No seriaization of one behind the other Tasks are independent (easier to think about) The buffer set aows each to run without expicit handoff 22

23 Bounded Buffer (2) Use three semaphores: empty count of empty buffers Counting semaphore empty = N (np-nc) fu count of fu buffers Counting semaphore np - nc = fu mutex mutua excusion to shared set of buffers Binary semaphore 23

24 Bounded Buffer (3) mutex = 1; // mutua excusion to shared set of buffers empty = N; // count of empty buffers (a empty to start) fu = 0; // count of fu buffers (none fu to start) producer { whie (1) { Produce new resource; P(empty); // wait for empty buffer P(mutex); // ock buffer ist Add resource to an empty buffer; V(mutex); // unock buffer ist V(fu); // note a fu buffer consumer { whie (1) { P(fu); // wait for a fu buffer P(mutex); // ock buffer ist Remove resource from a fu buffer; V(mutex); // unock buffer ist V(empty); // note an empty buffer Consume resource; 24

25 Bounded Buffer (4) 25 Consumer decrements FULL and Bocks when buffer has no item Since the semaphore FULL is at 0

26 Bounded Buffer (5) Why need the mutex at a? Where are the critica sections? What happens if operations on mutex and fu/empty are switched around? The pattern of P/V on fu/empty is a common construct often caed an interock Why V(fu) and V(empty)? Producer-Consumer and Bounded Buffer are cassic exampes of synchronization probems 26

27 Youtube Video for Bounded Buffer Ts 27

28 Possibe Deadocks with s Exampe: P0 P1 share two mutex semaphores S and Q S:= 1; Q:=1; P(S); P(Q);.. V(S); V(Q); P(Q); P(S); V(Q); V(S); 28

29 Be Carefu When Using s // Vioation of Mutua Excusion V(mutex); critica section P(mutex); // Deadock Situation P(mutex); critica section P(mutex); // Vioation of Mutua Excusion critica section V(mutex); 29

30 Summary s can be used to sove any of the traditiona synchronization probems However, they have some drawbacks They are essentiay shared goba variabes Can potentiay be accessed anywhere in program No connection between the semaphore and the data being controed by the semaphore Used both for critica sections (mutua excusion) and coordination (scheduing) Note that I had to use comments in the code to distinguish No contro or guarantee of proper usage Sometimes hard to use and prone to bugs 30

31 Monitors 31 A monitor is a programming anguage construct that contros access to shared data Synchronization code added by compier, enforced at runtime Why is this an advantage? A monitor is a modue that encapsuates Shared data structures Procedures that operate on the shared data structures Synchronization between concurrent threads that invoke the procedures A monitor protects its data from unsynchronized access It guarantees that threads accessing its data through its procedures interact ony in egitimate ways

32 Monitor Semantics A monitor guarantees mutua excusion Ony one thread can execute any monitor procedure at any time (the thread is in the monitor ) If a second thread invokes a monitor procedure when a first thread is aready executing one, it bocks So the monitor has to have a wait queue If a thread within a monitor bocks, another one can enter What are the impications in terms of paraeism in monitor? 32

33 Account Exampe Monitor account { doube baance; doube withdraw(amount) { baance = baance amount; return baance; Threads bock waiting to get into monitor withdraw(amount) baance = baance amount; withdraw(amount) withdraw(amount) return baance (and exit) baance = baance amount return baance; When first thread exits, another can enter. Which one is undefined. baance = baance amount; return baance; Hey, that was easy But what if a thread wants to wait inside the monitor? 33

34 Condition Variabes A condition variabe is associated with a condition needed for a thread to make progress Monitor M {... monitored variabes Condition c; void enter_mon (...) { if (extra property not true) wait(c); do what you have to do if (extra property true) signa(c); waits outside of the monitor's mutex brings in one thread waiting on condition 34

35 Condition Variabes Condition variabes support three operations: Wait reease monitor ock, wait for C/V to be signaed So condition variabes have wait queues, too Signa wakeup one waiting thread Broadcast wakeup a waiting threads Condition variabes are not booean objects if (condition_variabe) then does not make sense if (num_resources == 0) then wait(resources_avaiabe) does An exampe wi make this more cear 35

36 Condition Variabes Condition variabes are NOT conditions So don t EVER do: if (conditionavariabe){ 36 Instead, it is a way for one thread to wait (if some resource is not avaiabe), and some other thread to wake it up once the resource becomes avaiabe Seep Wake (aso caed as signa ) Wakea (or signaa )

37 Condition Variabe & Lock Condition variabe doesn t repace ock, instead it compiments ock Seep(condition, ock) or Wait(condition, ock) First reease the ock, put the thread into the queue of the condition, if waking up, re-aquiring the ock Once seep returns, it is awaken by some other thread, and it aso hods the ock Wake(condition) or Signa(condition): Wake up a thread waiting on the condition (queue) Some systems use a different name such as Signa(condition) or Notify(condition) Wakea(condition) or Broadcast(condition) Wake a the thread waiting on the condition (queue) Some systems may use a different name such as SignaA(condition), or NotifyA(condition) 37

38 Monitor Bounded Buffer Monitor bounded_buffer { Resource buffer[n]; // Variabes for indexing buffer // monitor invariant invoves these vars Condition not_fu; // space in buffer Condition not_empty; // vaue in buffer void put_resource (Resource R) { if (buffer array is fu) wait(not_fu); Add R to buffer array; signa(not_empty); Resource get_resource() { if (buffer array is empty) wait(not_empty); Get resource R from buffer array; signa(not_fu); return R; // end monitor 38 What happens if no threads are waiting when signa is caed? Signa is ost

39 Monitor Queues Monitor bounded_buffer { Condition not_fu; other variabes Condition not_empty; void put_resource () { wait(not_fu) signa(not_empty) Resource get_resource () { Waiting to enter Waiting on condition variabes Executing inside the monitor 39

40 Condition Vars!= s Monitor with Condition variabes!= semaphores But they can impement each other Access to the monitor is controed by a ock wait() bocks the caing thread, and gives up the ock To ca wait, the thread has to be in the monitor (hence has ock) ::P just bocks the thread on the queue signa() causes a waiting thread to wake up If there is no waiting thread, the signa is ost ::V() increases the semaphore count, aowing future entry even if no thread is waiting Condition variabes have no history 40

41 Signa Semantics There are two favors of monitors that differ in the scheduing semantics of signa() Hoare monitors (origina) signa() immediatey switches from the caer to a waiting thread The condition that the waiter was anticipating is guaranteed to hod when waiter executes Signaer must restore monitor invariants before signaing Mesa monitors (Mesa, Java) signa() paces a waiter on the ready queue, but signaer continues inside monitor Condition is not necessariy true when waiter runs again Returning from wait() is ony a hint that something changed Must recheck conditiona case 41

42 Hoare vs. Mesa Monitors Hoare if (empty) Mesa wait(condition); whie (empty) wait(condition); Tradeoffs Mesa monitors easier to use, more efficient Fewer context switches, easy to support broadcast Hoare monitors eave ess to chance Easier to reason about the program 42

43 Monitor Readers and Writers Write with just wait() wi be safe, maybe not ive - why? Starvation Monitor RW { int nr = 0, nw = 0; Condition canread, canwrite; 43 void StartRead () { whie (nw!= 0) do wait(canread); nr++; void EndRead () { nr--; if (nr==0) signa(canwrite) void StartWrite { whie (nr!= 0 nw!= 0) do wait(canwrite); nw++; void EndWrite () { nw--; signa(canwrite); signa(canread); // end monitor

44 Monitor Readers and Writers Is there any priority between readers and writers? What if you wanted to ensure that a waiting writer woud have priority over new readers? 44

45 Summary s P()/V() impement bocking mutua excusion Aso used as atomic counters (counting semaphores) Can be inconvenient to use Monitors Synchronizes execution within procedures that manipuate encapsuated data shared among procedures Ony one thread can execute within a monitor at a time Reies upon high-eve anguage support Condition variabes Used by threads as a synchronization point to wait for events Inside monitors, or outside with ocks 45

46 Dining Phiosophers: an inteectua game Phiosophers eat/think Eating needs 2 forks Pick one fork at a time Possibe deadock? How to prevent deadock? 46

47 Does it sove the Dining Phiosophers Probem? 47

48 Dining Phiosophers Soution 48

49 Dining Phiosophers Soution 49

50 The Seeping Barber Probem N customer Chair One barber can cut one customer s hair at any time No customer, goes to seep 50

51 The Seeping Barber Soution (1) 51

52 The Seeping Barber Soution (2) 52

53 The Seeping Barber Soution (3) Soution to seeping barber probem. 53

54 Santa Cause Probem c4 54