Баръер в 1 мс
Можно ли преодолеть баръер в 1 милисекунду для отчета времени в микросекундах каким-либо способом? TTimer такой возможности не дает
А что за задача стоит? Для чего это?
Вот мои мысли в слух, которые могут быть ошибочными или неправильными:
Я не знаю как изнутри роботает ТТаймер. Возможно отслеживает прерывания таймера, но они кажется происходят примерно 12,5 раз в секунду. Ето слишком мало по сравнению с 1000.
Есть такты процессора. И помойму их количество можно узнать командой RDTCS (о чем я тоже не имею никакого представления и никогда такого не делал.) Под досом я бы питался сделать так.
1. Перехватываю преривания таймера.
2. Засекаю количество тактов и жду несколько тиков таймера.
3. считаю, сколько примерно ето милисекунд.
4. Засекаю количество тактов, ищу разницу тактов, читаю сколько тактов на одну милисекунду.
5. пишу подпрограму которая выполняет задержку.
Ето все на асемблере, на котором я только лабы в политехе делал.
Возможна идея неправильная и не реализируемая. Так что простити если что не так.
ЗЫ. Даже если так можно сделать всеровно роботать будет не точно.
Виндовс - не система реального времени и запросто может передать управление другому процесу на неопределенно е время.
Я не знаю как изнутри роботает ТТаймер. Возможно отслеживает прерывания таймера, но они кажется происходят примерно 12,5 раз в секунду. Ето слишком мало по сравнению с 1000.
Есть такты процессора. И помойму их количество можно узнать командой RDTCS (о чем я тоже не имею никакого представления и никогда такого не делал.) Под досом я бы питался сделать так.
1. Перехватываю преривания таймера.
2. Засекаю количество тактов и жду несколько тиков таймера.
3. считаю, сколько примерно ето милисекунд.
4. Засекаю количество тактов, ищу разницу тактов, читаю сколько тактов на одну милисекунду.
5. пишу подпрограму которая выполняет задержку.
Ето все на асемблере, на котором я только лабы в политехе делал.
Возможна идея неправильная и не реализируемая. Так что простити если что не так.
ЗЫ. Даже если так можно сделать всеровно роботать будет не точно.
Виндовс - не система реального времени и запросто может передать управление другому процесу на неопределенно е время.
С аналогичным успехом можно повесить в другом потоке простой счётчик вида i++, пусть тикает. При помощи TTimer можно отследить среднее время между приращениями. Потом посчитать количество приращений, и буте счастье. Другой вопрос, что Винда потокау выделяет всякий раз разное время, тут возможна ошибка.
Цитата: Sanila_san
С аналогичным успехом можно повесить в другом потоке простой счётчик вида i++, пусть тикает. При помощи TTimer можно отследить среднее время между приращениями. Потом посчитать количество приращений, и буте счастье. Другой вопрос, что Винда потокау выделяет всякий раз разное время, тут возможна ошибка.
:) немножко не то. Так придется росчитывать на то что ОС переключится на другой поток, что может и не произойти в течении длительного времени и пройдет очень много тактов процессора.
В моем варианте если при выполнении нашего потока не произойдет переключения на другой, то все будет гладко, если такое произойдет и подпрограма задержки провтыкает окончания милисекунды, она сразу же завершится при передаче ей управления (ну не сразу а после читания количества тактов)
В твоем случае она будет крутится в цыкле пока счетчик в другом потоке не добежыт до нужного значения.
Но думается мне что ето все делать гиморно и должны быть готовые решения.
Мой вариант и правда содержит много оговорок. Я исходил из того узконишевого предположения, что для одинаково сложных задач система выделяет примерно равные промежутки времени. Мой способ на самом деле плох донельзя. Его нельзя использовать. Должно быть готовое решение, наверняка оно есть.
Используй:
QueryPerformanceFrequency
и
QueryPerformanceCounter
это максимум, что можно выдавить из windows
QueryPerformanceFrequency
и
QueryPerformanceCounter
это максимум, что можно выдавить из windows