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

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

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

Между Boost.Thread и стандартной библиотекой потоков 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.Chrono был принят).
• Некоторые имена разные (например, boost::unique_futureпротив std::future)
• Семантика передачи аргументов std::threadотличается от использования boost::thread--- Boost boost::bind, которое требует копируемых аргументов. std::threadпозволяет только типы перемещения, такие как std::unique_ptrпередаваемые в качестве аргументов. Благодаря использованию boost::bindсемантика заполнителей, таких как _1вложенные выражения связывания, также может быть различной.
• Если вы не вызываете явно join()или detach()тогда boost::threadдеструктор и оператор присваивания вызовут detach()объект потока, который уничтожается / назначается. С std::threadобъектом C ++ 11 это приведет к вызову std::terminate()и отмене приложения.

Чтобы прояснить вопрос о параметрах «только для перемещения», ниже приведен действительный код C ++ 11, который передает владение intиз временного std::unique_ptrпараметра параметру, f1когда запускается новый поток. Однако, если вы используете boost::threadего, он не будет работать, так как он используется boost::bindвнутри, и std::unique_ptrне может быть скопирован. Существует также ошибка в библиотеке потоков C ++ 11, предоставляемой с GCC, которая препятствует этой работе, поскольку она также используется std::bindв реализации.

void f1(std::unique_ptr<int>);
std::thread t1(f1,std::unique_ptr<int>(new int(42)));

Если вы используете Boost, то вы, вероятно, можете безболезненно переключаться на потоки C ++ 11, если ваш компилятор поддерживает его (например, в последних версиях GCC в linux в основном реализована полная библиотека потоков C ++ 11, доступная в -std=c++0xрежиме).

Если ваш компилятор не поддерживает потоки C ++ 11, вы можете получить стороннюю реализацию, такую ​​как Just :: Thread , но это все еще является зависимостью.

std::threadв значительной степени смоделирован после boost::thread, с некоторыми отличиями :

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

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

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

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

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

• http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590
• http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740

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

Корпоративный случай

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

Базовый / Tech Startup Case

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

Мой опыт

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

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

Что касается std :: shared_mutex, добавленного в C ++ 17

Другие ответы здесь дают очень хороший обзор различий в целом. Тем не менее, есть несколько проблем, std::shared_mutexкоторые буст решает.

1. Восстанавливаемые мутанты. Они отсутствуют в std::thread. Они позволяют преобразовать читателя в писателя, не позволяя другим писателям входить до вас . Они позволяют выполнять такие вещи, как предварительная обработка больших вычислений (например, переиндексация структуры данных) в режиме чтения, а затем обновляться до записи, чтобы применить переиндекс, удерживая блокировку записи только в течение короткого времени.

2. Честность. Если вы постоянно читаете с std::shared_mutex, ваши писатели будут заблокированы на неопределенный срок. Это потому, что если придет другой читатель, им всегда будет отдан приоритет. При этом boost:shared_mutexвсе потоки в конечном итоге получат приоритет. ⁽¹⁾ Ни читатели, ни писатели не будут голодать.

Дело в том, что если у вас система с очень высокой пропускной способностью, без простоев и с высокой конкуренцией, std::shared_mutexвы никогда не будете работать без ручной сборки приоритетной системы поверх нее. boost::shared_mutexбудет работать из коробки, хотя в некоторых случаях вам, возможно, придется повозиться с ним. Я бы сказал, что std::shared_mutexповедение - это скрытая ошибка, ожидающая появления в большинстве кодов, которые ее используют.

⁽¹⁾ _{Фактический алгоритм использует на основе ОС планировщик потоков. По моему опыту, когда чтение насыщено, в Windows более длинные паузы (при получении блокировки записи), чем в OSX / Linux.}

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

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

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