Рубрика «actor model» - 2

Когда-то в SObjectizer-4 «из коробки» была доступна возможность построения распределенных приложений. Но не всегда это работало так хорошо, как хотелось бы. В итоге в SObjectizer-5 от поддержки распределенности в самом ядре SObjectizer-а мы отказались (подробнее этот вопрос рассматривается здесь). Отказались в пользу того, чтобы под конкретную задачу можно было выбрать конкретный транспорт с учетом особенностей этой самой задачи. Написав для этого соответствующую обвязку, которая будет скрывать от программиста детали работы выбранного транспорта.

В данной статье мы попробуем рассказать об одной такой обвязке вокруг MQTT и libmosquttio, посредством которой была реализована возможность взаимодействия частей распределенного приложения.
Читать полностью »

Продолжаем знакомить читателей с открытым C++ным фреймворков под названием SObjectizer. Наш фреймворк упрощает разработку сложных многопоточных приложений за счет того, что C++программисту становятся доступны более высокоуровневые инструменты, позаимствованные из Модели Акторов, CSP и Publish-Subscribe. При этом, как бы высокопарно это не звучало, SObjectizer является одним из немногих открытых, живых и развивающихся акторных фреймворков для C++.

Мы уже посвятили SObjectizer-у более десятка статей на Хабре. Но все равно читатели жалуются на наличие «белых пятен» в понимании того, как SObjectizer работает и как взаимосвязаны между собой различные типы сущностей, которыми оперирует SObjectizer.

В этой статье мы попробуем заглянуть под капот SObjectizer-у и постараемся «на пальцах» и в картинках объяснить из чего он состоит и как, в общих чертах, он работает.
Читать полностью »

оригинал

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

Основная проблема кроется в пограничных условиях. Программисты делают все возможное для написания и тестирования “happy path”, но человеческий фактор мешает нам видеть проблему со всех сторон и особенно края и углы, которые причиняют наибольшие проблемы пока программа используется.

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

Читать полностью »

О чем эта статья?

Одной из основных отличительных черт C++ного фреймворка SObjectizer является наличие диспетчеров. Диспетчеры определяют где и как акторы (агенты в терминологии SObjectizer-а) будут обрабатывать свои события: на отдельной нити, на пуле рабочих нитей, на одной общей для группы акторов нити и т.д.

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

В общем, если кому-то интересно прикоснуться к деталям реализации одного из немногих живых и развивающихся акторных фреймворков для C++, то можно смело читать дальше.

Преамбула

Недавно один из пользователей SObjectizer-а рассказал про специфическую проблему, с которой ему довелось столкнуться в процессе использования SObjectizer-а. Смысл в том, что на базе SObjectizer-овских агентов разрабатывается приложение для управления подключенными к компьютеру устройствами. Часть операций (а именно операция инициализации и переинициализации устройства) выполняется синхронно, что приводит к блокировке рабочей нити на некоторое время. Операции же ввода-вывода осуществляются асинхронно, поэтому иницирование чтения/записи и обработка результата чтения-записи выполняются значительно быстрее и не блокируют рабочую нить надолго.
Читать полностью »

Модель акторов — это хороший подход к решению некоторых типов задач. Готовый акторный фреймворк, особенно в случае языка C++, может очень сильно облегчить жизнь разработчика. С программиста снимается изрядная часть забот по управлению рабочими контекстами, организации очередей сообщений, контролю за временем жизни сообщений и т.д. Но, как говорится, все хорошее в этой жизни либо противозаконно, либо аморально, либо ведет к ожирению ничего не дается бесплатно. Одна из проблем использования готового (т.е. чужого) акторного фреймворка состоит в том, что иногда он превращается в «черный ящик». Ты видишь, что ты отдаешь в этот «черный ящик», ты видишь, что из него приходит (если вообще приходит). Но далеко не всегда понятно, как из первого получается второе…
Читать полностью »

Когда летом 2016-го года создавалась первая статья про SObjectizer мы говорили, что со временем будем рассказывать и о деталях его реализации, дабы заинтересованные читатели могли заглянуть «под капот». Сегодняшняя статья будет как раз про потроха SObjectizer-а. Про механизм mbox-ов («почтовых ящиков»), который используется для организации взаимодействия акторов (агентов в нашей терминологии).

Почему речь именно про mbox-ы?

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

Зачем нужны mbox-ы?

Почтовые ящики в SObjectizer нужны для того, чтобы организовывать взаимодействие между агентами. Общение между агентами строится посредством асинхронных сообщений и эти самые сообщения нужно куда-то отсылать. Возникает вопрос: «Куда именно?»
Читать полностью »

Эта статья является адаптированным вариантом текста одноименного доклада с конференции C++ CoreHard Autumn 2017. Статья рассматривается как завершение темы, поднятой ранее в публикациях "Модель Акторов и C++: что, зачем и как?" и «Шишки, набитые за 15 лет использования акторов в C++» часть I и часть II. Сегодня речь пойдет о том, как понять, что Модель Акторов может быть успешно использована в вашем проекте.

В принципе, статья является «капитанской», т.к. описываемые в ней вещи вполне очевидны и диктуются обычным здравым смыслом. Но, к сожалению, не часто внимание акцентируется именно на них.

Лирическое отступление на тему «Модель Акторов и C++: миф или реальность?»

В статье обсуждаются вещи, которые присущи самой Модели Акторов, безотносительно конкретных языков программирования. Но, т.к. автор тесно связан с разработкой ПО на C++, то есть некоторый акцент на применимость акторов именно в C++.

Читать полностью »

Корни SObjectizer берут свое начало в теме автоматизированных систем управления технологическими процессами (АСУТП). Но использовали мы SObjectizer в далеких от АСУТП областях. Поэтому иногда возникает ностальгия из категории «эх, давно не брал в руки шашек...» Однажды из-за этого в составе SObjectizer появился один из самых объемных примеров — machine_control. Уж очень тогда захотелось «тряхнуть стариной», смоделировать задачку управления оборудованием на современном SObjectizer-е. Ну и под шумок запихнуть в пример разные вкусные фичи SObjectizer-а вроде фильтров доставки, шаблонных агентов и диспетчера с поддержкой приоритетов. Сегодня попробуем рассказать и показать, как это все работает.

The Engine Room - Steel Stacks, Bethlehem, PA
Photo by Mike Boening

Читать полностью »

Когда мы начали рассказывать про свой OpenSource акторный фреймворк для C++ на Хабре, мы пообещали описывать некоторые особенности деталей реализации SObjectizer-а. Одна из новых фич, которая была реализована в недавно вышедшей версии 5.5.19, отлично подходит для такого рассказа. Кроме того, она интересна еще и тем, что нам пришлось взглянуть на сценарии использования SObjectizer с совершенно другой стороны. Можно даже сказать, что один из наших шаблонов оказался разорванным.

Речь идет о возможности SObjectizer-а выполнять все свои действия на одной единственной рабочей нити. Начиная с версии 5.5.19 использовать Actor- и Publish/Subscribe модели можно даже в однопоточном приложении. Понятное дело, что акторы должны будут работать в режиме кооперативной многозадачности, но в каких-то случаях именно это и требуется.

А где может потребоваться использовать акторов в однопоточном приложении?

Читать полностью »

В комментариях к последней статье про шишки, которые нам довелось набить за 15 лет использования акторов в C++, вновь всплыла тема отсутствия в SObjectizer-5 распределенности «из коробки». Мы уже отвечали на эти вопросы множество раз, но очевидно, что этого недостаточно.

В SObjectizer-5 нет распределенности потому, что в SObjectizer-4 поддержка распределенности была, но по мере того, как расширялся спектр решаемых на SObjectizer задач и росли нагрузки на SObjectizer-приложения, нам пришлось выучить несколько уроков:

  • под каждый тип задачи желательно иметь свой специализированный протокол. Потому что обмен большим количеством мелких сообщений, потеря части которых не страшна, сильно отличается от обмена большими бинарными файлами;
  • реализация back-pressure для асинхронных агентов — это сама по себе непростая штука. А когда сюда еще и примешивается общение по сети, ситуация становится гораздо хуже;
  • сегодня какие-то куски распределенного приложения обязательно будут написаны на других языках программирования, а не на C++. Поэтому требуется интероперабильность и наш собственный протокол, заточенный под C++ и SObjectizer, мешает разработке распределенных приложений.

Далее в статье попробуем раскрыть тему подробнее.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js