Department of Computer Science and

Engineering (RA)
COURSE NAME: PARALLEL &DISTRIBUTED COMPUTING
COURSE CODE: 22CS4106 R

TOPIC: COORDINATION ALGORITHMS

CO-4 Session -
21
MUTUAL EXCLUSION

Mutual exclusion is frequently used to secure shared resources inside a distributed system.
It could be important, for example, to guarantee that no other process modifies a shared resource while
another is working on it.

There are three mutual exclusion algorithms in distributed systems are follows:

 Centralized

 Distributed

 Token Ring

• Let us first understand the primitive concept of a centralized algorithm before we dive into the modern
distributed and token ring systems.

2
3
4
Advantages of a centralized mutually exclusive algorithm:
 Simple to carry out. It consists of only three messages associated with each critical region: request, grant and
release.
 The processes do not undergo starvation. Starvation is when a process waits for ever for it’s turn to arrive.
 Using the FIFO (first in first out) order for permission the algorithm remains judicious in its ways by offering a fair
chance it every process.
Disadvantages of a centralized mutually exclusive algorithm:
 The problem of a single coordinator being the only source of management and progress in the system could result
into blockage and a single point of failure.
 The processes that remain blocked cannot determine whether the purpose for blockage is a dead coordinator or an
occupied critical region.
 If it is a large system, it is prone to performance bottlenecks.

5
 With this algorithm, mutual exclusion is guaranteed without deadlock or starvation.
 If the total number of processes is N, then the number of messages that a process needs to send and
receive before it can enter its critical region is 2· (N −1): N−1 request messages to all other processes, and
subsequently N−1 OK messages, one from each other process.
 A critical region is a series of instructions to be executed by a process, which requires mutually exclusive
access.
 Unfortunately, this algorithm has N points of failure. If any process crashes, it will fail to respond to
requests.
 This silence will be interpreted (incorrectly) as denial of permission, thus blocking all subsequent
attempts by all processes to enter any of their respective critical regions.
 The algorithm can be patched up as follows. When a request comes in, the receiver always sends a reply,
either granting or denying permission.
 After a request is denied, the sender should block, waiting for a subsequent OK message.

6
 Another problem with this algorithm is that either a multicast communication primitive
must be used, or each process must maintain the group membership list itself, including
processes entering the group, leaving the group, and crashing.
 The method works best with small groups of processes that never change their group
memberships. Finally, note that all processes are involved in all decisions concerning
accessing the shared resource, which may impose a burden on processes running on
resource-constrained machines.
Various minor improvements are possible to this algorithm.
 For example, getting permission from everyone is overkill. All that is needed is a method
to prevent two processes from accessing the resource at the same time.
 The algorithm can be modified to grant permission when it has collected permission
from a simple majority of the other processes, rather than from all of them

7
8
9
MUTUAL EXCLUSION: TOKEN RING ALGORITHM

Essence
Organize processes in a logical ring, and let a token be passed between
them. The one that holds the token is allowed to enter the critical region (if it
wants to).

An overlay network constructed as a logical ring with a circulating

token

A token-ring algorithm
 When the ring is initialized, process P0 is given a token. The token circulates around the ring. Assuming there are N
processes, the token is passed from process Pk to process P(k+1)modN in point-to-point messages.
 When a process acquires the token from its neighbour, it checks to see if it needs to access the shared resource.
 If so, the process goes ahead, does all the work it needs to, and releases the resources.
 After it has finished, it passes the token along the ring.
 It is not permitted to enter the resource immediately again using the same token.
 If a process is handed the token by its neighbour and is not interested in the resource, it just passes the token along.
 As a consequence, when no processes need the resource, the token just circulates around the ring.
 The correctness of this algorithm is easy to see.
 Only one process has the token at any instant, so only one process can actually get to the resource. Since the token
circulates among the processes in a well-defined order, starvation cannot occur.
 This algorithm has its own problems. If the token is ever lost, for example because its holder crashes or due to a lost
message containing the token, it must be regenerated.

11
 In fact, detecting that it is lost may be difficult, since the amount of time between
successive appearances of the token on the network is unbounded.
 The fact that the token has not been spotted for an hour does not mean that it has
been lost; somebody may still be using it.
 The algorithm also runs into trouble if a process crashes, but recovery is relatively easy.
If we require a process receiving the token to acknowledge receipt, a dead process will
be detected when its neighbour tries to give it the token and fails.
 At that point, the dead process can be removed from the group, and the token holder
can throw the token over the head of the dead process to the next member down the
line, or the one after that, if necessary.

12
 DECENTRALIZED MUTUAL EXCLUSION

Principle
Assume every resource is replicated N times, with each replica having its own
coordinator ⇒ access requires a majority vote from m > N/2 coordinators.
A coordinator always responds immediately to a request.

Assumption
When a coordinator crashes, it will recover quickly, but will have forgotten
about permissions it had granted.

A decentralized algorithm
 DECENTRALIZED MUTUAL EXCLUSION

How robust is this system?

• Let p = ∆ t / T be the probability that a coordinator resets during a time
interval ∆ t , while having a lifetime of T .
• The probability P[k ] that k out of m coordinators reset during the same
interval follows a binomial distribution:

This equation represents the likelihood of k failures occurring out

of m possible
coordinators.

A decentralized algorithm
15
The condition f ≥ 2m - N sets a threshold for when failures become critical. If
the number of failed coordinators reaches this level, the decentralized mutual
exclusion system can no longer guarantee correctness.

16
 Mutual exclusion: comparison

Messages per Delay before entry

Algorithm entry/exit (in message times)
Centralized 3 2
Distributed 2(N − 1) 2(N − 1)
Token ring 1,..., ∞ 0,..., N − 1
Decentralized 2kN +(k − 1)N/2 + N, k = 1, 2,... 2kN +(k − 1)N/2

A decentralized algorithm
 EXAMPLE: ZOOKEEPER

Basics (and keeping it simple)

• Centralized server setup
• All client-server communication is nonblocking: a client immediately gets
a response
• ZooKeeper maintains a tree-based namespace, akin to that of
a filesystem
• Clients can create, delete, or update nodes, as well as check
existence.

Example: Simple locking with ZooKeeper

 ZOOKEEPER RACE CONDITION

Note
ZooKeeper allows a client to be notified when a node, or a branch in the tree, changes. This may easily
lead to race conditions.

Consider a simple locking mechanism

1. A client C1 creates a node /lock .
2. A client C2 wants to acquire the lock but is notified that the associated node already exists.
3. Before C2 subscribes to a notification, C1 releases the lock, i.e., deletes
/lock .
4. Client C2 subscribes to changes to /lock and blocks locally.

Solution
Use version numbers
Example: Simple locking with ZooKeeper
Coordination

ZooKeeper versioning

Notations
• W (n, k )a: request to write a to node n, assuming current version is k
.
• R(n, k ): current version of node n is k .
• R(n): client wants to know the current value of node n
• R(n, k )a: value a from node n is returned with its current version k .

Example: Simple locking with ZooKeeper

 ZOOKEEPER LOCKING PROTOCOL

It is now very simple

1. lock: A client C1 creates a node /lock .
2. lock: A client C2 wants to acquire the lock but is notified that the
associated node already exists ⇒ C2 subscribes to notification
on changes of /lock .
3. unlock: Client C1 deletes node /lock ⇒ all subscribers to changes
are notified.

Example: Simple locking with ZooKeeper

 ELECTION ALGORITHMS

Principle
An algorithm requires that some process acts as a coordinator. The question
is how to select this special process dynamically.

Note
In many systems, the coordinator is chosen manually (e.g., file servers).
This leads to centralized solutions ⇒ single point of failure.

Teasers
1. If a coordinator is chosen dynamically, to what extent can we speak
about a centralized or distributed solution?
2. Is a fully distributed solution, i.e. one without a coordinator, always more
robust than any centralized/coordinated solution?
Basic assumptions

• All processes have unique id’s

• All processes know id’s of all processes in the system (but not if they
are up or down)
• Election means identifying the process with the highest id that is up
 ELECTION BY BULLYING

Principle
Consider N processes {P0 , . . . , PN−1} and let id (Pk ) = k . When a
process Pk notices that the coordinator is no longer responding to requests, it
initiates an election:
1. Pk sends an ELECTION message to all processes with higher
identifiers:
Pk + 1 , Pk + 2 , . . . , PN−1.

2. If no one responds, Pk wins the election and becomes coordinator.

3. If one of the higher-ups answers, it takes over and Pk ’s job is done.

The bully algorithm

 Election by bullying
The bully election algorithm

The bully algorithm

 ELECTION IN A RING

Principle
Process priority is obtained by organizing processes into a (logical) ring. The process with
the highest priority should be elected as coordinator.
• Any process can start an election by sending an election message to its successor. If a
successor is down, the message is passed on to the next successor.
• If a message is passed on, the sender adds itself to the list. When it gets back to the
initiator, everyone had a chance to make its presence known.
• The initiator sends a coordinator message around the ring containing a list of all living
processes. The one with the highest priority is elected as coordinator.

A ring algorithm
Coordination

Election in a ring
Election algorithm using a ring

• The solid line shows the election messages initiated by P6

• The dashed one, the messages by P3

A ring algorithm
EXAMPLE: LEADER ELECTION IN ZOOKEEPER SERVER GRO

Basics
• Each server s in the server group has an identifier id(s)
• Each server has a monotonically increasing counter tx(s) of the latest transaction it handled (i.e.,
series of operations on the namespace).
• When follower s suspects leader crashed, it broadcasts an ELECTION
message, along with the pair (voteID,voteTX ). Initially,
• voteID ← id(s)
• voteTX ← tx(s)
• Each server s maintains two variables:
• leader(s): records the server that s believes may be final leader. Initially, leader(s) ← id(s).
• lastTX(s): what s knows to be the most recent transaction. Initially, lastTX(s) ← tx(s).

Example: Leader election in ZooKeeper

EXAMPLE: LEADER ELECTION IN ZOOKEEPER SERVER GRO

When s∗ receives (voteID,voteTX )

• If lastTX(s∗) < voteTX , then s∗ just received more up-to-date information on the most recent
transaction, and sets
• leader(s∗) ← voteID
• lastTX(s∗) ← voteTX
• If lastTX(s∗) = voteTX and leader(s∗) < voteID, then s∗ knows as much about the most recent
transaction as what it was just sent, but its perspective on which server will be the next leader needs
to be updated:
• leader(s∗) ← voteID

Note
When s∗ believes it should be the leader, it broadcasts ⟨id(s∗), tx(s∗)⟩. Essentially, we’re bullying.

Example: Leader election in ZooKeeper

 THANK YOU

parallel and distributed computing

CREATED BY K. VICTOR BABU