Mutex Requirements:
correctness and safety: one process hold critical section
fairness: Any process that makes a request must be granted lock
number of cycles (typically n)
We need consistency in distributed system accross different machines. (no inconsistency)
Distributed Mutex Requirements: no shared memory
Assume: - total number of processes is fixed at n. - No process fails or misbehaves. - message never fails, but can be reordered.
Unicast: point-to-point Multicast: broadcast to multiple machines (might or might not be all). all messages are delivered in the same order to each receiver. Cycle: one transection (a complete round of the protocol with one process i entering its critical section and then exiting.)
We assume we have n copies of data in n servers that are distributed in the world. Each server got request from client and want to access its database. But we need to make sure all the copies of database are identical upon modification by multiple servers. We only care about the locks, but we don't care about how exactly the data is modified. // QUESTION: is this the assumption?
Existing Algorithms:
Centralized Mutual Exclusion: centralized server queueing up requests
Bully Leader Election
A Ring Algorithm: priority based
Decentralized Mutual Exclusion: resource is replicated
Totally-Ordered Multicast
Lamport Mutual Exclusion
Ricart & Agrawala Mutual Exclusion
Token Ring Mutual Exclusion
Decentralized Mutual Exclusion: a way to access critical region shared by multiple server
Decentralized Mutual Exclusion: - correctness: majority vote ensure safety (very low failure rate with only 8 copies of data in 8 servers) - fairness: random chance - performance: 2m + m total message to get majority (but unbounded number of messages per cycle) - node failure and recovery is still a issue (when coordinator fail and forgot it has already granted someone resource, and made another grant) - backoff and retry might lead to starvation (when everybody is trying to access resource)
Bully Leader Election: Nobody want to be the leader, but everybody can appoint a leader. Everybody must accept appointment unless you can hand the task of the leader to other people. Youtube
Ring Algorithm Election: processes arrange as a ring and collect information about all the alive servers Youtube
[i]
and send it to server S_{i+1 \mod n}, if it does not respond, then send it to S_{i+2 \mod n} until someone reply[i, i+1]
and send it to the next person S_{i + 2\mod n}[...]
the piece of paper who has the highest priority.
Total Ordered Multicast using Total Order Lamport (TO-Lamport) Clock: we want all servers to process a specific list of command
in order
command
, when generated, is timestamped with the server's current total order lamport timestamp when the server first get the message (assume only 1 server in the system got the message). The command
is then broadcast to other servers.command
. They are sorted based on total order lamport clock.command
, send ACK
to ALL servers in the system.ACK
, mark the corresponding command
as ACKED
.ACKED
. If so, process that command
.Property of Multicast using TO-Lamport:
tolerate: crazy message delay
need to assume: all messages sent by one sender are received in the order they were sent and that no messages are lost.
Why does it work
ACK
, the the receiver must have received all prior command
from the sendercommand
Lamport Mutual Exclusion: Total Ordered Multicast with slight change, assuming no replicate data among servers
instead of sending command
, we send p_i want to access critical region
when processing command
, we allow p_i to access critical region
only ACK
to one server (sender) instead of broadcasting ACK
(only the requester need to know when it can access critical region, assuming no malicious server)
p_i want to access critical region
, but might not have consistent ACKED
status on every p_i want to access critical region
.ACK
and have its p_i want to access critical region
being the oldest in the queuebroadcast RELEASE
lock to all servers once sender has done with critical region
upon receive RELEASE
, remove element in the queue no matter whether p_i want to access critical region
is ACKED
Performance of Lamport Mutual Exclusion: - process i sends n-1
p_i want to access critical region
messages - process i receives n-1ACK
messages - process i sends n-1RELEASE
messagesThe algorithm does not tolerate server failure.
Ricart & Agrawala Mutual Exclusion: assume no message lost, mul
REQUEST
to all serversYES
RESUEST
:YES
if it is not interested in data.YES
if it is interested in data, but has not gotten permission, and the lamport clock is the current REQUEST
is lower than itself's REQUEST
.REQUEST
is greater than itself's REQUEST
.Properties of Ricart & Agrawala Mutual Exclusion: - Correctness: yes (by contradiction with total order lamport) - Deadlock Free: no cyclic wait with total order lamport - Starvation Free: we do not drop request, assume no dropped message, lamport clock strictly increase - Performance: 2(n-1) messages in a cycle (n-1 requests by i and n-1 replies to i) - Issues: no failure tolerate, will introduce starvation if one server fails
Token Ring Algorithm:
Token Ring Algorithm: - Correctness: only one token - Fairness: deterministic order - Performance: If nobody has message, still pass around token. Latency is between [0, n-1]. - Issue: token lost due to failure. Hard to detect token lost. Difficult to add and remove server.
Table of Content