In recent years there has been a shift in microprocessor manufacture from building single-core processors towards providing multiple cores on the same chip. This shift has meant that a much wider population of developers are faced with the task of developing parallel software: a difficult, time consuming and expensive process. With the aim of identifying issues, emerging practices and design opportunities for support, we present in this paper a qualitative study in which we interviewed a range of software developers, in both industry and academia. We then perform a systematic analysis of the data and identify several cross-cutting themes. These analysis themes include the practical relevance of the probe effect, the significance of orchestration models in development and the mismatch between currently available tools and developers' needs. We also identify an important characteristic of parallel programming, where the process of optimisation goes hand in hand with the process of debugging, as opposed to clearer distinctions which may be made in traditional programming. We conclude with reflection on how the study can inform the design of software tools to support developers in the endeavour of parallel programming.

Transactional memory (TM) has become an active research area as it promises to simplify the development of highly scalable parallel programs. Scalability is quickly becoming an essential software requirement as successive commodity processors integrate ever larger numbers of cores. Non-trivial TM applications to test TM implementations have only recently begun to emerge, but have been written in different programming languages, using different TM implementations, making analysis difficult. We ported the popular non-trivial TM applications from the STAMP suite (Genome, KMeans, and Vacation), and Lee-TM to DSTM2, a software TM implementation, and built into it a framework to profile their execution. This paper investigates which profiling information is most relevant to understanding the performance of these non-trivial TM applications using up to 8 processors. We report commonly used transactional execution metrics and introduce two new metrics that can be used to profile TM applications.

While Transactional Memory (TM) research on shared-memory chip multiprocessors has been flourishing over the last years,limited research has been conducted in the cluster domain. In this paper,we introduce a research platform for exploiting software TMon clusters. The Distributed Software Transactional Memory (DiSTM) system has been designed for easy prototyping of TM coherence protocols and it does not rely on a software or hardware implementation of distributed shared memory. Three TM coherence protocols have been implemented and evaluated with established TM benchmarks. The decentralized TransactionalCoherence and Consistency protocol has been compared against two centralized protocols that utilize leases. Results indicate thatdepending on network congestion and amount of contention different protocols perform better.

Traditional parallel programming models achieve synchronization with error-prone and complex-to-debug constructs such as locks and barriers. Transactional Memory (TM) is a promising new parallel programming abstraction that replaces conventional locks with critical sections expressed as transactions. Most TM research has focused on single address space parallel machines, leaving the area of distributed systems unexplored. In this paper we introduce a flexible Java Software TM (STM) to enable evaluation and prototyping of TM protocols on clusters. Our STM builds on top of the ProActive framework and has as an underlying transactional engine the state-of-the-art DSTM2. It does not rely on software or hardware distributed shared memory for the execution. This follows the transactional semantics at object granularity level and its feasibility is evaluated with non-trivial TM-specific benchmarks.

Experience in profiling Lee's routing algorithm, a new complex TM application, showed that transactional applications may exhibit dynamic exploitable parallelism, i.e. the amount of useful parallelism available at any point in time varies during the execution of the application. Obviously, executing too many transactions at times when the available parallelism is low will lead to high contention and wasted computation in aborted transactions, and vice versa. Current Transactional Memory (TM) implementations do not account for this behavior.