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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Получается ДОС=заведомо неудобная разработка и как следствие... 19.04.07 12:57  Число просмотров: 1920
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 19.04.07 13:00  Количество правок: 5
<"чистая" ссылка>
[moved from humor]
> Более УДОБНАЯ разработка ВСЕГДА приводит к менее
> забаженному коду при равных затратах. Это закон такой.
> Затем и использовать.
Получается ДОС=заведомо неудобная разработка и, как следствие, забаженность?
> ????
> Ты сейчас о чем? Все мэйнлайновые многозадачные ОС-и сейчас
> используют преемптивную (вытесняющую) многозадачность. Если
> какой-то процесс (все его потоки) пытается работать слишком
> должно и не уходит в wait сам - его просто вытеснит
> шедулер. Процесс ничего не может с этим поделать.
О том, если наша задача обрабатывает события и при этом (вдруг :-) кушает много ЦПУ, то если какой-то другой задачке потребуется ЦПУ, то ОС передаст ей управление, причем с еще бОльшим приоритетом, поскольку она до этого находилась в состоянии ожидания, а наша прога не вовремя ореагирует на событие. Я уж не говорю о сервисах и драйверах, которые так и наравят перебить работу непрерываемой программы.
> Большинство многозадачных ОС тоже не лохи писали :-)
> Краткая справка: если поток добровольно отдал свой квант
> времени например вызовом WaitForSingleObject (в случае
> винды), то в случае перехода ожидаемого объекта в signalled
> state управление СРАЗУ ЖЕ передается ожидавшему потоку. Не
> дожидаясь даже выхода из функции SetEvent (например). Да
> еще и с возможным priority boost-ом (приоритет несколько
> повышается). Кстати о приоритетах. Система приоритетов сама
> по себе в значительной мере решает проблему, которая тебе
> видится в многозадачных ОС, а ведь в той же винде есть еще
> и реалтаймовые потоки. Они НЕ ВЫТЕСНЯЮТСЯ. Ни один
> нереалтаймовый поток не получит управление пока хоть один
> реалтаймовый находится в состоянии ready (то есть готов к
> исполнению). И это только юзермод. В драйвере ты вообще
> можешь поставить свой обработчик прерываний на устройство и
> получать управление со скоростью с которой процессор в
> принципе может обработать это прерывание.
Помню инструкцию по разработке драйверов для RSX-11, звучало примерно так: "Не забывайте, что при обработке прерывания нельзя выполнять более N инструкций. Если этого мало, то нужно понизить приоритет обработки до X уровня (уровня устройства), чтобы дать возможность быть обработаными не менее важные прерывания. Если же в этом режиме обработка продолжается более M инструкций, то необходимо продолжить обработку в режиме отложенных прерываний".
Интересно, писатели под винды придерживаются каких-либо правил? Я заранее в это не верю.
> Ровно наоборот. В досе писать сложнее как раз таки из-за
> отсутствия нормальных средств разработки.
Кому как. Хотя дело и не в том, в чем писать, а в том, под чем работать будет.
> Ровно наоборот. Я хочу не сам отрисовывать курсор мыши и
> кнопки во фреймбуфере, а просто сказать системе, что мне
> нужна кнопка с такой то надписью и получать от системы
> сообщения о ее нажатии.
Речь идет не о пользовательских задачах, а о спецоборудовании, построеном на базе ПК, а может даже о процессе разработки такового.
> Вряд ли какое периферийное устройство обеспечит тебе такую
> точность. Разве что сядешь напрямую на процессорную шину.
Да, типовые устройства дают микросекундные точности. Наносекунды даст только прямое подключение к процессору, но на процессорную шину сесть сложно.
> А вот еще один пример (на этот раз реальный): несколько
> десятков людей переоблучились (как минимум пятеро погибло)
> из-за бага в программе обслуживающей рентген-аппарат.
> http://en.wikipedia.org/wiki/Therac_25
Осторожно надо быть с такими опасными аппаратами. А на "Першинги" PDP-11 ставили.
> Неоттестированный (плохо оттестированный) кусок софта
> гораздо опаснее, чем просто не успевающий вовремя но в 100%
> случаев (хотя и это не проблема многозадачных ОСей).
Думается, что в винде обработчик таймерного прерывания все-таки посложнее, чем в ДОСе, но и в ДОСе он (гад) вносит достаточную погрешность так, что с ним приходится бороться.
<miscellaneous> Поиск 








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


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach