We propose a new form of software transactional memory (STM) designed to support dynamic-sized data structures, and we describe a novel non-blocking implementation. The non-blocking property we consider is obstruction-freedom. Obstruction-freedom is weaker than lock-freedom; as a result, it admits substantially simpler and more efficient implementations. A novel feature of our obstruction-free STM implementation is its use of modular contention managers to ensure progress in practice. We illustrate the utility of our dynamic STM with a straightforward implementation of an obstruction-free red-black tree, thereby demonstrating a sophisticated non-blocking dynamic data structure that would be difficult to implement by other means. We also present the results of simple preliminary performance experiments that demonstrate that an "early release " feature of our STM is useful for reducing contention, and that our STM lends itself to the effective use of modular contention managers.

Despite years of research, the design of efficient nonblocking algorithms remains difficult. A key reason is that current shared-memory multiprocessor architectures support only single-location synchronisation primitives such as compareand-swap (CAS) and load-linked/store-conditional (LL/SC). Recently researchers have investigated the utility of doublecompare-and-swap (DCAS)—a generalisation of CAS that supports atomic access to two memory locations—in overcoming these problems. We summarise recent research in this direction and present a detailed case study concerning a previously published nonblocking DCAS-based doubleended queue implementation. Our summary and case study clearly show that DCAS does not provide a silver bullet for nonblocking synchronisation. That is, it does not make the design and verification of even mundane nonblocking data structures with desirable properties easy. Therefore, our position is that while slightly more powerful synchronisation primitives can have a profound effect on ease of algorithm design and verification, DCAS does not provide sufficient additional power over CAS to justify supporting it in hardware.

Abstract. The obstruction-free progress condition is weaker than previous nonblocking progress conditions such as lock-freedom and waitfreedom, and admits simpler implementations that are faster in the uncontended case. Pragmatic contention management techniques appear to be effective at facilitating progress in practice, but, as far as we know, none guarantees progress. We present a transformation that converts any obstruction-free algorithm into one that is wait-free when analyzed in the unknown-bound semisynchronous model. Because all practical systems satisfy the assumptions of the unknown-bound model, our result implies that, for all practical purposes, obstruction-free implementations can provide progress guarantees equivalent to wait-freedom. Our transformation preserves the advantages of any pragmatic contention manager, while guaranteeing progress. 1

Abstract. This paper presents lower bounds on the time- and spacecomplexity of implementations that use the k compare-and-swap (k-CAS) synchronization primitives. We prove that the use of k-CAS primitives cannot improve neither the time- nor the space-complexity of implementations of widely-used concurrent objects, such as counter, stack, queue, and collect. Surprisingly, the use of k-CAS may even increase the space complexity required by such implementations. We prove that the worst-case average number of steps performed by processes for any n-process implementation of a counter, stack or queue object is Ω(log k+1 n), even if the implementation can use j-CAS for j ≤ k. This bound holds even if a k-CAS operation is allowed to read the k values of the objects it accesses and return these values to the calling process. This bound is tight. We also consider more realistic non-reading k-CAS primitives. An operation of a non-reading k-CAS primitive is only allowed to return a success/failure indication. For implementations of the collect object that use such primitives, we prove that the worst-case average number of steps performed by processes is Ω(log 2 n), regardless of the value of k. This implies a round complexity lower bound of Ω(log 2 n) for such implementations. As there is an O(log 2 n) round complexity implementation of collect that uses only reads and writes, these results establish that non-reading k-CAS is no stronger than read and write for collect implementation round complexity. We also prove that k-CAS does not improve the space complexity of implementing many objects (including counter, stack, queue, and singlewriter snapshot). An implementation has to use at least n base objects even if k-CAS is allowed, and if all operations (other than read) swap exactly k base objects, then the space complexity must be at least k · n. 1

We present PermiSTM, a single-version STM that satisfies a practical notion of permissiveness, usually associated with keeping many versions: it never aborts read-only transactions, and it aborts other transactions only due to a conflicting transaction (which writes to a common item), thereby avoiding spurious aborts. It avoids unnecessary contention on the memory, being strictly disjoint-access parallel. 1

Abstract. We present PermiSTM, a single-version STM that satisfies a practical notion of permissiveness, usually associated with keeping many versions: it never aborts read-only transactions, and it aborts other transactions only due to a conflicting transaction (which writes to a common item), thereby avoiding spurious aborts. It avoids unnecessary contention on the memory, being strictly disjointaccess parallel. 1

We present a single-version STM that satisfies a practical notion of permissiveness: it never aborts read-only transactions, and it only aborts an update transaction due to another conflicting update transaction, thereby avoiding many spurious aborts. It avoids unnecessary contention on the memory, being strictly disjoint-access parallel. Categories and Subject Descriptors D.1.3 [Software]: Programming Techniques—Concurrent