Каково различие между “зелеными потоками” и процессами Erlang?

Когда люди возражают против того, чтобы называть процессы Erlang «зелеными потоками», они не возражают против «зеленой» части, они возражают против «части».

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

Процессы Erlang ничего не разделяют, таким образом, они являются настоящими процессами. Однако обычно они реализуются «зеленым» способом. Так что технически это «зеленые процессы».

Я обычно называю их «зелеными потоками», когда я хочу подчеркнуть легкую реализацию , и называю их «процессами». когда я хочу подчеркнуть семантику «ничего не разделяемое» . Таким образом, мне не нужно объяснять, что я имею в виду под «зелеными процессами».

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

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

Заметные ситуации, когда это делается в Erlang/OTP:

• Большие двоичные файлы (более 64 байт) - это ссылки, считанные в специальной двоичной куче, и ссылки в эту куче передаются при передаче сообщений.
• Буквальные значения помещаются в специальную область памяти, все процессы, на которые они ссылаются, ссылаются на значения в той же самой области памяти (но как только значение передается в сообщении, в процессе приёма делается дубликат).
• Каждый узел как глобальная таблица атомов, и значения атомов действительно являются ссылками в эту таблицу, это делает проверку атомного равенства очень эффективной (сравните указатель вместо строки).
• Экспериментальная настройка erl -hybrid, которая объединяет кучи процессов и кучи общих папок, заставляя процессы копировать значения из кучи процессов в кучи общих папок первыми при их использовании в сообщении. Я нашел эту тему о гибридных кучах, которая также объясняет некоторые проблемы с концепцией.

Другой трюк, который можно сделать, это фактически мутировать значения, но сделать так, чтобы оно не было видно. Это является дополнительным объяснением того, что непреложные значения являются семантическим ограничением.

Вот несколько примеров, когда OTP/Erlang на самом деле будет мутировать значения:

• "Последние" (R12) оптимизации в работе с синтаксисом двоичных файлов позволяют добавлять в конец двоичных файлов и фактически не строить новый двоичный файл с добавленным новым хвостом.
• Было сказано, что новые кортежи с немедленным элементом set_element могут быть или были однажды транслированы компилятором для фактического изменения элемента на месте кортежа.

Эти оптимизации идут под теорию, что "если дерево падает в лесу, и никого нет рядом, чтобы его услышать, действительно ли оно издает звук?". То есть, ссылки не должны были ускользнуть от объекта, который должен быть мутирован. Потому что тогда можно заметить, что он изменился.

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

Другое упрощение, которое заходит слишком далеко, это сказать, что у Эрланга нет никаких побочных эффектов. Но это еще один вопрос, если его когда-нибудь зададут.