Mutual exclusion Ludovic Henrio CNRS - projet SCALE Distributed Algorithms.

Slides:



Advertisements
Similar presentations
Dr. Kalpakis CMSC 621, Advanced Operating Systems. Distributed Mutual Exclusion.
Advertisements

CS542 Topics in Distributed Systems Diganta Goswami.
Token-Dased DMX Algorithms n LeLann’s token ring n Suzuki-Kasami’s broadcast n Raymond’s tree.
Time and Clock Primary standard = rotation of earth De facto primary standard = atomic clock (1 atomic second = 9,192,631,770 orbital transitions of Cesium.
1 Algorithms and protocols for distributed systems We have defined process groups as having peer or hierarchical structure and have seen that a coordinator.
Page 1 Mutual Exclusion* Distributed Systems *referred to slides by Prof. Paul Krzyzanowski at Rutgers University and Prof. Mary Ellen Weisskopf at University.
CS 582 / CMPE 481 Distributed Systems
Computer Science Lecture 12, page 1 CS677: Distributed OS Last Class Distributed Snapshots –Termination detection Election algorithms –Bully –Ring.
CS603 Process Synchronization February 11, Synchronization: Basics Problem: Shared Resources –Generally data –But could be others Approaches: –Model.
20101 Synchronization in distributed systems A collection of independent computers that appears to its users as a single coherent system.
Hwajung Lee. Question 1. Why is physical clock synchronization important? Question 2. With the price of atomic clocks or GPS coming down, should we care.
CS 425 / ECE 428 Distributed Systems Fall 2014 Indranil Gupta (Indy) Lecture 12: Mutual Exclusion All slides © IG.
Distributed Mutual Exclusion Béat Hirsbrunner References G. Coulouris, J. Dollimore and T. Kindberg "Distributed Systems: Concepts and Design", Ed. 4,
1 Distributed Process Management: Distributed Global States and Distributed Mutual Exclusion.
Computer Science Lecture 12, page 1 CS677: Distributed OS Last Class Vector timestamps Global state –Distributed Snapshot Election algorithms.
CIS 720 Distributed algorithms. “Paint on the forehead” problem Each of you can see other’s forehead but not your own. I announce “some of you have paint.
Dr. Kalpakis CMSC 621, Advanced Operating Systems. Fall 2003 URL: Distributed Mutual Exclusion.
Distributed Mutual Exclusion
Distributed Algorithms
1 A Mutual Exclusion Algorithm for Ad Hoc Mobile networks Presentation by Sanjeev Verma For COEN th Nov, 2003 J. E. Walter, J. L. Welch and N. Vaidya.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Mutual Exclusion Steve Ko Computer Sciences and Engineering University at Buffalo.
4.5 DISTRIBUTED MUTUAL EXCLUSION MOSES RENTAPALLI.
4.5 Distributed Mutual Exclusion Ranjitha Shivarudraiah.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Mutual Exclusion Steve Ko Computer Sciences and Engineering University at Buffalo.
Maekawa’s algorithm Divide the set of processes into subsets that satisfy the following two conditions: i  S i  i,j :  i,j  n-1 :: S i  S j.
MUTUAL EXCLUSION AND QUORUMS CS Distributed Mutual Exclusion Given a set of processes and a single resource, develop a protocol to ensure exclusive.
Computer Science Lecture 12, page 1 CS677: Distributed OS Last Class Vector timestamps Global state –Distributed Snapshot Election algorithms –Bully algorithm.
Chapter 2/6 –Critical Section Problem / Mutual exclusion progress, bounded wait –Hardware Solution disable interrupts –problems ? –Software Solution busy.
CS425 /CSE424/ECE428 – Distributed Systems – Fall 2011 Material derived from slides by I. Gupta, M. Harandi, J. Hou, S. Mitra, K. Nahrstedt, N. Vaidya.
Coordination and Agreement. Topics Distributed Mutual Exclusion Leader Election.
Presenter: Long Ma Advisor: Dr. Zhang 4.5 DISTRIBUTED MUTUAL EXCLUSION.
Hwajung Lee. Question 1. Why is physical clock synchronization important? Question 2. With the price of atomic clocks or GPS coming down, should we care.
Studying Different Problems from Distributed Computing Several of these problems are motivated by trying to use solutiions used in `centralized computing’
Lecture 10 – Mutual Exclusion Distributed Systems.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Mutual Exclusion & Leader Election Steve Ko Computer Sciences and Engineering University.
Physical clock synchronization Question 1. Why is physical clock synchronization important? Question 2. With the price of atomic clocks or GPS coming down,
ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.
Hwajung Lee. Mutual Exclusion CS p0 p1 p2 p3 Some applications are:  Resource sharing  Avoiding concurrent update on shared data  Controlling the.
Hwajung Lee. Mutual Exclusion CS p0 p1 p2 p3 Some applications are: 1. Resource sharing 2. Avoiding concurrent update on shared data 3. Controlling the.
Page 1 Mutual Exclusion & Election Algorithms Paul Krzyzanowski Distributed Systems Except as otherwise noted, the content.
Lecture 12-1 Computer Science 425 Distributed Systems CS 425 / CSE 424 / ECE 428 Fall 2012 Indranil Gupta (Indy) October 4, 2012 Lecture 12 Mutual Exclusion.
Lecture 7- 1 CS 425/ECE 428/CSE424 Distributed Systems (Fall 2009) Lecture 7 Distributed Mutual Exclusion Section 12.2 Klara Nahrstedt.
Decentralized solution 1
CIS 825 Review session. P1: Assume that processes are arranged in a ring topology. Consider the following modification of the Lamport’s mutual exclusion.
Distributed Mutual Exclusion Synchronization in Distributed Systems Synchronization in distributed systems are often more difficult compared to synchronization.
Mutual Exclusion Algorithms. Topics r Defining mutual exclusion r A centralized approach r A distributed approach r An approach assuming an organization.
Hwajung Lee. Mutual Exclusion CS p0 p1 p2 p3 Some applications are:  Resource sharing  Avoiding concurrent update on shared data  Controlling the.
Token-passing Algorithms Suzuki-Kasami algorithm The Main idea Completely connected network of processes There is one token in the network. The holder.
CS3771 Today: Distributed Coordination  Previous class: Distributed File Systems Issues: Naming Strategies: Absolute Names, Mount Points (logical connection.
CSC 8420 Advanced Operating Systems Georgia State University Yi Pan Transactions are communications with ACID property: Atomicity: all or nothing Consistency:
Homework-6 Questions : 2,10,15,22.
Revisiting Logical Clocks: Mutual Exclusion Problem statement: Given a set of n processes, and a shared resource, it is required that: –Mutual exclusion.
CS 425 / ECE 428 Distributed Systems Fall 2015 Indranil Gupta (Indy) Oct 1, 2015 Lecture 12: Mutual Exclusion All slides © IG.
Lecture 18: Mutual Exclusion
Exercises for Chapter 11: COORDINATION AND AGREEMENT
Distributed Mutual Exclusion
Distributed Mutual Exclusion
Decentralized solution 1
Mutual Exclusion Problem Specifications
ITEC452 Distributed Computing Lecture 7 Mutual Exclusion
Outline Distributed Mutual Exclusion Introduction Performance measures
Mutual Exclusion CS p0 CS p1 p2 CS CS p3.
CSE 486/586 Distributed Systems Mutual Exclusion
Physical clock synchronization
Synchronization (2) – Mutual Exclusion
ITEC452 Distributed Computing Lecture 7 Mutual Exclusion
Distributed Systems and Concurrency: Synchronization in Distributed Systems Majeed Kassis.
Distributed Mutual eXclusion
CSE 486/586 Distributed Systems Mutual Exclusion
Hwajung Lee ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Sequential and concurrent events. Understanding logical clocks and vector clocks.
Presentation transcript:

Mutual exclusion Ludovic Henrio CNRS - projet SCALE Distributed Algorithms

2 Distributed Algorithms – Mutual Exclusion Distributed Mutual Exclusion 1 – Introduction 2 – Solutions Using Message Passing 3 – Token Passing Algorithms

3 Distributed Algorithms – Mutual Exclusion Why Do We Need Distributed Mutual Exclusion (DME) ? Atomicity exists only up to a certain level: Atomic instructions define the granularity of the computation Types of possible interleaving Assembly Language Instruction? Remote Procedure Call? Weak memory model? Some applications are: Resource sharing Avoiding concurrent update on shared data Controlling the grain of atomicity Medium Access Control in Ethernet 1- Introduction

4 Distributed Algorithms – Mutual Exclusion Why Do We Need Distributed Mutual Exclusion (DME) ? Example: Bank Account Operations 1- Introduction shared n : integer Process P Account receives amount nP Computation: n = n +nP: P1. Load Reg_P, n P2. Add Reg_P, nP P3. Store Reg_P, n Process Q Account receives amount nQ Computation: n = n +nQ: Q1. Load Reg_Q, n Q2. Add Reg_Q, nQ Q3. Store Reg_Q, n

5 Distributed Algorithms – Mutual Exclusion Why Do We Need DME? (example cont'd) 1- Introduction Possible Interleaves of Executions of P and Q: 2 give the expected result n= n + nP + nQ P1, P2, P3, Q1, Q2, Q3 Q1, Q2, Q3, P1, P2, P3 5 give erroneous result n = n+nQ P1, Q1, P2, Q2, P3, Q3 P1, P2, Q1, Q2, P3, Q3 P1, Q1, Q2, P2, P3, Q3 Q1, P1, Q2, P2, P3, Q3 Q1, Q2, P1, P2, P3, Q3 5 give erroneous result n = n + nP Q1, P1, Q2, P2, Q3, P3 Q1, Q2, P1, P2, Q3, P3 Q1, P1, P2, Q2, Q3, P3 P1, Q1, P2, Q2, Q3, P3 P1, P2, Q1, Q2, Q3, P3

6 Distributed Algorithms – Mutual Exclusion Principle of the Mutual Exclusion Problem (2) Each process, before entering the CS acquires the authorizatino to do so. Critical section should eventually terminate 1- Introduction Enter CS Exit CS Acquire authorisation Enter CS Exit CS Acquire authorisation req=[1,1,1,0,0] CS p1 p2 p3

7 Distributed Algorithms – Mutual Exclusion Mutual exclusion in the shared memory model – a solution for 2 processes Warm up exercise (not easy): check Knuth’s algo

8 Distributed Algorithms – Mutual Exclusion Beware weak memory models

9 Distributed Algorithms – Mutual Exclusion CorrectnessConditions... ME1 : Mutual Exclusion At most one process can remain in CS at any time Safety property ME2 : Freedom from deadlock At least one process is eligible to enter CS Liveness property ME3 : Fairness Every process trying to enter must eventually succeed Absence of starvation A measure of fairness: bounded waiting Specifies an upper bound on the number of times a process waits for its turn to enter SC -> n-fairness (n is the MAXIMUM number of rounds) FIFO fairness when n=0 2- Solutions using Message Passing

10 Distributed Algorithms – Mutual Exclusion Distributed Mutual Exclusion 1 – Introduction 2 – Solutions using Message Passing 3 – Token Passing Algorithms Two kinds of algorithms: logical clock based and token based.

11 Distributed Algorithms – Mutual Exclusion Problem formulation Assumptions n processes (n>1), numbered 0... n-1, noted Pi communicating by sending / receiving messages topology: completely connected graph each Pi periodically wants: 1. enter the Critical Section (CS) 2. execute the CS code 3. eventually exit the CS code Devise a protocol that satisfies: ME1 : Mutual Exclusion ME2 : Freedom from deadlock ME3 : Progress (of each process) → Fairness 2- Solutions using Message Passing

12 Distributed Algorithms – Mutual Exclusion Centralized solution Use a coordinator process External process One of the Pi-s Queue requests and authorize one by one Problems: Major: Single point of failure, contention Minor: Unable to achieve FIFO fairness (except if CO) Example: 2- Solutions using Message Passing i j coord request CS message request CS How to anticipate this late arrival? 342 clients busy: boolean server queue req reply release 1 What if a timestamp is given when sending the CS request? req=[1,2]

13 Distributed Algorithms – Mutual Exclusion Lamport's Solution Assumptions: Each communication channel is FIFO Each process maintains a request queue Q Algorithm described by 5 rules LA1. To request entry, send a time-stamped message to every other process and enqueue to local Q (of sender) LA2. Upon reception place request in Q and send time-stamped ACK but once out of CS (possibly immediately if already out) LA3. Enter CS when: 1. request first in Q (chronological order) 2. AND all ACK received from others LA4. To exit CS, a process must: 1. delete request from Q 2. send time-stamped release message to others LA5. When receiving a release msg, remove request from Q 2- Solutions using Message Passing Run an example with 3 processes and different interleavings

14 Distributed Algorithms – Mutual Exclusion Analysis of Lamport's Solution 2- Solutions using Message Passing WHY?

15 Distributed Algorithms – Mutual Exclusion Analysis of Lamport's Solution (2) 2- Solutions Using Message Passing WHY? ALWAYS? What is causal ordering?

16 Distributed Algorithms – Mutual Exclusion Analysis of Lamport's Solution (3) Proof of FIFO fairness. timestamp (j) < timestamp (k)  j enters its CS before k does so Suppose not. So, k enters its CS before j. So k did not receive j’s request. But k received the ack from j for its own req. This is impossible if the channels are FIFO. Message complexity = 3(N-1) (per trip to CS) (N-1 requests + N-1 ack + N-1 release) k j Req (20 ) ack Req (30)

17 Distributed Algorithms – Mutual Exclusion Ricart & Agrawala’s Solution 2- Solutions Using Message Passing What is new? 1. Broadcast a timestamped request to all. 2. Upon receiving a request, send ack if -You do not want to enter your CS, or -You are trying to enter your CS, but your timestamp is higher than that of the sender. (If you are already in CS, then buffer the request) 3. Enter CS, when you receive ack from all. 4. Upon exit from CS, send ack to each pending request before making a new request. (No release message is necessary) Run an example with 3 processes and different interleavings

18 Distributed Algorithms – Mutual Exclusion Analysis of Ricart & Agrawala’s Solution 2- Solutions Using Message Passing k j Req(j) Ack(j) Req(k)

19 Distributed Algorithms – Mutual Exclusion Exercise A Generalized version of the mutual exclusion problem in which up to L processes (L  1) are allowed to be in their critical sections simultaneously is known as the L- exclusion problem. Precisely, if fewer than L processes are in the CS at any time and one more process wants to enter it, it must be allowed to do so. Modify R.-A. algorithm to solve the L-exclusion problem.

20 Distributed Algorithms – Mutual Exclusion Distributed Mutual Exclusion 1 – Introduction 2 – Solutions Using Message Passing 3 – Token Passing Algorithms

21 Distributed Algorithms – Mutual Exclusion Token Ring Approach P0 P1 P2 P3 PN-1 Previous holder of token next holder of token current holder of token

22 Distributed Algorithms – Mutual Exclusion The basic ring approach

23 Distributed Algorithms – Mutual Exclusion Suzuki-Kasami Solution 3- Tokens passing algorithms A mix of the lamport queue and the token approach Completely connected network of processes There is one token in the network. The holder of the token has the permission to enter CS. Any other process trying to enter CS must acquire that token. Thus the token will move from one process to another based on demand. I want to enter CS

24 Distributed Algorithms – Mutual Exclusion Suzuki-Kasami Algorithm 3- Tokens passing algorithms Process i broadcasts (i, num) Each process maintains -an array req : req[j] denotes the sequence nb of the latest request from process j (Some requests will be stale soon) Additionally, the holder of the token maintains - an array last: last[j] denotes the sequence number of the latest visit to CS for process j. - a queue Q of waiting processes req: array[0..n-1] of integer last: array [0..n-1] of integer Sequence number of the request req last queue Q

25 Distributed Algorithms – Mutual Exclusion Suzuki-Kasami Algorithm (2) 3- Tokens passing algorithms When a process i receives a request (k, num) from process k, it sets req[k] to max(req[k], num). The holder of the token --Completes its CS --Sets last[i]:= its own num --Updates Q by retaining each process k only if 1+ last[k] = req[k] ( This guarantees the freshness of the request) --Sends the token to the head of Q, along with the array last and the tail of Q In fact, token  (Q, last) Req: array[0..n-1] of integer Last: Array [0..n-1] of integer Qu: why???

26 Distributed Algorithms – Mutual Exclusion Suzuki-Kasami Algorithm (3) 3- Tokens passing algorithms {Program of process j} Initially,  i: req[i] = last[i] = 0 * Entry protocol * req[j] := req[j] + 1 Send (j, req[j]) to all Wait until token (Q, last) arrives Critical Section * Exit protocol * last[j] := req[j]  k ≠ j: k  Q  req[k] = last[k] + 1  append k to Q; if Q is not empty  send (tail-of-Q, last) to head-of-Q fi * Upon receiving a request (k, num) * req[k] := max(req[k], num)

27 Distributed Algorithms – Mutual Exclusion Example of Suzuki-Kasami Algorithm Execution 3- Tokens passing algorithms req=[1,0,0,0,0] last=[0,0,0,0,0] req=[1,0,0,0,0] initial state: process 0 has sent a request to all, and grabbed the token

28 Distributed Algorithms – Mutual Exclusion Example of Suzuki-Kasami Algorithm Execution 3- Tokens passing algorithms req=[1,1,1,0,0] last=[0,0,0,0,0] req=[1,1,1,0,0] 1 & 2 send requests to enter CS

29 Distributed Algorithms – Mutual Exclusion Example of Suzuki-Kasami Algorithm Execution 3- Tokens passing algorithms req=[1,1,1,0,0] last=[1,0,0,0,0] Q=(1,2) req=[1,1,1,0,0] 0 prepares to exit CS

30 Distributed Algorithms – Mutual Exclusion Example of Suzuki-Kasami Algorithm Execution 3- Tokens passing algorithms req=[1,1,1,0,0] last=[1,0,0,0,0] Q=(2) req=[1,1,1,0,0] 0 passes token (Q and last) to 1

31 Distributed Algorithms – Mutual Exclusion Example of Suzuki-Kasami Algorithm Execution 3- Tokens passing algorithms req=[2,1,1,1,0] last=[1,0,0,0,0] Q=(2,0,3) req=[2,1,1,1,0] 0 and 3 send requests

32 Distributed Algorithms – Mutual Exclusion Example of Suzuki-Kasami Algorithm Execution 3- Tokens passing algorithms req=[2,1,1,1,0] last=[1,1,0,0,0] Q=(0,3) req=[2,1,1,1,0] 1 sends token to 2

33 Distributed Algorithms – Mutual Exclusion Summary and advantages WHY?

34 Distributed Algorithms – Mutual Exclusion Back to message passing: Maekawa’s Solution First solution with a sublinear O(sqrt N) message complexity. “Close to” Ricart-Agrawala’s solution, but each process is required to obtain permission from only a subset of peers In this course: a quick overview of the basic algorithm

35 Distributed Algorithms – Mutual Exclusion Maekawa’s Algorithm 2- Solutions Using Message Passing With each process i, associate a subset S i.Divide the set of processes into subsets that satisfy the following two conditions: i  S i  i,j :  i,j  n-1 :: S i  S j ≠  Main idea. Each process i is required to receive permission from S i only. Correctness requires that multiple processes will never receive permission from all members of their respective subsets. 0,1,21,3,5 2,4,5 S0S0 S1S1 S2S2

36 Distributed Algorithms – Mutual Exclusion Maekawa’s Algorithm (example cont'd) 2- Solutions Using Message Passing Behaviour of process i 1. Send timestamped request to each process in S i. 2. Request received  send ack to process with the lowest timestamp. Thereafter, "lock" (i.e. commit) yourself to that process, and keep others waiting. 3. Enter CS if you receive an ack from each member in S i. 4. To exit CS, send release to every process in S i. 5. Release received  unlock yourself. Then send ack to the next process with the lowest timestamp. S 0 ={0, 1, 2} S 1 ={1, 3, 5} S 2 ={2, 4, 5} S 3 ={0, 3, 4} S 4 ={1, 4, 6} S 5 ={0, 5, 6} S 6 ={2, 3, 6} Example. Let there be seven processes 0, 1, 2, 3, 4, 5, 6

37 Distributed Algorithms – Mutual Exclusion Analysis of Maekawa’s Algorithm (version 1) 2- Solutions Using Message Passing ME1. At most one process can enter its critical section at any time. Let i and j attempt to enter their Critical Sections S i  S j ≠0  there is a process k  S i  S j Process k will never send ack to both. So it will act as the arbitrator and establishes ME1 S 0 ={0, 1, 2} S 1 ={1, 3, 5} S 2 ={2, 4, 5} S 3 ={0, 3, 4} S 4 ={1, 4, 6} S 5 ={0, 5, 6} S 6 ={2, 3, 6}

38 Distributed Algorithms – Mutual Exclusion Analysis of Maekawa’s Algorithm (version 1) 2- Solutions Using Message Passing ME2. No deadlock. Unfortunately deadlock is possible! Assume 0, 1, 2 want to enter their critical sections. From S 0 = {0,1,2}, 0,2 send ack to 0, but 1 sends ack to 1 ; From S 1 = {1,3,5}, 1,3 send ack to 1, but 5 sends ack to 2 ; From S 2 = {2,4,5}, 4,5 send ack to 2, but 2 sends ack to 0 ; Now, 0 waits for 1 (to send a release), 1 waits for 2 (to send a release),, and 2 waits for 0 (to send a release),. So deadlock is possible! S 0 ={0, 1, 2} S 1 ={1, 3, 5} S 2 ={2, 4, 5} S 3 ={0, 3, 4} S 4 ={1, 4, 6} S 5 ={0, 5, 6} S 6 ={2, 3, 6}

39 Distributed Algorithms – Mutual Exclusion Problem: Potential of Deadlock  Without the loss of generality, assume that three sites S i, S j and S k simultaneously invoke Mutual Exclusion, and suppose: R i  R j = {S u } R j  R k = {S v } R k  R i = {S w }  Solution: extra msg’s to detect deadlock, maximum number of msg’s = 5(sqtr(n) + 1). NOT PRESENTED HERE SiSi SwSw SkSk SvSv SjSj SuSu Ack W W W

40 Distributed Algorithms – Mutual Exclusion Exercise: Dekker’s algorithm

41 Distributed Algorithms – Mutual Exclusion

42 Distributed Algorithms – Mutual Exclusion Fault tolerance

43 Distributed Algorithms – Mutual Exclusion A trivial solution: centralized solution Trivial solution consists in having one centralised server distributing authorisations Defaults: Centralized server Faults, contention req=[1,1,1,0,0] Server Acquire authorisation

44 Distributed Algorithms – Mutual Exclusion Maekawa’s Algorithm, avoiding deadlocks 2- Solutions Using Message Passing Avoiding deadlock If processes always receive messages in increasing order of timestamp, then deadlock “could be” avoided. But this is too strong an assumption. Another more complex version exists that should ensure absence of deadlocks (not presented here) S 0 ={0, 1, 2} S 1 ={1, 3, 5} S 2 ={2, 4, 5} S 3 ={0, 3, 4} S 4 ={1, 4, 6} S 5 ={0, 5, 6} S 6 ={2, 3, 6}

45 Distributed Algorithms – Mutual Exclusion Small question/exercise

46 Distributed Algorithms – Mutual Exclusion How to Measure Performance  Number of msg’s per CR invocation.  Fairness measure (previous slide)  Synchronization Delay (SD).  Response Time (RT).  System Throughput (ST):  ST = 1/(SD + E)  where E is the average CR execution time. last req exits CRnext req enters CR SD enters CR exits CR CR req E RT Used here

47 Distributed Algorithms – Mutual Exclusion Last words before getting to the algorithms …