26

OpenMP has its own support for atomic access, however, there are at least two reasons for preferring C++11 atomics: they are significantly more flexible and they are part of the standard. On the other hand, OpenMP is more powerful than the C++11 thread library.

The standard specifies the atomic operations library and the thread support library in two distinct chapters. This makes me to believe that the components for atomic access are kind of orthogonal to the thread library used. Can I indeed combine C++11 atomics and OpenMP?

There is a very similar question on Stack Overflow; however, it has been basically unanswered for three years, since its answer does not answer the actual question.

Community
  • 1
  • 1
user1494080
  • 2,064
  • 2
  • 17
  • 36
  • Why would you not be able to? Just don't try to acquire a C++ mutex and wait on it using OpenMP. – brian beuning Dec 24 '16 at 00:43
  • @brianbeuning Well, I'm unsure, that's why I am asking. There is a comment to the linked question speculating that we "will likely run into problems". I couldn't find any solid answer to the question on the web, that's why I kind of re-raised the question again. – user1494080 Dec 24 '16 at 00:56
  • 5
    This is a implementation defined behavior and may vary between compilers. However, there's also a more "practical" answer. In most cases, if the standard library, and OpenMP runtime, come from the same vendor of compiler, you are most likely to be fine. For example, using GCC with libstdc++ and libgomp , clang with libc++ and LLVM (Intel) runtime. There might be problems when using a compiler that does not have its own standard library, for example Intel C++ with libstdc++ on Linux or libc++ on macOS. I have seen issues in this case but very rarely. – Yan Zhou Dec 24 '16 at 02:22
  • 4
    That said, in most cases you should expect them to work as you expect. But just test it more carefully. Threading facilities such as standard library threads and OpenMP, is more of a OS-specific issue while atomics are more hardware related. It is possible for one part of the tool chain, say the OpenMP in compiler misuse a OS feature and the other part, the standard library make a different assumption of the OS, and they end up don't play nice. Any software can have bugs. But if the different parts come from the same vendor, it might have a better chance been more throughly tested – Yan Zhou Dec 24 '16 at 02:26
  • *"This makes me to believe that the components for atomic access are kind of orthogonal to the thread library used"* - From my understanding, it is not so much they are orthogonal. Rather, they are different primitives that operate at slightly different levels to solve different problems. If I had to characterize them based on my understanding then I'd say they compliment one another. Also see [C++11 introduced a standardized memory model. What does it mean? And how is it going to affect C++ programming?](https://stackoverflow.com/q/6319146/608639). – jww Dec 07 '18 at 02:09

2 Answers2

14

Update:

OpenMP 5.0 defines the interactions to C++11 and further. Among others, it says that using the following features may result in unspecified behavior:

  • Data-dependency ordering: atomics and memory model
  • Additions to the standard library
  • C++11 library

So clearly, mixing C++11 atomics and OpenMP 5.0 will result in unspecified behavior. At least the standard itself promises that "future versions of the OpenMP specification are expected to address [these] features".

Old discussion:

Interestingly, the OpenMP 4.5 standard (2.13.6) has a rather vague reference to C++11 atomics, or more specific std::memory_order:

The intent is that, when the analogous operation exists in C++11 or C11, a sequentially consistent atomic construct has the same semantics as a memory_order_seq_cst atomic operation in C++11/C11. Similarly, a non-sequentially consistent atomic construct has the same semantics as a memory_order_relaxed atomic operation in C++11/C11.

Unfortunately this is only a note, there is nothing that defines that they are playing nicely together. In particular, even the latest OpenMP 5.0 preview still refers to C++98 as the only normative reference for C++. So technically, OpenMP doesn't even support C++11 itself.

That aside, it will probably work most of the time in practice. I would agree that using std::atomic has less potential for trouble if used together with OpenMP than C++11 threading. But if there is any trouble, it may not be as obvious. Worst case would be a atomic that doesn't operate atomically, even though I have serious trouble imagining a realistic scenario where this may happen. At the end of the day, it may not be worth it and the safest thing is to stick with pure OpenMP or pure C++11 thread/atomics.

Maybe Hristo has something to say about this, in the mean time check out this answer for a more general discussion. While a bit dated, I'm afraid it still holds.

Zulan
  • 21,896
  • 6
  • 49
  • 109
  • 6
    I asked once a member of the OpenMP ARB and the **unofficial** response was that interoperability between OpenMP and any other threading paradigm will probably never make it into the specification, but that most vendors will anyway Do The Right Thing (tm) as summarised in the comments by Yan Zhou. In other words, such code will mostly work, but will never be portable. – Hristo Iliev Dec 25 '16 at 23:06
3

This is currently unspecified by OpenMP 4.5. In practice, you can use C++11 atomic operations with OpenMP threads in most compilers, but there is no formal guarentee that it will work.

Because of the unspecified behavior, GCC did not support C11 atomics (which are nearly identical in semantics to C++11 atomics) and OpenMP threads until recently. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 for details.

OpenMP 5.0 made an attempt to address this. The normative language references were updated to C11 and C++11. However, the atomics and memory model from these is "not supported", which means implementation-defined. I wish OpenMP 5.0 said more but it is extremely difficult to define the interaction of OpenMP and ISO language atomics.

Jeff Hammond
  • 5,374
  • 3
  • 28
  • 45