Здравствуйте, Евгений Музыченко, Вы писали:
V>>не стоит создавать взаимные блокировки ресурсов у драйвера и прикладной части, стоит использовать lock-free техники. ЕМ>Стоит, но кто бы это делал в той же винде...
Сложно протестировать и\или провалидировать подобный код. Если речь о ядре.
V>>подавляющее большинство плюсовых библиотек использовать будет невозможно. ЕМ>Их уже из-за исключений невозможно использовать.
Здравствуйте, 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. Тоже элементарно реализуется в ядерном коде, я такое давно использую.
Здравствуйте, Sharov, Вы писали:
S>Сложно протестировать и\или провалидировать подобный код. Если речь о ядре.
Почему сложно? Любые техники синхронизации тестируются одинаково — запускается несколько параллельных потоков, которые конкурируют между собой за ресурсы, попутно проверяя корректность работы примитивов, и гоняется какое-то время.
V>>>подавляющее большинство плюсовых библиотек использовать будет невозможно. ЕМ>>Их уже из-за исключений невозможно использовать.
S>А при чем тут исключения?
Большинство плюсовых библиотек без исключений не живет, иначе их не считали бы "истинно плюсовыми".
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Сложно протестировать и\или провалидировать подобный код. Если речь о ядре. ЕМ>Почему сложно? Любые техники синхронизации тестируются одинаково — запускается несколько параллельных потоков, которые конкурируют между собой за ресурсы, попутно проверяя корректность работы примитивов, и гоняется какое-то время.
Речь о lock-free алгоритмах, где нету никаких примитивов синхроиназии, используются cas инструкции,
т.е. атомарные. Кажется, что с примитвом протестировать и проверить прощее, а вот без уже
проблематично. Ну и речь о ядре, там своя специфика. Наверное.
S>>А при чем тут исключения? ЕМ>Большинство плюсовых библиотек без исключений не живет, иначе их не считали бы "истинно плюсовыми".
А какая проблема с исключениями в rt системах(или ядре) как таковых?
Здравствуйте, Евгений Музыченко, Вы писали:
П>>Ничего там не вылизывалось, ставил на древнюю систему самую обычную древнюю XPшку, по сети закидывал файлы с жи кодом
ЕМ>Повезло, бывает.
Ну, вообще-то этим мачем дофига народу пользуется. Всем везёт?
Здравствуйте, andyp, Вы писали:
A>Если сможешь доказать, что прога + ос (т.е. все целиком) ВСЕГДА реагирует на внешние раздражители за некоторое наперед известное время, то система будет системой реального времени, отчего ж нет.
А какой она в этом случае будет, soft... или hard...?
Пока не доказано, не является?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, tapatoon, Вы писали:
T>Каждая апи ОС принимает параметр максимального времени исполнения, по прошествии которого гарантированно возвращается результат операции или таймаут
Здравствуйте, Sharov, Вы писали:
S>Речь о lock-free алгоритмах, где нету никаких примитивов синхроиназии, используются cas инструкции,
Я в курсе. Эти команды и есть примитивы.
S>Кажется, что с примитвом протестировать и проверить прощее, а вот без уже проблематично.
Какая разница-то, если все тупо сводится к массированному конкурентному использованию примитивов, какими бы они ни были?
S>речь о ядре, там своя специфика. Наверное.
Там всей специфики — нельзя [слишком долго] ждать в состояниях, в которых недоступно переключение контекста, а для lock-free ожидания не требуется.
S>А какая проблема с исключениями в rt системах(или ядре) как таковых?
С обычными исключениями — никакой, а с плюсовыми вся проблема в том, что этот громоздкий и уродливый механизм попросту не хотят тащить в ядро, и правильно делают.
Здравствуйте, пффф, Вы писали:
П>вообще-то этим мачем дофига народу пользуется. Всем везёт?
Всем везти никак не может. Либо Вы недостаточно информированы, либо там инструкция требует определенных телодвижений для получения состояния системы, которое у Вас (и еще кого-то, но далеко не у всех) получилось случайно.
Здравствуйте, Философ, Вы писали:
Ф>есть там какая-нибудь гарантия, что аудио никогда не будет заикаться, а видео не будет пропускать кадры?
Абсолютной гарантии нигде нет. Но в мало-мальски приличной RT-системе вероятность заикания/пропуска примерно такая же, как и появления дефектного блока на диске, порчи данных в памяти и т.п. То есть, она ненулевая, но, во-первых, пренебрежимо мала на фоне длительности успешной работы, а во-вторых, такая ситуация рассматривается, как отказ/нарушение работы, а не как вполне штатная, хоть и досадная, ситуация.
Здравствуйте, Евгений Музыченко, Вы писали:
Ф>>есть там какая-нибудь гарантия, что аудио никогда не будет заикаться, а видео не будет пропускать кадры? ЕМ>Абсолютной гарантии нигде нет. Но в мало-мальски приличной RT-системе...
Данная ветка про Линукс. Я у него про Линукс спрашивал.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему сложно? Любые техники синхронизации тестируются одинаково — запускается несколько параллельных потоков, которые конкурируют между собой за ресурсы, попутно проверяя корректность работы примитивов, и гоняется какое-то время.
Фигня. У меня, где-то в моих завалах лежит пример кода, в котором ошибка на i7-6700K воспроизводилась один раз на примерно 300К итераций, а на i9-11900kf не воспроизводится. Я догадываюсь, что воспроизведётся рано или поздно, но ни разу не дожидался воспроизведения.
Гонять какое-то время — явно плохой способ.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sharov, Вы писали:
S>Речь о lock-free алгоритмах, где нету никаких примитивов синхроиназии, используются cas инструкции, S>т.е. атомарные.
Вот кто-нибудь бы ещё в мануалы к процессорам заглядывал, например в интеловский, где английским по белому написано про эти инструкции, что чтобы они были атомарными, нужно использовать LOCK prefix — оно lock на шину выставляет.
Вот, например CMPXCHG
This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically. To simplify the
interface to the processor’s bus, the destination operand receives a write cycle without regard to the result of the
comparison. The destination operand is written back if the comparison fails; otherwise, the source operand is
written into the destination. (The processor never produces a locked read without also producing a locked write.)
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Речь о lock-free алгоритмах, где нету никаких примитивов синхроиназии, используются cas инструкции, ЕМ>Я в курсе. Эти команды и есть примитивы.
Не понял, одно дело некий объект (мьютекс), а другое дело инструкция "атомарно считать и обновить".
Можно притив захватить какой-нибудь соотв. инсрукцией, например. Но это не одно и тоже.
S>>Кажется, что с примитвом протестировать и проверить прощее, а вот без уже проблематично. ЕМ>Какая разница-то, если все тупо сводится к массированному конкурентному использованию примитивов, какими бы они ни были?
Мне казалось, что lock-free алгоритмы не предполагают примитивов.
S>>речь о ядре, там своя специфика. Наверное. ЕМ>Там всей специфики — нельзя [слишком долго] ждать в состояниях, в которых недоступно переключение контекста, а для lock-free ожидания не требуется.
Тут согласен, поток по идее всегда что-то делает, а не ждет чего-то. Точнее ждет активно.
Здравствуйте, Евгений Музыченко, Вы писали:
П>>вообще-то этим мачем дофига народу пользуется. Всем везёт?
ЕМ>Всем везти никак не может. Либо Вы недостаточно информированы, либо там инструкция требует определенных телодвижений для получения состояния системы, которое у Вас (и еще кого-то, но далеко не у всех) получилось случайно.
Я хорошо вопрос изучал. Нет ни инструкции по настройке системы под это ПО, ни жалоб тех, у кого оно не работает. Ну, то есть, много вопросов, как настроить входные/выходные пины LPT-порта, что и как с платами совместимых с ним контроллеров, и тд и тп. Про настройку WinXP ничего нет. Единственное, что было известно на тот момент — это то, что Mach3 ставит в систему какой-то свой драйвер, и по этой причине не совместима с вистой и семёркой.
