4.2. Основные функциональные компоненты ОС автономного компьютера
— по типам локальных ресурсов, которыми управляет ОС; соответствующие подсистемы – подсистемы управления ресурсами ;
Основные подсистемы управления ресурсами – это подсистемы:
· управления файлами и внешними устройствами.
Общие для всех ресурсов – это подсистемы:
· прикладного программного и пользовательского интерфейсов;
· защиты данных и администрирования.
Во вводной части (см. п. 1) при описании функций ОС фактически были перечислены функции этих подсистем. Охарактеризуем их и далее перейдем к их рассмотрению в рамках отдельных тем.
Эта подсистема – важнейшая часть ОС.
Подсистема управления процессами планирует выполнение процессов и выполняет следующие функции:
— распределяет процессорное время между несколькими одновременно существующими в системе процессами;
— занимается созданием, переключением состояния и уничтожением процессов;
— обеспечивает процессы необходимыми системными ресурсами;
— поддерживает синхронизацию процессов;
— обеспечивает взаимодействие процессов.
Функциями подсистемы управления памятью являются:
— отслеживание свободной и занятой памяти;
— выделение памяти процессам и ее освобождение при завершении процесса;
— защита памяти процесса;
— вытеснение процессов из оперативной памяти на диск при ее нехватке и возвращение в оперативную память при освобождении места в ней (механизм виртуальной памяти );
— настройка адресов программы на конкретную область физической памяти.
· Управление файлами и внешними устройствами
Файловая система выполняет преобразование символьных имен файлов в физические адреса данных на диске, организует совместный доступ к файлам, защищает их от несанкционированного доступа.
Таким образом, ОС поддерживает высокоуровневый унифицированный интерфейс для написания прикладных программ. Со времени появления ОС Unix этот интерфейс в большинстве систем строится на концепции файлового доступа : обмен с внешним устройством выглядит как обмен с файлом. В качестве файла может выступать как реальный файл на диске, так и алфавитно-цифровой терминал, принтер или сетевой адаптер. Реальная аппаратура подменяется удобными для пользователя и программиста абстракциями.
· Интерфейс прикладного программирования и пользовательский интерфейс
Под интерфейсом прикладного программирования понимаются средства, предоставляемые операционной системой для обращения к ее возможностям при написании приложений. Традиционно термин «прикладное программирование» использовался как противоположный «системному программированию». Относительное различие системного и прикладного программирования заключается в том, что путем создания программ первое предполагает расширение возможностей операционной системы, а второе – решение задач из конкретной проблемной области. В данном случае это различие несущественно.
В программах обращения к ОС используются по крайней мере в следующих случаях:
— для выполнения действий с особым статусом, которым обладает только ОС (например, для управления аппаратными средствами компьютера); обычно это необходимо для более эффективного использования аппаратных ресурсов;
— для упрощения написания приложений посредством использования готовых отлаженных сервисных функций ОС, реализующих часто требующиеся универсальные действия.
Возможности ОС доступны программисту в виде набора функций, называющегося API (Application Programming Interface, интерфейс прикладного программирования). При этом для разработчика приложений все особенности конкретной ОС представлены особенностями ее API, поэтому операционные системы с различной внутренней организацией, но с одинаковым набором функций API представляются на этом уровне как одна ОС. Это упрощает стандартизацию ОС и обеспечивает переносимость приложений в рамках ОС одного стандарта. Например, следование общим стандартам API Unix позволяет говорить о некоторой обобщенной ОС Unix при существенных различиях внутренней организации версий этой ОС от разных производителей.
ОС Windows поддерживает объектно-ориентированный стиль программирования. Объектами являются окна. Поэтому работа с системными функциями Windows может осуществляться по тем же правилам, что и с пользовательскими функциями. Например, программу с использованием системных функций Windows можно реализовать в среде Delphi или на С++.
Функции WinAPI находятся в системных загружаемых библиотеках, таких как system32.dll, kernel32.dll, user32.dll, gdi32.dll и др. (каталог g:\ WINDOWS\system32). Эти библиотеки используются самой ОС, поэтому они всегда находятся в памяти. Каждое приложение должно самостоятельно подключать библиотеки, содержащие необходимые ему функции.
Описания функций WinAPI на языке Си можно посмотреть через меню Пуск / Программы /Borland Delphi 7/Help/MS SDK Help Files/Win32 Developer’s References.
uses windows, messages;
Фрагмент модуля windows с описанием рассматриваемой функции ( файл g:\Program Files\Borland\Delphi7\Source\Rtl\Win\Windows. pas):
Под архитектурной операционной системы понимают структурную и функциональную организацию ОС на основе некоторой совокупности программных модулей. В состав ОС входят исполняемые и объектные модули стандартных для данной ОС форматов, программные модули специального формата (например, загрузчик ОС, драйверы ввода-вывода ), конфигурационные файлы, файлы документации, модули справочной системы и т.д.
На архитектуру ранних операционных систем обращалось мало внимания: во-первых, ни у кого не было опыта в разработке больших программных систем, а во-вторых, проблема взаимозависимости и взаимодействия модулей недооценивались. В подобных монолитных ОС почти все процедуры могли вызывать одна другую. Такое отсутствие структуры было несовместимо с расширением операционных систем. Первая версия ОС OS/360 была создана коллективом из 5000 человек за 5 лет и содержала более 1 млн строк кода. Разработанная несколько позже операционная система Multics содержала к 1975 году уже 20 млн строк. Стало ясно, что разработка таких систем должна вестись на основе модульного программирования.
Большинство современных ОС представляют собой хорошо структурированное модульные системы, способные к развитию, расширению и переносу на новые платформы. Какой-либо единой унифицированной архитектуры ОС не существует, но известны универсальные подходы к структурированию ОС. Принципиально важными универсальными подходами к разработке архитектуры ОС являются [4, 13, 22]:
Первые ОС разрабатывались как монолитные системы без четко выраженной структуры (рис.3.4).
Для построения монолитной системы необходимо скомпилировать все отдельные процедуры, а затем связать их вместе в единый объектный файл с помощью компоновщика (примерами могут служить ранние версии ядра UNIX или Novell NetWare). Каждая процедура видит любую другую процедуру (в отличие от структуры, содержащей модули, в которой большая часть информации является локальной для модуля, процедуры модуля можно вызвать только через специально определенные точки входа).
Такая организация ОС предполагает следующую структуру [28]:
В этой модели для каждого системного вызова имеется одна сервисная процедура. Утилиты выполняют функции, которые нужны нескольким сервисным процедурам. Это деление процедур на три слоя показано на рис.3.5.
Для обеспечения высокой скорости работы ОС модули ядра ( по крайней мере, большая их часть) являются резидентными и работают в привилегированном режиме ( Kernel mode ). Этот режим обеспечивает, вопервых, безопасность работы самой ОС от вмешательства приложений, и, во-вторых, возможность работы модулей ядра с полным набором машинных инструкций, позволяющих собственно ядру выполнять управление ресурсами компьютера, в частности, переключение процессора с задачи на задачу, управление устройствами ввода-вывода, распределением и защитой памяти и др.
Вспомогательные модули обычно подразделяются на группы:
Многослойная структура ядра ОС может быть представлена, например, вариантом, показанным на рис.3.6.
В данной схеме выделены следующие слои.
Многослойная классическая многоуровневая архитектура ОС не лишена своих проблем. Дело в том, что значительные изменения одного из уровней могут иметь трудно предвидимое влияние на смежные уровни. Кроме того, многочисленные взаимодействия между соседними уровнями усложняют обеспечение безопасности. Поэтому, как альтернатива классическому варианту архитектуры ОС, часто используется микроядерная архитектура ОС.
Схематично механизм обращений к функциям ОС, оформленным в виде серверов, выглядит, как показано на рис.3.9.
Схема смены режимов при выполнении системного вызова в ОС с микроядерной архитектурой выглядит, как показано на рис.3.10.
Из рисунка ясно, что выполнение системного вызова сопровождается четырьмя переключениями режимов (4 t), в то время как в классической архитектуре – двумя. Следовательно, производительность ОС с микроядерной архитектурой при прочих равных условиях будет ниже, чем у ОС с классическим ядром.
В то же время признаны следующие достоинства микроядерной архитектуры [36]:
По многим источникам вопрос масштабов потери производительности в микроядерных ОС является спорным. Многое зависит от размеров и функциональных возможностей микроядра. Избирательное увеличение функциональности микроядра приводит к снижению количества переключений между режимами системы, а также переключений адресных пространств процессов.
Может быть, это покажется парадоксальным, но есть и такой подход к микроядерной ОС, как уменьшение микроядра.
Для возможности представления о размерах микроядер операционных систем в ряде источников [22] приводятся такие данные:
В современных операционных системах различают следующие виды ядер.
Наиболее тесно элементы микроядерной архитектуры и элементы монолитного ядра переплетены в ядре Windows NT. Хотя Windows NT часто называют микроядерной операционной системой, это не совсем так. Микроядро NT слишком велико (более 1Мбайт), чтобы носить приставку «микро». Компоненты ядра Windows NT располагаются в вытесняемой памяти и взаимодействуют друг с другом путем передачи сообщений, как и положено в микроядерных операционных системах. В то же время все компоненты ядра работают в одном адресном пространстве и активно используют общие структуры данных, что свойственно операционным системам с монолитным ядром.
Комплект тестов по учебной дисциплине Операционные системы
Комплект тестов по учебной дисциплине «Операционные системы»
В1 Системная служебная программа, выполняющая анализ локальных томов с последующим поиском и объединением фрагментированных файлов и папок называется…
В2 Установите соответствие между задачами и функциями интерфейса операционной системы ЗАДАЧА ФУНКЦИЯ
А Управление процессами 1 запрос на управление виртуальными устройствами
Б Управление памятью 2 запрос на выделение блока памяти
В Управление вводом-выводом 3 запуск, приостанов и снятие задачи с выполнения
Запишите в таблицу выбранные цифры
В1 Среда, в которой выполняются прикладные программы пользователей называется…
В2 Установите соответствие между командой и ее описанием: к каждойпозиции первого столбца подберите соответствующую позицию из второго столбца, обозначенную цифрой.
ОПИСАНИЕ
А adduser
Г date
1 показывает нынешние дату и время, по системным часам ядра
2 изменение пароля пользователя
3 создание нового пользователя
Запишите в таблицу выбранные цифры.
Эталон ответов для проверки результатов педагогических измерений «Операционные системы»
Подсистема управления процессами – важнейшая часть ОС. Процесс кратко можно определить как «программу в стадии выполнения». Реально это некоторый исполняемый код, содержащий обращения к функциям операционной системы и через их посредство получающий доступ к ресурсам. Таким образом, процесс можно также определить как некоторую заявку на потребление системных ресурсов.
Подсистема управления процессами планирует выполнение процессов и выполняет следующие функции:
· распределяет процессорное время между несколькими одновременно существующими в системе процессами;
· занимается созданием, переключением состояния и уничтожением процессов;
· обеспечивает процессы необходимыми системными ресурсами;
· поддерживает синхронизацию процессов;
· обеспечивает взаимодействие процессов.
Многозадачность – способ организации вычислительного процесса, при котором на одном процессоре попеременно выполняются сразу несколько программ.
Цель минимизация простоев устройств компьютера
Приложения используют совместно не только процессор, но и другие ресурсы компьютера: оперативную память, устройства ввода-вывода, данные. Мультипрограммирование призвано повысить эффективность использования вычислительной системы.
Характерные критерии производительности:
· Удобство работы пользователя, заключающееся, в том, что они имеют возможность интерактивно работать одновременно с несколькими приложениями на одной машине;
Многозадачность в системах пакетной обработки
Системы пакетной обработки предназначались в основном для решения задач вычислительного характера, не требующих быстрого получения результатов. Главным критерием эффективности систем пакетной обработки является максимальная пропускная способность, то есть решение максимального числа задач в единицу времени.
Для достижения этой цели используется следующая схема: сначала формируется пакет заданий, каждое задание содержит требования к системным ресурсам; из этого пакета формируется мультипрограммная смесь. Для одновременного выполнения выбираются задачи, предъявляющие разные требования к ресурсам, так чтобы обеспечить сбалансированную загрузку всех устройств вычислительной машины. Таким образом, выбор нового задания осуществляется на основании текущего состояния системы, то есть выбирается выгодное задание. Следовательно, в вычислительных системах, работающих под управлением пакетных ОС, невозможно гарантировать выполнение того или иного задания в течение определенного времени.
Если посмотреть на совмещение во времени операций ввода-вывода и вычислений, то можно представить себе несколько различных способов. Один их них характерен для систем с выделенным процессором ввода-вывода. В мэйнфреймах процессоры ввода-вывода называются каналами. Обычно канал имеет систему команд, отличающуюся от системы команд центрального процессора. Эти команды специально предназначены для управления внешними устройствами. Канальные программы могут храниться в той же оперативной памяти, что и программы центрального процессора. В системе команд центрального процессора предусмотрена специальная инструкция, с помощью которой каналу передаются параметры и указания на то, какую программу ввода-вывода он должен выполнить. Начиная с этого момента центральный процессор и канал могут работать параллельно.
Многозадачность в системах разделения времени
· Пользователь интерактивно работает сразу с несколькими приложениями
· Принудительная приостановка приложений, и выделение кванта времени другому приложению
· Пропускная способность меньше, чем у систем пакетной обработки
· Дополнительные накладные расходы на переключение контекстов
· Более эффективное использование ресурсов системы
Ясно что пропускная способность ниже, чем у систем пакетной обработки, так как на выполнение принимается каждая запущенная пользователем задача, а не та которая выгодна системе. Кроме того производительность системы снижается из-за дополнительных накладных расходов связанных с переключением контекста.
Многозадачность в системах реального времени
· Фиксированный набор заранее разработанных программ
· Переключение между задачами основано на расписании плановых работ
· Пропускная способность не главное
· Основной критерий реактивность или время реакции системы
· Проектируется с учетом запаса
В системах реального времени мультипрограммная смесь представляет собой фиксированный набор заранее заданных программ, а выбор на выполнение осуществляется по прерываниям или в соответствии с расписанием плановых работ.
Способность аппаратуры компьютера и ОС к быстрому ответу зависит в основном от скорости переключения между задачами. Если при возникновения прерывания процессор должен опросить сотни потенциальных источников, то реакция системы будет слишком медленной.
В системах реального времени не стремятся максимально загружать все устройства, наоборот, при проектировании программного управляющего комплекса обычно закладывается некоторый запас вычислительной мощности на случай пиковой нагрузки.
10. Понятия процесса и потока. Состояния потока.
Планирование и диспетчеризация потоков в многопоточных системах
(планирование потоков с использованием не вытесняющих алгоритмов, вытесняющее планирование потоков на основе квантования, вытесняющее планирование на основе приоритетов, смешанные алгоритмы планирования).
Приоритеты и концепции планирования потоков в Windows 2000, ОС Unix System V и OS/2.
Понятия «процесс» и «поток»
Чтобы поддерживать мультипрограммирование, ОС должна определить и оформить для себя те внутренние единицы работы, между которыми будет разделяться процессор и другие ресурсы компьютера. В настоящее время в большинстве операционных систем определены два типа единиц работы. Более крупная единица работы, обычно носящая название процесса, или задачи, требует для своего выполнения нескольких более мелких работ, для обозначения которых используют термины «поток», или «нить».
Итак, в чем же состоят принципиальные отличия в понятиях «процесс» и «поток»?
Очевидно, что любая работа вычислительной системы заключается в выполнении некоторой программы. Поэтому и с процессом, и с потоком связывается определенный программный код, который для этих целей оформляется в виде исполняемого модуля. Чтобы этот программный код мог быть выполнен, его необходимо загрузить в оперативную память, возможно, выделить некоторое место на диске для хранения данных, предоставить доступ к устройствам ввода-вывода, например к последовательному порту для получения данных по подключенному к этому порту модему; и т. д. В ходе выполнения программе может также понадобиться доступ к информационным ресурсам, например файлам, портам TCP/UPD, семафорам. И, конечно же, невозможно выполнение программы без предоставления ей процессорного времени, то есть времени, в течение которого процессор выполняет коды данной программы.
В операционных системах, где существуют и процессы, и потоки, процесс рассматривается операционной системой как заявка на потребление всех видов ресурсов, кроме одного — процессорного времени. Этот последний важнейший ресурс распределяется операционной системой между другими единицами работы — потоками, которые и получили свое название благодаря тому, что они представляют собой последовательности (потоки выполнения) команд.
В простейшем случае процесс состоит из одного потока, и именно таким образом трактовалось понятие «процесс» до середины 80-х годов (например, в ранних версиях UNIX) и в таком же виде оно сохранилось в некоторых современных ОС. В таких системах понятие «поток» полностью поглощается понятием «процесс», то есть остается только одна единица работы и потребления ресурсов — процесс. Мультипрограммирование осуществляется в таких ОС на уровне процессов.
Для того чтобы процессы не могли вмешаться в распределение ресурсов, а также не могли повредить коды и данные друг друга, важнейшей задачей ОС является изоляция одного процесса от другого. Для этого операционная система обеспечивает каждый процесс отдельным виртуальным адресным пространством, так что ни один процесс не может получить прямого доступа к командам и данным другого процесса.
При необходимости взаимодействия процессы обращаются к операционной системе, которая, выполняя функции посредника, предоставляет им средства межпроцессной связи — конвейеры, почтовые ящики, разделяемые секции памяти и некоторые другие.
Однако в системах, в которых отсутствует понятие потока, возникают проблемы при организации параллельных вычислений в рамках процесса. А такая необходимость может возникать. Действительно, при мультипрограммировании повышается пропускная способность системы, но отдельный процесс никогда не может быть выполнен быстрее, чем в однопрограммном режиме (всякое разделение ресурсов только замедляет работу одного из участников за счет дополнительных затрат времени на ожидание освобождения ресурса). Однако приложение, выполняемое в рамках одного процесса, может обладать внутренним параллелизмом, который в принципе мог бы позволить ускорить его решение. Если, например, в программе предусмотрено обращение к внешнему устройству, то на время этой операции можно не блокировать выполнение всего процесса, а продолжить вычисления по другой ветви программы. Параллельное выполнение нескольких работ в рамках одного интерактивного приложения повышает эффективность работы пользователя. Так, при работе с текстовым редактором желательно иметь возможность совмещать набор нового текста с такими продолжительными по времени операциями, как переформатирование значительной части текста, печать документа или его сохранение на локальном или удаленном диске. Еще одним примером необходимости распараллеливания является сетевой сервер баз данных. В этом случае параллелизм желателен как для обслуживания различных запросов к базе данных, так и для более быстрого выполнения отдельного запроса за счет одновременного просмотра различных записей базы.
Потоки возникли в операционных системах как средство распараллеливания вычислений. Конечно, задача распараллеливания вычислений в рамках одного приложения может быть решена и традиционными способами.
Во-вторых, решением является создание для одного приложения нескольких процессов для каждой из параллельных работ. Однако использование для создания процессов стандартных средств ОС не позволяет учесть тот факт, что эти процессы решают единую задачу, а значит, имеют много общего между собой — они могут работать с одними и теми же данными, использовать один и тот же кодовый сегмент, наделяться одними и теми же правами доступа к ресурсам вычислительной системы. Так, если в примере с сервером баз данных создавать отдельные процессы для каждого запроса, поступающего из сети, то все процессы будут выполнять один и тот же программный код и выполнять поиск в записях, общих для всех процессов файлов данных. А операционная система при таком подходе будет рассматривать эти процессы наравне со всеми остальными процессами и с помощью универсальных механизмов обеспечивать их изоляцию друг от друга. В данном случае все эти достаточно громоздкие механизмы используются явно не по назначению, выполняя не только бесполезную, но и вредную работу, затрудняющую обмен данными между различными частями приложения. Кроме того, на создание каждого процесса ОС тратит определенные системные ресурсы, которые в данном случае неоправданно дублируются — каждому процессу выделяются собственное виртуальное адресное пространство, физическая память, закрепляются устройства ввода-вывода и т. п.
Из всего вышеизложенного, следует, что в операционной системе наряду с процессами нужен другой механизм распараллеливания вычислений, который учитывал бы тесные связи между отдельными ветвями вычислений одного и того же приложения. Для этих целей современные ОС предлагают механизм многопоточной обработки (multithreading). При этом вводится новая единица работы — поток выполнения, а понятие «процесс» в значительной степени меняет смысл. Понятию «поток» соответствует последовательный переход процессора от одной команды программы к другой. ОС распределяет процессорное время между потоками. Процессу ОС назначает адресное пространство и набор ресурсов, которые совместно используются всеми его потоками.
Создание потоков требует от ОС меньших накладных расходов, чем процессов. В отличие от процессов, которые принадлежат разным, вообще говоря, конкурирующим приложениям, все потоки одного процесса всегда принадлежат одному приложению, поэтому ОС изолирует потоки в гораздо меньшей степени, нежели процессы в традиционной мультипрограммной системе. Все потоки одного процесса используют общие файлы, таймеры, устройства, одну и ту же область оперативной памяти, одно и то же адресное пространство. Это означает, что они разделяют одни и те же глобальные переменные. Поскольку каждый поток может иметь доступ к любому виртуальному адресу процесса, один поток может использовать стек другого потока. Между потоками одного процесса нет полной защиты, потому что, во-первых, это невозможно, а во-вторых, не нужно. Чтобы организовать взаимодействие и обмен данными, потокам вовсе не требуется обращаться к ОС, им достаточно использовать общую память — один поток записывает данные, а другой читает их. С другой стороны, потоки разных процессов по-прежнему хорошо защищены друг от друга.
Итак, мультипрограммирование более эффективно на уровне потоков, а не процессов. Каждый поток имеет собственный счетчик команд и стек. Задача, оформленная в виде нескольких потоков в рамках одного процесса, может быть выполнена быстрее за счет псевдопараллельного (или параллельного в мультипроцессорной системе) выполнения ее отдельных частей. Например, если электронная таблица была разработана с учетом возможностей многопоточной обработки, то пользователь может запросить пересчет своего рабочего листа и одновременно продолжать заполнять таблицу. Особенно эффективно можно использовать многопоточность для выполнения распределенных приложений, например многопоточный сервер может параллельно выполнять запросы сразу нескольких клиентов.
Использование потоков связано не только со стремлением повысить производительность системы за счет параллельных вычислений, но и с целью создания более читабельных, логичных программ. Введение нескольких потоков выполнения упрощает программирование. Например, в задачах типа «писатель-читатель» один поток выполняет запись в буфер, а другой считывает записи из него. Поскольку они разделяют общий буфер, не стоит их делать отдельными процессами. Другой пример использования потоков — управление сигналами, такими как прерывание с клавиатуры (del или break). Вместо обработки сигнала прерывания один поток назначается для постоянного ожидания поступления сигналов. Таким образом, использование потоков может сократить необходимость в прерываниях пользовательского уровня. В этих примерах не столь важно параллельное выполнение, сколь важна ясность программы.
Наибольший эффект от введения многопоточной обработки достигается в мультипроцессорных системах, в которых потоки, в том числе и принадлежащие одному процессу, могут выполняться на разных процессорах действительно параллельно (а не псевдопараллельно).
ОС выполняет планирование потоков, принимая во внимание их состояние. В мультипрограммной системе поток может находиться в одном из трех основных состояний:
· выполнение — активное состояние потока, во время которого поток обладает всеми необходимыми ресурсами и непосредственно выполняется процессором;
· ожидание — пассивное состояние потока, находясь в котором, поток заблокирован по своим внутренним причинам (ждет осуществления некоторого события, например завершения операции ввода-вывода, получения сообщения от другого потока или освобождения какого-либо необходимого ему ресурса);
· готовность — также пассивное состояние потока, но в этом случае поток заблокирован в связи с внешним по отношению к нему обстоятельством (имеет все требуемые для него ресурсы, готов выполняться, однако процессор занят выполнением другого потока).
В течение своей жизни каждый поток переходит из одного состояния в другое в соответствии с алгоритмом планирования потоков, принятым в данной операционной системе.
Рассмотрим типичный граф состояния потока (рис. 4.3). Только что созданный поток находится в состоянии готовности, он готов к выполнению и. стоит в очереди к процессору. Когда в результате планирования подсистема управления потоками принимает решение об активизации данного потока, он переходит в состояние выполнения и находится в нем до тех пор, пока либо он сам освободит процессор, перейдя в состояние ожидания какого-нибудь события, либо будет принудительно «вытеснен» из процессора, например вследствие исчерпания отведенного данному потоку кванта процессорного времени. В последнем случае поток возвращается в состояние готовности. В это же состояние поток переходит из состояния ожидания, после того как ожидаемое событие произойдет.
Рис. 4.3. Граф состояний потока в многозадачной среде
В состоянии выполнения в однопроцессорной системе может находиться не более одного потока, а в каждом из состояний ожидания и готовности — несколько потоков. Эти потоки образуют очереди соответственно ожидающих и готовых потоков. Очереди потоков организуются путем объединения в списки описателей отдельных потоков. Таким образом, каждый описатель потока, кроме всего прочего, содержит по крайней мере один указатель на другой описатель, соседствующий с ним в очереди. Такая организация очередей позволяет легко их переупорядочивать, включать и исключать потоки, переводить потоки из одного состояния в другое. Если предположить, что на рис. 4.4 показана очередь готовых потоков, то запланированный порядок выполнения выглядит так: А, В, Е, D, С.
Рис. 4.4. Очередь потоков
Планирование и диспетчеризация потоков
На протяжении существования процесса выполнение его потоков может быть многократно прервано и продолжено. (В системе, не поддерживающей потоки, все сказанное ниже о планировании и диспетчеризации относится к процессу в целом.)
Переход от выполнения одного потока к другому осуществляется в результате планирования и диспетчеризации. Работа по определению того, в какой момент необходимо прервать выполнение текущего активного потока и какому потоку предоставить возможность выполняться, называется планированием. Планирование потоков осуществляется на основе информации, хранящейся в описателях процессов и потоков. При планировании могут приниматься во внимание приоритет потоков, время их ожидания в очереди, накопленное время выполнения, интенсивность обращений к вводу-выводу и другие факторы. ОС планирует выполнение потоков независимо от того, принадлежат ли они одному или разным процессам. Так, например, после выполнения потока некоторого процесса ОС может выбрать для выполнения другой поток того же процесса или же назначить к выполнению поток другого процесса.
Планирование потоков, по существу, включает в себя решение двух задач:
· определение момента времени для смены текущего активного потока;
· выбор для выполнения потока из очереди готовых потоков.
Существует множество различных алгоритмов планирования потоков, по-своему решающих каждую из приведенных выше задач. Алгоритмы планирования могут преследовать различные цели и обеспечивать разное качество мультипрограммирования. Например, в одном случае выбирается такой алгоритм планирования, при котором гарантируется, что ни один поток/процесс не будет занимать процессор дольше определенного времени, в другом случае целью является максимально быстрое выполнение «коротких» задач, а в третьем случае — преимущественное право занять процессор получают потоки интерактивных приложений. Именно особенности реализации планирования потоков в наибольшей степени определяют специфику операционной системы, в частности, является ли она системой пакетной обработки, системой разделения времени или системой реального времени.
В большинстве операционных систем универсального назначения планирование осуществляется динамически (on-line), то есть решения принимаются во время работы системы на основе анализа текущей ситуации. ОС работает в условиях неопределенности — потоки и процессы появляются в случайные моменты времени и также непредсказуемо завершаются. Динамические планировщики могут гибко приспосабливаться к изменяющейся ситуации и не используют никаких предположений о мультипрограммной смеси. Для того чтобы оперативно найти в условиях такой неопределенности оптимальный в некотором смысле порядок выполнения задач, операционная система должна затрачивать значительные усилия.
Другой тип планирования — статический — может быть использован в специализированных системах, в которых весь набор одновременно выполняемых задач определен заранее, например в системах реального времени. Планировщик называется статическим (или предварительным планировщиком), если он принимает решения о планировании не во время работы системы, а заранее (off-line). Соотношение между динамическим и статическим планировщиками аналогично соотношению между диспетчером железной дороги, который пропускает поезда строго по предварительно составленному расписанию, и регулировщиком на перекрестке автомобильных дорог, не оснащенном светофорами, который решает, какую машину остановить, а какую пропустить, в зависимости от ситуации на перекрестке.
Результатом работы статического планировщика является таблица, называемая расписанием, в которой указывается, какому потоку/процессу, когда и на какое время должен быть предоставлен процессор. Для построения расписания планировщику нужны как можно более полные предварительные знания о характеристиках набора задач, например о максимальном времени выполнения каждой задачи, ограничениях предшествования, ограничениях по взаимному исключению, предельным срокам и т. д.
После того как расписание готово, оно может использоваться операционной системой для переключения потоков и процессов. При этом накладные расходы ОС на исполнение расписания оказываются значительно меньшими, чем при динамическом планировании, и сводятся лишь к диспетчеризации потоков/процессов.
Диспетчеризация заключается в реализации найденного в результате планирования (динамического или статистического) решения, то есть в переключении процессора с одного потока на другой. Прежде чем прервать выполнение потока, ОС запоминает его контекст, с тем чтобы впоследствии использовать эту информацию для последующего возобновления выполнения данного потока. Контекст отражает, во-первых, состояние аппаратуры компьютера в момент прерывания потока: значение счетчика команд, содержимое регистров общего назначения, режим работы процессора, флаги, маски прерываний и другие параметры. Во-вторых, контекст включает параметры операционной среды, а именно ссылки на открытые файлы, данные о незавершенных операциях ввода-вывода, коды ошибок выполняемых данным потоком системных вызовов и т. д.
Диспетчеризация сводится к следующему:
· сохранение контекста текущего потока, который требуется сменить;
· загрузка контекста нового потока, выбранного в результате планирования;
· запуск нового потока на выполнение.
Поскольку операция переключения контекстов существенно влияет на производительность вычислительной системы, программные модули ОС выполняют диспетчеризацию потоков совместно с аппаратными средствами процессора.
В контексте потока можно выделить часть, общую для всех потоков данного процесса (ссылки на открытые файлы), и часть, относящуюся только к данному потоку (содержимое регистров, счетчик команд, режим процессора). Например, в среде NetWare 4.x различаются три вида контекстов: глобальный контекст (контекст процесса), контекст группы потоков и контекст отдельного потока. Соотношение между данными этих контекстов напоминает соотношение глобальных и локальных переменных в программе, написанной на языке С. Переменные глобального контекста доступны для всех потоков, созданных в рамках одного процесса. Переменные локального контекста доступны только для кодов определенного потока, аналогично локальным переменным функции. В NetWare можно создавать несколько групп потоков внутри одного процесса и эти группы будут иметь свой групповой контекст. Переменные, принадлежащие групповому контексту, доступны всем потокам, входящим в группу, но недоступны остальным потокам.
Очевидно, что такая иерархическая организация контекстов ускоряет переключение потоков, так как при переключении с потока на поток в пределах одной группы нет необходимости заменять контексты групп или глобальные контексты, достаточно лишь заменить контексты потоков, которые имеют меньший объем. Аналогично при переключении с потока одной группы на поток другой группы в пределах одного процесса глобальный контекст не изменяется, а изменяется лишь контекст группы. Переключение же глобальных контекстов происходит только при переходе с потока одного процесса на поток другого процесса.
Вытесняющие и невытесняющие алгоритмы планирования
С самых общих позиций все множество алгоритмов планирования можно разделить на два класса: вытесняющие и невытесняющие алгоритмы планирования.
· Невытесняющие (non-preemptive) алгоритмы основаны на том, что активному потоку позволяется выполняться, пока он сам, по собственной инициативе, не отдаст управление операционной системе для того, чтобы та выбрала из очереди другой готовый к выполнению поток.
· Вытесняющие (preemptive) алгоритмы — это такие способы планирования потоков, в которых решение о переключении процессора с выполнения одного потока на выполнение другого потока принимается операционной системой, а не активной задачей.
Основным различием между вытесняющими и невытесняющими алгоритмами является степень централизации механизма планирования потоков. При вытесняющем мультипрограммировании функции планирования потоков целиком сосредоточены в операционной системе и программист пишет свое приложение, не заботясь о том, что оно будет выполняться одновременно с другими задачами. При этом операционная система выполняет следующие функции: определяет момент снятия с выполнения активного потока, запоминает его контекст, выбирает из очереди готовых потоков следующий, запускает новый поток на выполнение, загружая его контекст.
