Разумно ли заменить boost::thread и boost:: mutex на эквиваленты c++11?

мотивация: причина, по которой я рассматриваю это, заключается в том, что мой гениальный менеджер проектов считает, что boost-это еще одна зависимость, и что это ужасно, потому что "вы зависите от нее"(я попытался объяснить качество boost, а затем сдался через некоторое время :( ). Меньшая причина, по которой я хотел бы это сделать, заключается в том, что я хотел бы изучить функции c++11, потому что люди начнут писать в нем код. Итак:

  1. есть ли отображение 1:1 между #include<thread> #include<mutex>и повышение эквиваленты?
  2. не считаете ли вы хорошей идеей заменить boost stuff на c++11
    материал. Мое использование примитивно, но есть примеры, когда std не делает предложите, что толчок делает? Или (богохульство) наоборот?

С. П. Я использую GCC, поэтому заголовки есть.

6 143
c++ boost-spirit multithreading c++11 mutex

6 ответов:

есть несколько различий между импульс.Поток и стандартная библиотека потоков C++11:

  • Boost поддерживает отмену потока, C++11 потоков не
  • в C++11 поддерживает std::async, но Boost не
  • Boost имеет boost::shared_mutex для блокировки нескольких читателей / одного писателя. Аналогичное std::shared_timed_mutex доступно только с C++14 ( N3891), в то время как std::shared_mutex доступно только с C++17 (N4508).
  • C++11 таймауты отличаются для увеличения таймаутов (хотя это должно скоро измениться теперь Boost.Хроно был принят).
  • некоторые имена отличаются (например boost::unique_future vs std::future)
  • аргумент-передача семантики std::thread разные boost::thread --- Boost использует boost::bind, который требует аргументов, которые можно копировать. std::thread позволяет перемещать только такие типы, как std::unique_ptr для передачи в качестве аргументов. Благодаря использованию boost::bind, в семантика заполнителей, таких как _1 во вложенных выражениях привязки тоже могут быть разные.
  • если вы явно не вызываете join() или detach() тут boost::thread деструктор и оператор присваивания будут называть detach() на объекте потока, который уничтожается / назначается. С C++11
179

std::thread в значительной степени по образцу boost::thread С несколько различий:

  • boost не копируется, один-дескриптор-карты-к-одному-ОС-поток, семантика сохраняются. Но эта резьба является подвижной, чтобы позволить возвращать резьбу из заводских функций и помещать в контейнеры.
  • это предложение добавляет отмену к boost::thread, что является серьезным осложнением. Это изменение оказывает большое влияние не только на поток, но и на остальную часть библиотека потоков C++ также. Считается, что это большое изменение оправдано из-за выгоды.
    • теперь деструктор потока должен вызвать cancel перед отсоединением, чтобы избежать случайной утечки дочерних потоков при отмене родительских потоков.
    • теперь требуется явный элемент отсоединения, чтобы включить отсоединение без отмены.
  • понятия дескриптора потока и идентичности потока были разделены на два класса (это один и тот же класс в boost::thread). Это должно поддержать более легкую манипуляцию и хранение идентичности потока.
  • добавлена возможность создания идентификатора потока, который гарантированно сравнивается с любым другим соединяемым потоком (boost::thread этого нет). Это удобно для кода, который хочет знать, выполняется ли он тем же потоком, что и предыдущий вызов (рекурсивные мьютексы являются конкретным примером).
  • существует "задняя дверь", чтобы получить собственный поток обработайте так, чтобы клиенты могли управлять потоками, используя базовую ОС, если это необходимо.

это с 2007 года, поэтому некоторые пункты больше не действительны:boost::thread есть native_handle функция теперь, и, как отмечают комментаторы,std::thread больше нет отмена.

Я не мог найти каких-либо существенных различий между boost::mutex и std::mutex.

23

есть одна причина не переносить на std::thread.

если вы используете статическое связывание, std::thread становится непригодным из-за этих ошибок gcc/особенности:

а именно, если вы называете std::thread::detach или std::thread::join это приведет к исключению или аварии, в то время как boost::thread работает нормально в этих случаи.

6

Корпоративный Делу

если вы пишете программное обеспечение для предприятия, которое должно работать на умеренном или большом разнообразии операционных систем и, следовательно, строить с различными компиляторами и версиями компиляторов (особенно относительно старых) на этих операционных системах, мое предложение-держаться подальше от C++11 вообще на данный момент. Это означает, что вы не можете использовать std::thread, и я бы рекомендовал использовать boost::thread.

Базовый / Технический Запуск Дело

если вы пишете для одной или двух операционных систем, вы точно знаете, что вам понадобится только построить современный компилятор, который в основном поддерживает C++11 (например, VS2015, GCC 5.3, Xcode 7), и вы уже не зависите от библиотеки boost, то std::thread может быть хорошим вариантом.

Мой Опыт

Я лично склоняюсь к закаленной, широко используется, высокая совместимость, высокую библиотек, таких как повышение по сравнению с очень современная альтернатива. Это особенно верно для сложных предметов программирования, таких как резьба. Кроме того, я уже давно испытал большой успех с boost::thread (и повысить в целом) по широкому спектру сред, компиляторов, моделей потоков и т. д. Когда его мой выбор, я выбираю повышение.

5

С Visual Studio 2013 std::mutex кажется, ведет себя иначе, чем boost::mutex, что вызвало у меня некоторые проблемы (см. этот вопрос).

3

Я попытался использовать shared_ptr из std вместо boost, и я действительно нашел ошибку в реализации gcc этого класса. Мое приложение было сбой из-за деструктора вызывается дважды (этот класс должен быть потокобезопасным и не должен генерировать такие проблемы). После перехода на boost:: shared_ptr все проблемы исчезли. Текущие реализации C++11 все еще не созрели.

Boost также имеет больше возможностей. Например, заголовок в версии std не предоставляет сериализатор потоку (т. е. cout

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

0