Пул потоков и многоядерные системы

Question

Как вы думаете, шаблон проектирования потокового пула - это путь к многоядерному будущему?

Например, библиотека потокового пула, если она широко используется, делает / заставляет программу записи приложения

(1) разбивать проблему на отдельные параллельные задания, что способствует (навязыванию :)) параллелизма

(2) Абстракция от всех низкоуровневых вызовов ОС, синхронизация и т. Д. Облегчает жизнь программиста.(Особенно для программистов на C :))

Я твердо уверен, что это лучший способ (или один из "лучших" способов :)) для многоядерного будущего ...

Итак,у меня вопрос, пишу ли я так, или я в каком-то заблуждении:)

С уважением,

Микроядро

Answer 1

Пул потоков - это метод, который включает очередь и несколько потоков, принимающих задания из очереди и обрабатывающих их.Это отличается от техники запуска новых потоков при появлении новой задачи.

Преимущество состоит в том, что максимальное количество потоков ограничено , чтобы избежать слишком большого количества потоков и что с любой новой задачей связано меньше накладных расходов (поток уже запущен и выполняет задачу. Не требуется запуск угрозы).

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

Во многих областях пул потоков просто бесполезен.Таким образом, вы не можете обобщать.Иногда многопоточность вообще невозможна.Или даже не желательно, так как многопоточность добавляет к вашему коду непредсказуемый элемент (условия гонки), который крайне сложно отлаживать.

Библиотека пула потоков вряд ли "заставит" вас использовать его.Вам все еще нужно все продумать, и если вы просто начнете одну тему ... Не поможет.

Answer 2

Для пулов потоков ядра Windows NT обычно гораздо менее эффективны, чем порты завершения ввода-вывода.Они широко освещены в многочисленных вопросах и ответах здесь.IOCP включают управляемую событиями обработку, в которой несколько потоков могут ожидать на IOCP, пока не произойдет событие из-за IOC (чтение или запись) в сокете или дескрипторе, который затем ставится в очередь в IOCP.IOCP, в свою очередь, связывает ожидающий поток с идентификатором события и освобождает поток для обработки.После того как поток обработал событие и инициировал новый ввод-вывод, он возвращается к IOCP, чтобы дождаться следующего события (которое может быть или не быть завершением ввода-вывода, которое он только что инициировал).

IOC также могут быть искусственно сигнализированы путем явной публикации из не-события.

Использование IOCP не является опросом.Оптимальная реализация IOCP будет иметь столько потоков, ожидающих на IOCP, сколько имеется ядер в системе.Все потоки могут выполнять один и тот же физический код, если он считается эффективным.Поскольку поток обрабатывает от IOC до момента ввода / вывода, он ничего не делает, что заставляет его ждать других ресурсов, за исключением, возможно, конкуренции за доступ к областям, безопасным для потока.Это естественный выбор, чтобы отойти от парадигмы «одна ручка на нить».Поэтому потоки, контролируемые IOCP, настолько эффективны, насколько их может программист.

Answer 3

Как и почти для каждой темы информатики, ответ таков: она зависит.

система объединения в порядке с смущающе параллельной http://en.wikipedia.org/wiki/Embarrassingly_parallel

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

Answer 4

Мне очень нравится ответ @yaankee, за исключением того, что я бы сказал, что пул потоков - это почти всегда правильный путь.Причина: пул потоков может выродиться в простую статическую модель разделения работы для таких задач, как умножение матрицы на матрицу.OpenMP руководствуется в том же духе.