При сбое оборудования это может вызвать ряд симптомов. Скорее всего, это «синий экран смерти», но с меньшей легкостью могут появиться и другие симптомы. Чтобы получить более полное представление о том, как аппаратные средства могут воздействовать на несвязанные программы, рассмотрим модель операционной системы:
Программное обеспечение пользователя> Ядро> Уровень аппаратной абстракции> Оборудование
Любая программа, которая хочет взаимодействовать буквально с любым ресурсом, даже с процессором или оперативной памятью, должна взаимодействовать с ядром, что, в свою очередь, зависит от HAL для преобразования различных физических сигналов на аппаратное обеспечение и от него в логические сигналы к ядру и от него. ,
Ядро имеет определенные ограничения для "гарантии" стабильности, такие как ограниченная возможность повторного входа, безопасность потоков, ограничения ресурсов и так далее. В частности, большинство аппаратных средств не имеют концепции совместного использования; это обобщается на более высоком уровне через драйверы HAL или ядра.
Если вы помните времена модемов, только одна программа за раз могла использовать модем, например, номеронабиратель. Интернет обошел это путем создания общего стека - все программы, желающие получить доступ к Интернету, делали это через общий стек, и этот один стек имел исключительный контроль над оборудованием. Стек производит мультиплексирование для совместного использования этого ресурса.
Даже сегодня звуковые карты, дисководы, видеокарты и т.д. Физически не могут использоваться совместно. Сигналы запутаются, и наступит хаос. HAL проделывает довольно хорошую работу, заставляя пользователей думать, что на самом деле происходит больше, чем одна вещь одновременно. Есть еще физическое узкое место, которое есть, но мы обычно не замечаем его, когда аппаратное обеспечение работает так, как оно предназначено.
Но, чтобы понять суть проблемы, если у HAL есть проблема со связью с устройством, оно может быть заблокировано, когда оно пытается переслать или перечитать данные снова и снова. HAL также, как правило, не является многопоточным, поэтому он может обрабатывать только один запрос за раз (на цепочку драйверов).
Если драйвер диска заблокирован, попробуйте прочитать плохой диск, например, любая другая программа, которая пытается выполнить аналогичный вызов API, будет находиться в очереди за заблокированным вызовом, что может привести к зависанию этой программы. Многопоточные программы не будут иметь этой проблемы, потому что пользовательский интерфейс может оставаться отзывчивым, пока диск был заблокирован. К сожалению, большинство программ не являются многопоточными.
Многие программы в Windows в основном зацикливаются, например:
while(GetMessage(&msg, hWnd, NULL, NULL)) {
DispatchMessage(&msg);
}
Как вы можете догадаться, есть только одна нить. Как только он пытается прочитать с диска, который завис, он не может восстановиться, пока диск в конечном счете не истечет. Если это не так, эта программа зависит от API операционной системы. Даже если бы он был многопоточным, поток чтения с диска стал бы заблокированным, хотя поток пользовательского интерфейса мог бы обнаружить это и восстановить / прервать.
Чтобы усугубить проблему, многие вызовы API, такие как те, которые выделяют память, открывают диски или файлы и т.д., Являются блокирующими вызовами. Они заставляют текущий поток ждать неопределенно (если он не запрашивает определенное значение тайм-аута), пока ОС не сможет выполнить запрос или прервать его из-за тайм-аута. Большинство программ не предполагают, что ОС займет очень много времени, и поэтому никогда не указывают время ожидания. Эти программы никогда не восстановятся, если диск не отвечает.
Для программы, которая «никогда не обращается к неисправному диску», это не обязательно. Все, что нужно сделать, это вызвать функцию, которая в данный момент заблокирована неисправным диском. Например, если OpenFile был вызван на неисправном приводе DVD, другие запросы к файлам могут зависать до истечения времени ожидания привода DVD, даже если они читают только с системного диска.
Может быть, программа вызывает GetOpenFileName, который показывает отображаемое в ОС диалоговое окно, которое принимает управление потоком до его возврата. В этом окне перечислены все диски в системе путем перечисления списка дисков. Если API зависает на плохом диске, конечный результат остается тем же: диалоговое окно останавливается, останавливая все приложение, ожидая, когда этот диск станет доступным / свободным.
