Средства и методы разработки

Ровно наоборот -- уйти от биглупа. Флаг -- да, изменение состояния. Задача сама спросит -- не вариант для сколько-нибудь большой системы, поскольку эти опросы, "сама спросит", тупо занимают много времени (и тратят энергии), увеличивают время отклика системы. Идея в том, чтоб запускалось только то, что должно запускаться, чтоб исключить "поллинг". Ровно в том же, что и с очередями событий. Но с той разницей, что мы принципиально отказываемся от модели подписчика в пользу наблюдателя и таким образом исключаем ряд потенциальных проблем (на самом деле переносим на другой уровень, где они на 90% сами решаются). Какой размер очереди сообщений нужен? Так же как и со стеком -- никто не скажет. И хуже того, какой ни возьми в ряде случаев оно всё ведёт к отказу (скорость поступления событий превышает скорость их обработки). Какой размер priority queue для событий -- я скажу. Ровно столько сколько разных типов событий есть вообще и не единицей больше. Их даже компилятор в момент компиляции посчитать может и ровно столько выделить. Т.е. в моём варианте всегда есть детерменизм в поведении системы при любых входных воздействиях (повторюсь, проблема отчасти переложена на реализацию конкретных автоматов, например, но там уже понятно как её решать). В варианте с очередью его нет и не может быть по двум причинам: ни глубина очереди непонятна (а она может быть реально большая, в N раз больше, чем число событий, т.к. в модели подписчика если N слушателей подписались -- для каждого своя копия события -- просто даже по памяти для МК уже неудобно), ни нет детерменизма в условиях быстрого поступления событий (причём здесь тоже непросто, "шторм" событий может же иметь чисто внутрипрограммные причины, не обязательно внешние воздействия даже -- и _нет_ способа гарантировать, что в какой-то момент программу не заштормит в состояние дедлока -- вот это принципиально, это не для настоящего embedded, это для windows-программирования только и годится).