Таймер программно

← →
KilkennyCat © (2004-11-08 02:05) [40]

> Defunct © (08.11.04 02:01) [38]

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

← →
Defunct © (2004-11-08 02:13) [41]

KilkennyCat © (08.11.04 02:04) [39]
От процессора зависит, сколько команд для конкретного потока он успеет обработать за отведенное время.

Вот если взять диаграмму [37] и выполнить на двое более быстром процессоре, будет уже такая картинка:

^
|XЯHHEXXXXЯHHEXXXЯHHEXXXЯ
____________________________

Ну а если убить ваш поток с циклом - получим свободное процессорное время.

Конечно же то что я здесь рисую, очень упрощено, я не учитываю возврат управления Ядру процедурой Sleep.

> выполняющая просто одну тупую операцию, будет работать одинаково на пне 166 и на пне-4 3 ГГц?

Нет конечно же нет, от скорости процессора зависит, еще раз повторюсь, количество команд выполненных в секунду. А системный таймер работает-то одинаково.

← →
Ihor Osov'yak © (2004-11-08 02:13) [42]

2 [29] KilkennyCat © (08.11.04 01:09)

вопрос спорный. Собственно таймер, дергающий соотв. аппаратное прерывание действительно не может быть запрограммирован на довольно высокую частоту, следовательно дискретность отсчета высокой быть не может.. Но с другой стороны - в процессорах начиная c Pentium есть такая вещь, как TSC - time stamp counter - обычный 64 битный регистр, считающий каждый тик тактовой частоты процессора и доступный по чтению (ОС может запретить доступность для пользовательского режима, и это, кажется, так и делается). С его помощью можна делать довольно точные временные задержки.. На уровне нескольких тактов процессора. Или измерять довольно точно интервалы времени.. А относительно таймера в классическом понимании - не уверен..
С другой стороны мs все же на уровне апи ядра дискретность временных интервалов установила в 100 наносекунд. Насколько точно будут срабатывать всякие KeSetTimer - не интересовался.. То ли там действительно есть такая точность ( что вряд ли - так как точный подвод можно сделать наверное только на основании чтения в цыкле TSC на завершальных стадиях ожидания ценой блокировки остальных потоков - а это маловероятно), то ли МS просто сделала запас на развитие аппаратной платформы - не могу сказать..

Но вот что измерения интервалов на основании TSC - довольно точное - то это таки факт.. Мне приходилось делать измерение некоторых интервалов времени в драйвере -фильтре с помощью KeQueryPerformanceCounter (которая в конечном итоге читает TSC) - то похоже на то, что действительно получается довольно точный результат..

← →
KilkennyCat © (2004-11-08 02:23) [43]

ну, вообщем, все и вся еще раз доказали, что серъезные задачи решаются серъезными вещами. Я попозже покопаюсь во всем этом, ветку сохранил, и попытаюсь разобраться. Очень бы хотелось сделать возможным создание многоканального мониторинга быстрых процессов... интересно как и с моральной точки зрения, так и с материальной.

> Ihor Osov"yak © (08.11.04 02:13) [42]

TSC - я ведь слышал об этом... да забыл. Спасибо, за напоминание.

← →
Ihor Osov'yak © (2004-11-08 02:29) [44]

2 [27] GuAV © (08.11.04 01:06)

>ThreadId тот же. с GetThreadContext что делать - не знаю...

я имел ввиду ThreadId. ThreadContext - оговорка..

... судя с Ваших слов моя версия правильная. Возьму во внимание, со временем наверно найду где-то подтверждение в соотв. литературе..

← →
Ihor Osov'yak © (2004-11-08 02:35) [45]

2 [43] KilkennyCat ©

помнится, также в контекте пентиум 2 про проскакивало также сообщение о таймере, встроенном в ядро процессора - local APIC - не знаю, сохранилась ли эта фишка в PIII и далее, а также как дела с этим в K7 - я в общем то не специалист в современном аппаратном обеспечении, так, иногда прохожу мимо :-)

← →
Defunct © (2004-11-08 02:37) [46]

Ihor Osov"yak © (08.11.04 02:13) [42]

ЗЫ, а по TSC кажется нет механизма генерации аппаратного прерывания при переполнении. так что его можно использовать в целях таймера только либо в совокупности с отладочным режимом либо просто опросом. (от проца будет такой таймер сильно зависеть, а добавить сюда всякие нововведенные D.O.T. (Dynamic Overclocking Tech") так вообще получается никакой точности (даже если синхронизировать по IRQ0).

← →
KilkennyCat © (2004-11-08 02:43) [47]

> Ihor Osov"yak © (08.11.04 02:35) [45]

и это самое ужасное... мне и так хватило головной боли сидеть в москве неделю, когда выяснилось, что прога, написанная для амд, не живет на интелле...

← →
KilkennyCat © (2004-11-08 02:47) [48]

> Defunct © (08.11.04 02:37) [46]

разве такты процессора менее точны? на мой взгляд, чем больше частота работы электроники, тем выше стабильность.
Опрос нечем не хуже прерывания, меня так даже наоборот учили - стараться самому знать, когда опрашивать, а не дожидаться прерывания.

← →
Ihor Osov'yak © (2004-11-08 02:54) [49]

2 [46] Defunct © (08.11.04 02:37)

> а по TSC кажется нет механизма генерации аппаратного прерывания
а я что, утверждал что есть?
это я намек на способность внимательно читать.

>при переполнении
64 бита довольно трудно перемолнить, имхо..

> от проца будет такой таймер сильно зависеть, а добавить сюда всякие нововведенные D.O.T.

если посмотреть внимательно на декларацию KeQueryPerformanceCounter, то можно заметить еще один возвращаемый параметр - OUT PLARGE_INTEGER PerformanceFrequency - количество тиков в секунду на момент выполнения вызова функции - это не тему разных тактовых частот.. А относительно всяких D.O.T. - то на время измерения их вполне можно и отключить.

← →
Ihor Osov'yak © (2004-11-08 02:56) [50]

> меня так даже наоборот учили - стараться самому знать, когда опрашивать, а не дожидаться прерывания.

вполне может быть - и даже при определенных обстоятельствах оптимальние - ведь обработка прерывания довольно ресурсоемкая операция..

← →
KilkennyCat © (2004-11-08 02:58) [51]

> Ihor Osov"yak © (08.11.04 02:54) [49]

даже если бы PerformanceFrequency не было, разные тактовые частоты можно и предварительной юстировкой определить...

← →
Defunct © (2004-11-08 02:59) [52]

KilkennyCat © (08.11.04 02:47) [48]

> разве такты процессора менее точны?

Знаете что такое D.O.T.?
Это, например, у вас процессор P4-3.0, а в виндовсе частота процессора пляшет от 2.6Ghz до 3.8Ghz взависимости от загруженности процессора. Ну и что вам даст подстчет тактов скажем 3.6 Гтактов, это больше секунды или меньше или равно?
(Мы даже еще на другой комп программу переносить не будем, а она будет уже неправильно работать)

> на мой взгляд, чем больше частота работы электроники, тем выше стабильность.

no-comment ;>
было бы все так просто уже б давно были процессоры с бесконечной частотой, но вот есть одна маленькая проблемка - чем выше частота, тем меньше стабильность электроники из-за вихревых токов (приходится усовершенствовать технологический процесс, понижать напряжение питания и т.д., короче масса проблем).

> Опрос нечем не хуже прерывания,
плохо вас учили. Таких учителей надо наказывать.
Прогр. опрос - 1-ое поколение машин.
Прерывания - 3-е поколение машин.

← →
Defunct © (2004-11-08 03:08) [53]

> это я намек на способность внимательно читать.
ок

> 64 бита довольно трудно переполнить
логично, ~2^32 секунд ;>

> PerformanceFrequency
не доверяю я таким штукам. погрешность очень высока.

> А относительно всяких D.O.T. - то на время измерения их вполне можно и отключить
Согласен.

imho все же лучше не использовать виндовс и ее программные средства для организации задержек с точностью менее 10ms.

← →
KilkennyCat © (2004-11-08 03:09) [54]

> Defunct © (08.11.04 02:59) [52]

я не знаю про ДОТ, не сталкивался. Но предполагаю, что изменение частоты процессора изменяется по вполне жестким законам, отследить или менять которые вполне по силам.

гм... не путайте стабильность различную... разве я говорил о стабильности самих электрических процессов? Почему в электронных часах не используют генератор с частотой 1 Гц, хотя это удобно?

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

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

← →
Defunct © (2004-11-08 03:24) [55]

> я не знаю про ДОТ, не сталкивался. Но предполагаю, что изменение частоты процессора изменяется по вполне жестким законам, отследить или менять которые вполне по силам.

Да по вполне жестким законам китайских разработчиков:
- Загрузка процессора 100% - повышаем частоту плавно.
- Загрузка процессора 0% - снижаем частоту плавно.

какой же тут четкий закон для динамики?

> гм... не путайте стабильность различную... разве я говорил о стабильности самих электрических процессов? Почему в электронных часах не используют генератор с частотой 1 Гц, хотя это удобно?

Я вам объясню. Потому что RC-цепочка для обеспечения 1 Гц потребует электролит, и соответственно часы увеличатся в размере. Вот и взяли за основу частоту 32768 Гц для часов, которая обеспечивание маленьким кварцевым резонатором.

Выражайтесь нормально, потому что эта фраза
> на мой взгляд, чем больше частота работы электроники, тем выше стабильность.
трактуется однозначно.

> Мои учителя, извините, намного умнее Вас.
Как вы определили? Не потому ли, что они не заходят на этот форум? ;)

> Я ведь не утверждал, что они абсолютно запрещали ипользовать прерывания.
Этого вы не утверждали, но зато сказали

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

В режиме прерываний программа прерывается ровно в момент происхождения события, а при программном опросе вы можете одно из двух либо пропустить событие либо потратить процессорное время на ожидание события.

> Тем более, что они работали не только с ПК, но и с другими представителями вычислительной техники...
С калькуляторами?

← →
KilkennyCat © (2004-11-08 03:48) [56]

> Defunct © (08.11.04 03:24) [55]

как однако вы все извращаете... ну ладно, я тоже поизвращаюсь.

я не понимаю плавных понижений частоты. или китайцы используют аналогыве процессоры?

можно сделать RC-цепочку и без электролита. можно и LC. но это не суть важно. почему использована частота и в кварце 32768 Гц? из-за размеров? нет, могу подарить малюсенький кварц на 1 кгц.

фразы трактуются по-разному. мы обсуждали точность работы таймера.

при чем здесь этот форум и то, что мои учителя умнее? Как мне это трактовать? Что я считаю, что все сюда ходящие - глупее? нет, не считаю. Просто они стояли у основ электроники. Не хватали поверхностно, и знания их фундаментальны. Не думаю, что Ваш возраст равняется ихнему.

Да, я выразился, что опрос предпочтительнее прерывания. И сказал, что меня так учили. Поясните мне, почему я не прав, а заодно и ложно мое обучение, а не увольняйте моих учителей :) Хотя, они вообще-то и так уже на пенсии.

о, вот и обяснение...

> В режиме прерываний программа прерывается ровно в момент
> происхождения события, а при программном опросе вы можете
> одно из двух либо пропустить событие либо потратить процессорное
> время на ожидание события.

замечательно. может, Вы все-таки соблаговолите расписать весь процесс прерывания, а заодно для нескольких устройств, скажем так, для двадцати. Люблю я многоразрядные шины... лучше, пущай у нас на компе будет 32 устройства. Воткнуты все в PCI. Как тут прерывания поработают? только подробно, пожалуйста, с учетом всех действий процессора, по сохранению того, что до прерывания было и восстановлением после.
И какое время на ожидание события? Вы же, если придираетесь к словам, то придирайтесь дальше - я ведь написал "старатся знать, когда надо опрашивать".

С калькуляторами? Любезный, ежели б Вы в те времена сумели бы разработать калькулятор, я бы снял перед Вами шляпу.

И вообще, Ваша агрессивность - это просто попытка скрыть что-то... Может, просто боитесь показаться в чем-то недостаточно образованным?

← →
KilkennyCat © (2004-11-08 03:54) [57]

P.S. руководствуясь поговоркой, что спорят только подлецы и дураки (дурак - потому что проспорит, но все равно спорит, подлец - знает, что прав, но все равно спорит), спорить дальше не буду. Не хочу оказаться подлецом.

← →
Defunct © (2004-11-08 04:58) [58]

Эх.. уйдет эта ветка похоже в потрепаться..

> фразы трактуются по-разному. мы обсуждали точность работы таймера.

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

> при чем здесь этот форум и то, что мои учителя умнее? Как мне это трактовать?
трактуйте как угодно.
я же вас не спрашивал как мне трактовать это:

"Мои учителя, извините, намного умнее Вас",

более того могу сказать, что у меня были учителя глупее Вас.

> Просто они стояли у основ электроники. Не хватали поверхностно, и знания их фундаментальны. Не думаю, что Ваш возраст равняется ихнему.

Скажите, вы вообще на какой волне? Я говорил об архитектуре вычислительных систем, именно там есть понятия режим программного опросаи режим прерываний, в электронике этих понятий нет. Я ничего не имею против ваших учителей как светил электроники. Но скажите почему вы вспомнили о них применительно совсем к другой области науки?

> Вы все-таки соблаговолите расписать весь процесс прерывания, а заодно для нескольких устройств, скажем так, для двадцати.

Скажем так.
В теории есть 3 метода организации контроллера прерваний.
1. Централизованный (микросхема/ы КПП).
2. Децентрализованный (дейзицепочка).
3. Гибридны (комбинацие первых двух).

В x86 применяется централизованный двухуровневый контроллер. Распишу по приоритетам 0-наивысший приоритет, дальше IRQ расположены по-убыванию:

IRQ0 - таймер
IRQ1 - клава
IRQ2 -> cascade -> (сюда подключен второй уровень)
< cascade >
IRQ8 - PCI
IRQ9 - PCI
IRQ10 - PCI
IRQ11 - PCI
IRQ12 - PCI
IRQ13 - FPU
IRQ14 - HDD
IRQ15 - HDD
[IRQ16] - опционально
.. - опционально
[IRQ23] - опционально
</cascade>
IRQ3 - com2/4
IRQ4 - com1/3
IRQ5 - ISA или lpt2
IRQ6 - Если не изменяет память - для используется для реген. памяти.
IRQ7 - Lpt1

Централизованный контроллер имеет место в архитектуре x86 и работает так:
1. От внешних устройств (ВУ) приходят запросы на прерывание (IRQ). Контроллер приоритетных прерываний (КПП) складывает по Or все запросы на прерывание (IRQ) и выдает процессору сигнал INT.
2. Процессор при получание сигнала INT завершеет текущую команду и приостанавливает выполение текущей программы, считывает с КПП вектор самого высокоприоритетного прерывания (приоритет определяется по IRQ, для централизованного контроллера приоритеты фиксированы) сохраняет текущий адрес CS:IP и регистр состояния программы Flags/FlagsD и переходит по адресу вектора. 3. Обрабатывается событие.
5. Контроллеру прерываний посылается сигнал EndOfInt, соответственно выключается (переводится в 0) самый приоритетный сигнал IRQ.
4. Восстаналивается сохраненный адрес прерванной программы, и регистр состояния программы.

Ну и работаем себе дальше, только событие уже обслужено. Не надо ничего ждать, ничего опрашивать.

> только подробно, пожалуйста, с учетом всех действий процессора, по сохранению того, что до прерывания было и восстановлением после.

Могу конечно, рассказать подробно, но только если вы хотите качественный ответ, то дучше подождать до завтра. Ибо уже 4 часа ночи, да и рисунки тут очень трудно рисовать.

> С калькуляторами? Любезный, ежели б Вы в те времена сумели бы разработать калькулятор, я бы снял перед Вами шляпу.
Значит я угадал.
Очень хочу спать, хотел и здесь вам возразить, но уж ладно как-нибудь потом, а то в голове просто кашмар какой-то (ни одной мысли).

> И вообще, Ваша агрессивность - это просто попытка скрыть что-то...
Возможно. А возможно так действует уходящее воскресенье.

> Может, просто боитесь показаться в чем-то недостаточно образованным?
Да нет, я наоборот могу сам сказать, что толком ничего не знаю. И совсем не стыжусь этого.

PS: допускаю, что в этом посте могут быть логические несоответствия.. пора спать..

← →
Defunct © (2004-11-08 05:02) [59]

Удалено модератором

← →
KilkennyCat © (2004-11-08 05:10) [60]

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

А почему воскресенье уходящее? Парздник же еще будет... так что сегодня - выходной.

← →
KilkennyCat © (2004-11-08 05:13) [61]

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

← →
Defunct © (2004-11-08 05:14) [62]

KilkennyCat ©

Я наконец-то понял что ваши учителя вам говорили, но вы этого похоже не поняли.

Если выбросить первую часть фразы:
> "Опрос нечем не хуже прерывания,"
выбросить так далеко как только можно.

то вторая часть фразы получается впоне корректой, и в ней как раз говорится про режим прерываний.

меня так даже наоборот учили - стараться самому знать, когда опрашивать, а не дожидаться прерывания.

Как можно узнать когда опрашивать?
ответ очевиден:
по факту возбуждения прерывания.

← →
Defunct © (2004-11-08 08:19) [63]

> что есть три способа получения информации от устройств - прерывание, опрос и прямой доступ к памяти.

да все вы правильно считаете именно 3 способа. Мы просто не затрагивали DMA

> А почему воскресенье уходящее? Парздник же еще будет... так что сегодня - выходной.

Дык, в нашей стране Янукович пока Президентом не стал. Вот как будет он президентом так и к нам праздник вернется. А пока 7 Ноября обычный будний день.

> а вообще, спешка и эмоции в данных случаях - вредная вещь.
угу

← →
KilkennyCat © (2004-11-08 10:18) [64]

> Defunct © (08.11.04 05:14) [62]

хорошо, ну а предположим такой вариант: данные, которые я должен получать, мне нужны только тогда, когда я их забираю. То есть, я читаю какой-либо порт, обрабатываю данные, и вывожу на порт команду внешнему устройству на обновление. Выгодно ли тогда прерывание? С точки зрения оптимальности и простоты программирования?

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

З.Ы. Я не спорю, я спрашиваю :)

← →
Cobalt © (2004-11-08 12:57) [65]

2 KilkennyCat © (08.11.04 10:18) [64]
> Выгодно ли тогда прерывание? С точки зрения оптимальности и простоты программирования?
1) Скорости жестко задаются, как правило, в электронике. В PC - скорость - несколько размытое понятие, т.к. он многозадачный.

Смотри - Прерывание:
* 1) Принимаешь сигнал от порта, читаешь из него.
2) Посылаешь в него команду пересылки новых данных
* 3) Принимаешь следущие данные. И т.д.

Опрос:
* 1) Принимаешь сигнал от порта, читаешь из него.
2) Посылаешь в него команду пересылки новых данных
3) Принимаешь следущие данные. (какова задержка между 2 и 3? в PC очень трудно гарантировать. И эту задержку тебя все остальные должны ждать? А сколько у тебя будет таймаут?)

* прерывание

← →
Piter © (2004-11-08 14:19) [66]

Ihor Osov"yak © (07.11.04 22:54) [19]
так как отложенный вызов процедуры таймера вероятнее всего делается где-то в глубине getmessage или ему подобных

Цитата:

"When you specify a TimerProc callback function, the DispatchMessage function simply calls the callback function instead of the window procedure"

Defunct © (08.11.04 1:08) [28]
Точность прораммного таймера 100нс в Windows не может быть достигнута не только из-за неизвестного интервала задержки между переключениями потоков, но и из-за ограничений аппаратных средств системы: аппаратный системный таймер всего один, работает всегда с одинаковой частотой, которая не превышает 1.13Mhz (мининимально возможный гарантированный временной интервал 1mks)..

по-моему, очень логично. Если все сказанное правда - я не понимаю, почему Ihor Osov"yak пишет:

Ihor Osov"yak © (08.11.04 0:55) [26]
во вторых еще и потому, что вы несете ахинею.

← →
KilkennyCat © (2004-11-08 14:27) [67]

> Cobalt © (08.11.04 12:57) [65]
> 3) Принимаешь следущие данные. (какова задержка между 2
> и 3? в PC очень трудно гарантировать. И эту задержку тебя
> все остальные должны ждать? А сколько у тебя будет таймаут?)

в большинстве случаев я могу знать скорость реакции устройства на запрос данных. Почему меня нельзя ждать? Предположим, я просто регистрирую состояние какого-лтбо объекта через определенный промежуток времени. Мне не важно, что было в этом промежутке, мне важно состояние в момент опроса. Ну, практическая задача: синхронизация программных часов по внешнему высококоточному таймеру. Причем, программа делает что-то очень важное, ее нельзя дергать, то есть, приоритет ее основной работы выше. Есть возможность - она синхронизируется. Нет - извините. В случае прерываний, получается, что она должна все равно отвлечься, чтобы сказать - не до тебя сейчас, занята я.

← →
GuAV © (2004-11-08 14:27) [68]

Piter © (08.11.04 14:19) [66]
DispatchMessage
Cпасибо. Не знаю почему я этого не нашел :(

ааааааа!

слушайте, тогда просто скажите, в каких случаях, на ваш взгляд, требуется опрос, в каких прерывание? :)

2 [66] Piter © (08.11.04 14:19)
>так как отложенный вызов процедуры таймера вероятнее всего делается где-то в глубине getmessage или ему подобных
>When you specify a TimerProc callback function, the DispatchMessage function simply calls the callback function instead of the window procedure

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

> почему Ihor Osov"yak пишет:
>>во вторых еще и потому, что вы несете ахинею.

хотя бы потому, что человек в упор не замечает, что я говорю об дистретности программирования временных интервалов, а не об точности.
а во вторых, из за наличия уж многих шедевров вида
"который всего один и неспособен выдавать синхроимпульсы с частотой 10Mhz для всех потоков.." Интересно, что это за ноу-хау в архитектуре, способное передвать "синхроимпульсы" потокам? И какова физика этого ноу-хау.
Зы. я уже молчу о продемонстрированном незнании тематики о приоритетах потоков..

2 [69] KilkennyCat © (08.11.04 14:34)

>слушайте, тогда просто скажите, в каких случаях, на ваш взгляд, требуется опрос, в каких прерывание? :)

а вот это уже зависит от архитектуры конкретного решения. Вот, возьмем к примеру шину USB. Синхронизация общения между хост-контролером и устройствами, подключенными к USB шине идет как раз способом опроса, а не прерываний...
Или та же клавиатура, но внутри.. Опрос клавиш все же идет сканированием контролером клавиатуры. Прерывания - это уже на системной плате, после того как пришел сигнал от конролера клавиатуры.. То есть в случае клавиатуры имеем комбинацию - опрос и прерывание. Опрос на уровне дешевого и простого контролера, входящего в состав клавиатуры, и прерывание - это уже когда нужно привлечь внимание дорогого и постоянно занятого ЦП в случае реального ввода кода нажатой клавиши..

Ihor Osov"yak © (08.11.04 15:25) [70]
я рассматривал случай, когда таймер SetTimer получает нулевой хендл окна. То есть здесь говорить о процедуре окна не следует

а кто говорит о процедуре окна? Вы предположили, что вызов TimerProc происходит где в недрах GetMessage, а я говорю, что он происходит где-то в недрах DispatchMessage, что логично, ибо приложение может и не пользоваться GetMessage, а использовать PeeMessage :)

2 [72] Piter © (08.11.04 16:05)

>а кто говорит о процедуре окна?

блин, ну хоть то, что цитируем сами, читать то можно?

см. [66] Piter © (08.11.04 14:19)
>"When you specify a TimerProc callback function, the DispatchMessage function simply calls the callback function instead of the window procedure"

Ihor Osov"yak © (08.11.04 16:32) [73]

А, ты про это. Ну ладно... все равно не понимаю о чем мы говорим. Я своим постом хотел сказать одно - что вызов TimerProc происходит при вызове DispatchMessage - вот и все. Ты предполагал, что при вызове GetMessage или подобном, я же уточнил. Это все, что я хотел сказать :)

Удалено модератором

KilkennyCat © (08.11.04 14:34) [69]

> слушайте, тогда просто скажите, в каких случаях, на ваш взгляд, требуется опрос, в каких прерывание? :)

Ок.
Для того чтобы сказать в каких случаях следует использовать опрос, а в каких прерывание, достаточно рассмотреть преимущества и недостатки обеих режимов.

1. Режим программного опроса:
преимущества:
- простота реализации.
- как следствие простоты - отсутствие дополнительных схемных решений.
недостатки:
- потеря процессорного времени на ожидание событий
- возможность потери события в случае опроса нескольких устройств.

2. Режим прерываний
преимущества:
- возможность отделения операций ввода/вывода от выполнения основной программы
- запуск подпрограммы обслуживания ввода/выода по факту появления и/или требования данных ВУ.
недостатки:
- сложность реализации.
- как следствие необходимость использования дополнительных схемных решений.

Итак, программный опрос выгодно использовать в дешевых устройствах с простым процессором.

Во всех остальных случаях целесообразнее применять режим прерываний.

> хорошо, ну а предположим такой вариант: данные, которые я должен получать, мне нужны только тогда, когда я их забираю. То есть, я читаю какой-либо порт, обрабатываю данные, и вывожу на порт команду внешнему устройству на обновление. Выгодно ли тогда прерывание?

Конечно, если спецификация устройства с которым вы работаете способна обеспечивать хранение данных сколь угодно долго тогда безусловно можно обойтись опросом.

Но как правило ВУ неспособны долго хранить данные. Давайте рассмотрим на примере всем известного COM порта:

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

В режиме же прерываний, сам COM порт просигнализирует процессору о приходе байта, таким образом достаточно будет просто сразу взять и прочитать этот байт, потеря данных исключается и нет никакого ожидания.

мне вот тоже кажется, что Ihor Osov"yak ругался и обзывал ламером Defunct"а из-за утверждения, с которым сам потом и согласился. Я про:

Ihor Osov"yak © (07.11.04 19:34) [6]
ну, еще бы на уровень 0 прыгнуть, там отсчет доступен с дискретностью 100 наносекунд :-).
Только вот потом проблема, что все достигнутая точность уйдет коту под хвост вследствии некоторой непрогнозированности задержки на переключение потоков

ни слова о неточности самого аппаратного таймера

Ihor Osov"yak © (07.11.04 22:16) [13]
я не говорил, что речь идет о системе на базе 8086/8088. Что это не так, можно было бы догадаться хотя бы по упоминанию режима ядра. То есть, что речь идет как минимум о 386

эта фраза я так понимаю подразуемвает то, что в 386 отсчет временных интервалов точнее. При этом фраза:

Defunct © (08.11.04 0:35) [24]
системный таймер не изменялся. как был 1.3Mhz или точнее сказать 1.13Mhz так и остался

не была опровергнута. Более того, с ней вроде даже как согласились:

Ihor Osov"yak © (08.11.04 2:13) [42]
собственно таймер, дергающий соотв. аппаратное прерывание действительно не может быть запрограммирован на довольно высокую частоту

То есть, Ihor Osov"yak нигде не утверждал, что можно отсчитать точно промежутки времени по 100нс, но как минимум давал понять, что в современных компьютерах это можно сделать куда точнее, чем в 8086/8088 компьютерах. А, видимо, это не так. Таймер как был так и остался.

Спор то вообще ни о чем. Ihor Osov"yak говорил, что нельзя отсчитать точные промежутки времени из-за переключения потоков и из-за недостаточного приоритета пользовательских потоков по сравнению с потоками ядра. А Defunct говорит, что даже если все было бы в реальном времени, то отсчитать такие промежутки времени все равно нереально из-за ограничений аппаратного таймера.

Я так понял вашу дискуссию.

P.S. А насчет несдержанности Ihor Osov"yak - это да. Я тоже был удивлен его поведением, когда кто-то пытается доказать, что он не прав, искры летят налево и направо. Прямо удивительно для взрослого человека...

Defunct © (08.11.04 02:37) [46]
При частоте прочессора на переполнение потруется порядка 600, для 3 ггц 200. Долго ждать придется

2 moderator

просьба восстановить пост [24]. В нем была приведена ссылка на источник, где можно прочитать об организации системного таймера в чипсетах под P4.

Если там и были грубости, то это возможно была просто опечатка.

Таймер программно Найти похожие ветки