Concurrent AVL Trees

1. Concurrent AVL Trees Implementation and Comparison Of course-grained and fine-grained Brian Cheng bcheng@vt.edu Jeremy Tate jtate09@vt.edu |

2. Agenda • Introduction • Solution Approach • Analysis • Future Work and Difficulties Encountered • Conclusion

3. Agenda • Introduction • Solution Approach • Analysis • Future Work and Difficulties Encountered • Conclusion

4. Introduction • Binary Search Tree: data structure • Standard operations: • Add – Add a node to the tree • Remove – Remove a node from the tree • Contains – Determine whether the tree contains a node • Benefits: • Logarithmic in time complexity

5. Introduction • AVL Tree • Balanced tree where the height of any two leaf nodes do not differ by more than 1 • Benefits: • Height of tree is carefully managed to reduce the number of nodes to traverse; therefore, faster in operation (O(log(n))) • Concurrent AVL Tree • Course-grained lock - one lock for the tree • Fine-grained lock - one lock for each node in the tree

6. Introduction • Project Goals/Objectives: • Implement the following: • AVL Tree • Concurrent AVL Tree with Course-grained locks • Concurrent AVL Tree with Fine-grained locks • Test the two Concurrent implementations • Compare and analyze the test results

7. Past Efforts • Hanke [1] showed improved performance with a relaxed balance red-black tree in a concurrent context • Ellis [2] and Nurmi et. al [3] used sentinel nodes with "real" nodes as all being leaf nodes  • Relax balance requirements

8. Agenda • Introduction • Solution Approach • Analysis • Future Work and Difficulties Encountered • Conclusion

9. Solution Approach • Reduce size of tree by not using sentinel nodes • Induce higher cost from lock contention • Gain performance from shorter tree • Relax balance requirements of nodes

10. Add() • General steps for adding a new item to the tree • Lock nodes in a hand-over-hand manner working down the tree going left or right depending on value comparison • Lock the tree before obtaining the next child node lock • Uses lock coupling to prevent deadlocks • If not able to lock both curr and next, release both locks and retry • Insert new node as specified child of parent • Test for rebalance

11. Contains() • Search for key  • If search key less than current key, go left • Else go right • If search key is less than  current key and current does not have a left child, key is not in the tree

12. Remove() • Search for key in tree • If found not found, return • Find replacement value giving preference to left subtree • Lock tree • Lock both curr and next • Unlock tree • Copy value of replacement • Remove replacement node from tree • Overwrite removed key with replacement

13. Rebalance Overview • Rebalance required if node balance outside of [-2,2] • Balance factor = left subtree height - right subtree height • Two rotations • Single • Double • Each rotation type has a mirrored version for left and right  • Four total

14. Single Rotation • Blue’s child red is promoted to parent • Blue made right child of red

15. Double Rotation • "C" shape • Single rotate green node to be parent of red node • Green > red • Single rotation from original parent node • Blue node demoted to right child of green

16. Rebalance() • Lock tree • Test each node for imbalance • If unbalanced, rebalance • If balance factor outside of normal range, rebalance on child node • Relaxed height requirement • Unlock tree

17. Agenda • Introduction • Solution Approach • Analysis • Future Work and Difficulties Encountered • Conclusion

18. Analysis • Measured unit: Throughput (operations/milliseconds) • Number of operations per thread: 50,000 • Operation set for each thread • Add = 100% • Add = 80% Contains = 20% • Add = 50% Contains = 50% • Add = 20% Contains = 80% • Vary thread count for each set of operations • 1, 2, 5, 8, 10 Threads • Each test iteration was repeated five times and averaged

19. Analysis

20. Analysis

21. Analysis

22. Analysis

23. Analysis • Course-grained lock implementation produced higher throughput for a majority of tests • Fine-grained lock implementation with more contains() calls produced higher results for low thread counts • Possible Reasons: • Implementation of how a thread traverses a tree • Rebalance halts all other threads • Rebalance may cause other threads to restart operation

24. Agenda • Introduction • Solution Approach • Analysis • Future Work and Difficulties Encountered • Conclusion

25. Future Work • Finalize remove() • Extend the fine-grained implementation to remove nodes • Optimistic Approach • Instead of halting on rebalance to finish, assume it is correct and verify before returning • ReentrantReadWrite Lock • Use a read lock for when traversing and a write lock for when modifying the node

26. Difficulties Encountered • Below is a list of difficulties encountered during implementation: • Mutual exclusion • Fairness • Deadlocks on trees • Deadlocks on nodes • Validating tree state

27. Agenda • Introduction • Solution Approach • Analysis • Future Work and Difficulties Encountered • Conclusion

28. Conclusion • Measured throughput of the fine-grained lock did not meet theoretical expectations • Overhead induced by maintaining fine-grained locks could potentially outweigh the benefit of having several threads act on the same resource • Do not reinvent the wheel

29. Questions?

30. References • S. Hanke, "The Performance of Concurrent Red-Black Tree Algorithms," Proceedings of the 3rd International Workshop on Algorithm Engineering, LNCS, vol. 1668, pp. 286-300, 1999. • C. S. Ellis, "Concurrent Search and Insertion in AVL Trees," IEEE Transactions on Computers, Vols. C-29, no. 9, pp. 811-817, 1980. • O. Nurmi, E. S. Soininen and D. Wood, "Relaxed AVL trees, main-memory databases and concurrency," International journal of computer mathematics, vol. 62, pp. 23-44, 1996.