Процессы, нити, зеленые нити, протопотоки, волокна, сопрограммы: какая разница?

Question

Я читаю о параллелизме.У меня есть немного над головой с терминами, которые имеют сбивающие с толку определения.А именно:

• Процессы
• Нити
• "Зеленые нити"
• Протопотоки
• Волокна
• Сопрограммы
• "Горутины" на языке Го

У меня сложилось впечатление, что различия основаны на (1) будь то по-настоящему параллельным или мультиплексным;(2) управляются ли они в ЦП, в ОС или в программе;и (3..5) несколько других вещей, которые я не могу определить.

Существует ли краткое и недвусмысленное руководство по различиям между этими подходами к параллелизму?

Answer 1

ОК, я сделаю все возможное.Повсюду есть предостережения, но я сделаю все возможное, чтобы понять мои термины и ссылки на то, что приближается к определению, которое я дал.

• Процесс Управляемый ОС (возможно) действительно параллельный, по крайней мере, при наличии подходящей аппаратной поддержки.Существуют в своем собственном адресном пространстве.
• Thread : Управляется ОС, в том же адресном пространстве, что и родительский объект и все его другие потоки.Возможно, это действительно одновременно, и многозадачность имеет преимущественный характер.
• Зеленая нить : Это проекции в пространстве пользователя, имеющие ту же концепцию, что и потоки, но не управляемые ОС.Вероятно, не совсем одновременный, за исключением того, что может быть несколько рабочих потоков или процессов, одновременно предоставляющих им процессорное время, поэтому, вероятно, лучше всего рассматривать это как чередование или мультиплексирование.
• Протопотоки : Iне мог дразнить определение из этих.Я думаю они чередуются и управляются программами, но не верьте мне на слово.Я чувствовал, что они по сути являются специфичной для приложения реализацией модели «зеленых потоков» с соответствующей модификацией для домена приложения.
• Fibers : управляемый ОС.Точно потоки, за исключением совместной многозадачности и, следовательно, не совсем параллельные.
• сопрограммы : точно волокна, кроме не управляемых ОС.
• Goroutines : Они утверждают, что они не похожи ни на что другое, но кажутся ровно зелеными потоками, как, например, управляемыми процессами в одном адресном пространстве и мультиплексированными в системные потоки.Возможно, кто-то с большим знанием о Go сможет пробиться через маркетинговый материал.

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

Кроме того, помните о разнице между параллельным и одновременно .Возможно, вы использовали первое в своем вопросе, где, я думаю, вы имели в виду второе.

Answer 2

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

• Процесс:
  • Под управлением ОС
  • Каждое имеет свое собственное виртуальное адресное пространство
  • Может быть прервано (прервано) системой для запуска другого процесса
  • Может работать параллельно с другими процессами на других процессорах
  • Слишком высокая нагрузка на память процессов (включает таблицы виртуальной памяти, дескрипторы открытых файлов и т. д.)
  • Затраты времени на создание и переключение контекста между процессами относительно высоки
• Потоки:
  • Управляемый ОС
  • Каждый из них "содержится" в каком-то конкретном процессе
  • Все потоки в одном и том же процессе совместно используют одно и то же виртуальное адресное пространство
  • Может быть прервано системой для разрешениядругой поток для запуска
  • Может работать параллельно с другими потоками на разных процессорах
  • Расходы памяти и времени, связанные с потоками, меньше, чемn процессов, но все еще нетривиальных
    • (Например, обычно переключение контекста включает в себя вход в ядро ​​и вызов системного планировщика.)
• Совместные потоки:
  • Может или не может управляться ОС
  • Каждый «содержится» в каком-то конкретном процессе
  • В некоторых реализациях каждый «содержится» в каком-то конкретномПоток ОС
  • Не может быть прерван системой, чтобы разрешить запуск кооперативного однорангового узла
    • (Разумеется, содержащийся процесс / поток все еще может быть прерван)
  • Должен вызывать специальный примитив yield, чтобы разрешить запуск потоков равноправных кооперативов
  • Обычно нельзя запускать параллельно с кооперативными одноранговыми узлами
    • (хотя некоторые люди считают, что это возможно: http://ocm.dreamhosters.com/.)
  • Существует множество вариантов темы кооперативных нитей, которые называются разными именами:
    • Волокна
    • Зеленые нити
    • Протопотоки
    • Потоки пользовательского уровня (потоки пользовательского уровня могут быть прерывистыми / вытесняющими, но это довольно необычная комбинация)
  • В некоторых реализациях кооперативных потоков используются такие методы, как стеки разделения / сегментирования илидаже индивидуальное выделение кучи для каждого кадра вызова, чтобы уменьшить накладные расходы памяти, связанные с предварительным выделением большого куска памяти для стека
  • В зависимости от реализации, вызов системного вызова блокировки (например, чтение из сети или спящий режим)либо блокирует целую группу взаимодействующих потоков, либо неявно приводит к тому, что вызывающий поток выдает
• Сопрограммы:
  • Некоторые люди используют "сопрограмму" и "кооперативный поток"более или менее синонимично
    • Я не предпочитаю это использование
  • Некоторые реализации сопрограмм на самом деле являются "мелкими" кооперативными потоками;yield может быть вызван только «процедурой ввода сопрограммы»
  • Легкая (или полу-сопрограммная) версия проще в реализации, чем потоки, поскольку для каждой сопрограммы не требуется полный стек (только один кадр для записипроцедура)
  • Часто в сопрограммных каркасах есть примитивы выхода, которые требуют от вызывающего явно указывать, какой контроль сопрограмм следует передать
• Генераторам:
  • Restricted (мелкий) сопрограммы
  • yield может возвращать управление только тому коду, который вызвал генератор
• Запрограммировано:
  • Странный гибрид кооперативных потоков и потоков ОС
  • Невозможно прервать (как взаимодействующие потоки)
  • Может работать параллельно в управляемом языком пуле потоков ОС
• Обработчики событий:
  • Процедуры / методы, которые вызываются диспетчером событий в ответ на какое-либо происходящее действие
  • Очень популярны для программирования пользовательского интерфейса
  • Немного не требуют поддержки языка / системы;может быть реализован в библиотеке
  • Одновременно может работать не более одного обработчика событий;диспетчер должен дождаться окончания обработки (возврата) обработчика перед началом следующего
    • Делает синхронизацию относительно простой;различные исполнения обработчиков никогда не перекрываются во времени
  • Реализация сложных задач с обработчиками событий приводит к «инвертированному потоку управления» / «копированию стека»
• Задачи:
  • Единицы работы, которые распределяются менеджером в пул работников
  • Работниками могут быть потоки, процессы или машины
    • Конечно, видРаботник, используемый библиотекой задач, оказывает значительное влияние на то, как реализуются задачи.
  • В этом списке непоследовательной и запутанной терминологии «задача» берет корону.В частности, в сообществе встраиваемых систем «задача» иногда используется для обозначения «процесс», «поток» или «обработчик события» (обычно называемый «подпрограммой обработки прерывания»).Это также иногда используется в общем / неформальном виде для обозначения любого вида единиц вычислений.

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

Для большинства приложений я думаю, что основанные на задачах платформы лучше всего подходят для распараллеливания.Большинство популярных (Intel TBB, Apple GCD, Microsoft TPL & PPL) используют потоки в качестве рабочих.Хотелось бы, чтобы было несколько хороших альтернатив, использующих процессы, но я не знаю ни о каких.

Если вы заинтересованы в параллелизме (в отличие от параллелизма процессора), обработчики событий - самый безопасный путь.Кооперативные темы - интересная альтернатива, но немного дикого запада.Пожалуйста, не используйте потоки для параллелизма, если вы заботитесь о надежности и надежности вашего программного обеспечения.

Answer 3

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

Я использовал протопотоки для реализации асинхронного ввода-вывода: http://martinschroder.se/asynchronous-io-using-protothreads/

Answer 4

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