Система, управляемая событиями и SST(super-simple tasker), Выделено из "ООП. Классы и динамические объекты" Опции

[brag]

Недавно я начал пользоваться динамической памятью. Раньше пользовался только статикой, то есть placement new. Со статикой сложно работать с такими шаблонами, как фабрика обьектов, временные задачи итд.
Программирую в основном под cortex-m3/m4
Код реализации аллокатора вышел довольно простым и быстрым, критически секции есть, но очень короткие(там прочитать/записать пару байт).
При чем я не использую этих всяких монстров под названием RTOS, у меня свой простейший асинхронный планировщик задач, занимает строк 300 кода с комментариями(погуглите запрос "super simple tasker", поймете что это).
В купе с динамическим аллокатором, variable element-size queue, новыми фишками C++ (шаблоны, лямбда-функции, auto) получается очень простой, безопасный и мощный фреймворк.
Вспоминаю работу с классическими Thread-ами(с ихними стеками - куча кода было написано для анализа программ на предмет нужного обьема стека, и теперь эта куча кода отправлена на мусорку) со всеми этими тяжеленными мютексами, семафорами, вечными циклами как страшный сон.

Если кому интересно - расскажу и покажу как это все работает.

[sigmaN]

Да, я тоже могу сказать, что узнал что-то новое из этой беседы.
Особенно меня удивил JS конечно же. Вот уж не ожидал так не ожидал ) Я JS использовал только в Qt, там он часть QML для создания интерфейсов.

В принципе реализация делегата более-менее стандартная. Нагугливается довольно легко.

У меня единственное остаются вопросы по SST конечно... постараюсь вкратце описать всё это.
Для начала давайте определимся, что любой объект с состоянием(для простоты рассматриваем класс в ООП) это так или иначе и есть конечный автомат. Методы класса в данном случае действуют как события приводящие или не приводящие к изменению состояния. Т.е. я хочу подчеркнуть, что в реальном мире у объекта много точек входа для изменения состояния.
Чтобы состояние менялось атомарно и состояние менялось строго в соответствии с графом(алгоритмом) при вызове методов из разных потоков(т.е. упростим до понятия "одновременно") вводятся мьютексы, сериализирующие изменение состояния. Т.е. делая эти изменения последовательными не смотря на то, что запросы на изменение пришли "одновременно".
В реальном мире в реальных системах состояний у объектов много и графы их изменений в масштабах системы довольно сложны, ребер(процесс смены состояния) у такого графа может быть довольно много.
Просто хочу чтобы мы это поняли.
Пеоеходим к SST:
Первое и самое главное ограничение это необходимость редизайна задачи(объекта, конечного автомата) таким образом, чтобы при выделении процессорного времени она быстренько run to completion. Следовательно мы должны проектировать наш объект(конечный атомат) таким образом, чтобы все изменения в состоянии происходили строго из одной точки входа(функции, которую дёргает SST планировщик). И обязательно принять условие, что только планировщик будет вызывать эту функцию. Обоснуем: извместно, что в любой момент выполнение может быть прервано другой задачей(более приоритетной, но это щас не важно) и не дай Бог та другая задача сделает что-то(вызовет метод), что изменит состояние первой задачи, которая находится в процессе смены состояния! Выполнение то было прервано на пол пути, где-то посередине ребра графа состояний конечного автомата. Бог знает в каком месте.
Я правильно мыслю? Не слишком блокировочно и многопоточно?

Таким образом да, благодаря одному потоку мы уже имеем последовательное выполнение и якобы не нуждаемся в мьютексах, которые как раз и созданы для сериализации доступа.
Мы вроде как экономим память и проц т.к. не переключаем полный контекст. Безусловно ДА.
Обратная сторона медали:
Мы приходим к жесточайшим ограничениям межзадачного взаимодействия! Единственная точка входа в задачу заставит нас сообщения для этой задачи хранить в очереди. Реализация такой очереди требует унификации всех сообщений(событий) системы или подсистемы. Таким образом интерфейс задачи(объекта) превращается не в привычный набор методов, а в набор сообщений которые можно посылать объекту.
Из всего этого следуют требования очень вдумчивой расстановки приоритетов задач, что по дизайну заставит вас подпиливать задачи под систему, что нарушиает инкапсуляцию, увеличивает завязку частей системы друг на друга. Хотя-бы в части форматов этих очередей с сообщениями. В системе появляется много функторов(делегаты ваши) которые циркулируют туда-сюда...

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

По этим причинам SST это далеко не панацея, а хитрое название для давно и хорошо известного автоматного подхода https://ru.wikipedia.org/wiki/%D0%90%D0%B2%...%BD%D0%B8%D0%B5
способ сэкономить немного памяти/немного проца за счет немалых изменений в архитектуре системы.
Конечно же такой подход тоже является NP полным и позволит вам теоретически решить любую задачу.

Дискутировать тут можно только над целесообразностью такого преобразования системы. Можно рассуждать над побочными эффектами, над расширяемостью такой системы и т.д...
Как видим на примере современных ОС в реальном мире побеждает симбиоз потоков и разделения времени с событиями(асинхронный IO тому пример).
На чем наверно можно и сделать окончательный вывод )