QoS -enabled Tree-based Distributed Mutexes

1. QoS-enabled Tree-based Distributed Mutexes James Edmondson Brian Sulcer

2. Table of Contents • Introduction • Proposed Solution • QoS Properties • Performance Profile • Conclusion

3. Introduction • Mutual exclusion is the acquisition of a resource by competing threads or processes • In distributed systems, most mutual exclusion techniques are only interested in proper execution • No QoS guarantees • Priority inversions are common • Fault tolerance is a side note or rarely considered

4. Introduction Lamport technique Broadcast to all processes Wait for replies from all Enter critical section B A F R(1,D) G(1,D) R(1,D) G(1,D) C G(1,D) R(1,D) R(1,D) G(1,D) D E R(1,D) G(1,D)

5. Introduction Agarwal-El Abbadi,Tree-based quorum Each process requests CS from log n processes in its quorum Each process in the quorum must grant access A B C R(1,D) R(1,D) G(1,D) G(1,D) D E F

6. Introduction Raymond Spanning Tree Token is passed along a spanning tree If a process has a token, it is free to enter its critical section A G(1,D) R(1,D) B C G(1,D) R(1,D) D E F R(1,D)

7. Proposed Solution Tree-based scheme • Each process only requests from its parent • Root process grants based on some priority mechanism • Reply percolates down to requester • Release percolates back up to root A R(1,D) G(1,D) L(D) B C G(1,D) R(1,D) L(D) D E F

8. QoS Properties Fine-grained priority control • Higher priority processes can be placed at higher levels • Faster access for higher priority processes • Multiple priority mechanisms available • Weighted Level and Fair are of note A 4 G(1,D) R(2,1,F) R(2,1,D) B C 3 3 G(1,D) R(2,1,D) R(2,1,E) R(2,1,F) D E F 2 2 2

9. QoS Properties • To combat priority inversions, we can add enhancements • Before forwarding a reply to a child, if we have a request pending, go ahead and enter our CS before forwarding • Before forwarding a release to a parent, if we have a request pending, go ahead and enter CS before forwarding A R(1,D) L(D,B) G(1,D) B C G(1,D) R(1,D) L(D) D E F

10. QoS Properties • Fault tolerance • Presume process will be replaced or restarted on failure • Maintain queue of requests, remove requests on release • Most faults do not require any specialized changes • Introduce sync message to cover specialfailures • Executed by parent of a failed process A R(1,D) S(1,D) G(1,D) L(D) B C C B Process Cloud S(1,D) G(1,D) L(D) R(1,D) D E F

11. Performance Profile (no faults) • Worst case message complexity • 3d (d = depth of tree = log n in complete b-tree) • Best case message complexity A • 0 – root process G(1,D) R(1,B) G(1,B) R(1,D) L(B) L(D) • 3 – child process of root B C G(1,D) R(1,D) L(D) D E F

12. Performance Profile (no faults) • Heavy load – weighted/level priority – no root requests • Message complexity - 3d (d = highest depth of tree where recurring requests are occurring) • Synchronization delay – 2 x t x d (t = message time) d = 1 A R(2,2,C) G(C) L(C) R(2,1,C) R(2,1,B) R(2,2,B) G(B) L(B) B C R(3,1,D) D E F

13. Performance Profile (no faults) • Averages for heavy load– fair priority – root request every d/t • Message complexity – O(3d) (d = maximum depth of tree) • Synchronization delay – O(t) to O(2 t d) , t = message transmit time A R(1,D) L(D,B) G(1,D) B C G(1,D) R(1,D) L(D) D E F

14. Conclusion • QoS-enabled tree-based mutexes offer many benefits over traditional distributed mutexes • Reduced priority inversions • Robust fault tolerance • Excellent scalability and throughput • Easy to implement for distributed programmers • Shared memory implementation took ~3 hours to code for authors