Единое окно доступа к образовательным ресурсам

Операционные системы. Теория и практика: Учебное пособие

Голосов: 2

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

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра.
Изображения (картинки, формулы, графики) отсутствуют.
    чет за собой изменение порядка выполнения команд процессором.
     В зависимости от источника все прерывания делят на два класса:
      аппаратные (внешние и внутренние);
      программные.
     Аппаратные (англ. Interrupt Request – IRQ) – события от перифе-
рийных устройств или события в микропроцессоре, возникающие
вследствие подачи некоторой аппаратурой электрического сигнала, ко-
торый передается на специальный вход прерывания процессора. При
этом внешними будут прерывания, инициированные периферийными
устройствами (например, нажатия клавиш клавиатуры, движение мыши,
сигнал от таймера, сетевой карты или дискового накопителя), а внут-
ренними – те, что происходят в микропроцессоре.
     Внешние прерывания являются асинхронными по отношению к по-
току инструкций прерываемой программы. Аппаратура процессора ра-
ботает так, что асинхронные прерывания возникают между выполнени-
ем двух соседних инструкций, при этом система после обработки пре-
рывания продолжает выполнение процесса, уже начиная со следующей
инструкции.
     Внутренние прерывания, называемые также исключениями (англ.
exception), происходят в микропроцессоре и инициируются синхронно
выполнению программы при появлении аварийной ситуации в ходе ис-
полнения некоторой инструкции программы – возникают непосред-
ственно в ходе выполнения тактов команды («внутри» выполнения).
Примерами исключений являются деление на нуль, ошибки защиты па-
мяти, обращения по несуществующему адресу, попытка выполнить при-
вилегированную инструкцию в пользовательском режиме и т.п.
     Программные прерывания возникают (синхронно) при исполнении
особой команды процессора, которая имитирует прерывание, т.е. пере-
ход на новую последовательность инструкций. Этот класс прерываний
отличается от предыдущих тем, что они по своей сути не являются «ис-
тинными» прерываниями. Этот механизм был специально введен для
того, чтобы переключение на системные программные модули происхо-
дило не просто как переход на подпрограмму, а точно таким же образом,
как и обычное прерывание. Этим, прежде всего, обеспечивается автома-
тическое переключение процессора в привилегированный режим с воз-
можностью исполнения любых команд ОС.
     Механизм обработки прерываний независимо от архитектуры вы-
числительной системы подразумевает выполнение некоторой последо-
вательности шагов.
     Шаг 1. Установление факта прерывания (прием сигнала запроса на
прерывание) и идентификация прерывания (в ОС идентификация пре-
рывания иногда осуществляется повторно, на шаге 4).
                                 41


     Шаг 2. Запоминание состояния прерванного процесса вычислений.
Состояние процесса выполнения программы определяется, прежде все-
го, значением счетчика команд (адресом следующей команды), содер-
жимым регистров процессора, и может включать также спецификацию
режима (например, режим пользовательский или привилегированный) и
другую информацию.
     Шаг 3. Управление аппаратно передается на подпрограмму обра-
ботки прерывания. В простейшем случае в счетчик команд заносится
начальный адрес подпрограммы обработки прерываний, а в соответ-
ствующие регистры – информация из слова состояния.
     Шаг 4. Сохранение информации о прерванной программе, которую
не удалось спасти на шаге 2 с помощью аппаратуры. В некоторых про-
цессорах предусматривается запоминание довольно большого объема
информации о состоянии прерванных вычислений.
     Шаг 5. Собственно выполнение программы, связанной с обработ-
кой прерывания. Эта работа может быть выполнена той же подпрограм-
мой, на которую было передано управление на шаге 3, но в ОС доста-
точно часто она реализуется путем последующего вызова соответству-
ющей подпрограммы.
     Шаг 6. Восстановление информации, относящейся к прерванному
процессу (этап, обратный шагу 4).
     Шаг 7. Возврат на прерванную программу.
     Следует отметить, что шаги 1-3 реализуются аппаратно, а шаги 4-
7 – программно.
     Главные функции механизма прерываний – это:
      распознавание или классификация прерываний;
      передача управления соответствующему обработчику прерыва-
ний;
      корректное возвращение к прерванной программе.
     На рис. 6 показано, что при возникновении запроса на прерывание
естественный ход вычислений нарушается и управление передается на
программу обработки возникшего прерывания (обработчик прерываний,
процедура обслуживания прерываний, англ. Interrupt Service Routine).
При этом средствами аппаратуры сохраняется (как правило, с помощью
механизмов стековой памяти) адрес той команды, с которой следует
продолжить выполнение прерванной программы.




                                 42


                                                      Отключение
                                                 прерываний, со хранение
                            Исполняемая           контекста прерванной
                             программа            программы, установка
                                                 режима работы системы
                                                      прерываний
     Прерывание




                                                    Собственное тело
                                                  программы обработки
                                                      прерываний




                                                     Восстановление
                                                  контекста прерванной
                                                    ранее программы,
                                                   установка прежнего
                                                     режима работы
                                                   системы прерываний


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

                                          43


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




                                        прерываний
                                      (маскирование)

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




                                                                Восстановление
                                                               контекста задачи,
                                                              установка прежнего
                                                                режима работы
                                                             системы прерываний и
                                                                   передача
                                                                  управления
                                                                  этой задаче


                Рисунок 7 – Обработка прерывания при участии супервизора

              Как видно из представленной схемы, здесь отсутствует возврат в
                                            44


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

                                     Магнитные диски

         Внешние устройства        Сетевое оборудование

                                        Терминалы
                                                           Низкий
                              Программные прерывания      приоритет


      Рисунок 8 – Распределение прерываний по уровням приоритета
                                              45


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

    3.2     Планирование процессов и потоков
    3.2.1   Понятие процесса и потока
     Для того, чтобы перейти к более подробному рассмотрению поня-
тия процесс, рассмотрим примеры, позволяющие выявить различия
между понятиями программа, задача или процесс.
     Пусть два студента запускают программу извлечения квадратного
корня, при этом один хочет вычислить квадратный корень из 4, а вто-
рой – из 1. С точки зрения студентов, запущена одна и та же программа;
с точки зрения компьютерной системы, ей приходится заниматься двумя
различными вычислительными процессами, так как разные исходные
данные приводят к разному набору вычислений. Следовательно, на
уровне происходящего внутри вычислительной системы нельзя исполь-
зовать термин «программа» в пользовательском смысле слова. Рассмот-
рим другой пример. Пусть два студента сформировали идентичные за-
дания и пытаются извлечь квадратный корень из 1, но система выполня-
ет эти вычисления с некоторым сдвигом во времени: в то время как одно
из выполняемых заданий приступило к печати результата и ждет окон-
чания операции ввода-вывода, второе только начинает исполняться.
Очевидно, что в один момент времени в системе присутствуют различ-
ные задания, так как состояние процесса их выполнения различно.
     В связи с этим, термины программа и задание правомерно приме-
нять для описания некоторых статических, неактивных объектов. Для
описания динамических объектов используют термин процесс. Процесс
характеризует некоторую совокупность набора исполняющихся команд,
ассоциированных с ним ресурсов (выделенная для исполнения память
или адресное пространство, стеки, используемые файлы и устройства
ввода-вывода и т.д.) и информации о текущем моменте его исполнения
(значения регистров, программного счетчика, состояние стека и значе-
ния переменных), находящуюся под управлением ОС. Такая обособлен-
ность нужна для того, чтобы защитить один процесс от другого, по-
скольку они, совместно используя все ресурсы вычислительной систе-
                                  46


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


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

                                 48


     Следует отметить, что легковесными эти процессы называют пото-
му, что ОС не должна для них организовывать полноценную виртуаль-
ную машину (с собственными ресурсами), а развиваются они в том же
виртуальном адресном пространстве, могут пользоваться теми же фай-
лами, виртуальными устройствами и иными ресурсами, выделенными
ОС данному процессу. Единственное, что они имеют свое – это процес-
сорный ресурс. Другими словами, понятию поток соответствует после-
довательный переход процессора от одной команды программы к дру-
гой, при этом ОС распределяет процессорное время между потоками. В
то же время процессу ОС назначает адресное пространство и набор ре-
сурсов, которые совместно используются всеми его потоками.
    3.2.2   Создание процессов и потоков
     Создать процесс – это прежде всего означает создать описатель
процесса, в качестве которого выступает одна или несколько информа-
ционных структур, содержащих все сведения о процессе, необходимые
ОС для управления им. Примерами описателей процесса являются блок
управления задачей (Task Control Block – ТСВ) в OS/360, управляющий
блок процесса (Process Control Block – РСВ) в OS/2, дескриптор процес-
са в Unix, объект-процесс (object-process) в Windows NT.
     Создание описателя процесса знаменует собой появление в системе
еще одного претендента на вычислительные ресурсы. Начиная с этого
момента при распределении ресурсов ОС должна принимать во внима-
ние потребности нового процесса. Создание процесса включает загрузку
кодов и данных исполняемой программы данного процесса с диска в
оперативную память. Для этого ОС должна обнаружить местоположе-
ние такой программы на диске, перераспределить оперативную память и
выделить память исполняемой программе нового процесса. Затем необ-
ходимо считать программу в выделенные для нее участки памяти и,
возможно, изменить параметры программы в зависимости от размеще-
ния в памяти.
     В системах с виртуальной памятью (подробнее особенности орга-
низации виртуальной памяти рассмотрены ниже п. 4.2) в начальный мо-
мент может загружаться только часть кодов и данных процесса, с тем
чтобы «подкачивать» остальные по мере необходимости. Существуют
системы, в которых на этапе создания процесса не требуется непремен-
но загружать коды и данные в оперативную память, вместо этого испол-
няемый модуль копируется из того каталога файловой системы, в кото-
ром он изначально находился, в область подкачки – специальную об-
ласть диска, отведенную для хранения кодов и данных процессов. При
выполнении всех этих действий подсистема управления процессами

                                  49


тесно взаимодействует с подсистемой управления памятью и файловой
системой.
     Создание процесса состоит из нескольких этапов:
      присвоения идентификатора процессу;
      включения его в список активных процессов, известных системе;
      формирования блока управления процессом;
      выделения процессу начальных ресурсов.
     В многопоточной системе при создании процесса ОС создает для
каждого процесса как минимум один поток. При создании потока так
же, как и при создании процесса, ОС генерирует специальную информа-
ционную структуру – описатель потока.
     В исходном состоянии поток (или процесс, если речь идет о систе-
ме, в которой понятие «поток» не поддерживается) находится в при-
остановленном состоянии. Момент выборки потока на выполнение осу-
ществляется в соответствии с принятым в данной системе правилом
предоставления процессорного времени и с учетом всех существующих
в данный момент потоков и процессов. В случае если коды и данные
процесса находятся в области подкачки, необходимым условием активи-
зации потока процесса является также наличие места в оперативной па-
мяти для загрузки его исполняемого модуля.
     В общем случае существующий процесс может породить новый
процесс, и может иметь место иерархическая структура процессов. За-
дача может порождать подзадачу в мультипрограммном режиме, и в
этом смысле будут появляться родительский и дочерний процессы.
Уничтожение процесса означает удаление его из системы. Ресурсы воз-
вращаются системе, имя процесса удаляется из списка, блок управления
процессом освобождается.
     В разных ОС по-разному строятся отношения между потоками-
потомками и их родителями. Например, в одних ОС выполнение роди-
тельского потока синхронизируется с его потомками, в частности после
завершения родительского потока ОС может снимать с выполнения всех
его потомков. В других системах потоки-потомки могут выполняться
асинхронно по отношению к родительскому потоку. Потомки, как пра-
вило, наследуют многие свойства родительских потоков. Во многих си-
стемах порождение потомков является основным механизмом создания
процессов и потоков.
    3.2.3   Управляющие структуры процессов и потоков
    Для того чтобы ОС могла управлять процессами, она должна рас-
полагать всей необходимой для этого информацией, содержащейся в
описателе процесса – дескрипторе процесса (контексте процесса). В об-

                                 50



    
Яндекс цитирования Яндекс.Метрика