[prog.thoghts] Еще несколько слов на тему однопоточного SObjectizer Environment

Тема однопоточного SObjectizer Environment сидит в голове уже довольно давно. К сожалению, она не так проста, как это представлялось ранее. Поэтому руки дошли только сейчас.

Почему тема не так проста. Имеет смысл рассматривать три ситуации:

1. Используется многопоточный SOEnv. Не суть важно, есть ли в приложении другие рабочие потоки или нет, просто из-за того, что сами агенты внутри SOEnv могут работать на разных потоках, нужно защищать внутренности SOEnv, диспетчеров и самих агентов от многопоточного доступа. Т.е. где-то будут использоваться атомарные счетчики, где-то спин-локи, где-то мутексы и т.д. и т.п.
2. Используется однопоточный SOEnv, но внутри многопоточного приложения. Т.е. все агенты работают внутри SOEnv, но кроме них в приложении есть еще и другие активности. Поэтому сообщение агенту может прилететь не только из самого SOEnv, но и извне SOEnv. Поэтому потроха SOEnv и агентов так же должны защищаться (следовательно, остаются те же самые атомарные счетчики, спин-локи, мьютексы и т.д. и т.п.). Так что в этой ситуации реализация самих агентов мало чем отличается от реализации агентов для случая многопоточного SOEnv.
3. Используется однопоточный SOEnv внутри однопоточного же приложения. Т.е. когда запускается SOEnv, в приложении больше ничего не работает. Это означает, что агент может получить сообщение только из этого же самого SOEnv. А это устраняет необходимость защиты потрохов SOEnv и агентов от многопоточного доступа. Т.е. не нужны ни атомарные счетчики, ни спин-локи, ни мутексы...

Пока для версии 5.5.19 рассматривается вариант сделать однопоточный SOEnv только для второго сценария, т.е. для случая, когда однопоточный SOEnv работает внутри многопоточного приложения. В этом случае можно не только переиспользовать уже имеющийся код, но и нет риска внести несовместимость между версиями на уровне исходных текстов. Ибо сейчас мне кажется, что реализовать SO-5, который бы эффективно работал во всех трех ситуациях, возможно только за счет активного использования шаблонов.

Например, чтобы базовый тип агента, so_5::agent_t, был шаблоном приблизительно такого вида:

template< typename Env = so_5::mt_env::environment_t > class agent_t { public :    ...    Env & so_environment() { return *m_env; } private :    Env * m_env;    ... // Какие-то внутренности, которые зависят от типа Env. };

Тогда, если пользователь создает агента для работы в многопоточном окружении, он может написать так:

class my_agent_t : public so_5::agent_t<> {    ... // Начинка прикладного агента. };

Если нужно создать агента, который должен работать только в однопоточном окружении (т.е. его потроха не защищены никакими примитивами синхронизации), то можно писать так:

class st_only_agent_t : public so_5::agent_t< so_5::st_env::environment_t > {    ... // Начинка прикладного агента. };

Если нужно создавать агента, который сможет работать в любом окружении, то такой агент должен быть шаблоном:

template< typename Env > class universal_agent_t : public so_5::agent_t< Env > {    ... // Начинка прикладного агента. };

Вот в случае с шаблонной реализацией агентов более-менее понятно, как играть с деталями реализации so_5::agent_t, чтобы для каждого типа окружения (многопоточного или однопоточного) в агенте были все необходимые внутренности (а так же отсутствовало все лишнее). Если же пытаться обходиться без шаблонов, то, боюсь, все уходит в сторону дополнительной косвенности. Т.е. очевидным образом напрашивается PImpl, где внутренности агента будут создаваться динамически при регистрации агента в SOEnv и конкретный тип этих внутренностей будет определяться типом SOEnv.

Вот эта самая косвенность мне и не нравится. Поэтому шаблоны выглядят предпочтительнее.

Но если агенты становятся шаблонами, параметризуемыми через SOEnv, то с большой долей вероятности и все остальные части SObjectizer-а так же окажутся шаблонами. Например, mbox-ы так же должны быть шаблонами, т.к. для многопоточных SOEnv в них должны быть примитивы синхронизации, а для однопоточных SOEnv это не нужно. Диспетчеры так же нужно будет оформить так, чтобы какой-нибудь thread_pool диспетчер мог применяться для многопоточного SOEnv, но не мог для однопоточного (и чтобы это проверялось в compile-time). Да и сам so_5::environment_t вполне может быть шаблоном.

Так что это прямая дорога к тому, чтобы SO-5 перешел в категорию header-only библиотек. Что может и не есть плохо, но на данный момент это слишком стремный шаг.

Поэтому пока речь идет о том, чтобы в SO-5.5.19 сделать поддержку многопоточного SOEnv и однопоточного SOEnv в многопоточном приложении. Посмотреть, что из этого выйдет. А потом, если будет такая необходимость, решить что делать с однопоточным SOEnv для однопоточных приложений: переводить ли SO-5 в категорию header-only библиотек или идти каким-то другим путем.

Пока как-то так события развиваются. Если же кому-то нужен именно однопоточный SOEnv именно для однопоточного приложения, то тогда об этом лучше сказать прямо сейчас.

---

Знаю, что можно попробовать сохранить совместимость на уровне исходных текстов за счет вот таких приемов:

namespace so_5 { template< typename Env > class agent_template { ... }; using agent_t = agent_template< so_5::mt_env::environment_t >; template< typename Env > class mbox_template { ... }; using mbox_t = mbox_template< so_5::mt_env::environment_t >; ... }

Что позволит сохранить работоспособность уже написанного кода вида:

class my_agent : public so_5::agent_t { public :    my_agent( context_t ctx, so_5::mbox_t parent )       :  so_5::agent_t{ std::move(ctx) }       ,  m_parent{ std::move(parent) }    {}    ... private :    const so_5::mbox_t m_parent;    ... };

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