Такой вот вопрос: Повесит ли все нафиг поток c LOW_REAL_TIME_PRIORITY, запущенный на многопроцессорном компе, который станет поллить переменную как например while(!CallNow);? Ну, мне кажется очевидным ответ "нет", но вот совсем не очевидно, как это скажется на остальных процессах, которыми занимался раньше этот процессор? Есть ли в DDK средства, которые могли бы полностью "освободить" данный процессор под запускаемый поток(вообще, корректен ли такой вопрос?). Мне кажется он корректным, поскольку, например, есть такой параметр у объекта прерывания как KAFFINITY, который, как я понимаю, определяет каким процессором будет обрабатывться это прерывание. И если процессор будет занят реал-тайм потоком, он не сможет обрабатывть некоторые прерывания, а это типа плохо и все такое
Мда, синхронизация типа while(!CallNow) это рулез полный... Не завидую я пользователям твоего драйвера, ой как не завидую... Как говорят на udaff.com, аффтар [вырезано цензурой].
Да хватит прикалываться! Вопрос скорее теоретический, это типа не статья и все такое В винде как я понимаю, для подобных целей предусмотрены Timers, но если тимерс как-то меня не устроят - можно будет и к таким, "кривым" средствам прибегнуть
ubil Кажется Intel выпускает многоядерные процессоры поддерживающие виртуализацию - может на таком процессоре попробывать полностью захватить ядро (в отдельной ОС), и использовать его только для упомянутого тобой цикла? Вообще чего ты хочешь добиться я пока неуловил, если надо обрабатывать изменение переменной - для этого гораздо лучше события использовать, или как более "реактивный" метод - брякпойнт на адрес или страницу.
aplet С очень большой частотой мне скорее всего надо будет "беспокоить" порт(например, мониторить состояние линий LPT). А с переменной - это уже немного другая ситуация: Например нужно когда возникант прерывание "сказать" висячему потоку возобновить работу. Это можно сделать и с помощью событий, но только если понизить IRQL прямо в прерывании Но если при работе такого драйвера, запустить фильмец, например, проверку Касперским устроить.. Кароче это не совсем стабильно работает. Вот тут и возникла идея поллить переменную. Но поток должен быть REAL-TIME, в протианом случае может случиться так, что ждать возобновления потока после окончания прерывания придется сильно долго(до 1 секунды даже иногда). И тут наконец возникает идея для потока использовать отдельный проц... Но, надо еще с таймером попробовать сделать. А в чем заключается этот "реактивный" метод?
ubil Ничего особенного этот метод не представляет собой - просто отладочный механизм, позволяющий перехватывать изменения в переменных что называется real-time (соответсвенно поток занимающийся модификацией переменной будет грубо прерван). Не уверен что это как-то соотносится с твоей задачей. Если это ты делаешь для себя лично - имеет смысл присмотреться к QNX и ей подобным осям (DOS!), окна просто не предназначены для моментальной реакции, или приоритетной обработки очень частых событий.
Для обработки прерываний можно использовать DPC, а там IRQL=DISPATCH_LEVEL и можно использвать KeSetEvent. Для выполнения коротких операций на PASSIVE_LEVEL существует IoQueueWorkItem. Для быстрой синхронизации в мультипроцессорных системах есть спинлоки. Короче не страдай фигней, а почитай книжку по программированию драйверов. ubil Имхо если ты пытаешся обрабатывать прерывания в РЕАЛЬНОМ времени, то винда тебе не подходит.
Ms Rem Я читаю книги, только вот так получилось, что я начал с w2kdriverbook и она стала для меня самой "родной". В общем, я для себя наконец уже понял, что книгу Уолтера Ония тоже стоит проработать. Я пробовал и DPC использовать, но это тогда как-то не помогло. Можно будет еще раз попробовать(тепрь точно удостоверившись, что поток работает с LOW_REAL_TIME_PRIORITY). А вот с Work Items 100пудово надо будет разобраться. Уолтер про них написал... Кстати, какие есть еще книги? Желательно уровнем >= "Programming the Microsoft WDM"?
ubil Согласно маниалам Microsoft по написанию драйверов - работа любого драйвера, может быть прервана потоком с более высоким приоритетом. (это официально) Реально в многопроцессорной системе всегда может наступить исключение допустим по ошибке памяти (имеется ввиду ошибка четности проще говоря аппаратный сбой в памяти) которая прервет выполнение любого потока. В многопроцессорной системе выполнить ассемблерную инструкцию cli (запрет прерываний) можно только на одном процессоре и следовательно система не зависнет, другое дело запретить прерывания через контроллер прерываний, вот тогда ты получишь полную власть (конечно если не возникнет исключение) над компьютером.
Ладна, как появится возможность протестить на такие вещи многопроцессорный комп - расскажу Типа экспериментальное подтверждение не помешает
