Asynchronous Message Passing

Slides:



Advertisements
Similar presentations
Deadlock Prevention, Avoidance, and Detection
Advertisements

CAS3SH3 Midterm Review. The midterm 50 min, Friday, Feb 27 th Materials through CPU scheduling closed book, closed note Types of questions: True & False,
Deadlock Prevention, Avoidance, and Detection.  The Deadlock problem The Deadlock problem  Conditions for deadlocks Conditions for deadlocks  Graph-theoretic.
Token-Dased DMX Algorithms n LeLann’s token ring n Suzuki-Kasami’s broadcast n Raymond’s tree.
Section 3. True/False Changing the order of semaphores’ operations in a program does not matter. False.
Leader Election Let G = (V,E) define the network topology. Each process i has a variable L(i) that defines the leader.  i,j  V  i,j are non-faulty.
CIS 725 Guarded Command Notation. Programming language style notation Guarded actions en(a)  a en(a): guard of the action boolean condition or boolean.
Dining Philosophers (Diners) Problem n definition n Chandy and Misra solution n extension to drinking philosophers.
Enforcing Mutual Exclusion Message Passing. Peterson’s Algorithm for Processes P0 and P1 void P0() { while( true ) { flag[ 0 ] = false; /* remainder */
CS 582 / CMPE 481 Distributed Systems
Ordering and Consistent Cuts Presented By Biswanath Panda.
Concurrency: Deadlock and Starvation Chapter 6. Revision Describe three necessary conditions for deadlock Which condition is the result of the three necessary.
CS603 Process Synchronization February 11, Synchronization: Basics Problem: Shared Resources –Generally data –But could be others Approaches: –Model.
Synchronization in Distributed Systems. Mutual Exclusion To read or update shared data, a process should enter a critical region to ensure mutual exclusion.
Distributed Mutual Exclusion Béat Hirsbrunner References G. Coulouris, J. Dollimore and T. Kindberg "Distributed Systems: Concepts and Design", Ed. 4,
Distributed Mutual Exclusion
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Mutual Exclusion Steve Ko Computer Sciences and Engineering University at Buffalo.
Probabilistic Methods in Concurrency Lecture 4 Problems in distributed systems for which only randomized solutions exist Catuscia Palamidessi
© 2004, D. J. Foreman 1 High Level Synchronization and Inter-Process Communication.
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.
The Complexity of Distributed Algorithms. Common measures Space complexity How much space is needed per process to run an algorithm? (measured in terms.
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.
CIS Operating Systems Deadlock Professor Qiang Zeng Fall 2015.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Mutual Exclusion & Leader Election Steve Ko Computer Sciences and Engineering University.
Hwajung Lee. Why do we need these? Don’t we already know a lot about programming? Well, you need to capture the notions of atomicity, non-determinism,
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.
CIS 720 Asynchronous Message Passing. Asynchronous message passing Send is non-blocking Modeling a channel c: 1.Two variables: sent c, recv c 2.Queue.
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.
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.
CIS 725 Lecture 2. Finite State Machine Model FSM = (A, S, T, s 0 ) A = set of actions S = set of states s 0 = initial states T = transition relation.
CIS 720 Asynchronous Message Passing. Dining philosophers problem P 0 : do hungry acquire left and right fork eat release forks sleep od.
1 Chapter 11 Global Properties (Distributed Termination)
CIS 825 Review session. P1: Assume that processes are arranged in a ring topology. Consider the following modification of the Lamport’s mutual exclusion.
© 2004, D. J. Foreman 1 Monitors and Inter-Process Communication.
CSC 8420 Advanced Operating Systems Georgia State University Yi Pan Transactions are communications with ACID property: Atomicity: all or nothing Consistency:
Informationsteknologi Monday, October 1, 2007Computer Systems/Operating Systems - Class 111 Today’s class Deadlock.
Interprocess Communication Race Conditions
Model and complexity Many measures Space complexity Time complexity
Deadlock Detection & recovery
Operating systems Deadlocks.
Dining Philosophers (Diners) Problem
Mutual Exclusion Continued
Distributed Mutual Exclusion
Leader Election (if we ignore the failure detection part)
Chapter 7 Deadlock.
Comparison between Suzuki Kasami’s and Raymond’s Tree Algorithm
If statement.
Distributed Mutual Exclusion
Operating systems Deadlocks.
ITEC452 Distributed Computing Lecture 7 Mutual Exclusion
Outline Distributed Mutual Exclusion Introduction Performance measures
Mutual Exclusion CS p0 CS p1 p2 CS CS p3.
CIS 720 Message Passing.
Semaphores Chapter 6.
CSE 486/586 Distributed Systems Mutual Exclusion
Distributed Systems CS
CIS 720 Message Passing.
CIS 720 Message Passing.
Lecture 11: Coordination and Agreement
Asynchronous Message Passing
Distributed algorithms
Asynchronous Message Passing
Distributed Systems and Concurrency: Synchronization in Distributed Systems Majeed Kassis.
Distributed Mutual eXclusion
CSE 486/586 Distributed Systems Mutual Exclusion
CSE 486/586 Distributed Systems Leader Election
Presentation transcript:

Asynchronous Message Passing CIS 720 Asynchronous Message Passing

Asynchronous message passing Send is non-blocking Modeling a channel c: Two variables: sentc, recvc Queue

Example P1: P2: y = 2; send(y,ch2); receive(y,ch1) x = 0; send(x,ch1); receive(x,ch2); P2: y = 2; send(y,ch2); receive(y,ch1)

Computing the minimum value A: B: C: a=initial value; m = Max; b = …. c = …. B ! a; C !a; A!b; C!b A!c; B!c B ? v; a = min(a,v); : : C ? v; a = min(a,v);

2-process mutual exclusion: Token passing sent = false; user_req = false; req_recd = false; hold = true do !hold /\ user_req /\ !sent  send(req,P1); sent = true; user_req = false; [] receive(req,j) req_recd = true; [] receive(token,x)  hold = true; user_enter = true; [] user_release /\ req_recd  send(token,P1); hold = false req_recd = false; od

Mutual exclusion: Token passing Site i: sent = false; user_req = false; parent = initial_value; in_cs = false; do user_req  if !sent then send(req,parent); sent = true; enqueue <req,i> in Q; user_req = false; [] receive(req,j)  if [] !hold  if !sent then send(req,parent); sent = true; enqueue <req,j> in Q; [] hold && !in_cs  send(token,j); parent = j; hold = false [] hold && in_cs  enqueue <req,j> in Q fi [] receive(token,x)  hold = true; if <req,i> in Q then in_cs = true; else if j in Q then send(token,j); parent = j; hold = false [] user_release  in_cs = false; if j in Q then send(token,j); parent = j od

3 4 1 5 6 2 3 4 1 5 6 2 3 4 1 5 6 2

For each fork, use a request-based token protocol If request is from a higher id process then give up the fork. If request is from lower id process and you are hungry then delay sending the fork.

2 f1 1 f2 f5 3 f3 5 f4 4

1 2 3 4 5 f5 f4 f3 f2 f1 1 2 3 4 5 f5 f4 f3 f2 f1 1 2 3 4 5 f5 f4 f3 f2 f1 Alternative strategy: Give up both forks at once

Drinking Philosophers problem Shared bottles A philosopher may request a subset of bottles

Using dining philosophers… Each edge has a bottle and a fork When a philosopher becomes thirsty, it also becomes hungry Request all neighboring forks When all forks are received, requests the desired bottles As soon as the bottles are received, release all the forks and start drinking

Using sequence numbers Session_numi = current session number High_numi = highest session number received so far

thirstyi  for all bottles b needed, needb = true; session_numi = high_numi + 1 tranquili  for each consumed bottle b, needb = false; if reqb then send b, holdb = false needb /\ ! holdb /\ sentb  send req(b,session_numi, i); sentb = false; receive req(b,x,j)  high_numi = max(x, high_numi); reqb = true; if (! Needb \/ (Thirstyi /\ (session_numi, i) > (x,j)) then send b; holdb = false

Committee Coordination Problem Each committee has a set of members A professor may belong to more than one committee A meeting can be started only if all members are available No two committees with common members may meet simultaneously If all members of a committee are waiting then some committee meeting must eventually take place

Committee = philosopher Two committee share a fork if they have a common member Each professor is initially assigned a fixed number of tokens, equal to the number of committees it belongs to When a professor is willing to attend a committee meeting, it sends a token to the corresponding philosopher. When a philosopher receives a token from every member, it changes status to hungry When it changes status to eating, meeting can be scheduled.