OberonCore

Возможно, глупый вопрос: а зачем в выражении Services.Ticks() + 5 * Services.resolution используется Services.Ticks()? Эта функция возвращает огромное число. В остальном, кажется разобрался. Тики происходят Services.resolution, то есть 1000 раз в секунду.
Пользуясь случаем, задам ещё вопрос. Значительно ли кооперативная многозадачность отличается от многопоточности, с точки зрения простого пользователя, которого не интересует техническая сторона вопроса? (круто загнул! )

Процедура DoLater регистрирует действие, которое должно произойти в определённый момент времени. Вот мы и вычисляем этот момент с помощью Services.Ticks(), которая возвращает количество прошедших от полуночи миллисекунд.

Спасибо! Вот теперь всё понятно.

Только не от полуночи, а от старта Виндовса.

При продуманной и качественной реализации с точки зрения пользователя разницы нет.Виндовс поднимается в полночь...
: ))

Да, точно, я ошибся. Services.Ticks использует винапишную GetTickCount. А вот в доке к Services написано, что Services.Ticks возвращает именно что текущее время, без упоминания начала отсчёта от старта системы.

У меня на днях возник где-то сходный вопрос: если мне для встроенного приложения надо полноценно нагрузить несколько (ну, 2 ) ядер микропроцессора, не будет ли достаточно просто реализовать аналог виртовского модуля Processes (на основе сопрограмм)?
Ведь здесь главное, что ядра не простаивают, работа делается.

А с точки зрения пользователя ПК может быть существенным желание, чтобы поток, реагирующий на его действия, не заставлял его долго ждать и подозревать, что программа "зависла".

Тут уместно было бы ещё упомянуть, что один тик не равен одной миллисекунде в точности, он чуть-чуть дольше.

Я проводил замеры (на компе АСУ ТП), и у меня получалось, что число тиков в сутках не постоянно, оно колеблется в пределах +-4 от расчётного. Возможно, что это как-то зависит от железа.

А точнее - от контроллера прерываний конкретной аппаратной платформы. Ну и от ОС.

Ну, исчо там ведь кварц стоит... И он температурно подвергается...

А ещё, наверное, если операционная система будет под большой нагрузкой, то некоторую часть прерываний она может не успеть обработать и пропустить тик, не так ли?

Да ну, бросьте! У него погрешность частоты в ppm-ах измеряется...

upd/ Вообще, если считать, что в сутках 86400000 мс, а один тик = 1 мс, то +- 4 тика в сутки вполне может укладываться в погрешность кварцевого генератора...

Интересен метод измерения тика.

А не пора-ли уж подумать о переходе с винды на что-то более адекватное, если есть необходимость в достаточно частом опросе того-же COM порта?

Сейчас я вспомнил, что ситуация ещё хуже, чем я выше написал.

Проблема в программе была такая: каждая запись в БД снабжается меткой даты-времени. Если время берётся из системных часов, то есть две проблемы: 1) переход на летнее время и обратно; 2) шаловливые руки пользователя, исправляющего системное время компьютера. Напомню, что во времена Win95/98 запретить пользователю изменить системное время было практически невозможно (двойной клик по часикам - и вперёд). Чтобы записи в БД шли со строго неубывающими метками времени, было принято решение брать системное время в момент запуска программы, а далее отсчитывать секунды тиками (тот самый GetTickCount) и хранить собственное "отмеренное" время.

Тогда-то я и узнал, что в Windows 98 в сутках вовсе не X=24*60*60*1000 тиков, а иной раз примерно на 4000 больше. Т.е. тиковое время за сутки убегает вперёд приблизительно на 4 секунды.

Метод измерения: программа раз в сутки перезапускалась, и при завершении работы выводила в журнал своё внутреннее время и системное время с точностью до секунды. Регулярно наблюдаемая разница > 1 секунды говорила о том, что пользователь тут ни при чём (тем более, что им говорили не трогать время, и что они были заинтересованы в корректной работе программы). Разница в 1 секунду понятна и легко объяснима, но в 4 секунды...

Если есть постоянно включенный компьютер, то можно написать простенькую программу, которая будет показывать тиковое время. Или ещё проще: поставить в автозапуск программу, которая запомнит системное время и соответствующее ему значение GetTickCount. Далее в любой момент времени можно взять текущие значения и сравнить с точкой отсчёта: сколько по системным часам, и сколько по тиковым.

Ну, если надо будет только COM-порт опрашивать и больше ничего, то может и перейдём : )

У меня не было ещё задач, где был бы необходим опрос чаще 10 раз в секунду или с точным квантованием времени. Мы просто используем винду по назначению, а не как ОС реального времени.

Но и точность тиков при таких больших периодах времени вобщем-то до-лампочки
Что, только COM-порт можно в компе опрашивать?

А сутки Вы по атомным часам отмеряли?

Да, по атомным. Читайте пост внимательнее.