Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Не знаю, как в Linux, а в Windows аппаратные прерывания — один из последних факторов, влияющих на реактивность процессов.
Это от драйвера зависит.
Маскируемое прерывание должно быть отработано как можно быстрее, т.е. в идеале — выставить пару флагов, разрешить аппаратные прерывания и инициировать уже программное прерывание.
ЕМ>На современном железе нужны десятки-сотни тысяч прерываний в секунду, чтобы они стали ощутимо кому-то мешать.
Реалтайм бывает разный.
Современные Windows и Linux на грамотно построенной аппаратуре и соотв. драйверном и прикладном ПО способны обеспечить реакцию в единицы микросекунд запросто.
ЕМ>В основном тормозят кривые драйверы (в том числе родные) и чрезмерно раздутый код ядра.
Приличная часть кода ядра может и не использоваться вовсе, а в Linux лишнее можно легко выключить из сборки.
Ведь ты ж не будешь строить реалтаймовую систему как "просто еще одну программу" на десктопе общего назначения?
Зачем запускать десятки ненужных процессов?
V>>в виндах отродясь был realtime-приоритет, для linux есть соотв. патчи.
ЕМ>Это всего лишь наивысший приоритет user-mode кода. От тормозов в ядре он спасти не может.
Процессоры сегодня многоядерные, поэтому, если с драйвером нет взаимных блокировок ресурсов и прикладной поток исполняется в другом ядре чем то, которое обслуживает прерывание, то прикладной процесс с наивысшим приоритетом будет всегда оперативно получать тики проца.
Там всей разницы, что ожидающий на семафоре или HEVENT такой поток получает тики проца в Windows сразу же при установке примитива сигнализации, а в Linux такие потоки получали тики проца через стандартный решедуллинг раз в 1/1000 сек, почему Linux и не считалась системой реального времени. Но есть патчи, которые заставляют решедулить потоки при установке из ядра примитивов сигнализации, т.е. которые передают управление нужному потоку сразу — у каждого примитива сигнализации есть список ожидающих его потоков. На autoreset HEVENT обычно ожидает один поток, на семафоре могут ожидать несколько потоков, например, несколько прикладных потоков с наивысшим приоритетом раскиданы по физическим ядрам и обрабатывают поступающие данные в режиме СМО.
V>>не стоит создавать взаимные блокировки ресурсов у драйвера и прикладной части, стоит использовать lock-free техники. 
ЕМ>Стоит, но кто бы это делал в той же винде... 
Там это делали отродясь, по крайней мере в дровах от самой MS.
V>>прикладной код может целиком жить в драйвере, хотя в этом случае писать придётся на Си или на сильно урезанном С++ — без исключений/RAII, без динамической инициализации глобальных объектов, без RTTI и, возможно, без сохранения плавающих регистров м/у прерываниями, т.е.,
ЕМ>RAII не требует ничего, кроме поддержки конструкторов/деструкторов, это реализовано везде.
RAII требует реакции на исключения.
Но, я мог здесь и поторопиться в рассуждениях, бо, действительно, в отсутствии исключений, дело только за вызовами деструкторов по выходу из scope.
ЕМ>А что такое "динамическая инициализация глобальных объектов"?
Это когда у глобальных/статических переменных вызывается конструктор и в конце работы модуля деструктор.
