пятница, 7 ноября 2014 г.

[prog.c++] Хочется странного. Полностью однопоточный вариант SObjectizer?

В последнее время код не пишу. Посему появляется возможность пофантазировать на разные отвлеченные и не очень темы. Одна из них -- это такой вариант run-time SObjectizer, в котором все работает в рамках одной рабочей нити. В пределе один run-time SObjectizer и прикладные агенты работают на одной-единственной, главной, нити приложения.

Появилась эта мысль при обдумывании реализации на SO5 имитатора одного технологического процесса (корни этой задачи уходят в далекие 1998-2000 годы). Захотелось имитаторы компонентов представлять в виде отдельных процессов ОС, взаимодействующих посредством MQTT. Оказалось, что практически для всех этих компонентов будет достаточно одной рабочей нити, на которой будут работать несколько не очень сложных агентов. Т.е. разворачивать в каждом процессе многопоточную кухню обычного SObjectizer-овского RunTime можно, пользователь все равно ничего снаружи не видит. Но это не отменяет того факта, что пара-тройка служебных нитей SObjectizer-а в дополнение к единственной необходимой рабочей нити в простейшем приложении -- это overkill и расход ресурсов (пусть даже их и не принято считать нонче, когда народ разрабатывает большие системы не то что на Java или C#, но на Python-ах и Ruby).

Потом подумалось о различных "умных" устройствах и встраиваемых системах вообще. Возможно, со временем, разработка софта для таких устройств создаст очередную большущую прикладную нишу, как это было в свое время с разработкой десктоп-приложений, Web-приложений и приложений для мобильных устройств (нынешний тренд). Конечно же, там так же будет своя дифференциация -- будут устройства помощнее, где будут многоядерные процессоры, ОС общего назначения и где можно будет запускать managed-приложения на какой-нибудь Java или даже Python/Ruby. Но ведь будут и менее мощные устройства, с одним вычислительным ядром, с небольшим объемом памяти, со специализированной, сильно урезанной ОС. Может ли SObjectizer позволить создавать приложения для них?

В принципе, а почему бы и нет?

На первый взгляд, для реализации однопоточного SObjectizer нет принципиальных препятствий. Всего один диспетчер. Специальный вариант таймера, который опрашивается между обработкой событий из очереди заявок. Более простая дерегистрация коопераций. Можно даже подумать о том, чтобы SObjectizer RunTime мог дергаться внутри какого-то event-loop-а. Например, когда нет никаких внешних событий или же сразу после их обнаружения.

Или же о варианте, когда SObjectizer интегрируется с MQTT или CoAP инструментами. Т.е. приложение представляет из себя однопоточный MQTT-клиент или CoAP-овский сервис. Внутри которого работают SObjectizer-овские агенты. Например, когда MQTT-шный клиент получает сообщение по подписке, это сообщение тут же передается SObjectizer-овскому агенту, который в этом сообщении заинтересован. Аналогично и с CoAP-ом: запрос принимается CoAP-овским слоем, а на обработку отдается SObjectizer-овскому агенту.

Насколько я помню, взаимодействие с внешним оборудованием, которое чаще всего и реализуется во встраиваемых устройствах, как раз хорошо описывается конечными автоматами. Типа: сработал таймер, отослали команду на включение лампочки в порт ввода-вывода, подождали N миллисекунд, опросили второй порт, если значение не поменялось, подождали еще K миллисекунд, еще раз опросили второй порт, если опять не поменялось, то повторили команду... В принципе, когда-то давным-давно, SCADA Objectizer-овские агенты для таких целей и предназначались. Теперь можно попробовать вернуться к истокам. Ведь я сильно сомневаюсь, что на маломощном устройстве с урезанной донельзя специализированной ОС кто-то будет делать такие вещи на короутинах. Не, наверняка будут ;) И это будет стильно, модно и молодежно ;) Но насколько практично?


Вот такие вот мысли. Интересно было бы попробовать. Но так, чтобы и существующий код ломать полностью не пришлось.

Похоже, придется наворачивать что-то на шаблонах. А это интересно еще и тем, что если базовые части SObjectizer-а станут представлять из себя шаблонные конструкции, то и SObjectizer может превратиться в header-only библиотеку. Что, как мне представляется, есть очень даже неплохо :)

Отправить комментарий