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

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

Обычные тесты из миллиардов итераций в течении десятков минут и плотной работы других приложений, в т.ч. с HD-дисками, что классически вызывает торможения порой даже мышки.
Есть два реалтаймовых потока, разнесённых через affinity по разным ядрам, кроме нулевого.
Обмениваются сигналом с одного семафора поочерёдно, замеряется время реакции.

Укладывалось до менее микросекунды, вычти еще отсюда стоимость вызова QPC и вычти стоимость принудительного вытеснения потока из-за захода в блокирующее ожидание.
На технике из 2009-го укладывалось в полторы микросекунды.

И ни разу не пролабало.

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


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

Не процессор, а ядро, у меня в непосредственном распоряжении были только однопроцессорные машинки.
И откуда там аппаратное ожидание на семафоре?

Блокирующее ожидание на семафоре или HEVENT всегда приводит к вытеснению потока и постановке ожидающего потока в сортированную по приоритетам очередь ожидающих потоков на примитиве синхронизации.

Т.е., в момент установки семафора ОС проверяет очередь ожидающих потоков и их приоритет (в сортированной очереди проверяется только голова списка), затем, в случае привязки affinity, всё происходит достаточно прямолинейно — проверяется текущий поток только указанного ядра и, если приоритет исполняющегося потока оказался ниже приоритета ожидающего потока (да, ты прав, после некоторого ожидания "виртуальный" приоритет ожидающего потока поднимается в этих расчётах, но в случае реалтаймового потока мы уже имеем наивысший приоритет из всех возможных), затем тому ядру посылается соотв. софтовое прерывание для переключения контекста исполнения на другой софтовый поток.

Выглядит всё это достаточно дорогостояще, но в сотни наносекунд на современном железе укладывается.

Понятно, что можно использовать spin-wait техники и или есть еще техники для межпоточных очередей (через доп. interlocked trigger), чтобы не обращаться лишний раз к примитиву синхронизации уровня ядра и не тратить тики процессорных ядер на достаточно дорогостоящий решедуллинг с переключением контекста.


ЕМ>Если на нем вдруг выполняется обработчик обычного и/или отложенного прерывания

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


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

Да там единственный непрерываемый сигнал софтовый сигнал — это смена текущего контекста исполнения.
Т.е. плюс-минус до сотни наносекунд примерно потенциальное "дрожание фронта". ))
И то, событие достаточно редкое по меркам систем, где рассуждают о реалтайме.


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

Большинство софтовых сигналов могут прерваны более приоритетными сигналами — я в самом первом сообщении ветки уже упомянул это, что такие обработчики не несут с собой нерешаемой проблемы.

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

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


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

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

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

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

В том числе есть чисто софтовая эмуляция интерфейса https://asio4all.org/, удобная для разработки и отладки.
Но профессиональные аудиокарты, в т.ч. внешние USB 3.0 уже идут со своими дровами ASIO, с чем я тоже одно время несколько лет плотно работал. ))


ЕМ>и довольно примитивный, неудобный и кривой.

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


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

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


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

Это на полный круг со своими эффектами звука уже.
"Без приседаний" нижний предел был в районе 8-10 мкс.


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

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


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

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


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

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

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

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

Обычные тесты из миллиардов итераций в течении десятков минут и плотной работы других приложений, в т.ч. с HD-дисками, что классически вызывает торможения порой даже мышки.
Есть два реалтаймовых потока, разнесённых через affinity по разным ядрам, кроме нулевого.
Обмениваются сигналом с одного семафора поочерёдно, замеряется время реакции.

Укладывалось до менее микросекунды, вычти еще отсюда стоимость вызова QPC и вычти стоимость принудительного вытеснения потока из-за захода в блокирующее ожидание.
На технике из 2009-го укладывалось в полторы микросекунды.

И ни разу не пролабало.

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


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

Не процессор, а ядро, у меня в непосредственном распоряжении были только однопроцессорные машинки.
И откуда там аппаратное ожидание на семафоре?

Блокирующее ожидание на семафоре или HEVENT всегда приводит к вытеснению потока и постановке ожидающего потока в сортированную по приоритетам очередь ожидающих потоков на примитиве синхронизации.

Т.е., в момент установки семафора ОС проверяет очередь ожидающих потоков и их приоритет (в сортированной очереди проверяется только голова списка), затем, в случае привязки affinity, всё происходит достаточно прямолинейно — проверяется текущий поток только указанного ядра и, если приоритет исполняющегося потока оказался ниже приоритета ожидающего потока (да, ты прав, после некоторого ожидания "виртуальный" приоритет ожидающего потока поднимается в этих расчётах, но в случае реалтаймового потока мы уже имеем наивысший приоритет из всех возможных), затем тому ядру посылается соотв. софтовое прерывание для переключения контекста исполнения на другой софтовый поток.

Выглядит всё это достаточно дорогостояще, но в сотни наносекунд на современном железе укладывается.

Понятно, что можно использовать spin-wait техники и или есть еще техники для межпоточных очередей (через доп. interlocked trigger), чтобы не обращаться лишний раз к примитиву синхронизации уровня ядра и не тратить тики процессорных ядер на достаточно дорогостоящий решедуллинг с переключением контекста.


ЕМ>Если на нем вдруг выполняется обработчик обычного и/или отложенного прерывания

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


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

Да там единственный непрерываемый сигнал софтовый сигнал — это смена текущего контекста исполнения.
Т.е. плюс-минус до сотни наносекунд примерно потенциальное "дрожание фронта". ))
И то, событие достаточно редкое по меркам систем, где рассуждают о реалтайме.


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

Большинство софтовых сигналов могут прерваны более приоритетными сигналами — я в самом первом сообщении ветки уже упомянул это, что такие обработчики не несут с собой нерешаемой проблемы.

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

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


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

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

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

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

В том числе есть чисто софтовая эмуляция интерфейса https://asio4all.org/, удобная для разработки и отладки.
Но профессиональные аудиокарты, в т.ч. внешние USB 3.0 уже идут со своими дровами ASIO, с чем я тоже одно время несколько лет плотно работал. ))


ЕМ>и довольно примитивный, неудобный и кривой.

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


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

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


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

Это на полный круг со своими эффектами звука уже.
"Без приседаний" нижний предел был в районе 8-10 ms.


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

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


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

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


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

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