Множество виртуальных таймров, на одном системном.
Есть идея вести некий реестр таймеров и при каждом прерывании системного таймера, проверять наступило ли время события для программного таймера. Если событие наступило, то производить переход в обработчик события.
Казалось бы вроде как все просто, но насколько подобная схема будет тормозить систему? Ведь получается, что выход из прерывания не произойдет, пока не будут обработаны все "подписанты" из реестра текущих событий. А ведь там уже могут быть навешаны уже достаточно объемные функции...
Какие есть альтернативы?
операционная система получает от драйвера теймера сигнал "прошло столько-то времени" , после чего обновляет значения логических таймеров и , если условия выполнены , посылает сигнал "время таймера прошло" приложениям .
это так "на пальцах" объясняю . :)
И видимо очередь с приоритетом?
Т.е. нужно сделать некий диспетчер содержащий эту самую очередь и в бесконечном цикле проверять его на наличие событий?
P.S. Чем Ваше "объяснение на пальцах" отличается от моего первого варианта, за исключением разве что типа и источника сигнала?
Из первого сообщения это никак не следует.
Телепатов здесь нет.
А коль скоро не оговорено обратное, следует считать, что дело происходит под многозадачной ОС.
Невозможно получить адекватный ответ на неправильно поставленный вопрос.
Есть только маленький нюанс, время проведенное в обработчике линейно зависит от количества таймеров в списке, что в конечном счете, при соотв. количестве этих самых таймеров заставляет все встать колом.:D
Разумные ограничения всегда должны быть.
Какие есть альтернативы?
Можно использовать что-то вроде сторожевого таймера. Только он не будет сбрасывать контроллер (процессор или что там у вас), а заблокирует таймеры (или вообще прекратит выполнение насовсем), передав управление основной системе.
Понятно, что приоритет прерывания у такого "как бы сторожевого таймера" должен быть выше. Понятно, что в контроллере должно быть больше одного аппаратного таймера (что обычно и бывает) и хотя бы 2 приоритета прерываний.
Понятно, что приоритет прерывания у такого "как бы сторожевого таймера" должен быть выше. Понятно, что в контроллере должно быть больше одного аппаратного таймера (что обычно и бывает) и хотя бы 2 приоритета прерываний.
Чем стояние колом отличается от стояния колом вместе с недо-вачдогом? Каково истинное предназначение вачдога?
ну так я сразу сказал "в простейшем случае обработчик .." )
+1
Действительно, основная проблема заключается в том, чтобы не декрементировать постоянно каждый счетчик. Можно упорядочить список по значению timeout и хранить разницу в тиках до ближайшего события timeout. В этом случае за раз будут обрабатываться только те (относительные) счетчики (а фактически один счетчик и структура, объединяющая несколько таймеров в одну группу), которые соответствуют одному моменту наступления события timeout. Надеюсь, я понятно объяснил.
Его предназначение - перезапускать зависшую систему. Он работает так: если за определенный период не будет сброшен флаг сторожевого таймера, то таймер перезапускает всю систему.
В моём случае "недовачдог" будет сбрасывать или замораживать только часть системы, если основная программа не успела сбросить определенный флаг.
При этом наиболее приоритетная операция будет выполняться при любой сложности, при любом количестве низкоприоритетных логических таймеров.
Иначе, если у всех подпрограмм приоритет одинаков, то надо брать железо помощнее.
Ну, я так понимаю, речь уже перешла с самого принципа (вызывать обработчики в прерывании таймера или отложить обработку до завершения прерывания) на способы оптимизации второго варианта.
С одной стороны, задачу нужно решать последовательно, но с другой, конечно, на этапе принятия решения о выборе нужно представлять себе направление дальнейшего пути.
В данном же случае, мне кажется, все равно обсуждение оптимизации преждевременно, т.к. если уж появляется вероятность того, что система "встанет колом" от одного только инкрементирования счетчиков, то чего можно ожидать, если по каждому еще и вызывать обработчик. Притом до завершения аппаратного прерывания.