Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
СПО_лекции_ЗФ.docx
Скачиваний:
61
Добавлен:
16.03.2016
Размер:
519.74 Кб
Скачать

Идентификация процесса

Для того чтобы ОС могла управлять процессами, она должна располагать всей необходимой для этого информацией. С этой целью на каждый процесс заводится специальная информационная структура, называемая дескриптором процесса (описателем задачи, блоком управления задачей). В общем случае дескриптор процесса содержит следующую информацию:

  • идентификатор процесса (так называемый PID – process identificator);

  • тип (или класс) процесса, который определяет для супервизора некоторые правила предоставления ресурсов;

  • приоритет процесса, в соответствии с которым супервизор предоставляет ресурсы. В рамках одного класса процессов в первую очередь обслуживаются более приоритетные процессы;

  • переменную состояния, которая определяет, в каком состоянии находится процесс (готов к работе, в состоянии выполнения, ожидание устройства ввода/вывода и т. д.);

  • защищённую область памяти (или адрес такой зоны), в которой хранятся текущие значения регистров процессора, если процесс прерывается, не закончив работы. Эта информация называется контекстом задачи;

  • информацию о ресурсах, которыми процесс владеет и/или имеет право пользоваться (указатели на открытые файлы, информация о незавершенных операциях ввода/вывода, т.п.);

  • место (или его адрес) для организации общения с другими процессами;

  • параметры времени запуска (момент времени, когда процесс должен активизироваться, и периодичность этой процедуры);

  • в случае отсутствия системы управления файлами – адрес задачи на диске в её исходном состоянии и адрес на диске, куда она выгружается из оперативной памяти, если её вытесняет другая (для диск-резидентных задач, которые постоянно находятся во внешней памяти на системном магнитном диске и загружаются в оперативную память только на время выполнения).

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

В некоторых ОС количество описателей определяется жестко и заранее (на этапе генерации варианта операционной системы или в конфигурационном файле, который используется при загрузке ОС), в других – по мере необходимости система может выделять участки памяти под новые описатели. Например, в OS/2 максимально возможное количество описателей задач определяется в конфигурационном файле CONFIG.SYS. Следует отметить, что в данном файле указывается количество не процессов, а именно задач, и под задачей в данном случае понимается как процесс, так и поток этого же процесса. Например, строка в файле CONFIG.SYS

THREADS=1024

указывает, что всего в системе может параллельно существовать и выполняться до 1024 задач, включая вычислительные процессы и их потоки.

В ОСРВ зачастую количество процессов фиксируется и целесообразно заранее определять (на этапе генерации или конфигурирования ОС) их количество. Поскольку дескрипторы процессов постоянно располагаются в оперативной памяти (с целью ускорить работу диспетчера), то их количество не должно быть большим. При необходимости иметь большое количество задач один и тот же дескриптор может в разное время предоставляться для разных задач, но это сильно снижает скорость реагирования системы.

Для более эффективной обработки данных в ОСРВ целесообразно иметь постоянные задачи полностью или частично всегда существующие в системе независимо от того, поступило на них требование или нет. Каждая постоянная задача обладает некоторой собственной областью оперативной памяти (ОЗУ-резидентные задачи) независимо от того, выполняется задача в данный момент или нет. Эта область, в частности, может использоваться для хранения данных, полученных задачей ранее. Данные могут храниться в ней и тогда, когда задача находится в состоянии ожидания или даже в состоянии бездействия.

Понятие процесса было введено для реализации идей мультипрограммирования.

Мультипрограммный режим работы вычислительной системы заключается в том, что пока одна программа (процесс, задача) ожидает завершения очередной операции ввода/вывода, другая программа (задача) может быть поставлена на выполнение. При мультипрограммировании повышается пропускная способность системы, но отдельный процесс никогда не может быть выполнен быстрее, чем, если бы он выполнялся в однопрограммном режиме.

Когда говорят о процессах, то тем самым хотят отметить, что ОС поддерживает их обособленность: у каждого процесса имеется свое виртуальное адресное пространство, каждому процессу назначаются свои ресурсы (файлы, окна, семафоры и т.д.). Такая обособленность нужна для того, чтобы защитить один процесс от другого, поскольку они, совместно используя все ресурсы вычислительной системы, конкурируют друг с другом. В общем случае процессы никак не связаны между собой и могут принадлежать даже разным пользователям, разделяющим одну вычислительную систему. Другими словами, ОС считает процессы совершенно несвязанными и независимыми. При этом именно ОС регулирует конкуренцию между процессами по поводу ресурсов.

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

Если же программные модули, исполняющие длительные операции, оформлять в виде самостоятельных «подпроцессов», которые будут выполняться параллельно с другими «подпроцессами», то у пользователя появляется возможность параллельно выполнять несколько операций в рамках одного приложения (процесса). «Подпроцессы» это и есть нити или, как встречается в литературе, треды (thread). Еще одним синонимом, встречающимся в литературе, является поток. Легковесными их называют потому, что ОС не должна для них организовывать полноценную виртуальную машину. Эти задачи:

  • не имеют своих собственных ресурсов;

  • они развиваются в том же виртуальном адресном пространстве;

  • могут пользоваться теми же файлами, виртуальными устройствами и иными ресурсами, что и данный процесс.

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

Особенно эффективно можно использовать многопоточность для выполнения распределённых приложений; например, многопоточный сервер может параллельно выполнять запросы сразу нескольких клиентов.

Вследствие того, что треды, относящиеся к одному процессу, выполняются в одном и том же виртуальном адресном пространстве, между ними легко организовать тесное взаимодействие, в отличие от процессов, для которых нужны специальные механизмы обмена сообщениями и данными. Более того, программист, создающий многопоточное приложение, может заранее продумать работу множества тредов процесса таким образом, чтобы они могли взаимодействовать наиболее выгодным способом, а не участвовать в конкуренции за предоставление ресурсов тогда, когда этого можно избежать.

Итак, к достоинствам многопоточности в программировании можно отнести следующее:

  • упрощение программы в некоторых случаях, за счет использования общего адресного пространства;

  • меньшие относительно процесса временные затраты на создание потока;

  • повышение производительности процесса за счет распараллеливания процессорных вычислений и операций ввода/вывода.