Размышления и впечатления, которые не хочется держать в себе. О программировании в частности. Ну и о творчестве, и о жизни вообще.
Кстати говоря, в упомянутом в предыдущем посте примере collector_many_performers создается 30 рабочих нитей для обслуживания агентов. Но нигде в коде нет ничего, связанного с ручным управлением этими нитями. Или же с какими-нибудь низкоуровневыми примитивами синхронизации. Или же с ручным привязыванием очередей сообщений к сущностям и запихиванию/извлечению сообщений в/из этих очередей. Ничего этого нет.
Просто все работает и все ;)
SObjectizer рулит, одним словом :)))
Тема была начата двумя сообщениями: "Агент-collector + агент-performer = паттерн для нескольких ситуаций" и "Еще одна идея по балансировке нагрузки на нескольких агентов". Изложенные в вышеозначенных постах идеи удалось проиллюстрировать небольшими работающими примерами. Они уже есть в репозитории SObjectizer-а на SourceForge: collector_performer_pair и collector_many_performers, пока в branches, но во время следующего релиза обязательно войдут в стабильную версию.
При написании примеров выяснилось, что распараллелить обработку сообщений посредством thread_safe-событий и диспетчера adv_thread_pool очень просто, все делается буквально по щелчку. А вот с идеей реализации агентов-близнецов дело не пошло.
Может этот ролик демонстрировали в РФ, но здесь, в РБ, я его раньше, к сожалению, не видел.
Вот здесь статья о ролике, в которой есть видео, посвященное его созданию.
Что-то в последнее время встречая в описании вакансии фразу вроде "Требуется знание библиотеки Boost" возникает труднопреодолимое желание выяснить, а какую же именно часть из этого перечня входящих в Boost библиотек знают те, кто эту вакансию объявлял.
Имхо, "знание Boost-а" сейчас -- это как "знание высшей математики": совершенно бесполезная фраза без уточнения того, о чем конкретно идет речь.
Еще одна интересная презентация на тему того, где находит свое применение C++, ACE, OpenDDS и TAO. На этот раз речь идет о проекте DARPA System F6, где F6 -- это Future, Fast, Flexible, Fractionated, Free-Flying Spacecraft.
С удовольствием посмотрел презентацию "DDS vs DDS4CCM" от Remedy IT (эта компания стоит за такими вещами, как ACE и TAO). И хоть многое было не понятно и для того, чтобы досконально разобраться, что к чему (если это потребуется) придется приложить немало усилий, но все равно воспринимается как бальзам на душу. По многим причинам.
Джим Коллинз, один из авторов книги "Построенные навечно", не так давно написал книгу "Как гибнут великие". В которой разобрал сценарии, ведущие к краху бывших некогда великими компаний.
Открыл Google Translate (в Firefox-е), выбрал перевод с испанского, скопипастил слово из клиборда. Получил:
Велик, могуч и удивителен язык-то русский! :)
Upd. Продолжение еще фееричнее:
В предыдущем посте был озвучен способ использования возможностей adv_thread_pool-диспетчера по балансированию нагрузки между несколькими рабочими нитями (за счет thread_safe-обработчиков событий у агентов). Для этого способа необходимо, чтобы обработчик события не изменял состояние агента. В ряде случаев это возможно. Но далеко не всегда.
Чем больше думаешь о таких вещах, как защита агентов от перегрузки и обеспечение дедлайнов обработки сообщений, тем больше убеждаешься в том, что разделение на агента-collector-а и агента-performer-а -- это действительно очень простой и действенный путь к нужному результату. Фактически, паттерн для SObjectizer.
Суть этого приема в том, что для выполнения какой-то прикладной работы создаются два агента, работающих на разных контекстах.
