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

ЕМ>>в Windows аппаратные прерывания — один из последних факторов, влияющих на реактивность процессов.

V>Это от драйвера зависит.

Сами по себе аппаратные прерывания и общий механизм их обработки в ОС не зависят от драйверов. А уж когда дошло до драйвера, может случиться все, что угодно.

V>Современные Windows и Linux на грамотно построенной аппаратуре и соотв. драйверном и прикладном ПО способны обеспечить реакцию в единицы микросекунд запросто.

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

ЕМ>>В основном тормозят кривые драйверы (в том числе родные) и чрезмерно раздутый код ядра.

V>Приличная часть кода ядра может и не использоваться вовсе

В современной винде с этим все хуже и хуже с каждой очередной версией, особенно после введения в ядро гипервизора.

V>Ведь ты ж не будешь строить реалтаймовую систему как "просто еще одну программу" на десктопе общего назначения?

Почему бы и нет, если требования разумны? Вполне логично было бы, например, использовать "десктоп общего назначения" для воспроизведения музыки и показа картинок в клубе. Но та же винда без специального допиливания и жесткого контроля всего софта имеет свойство запинаться в случайные моменты времени.

V>>>в виндах отродясь был realtime-приоритет, для linux есть соотв. патчи.
ЕМ>>Это всего лишь наивысший приоритет user-mode кода. От тормозов в ядре он спасти не может.

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

Если умудрится обходиться без общих ресурсов системы (например, файлов).

V>Там всей разницы, что ожидающий на семафоре или HEVENT такой поток получает тики проца в Windows сразу же при установке примитива сигнализации

Не "получает", а может получать, и не "тики проца", а временное повышение приоритета, а до тиков проца в этот момент еще очень далеко.

V>>>стоит использовать lock-free техники.
ЕМ>>Стоит, но кто бы это делал в той же винде...

V>Там это делали отродясь, по крайней мере в дровах от самой MS.

Э-э-э... В каких именно драйверах от MS Вы видели "lock-free техники"? Может, конечно, и есть отдельные примеры, которых я не видел, но "отродясь" там все тупо на спинлоках, мьютексах и событиях.

V>RAII требует реакции на исключения.

Сам по себе — не требует, и никогда не требовал, он вообще ничего не знает о существовании исключений.

V>дело только за вызовами деструкторов по выходу из scope.

Именно.

ЕМ>>А что такое "динамическая инициализация глобальных объектов"?

V>Это когда у глобальных/статических переменных вызывается конструктор и в конце работы модуля деструктор.

Это ж всегда называлось статической инициализацией, ибо программа в этом не участвует, за нее это делает CRT. Тоже элементарно реализуется в ядерном коде, я такое давно использую.