Имеют ли pthreads какие-либо преимущества перед GCD?

Это потрясающее чувство, которое вы испытываете ... именно поэтому был изобретен GCD.

На самом базовом уровне есть потоки, pthreads - это POSIX API для потоков, поэтому вы можете писать код в любой совместимой ОС и ожидать, что он будет работать. GCD построен на основе потоков (хотя я не уверен, действительно ли они использовали pthreads в качестве API). Я считаю, что GCD работает только на OS X и iOS, и это в двух словах является его основным недостатком.

Обратите внимание, что проекты, которые интенсивно используют потоки и требуют высокой производительности, реализуют собственную версию пулов потоков. GCD позволяет вам в который раз не изобретать (заново) колесо.

Я иду с другой стороны: начал использовать pthreads в своем приложении, которое я недавно заменил на std::thread из C ++ 11. Теперь я играю с конструкциями более высокого уровня, такими как псевдо-ускоренный пул потоков, и даже более абстрактным, Intel Стандартные блоки потоков. Я бы посчитал, что GCD будет на уровне или даже выше, чем TBB.

Несколько комментариев:

• imho, pthread не сложнее, чем GCD: по сути, pthread фактически содержит очень мало команд (всего несколько: использование только тех, которые упомянуты в OP, даст вам 95% + функциональности что вам когда-нибудь понадобится). Как и любая библиотека нижнего уровня, то, как вы их собираете и как вы используете, дает вам всю силу. Не забывайте, что в конечном итоге библиотеки, такие как GCD и TBB, будут вызывать библиотеку потоков, например pthreads или std::thread.
• иногда успех или неудача зависит не от того, что вы используете, а от того, как вы это используете. Как сторонники библиотеки, TBB или GCD расскажут вам обо всех преимуществах использования их библиотек, но пока вы не опробуете их в контексте реального приложения, все это будет теоретической пользой. Например, когда я прочитал о том, как легко использовать мелкозернистый parallel_for, я сразу же применил его в задаче, для которой, как мне казалось, можно было бы извлечь выгоду из параллелизма. Естественно, меня тоже привлек тот факт, что TBB будет обрабатывать все детали об оптимальной балансировке нагрузки и распределении потоков. Результат? TBB занял в пять раз больше времени, чем однопоточная версия! Но я не виню TBB: оглядываясь назад, очевидно, что это случай неправильного использования parallel_for: когда я читал мелкий шрифт, я обнаружил накладные расходы, связанные с использованием parallel_for, и предположил, что в моем случае затраты на переключение контекста и добавленные вызовы функций перевешивают преимущества использования нескольких потоков. Поэтому вы должны профилировать свое дело, чтобы увидеть, какой из них будет работать быстрее. Возможно, вам придется реорганизовать свой алгоритм, чтобы использовать меньше накладных расходов на потоки.
• почему это происходит? Как pthread или никакие потоки могут быть быстрее, чем GCD или TBB? Когда дизайнер проектирует GCD или TBB, он должен делать предположения о среде, в которой будут выполняться задачи. Фактически, библиотека должна быть достаточно общей, чтобы она могла обрабатывать странные, непредвиденные варианты использования со стороны разработчика. Эти общие реализации не будут бесплатными. С другой стороны, библиотека будет запрашивать оборудование и текущую рабочую среду, чтобы лучше сбалансировать нагрузку. Будет ли это работать вам на пользу? Единственный способ узнать это - попробовать.
• есть ли польза от изучения низкоуровневых библиотек, таких как std::thread, когда доступны высокоуровневые библиотеки? Ответ - громкое ДА. Преимущество использования высокоуровневых библиотек заключается в абстракции от деталей реализации. Недостатком использования высокоуровневых библиотек также является абстракция от деталей реализации. При использовании pthreads я в высшей степени осведомлен об общем состоянии и времени жизни объектов, потому что, если я ослаблю бдительность, особенно в проекте среднего или большого размера, я могу очень легко получить условия гонки или сбои памяти. Эти проблемы исчезнут, когда я использую библиотеку более высокого уровня? Не совсем. Похоже, мне не нужно думать о них, но на самом деле, если я буду небрежно с этими деталями, реализация библиотеки также выйдет из строя. Таким образом, вы обнаружите, что если вы понимаете конструкции нижнего уровня, все эти библиотеки действительно имеют смысл, потому что в какой-то момент вы будете думать о их реализации самостоятельно, если будете использовать вызовы нижнего уровня. Конечно, на этом этапе обычно лучше использовать проверенный и отлаженный библиотечный вызов.

Итак, давайте разберем возможные реализации:

• Вызовы библиотеки TBB / GCD: наибольшее преимущество для новичков в многопоточности. У них более низкие барьеры для входа по сравнению с изучением библиотек более низкого уровня. Однако они также игнорируют / скрывают некоторые ловушки использования многопоточности. Динамическая балансировка нагрузки сделает ваше приложение более переносимым без дополнительного программирования с вашей стороны.
• Вызовы pthread и std::thread: на самом деле нужно изучить очень мало вызовов, но их правильное использование требует внимания к деталям и глубокого понимания того, как работает ваше приложение. Если вы можете понимать потоки на этом уровне, API-интерфейсы высокоуровневых библиотек, безусловно, будут иметь больше смысла.
• Однопоточный алгоритм: давайте не будем забывать о преимуществах простого однопоточного сегмента. Для большинства приложений однопоточность проще для понимания и гораздо менее подвержена ошибкам, чем многопоточность. Фактически, во многих случаях это может быть правильный выбор дизайна. Дело в том, что реальное приложение проходит через различные фазы многопоточности и фазы однопоточности: возможно, нет необходимости постоянно быть многопоточным.

Какой из них самый быстрый? Удивительно, но это может быть любой из трех перечисленных выше. Чтобы получить преимущества в скорости многопоточности, вам может потребоваться радикальная реорганизация ваших алгоритмов. Перевешивают ли выгоды затраты или нет, в значительной степени зависит от конкретного случая.

О, и OP спросил о случаях, когда thread_pool не подходит. Простой случай: если у вас есть плотный цикл, который не требует большого количества циклов на цикл для вычислений, использование thread_pool может стоить больше, чем преимущества без серьезной переделки. Также помните о накладных расходах на вызовы функций, таких как лямбда-выражение через пулы потоков, по сравнению с использованием одного жесткого цикла.

Для большинства приложений многопоточность - это своего рода оптимизация, поэтому делайте это в нужное время и в нужных местах.

GCD - это технология Apple, не самая кроссплатформенная; pthread доступны практически во всем, начиная с OSX, Linux, Unix, Windows ... включая этот тостер

GCD оптимизирован для параллелизма пула потоков. Pthreads - это (как вы сказали) очень сложные строительные блоки для параллелизма, вам остается разрабатывать свои собственные модели. Я настоятельно рекомендую взять книгу по этой теме, если вы хотите узнать больше о pthreads и различных моделях параллелизма.

Как и любой декларативный подход с поддержкой, например openmp или Intel TBB GCD должен быть очень хорош в досадно параллельном проблемы и, вероятно, будет легко победить наивную параллельную сортировку, запрограммированную вручную. Я бы посоветовал вам все же изучить pthreads. Вы лучше поймете параллелизм, вы сможете применить правильный инструмент в каждой конкретной ситуации, и если ничего другого - существует масса кода, основанного на pthread, - вы сможете читать «устаревший» код.

Обычно: одна задача на каждую реализацию Pthread использует мьютексы (функция ОС).
GCD: 1 задача на блок, сгруппированы в очереди. 1 поток на виртуальный ЦП может получить очередь и выполнять все задачи без мьютексов. Это снижает накладные расходы на управление потоками и мьютекс, что должно повысить производительность.

GCD абстрагирует потоки и предоставляет вам очереди отправки. Он создает потоки по своему усмотрению с учетом количества доступных ядер процессора. GCD имеет открытый исходный код и доступен через библиотеку libdispatch. FreeBSD включает libdispatch начиная с версии 8.1. GCD и C Blocks - это мэрский вклад Apple в сообщество программистов C. Я бы никогда не стал использовать ОС, не поддерживающую GCD.