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

[brag]

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

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

[brag]

arhiv6 , Вы путаете задачу и обработчик события. Это 2 разные понятия.
Обработчик может либо работать, либо не работать(выйти и освободить кадр стека), либо быть вытеснен обработчиком более приоритетного события, стек которого ляжет поверх вытесненного обработчика. Это по сути обычная функция и в моей реализации SST большинство времени планировщик именно это и делает - просто вызывает функцию.
Цепочка вызовов функций физически выглядит так: postEvent() -> scheduler() -> handler(). При чем функция postEvent - шаблонная inline, фактически будет вызван только scheduler() затем handler(). Операция очень быстрая и это от части заслуга компилятора.
А вот задача уже имеет свое состояние и для ее выполнения может понадобится куча событий, которые будут возникать хоть на протяжении целого года.
И состояние этой задачи и есть так называемый контекст, только это не регистры, как в многопоточной модели, а обычные переменные и обьекты C++.
А физически хранятся они там же, где и сама задача - в ячейке очереди задач. Это динамическая память. И она будет освобождена, как только задача завершит свою работу.

Посмотрите мой исходник, который я привел несколькими постами выше http://electronix.ru/forum/index.php?showt...t&p=1447897
DfMassEraseTask - это задача, вернее ее описание. Таких задач может быть создано хоть 100(ну на сколько хватит динамической памяти).
Ее контекст - это переменные:

Код

Df* const df;
delegate<void()> cbk;
SST::TPriority cbk_priority;

Физически - это 3 указателя и 1 байт и того на Cortex-M3/M4 займет это дело 4 слова(из за выравнивания) - 16 байт. А сколько занял бы стек потока? Килобайт? или может 512 байт хватит? Как посчитать?

[arhiv6]

brag, спасибо большое за разъяснение, теперь всё понятно. А можете посоветовать что почитать для тех кто хочет больше узнать про асинхронное программирование (не привязываясь к языку, чтобы упор был именно на алгоритмы)?

Сообщение отредактировал arhiv6 - Sep 8 2016, 10:54

[brag]

[/b]brag[/b], спасибо большое за разъяснение, теперь всё понятно. А можете посоветовать что почитать для тех кто хочет больше узнать про асинхронное программирование (не привязываясь к языку, чтобы упор был именно на алгоритмы)?

Не за что. Почитать мало что есть, нужно тренироваться. Для этого отлично подходит Javascript/NodeJS. А потом и на C++11(именно 11, на старых плюсах кода надо больше) сможете или на другом языке, который позволяет программировать в асинхронном стиле просто, без бубна. Можно и на C асинхронно писать, даже на ассемблере, только кода будет слишком много. Лучше поручить эту грязную работу компилятору.
Алгоритмы на любом языке одинаковые, отличается лишь внешний вид кода.