Transactional Memory and OpenMP

• Published in: A Practical Programming Model for the Multi-Core Era Vol. 4935; pp. 37 - 53
• Main Authors: Milovanović, Miloš, Ferrer, Roger, Unsal, Osman S., Cristal, Adrian, Martorell, Xavier, Ayguadé, Eduard, Labarta, Jesús, Valero, Mateo
• Format: Book Chapter
• Language: English
• Published: Germany Springer Berlin / Heidelberg 2008; Springer Berlin Heidelberg
• Series: Lecture Notes in Computer Science
• Subjects: Compiler; OpenMP; Software Transaction Memory; STM Library
• ISBN: 3540693025; 9783540693024
• ISSN: 0302-9743; 1611-3349
• DOI: 10.1007/978-3-540-69303-1_4

Future generations of Chip Multiprocessors (CMP) will provide dozens or even hundreds of cores inside the chip. Writing applications that benefit from the massive computational power offered by these chips is not going to be an easy task for mainstream programmers who are used to sequential algorithms rather than parallel ones. This paper explores the possibility of using Transactional Memory (TM) in OpenMP, the industrial standard for writing parallel programs on shared-memory architectures, for C, C++, and Fortran. One of the major complexities in writing OpenMP applications is the use of critical regions (locks), atomic regions and barriers to synchronize the execution of parallel activities in threads. TM has been proposed as a mechanism that abstracts some of the complexities associated with concurrent access to shared data while enabling scalable performance. The paper presents a first proof-of-concept implementation of OpenMP with TM. Some extensions to the language are proposed to express transactions. These extensions are handled by our source-to-source OpenMP Mercurium compiler and our Software Transactional Memory (STM) library Nebelung that supports the code generated by Mercurium. The current implementation of the library has no support at the hardware level, so it is a proof-of-concept implementation. Hardware Transactional Memory (HTM) or Hardware-assisted STM (HaSTM) are seen as possible paths to make the tandem TM-OpenMP more usable. The paper finishes with a set of open issues that still need to be addressed, either in OpenMP or in the hardware/software implementations of TM.