Операционные системы. Учебное пособие. Марапулец Ю.В. - 47 стр.

максимально возможное количество дескрипторов задач определяется в конфигураци-
онном файле CONFIG.SYS, а в Windows NT оно в явном виде не задается.
      В ОСРВ чаще всего количество процессов фиксируется и, следовательно, целесо-
образно заранее определять (на этапе генерации или конфигурирования ОС) количество
дескрипторов. Для использования таких ОС в качестве систем общего назначения обыч-
но количество дескрипторов берется с некоторым запасом, и появление новой задачи
связывается с заполнением этой информационной структуры. Поскольку дескрипторы
процессов постоянно располагаются в оперативной памяти, то их количество не должно
быть очень большим. При необходимости иметь большое количество задач один и тот
же дескриптор может в разное время предоставляться для разных задач, но это сильно
снижает скорость реагирования системы.
      Для более эффективной обработки данных в системах реального времени целесо-
образно иметь постоянные задачи, полностью или частично всегда существующие в сис-
теме независимо от того, поступило на них требование или нет [2]. Каждая постоянная
задача обладает некоторой собственной областью оперативной памяти (ОЗУ-
резидентные задачи) независимо от того, выполняется задача в данный момент или нет.
Эта область, в частности, может использоваться для хранения данных, полученных зада-
чей ранее. Данные могут храниться в ней и тогда, когда задача находится в состоянии
ожидания или даже в состоянии бездействия.
      Для аппаратной поддержки работы операционных систем с этими информацион-
ными структурами (дескрипторами задач) в процессорах могут быть реализованы соот-
ветствующие механизмы. Так, например, в микропроцессорах Intel 80х86, начиная с по-
коления 80286, имеется специальный регистр TR (task register), указывающий
местонахождение TSS (сегмента состояния задачи), в котором при переключении с зада-
чи на задачу автоматически сохраняется содержимое регистров процессора.
      Как ранее было указано процесс - отдельная задача, для которой операционная
системы выделяет необходимые ресурсы, такие как виртуальную память, процессорное
время и т.д. Такая обособленность нужна для того, чтобы защитить один процесс от дру-
гого, поскольку они, совместно используя все ресурсы вычислительной системы, конку-
рируют друг с другом. В общем случае процессы просто никак не связаны между собой
и могут принадлежать даже разным пользователям, разделяющим одну вычислительную
систему.
      Однако желательно иметь еще и возможность задействовать внутренний паралле-
лизм, который может быть в самих процессах. Такой внутренний параллелизм встреча-
ется достаточно часто и его использование позволяет ускорить их решение. Например,
некоторые операции, выполняемые приложением, могут требовать для своего исполне-
ния достаточно длительного использования центрального процессора. В этом случае при
интерактивной работе с приложением пользователь вынужден долго ожидать заверше-
ния заказанной операции и не может управлять приложением до тех пор, пока операция
не выполнится до самого конца. Такие ситуации встречаются достаточно часто, напри-
мер, при обработке больших изображений в графических редакторах. Если же про-
граммные модули, исполняющие такие длительные операции, оформлять в виде само-
стоятельных «подпроцессов» (потоков, тредов), которые будут выполняться
параллельно с другими «подпроцессами», то у пользователя появляется возможность
параллельно выполнять несколько операций в рамках одного приложения (процесса).
Операционная система не создает для потоков полноценную виртуальную машину. Эти
задачи не имеют своих собственных ресурсов, они развиваются в том же виртуальном
адресном пространстве, могут пользоваться теми же файлами, виртуальными устройст-
вами и иными ресурсами, что и данный процесс. Единственное, что им необходимо
иметь в самостоятельном пользовании - это процессорный ресурс. В однопроцессорной
системе потоки разделяют между собой процессорное время так же, как это делают


                                         49