A Deadlock-free Multi-granular, Hierarchical Locking Scheme for Real-time Collaborative Editing. Jon A. Preston Sushil K. Prasad

Transcription

1 A Deadlock-free Multi-granular, Hierarchical Locking Scheme for Real-time Collaborative Editing Jon A. Preston Sushil K. Prasad

2 Agenda Motivation Related Work in Collaborative Editing Systems The Tree Data Structure Properties and Algorithms InsertUser (with demotion RemoveUser (with promotion Conclusions and Future Work 2of 25

3 Motivation Collaborative Editing Systems (CES concurrency control falls into two approaches Optimistic Pessimistic Our scheme is a hybrid of these approaches Avoid transformation/merge problems of optimistic Provide high level of concurrency/access Locking is automatic (transparent to user 3of 25

4 Related Work Increase parallelism in software engineering [10] and avoid bottleneck of traditional CMS [3] Avoids explicit turn-taking or system-specific approach [1], [11], and [12] Transparent to user [4], [5], [6], and [13] Avoids the merge problem [8] Provides multi-granular, hierarchical locking [7] Flexible, open-systems, Web-services based approach [2], [14] and [15] 4of 25

5 The Tree Structure Structure denotes sections and sub-sections Only leaf nodes contain satellite data All access requests from client will reference a specific leaf node (as the client knows only of document content, not tree Nodes store ownership/lock information If a section of the document is owned by a user u, then all subsections (i.e. child nodes in the tree are also owned by the same user u. Similarly, if a section of the document is not owned by any user, then all subsections (i.e. child nodes in the tree are also not owned by any. 5of 25

6 Mappings It is possible to map a document to a tree and from this tree to a binary tree Without loss of generality, our algorithms work on this binary tree Title (t artif Paragraph A (p a Title A1 (t a1 Paragraph A1 (p a1 Paragraph A11 (p a11 Paragraph A12 (p a12 Paragraph A2 (p a2 Paragraph A3 (p a3 Paragraph B (p b t artif p a p b t a1 p a1 p a2 p a11 p a12 p a3 t artif p a t a1 p a1 p a11 p b p a12 p a2 p a3 6of 25

7 Maintaining the Largest Sub-tree It is desirable to own the largest sub-tree possible Can keep cached changes local Reduces network messaging Only give up an owned portion of the tree when another user enters and injects contention (demotion 7of 25

8 Enter/Leave Document To clarify, we assume Users can enter and leave the document at any time To move from one section of the document to another, leave current section and enter new section (leave and reenter document This is seamless/transparent to the user (i.e. the system removes and re-adds the user without informing the user Issues of performance and cache optimization are still open for our research 8of 25

9 Concurrent Reading/Sharing As with other CES/CSCW systems, sharing is permissible This paper/presentation addresses exclusive write access Certainly, concurrent read access is permissible Updating the view of read-only clients upon a change would occur as it does in other systems 9of 25

10 Path Finding Since each node is uniquely identified, it is always possible to know the path to a node in the tree Left = 0 Right = 1 Node of 25

11 The Node Structure The node structure contains Left and right children Sibling Color (white, black, grey Owner (if black, what user owns this sub-tree Original Request (what sub-tree node was requested to cause ownership of this node 11 of 25

12 Coloring White Unowned All sub-tree nodes are white logically Black Owned All sub-tree nodes are black logically Grey Grey-color 2 There must exist 2 black nodes in the sub-trees Possible grey configurations: 12 of 25

13 Algorithms Deadlock-free Always traverse top to bottom [9] Handshake lock Acquire node Acquire node s child Release node Insert User Remove User 13 of 25

14 InsertUser User u i requests lock on node w All nodes in the path from t to v must be grey If white, lock higher If black, lock fails Increase grey-color in path If contention on w Demote w If w is leaf undo inflated grey color β α t v InsertUser(w w α β t v w 14 of 25

15 InsertUser - Demotion At times, demotion is necessary When the top-to-bottom access encounters a black node Push the ownership down (if a leaf, fail Requires that we maintain originalrequest (i.e., why is this node black t t Paint node grey Recursion if we push along the same path to requested node α u 2 v InsertUser(w, u 1 α v u 2 u 1 15 of 25 x w x w

16 16 of 25 InsertUser InsertUser(w, u i if w.owner u i RecurseInsert(root, w, u i RecurseInsert(n, w, u i if n.color = white // ensures we always acquire largest lock then SetOwner(n, u i, w else if n is a leaf node // a leaf node but not white, so failed insert (i.e. we can t demote a leaf then RecurseRemove(root, w, u i // undo the false insert s effect on greycolors return failure else if n.color = grey // keep looking down then n.greycolor = n.greycolor + 1 else RecurseInsert(NextInPath(n, w, w, u i // color of node in path to w is black, so we must demote it b = NextInPath(n, w a = NextInPath(n, n.originalrequest SetOwner (a, n.owner, n.originalrequest // demote n to a n.color = grey n.greycolor = 2 if a b SetOwner(w, u i, r w.color = black w.owner = u i w.originalrequest = r then else SetOwner (b, u i, w // the nodes are in separate paths RecurseInsert(b, w, u i // the nodes are in the same path

17 RemoveUser User u i releases lock on node w All nodes in the path from t to v must be grey If white, lock higher If black, release higher Decrease grey-color in path Promote if possible when grey-color goes from 2 to 1 17 of 25

18 RemoveUser Cases With promotion Without promotion 2 t RemoveUser(w 1 t u i v u j w u i v w 3 t RemoveUser(w 2 t Promote(v 2 v w 2 v w u i t v w 18 of 25

19 RemoveUser Promotion When grey-color reduces from 2 to 1, promote 4 3 v v 2 2 RemoveUser(w, u1 2 u w u 2 u 1 19 of 25

20 RemoveUser RemoveUser(w, u i if w.owner = u i then RecurseRemove(root, w, u i RecurseRemove(n, w, u i if n.color = black and n.owner = u i then ReleaseOwner(n else if n.color = grey // keep looking down then n.greycolor = n.greycolor 1 if n.greycolor = 1 and w.sibling.color = black // sibling promotion priority then SetOwner(n, w.sibling.owner, w.sibling else if n.greycolor = 1 and w.color = black // w must be all that remains then SetOwner(n, w.owner, w else if n.greycolor = 0 and // paint n white as w and w.sibling are white then ReleaseOwner(n else RecurseRemove(NextInPath(n,w, w, u i ReleaseOwner(w w.color = white w.owner = NIL w.originalrequest = NIL 20 of 25

21 RemoveUser Special Cases If an insertion failed, then we invoke a RemoveUser to reduce the artificially-inflated grey-count along the path from root to desired node It is possible that legitimate removals occurred between the time of the failed insertion and the concomitant removal (to compensate for the failed insertion Consequently, the grey-count of a node can fall to 1 Promote sibling or the node associated with the failed insert Additionally, the grey-count of a node could fall to 0 Promote nothing (everything is now removed below this node Paint this node white 21 of 25

22 Analysis RemoveUser makes a single pass of the tree from top to bottom O(h where h is equal to the height of the tree. InsertUser can fail and require an undo of the artificially-inflated grey-colors (via a call to RemoveUser Thus at most two passes of the tree from top to bottom Also O(h where h is equal to the height of the tree Promotion occurs in O(1 because we know the sibling is to be promoted (or in the special cases, the failed insert node is promoted or nothing is promoted 22 of 25

23 Conclusion Contributes hybrid concurrency policy to the field of CSCW/CES Deadlock-free Multi-granular, hierarchical locking Maximizes sub-tree owned Minimizes messaging/communication Insert and remove algorithms efficient O(h Promotion is efficient O(1 23 of 25

24 Future Work Address tree modification Insert obtain lock on parent, then insert below Delete obtain lock on node and remove Split obtain lock on node and create children Join obtain lock on both nodes and combine Move this is a delete + insert Simulation in progress Further define cache policies for concurrent readers Place into larger framework of open-system, Web services based architecture and simulate editing 24 of 25

25 References 1. Netbeans Collaboration Project. Sun Microsystems. Viewed August, V. Bharadwaj and Y.V. R. Reddy. A Framework to Support Collaboration in Heterogeneous Environments. SIGGROUP Bulletin. Vol 24, No 3. December pp M. Chu-Carroll, J. Wright, and D. Shields. Supporting Aggregation in Fine Grained Software Configuration Management. SIGSOFT 2002/FSE-10. Charleston, SC. November M. Chu-Carroll and S. Sprenkle. Coven: Brewing Better Collaboration through Software Configuration Management. SIGSOFT San Diego, CA. November C. Ellis and S. Gibbs. Concurrency Control in Groupware Systems. In Proceedings of ACM SIGMOD Conference on Management of Data, pages ACM Press, May S. Greenberg and D. Marwood. Real Time Groupware as a Distributed System: Concurrency Control and its Effect on the Interface. In Proceedings ACM Conferences on Computer Supported Cooperative Work, pages ACM Press, Nov B. Magnusson, U. Asklund, S. Minör. Fine-Grain Revision Control for Collaborative Development. Proceedings of ACM SIGSOFT 93. Los Angeles, CA. December J. Munson and P. Dewan. A Concurrency Control Framework for Collaborative Systems. Proceedings Computer Supported Cooperative Work, pages ACM Press, Nov V. N. Rao and V. Kumar. Concurrent Access of Priority Queues. IEEE Transactions on Computers. Vol 37, No 12. pp C. O Reilly. A Weakly Constrained Approach to Software Change Coordination. In Proceedings of the 26th International Conference on Software Engineering H. Shen, C. T. Cheong, and C. Sun. CoStarOffice: Toward a Flexible Platform-independent Collaborative Office System. IWCES D. Sun, S. Xia, C. Sun, and D. Chen. Operational Transformation for Collaborative Word Processing. CSCW 04. Chicago, IL. November CHI Letters. Vol 6, Issue 3. pp A.van der Hoek, D. Redmiles, P. Dourish, A. Sarma, R. S. Filho, and C. de Souza. Continuous Coordination: A New Paradigm for Collaborative Software Engineering Tools. Workshop on Directions in Software Engineering Environments. ICSE Y. Yang and D. Li. Separating Data and Control: Support for Adaptable Consistency Protocols in Collaborative Systems. Proceedings of CSCW 04. Chicago, IL. November CHI Letters. Vol 6, Issue 3. pp M. Younas and R. Iqbal. Developing Collaborative Editing Applications using Web Services. IWCES B. P. Zeigler and H.S. Sarjoughian. Introduction to DEVS Modeling & Simulation with JAVA: Developing Component-based Simulation Models. Technical Document, University of Arizona of 25