LINUX.ORG.RU

Обновился инструмент для работы с агентами/акторами в C++: SObjectizer 5.4.0

 , , ,


0

1

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

Последние несколько лет SObjectizer развивается на SourceForge как OpenSource проект под BSD-лицензией. Подробнее об истории, текущем состоянии и направлении движения SObjectizer можно прочитать здесь.

Версия 5.4.0 содержит несколько изменений и улучшений, среди которых можно выделить следующие:

  • новый тип mbox-а: multi-producer/single-consumer (MPSC). Позволяет организовать эффективное peer-to-peer взаимодействие агентов (ранее такое взаимодействие было частным случаем использования модели publish/subscribe). Накладные расходы на общение двух агентов через MPSC заметно ниже, чем при работе через старые multi-producer/multi-consumer mbox-ы;
  • для обработчиков событий можно указывать признак thread safety. По умолчанию все обработчики событий рассматриваются как not_thread_safe и для одного агента обработчики его событий запускаются строго последовательно. Если же событие помечено как thread_safe, но новый диспетчер adv_thread_pool может параллельно запустить несколько thread_safe-обработчиков для одного агента на разных нитях;
  • новый диспетчер thread_pool, который использует пул рабочих потоков и распределяет обработчики событий между этими потоками (здесь чуть подробнее о принципах работы этого диспетчера);
  • новый диспетчер adv_thread_pool, который так же использует пул рабочих потоков и распределяет обработчики событий с учетом флага thread safety (здесь чуть подробнее об этой возможности);
  • режим autoshutdown — SObjectizer Environment завершает свою работу после дерегистрации последней кооперации;
  • теперь диспетчеров можно добавлять и после запуска SObjectizer Environment (ранее это нужно было делать только до старта Environment-а);
  • серьезная реорганизация внутренней кухни, увеличение производительности и улучшение масштабируемости.

Более подобно список изменений в версии 5.4.0 на русском языке описывается здесь.

Версия распространяется в виде сборки so-201408-00, в которую кроме SObjectzer 5.4.0 входит еще несколько SObjectizer-библиотек, предназначенных для разработки больших, распределенных приложений на основе SObjectizer, а именно:

  • so_log, служащая оберткой над ACE Logging и упрощающая логирование для агентов;
  • so_sysconf, позволяющая собирать большое приложение из маленьких кусочков, оформленных в виде dll/so-библиотек;
  • so_5_transport, оформляющая работу с TCP/IP соединениями в виде транспортных SObjectizer-агентов;
  • mbapi, являющаяся высокоуровневой библиотекой для обмена сообщениями между агентами или между компонентами распределенного приложения.

Релизная сборка может быть загружена с SourceForge в виде архива или же взята из svn-репозитория.

Wiki-раздел SObjectizer-а на SourceForge содержит более подробную информацию как об особенностях версии 5.4.0, так и о самом SObjectizer и его основах.

★★★★★

Последнее исправление: beastie (всего исправлений: 1)

Чем это лучше Erlang'a? Как обстоят дела с отказоустойчивостью? Есть ли результаты стресс-тестов которые показывают что «SObjectizer использовался для создания <...> серьезных распределенных приложений, работающих под большой нагрузкой в режиме 24x7»?

NegatiV
()
Последнее исправление: NegatiV (всего исправлений: 1)
Ответ на: комментарий от NegatiV

Чем это лучше Erlang'a?

Я так понимаю, что после 2003-2004 годов, все, кого устраивает Erlang, просто используют Erlang. Если же вместо Erlang-а нужно оставаться в рамках другого языка/платформы, то начинают придумывать другие реализации, вроде Akka, Jetlang, CAF, Theron и пр. Можно ли вести разговор о том, чем Akka лучше Erlang?

Собственно, SObjectizer — это инструмент для C++. Если есть необходимость задействовать акторы в C++ программе, то вы же не будете тянуть туда Erlang.

Ну и кроме того, основные идеи SObjectizer-а сформировались еще до явления Erlang-а широкой общественности. Так что он не лучше, он просто другой. Но с какими-то общими чертами в виде обмена сообщениями между сущностями.

Как обстоят дела с отказоустойчивостью?

Что именно вы подразумеваете под отказоустойчивостью?

Есть ли результаты стресс-тестов которые показывают что «SObjectizer использовался для создания <...> серьезных распределенных приложений, работающих под большой нагрузкой в режиме 24x7»?

В компании, где я раньше работал, он именно для таких приложений и использовался. И используется сейчас. Но это не OpenSource приложения.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Под отказоустойчивостью понимаю то же что и все - способность системы пережить отказ в одном или нескольких ее компонентах. Есть ли супервизоры, перезапускающие отказавшие компоненты по какой-либо политике (просто перезапустить компонент, перезапустить группу компонентов, перезапустить зависимости компонента и т.д.)? Про крэши я молчу, они просто положат программу целиком. Жаль что стресс-тестов нет, было бы интересно взглянуть. И еще, что-то не увидел в примерах есть ли возможность извлекать из mailbox'a сообщения с приоритетом. А так весьма занятно, надо будет глянуть поближе.

NegatiV
()
Ответ на: комментарий от NegatiV

В SObjectizer есть возможность назначить реакцию на вылетевшее из обработчика события исключение: его можно проигнорировать; можно дерегистрировать кооперацию, в которую входил агент; можно инициировать нормальный shutdown для SObjectizer; можно сразу прибить приложение через std::abort() чтобы его рестартовали.

Готовых supervisor-ов, как в Erlang-е нет. Есть нотификации, которые могут рассылаться при дерегистрации коопераций, на их основе можно делать аналоги supervisor-ов (что-то подобное показано в примере, вот его более подробное объяснение)

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

Жаль что стресс-тестов нет, было бы интересно взглянуть.

В архиве с бинарниками для Windows есть примеры sample/mbapi_4/ping и sample/mbapi_4/stages, в которых находятся bat и rb-файлы для запуска примера в различных конфигурациях. Там можно запустить с десяток связанных друг с другом процессов, которые будут обмениваться сообщениями.

Это не столько стресс-тест, но демонстрация того, что распределенное приложение может состоять из большого количества компонентов.

Микробенчмарки есть, они меряют разные аспекты производительности.

И еще, что-то не увидел в примерах есть ли возможность извлекать из mailbox'a сообщения с приоритетом.

Нет, приоритеты для событий в SO-5 не поддерживаются. Была такая фича в SO-4, но за 12 лет использования SO-4 она была востребована буквально два или три раза, и то это было не бесспорно. Так что отказались, т.к. на производительности это сказывается очень сильно.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от nanoolinux

Увидел.) Несколько неудобочитаемо и загромождено, но тут дело скорее привычки (в крайнем случае можно typedef'ами все переименовать =) ), крайнее недовольство вызывает только указание версии либы в имени неймспейса.

NegatiV
()
Ответ на: комментарий от NegatiV

Да ну нафих. Тайпдефами пользуеться только микрософт и эди)

nanoolinux ★★★★
()
Ответ на: комментарий от nanoolinux

Ты ещё примеры кода не видел)

Да-да, Perl отдыхает.

Только вот сложные вещи просто и лаконично на C++ мало кому удается выражать. Буквально сегодня проскочила презентация о мэппинге CORBA IDL в C++11. Там что-то тоже, как только о чем-то более сложном речь заходит, так уровень синтаксического оверхеда существенно вырастает.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от NegatiV

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

Если кто-то привык пользоваться using namespace, то это вообще ни разу не проблема.

Просто дело вкуса и привычки.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Правильно. Потоки для акторов и 24/7 не совместимы в принципе. Что бы было 24/7 нужно юзать юникс процессы. Собственно так и было лет 20-30 назад, но были проблемы с производительностью передачи данных от одного процесса к другому. Сис5айписи работает, но медленно. Очевидно его сделали для того, что бы разработчики не изобретали лисапеды. Но проблемы с производительностью остались. Что бы их победить придумали питредс, которые сейчас пихают куда ни попадя и даже не думают о стабильности. В итоге современные поделия на спп - сами знаете что.

В эрланге решаются обе проблемы. Процессы изолированы, а передача данных эфективна.

nanoolinux ★★★★
()
Ответ на: комментарий от nanoolinux

Потоки для акторов и 24/7 не совместимы в принципе.

Ну да, конечно.

Что бы было 24/7 нужно юзать юникс процессы.

Чтобы было 24/7 нужно прежде всего думать о качестве. Процессы и рестарты помогают пережить проблемы, но не избавиться от них.

Что бы их победить придумали питредс

У меня другое мнение о том, зачем придумали нити.

В эрланге решаются обе проблемы. Процессы изолированы, а передача данных эфективна.

Аминь.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от NegatiV

Не, я в принципе не использую using namespace, пусть все в своих скоупах сидит.

Вот я тоже не сторонник using namespace, крайне редко его использую. А номер поколения проекта добавлен в верхнее пространство имен для того, чтобы иметь возможность в больших проектах задействовать несколько версий проекта. Так у нас было, например, с cls_2/cls_3, oess_1/oess_2, so_4/so_5, mbapi_3/mbapi_4. И, полагаю, еще будет неоднократно.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от nerdogeek

Чем SObjectizer лучше C++ Actor Framework ?

Имхо, авторы CAF (бывший libcppa) решили за счет возможностей C++11 сделать в C++ очень похожий клон Erlang-а. При этом упор делается на parallel computing. Тогда как SObjectizer всегда ориентировался именно на concurent computing. Отсюда в SObjectizer такие вещи, как диспетчеры.

Более подробно на тему соотношения SObjectizer и CAF:

http://eao197.blogspot.com/2014/07/progthoughts-libcppa.html http://eao197.blogspot.com/2014/07/progc-sobjectizer-libcppa.html http://eao197.blogspot.com/2014/07/progc-libcppa.html

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

Чтобы было 24/7 нужно прежде всего думать о качестве

Так возьми и подумай. У тебя автомат из двух компонент. И теперь у тебя есть два варианта: фейл в одном компоненте приводит к фейлу в другом; фейл в одном не приводит к фейлу в другом. Внимание вопрос: посчитай надёжность всего автомата если надёжность компонента - Н.

У меня другое мнение о том, зачем придумали нити.

Поделись догадками!

nanoolinux ★★★★
()
Последнее исправление: nanoolinux (всего исправлений: 1)
Ответ на: комментарий от nanoolinux

Внимание вопрос: посчитай надёжность всего автомата если надёжность компонента - Н.

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

А потом пусть напишет какой-нибудь научно-популярный пост и опубликует где-нибудь, где это будет более интересно, чем здесь.

Поделись догадками!

Это оффтопик.

eao197 ★★★★★
() автор топика
Ответ на: комментарий от eao197

где это будет более интересно, чем здесь.

Это всё уже давно написано в книжках по теории автоматов, да.

Это оффтопик.

Ну и что?

nanoolinux ★★★★
()
Ответ на: комментарий от niXman

Признайся, ты просто не понял, о чём там написано.

nanoolinux ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.