Как усыпить процесс в ядре на 2 мс?

[Anonymous]

В Windows? На команду Sleep ругается.

[SlavaI]

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

[Anonymous]

Сорри я и имел ввиду поток. KeWait... использовать не получается задержки получаются слишком большие. Может это как-то побороть можно?
С KeDelayExecutionThread тоже фигня, я хочу снизить нагрузку на нить, которая жрет сейчас 99% времени, большую часть конечно простаивая. Поставил задержку, нагрузка не изменилась, такое ощущение, что нить просто ждет не отдавая ресурсов.

[maaaaaad]

А вы случайно не путаете терминолочию? Нитей в ядре нет. Есть потоки KTHREAD и процессы KPROCESS. Их, конечно, можно организовать самому но вы уверенны что вы ЭТО делаете?

Теперь. Обьясните что за процесс такой. Чужой процесс? Или вы сами как-то создаете процесс в ядре?

Так. Функций усыплений процессов я тоже думаю что нет. Для усыпления потока нужно самому усыпить список связанных потоков threadlisthead. Для начала я бы так стал действовать.


otherox-alongtheroad rip my sound system

[maaaaaad]

Короче я нифига не понял вопроса =))
нить??? чья??? где???
и как можно жрать 99% ресурсов простаивая?

[maaaaaad]

У вас вообще какая операционная система?? =)

[Anonymous]

Mr. Quaky Hands,
Как же нет, если вы сами говорите о kthread? Речь о них.
тред создаю я сам и он общается с устройством. 99% он жрет простаивая в том смысле, что не делает полезной работы. while(1) то есть.
Пакет от устройства пропустить нельзя, а если перевести в KeWaitForSingle Object время реакции медленне чем работает устройство.
Система XP.

[SlavaI]

Пакет от устройства пропустить нельзя, а если перевести в KeWaitForSingle Object время реакции медленне чем работает устройство.

Мы это тут уже не раз обсуждали. Если у тебя такое устройство, то наврят ли ты напишешь нормальный драйвер для системы не real time- ты будешь терять данные, если устройство само не будет их буферизировать в объеме, достаточном для реакции системы.

Недавно это вот тут обсуждалось   https://forum.shelek.ru/index.php/topic,1510.0.html
 там тоже были проблемы с реакцией системы.

[Anonymous]

SlavaI,
Спасибо, весьма дельная ссылка, сутуация у меня очень похожая. Меня заинтересовало вот это ваше предложение:
"Как вариант могу предложить сразу выцарапывать данные с карты в ISR и вставлять их в какой-то буфер, где они накапливаются, ставить DPC, в нем SetEvent, будить поток, желательно системный(PsCreateSystemThread) и в нем с буфером разбираться, вынимая из него данные от нескольких прерываний. "

Я, сейчас, примено так и делаю, забираю данные в ISR во внутренюю очередь, потом их забираю в UserMode ReadFile'ом в бесконечном цикле. И наоборот для отправки заполняю данные очереди WriteFile'ом и SystemThread в бесконечном же цикле ее проверяет. В принципе, работает, но загрузка проца всегда на 99%. Что мне очень не нравится, но если высталять событие поле каждого пакета, то выходит полная ерунда. Не могли бы вы подробнее обяснить ваш совет с DPC, поскольку, мне кажется, ответ где-то здесь, но я совсем ничего не понял. :oops:

[maaaaaad]

ReadFile'ом в бесконечном цикле.....WriteFile'ом и SystemThread в бесконечном же цикле

загрузка проца всегда на 99%

Это опять while(1)? Тогда все лочино, не правда ли?

Сказали же: Выставлять событие по добавлению в очередь, а в юзер потоке ждать на событии и очищать очередь. И не на DIRQL а на DISPATCH. Нужно создать DPC объект (KeInitializeDpc) а в ISR добавлять в очередь DPC свой обработчик dpcforisr (KeInsertQueueDpc). Что непонятно то?
И вобще не делайте с системным потоком.