Файл: Курс лекций по дисциплине Операционные системы 2 Содержание.pdf

19
4. Модель клиент-сервер
Вариация идеи микроядер выражается в обособлении двух классов процессов:
серверов, каждый из которых предоставляет какую-нибудь службу, и клиентов, которые пользуются этими службами. Эта модель известна как клиент-серверная.
Вся суть заключается в наличии клиентских процессов и серверных процессов.
Связь между клиентами и серверами часто организуется с помощью передачи сообщений.
Чтобы воспользоваться службой, клиентский процесс составляет сообщение, в котором говорится, что именно ему нужно, и отправляет его соответствующей службе. Затем служба выполняет определенную работу и отправляет обратно ответ. Если клиент и сервер запущены на одной и той же машине, то можно провести определенную оптимизацию, но концептуально здесь идет речь о передаче сообщений.
Очевидным развитием этой идеи будет запуск клиентов и серверов на разных компьютерах, соединенных локальной или глобальной сетью, как показано на рис. 3.
Рис. 3. Модель клиент-сервер в распределенной системе
5. Виртуальные машины
Первые выпуски OS/360 были системами исключительно пакетной обработки. Но многие пользователи машин IBM/360 хотели получить возможность интерактивной работы с использованием терминала.
Группа из научного центра IBM Scientific Center в Кембридже разработала
CP/CMS, а позже переименованная в VM/370, основана на следующем проницательном наблюдении: система с разделением времени обеспечивает многозадачность и расширенную машину с более удобным интерфейсом, чем у простого оборудования.
Сущность VM/370 заключается в полном разделении этих двух функций.
Сердце ОС, называемое монитором виртуальной машины, работает с оборудование и обеспечивает многозадачность, предоставляя верхнему слою не одну, а несколько виртуальных машин.
Рис. 4. Структура VM/370 с системой CMS
Поскольку каждая виртуальная машина идентична настоящему оборудованию, на каждой из них может работать любая ОС, которая запускается прямо на аппаратуре. На разных виртуальных машинах могут функционировать различные ОС. На некоторых из них для обработки пакетов и транзакций работают потомки OS/360, а на других для интерактивного разделения времени пользователей работает однопользовательская интерактивная система CMS (Conversational Monitor System – система диалоговой обработки). Когда программа ОС CMS выполняет системный вызов, он прерывает ОС на своей собственной виртуальной машине, а не на VM/370, как произошло бы, если бы он

20 работал на реальной машине вместо виртуальной. Затем CMS выдает обычные команды ввода-вывода для чтения своего виртуального диска или другие команды, которые ей могут понадобиться для выполнения вызова. Эти команды ввода-вывода перехватываются
VM/370, которая выполняет их в рамках моделирования реального оборудования. При полном разделении функций многозадачности и предоставления расширенной машины каждая часть может быть намного проще, гибче и удобной для обслуживания.
Идея виртуальной машины очень часто используется в наши дни, но в несколько другом контексте: для работы старых программ, написанных для системы MS-DOS на
Pentium. Корпорация Intel создала на процессоре Pentium режим виртуального процессора
8086. Такой режим используется системой Windows и другими ОС для запуска программ
MS-DOS. Программы запускаются в режиме виртуального процессора 8086. Пока они выполняют обычные команды, они работают напрямую с оборудованием. Но когда программа пытается обратиться по прерыванию к ОС, чтобы сделать системный вызов, или пытается напрямую осуществить ввод-вывод данных, происходит прерывание с переключением на монитор виртуальной машины.
Кроме того, виртуальные машины используются, правда, несколько другим способом, для работы программ Java. Когда корпорация Sun Microsystems придумала язык программирования Java, она также разработала виртуальную машину (то есть архитектуру компьютера), называемую JVM (Java Virtual Machine - виртуальная машина Java).
Компилятор Java выдает код для JVM, который затем обычно выполняется программным интерпретатором JVM.Преимущество этого подхода заключается в том, что код JVM можно передавать через Internet на любой компьютер, имеющий интерпретатор JVM, и запускать там.
6. Зкзоядро
В системе VM/370 каждый пользователь получает точную копию настоящей машины. На Pentium, в режиме виртуальной машины 8086, каждый пользователь получает точную копию другой машины. Развив эту идею дальше, изобрели систему, которая обеспечивает каждого пользователя абсолютной копией реального компьютера, но с подмножеством ресурсов. Например, одна виртуальная машина может получить блоки на диске в номерами от 0 до 1023, следующая – от 1024 до 2047 и т.д.
На нижнем уровне в режиме ядра работает программа, которая называется экзоядром (exokernel). В еѐ задачу входит распределение ресурсов для виртуальных машин, а после этого проверка их использования (то есть отслеживание попыток машин использовать чужой ресурс). Каждая виртуальная машина на уровне пользователя может работать с собственной ОС, как на VM/370 или виртуальных 8086-ч для Pentium, с той разницей, что каждая машина ограничена набором ресурсов, которые она запросила и которые ей были предоставлены.
Преимущество схемы экзоядра заключается в том, что она позволяет обойтись без уровня отображения. При других методах работы каждая виртуальная машина считает, что она использует свой собственный диск с нумерацией блоков от 0 до некоторого максимума. Поэтому монитор виртуальной машины должен поддерживать таблицы преобразования адресов на диске ( и всех других ресурсов). Такой подход имеет еще одно преимущество: он отделяет многозадачность (в экзоядре) от ОС пользователя (в пространстве пользователя) с меньшими затратами, так как для этого ему необходимо всего лишь не допускать вмешательства одной виртуальной машины в работу другой.

21
Лекция 3
Тема: Процессы и потоки
План:
1. Процессы
2. Потоки
3. Реализация потоков
Литература:
1. Таненбаум Э. Современные операционные системы. – 3-е издание. – СПб.:
Питер, 2010. Гл. 1. с. 97-183.
2. Гордеев А.В. Операционные системы– 2-е издание. – СПб.: Питер, 2004. Гл. 1. с. 50-71.
1. Процессы
Процесс – абстрактное понятие, описывающее работу программы.
Модель процесса. В этой модели все функционирующее на компьютере ПО, иногда включая собственно ОС, организовано в виде набора последовательных процессов, или, для краткости, просто процессов. Процессом является выполняемая программа, включая текущие значения счетчика команд, регистров и переменных. С позиций данной абстрактной модели, у каждого процесса есть собственный виртуальный центральный процессор. На самом деле, разумеется, реальный процессор переключается с процесса на процесс, но для лучшего понимания системы значительно проще рассматривать набор процессов, идущих параллельно (псевдопараллельно), чем пытаться себе представить процессор, переключающийся от программы к программе. Это переключение и называется многозадачностью или мультипрограммированием.
На рис. 1.а. представлена схема компьютера, работающего с четырьмя программами. На рис. 1.б. представлены четыре процесса, каждый со своей управляющей логикой (то есть логическим счетчиком команд), идущие независимо друг от друга.
Разумеется, на самом деле существует только один физический счетчик команд, в который загружается логический счетчик команд, в который загружается логический счетчик команд текущего процесса. Когда время, отведенное данному процессу заканчивается, физический счетчик сохраняется в логическом счетчике команд процесса в памяти. На рис. 1.в. видно, что за достаточно большой промежуток времени изменилось состояние всех четырех процессов, но в каждый конкретный момент в действительности работает только один процесс.
Рис. 1.
Создание процесса. Четыре основные события, приводящие к созданию процессов:
1. Инициализация системы. Обычно при загрузке ОС создаются несколько процессов. Некоторые из них являются высокоприоритетными процессами, то есть

22 обеспечивающими взаимодействие с пользователем и выполняющими заданную работу.
Остальные процессы являются фоновыми, они не связаны с конкретными пользователями, но выполняют особые функции. В UNIX для вывода списка запущенных процессов используется программа ps. В Windows достаточно нажать CTRL+ALT+DEL и запуститься диспетчер задач.
2. Выполнение изданного работающим процессом системного запроса и
создание процесса.
3. Запрос пользователя на создание процесса. В интерактивных системах пользователь может запустить программу, набрав на клавиатуре команду или дважды щелкнув на значке программы.
4. Инициирование пакетного задания. Пользователи посылают пакетное задание, а ОС создает новый процесс и запускает следующее задание из очереди в тот момент, когда освобождаются необходимые ресурсы.
С технической точки зрения во всех перечисленных случаях новый процесс формируется одинаково: текущий процесс выполняет системный запрос на создание нового процесса. В роли текущего процесса может выступать процесс, запущенный пользователем, системный процесс, инициированный клавиатурой или мышью, а также процесс, управляющий пакетами. В любом случае этот процесс всего лишь выполняет системный запрос и создает новый процесс. Системный запрос заставляет ОС создать новый процесс, а также прямо или косвенно содержит информацию о программа, которую нужно запустить в этом процессе.
В UNIX существует только один системный запрос, направленный на создание процесса: fork (ветвление или вилка). Этот запрос создает дубликат вызываемого процесса. После выполнения запроса fork двум процессам – родительскому и дочернему – соответствуют одинаковые образы памяти, строки окружения и одни и те же открытые файлы. Обычно дочерний процесс выполняет системный execve (или похожий) для изменения своего образа памяти и запуска новой программы. Так, когда пользователь набирает на клавиатуре команду sort, оболочка создает путем ветвления дочерний процесс, который и выполняет программу sort. Смысл этого двухступенчатого процесса заключается в том, что дочерний процесс успевает обработать описания файлов после fork, но до execve, чтобы выполнить перенаправление стандартных устройств ввода и вывода и потока сообщений об ошибках.
В Windows же вызов всего одной функции CreateProcess интерфейса Win32 управляет и созданием процесса, и запуском в нем нужной программы. У этой функции 10 параметров: программа, которую нужно запустить, параметры командной строки этой программы, различные атрибуты защиты, биты, управляющие наследованием открытых файлов, приоритеты, спецификация окна, которое следует открыть для процесса, и указатель на структуру, в которой информация о созданном процессе возвращается вызывающей программе. Кроме CreateProcess в Win32 есть около 100 функций для управления процессами и их синхронизации.
Завершение процесса:
1. Обычный выход (преднамеренно). (В UNIX системный запрос об окончании работы – exit, а в Windows – ExitProcess).
2. Выход по ошибке (преднамеренно).
3. Выход по неисправимой ошибке (непреднамеренно).
4. Уничтожение другим процессом (непреднамеренно). (В UNIX системный запрос на уничтожение процесса – kill, а в Windows – TerminateProcess).
Иерархия процессов.
В UNIX процесс, все его «дети» и дальнейшие потомки образуют группу процессов. Сигнал, посылаемый пользователем с клавиатуры, доставляется всем членам

23 группы, взаимодействующим с клавиатурой в данный момент (обычно это все активные процессы, созданные в текущем окне). Каждый из процессов может перехватить сигнал, игнорировать его или выполнить другое действие, предусмотренное по умолчанию.
В Windows отсутствует понятие иерархии процессов, и все процессы равноправны.
Единственное, в чем проявляется что-то вроде иерархии процессов – создание процесса, в котором родительский процесс получает специальный маркер (так называемый, дескриптор), позволяющий контролировать дочерний процесс. Но маркер можно передать другому процессу, нарушая иерархию.
Состояния процессов.
Три возможных состояния процесса:
1. Работающий (в конкретный момент использующий процессор).
2. Готовый к работе (процесс временно приостановлен, чтобы позволить выполняться другому процессу).
3. Заблокированный (процесс не может быть запущен прежде, чем произойдет некое внешнее событие).
Рис. 2. Диаграмма состояний процесса.
Реализация процессов
Для реализации модели процессов ОС содержит таблицу, называемую таблицей
процессов, с одним элементом для каждого процесса. Элемент таблицы содержит информацию о состоянии процесса, счетчике команд, указателе стека, распределении памяти, состоянии открытых файлов, об использовании и распределении ресурсов, а также всю остальную информацию, которую необходимо сохранять при переключении в состояние готовности или блокировки для последующего запуска – как если бы процесс не останавливался.
В таблице 2.1. показаны некоторые наиболее важные поля типичной системы.
С каждым классом устройств ввода-вывода (гибкий диск, жесткий диск, таймер, терминал) связана область памяти (обычно расположенная в нижних адресах), называемая
вектором прерываний. Вектор прерываний содержит адрес процедуры обработки

24 прерываний. Представьте, что в момент прерывания диска работал пользовательский процесс 3. Содержимое счетчика команд процесса, слово состояния программы и, возможно, один или несколько регистров записываются в (текущий) стек аппаратным средством прерывания. Затем происходит переход по адресу, указанному в векторе прерывания диска. Вот и все, что делают аппаратные средства прерывания. С этого момента вся остальная обработка прерывания производится программным обеспечением, например процедурой обработки прерываний.
Все прерывания начинаются с сохранения регистров, часто в блоке управления текущим процессом в таблице процессов. Затем информация, помещенная в стек прерыванием, удаляется, и указатель стека переставляется на временный стек, используемый программой обработки процесса. Такие действия, как сохранение регистров и установка указателя стека, выполняются небольшой программой на ассемблере. По завершении своей работы эта программа вызывает процедуру на языке С, которая выполняет все остальные действия, связанные с конкретным прерыванием. Когда процедура завершает свою работу, вызывается планировщик для выбора следующего процесса. После этого управление возвращается к программе на ассемблере, загружающей регистры и карту памяти для текущего процесса и запускающей его.
2. Потоки
В обычных ОС каждому процессу соответствует адресное пространство и одиночный управляющий поток.
Модель потока. Модель процесса базируется на двух независимых концепциях: группировании ресурсов и выполнении программы. Иногда полезно их разделять, и тут появляется понятие потока.
С одной стороны, процесс можно рассматривать как способ объединения родственных ресурсов в одну группу. У процесса есть адресное пространство, содержащее текст программы и данные, а также другие ресурсы (открытые файлы, дочерние процессы, необработанные аварийные сообщения, обработчики сигналов, учетная информация и много другое). Гораздо проще управлять ресурсами, объединив их в форме процесса.
С другой стороны, процесс можно рассматривать как поток исполняемых команд или просто поток. У потока есть счетчик команд, отслеживающий порядок выполнения действий. У него есть регистры, в которых хранятся текущие переменные. У него есть стек, содержащий протокол выполнения процесса, где на каждую процедуру, вызванную, но еще не вернувшуюся, отведен отдельный фрейм.
Процессы используются для группировки ресурсов, а потоки являются объектами, поочередно исполняющимися на центральном процессоре.
Концепция потоков добавляет к модели процесса возможность одновременного выполнения в одной и той же среде нескольких программ, в достаточной степени независимых. Несколько потоков, работающих параллельно в одном процессе, аналогичны нескольким процессам, идущим параллельно на одном компьютере. В первом случае потоки разделяют адресное пространство, открытые файлы и другие ресурсы. Во втором случае процессы совместно пользуются физической памятью, дисками,

25 принтерами и другими ресурсами. Потоки обладаю некоторыми свойствами процессов, поэтому их иногда называют упрощенными процессами. Термин многопоточность также используется для описания использования нескольких потоков в одном процессе.
Использование потоков
Основной причиной использования потоков является выполнение большинством приложений существенного числа действий, некоторые из них могут время от времени блокироваться. Схему программы можно существенно упростить, если разбить приложение на несколько последовательных потоков, запущенных в квазипараллельном режиме.
Еще одним аргументом в пользу потоков является легкость их создания и уничтожения (поскольку с потоком не связаны никакие ресурсы).
Третьим аргументом является производительность. Концепция потоков не дает увеличения производительности, если все они ограничены возможностями процессора. Но когда имеется одновременная потребность в выполнении большого объема вычислений и операций ввода-вывода, наличие потоков позволяет совмещать эти виды деятельности во времени, тем самым увеличивая общую скорость работы приложения.
Концепция потоков полезна в системах с несколькими процессорами, где возможен настоящий параллелизм.
3. Реализация потоков
Есть два основных способа реализации набора потоков: в пользовательском пространстве и в ядре. Это утверждение носит несколько спорный характер, поскольку возможна еще и гибридная реализация.
3.1. Реализация потоков в пространстве пользователя
Первый способ - это поместить весь набор потоков в пользовательском пространстве. И об этом наборе ядру ничего не известно. Что касается ядра, оно управляет обычными, однопотоковыми процессами. Первое и самое очевидное преимущество состоит в том, что набор потоков на пользовательском уровне может быть реализован в операционной системе, которая не поддерживает потоки. Под эту категорию подпадают все операционные системы, даже те, которые находятся еще в разработке. При этом подходе потоки реализованы с помощью библиотеки. У всех этих реализаций одна и та же общая структура, показанная на рис. 1, а.
Рис. 1. Набор потоков на пользовательском уровне (а); набор потоков,
управляемый ядром (б)

26
Потоки запускаются поверх системы поддержки исполнения программ (run-time system), которая представляет собой набор процедур, управляющих потоками. Когда потоки управляются в пользовательском пространстве, каждому процессу необходимо иметь свою собственную таблицу потоков, чтобы отслеживать потоки, имеющиеся в этом процессе. Эта таблица является аналогом таблицы процессов, имеющейся в ядре, за исключением того, что в ней содержатся лишь свойства, принадлежащие каждому потоку, такие как счетчик команд потока, указатель стека, регистры, состояние и т. д. Таблица потоков управляется системой поддержки исполнения программ. Когда поток переводится в состояние готовности или блокируется, информация, необходимая для возобновления его выполнения, сохраняется в таблице потоков, точно так же как ядро хранит информацию о процессах в таблице процессов.
Когда поток совершает какие-то действия, которые могут вызвать его локальную блокировку, например ожидание, пока другой поток его процесса не завершит какую- нибудь работу, он вызывает процедуру системы поддержки исполнения программ. Эта процедура осуществляет проверку, может ли поток быть переведен в состояние блокировки. Если может, она сохраняет регистры потока (то есть свои собственные регистры) в таблице потоков, находит в таблице поток, готовый к выполнению, и перезагружает регистры машины сохраненными значениями нового потока. Как только будут переключены указатель стека и счетчик команд, автоматически будет возобновлено выполнение нового потока. Если машине дается инструкция сохранить все регистры и следующая инструкция — загрузить все регистры, то полное переключение потока может быть осуществлено за счет всего лишь нескольких инструкций. Переключение потоков, осуществленное таким образом, по крайней мере на порядок, а может быть, и больше, быстрее, чем перехват управления ядром, что является веским аргументом в пользу набора потоков, реализуемого на пользовательском уровне.
Но у потоков есть одно основное отличие от процессов. Когда поток на время останавливает свое выполнение, код процедуры может самостоятельно сохранять информацию о потоке в таблице потоков. Более того, он может затем вызвать планировщик потоков, чтобы тот выбрал для выполнения другой поток. Процедура, которая сохраняет состояние потока, и планировщик, — это всего лишь локальные процедуры, поэтому их вызов намного более эффективен, чем осуществление вызова ядра.
Помимо всего прочего, не требуется перехват управления ядром, не требуется переключение контекста, кэш в памяти не нужно сбрасывать на диск и т. д. Благодаря всему этому планировщик потоков работает очень быстро.
У потоков, реализованных на пользовательском уровне, есть также и другие преимущества. Они позволяют каждому процессу иметь свои собственные настройки алгоритма планирования. Например, для некоторых приложений, которые имеют поток сборщика мусора, есть еще один плюс — им не следует беспокоиться о потоках, остановленных в неподходящий момент. Эти потоки также лучше масштабируются, поскольку потоки в памяти ядра безусловно требуют в ядре пространства для таблицы и стека, что при очень большом количестве потоков может вызвать затруднения.
Но, несмотря на лучшую производительность, у потоков, реализованных на пользовательском уровне, есть ряд существенных проблем. Первая из них — как реализовать блокирующие системные вызовы. Представьте, что поток считывает информацию с клавиатуры перед нажатием какой-нибудь клавиши. Мы не можем разрешить потоку осуществить настоящий системный вызов, поскольку это остановит выполнение всех потоков. Одна из главных целей организации потоков в первую очередь состояла в том, чтобы позволить каждому потоку использовать блокирующие вызовы, но при этом предотвратить влияние одного заблокированного потока на выполнение других потоков. Работая с блокирующими системными вызовами, довольно трудно понять, как можно достичь этой цели без особого труда.