2016-12-24 5 views
13

OpenMP имеет собственную поддержку для атомарного доступа, однако есть предпосылки для предпочтения атомарности C++ 11: они значительно более гибкие и являются частью стандарта. С другой стороны, OpenMP более мощный, чем библиотека потоков C++ 11.Смешивание C++ 11 atomics и OpenMP

Стандарт определяет библиотеку атомарных операций и поддержку библиотекипотока в двух отдельных главах. Это заставляет меня поверить, что компоненты для доступа атома являются ортогональными к используемой библиотеке потоков. Могу ли я объединить атомы C++ 11 и OpenMP?


Существует очень similar question на переполнение стека; однако в течение трех лет он оставался без ответа, поскольку его ответ не отвечает на фактический вопрос.

+0

Почему бы не быть точным? Просто не пытайтесь получить мьютекс C++ и ждать его с помощью OpenMP. –

+0

@brianbeuning Ну, я не уверен, вот почему я спрашиваю. Есть комментарий к связанному вопросу, предполагающему, что мы, скорее всего, столкнемся с проблемами.Я не мог найти твердого ответа на вопрос в Интернете, поэтому я как бы снова поднял вопрос. – user1494080

+3

Это поведение, определенное реализацией, и может варьироваться между компиляторами. Однако есть и более «практический» ответ. В большинстве случаев, если стандартная библиотека и среда выполнения OpenMP исходят от того же поставщика компилятора, вы, скорее всего, будете в порядке. Например, с использованием GCC с libstdC++ и libgomp, clang с libC++ и LLVM (Intel). Возможно, возникнут проблемы при использовании компилятора, у которого нет собственной стандартной библиотеки, например, Intel C++ с libstdC++ в Linux или libC++ на macOS. Я видел проблемы в этом случае, но очень редко. –

ответ

6

Интересно, что стандарт OpenMP 4.5 (2.13.6) имеет довольно неопределенную ссылку на C++ 11 Атомикс, или более конкретно std::memory_order:

Намерение состоит в том, что, когда аналогичная операция существует в C++ 11 или C11, последовательная последовательная атомная конструкция имеет ту же семантику как атомную операцию memory_order_seq_cst в C++ 11/C11. Аналогичным образом, некоторая последовательная атомная конструкция имеет ту же семантику, что и . Операция памяти_order_relaxed атома в C++ 11/C11.

К сожалению, это только примечание, нет ничего, что бы определяло, что они прекрасно играют вместе. В частности, даже последний предварительный просмотр OpenMP 5.0 по-прежнему относится к C++ 98 как единственная нормативная ссылка для C++. Итак, технически, OpenMP даже не поддерживает C++ 11.

Это в сторону, вероятно, будет работать большую часть времени на практике. Я бы согласился с тем, что использование std::atomic имеет меньший потенциал для проблем при использовании вместе с OpenMP, чем с потоком C++ 11. Но если есть какие-то проблемы, это может быть не так очевидно. Худший случай будет атомом, который не работает атомарно, хотя у меня есть серьезные проблемы с реалистичным сценарием, где это может произойти. В конце концов, это может не стоить того, и самое безопасное - придерживаться чистого потока OpenMP или чистого C++ 11 thread/atomics.

Возможно, у Христа есть что сказать об этом, в то же время проверьте this answer для более общей дискуссии. Хотя я немного устарел, я боюсь, что он все еще держится.

+4

Я спросил, как член OpenMP ARB и ** неофициальный ** ответ заключались в том, что совместимость между OpenMP и любой другой парадигмой потоков будет вероятно, никогда не вникают в спецификацию, но большинство поставщиков все равно будут делать правильную вещь (tm), как описано в комментариях Ян Чжоу. Другими словами, такой код будет работать в основном, но никогда не будет переносимым. –

1

В настоящее время это не определено OpenMP 4.5. На практике вы можете использовать атомарные операции C++ 11 с потоками OpenMP в большинстве компиляторов, но нет формальной гарантии, что она будет работать.

Из-за неопределенного поведения GCC не поддерживал атомизацию C11 (которая почти идентична семантике атомам C++ 11) и потокам OpenMP до недавнего времени. См. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467.

OpenMP 5+ рассмотрит это. Я лично участвую в этом процессе, но поскольку ничто еще не было ратифицировано, я не буду комментировать детали.