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

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

Это не тот реалтайм.
Через буферирование до 1-2 сек требования к "реалтаймовости" снижаются до примерно этих значений. ))


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

Это только обновления, плановое обслуживание дисков (если HD) и проверка на вирусы/трояны.
Всё это отключается через политики простым скриптом.


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

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


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

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


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

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

Я с этим одно время плотно экспериментировал с дровами ASIO, добивался задержки обработки звука 2 мс, где комп представлял из себя гитарную самописную примочку.


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

Там lock-free очереди.
Причём, что забавно, примерно такие же (вернее, почти в точности такие же) очереди я "изобрел" и вылизал в нулевые, пока MS однажды не открыла исходники своей библиотеки для построения межпотоковой обработки данных. Причём, все годы до этого я несколько переживал насчёт своей схемы (многократно мысленно и в тестах трассировал, там достаточно много было тонкостей), но, увидев практически один-в-один реализацию, вздохнул с облегчением.

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

В любом случае, не проблема дёрнуть HEVENT или семафор из разных потоков, бо там lock-free в цикле унутре ядра на этих примитивах.
Проблема может быть, например, с мьютексом или другими ресурсами, доступ к которым организован как исключительный.
Так вот, этого исключительного одновременного доступа из драйвера и из юзерского кода быть не должно.


V>>RAII требует реакции на исключения.
ЕМ>Сам по себе — не требует, и никогда не требовал, он вообще ничего не знает о существовании исключений.

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


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

ЕМ>Именно.

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

Фаза статической инициализации — это загрузка модуля загрузчиком ОС.
Это инициализация глобальных переменных константами времени компиляции или константами времени загрузки модуля (например, физическими адресами ф-ий и глобальных переменных).


ЕМ>ибо программа в этом не участвует, за нее это делает CRT.

Эта часть называется динамической инициализацией, т.к. уже исполняется пользовательский код (тела конструкторов).
В фазе статической инициализации пользовательский код не исполняется.


ЕМ>Тоже элементарно реализуется в ядерном коде, я такое давно использую.

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

Или речь о самописной подсистеме, эмулирующей происходящее, но заставляющей оформлять глобальные переменные неким особым образом (т.е. не обеспечивающей гарантии языка)?
Второе я делал банально для TLS-объектов, бо в прошлых стандартах оно не работало. ))