Distributed Mutual Exclusion

Slides:



Advertisements
Similar presentations
UNIT-II Distributed Synchronization
Advertisements

Dr. Kalpakis CMSC 621, Advanced Operating Systems. Distributed Mutual Exclusion.
CS542 Topics in Distributed Systems Diganta Goswami.
Suzuki Kasami Example. Consider 5 Sites S1 S2 S4 S3 S5 n=1 n=2 n=5 n=4 n=
Ricart and Agrawala’s Algorithm
Token-Dased DMX Algorithms n LeLann’s token ring n Suzuki-Kasami’s broadcast n Raymond’s tree.
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
What we will cover…  Distributed Coordination 1-1.
20101 Synchronization in distributed systems A collection of independent computers that appears to its users as a single coherent system.
Operating Systems, 2011, Danny Hendler & Amnon Meisels 1 Distributed Mutual Exclusion  Introduction  Ricart and Agrawala's algorithm  Raymond's algorithm.
1 Distributed Process Management: Distributed Global States and Distributed Mutual Exclusion.
Dr. Kalpakis CMSC 621, Advanced Operating Systems. Fall 2003 URL: Distributed Mutual Exclusion.
Distributed Mutex EE324 Lecture 11.
Distributed Mutual Exclusion
Performance of Token- based Distributed Mutual Exclusion Algorithms Scott J. McCallen Kent State University November
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.
CSC Distributed Mutual Exclusion Presenter: Weiling Li Instructor: Dr. Zhang.
MUTUAL EXCLUSION AND QUORUMS CS Distributed Mutual Exclusion Given a set of processes and a single resource, develop a protocol to ensure exclusive.
Chapter 2/6 –Critical Section Problem / Mutual exclusion progress, bounded wait –Hardware Solution disable interrupts –problems ? –Software Solution busy.
D ISTRIBUTED S YSTEM M UTUAL E XCLUSION UNIT-3. D ISTRIBUTED M UTUAL E XCLUSION  Concurrent access to a shared resource (critical region) by several.
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.
Vector Clock Each process maintains an array of clocks –vc.j.k denotes the knowledge that j has about the clock of k –vc.j.j, thus, denotes the clock of.
Studying Different Problems from Distributed Computing Several of these problems are motivated by trying to use solutiions used in `centralized computing’
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Mutual Exclusion & Leader Election Steve Ko Computer Sciences and Engineering University.
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.
Synchronization: Distributed Mutual Exclusion (Week:6)
A Tree Based Algorithm fro Distributed Mutual Exclusion Addy Gronquist 11/19/2003.
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.
Mutual Exclusion Algorithms. Topics r Defining mutual exclusion r A centralized approach r A distributed approach r An approach assuming an organization.
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:
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
4.5 Distributed Mutual Exclusion
Mutual Exclusion A condition in which there is a set of processes, only one of which is able to access a given resource or perform a given function at.
Chapter 18 Distributed Control Algorithms
Mutual Exclusion Continued
Distributed Mutex EE324 Lecture 11.
Comparison between Suzuki Kasami’s and Raymond’s Tree Algorithm
Distributed Mutual Exclusion
Distributed Mutual Exclusion
Decentralized solution 1
Raymond Exclusive Algorithm
Mutual Exclusion Problem Specifications
Logical Clocks and Casual Ordering
ITEC452 Distributed Computing Lecture 7 Mutual Exclusion
Outline Distributed Mutual Exclusion Introduction Performance measures
Mutual Exclusion CS p0 CS p1 p2 CS CS p3.
Non-Distributed Excercises
CSE 486/586 Distributed Systems Mutual Exclusion
Synchronization (2) – Mutual Exclusion
Distributed Mutual Exclusion
Distributed Systems and Concurrency: Synchronization in Distributed Systems Majeed Kassis.
Distributed Mutual eXclusion
Advanced Operating System Maekawa vs. Ricart-Agrawala By Rizal M Nor
CSE 486/586 Distributed Systems Mutual Exclusion
Presentation transcript:

Distributed Mutual Exclusion CS60002: Distributed Systems Pallab Dasgupta Professor, Dept. of Computer Sc. & Engg., Indian Institute of Technology Kharagpur INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Mutual Exclusion Very well-understood in shared memory systems Requirements: at most one process in critical section (safety) if more than one requesting process, someone enters (liveness) a requesting process enters within a finite time (no starvation) requests are granted in order (fairness) INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Types of Dist. Mutual Exclusion Algorithms Non-token based / Permission based Permission from all processes: e.g. Lamport, Ricart-Agarwala, Raicourol-Carvalho etc. Permission from a subset: ex. Maekawa Token based ex. Suzuki-Kasami INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Some Complexity Measures No. of messages/critical section entry Synchronization delay Response time Throughput INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Lamport’s Algorithm Every node i has a request queue qi keeps requests sorted by logical timestamps (total ordering enforced by including process id in the timestamps) To request critical section: send timestamped REQUEST(tsi, i) to all other nodes put (tsi, i) in its own queue On receiving a request (tsi, i): send timestamped REPLY to the requesting node i put request (tsi, i) in the queue INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Lamport’s Algorithm contd.. To enter critical section: Process i enters critical section if: (tsi, i) is at the top if its own queue, and Process i has received a message (any message) with timestamp larger than (tsi, i) from ALL other nodes. To release critical section: Process i removes its request from its own queue and sends a timestamped RELEASE message to all other nodes On receiving a RELEASE message from i, i’s request is removed from the local request queue INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Some notable points Purpose of REPLY messages from node i to j is to ensure that j knows of all requests of i prior to sending the REPLY (and therefore, possibly any request of i with timestamp lower than j’s request) Requires FIFO channels. 3(n – 1 ) messages per critical section invocation Synchronization delay = max mesg transmission time Requests are granted in order of increasing timestamps INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

The Ricart-Agrawala Algorithm Improvement over Lamport’s Main Idea: node j need not send a REPLY to node i if j has a request with timestamp lower than the request of i (since i cannot enter before j anyway in this case) Does not require FIFO 2(n – 1) messages per critical section invocation Synchronization delay = max. message transmission time Requests granted in order of increasing timestamps INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

The Ricart-Agrawala Algorithm To request critical section: send timestamped REQUEST message (tsi, i) On receiving request (tsi, i) at j: send REPLY to i if j is neither requesting nor executing critical section or if j is requesting and i’s request timestamp is smaller than j’s request timestamp. Otherwise, defer the request. To enter critical section: i enters critical section on receiving REPLY from all nodes To release critical section: send REPLY to all deferred requests INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Roucairol-Carvalho Algorithm Improvement over Ricart-Agarwala Main idea Once i has received a REPLY from j, it does not need to send a REQUEST to j again unless it sends a REPLY to j (in response to a REQUEST from j) Message complexity varies between 0 and 2(n – 1) depending on the request pattern worst case message complexity still the same INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Maekawa’s Algorithm Permission obtained from only a subset of other processes, called the Request Set (or Quorum) Separate Request Set, Ri, for each process i Requirements: for all i, j: Ri ∩ Rj ≠ Φ for all i: i Є Ri for all i: |Ri| = K, for some K any node i is contained in exactly D Request Sets, for some D for Maekawa’s INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

A Simple Version To request critical section: i sends REQUEST message to all process in Ri On receiving a REQUEST message: Send a REPLY message if no REPLY message has been sent since the last RELEASE message is received. Update status to indicate that a REPLY has been sent. Otherwise, queue up the REQUEST To enter critical section: i enters critical section after receiving REPLY from all nodes in Ri INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

A Simple Version contd.. To release critical section: Send RELEASE message to all nodes in Ri On receiving a RELEASE message, send REPLY to next node in queue and delete the node from the queue. If queue is empty, update status to indicate no REPLY message has been sent. INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Features Message Complexity: Synchronization delay = 2*(max message transmission time) Major problem: DEADLOCK possible Need three more types of messages (FAILED, INQUIRE, YIELD) to handle deadlock. Message complexity can be 5*sqrt(N) Building the request sets? INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Token based Algorithms Single token circulates, enter CS when token is present Mutual exclusion obvious Algorithms differ in how to find and get the token Uses sequence numbers rather than timestamps to differentiate between old and current requests INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Suzuki Kasami Algorithm Broadcast a request for the token Process with the token sends it to the requestor if it does not need it Issues: Current versus outdated requests Determining sites with pending requests Deciding which site to give the token to INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Suzuki Kasami Algorithm The token: Queue (FIFO) Q of requesting processes LN[1..n] : sequence number of request that j executed most recently The request message: REQUEST(i, k): request message from node i for its kth critical section execution Other data structures RNi[1..n] for each node i, where RNi[ j ] is the largest sequence number received so far by i in a REQUEST message from j. INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Suzuki Kasami Algorithm To request critical section: If i does not have token, increment RNi[ i ] and send REQUEST(i, RNi[ i ]) to all nodes If i has token already, enter critical section if the token is idle (no pending requests), else follow rule to release critical section On receiving REQUEST(i, sn) at j: Set RNj[ i ] = max(RNj[ i ], sn) If j has the token and the token is idle, then send it to i if RNj[ i ] = LN[ i ] + 1. If token is not idle, follow rule to release critical section INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Suzuki Kasami Algorithm To enter critical section: Enter CS if token is present To release critical section: Set LN[ i ] = RNi[ i ] For every node j which is not in Q (in token), add node j to Q if RNi[ j ] = LN[ j ] + 1 If Q is non empty after the above, delete first node from Q and send the token to that node INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Notable features No. of messages: 0 if node holds the token already, n otherwise Synchronization delay: 0 (node has the token) or max. message delay (token is elsewhere) No starvation INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Raymond’s Algorithm Forms a directed tree (logical) with the token-holder as root Each node has variable “Holder” that points to its parent on the path to the root. Root’s Holder variable points to itself Each node i has a FIFO request queue Qi INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Raymond’s Algorithm To request critical section: Send REQUEST to parent on the tree, provided i does not hold the token currently and Qi is empty. Then place request in Qi When a non-root node j receives a request from i place request in Qj send REQUEST to parent if no previous REQUEST sent INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Raymond’s Algorithm When the root receives a REQUEST: send the token to the requesting node set Holder variable to point to that node When a node receives the token: delete first entry from the queue send token to that node if queue is non-empty, send a REQUEST message to the parent (node pointed at by Holder variable) INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Raymond’s Algorithm To execute critical section: enter if token is received and own entry is at the top of the queue; delete the entry from the queue To release critical section if queue is non-empty, delete first entry from the queue, send token to that node and make Holder variable point to that node If queue is still non-empty, send a REQUEST message to the parent (node pointed at by Holder variable) INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR

Notable features Average message complexity: O(log n) Sync. delay = (T log n)/2, where T = max. message delay INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR