Sequential and Concurrent events Sequential Totally ordered in
- Slides: 15
Sequential and Concurrent events Sequential = Totally ordered in time. Total ordering is feasible in a single process that has only one clock. This is not true in a distributed system. Two issues are important here: ¨ How to synchronize physical clocks ? (We already discussed this) ¨ Can we define sequential and concurrent events without using physical clocks, since physical clocks cannot be perfectly synchronized?
Causality helps identify sequential and concurrent events without using physical clocks. Joke � Re: joke (� implies causally ordered before or happened before) Message sent � message received Local ordering: a � b� c (based on the local clock)
Defining causal relationship Rule 1. If a, b are two events in a single process P, and the time of a is less than the time of b then a �b. Rule 2. If a = sending a message, and b = receipt of that message, then a �b. Rule 3. a �b b �c a �c
Example of causality a �d since (a �b b �c c �d) e �d since (e �f f �d) (Note that �defines a PARTIAL order). Is g�f or f�g? NO. They are concurrent. . Concurrency = absence of causal order
Logical clocks LC is a counter. Its value respects causal ordering as follows a �b LC(a) < LC(b) Note that LC(a) < LC(b) does NOT imply a �b. Each process maintains its logical clock as follows: LC 1. Each time a local event takes place, increment LC. LC 2. Append the value of LC to outgoing messages. LC 3. When receiving a message, set LC to 1 + max (local LC, message LC)
Total order in a distributed system Total order is important for some applications like scheduling (firstcome first served). But total order does not exist! What can we do? Strengthen the causal order �to define a total order (<<) among events. Use LC to define total order (in case two LC’s are equal, process id’s will be used to break the tie). Let a, b be events in processes i and j respectively. Then a << b iff -- LC(a) < LC(b) OR -- LC(a) = LC(b) and i < j a � b a << b, but the converse is not true. The value of LC of an event is called its timestamp.
Vector clock Causality detection can be an important issue in applications like group communication. Logical clocks do not detect causal ordering. Vector clocks do. a �b VC(a) < VC(b) C may receive Re: joke before joke, which is bad!
Implementing VC {Sender process i} jth component of VC 1. Increment VC[i]. 2. Append the local VC to every outgoing message. {Receiver process j} 3. When a message with a vector timestamp T arrives from i, first increment the jth component VC[j] of the local vector clock, and then update the local vector clock as follows: k: 0 ≤ k ≤N-1: : VC[k] : = max (T[k], VC[k]).
Vector clocks Example Let a, b be two events. Define. VC(a) < VC(b) iff i : 0 ≤ i ≤ N-1 : VC(a)[i] ≤ VC(b)[i], and j : 0 ≤ j ≤ N-1 : VC(a)[j] < VC(b)[j], VC(a) < VC(b) a �b Causality detection [3, 3, 4, 5, 3, 2, 1, 4] < [3, 3, 4, 5, 3, 2, 2, 5] But, [3, 3, 4, 5, 3, 2, 1, 4] and [3, 3, 4, 5, 3, 2, 2, 3] are not comparable
Mutual Exclusion p 0 CS p 1 CS p 2 CS p 3 CS
Why mutual exclusion? Some applications are: 1. Resource sharing 2. Avoiding concurrent update on shared data 3. Controlling the grain of atomicity 4. Medium Access Control in Ethernet 5. Collision avoidance in wireless broadcasts
Specifications ME 1. At most one process in the CS. (Safety property) ME 2. No deadlock. (Safety property) ME 3. Every process trying to enter its CS must eventually succeed. This is called progress. (Liveness property) Progress is quantified by the criterion of bounded waiting. It measures a form of fairness by answering the question: Between two consecutive CS trips by one process, how many times other processes can enter the CS? There are many solutions, both on the shared memory model and the message-passing model
Message passing solution: Centralized decision making server busy: boolean queue req reply clients release Client do true send request; wait until a reply is received; enter critical section (CS) send release; <non-CS activities> od Server do request received and not busy send reply; bus request received and busy enqueue sender release received and queue is empty busy: = fal release received and queue not empty send rep to the head of the queue od
Comments - Centralized solution is simple. - But the server is a single point of failure. This is BAD. - ME 1 -ME 3 is satisfied, but FIFO fairness is not guaranteed. Why? Can we do better? Yes!
Decentralized solution 1: Lamport’s algorithm {Life of each process} 1. Broadcast a timestamped request to all. 2. Request received enqueue sender in local Q; . Not in CS send ack In CS postpone sending ack (until exit from CS). 3. Enter CS, when (i) You are at the head of your own local Q (ii) You have received ack from all processes 4. To exit from the CS, (i) Delete the request from Q, and (ii) Broadcast a timestamped release 5. Release received remove sender from local Q. Completely connected topo Can you show that it satisfies all the properties (i. e. ME 1, ME 2, ME 3) of a correct solution?
- Order of events
- Combinational logic vs sequential logic
- Concurrent events definition
- Concurrent events examples
- Mutually exclusive events vs not mutually exclusive events
- Totally derma
- What is a tessellation?
- Cardiovascular/lymphatic system it's totally tubular
- Materials that block the light
- Totally responsible person
- Awareness requires totally focusing attention on the task.
- Totally derma collagen powder
- Give the domain
- Domain and range ordered pairs
- How to find the domain
- Python unordered pair