П.6. - очень часто пишут, что "RTOS должна обеспечивать наследование приоритетов" ... вот MS всё спорила, что в WinNT есть наследование приоритетов ;-)...
Этот пункт очень сильно связан с предыдущим...
Наследуется.
Первоначально опубликовано Olej
Наследование приоритетов - это когда вызовы (в том числе и API, в том числе и API ядра!) выполняются под приоритетом вызывающего потока (процесса). Говорят, что "в макроядерной архитектуре это весьма трудно реализовать"... но дело то в том, что даже реализовав это - оно там бессмысленно:
- отношения приоритетов имеет смысл только в контексте кто и кого может прервать при исполнении. Но если API ядра выполняюися в блокирующем режиме - то какая разница, под каким приоритетом они это делают?!
Приоритеты наследуются, но что там может происходит при переходе из r3 в r0 и обратно - не скажу, ибо в ядрах не ковыряюсь.
Первоначально опубликовано Olej
В QNX - наследование приоритетов - органичная особенность, блюдущаяся на всез уровнях иерархий.
Следующий пункт - это вот тот сакраментальный N+1-й критерий, о котором я упоминал выше, и который появился гораздо позже остальных: "RTOS должна препятсвовать возникновению инверсии приоритетов". Это потрясающе интересная проблема, в общем виде она не решена, но я даже не стал её выносить в отдельный "П", т.к. - как можно вообще рассуждать об "инверсии приоритетов" в OS-ах, в которых нет наследования приоритетов!!!
P.S. Я не буду детально расписывать "инверсию приоритетов", но только скажу: а). этот эффект возникает только при рассмотрении 3-х и более параллельных веток выполнения (поток, процесс), потому его и "просмотрели", б). выявляется он крайне редко - для этого нужно стечение временных интервалов этих >=3-х процессов, в). поэтому оттестировать его (отсутствие ;-)) практически невозможно, г). но когда возникает - то элементарная логика выполнения нарушается (низкоприоритетный процесс выполняется, а высокоприоритетный - стоит и его ждёт), д). ... и вот тогда точно "рванёт"... ;-( (какой там закон Мэрфи?).
инверсия приоритетов возможна для класса normal, для server и time-critial - нет - там приоритеты абсолютные и шедулер другой. Деталей я уже не помню, а особо сильно в них не вдавался. Для Normal есть еще MAXWAIT - если в течении такого времени нитка не получала управление, то система на один таймслайс поднимает ей приоритет
SY,
EK
Первоначально опубликовано evgen
Обычно таки разделяют hard и не hard-realtime OS.
РазделяЛИ активно 4-5 лет назад, в тот период, когда MS безумно хотелось протолкать WinNT4 под realtime и сертифицировать на POSIX. Так что пришлось даже распространить термин "мягкий реалтайм"... С тех времён картина несколько поменялась, и очень многие из работающих в realtime области воспринимают "мягкий реалтайм" не иначе, как "осетрину не первой свежести"... А об, мягко говоря, слабой пригодности под realtime как WinNT, так и разнообразных надстроек над ней, с аргументацией и "разбором полётов" - так много опубликовано в Internet, что добавить просто нечего... Ссылки давать?
Первоначально опубликовано evgen
По факту у меня получаются весьма hard-realtime системы на не hard-realtime OS - и оно работает в промышленных условиях.
1. а кто вам сказал что оно hard-realtime (или даже просто в любой мере realtime)? тестирование? Так тестирование ничего не может вообще доказать, кроме "отрицательного подтверждения". Это как соотношение: тестирование-верификация ПО: верификации можно доверять, тестированию - нет.
2. сам термин "весьма hard-realtime системы" - хорош! Это ещё один уровень градации - нечто среднее между "жёстким" и "мягким"? И потом, чтоб придать этой фразе завершённую торжественность, правильнее, наверное, так сказать: "По факту у меня получаются весьма hard-realtime системы на совершенно не realtime OS - и оно работает в промышленных условиях" ("... люблю отдельные красивые слова..." (с) Сатин - М.Горький "На дне").
3. а в отношениее "получаются весьма hard-realtime системы на не hard-realtime OS"... чудеса бывают в природе, но крайне редко (по крайней мере, так учат законы термодинамики):
- Я духов вызывать могу из бездны!
- Я тоже могу, вопрос только в том - явятся ли они на зов...
(с)У.Шекспир "Генрих IV".
Первоначально опубликовано evgen
Часть из приложений я описывал, и не только здесь. И почему-то никто не объявился и не сказал - у меня точно такое же, но под QNX.
Не повезло, значит. Ну я теперь восполняю - я делал точно такое, ещё начиная с времён DEC RT-11 (тоже RTOS ;-)) и заканчивая QNX...
Ну и что - это что-то добавляет, что кто-то сказал?
Число проданных лицензий QNX (внедрений в устройствах, системах...) - что-то за 400000... Вы, скорее всего, держите в своих руках device-ы, не подозревая, что в них "унутрях" работает QNX: мобильные телефоны, так всеми любимые маршрутизаторы Cysko... Очень часто по реальной жизни пользователи узнают, что в их устройствах работает QNX, только когда после 5-10 лет эксплуатации оно ломается, и его несут в ремонт...
Первоначально опубликовано evgen
Даже обидно, панимаешь.
Так что - поводы для обиды сильно преувеличены! :D
Первоначально опубликовано evgen
Наследуется.
Может, гипотетически, и наследуется (MS нашептала? ;-)) - но какая разница:
- если вызов API ядра (r0) не может быть прерван до своего завершения...
- то какая разница? на каком приоритете это будет происходить?
Первоначально опубликовано evgen
инверсия приоритетов возможна для класса normal, для server и time-critial - нет - там приоритеты абсолютные и шедулер другой. Деталей я уже не помню, а особо сильно в них не вдавался. Для Normal есть еще MAXWAIT - если в течении такого времени нитка не получала управление, то система на один таймслайс поднимает ей приоритет
Про то, что инверсия приоритетов отсутствует - это вы из документации MS почерпнули? Все, кто это анализирует, пишут: "присутствует", а MS пишет "отсутствует"... "... не читайте большевистских газет перед едой..." (с).
Первоначально опубликовано evgen
Не пользуйте блокирующие вызовы и будет вам щастье.
Стандартные пайпы OS/2 совершенно спокойно живут под netbios'ом / netbios over ip.
Здесь "блокирующие-неблокирующие" - абсолютно не имеет отношения к тому, о чём я писал: TCP не в состоянии обнаружить обрыв канала непосредственно до операции ввода/вывода (когда обнаруживать, зачастую, уже поздно)... И это абсолютно не имеет отношения к способу осуществления ввода/вывода: синхронный, неблокирующий, по select, с использованием signal, асинхронный... - это принципиальная особенность TCP/IP, вытекающая из RFC, а не реализаций.
P.S. Есть способы обойти эту неприятность, но это именно "обойти" - это обмен периодическими пульсами по "молчащему" каналу, используя даже aut-of-band канал ... см. У.Стивенса "UNIX. Разработка сетевых приложений". Но всё это - сложно и громоздко.
А с пайпами, и "свободно" ... "это вам просто показалось" как говорилось в одном славном анекдоте ;-) - IP есть IP, и его функционирование определяется RFCs и ничем больше, не реализационными вещами: OS/2, netbios over ip, пайпы и т.д.- это всё только надстройки, и если у базиса нет какой-то возможности - то на верхних уровнях они уже не появятся!
Первоначально опубликовано Olej
Первоначально опубликовано evgen
По факту у меня получаются весьма hard-realtime системы на не hard-realtime OS - и оно работает в промышленных условиях.
1. а кто вам сказал что оно hard-realtime (или даже просто в любой мере realtime)? тестирование? Так тестирование ничего не может вообще доказать, кроме "отрицательного подтверждения". Это как соотношение: тестирование-верификация ПО: верификации можно доверять, тестированию - нет.
Область применения: управление приводами(2-4координаты) для лазерных систем. Любая запинка видна глазками, слышна ушками и чувствуется ручками.
Характерные времена - от суток до десятков наносекунд,
характерные размеры - от метров до долей микрона, причем не только измеряемые/программные, но управляемые.
Объясните дураку чем это не realtime системы
2. сам термин "весьма hard-realtime системы" - хорош! Это ещё один уровень градации - нечто среднее между "жёстким" и "мягким"? И потом, чтоб придать этой фразе завершённую торжественность, правильнее, наверное, так сказать: "По факту у меня получаются весьма hard-realtime системы на совершенно не realtime OS - и оно работает в промышленных условиях" ("... люблю отдельные красивые слова..." (с) Сатин - М.Горький "На дне").
3. а в отношениее "получаются весьма hard-realtime системы на не hard-realtime OS"... чудеса бывают в природе, но крайне редко (по крайней мере, так учат законы термодинамики):
- Я духов вызывать могу из бездны!
- Я тоже могу, вопрос только в том - явятся ли они на зов...
(с)У.Шекспир "Генрих IV".
Первоначально опубликовано Olej
Первоначально опубликовано evgen
Часть из приложений я описывал, и не только здесь. И почему-то никто не объявился и не сказал - у меня точно такое же, но под QNX.
Не повезло, значит. Ну я теперь восполняю - я делал точно такое, ещё начиная с времён DEC RT-11 (тоже RTOS ;-)) и заканчивая QNX...
Такое - что ?
1-Wire ? Во времена RT-11 его мягко говоря еще не было.
Первоначально опубликовано Olej
Число проданных лицензий QNX (внедрений в устройствах, системах...) - что-то за 400000...
ну повесте эту цифру вместо иконы и молитесь на нее...
Первоначально опубликовано Olej
Вы, скорее всего, держите в своих руках device-ы, не подозревая, что в них "унутрях" работает QNX: мобильные телефоны, так всеми любимые маршрутизаторы Cysko... Очень часто по реальной жизни пользователи узнают, что в их устройствах работает QNX, только когда после 5-10 лет эксплуатации оно ломается, и его несут в ремонт...
ну-ка, ну-ка... это в каком мобильнике внутри QNX ?
SY,
EK
Первоначально опубликовано Olej
Первоначально опубликовано evgen
Наследуется.
Может, гипотетически, и наследуется (MS нашептала? ;-)) - но какая разница:
- если вызов API ядра (r0) не может быть прерван до своего завершения...
- то какая разница? на каком приоритете это будет происходить?
Первоначально опубликовано evgen
инверсия приоритетов возможна для класса normal, для server и time-critial - нет - там приоритеты абсолютные и шедулер другой. Деталей я уже не помню, а особо сильно в них не вдавался. Для Normal есть еще MAXWAIT - если в течении такого времени нитка не получала управление, то система на один таймслайс поднимает ей приоритет
Про то, что инверсия приоритетов отсутствует - это вы из документации MS почерпнули? Все, кто это анализирует, пишут: "присутствует", а MS пишет "отсутствует"... "... не читайте большевистских газет перед едой..." (с).
SY,
EK
Етить. Одно неосторожное движение - и кю.
PS: The site forum.cta.ru is running Microsoft-IIS/5.0 on Windows 2000.
SY,
EK
Первоначально опубликовано Olej
Может, гипотетически, и наследуется (MS нашептала? ;-)) - но какая разница:
- если вызов API ядра (r0) не может быть прерван до своего завершения...
- то какая разница? на каком приоритете это будет происходить?
[...]
Про то, что инверсия приоритетов отсутствует - это вы из документации MS почерпнули? Все, кто это анализирует, пишут: "присутствует", а MS пишет "отсутствует"... "... не читайте большевистских газет перед едой..." (с).
Дядя, простниесь - какая такая MS ?
Почитамши на досуге книжек я вообще перестал понимать, что вы имеете ввиду под инверсией приоритетов и какие такие от нее проблемы применительно к OS/2 ? Или вы про свои юниксовые заморочки с nice подумали ?
SY,
EK
Первоначально опубликовано Olej
Первоначально опубликовано evgen
Не пользуйте блокирующие вызовы и будет вам щастье.
Стандартные пайпы OS/2 совершенно спокойно живут под netbios'ом / netbios over ip.
Здесь "блокирующие-неблокирующие" - абсолютно не имеет отношения к тому, о чём я писал: TCP не в состоянии обнаружить обрыв канала непосредственно до операции ввода/вывода (когда обнаруживать, зачастую, уже поздно)... И это абсолютно не имеет отношения к способу осуществления ввода/вывода: синхронный, неблокирующий, по select, с использованием signal, асинхронный... - это принципиальная особенность TCP/IP, вытекающая из RFC, а не реализаций.
P.S. Есть способы обойти эту неприятность, но это именно "обойти" - это обмен периодическими пульсами по "молчащему" каналу, используя даже aut-of-band канал ... см. У.Стивенса "UNIX. Разработка сетевых приложений". Но всё это - сложно и громоздко.
А с пайпами, и "свободно" ... "это вам просто показалось" как говорилось в одном славном анекдоте ;-) - IP есть IP, и его функционирование определяется RFCs и ничем больше, не реализационными вещами: OS/2, netbios over ip, пайпы и т.д.- это всё только надстройки, и если у базиса нет какой-то возможности - то на верхних уровнях они уже не появятся!
Я пайпы стандарно пользую по нетбиосу. Таймауты и ошибки при потере связи там есть и я думаю что оно точно также будет работать и для случая netbios over ip, тем более что у других оно работает. Как оно там реализовано - мне без большой разницы.
SY,
EK
Первоначально опубликовано evgen
Область применения: управление приводами(2-4координаты) для лазерных систем. Любая запинка видна глазками, слышна ушками и чувствуется ручками.
Характерные времена - от суток до десятков наносекунд,
характерные размеры - от метров до долей микрона, причем не только измеряемые/программные, но управляемые.
Объясните дураку чем это не realtime системы
То, что "работает" и "глазками" там что-то кому-то видно - это ещё, ну абсолютно, ни о чём не говорит. Возможно, вся система и выглядит как realtime, но, может, там весь управляющий процесс развивается как последовательностный... или ещё как подобно, что негативные эффекты no-realtime могут вообще не выявляться: такого поверхностного описания, что "там всё круто" - в постановочном плане явно недостаточно, чтоб либо утверждать (либо опровергать) что такая система требует realtime ПО.
Очень часто realtime требования выплывают в приложениях, в которых достаточно много логически параллельных ветвей исполнения 5-10 (но, кстати, и 100-200 thread тоже совершенно реально). Вот там в полную меру предмет обсуждения и вылезает...
Первоначально опубликовано evgen
Часть из приложений я описывал, и не только здесь. И почему-то никто не объявился и не сказал - у меня точно такое же, но под QNX.
Первоначально опубликовано Olej
Не повезло, значит. Ну я теперь восполняю - я делал точно такое, ещё начиная с времён DEC RT-11 (тоже RTOS ;-)) и заканчивая QNX...
Такое - что ?
1-Wire ? Во времена RT-11 его мягко говоря еще не было.
Юноша, я же не буду с вами спорить на ваших некорректных тонах... Хотя-бы потому, что "из 2-х дураков один должен, всё таки, быть умнее"(с). У вас есть технические соображения (озарения?) - излагайте.
А "такое" - это, например, код, который до сих пор работает в штатных изделиях систем ПВО/ПРО России (тогда СССР)... Это - "мягко говоря" ;-) - в те времена, когда вы изучали мироздание ещё по методике "не отрывая задницу от горшка"... :-). А после тех времён - ещё много, мнго и много...
Но это вся эта лирика - не аргументаци в выяснении технических нюансов.
Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме
