Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Получается ДОС=заведомо неудобная разработка и как следствие... 19.04.07 12:57 Число просмотров: 2035
Автор: 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%
> случаев (хотя и это не проблема многозадачных ОСей).
Думается, что в винде обработчик таймерного прерывания все-таки посложнее, чем в ДОСе, но и в ДОСе он (гад) вносит достаточную погрешность так, что с ним приходится бороться.
|
|
|
подробно о проекте
Анализ криптографических сетевых... 
