Интересна такая вещь - сколько времени отнимает нить подвешанная WaitForSingleObject? И вообще принцип работы. Если я подвешал на WaitForSingleObject с INFINITE как идёт проверка? На каждый квант для нити? Если да то сколько проверка состояния займёт? Нужно максимально загасить активность управляющей нити до момента когда определённый участок отработает другая, но при этом дать понять что она отработала. Обычные средства синхронизации не годятся - слишком долго ждать возврата из синхронизирующих функций. На параллельном порту висит микроба и как она только подала признаки жизни - нужно тут же считывать, максимально что я могу позволить - дать время на глобальной переменной которую управляющая нить будет проверять по таймеру и тут вопрос либо как-то управляющую нить усыплять - пробуждать по другому контролирующему таймеру либо ей самой впасть в INFINITE на WaitForSingleObject пока читающая нить не отработает. Планируется работа в XP.
If the object's state is nonsignaled, the calling thread enters the wait state. It uses no processor time while waiting for the object state to become signaled or the time-out interval to elapse.
Ну дык в сабже сказано Прожорливость WaitForSingleObject а не прожорливость нити которая её вызвала. Т.е. у системы должен быть какой то низкоуровневый механизм проверки будить нить или нет, т.е. отработала нить которую ждут или нет. Или по таймеру или как-то прерыванием (? не пойму только пока как это можно сделать схемно, т.что рабочая версия - таймером) Вот как этот механизм работает и сколько он жрёт, чтобы определить давать наконец кванты ожидающей нити или нет - вот это и интересно. Мне нужно сигнал снимать в реальном времени, очень тут важно чтобы возможный перерыв был минимальным. Понятно, что лучше выполнять задачу бы в реальном режиме, но такие уж условия. Если переключения будут слишком частыми и надолго, прийдётся придумывать как-то через аппаратный независимый буффер.
а первой строкой в тексте? вообщем, WaitForSingleObject тоже ничего не делает - переводит нить в состояние WAIT и сообщает какому-то низкоуровневому обработчику хэндл этой нити и по какому поводу ее будить. Больше ничего. Если тебя интересует низкоуровневый обработчик, то никто кроме разработчиков из ms не даст тебе ответа, сколько раз в секунду проверяется значение переменной, или самому разве что копать исходники
почему бы просто не совместить считывающую прогу с записывающей? Быстрей этого ничего не будет, это ж jmp из цикла опроса. IMHO
Ну прога то (если имелся ввиду процесс) вообще одна. Нити разные. И нет там никакой записывающей, есть котролирующая нить, т.е. отслеживающая устанавливаемый time-out при однородном меандре, предоставляющая возможность эктренного завершения опроса по фронту сигнала. А читающая нить пока не обнаружила не однородности читает порт циклами по 16 килогерц и на конце проверяет устанавливаемый со стороны timeout если обнаружила неоднородность - сигнализирует и переходит на чтение в дамп. У неё слишком большие требования к чувствительности по частоте сигнала чтобы на неё ещё наваливать обработку от пользователя, поэтому реакция на действия пользователя сделана во внешней нити которая может реагировать на пользователя только если сканирующая нить не сообщила об неоднородном сигнале.
[ The Svin: <font color="indigo]сколько времени отнимает нить подвешанная WaitForSingleObject?</font><!--color--> ] Нисколько. Поток исключается из планирования. Процессор ему больше не дают. Есть, правда, одно исключение - APC, но оно к делу не относится. [ The Svin: <font color="indigo]Если я подвешал на WaitForSingleObject с INFINITE как идёт проверка?</font><!--color--> ] Проверка выполняется только в момент перехода объекта, на котором ты ждешь, в свободное состояние. У каждого ожидаемого объекта есть список потоков, ждущих объект. При вызове функции, освобождающей объект, она проходит по списку и делает ожидающие потоки планируемыми, выделяя им полный квант. Т.е., грубо говоря, просто ставит их в очередь готовых к выполнению потоков и они начинают опять же ждать, но уже момента, когда планировщик потоков подключит их к камню. Ну там деталей всяких куча, но суть такая. Самое главное понять, что поток получит процессор, не в тот момент, когда освободится объект, а когда планировщик потоков посчитает нужным это сделать, а это зависит от текущей загрузки системы и приоритета потока. Т.е. говорить о реальном времени или "медленнее", "быстрее" просто не имеет смысла. Windows не является осью реального времени.
