информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медSpanning Tree Protocol: недокументированное применениеАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Блокировка российских аккаунтов... 
 Отзыв сертификатов ЦБ РФ, ПСБ,... 
 Памятка мирным людям во время информационной... 
главная обзор 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 13:21  Число просмотров: 1924
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
[moved from humor]
> Получается ДОС=заведомо неудобная разработка и как
> следствие забаженость?

Да. Можно сформулировать по другому: для достижения одинакового уровня забаженности на менее удобном интрументарии придется затратить больше ресурсов (в том числе и временнЫх), чем на более удобном.

> О том, если наша задача обрабатывает события и при это
> (вдруг :-) кушает много ЦПУ, то если какой-то другой
> задачке потребуется ЦПУ, то ОС передаст ей управление,
> причем с еще бОльшим приоритетом, поскольку она до этого

Ага. А вот теперь нам поведают о том как подобные проблемы (необходимость одновременной обработки двух разных событий) с легкостью решаются в ДОС-е :-)

> находилась в состоянии ожидания, а наша прога не вовремя
> ореагирует на событие. Я уж не говорю о сервисах и
> драйверах, которые так и наравят перебить работу
> непрерываемой программы.

Никто не норовит. Сервисы - являются обычными процессами. А драйверы вообще не ни при чем. Единицей исполнения является поток. Драйвер конечно может создать рабочий поток, но это будет такой же поток как и все остальные потоки в системе: со своим приоритетом и возможностью вытеснить.

> Помню инструкцию по разработке драйверов для RSX-11,
> звучало примерно так: "Не забывайте, что при обработке
> прерывания нельзя ваполнять более N инструкций. Если этого
> мало, то нужно понизить приоритет обработки до X уровня
> (уровня устройства), чтобы дать возможность быть
> обработаными не менее важные прерывания. Если же в это
> режиме обработка продолжается более M инструкций, то
> необходимо продолжить обработку в режиме отложенных
> прерываний".
> Интересно, писатели под винды придерживаются каких-либо
> правил? Я заранее в это не верю.

Зря не веришь. Есть рекомендация не задерживаться в обработчике прерывания больше N микросекунд. Всю остальную работу производить в DPC (deferred procedure call). Как раз именно потому, что прерывания от девайсов маскируют прерывания с более низким IRQL. Надо вычитать всю неотложную информацию из портов и поставить DPC - дальше вся работа будет производиться на DISPATCH_LEVEL-е.

"Because ISRs must execute as quickly as possible, drivers must usually postpone the completion of servicing an interrupt until after the ISR returns. Therefore, the system provides support for deferred procedure calls (DPCs), which can be queued from ISRs and which are executed at a later time and a lower IRQL than the ISR."

> Кому как. Хотя дело и не в том, в чем писать, а в том, под
> чем работать будет.

Дело именно в средствах разработки. Писать под винду во многом даже проще, чем под дос (например, работа с памятью)

> Речь идет не о пользовательских задачах, а о
> спецоборудовании, построеном на базе ПК, а может даже о
> процессе разработки такового.

Не вижу проблем для общения со спецоборудованием.

> Думается, что в винде обработчик таймерного прерывания
> все-таки посложнее, чем в ДОСе, но и в ДОСе он (гад) вносит
> достаточную погрешность так, что с ним приходится бороться.

Прикол в том, что даже если это и скажется на работе, оно скажется сразу же - при первом же тестировании. А вот другие (неявные) проблемы (которые могут быть и при досовой и при "многозадачной" разработке) лечге тестить и отлавливать при наличии хороших средств разработки.
<miscellaneous> Поиск 






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


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach