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

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

Как раз плотная работа HDD должна вызывать меньше торможений (если в коде нет косяков), чем столь же плотная работа SSD. Драйвер заряжает передачу по DMA и сразу возвращает управление. А вот некоторые драйверы SSD, судя по всему, "оптимизируют" не слишком длинные операции, не возвращая управления до их завершения, чтобы получить более высокие результаты в тестах за счет ресурсов процессора.

V>На технике из 2009-го укладывалось в полторы микросекунды.

Сколько сочетаний железа/ОС Вы таким образом тестировали, и какие телодвижения предшествовали получению таких результатов?

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

V>Не процессор, а ядро

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

V>И откуда там аппаратное ожидание на семафоре?

Ну а что еще делать процессору/ядру, когда у него нет кода, готового к исполнению? Коль уж Вы упоминаете affinity, назначенный тестовому потоку, то возникает логичное предположение, что все остальные процессы/потоки на данный процессор/ядро не допускаются, и на нем исполняется только служебный код ОС (привязанные прерывания, DPC и прочее). Иначе нет почти никакого смысла в привязывании потока к определенным ядрам — большее значение имеет отвязывание его от наиболее загруженных ядер (того же нулевого).

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

А Вы проверяли, что эти ядра действительно не участвуют? Ну и не забывайте про DPC affinity — это вполне себе годный способ распределения нагрузки. Смотрели распределение DPC по ядрам?

V>только реагирующих на сигналы (программные прерывания)

Что именно Вы называете "программными прерываниями"? Чтобы известить другие процессоры/ядра о событии, используется аппаратное IPI, оно не бесплатное.

ЕМ>>то до переключения контекста дойдет лишь после того, как все эти обработчики завершатся.

V>Да там единственный непрерываемый сигнал софтовый сигнал — это смена текущего контекста исполнения.

Так на каком основании Вы предполагаете, что нужное ядро всегда будет готово к переключению контекста?

V>Большинство софтовых сигналов могут прерваны более приоритетными сигналами

Что Вы называете "сигналами" применительно к Windows? Документация MS по ядру Windows использует только глагол to signal, и прилагательное signaled.

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

Где именно они так называются? Если Вы об общей теории прерываний, то она допускает различные реализации. А конкретно в Windows термин interrupt используется только в отношении аппаратного прерывания. "Долгая" обработка реализуется через DPC, к ним существительное interrupt не применяется. У DPC есть приоритеты, но они влияют только на размещение в очереди. Если на ядре/процессоре начал выполнение обработчик DPC, то прервать его может только аппаратное прерывание, после завершения которого он продолжит работу, принудительно вытеснить его другим DPC или потоком невозможно.

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

Знаю, я делал и драйверы ASIO, и клиенты для них. Редкостное убожество. Даже в 90-х оно годилось максимум в качестве временного наколенного решения, но тащить его тридцать лет — знатное извращение.

V>Но профессиональные аудиокарты, в т.ч. внешние USB 3.0 уже идут со своими дровами ASIO

За редким исключением, там нет никаких особых "дров ASIO". Есть общий драйвер WDM/KS, а прилагаемая ASIO DLL работает либо через сам KS (как ASIO4ALL), либо через специальные функции ядерного драйвера, чтоб не заморачиваться с KS-протоколами.

V>В этом и был смысл, наверно, чтобы миновать всевозможные этапы конвейеров аудиокарт и соотв. их драйверов, т.е. стрим идёт мимо микшеров, мимо посаженных эффектов картейки (шумоподавление, эхо и т.д.), мимо вообще всего тупо на выход или тупо со входа.

В те времена, когда Steinberg его выкатила, не было никаких "конвейеров", "микшеров" и "эффектов". Тогда в винде просто был тормозной (и еще более примитивный) звуковой интерфейс, и любой драйвер ASIO работал с железом напрямую, вообще никак не контактируя с виндовой звуковой подсистемой. Но уже в Win2k это привели в порядок (KS был даже в Win98), и с тех пор для того, чтобы любить ASIO, нужно слепо верить в его крутизну и превосходство, иначе никак.

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

Для любого устройства иначе нельзя. Но необходимость прикручивать что-то сбоку отпала минимум 25 лет назад, а воз и ныне там.

V>"Без приседаний" нижний предел был в районе 8-10 мкс.

Микросекунд? Не верю. Может, милли-?

V>>>Там lock-free очереди.
ЕМ>>В каких именно драйверах ядра Вы их видели, и для чего они там?

V>Это в открытом однажды их фреймворке для эффективной многопоточной обработки данных.

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

V>Прям уж не всегда?

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

V>Мне как раз любопытны такие задачи, бо много возился с задачами как раз избегания столкновения потоков.

Когда все механизмы взаимодействия проектируются с нуля, и потом ничего не добавляется и не переделывается, то гораздо проще. Сложнее, когда нужно обеспечить синхронизацию с уже готовой библиотекой, использующей не самые удачные решения. В случае с виндой одной из таких библиотек является Port Class Driver для звуковых устройств. Его фреймворк заточен под то, чтоб минидрайвер мог написать даже весьма средний программист, поэтому с разведением возможных блокировок выходит очень грустно.

V>Мне вообще странно, почему подобное не идёт изкаробки. ))

Мне тоже странно, только многим ли оно надо? Большинство жрет, что дают, и просит еще.