Параллельный C++11 — какие наборы инструментов можно использовать?

Я активно использую <thread> <atomic> <mutex> и т. д. в своем коде, который включает в себя несколько алгоритмов без блокировок. Я ориентируюсь (в конечном итоге) на среду Linux. Я разрабатывал с помощью бета-версии Visual Studio 2011, которая, хотя и ужасно лишена других функций С++ 11, кажется единственной набором инструментов, реализующим параллельные функции.

См. поддержку С++ 11 здесь:

Теперь, если другим просто не хватает библиотеки, содержащей параллельные функции C++ 11, я могу легко использовать just::thread, однако и clang, и gcc отвечают "нет" модели памяти С++ 11, которую, по крайней мере, визуальный С++ поддерживает. Я не совсем уверен, каков будет эффект от этого - вероятно, оптимизация кода, по-видимому, свободного от побочных эффектов, среди других ошибочных вещей.

Если пока я полностью избегаю оптимизированных сборок и компилирую только отладочные сборки без включенных оптимизаций — разумно ли использовать тулчейн Clang или GCC?


c++ multithreading synchronization c++11 lock-free
person Eloff    schedule 07.04.2012    source источник
comment
Я сразу предполагаю, что если вы используете just::thread, он будет работать нормально. Он использует нативные (Posix или Win32) примитивы для обеспечения соблюдения таких вещей, как порядок, поэтому я думаю, что компилятор должен быть довольно сильно сломан, чтобы он не работал.   -  person Jerry Coffin    schedule 07.04.2012
comment
Вам, вероятно, следует включить в свой список тег, связанный с многопоточностью, Энтони Уильямс регулярно появляется здесь, так что, если вам повезет, он это заметит. Я думаю, что он создал just::thread, чтобы он был кроссплатформенным, так что я не ожидаю никаких проблем.   -  person Matthieu M.    schedule 07.04.2012

Ответы (2)


arrow_upward
4
arrow_downward

Статус GCC 4.7

Работа над моделью памяти C++ продолжается и должна быть завершена в следующем выпуске GCC. GCC 4.7 уже выпущен, так что вы можете ожидать от него именно этого.

  • Полная атомарная реализация для поддерживаемых инструкций без блокировки. Все атомарные операции были реализованы с помощью новых встроенных функций __atomic, и большинство целей отражают параметр модели памяти в сгенерированном коде. Оптимизация не будет перемещать операции с общей памятью за пределы атомарных операций, поэтому учитываются различные отношения событий.
  • Когда инструкции по блокировке недоступны (через аппаратную или операционную поддержку), атомарные операции оставляются как вызовы функций, которые должны быть разрешены библиотекой. Из-за нехватки времени и незавершенного API libatomic не поставляется с GCC 4.7. Это легко определить, встретив неудовлетворительные внешние символы, начинающиеся с _atomic*.
  • Если программе требуется помощь библиотеки, можно скомпилировать один образец реализации файла C и связать его с клиентской программой, чтобы разрешить эти внешние вызовы функций с использованием заблокированной реализации. Скачать образец libatomic
  • Шаблоны C++ полностью поддерживают объекты произвольного размера, хотя ранее упомянутый файл libatomic.c может потребоваться для соответствия некоторым пользовательским классам. Если класс отображается на тот же размер, что и поддерживаемый целочисленный тип без блокировок, то также будут использоваться подпрограммы без блокировок.
  • Битовые поля не соответствуют модели памяти. Другими словами, они могут вызвать гонки при загрузке или сохранении данных из-за доступа к целым словам при чтении или записи.
  • Оптимизации не прошли полную проверку на соответствие, хотя некоторая работа была проделана. Некоторые оптимизации могут привести к новым гонкам данных, которых раньше не было. Количество известных случаев невелико, и проверка на соответствие не является тривиальной. Если кто-то столкнется со случаем, когда оптимизация приводит к новой гонке данных, пожалуйста, откройте для этого дело об ошибке, чтобы его можно было решить.

Поддержка в LLVM, похоже, будет продолжена: http://llvm.org/releases/3.0/docs/Atomics.html

Однако трудно сказать, в какой степени это на самом деле используется в clang. Похоже, что <atomic> в основном работает для некоторых типов. Я получаю утверждения компилятора для других типов, в которых говорится, что атомарный тип был неожиданным, что дает некоторую уверенность в типах, с которыми он работает.

person bames53    schedule 08.04.2012
comment
Это выглядит многообещающе. На самом деле я склоняюсь к clang, потому что он, кажется, выдает более полезные сообщения об ошибках, и для меня это существенная синхронизация времени с С++. Есть экспериментальный QtCreator, который использует clang для реализации модели кода (дополнение, подсветка, рефакторинг и т. д.). Я собираюсь попробовать, так как очень скучаю по своей визуальной студии + визуальной помощи x в Linux. - person Eloff; 09.04.2012

arrow_upward
1
arrow_downward

Я успешно использовал gcc-4.7 на 64-битных Linux и Windows. std::thread и т. д. отлично работает в Linux даже с gcc-4.6.
В Windows gcc-4.7 (mingw64) есть небольшие проблемы, утечки памяти с деструкторами std::condition_variable AFAIR.

person Gunther Piez    schedule 07.04.2012