Autonomic Concurrency Regulation in Transactional Memory Short Term Scientific Mission Relation Applicant : Diego Rughetti January

Transactional Memory (TM) has emerged as a powerful programming paradigm for concurrent applications. TM allows encapsulating the access to data shared across concurrent threads within transactions, thus avoiding the need for synchronization mechanisms to be explicitly coded by the programmer. On the other hand, synchronization transparency must not come at the expense of performance. Hence, TM-based systems must be enriched with mechanisms providing optimized run-time efficiency. Among the issues to be tackled, a crucial one is related to determining the optimal level of concurrency (number of threads) to be employed for running the application. When using too low levels of concurrency, the intrinsic parallelism of applications may not be fully untapped. On the other hand, an excessively high concurrency level may lead to thrashing phenomena caused by excessive data contention and consequent transaction aborts. In this relation we present the results of a study aimed to evaluate to what extent existing techniques for self-tuning the concurrency level of Software Transactional Memory can be effectively used in the context of Hardware Transactional Memory (Intel TSX). Our study highlights that the techniques developed for STM can exhibit significant drawbacks when employed in a HTM-based system. This finding has motivated the investigation of two novel approaches for optimal concurrency level prediction explicitly tailored for Hardware Transaction Memory. By means of an experimental study based on the STAMP benchmark suite, we show that the proposed techniques are not only lightweight, but also that they can achieve a significantly higher accuracy than pre-existing optimization techniques proposed for STM. 1 The concurrency problem in STM and HTM One of the main challenges that a programmer has to face during the design of parallel and distributed applications is how to ensure its scalability, that is the capacity of an application to increase proportionally its performance increasing the amount of available computing resources. Focusing our attention on centralized multi-core systems, an ideal parallel application should scale linearly with the number of available cores. Usually this level of scalability is not reachable due to two main factors: • contention on physical resource: this issue is experienced by processes/threads that compose the parallel application when they try to access shared hardware resource (e.g. memory buses). It is strictly related to the specific hardware used to run the application and keeping under control its impact on performance requires a detailed hardware knowledge; • contention on logical resource: it is experienced by the processes/threads that compose the parallel application when they try to concurrently access shared logical resources, like data in shared memory. It is strictly related to the application logic and its impact on application performance can often be higher than that caused by the contention on physical resource. To limit the impact of logical contention on application scalability and performance the programmer must have a detailed knowledge of the application logic and of the application data access pattern. In this way the programmer can divide properly the work between threads minimizing the need for synchronization, and use synchronization mechanisms that minimize wasted time (when synchronization is strictly necessary). But these tasks are not trivial and, in the context of transactional applications, TM helps to simplify developer’s work by easing the task of synchronizing access to shared data. This implies that the logical contention experimented by transactional applications is closely related to the concurrency control mechanism implemented by the TM. As we will show in section 3, unlike STM, in many HTM-based applications the main transaction abort reason is not the logical contention. Performance and scalability still depend from the application transactional profile but the transactions