Зеленая нить
В компьютерном программировании — зеленый поток это поток , запланированный библиотекой времени выполнения или виртуальной машиной (ВМ), а не изначально базовой операционной системой (ОС). Зеленые потоки эмулируют многопоточные среды, не полагаясь на какие-либо собственные возможности ОС, и управляются в пространстве пользователя , а не в пространстве ядра , что позволяет им работать в средах, не имеющих встроенной поддержки потоков. [1]
Этимология
[ редактировать ]Зеленые потоки относятся к названию исходной библиотеки потоков для языка программирования Java (которая была выпущена в версии 1.1 от зеленых потоков отказались , а затем в версии 1.3 в пользу собственных потоков). Он был разработан The Green Team в Sun Microsystems . [2]
История
[ редактировать ]Зеленые потоки некоторое время были доступны в Java между 1997 и 2000 годами.
Зеленые потоки совместно используют один поток операционной системы посредством совместного параллелизма и поэтому не могут достичь прироста производительности за счет параллелизма, как потоки операционной системы. Основное преимущество сопрограмм и зеленых потоков — простота реализации.
Производительность
[ редактировать ]![]() | Этот раздел необходимо обновить . ( февраль 2014 г. ) |
На многоядерном процессоре реализации собственных потоков могут автоматически распределять работу между несколькими процессорами, тогда как реализации зеленого потока обычно не могут. [1] [3] На некоторых виртуальных машинах зеленые потоки можно запускать гораздо быстрее. Однако на однопроцессорных компьютерах наиболее эффективная модель еще четко не определена.
Тесты на компьютерах с ядром Linux версии 2.2 (выпущенной в 1999 году) показали, что: [4]
- Зеленые потоки значительно превосходят собственные потоки Linux при активации и синхронизации потоков .
- Собственные потоки Linux имеют немного лучшую производительность при ввода-вывода (I/O) и переключении контекста . операциях
Когда зеленый поток выполняет блокирующий системный вызов, блокируется не только этот поток, но и все потоки внутри процесса. [5] Чтобы избежать этой проблемы, зеленые потоки должны использовать асинхронные операции ввода-вывода , хотя повышенную сложность на стороне пользователя можно уменьшить, если виртуальная машина, реализующая зеленые потоки, порождает определенные процессы ввода-вывода (скрытые для пользователя) для каждого ввода-вывода. О операция. [ нужна ссылка ]
Существуют также механизмы, которые позволяют использовать собственные потоки и снижают затраты на активацию и синхронизацию потоков:
- Пулы потоков сокращают стоимость создания нового потока за счет повторного использования ограниченного числа потоков. [6]
- Языки, использующие виртуальные машины и собственные потоки, могут использовать escape-анализ, чтобы избежать синхронизации блоков кода, когда они не нужны. [7]
Зеленые потоки в виртуальной машине Java
[ редактировать ]В Java 1.1 зеленые потоки были единственной моделью потоков, используемой виртуальной машиной Java (JVM). [8] по крайней мере на Солярисе . Поскольку зеленые потоки имеют некоторые ограничения по сравнению с собственными потоками, в последующих версиях Java от них отказались в пользу собственных потоков. [9] [10]
Исключением является виртуальная машина Squawk , представляющая собой смесь операционной системы для маломощных устройств и виртуальной машины Java. Он использует зеленые потоки, чтобы свести к минимуму использование собственного кода и поддержать миграцию его изолятов.
Коврик [11] [12] и Квазар [13] [14] — это проекты с открытым исходным кодом, которые реализуют зеленые потоки в более поздних версиях JVM путем изменения байт-кода Java, созданного компилятором Java (Quasar также поддерживает Kotlin и Clojure ).
Зеленые нити на других языках
[ редактировать ]Существуют некоторые другие языки программирования , которые реализуют эквиваленты зеленых потоков вместо собственных потоков. Примеры:
- Chicken Scheme использует облегченные потоки пользовательского уровня, основанные на первоклассных продолжениях. [15]
- Общий Лисп [16]
- CPython изначально поддерживает asyncio, начиная с версии 3.4, существуют альтернативные реализации, такие как greenlet , eventlet и gevent , PyPy. [17]
- Crystal предлагает волокна [18]
- D предлагает волокна , используемые для асинхронного ввода-вывода. [19]
- Dyalog APL называет их потоками. [20]
- Эрланг [21]
- Go реализует так называемые горутины [22]
- Хаскелл [22]
- Юля зеленые нити использует для своих Заданий .
- Лимбо [23]
- Lua использует сопрограммы для параллелизма. Lua 5.2 также предлагает настоящую семантику сопрограмм C через функции lua_yieldk , lua_callk и lua_pcallk . Расширение CoCo обеспечивает истинную семантику сопрограмм C для Lua 5.1.
- Nim обеспечивает асинхронный ввод-вывод и сопрограммы.
- OCaml , начиная с версии 5.0, поддерживает зеленые потоки через Domainslib.Task. модуль
- occam , который предпочитает термин «процесс», а не «поток», поскольку его происхождение связано с последовательными процессами.
- Perl поддерживает зеленые потоки через сопрограммы
- PHP поддерживает зеленые потоки через волокна и сопрограммы.
- Руби до версии 1.9 [24]
- Racket (родные темы также доступны через Places [25] )
- Rust изначально поддерживает системные потоки [26] и поддерживает асинхронный ввод-вывод через сторонние библиотеки, такие как Tokio.
- SML/NJ Реализация Concurrent ML
- Smalltalk (большинство диалектов: Squeak , VisualWorks, GNU Smalltalk и т. д.)
- Stackless Python поддерживает либо вытесняющую многозадачность , либо совместную многозадачность посредством микропотоков (называемых тасклетами ). [27]
- В Tcl есть сопрограммы и цикл событий. [28]
Виртуальная машина Erlang имеет так называемые зеленые процессы — они похожи на процессы операционной системы (они не разделяют состояние, как потоки), но реализованы в системе времени выполнения Erlang (erts). Их иногда называют зелеными нитями , но они имеют существенные различия. [ нужны разъяснения ] из стандартных зеленых ниток. [ нужна ссылка ]
В случае GHC Haskell переключение контекста происходит при первом выделении после настраиваемого таймаута. Потоки GHC также потенциально выполняются в одном или нескольких потоках ОС в течение их жизни (между потоками GHC и потоками ОС существует связь «многие ко многим»), что обеспечивает параллелизм на симметричных многопроцессорных машинах, не создавая при этом более дорогостоящих потоков ОС, чем необходимо. для работы на доступном количестве ядер. [ нужна ссылка ]
Большинство виртуальных машин Smalltalk не учитывают этапы оценки; однако виртуальная машина по-прежнему может вытеснять исполняемый поток внешними сигналами (такими как истечение срока действия таймеров или появление доступности ввода-вывода). Обычно циклическое планирование используется для того, чтобы процесс с высоким приоритетом, который регулярно просыпается, эффективно реализовывал вытеснение с разделением времени :
[
[(Delay forMilliseconds: 50) wait] repeat
] forkAt: Processor highIOPriority
Другие реализации, например QKS Smalltalk, всегда используют разделение времени. В отличие от большинства реализаций зеленого потока, QKS также поддерживает предотвращение инверсии приоритетов .
Отличия от виртуальных потоков в виртуальной машине Java
[ редактировать ]Виртуальные потоки были представлены в качестве предварительной функции в Java 19. [29] и стабилизирован в Java 21. [30] Важные различия между виртуальными потоками и зелеными потоками:
- Виртуальные потоки сосуществуют с существующими (невиртуальными) потоками платформы и пулами потоков.
- Виртуальные потоки защищают свою абстракцию:
- В отличие от зеленых потоков, спящий режим виртуального потока не блокирует основной поток-носитель.
- Работе с локальными переменными потока уделяется меньше внимания, а в качестве более легкой замены предлагаются значения с ограниченной областью действия. [31]
- Виртуальные потоки можно легко приостановить и возобновить, используя поддержку JVM для специальных задач.
jdk.internal.vm.Continuation
сорт. - Виртуальные потоки обрабатывают блокирующие вызовы, прозрачно отключаясь от несущего потока, где это возможно, в противном случае компенсируя это увеличением количества потоков платформы.
См. также
[ редактировать ]- Асинхронный/ожидание
- Легкий процесс
- Сопрограмма
- виртуальная машина Java
- Глобальная блокировка переводчика
- Волокно (информатика)
- Переносимые потоки GNU
- Протопотоки
Ссылки
[ редактировать ]- ^ Перейти обратно: а б Синтес, Тони (13 апреля 2001 г.). «Четверо на века» . JavaWorld . Архивировано из оригинала 15 июля 2020 г. Проверено 14 июля 2020 г.
Зеленые потоки, потоки, предоставляемые JVM, выполняются на уровне пользователя, а это означает, что JVM сама создает и планирует потоки. Поэтому ядро операционной системы не создает и не планирует их. Вместо этого базовая ОС видит JVM только как один поток. Зеленые нити оказываются неэффективными по ряду причин. Прежде всего, зеленые потоки не могут использовать преимущества многопроцессорной системы (...). Таким образом, потоки JVM обязаны выполняться внутри одного потока JVM, который работает внутри одного процессора.
{{cite web}}
: CS1 maint: bot: исходный статус URL неизвестен ( ссылка ) - ^ «Технология Java: первые годы» . java.sun.com . 22 декабря 2014 г. Архивировано из оригинала 30 мая 2008 г.
- ^ «Чем отличаются «зеленые» нити от «родных»?» . jguru.com . 6 сентября 2000 г. Проверено 1 июня 2009 г.
На многопроцессорных машинах собственные потоки могут запускать более одного потока одновременно, назначая разные потоки разным процессорам. Зеленые потоки выполняются только на одном процессоре.
- ^ «Сравнительная оценка производительности потоков Java для встроенных приложений: Linux Thread против Green Thread». CiteSeerX 10.1.1.8.9238 .
- ^ Столлингс, Уильям (2008). Операционные системы, внутренние принципы и принципы проектирования . Нью-Джерси: Прентис Холл. п. 171. ИСБН 9780136006329 .
- ^ Зигер, Ник (22 июля 2011 г.). «Параллелизм в JRuby» . Машинный двор . Архивировано из оригинала 30 января 2014 г. Проверено 26 января 2013 г.
Для систем с большими объемами электронной почты этот наивный подход может оказаться неэффективным. Собственные потоки требуют больших затрат на инициализацию и объем памяти, чем зеленые потоки, поэтому JRuby обычно не может поддерживать более 10 000 потоков. Чтобы обойти эту проблему, мы можем использовать пул потоков.
- ^ Гетц, Брайан (18 октября 2005 г.). «Теория и практика Java: оптимизация синхронизации в Mustang» . ИБМ . Проверено 26 января 2013 г.
- ^ «Потоки Java в среде Solaris – более ранние выпуски» . Корпорация Оракл . Проверено 26 января 2013 г.
В результате возникло несколько проблем: приложения Java не могли взаимодействовать с существующими приложениями MT в среде Solaris, потоки Java не могли работать параллельно на многопроцессорах, приложение MT Java не могло использовать настоящий параллелизм ОС для более быстрых приложений ни на однопроцессорах, ни на многопроцессорах. . Чтобы существенно повысить производительность приложений, библиотека зеленых потоков была заменена собственными потоками Solaris для Java на платформе Solaris 2.6; это перенесено на платформы Solaris 7 и Solaris 8.
- ^ «Нитки: Зелёные или Родные» . Группа ШОС . Проверено 26 января 2013 г.
Выигрыш в производительности от использования собственных потоков на машине MP может быть значительным. Например, используя искусственный тест, в котором потоки Java выполняют обработку независимо друг от друга, можно добиться трехкратного увеличения общей скорости на машине с 4 процессорами MP.
- ^ «Нитки: Зелёные или Родные» . codestyle.org. Архивировано из оригинала 16 января 2013 г. Проверено 26 января 2013 г.
JVM требует значительных затрат на обработку для отслеживания состояний потоков и переключения между ними, поэтому режим зеленого потока устарел и удален из более поздних реализаций Java.
- ^ «килим» . Гитхаб . Проверено 9 июня 2016 г.
- ^ «Килим» . www.malhar.net . Проверено 9 июня 2016 г.
- ^ «Код Квазара на GitHub» . Гитхаб .
- ^ «Параллельная Вселенная» . Архивировано из оригинала 22 декабря 2015 года . Проверено 6 декабря 2015 г.
- ^ «Куриная схема» . Проверено 5 ноября 2017 г.
- ^ "thezerobit/green-threads" . Гитхаб . Проверено 8 апреля 2016 г.
- ^ «Функции Stackless на уровне приложения — документация PyPy 4.0.0» . Проверено 6 декабря 2015 г.
- ^ «Параллелизм: GitBook» . Crystal-lang.org . Проверено 03 апреля 2018 г.
- ^ «Волокна — Дланг Тур» . www.tour.dlang.org . Проверено 2 мая 2022 г.
- ^ «Темы: Обзор» . Справка по Dialog APL 17.0 . Проверено 14 декабря 2018 г.
Поток — это цепочка выполнения в рабочей области APL.
- ^ @joeerl (23 июня 2018 г.). «Процессы Erlang эмулируются в виртуальной машине Erlang, как зеленые потоки — они нам нравятся, поскольку это упрощает многие проблемы…» ( Твит ) – через Twitter .
- ^ Перейти обратно: а б «Иди и догма» . исследование!rsc . Проверено 14 января 2017 г.
например, и Go, и Haskell нуждаются в своего рода «зеленых потоках», поэтому существует больше общих проблем во время выполнения, чем вы могли ожидать.
- ^ «Язык программирования Лимбо» . www.vitanuova.com . Проверено 1 апреля 2019 г.
- ^ «Многопоточность в интерпретаторе MRI Ruby | BugFactory» . Проверено 18 июня 2024 г.
- ^ «Рэкетные места» . Проверено 13 октября 2011 г.
Места позволяют разрабатывать параллельные программы, использующие преимущества машин с несколькими процессорами, ядрами или аппаратными потоками. Место — это параллельная задача, которая по сути является отдельным экземпляром виртуальной машины Racket.
- ^ «Использование потоков для одновременного выполнения кода — язык программирования Rust» . doc.rust-lang.org . Проверено 24 сентября 2021 г.
- ^ «Stackless.com: О Stackless» . Архивировано из оригинала 27 февраля 2012 г. Проверено 27 августа 2008 г.
Встроенный планировщик циклического перебора. Его можно использовать для планирования тасклетов как совместно, так и упреждающе.
- ^ «Цикл событий Tcl» . Проверено 6 декабря 2015 г.
- ^ «JEP 425: Виртуальные потоки (предварительная версия)» . Проверено 25 января 2024 г.
- ^ «JEP 444: Виртуальные потоки» . Проверено 25 января 2024 г.
- ^ «JEP 464: ограниченные значения (вторая предварительная версия)» . Проверено 25 января 2024 г.
Внешние ссылки
[ редактировать ]- « Четверо на века », статья JavaWorld о зеленых нитях
- Зеленые темы в темах по Java: часто задаваемые вопросы