информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяГде водятся OGRыСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
 Рекордное число уязвимостей в 2021 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
NT и линух никак не могут быть реалтаймовыми, что бы там ни говорил пеар 20.08.07 15:46  Число просмотров: 4002
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> ОСРВ многозадачны по определению, считать инструкции не
> очень имеет смысл... И ОСРВ не пишутся под конкретную
> платформу, что тоже умаляет смысл подсчёта времени
> исполнения каждой процедуры.
> Другое дело, что щедулер там весьма детерминированный, и
> можно немножко представлять, «что будет, если». В тех

Отличие здесь далеко не в шедулере, тем более что в ОСРВ и обычных алгоритмы шедулинга примерно одинаковые.

> > Так что позвольте с вами не согласиться. Да и вообще,
> по
> > моему правильным будет при наступлении события
> обработать
> > его, а не поставить в очередь, чтоб обработать
> как-нибудь
> > потом. В результате имеем то, что окошко появляется
> спустя
> > минуту, после того, как кликнешь по ярлычку :-).

Это не тебе (тут двойное цитирование), но отвечу здесь, чтобы не плодить ветки - это вообще ни к селу ни к городу :-)
Окошко появляется минуту спустя потому, что люди пишут на всяком отстое типа делфи, VB или в лучшем случае Java/.Net, а не потому, что ядро ОС плохое.

> Событий нет в компьютерах самих по себе, это абстракции ОС
> или программиста. А прерывания, что являются реальными
> событиями в компьютерах, не являются этими абстракциями,
> они лишь «заготовки» для них. Прерывания вообще-то претят
> общей идеологии процессов в ОС. И что обычная ОС, что ОСРВ
> стремятся обработать прерывания как можно быстрее,
> переложив дальнейшую обработку на «потом». Те же «события»
> могут ждать, к примеру, несколько процессов, а процессор
> один, как прикажете обработать событие «сразу»? ;-)

Отож бо й воно.

> Всё это к тому, что «потом» в обычной ОС менее
> детерминировано, чем в ОСРВ, о чём я написал чуть выше.
> Вокруг ОСРВ вообще много всякого странного пеара...
> К примеру, был патчи для NT4 сторонних производителей...
> Превращающие эту ОС в ОСРВ, т.е. поставил патч и
> пользуешься новыми реалтаймовыми функциями ядра на
> здоровье... Есть ещё всякие интересные понятия жёсткого и

Вот здесь собственно и сабж. Это сейчас модно подмазывать к какому нибудь раскрученному понятию, смысл которого все равно никто не понимает. Ни "реалтаймовая" NT ни RTLinux не являются реалтаймовыми ОС. Это системы с монолитным (что не мешает им быть модульными) ядром, значит все модули ядра (драйверы) работают в том же контексте безопасности, что и само ядро. А если любой third party драйвер может просто запретить все прерывания и войти в бесконечный цикл, то о каком гарантированном времени отлика может идти речь?

> мягкого риалтайма...
> В общем, мир снова не чёрно-белый, а цветной и всякоразный
> ;-)

Ага :-)
Даже в случае монолитных ядер не все так запущенно, как я написал :-)
Принекоторыхусловиях монолитное ядро может быть реалтаймовым. В частности, если запрещена загрузка любых third party драйверов. Однако, чем больше ядро (в ядро нужно включить не только непосредственно ядро, но и все драйвера, работающие на одном уровне безопасности с ним), тем выше вероятность ошибки в реализации (даже если архитектрура в принципе допускает реалтаймовость) при которой гарантированное время отклика ни фига не гарантируется.

Собственно именно поэтому ОС реального времени стоит искать только среди микроядерных ОС
<theory> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach