Distributed Computing

(Mutual Exclusion)
Algorithms

Shah Khalid
Shah.khalid{@}seecs.edu.pk
National University of Sciences and Technology (NUST)
Last Session

❏ Sychronization Algorithms

❏ Distributed Indexing and Searching

❏ Solr- how to install and configure

❏ Distributed Information Retrieval

2
Today

❏ Mutule Exclusion - How in CS-OS?

❏ Example- why ME

❏ Performance Metrics
❏ Algorithms

❏ Non-token based approach

❏ Lamport's algorithm, Ricart–Agrawala algorithm etc.

❏ Token based approach

❏ Suzuki-Kasami’s Broadcast Algorithm

3
❏ Quorum based approach
○ Maekawa’s Algorithm
 Mutual Exclusion
❖ Fundamental of distributed systems is concurrency and collaboration
❖ Simultaneous access to same resources
❖ It is the requirement that a process can not enter its critical section while another
concurrent process is currently present or executing in its critical section
❖ i.e. only one process is allowed to execute the CS at any given instance of time.
❖ What is Mutual Exclusion?
❖ When a process is accessing a shared variable, the process is said to be in a CS
(critical section).
❖ No two process can be in the same CS at the same time. This is called mutual
exclusion.

4
 Mutual Exclusion Algorithms
❖ Create an algorithm to allow a process to obtain exclusive access to a resource

❖ Three basic approaches for distributed mutual exclusion:

❖ Non-token based approach
❖ Lamport's algorithm, Ricart–Agrawala algorithm etc.

❖ Token based approach

❖ Suzuki-Kasami’s Broadcast Algorithm

❖ Quorum based approach

❖ Maekawa’s Algorithm
Why Mutual Exclusion in the Cloud

❖ Bank’s servers in the cloud: Two of your customers

make simultaneous deposits of $10,000 into your bank
account
❖ Both read initial of $1000 concurrently from the bank’s
cloud server
❖ Both add $10,000 to this amount
❖ Both write the final amount to the server
❖ What is wrong?

6
 Why Mutual Exclusion
❖ Bank’s servers in the cloud: Two of your customers make
simultaneous deposits of $10,000 into your bank account
❖ Both read initial of $1000 concurrently from the bank’s cloud
server
❖ Both add $10,000 to this amount
❖ Both write the final amount to the server
❖ You lost $10,000!
❖ Need mutually exclusive access to your account entry at the
server
❖ Or mutually exclusive access to executing the code that modifies
the account entry
7
 Problem Statement for Mutual
Exclusion
❖ Critical Section: Piece of code (at all processes) for
which we need to ensure there is at most one process
executing it at any point of time
❖ Each process can call three functions
❖ enter - to enter the critical section
❖ AccessResource - to run the critical section code
❖ exit - to exit the critical section

8
 Bank Example
Same piece of code

❖ Process - I ❖ Process - II
❖ enter(S); ❖ enter(S);
❖ accessResource ❖ accessResource
❖ obtain bank amount ❖ obtain bank amount
❖ add in deposit ❖ add in deposit
❖ update bank amount ❖ update bank amount
❖ accessResource - end ❖ accessResource - end
❖ exit(S) ❖ exit(S)

9
 Processes Sharing An OS:
Semaphores
❖ Semaphore == an integer that can only be accessed via
two special functions
❖ Semaphore S: 1
1. wait(S)
while(1)
if(S > 0)
S- -;
break;
2. Signal(S)

10
Bank Example using Semaphore
Same piece of code
❖ Semaphore S : 1 ❖ Semaphore S : 1
❖ Process - I ❖ Process - II
❖ Wait (S); ❖ Wait (S);
❖ accessResource ❖ accessResource
❖ obtain bank amount ❖ obtain bank amount
❖ add in deposit ❖ add in deposit
❖ update bank amount ❖ update bank amount
❖ accessResource - end ❖ accessResource - end
❖ Signal (S) ❖ Signal (S)
12
 Approaches to solve distributed
mutual exclusion
❖ Distributed systems
❖ Process communicating by exchange messages
❖ Need to guarantee 3 properties
❖ Safety - At any instant, only one process can execute the
critical section.
❖ Liveness - Every request for a CS is granted eventually
❖ Fairness - Each process gets a fair chance to execute the
CS. Fairness property generally means the CS execution
requests are executed in the order of their arrival (time is
determined by a logical clock) in the system
13
 Performance Metrics
❖ The performance is generally measured by the following
four metrics:
❖ Message complexity: The number of messages
required per CS execution by a site.
❖ Synchronization delay: After a site leaves the CS, it is
the time required and before the next site enters the CS
(see Figure 1).
 Performance Metrics
❖ Response time: The time interval a request waits for its
CS execution to be over after its request messages
have been sent out (see Figure 2).

❖ System throughput: The rate at which the system

executes requests for the CS.
❖ system throughput=1/(SD+E )
where SD is the synchronization delay and E is the
average critical section execution time.
 Mutual Exclusion

Centralized Algorithm

16
 Distributed Mutual Exclusion -
System Model

System Model
❖ N sites - S1, S2, ……, SN
❖ Each pair of processes is connected by reliable
channels
❖ Messages are eventually delivered to recipient and in
FIFO order

17
 Central Solution
❖ Elect a central master or leader
Master keeps
❖ A queue of waiting requests from processes who wish to access the CS
❖ A special token which allows its holder to access CS
Actions of any process in group
❖ enter( )
❖ send a request to master
❖ wait for token from master
❖ exit( )
❖ send back token to master

18
Central Solution

19
 Analysis of Central Algorithm
❖ Safety - at most one process in CS
❖ Exactly one token
❖ Liveness - every request for CS granted eventually
❖ With N processes in system, queue has at most N
processes
❖ If each process exits CS eventually and no failure,
liveness guaranteed
❖ FIFO Ordering is guaranteed in order of requests received
at master
20
 Analysis of Central Algorithm
❖ Bandwidth: the total number of messages sent in each
enter and exit operation
❖ 2 messages for entry
❖ 1 message for exit
❖ 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)
❖ 2 messages

21
Advantages of CA
 Shortcomings
❖ Master - single point of failure, bottleneck
❖ Unable to detect dead coordinator

23
 Today…
❖ Last Session:
❖ Mutual Exclusion, properties, performance metrics
❖ Centralized algorithm,
❖ Today’s Session:
❖ Lamport’s algorithm
❖ Ricart Agrawala’s Algorithm
❖ Token –based

❖ Suzuki

❖ and Quorum based algorithm

 Distributed Algorithm

Think about distributed algorithm where every node

take part in decision

25
 Distributed Algorithm
Can we use our total ordering multicast algorithm here

26
What is Lamport’s Algorithm
• is a permission based algorithm
proposed by Lamport as an
illustration of his synchronization
scheme for distributed systems.
• Intended to improve the safety in the
usage of shared resources

• Using mutual exclusion.

Related Terms
• Mutual exclusion
• Types of mutual exclusion algorithm
• Critical Section(C.S.)
• Logical Clock
• timestamp is used to order critical
section requests and to resolve any
conflict between requests.
 Algorithm
• Every site Si keeps a request_queue i,
• contains mutual exclusion requests
ordered by their timestamps
• messages to be delivered in the FIFO
order between every pair of sites
The Algorithm
• Requesting the critical section:
• When a site Si wants to enter the CS, it broadcasts a REQUEST(tsi
, i ) message to all other sites and places the request on request
queuei . ((tsi , i ) denotes the timestamp of the request.)
• When a site Sj receives the REQUEST(tsi , i ) message from site Si
,places site Si ’s request on request queuej and it returns a
timestamped REPLY message to Si .
• Executing the critical section: Site Si enters the CS when the
following two conditions hold:
• 1: Si has received a message with timestamp larger than (tsi , i )
from all other sites.
• 2: Si ’s request is at the top of request queuei .
The Algorithm
• Releasing the critical section:
• Site Si , upon exiting the CS, removes its request from the top of its
request queue and broadcasts a timestamped RELEASE message to all
other sites.
• When a site Sj receives a RELEASE message from site Si , it removes
Si ’s request from its request queue.
When a site removes a request from its request queue, its own request
may come at the top of the queue, enabling it to enter the CS.
 System Models
• Requesting The C.S.

• Executing The C.S.

• Releasing The C.S.`

 Example
• We have S1,S2,S3 as sites
• S1,S2 request for CS
• S2 Being first
 (2,1)
S1

S2
(1,2)

S3

S1,S2 making request for entering CS

 (2,1) (1,2),(2,1)
S1
S2 enters CS

S2
(1,2),(2,1)
(1,2)

S3

(1,2) (1,2),(2,1)

Site S2 enters CS
 (2,1) (1,2),(2,1)
S1
S2 exits CS

S2
(1,2),(2,1)
(1,2)

S3

(1,2) (1,2),(2,1)

Site S2 exitsCS and release message

 (2,1)
(2,1) (1,2),(2,1)
S1
S1enters CS

S2
(1,2),(2,1)
(1,2)

S3

(1,2) (1,2),(2,1) (2,1)

Site S1 entersCS
Performance Analysis
• Total No. of REQUEST (N-1)
• Total No. Of REPLY (N-1)
• Total No. Of RELEASE (N-1)

• Total = 3(N-1)

•Unreliable approach: failure of any one of the

processes will halt the progress of entire system.
Distributed Algorithm -Ricart Agrawala’s Algorithm

❖ To access a shared resource, the process builds a message containing the

name of the resource, its process number and its current logical time
❖ Then it sends the message to all processes (reliably)
❖ Three different cases for the replies:
I) If the receiver already has access to the resource, it simply does not
reply. Instead, it queues the request
II) If the receiver is not accessing the resource and does not want to
access it, it sends back an OK message to the sender
III) If the receiver wants to access the resource as well but has not yet
done so, it compares the timestamp of the incoming message with the
one contained in the message that it has sent everyone. The lowest
one wins. Sends an OK if incoming timestamp is lower
39
 Ricart Agrawala’s Algorithm

❖ Message include <Pi, Ti, R>

❖ Process “i” enter critical section:
❖ Set state to Wanted
❖ Multicast “Request” <Ti, Pi, R> to all processes
❖ Wait until all processes send back “Reply”
❖ Change state to “Held” and enter the CS

40
 Ricart Agrawala’s Algorithm
❖ On receipt of a Request <Tj, Pj> at Pj
❖ If state == Held
❖ Add request to queue
❖ If state == Wanted && (Tj,j) < (Ti,i)
❖ Add request to queue
❖ Else
❖ Send Reply

41
Ricart Agrawala’s Algorithm
Case-I

42
Ricart Agrawala’s Algorithm
Case-I

43
 Ricart Agrawala’s Algorithm
Case-II

44
 Ricart Agrawala’s Algorithm
Case-II

45
 Ricart Agrawala’s Algorithm
Case-II

46
 Ricart Agrawala’s Algorithm
Case-II

47
 Ricart Agrawala’s Algorithm
Case-II

48
Ricart Agrawala’s Algorithm
Case-II

49
 Ricart-Agrawala: Example(2)
Step 1:
S1 (2,1)

S2
(1,2)

S3
Step 2:
S1

S2 enters CS
S2
(2,1)
S3
Ricart-Agrawala: Example…

Step 3:
S1

S1 enters CS
S2
(2,1)
S2 leaves CS
S3
Ricart-Agrawala: Example(3)
Performance
❖ Number of messages required per entry is 2(n-1), more traffic
❖ Unreliable approach: failure of any one of node in the system can halt
the progress of the system. In this situation, the process will starve
forever.
The problem of failure of node can be solved by detecting failure after
some timeout.
❖ Performance bottleneck again like centralized algorithm
❖ Slower

53
Token-based Algorithm

54
 Token-based Algorithm
❖ Completely different approach
❖ In token-based algorithms, a unique token is shared

among the sites. A site is allowed to enter its CS if it

possesses the token.
❖ Token-based algorithms use sequence numbers instead

of timestamps. (Used to distinguish between old and

current requests.)

55
 Token Ring

❖ Only one process has the

token
❖ Starvation cannot occur
❖ Token lost, regenerated must
difficult to detect

56
Token-passing Algorithms
Suzuki-Kasami Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-1 of SK Algorithm
Example-2
Example-2
Example-2
Example-2
Example-2
Example-2
 Analysis of Ring Based Mutual
Exclusion (Performace)

❖ Safety: Exactly one token

❖ Liveness: Token eventually loops around ring and
reaches requesting process
❖ Bandwidth per entry : 1 message by requesting process
but N messages throughout system
❖ 1 message sent per exit()

80
 Analysis of Ring Based Mutual
Exclusion

❖ Synchronization delay between one process exit from

the CS and the next process enter
❖ In case site does not holds the idle token, the maximum
synchronization delay is equal to maximum message
transmission time and a maximum of N message is
required per critical section invocation.

81
 Maekawa’s Algorithm
• Maekawa’s algorithm was the first quorum-based
mutual exclusion algorithm.

• A site does not request permission from all other sites,

but only from a subset of the sites. The request set of
sites are chosen such that ∀i,∀j : 1 ≤ i, j ≤ N :: Ri ∩ Rj !=
Φ.
• A site can send only one REPLY message at a time, i.e., a site
can send a REPLY message only after receiving a RELEASE
message for the previous REPLYmessage.
 A simple protocol works as follows:

• Let ‘a’ is a site in quorum ‘A’. If ‘a’ wants to

invoke mutual exclusion, it requests
permission from all sites in its quorum ‘A’.
• Every site does the same to invoke
mutual exclusion.
• Due to the Intersection Property, quorum ‘A’
contains at least one site that is common to
the quorum of every other site.
• These common sites send permission to only
one site at any time. Thus, mutual exclusionis
guaranteed.
With each process i, associate a R0 R1
subset Ri. Divide the set of
processes into subsets that satisfy
the following two 0,1,2 1,3,5
conditions:
i ∈Ri
∀i,j : 0≤i,j ≤ n-1 |Ri ⋂ Rj ≠ ∅
2,4,5
• Main idea. Each process i is
required to receive permission R2
from Ri only.
Correctness requires that
multiple processes will never
receive permission from all
members of their respective
Maekawa’s algorithm: Example

Example. Let there be seven processes 0, 1, 2,

3, 4, 5, 6
S0 = {0, 1, 2}
S1 = {1, 3, 5}
S2 = {2, 4, 5}
S3 = {0, 3, 4}
S4 = {1, 4, 6}
S5 = {0, 5, 6}
S6 = {2, 3, 6}
 Maekawa’s algorithm: Example
{Life of process i}
1. Send timestamped request to each process in Si. S0 = {0, 1, 2}
2. Request received send reply to process with the
S1 = {1, 3, 5}
lowest timestamp. Thereafter, "lock" (i.e. commit)
S2 = {2, 4, 5}
yourself to that process, and keep others waiting.
S3 = {0, 3, 4}
3. Enter CS if you receive an reply from each member
S4 = {1, 4, 6}
in Si.
S5 = {0, 5, 6}
4. To exit CS, send release to every process in Si.
S6 = {2, 3, 6}
5. Release receivedunlock yourself. Then send
reply to the next process with the lowest
timestamp.
 Maekawa’s algorithm: Example
S0 = {0, 1, 2}
At most one process can enter its critical section at any S1 = {1, 3, 5}
time. S = {2, 4, 5}
2

S3 = {0, 3, 4}
Let i and j attempt to enter their Critical Sections
S4 = {1, 4, 6}
Si ∩ Sj ≠ ∅implies there is a process k ∊Si ⋂Sj
S5 = {0, 5, 6}
Process k will never send reply to both. S6 = {2, 3, 6}
 Algorithm
1. Requesting CS:
– Si sends REQUEST(i) to sites in Ri.
– Sj sends REPLY to Si if Sj has NOT sent a REPLY
message to any site after it received the last
RELEASE message.
• Otherwise, queue up Si’s request.
2. Executing CS: after getting REPLY from all sites in Ri.
3. Releasing CS:
– send RELEASE(i) to all sites in Ri
– Any Sj after receiving RELEASE message,
send REPLY message to the next request in
queue.
– If queue empty, update status indicating receipt of
RELEASE.
Performance
 Next

• Election Algorithms