Distributed Systems Mutual Exclusion & Election Algorithms Mutual Exclusion & Election Algoritms Paul Krzyzanowski pxk@cs.rutgers.edu Except as otherwise noted, the content of this presentation is licensed under the Creative Commons Attribution 2.5 License. Page 1 Page 1 Page 2 Page 2 Process Synchronization Centralized Systems Techniques to coordinate execution among Mutual exclusion via: processes – Test & set in hardware – Semaphores – One process may have to wait for another – Messages – Shared resource (e.g. critical section) may require – Condition variables exclusive access Page 3 Page 4 Distributed Mutual Exclusion Centralized algorithm • Assume there is agreement on how a resource • Mimic single processor system is identified • One process elected as coordinator – Pass identifier with requests request(R) 1. Request resource C • Create an algorithm to allow a process to 2. Wait for response grant(R) obtain exclusive access to a resource. 3. Receive grant P 4. access resource 5. Release resource release(R) Page 5 Page 6 1
Centralized algorithm Centralized algorithm If another process claimed resource: Benefits – Coordinator does not reply until release • Fair – Maintain queue – All requests processed in order • Service requests in FIFO order • Easy to implement, understand, verify P 2 Queue request(R) Problems request(R) P 1 C • Process cannot distinguish being blocked from P 2 grant(R) a dead coordinator request(R) P 0 • Centralized server can be a bottleneck grant(R) P 1 release(R) Page 7 Page 8 Token Ring algorithm Token Ring algorithm Assume known group of processes • Initialization – Some ordering can be imposed on group – Process 0 gets token for resource R – Construct logical ring in software • Token circulates around ring – Process communicates with neighbor – From P i to P (i+1) mod N • When process acquires token P 0 – Checks to see if it needs to enter critical section P 1 P 5 – If no, send ring to neighbor P 0 – If yes, access resource P 1 P 5 • Hold token until done P 4 P 2 P 4 P 2 P 3 P 3 token(R) Page 9 Page 10 Token Ring algorithm Ricart & Agrawala algorithm • Only one process at a time has token • Distributed algorithm using reliable multicast and logical clocks – Mutual exclusion guaranteed • Process wants to enter critical section: • Order well-defined – Compose message containing: – Starvation cannot occur • Identifier (machine ID, process ID) • If token is lost (e.g. process died) • Name of resource – It will have to be regenerated • Timestamp (totally-ordered Lamport) – Send request to all processes in group • Does not guarantee FIFO order – Wait until everyone gives permission – sometimes this is undesirable – Enter critical section / use resource Page 11 Page 12 2
Ricart & Agrawala algorithm Ricart & Agrawala algorithm • When process receives request: • N points of failure – If receiver not interested: • A lot of messaging traffic • Send OK to sender • Demonstrates that a fully distributed – If receiver is in critical section algorithm is possible • 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 Page 13 Page 14 Lamport’s Mutual Exclusion Lamport’s Mutual Exclusion Each process maintains request queue Entering critical section (accessing resource) : – Contains mutual exclusion requests – P i received a message ( ack or release ) from every other process with a timestamp larger than T i – P i ’s request has the earliest timestamp in its queue Requesting critical section: – Process P i sends request( i , T i ) to all nodes Difference from Ricart-Agrawala: – Places request on its own queue Lamport time – Everyone responds (acks) … always - no hold-back – When a process P j receives – Process decides to go based on whether its a request, it returns a timestamped ack request is the earliest in its queue Page 15 Page 16 Lamport’s Mutual Exclusion Releasing critical section: – Remove request from its own queue – Send a timestamped release message Election algorithms – 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 Page 17 Page 18 Page 18 3
Elections Bully algorithm • Need one process to act as coordinator • Select process with largest ID as coordinator • When process P detects dead coordinator: – Send election message to all processes with higher • Processes have no distinguishing IDs. characteristics • If nobody responds, P wins and takes over. • If any process responds, P’s job is done. – Optional: Let all nodes with lower IDs know an • Each process can obtain a unique ID election is taking place. • If process receives an election message – Send OK message back – Hold election (unless it is already holding one) Page 19 Page 20 Bully algorithm Ring algorithm • A process announces victory by sending all • Ring arrangement of processes processes a message telling them that it is • If any process detects failure of coordinator the new coordinator – Construct election message with process ID and send to next process – If successor is down, skip over • If a dead process recovers, it holds an – Repeat until a running process is located election to find the coordinator. • Upon receiving an election message – Process forwards the message, adding its process ID to the body Page 21 Page 22 Ring algorithm Problems with elections Eventually message returns to originator Network segmentation – Process sees its ID on list – Split brain – Circulates (or multicasts) a coordinator message announcing coordinator • E.g. lowest numbered process Rely on alternate communication mechanism – Redundant network, shared disk, serial line, SCSI Page 23 Page 24 4
The end. Page 25 Page 25 5
Recommend
More recommend