Abstract: Many conventional lock-free data structures exploit techniques that are possible only because state-of-the-art 64-bit processors are still running 32-bit operating systems and applications. As software catches up to hardware, “64-bit-clean” lock-free data structures, which cannot use such techniques, are needed. We present several 64-bit-clean lock-free implementations: including load-linked/store conditional variables of arbitrary size, a FIFO queue, and a freelist. In addition to being portable to 64-bit software (or more generally full-architectural-width pointer operations), our implementations also improve on existing techniques in that they are (or can be) space-adaptive and do not require a priori knowledge of the number of threads that will access them.

Abstract: A computer system stores a dynamically sized array as a base array that contains references to subarrays in which the (composite) array's data elements reside. Each of the base-array elements that thus refers to a respective subarray is associated with a respective subarray size. Each base-array index is thereby at least implicitly associated with a cumulative base value equal to the sum of all preceding base indexes' associated subarray sizes. In response to a request for access to the element associated with a given (composite-array) index, the array-access system identifies the base index associated with the highest cumulative base value not greater than the composite-array index and performs the access to the subarray identified by the element associated with that base index. Composite-array expansion can be performed in a multi-threaded environment without locking, simply by employing a compare-and-swap or similar atomic operation.

Abstract: A system for controlling contention between conflicting transactions in a transactional memory system. During operation, the system receives a request to access a cache line and then determines if the cache line is already in use by an existing transaction in a cache state that is incompatible with the request. If so, the system determines if the request is from a processor which is in a polite mode. If this is true, the system denies the request to access the cache line and continues executing the existing transaction.

Abstract: We propose a class of mechanisms to support a new style of synchronization that offers simple and efficient solutions to several existing problems for which existing solutions are complicated, expensive, and/or otherwise inadequate. In general, the proposed mechanisms allow a program to read from a first memory location (called the “flagged” location), and to then continue execution, storing values to zero or more other memory locations such that these stores take effect (i.e., become visible in the memory system) only while the flagged memory location does not change. In some embodiments, the mechanisms further allow the program to determine when the first memory location has changed. We call the proposed mechanisms conditional multi-store synchronization mechanisms.

Abstract: One embodiment of the present invention provides a system that ensures that progress is made in an environment that supports execution of obstruction-free operations. During execution, when a process pi invokes an operation, the system checks a panic flag, which indicates whether a progress-ensuring mechanism is to be activated. If the panic flag is set, the progress-ensuring mechanism is activated, which causes the system to attempt to perform the operation by coordinating actions between processes to ensure that progress is made in spite of contention between the processes. On the other hand, if the panic flag is not set, the system attempts to perform the operation essentially as if the progress-ensuring mechanism were not present. In this case, if there is an indication that contention between processes is impeding progress, the system sets the panic flag, which causes the progress-ensuring mechanism to be activated so that processes will coordinate their actions to ensure that progress is made.

Abstract: We explore techniques for designing nonblocking algorithms that do not require advance knowledge of the number of processes that participate, whose time complexity and space consumption both adapt to various measures, rather than being based on predefined worst-case scenarios, and that cannot be prevented from future memory reclamation by process failures. These techniques can be implemented using widely available hardware synchronization primitives. We present our techniques in the context of solutions to the well-known Collect problem. We also explain how our techniques can be exploited to achieve other results with similar properties; these include long-lived renaming and dynamic memory management for nonblocking data structures.

Abstract: A set of structures and techniques are described herein whereby an exemplary concurrent shared object, namely a shared skip list, can be implemented in a lock-free manner. Indeed, we have developed a number of interesting variants of a lock-free shared skip-list, including variants that may be employed to provide a lock-free shared dictionary. In some variants, a key-value dictionary is implemented.

Abstract: A method for executing transactions including obtaining a memory location required by a first transaction, where the first transaction is identified using a first transaction identification and a first transaction version; determining a second transaction with ownership of a memory group including the memory location, where the second transaction is identified using a second transaction identification and a second transaction version; copying an intermediate value associated with the memory group from the second transaction into transactional metadata associated with the first transaction; changing ownership of the memory group to the first transaction; and committing the first transaction.

Abstract: One embodiment of the present invention provides a system that avoids locks by transactionally executing critical sections. During operation, the system receives a program which includes one or more critical sections which are protected by locks. Next, the system modifies the program so that the critical sections which are protected by locks are executed transactionally without acquiring locks associated with the critical sections.

Abstract: A transactional memory implementation has been developed that is capable of coordinating concurrent hardware transactional memory (HTM) and software transactional memory (STM) transactions over a unified transactional memory space. Some implementations employ hardware transactional memory, if available or suitable, to improve performance. Some exploitations include a hardware transactional memory in which, or for which, hardware-mediated transactions are augmented to include within their transactional scope (or mechanism) one or more additional transactional locations that facilitate coordination with concurrently executing software-mediated transactions (if any).

Abstract: We explore techniques for designing nonblocking algorithms that do not require advance knowledge of the number of processes that participate, whose time complexity and space consumption both adapt to various measures, rather than being based on predefined worst-case scenarios, and that cannot be prevented from future memory reclamation by process failures. These techniques can be implemented using widely available hardware synchronization primitives. We present our techniques in the context of solutions to the well-known Collect problem. We also explain how our techniques can be exploited to achieve other results with similar properties; these include long-lived renaming and dynamic memory management for nonblocking data structures.

Abstract: One embodiment of the present invention provides a system that facilitates selectively unmarking load-marked cache lines during transactional program execution, wherein load-marked cache lines are monitored during transactional execution to detect interfering accesses from other threads. During operation, the system encounters a release instruction during transactional execution of a block of instructions. In response to the release instruction, the system modifies the state of cache lines, which are specially load-marked to indicate they can be released from monitoring, to account for the release instruction being encountered. In doing so, the system can potentially cause the specially load-marked cache lines to become unmarked. In a variation on this embodiment, upon encountering a commit-and-start-new-transaction instruction, the system modifies load-marked cache lines to account for the commit-and-start-new-transaction instruction being encountered.

Abstract: Transactional programming promises to substantially simplify the development and maintenance of correct, scalable, and efficient concurrent programs. Designs for supporting transactional programming using transactional memory implemented in hardware, software, and a mixture of the two have emerged recently. However, various features and capabilities that would be desirable for debugging programs executed using transactional memory are absent from conventional debuggers. Because transactional memory implementations provide the “illusion” of multiple memory locations changing value atomically, while in fact they do not, there can be significant challenges involved with integrating debuggers with such programs to provide the user with a coherent view of program execution. We describe use of transactional memory access tracking mechanism for implementations of watchpoints on memory locations that correspond to transactional variables.

Abstract: A computer system implementing transient blocking synchronization allows a memory location leased by a first process to be read-accessible to another process. In other words, more than one thread may have read-only type leases on a given memory location at a given time. Such “shared” leases expire when respective lease periods of the shared leases elapse.

Abstract: A computer system uses transient blocking synchronization for performing operations on shared memory. When performing operations on more than one memory location, the computer system obtains transient exclusive access to a first memory location. The computer system then obtains transient exclusive access to a second memory location, where the transient exclusive access to the second memory location does not expire prior to an expiration of the transient exclusive access to the first memory location or until explicitly unleased.

Abstract: A method for inserting an object into a concurrent set including obtaining a key associated with the object, traversing the concurrent set using a first thread containing the key, identifying a first insertion point while traversing the concurrent set, where the first insertion point is before a current node and after a predecessor node, obtaining a first lock for the predecessor node after identifying the first insertion point, validating the predecessor node and the current node after obtaining the lock, inserting a new node into the concurrent set after validating, where the new node is associated with the object, and releasing the first lock after inserting the new node.

Abstract: 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. An interesting feature of our obstruction-free STM implementation is its ability to use of modular contention managers to ensure progress in practice.

Abstract: Transactional programming promises to substantially simplify the development and maintenance of correct, scalable, and efficient concurrent programs. Designs for supporting transactional programming using transactional memory implemented in hardware, software, and a mixture of the two have emerged recently. However, certain features and capabilities that would be desirable for debugging programs executed using transactional memory are absent from conventional debuggers. Breakpointing is one example of a capability not well supported when conventional debugging technology is applied to transactional memory. We describe techniques by which a debugger may instrument code (or by which a TM library may provide functionality) to direct execution of an atomic block to a code path that facilitates breakpoint handling.

Abstract: Transactional programming promises to substantially simplify the development and maintenance of correct, scalable, and efficient concurrent programs. Designs for supporting transactional programming using transactional memory implemented in hardware, software, and a mixture of the two have emerged recently. Unfortunately, conventional debugging programs are often inadequate when employed in relation to code that employs transactional memory and new or modified techniques are needed. Implementations of delayed breakpoints are described that provide programmers with the benefits of breakpoints in transactional code, while minimizing the side-effects of breakpoints placed inside atomic block.

Abstract: Transactional programming promises to substantially simplify the development and maintenance of correct, scalable, and efficient concurrent programs. Designs for supporting transactional programming using transactional memory implemented in hardware, software, and a mixture of the two have emerged recently. However, various features and capabilities for debugging programs executed using transactional memory are absent from conventional debuggers. Because transactional memory implementations provide the “illusion” of multiple memory locations changing value atomically, there are challenges involved with integrating debuggers with such programs to provide the user with a coherent view of program execution. For instance, when execution is halted for debugging, a user may request to view a transactional variable or memory location. The transactional variable or memory location may have a pre-transaction value and a tentative value.