1 / 38

Outline

Outline. Distributed Mutual Exclusion Introduction Performance measures Centralized algorithm Non-token-based algorithms Lamport’s algorithm Ricart-Agrawala algorithm Token-based algorithms Suzuki-Kasami’s broadcast algorithm Singhal’s heuristic algorithm Raymond’s tree-based algorithm

kele
Download Presentation

Outline

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Outline • Distributed Mutual Exclusion • Introduction • Performance measures • Centralized algorithm • Non-token-based algorithms • Lamport’s algorithm • Ricart-Agrawala algorithm • Token-based algorithms • Suzuki-Kasami’s broadcast algorithm • Singhal’s heuristic algorithm • Raymond’s tree-based algorithm • Comparison COP5611

  2. Announcement • Next Tuesday (Feb. 18, 2003) Dr. Ted Baker will lecture on distributed deadlock detection (Chapter 7) • Please read the materials ahead of time • Please review the local deadlock detection algorithms (Chapter 3) • I will post his lecture notes on the class web too COP5611

  3. The Critical Section Problem • When processes (centralized or distributed) interact through shared resources, the integrity of the resources may be violated if the accesses are not coordinated • The resources do not record all the changes • A process may obtain inconsistent values • The final state of the shared resource may be inconsistent COP5611

  4. An Example • Suppose we have two processes, (one is called producer and the other one consumer), the shared variable counter is 5 initially • Producer: counter = counter +1 P1: load counter, r1 P2: add r1, #1, r2 P3: store r2, counter • Consumer: counter = counter - 1 C1: load counter, r1 C2: add r1, #-1, r2 C3: store r2, counter COP5611

  5. An Example - cont. • A particular execution sequence • P1: load counter, r1 • P2: add r1, #1, r2 --- Context switch ---- • C1: load counter, r1 • C2: add r1, #-1, r2 • C3: store r2, counter --- Context switch ---- • P3: store r2, counter • What is the value ofcounter? COP5611

  6. An Example - cont. • A particular execution sequence • C1: load counter, r1 • C2: add r1, #-1, r2 --- Context switch ---- • P1: load counter, r1 • P2: add r1, #1, r2 • P3: store r2, counter --- Context switch ---- • C3: store r2, counter • What is the value ofcounter this time? COP5611

  7. An Example - cont. • A particular execution sequence • C1: load counter, r1 • C2: add r1, #-1, r2 • C3: store r2, counter --- Context switch ---- • P1: load counter, r1 • P2: add r1, #1, r2 • P3: store r2, counter --- Context switch ---- • What is the value ofcounter this time? COP5611

  8. Mutual Exclusion • One solution to the problem is that at any time at most only one process can access the shared resources • This solution is known as mutual exclusion • A critical section is a code segment in a process which shared resources are accessed • A process can have more than one critical section • There are problems which involve shared resources where mutual exclusion is not the optimal solution COP5611

  9. The Structure of Processes • Structure of process Pi repeat entry section critical section exit section reminder section untilfalse; COP5611

  10. Mutual Exclusion in Traditional OS • Through semaphores, monitors or other programming-language constructs • Semaphore S – integer variable • can only be accessed via two indivisible (atomic) operations wait (S): whileS 0 dono-op;S := S– 1; signal (S): S := S + 1; COP5611

  11. Mutual Exclusion in Traditional OS – cont. • Shared variables • varmutex : semaphore • initially mutex = 1 • Process Pi repeat wait(mutex); critical section signal(mutex); remainder section untilfalse; COP5611

  12. Distributed Mutual Exclusion • Due to the absence of shared memory, solutions for mutual exclusion based on shared memory cannot be used in distributed systems • It must be based on message passing COP5611

  13. Performance Measure for Distributed Mutual Exclusion • The number of messages per CS invocation • Synchronization delay • The time required after a site leaves the CS and before the next site enters the CS • System throughput 1/(sd+E), where sd is the synchronization delay and E the average CS execution time • Response time • The time interval a request waits for its CS execution to be over after its request messages have been sent out COP5611

  14. Performance Measure for Distributed Mutual Exclusion COP5611

  15. A Centralized Algorithm • It is a simple solution • One site, called the control site, is responsible for granting permission to the CS execution • To request the CS, a site sends a REQUEST message to the control site • When a site is done with CS execution, it sends a RELEASE message to the control site • The control site queues up the requests for the CS and grant them permission COP5611

  16. A Centralized Algorithm – cont. • Process 1 asks the coordinator for permission to enter a critical region. Permission is granted • Process 2 then asks permission to enter the same critical region. The coordinator does not reply. • When process 1 exits the critical region, it tells the coordinator, when then replies to 2 COP5611

  17. A Centralized Algorithm – cont. • Analysis of the centralized algorithm • There is a single point of failure • Number of messages per CS • The synchronization delay • System throughput • Response time • Best case • Worst case COP5611

  18. Distributed Solutions • Non-token-based algorithms • Use timestamps to order requests and resolve conflicts between simultaneous requests • Lamport’s algorithm and Ricart-Agrawala Algorithm • Token-based algorithms • A unique token is shared among the sites • A site is allowed to enter the CS if it possess the token and continues to hold the token until its CS execution is over; then it passes the token to the next site COP5611

  19. Lamport’s Distributed Mutual Exclusion Algorithm • This algorithm is based on the total ordering using Lamport’s clocks • Each process keeps a Lamport’s logical clock • Each process is associated with a unique id that can be used to break the ties • In the algorithm, each process keeps a queue, request_queuei, which contains mutual exclusion requests ordered by their timestamp and associated id • Ri of each process consists of all the processes • The communication channel is assumed to be FIFO COP5611

  20. Lamport’s Distributed Mutual Exclusion Algorithm – cont. COP5611

  21. Lamport’s Distributed Mutual Exclusion Algorithm – cont. COP5611

  22. Lamport’s Distributed Mutual Exclusion Algorithm – cont. COP5611

  23. Lamport’s Distributed Mutual Exclusion Algorithm – cont. COP5611

  24. Lamport’s Distributed Mutual Exclusion Algorithm – cont. • Performance analysis • Number of messages per CS • Synchronization delay • Throughput • Response time COP5611

  25. Ricart-Agrawala Algorithm COP5611

  26. Ricart-Agrawala Algorithm – cont. COP5611

  27. Ricart-Agrawala Algorithm – cont. COP5611

  28. Ricart-Agrawala Algorithm – cont. • Performance analysis • Number of messages per CS • Synchronization delay • Throughput • Response time COP5611

  29. A Simple Toke Ring Algorithm • When the ring is initialized, one process is given the token • The token circulates around the ring • It is passed from k to k+1 (modulo the ring size) • When a process acquires the token from its neighbor, it checks to see if it is waiting to enter its critical section • If so, it enters its CS • When exiting from its CS, it passes the token to the next • Otherwise, it passes the token to the next COP5611

  30. A Simple Toke Ring Algorithm – cont. • An unordered group of processes on a network. • A logical ring constructed in software. COP5611

  31. A Simple Toke Ring Algorithm – cont. • Performance analysis • Number of messages per CS • Synchronization delay • Response time • Problems • Lost token • Process crash COP5611

  32. Suzuki-Kasami’s Algorithm • Data structures • Each site maintains a vector consisting the largest sequence number received so far from other sites • The token consists of a queue of requesting sites and an array of integers, consisting of the sequence number of the request that a site executed most recently COP5611

  33. Suzuki-Kasami’s Algorithm – cont. COP5611

  34. Suzuki-Kasami’s Algorithm – cont. • Performance analysis • Number of messages per CS invocation • Synchronization delay • Response time • System throughput COP5611

  35. Singhal’s Heuristic Algorithm • In this algorithm, each site maintains information about the state of other sites in the system • The site only sends the request to a subset of sites that most likely have the token will in a near future • This reduces the number of messages per CS execution COP5611

  36. Raymond’s Tree-Based Algorithm • In this algorithm, sites are logically arranged as a directed tree COP5611

  37. Comparison of Distributed Mutual Exclusion Algorithms COP5611

  38. Summary • Mutual exclusion is one solution to the critical section problem • Due to the absence of shared memory, distributed mutual exclusion algorithms are message-based • Centralized algorithms • Non-token-based algorithms • Token-based algorithms COP5611

More Related