我可以安全地使用OpenMP与C ++ 11吗？ [英] Can I safely use OpenMP with C++11?

问题描述

OpenMP标准仅考虑C ++ 98（ISO / IEC 14882：1998）。这意味着在C ++ 03或甚至C ++ 11下没有标准支持使用OpenMP。因此，使用C ++> 98和OpenMP的任何程序都在标准之外运行，这意味着即使它在某些条件下工作，也不可能是可移植的，但绝对不能保证。

The OpenMP standard only considers C++ 98 (ISO/IEC 14882:1998). This means that there is no standard supporting usage of OpenMP under C++03 or even C++11. Thus, any program that uses C++ >98 and OpenMP operates outside of standards, implying that even if it works under certain conditions, it's unlikely to be portable but definitely never guaranteed.

C ++ 11有自己的多线程支持，这很可能会与OpenMP在某些实现上冲突。

The situation is even worse with C++11 with its own multi-threading support, which very likely will clash with OpenMP for certain implementations.

因此，安全性它使用OpenMP与C ++ 03和C ++ 11？

So, how safe is it to use OpenMP with C++03 and C++11?

可以安全地使用C ++ 11多线程以及OpenMP在同一个程序，但不交叉它们（即任何代码中没有OpenMP语句传递给C ++ 11并发功能，并且在OpenMP生成的线程中没有C ++ 11并发）。

Can one safely use C++11 multi-threading as well as OpenMP in one and the same program but without interleaving them (i.e. no OpenMP statement in any code passed to C++11 concurrent features and no C++11 concurrency in threads spawned by OpenMP)?

我特别感兴趣的情况，我首先调用一些代码使用OpenMP，然后一些其他代码使用C ++ 11并发在相同的数据结构。

I'm particularly interested in the situation where I first call some code using OpenMP and then some other code using C++11 concurrency on the same data structures.

推荐答案

Walter，我相信我不仅告诉你在其他讨论，但也直接从源头提供了信息（即来自我的同事，他是OpenMP语言委员会的成员）。

Walter, I believe I not only told you the current state of things in that other discussion, but also provided you with information directly from the source (i.e. from my colleague who is part of the OpenMP language committee).

OpenMP被设计为轻量级数据并行加入FORTRAN和C，后来扩展到C ++成语通过随机访问迭代器的并行循环）以及任务与引入显式任务的并行性。它意味着作为在所有三种语言中尽可能多的平台可移植的并且提供基本上相同的功能。它的执行模型非常简单 - 单线程应用程序在并行区域中分叉线程组，在其中运行一些计算任务，然后将这些小组连接回串行执行。

OpenMP was designed as a lightweight data-parallel addition to FORTRAN and C, later extended to C++ idioms (e.g. parallel loops over random-access iterators) and to task parallelism with the introduction of explicit tasks. It is meant to be as portable across as many platforms as possible and to provide essentially the same functionality in all three languages. Its execution model is quite simple - a single-threaded application forks teams of threads in parallel regions, runs some computational tasks inside and then joins the teams back into serial execution. Each thread from a parallel team can later fork its own team if nested parallelism is enabled.

由于OpenMP的主要用途是在高性能计算中（毕竟，它的指令和执行模型从高性能Fortran借用），任何OpenMP实现的主要目标是效率，并且不是与其他线程范例的互操作性。在某些平台上，只有当OpenMP运行时是控制进程线程的唯一一个时，才能实现有效的实现。此外，OpenMP的某些方面可能不适合其他线程构造，例如，当分叉两个或多个并行并行区域时，由 OMP_THREAD_LIMIT 设置的线程数限制。

Since the main usage of OpenMP is in High Performance Computing (after all, its directive and execution model was borrowed from High Performance Fortran), the main goal of any OpenMP implementation is efficiency and not interoperability with other threading paradigms. On some platforms efficient implementation could only be achieved if the OpenMP run-time is the only one in control of the process threads. Also there are certain aspects of OpenMP that might not play well with other threading constructs, for example the limit on the number of threads set by OMP_THREAD_LIMIT when forking two or more concurrent parallel regions.

由于OpenMP标准本身并不严格禁止使用其他线程范例，而且也不能标准化与此类的互操作性，因此支持此类功能由实现者决定。这意味着一些实现可能提供顶级OpenMP区域的安全并发执行，一些可能不提供。 x86实现者承诺支持它，可能是因为它们中的大多数也是其他执行模型的支持者（例如英特尔与Cilk和TBB，GCC与C ++ 11等）和x86通常被认为是一个实验平台其他供应商通常更保守）。

Since the OpenMP standard itself does not strictly forbid using other threading paradigms, but neither standardises the interoperability with such, supporting such functionality is up to the implementers. This means that some implementations might provide safe concurrent execution of top-level OpenMP regions, some might not. The x86 implementers pledge to supporting it, may be because most of them are also proponents of other execution models (e.g. Intel with Cilk and TBB, GCC with C++11, etc.) and x86 is usually considered an "experimental" platform (other vendors are usually much more conservative).

OpenMP 4.0对于它所使用的C ++特性（ISO / IEC 14882：1998） a href =http://www.openmp.org/mp-documents/OpenMP4.0RC1_final.pdf>此处）。标准现在包括像便携线程亲和这样的东西 - 这绝对不适合与其他线程范例，这可能提供自己的绑定机制与OpenMP的冲突。同样，OpenMP语言针对HPC（数据和任务并行科学和工程应用程序）。 C ++ 11结构针对通用计算应用程序。如果你想要奇特的C ++ 11并发的东西，那么使用C ++ 11，或者如果你真的需要与OpenMP混合，然后坚持C ++ 98的语言功能的子集，如果你想保持便携。 / p>

OpenMP 4.0 is also not going further than ISO/IEC 14882:1998 for the C++ features it employs (the SC12 draft is here). The standard now includes things like portable thread affinity - this definitely does not play well with other threading paradigms, which might provide their own binding mechanisms that clash with those of OpenMP. Once again, the OpenMP language is targeted at HPC (data and task parallel scientific and engineering applications). The C++11 constructs are targeted at general purpose computing applications. If you want fancy C++11 concurrent stuff, then use C++11 only, or if you really need to mix it with OpenMP, then stick to the C++98 subset of language features if you want to stay portable.

我特别感兴趣的情况，我首先调用一些代码使用OpenMP，然后一些其他代码使用C ++ 11并发相同的数据结构。

I'm particularly interested in the situation where I first call some code using OpenMP and then some other code using C++11 concurrency on the same data structures.

没有什么明显的原因，你想要不可能，但它是由你的OpenMP编译器，运行。有自由和商业库使用OpenMP并行执行（例如MKL），但是总是有可能与多线程代码不兼容的警告（虽然有时在用户手册中被深深地隐藏），它们提供了什么和何时可能的信息。一如往常，这超出了OpenMP标准的范围，因此YMMV。

There are no obvious reasons for what you want to not be possible, but it is up to your OpenMP compiler and run-time. There are free and commercial libraries that use OpenMP for parallel execution (for example MKL), but there are always warnings (although sometimes hidden deeply in their user manuals) of possible incompatibility with multithreaded code that give information on what and when is possible. As always, this is outside of the scope of the OpenMP standard and hence YMMV.

这篇关于我可以安全地使用OpenMP与C ++ 11吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！