Здравствуйте, Евгений Музыченко, Вы писали:

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

Тут дело не только в ОС, а еще в конкретном оборудовании и настройке самой ОС, в т.ч. настройки её при компиляции ядра.

И Windows, и Linux могут быть собраны таким образом для конкретной железки, чтобы, допустим, прерывания обрабатывались только нулевым ядром.
В этом случае даже "короткое" аппаратное прерывание, маскирующая другие прерывания, не заденет процессы, исполняющиеся в других ядрах, а там уже вопрос приоритета, если есть боязнь вытеснения — в виндах отродясь был realtime-приоритет, для linux есть соотв. патчи.

А для "длинных" софтовых прерываний в этих ОС никогда не было проблем одновременной их обработки.

В общем, это вопрос сочетания сборки ядра, распределения аппаратных ресурсов (в т.ч. назначения affinity для прикладных потоков) и взаимодействия драйвера устройства и прикладного кода, требующего реалтайм.

Например, не стоит создавать взаимные блокировки ресурсов у драйвера и прикладной части, стоит использовать lock-free техники.

С сигналингом тоже достаточно просто — прикладной процесс может находиться в режиме ожидания на некоем HEVENT, имея при этом realtime-приоритет, а драйвер, после подготовки данных, может дёрнуть этот примитив синхронизации и тогда прикладной процесс получит в своём привязанном через affinity аппаратном потоке ресурс проца.

Ну и, сам прикладной код может целиком жить в драйвере, хотя в этом случае писать придётся на Си или на сильно урезанном С++ — без исключений/RAII, без динамической инициализации глобальных объектов, без RTTI и, возможно, без сохранения плавающих регистров м/у прерываниями, т.е., подавляющее большинство плюсовых библиотек использовать будет невозможно.