Вызов процедуры с определенной частотой
Возможно ли реализовать вызов определенного кода со строго заданным количеством вызовов в секунду? Количество может быть, например, 101, то есть варианты типа while(true){sleep(...); /*dosmth*/} не пройдут.
Если это возможно то как и какова вероятность погрешности?
P.S. Имеется в виду, что время между вызовами будет одинаковое.
Если это возможно то как и какова вероятность погрешности?
P.S. Имеется в виду, что время между вызовами будет одинаковое.
Воспользуйтесь таймером... WinAPI таймер задаётся с точностью до миллисекунды...
А там можно установить дилей 9.9009900990099009900990099009901 миллисекунды? Я ж написал, что количество может быть, например, 101 (1000 на 101 ну никак нацело не делится)...
Да уж... Ответил не задумываясь - извиняюсь... Интересный вопрос... А Вы уверены, что код вообще выполнится за это короткое время?
Ну, должен, наверно :)
Цитата из Рихтера "Создание эффективных Win32 приложений"
Цитата:
Меня часто спрашивают, как сделать так, чтобы поток гарантированно запускался в течение определенного времени после какого-нибудь события — например, не позднее чем через миллисекунду после приема данных с последовательного порта? Ответ прост: никак. Такие требования можно предъявлять к операционным системам реального времени, но Windows к ним не относится.
Windows -- система с вытесняющей многозадачностью. И то, через какой промежуток времени начнет выполняться код в вашем таймере, зависит от ситуации в системе на текущий момент.
Если имеется в виду стандартный IBM PC и ОС Windows, то "прямо" - никак.
Нужно или нестандартное аппаратное обеспечение, или ОС реального времени, или и то, и другое.
В принципе, в качестве "нестандартного оборудования" можно попытаться использовать звуковую карту и повесить процедуру, которая должна выполняться с определенной периодичностью на прерывание звуковой карты.
PS. Скажу сразу: таймер Windows обладает явно недостаточной точностью, чтобы удовлетворять поставленной задаче - 101 за секунду. Если бы было 101, скажем, за минуту, то, вполне вероятно, он бы и справился с поставленной задачей.
Нужно или нестандартное аппаратное обеспечение, или ОС реального времени, или и то, и другое.
В принципе, в качестве "нестандартного оборудования" можно попытаться использовать звуковую карту и повесить процедуру, которая должна выполняться с определенной периодичностью на прерывание звуковой карты.
PS. Скажу сразу: таймер Windows обладает явно недостаточной точностью, чтобы удовлетворять поставленной задаче - 101 за секунду. Если бы было 101, скажем, за минуту, то, вполне вероятно, он бы и справился с поставленной задачей.
Понятно. Спасибо за ответы.
Обычные аймеры - асинхронный механизм, там даже о 20 милисекундах реч не всегда идёт.
Но есть возможность определить время. (например с точночтью до милисекунды) GetTickCount() или timeGetTime();
И есть возможность с помощью обычных циклов организовать задержку любой точности, и тут дискретность времени может быть почти сколько угодно мала. Ведь int i = 2; будет выполнятся за ничтожное время, там даже не о наносекундах наверное.
Тоесть можно рекурсивно, вызывая функцию-функтор, и определяя необходимую задержку с помощью ф-й GetTickCount() (или каки-то наподобие) добиться более-менее работающего решения, но опять таки о очень точных отрезках времени реч не идёт вообще. Думаю большое число задач можно и таким способом решить.
ps. Это конечно пластилин обмотаный старой изолентой :p но как вариант
Но есть возможность определить время. (например с точночтью до милисекунды) GetTickCount() или timeGetTime();
И есть возможность с помощью обычных циклов организовать задержку любой точности, и тут дискретность времени может быть почти сколько угодно мала. Ведь int i = 2; будет выполнятся за ничтожное время, там даже не о наносекундах наверное.
Тоесть можно рекурсивно, вызывая функцию-функтор, и определяя необходимую задержку с помощью ф-й GetTickCount() (или каки-то наподобие) добиться более-менее работающего решения, но опять таки о очень точных отрезках времени реч не идёт вообще. Думаю большое число задач можно и таким способом решить.
ps. Это конечно пластилин обмотаный старой изолентой :p но как вариант
Цитата: iridum
Но есть возможность определить время. (например с точночтью до милисекунды) GetTickCount() или timeGetTime();
И есть возможность с помощью обычных циклов организовать задержку любой точности, и тут дискретность времени может быть почти сколько угодно мала. Ведь int i = 2; будет выполнятся за ничтожное время, там даже не о наносекундах наверное.
И есть возможность с помощью обычных циклов организовать задержку любой точности, и тут дискретность времени может быть почти сколько угодно мала. Ведь int i = 2; будет выполнятся за ничтожное время, там даже не о наносекундах наверное.
А если во время работы этих циклов кто-нибудь запустит сильно нагруженный поток с приоритетом повыше?
Есть книга Юрия Щупака "Win32 API Эффективная разработка приложений". Не буду ее особо хвалить, но работа со временем там приведена хорошо: рассмотрена работа с мультимедийным таймером (который работает намного стабильнее, чем стандартный), и разные способы измерять промежутки времени в микросекундах и даже меньше.
Естественно, и там упомянуто, что Windows - это не система реального времени.
Естественно, и там упомянуто, что Windows - это не система реального времени.
iridium,
GetTickCount хотя и выдает время в мс, имеет такую же погрешность, т.е. порядка тех же 20 мс.
GetTickCount хотя и выдает время в мс, имеет такую же погрешность, т.е. порядка тех же 20 мс.
Каждому потоку выделяется примерно по 20 мс времени, поэтому расчитывать на более или менее определённый delay можно только в пределах этого промежутка.
К сожалению, автор не сказал, для чего ему такое решение. Я сейчас могу предположить, что строится какая-то система обработки внешних сигналов, и в этом случае может быть правильнее обеспечить не гарантированное время отклика (что в Windows можно только в известных пределах, и то с вероятностью < 1), а гарантированную пропускную способность. Это делается несколько проще.
К сожалению, автор не сказал, для чего ему такое решение. Я сейчас могу предположить, что строится какая-то система обработки внешних сигналов, и в этом случае может быть правильнее обеспечить не гарантированное время отклика (что в Windows можно только в известных пределах, и то с вероятностью < 1), а гарантированную пропускную способность. Это делается несколько проще.