Название алгоритма навеяно, видимо, образом осторожного банкира, который выдает кредит только в том случае, если после этого сможет выполнить все свои обязательства даже в худшем случае. Явно не российский банкир.
Хотя данный алгоритм красив и логичен, у него есть, по меньшей мере, два недостатка. Во-первых, в современных ОС не принято требовать от процессов, чтобы те заранее объявляли свои будущие потребности в ресурсах. Во-вторых, выполнять проверку безопасности состояния при каждом запросе любого из процессов – слишком трудоемкое удовольствие.
Рассмотрим, наконец, третий подход – ликвидацию уже возникших тупиков, без попыток предотвратить их возникновение. В книге /2/ этот подход назван «алгоритмом страуса».
Здесь, прежде всего, возникает вопрос: как убедиться, что система действительно в тупике? Внешним признаком этого является длительное отсутствие какой-либо активности двух или более процессов. Но это недостоверный признак, процессы могли просто надолго задуматься над каким-нибудь трудоемким вычислением. Есть алгоритмы, которые анализируют текущее состояние процессов и ресурсов, наличие заблокированных запросов, и на этой основе ставят диагноз тупика. В принципе, такой алгоритм мог бы быть встроен в ОС. Однако в литературе нет сведений о том, чтобы это было осуществлено на практике. Обычно полагаются на волевое решение оператора или администратора системы.
Но пусть даже точно известно, что тупик есть. Как можно его устранить? Как «растащить баранов с моста»? Как правило, для этого применяется радикальное решение: принудительно прекратить один из тупиковых процессов (сбросить одного барана в реку). Если не помогло – утопить следующего барана. И т.д.
В литературе рассматриваются и более гуманные, но сложные способы. В принципе, можно регулярно запоминать состояние всех или только наиболее ответственных процессов в определенных контрольных точках или через определенные периоды времени. Тогда, вместо полного прекращения процесса, его можно вернуть к одной из последних контрольных точек и придержать там, пока другой баран не перейдет через реку.
Завершая рассмотрение проблемы тупиков, следует признать, что в настоящее время ее практическое значение значительно меньше, чем хотелось бы теоретикам. Во-первых, совсем не легко загнать в тупик современную ОС, работающую на компьютере с огромными ресурсами. В примере мы рассмотрели тупик, возникший из-за 100 Мб памяти, но если учесть еще несколько гигабайт, которые можно использовать в файле подкачки, то запросы процессов должны быть уж очень велики, чтобы привести к тупику. А, скажем, такое устройство, как принтер, в современных ОС вообще не может стать причиной тупика, т.к. система не отдает его во владение ни одному процессу даже на время.
Во-вторых, хотя тупик в принципе остается возможным, пользователь вряд ли даже заметит его. Скорее, он скажет «Опять Windows зависла!» и перезагрузит систему.
Предотвращение тупиков остается действительно важным, например, при разработке встроенной системы, которая должна длительное время безотказно работать без вмешательства человека.
4.4.1. Процессы в MS-DOS
Как говорилось выше, управление процессами в однозадачных ОС, к которым относится MS-DOS, является сравнительно тривиальной задачей.
Загрузка ОС завершается запуском программы командного интерпретатора COMMAND.COM, в задачи которого входит:
· чтение и анализ команд, вводимых пользователем с клавиатуры;
· выполнение внутренних команд системы, таких, как команда выдачи содержания каталога, команды копирования, удаления и переименования файлов и т.п.;
· запуск на выполнение системных и прикладных программ;
· обработка критических ошибок, происшедших в ходе выполнения системных функций MS-DOS;
· завершение работы программы с освобождением всех ресурсов, занимавшихся программой.
Запуская программу пользователя, COMMAND.COM не завершает собственную работу, а фактически переходит в состояние сна. После завершения запущенной программы COMMAND.COM возобновляет работу, выдавая приглашение к вводу следующей команды. Таким же образом программа пользователя может запустить другую программу и ожидать ее завершения. Количество одновременно присутствующих в системе процессов ограничено только размером памяти системы (не более 640 Кб на всех), однако только последняя запущенная программа может быть в активном (работающем) состоянии. Если же и эта программа блокируется на выполнении системной функции (например, ожидает ввода с клавиатуры), то в системе не остается активных процессов. Таким образом, термин «однозадачная ОС» в данном случае следует понимать как «ОС, допускающая не более одной активной задачи». Системе не приходится заниматься разделением процессорного времени и другими «многозадачными» проблемами, за исключением только сохранения и восстановления контекста родительской программы.
Некоторым исключением из правила «одна активная задача» являются резидентные программы MS-DOS, рассмотренные в п. 4.4.5.
Среда программы (environment; другой перевод – «окружение») представляет собой текстовый массив, состоящий из строк вида:
"переменная=значение", 0
Здесь переменная и значение – любые (в разумных пределах) текстовые величины, байт 0 завершает каждую строку.
Понятие среды было введено в системе UNIX и позаимствовано оттуда в MS-DOS и Windows без особых изменений.
Имеется несколько стандартных (системных) переменных среды, из которых наиболее известны PATH (определяет пути к каталогам, в которых система ищет исполняемый файл) и PROMPT (задает вид подсказки при диалоге с ОС). Кроме того, многие прикладные программы требуют для правильной работы, чтобы были заданы специфические переменные среды, описывающие, например, размещение рабочих каталогов программы, способ работы с расширенной памятью или какие-то иные характеристики режима работы программы.
Можно рассматривать переменные среды как своего рода параметры, передаваемые программе при ее запуске, аналогично тому, как подпрограмма получает параметры при вызове. Интерпретатор команд COMMAND.COM также имеет свою среду, которую называют корневой средой. Для создания переменных корневой среды, их удаления и изменения значений может использоваться системная команда SET. Когда COMMAND.COM запускает программу пользователя или одна программа запускает другую, создается порожденный процесс, который получает собственный экземпляр блока среды, при этом по умолчанию создается точная копия среды родителя, однако можно создать совершенно иную среду.
Одной из основных задач, которые должна решать система, является запуск программ на выполнение. Для этого предназначена системная функция Exec, которая может быть вызвана либо программой COMMAND.COM, выполняющей команду пользователя, либо непосредственно программой пользователя, через программное прерывание int 21h.
Функция Exec требует указания ряда параметров, из которых важны:
· Имя файла запускаемой программы. Если имя не содержит пути к каталогу, то файл ищется в текущем каталоге, а также в каталогах, перечисленных в переменной PATH.
· Командная строка. Так принято называть строку параметров, передаваемых программе. При запуске программы по команде пользователя командная строка задается после имени программы, она отделена от имени пробелом. Анализ содержимого командной строки полностью возлагается на запускаемую программу, система лишь передает эту строку программе.
· Адрес массива, содержащего параметры среды программы. Если он не задан, то для запускаемой программы создается копия среды программы-родителя.
В MS-DOS используются два формата выполняемых программ.
Файл формата COM содержит только коды позиционно-независимой программы, которая может быть без изменения загружена для исполнения по любому свободному адресу памяти. Все программа должна помещаться в единственном сегменте, поэтому размер файла ограничен 64 Кб.
Файл формата EXE представляет собой перемещаемую программу. Файл состоит из заголовка, словаря перемещений и собственно кода. Информация в заголовке позволяет указать размер части файла, которая должна загружаться в память при запуске программы, максимальный и минимальный размер памяти, дополнительно резервируемой для размещения данных, начальный адрес стека, адрес запуска программы. Размер файла практически не ограничен, но размер загружаемой части должен быть в пределах, предоставляемых DOS, т.е. примерно 500 – 550 Кб.
Первые два байта EXE-файла содержат сигнатуру (признак) файла формата EXE, в качестве которой используются две буквы 'MZ'[10]. Считается, что это инициалы программиста Марка Збиковского, который участвовал в разработке MS-DOS.
При запуске программы система выполняет следующие действия:
· Выделяет два непрерывных блока памяти: для параметров среды (блок среды) и для самой программы (блок PSP). Для программы, как правило, выделяется максимально возможный непрерывный блок памяти, если только в заголовке EXE-файла не задан меньший размер.
· Определяет размер загружаемой части программы (для COM-файла это весь файл), и считывает из файла коды программы.
· Для EXE-файла выполняет настройку программы на адрес загрузки, прибавляя этот адрес к тем местам программы, которые перечислены в словаре перемещений.
· Формирует в начале блока программы массив, который называется PSP (ProgramSegmentPrefix). В PSP содержатся, в частности, адрес блока среды, адрес возврата в родительскую программу, адрес и размер таблицы JFT, сама эта таблица, командная строка программы.
· Заполняет первые 5 элементов таблицы JFT (стандартные хэндлы), копируя их из JFT родительской программы.
· Заносит начальные значения в регистры процессора.