DTU Compute
Department of Applied Mathematics and Computer Science
Coordination and Agreement
Nicola Dragoni
Embedded Systems Engineering
DTU Informatics
1. Introduction
2. Distributed Mutual Exclusion
3. Elections
4. Multicast Communication
5. Consensus and related problems
DTU Compute
Department of Applied Mathematics and Computer Science
AIM: Coordination and/or Agreement
Collection of algorithms whose goals vary but which share an aim that is
fundamental in distributed systems:
for a set of distributed processes
to coordinate their actions
and/or
to agree on one or more values
2
DTU Compute
Department of Applied Mathematics and Computer Science
Failure Assumptions
• Each pair of processes is connected by reliable channels
‣ A reliable channel eventually delivers a message to the recipient’s input
buffer
• No process failure implies a threat to the other processes’ ability to
communicate
‣ None of the processes depends upon another to forward messages
3
DTU Compute
Department of Applied Mathematics and Computer Science
Distributed Mutual Exclusion
Problem and requirements
DTU Compute
Department of Applied Mathematics and Computer Science
Problem: Coordinate Access to Shared Resources
• Distributed processes often need to coordinate their activities
• If a collection of processes share a resource (or collection of resources), then
mutual exclusion is required to prevent interference and ensure
consistency when accessing the resources
• Critical Section (CS) problem in the domain of operating systems:
AT ANY MOMENT,
AT MOST ONE PROCESS CAN STAY IN ITS CS!
5
DTU Compute
Department of Applied Mathematics and Computer Science
Why Is CS More Complex in Distributed Systems?
• In a distributed system, neither
‣ shared variables (semaphores) nor
‣ facilities supplied by a single local kernel
can be used to solve the problem!
• We require a distributed mutual exclusion: one that is based solely on
message passing, in a context of
‣ unpredictable message delays
‣ no complete knowledge of the state of the system
6
DTU Compute
Department of Applied Mathematics and Computer Science
Model (Without Failures)
• We consider a system of N processes pi, i =1,...,N that do not share variables
• The processes access common resources, but they must do so in a critical
section
• The system is asynchronous
• Processes do not fail
• Message delivery is reliable: any message sent is eventually delivered intact,
exactly once
• Client processes are well-behaved and spend a finite time accessing
resources within their CSs
7
DTU Compute
Department of Applied Mathematics and Computer Science
Critical Section (CS)
• The application-level protocol for executing a CS is as follows:
‣ enter(): enter a critical section - block if necessary
‣ resourceAccess(): access shared resources in critical section
‣ exit(): leave critical section - other processes may now enter
8
DTU Compute
Department of Applied Mathematics and Computer Science
Requirements for ME
• A mutual exclusion algorithm should satisfy the following properties:
‣ [ME1] Safety: at most one process can execute in the CS at a time
‣ [ME2] Liveness: requests to enter and exit the CS eventually succeed
‣ [ME3] Ordering: if one request to enter the CS happened-before another,
then entry to the CS is granted in that order
• Safety is absolutely necessary (CORRECTNESS property)
• The other two properties are considered important in ME algorithms
9
DTU Compute
Department of Applied Mathematics and Computer Science
On ME Requirements: Liveness
• [ME2] Liveness: requests to enter and exit the CS eventually succeed
Implies freedom from both deadlock and starvation
‣ Deadlock: involve two or more processes becoming stuck indefinitely
while attempting to enter or exit the critical section, by virtue of their mutual
interdependence
‣ Even without a deadlock, a poor algorithm might lead to starvation: the
indefinite postponement of entry for a process that has requested it
• The absence of starvation is a FAIRNESS condition
10
DTU Compute
Department of Applied Mathematics and Computer Science
On ME Requirements: Ordering
• [ME3] Ordering: if one request to enter the CS happened-before another,
then entry to the CS is granted in that order
N.B.:
If a solution grants entry to the CS in happened-before order
and
if all the requests are related by happened-before
then
it is not possible for a process to enter the CS more than
once while another waits to enter
Happened-before ordering of CS requests implies liveness
11
DTU Compute
Department of Applied Mathematics and Computer Science
[Ordering] Example
• A multi-threaded process may continue with other processing while a thread
waits to be granted entry to a CS
‣ During this time, it might send a message to another process, which
consequently also tries to enter the CS
‣ ME3 specifies that the first process be granted access before the second
request
to enter
the CS p1 must enter
p1 the CS before p2
m request to
enter the CS
p2
12
DTU Compute
Department of Applied Mathematics and Computer Science
Performance Criteria
• The bandwidth consumed, which is proportional to the number of
messages sent in each entry and exit operation
• The client delay incurred by a process at each entry and exit operation
• Throughput of the system: the rate at which the collection of processes
as a whole can access the CS, given that some communication is
necessary between successive processes
1
throughput =
(E + SD)
E = average CS execution time
SD (synchronization delay) = delay between one process exiting the CS and the
next process entering it
13
DTU Compute
Department of Applied Mathematics and Computer Science
Design of Distributed ME Algorithms
• Complex because these algorithms have to deal with
‣ unpredictable message delays
‣ incomplete knowledge of the system state
• 3 basic approaches:
‣ Token based approaches
‣ Non-token based approaches
- Quorum based approaches
14
DTU Compute
Department of Applied Mathematics and Computer Science
Distributed Mutual Exclusion
Token based algorithms
DTU Compute
Department of Applied Mathematics and Computer Science
[Distributed ME] Token Based Algorithms
• A unique token (PRIVILEGE msg) is shared among the processes
• A process is allowed to enter its CS if it possesses the token
• The process continues to hold the token until the execution of the CS is over
• Mutual exclusion is ensured because the TOKEN IS UNIQUE
• The algorithms based on this approach essentially differ in the way a process
carries out the search for the token
16
DTU Compute
Department of Applied Mathematics and Computer Science
The Central Server Algorithm
• Simplest way to achieve mutual exclusion: a server grants permission to enter
the CS
• To enter a CS, a process sends a requests to the server and awaits a reply from it
• The reply constitutes a token signifying permission to enter the CS
• If no other process has the token at the time of the request then the server replies
immediately, granting the token
• If the token is currently held by another process, then the server does not reply but queues
the request
• On exiting the CS, a message is sent to the server, giving it back the token
• If the queue of waiting process is not empty, then the server chooses the oldest entry in the
queue, removes it and replies to the corresponding process
• The chosen process then holds the token Algorithm
17
DTU Compute
Department of Applied Mathematics and Computer Science
[The Central Server Algorithm] Example
• Process p1 does not currently require entry to the CS
• Process p2‘s request has been appended to the queue, which already
contained p4‘s request
• Process p3 exits the CS
• The server removes p4‘s entry and
grants permission to enter to p4 by
replying to it
18
DTU Compute
Department of Applied Mathematics and Computer Science
Performance of the Central Server Algorithm
• Entering the CS:
‣ It takes 2 messages: a request followed by a grant
‣ It delays the requesting process (client) by the time for this round-trip
• Exiting the CS:
‣ It takes 1 release message
‣ Assuming asynchronous message passing, this does not delay the exiting
process
• Synchronization delay: time taken for a round-trip (a release msg to the
server, followed be a grant msg to the next process to enter the CS)
• The server may become a performance bottleneck for the system as a whole
19
DTU Compute
Department of Applied Mathematics and Computer Science
Homework
• Basic: given the assumption that no failures occur, informally discuss why
‣ safety and liveness conditions [ME1 and ME2] are met by the Central
Server algorithm
‣ the algorithm does not satisfy the ordering property [ME3]
- hint: describe a situation in which two requests are not processed in
happened-before order
• Advanced: prove the above statements
20
DTU Compute
Department of Applied Mathematics and Computer Science
A Ring-Based Algorithm
• Logical ring: one of the simplest ways to arrange a ME between N processes
without requiring an additional process
The ring topology may be unrelated to the physical interconnections between
the underlying computers
• Basic idea: exclusion is conferred by obtaining a
token in the form of a message from process to
process in a single direction around the ring
• If a process does not require to enter the CS when Each process pi has a
it receives the token, then it immediately forwards communication channel
the token to its neighbour
to the next process in
the ring, p(i + 1) mod N
• A process that requires the token waits until it
receives it, but retains it
• To exit the CS, the process sends the token on to
its neighbour Algorithm
21
DTU Compute
Department of Applied Mathematics and Computer Science
Performance of the Ring-Based Algorithm
• The algorithm continuously consumes network bandwidth, except when a
process is inside the critical section
‣ The processes send messages around the ring even when no process
requires entry to the CS
• The delay experienced by a process requesting entry to the CS is between 0
messages (when it has just received the token) and N messages (when it has
just passed on the token)
• To exit the CS requires only one message
• The synchronization delay between one process’s exit from the CS and the
next process’s entry is anywhere from 1 to N message transmissions
22
DTU Compute
Department of Applied Mathematics and Computer Science
Homework
• Basic: given the assumption that no failures occur, informally discuss why
‣ the safety and liveness conditions [ME1 and 2] are met by the Ring-Based
algorithm
‣ the algorithm does not necessarily satisfy the ordering property [ME3]
- hint: give an example execution of the algorithm to show that
processes are not necessarily granted entry to the critical section in
happened-before order
• Advanced: prove the above statements
23
DTU Compute
Department of Applied Mathematics and Computer Science
Distributed Mutual Exclusion
Non-token based algorithms
DTU Compute
Department of Applied Mathematics and Computer Science
[Distributed ME] Non-token Based Algorithms
• Two or more successive rounds of messages are exchanged among the
processes to determine which process will enter the CS next
• A process enters the CS when an assertion, defined on its local variables,
becomes true
• Mutual exclusion is enforced because the assertion becomes true only
at one site at any given time
25
DTU Compute
Department of Applied Mathematics and Computer Science
Lamport’s Algorithm
• Requires communication channels to deliver messages in FIFO order
• Satisfies conditions ME1, ME2 and ME3
• Based on Lamport logical clocks: timestamped requests for entering the CS
• Every process pi keeps a queue, request_queuei, which contains mutual
exclusion requests ordered by their timestamps
• IDEA: the algorithm executes CS requests in the increasing order of
timestamps
• Timestamp: (clock value, id of the process)
26
DTU Compute
Department of Applied Mathematics and Computer Science
Timestamp: (clock value, id of the process)?
Why does the algorithm need
the id of the sending process
in the timestamp?
27
DTU Compute
Department of Applied Mathematics and Computer Science
Extension of Happened-Before Relation (→)
• → defines a partial ordering of events in the system
CR1: If ∃ process pi such that e ➝i e’, then Li(e) < Li(e’)
CR2: If a is the sending of a message by pi and b is the receipt of the same
message by pj, then Li(a) < Lj(b)
CR3: If e, e’, e’’ are three events such that L(e) < L(e’) and L(e’) < L(e’’) then
L(e) < L(e’’)
Timestamps totally
• A total ordering requires the further rule:
ordered!!
Example: (1, 1) < (1, 2)
CR4: a (in pi) b (in pj) if and only if
either Li(a) < Lj(b)
or Li(a) = Lj(b) ∧ pi ≺ pj
for some suitable ordering ≺ of the processes
28
DTU Compute
Department of Applied Mathematics and Computer Science
Lamport’s Algorithm [1978]
Requesting the CS
Process pi updates its local clock and timestamps the request (tsi)
Process pi broadcasts a REQUEST(tsi, i) to all the other processes
Process pi places the request on request_queuei
On Receiving REQUEST(tsi, i) from a process pi
Process pj places pi’s request on request_queuej
Process pj returns a timestamped REPLY msg to pi
Executing the CS
Process pi enters the CS when the following two conditions hold:
‣ L1: pi has received a msg with timestamp larger than (tsi, i) from all other processes
‣ L2: pi’s request is at the top of request_queuei
Releasing the CS
Process pi removes its request from the top of request_queuei
Process pi broadcasts a timestamped RELEASE msg to all other processes
On Receiving RELEASE from a process pi
Process pj removes pi’s request from its request queue request_queuej
29
DTU Compute
Department of Applied Mathematics and Computer Science
The Algorithm in Action: Entering a CS
• p1 and p2 send out REQUEST messages for the CS to the other processes
REQUEST(1, 1)
p1
REQUEST(1, 2)
p2
p3
request_queue1 (1, 1)
request_queue2 (1, 2)
30
DTU Compute
Department of Applied Mathematics and Computer Science
The Algorithm in Action: Entering a CS
• Both p1 and p2 have received timestamped REPLY msgs from all processes
p1 enters the CS
p1
p2
p3
request_queue1 (1, 1) (1, 2) ‣ L1: p1 has received a msg with timestamp larger
than (1, 1) from all other processes
request_queue2 (1, 1) (1, 2) ‣ L2: p1’s request is at the top of request_queue1
31
DTU Compute
Department of Applied Mathematics and Computer Science
The Algorithm in Action: Exiting a CS
• p1 exits and sends RELEASE msgs to all other processes
p1 exits the CS
p1
p2
p3
request_queue1 (1, 2)
request_queue2 (1, 2) (1, 1)
32
DTU Compute
Department of Applied Mathematics and Computer Science
The Algorithm in Action: Exiting a CS
• p1 exits and sends RELEASE msgs to all other processes
p1
p2
p3
request_queue1 (1, 2) On Receiving RELEASE from process p1
• Process p2 removes p1’s request from its request
request_queue2 (1, 2) queue request_queue2
33
DTU Compute
Department of Applied Mathematics and Computer Science
The Algorithm in Action: p2 enters the CS...
• p1 exits and sends RELEASE msgs to all other processes
p1
p2
p2 enters the CS
p3
request_queue1 (1, 2) ‣ L1: p2 has received a msg with timestamp larger
than (1, 2) from all other processes
request_queue2 (1, 2) ‣ L2: p2’s request is at the top of request_queue2
34
DTU Compute
Department of Applied Mathematics and Computer Science
Another Example
35
DTU Compute
Department of Applied Mathematics and Computer Science
Correctness Theorem
Lamport’s algorithm achieves mutual exclusion (property ME1)
Proof [by contradiction]:
- suppose two processes pi and pj are executing the CS concurrently
➡ L1 and L2 must hold at both sites concurrently
➡ at some instant in time, say t, both pi and pj have their own requests at the top
of their request_queue and condition L1 holds at them
- Without loss of generality, assume that (tsi, i) < (tsj, j)
- From L1 and FIFO property, at instant t the request of pi must be in
request_queuej when pj was executing its CS
➡ pj’s own request is at the top of request_queuej when a smaller timestamp
request, (tsi, i) from pi, is present in the queue - a contradiction!!
request_queuej (tsj, j) ... (tsi, i) ...
36
DTU Compute
Department of Applied Mathematics and Computer Science
Fairness Theorem
Lamport’s algorithm is fair (that is, the requests for CS are executed in the order
of their timestamps)
Proof [by contradiction]:
- without loss of generality, suppose a pi’s request has a smaller timestamp than
the request of another site pj and pj is able to execute the CS before pi
➡ for pj to execute the CS, it has to satisfy L1 and L2, which implies that:
- at some instant in time, say t, pj has its own request at the top of its queue
- pj has also received a message with timestamp larger than the timestamp of
its request from all other processes, including pi
- by assumption, request queue of a process is ordered by timestamps
- according to our assumption pi has lower timestamp
➡ So pi’s request must be placed ahead of the pj’s request in the request_queuej -
a contradiction!
37
DTU Compute
Department of Applied Mathematics and Computer Science
Performance of Lamport’s Algorithm
• For each CS execution, the algorithm requires
‣ (N - 1) REQUEST messages
‣ (N - 1) REPLY messages
‣ (N - 1) RELEASE messages
• Thus, the algorithm requires 3(N - 1) messages per CS invocation
• The client delay in requesting entry is a round-trip time
• The synchronization delay is 1 msg transmission (average message delay)
38
DTU Compute
Department of Applied Mathematics and Computer Science
Homework
• Advanced: why does Lamport's algorithm require communication channels to
deliver messages in FIFO order?
39
DTU Compute
Department of Applied Mathematics and Computer Science
Ricart and Agrawala’s Idea [1981]
• Basic idea:
‣ processes that require entry to a CS multicast a request message
‣ processes can enter the CS only when all the other processes have replied
to this message
‣ node pj does not need to send a REPLY to node pi if pj has a request with
timestamp lower than the request of pi (since pi cannot enter before pj
anyway in this case)
• Does NOT require communication channels to be FIFO
40
DTU Compute
Department of Applied Mathematics and Computer Science
Ricart and Agrawala’s Algorithm [1981]
• Each process pi keeps a Lamport clock, updated according to LC1 and LC2
• Messages requesting entry are of the form <T, pi>, where T is the sender’s
timestamp and pi is the sender’s identifier
• Every process records its state of being outside the CS (RELEASED), wanting
entry (WANTED) or being in the CS (HELD) in a variable state
41
DTU Compute
Department of Applied Mathematics and Computer Science
Ricart and Agrawala’s Algorithm [1981]
On initialization To exit the Critical Section
state := RELEASED; state := RELEASED;
reply to any queued requests;
To enter the Critical Section
state := WANTED;
Multicast REQUEST to all processes;
T := request’s timestamp;
Wait until (number of replies received = (N – 1));
If two or more processes request
state := HELD;
entry at the same time, then
whichever process’s request
On receipt of a request <Ti, pi> at pj (i ≠ j) bears the lowest timestamp will
if (state = HELD or (state = WANTED and (T, pj) < (Ti, pi)))
be the first to collect N-1 replies,
then
granting it entry next.
queue request from pi without replying;
else
In case of equal timestamps, the
reply immediately to pi;
requests are ordered according
end if to the process identifiers.
42
DTU Compute
Department of Applied Mathematics and Computer Science
[Ricart and Agrawala’s Algorithm] Example
• p3 not interested in entering the CS
• p1 and p2 request it concurrently
43
DTU Compute
Department of Applied Mathematics and Computer Science
[Ricart and Agrawala’s Algorithm] Example
• The timestamp of p1’s request is 41, that of p2 is 34.
• When p3 receives their requests, it replies immediately
44
DTU Compute
Department of Applied Mathematics and Computer Science
[Ricart and Agrawala’s Algorithm] Example
• When p2 receives p1’s request, it finds its own request has the lower
timestamp (34 < 41), and so does not reply, holding p1 off
45
DTU Compute
Department of Applied Mathematics and Computer Science
[Ricart and Agrawala’s Algorithm] Example
• However, p1 finds that p2’s request has a lower timestamp than that of its own
request (34 < 41) and so replies immediately
46
DTU Compute
Department of Applied Mathematics and Computer Science
[Ricart and Agrawala’s Algorithm] Example
• On receiving the 2nd reply, p2 can enter the CS
47
DTU Compute
Department of Applied Mathematics and Computer Science
[Ricart and Agrawala’s Algorithm] Example
• When p2 exits the CS, it will reply to p1’s request and so grant it entry
48
DTU Compute
Department of Applied Mathematics and Computer Science
Performance of the Ricart-Agrawala’s Algorithm
• Gaining entry takes 2(N-1) messages:
‣ N-1 to multicast the request
‣ followed by N-1 replies
• The client delay in requesting entry is a round-trip time
• The synchronization delay is 1 message transmission time
• Ricart and Agrawala refined the algorithm so that it requires N messages to
obtain entry in the worst (and common) case
[Raynal, M. (1988). Distributed Algorithms and Protocols. Wiley]
49
DTU Compute
Department of Applied Mathematics and Computer Science
Homework
• Ricart and Agrawala’s Algorithm: prove that the algorithm achieves the safety
property ME1
‣ hint: proof by contradiction
• Verify, in a similar way, that the algorithm also meets requirements ME2 and
ME3.
50
DTU Compute
Department of Applied Mathematics and Computer Science
Distributed Mutual Exclusion
Quorum-Based ME Algorithms
DTU Compute
Department of Applied Mathematics and Computer Science
Quorum-Based Algorithms
• Each process requests permission to execute the CS from a subset of
processes (QUORUM)
• The quorums are formed in such a way that when two processes concurrently
request access to the CS
‣ at least one process receives both the requests
‣ this process is responsible to make sure that only one request executes
the CS at any time
52
DTU Compute
Department of Applied Mathematics and Computer Science
Quorum-Based Mutual Exclusion Algorithms
• Idea:
‣ processes vote for one another to enter the CS
‣ a process can vote only one process per session
‣ a “candidate” process must collect sufficient votes to enter the CS
- a process does NOT need permission from ALL other processes, but
only from a SUBSET of the processes (QUORUM)
• Intersection property: for every quorum Vi, Vj ⊆ {p1, p2, ..., pN}, Vi ∩ Vj ≠ ∅
‣ Example: {2, 5, 7} and {5, 7, 9} are suitable quorums, {1, 2, 3} and {5, 7, 9}
are not suitable quorums
• Algorithms basically differ in how the quorum is constructed
53
DTU Compute
Department of Applied Mathematics and Computer Science
Simple Quorum-Based ME Algorithm
• A simple protocol works as follows:
‣ let pi be a process in quorum Vi
‣ if pi wants to invoke mutual exclusion, it requests permission from all
processes in its quorum Vi
(every process does the same to invoke mutual exclusion)
‣ due to the Intersection property, quorum Vi contains at least one process
that is common to any other quorums
‣ these common processes send permission (i.e., vote) to only one process
at any time
‣ Thus, mutual exclusion is guaranteed
54
DTU Compute
Department of Applied Mathematics and Computer Science
Maekawa’s Algorithm: Quorums
• The quorums are constructed to satisfy the following conditions:
M1 ∀i ∀j : i ≠ j, 1 ≤ i, j ≤ N, then Vi ∩ Vj ≠ ∅
necessary for
M2 ∀i : 1 ≤ i ≤ N, then pi ∈ Vi
correctness
M3 ∀i : 1 ≤ i ≤ N, then |Vi| = K
desiderable features
M4 any process pj is contained in K number of Vis, 1 ≤ i, j ≤ N
• Optimal solution: N = K(K - 1) + 1, which gives K = √N
55
DTU Compute
Department of Applied Mathematics and Computer Science
Maekawa’s Algorithm [1985]
On initialization For pi to exit the critical section
state := RELEASED;
state := RELEASED;
voted := FALSE;
Multicast RELEASE to all processes in Vi;
For pi to enter the critical section On receipt of a RELEASE from pi at pj
state := WANTED;
if (queue of requests is non-empty)
Multicast REQUEST to all processes in Vi;
then
Wait until (number of replies received = K);
remove head of queue – from pk, say;
state := HELD;
send REPLY to pk;
voted := TRUE;
On receipt of a REQUEST from pi at pj else
if (state = HELD or voted = TRUE)
voted := FALSE;
then
end if
queue request from pi without replying;
else
send REPLY to pi;
voted := TRUE;
end if
56
DTU Compute
Department of Applied Mathematics and Computer Science
Correctness Theorem
• Maekawa’s algorithm achieves mutual exclusion.
• Proof: homework
57
DTU Compute
Department of Applied Mathematics and Computer Science
Performance of Maekawa’s Algorithm
• The size of each quorum is √N
➡ The bandwidth utilization is 3√N messages per CS execution
‣ 2√N messages per entry to the CS (√N REQUEST and √N REPLY)
‣ √N messages per exit
• The client delay in requesting entry is a round-trip time
• The synchronization delay is a round-trip time
58
DTU Compute
Department of Applied Mathematics and Computer Science
A Problematic Scenario
• Consider processes p1, p2 and p3 with V1 = {p1, p2}, V2 = {p2, p3}, V3 = {p1, p3}
p2
V1 V2
p1 V3 p3
• If the processes simultaneously request entry to the CS, then the following
scenario is possible:
‣ p1 is a candidate in V1, waiting for p2’s REPLY
K!
OC
‣ p2 is a candidate in V2, waiting for p3’s REPLY
E A DL
D
‣ p3 is a candidate in V3, waiting for p1’s REPLY
59
DTU Compute
Department of Applied Mathematics and Computer Science
Deadlock Scenario
p2
REQUEST
V1 V2
REPLY p1 p3
V3
p3
p1
p1
p2
p2
p3
• Each process has received one out of two replies, and none can proceed!
60
DTU Compute
Department of Applied Mathematics and Computer Science
Solving the Deadlock Problem
• Intuition: Maekawa’s algorithm can deadlock because a process is exclusively
locked by other processes and requests are not prioritised by their
timestamps
• The algorithm can be adapted so that it becomes deadlock-free
• IDEA: in the adapted protocol, processes queue outstanding requests in
happened-before order, so that requirements ME3 is also satisfied
• See paper:
B. Sanders.
The Information Structure of Distributed Mutual Exclusion Algorithms
ACM Transactions on Computer Systems, Vol. 5, No. 3, pp. 284-99, 1987.
61
DTU Compute
Department of Applied Mathematics and Computer Science
Fault Tolerance
• What happens when messages are lost?
• What happens when a process crashes?
➡ None of the algorithms would tolerate the loss of messages, if the channels
were unreliable
• Ring-based algorithm: cannot tolerate a crash failure of any single process
• Central server algorithm: can tolerate the crash failure of a client process that
neither holds nor has requested the token
• Ricart-Agrawala algorithm: can be adapted to tolerate the crash failure of
such a process, by taking it to grant all requests implicitly
• Maekawa’s algorithm: can tolerate some process crash failures: if a crashed
process is not in a voting set that is required, then its failure will not affect the
other processes
62
