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

Interrupt Request Level (IRQL) — это некое свойство потока (чем то похожее на приоритет). Оно означает, что потоки с более низким IRQL не смогут вытеснить поток с более высоким IRQL.

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

Вопросы:

1. Правильно ли я понял, и если нет, то как правильно?
2. Если правильно, то если у какого-либо потока максимальный IRQL (= 31 вроде), означает ли это, что его не сможет вытеснить никакой другой поток?

Здравствуйте, Аноним, Вы писали:

А>1. Правильно ли я понял, и если нет, то как правильно?
А>2. Если правильно, то если у какого-либо потока максимальный IRQL (= 31 вроде), означает ли это, что его не сможет вытеснить никакой другой поток?

Вы путаете IRQL и приоритеты потоков

SS>Вы путаете IRQL и приоритеты потоков

В двух словах, если не сложно, что же это такое — IRQL ?

Здравствуйте, Аноним, Вы писали:

А>Interrupt Request Level (IRQL) — это некое свойство потока (чем то похожее на приоритет). Оно означает, что потоки с более низким IRQL не смогут вытеснить поток с более высоким IRQL.

нет,

IRQL — per processor, показывает какие прерывания будет обрабатывать процессор, IRQL может изменяться системой

IRQ — per thread

читайте Руссиновича, там подробно написано

Здравствуйте, Аноним, Вы писали:

SS>>Вы путаете IRQL и приоритеты потоков

А>В двух словах, если не сложно, что же это такое — IRQL ?

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

В режиме ядра вы можете менять текущий IRQL, вызывая функции KeRaise/KeLowerIrql, тем самым запрещая или разрешая определенные прерывания. Например, повысив IRQL до DPC/DISPATCH_LEVEL, вы запретите перепланировку потока, которая запускается в виде программного прерывания (DPC) на DISPATCH_LEVEL. Этот факт используется при реализации спинлока на однопроцессорной машине, например.

Кстати, именно потому, что на IRQL >= DISPATCH_LEVEL, запрещена перепланировка и переключение задач, на этих уровнях IRQL нельзя ждать на объекте синхронизации. Ведь если объект синхронизации занят, системе пришлось выполнить перепланировку, которая невозможна на IRQL >= DISPATCH_LEVEL. Из этого имеется еще одно интересное следствие — нельзя обращаться к выгружаемой памяти, т.к. в результате обработки ошибки страницы, нужно будет опять-таки ждать, пока страница загрузится в память.

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

не 'IRQ', а 'приоритет', описался

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

[skipped]

Спасибо за исчерпывающее объяснение!
Т.е. если все процессоры поднять до IRQL = DISPATCH_LEVEL, то поток, который сделал это, гарантированно не будет прерван другими потоками, да?

Здравствуйте, Аноним, Вы писали:

А>Т.е. если все процессоры поднять до IRQL = DISPATCH_LEVEL, то поток, который сделал это, гарантированно не будет прерван другими потоками, да?

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

SS>Потоку достаточно поднять IRQL до DISPATCH_LEVEL на текущем процессоре, чтобы избежать переключения задач на текущем процессоре. При этом выполнение потока может быть прервано для обслуживания прерываний от устройств.

Понял. Т.е. чтобы поток вообще не был прерван никем, нужно сделать две вещи:

1. Поднять IRQL на всех процессорах до DISPATCH_LEVEL
2. Запретить прерывания — cli

Здравствуйте, Аноним, Вы писали:

А>Понял. Т.е. чтобы поток вообще не был прерван никем, нужно сделать две вещи:

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

А>1. Поднять IRQL на всех процессорах до DISPATCH_LEVEL

Чтобы запретить переключение задач на текущем процессоре, можно поднять IRQL до уровня DISPATCH_LEVEL. Это гарантирует, что поток не будет вытеснен в результате перепланировки. Это отнюдть не означает, что выполнение потока не может быть прервано для обработки прерывания или исключения.

А>2. Запретить прерывания — cli

Зачем? Чего добиться хотите?

SS>Зачем? Чего добиться хотите?

Если все процессоры перевести на DISPATCH_LEVEL, то это позволить уберечь поток от перепланировки. Но вы сказали, что поток может быть также прерван и по прерыванию или исключению. Если недопускать (методом прямых рук ) возникновения исключений, то остаются прерывания. Т.о. если их запретить, то не останеться факторов, которые могли бы инициировать перепланировку. А значит поток не будет прерван. Я прав?

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

SS>Зачем? Чего добиться хотите?
Предположу, что речь идет о том, как атомарно пропатчить ядро — не имея риска, что во время изменения какого-то адреса поток на другом процессоре выполнит заменяемый код.

Здравствуйте, Аноним, Вы писали:

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

А>Interrupt Request Level (IRQL) — это некое свойство потока (чем то похожее на приоритет). Оно означает, что потоки с более низким IRQL не смогут вытеснить поток с более высоким IRQL.

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

А>Вопросы:

А>1. Правильно ли я понял, и если нет, то как правильно?
А>2. Если правильно, то если у какого-либо потока максимальный IRQL (= 31 вроде), означает ли это, что его не сможет вытеснить никакой другой поток?
--
Прочитайте дополнительно вот эту статью "Scheduling, Thread Context, and IRQL", вполне возможно, после этого Вы сами сможете ответить на эти вопросы.

C уважением,
Геннадий Майко.

ГМ>Прочитайте дополнительно вот эту статью "Scheduling, Thread Context, and IRQL", вполне возможно, после этого Вы сами сможете ответить на эти вопросы.

Вот за статью — огромное спасибо.
Я так понял, следующий абзац отвечает на вопрос о вытеснении потоков:

DISPATCH_LEVEL
DISPATCH_LEVEL is the highest software interrupt level and the first processor-specific level. The Windows thread scheduling and dispatching components (collectively called “the dispatcher”) run at IRQL DISPATCH_LEVEL. Some other kernel-mode support routines, some driver routines, and all deferred procedure calls (DPCs) also run at IRQL DISPATCH_LEVEL. While the processor operates at this level, one thread cannot pre-empt another; only a hardware interrupt can interrupt the running thread. To maximize overall system throughput, driver code that runs at DISPATCH_LEVEL should perform only the minimum amount of required processing.

А это про ограничения кода, выполняющегося на этом IRQL:

Because code that is running at DISPATCH_LEVEL cannot be pre-empted, the operations that a driver can perform at DISPATCH_LEVEL are restricted. Any code that must wait for an object that another thread sets or signals asynchronously—such as an event, semaphore, mutex, or timer—cannot run at DISPATCH_LEVEL because the waiting thread cannot block while waiting for the other thread to perform the action. Waiting for a nonzero period on such an object while at DISPATCH_LEVEL causes the system to deadlock and eventually to crash.

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

1. Перевести процессор на DISPATCH_LEVEL
2. Запретить прерывания — cli

Так это или нет?

Здравствуйте, Аноним,

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

А>1. Перевести процессор на DISPATCH_LEVEL
А>2. Запретить прерывания — cli

А>Так это или нет?
--
Если Вы действительно спрашиваете то, что выделено выше, то нет. Для этого достаточно поднять IRQL данного процессора до DISPATCH_LEVEL — "While the processor operates at this level, one thread cannot pre-empt another". Однако это не значит, что поток не может быть прерван вообще.

C уважением,
Геннадий Майко.

ГМ>Если Вы действительно спрашиваете то, что выделено выше, то нет. Для этого достаточно поднять IRQL данного процессора до DISPATCH_LEVEL — "While the processor operates at this level, one thread cannot pre-empt another". Однако это не значит, что поток не может быть прерван вообще.

Позвольте, а как же прерывания?! Ведь код обработчика прерывания (например, от девайса) вытеснит мой код! Для этого я и хочу запрещать прерывания.

Здравствуйте, Аноним, Вы писали:

ГМ>>Если Вы действительно спрашиваете то, что выделено выше, то нет. Для этого достаточно поднять IRQL данного процессора до DISPATCH_LEVEL — "While the processor operates at this level, one thread cannot pre-empt another". Однако это не значит, что поток не может быть прерван вообще.

А>Позвольте, а как же прерывания?! Ведь код обработчика прерывания (например, от девайса) вытеснит мой код! Для этого я и хочу запрещать прерывания.
--
Извините, я могу отвечать только на Ваши вопросы; я не могу отвечать на то, что Вы подумали, формулирую Ваш вопрос.
Вы написали "для того, чтобы некоторой поток не был прерван другим потоком", а похоже, что при этом Вы имели в виду "для того, чтобы некоторой поток не был прерван". Чувствуете разницу?
Так на какой вопрос отвечать?

C уважением,
Геннадий Майко.

ГМ>Вы написали "для того, чтобы некоторой поток не был прерван другим потоком", а похоже, что при этом Вы имели в виду "для того, чтобы некоторой поток не был прерван". Чувствуете разницу?
ГМ>Так на какой вопрос отвечать?

Э-хе-хех... Это одно и то же на самом деле. Я довольно точно сформулировал вопрос. Поток может быть прерван кем? Только другим потоком, верно? Ну вот. Те же обработчики прерываний тоже ведь работают в каком-то потоке ядра. Двоякого толкования моего вопроса быть не может, я имел в виду именно то, что сказал. Меня не интересует, будет ли поток уничтожен или нет, будет он приостановлен или нет, будет он прерван планировщиком или же по прерыванию/исключению. Мне нужно, чтобы в каждый момент определённого интервала выполнялся мой и только мой код.

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

Здравствуйте, Аноним, Вы писали:

ГМ>>Вы написали "для того, чтобы некоторой поток не был прерван другим потоком", а похоже, что при этом Вы имели в виду "для того, чтобы некоторой поток не был прерван". Чувствуете разницу?
ГМ>>Так на какой вопрос отвечать?

А>Э-хе-хех... Это одно и то же на самом деле. Я довольно точно сформулировал вопрос. Поток может быть прерван кем? Только другим потоком, верно?
--
Нет, не правильно.
Поток может быть прерван не только другим потоком, но и, например, обработчиком прерывания, DPC, APC.


А>Те же обработчики прерываний тоже ведь работают в каком-то потоке ядра.
--
Нет, не правильно.
Обработчики прерывания не работают в каком-то (конкретном) потоке. Они прерывают текущий, в общем случае неопределенный и неизвестный (arbitrary) поток на некотором процессоре и работают в его контексте.


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

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

А>1. Перевести процессор на DISPATCH_LEVEL
А>2. Запретить прерывания — cli
--
Если убрать слова "другим потоком" выше, то в принципе да, так можно попытаться сделать.

С уважением,
Геннадий Майко.