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