В программировании, Зеленые потоки (англ. Green threads) — это потоки, управление которыми вместо операционной системы выполняет виртуальная машина (ВМ). Green threads эмулируют многопоточную среду, не полагаясь на возможности ОС по реализации легковесных потоков. Управление ими происходит в пользовательском пространстве, а не пространстве ядра, что позволяет им работать в условиях отсутствия поддержки встроенных потоков.^[1]

Выполнение

На многоядерных процессорах, родная реализация встроенных потоков (native threads) может автоматически назначать работу нескольким процессорам, в то время как реализация green threads обычно не может^[1][2]. Green threads могут быть запущенны гораздо быстрее на некоторых виртуальных машинах. Однако, на однопроцессорных компьютерах наиболее эффективная модель ещё не определена. Тесты на компьютерах под управлением (старого) Linux на ядре версии 2.2 показали^[3]:

• Green threads значительно превосходят встроенные потоки Linux системы по времени активации потоков и синхронизации.
• Встроенные потоки Linux имеют несколько более высокую производительность операций ввода/вывода и переключения контекста.

Когда green thread выполняет блокирующий системный вызов, блокируется не только этот поток, но и все потоки внутри процесса^[4]. Чтобы избежать этой проблемы, green threads должны использовать асинхронные операции ввода/вывода, хотя данную сложность можно скрыть порождать скрытые для пользователя процессы на каждую операцию ввода/вывода, которые объединяются с green thread.

Есть также механизмы, которые позволяют использовать собственные потоки и снизить накладные расходы на активацию и синхронизацию потоков:

• Пулы потоков снижают затраты на порождение новых потоков за счет повторного использования ограниченного числа потоков^[5].
• Также, языки, исполняющиеся на виртуальных машинах, НО использующие native threads, могут использовать технику оптимизации — анализ побочных эффектов (Escape-анализ), чтобы избежать синхронизации блоков кода, когда это возможно^[6].

Green threads в JVM

В Java 1.1 green threads являлись единственной потоковой моделью (моделью распараллеливания потоков), используемой в JVM^[7], по крайней мере, в Solaris. Ввиду того, что green threads обладают ограничениями в сравнении с native threads, в последующих версиях Java основной упор сделан на native threads.

Исключением является виртуальная машина Squawk, которая представляет собой смесь ОС для маломощных устройств и JVM. Она использует green threads для того, чтобы сохранить машинный код в абсолютном минимуме и поддерживать миграцию своих изолятов (isolates).

Green threads в других языках

Есть и другие языки программирования, в которых по-прежнему аналоги green threads используются вместо native threads. Примеры:

• greenlet, eventlet и gevent
• Go
• Haskell
• Limbo
• сопрограммы для параллелизма. Эталонная реализация ограничивает их использование в коде Lua, но coco расширение позволяет использовать истинную семантику сопрограмм в C.
• Occam, который предпочитает термин «процесс» вместо термина «поток» из-за своего происхождения в Communicating sequential processes.
• Ruby до версии 1.9
• SML/NJ реализации Concurrent ML
• Smalltalk
• Stackless Python — поддерживает вытесняющую многозадачность или кооперативную многозадачность через микропотоки (так называемые тасклеты (tasklets))^[8].

В виртуальной машине Erlang имеет то, что можно назвать «green processes» — они как рабочие процессы системы (они не объявляют состояние, как это делают потоки), но реализуются в рамках Erlang Run Time System (ERTS). Их иногда рассматривают в качестве «green threads», но они имеют существенные отличия от стандартных green threads.

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

Occam выделяется в данном списке, потому что его оригинальная реализация была привязана к Транспьютеру, и, следовательно, не было необходимости в использовании виртуальной машины. Позже его портированные на другие процессоры копии обладали виртуальной машиной, построенной на базе Transputer`а, что являлось обоснованным с точки зрения эффективности решением, ввиду низких накладных расходов, необходимых для портирования.

Большинство виртуальных машин Smalltalk не ведут расчет оценки шагов; однако ВМ способна выделять выполняемый поток на внешние сигналы (например, истекающий таймер, или изменение доступности ввода/вывода). Обычно циклическое планирование используется для того, чтобы высокоприоритетный процесс, который должен запускаться регулярно, эффективно выполнял прерывания в режиме разделения времени (реализовывал вытесняющую многозадачность):

[
   [(Delay forMilliseconds: 50) wait] repeat
] forkAt: Processor highIOPriority

Другие реализации, например, QKS Smalltalk, постоянно используют разделение времени. В отличие от большинства реализаций green threads, QKS Smalltalk имеет поддержку предотвращения инверсии приоритетов.

Примечания