Comments 29
Скажите, а messaging frameworks, такие как например zeroMQ, рассматриваются в качестве implementation of Actor Model?
Хм… Никогда не задумывался на эту тему. Насколько я помню, при работе с ZeroMQ нужно самостоятельно извлекать сообщения из канала, определять их тип и искать подходящий обработчик для сообщения. Т.е. приходится вручную делать то, что акторный фреймворк делает автоматически. С этой точки зрения я бы не стал причислять ZeroMQ к реализациям Модели Акторов.

А вот в TIBCO Rendezvous, емнип, брала на себя заботы не только по доставке сообщений через транспортные каналы, но и по диспетчеризации листенеров сообщений. В этом плане листенеры в TIBCO Rendezvous похожи на акторов, а сам TIBCO Rendezvous может рассматриваться одна из возможных реализаций Модели Акторов. Хотя TIBCO Rendezvous больше относится к модели Publish/Subscribe, имхо.

CAF вполне себе нормально компилируется под msvc и требует лишь c++11, поэтому говорить о каком-то игнорировании платформы некорректно — требуется соответствие стандарту.

А разве было сказано, что CAF не компилируется msvc?

Нормально он стал компилироваться после выхода VC 14.0, до этого под Windows они рекомендовали пользоваться MinGW.

высокие требования CAF-а к уровню поддержки стандартов в C++ в компиляторе. Из-за этого разработчики CAF-а никогда не рассматривали Windows и VC++ в качестве одной из значимых платформ для своей разработки, ограничиваясь Linux-ом, FreeBSD MacOS, а также самыми свежими версиями компиляторов gcc и clang.


Высокие требования — это c++11, не более. Появилась поддержка c++11 — появилась поддержка платформы. В 2017 году говорить об этом, как о некой чрезвычайной требовательности, странно.


Посмотрете на историю добавления optional и variant типов — авторы добавили их с оглядкой на совместимость с c++17, но не потребовали поддержки "в новейших компиляторах".

Ну и где речь идет об «игнорировании платформы»? Значимой платформой Windows для них не была, они сами об этом, по-моему, в своем блоге писали. Мол, чем тратить время на борьбу с заморочками msvs, мы лучше сделаем что нам нужно на самых свежих версиях gcc и clang.

Что до 2017-го года, то, к сожалению, еще есть проекты, которые пока еще и не думают на vc 14.0 переходить, хорошо, если хотя бы на vc 12.0 сидят, а то могут и на более старых компиляторах оставаться.

В общем, если вам нравится CAF, то уж простите, что я высказался в их адрес столь жестко. Но я видел развитие событий именно таким образом.
Ну у вас там треть статьи про Erlang и всякие его VM. И даже код приведен. Неспроста же?
Говорить сейчас про Модель Акторов и не упомянуть про Erlang просто нельзя.
Но вот в какой блог нужно было разместить данную статью я так и не понял.

Хорошо бы добавить, что CAF поддерживает несколько различных типов обмена сообщениями:
Обычная отправка адресату, pub/sub (через группы), а также req/rep.


Кроме того, 0.15 получил возможность типизировать акторы, указывая типы обрабатываемых запросов/ответов, с проверкой в compile-time (невозможно отправить актору сообщение неподдерживаемого типа)

Было бы хорошо, если бы тот, кто имеет положительный опыт использования CAF-а, рассказал бы об этом фреймворке русскоязычным читателям в отдельной статье.
Текст претендует на некоторое сравнение существующих фреймфорков, и заканчивается фразой:
В чем SObjectizer сильно отличается от перечисленных выше проектов, так это симбиозом моделей Акторов, Publish-Subscribe и Comminicating Sequential Processes.

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

p.s.
Всё же написание статьи требует на порядок больше времени и сил, чем комментарий.
> Текст претендует на некоторое сравнение существующих фреймфорков

Вам показалось, не претендует.

> Но при этом не содержит упоминания о реализуемых моделях в других реализациях.

Про механизм групп в CAF у меня вообще не было представления, мне казалось, они там вообще для каких-то других целей использовались. Может быть это какое-то свежее добавление в 0.15.

CAF-ом никогда не пользовался, приходилось на него смотреть изредка, когда вот с подобными комментариями сталкивался. Что знал, рассказал. У кого есть опыт, пожалуйста, делитесь. Наверняка получится интереснее и подробнее, чем у меня.
То есть теперь Акторы заботятся о многопоточном доступе к очереди сообщений.
Если одновременно два потока пишут и принимающий поток читает, то всё равно приходится разграничивать доступ к очереди.
Не акторы, а акторный фреймворк. Как раз это один из факторов, благодаря которому разработка многопоточного софта с использованием акторных фреймворков оказывается проще, чем на «голых» нитях/мутексах. Программист берет готовый, отлаженный и опробированный в разных проектах инструмент и получает работающие mpsc/mpmc очереди «из коробки». Ему не нужно очереди программировать вручную, отлаживать их и т.д.

Причем этот бонус разработчик получает не только в случае использования акторных фреймворков, но и в случае использования фреймворков с реализации других подходов к решению проблем concurrent computing: будь то реализация модели Pub/Sub или CSP. Но акторные фреймворки, особенно те, в которых актор — это не поток ОС, а объект или короутина, дают еще одно преимущество: они берут на себя задачу диспетчеризации событий для акторов. Тем самым снимая с разработчика еще и заботы об организации рабочих потоков, распределение задач по ним и т.д.
Есть один существенный нюанс. При «небольшом» потоке сообщений и «быстрой» обработке, крайне невыгодно помещать генераторы и обработчики в свои индивидуальные потоки: расходы на переключение контекстов будут огромными. Акторный фреймворк может как взять на себя решение задачи по распределению задач по потокам, так и позволить разработчику быстро переконфигурировать приложение, указывая рспределение акторов по потокам.

В caf существует 3 типа акторов: event_based_actor, blocking_actor и scoped_actor.
  • event_based_actor только лишь обрабатывает сообщения (в том числе, может слать сообщения сам себе ). Для такого типа акторов caf учитывает «родство» и по умолчанию помещает потомка в поток родителя. При создании актора можно задать опцию «detached», что заставит caf поместить его в свой отдельный поток
  • blocking_actor живёт в своём собственном потоке и пользователь сам решает когда он должен принимать сообщения, а когда — спать
  • scoped_actor нужен для взаимодействия с системой акторов «извне».


Ну и да, каждый актор имеет свои собственные очереди сообщений и ожиданий ответов.
Я вам больше скажу :)
Ключевым фактором является «тяжесть» обработки сообщения. Чем короче время обработки, тем меньше выгод в разнесении обработчиков по разным потокам. Даже при высокой интенсивности потока сообщений.

При очень высокой интенсивности и совсем дешевой обработке, вообще актуальность использования Модели Акторов под вопросом. Тут может лучше работать подход на основе Disruptor-а.

Что касается управления контекстами, то сейчас в SObjectizer восемь типов готовых диспетчеров и разработчик может распределять своих акторов между ними как ему захочется, в том числе выбирая конфигурацию прямо в run-time. Чему способствует так же и то, что в SObjectizer всего один вид агентов, а не зоопарк, как в CAF :)

Ну и на счет зоопарка в CAF. Документация говорит, что там есть где развернуться:
CAF provides several actor implementations, each covering a particular use case. The available implementations differ in three characteristics: (1) dynamically or statically typed, (2) class-based or function-based, and (3) using asynchronous event handlers or blocking receives.

И, скажем, Pub/Sub на базе CAF-овских групп доступен для dynamically typed акторов, но не для statically typed.

Вероятно, кому-то доставляет удовольствие со всем этим разбираться :)
При очень высокой интенсивности и совсем дешевой обработке, вообще актуальность использования Модели Акторов под вопросом. Тут может лучше работать подход на основе Disruptor-а.

слишком мутное описание, чтобы из него можно было что-то почерпнуть об алгоритме.


Ну и на счет зоопарка в CAF. Документация говорит, что там есть где развернуться:
CAF provides several actor implementations, each covering a particular use case. The available implementations differ in three characteristics: (1) dynamically or statically typed, (2) class-based or function-based, and (3) using asynchronous event handlers or blocking receives.


  1. Есть ли в SObjectizer статическая типизация агентов? Как это сделано у Вас?
  2. Подразумевается, что актор может быть как функцией, так и классом. К чему требовать классы там, где достаточно лябды?
  3. "зоопарк" типов акторов вроде как объективен:
    • не всегда возможно запихнуть всё приложение в модель акторов (gui, например), поэтому необходим тип акторов, который живёт "вовне" (scoped_actor) и управляется внешним event-loop
    • Для работы внутри системы акторов также вохможны 2 ситуации:
      — работа, основанная на сообщениях от других акторов (event_based_actor)
      — работа, требующая ручного управления событиями внутри актора (сокеты, железо, бд и тп) (blocking_actor)

Как решаеются эти задачи в SObjectizer?


Вероятно, кому-то доставляет удовольствие со всем этим разбираться :)

В SObjectizer настолько прост, что в нём ненужно разбираться?

слишком мутное описание, чтобы из него можно было что-то почерпнуть об алгоритме.

Так описания алгоритма и не было. Речь о том, что когда идет интенсивный поток заявок, а обработка каждой заявки занимает очень небольшое время, то на практике очень хорошо зарекомендовал себя подход Disruptor.
Есть ли в SObjectizer статическая типизация агентов? Как это сделано у Вас?

Не понятно, что подразумевается под статической типизацией. Посмотрите пример из статьи. Метод fixed_stack::on_push будет вызван только для сообщения push, ни для какого другого сообщения его использовать не получится. Возможно это как раз посредством статической типизации.

Вероятно, вы под статической типизацией понимаете что-то другое. Например, невозможность отправить агенту сообщение типа A, если агент в нем не заинтересован. Если так, то этого в SObjectizer нет. Поскольку на практике с такими задачами не встречались. Где это может потребоваться?

Подразумевается, что актор может быть как функцией, так и классом. К чему требовать классы там, где достаточно лябды?

Прекрасно, нет проблем. Можно так:
class onliner_demo final : public so_5::agent_t {
public :
  onliner_demo(context_t ctx) : so_5::agent_t(std::move(ctx)) {
    so_subscribe_self()
      .event( &onliner_demo::event_A )
      .event( &onliner_demo::event_B );
  }
private :
  void event_A(const A &) {...}
  void event_B(const B &) {...}
};

Можно так:
auto coop = env.create_coop("demo");
auto onliner_demo = coop.define_agent();
onliner_demo.event( onliner_demo, [](const A &) {...});
onliner_demo.event( onliner_demo, [](const A &) {...});

Причем для самого SO-5 разницы между этими агентами никакой нет, поскольку во втором случае неявным образом конструируется обычный наследник agent_t.

Соответственно, вне зависимости от вида оформления агента ему доступны все, что доступно агенту (подписки, привязка к диспетчерам и т.д.).
не всегда возможно запихнуть всё приложение в модель акторов (gui, например), поэтому необходим тип акторов, который живёт «вовне» (scoped_actor) и управляется внешним event-loop

Тут непонятно зачем такие сущности обзывать акторами и делать для них какие-то специальные варианты. Либо есть актор, который привязывается к соответствующему диспетчеру (а диспетчер можно сделать так, чтобы он работал на GUI-нити или на другой нити со своим event-loop-ом). Либо это вообще не актор, а просто внешняя сущность, которой нужно тем или иным образом с акторами взаимодействовать. Опять же, это решается без выделения особых типов акторов.
Для работы внутри системы акторов также вохможны 2 ситуации:
— работа, основанная на сообщениях от других акторов (event_based_actor)
— работа, требующая ручного управления событиями внутри актора (сокеты, железо, бд и тп) (blocking_actor)

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

В SObjectizer контекстами управляет диспетчер, к какому агента привяжут, так он и будет работать. Нужен агенту эксклюзивный контекст — он привязывается либо к active_obj-диспетчеру, либо к собственному one_thread-диспетчеру. При этом внешний вид актора и его внутреннее поведение никак не меняется.
В SObjectizer настолько прост, что в нём ненужно разбираться?

Люди говорят, что проще, чем CAF.
Не понятно, что подразумевается под статической типизацией. Посмотрите пример из статьи. Метод fixed_stack::on_push будет вызван только для сообщения push, ни для какого другого сообщения его использовать не получится. Возможно это как раз посредством статической типизации.
Вероятно, вы под статической типизацией понимаете что-то другое. Например, невозможность отправить агенту сообщение типа A, если агент в нем не заинтересован. Если так, то этого в SObjectizer нет. Поскольку на практике с такими задачами не встречались. Где это может потребоваться?

А что произойдёт с сообщением, для которого не задан обработчик?


В больших системах это как раз "обыденно", когда сообщение в следствие ошибок заруливается "не туда".
Правда, бывают ситуации, когда это делается намеренно (для маршрутизаторов), для этого в caf есть default_handler.

А что произойдёт с сообщением, для которого не задан обработчик?

Оно будет просто проигнорировано.
В больших системах это как раз «обыденно», когда сообщение в следствие ошибок заруливается «не туда».

Доставка сообщений вообще в принципе ненадежна. Так что заруливание «не туда» или потеря по какой-то другой причине — особой разницы нет.
Правда, бывают ситуации, когда это делается намеренно (для маршрутизаторов), для этого в caf есть default_handler.

Не понятно, зачем это нужно. Но, раз сделали, значит нужно зачем-то.
Доставка сообщений вообще в принципе ненадежна. Так что заруливание «не туда» или потеря по какой-то другой причине — особой разницы нет.

С таким же успехом можно сказать "вызов функций в принципе ненадёжен"…
Надёжность определяется средой передачи и протоколом.


Не понятно, зачем это нужно. Но, раз сделали, значит нужно зачем-то.

Нужно это примерно для того же, для чего разработчики protobuf создали тип Any.

С таким же успехом можно сказать «вызов функций в принципе ненадёжен»…

Между синхронным вызовом и асинхронной отсылкой сообщения есть принципиальная разница. В случае вызова для вызывающего кода нет ничего между вызовом и получением результата (даже если результат — это исключение о невозможности выполнить вызов).

В случае отсылки сообщения отправитель продолжает нормально работать пока сообщение дойдет до получателя. Дойдет или нет — никто никаких гарантий не дает. Есть ряд причин, по которым доставка и обработка отосланного сообщения может не состоятся.
Надёжность определяется средой передачи и протоколом.

Странная фраза. Могли вы пояснить, какое отношение она имеет к обмену сообщениями между акторами внутри одного процесса (хотя бы одного процесса для простоты)?
Нужно это примерно для того же, для чего разработчики protobuf создали тип Any.

Для чего нужно нечто, что можно охарактеризовать как opaque payload, в транспортных протоколах — понятно. Зачем акторам иметь возможность получить сообщение, типа которого они не знают — нет. Можно прикладной пример?

Если не затруднит, можно в двух словах в чём преимущества акторов перед "чистой" моделью передачи сообщений, той же MPI?

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

На мой взгляд, Модель Акторов — это следующий логический шаг в степени использования message-passing. Т.е. сперва вы решаете, что вам нужны независимые потоки управления, у каждого из которых свои собственные данные. И для общения между потоками вам нужен обмен сообщениями.

Затем вы понимаете, что у ваших потоков появляется какое-то сложное поведение, которое зависит от того, какие сообщения поток получает. Потом вы обнаруживаете, что можно как бы разделить логические потоки и физические. И что логических потоков вам нужно больше, чем физических. Вам теперь нужно отобразить N логических потоков на M физических.

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

Ну и еще замечу, что MPI предназначен для решения проблем parallel computing, тогда как акторы — для concurrent computing. Специфика немного разная.
Only those users with full accounts are able to leave comments. Log in, please.