При вызове функции WaitForSingleObject (или других Wait...) с минимальной задержкой 1мс, возврат происходит через ~15мс.

Запоминается время до вызова и считывается после. В результате получаю 15-20мс, и на одноядерном Целероне 666 и на двух ядерном 1800 Пне.

Повышение приоритета ожидающего процесса и потока до критического не даёт ни какого результата.

Как ускорить срабатывание?

_>При вызове функции WaitForSingleObject (или других Wait...) с минимальной задержкой 1мс, возврат происходит через ~15мс.
_>Запоминается время до вызова и считывается после.

Прежде всего, проверь хендл, на котором ждёшь. Он должен быть в сигнальном состоянии. Если это так, то твои замеры — чушь собачья, потому что поток может быть прерван в любое время, и его приоритет тут не всегда влияет. Пройдись отладчиком и убедись, что функция WaitForSingleObject(hHandle, 1) возвращается почти моментально. Если это реально не так, значит что-то не то с хендлом.

Благодарю за ответ!

Почему он должен быть в сигнальном состоянии? Событие не поступает (пока на данном этапе), просто вызывается WaitForSingleObject(hHandle, 1) и засекаются времена. Получается 15-20мс.

_>Событие не поступает (пока на данном этапе), просто вызывается WaitForSingleObject(hHandle, 1) и засекаются времена. Получается 15-20мс.

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

Здравствуйте, _alecs, Вы писали:

_>При вызове функции WaitForSingleObject (или других Wait...) с минимальной задержкой 1мс, возврат происходит через ~15мс.

Это нормально. Переход в режим ожидания — добровольная отдача кванта выполнения задачи. А квант времени у нас 10 или 15 мс на настольных системах. В принципе, в определенных условиях управления могут вернуть раньше, из-за завершения какой-нибудь приоритетной операции ВВ. Если в просто ждете события илди там таймера к примеру — потеряете не меньше кванта. Принцип прост — ж..у поднял, место потерял. Таким образом, мои поздравления — вы определили длительность кванта.

TC>Это нормально. Переход в режим ожидания — добровольная отдача кванта выполнения задачи. А квант времени у нас 10 или 15 мс на настольных системах. В принципе, в определенных условиях управления могут вернуть раньше, из-за завершения какой-нибудь приоритетной операции ВВ. Если в просто ждете события илди там таймера к примеру — потеряете не меньше кванта. Принцип прост — ж..у поднял, место потерял. Таким образом, мои поздравления — вы определили длительность кванта.
Квант времени исполнения — порядка 30-60 мсек, на разных виндах (серверных и обычных) и в зависимости от foreground кванты разные. А автор определил разрешение системного таймера.

Здравствуйте, _alecs, Вы писали:

_>При вызове функции WaitForSingleObject (или других Wait...) с минимальной задержкой 1мс, возврат происходит через ~15мс.
_>Запоминается время до вызова и считывается после. В результате получаю 15-20мс, и на одноядерном Целероне 666 и на двух ядерном 1800 Пне.
_>Повышение приоритета ожидающего процесса и потока до критического не даёт ни какого результата.
_>Как ускорить срабатывание?

Попробуй timeBeginPeriod(1)

Setting a higher resolution can improve the accuracy of time-out intervals in wait functions. However, it can also reduce overall system performance, because the thread scheduler switches tasks more often.

(c) MDSN

и обсуждение на форуме sysinternals

А>Квант времени исполнения — порядка 30-60 мсек, на разных виндах (серверных и обычных) и в зависимости от foreground кванты разные. А автор определил разрешение системного таймера.

30-60 — это для серверных платформ, там обычно делают кванты длинные — по несколько тиков таймера. Для настольных — как раз 15мс характерная величина. И автор определили именно длительность кванта в своей системе, ведь он мерил промежуток времени между потерей управления и возвращением его обратно, а эта величина будет как раз кратна кванту ( если конечно не ждать окончания приоритетной операции ВВ ).

TC>30-60 — это для серверных платформ, там обычно делают кванты длинные — по несколько тиков таймера. Для настольных — как раз 15мс характерная величина. И автор определили именно длительность кванта в своей системе, ведь он мерил промежуток времени между потерей управления и возвращением его обратно, а эта величина будет как раз кратна кванту ( если конечно не ждать окончания приоритетной операции ВВ ).
Ненене...Для начала надо разобраться с терминологией. Го сюда http://technet.microsoft.com/en-us/sysinternals/bb963889.aspx
Вся нужная инфа там заключена в предложении — "Three quantum units elapse every tick of NT's quantum-tracking timer, and a timer tick period is either 10 milliseconds or 15 milliseconds in length" и в табличке. Из чего делается вывод что квант — это абстрактная величина равная 1/3 периода системного таймера. Период таймера равен намеряным автором 15 мсек (15.625 мсек если быть точным) на SMP системе, так что квант — 5 мсек. Time slice, (т.е. кусочек времени который непрерывно исполняется поток, при условии отсутствия других потоков с более высоким динамическим приоритетом ) определяется исходя из приведенной далее таблички (смотрите табличку для 2к, а не для NT) и в workstation (т.е. в ХР) он от 30 мсек до 90 мсек для foreground приложений) а в серверных виндах — больше.

Возвращаясь к топике — ожидание с таймаутом закончится раньше кванта при очередном тике таймера (и соответственно вызове шедулера) если сейчас нету других потоков, которым требуется процессор. Подозреваю это как раз случай автора, и намерял он справочные 15 мсек- разрешение таймера . А вот еслибы бы он запустил в фоне другой поток который бы жрал CPU — тогда бы да — он бы намерял квант, который был бы больше тика системного таймера, согласно мутному описанию по сцылке что я дал.

Всех благодарю за ответы!

Остался только один вопрос, когда делаю тестовую прогу — создаю событие, запускаю WaitForSingleObject на 1 мс — всё отробатывает нормально, и быстро. Когда засекаю у себы в рабочем приложении (в нём потока три), один поток ждёт ответа от другого, вот здесь и возникают те самые ~15мс! В одном случае в тестовой проге (один поток) всё работает быстро в другом случае с задержками. Причём в рабочей программе, поток от которого ждут установки события находится в функции Wait... и не исполняется, основной поток ждёт ввода данных от пользователя. Непонятно пока в чём разница, и почему такое происходит...

Немного не так написал, если событие установленно то отрабатывает быстро. Но если событиене не установленно и срабатывает таймер, то таймер срабатывает с дискретом 12-16мс!

Как лучше отработать 1мс задержку — WaitForSingleObject( hEvent, 0) — в цикле?

_>Как ускорить срабатывание?
Перейти на ОС реального времени. Обычный Windows таковой не является.

Что в цикле WaitForSingleObject( hEvent, 0) сделать чтобы не сильно нагружать процессор? Имеются ли функции на подобие Sleep( 100мкс! ) или нет?

Я так понимаю, что ещё главное необходимо поднять приоритет процесса/потока чтобы во время отработки этой 1мс другой процесс/поток не забрал квант! Так? И какая вероятность того, что кто то может вклиниться?
Операция 'Передача данных в модуль' прервана.
Объект сообщивший об ошибки: Драйвер Com-порта
Описание ошибки: Нет связи с модулем, драйвер не смог передать данные в модуль.