Skip to main content
Log in

Built-in Coloring for Highly-Concurrent Doubly-Linked Lists

  • Published:
Theory of Computing Systems Aims and scope Submit manuscript

Abstract

This paper presents a novel approach for highly-concurrent nonblocking implementations of doubly-linked lists, based on dynamically maintaining a coloring of the nodes in the list. In these implementations, operations on non-adjacent nodes in the linked-list proceed without interfering with each other. Roughly speaking, the operations are implemented by acquiring nodes in the operation’s data set, in the order of their colors, and then making the changes atomically. The length of waiting chains is restricted, thereby increasing concurrency, because the colors are taken from a small set. Operations carefully update the colors of the nodes they modify, so neighboring nodes in the list have different colors. A helping mechanism ensures progress in small neighborhoods of processes that keep taking steps.

We use this approach in two new algorithms: CAS-Chromo uses an unary conditional primitive, cas, and allows insertions anywhere in the linked list and removals only at the ends, while DCAS-Chromo allows insertions and removals anywhere but uses a stronger primitive, dcas.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Pseudocode 1
Pseudocode 2
Pseudocode 3
Pseudocode 4
Fig. 8
Pseudocode 5

Similar content being viewed by others

Notes

  1. This is similar to the way an operation is invalidated before releasing its nodes in [4].

References

  1. Afek, Y., Merritt, M., Taubenfeld, G., Touitou, D.: Disentangling multi-object operations. In: Proceedings of the 16th Annual ACM Symposium on Principles of Distributed Computing (PODC), pp. 111–120 (1997)

    Google Scholar 

  2. Agesen, O., Detlefs, D.L., Flood, C.H., Garthwaite, A.T., Martin, P.A., Shavit, N., Steele, G.L.: DCAS-based concurrent deques. Theory Comput. Syst. 35(3), 349–386 (2002)

    Article  MathSciNet  MATH  Google Scholar 

  3. Arora, N.S., Blumofe, R.D., Plaxton, C.G.: Thread scheduling for multiprogrammed multiprocessors. Theory Comput. Syst. 34(2), 115–144 (2001)

    MathSciNet  MATH  Google Scholar 

  4. Attiya, H., Dagan, E.: Improved implementations of binary universal operations. J. ACM 48(5), 1013–1037 (2001)

    Article  MathSciNet  Google Scholar 

  5. Attiya, H., Hillel, E.: Highly concurrent multi-word synchronization. Theor. Comput. Sci. 412(12–14), 1243–1262 (2011)

    Article  MathSciNet  MATH  Google Scholar 

  6. Attiya, H., Welch, J.: Distributed Computing: Fundamentals, Simulations and Advanced Topics, 2nd edn. Wiley-Interscience, New York (2004)

    Google Scholar 

  7. Barnes, G.: A method for implementing lock-free shared-data structures. In: Proceedings of the 5th Annual ACM Symposium on Parallel Algorithms and Architectures (SPAA), pp. 261–270 (1993)

    Google Scholar 

  8. Detlefs, D., Flood, C.H., Garthwaite, A., Martin, P., Shavit, N., Steele, G.L. Jr.: Even better DCAS-based concurrent deques. In: Proceedings of the 14th International Conference on Distributed Computing (DISC), pp. 59–73 (2000)

    Google Scholar 

  9. Doherty, S., Detlefs, D.L., Groves, L., Flood, C.H., Luchangco, V., Martin, P.A., Moir, M., Shavit, N., Steele, G.L. Jr.: DCAS is not a silver bullet for nonblocking algorithm design. In: Proceedings of the 16th Annual ACM Symposium on Parallelism in Algorithms and Architectures (SPAA), pp. 216–224 (2004)

    Google Scholar 

  10. Fich, F.E., Luchangco, V., Moir, M., Shavit, N.: Obstruction-free step complexity: Lock-free DCAS as an example. In: Proceedings of the 19th International Symposium on Distributed Computing (DISC), pp. 493–494 (2005)

    Google Scholar 

  11. Greenwald, M.: Non-blocking synchronization and system design. PhD thesis, Stanford University, August 1999

  12. Greenwald, M.: Two-handed emulation: how to build non-blocking implementations of complex data-structures using DCAS. In: Proceedings of the 21st Annual Symposium on Principles of Distributed Computing (PODC), pp. 260–269 (2002)

    Google Scholar 

  13. Ha, P.H., Tsigas, P., Wattenhofer, M., Wattenhofer, R.: Efficient multi-word locking using randomization. In: Proceedings of the 24th Annual ACM Symposium on Principles of Distributed Computing (PODC), pp. 249–257 (2005)

    Google Scholar 

  14. Harris, T.L.: A pragmatic implementation of non-blocking linked-lists. In: Proceedings of the 15th International Conference on Distributed Computing (DISC), pp. 300–314 (2001)

    Google Scholar 

  15. Harris, T.L., Fraser, K.: Language support for lightweight transactions. In: Proceedings of the 2003 ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA), pp. 388–402 (2003)

    Google Scholar 

  16. Herlihy, M., Wing, J.M.: Linearizability: a correctness condition for concurrent objects. ACM Trans. Program. Lang. Syst. 12(3), 463–492 (1990)

    Article  Google Scholar 

  17. Herlihy, M., Luchangco, V., Moir, M.: Obstruction-free synchronization: Double-ended queues as an example. In: Proceedings of the 23rd International Conference on Distributed Computing Systems (ICDCS), pp. 522–529 (2003)

    Google Scholar 

  18. IBM. IBM System/370 Extended Architecture, Principle of Operation. IBM Publication No. SA22-7085 (1983)

  19. Merritt, R.: IBM plants transactional memory in CPU. EETimes, August 2011. http://www.eetimes.com/electronics-news/4218914/IBM-plants-transactional-memory-in-CPU

  20. Michael, M.M.: High performance dynamic lock-free hash tables and list-based sets. In: Proceedings of the 14th Annual Symposium on Parallelism in Algorithms and Architectures (SPAA), pp. 73–82 (2002)

    Google Scholar 

  21. Michael, M.M.: CAS-based lock-free algorithm for shared deques. In: Proceedings of the 9th Euro-Par Conference on Parallel Processing, pp. 651–660 (2003)

    Google Scholar 

  22. Reinders, J.: Transactional synchronization in Haswell, February 2012. http://software.intel.com/en-us/blogs/2012/02/07/transactional-synchronization-in-haswell/

  23. Schneider, J., Wattenhofer, R.: Bounds on contention management algorithms. In: Proceedings of the 20th International Symposium on Algorithms and Computation (ISAAC), pp. 441–451 (2009)

    Chapter  Google Scholar 

  24. Shavit, N., Touitou, D.: Software transactional memory. Distrib. Comput. 10(2), 99–116 (1997)

    Article  Google Scholar 

  25. Sundell, H.: Efficient and practical non-blocking data structures. PhD thesis, Chalmers University of Technology (2004)

  26. Sundell, H., Tsigas, P.: Lock-free deques and doubly linked lists. J. Parallel Distrib. Comput. 68(7), 1008–1020 (2008)

    Article  MATH  Google Scholar 

  27. Turek, J., Shasha, D., Prakash, S.: Locking without blocking: making lock based concurrent data structure algorithms nonblocking. In: Proceedings of the 11th ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS), pp. 212–222 (1992)

    Google Scholar 

Download references

Acknowledgements

We thank David Hay, Danny Hendler, Gadi Taubenfeld and the anonymous referees for helpful comments. This research was supported by the Israel Science Foundation (grants 1344/06 and 1227/10).

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Hagit Attiya.

Appendices

Appendix A: Proofs of Lemmas 1 and 2

Lemma 1

An operation op successfully applies changes only when it is in apply phase, and only to nodes in op’s last data set memento.

Proof

An executing process of op that calls applyChanges first verifies that the operation is in the apply phase (line 22), implying that this is the last round of the operation, and it holds the last data set memento. Since an operation changes only nodes in its data set memento, executing processes apply the same changes on the same nodes (from the last data set memento).

Let p j be the process that advances op from apply phase to release phase (line 24). Before changing the state, p j executes applyChanges (line 23), thus cas is applied at least once to each of the attributes based on values in the node mementos (see the code in Pseudocode 3), prior to the state transition. Once a cas is applied successfully the attribute is inconsistent with its memento since at least the ABA-prevention counter has changed. If after the transition another process p i applies cas to some attribute while applying op’s changes, p i ’s cas fails. □

In order to prove Lemma 2(1–4), it is helpful to inductively carry two additional claims (5 and 6).

Lemma 2′

(extended) The following claims all hold for every operation op:

  1. 1.

    If op acquires a node t in the r-th round, then the r-th memento of t in op’s data set is valid and t, excluding t’s owner, has not changed after it was cloned by op in the r-th round.

  2. 2.

    op advances from the r-th acquire phase to the r-th apply phase only if all the nodes in its data set are consistent with the r-th data set memento, and are acquired by op.

  3. 3.

    op only applies changes to nodes that are acquired by it.

  4. 4.

    op releases nodes only when it is in release phase, and during its r-th release phase it only releases nodes it has acquired in the r-th round.

  5. 5.

    op acquires nodes only when it is in acquire phase, and during its r-th acquire phase it only acquires nodes that are in its r-th data set memento.

  6. 6.

    When an executing process of op returns from acquireColor(c,r), either all nodes with color c in the r-th data set memento are acquired by op, or op is not in the r-th acquire phase.

Proof

The claims are proved simultaneously by induction on the execution length. In the base case, the empty execution, all claims vacuously hold. In the induction step, we consider each claim:

  1. 1.

    If the r-th memento of a node t in op’s data set is invalid no executing process tries to acquire t in the r-th round (line 37, and line 52).

    Now, assume t has changed after op cloned it in the r-th round, and that p i , an executing process of op calls acquireColor(c,r), where c is the color of t. If the change occurs before p i verifies t is consistent with its memento (line 37), then p i does not try to acquire t. Otherwise the change occurs after verifying the consistency, and in particular after p i reads the content of t’s owner (line 36). By Lemma 1, the change is applied by an operation op′ in its apply phase. By (3), t is owned by op′ when applying the change. If op′ acquired t before p i reads the content of t’s owner, then by (4) it is not released until after op′ applied the changes, i.e., until after p i reads the owner, then p i does not try to acquire t. Otherwise, op′ acquired t after p i reads t’s owner, in this case, p i fails acquiring t’s owner, since the ABA-prevention counter has changed.

  2. 2.

    A transition of op from the r-th acquire phase to the r-th apply phase by an executing process occurs only after the executing process calls acquireColor(c,r) with all colors from the r-th color set while op is in the r-th acquire phase. By (6), when returning from each such round, all relevant nodes are acquired by op, and by (4), they were not released since then. As the set of colors includes all nodes in the r-th data set memento, they are all owned by op while the transition occurs. By (1), no node in the r-th data set memento is changed before op advances to the apply phase. So, when the transition occurs all nodes in the r-th data set memento are acquired by op, and they are consistent with their mementos.

  3. 3.

    By Lemma 1, op only applies changes while it is in apply phase and only to nodes that are in the last data set memento. By (2), when the transition to apply phase occurs all nodes in the r-th (last) data set memento are acquired by op, and by (4), it does not release the nodes while it is in the apply phase, implying that op changes a node only while owning it.

  4. 4.

    The transition of op from the r-th release phase to the r-th final phase (line 14) by the initiator of op, p, occurs after p calls the releaseDataset method (line 25), to release all nodes in the r-th data set memento (line 28). All processes executing the r-th round try to release the same nodes from the r-th data set memento, since by (5), op only acquires nodes from the r-th data set memento in the r-th round. When a process p i releases op’s data set while executing the r-th round of op, it reads the owner on a node t (line 29), and tries to release t (line 31) after verifying that op is in the release phase and t is owned by op in its r-th round (line 30). It can be easily verified from the code that after p completes the releaseDataset method all the nodes that were acquired by op are released. Thus, if p i tries to release the nodes after the transition occurs, the cas fails since the ABA-prevention counter has changed.

  5. 5.

    Consider an executing process p i executing the r-th round of op. First p i reads t from op’s r-th data set memento (line 34); then p i reads t’s owner (line 36); verifies that t’s memento is valid (line 37); and that op is in the r-th acquire phase (line 38). Let p j be the executing process that advances op from the r-th acquire phase either to the r-th apply phase or to the r-th release phase. Assume the transition occurs after p i verifies the phase, and specifically after it reads t’s owner, but before p i tries to acquire t (line 40). If p j advances op to the r-th apply phase, by (2) all nodes in the r-th data set memento, including t, are acquired by op when p j makes the transition. Thus either p i discovers that t is owned by op or it fails acquiring t’s owner, since at least the ABA-prevention counter has changed.

    Otherwise, p j advances to the r-th release phase since it discovers that some node t′ in the r-th data set memento is inconsistent with its memento (line 37 or line 43). There are three cases depending on the order between the colors of the nodes:

    1. (i)

      t′ and t have the same color. Before the transition occurs, p j violates the owners of both nodes by “touching” their ABA-prevention counter (line 52). By (1), since t changed while op is in the r-th acquire phase, p i cannot successfully acquire it in this round.

    2. (ii)

      t′ has lower color than t. Thus, p i executes acquireColor(c′,r), where c′ is the color of t′, before trying to acquire t. By (6), t′ was acquired by op and by (1), it has not changed while op is in the r-th acquire phase, which contradicts the assumption that p j discovers it is inconsistent with its memento.

    3. (iii)

      t′ has higher color than t. Thus, p j executes acquireColor(c,r), where c is the color of t, before discovering the change in t′. By (6), t was acquired by op. Thus either p i discovers that t is owned by op or it fails acquiring t, since at least the ABA-prevention counter has changed.

  6. 6.

    An executing process of op that executes acquireColor(c,r) returns from the method in one of three cases: Two cases are when it recognizes a change in the state (line 38 or line 44), and it is evident by the state diagram that when returning from the method, op is no longer in the r-th acquire phase. The third case is after verifying all the nodes with color c in the r-th data set memento are acquired by op (line 42). Now, if when returning from the method some of the nodes are not owned by op, then, by (4), they are released by the operation that acquired them, while it is in release phase, so this case also satisfies the condition. □

Appendix B: Proof of Lemma 3

Recall that a node is valid if it is an anchor or both its left and right links are not null.

The proof is by induction on the execution order. In the base case, the linked list is empty: the left anchor is colored c 1 and the right anchor is colored c 3, and hence, they are legally colored.

Induction step: a node can become illegally colored only when some operation applies its changes to the node or one of its neighbors. By Lemma 2(3), an operation changes a node only if it owns it. This implies that no node is inserted or removed immediately to the left or to the right of an operation data set while the operation applies its changes. Moreover, by the above observation a pop and remove operations only change the color of the right node in the data set and an insert or push operations only change the color of the new, i.e., middle, node in the data set. Thus, we can derive the next claim:

Claim

An operation changes a node’s color only if it holds the node and its left neighbor.

We analyze every step in the apply phase of an operation, and we show that after each such step the node that was changed is still legally colored. Consider first the PushLeft operation presented in Fig. 9. The data set of the operation, op 1, is the new node (m), the left anchor (LA), and its right neighbor (m 1). While op 1 is applying its changes, other operations neither remove nor insert nodes to the right of the right neighbor node, and also do not change the colors of the nodes in the data set. The claim implies that other operations do not change the color of an additional right neighbor (m 2). For PushRight or insert operations, the induction assumption also implies that a left neighbor is legally colored even if its color is changed by another operation. It remains to show, by inspecting the code, that the changes applied by the operation keep the nodes legally colored.

Line 75:

update right link of the new node: the new node is not yet valid (Fig. 9(b));

Fig. 9
figure 14

Example: the applyChanges method for PushLeft operation (Pseudocode 3). Given the nodes LA,m 1,m 2 from Fig. 3, op 1 pushes a new node, m, into the left side of the list

Line 76:

update left link of the new node: the new node is valid and it is legally colored (Fig. 9(c));

Line 77:

the new node is assigned with a non-temporary color different than its neighbors and the new node is legally colored (Fig. 9(d));

Line 78:

update left link of the right neighbor (m 1): the right neighbor has color different than the colors of the new node and the right neighbor (m 2), and thus it is legally colored (Fig. 9(e)).

Line 79:

update right link of the left anchor (or the source node in the case of an insertRight operation): the left anchor has color different than the color of the new node (in the case of an insertRight operation the source node also has color different than the color of the left neighbor), and thus it is legally colored (Fig. 9(f));

We next analyze the PopLeft operation (see Fig. 10). The data set of the operation, op 2, is the left anchor (LA) and its right neighbors (m 1 and m 2). While op 2 is applying its changes, other operations neither remove nor insert nodes to the right of the right neighbor, and also do not change the colors of the nodes in the data set. The claim implies that other operations do not change the color of an additional right neighbor (m 3). For a PopRight operation, the induction assumption implies that the left neighbor is legally colored even if its color is changed by another operation. We show again that the operation’s changes keep the nodes legally colored:

Line 85:

the right neighbor (m 2) is assigned with the temporary color: the right neighbor is legally colored, since the subject node (m 1) and the right neighbor (m 3) have colors different than the temporary color (Fig. 10(b));

Fig. 10
figure 15

Example: the applyChanges method for PopLeft operation (Pseudocode 3). Given the nodes LA,m 1,m 2,m 3 from Fig. 3, op 2 pops the node m 1

Line 86:

update right link of the left anchor (m 2): the left anchor has a non-temporary color, and thus it is legally colored (Fig. 10(c));

Line 87:

update left link of the right neighbor: the right neighbor is legally colored, since the left anchor and the adjacent node to the right have colors different than the temporary color (Fig. 10(d));

Line 88:

set right link of the subject node to null: the subject node is now invalid (Fig. 10(e));

Line 89:

set left link of the subject node to null: the subject node is invalid (Fig. 10(e));

Line 90:

the right neighbor is assigned with a non-temporary color different than its neighbors, and thus it is legally colored (Fig. 10(f)).

It remains to show that the remove operation keeps the coloring legal (see Fig. 11). The remove operation manipulates its data set in a manner similar to the pop operation. We analyze the Remove operation, op 4, presented earlier in Fig. 3. Figure 11(a) presents the nodes m 2,m 3,m 4,m 5,m 6 from Fig. 3, op 4 removes the source node m 4. The data set of the operation is the source node and its neighbors (m 3 and m 5). During the acquire phase, op 4 first acquires m 4, and then atomically acquires m 3 and m 5, which are equally colored. While op 4 is applying its changes, other operations neither remove nor insert nodes to the left of the left neighbor and to the right of the right neighbor, and also do not change the colors of the nodes in the data set. The claim implies that other operations do not change the color of an additional right neighbor (m 6). Moreover, the left neighbor (m 2) is legally colored even if its color is changed by another operation, while op 4 is applying its changes. The detailed description follows along the same lines as the PopLeft operation.

Fig. 11
figure 16

Example: an execution of a Remove operation—op 4 from Fig. 3

Rights and permissions

Reprints and permissions

About this article

Cite this article

Attiya, H., Hillel, E. Built-in Coloring for Highly-Concurrent Doubly-Linked Lists. Theory Comput Syst 52, 729–762 (2013). https://doi.org/10.1007/s00224-012-9420-5

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00224-012-9420-5

Keywords

Navigation