Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Более удобная разработка всегда приводит к менее... 19.04.07 11:30 Число просмотров: 2345
Автор: amirul <Serge> Статус: The Elderman
|
[moved from humor] > 1. Если для решения задачи хватает ДОСа, то зачем > использовать что-то более монстрическое.
Более УДОБНАЯ разработка ВСЕГДА приводит к менее забаженному коду при равных затратах. Это закон такой. Затем и использовать.
> 2. Есть такие задачи, которые нельзя решить в многозадачных > системах. Например главную программу может не устроить, что > какая-то другая программа может использовать процессорный > ресурс достаточно длительное время, тем самым главная > программа на некоторое время "зависнет".
????
Ты сейчас о чем? Все мэйнлайновые многозадачные ОС-и сейчас используют преемптивную (вытесняющую) многозадачность. Если какой-то процесс (все его потоки) пытается работать слишком должно и не уходит в wait сам - его просто вытеснит шедулер. Процесс ничего не может с этим поделать.
> 3. ДОС позволяет добиться реалтаймовости и мгновенного > реагирования на события.
Большинство многозадачных ОС тоже не лохи писали :-)
Краткая справка: если поток добровольно отдал свой квант времени например вызовом WaitForSingleObject (в случае винды), то в случае перехода ожидаемого объекта в signalled state управление СРАЗУ ЖЕ передается ожидавшему потоку. Не дожидаясь даже выхода из функции SetEvent (например). Да еще и с возможным priority boost-ом (приоритет несколько повышается). Кстати о приоритетах. Система приоритетов сама по себе в значительной мере решает проблему, которая тебе видится в многозадачных ОС, а ведь в той же винде есть еще и реалтаймовые потоки. Они НЕ ВЫТЕСНЯЮТСЯ. Ни один нереалтаймовый поток не получит управление пока хоть один реалтаймовый находится в состоянии ready (то есть готов к исполнению). И это только юзермод. В драйвере ты вообще можешь поставить свой обработчик прерываний на устройство и получать управление со скоростью с которой процессор в принципе может обработать это прерывание.
> 4. В принципе можно и без ДОСа, но тогда реализовать задачу > будет чуть сложнее. Ведь в большинстве случаев, используя
Ровно наоборот. В досе писать сложнее как раз таки из-за отсутствия нормальных средств разработки.
> ДОС, задачу проше запускать (иначе через перезагрузку), > задаче проще сохранять информацию в файл, задаче проще > работать с вводом/выводом (экран и кнопки, например).
Ровно наоборот. Я хочу не сам отрисовывать курсор мыши и кнопки во фреймбуфере, а просто сказать системе, что мне нужна кнопка с такой то надписью и получать от системы сообщения о ее нажатии.
> Вот пример: используем компьютер в качестве > диагностического оборудования. Используем именно то > свойство компа, что он может реагировать на электрические > импульсы и с тосностью до наносекунд определять интервалы
Вряд ли какое периферийное устройство обеспечит тебе такую точность. Разве что сядешь напрямую на процессорную шину.
> между ними, а так же накапливать эту информацию для > статистической обработки, результаты которой и будут > "диагнозом". Точной работе не нужна многопользовательность, > а многозадачность будет только мешать. Скажу откровенно, > даже в ДОСе приходится бороться с "помехами", а именно > запрещать прерывания от таймера, а потом корректировать > системное время.
А вот еще один пример (на этот раз реальный): несколько десятков людей переоблучились (как минимум пятеро погибло) из-за бага в программе обслуживающей рентген-аппарат.
http://en.wikipedia.org/wiki/Therac_25
Неоттестированный (плохо оттестированный) кусок софта гораздо опаснее, чем просто не успевающий вовремя но в 100% случаев (хотя и это не проблема многозадачных ОСей).
|
|
|