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