Как устроена задержка в TTimer?

Мне необходимо несколько раз в секунду выполнять некоторую функцию, выполнение которой занимает длительное время.
Предположим, что нужно вызывать функцию 10 раз в секунду. Логично предположить, что для этого свойство Interval у TTimer нужно задать 100 (мс).
Но, предположим, что для выполнения функции OnTimer() требуется: а) на мощном компьютере 30 мс; б) на слабом компьютере 120 мс.

Как будет реализована задержка таймера в случаях "а" и "б"?

Нужно ли в случае "а" уменьшать свойство Interval таким образом, чтобы учесть время выполнения OnTimer (например 30 + 70 = 100)? Или же Событие OnTimer в любом случае будет стабильно срабатывать 10 раз в секунду?

Что будет происходить в случае "б"? События OnTimer будут накапливаться в какой-нибудь очереди на выполнение? Или будут пропускаться (игнорироваться) те события, которые не успевают обработаться на данный момент?

И как грамотно и корректно определить, успевает ли выполниться функция между двумя срабатываниями таймера (чтобы предупредить пользователя, что мощности его ПК недостаточно для корректной работы программы)?

0

Если не ошибаюсь, для случая а) операция будет выполняться (примерно) раз в 130 мс, для б) - раз в 220 мс.
Нужно вынести код, выполняемый при срабатывании таймера, в отдельный поток.
Для определения времени выполнения можно использовать GetTickCount().

1

gunslinger, попробую написать демо пример для изучения данного вопроса...

Если у кого-то есть конкретный опыт в этом вопросе - прошу поделиться)

0

Сообщение от znseday Как будет реализована задержка таймера в случаях "а" и "б"?

В момент определенный интервалом таймера, в очередь сообщений поступит очередное сообщение WM_TIMER, которое будет там торчать до тех пор, пока его не выберет WndProc компонента TTimer. То есть, следующий тик настанет вовремя, и плевать таймер хотел, успела отработать та процедура, которую ты вызвал, или не успела. Если процедура, которую ты вызываешь, нереентерабельна - будут проблемы.

0

gunslinger, если создавать отдельный поток, то его лучше создавать каждый раз новый в OnTimer (и, соответственно, проверять его состояние на STEAL_ACTIVE) или же создать всего один дополнительный поток и как-то реализовать его взаимодействие с таймером?

volvo, что если создать статическую (или глобальный) переменную-флаг, который будет хранить состояние - отработала функция или нет. Грубо говоря в конце OnTimer() устанавливать в состояние "отработала", а в начале OnTimer() проверить состояние флага - если не отработала, то выдать ошибку о том, что производительности ПК не хватает для решения задачи.

0

Сообщение от znseday или же создать всего один дополнительный поток и как-то реализовать его взаимодействие с таймером?

Это не спасет при недостатке вычислительной мощности. Придется создавать каждый раз новый поток, разумеется, при недостатке мощностей они будут изначально создаваться чаще, чем уничтожаться, и чем больше их будет, тем больше они будут отжирать ресурсы.

Так что вариант с проверкой, отработал ли предыдущий вызов (через флажок) очень даже к месту будет.

0

Сообщение от volvo Это не спасет при недостатке вычислительной мощности. Придется создавать каждый раз новый поток, разумеется, при недостатке мощностей они будут изначально создаваться чаще, чем уничтожаться, и чем больше их будет, тем больше они будут отжирать ресурсы.

Согласен. Поэтому и предлагаю проверять через:
Если поток еще не отработал до момента наступления нового события таймера, то ошибка о недостатки производительности.

С одной стороны, идея с простым флажком требует меньше ресурсов и проще. С другой стороны, возможно, потоки и лучше. Нужно на практике потестировать, как все это будет работать. Ключевым фактором для меня является стабильность срабатывания функции, т.е. например строго через 100 мс без отклонений в большую или меньшую сторону.

0