Куда девается многозадачность Windows при опросе CD дисковода?

Чистого кода, коллеги!

Позволю себе задать "наивный" вопрос.
Куда девается многозадачность Windows, когда вы вставляете CD в дисковод? Почему оная так тормозит на этапе опроса дисковода? И какие организационно-программные выводы можно из этого сделать?

 

дай угадаю

у тебя привод на IDE ?

 

— Папа, а Windows многозадачная, а? Покажешь?
— Конечно покажу, доченька, только подожди немного: сейчас дискетка доформатируется.

 

Colibri
Разумеется IDE. Делаю наивные глаза и спрашиваю: "А USB-шные приводы Винды не тормозят?"

nerezus
Вот! Хотелось бы понять, почему болезнь старого интерфейса с флопами оказалась такой заразной.

 

Дело в том что в виндоусе вытесняющая много задачность. Так вот чтобы хоть както опросить дисковот найди авторан и прочее требуется вытеснить все задачи в том числе и в той которой работает пользователь иначе ничего не выйдет. Это большая недороботка $M.

 

Pavia

А почему? Ведь это не зависит ни от быстродействия проца, ни от памяти (дискетка. с СД-юком вроде все нормально). ДМА?

 

Если привод висит на том же канале IDE что и системный диск, возможны блокировки (на уровне IDE контроллера) - т.к. шина то одна и наличие на одном канале двух устройств означает не параллельность физическую, а временнОе разделение доступа, которое вешает второй девайс при некоторых монопольных или длящихся операциях.

 

не только CD
попробуйте создать вару с pre-allocated винтом гигов на 50
реально все кроме рейда замирает

имхо ДМА занимает шину на 100% и цпу просто стоит-отдыхает, исследует свой кэш

 

Тут всё вместе сказывается. Не в последнюю очередь -- невысокая эффективность винды при обработке аппаратных прерываний (кстати, этим страдает и линух, и прочие современные оси). Чтобы обрабатывать действительно эффективно, надо "закладываться" на особенности платформы и аппаратуры, а это делает соответствующую часть абсолютно непереносимой. ХАЛ тут не спасает: в него вынесены лишь отдельные функции, в то время как для скорости надо бы все драйверы таковыми делать, а также ряд общесистемных подпрограмм ядра. В общем, си масдай, асм рулит! Ну и кривые извилины с прямыми руками, есно

 

SII
Да тут дело скорее в том что виндоус хоть и работает с DMA. Но работает криво. Нужно делать асинхронный доступ к файлам. А ввиндоусе такого нет. Вот и весит проц ждет пока все не считает.

 

Gray

Это все фигня)) Вот куда девается многозадачность windows когда я отключаю свой телефон от USB? ) У меня на несколько секунд вообще все процессы замирают)) Звук, видео, рендеринг...))) Как будто кто-то поблизости начал жрать данон)))))

 

Хм, у меня такого нет. Но это уже не стоит вешать на винду - проблема может быть в драйвере устройства твоего. Драйвер можно написать так криво, что даже "крутизна" ОС не спасет. Ну, если драйвер конечно выполняется как часть ядра, а не как в Minix.

 

'IDE' - это в данном случае как противопоставление 'SATA'?

У меня IDE-привод, на отдельном канале. Если вставить диск и быстро открыть "Мой компьютер", то единственное, что подвиснет - это как раз открывшееся окно, да и то на секунду-три. Хотя если диск битый, то это окно может долго провисеть. Но всё остальное-то вполне многозадачно же. Правда, есть Гипер-Ниточность...

 

Думаю, что DMA здесь не при чем. Ибо винды сильно тормозятся именно при опросе дисковода после вставления в оный CD. Не так уж много при этом с диска читается - служебная информация о типе диска и корневой каталог.
Ведь при чтении с CD (например, при воспроизведении фильма) винды не столь уж сильно тормозят.
Более того, при форматировании флопи DMA практически не используется, а тормоз знатный получается.
Кстати, а под Вистой такое наблюдается?

 

Gray
У меня в голове вертится такая схема:

1. Процесс запрашивает данные с CD, как реакция на его вставку.
2. Управление передается драйверу, который усыпляет поток пока мотор не раскрутится.
3. Когда устройство становится готовым, оно оповещает драйвер и поток просыпается, выполняясь дальше.

Естественно, что на шаге 2 поток будет спать довольно продолжительное время. А вот насколько все приложение зависимо от этого потока, зависит уже от самого приложения.

Но это все чисто теоретически.

 

Sol_Ksacap
такаяже байда как и у меня, причем только изза сд привода на IDE.
Рар на сд всегда застряёт (когда выбираешь папку назначения) при разворачивании дерева...
Не понимаю зачем опрашивать сидиром при открытии окна, неужели нельзя кешировать с последнего доступа к нему, и не только к сд приводу а также и к дискам. Даже кеш самих устройств можно на это наладить раз в винде не всё гладко с этим, и кстати лишь разгонять движок при таком обращении к кешу, чтобы если юзверь выберет не другое дерево а именно сд привод то он былбы уже готов, иначе уже самообновил свой кеш на предмет содержимого. Кстати самообновлять свой кеш сд привод могбы при замене диска, не занимая при этом шину. Короче претензия сугубо к производителям приводов думаю, на их ответственности такие действия

 

Great
_DEN_

У меня тоже всё подвисает на ннадцать секунд, если завис GPRS, а это происходит регулярно. Ну а кривые драйвера -- это следствие кривой системы в целом. Нет, понятно, что под прямую систему можно написать кривой драйвер, и будут гарантированы проблемы, но они же возникают с теми же флопами и сидюками, а драйвера для них сами мелкомягкие клепают.

Кстати, у меня ещё вот какая мысля мелькнула... Тормозит при обращении к медленным дискам, так? А что с них читается? Что-то управляющее файловой системы. Ну а файловые системы поддерживаются специальными драйверами, а отнюдь не внешними по отношению к ядру программами. Если же этот драйвер подвис (ожидая данные), вполне резонно полагать, что подвиснет и всё остальное.

 

SII
Зависание системы это проблема виндоус и главная причина не продуманное планирование.

Помимо самих драйверов еще вызываются системные процессы, которые являются внешними приложениями и не должны исполняться в ядре. Но виснит все и на мертво.

А это не резонно это криворукость разработчиков драйверов. Которые должны были отдать проц время. И вообще такими вещами как планирование должна заниматься система(ОС, компилятор или что-то еще), а не програмист
Между прочем не так давно проскакивала статистика ошибок в драйверах висты. Так вот большая часть 29% пришлась на нвидиа, и чуть поменьше 19% на саму майкрософт.

 

у меня райд на нВидиа, так с дровами приходящими по апдейту на райд либо сата, система тупо виснет при загрузке винды. А стандартные и нВидиа дрова работают.
была проблема в их нТюне, тупо вешал систему при смене параметров (часто), но новая Perfomance работает ровно, так у майкрософт и первой проге аналогов небыло.
Естли сравнивать видео дрова с темже каталистом, то дрова нВидиа святые

 

6arrep
Это данные с бетты висты. После они были устраненны. Я привел эти цифры к тому, что в написании дров майкрософт не лучший показатель.