AIM: To study Implementation of Mutual Exclusion algorithms.

Mutual Exclusion
• A condition in which there is a set of processes, only one of which is
able to access a given resource or perform a given function at any
time

Centralized Systems
Mutual exclusion via:
– Test & set
– Semaphores
– Messages
– Monitors

Distributed Mutual Exclusion

 Assume there is agreement on how a resource is identified

 Pass identifier with requests

 Create an algorithm to allow a process to obtain exclusive access to a
resource
 Centralized Algorithm
 Token Ring Algorithm
 Distributed Algorithm
 Decentralized Algorithm

Centralized algorithm
• Mimic single processor system
• One process elected as coordinator
1. Request resource
2. Wait for response
3. Receive grant
4. Access resource
5. Release resource

Centralized algorithm:
If another process claimed resource:

– Coordinator does not reply until release

– Maintain queue

• Service requests in FIFO order

Benefits
• Fair

– All requests processed in order

• Easy to implement, understand, verify

Problems
• Process cannot distinguish being blocked from a dead coordinator
• Centralized server can be a bottleneck

Token Ring algorithm

Assume known group of processes

– Some ordering can be imposed on group

– Construct logical ring in software

– Process communicates with neighbor

– Initialization

– Process 0 gets token for resource R

– Token circulates around ring

– From Pi to P(i+1)mod N

– When process acquires token

– Checks to see if it needs to enter critical section

– If no, send token to neighbor

– If yes, access resource

– Hold token until done

– Only one process at a time has token

– Mutual exclusion guaranteed

– Order well-defined

– Starvation cannot occur

– If token is lost (e.g. process died)

– It will have to be regenerated

– Does not guarantee FIFO order

Ricart & Agrawala algorithm

• Distributed algorithm using reliable multicast and logical clocks
• Process wants to enter critical section:

– Compose message containing:

• Identifier (machine ID, process ID)

• Name of resource

• Timestamp (totally-ordered Lamport)

– Send request to all processes in group

– Wait until everyone gives permission

– Enter critical section / use resource

• When process receives request:

– If receiver not interested:

• Send OK to sender

– If receiver is in critical section

• Do not reply; add request to queue

– If receiver just sent a request as well:

• Compare timestamps: received & sent messages

• Earliest wins

• If receiver is loser, send OK

• If receiver is winner, do not reply, queue

• When done with critical section

– Send OK to all queued requests

• N points of failure

• A lot of messaging traffic

• Demonstrates that a fully distributed algorithm is possible

 Lamport’s Mutual Exclusion
Each process maintains request queue

– Contains mutual exclusion requests

Requesting critical section:

– Process Pi sends request(i, Ti) to all nodes

– Places request on its own queue

– When a process Pj receives

a request, it returns a timestamped ack

Entering critical section (accessing resource):

– Pi received a message (ack or release) from every other process

with a timestamp larger than Ti

– Pi’s request has the earliest timestamp in its queue

Difference from Ricart-Agrawala:

– Everyone responds … always - no hold-back

– Process decides to go based on whether its request is the earliest in

its queue

Releasing critical section:

– Remove request from its own queue

– Send a timestamped release message

– When a process receives a release message

• Removes request for that process from its queue

• This may cause its own entry have the earliest timestamp in
the queue, enabling it to access the critical section

Decentralized Algorithm
• Based on the Distributed Hash Table (DHT) system structure previously
introduced
 – Peer-to-peer

– Object names are hashed to find the successor node that will store
them

• Here, we assume that n replicas of each object are stored

Characteristics of Decentralized Algorithms

 No machine has complete information about the system state
 Machines make decisions based only on local information
 Failure of one machine does not ruin the algorithm
 Three is no implicit assumption that a global clock exists

Placing the Replicas

• The resource is known by a unique name: rname

– Replicas: rname-0, rname-I, …, rname-(n-1)

– rname-i is stored at succ(rname-i), where names and site names are

hashed as before

– If a process knows the name of the resource it wishes to access, it

also can generate the hash keys that are used to locate all the
replicas

• Every replica has a coordinator that controls access to it (the coordinator

is the node that stores it)

• For a process to use the resource it must receive permission from m > n/2
coordinators

• This guarantees exclusive access as long as a coordinator only grants

access to one process at a time

• The coordinator notifies the requester when it has been denied access as
well as when it is granted

– Requester must “count the votes”, and decide whether or not

overall permission has been granted or denied

• If a process (requester) gets fewer than m votes it will wait for a random
time and then ask again
• If a resource is in high demand, multiple requests will be generated

• It’s possible that processes will wait a long time to get permission

• Deadlock?

• Resource usage drops

• More robust than the central coordinator approach and the distributed
approaches. If one coordinator goes down others are available.

– If a coordinator fails and resets then it will not remember having

granted access to one requestor, and may then give access to
another. According to the authors, it is highly unlikely that this
will lead to a violation of mutual exclusion. (See the text for a
probabilistic argument.)