| Author: | Евгений Охотников |
|---|---|
| Contact: | eao197 at intervale dot ru; eao197 at yahoo dot com |
| Date: | 2008.09.23 |
В последнее время наблюдается растущий рост интереса к мультипоточному программированию. Появление недорогих мультипроцессорных систем и мультиядерных процессоров привело к тому, что приложения стали работать в условиях реальной параллельности потоков. Т.е. удачное разделение работы в приложении между потоками может серьезно увеличить производительность приложения. А неудачное наоборот -- на двухядерном процессоре программа может работать даже медленнее, чем на одноядерном.
Мультиядерные процессоры подогревают интерес разработчиков к инструментам, способным упростить реализацию параллельных вычислений. Например, к таким, как OpenMP, TBB, ParallelExtensions. Но эти инструменты нацелены именно на параллельные вычисления. Они не очень подходят для целого класса задач, в частности для многопоточного событийно-ориентированного программирования. В подобных случаях разработчикам остается самим вручную управлять нитями, очередями сообщений и синхронизацией. Однако, ручное управление потоками и их синхронизации в условиях десятков, а то и сотен потоков в приложении, весьма трудоемко и черевато ошибками и длительной отладкой.
Существует мнение, что обмен сообщениями между отдельными сущностями приложения является более надежным способом реализации параллельных активностей в приложении. На практике это отлично доказывает такой язык программирования, как Erlang. В нем есть параллельные, изолированные друг от друга процессы, взаимодействие между которыми обеспечивается только за счет обмена сообщениями. Эта модель способствует не только упрощению разработки систем с большим количеством параллельных активностей, но и повышает надежность приложений (хотя ведущую роль в обеспечении надежности играет изолированность процессов). Опыт использования Erlang в ряде телекоммуникационных проектов компании Ericsson оказался настолько убедительным, что механизм обмена сообщениями Erlang теперь копируется в других языках (например, Scala Actors).
Т.е. с пришествием доступных мультипроцессорных/мультиядерных систем разработчикам требуются инструменты, которые бы брали на себя задачи управления потоками и обеспечивали взаимодействие между отдельными потоками посредством сообщений. Как раз таким инструментом является SObjectizer:
Но SObjectizer отвечает не только за обмен сообщениями и за управление потоками. SObjectizer оказался уникальным инструментом, чем-то средним между системами доставки сообщений (вроде TIBCO Rendezvous) и фреймворками для событийно-ориентированного программирования (вроде SEDA). Т.е. SObjectizer может предложить разработчику больше, что просто управление множеством потоков. И, что важно, SObjectizer уже доказал свою состоятельность в ряде проектов.
Вот примеры предметных областей и систем, в которых SObjectizer был или мог быть успешно использован:
Подобное разнообразие возможных применений SObjectizer в сочетании с увеличивающимся интересом к мультипоточному программированию свидетельствует о том, что SObjectizer сохраняет свою актуальность. Поэтому имеет смысл продолжить его развитие и совершенствование.
Дизайн SObjectizer 4 был разработан в первой половине 2002-го года. За прошедшее время SObjectizer 4 претерпел множество переделок, дополнений и улучшений. Но основные элементы дизайна, заложенные в самом начале, практически не подвергались пересмотру.
За это время SObjectizer 4 зарекомендовал себя как достаточно простой в освоении и надежный инструмент, на основе которого реализованы несколько важных проектов в компании Интервэйл. Часть этих проектов находится в эксплуатации, работает под большой нагрузкой, постоянно модифицируется и развивается.
Опыт использования SObjectizer 4 выявил в нем ряд недостатков, в том числе и вытекающих из первоначального дизайна. Часть из них невозможно устранить без кардинального перепроектирования SObjectizer, что вряд ли возможно в рамках SObjectizer 4 из-за груза уже созданных на SObjectizer 4 систем. Но, если над SObjectizer 5 не будет висеть домоклов меч совместимости с SObjectizer 4, то это позволит:
Создание SObjectizer 5 может идти по одному из следующих сценариев:
Пока сложно сказать, каким будет SObjectizer 5, но уже понятно, что:
Для того, чтобы со временем более четко обозначить контуры будущего SObjectizer 5, можно начать с попытки найти ответы на следующие вопросы:
Что не так в SObjectizer 4 и как это исправить в SObjectizer 5?
Этот вопрос вскрывает проблемы SObjectizer 4 и показывает, чего нельзя делать в SObjectizer 5. Ответ на этот вопрос должен подсказать как сделать SObjectizer 5 простым и эффективным инструментом разработки агентных приложений.
Как построить процесс разработки SObjectizer 5?
SObjectizer 4 изначально создавался как внутренний продукт компании Интервэйл. На момент своей публикации в виде OpenSource проекта он представлял из себя цельный продукт, неизвестный широкому кругу разработчиков. В случае SObjectizer 5 можно попробовать сделать процесс его разработки публичным, что может привлечь к SObjectizer более пристальное внимание и вовлечь в разработку тех программистов, которым больше нравится создавать подобные инструменты, нежели использовать чужие готовые разработки.
Ниже перечисленны основные моменты, которые сейчас выглядят недостатками SObjectizer 4. Они упорядоченны по степени уменьшения критичности, т.е. вначале обсуждаются наиболее серьезные проблемы, затем менее серьезные. Это так же означает, что при разработке SObjectizer 5 основной упор будет сделан на устранение самых больших просчетов.
При разработке SObjectizer 4 было принято решение о том, что:
Одной из причин принятия такого решения было желание повысить надежность SObjectizer-приложений. Поскольку в C++, в отличии от ряда других языков, работа с исключениями менее удобна и предсказуема:
в C++ нет возможности указать, что метод выпускает наружу исключение или что он никогда этого не делает. При этом в C++ нет единого подхода к информированию о возникающих ошибках: часть библиотек порождает исключения, часть возвращает коды ошибок, часть устанавливает errno. Поэтому не всегда легко определить, можно ли ожидать от кода возникновения исключения или нет;
в C++ проблематично оборачивать одно исключение в другое. Например, если какой-то код перехватывает исключения и хочет инкапсулировать их в собственное исключение:
void f()
{
try
{
... какой-то код ...
}
catch( const std::exception & x )
{
// По сути, здесь перехватываются все "легальные" исключения.
// Далее хотелось бы выбросить собственное исключение,
// но это не так просто.
// Нельзя в my_exception сохранить ссылку x, т.к. она вскоре
// станет некорректной.
throw my_exception( x );
}
}
в C++ нет стек-трейса, связанного с исключением. Поэтому сам факт перехвата исключения часто оказывается бесполезным, т.к. без стек-трейса невозможно определить, где данное исключение возникло.
Вместо повышения надежности SObjectizer-приложений и упрощения их разработки в результате использования кодов возврата были получены несколько иные эффекты:
Невозможность выпуска исключений из обработчиков событий является наиболее серьезной проблемой SObjectizer 4. Как показала практика, агенты рано или поздно встречаются с непредусмотренными исключениями, которые они не в состоянии обработать. Такие исключения, как правило, оставляют агента в неопределенном состоянии, в котором невозможно продолжать корректную работу. Поэтому во многих случаях необходим рестарт агента. И было бы здорово, чтобы этот рестарт осуществлял сам SObjectizer, информируя при этом остальные части приложения о произведенном рестарте (по аналогии с механизмом процессов-супервизоров в Erlang).
Итак, на основании опыта SObjectizer 4 преставляется выгодным следующее решение для SObjectizer 5:
Некоторые соображения о том, как SObjectizer может обрабатывать выпущенные из обработчиков событий исключения, описаны в RFC Поддержка исключений в SObjectizer.
По сегодняшним меркам код SObjectizer-агентов не просто многословен, а очень многословен. Ведь для того, чтобы агент заработал в составе SObjectizer необходимо:
Ситуация усугубляется еще и тем, что средства разработки для C++ (например, такие как MS Visual Studio, Code::Blocks или KDevelop) ничего не знают про специфику SObjectizer и не могут помочь разработчику в написании этого кода.
Возможно, самая большая проблема с многословностью в SObjectizer 4 связана не столько с объемом необходимого вспомогательного кода, сколько с тем, насколько этот объем пугает новичков. В самом деле, в реальных проектах код агента занимает в несколько раз больше, чем описания этого агента для SObjectizer. Но вот разница между объемами прикладного и описательного кода в простых демонстрационных примерах/тестах вызывает скептические усмешки у новичков при первом взгляде на SObjectizer. Что, вероятно, временами отталкивает людей от дальнейшего знакомства с SObjectizer.
Итак, одной из задач SObjectizer 5 является серьезное сокращение объема описаний, необходимых для SObjectizer агентов.
За счет чего будет сделано это сокращение -- открытый вопрос. Одним из путей является использование внешнего языка описаний и кодогенерации. Некоторы соображения по этому поводу сделаны в RFC Нужен ли SObjectizer-у DSL? и Жесткая проверка доступности событий в состояниях агентов.
В SObjectizer 4 для идентификации агентов, сообщений, событий и состояний используются строковые имена. Например, отсылка сообщения агенту выглядит как:
so_4::api::send_msg(
"some_agent",
"some_msg" );
А подписка события агента как:
so_subscribe( "some_agent", "evt_some_event", "msg_some_message" );
Использование строковых идентификаторов ведет к следующим проблемам:
С другой стороны, строковые имена оказались достаточно удобным и гибким способом работы с различными сущностями в SObjectizer. В частности, благодоря строковым именам работает утилита so_send_stdin, позволяющая отправлять в SObjectizer-приложение сообщения и запросы.
Поэтому в SObjectizer 5 необходимо объединить гибкость строковых имен со скоростью целочисленных идентификаторов, а так же со статическим контролем со стороны компилятора. Один из возможных способов достижения этого состоит в использовании внешнего языка описания агентов, из которого специальным транслятором генерируется набор вспомогательных классов и методов. Что может сделать возможным программирование на SObjectizer в следующем стиле:
void a_meeting_place_t::so_on_subscription()
{
// Подписка событий на сообщения.
so_events().evt_first_in().subscribe(
so_messages().msg_creature_in() );
so_events().evt_second_in().subscribe(
so_messages().msg_creature_in() );
}
void a_meeting_place_t::evt_first_in( const msg_creature_in & cmd )
{
...
// Переход в состояние.
so_states().st_first_in().switch_to();
}
void a_meeting_place_t::evt_second_in( const msg_creature_in & cmd )
{
...
// Отсылка сообщения.
auto_ptr< msg_meet_completed > msg1 =
so_messages().msg_meet_complete().make();
msg1->... // Инициализация.
msg1->send();
...
// Переход в состояние.
so_states().st_empty().switch_to();
}
Подобные вспомогательные классы/методы будут скрывать от программиста идентификаторы используемых сущностей. А так же позволят преобразовывать строковые имена в идентификаторы:
auto_ptr< some_msg > msg1 = so_5::api::lockup_message(
"some_agent::some_msg" ).make();
...
msg1->send( so_5::api::lockup_agent( "some_agent" ) );
Одной из особенностей агентных систем, разработанных с помощью SObjectizer, является эпизодическая непредсказуемость поведения всего приложения. Т.е. легко отследить логику работы каждого отдельного агента, но общее поведение множества агентов в приложении может быть очень неожиданным для разработчика. В агентных приложениях наблюдаются такие же явления, как и в реальной жизни. Например, в птичьей стае каждая особь следует нескольким простым правилам. Тем не менее, предугадать точную форму или направление движения всей стаи в конкретных условиях может быть невозможно.
Негативным проявлением подобной непредсказуемости агентного приложения является ситуация, при которой агенты начинают генерировать друг другу больше сообщений, чем они в состоянии обработать. Обычно это связано с периодическими сообщениями, когда некоторое множество периодических сообщений начинает генерироваться одновременно и прикладные агенты не успевают их обработать до следующего срабатывания таймера и генерации новой порции этих же периодических сообщений.
Т.е. в SObjectizer возможны ситуации, когда агенты генерируют больше работы, чем успевают выполнить. Внешне это выглядит как загрузка процессора на 100% и постоянный рост объема используемой приложением памяти.
Наиболее качественно эта проблема может быть решена на прикладном уровне, когда программист реализует в своих прикладных агентах какие-либо ограничения или адаптивные алгоритмы генерации нагрузки. В этом случае не будет потерь сообщений агентов и прочих мелких сбоев, обработку которых приходится предусматривать в прикладных агентах.
Но и SObjectizer должен предоставить разработчику какие-либо механизмы, которые бы помогли приложению пережить подобные всплески нагрузки. Например:
Целью этих механизмов является обеспечение отзывчивости приложения даже в случае многократного превышения прикладными агентами допустимого порога нагрузки. Чтобы в этом случае иметь возможность вмешаться в ход работы приложения (например, посредством отсылки команд с помощью sop-файлов) и это вмешательство было воспринято приложением.
Одной из проблем, с которой сталкиваются новички в начале своей работы с SObjectizer является пропажа сообщений. Т.е. где-то сообщение отсылается, но нужное событие не срабатывает. Данная проблема может быть вызвана рядом причин:
В первых двух ситуациях SObjectizer Run-Time помещает в поток ошибок сообщения о проблеме. В послених двух SObjectizer ведет себя как черный ящик -- сообщения пропадают в нем без следа.
По мере приобретения опыта подобные ошибки возникают все реже и реже. Но в начале они становятся серьезным препятствием перед неопытным SObjectizer-программистом.
Для того, чтобы окончательно устранить проблему поиска следов пропавшего сообщения, в SObjectizer 5 должны быть средства трассировки судьбы сообщения. Эти средства должны быть достаточно гибкими, чтобы позволять отслеживать судьбу только одного из множества других сообщений. В то же время, эти средства должны иметь очень низкие накладные расходы в механизме диспетчеризации SObjectizer, чтобы скорость работы SObjectizer была максимальной. В идеале, при отсутствии трассировки не должно быть никаких накладных расходов.
К сожалению, в настоящий момент нет никаких соображений о том, как трассировка сообщений может быть реализована в SObjectizer.
В посление годы практически все серьезные проекты на SObjectizer используют библиотеку MBAPI для организации взаимодействия между компонентами (зачастую распределенными). MBAPI оказался более высокоуровневым инструментом для построения распределенных приложений на SObjectizer, чем глобальные агенты (хотя сам MBAPI работает с помощью механизма глобальных агентов). Не в последнюю очередь эта высокоуровневость обеспечивается за счет возможностей перехвата и перемаршрутизации MBAPI сообщений (чего нельзя делать с обычными сообщениями агентов).
Но при использовании MBAPI разработчик сталкивается с тем что:
Кроме того, библиотека MBAPI сама прошла достаточно длинный эволюционный путь, на протяжении которого предпринимались попытки сохранить совместимость с предшествующими версиями MBAPI. В результате чего в MBAPI существует набор устаревших базовых классов и методов, от которых хотелось бы избавиться.
Если ядро SObjectizer 5 будет включать в себя основные понятия и механизмы MBAPI, то это позволит:
Возможно, подобная интеграция MBAPI с ядром SObjectizer расширит SObjectizer новыми понятиями. Так, в SObjectizer существуют только агенты и рассылка сообщений (целенаправленная или широковещательная). Добавление mbox-ов и перехвата/перемаршутизации сообщений может ввести в SObjectizer такие понятия, как:
В данном разделе не будут рассматриваться такие вопросы, как организация проектной команды, распределение обязанностей, сроки реализации, размещения репозитория исходных текстов и пр. Это все рабочие моменты, которые должны решаться в рабочем порядке. Здесь же делается попытка обозначить аспекты, способные сделать SObjectizer более открытым и более стимулирующим желание попробовать принять участие в его развитии.
Когда компания Интервэйл опубликовала SObjectizer 4 на SourceForge это был завершенный программный продукт, со сложившимся дизайном, готовой документацией и выработавшимися методиками его использования. Любой заинтересовавшийся SObjectizer разработчик мог скачать его, посмотреть и сказать: "Я видел это".
Одной из целей выпуска SObjectizer 4 под OpenSource-лицензией было привлечение заинтересованных разработчиков к развитию SObjectizer. Свежие люди -- свежие идеи. Это как раз то, в чем нуждается SObjectizer. Идеи важны даже больше, чем помощь в их реализации.
К сожалению, нельзя сказать, что эта цель была достигнута. Возможно, свою отрицательную роль сыграла как раз зрелось и завершенность SObjectizer 4. Здесь не было большой свободы для того, чтобы заинтересовавшийся разработчик мог почувствовать, что он может приложить свои силы и свою фантазию к этому проекту. Т.е. не было интересного приглашения с совместному созданию чего-то нового, не было того, что позволило бы человеку затем сказать "Я сделал это".
Если эта проблема действительно имеет место быть, то при разработке SObjectizer 5 нужно попытаться избавиться от нее.
SObjectizer 4 используется для реализации внутренних проектов компании Интервэйл, которые вряд ли когда-нибудь будут представлены широкой публике. Это делает невозможным наглядную демонстрацию работы SObjectizer в более-менее серьезных разработках. Пользователю остается судить о SObjectizer по небольшим примерам и тестам в составе дистрибутива SObjectizer. Что далеко не всегда может составить у потенциального пользователя благоприятное и объективное впечатление о SObjectizer.
Поэтому представляется интересным использовать SObjectizer 5 в каком-нибудь не очень большом и сложном, но более-менее полезном OpenSource-проекте. Польза подобного проекта выражается в том, что это будет работающий проект, который можно будет сравнить с аналогичными разработками на других языках. Такое сравнение будет полезно не только пользователям SObjectizer, но и проектной команде SObjectizer, т.к. это продемонстрирует преимущества и недостатки SObjectizer по сравнению с другими подходами.
Однако, нужно понимать, что в первое время разработка и поддержка этого проекта будет вестись силами команды разработчиков SObjectizer 5. Что будет отражаться как на его объеме, так и на его прикладной направленности.
Возможно, подобным проектом станет компонент для работы с GSM-модемом, являющийся частью шлюза коротких сообщений компании Интервэйл. Данный компонент может быть автономным SObjectizer-приложением, которое можно использовать для отсылки и получения SMS-сообщений через GSM-модем.
Долгое время SObjectizer 4 разрабатывался как внутренний продукт, применявшийся небольшим количеством разработчиков. Поэтому документированию SObjectizer и построенных вокруг него библиотек, не уделялось должного внимания. Чаще всего на это просто не было времени. Особенно это касалось обучающий материалов -- написать толковое руководство по более-менее сложному инструменту гораздо сложнее, чем объяснить на пальцах основные принципы его использования в обычной беседе.
Подобная ситуация привела к тому, что SObjectizer 4 обладает рядом полезных библиотек, которые до сих пор не удается подготовить к публикации на SourceForge как раз из-за отсутствия обучающих материалов и примеров.
Недостаток документации -- это проблема значительного количества программных продуктов, особенно OpenSource разработок. Такова природа программистов -- писать код гораздо интереснее, чем документацию. Тем важнее для SObjectizer 5 синхронизировать выпуск релизов SObjectizer и его библиотек с выпуском документации. В первую очередь справочных руководств (reference manuals) и обучающих материалов (tutorials и guides) -- это позволит пользователям гораздо быстрее осваивать SObjectizer.
SObjectizer всегда был русскоязычным продуктом. Его делала команда русскоязычных разработчиков и использовался он в русскоязычной компании. Поэтому и продвижение SObjectizer в массы началось с русскоязычных форумов и журналов.
Однако, в странах бывшего СНГ, в которых находится подавляющее большинство русскоязычных программистов, складывается достаточно странная ситуация. Большие команды работают на оффшорных проектах и, поэтому, не могут выбирать используемые технологии самостоятельно, поскольку часто это уже давно сделано заказчиком.
Поэтому может оказаться, что принятие английского языка в качестве основного языка проекта SObjectizer 5, позволит привлечь к SObjectizer гораздо большее внимание и получить гораздо большие дивиденды, чем сохранение в качестве основного русского языка. Хотя и не понятно, достаточным ли окажется уровень знания английского у основных членов проектной команды SObjectizer 5 для того написания документации и общения на форумах и в списках рассылки.