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

Код C ++ не имеет отношения к справедливости, изоляции, обнаружению ошибок или распределению, которые являются всем тем, что Erlang привносит как часть своей модели акторов.

• Ни одному актеру не разрешается морить голодом любого другого актера (справедливость)
• Если один актер выйдет из строя, это повлияет только на этого актера (изоляция)
• Если один субъект выходит из строя, другие участники должны иметь возможность обнаруживать этот сбой и реагировать на него (обнаружение неисправности).
• Актеры должны иметь возможность общаться по сети, как если бы они были на одной машине (распространение)

Также эмулятор лучевого SMP обеспечивает JIT-планирование акторов, перемещая их в ядро, которое на данный момент является наименее загруженным, а также переводит потоки в спящий режим на определенных ядрах, если они больше не нужны.

Вдобавок все библиотеки и инструменты, написанные на Erlang, могут предполагать, что мир работает именно так, и быть спроектированы соответствующим образом.

Это не невозможно сделать в C ++, но становится все труднее, если вы добавите тот факт, что Erlang работает почти со всеми основными конфигурациями аппаратного и ОС.

изменить: только что нашел описание Ульфа Вигера о том, как он видит параллелизм в стиле Erlang.

Я не люблю цитировать себя, но из Первое правило программирования Вирдинга

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

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

Во-первых, снимает замки. В книге Джо Армстронга излагается этот мысленный эксперимент: предположим, что ваш процесс получает блокировку, а затем сразу дает сбой (сбой памяти вызывает сбой процесса или отключение питания части системы). В следующий раз, когда процесс ожидает той же блокировки, система только что зашла в тупик. Это может быть очевидная блокировка, как в вызове AquireScopedLock () в примере кода; или это может быть неявная блокировка, полученная от вашего имени менеджером памяти, например, при вызове malloc () или free ().

В любом случае сбой вашего процесса остановил работу всей системы. Фини. Конец истории. Ваша система мертва. Если вы не можете гарантировать, что каждая библиотека, которую вы используете в C / C ++, никогда не вызывает malloc и никогда не получает блокировку, ваша система не является отказоустойчивой. Системы Erlang могут и действительно уничтожают процессы по желанию, когда они находятся под большой нагрузкой, чтобы прогрессировать, поэтому при масштабировании ваши процессы Erlang должны быть уничтожаемыми (в любой отдельной точке выполнения), чтобы поддерживать пропускную способность.

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

Во-вторых, Erlang устраняет статическую типизацию, что, в свою очередь, обеспечивает возможность горячей замены кода и одновременного запуска двух версий одного и того же кода. Это означает, что вы можете обновить свой код во время выполнения, не останавливая систему. Таким образом системы остаются работоспособными в течение девяти девяток или 32 мсек простоя в год. Их просто модернизируют на месте. Для обновления ваши функции C ++ необходимо будет повторно связать вручную, а одновременное выполнение двух версий не поддерживается. Обновление кода требует простоя системы, и если у вас есть большой кластер, который не может запускать более одной версии кода одновременно, вам нужно сразу отключить весь кластер. Ой. А в телекоммуникационном мире это не терпимо.

Вдобавок Erlang забирает разделяемую память и разделяемую совместно используемую сборку мусора; каждый легкий процесс собирает мусор независимо. Это простое расширение первого пункта, но подчеркивает, что для истинной отказоустойчивости вам нужны процессы, которые не заблокированы с точки зрения зависимостей. Это означает, что ваши паузы GC по сравнению с java допустимы (маленькие, вместо получасовой паузы для завершения GC на 8 ГБ) для больших систем.

Существуют актуальные библиотеки акторов для C ++:

• http://actor-framework.org/

• http://www.theron-library.com/

И список некоторых библиотек для других языков.

Речь идет не столько о модели акторов, сколько о том, насколько сложно правильно написать что-то, аналогичное OTP на C ++. Кроме того, разные операционные системы предоставляют радикально разную отладку и системные инструменты, а виртуальная машина Erlang и несколько языковых конструкций поддерживают единый способ определения того, чем занимаются все эти процессы, что было бы очень сложно сделать единообразным способом (или, возможно, вообще) на нескольких платформах. (Важно помнить, что Erlang / OTP возник раньше, чем нынешний ажиотаж вокруг термина «модель акторов», поэтому в некоторых случаях такого рода дискуссии сравнивают яблоки и птеродактили; великие идеи склонны к самостоятельному изобретению.)

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

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

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

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

Так что на самом деле дело не в необходимости языка, как Erlang, а в уже существующей среде выполнения и OTP, выраженных довольно чисто, и чрезвычайно сложно реализовать что-либо близкое к нему на другом языке. OTP - это просто акт, которому сложно следовать. Точно так же нам не совсем нужен C ++, мы могли бы просто придерживаться сырого двоичного ввода, Brainfuck и считать Assembler нашим языком высокого уровня. Также нам не нужны поезда или корабли, так как все мы умеем ходить и плавать.

При этом байт-код виртуальной машины хорошо документирован, и появилось несколько альтернативных языков, которые компилируются с ней или работают со средой выполнения Erlang. Если мы разделим вопрос на языковую / синтаксическую часть («Должен ли я понимать лунные руны для параллелизма?») И платформенную часть («Является ли OTP наиболее зрелым способом обеспечения параллелизма, и поможет ли он мне решить самые сложные вопросы? , наиболее распространенные ошибки, которые можно найти в параллельной распределенной среде? "), то ответ будет (" нет "," да ").

Casablanca - еще один новичок в блоке модели акторов. Типичный асинхронный прием выглядит так:

PID replyTo;
NameQuery request;
accept_request().then([=](std::tuple<NameQuery,PID> request)
{
   if (std::get<0>(request) == FirstName)
       std::get<1>(request).send("Niklas");
   else
       std::get<1>(request).send("Gustafsson");
}

(Лично я считаю, что CAF лучше скрывает сопоставление с образцом за красивым интерфейс.)