Интерфейс прикладного программирования

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

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

Приложения выполняют обращения к функциям API с помощью системных вызовов. Способ, которым приложение получает услуги операционной системы, очень похож на вызов подпрограмм. Информация, нужная ОС и состоящая обычно из идентификатора команды и данных, помещается в определенное место памяти, в регистры и/или стек. Затем управление передается операционной системе, которая выполняет требуемую функцию и возвращает результаты через память, регистры или стеки. Если операция проведена неуспешно, то результат включает индикацию ошибки.

Способ реализации системных вызовов зависит от структурной организации ОС, которая, в свою очередь, тесно связана с особенностями аппаратной платформы. Кроме того, он зависит от языка программирования. При использовании ассемблера программист устанавливает значения регистров и/или областей памяти, а затем выполняет специальную инструкцию вызова сервиса или программного прерывания для обращения к некоторой функции ОС. При использовании языков высокого уровня функции ОС вызываются тем же способом, что и написанные пользователем подпрограммы, требуя задания определенных аргументов в определенном порядке.

Пользовательский интерфейс

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

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

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

Контрольные вопросы

1. Каковы основные компоненты операционной системы?

2. Что такое процесс? В чем состоит разница между процессом и программой?

3. Перечислите основные функции ОС по управлению памятью.

4. Что входит в функции файловой системы?

5. Что такое драйвер устройства?

6. Как обеспечивается безопасность и защита данных в ОС?

СТРУКТУРА операционной системы

Монолитные системы

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

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

Однако даже такие монолитные системы могут иметь некоторую структуру. При обращении к системным вызовам, поддерживаемым операционной системой, параметры помещаются в строго определенные места — регистры или стек, после чего выполняется специальная команда прерывания, известная как вызов ядра или вызов супервизора. Эта команда переключает машину из режима пользователя в режим ядра и передает управление операционной системе. Затем операционная система проверяет параметры вызова, чтобы определить, какой системный вызов должен быть выполнен. После этого ОС обращается к таблице как к массиву с номером системного вызова в качестве индекса. В k- мэлементе таблицы содержится ссылка на процедуру обработки системного вызова k. Такая организация операционной системы предполагает следующую структуру:

1. Главная программа, которая вызывает требуемую служебную процедуру.

2. Набор служебных процедур, выполняющих системные вызовы.

3. Набор утилит, обслуживающих служебные процедуры.

В этой модели для каждого системного вызова имеется одна служебная процедура. Утилиты выполняют функции, которые нужны нескольким служебным процедурам. Деление процедур на три уровня показано на рис.5.1.

Рисунок 5.1 - Простая модель монолитной системы

Многоуровневые системы

Обобщением подхода, изображенного на рис. 5.1, является организация операционной системы в виде иерархии уровней. Первой системой, построенной таким образом, была система THE, созданная в Technische Hogeschool Eindhoven (Нидерланды) Э. Дейкстрой (Е. W. Dijkstra) и его студентами в 1968 году. Она была простой пакетной системой для голландского компьютера Electrologica X8, память которого состояла из 32К 27-разрядных слов. Система включала 6 уровней, как показано в табл. 5.1. Уровень 0 занимался распределением времени процессора, переключая процессы при возникновении прерывания или при срабатывании таймера. Над уровнем 0 система состояла из последовательных процессов, каждый из которых можно было запрограммировать, не заботясь о том, что на одном процессоре запущено несколько процессов. Другими словами, уровень 0 обеспечивал базовую многозадачность процессора.

Таблица 5.1 - Структура операционной системы THE

Уровень	Функция
	Оператор
	Программы пользователя
	Управление вводом-выводом
	Связь оператор-процесс
	Управление памятью и барабаном
	Распределение процессора и многозадачность

Уровень 1 управлял памятью. Он выделял процессам пространство в оператив­ной памяти и на магнитном барабане объемом 512 К слов для тех частей процессов (страниц), которые не помещались в оперативной памяти. Процессы более высоких уровней не заботились о том, находятся ли они в данный момент в памяти или на барабане. Программное обеспечение уровня 1 обеспечивало попадание страниц в оперативную память по мере необходимости.

Уровень 2 управлял связью между консолью оператора и процессами. Таким образом, все процессы выше этого уровня имели свою собственную консоль оператора. Уровень 3 управлял устройствами ввода-вывода и буферизировал потоки информации к ним и от них. Любой процесс выше уровня 3, вместо того чтобы работать с конкретными устройствами, с их разнообразными особенностями, мог обращаться к абстрактным устройствам ввода-вывода, обладающим удобными для пользователя характеристиками. На уровне 4 работали пользовательские програм­мы, которым не надо было заботиться ни о процессах, ни о памяти, ни о консоли, ни об управлении устройствами ввода-вывода. Процесс системного оператора раз­мещался на уровне 5.

Дальнейшее обобщение многоуровневой концепции было сделано в операцион­ной системе MULTICS. В ней уровни представляли собой серию концентрических колец, где внутренние кольца являлись более привилегированными, чем внешние. Первоначально предусматривалось 64 кольца, но на практике использовалось только 8. Когда процедура внешнего кольца хотела вызвать процедуру кольца, лежащего внутри, она должна была выполнить эквивалент системного вызова, то есть команду TRAP, параметры которой тщательно проверяются перед тем, как выполняется вызов. Хотя операционная система в MULTICS являлась частью адресного пространства каждого пользовательского процесса, аппаратура обеспечивала защиту данных на уровне сегментов памяти, разрешая или запрещая доступ к индивидуальным процедурам (в действительности к сегментам памяти) для записи, чтения или выполнения.

Стоит отметить, что в системе THE многоуровневая схема представляла собой исключительно конструкционное решение, и все части системы были, в конечном счете, связаны в один объектный файл, а в MULTICS механизм разделения колец действовал во время исполнения на аппаратном уровне.

Преимущество подхода MULTICS заключается в том, что его можно расширить и на структуру пользовательских подсистем. Например, профессор может написать программу для тестирования и оценки студенческих программ и запустить ее в кольце n, в то время как студенческие программы будут работать в кольце n + 1, так что они не смогут изменить свои оценки.

Многоуровневая организация системы имеет много достоинств. Она существенно упрощает разработку системы, так как позволяет сначала определить «сверху вниз» функции слоев и межслойные интерфейсы, а затем при детальной реализации постепенно наращивать мощность функций слоев, двигаясь «снизу вверх». Кроме того, при модернизации системы можно изменять модули внутри слоя без необходимости производить какие-либо изменения в остальных слоях, если при этих внутренних изменениях межслойные интерфейсы остаются в силе.

Виртуальные машины

В 60-70-е годы ХХ в. наиболее распространены были компьютеры фирмы IBM с операционной системой OS/360. Исходная версия этой ОС была системой исключительно пакетной обработки. Однако множество пользователей OS/360 желали работать в системе с разделением времени, поэтому различные группы программистов как в самой корпорации IBM, так и вне ее решили написать для этой машины системы с разделением времени. Официальная система с разделением времени от IBM, которая называлась TSS/360, поздно вышла в свет и оказалась настолько громоздкой и медленной, что на нее перешли немногие. В конечном счете от нее отказались, но уже после того, как ее разработка потребовала около 50 млн. долларов. Группа из научного центра IBM в Кембридже, штат Массачусетс, разработала в корне отличающуюся от нее систему, которую IBM в результате приняла как законченный продукт. Сейчас она широко используется на еще оставшихся мэйнфреймах.

Эта система, в оригинале называвшаяся CP/CMS, а позже переименованная в VM/370, была основана на следующем проницательном наблюдении: система с разделением времени обеспечивает (1) многозадачность и (2) расширенную машину с более удобным интерфейсом, чем тот, что предоставляется оборудова­нием напрямую. VM/370 основана на полном разделении этих двух функций.

Сердце системы, называемое монитором виртуальной машины, работает с оборудованием и обеспечивает многозадачность, предоставляя верхнему слою не одну, а несколько виртуальных машин, как показано на рис. 5.2. Но, в отличие от всех других операционных систем, эти виртуальные машины не являются расширенными. Они не поддерживают файлы и прочие удобства, а представляют собой точ­ные копии «голой» аппаратуры, включая режимы ядра и пользователя, ввод-вывод данных, прерывания и все остальное, присутствующее на реальном компьютере.

Поскольку каждая виртуальная машина идентична настоящему оборудованию, на каждой из них может работать любая операционная система, которая запускается прямо на аппаратуре. На разных виртуальных машинах могут (а зачастую так и происходит) функционировать различные операционные системы. На некоторых из них для обработки пакетов и транзакций работают потомки OS/360, a на других для интерактивного разделения времени пользователей работает однопользовательская интерактивная система CMS (Conversational Monitor System — система диалоговой обработки).

Рисунок 5.2 - Структура VM/370 с системой CMS

Когда программа операционной системы CMS выполняет системный вызов, он прерывает операционную систему на своей собственной виртуальной машине, а не на VM/370, как произошло бы, если бы он работал на реальной машине вместо виртуальной. Затем CMS выдает обычные команды ввода-вывода для чтения своего виртуального диска или другие команды, которые ей могут понадобиться для выполнения вызова. Эти команды ввода-вывода перехватываются VM/370, которая выполняет их в рамках моделирования реального оборудования. При полном разделении функций многозадачности и предоставления расширенной машины каждая часть может быть намного проще, гибче и удобней для обслуживания.

Идея виртуальной машины очень часто используется в наши дни, но в несколько другом контексте: для работы старых программ, написанных для системы MS-DOS на Pentium (или на других 32-разрядных процессорах Intel). При разработке компьютера Pentium и его программного обеспечения обе компании, Intel и Microsoft, понимали, что возникнет острая потребность в работе старых программ на новом оборудовании. Поэтому корпорация Intel создала на процессоре Pentium режим виртуального процессора 8086. В этом режиме машина действует как 8086 (которая с точки зрения программного обеспечения идентична 8088), включая 16-разрядную адресацию памяти с ограничением объема памяти в 1 Мбайт.

Такой режим используется системой Windows и другими операционными системами для запуска программ MS-DOS. Программы запускаются в режиме виртуального процессора 8086. Пока они выполняют обычные команды, они работают напрямую с оборудованием. Но когда программа пытается обратиться по прерыванию к операционной системе, чтобы сделать системный вызов, или пытается напрямую осуществить ввод-вывод данных, происходит прерывание с переключением на монитор виртуальной машины.

Возможны два варианта устройства. Первый: сама система MS-DOS загружена в адресное пространство виртуальной машины 8086, так что монитор виртуальной машины только отсылает прерывания назад к MS-DOS, как это происходит на ре­альной 8086. Когда затем MS-DOS пытается самостоятельно осуществить ввод-вывод, операция перехватывается и выполняется монитором виртуальной машины.

В другом варианте монитор виртуальной машины перехватывает первое прерывание и сам выполняет ввод-вывод, так как он знает все системные вызовы

MS-DOS как раз и имеет представление о том, что должно делать каждое прерывание. Этот вариант не столь безупречен, как первый, потому что, в отличие от первого варианта, он корректно моделирует только MS-DOS и никакие другие операционные системы. С другой стороны, он работает намного быстрее, так как избегает проблем запуска MS-DOS для выполнения ввода-вывода. Существует еще один недостаток фактического запуска MS-DOS в режиме виртуальной 8086: MS-DOS очень часто оперирует флагом разрешения/запрещения прерывания, а моделирование этого требует больших затрат.

Стоит отметить, что ни один из двух описанных методов в действительности не является те же самым, чем была VM/370, потому что смоделированная машина представляет собой только 8086, а не полноценный Pentium. B системе VM/370 можно было запустить на виртуальной машине саму VM/370. Ha Pentium нельзя запустить, скажем, операционную систему Windows на виртуальной 8086, потому что не существует версий Windows, работающих на этой машине. Даже для самых старых версий Windows необходим как минимум 286-й процессор, а моделирование 286 не поддерживается (не говоря уже об эмуляции Pentium). Однако, если немного модифицировать двоичный код Windows, подобная модель становится возможна, и даже возможна ее коммерческая реализация.

Кроме того, виртуальные машины используются, правда, несколько другим способом, для работы программ Java. Когда корпорация Sun Microsystems придумала язык программирования Java, она также разработала виртуальную машину (то есть архитектуру компьютера), называемую JVM (Java Virtual Machine — виртуальная Машина Java). Компилятор Java выдает код дляJVM, который затем обычно выполняется программным интерпретатором JVM. Преимущество этого подхода заключается в том, что код JVM можно передавать через Internet на любой компьютер, имеющий интерпретатор JVM, и запускать там. Если бы компилятор выдавал двоичные программы, например, для компьютеров SPARC или Pentium, их было бы нельзя куда-либо передать и запустить в работу так просто, как это происходит c JVM. (Конечно, компания Sun могла бы разработать компилятор, который выдавал бы двоичные коды SPARC, и затем использовать интерпретатор SPARC, но cтpyктypa JVM намного проще для интерпретации.) Другое преимущество JVM заключается в том, что когда интерпретатор реализован должным образом, что вовсе не тривиально, пpиходящие JVM-пporpaммы можно проверить в целях безопасности и затем запустить в защищенной среде, так что эти программы не смогут похитить данные или причинить какой-нибудь иной вред.

Экзоядро

В системе VM/370 каждый пользователь получает точную копию настоящей ма­шины. На Pentium, в режиме виртуальной машины 8086, каждый пользователь получает точную копию другой машины. Развив эту идею дальше, исследователи из Массачусетского технологического института изобрели систему, которая обеспечивает каждого пользователя абсолютной копией реального компьютера, но с подмножеством ресурсов. Например, одна виртуальная машина может получить блоки на диске с номерами от 0 до 1023, следующая — от 1024 до 2047 и т. д.

На нижнем уровне в режиме ядра работает программа, которая называется
экзоядро (exokernel). В ее задачу входит распределение ресурсов для виртуальных машин, а после этого проверка их использования (то есть отслеживание попыток машин использовать чужой ресурс). Каждая виртуальная машина на уровне пользователя может работать с собственной операционной системой, как на VM/370 или виртуальных 8086-х для Pentium, c той разницей, что каждая машина ограничена набором ресурсов, которые она запросила и которые ей были предоставлены.

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

Модель клиент-сервер

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

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

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

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

Рисунок 5.3. Модель клиент-сервер

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

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

Рисунок 5.4 - Модель клиент-сервер в распределенной системе

 

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

Контрольные вопросы

1. Поясните достоинства и недостатки монолитных систем.

2. Приведите пример многоуровневой операционной системы.

3. Приведите примеры использования виртуальных машин в современных операционных системах.

4. Поясните преимущества схемы экзоядра.

5. Модель клиент-сервер популярна в распределенных системах. Можно ли использовать ее также в однокомпьютерных системах?

 

Процессы и потоки

Концепция процесса

В ранних компьютерных системах выполнялась только одна программа. Эта программа получала полный контроль над системой и доступ ко всем ее ресурсам. Современные системы допускают загрузку в память многих программ и их параллельное выполнение. Эта эволюция привела к появлению понятия процесса как программы во время выполнения. Процесс – рабочая единица любой операционной системы.

Процесс – это не просто выполняющаяся программа. Понятие процесса обычно включает:

­ программный код;

­ счетчик команд и содержимое системных регистров;

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

­ сегмент данных (для глобальных данных).

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

Состояния процесса

Жизненный цикл процесса может быть разбит на несколько состояний. Различают следующие состояния процесса:

­ Новый (New). Процесс только что создан, но еще не готов к выполнению.

­ Выполняемый (Running). Команды процесса выполняются центральным процессором.

­ Ожидающий (Waiting). Процесс ожидает наступления некоторого события, например завершения ввода-вывода или поступления сигнала.

­ Готовый (Ready). Процесс готов к выполнению и ожидает освобождения центрального процессора.

­ Завершенный (Terminated). Процесс завершил свою работу, но еще не удален из системы.

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

Рисунок 6.1. Диаграмма переходов для состояний процесса

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

­ Created. Это состояние, в котором находится новый процесс, созданный функцией fork. Это переходное состояние, то есть процесс уже поступил в систему, но еще не готов к выполнению.

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

­ Kernel mode. Процесс переходит в режим ядра при выполнении таких задач, как, например, обмен данными. Когда процесс работает в режиме ядра, он находится под управлением ядра; ядро определяет также и момент возврата из этого режима. В некоторых случаях, например при вызове функции exit(), такой возврат вообще не происходит.

­ Ready to run. В этом состоянии процесс не занимает время центрального процессора, но готов к выполнению. Момент выхода из данного режима определяется ядром.

­ Sleeping. В этом состоянии процесс обычно ожидает наступления какого-либо события (например, завершения операции обмена с диском).

­ Preempted. Это состояние похоже на ready to run, однако, оно наступает только тогда, когда процесс находится в состоянии перехода от kernel mode к user mode, a ядро переключается на другую задачу.

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

­ Swapped sleeping. Процесс находится в состоянии покоя и переписан из основной памяти на диск, чтобы освободить часть памяти для текущих потребностей.

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

Реализация процессов

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

Назовемэтот элемент таблицы описателем процесса или блоком управления процессом (РСВ - process control block).

РСВ содержит множество параметров, характеризующих процесс, включая:

­ Состояние процесса. Одно из перечисленных выше.

­ Счетчик команд. Содержит адрес (регистр адреса) команды процесса, которая должна выполняется следующей.

­ Регистры процессора. Набор регистров, содержащих информацию необходимую для работы процесса. Зависит от конкретного компьютера. Это может быть аккумуляторы, регистры индекса, циклы стека, регистры общего назначения и прочие.

­ Информация для планировщика процессора. Приоритет процесса, указатель на очереди процессов и другие параметры. Как и счетчик адреса, эта информация должна сохраняться при возникновении прерывания и переключении CPU между процессами.

­ Информация для планирования памяти. Эта информация может включать значение регистра базы и границы, таблицы страниц (сегментов и прочие).

­ Учетная информация. Эта информация включает время фактического использования CPU, общее время работы процесса, учетный номер процесса и прочие.

­ Информация о состоянии ввода-вывода. Список устройств, закрепленных за процессом, список открытых файлов и др.

Во многих ОС информация, характеризующая процесс, хранится не в одной, а в нескольких связанных структурах данных. Эти структуры могут иметь различные наименования, содержать дополнительную информацию или, наоборот, лишь часть описанной информации. Примерами описателей процесса являются блок управления задачей (ТСВ – Task Control Block) в OS/360, управляющий блок процесса в OS/2, дескриптор процесса в UNIX, объект-процесс (object-process) в Windows NT.

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

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

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

Таблица 6.1 - Схема обработки прерывания нижним уровнем операционной системы

1. Аппаратное обеспечение сохраняет в стеке счетчик команд и т. п.

2. Аппаратное обеспечение загружает новый счетчик команд из вектора прерываний

3. Процедура на ассемблере сохраняет регистры

4. Процедура на ассемблере устанавливает новый стек

5. Запускается программа обработки прерываний на С. (Она обычно считывает и буферизирует входные данные)

6. Планировщик выбирает следующий процесс

7. Программа на С передает управление процедуре на ассемблере

8. Процедура на ассемблере запускает новый процесс

Потоки

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

Модель процесса базируется на двух независимых концепциях: группировании ресурсов и выполнении программы. Иногда полезно их разделять, и тут появляется понятие потока или нити (thread).

С одной стороны, процесс можно рассматривать как способ объедине