SObjectizer 5.3.0

eao197, на вашем месте в качестве основы реализации ad-hoc агентов я бы рассмотрел шаблонный класс, типизируемый контекстом, который передает этот контекст (и env) первыми параметрами в лямбды. Сигнатура лямбды усложнится, но вероятность допустить ошибку значительно уменьшится, что важнее.

Цитата Flex Ferrum @ 05.07.14, 09:54

eao197, на вашем месте в качестве основы реализации ad-hoc агентов я бы рассмотрел шаблонный класс, типизируемый контекстом, который передает этот контекст (и env) первыми параметрами в лямбды. Сигнатура лямбды усложнится, но вероятность допустить ошибку значительно уменьшится, что важнее.

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

Если же я ошибаюсь, то в будущем можно будет и более сложные варианты рассмотреть.

Цитата eao197 @ 04.07.14, 19:11

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

Когда кажется, креститься надо. Все там одновременно насколько это возможно.

Цитата korvin @ 05.07.14, 10:04

Когда кажется, креститься надо. Все там одновременно насколько это возможно.

Это доказательство из разряда "Мамой клянусь!"

Впрочем, я посмотрел свой старый код, который я когда-то делал на mutex-ах. Там не было задачи обеспечивать синхронный запуск всех четырех рабочих очередей. Так что это я уже что-то от себя выдумал. Под впечатлением от Qt-шной реализации Игоря Мирончика.

Цитата Flex Ferrum @ 05.07.14, 09:18

bsivko, угу, ясно. Интересно, насколько ускорится код eao197, если перестать постоянно дёргать хип таким вот образом?

Не так, чтобы много. На 500k встреч время уменьшилось с 1.9s до 1.7s. Код теста здесь.

В данном тесте основные потери времени идут на том, что в очереди каждой рабочей нити хамелеонов оказывается всего одна заявка. Поэтому когда она извлекается, рабочая нить засыпает на condition variable в ожидании следующей заявки. Это дорого.
Если бы в данном конкретном примере рабочие нити ждали не на condition variable, а на spin lock-ах, то время работы было бы заметно меньше. Но это была бы заточка под конкретный тест. А в общем случае запускать ожидание рабочей нити на spin lock-е -- это неразумно.

Может быть, со временем мы придем к какому-то более хитрому, адаптивному механизму. Например, сначала несколько попыток ожидания на spin lock-е, затем переход к condition variable. Нужно будет смотреть. Но хотелось бы отталкиваться не от простых синтетических тестов.

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

Цитата eao197 @ 05.07.14, 10:08

Это доказательство из разряда "Мамой клянусь!"

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

Сообщение отредактировано: korvin - 05.07.14, 11:41

Цитата korvin @ 05.07.14, 11:35

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

Практика доказывает наличие проблем, а не их отсутствие.
Что должен показать вывод времени?

Я исхожу из того, что запуск гороутин идет подряд:

go newChameleon(meets, colorBlue,   meetplace)
go newChameleon(meets, colorRed,    meetplace)
go newChameleon(meets, colorYellow, meetplace)
go newChameleon(meets, colorBlue,   meetplace)

И каждый хамелеон начинал работать не дожидаясь каких-то сигналов:

func newChameleon(meets chan int, c color, meetplace chan meeter) {
    done := make(chan bool)
    self := &chameleon{c, 0}
    for {
        meetplace <- meeter{self, done}

Это означает, что если в самом Go нет какой-то магии вокруг канала chan meeter, то первая запущенная гороутина сразу же пишет в канал. Туда же сразу же пишет вторая, третья и т.д.

Только вот многопоточная/многопроцессная работа она такая вот. Специфична тем, что текущий поток/процесс может быть приостановлен в любой момент (есть многозадачность реально вытесняющая). Это значит, что между второй и третьей конструкцией go newChameleon() поток с функцией main может быть приостановлен на некоторое время. Этого времени может хватить двум первым хамелеонам для того, чтобы выбрать весь лимит встреч. А может и не хватить. Что чаще всего и происходит на практике, т.к. если система не перегружена выше крыши, нити/процессы прерываются не небольшие интервалы времени. Тем не менее, с теоритической точки зрения, вполне может быть так, что весь тест проделают только два или три стартовавших первыми хамелеонов.

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

Цитата eao197 @ 05.07.14, 11:47

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

Да всё одно и то же на самом деле.

Цитата eao197 @ 05.07.14, 11:47

Практика доказывает наличие проблем, а не их отсутствие.

И какие проблемы ты видишь в моем примере?

Цитата eao197 @ 05.07.14, 11:47

Это означает, что если в самом Go нет какой-то магии вокруг канала chan meeter, то первая запущенная гороутина сразу же пишет в канал. Туда же сразу же пишет вторая, третья и т.д.

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

Цитата korvin @ 05.07.14, 12:31

И какие проблемы ты видишь в моем примере?

Я их уже описал.

Цитата korvin @ 05.07.14, 12:31

Каналы --- точки синхронизации, все четыре горутины пытаются писать в канал и блокируются до тех пор, пока их сообщение не будет прочтено.

Гороутина meetingplace уже запущена к тому моменту, когда стартует первый хамелеон. Так что обработка запросов хамелеонов идет сразу же, как только первый из них появляется.
Если бы гороутина meetingplace стартовала после хамелеонов -- это бы лишило мои замечания смысла.

Цитата eao197 @ 05.07.14, 11:47

Это значит, что между второй и третьей конструкцией go newChameleon() поток с функцией main может быть приостановлен на некоторое время. Этого времени может хватить двум первым хамелеонам для того, чтобы выбрать весь лимит встреч.

А еще кто-то может выдернуть шнур питания, да.

Добавлено 05.07.14, 12:38

Цитата eao197 @ 05.07.14, 12:37

Если бы гороутина meetingplace стартовала после хамелеонов -- это бы лишило мои замечания смысла.

Это бы ничего не изменило, в твоей ситуации горутина meetingplace может просто быть приостановлена на неопределенное время и ничего не будет работать.

Добавлено 05.07.14, 12:41
Но да ладно, просили, получите.

Состоялся релиз SObjectizer 5.4.0

Версия 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, являющаяся высокоуровневой библиотекой для обмена сообщениями между агентами или между компонентами распределенного приложения.

Примечание. Компилятор Microsoft Visual C++ 11 (т.е. MSVS2012) больше не поддерживается. Для компиляции под Windows теперь нужно использовать Visual C++ 12 (т.е. MSVS2013).

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

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

Также может быть интересна статья о SObjectizer на Openquality.

Сообщение отредактировано: bsivko - 14.08.14, 10:47

SObjectizer обновился до версии 5.5.0

Главное отличие v.5.5.0 от предыдущих версий -- это отсутствие зависимости от ACE Framework. Т.е. теперь ACE в коде ядра SObjectizer не используется вообще, для SObjectizer достаточно наличия стандартной библиотеки C++11. Это означает, что SObjectizer уменьшился в размере, нужно меньше времени на сборку SObjectizer-проектов, упрощается поддержка различных компиляторов и платформ. В частности, эта версия SObjectizer тестировалась посредством MSVS2013 (Windows), GCC 4.8/4.9 (Windows, Linux), Clang 3.5.0 (Linux).

Из более мелких изменений можно отметить прямую поддержку std::chrono при работе с отложенными/периодическими сообщениями, а так же небольшое изменение названий некоторых классов/функций (с сохранением старых имен для обеспечения совместимости). Более подробная информация о нововведениях в v.5.5.0 доступна в соответствующем разделе Wiki проекта. Так же увеличилось количество страниц с описаниями базовых вещей SObjectizer.

Версия 5.5.0 может быть загружена из раздела Files или получена из Subversion-репозитория.

Примечание. Этот релиз содержит только ядро SObjectizer (т.е. проект so_5). Никакие другие подпроекты (вроде so_log или so_sysconf) в релиз не включены. Возможно, сборка SObjectizer Assembly со всеми подпроектами будет сформирована и опубликована позже (если она действительно кому-то потребуется).

PS. Анонс делается просто для того, чтобы уведомить, что такой проект есть, живет, развивается. Доступен под BSD-лицензий, т.е. даром, в том числе и для коммерческих проектов. Это не просьба сделать code review. И не попытка кому-то что-то "продать".

PPS. Специально для желающих постебаться над синтаксисом и посравнивать программирование на C++ с Perl-ом. Вот классический пример Hello, World. В традиционном, ООП-шном варианте, с созданием класса агента и переопределением виртуальных методов (хотя есть и более модерновый вариант, с использованием С++ных лямбда-функций):

#include <iostream>
 
// Main SObjectizer header files.
#include <so_5/all.hpp>
 
// Definition of an agent for SObjectizer.
class a_hello_t : public so_5::rt::agent_t
{
    public:
        a_hello_t( so_5::rt::environment_t & env )
            : so_5::rt::agent_t( env )
        {}
 
        // A reaction to start of work in SObjectizer.
        virtual void
        so_evt_start() override
        {
            std::cout << "Hello, world! This is SObjectizer v.5."
                << std::endl;
 
            // Shutting down SObjectizer.
            so_environment().stop();
        }
 
        // A reaction to finish of work in SObjectizer.
        virtual void
        so_evt_finish() override
        {
            std::cout << "Bye! This was SObjectizer v.5."
                << std::endl;
        }
};
 
int
main( int, char ** )
{
    try
    {
        // Starting SObjectizer.
        so_5::launch(
            // A function for SO Environment initialization.
            []( so_5::rt::environment_t & env )
            {
                // Creating and registering single agent as a cooperation.
                env.register_agent_as_coop( "coop", new a_hello_t( env ) );
            } );
    }
    catch( const std::exception & ex )
    {
        std::cerr << "Error: " << ex.what() << std::endl;
        return 1;
    }
 
    return 0;
}

PPPS. Специально для желающих узнать, чем SObjectizer лучше libcppa/CAF. В двух словах -- это две совершенно разные разработки, ставящие перед собой разные цели и достигающие их разными способами. Подробнее здесь и здесь.

Сообщение отредактировано: eao197 - 01.10.14, 07:57

Версия 5.5.1

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

Если кому-то интересно, то вот еще один пример. Одно из возможных решений проблемы Producer-Consumer с защитой Consumer-а от перегрузки.