Ensuring Safe Access to Shared Resources in Distributed Systems, Study notes of Electrical and Electronics Engineering

Download Ensuring Safe Access to Shared Resources in Distributed Systems and more Study notes Electrical and Electronics Engineering in PDF only on Docsity!

Lecture 6

distributed mutual exclusion

distributed systems

CS425 / ECE 428 / CSE 424

sayan mitra

acknowledgment

these slides are based on ideas and material from the following sources:

• slides prepared by professors m. t. harandi and j. hou and subsequently modified by professors indranil gupta, nitin vaidya, and yih-chun hu at university of illinois
• slides from professor s. ghosh’s course at university of iowa

why mutual exclusion?

• bank database: think of two simultaneous

deposits of $10,000 into your bank account from

2 ATMs.

• both ATMs read initial amount of $1000 concurrently

from the bank server

• both ATM add $10,000 to this amount (locally at the

ATM)

• both write the final amount to the server
• what’s wrong?

• ATMs need mutually exclusive access to your

account entry at the server (or, to executing the

code that modifies the account entry)

 critical section problem : piece of code (at all clients) for

which we need to ensure there is at most one client

executing it at any point of time.

 solutions:

 semaphores, mutexes, locks, etc. in local operating systems

 message-passing-based protocols in distributed systems:

 enter() the critical section

 accessresource() in the critical section

 exit() the critical section

 distributed mutual exclusion requirements:

 safety – at most one process may execute in cs at any time

 liveness – every request for a cs is eventually granted

 fairness/ordering (desirable) – requests are granted in

FIFO order

mutual exclusion

refresher - semaphores

• to synchronize access of multiple threads to common

data structures

• semaphore is a protected variable with two operations
• init: semaphore s=1;
• wait(s):

while(true) {if (s > 0) then s := s-1; break} // each execution of loop is atomic

• signal(s):

s++; // atomic operation

refresher - semaphores

• to synchronize access of multiple threads to common

data structures

• semaphore is a protected variable with two operations
• init: semaphore s=1;
• wait(s):

while(true) {if (s > 0) then s := s-1; break} // each execution of loop is atomic

• signal(s):

s++; // atomic operation

enter()

exit()

distributed ME: performance criteria

• bandwidth : the total number of messages sent in each entry and exit operation.
• delay
  • client delay : the delay incurred by a process at each entry and exit operation (when no other process is waiting)
  • synchronization delay : the time interval between one process exiting the critical section and the next process entering it (when there is only one process waiting)
• these translate into throughput -- the rate at which the processes can access the critical section, i.e., x processes per second.

(these definitions more correct than the ones in the textbook)

assumptions

• for all the algorithms studied, we assume

• reliable FIFO channels between every process pair i.e., messages from i are eventually delivered to j’s input buffer in FIFO order
• processes do not fail.

 operations ( token gives access to CS)

 to enter a CS

send a request to the L & wait for token

 on exiting the CS

send a message to L to release the token

 upon receipt of a request

if no other process has the token, L replies with the token; otherwise, L queues the request

 upon receipt of a release message

L removes oldest entry in the queue (if any) replies with token  features:

 safety, liveness, order are guaranteed

 it takes 3 messages per (entry + exit) operation

 client delay: one round trip time (request + grant)

 synchronization delay: one round trip time (release + grant)

 coordinator : performance bottleneck and single point of failure

centralized control of mutual exclusion

 processes are organized in a logical unidirectional ring

pi has a communication channel to p(i+1)mod (n+1).

 operations:

 only the process holding the token can enter the CS

 to enter CS wait for the token

 to exit the CS (or relinquish opportunity) pi sends token to

p(i+1)mod (n+1)

token ring approach

P

P

P P

Pn

Previous holder of token

next holder of token

current holder of token

 features:

 safety & liveness are guaranteed, but ordering is not  bandwidth: 1 message per exit  client delay: 0 to (N+1) message transmissions  synchronization delay between one process’s exit from the CS and the next process’s entry is between 1 and N message transmissions.

Ricart and Agrawala’s algorithm

On initialization status := RELEASED; To enter the section status := WANTED; Multicast request to all processes; T := request’s timestamp; Wait until (number of replies received = (N – 1)); state := HELD;

On receipt of a request <Ti, pi> at pj (i ≠ j) if (status = HELD or (status = WANTED and (T, pj) < (Ti, pi))) then queue request from pi without replying; else reply immediately to pi; end if To exit the critical section state := RELEASED; reply to any queued requests;

request processing deferred here

Ricart and Agrawala’s algorithm

p 3

Reply

p 1

p 2

Reply Reply

timestamp approach: Maekawa’s algorithm

 multicasts messages to a (voting) subset of nodes

 each process pi is associated with a voting set vi (of processes)

 each process i belongs to its own voting set vi

 the intersection of any two voting sets is not empty

 each voting set is of size k

 each process belongs to m other voting sets

 to access at resource , pi requests permission from all other

processes in its own voting set vi

 guarantees safety, not liveness (may deadlock)

 Maekawa showed that k=m=n works best

 one way of doing this is to put nodes in a n by n matrix and

take the union of row & column containing pi as its voting set

Maekawa’s algorithm – part 1

On initialization status := RELEASED; voted := FALSE; For pi to enter the critical section status := WANTED; Multicast request to all processes in Vi – {pi}; Wait until (number of replies received = (K – 1)); state := HELD; On receipt of a request from pi at pj (i ≠ j) if (state = HELD or voted = TRUE) then queue request from pi without replying; else send reply to pi; voted := TRUE; end if