Transactional memory

About: Transactional memory is a research topic. Over the lifetime, 2365 publications have been published within this topic receiving 60818 citations.

Approximate Count and Queue Objects in Transactional Memory

Abstract: In Transactional Memory each shared object can be accessed by concurrent transactions which may result to object access conflicts and aborts. Opacity is a precise consistency property which maps a concurrent execution to a legal sequential execution that preserves the real time order of events. However, having precise consistency may result in a large rate of aborts especially in systems that have frequent memory updates. In real applications, there are systems that do not require precise consistency especially when the data is not sensitive. As a means for relaxing consistency, we use the notion of K-opacity where transactions are allowed to read one of the K most recent written values to the objects (and not the latest value only). This increases the throughput and reduces the abort rate by reducing the chance of conflicts. In this paper we apply the K-opacity concept to read/write, count and queue objects, which are common objects used in typical concurrent programs. We use the technique of writer lists to keep track of the transactions and the data being written to the system, in order to control the error rate and to prevent error propagation. We illustrate with an experimental analysis the positive impact of our approach on performance, where higher opacity relaxation (higher values of K) increases the throughput and decreases the aborts rate significantly.

System and method for supporting a self-tuning locking mechanism in a transactional middleware machine environment

Abstract: A lock mechanism can be supported in a transactional middleware system to protect transaction data in a shared memory when there are concurrent transactions. The transactional middleware machine environment comprises a semaphore provided by an operating system running on a plurality of processors. The plurality of processors operates to access data in the shared memory. The transactional middleware machine environment also comprises a test-and-set (TAS) assembly component that is associated with one or more processes. Each said process operates to use the TAS assembly component to perform one or more TAS operations in order to obtain a lock for data in the shared memory. Additionally, a process operates to be blocked on the semaphore and waits for a release of a lock on data in the shared memory, after the TAS component has performed a number of TAS operations and failed to obtain the lock.

Parallelize the Runtime Checks -- Not the Application

Abstract: Sequential and parallel applications are both prone to security and dependability bugs. Compilers can reduce the impact of these bugs by instrumenting runtime checks into the generated code. These runtime checks can have a dramatic negative impact on the performance of an application. For instance, our measurements show that compiler generated array-bounds checks can increase the application’s runtime by 20x. To make compiler generated checks practically usable, the introduced application slowdowns must be decreased. Single thread performance is only expected to grow slowly. To compensate these single thread slowdowns, it is very desirable to parallelize checked applications and/or their runtime checks. In this paper, we provide evidence that it is more promising to parallelize the runtime checks than the application: We therefore compare two frameworks using two different parallelization approaches: (1) parallelizing the application together with the runtime checks, and (2) parallelizing only the runtime checks. We focus on two frameworks that were developed in our group: Tanger The first implementation is the compiler extension Tanger [2] for software transactional memory (STM). Tanger puts every memory access within transactions under the control of the TinySTM++ library [3]. To apply this approach, an application must be parallelizable with transactional memory. ParExC ParExC (Parallel Execution Checking) parallelizes the runtime checks but not the application itself. Therefore, it is also suited for applications that are difficult to parallelize. ParExC executes the application without any runtime checks in the so called predictor process. The predictor’s execution is partitioned into epochs. Each epoch is replayed by an executor process, but this time with runtime checks. We scale by running the executors in parallel to each other and the predictor. Like Speck [5], ParExC allows a fast execution of the application by speculating on the success of the runtime checks. Speck parallelizes using dynamic binary instrumentation. Unlike Speck, ParExC parallelizes compiler generated checks at compile time. Roadmap In Sections 2 and 3, we introduce the two approaches in more details. Our experiments in Section 4 show that the specialized ParExC approach scales better than applications instrumented by Tanger for a checker with heavy runtime overhead if at-most 8 cores are available.

TardisTM: incremental repair for transactional memory

Abstract: Transactional memory (TM) provides developers with a transaction primitive for concurrent code execution that transparently checks for concurrency conflicts. When such a conflict is detected, the system recovers by aborting and restarting the transaction. Although correct, this behavior wastes work and inhibits forward progress. In this paper, we present TardisTM, a software TM system that supports repairing concurrency conflicts while preserving unaffected computation. Our key insight is that existing conflict detection mechanisms can be extended to perform incremental transaction repair, when augmented with additional runtime information. To do so, we design a mechanism for localizing conflicts back to transactional program points, define the semantics for optional repair handler annotations, and extend the conflict detection algorithm to ensure all repairs are completed. To evaluate our system, we characterize the benefit of repair on a set of benchmark programs; we measure up to 2.95x speedup over mutual exclusion, and 93% abort reduction over a baseline software TM system that does not support repair.

System and method for supporting session management in a distributed transactional service system

Abstract: Session management can be supported in a distributed transactional service system using a distributed transactional server and an affinity client. The affinity client operates to receive a service request from a user application and invoke at least one distributed transactional service provided by the distributed transactional server. The distributed transactional server operates to create and maintain a session for the user application when the at least one distributed transactional service is invoked, and the distributed transactional server further operates to determine an affinity scope associated with the session. The affinity scope, which is maintained on the affinity client, defines a routing scope within the distributed transactional service system, into which consequent requests in the session from the user application are dispatched.