Techniques supporting threadprivate in OpenMP

  • Authors:
  • Xavier Martorell;Marc Gonzlez;Alex Duran;Jairo Balart;Roger Ferrer;Eduard Ayguadé;Jesús Labarta

  • Affiliations:
  • Barcelona Supercomputing Center, Computer Architecture Dept., Technical Univ. of Catalunya, Barcelona, Spain;Barcelona Supercomputing Center, Computer Architecture Dept., Technical Univ. of Catalunya, Barcelona, Spain;Barcelona Supercomputing Center, Computer Architecture Dept., Technical Univ. of Catalunya, Barcelona, Spain;Barcelona Supercomputing Center, Computer Architecture Dept., Technical Univ. of Catalunya, Barcelona, Spain;Barcelona Supercomputing Center, Computer Architecture Dept., Technical Univ. of Catalunya, Barcelona, Spain;Barcelona Supercomputing Center, Computer Architecture Dept., Technical Univ. of Catalunya, Barcelona, Spain;Barcelona Supercomputing Center, Computer Architecture Dept., Technical Univ. of Catalunya, Barcelona, Spain

  • Venue:
  • IPDPS'06 Proceedings of the 20th international conference on Parallel and distributed processing
  • Year:
  • 2006

Quantified Score

Hi-index 0.00

Visualization

Abstract

This paper presents the alternatives available to support threadprivate data in OpenMP and evaluates them. We show how current compilation systems rely on custom techniques for implementing thread-local data. But in fact the ELF binary specification currently supports data sections that become threadprivate by default. ELF naming for such areas is Thread-Local Storage (TLS). Our experiments demonstrate that implementing threadprivate based on the TLS support is very easy, and more efficient. This proposal goes in the same line as the future implementation of OpenMP on the GNU compiler collection. In addition, our experience with the use of threadprivate in OpenMP applications shows that usually it is better to avoid it. This is because threadprivate variables reside in common blocks and they impede the compiler to fully optimize the code. So it is better to keep threadprivate as a temporary technique only to ease porting MPI codes to OpenMP.