1 / 27

A Log(n) Multi-Mode Locking Protocol for Distributed Systems

A Log(n) Multi-Mode Locking Protocol for Distributed Systems. Nirmit Desai, Frank Mueller mueller@cs.ncsu.edu Department of Computer Science North Carolina State University. Background. Problem Large parallel and distributed systems Scalability of synchronization Motivation

jaredk
Download Presentation

A Log(n) Multi-Mode Locking Protocol for Distributed Systems

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. A Log(n) Multi-Mode Locking Protocol for Distributed Systems Nirmit Desai, Frank Mueller mueller@cs.ncsu.edu Department of Computer Science North Carolina State University

  2. Background • Problem • Large parallel and distributed systems • Scalability of synchronization • Motivation • Increasing need to share resources • Inadequate scalability of current protocols • Approach • Leveraging hierarchical locking in distributed synchronization • Contribution • Highly scalable protocol • Supports hierarchical locking NC State University

  3. Site 1 Shared Resource 1 Network Site N Site 2 Site 3 Shared Resource 2 Large Distributed Environments Distributed Environments Cluster Environments NC State University

  4. T T T T T is done B D B D B D B D A C A C A A C C Distributed Synchronization(Naimi et al.) • Single locking mode - Read and Write are not distinguished • Single level of locking granularity (either entire table or a tuple) Request from A Request from C NC State University

  5. Coarse grain Multi grain Fine grain Data Data Data Data Data Data Hierarchical Locking(a.k.a. Multi-granularity Locking) • How is a lock associated with data items ? - High overhead - High concurreny - Low overhead - No concurrency - Low overhead - High concurrency NC State University

  6. Data table Multi-Mode Locking Protocol 1. Intention Read (IR) /Intention Write (IW) on all upper level resources 2. Read (R) locks and Write (W) locks on the resource itself A : Reads tuple 2 t0:Acquire IR on the table t1:Acquire R on tuple #2 t2:Read tuple #2 t3:Release R t4:Release IR B : Writes tuple 3 t0:Acquire IW on the table t1:Acquire W on tuple #3 t2:Write tuple #3 t3:Release W t4:Release IW NC State University

  7. Data table X Multi-Mode Locking Protocol (cont.) • Modes incompatible?  Conflict  Block A: reads entire table t0:Acquire R on the table t1:Read table t2:Release R on the table B : Writes a tuple t0:Request IW on the table t1: wait for lock t2:Acquires IW t3:Acquire W on tuple t4:... NC State University

  8. Compatibility Matrix • ‘X’ indicates a conflict • Upgrade: Read followed by write to same data • assures consistent data • Lock Mode Strength: Less compatible  Stronger lock mode IR < R < U = IW < W NC State University

  9. E(U,U,0) B(R,R,0) D(IR,IR,0) A(0,0,0) C(IR,IR,0) Our Protocol - Conventions • Held Mode: Mh = Mode of held lock • Owned Mode: Mo = Strongest held mode in tree (rooted=owner) • Pending Mode: Mp = await this mode • Node state: (Mo, Mh, Mp) • Request arrives  test compatibility  grant/queue/forward based on result • Actions: rules & transition tables • Requester becomes a child of granter NC State University

  10. E(IR,IR,0) E(IR,IR,0) E(IR,IR,0) Token transfer A requests R B(0,0,0) B(0,0,0) B(0,0,0) D(0,0,IR) (D,IR) D(IR,IR,0) D(IR,IR,0) (A,R) Grant A(0,0,0) C(0,0,0) A(0,0,R) (A,R) C(0,0,0) A(R,R,0) C(0,0,0) A Granting/Forwarding Example • If Mr compatible with Mo  Mr compatible w/ all modes in subtree Invariant : “Node cannot grant request for stronger mode than it owns”  has to forward it to parent NC State University

  11. E(R,R,0) E(R,R,0) C releases IR B releases IR E(R,R,0) B(IR,IR,0) B(IR,0,0) (B,IR) B(IR,0,0) D(IR,IR,0) D(IR,IR,0) D(IR,IR,0) (C,IR) A(0,0,0) C(IR,IR,0) A(0,0,0) C(IR,IR,0) A(0,0,0) C(0,0,0) A Release Example Invariant: “Node knows owned mode of its children” • Notice: If a child releases a mode but owned mode is unchanged, no need to notify our parent B(0,0,0) NC State University

  12. E(R,R,0) A requests IR Send freeze (C,W) (C,W)(A,IR) (C,W) IR, R, U IR, R, U IR, R, U E(R,R,0) E(R,R,0) B(IR,IR,0) (C,W) IR, R IR, R IR IR Freeze (IR) Freeze (IR, R) D(R,R,0) (A,IR) (C,W) B(IR,IR,0) B(IR,IR,0) D(R,R,0) D(R,R,0) A(0,0,0) C(0,0,W) (A,IR) (C,W) A(0,0,IR) C(0,0,W) A(0,0,0) C(0,0,W) A Queuing Example Invariants: “Queue if request is conflicting. Freeze modes if it is a) incompatible with queued request and b) grantable otherwise” • Starvation of queued request is avoided, FIFO is ensured NC State University

  13. Measurements • Metrics of interest: Scalability of • Message overhead per lock request • Request latency time • Effect of changing concurrency level on scalability higher ratio  lower concurency • Compare with Naimi’s protocol • Coarse: Lock the entire table • Fine: Lock each entry • Multi-airline reservation system • IBM SP Power3 NC State University

  14. Comparison with Naimi’s protocols Message overhead per Request Response time per Request Naimi coarse has different functionality NC State University

  15. Effect of concurrency level • Concurrency level increases as # of nodes increase C NC State University

  16. Applications • State management of replicated data • Distributed databases (Oracle, MS-SQL) • Distributed transaction processing • Middleware concurrency services (CORBA) • Coordinated, distributed Server Farms • Fault tolerance in clusters • State replication for redundant computing • Distributed agreement • State coherence NC State University

  17. Related Work • Naimi et. al. (JPDC ‘96) • Distributed mutual exclusion, single level of granularity • Ramamritham et. Al. (SIGMOD ‘90) • Concurrency protocols, centralized transaction coordinator • Other approaches: complexity > O(log (n)) • Hierarchical locking: only in context of distributed synchronization problems in past • Scalability: had not been the focus NC State University

  18. Conclusions • Novel peer-to-peer distributed concurrency protocol • Compact formulation: rules and tables  simplicity intriguing • Highly scalable: O(log n) msgs, asymptote 3-5 msgs • High degree of concurrency common • Scalability unaffected by concurrency level • Response time: linear increasing w/ concurrency level • Best scalable protocol for hierarchical locking known • Wide applications in parallel and distributed world NC State University

  19. Breakup of Messages • Request propagation is major component C NC State University

  20. Concurrency level Request forwarding Request • Nodes Tree height Path length Request Request Message • more request msgs • propagation paths longer NC State University

  21. Concurrency level Granting Token transfers • Nodes Tree height Granting Token transfers Token Message • more contention • lower chance to grant token NC State University

  22. Grant Message • Concurrency level Granting • Nodes Tree height Granting • more contention • more child grants NC State University

  23. Concurrency level Granting Release • Nodes Tree height Granting Release Release Message • higher concurrency • more trees & release msgs NC State University

  24. Concurrency level Conflicts Freeze • Nodes Requests Conflicts Freeze Freeze Message • higher concurrency • more freezes (be fair) NC State University

  25. Rule for Granting at Non-root X = cannot grant NC State University

  26. Rule for Queuing/Forwarding Forward Queue NC State University

  27. Rule for Freezing Modes Modes to freeze NC State University

More Related