3. Higher-Level Synchronization - PowerPoint Presentation

3. Higher-Level Synchronization 3.1 Shared Memory Methods Monitors Protected Types3.2 Distributed Synchronization/Comm.Message-Based Communication Procedure-Based Communication Distributed Mutual Exclusion3.3 Other Classical ProblemsThe Readers/Writers ProblemThe Dining Philosophers Problem The Elevator Algorithm Operating Systems 1

Motivation Semaphores are powerful but low-level abstractionsProgramming with them is highly error proneSuch programs are difficult to design, debug, and maintainNot usable in distributed memory systemsNeed higher-level primitives Based on semaphores or messages Operating Systems 2

Monitors Follow the principles of abstract data types(object-oriented programming):A data object is manipulated only by a set of predefined operationsA monitor consists of:A collection of data representing the state of the resource controlled by the monitor, andProcedures/functions to manipulate the data Operating Systems 3

Monitors Implementation must guarantee:Resource is accessible by only monitor proceduresMonitor procedures are mutually exclusiveFor coordination, monitor provides “condition variable” c not a conventional variable, has no value, only a name chosen by programmer Each c has a waiting queue associatedc.waitCalling process is blocked and placed on queue c.signalCalling process wakes up waiting process (if any) Operating Systems 4

Monitors Example: process p1 needs to wait until a variable X becomes positive before it can proceedp1 steps out to wait on queue associated with condition variable X_is_positive Operating Systems 5

Monitors process p1 may reenter the monitor, however …Another process may execute X_is_positive.signal to wake up p1 when X becomes positive Operating Systems 6

Monitors Design Issue:After c.signal, there are 2 ready processes:The calling process that did the c.signalThe waiting process that the c.signal woke upWhich should continue? (Only one can be executing inside the monitor!)Two different approachesHoare monitorsMesa-style monitors Operating Systems 7

Hoare Monitors Introduced by Tony Hoare in a 1974http://wikipedia.org/wiki/C._A._R._HoareFirst implemented by Per Brinch Hansen in Concurrent Pascalhttp://wikipedia.org/wiki/Per_Brinch_HansenApproach taken by Hoare monitor:After c.signal,Awakened process continuesCalling process is suspended , and placed on high-priority queue Operating Systems 8

Hoare Monitors Effect of c.signal Operating Systems 9 urgent p 1 reenters Signaling process has the highest priority It r eenters as soon as p1 terminates

Bounded buffer problem monitor BoundedBuffer { char buffer[n]; int nextin=0, nextout=0, fullCount=0; condition notempty, notfull; deposit(char data) { if (fullCount ==n) notfull.wait ; buffer[ nextin ] = data; nextin = (nextin+1) % n; fullCount = fullCount+1; notempty.signal ; } remove(char data) { if ( fullCount ==0) notempty.wait ; data = buffer[ nextout ]; nextout = (nextout+1) % n; fullCount = fullCount - 1; notfull.signal; } } Operating Systems 10

Priority waits Original Hoare monitor signal resumes longest waiting process (i.e., queue is a FIFO queue)May lead to unnecessary wake-upsSolution: Priority WaitsEvery wait operation specifies a priority p c.wait (p)Waiting processes are kept sorted by pSmallest p = highest priorityReason: p frequently represents timeEarlier events (smaller p) must be processed firstc.signal wakes up highest-priority process (lowest p) Operating Systems 11

Example: alarm clock A monitor (AlarmClock) maintains the current time valueTime is advanced by periodic calls by hardwareA processes can go to sleep by calling AlarmClock.wakeMe(n) monitor AlarmClock { int now=0; condition wakeup; tick() { /*invoked by hardware*/ now = now + 1; wakeup.signal; } wakeMe ( int n ) { int alarm; alarm = now + n; while (now<alarm ) wakeup.wait (alarm ); wakeup.signal ; } } Operating Systems 12

Example: alarm clock Why do we need the last wakeup.signal in wakeMe?tick only wakes up one processIf there are multiple processes with same alarm time, all must be awakened tick wakes up the first process the first process wakes up the second process, etc.Do we really need priority waits?Not for correctness but for efficiency:Without priority waits, all processes would need to wake up to check their alarm settings Operating Systems 13

Mesa-style monitors After issuing c.signal, calling process continues executingProblem: Condition cannot be guaranteed after wakeupAssume that p 1 and p2 are waiting for some condition cCaller could satisfying c and wake up both processesAssume p1 starts and makes the condition false againWhen p2 resumes, c is not guaranteed to be true Solution: process must retest c after wakeup instead of: if (!condition) c.wait use: while (!condition) c.wait This form of signal is sometimes called notify Operating Systems 14

Monitors in Java Java supports synchronized methods, which permit Java objects to be used somewhat similarly to Mesa monitorsEvery object has an implicit lock, with a single associated conditionIf a method is declare synchronized, the object’s lock protects the entire methodwait() causes a thread to wait until it is notifiednotifyAll() awakens all threads waiting on the object’s lock notify () awakens a single randomly chosen thread waiting on the object’s lockBut there are differences… Operating Systems 15

Differences between Java objects and monitors MonitorsResource is only accessible by monitor proceduresMonitor procedures are mutually exclusiveJava objectsFields are not required to be privateMethods are not required to be synchronized Per Brinch Hansen: “It is astounding to me that Java’s insecure parallelism is taken seriously by the programming community, a quarter of a century after the invention of monitors and Concurrent Pascal. It has no merit.” [Java’s Insecure Parallelism, ACM SIGPLAN Notices 34: 38-45, April 1999]. Operating Systems 16

Protected types Introduced in programming language Ada (1995)Equivalent to special case of monitor wherec.wait is the first operation of a procedurec.signal is the last operationwait/signal are combined into a when(cond) clauseProcedure executes only when the condition is truewhen(cond) guards access to the procedure (instead of: if (!cond) c.wait ; ) When some other procedure makes cond true and terminates, it automatically enables the corresponding when clauses (instead of c.signal ) Operating Systems 17

Example: Bounded Buffer deposit(char c) when (fullCount < n) { buffer[nextin] = c; nextin = (nextin + 1) % n; fullCount = fullCount + 1; } remove(char c) when (fullCount > 0) { c = buffer[ nextout ]; nextout = ( nextout + 1) % n; fullCount = fullCount - 1; } Operating Systems 18

Distr ibuted SynchronizationSemaphore-based primitive requires shared memoryFor distributed memory:send(p,m)Send message m to process preceive(q,m)Receive message from process q in variable mSemantics of send and receive vary significantly in different systems:Does sender wait for message to be accepted?Does receiver wait if there is no message? Does sender name exactly one receiver? Does receiver name exactly one sender? Operating Systems 19

Types of send/receive Operating Systems 20

Channels, Ports, and Mailboxes Allow indirect communicationSenders/Receivers name channel/port/mailboxinstead of processesSenders/Receivers determined at runtimeSender does not need to knowwho receives the messageReceiver does not need to knowwho sent the message Operating Systems 21

Named Message Channels Named channel, ch1, connects processesp1 and p2p1 sends to p2 using send(ch1,”a”)p2 receives from p1 using: receive(ch1,x) Used in CSP/Occam: Communicating Sequential Processes in the Occam Programming Language (Hoare, 1978) Operating Systems 22

Named Message Channels in CSP/Occam Receive statements may be implemented as guarded commands Syntax: when (c1) s1 s is enabled (able to be executed) only when c is trueIf more than one guarded command is enabled, one of them is selected for executionThe condition c may contain receive statements, which evaluate to true if and only if the sending process is ready to send on the specified channel. Allow processes to receive messages selectively based on arbitrary conditions Operating Systems 23

Example: Bounded buffer with CSP Producer P, Consumer C, and Buffer B are Communicating Sequential ProcessesProblem statement: When Buffer full: B can only send to CWhen Buffer empty: B can only receive from PWhen Buffer partially filled: B must know whether C or P is ready to actSolution:C sends request to B first; B then sends dataInputs to B from P and C are guarded with when clause Operating Systems 24

Bounded Buffer with CSP Define 3 named channels deposit: P  Brequest: B  C remove: B  CP does:send(deposit, data);C does:send(request)receive(remove, data) Code for B on next slide Operating Systems 25

Bounded buffer with CSP process BoundedBuffer { ... while (1) { when ((fullCount<n) && receive(deposit, buf[nextin])) { nextin = (nextin + 1) % n; fullCount = fullCount + 1; } or when ((fullCount>0) && receive(request)) { send(remove, buf[nextout]); nextout = (nextout + 1) % n; fullCount = fullCount - 1; } } Operating Systems 26

Ports and Mailboxes Indirect communication (named message channels) allows a receiver to receive from multiple senders (nondeterministically)When channel is a queue, send can be nonblocking Such a queue is called mailbox or port,depending on number of receivers:A mailbox can have multiple receivers This can be expensive because receivers referring to the same mailbox may reside on different computersA port can have only one receiverSo all messages addressed to the same port can be sent to one central place. Operating Systems 27

Ports and Mailboxes Operating Systems 28 Figure 3-2

UNIX implements of interprocess communication 2 mechanisms: pipes and socketsPipes: Sender’s standard output is receiver’s standard inputp1 | p2 | … | pnSockets are named endpoints of a 2-way channel between 2 processes. Processes may be on different machines. To establish the channel:One process acts as a server, the other a client Server binds it socket to IP address of its machine and a port numberServer issues an accept statement and blocks until client issues a corresponding connect statementThe connect statement supplies the client’s IP address and port number to complete the connection. Operating Systems 29

Procedure-Based Communication Send/Receive are low level (like P/V)Typical interaction: Client-Server Send Request, Receive ResultMake this into a single higher-level primitiveRPC (Remote Procedure Call) or RendezvousCaller invokes procedure on remote machine Remote machine performs operation and returns resultSimilar to regular procedure call, with some differencesParameters cannot contain pointers or shared referencesPartial failure semantics Operating Systems 30

RPC Caller issues: result = f(params)This is translated into: Operating Systems 31 Calling Process ... send( server,f,params ); receive( server,result ); ... Server Process process RP_server { while (1) { receive( caller,f,params ); result=f( params ); send( caller,result ); } }

Rendezvous A more general procedure-based mechanismIntroduced as part of programming language AdaWith RPC: Called process p is part of a dedicated serverWith Rendezvous: p is part of an arbitrary (user) processp maintains state between callsp may accept/delay/reject callSetup is symmetrical: Any process may be a client or a server Operating Systems 32

Rendezvous Caller: Similar syntax/semantics to RPC q.f(param)where q is the called process (server)Server : Must indicate willingness to accept: accept f(param) SRendezvous:both processes wait for each otherthen server executes S (rendezvous)both processes continue in parallel(Rendezvous = meeting/date in French ) Operating Systems 33

Rendezvous Operating Systems 34

Selective Receive Permit server to wait for multiple asynchronous callsSelect statement encloses multiple acceptsEach accept may be guarded using a when clause Operating Systems 35 select { [when B1:] accept E1(…) S1; or [when B2:] accept E2(…) S2; or … [when Bn :] accept En(…) Sn ; [else R ] } Accept and process all enabled calls If there is no such call, execute else clause If no else clause, error

Example: Bounded Buffer process BoundedBuffer { while(1) { select { when (fullCount < n): accept deposit(char c) { buffer[nextin] = c; nextin = ( nextin + 1) % n; fullCount = fullCount + 1; } or when ( fullCount > 0): accept remove(char c) { c = buffer[ nextout ]; nextout = ( nextout + 1) % n; fullCount = fullCount - 1; } }}} Operating Systems 36

Distributed Mutual Exclusion Critical Section problem in a Distributed EnvironmentSeveral processes share a resource (a printer, a satellite link, a file…)Only one process can use the resource at a timeAdditional Challenges:No shared memoryNo shared clockDelays in message transmission. Operating Systems 37

Distributed Mutual Exclusion Central Controller SolutionRequesting process sends request to controllerController grants it to one processes at a timeProblems with this approach:Single point of failure, Performance bottleneckFully Distributed Solution:Processes negotiate access among themselves Operating Systems 38

Distributed Mutual Exclusion Token Ring solutionEach process has a controllerControllers are arranged in a ringControllers pass a token around the ringProcess whose controller holds token may enter its CS Operating Systems 39

Distributed Mutual Exclusion with Token Ring Operating Systems 40 Figure 3-4

Distributed Mutual Exclusion process controller[i] { while(1) { accept Token; select { accept Request_CS() {busy=1;} else null; } if (busy) accept Release_CS() {busy=0;} controller[(i+1) % n].Token; }} process p[i] { while(1) { controller[i].Request_CS(); CSi; controller[i].Release_CS(); programi; } } Operating Systems 41

Readers/Writers Problem Extension of basic Critical Section problemTwo types of processes entering a CS: Readers (R) and Writers (W)CS may only containA single W process (and no R processes); orAny number of R processes (and no W processes). A good solution should:Satisfy the mutual exclusion conditionsMaximize number of simultaneous R processes in CSPrevent starvation of either process type Operating Systems 42

Readers/Writers Problem Two possible approaches:R has priority over W: when at least one R is in CS, new R’s may enter when W exits, R’s have priority W has priority over R: when a W is waiting, no new R processes may enter when last R exits, W enters when W exits, W’s have priorityBoth approaches satisfy mutual exclusion and simultaneous R access, butBoth also lead to starvation of W or R Operating Systems 43

44 Operating Systems 44 Readers/Writers Problem Solution that prevents starvation of either R or W: R’s are in CS : a new R cannot enter if a W is waiting t he arrival of W stops the stream of R’s when last R exits, W enters W’s cannot starve W is in CS : w hen W leaves, all R’s that have arrived up to that point may enter (even those that arrived after the next W!) R’s cannot starve

Solution using monitor monitor Readers_Writers { int readCount=0,writing=0; condition OK_R, OK_W; start_read() { if (writing || !empty(OK_W)) OK_R.wait; readCount = readCount + 1; OK_R.signal ; } end_read () { readCount = readCount - 1; if ( readCount == 0) OK_W.signal ; } start_write () { if (( readCount !=0)||writing) OK_W.wait ; writing = 1; } end_write () { writing = 0; if (!empty(OK_R)) OK_R.signal ; else OK_W.signal ; } } Operating Systems 45

Dining philosophers Problem Each philosopher alternates between eating and thinkingEach philosopher needs both forks to eatRequirementsPrevent deadlockGuarantee fairness: no philosopher must starveGuarantee concurrency:non-neighbors may eat at the same time Operating Systems 46

Dining philosophers problem Basic structure for each philosopher p(i) : while (1) { think(i); grab_forks(i); eat(i); return_forks(i); }Each fork is a semaphore; grab=P(f[i]), return=V(f[i])Assume each philosopher grabs (and returns) left fork first grab_forks(i): { P(f[i]); P(f[i+1]) } return_forks(i): { V(f[i]); V(f[i+1]) } Problem: May lead to deadlock a ll grab left fork simultaneously, wait for right fork Operating Systems 47

Dining Philosophers Solutions to avoid deadlockUse a counter:At most n–1 philosophers may attempt to grab forksOne philosopher requests forks in reverse order, e.g., grab_forks(1): { P(f [2]); P(f [1]) }Both violate concurrency requirement: While P(1) is eating others could be blocked in a chain Operating Systems 48

CompSci 143A 49 49 Dining Philosophers Solution that avoids deadlock and provides concurrency: Divide philosophers into two groups One group tries to grab left fork first, the other right fork For example: Odd-numbered philosophers (1,3,5) grab left fork first Even-numbered philosophers (2,4) grab right fork first Pairs of neighbors compete with each other, no chain

Elevator Algorithm Loosely simulates an elevator (used for disk scheduling)Organization of elevatorn floorsElevator can be called to floor i: request(i)After elevator services a floor, it is released: released()Elevator scheduling policy When elevator is moving up, it services all requests at or above current position; then it reverses directionWhen elevator is moving down, it services all requests at or below current position; then it reverses direction Operating Systems 50

Elevator algorithm Implementation as a monitorTwo procedures: request(i) and release()When elevator is busy (moving or servicing a floor), request must wait in one of two queues: upsweep or downsweep Elevator services upsweep when moving up and downsweep when moving downRequest must place itself in correct queue:If current position < destination, wait in upsweepIf current position > destination wait in downsweepIf current position = destination wait in upsweep or downsweep depending on current direction Operating Systems 51

Elevator algorithm Monitor elevator { int dir=1, pos=1, busy=0; cond upsweep, downsweep; request(int dest) { if (busy) { if (pos < dest) || ( ( pos == dest ) && ( dir == up) ) ) upsweep.wait ( dest ); else downsweep.wait (- dest );} busy = 1; pos = dest ; } Operating Systems 52 release() { busy = 0; if ( dir ==up) if (!empty(upsweep)) upsweep.signal ; else { dir = down; downsweep.signal ; } else /* dir ==down*/ if (!empty( downsweep )) downsweep.signal ; else { dir = up; upsweep.signal ; } } }

Logical Clocks Many applications need to time-stamp events for debugging, recovery, distributed mutual exclusion, ordering of broadcast messages, transactions, etc.In a centralized system, can attach a clock value: C(e1) < C(e2) means e1 happened before e2Physical clocks in distributed systems are skewed. This can cause anomalies… Operating Systems 53

Skewed Physical Clocks Based on times, the log shows an impossible sequence:e3, e1, e2, e4Message arrived before it was sent!!Possible sequences: e1, e3, e2, e4 or e1, e2, e3, e4 Operating Systems 54 Figure 3-7

Logical Clocks Solution: time-stamp events using counters as logical clocks:Within a process p, increment counter for each new event: Lp(ei+1) = Lp(ei) + 1Label each send event with new clock value: Lp(es) = Lp(ei) + 1Label each receive event with new clock value based on maximum of local clock value and label of corresponding send event: Lq(er) = max( Lp(es), Lq(ei ) ) + 1 Operating Systems 55

Logical Clocks Logical Clocks yield a distributed happened-before relation:ei ek holds ifei and ek belong to the same process and ei happened before ek , or ei is a send and ek is the corresponding receive Operating Systems 56

Logical Clocks Operating Systems 57 Figure 3-8 L p1 (u)=4 L p2 (v)= max (4,1)+1=5 L p3 (x)= max (6,12)+1=13 L p2 (y)= max (7,14)+1=15

HistoryOriginally developed by Steve FranklinModified by Michael Dillencourt, Summer, 2007Modified by Michael Dillencourt, Spring, 2009Modified by Michael Dillencourt, Winter, 2010 Operating Systems 58