Параллелизм уровня потока VS Параллелизм уровня процесса

Question

У меня есть базовое понимание потоков и процессов, мне интересно, почему в каждом учебнике говорится о параллелизме на уровне потоков, существует ли параллелизм на уровне процессов? В чем преимущества параллелизма на уровне потоков по сравнению с параллелизмом на уровне процессов?

Answer 1

Существует параллелизм на уровне процесса.

Однако ядро ​​Linux не имеет представления о потоках или процессах. Он знает только задачи.

Существует Task_parallelism , который выполняется процессами или потоками.

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

Существуют также API-интерфейсы Linux, позволяющие управлять количеством ресурсов, которые можно совместно использовать или не распределять между потоками, что обеспечивает большую гибкость.

Именно поэтому параллелизм на уровне потоков более популярен, особенно в приложениях, написанных для коммерческих серверов, таких как базы данных.

Answer 2

Краткий ответ: производительность и простота программирования

Длинный ответ:

Во-первых, необходимо рассмотреть два различных вида параллелизма: параллелизм на основе задач (или «макропараллелизм») (например, задача A изменяет некоторые данные и передает результат в задачу B) и параллелизм на уровне данных (или «микропараллелизм») ( например, нагрузка для обработки большой матрицы или вектора распределяется между несколькими параллельными агентами).

Во-вторых, когда рассматривается параллелизм, разные агенты должны обмениваться информацией. Для параллелизма на уровне потоков все потоки имеют доступ к одному и тому же адресному пространству, а связь - только доступ к памяти. Напротив, параллелизм на уровне процессов требует специальных средств межпроцессного взаимодействия (IPC), чтобы процессы могли обмениваться данными. Существует несколько методов IPC (pipe, shared-mem, сокеты и т. Д.) (См., Например, https://en.wikipedia.org/wiki/Inter-process_communication).

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

На одном процессоре параллелизм на уровне процесса в настоящее время также используется для сценариев оболочки в качестве простого средства для повторного использования существующих программ. Например, в Unix сценарий типа «sort

Кроме того, большие преимущества параллелизма на уровне потоков:

1) простой и быстрый механизм связи через общую память

2) хорошо адаптирован к парализму на уровне задач или параллелизму на уровне данных

3) легко программировать

Пункт 2) и 3), вероятно, являются наиболее важными. В то время как параллелизм на уровне потоков может основываться на независимых задачах, ускорение часто ограничено, и большинство современных приложений используют параллелизм на уровне данных, для которого потоки хорошо адаптированы. Общее пространство памяти делает коммуникационные издержки очень ограниченными (за исключением случаев, когда рассматриваются блокировки), и существуют очень эффективные и простые в использовании инструменты распараллеливания (например, open-MP)

Реализация такого рода параллелизма на независимых процессах также возможна. Это часто случается при рассмотрении больших калькуляторов для высокопроизводительных вычислений. Существуют некоторые (грубые) инструменты (например, «интерфейс передачи сообщений»), но реализация на намного более сложна, подвержена ошибкам и менее эффективна, чем параллелизм на уровне потоков.