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

Нет, это вычёсывание случая, когда биглуп только со своими проверками оборачивается за сотни миллисекунд (и это время реакции системы на любое событие!). В то время, как могли бы быть десятки мкс в лучшем случае и единицы-десятки мс в среднем (в худшем можно устроить while(1); поэтому не обсуждается). Речь о том, чтоб сократить число ненужных вычислений (потому, что они тупо повторяются в цикле, хотя для ложных условий результат отбрасывается и потом перевычисляется снова -- т.е. вычисления не нужны). Я имею ввиду проверку условий в биглупе. И батарейка конечно тоже -- неэффективная организации вычислений ведёт к глобальному потеплению, росту энтропии и тепловой смерти вселенной. Далее, для "супервизора" нет задач и нет их состояний. Это лишь метод нотификации о событиях возникших в одних программных модулях для других. Вызывается callback из "супервизора" по возникновению события. Ничего больше. Нельзя говорить о "готовых к выполнению" -- готовы они когда поступит сигнал, чтоб его обработать. Не более того. Никакого "поллинга" (т.е. циклического опроса) в "супервизоре" НЕТ. Ты это уяснить не можешь. У него внутри очередь на самом деле, только не fifo, а приоритетная. Но можешь считать, что fifo. И он извлекает крайний элемент и обрабатывает (вызывает все callbacks). Если элементы (события) кончились -- засыпает на семафоре, сбрасываемом при записи нового события (из обработчика прерывания, например). Т.е. опрашивается только голова очереди и семафор. А не всё подряд в цикле. Вот это тебе не понятно, ты считаешь, что там все условия в цикле проверяются -- это не так. Планировщик вообще о них не в курсе. Я же упомянул выше, мол аналог libevent, который, думаю, многие знают как работает. В libevent тоже нет "поллинга", он может быть зарыт в дебрях ОС (select), но может его и не быть (в современных ОС там внутри свои очереди ожидания, в цикле сокеты никто не проверяет).

Битовую переменную, которую устанавливает обработчик прерывания и поллит супервизор.

Ещё раз -- нет поллинга. Источник сигнала сам сигнализирует, посылает событие в планировщик. Планировщик вызывает слушателей. Но планировщик ничего в цикле не должен опрашивать. Входным сигналом для планировщика является только вызов функции помещающей что-то в очередь. Почему в месте возникновения сигнала нельзя напрямую вызвать функцию. Да, это хороший вопрос. Тогда планировщик не нужен, и биг луп не нужен. Собственно это и пытается сделать планировщик -- вызвать нужные функции. Только не напрямую, потому что: 0) мы предполагаем, что источник событий ничего не знает о наблюдателе, только наблюдатель знает о событии -- иначе построить архитектуру ПО где все знают всех -- невозможно, только для маленьких систем, всё равно нужен какой-то механизм регистрации/отписки наблюдателей от события, нельзя просто в код вписать вызов функции (хотя таки да, это могут быть чисто callbacks, но... см. ниже); 1) это вызовет рекурсии (возможно бесконечные); 2) возможен "шторм событий" (программа сама генерирует событий больше, за единицу времени, чем может обработать, причём процесс может носить опять же рекурсивный лавинообразный характер) как в модели с подписчиком (vs наблюдатель), в данном случае ограничиваемый не размером очереди, а размером стека (к слову, в автоматной технологии Шалыто шторм событий невозможен, именно "поллинг" переменных состояния этому препятствует); 3) нет понятия приоритета и даже хуже -- даже биг-луп завершается более-менее за предопределённое время, здесь же это время может быть существенно больше (ограничено размером стека); 4) не все источники событий могут вызвать callbacks -- из прерываний, например, невозможно, или если событие порождено ОС; 5) в многопоточной среде это значит, что функции будут как попало вызываться из разных потоков и мы будем вынуждены всё обложить мьютексами и до конца жизни бороться с дедлоками (а хотели построить синхронную систему, чтоб как раз избавиться от недостатков многопоточного программирования). У Шалыто тоже, "общая шина сообщений" (is.ifmo.ru/projects/turn/), цитирую: --- cut here --- 3.1. Взаимодействие автоматов Для решения этой задачи предлагается использовать модель их взаимодействия, в которой параллельные автоматы связываются друг с другом, используя механизм обмена сообщениями. Это дополняет методы взаимодействия автоматов, которые применялись в SWITCH- технологии и значительно упрощает процесс синхронизации параллельных автоматов. В предлагаемой модели по сравнению со SWITCH-технологией не используются события, а вместо них применяются сообщения. За один такт работы, так как автоматы работают параллельно, автомату может быть послано более одного сообщения... --- cut here --- Потому, что теория автоматного программирования в чистом виде, без шины для обмена сообщениями иногда приводит в тупик. И это при том, что состояния всё-таки опрашиваются "поллингом" (именно он позволяет отвязаться от рекурсии и "шторма событий").