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

ЕМ>>использовать "десктоп общего назначения" для воспроизведения музыки и показа картинок в клубе.

V>Это не тот реалтайм.

Если тупо проигрывать MP3 и отображать картинки из файлов — да. Но в клубах часто используют диджейские станции, которые смешивают разные звуки, добавляют звуковые эффекты в музыку и голос, визуальные — в изображения, и т.п. Там очень плотные вычисления, и задержки даже в десяток миллисекунд могут быть слышны.

ЕМ>>Но та же винда без специального допиливания и жесткого контроля всего софта имеет свойство запинаться в случайные моменты времени.

V>Это только обновления, плановое обслуживание дисков (если HD) и проверка на вирусы/трояны.

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

V>Всё это отключается через политики простым скриптом.

Неважно, насколько просто это делается — важно то, что это приходится знать и делать.

V>Ну, когда разговор о реалтаймовых системах, то обычно подразумевают малый порядок времени отклика...
V>Какие там уже файлы? ))

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

V>Шаренная память, конечно.

Да никакой разницы. Это все компоненты системы, имеющие каждая собственные рамки. Медленное ОЗУ ничем не лучше медленного диска.

V>Не, в случае наивысшего приоритета потока — получает железно 100%-но! ))

Мамой клянетесь?

ЕМ>>и не "тики проца", а временное повышение приоритета, а до тиков проца в этот момент еще очень далеко.

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

Угу, только столь радужная картина будет только в случае, когда нужный процессор в это время висит в аппаратном ожидании. Если на нем вдруг выполняется обработчик обычного и/или отложенного прерывания, то до переключения контекста дойдет лишь после того, как все эти обработчики завершатся. А время их выполнения далеко не всегда ничтожно мало, поскольку их все чаще пишут из соображений "компилятор все оптимизирует", "процессор все разрулит", "и вообще, кого волнует лишняя сотня микросекунд".

V>Я с этим одно время плотно экспериментировал

А я с этим работаю уже больше двадцати лет. И хорошо вижу, где какие задержки.

V>с дровами ASIO

Это вообще чистый код пользовательского режима, работающий поверх любых ядерных средств, и довольно примитивный, неудобный и кривой. Но, поскольку этот интерфейс принято поддерживать в любых "профессиональных" устройствах, в соответствующей среде он считается верхом совершенства и эффективности, даже если работает через какой-нибудь тормозной драйвер ядра.

V>добивался задержки обработки звука 2 мс

Если железо позволяет, и драйвер хороший, то через KS (через который чаще всего и работает ASIO) можно и до 500-700 мкс допинать. Но с приседаниями.

V>Там lock-free очереди.

В каких именно драйверах ядра Вы их видели, и для чего они там?

V>исключительного одновременного доступа из драйвера и из юзерского кода быть не должно.

Не должно, но не всегда получается их корректно развести без ограничения функциональности.

V>Это ты линковался с подменой каких-нить конкретных кишок CRT конкретного компилятора своими хелперами?

Ага. У меня вообще свой простейший CRT, я пользуюсь только "независимыми" библиотечными функциями, которым не нужна определенная среда.