четверг, 21 сентября 2017 г.

[prog.c++] Вопрос к читателям: интересна ли кому-нибудь статья о деталях реализации asio_thread_pool диспетчера?

Мы вчера выкатили so_5_extra-1.0.2 с реализацией нового диспетчера на базе Asio. В этой самой реализации получилось интересное, как мне кажется, использование фишек С++, включая наследование, шаблоны и даже thread_local переменные. Причем "интересное" именно в плане использования возможностей языка. Специфика SObjectizer-а, конечно же, есть, но скорее как фон и условия, для которых пришлось искать решение.

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

Посему у меня к читателям блога пара вопросов:

  1. Будет ли интересен кому-нибудь такой рассказ вообще? Не хочется тратить несколько дней работы на то, что прочитает 10-15 человек.
  2. Если же статья все-таки кому-то интересна, то где бы вам было бы удобнее ее видеть: у меня в блоге или на Хабре? Место публикации важно потому, что, во-первых, от этого зависит стиль и подробность изложения, а так же, во-вторых, удобство комментирования и качество комментариев. В принципе, с точки зрения величины аудитории я бы нацеливался на Хабр. Но если у многих моих читателей к Хабру отношение негативное, то проще будет написать статью для блога.

В общем, прошу не счесть за труд и высказать свое мнение. Можно и пожелания по будущему тексту (например, на что сделать акцент, чтобы статья была интереснее для вас). Комментарии можно оставлять в блоге или в G+. Ну или там, где я еще размещу ссылки на этот пост (типа Facebook-а или LinkedIn-а).

На 2017.09.24 10:00 "за" проголосовало только четыре человека, этого мало для того, чтобы браться за написание статьи.

понедельник, 18 сентября 2017 г.

[prog.c++14] Мечты сбываются: задышала реализация диспетчера, которая может использовать пользовательские классы нитей

В рамках работ над новой версией so_5_extra разрабатывается asio_thread_pool-диспетчер. Это диспетчер, в котором на пуле потоков запускаются методы asio::io_service::run(), и агенты, которые привязаны к такому диспетчеру, отрабатывают свои события на этих же рабочих потоках. По сути, диспетчеризацией событий для таких агентов занимается asio::io_service. Что должно дать возможность агентам просто и прозрачно выполнять и IO-операции, и обработку прикладных сообщений не задумываясь о том контексте, на котором они работают (ноги у этого всего растут вот отсюда).

Но самое интересное для меня другое: это был еще и эксперимент по созданию диспетчера, который может использовать не только std::thread для создания рабочих потоков, но и предоставленный пользователем класс нити, если этот класс частично мимикрирует под std::thread. Зачем такое может потребоваться?

Ну, например, если вы хотите использовать какую-то специфическую для ОС функциональность, недоступную через std::thread. Скажем, если вам нужно назначить собственные pthread_attr_t перед запуском рабочей нити. Это не такая уж и экзотическая ситуация. Например, если вы создаете большое количество нитей в приложении, то можете захотеть уменьшить размер стека для них, т.к. размер по умолчанию для вашей задачи может быть слишком большой.

Так вот, этот новый asio_thread_pool показал, что подобный фокус вполне себе работает. И выглядит это как-то вот так:

// Definition of traits to be used with asio_thread_pool.
struct my_disp_traits
{
   // Actual type of thread to be used.
   using thread_type = my_pthread_t;
};
...
   // Create dispatcher for ring of agents.
   auto disp = asio_tp::create_private_disp<my_disp_traits>(
         coop.environment(),
         "asio_tp",
         std::move(disp_params) );

Стоить определить в traits-ах для диспетчера имя класса, который следует использовать вместо std::thread, и asio_thread_pool начнет использовать данный класс.

Любопытные последствия могут быть у этого эксперимента. У меня уже давно есть мысль о том, чтобы добавить возможность такой кастомизации ко всем штатным диспетчерам SO-5. И, поскольку эксперимент оказался удачным, такая возможность может воплотиться в реальность в SO-5.5.20, работа над которой должна начаться вот прямо после фиксации so_5_extra-1.0.2. А это означает, что реализации штатных диспетчеров вынужденно станут шаблонными. Что заметно уменьшит количество .cpp-файлов в исходниках SObjectizer-а. Что будет означать еще одним большой шаг в сторону header-only версии SO-5. При этом header-only -- это вовсе не самоцель. Но чем больше будет в SO-5 кастомизаций через шаблоны, тем ближе к header-only окажется реализация.

Под катом простейшая реализация my_pthread_t, набросанная на коленке за 15 минут...