This workshop paper reports work in progress on NZTM, a nonblocking, zero-indirection object-based hybrid transactional memory system. NZTM can execute transactions using best-effort hardware transactional memory if it is available and effective, but can execute transactions using NZSTM, our compatible software transactional memory system otherwise. Previous nonblocking software and hybrid transactional memory implementations pay a significant performance cost in the common case, as compared to simpler, blocking ones. However, blocking is problematic in some cases and unacceptable in others. NZTM is nonblocking, but shares the advantages of recent blocking STM proposals in the common case: it stores object data “in place”, thus avoiding the costly levels of indirection in previous nonblocking STMs, and improves cache performance by collocating object metadata with the data it controls. 1.

Chip multi-processors (CMPs) have become ubiquitous, while tools that ease concurrent programming have not. The promise of increased performance for all applications through ever more parallel hardware requires good tools for concurrent programming, especially for average programmers. Transactional memory (TM) has enjoyed recent interest as a tool that can help programmers program concurrently. The TM research community claims that programming with transactional memory is easier than alternatives (like locks), but evidence is scant. In this paper, we describe a user-study in which 147 undergraduate students in an operating systems course implemented the same programs using coarse and fine-grain locks, monitors, and transactions. We surveyed the students after the assignment, and examined their code to determine the types and frequency of programming errors for each synchronization technique. Inexperienced programmers found baroque syntax a barrier to entry for transactional programming. On average, subjective evaluation showed that students found transactions harder to use than coarse-grain locks, but slightly easier to use than fine-grained locks. Detailed examination of synchronization errors in the students’ code tells a rather different story. Overwhelmingly, the number and types of programming errors the students made was much lower for transactions than for locks. On a similar programming problem, over 70 % of students made errors with fine-grained locking, while less than 10 % made errors with transactions. 1

Software Transactional Memory (STM) promises to simplify concurrent programming without requiring specific hardware support. Yet, STM’s credibility lies on the extent to which it enables to leverage multicores and outperform sequential code. A recent CACM paper [3] questioned this ability and suggested the confinement of STM to a research toy. We revisit these conclusions through the most to date extensive comparison of STM performance to sequential code. We evaluate a state-of-the-art STM system, SwissTM, on a wide range of benchmarks and two different multicore systems. We dissect the inherent costs of synchronization as well as the overheads of compiler instrumentation and transparent privatization. Our results show that an STM with manually instrumented benchmarks and explicit privatization outperforms sequential code by up to 29 times on SPARC with 64 concurrent threads and by up to 9 times on x86 with 16 concurrent threads. Indeed the overheads of compiler instrumentation and transparent privatization are substantial, yet they do not prevent STM from generally outperforming sequential code.

Transactional memory (TM) is expected to become a widely used parallel programming paradigm for multi-core architectures. To reach this goal, we need tools that do not only help develop TMs, but also test them and evaluate them on a wide range of workloads. In this paper, we introduce a novel tool, TMUNIT, to assist researchers in designing and optimizing TMs. TMUNIT provides a domain-specific language for specifying workloads, and tests the performance and semantics of TMs. TMUNIT is freely available online. It comes with a test suite that compares the performance of TMs and explain their differences using semantics tests that outlines behavioral characteristics. 1.

Transactional memory presents a new concurrency control mechanism to handle synchronization between shared data. Dealing with concurrency issues has always been a difficulty when writing operating system software and using transactions aims to simplify matters. This thesis presents a framework for understanding how interrupt-driven device drivers can benefit from using transactional memory. A method for integrating software transactional memory (STM) into an operating system kernel is also developed and applied. This kernel uses STM over hardware transactional memory (HTM) because HTM requires modifications only implemented in simulated systems. By using STM, it is possible to build upon existing kernels and deploy operating systems onto commodity machines with communication peripherals. At the core is a modernized version of the Embedded Xinu operating system that has been ported to the Intel IA-32 architecture and modified to use a publicly available, production quality compiler and STM library available from Intel Corporation. The implementation of the Embedded Xinu kernel required several modifications to make use of the transactions offered by a library designed for use with user-level threads executing in Linux. Integrating the STM library into the kernel presents several challenges when dealing with a system that allows interrupts to enter at

Abstract. In concurrent programs raising an exception in one thread does not prevent others from operating on an inconsistent shared state. Instead, exceptions should ideally be handled in coordination by all the threads that are affected by their cause. In this paper, we propose a Java language extension for coordinated exception handling where a named abox (atomic box) is used to demarcate a region of code that must execute atomically and in isolation. Upon an exception raised inside an abox, threads executing in dependent aboxes, roll back their changes, and execute their recovery handler in coordination. We provide a dedicated compiler framework, CXH, to evaluate experimentally our atomic box construct. Our evaluation indicates that, in addition to enabling recovery, an atomic box executes a reasonably small region of code twice as fast as when using a failbox, the existing coordination alternative that has no recovery support.

In this “idea ” paper, we advocate the study of recently developed numerical algorithms that have tunable parallelism, which may provide a mechanism for a class of scientific applications to cope with or exploit heterogeneous multi- and many-core architectures. In particular, suppose we are given a physical system described by a partial differential equation (PDE) that we wish to integrate (i.e., solve) numerically; rather than using traditional algorithms that are designed primarily with data-parallelism in mind, our goal is to produce numerical algorithms that have a mix of highly asynchronous task-level parallelism and synchronous dataparallelism, with an algorithmic “tuning knob ” that at runtime can control the degree and type of parallelism. Such an algorithm and its implementation can in principle adapt to any hardware environment, whether it be highly multithreaded, support efficient data-parallel execution through large or small vector units, or have some heterogeneous mix of such components. The mathematical framework we consider here is the asynchronous variational integrator (AVI) framework of Lew, Marsden, Ortiz, and West (2003), in which an interesting class of continuous physical systems can be modeled and solved using what are essentially discrete-event simulation techniques. Beyond having attractive numerical properties, the numerical algorithms derived in the AVI framework can have the sort of tunable-parallel property described above. We believe AVI-based algorithms constitute an interesting workload for evaluating emerging parallel hardware and software systems; by extension, AVI-like methods should be a fruitful area of collaborative algorithmic and systems research. 1. INTRODUCTION: WHY

Transactional Memory (TM) is a promising abstraction as it hides all synchronization complexities from the programmers of concurrent applications. More particularly the TM paradigm operated a complexity shift from the application programming to the TM programming. Therefore, expert programmers have now started to look for the ideal TM that will bring, once-for-all, performance to all concurrent applications. Researchers have recently identified numerous issues TMs may suffer from. Surprisingly, no TMs have ever been tested in these scenarios. In this paper, we present the first to date TM testbed. We propose a framework, TMunit, that provides a domain specific language to write rapidly TM workloads so that our test-suite is easily extensible. Our reproducible semantic tests indicate through reproducible counter-examples that existing TMs do not satisfy recent consistency criteria. Our performance tests identify workloads where well-known TMs perform differently. Finally, additional tests indicate some workloads preventing contention managers from progressing.

Parallel programming is an increasingly important topic in software engineering due to the recent rise of multicore computer architectures. Although substantial research efforts have been made to simplify parallel programming models, few approaches concentrate on both simplicity and practicality. In this paper, we present the TBoost.STM programming model for parallel support in C++. TBoost.STM’s programming model extends DracoSTM’s model with language-like constructs for both transactional memory (TM) and mutual exclusion locks. Our library-based approach promotes a simplified programming model that increases correctness by using common programming structures. We compare our design to two other well-known librarybased approaches. Finally, we provide an overview of our implementation, its legal execution model and a number of examples demonstrating its use. 1.