Скачать презентацию Time and Global State Time z Time
82bf750227b84a5f4bfb40598bb42411.ppt
- Количество слайдов: 132
Скачать презентацию Time and Global State Time z Time
Скачать презентацию Time and Global State Time z Time
Time and Global State
Time z Time is an important and interesting issue. y. Time is a quantity often want to measure the happening of a certain event accurately. E. g. ecommerce transaction time at merchant and bank’s computers. y. Algorithms depend upon clock synchronization. E. g. use of timestamps to serialize transactions to maintain data consistency. Order of events required. y. Synchronize local clock with an authoritative, external source of time. Atomic oscillator clock is the most accurate physical clock. International Atomic Time and Coordinated Universal Time.
Figure 11. 1 Skew between computer clocks in a distributed system z Each node maintain a physical clock. However, they tend to drift even after an accurate initial setting. z Skew: the difference between the readings of any two clocks. z Clock drift: the crystal-based clock count time at different rates. Oscillator has different frequency. Drift rate is usually used to measure the change in the offset per unit of time. Ordinary quartz crystal clock, 1 second per 11. 6 days.
Synchronizing Physical Clocks z External synchronization: Ci is synchronized to a common standard. z |S(t) –Ci(t)| <D, for i = 1, 2, …N and for all real time t, namely clock Ci are accurate to within the bound D. S is standard time. z Internal synchronization: Ci is synchronized with one another to a known degree of accuracy. z |Ci(t) – Cj(t)| < D for i, j=1, 2, …N, and for all real time t, namely, clocks Ci agree with each other within the bound D.
Simplest Case of Internal Synchronization z In a synchronous system, bounds exist for clock drift rate, transmission delay and time for computing of each step. z One process sends the time t on it local clock to the other in a message m. The receiver should set its clock to t+Ttrans. It doesn’t matter whether t is accurate or not z Synchronous system: Ttrans could range from min to max. The uncertainty is u=(max-min). If receiver set clock to be t+min or t+max, the skew is as much as u. If receiver set the clock to be t+(min+max)/2, the skew is at most u/2. z Asynchronous system: no upper bound max. only lower bound.
Figure 11. 2 Clock synchronization using a time server mr p mt Time server, S z Cristian’s method: Time server, connected to a device receiving signals from UTC. Upon request, the server S supplies the time t according to its clock. z The algorithm is probabilistic and can achieve synchronization only if the observed round trip time are short compared with required accuracy. z From p’s point of view, the earliest time S could place the time in mt was min after p dispatch mr. The latest was min before mt arrived at p.
Cristian’s method mr p mt Time server, S z The time of S by the time p receives the message mt is in the range of [ t+min, t+Tround –min]. z P can measure the roundtrip time then p should set its time as ( t + Tround/2 ) as a good estimation. z The width of this range is (Tround -2 min). So the accuracy is +-(Tround /2 -min)
Cristian’s algorithm z Suffers from the problem associated with single server that single time server may fail. z Cristian suggested to use a group of synchronized time servers. A client multicast is request to all servers and use only the first reply. z A faulty time server that replies with spurious time values or an imposter time server with incorrect times.
Berkeley Algorithm z Internal synchronization when developed for collections of computers running Berkeley UNIX. z A coordinator is chosen to act as the master. It periodically polls the other computers whose clocks are to be synchronized, called slave. The salves send back their clock values to it. The master estimate their local clock times by observing the round-trip time similar to Cristian’s method. It averages the values obtained including its own. z Instead of sending the updated current time back to other computers, which further introduce uncertainty of message transmission, the master sends the amount by which each individual slave’s clock should adjust. z The master takes a fault-tolerant average, namely a subset of clocks is chosen that do not differ from one another by more than a specified bound. z The algorithm eliminates readings from faulty clocks. Such clocks could have a adverse effect if an ordinary average was taken.
The Network Time Protocol z Cristian’s method and Berkeley algorithm are primarily for Intranets. The Network Time Protocol(NTP) defines a time service to distribute time information over the Internet. y. Clients across the Internet to be synchronized accurately to UTC. Statistical techniques y. Reliable service that can survive lengthy losses of connectivity. Redundant servers and redundant paths between servers. y. Clients resynchronized sufficiently frequently to offset the rates of drift. y. Protection against interference with time services. Authentication technique from claimed trusted sources.
Figure 11. 3 An example synchronization subnet in an NTP implementation 1 2 3 3 Note: Arrows denote synchronization control, numbers denote strata. Hierarchical structure called synchronization subnet • Primary server: connected directly to a time source. • Secondary servers are synchronized with primary server. • Third servers are synchronized with secondary servers. Such subnet can reconfigure as servers become unreachable or failures occur.
The Network Time Protocol Server z NTP servers synchronize in one of three modes: z 1. Multicast mode: for high-speed LAN. One or more servers periodically multicasts the time to servers connected by LAN, which set their times assuming small delay. Achieve low accuracy. z 2. Procedure call: similar to Cristian’s algorithm. One server receives request, replying with its timestamp. Higher accuracy than multicast or multicast is not supported. z 3. Symmetric mode: used by servers that supply time in LAN and by higher level of synchronization subnet. Highest accuracy. A pair of servers operating in symmetric mode exchange messages bearing timing information.
Figure 11. 4 Messages exchanged between a pair of NTP peers Server B Ti-2 m Server A Ti- 3 Ti-1 Time m' Ti Time In all modes, messages are delivered unreliably, using UDP Internet transport protocol. In procedure-call and symmetric mode, processes exchange pairs of messages. Each message bears timestamps of recent message events: the local times when the previous NTP message between the pair was sent and received, and the local time when the current message was transmitted. The recipient of the NTP message notes the local time when it receives the message.
Figure 11. 5 Events occurring at three processes
Logical Time and Logical Clocks z In single process, events are ordered by local physical time. Since we cannot synchronize physical clocks perfectly across a distributed system, we cannot use physical time to find out the order of any arbitrary pair of events. z We will use logical time to order events happened at different nodes. Two simple points: y. If two events occurred at the same process, then they occurred in the order in which pi observes them y. Whenever a message is sent between processes, the event of sending the message occurred before the event of receiving the message.
Happen-before Relation/ Causal Ordering Lamport (1978) called the partial ordering by generalizing these two relationships the happened-before relation.
Figure 11. 6 Lamport timestamps for the events shown in Figure 11. 5
Logical Clocks z Lamport invented a logical clock Li, which is a monotonically increasing software counter, whose value need bear no particular relationship to any physical clock. Each process pi keeps its own logical clock. z LC 1: Li is incremented before each event is issued at process pi: Li = Li +1 z LC 2: a. Pi sends a message m, it piggybacks on m the value t = Li b. On receiving (m, t), a process pj computes Lj=max(Lj, t) and then applies LC 1 before timestamping the event receive(m).
Logical Clock z It can be easily shown that: z If e->e’ then L(e) < L(e’). z However, the converse is not true. If L(e) < L(e’), then we cannot infer that e->e’. E. g b and e z L(b)>L(e) but b||e z How to solve this problem?
Vector Clock z Lamport’s clock: L(e)<L(e’) we cannot conclude that e>e’. z Vector clock to overcome the above problem. z N processes is an array of N integers. Each process keeps its own vector clock Vi, which it uses to timestamp local events. z z VC 1: initially, Vi[j] = 0, for i, j = 1, 2…N VC 2: just before pi timestamps an event, it sets Vi[i] = vi[i]+1 VC 3: pi includes the value t= Vi in every message it sends VC 4: when pi receives a timestamp t in a message, it sets Vi[j]=max(Vi[j], t[j])for j =1, 2…, N. Merge operation.
Figure 11. 7 Vector timestamps for the events shown in Figure 11. 5 z Drawback compared with Lamport time, taking up an amount of storage and message payload proportional to N. z To compare vector timestamps, we need to compare each bit. Concurrent events cannot find a relationship.
Detecting global properties z We want to find out whether a particular property is true of a distributed system as it executes. z We will see three examples: z Distributed garbage collection: if there are no longer any reference to objects anywhere in the distributed system, the memory taken up by the objects should be reclaimed. z Distributed deadlock detection: when each of a collection of processes waits for another process to send it a message, and where there is a cycle in the graph of this “wait-for” relationship. z Distributed termination detection: detect if a distributed algorithm has terminated. It seems that we only need to test whether each process halted. However, it is not true. E. g. two processes and each of which may request values from the other. It can be either in passive or active state. Passive means it is not engaged in any activity but is prepared to respond. Two processes may both in passive states. At the same time, there is a message in on the way from P 2 to P 1, after P 1 receives it, it will become active again. So the algorithm has not terminated.
Figure 11. 8 Detecting global properties
Global States and consistent cuts z It is possible to observe the succession of states of an individual process, but the question of how to ascertain a global state of the system – the state of the collection of processes is much harder. z The essential problem is the absence of global time. If we had perfectly synchronized clocks at which processes would record its state, we can assemble the global state of the system from local states of all processes at the same time. z The question is: can we assemble the global state of the system from local states recorded at different real times? z The answer is “YES”.
Some definitions z A series of events occurs at each process. Each event is either an internal action of the process (variables updates) or it is the sending or receipt of a message over the channel. z is the state of process Pi before kth event occurs, so is the initial state of Pi. z Thus the global state corresponds to initial prefixes of the individual process histories.
Figure 11. 9 Cuts 0 e 1 1 2 e 1 3 e 1 p 1 m 1 p 2 m 2 0 e 2 1 e 2 Inconsistent cut 2 e 2 Physical time Consistent cut z A cut of the system’s execution is a subset of its global history that is a union of prefixes of process histories. z The state of each process is in the state after the last event occurs in its own cut. The set of last events from all processes are called frontier of the cut.
Cuts 0 e 1 1 2 e 1 3 e 1 p 1 m 1 p 2 m 2 0 e 2 1 e 2 Inconsistent cut 2 e 2 Physical time Consistent cut z Inconsistent cut: since P 2 contains receiving of m 1, but at P 1 it does not include sending of that message. This cut shows the an effect without a cause. We will never reach a global state that corresponds to process state at the frontier by actual execution under this cut. z Consistent cut: it includes both the sending and receipt of m 1. It includes the sending but not the receipt of m 2. It is still consistent with actual execution.
Consistent cut z A cut C is consistent if, for each event it contains, it also contains all the events that happened-before that event. z A consistent global state is one that corresponds to a consistent cut. z A run is a total ordering of all the events in a global history that is consistent with each local history’s ordering. z A linearization or consistent run is an ordering of the events in a global history that is consistent with this happened-before relation.
Global state predicate z Global state predicate is a function that maps from the set of global states of processes n the system to true or false. z Stable characteristics associated with object being garbage, deadlocked or terminated: once the system enters a state in which the predicate is True. It remains True in all future states reachable from that state. z Safety (evaluates to deadlocked false for all states reachable from S 0) z Liveness ( evaluate to reaching termination true for some of the states reachable from S 0)
Chandy and Lamport’s ‘snapshot’ algorithm z Chandy and Lamport(1985) describe a “snapshot” algorithm for determining global states of distributed system. z Record a set of process and channel states for a set of processes Pi such that even though the combination of recorded states may never have occurred at the same time, the recorded global state is consistent. z The algorithm records state locally at processes without giving a method for gathering the global state.
Assumption of Snapshot Algorithm 1. Neither channels nor processes fail; communication is reliable so that every message sent is eventually received intact, exactly once; 2. Channel are unidirectional either incoming or outgoing and provide FIFO order message delivery; 3. The graph of processes and channels is strongly connected (there is a path between any two processes). 4. Any process may initiate a global snapshot at any time. 5. The processes may continue their normal execution and send and receive normal massages while the snapshot takes place.
Snapshots Ideas z Each process records its own state and also for each incoming channel a set of messages sent to it. z Allow us to record process states at different times but to account for the differential between process states in terms of message transmitted but not yet received. z If process pi has sent a message m to process pj, but pj has not received it, then we account for m as belong to the state of the channel between them.
Figure 11. 10 Chandy and Lamport’s ‘snapshot’ algorithm Use of special marker message. It has a dual role, as a prompt for the receiver to save its own state if it has not done so; and as a means of determining which messages to include in the channel state. ********************************* Marker receiving rule for process pi On pi’s receipt of a marker message over channel c: if (pi has not yet recorded its state) it records its process state now; records the state of c as the empty set; turns on recording of messages arriving over other incoming channels; else pi records the state of c as the set of messages it has received over c since it saved its state. end if Marker sending rule for process pi After pi has recorded its state, for each outgoing channel c: pi sends one marker message over c (before it sends any other message over c).
Figure 11. 11 Two processes and their initial states Two processes connected by two unidirectional channels, c 1 and c 2. The two processes trade in ‘widgets’. Process p 1 sends orders for widgets over c 2 to p 2, enclosing payment at the rate of $10 per widget. Some time later, process p 2 sends widgets along channel c 1 to p 1. Process p 2 already received an order for five widgets, which it will shortly dispatch to p 1.
Figure 11. 12 The execution of the processes in Figure 11. 11 Final recorded state is: P 1<$1000, 0> P 2<$50, 1995> C 1<five widgets> C 2<> 1. P 1 records its state in S 0. Following the marker sending rule, it will send a marker over c 2 to p 2 before it sends the next order (10, $100). 2. Before p 2 receives the marker, it sends five widgets to p 1 over c 1. 3. Now P 1 receives five widgets and P 2 receives marker. P 2 will record it state S 2 and record c 2 as empty. Following the sending rule, p 2 sends a marker to p 1. 4. P 1 receives the marker, P 1 records the state of c 1 as five widget that it received after it first recorded its state.
Chandy-Lamport Algorithm Proof Theorem: The Chandy-Lamport Algorithm terminates – Proof: • Assumption: a process receiving a marker message will record its state and send marker messages via each outgoing channel in finite period of time. • If there is a communication path from P_i to P_k, then P_k will record its state a finite period of time after P_i • Since the communication graph is strongly connected, all process in the graph will have terminated recording their state and the state of incoming channels a finite time after some process initiated snapshot taking.
Chandy-Lamport Algorithm Proof Theorem: Snapshots taken by the Chandy-Lamport Algorithm correspond to consistent global states Proof: Let e_i and e_k be events at P_i and P_k, and let e_i → e_k. Then, if e_k is in the cut, so is e_i. That means, if e_k occurred before P_k recorded its state, then e_i must have occurred before P_i recorded its state k=i: obvious. k≠i: assume P_i recorded its state before e_i occurred - as k≠i there must be a finite sequence of messages m_1, . . . , m_n that induced e_i → e_k - then, before any of the m_1, . . . , m_n had arrived, a marker must have arrived at P_k , and P_k must have recorded it’s state before e_k occurred, hence a contradiction to the above assumption
Coordination and Agreement
Topics z A set of processes coordinate their actions. How to agree on one or more values z Avoid fixed master-salve relationship to avoid single points of failure for fixed master. z Distributed mutual exclusion for resource sharing z A collection of process share resources, mutual exclusion is needed to prevent interference and ensure consistency. ( critical section) z No shared variables or facilities are provided by single local kernel to solve it. Require a solution that is based solely on message passing. z Important factor to consider while designing algorithm is the failure
Distributed Mutual Exclusion z Application level protocol for executing a critical section y enter() // enter critical section-block if necessary y resrouce. Access() //access shared resoruces y exit() //leave critical section-other processes may enter Essential requirements: x ME 1: (safety) at most one process may execute in the critical section x ME 2: (liveness) Request to enter and exit the critical section eventually succeed. x ME 3(ordering) One request to enter the CS happened-before another, then entry to the CS is granted in that order. ME 2 implies freedom from both deadlock and starvation. Starvation involves fairness condition. The order in which processes enter the critical section. It is not possible to use the request time to order them due to lack of global clock. So usually, we use happen-before ordering to order message requests.
Performance Evaluation z Bandwidth consumption, which is proportional to the number of messages sent in each entry and exit operations. z The client delay incurred by a process at each entry and exit operation. z throughput of the system. Rate at which the collection of processes as a whole can access the critical section. Measure the effect using the synchronization delay between one process exiting the critical section and the next process entering it; the shorter the delay is, the greater the throughput is.
Central Server Algorithm z The simplest way to grant permission to enter the critical section is to employ a server. z A process sends a request message to server and awaits a reply from it. z If a reply constitutes a token signifying the permission to enter the critical section. z If no other process has the token at the time of the request, then the server replied immediately with the token. z If token is currently held by other processes, the server does not reply but queues the request. z Client on exiting the critical section, a message is sent to server, giving it back the token.
Figure 12. 2 Central Server algorithm: managing a mutual exclusion token for a set of processes Queue of requests ME 1: safety ME 2: liveness Are satisfied but not ME 3: ordering Server 4 2 1. Request token p 1 p 2 3. Grant token 2. Release token p 3 p 4 Bandwidth: entering takes two messages( request followed by a grant), delayed by the round-trip time; exiting takes one release message, and does not delay the exiting process. Throughput is measured by synchronization delay, the round-trip of a release message and grant message.
Ring-based Algorithm z Simplest way to arrange mutual exclusion between N processes without requiring an additional process is arrange them in a logical ring. z Each process pi has a communication channel to the next process in the ring, p(i+1)/mod N. z The unique token is in the form of a message passed from process to process in a single direction clockwise. z If a process does not require to enter the CS when it receives the token, then it immediately forwards the token to its neighbor. z A process requires the token waits until it receives it, but retains it. z To exit the critical section, the process sends the token on to its neighbor.
Figure 12. 3 A ring of processes transferring a mutual exclusion token ME 1: safety ME 2: liveness Are satisfied but not ME 3: ordering Bandwidth: continuously consumes the bandwidth except when a process is inside the CS. Exit only requires one message Delay: experienced by process is zero message(just received token) to N messages(just pass the token). Throughput: synchronization delay between one exit and next entry is anywhere from 1(next one) to N (self) message transmission.
Using Multicast and logical clocks z Mutual exclusion between N peer processes based upon multicast. z Processes that require entry to a critical section multicast a request message, and can enter it only when all the other processes have replied to this message. z The condition under which a process replies to a request are designed to ensure ME 1 ME 2 and ME 3 are met. z Each process pi keeps a Lamport clock. Message requesting entry are of the form<T, pi>. z Each process records its state of either RELEASE, WANTED or HELD in a variable state. y If a process requests entry and all other processes is RELEASED, then all processes reply immediately. y If some process is in state HELD, then that process will not reply until it is finished. y If some process is in state WANTED and has a smaller timestamp than the incoming request, it will queue the request until it is finished. y If two or more processes request entry at the same time, then whichever bears the lowest timestamp will be the first to collect N-1 replies.
Figure 12. 4 Ricart and Agrawala’s algorithm On initialization state : = RELEASED; To enter the section state : = WANTED; Multicast request to all processes; request processing deferred here T : = request’s timestamp; Wait until (number of replies received = (N – 1)); state : = HELD; On receipt of a request <Ti, pi> at pj (i ≠ j) if (state = HELD or (state = WANTED and (T, pj) < (Ti, pi))) then queue request from pi without replying; else reply immediately to pi; end if To exit the critical section state : = RELEASED; reply to any queued requests;
Figure 12. 5 Multicast synchronization p 41 p 3 Reply 1 34 Reply 41 34 p 2 Reply z P 1 and P 2 request CS concurrently. The timestamp of P 1 is 41 and for P 2 is 34. When P 3 receives their requests, it replies immediately. When P 2 receives P 1’s request, it finds its own request has the lower timestamp, and so does not reply, holding P 1 request in queue. However, P 1 will reply. P 2 will enter CS. After P 2 finishes, P 2 reply P 1 and P 1 will enter CS. z Granting entry takes 2(N-1) messages, N-1 to multicast request and N-1 replies. Bandwidth consumption is high. z Client delay is again 1 round trip time z Synchronization delay is one message transmission time.
Maekawa’s voting algorithm z It is not necessary for all of its peers to grant access. Only need to obtain permission to enter from subsets of their peers, as long as the subsets used by any two processes overlap. z Think of processes as voting for one another to enter the CS. A candidate process must collect sufficient votes to enter. z Processes in the intersection of two sets of voters ensure the safety property ME 1 by casting their votes for only one candidate.
Maekawa’s voting algorithm z A voting set Vi associated with each process pi. z there is at least one common member of any two voting sets, the size of all voting set are the same size to be fair. z The optimal solution to minimizes K is K~sqrt(N) and M=K.
Figure 12. 6 Maekawa’s algorithm – part 1 On initialization state : = RELEASED; voted : = FA LSE; For pi to enter the critical section state : = WANTED; Multicast request to all processes in Vi; Wait until (number of replies received = K); state : = HELD; On receipt of a request from pi at pj if (state = HELD or voted = TRUE) then queue request from pi without replying; else send reply to pi; voted : = TRUE; end if For pi to exit the critical section state : = RELEASED; Multicast release to all processes in Vi; On receipt of a release from pi at pj if (queue of requests is non-empty) then remove head of queue – from pk, say; send reply to pk; voted : = TRUE; else voted : = FALSE; end if
Maekawa’s algorithm z ME 1 is met. If two processes can enter CS at the same time, the processes in the intersection of two voting sets would have to vote for both. The algorithm will only allow a process to make at most one vote between successive receipts of a release message. z Deadlock prone. For example, p 1, p 2 and p 3 with V 1={p 1, p 2}, V 2={p 2, p 3}, V 3={p 3, p 1}. If three processes concurrently request entry to the CS, then it is possible for p 1 to reply to itself and hold off p 2; for p 2 rely to itself and hold off p 3; for p 3 to reply to itself and hold off p 1. Each process has received one out of two replies, and none can proceed. z If process queues outstanding request in happen-before order, ME 3 can be satisfied and will be deadlock free. z Bandwidth utilization is 2 sqrt(N) messages per entry to CS and sqrt(N) per exit. z Client delay is the same as Ricart and Agrawala’s algorithm, one round-trip time. z Synchronization delay is one round-trip time which is worse than R&A.
Fault tolerance z What happens when messages are lost? z What happens when a process crashes? z None of the algorithm that we have described would tolerate the loss of messages if the channels were unreliable. y The ring-based algorithm cannot tolerate any single process crash failure. y Maekawa’s algirithm can tolerate some process crash failures: if a crashed process is not in a voting set that is required. y The central server algorithm can tolerate the crash failure of a client process that neither holds nor has requested the token. y The Ricart and Agrawala algorithm as we have described it can be adapted to tolerate the crash failure of such a process by taking it to grant all requests implicitly.
Elections z Algorithm to choose a unique process to play a particular role is called an election algorithm. E. g. central server for mutual exclusion, one process will be elected as the server. Everybody must agree. If the server wishes to retire, then another election is required to choose a replacement. z Requirements: y. E 1(safety): a participant pi has Where P is chosen as the non-crashed process at the end of run with the largest identifier. (concurrent elections possible. ) y. E 2(liveness): All processes Pi participate in election process and eventually set
A ring based election algorithm z All processes arranged in a logical ring. z Each process has a communication channel to the next process. z All messages are sent clockwise around the ring. z Assume that no failures occur, and system is asynchronous. z Goal is to elect a single process coordinator which has the largest identifier.
Figure 12. 7 1. A ring-based election in progress 2. 3. 4. 5. 6. 7. 8. Initially, every process is marked as nonparticipant. Any process can begin an election. The starting process marks itself as participant and place its identifier in a message to its neighbour. A process receives a message and compare it with its own. If the arrived identifier is larger, it passes on the message. If arrived identifier is smaller and receiver is not a participant, substitute its own identifier in the message and forward if. It does not forward the message if it is already a participant. On forwarding of any case, the process marks itself as a participant. If the received identifier is that of the receiver itself, then this process’ s identifier must be the greatest, and it becomes the coordinator. The coordinator marks itself as non-participant set elected_i and sends an elected message to its neighbour enclosing its ID. When a process receives elected message, marks itself as a non-participant, sets its variable elected_i and forwards the message.
A ring-based election in progress z z z Note: The election was started by process 17. The highest process identifier encountered so far is 24. Participant processes are shown darkened E 1 is met. All identifiers are compared, since a process must receive its own ID back before sending an elected message. E 2 is also met due to the guaranteed traversals of the ring. Tolerate no failure makes ring algorithm of limited practical use. z z If only a single process starts an election, the worst-performance case is then the anti-clockwise neighbour has the highest identifier. A total of N-1 messages is used to reach this neighbour. Then further N messages are required to announce its election. The elected message is sent N times. Making 3 N-1 messages in all. Turnaround time is also 3 N-1 sequential message transmission time
The bully algorithm z Allows process to crash during an election, although it assumes the message delivery between processes is reliable. z Assume system is synchronous to use timeouts to detect a process failure. z Assume each process knows which processes have higher identifiers and that it can communicate with all such processes. z Three types of messages: y. Election is sent to announce an election message. A process begins an election when it notices, through timeouts, that the coordinator has failed. T=2 Ttrans+Tprocess From the time of sending y. Answer is sent in response to an election message. y. Coordinator is sent to announce the identity of the elected process.
Figure 12. 8 The bully algorithm 1. The process begins a election by sending an election message to these processes that have a higher ID and awaits an answer in response. If none arrives within time T, the process considers itself the coordinator and sends coordinator message to all processes with lower identifiers. Otherwise, it waits a further time T’ for coordinator message to arrive. If none, begins another election. 2. If a process receives a coordinator message, it sets its variable elected_i to be the coordinator ID. 3. If a process receives an election message, it send back an answer message and begins another election unless it has begun one already. E 1 may be broken if timeout is not accurate or replacement. (suppose P 3 crashes and replaced by another process. P 2 set P 3 as coordinator and P 1 set P 2 as coordinator) E 2 is clearly met by the assumption of reliable transmission. The election of coordinator p 2, after the failure of p 4 and then p 3
The bully algorithm z Best case the process with the second highest ID notices the coordinator’s failure. Then it can immediately elect itself and send N-2 coordinator messages. z The bully algorithm requires O(N^2) messages in the worst case - that is, when the process with the least ID first detects the coordinator’s failure. For then N-1 processes altogether begin election, each sending messages to processes with higher ID.
Consensus and Related Problems (agreement) z The problem is for processes to agree on a value after one or more of the processes has proposed what that value should be. (e. g. all controlling computers should agree upon whether let the spaceship proceed or abort after one computer proposes an action. ) z Assumptions: Communication is reliable but the processes may fail (arbitrary process failure as well as crash). Also specify that up to some number f of the N processes are faculty.
Consensus problem z Every process pi begins in the undecided state and propose a single value vi, drawn from a set D. The processes communicate with one another, exchanging values. Each process then sets the value of a decision variable di. In doing so it enters the decided state, in which it may no longer change di. z Requirements: y Termination: Eventually each correct process sets its decision variable. y Agreement: The decision value of all correct processes is the same: if pi and pj are correct and have entered the decided state, then di=dj y Integrity: if the correct processes all proposed the same value, then any correct process in the decided state has chosen that value. This condition can be loosen. For example, not necessarily all of them, may be some of them. It will be straightforward to solve this problem if no process can fail by using multicast and majority vote. Termination guaranteed by reliability of multicast, agreement and integrity guaranteed by the majority definition and each process has the same set of proposed value to evaluate. .
Figure 12. 17 Consensus for three processes
Byzantine general problem ( proposed in 1982) z Three or more generals are to agree to attack or to retreat. One, the commander, issues the order. The others, lieutenants to the commander, are to decide to attack or retreat. z But one or more of the general may be treacherous-that is, faulty. If the commander is treacherous, he proposes attacking to one general and retreating to another. If a lieutenant is treacherous, he tells one of his peers that the commander told him to attack and another that they are to retreat.
Byzantine general problem and Interactive consistency z A. Byzantine general problem is different from consensus in that a distinguished process supplies a value that the others are to agree upon, instead of each of them proposing a value. z Requirements: y Termination: eventually each correct process sets its decision variable. y Agreement: the decision value of all correct processes is the same. y Integrity: If the commander is correct, then all correct processes decide on the value that the commander proposed. If the commander is correct, the integrity implies agreement; but the commander need not be correct. B. Interactive consistency problem : Another variant of consensus, in which every process proposes a single value. Goal of this algorithm is for the correct processes to agree on a decision vector of values, one for each process. Requirements: Termination: eventually each correct process sets it decision variable. Agreement: the decision vector of all correct processes is the same. Integrity: If pi is correct, then all correct processes decide on vi as the ith component of the vector.
Consensus in a synchronous system z Basic multicast protocol assuming up to f of the N processes exhibit crash failures. z Each correct process collects proposed values from the other processes. This algorithm proceeds in f+1 rounds, in each of which the correct processes Basic-multicast the values between themselves. At most f processes may crash, by assumption. At worst, all f crashes during the round, but the algorithm guarantees that at the end of the rounds all the correct processes that have survived have the same final set of values are in a position to agree. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005
Figure 12. 18 Consensus in a synchronous system At most f crashes can occur, and there are f+1 rounds. So we can compensate up to f crashes. Any algorithm to reach consensus despite up to f crash failures requires at least f+1 rounds of message exchanges, no matter how it is constructed. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005
Figure 12. 19 Three byzantine generals p 1 (Commander) 1: v p 2 2: 1: v 3: 1: u Faulty processes are shown coloured 1: x 1: w p 3 p 2 2: 1: w p 3 3: 1: x 3: 1: u: first number indicates source, the second number indicates Who says. From P 3, P 1 says u. If solution exists, P 2 bound to decide on v when commander is correct. If no solution can distinguish between correct and faulty commander, p 2 must also choose the value sent by commander. By Symmetry, P 3 should also choose commander, p 2 does the same thing. But it contradicts with agreement. No solution is N<=3 f. All because that a correct general can not tell which process is faulty. Digital signature can solve this problem.
Figure 12. 20 Four byzantine generals p 1 (Commander) 1: v 2: 1: v p 2 1: v p 1 (Commander) 1: v p 3 3: 1: u 4: 1: v 2: 1: u p 2 1: v 1: w p 3 3: 1: w 4: 1: v 3: 1: w p 4 1: u 4: 1: v 2: 1: u Faulty processes are shown coloured 3: 1: w p 4 First round: the commander sends a value to each of the lieutenants. Second round: each of the lieutenants sends the value it received to its peers. A lieutenant receives a value from the commander, plus N-2 values from its peers. Lieutenant just applies a simple majority function to the set of values it receives. The faulty process may omit to send a value. If timeouts, the receiver just set null as received value.
Transactions and Concurrency Control
Figure 12. 1 Operations of the Account interface deposit(amount) deposit amount in the account withdraw(amount) withdraw amount from the account get. Balance() -> amount return the balance of the account set. Balance(amount) set the balance of the account to amount Operations of the Branch interface create(name) -> account create a new account with a given name look. Up(name) -> account return a reference to the account with the given name branch. Total() -> amount return the total of all the balances at the branch Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 2 A client’s banking transaction T: a. withdraw(100); b. deposit(100); c. withdraw(200); b. deposit(200); Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 3 Operations in Coordinator interface open. Transaction() -> trans; starts a new transaction and delivers a unique TID trans. This identifier will be used in the other operations in the transaction. close. Transaction(trans) -> (commit, abort); ends a transaction: a commit return value indicates that the transaction has committed; an abort return value indicates that it has aborted. abort. Transaction(trans); aborts the transaction. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 4 Transaction life histories Successful open. Transaction operation Aborted by client Aborted by server open. Transaction operation server aborts transaction operation close. Transaction abort. Transaction operation ERROR reported to client Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 5 The lost update problem Transaction. T : Transaction. U: balance = b. get. Balance(); b. set. Balance(balance*1. 1); a. withdraw(balance/10) balance = b. get. Balance(); b. set. Balance(balance*1. 1); c. withdraw(balance/10) balance = b. get. Balance(); $200 b. set. Balance(balance*1. 1); $220 a. withdraw(balance/10) $80 c. withdraw(balance/10) Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 $280
Figure 12. 6 The inconsistent retrievals problem Transaction V: a. withdraw(100) b. deposit(100) a. withdraw(100); Transaction. W: a. Branch. branch. Total() $100 total = a. get. Balance() $100 total = total+b. get. Balance() $300 total = total+c. get. Balance() b. deposit(100) $300 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 7 A serially equivalent interleaving of T and U Transaction. T: balance = b. get. Balance() b. set. Balance(balance*1. 1) a. withdraw(balance/10) Transaction. U: balance = b. get. Balance() b. set. Balance(balance*1. 1) c. withdraw(balance/10) balance = b. get. Balance() $200 b. set. Balance(balance*1. 1) $220 balance = b. get. Balance() $220 b. set. Balance(balance*1. 1) $242 a. withdraw(balance/10) $80 c. withdraw(balance/10) Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 $278
Figure 12. 8 A serially equivalent interleaving of V and W Transaction. V: a. withdraw(100); b. deposit(100) Transaction. W: a. Branch. branch. Total() a. withdraw(100); $100 b. deposit(100) $300 total = a. get. Balance() $100 total = total+b. get. Balance() $400 total = total+c. get. Balance(). . . Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 9 Read and write operation conflict rules Operations of different. Conflict transactions read No read write Yes Reason Because the effect of a pair of read operations does not depend on the order in which they are executed Because the effect of aread and a write operation depends on the order of their execution Because the effect of a pair of write operations depends on the order of their execution Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 10 A non-serially equivalent interleaving of operations of transactions T and U Transaction T: x = read(i) write(i, 10) write(j, 20) Transaction U: y = read(j) write(j, 30) z = read (i) Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 11 A dirty read when transaction T aborts Transaction. T: Transaction. U: a. get. Balance() a. set. Balance(balance + 10) a. get. Balance() a. set. Balance(balance + 20) balance = a. get. Balance() $100 a. set. Balance(balance + 10) $110 balance = a. get. Balance() $110 a. set. Balance(balance + 20) $130 commit transaction abort transaction Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 12 Overwriting uncommitted values Transaction T: Transaction U: a. set. Balance(105) a. set. Balance(110) a. set. Balance(105) $100 $105 a. set. Balance(110) Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 $110
Figure 12. 13 Nested transactions T : top-level transaction T 1 = open. Sub. Transaction T 2 = open. Sub. Transaction T 1 : commit T 2 : open. Sub. Transaction T 11 : T 12 : prov. commit open. Sub. Transaction T 21 : abort open. Sub. Transaction T 211 : prov. commit Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 14 Transactions T and U with exclusive locks Transaction T: balance = b. get. Balance() b. set. Balance(bal*1. 1) a. withdraw(bal/10) Transaction U: Operations Locks balance = b. get. Balance() b. set. Balance(bal*1. 1) c. withdraw(bal/10) Locks open. Transaction bal = b. get. Balance() lock B open. Transaction b. set. Balance(bal*1. 1) a. withdraw(bal/10) lock A close. Transaction bal = b. get. Balance() waits for. T’s lock on. B unlock. A, B lock B b. set. Balance(bal*1. 1) c. withdraw(bal/10) lock C close. Transaction unlock. B, C Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 15 Lock compatibility For one object Lock requested read write Lock already set none OK OK read OK wait write wait Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 16 Use of locks in strict two-phase locking 1. When an operation accesses an object within a transaction: (a) If the object is not already locked, it is locked and the operation proceeds. (b) If the object has a conflicting lock set by another transaction, the transaction must wait until it is unlocked. (c) If the object has a non-conflicting lock set by another transaction, the lock is shared and the operation proceeds. (d) If the object has already been locked in the same transaction, the lock will be promoted if necessary and the operation proceeds. (Where promotion is prevented by a conflicting lock, rule (b) is used. ) 2. When a transaction is committed or aborted, the server unlocks all objects it locked for the transaction. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 17 Lock class public class Lock { private Object object; // the object being protected by the lock private Vector holders; // the TIDs of current holders private Lock. Type lock. Type; // the current type public synchronized void acquire(Trans. ID trans, Lock. Type a. Lock. Type ){ while(/*another transaction holds the lock in conflicing mode*/) { try { wait(); }catch ( Interrupted. Exception e){/*. . . */ } } if(holders. is. Empty()) { // no TIDs hold lock holders. add. Element(trans); lock. Type = a. Lock. Type; } else if(/*another transaction holds the lock, share it*/ ) ){ if(/* this transaction not a holder*/) holders. add. Element(trans); } else if (/* this transaction is a holder but needs a more exclusive lock*/) lock. Type. promote(); } Continues on next } Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 slide
Figure 12. 17 continued public synchronized void release(Trans. ID trans ){ holders. remove. Element(trans); // set locktype to none notify. All(); } } // remove this holder Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 18 Lock. Manager class public class Lock. Manager { private Hashtable the. Locks; public void set. Lock(Object object, Trans. ID trans, Lock. Type lock. Type){ Lock found. Lock; synchronized(this){ // find the lock associated with object // if there isn’t one, create it and add to the hashtable } found. Lock. acquire(trans, lock. Type); } } // synchronize this one because we want to remove all entries public synchronized void un. Lock(Trans. ID trans) { Enumeration e = the. Locks. elements(); while(e. has. More. Elements()){ Lock a. Lock = (Lock)(e. next. Element()); if(/* trans is a holder of this lock*/ ) a. Lock. release(trans); } } Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 19 Deadlock with write locks Transaction. T Operations Locks a. deposit(100); Transaction. U Operations Locks write lock A b. deposit(200) write lock B a. withdraw(200); waits for T’s b. withdraw(100) waits for. U’s lock on B lock on A Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 20 The wait-for graph for Figure 12. 19 Held by Waits for A T U U T Waits for B Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Held by
Figure 12. 21 A cycle in a wait-for graph U T V Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 22 Another wait-for graph V T Held by T C W Held by U Held by W V B U Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Waits for
Figure 12. 23 Resolution of the deadlock in Figure 15. 19 Transaction T Operations Locks a. deposit(100); Transaction U Operations Locks write lock. A b. deposit(200) write lock. B a. withdraw(200); waits for T’s b. withdraw(100) waits for. U’s lock on B (timeout elapses) T’s lock on A becomes vulnerable, unlock. A, abort T lock on A a. withdraw(200); write locks. A unlock A, B Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 24 Lock compatibility (read, write and commit locks) For one object Lock to be set none write OK commit OK read OK OK wait write OK wait commit Lock already set read OK wait Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 25 Lock hierarchy for the banking example Branch A B C Account Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 26 Lock hierarchy for a diary Week Monday Tuesday Wednesday Thursday Friday time slots 9: 00– 10: 00– 11: 00– 12: 00– 13: 00– 14: 00– 15: 00– 16: 00 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 27 Lock compatibility table for hierarchic locks read Lock to be set write I-read I-write none OK OK read OK wait write wait I-read OK wait OK OK I-write wait OK OK For one object Lock already set Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Table on page 498 Serializability of transaction T with respect to transaction Ti Tv Ti Rule write read 1. Ti must not read objects written by. Tv read write 2. Tv must not read objects written by. Ti write 3. Ti must not write objects written byv and T Tv mustnot write objects written byi T Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 28 Validation of transactions Working Validation Update T 1 Earlier committed transactions T 2 T 3 Transaction being validated Tv active Later active transactions 1 active 2 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Page 499 -500 Validation of Transactions Backward validation of transaction Tv boolean valid = true; for (int Ti = start. Tn+1; Ti <= finish. Tn; Ti++){ if (read set of Tv intersects write set of Ti) valid = false; } Forward validation of transaction Tv boolean valid = true; for (int Tid = active 1; Tid <= active. N; Tid++){ if (write set of Tv intersects read set of Tid) valid = false; } Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 29 Operation conflicts for timestamp ordering Rule Tc 1. write Ti read 2. write Tc must not write an object that has been written by any Ti where. Ti >Tc this requires that Tc > write timestamp of the committed object. 3. read write T Tc must not read an object that has been written by any Ti where i >Tc this requires that Tc > write timestamp of the committed object. Tc must not write an object that has been read by any Ti where Ti >Tc this requires that Tc ≥ the maximum read timestamp of the object. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 30 Write operations and timestamps (b) T 3 write (a) T 3 write Before T 2 After T 2 Before T 1 T 3 After T 1 Key: T 2 Committed T 3 write (d) T 3 write Before T 1 T 4 After T 1 T 3 Before Time T 4 After T 4 Ti Time (c) Ti Transaction aborts Tentative object produced by transaction Ti (with write timestamp Ti T 4 Time Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 T 1<T 2<T 3<T 4
Page 503 Timestamp ordering write rule if (Tc ≥ maximum read timestamp on D && Tc > write timestamp on committed version of D) perform write operation on tentative version of D with write timestamp else /* write is too late */ Abort transaction Tc Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Page 504 Timestamp ordering read rule if ( Tc > write timestamp on committed version of D) { let Dselected be the version of D with the maximum write timestamp ≤ Tc if (Dselected is committed) perform read operation on the version Dselected else Wait until the transaction that made version Dselected commits or aborts then reapply the read rule } else Abort transaction Tc Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 31 (a) T 3 read T 2 Key: read proceeds Selected T 2 Time T 2 read proceeds Selected Ti Time Committed Ti (a) T 3 read T 1 T 4 Tentative read waits Selected T 4 Time Transaction aborts object produced by transaction Ti (with write timestamp Ti) T 1 < T 2 < T 3 < T 4 Time Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 12. 32 Timestamps in transactions T and U Timestamps and versions of objects A B C RTS WTS {} S open. Transaction bal = b. get. Balance() b. set. Balance(bal*1. 1) RTS WTS {} S {T} open. Transaction bal = b. get. Balance() wait for T a. withdraw(bal/10) commit bal = b. get. Balance() b. set. Balance(bal*1. 1) c. withdraw(bal/10) S, T T T {U} T, U Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 S, U
Figure 12. 33 Late write operation would invalidate a read T 3 read; T 1 T 3 write; T 2 T 5 read; T 4 write; T 3 T 5 T 3 Time T 1 < T 2 < T 3 < T 4 < T 5 Ti Tk Committed Key: Tentative object produced by transaction Ti (with write timestamp Ti and read timestamp Tk) Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Distributed transactions
Figure 13. 1 Distributed transactions (a) Flat transaction (b) Nested transactions M X T 11 X Client T Y T T 1 N T 12 T T 21 T 2 Client Y Z P T 22 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 2 Nested banking transaction X Client A 1 a. withdraw(10) B T b. withdraw(20) C c. deposit(10) D d. deposit(20) T Y T = open. Transaction open. Sub. Transaction a. withdraw(10); open. Sub. Transaction b. withdraw(20); open. Sub. Transaction c. deposit(10); open. Sub. Transaction d. deposit(20); close. Transaction T 2 Z T T 3 4 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 3 A distributed banking transaction join open. Transaction close. Transaction. participant A a. withdraw(4); join Branch. X T Client T = open. Transaction a. withdraw(4); c. deposit(4); b. withdraw(3); d. deposit(3); close. Transaction participant b. withdraw(T, 3); B join Note: the coordinator is in one of the servers, e. g. Branch. X b. withdraw(3); Branch. Y participant C c. deposit(4); D d. deposit(3); Branch. Z Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 4 Operations for two-phase commit protocol can. Commit? (trans)-> Yes / No Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote. do. Commit(trans) Call from coordinator to participant to tell participant to commit its part of a transaction. do. Abort(trans) Call from coordinator to participant to tell participant to abort its part of a transaction. have. Committed(trans, participant) Call from participant to coordinator to confirm that it has committed the transaction. get. Decision(trans) -> Yes / No Call from participant to coordinator to ask for the decision on a transaction after it has voted Yes but has still had no reply after some delay. Used to recover from server crash or delayed messages. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 5 The two-phase commit protocol Phase 1 (voting phase): 1. The coordinator sends a can. Commit? request to each of the participants in the transaction. 2. When a participant receives a can. Commit? request it replies with its vote (Yes or No) to the coordinator. Before voting Yes, it prepares to commit by saving objects in permanent storage. If the vote is No the participant aborts immediately. Phase 2 (completion according to outcome of vote): 3. The coordinator collects the votes (including its own). (a) If there are no failures and all the votes are Yes the coordinator decides to commit the transaction and sends a do. Commit request to each of the participants. (b) Otherwise the coordinator decides to abort the transaction and sends do. Abort requests to all participants that voted Yes. 4. Participants that voted Yes are waiting for a do. Commit or do. Abort request from the coordinator. When a participant receives one of these messages it acts accordingly and in the case of commit, makes a have. Committed call as confirmation to the coordinator. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 6 Communication in two-phase commit protocol Coordinator Participant step status 1 3 prepared to commit (waiting for votes) committed can. Commit? Yes 2 prepared to commit (uncertain) 4 committed do. Commit have. Committed done Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 7 Operations in coordinator for nested transactions open. Sub. Transaction(trans) -> sub. Trans Opens a new subtransaction whose parent is trans and returns a unique subtransaction identifier. get. Status(trans)-> committed, aborted, provisional Asks the coordinator to report on the status of the transaction trans. Returns values representing one of the following: committed, aborted, provisional. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 8 Transaction T decides whether to commit T abort (at M) 11 T 1 provisional commit (at X) T T provisional commit (at N) T 21 provisional commit (at N) T provisional commit (at P) 12 T 2 aborted (at Y) 22 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 9 Information held by coordinators of nested transactions Coordinator of transaction T T 1 T 2 T 11 T 12, T 21 T 22 Child transactions T 1, T 2 T 11, T 12 T 21, T 22 Participant Provisional commit list T 1, T 12 yes no (aborted) T 12 but not. T 21, T 12 no (parent aborted) 22 T Abort list T 11, T 2 T 11 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 10 can. Commit? for hierarchic two-phase commit protocol can. Commit? (trans, sub. Trans) -> Yes / No Call a coordinator to ask coordinator of child subtransaction whether it can commit a subtransaction sub. Trans. The first argument trans is the transaction identifier of top-level transaction. Participant replies with its vote Yes / No. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 10 can. Commit? for flat two-phase commit protoco can. Commit? (trans, abort. List) -> Yes / No Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote Yes / No. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 12 Interleavings of transactions U, V and W U d. deposit(10) V lock D b. deposit(10) a. deposit(20) W lock A at X lock B at Y c. deposit(30) b. withdraw(30) wait at Y lock C at Z c. withdraw(20) wait at Z a. withdraw(20) wait at X Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 13 Distributed deadlock (a) (b) W Held by D C A X Z Waits for W Waits for V Held by V U Waits for B Held by Y Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 U
Figure 13. 14 Local and global wait-for graphs local wait-for graph T U X local wait-for graph V global deadlock detector T T Y U Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 V
Figure 13. 15 Probes transmitted to detect deadlock W W® U ® V ® W Held by Waits for Deadlock detected C A Z W® U ® V Waits for Initiation W® U V U Held by Y B Waits for Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 X
Figure 13. 16 Two probes initiated Waits for V Waits for T T V U W (c) detection initiated at object requested by W (b) detection initiated at object requested by T (a) initial situation Waits for T ®U T W ®V U T ®U®W®V T®U®W ®T V W ®V U W ®V W ®T®U W Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Waits for
Figure 13. 17 Probes travel downhill . . (a) V stores probe when U starts waiting (b) Probe is forwarded when V starts waiting W U V probe queue U ®V Waits for B W U®V V® W Waits for C U ®V V U®V Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 probe queue U Waits for B
Figure 13. 18 Types of entry in a recovery file Type of entry Description of contents of entry Object A value of an object. Transaction status Transaction identifier, transaction statusprepared, committed ( aborted) and other status values used for the two-phase commit protocol. Intentions list Transaction identifier and a sequence of intentions, each of which consists of <identifier of object>, <position in recovery file of value of object>. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 19 Log for banking service P 0 P 1 P 2 P 3 Object: Object: Trans: A B C A B T 100 200 300 80 220 prepared <A, P 1> <B, P 2> P 0 P 4 Trans: T committed P 5 P 6 Object: C B 278 242 P 3 Checkpoint Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 P 7 Trans: U prepared <C, P 5> <B, P 6> P 4 End of log
Figure 13. 20 Shadow versions Map at start Map when T commits A ®P 0 B ® P 0' C ® P 0" A ®P 1 B ®P 2 C ® P 0" P 0 Version store P 0' P 0" 100 200 300 P 1 80 P 2 P 3 P 4 220 278 242 Checkpoint Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 21 Log with entries relating to two-phase commit protocol Trans: T Coord’r: T prepared part’pant list: . . . intentions list Trans: T Trans: U committed prepared Part’pant: Trans: U U Trans: U Coord’r: . . uncertain committed intention list s Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 22 Recovery of the two-phase commit protocol Role Status Action of recovery manager Coordinator prepared No decision had been reached before the server failed. It sends abort. Transactionto all the servers in the participant list and adds the transaction status aborted in its recovery file. Same action for state aborted. If there is no participant list, the participants will eventually timeout and abort the transaction. Coordinator committed A decision to commit had been reached before the server failed. It sends a do. Committo all the participants in its participant list (in case it had not done so before) and resumes the two-phase protocol at step 4 (Fig 13. 5). Participant committed The participant sends ahave. Committedmessage to the coordinator (in case this was not done before it failed). This will allow the coordinator to discard information about this transaction at the next checkpoint. Participant uncertain The participant failed before it knew the outcome of the transaction. It cannot determine the status of the transaction until the coordinator informs it of the decision. It will send a get. Decision to the coordinator to determine the status of the transaction. When it receives the reply it will commit or abort accordingly. Participant prepared The participant has not yet voted and can abort the transaction. Coordinator done No action is required. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Figure 13. 23 Nested transactions top of stack T 11 T T 1 T 2 A 1 T 12 A 11 A 1 T 1 A 12 A 11 T 11 A 2 A 12 T 12 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 T 2
Скачать презентацию Time and Global State Time z Time
82bf750227b84a5f4bfb40598bb42411.ppt