Department of Computer Science and

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

TOPIC: COORDINATION ALGORITHMS

 MUTUAL EXCLUSION: RICART & AGRAWALA

The same as Lamport except that acknowledgments are not sent

Return a response to a request only when:
• The receiving process has no interest in the shared resource; or
• The receiving process is waiting for the resource, but has lower
priority (known through comparison of timestamps).
In all other cases, reply is deferred, implying some more local
administration.

A distributed algorithm
 Mutual exclusion: Ricart & Agrawala
Example with three processes

(a) (b) (c)

(a) Two processes want to access a shared resource at the same moment.
(b) P0 has the lowest timestamp, so it wins.
(c) When process P0 is done, it sends an OK also, so P2 can now go ahead.

A distributed algorithm
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
 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 is

• f coordinators reset ⇒ correctness is violated when there is only a

minority of nonfaulty coordinators: when N − (m − f ) ≥ m, or, f ≥ 2m
−N.
• The probability of a violation is ∑m P[k ].
k =2m−N

A decentralized algorithm
 Decentralized mutual exclusion
Violation probabilities for various parameter
values
N m p Violation N m p Violation
8 5 3 sec/hour < 10−5 8 5 30 sec/hour < 10−3
8 6 3 sec/hour 8 6 30 sec/hour < 10−7
16 9 3 sec/hour < 10−4 16 9 30 sec/hour < 10−2
16 12 3 sec/hour 16 12 30 sec/hour
32 17 3 sec/hour < 10−4 32 17 30 sec/hour < 10−2
32 24 3 sec/hour 32 24 30 sec/hour

So....
What can we conclude?

A decentralized algorithm
 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