Download Distributed Software Develop - Synchronization - Slides | CS 682 and more Study notes Software Engineering in PDF only on Docsity!
Distributed Software Development
Synchronization
Chris Brooks Department of Computer Science University of San Francisco ?? Department of Computer Science — University of San Francisco – p.1/
Time in Distributed Systems 4-0:
In systems with multiple CPUs, the clocks are unlikely to have the exact same time. Variations in manufacturing cause clock skew. Insight: often, it doesn’t matter exactly what time an operation happens, but what order events occur in. (exception: hard real-time systems) ?? Department of Computer Science — University of San Francisco – p.2/
Logical clocks 4-1:
A logical clock is just a counter(or set of counters) What’s important is that all processes in the system can use it to produce a consistent ordering. This lets all processes in the system construct a global view of the system state. ?? Department of Computer Science — University of San Francisco – p.3/
Global state 4-2:
Many interesting problems in distributed computing can be expressed in terms of determining whether some property is satisfied. p Consensus Deadlock Termination Load balancing Global The general version of this problem is called the Predicate Evaluation Problem ?? Department of Computer Science — University of San Francisco – p.4/
Synchronization 4-3:
For example, to detect deadlock, we construct a wait-for graph. is waiting on a message^ ip if^ jp to^ ip Edge from process
.^ jp from If this graph has a cycle, we have deadlock. How do we do this while the computation is running? We can’t pause the computation and collect all the information in one place.
Distributed Computation 4-4:
We define a distributed computation to consist of a set of .n , ..., p^2 , p^1 p processes Unidirectional channels exist between each process for passing messages. We assume these channels are reliable, but not necessarily FIFO. Messages may arrive out of order. Assume the communication channels are asynchronous No shared clock No bound on message delay
Events and time 4-5:
Most of the time, we don’t necessarily care about the exact time when each event happens. Instead, we care about the order in which events happen on distributed machines. If we do care about time, then the problem becomes one of synchronizing about the global value of a clock. ?? Department of Computer Science — University of San Francisco – p.7/
Distributed Computation 4-6:
, ...^2 i , e^1 ie consists of a series of events^ ip A process There are three types of events: Local events - no communication with other processes Send events Receive events such that , ...^2 i, e^1 ie is a sequence of events local history a order is preserved. ?? Department of Computer Science — University of San Francisco – p.8/
Distributed Computation 4-7:
events is k of a history containing the first initial prefix The ki , ..., e^2 i, e^1 ie^ =^ kih^ denoted: <>=^0 i h of a computation is the union of all Global history The local histories. nh ∪ ... ∪ (^2) h ∪ (^1) h Notice that this doesn’t say anything about order of events between processes. Since an asynchronous system implies that there is no global time frame between events, we need some other way to order events on different processes. ?? Department of Computer Science — University of San Francisco – p.9/
Cause and Effect 4-8:
Cause and effect can be used to produce a partial ordering. Local events are ordered by identifier. Send and receive events are ordered. must occur )^1 m( send ,^2 p to^1 m sends a message^1 p If .)^1 m( receive before Assume that messages are uniquely identified. If two events do not influence each other, even indirectly, we won’t worry about their order. ?? Department of Computer Science — University of San Francisco – p.10/
Happens before 4-9:
. → relation is denoted happens before The Happens before is defined: lie^ →^ kie^ , thenk < l^ and^ li, e^ kie^ If (sequentially ordered events in the same process) je → ie , then)m( receive = je and )m( send = ie If (send must come before receive) ′′e^ →^ e^ , then′′e^ → ′e^ and ′e^ →^ e^ If (transitivity) are ′e and e , then we say thate 6 → ′e and ′e 6 → e If )′e||e concurrent. ( These events are unrelated, and could occur in either order.
Happens before 4-10:
Happens before provides a partial ordering over the global )→ H,( history. We call this a distributed computation. A distributed computation can be represented with a space-time diagram.
Monitoring a distributed 4-17:
computation
(^1) p (^2) p (^3) p 41 e^31 e^21 e^11 e 32 e^22 e^12 e 43 e^33 e^23 e^13 e 51 e Cut req req reply req reply req ?? Department of Computer Science — University of San Francisco – p.19/
Monitoring a distributed 4-18:
computation
after^2 p , 31 e receives the monitor message after^1 p Suppose
. 43 e after^3 p , and 22 e The WFG has edges (1,3), (2,1), (3,2). The system is not really deadlocked, though; the monitor received an inconsistent picture. This is called a ghost deadlock. ’s state reflects receiving a message^3 p Problem: process never sent.^1 p that (according to the monitor) Active monitoring isn’t going to work. ?? Department of Computer Science — University of San Francisco – p.20/
Consistent cuts 4-19:
consistent We need to restrict our monitor to looking at cuts ′e^ and^ e^ A cut is consistent if, for all events C ∈ ′e ⇒ )e → ′e and C ∈ e ( In other words, we retain causal ordering and preserve the ’happens before’ relation. A consistent cut produces a consistent global state. , then′e → e , if′ e, e A consistent run is one such that, for all in the run. ′e appears before e This produces a series of consistent global states. We need an algorithm that produces consistent cuts. ?? Department of Computer Science — University of San Francisco – p.21/
Passive monitor 4-20:
.^0 p Let’s alter our monitor Rather than sending ’inquiry’ messages, it listens. Whenever any other process executes an event, it .^0 p sends a message to would like to reconstruct a consistent run from these^0 p messages. How to prevent out-of-order messages? ?? Department of Computer Science — University of San Francisco – p.22/
Synchronous communication 4-21:
How could we solve this problem with synchronous communication and a global clock? δ Assume FIFO delivery, delays are bounded by )j( deliver → )i( deliver ⇒ )j( send → )i( send Receiver must buffer out-of-order messages. .)e( RC is stamped with the global clock: e Each event as )e( RC , it includese of event^0 p When a process notifies a timestamp. can process all messages with timestamps up^0 p ,t At time in increasing order. δ − t to No earlier message can arrive after this point.
Why does this work? 4-22:
, all messages sentt , at timeδ If we assume a delay of have arrived. δ − t before By processing them in increasing order, causality is preserved. )′e( < RC )e( RC ⇒ ′e → e a global clock!! have But we don’t
Logical clocks 4-23:
). LC Each process maintains a logical clock. ( Maps events to natural numbers. (0,1,2,3,...). In the initial state, all LCs are 0. contains a timestamp indicating the m Each message logical clock of the sending process. After each event, the logical clock for a process is updated as follows: is a local or send event. e if + 1 LC ) =e( LC .)m( receive = e if )) + 1m( LC, T S( max ) =e( LC The LC is updated to be greater than both the previous clock and the timestamp. ?? Department of Computer Science — University of San Francisco – p.25/
Logical clock example 4-24:
(^1) p (^2) p (^3) p 1 1 1 2 4 3 2 4 5 5 6 7 5 7 6 ?? Department of Computer Science — University of San Francisco – p.26/
Logical clocks 4-25:
Notice that logical clock values are increasing with respect to causal precedence. )′e( < LC )e( LC ,′e → e Whenever The monitor can process messages according to their logical clocks to always have a consistent global state. Are we done?
. liveness Not quite: this delivery rule lacks Without a bound on message delay, we can never be sure that we won’t have another message with a lower logical clock. We can’t detect gaps in the clock sequence. Example: we’ll wait forever for the nonexistent .^1 p from^3 e message for ?? Department of Computer Science — University of San Francisco – p.27/
Adding liveness 4-26:
We can get liveness by: Delivering messages in FIFO order, buffering out-of-order messages. Deliver messages in increasing timestamp order. after at least one^ ip from process m Deliver a message message from all other processes having a greater timestamp has been buffered. ?? Department of Computer Science — University of San Francisco – p.28/
Causal delivery 4-27:
Recall that FIFO only refers to messages sent by the same process. is a more general property which says that causal delivery when )^2 m( → )^1 m( deliver , then)^2 m( send → )^1 m( send if
.^2 m and^1 m different processes are sending Logical clocks aren’t enough to give us causal delivery.
Vector clocks 4-28:
Solution: keep a “logical clock” for each process.
. V C these are stored in a vector Assumes number of processes in known and fixed. Update rule: for send and internal. ] + 1i[ V C ] =i)[e( V C for receive; then ))m( V C, T S( max ) =e( V C ] + 1i[ V C ] =i)[e( V C On receive, the vector clock takes the max on a component-by-component basis, then updates the local clock.
