Лекции Системное ПО. Лекция Структура и основные компоненты вычислительной системы
 Скачать 0.71 Mb.
|
|
Лекция 12 На прошлой лекции мы начали говорить о процессах в операционной системе UNIX. Можно однозначно говорить о том, что процессы и механизмы управления процессами в операционной системе это есть одна из принципиальных особенностей операционной системы UNIX, т.е. тех особенностей, которые отличали систему при создании и отличают ее до сих пор. Более того, несмотря на старания господина Гейтса ситуация такова, что Гейтс повторяет те программные интерфейсы, которые используются для взаимодействия управления процессами, а не фирмы разработчики UNIX-ов повторяют те интерфейсы которые появились в Windows. Очевидно, первенство операционной системы UNIX. Мы говорили о том, что процесс в UNIX-е это есть нечто, что зарегистрировано в таблице процессов. Соответственно каждая запись в таблице процессов имеет номер. Номера идут от нуля до некоторого предельного значения, которое предопределено при установке системы. Номер в таблице процессов это есть так называемый идентификатор процесса, который в системе обозначается PID. Соответственно, подавляющее большинство действий, которые можно выполнить с процессом, выполняются при помощи указания на идентификатор процесса. Каждый процесс характеризуется контекстом процесса. Это блок данных, характеризующий состояние процесса, в том числе в этом блоке данных указывается информация об открытых файлах, о правилах обработки событий, возникающих в процессе. В этом наборе данных хранится информация, которая образуется при полном упрятывании процесса при переключении системы с процесса на процесс. Т.е., когда происходит по той или иной причине переключение выполнения с одного процесса на другой, для того, чтобы можно было восстановить работу процесса, некий набор данных размещается в контексте процесса. Этот набор данных представляет из себя содержимое регистровой памяти, некоторые режимы, которые установила программа и в которые пришел процессор (например, содержимое регистра результата), точку возврата из прерывания. Плюс контекст содержит много полезной информации, о которой мы будем говорить. Мы говорили о том. что в некотором смысле определено понятие тела процесса. Тело процесса состоит из двух сегментов — сегмента текста и сегмента данных. Сегмент текста это часть данных процесса, которые включают в себя код исполняемой программы. Сегмент данных это те пространства оперативной памяти, которые могут статически содержать данные. Мы говорили, что имеется возможность в системе иметь разделенные сегменты текста и сегменты данных. В свою очередь,система позволяет с одним сегментом текста связывать достаточно произвольную группу сегментов данных. Это, в частности, бывает полезно, когда в системе одновременно работают несколько одинаковых процессов. Важная и принципиальная вещь, связанная с организацией управлением процессами — механизм fork/exec. При обращении к функции fork происходит создание нового процесса, который является копией текущего процесса. Незначительные отличия этих процессов есть в идентификаторе процессов. Возможны некоторые отличия в содержимом контекста процесса. Функция exec позволяет заменять тело процесса, т.е. при обращении к этой функции, в случае успешного выполнения ее, тело процесса меняется на новое содержимое, которое указано в виден аргументов функции exec, точнее в виде имени некоторого файла. Мы говорили о том, что сама по себе функция fork почти бессмысленна. Смысл функции exec можно уловить, т.е. можно выполнять в рамках одного процесса несколько задач. Возникает вопрос: почему формирование этого процесса раздроблено на две функции fork и exec, чем это обосновано? Во многих системах есть одна функция, формирующая процесс с заданным содержимым. Дело в том, что при обращении к функции fork, как уже неоднократно было сказано, создается копия процесса, в том числе процесс сын наследует все те файлы, которые были открыты в процессе отце и многие другие права и привилегии. Бывает ситуация, когда не хотелось бы, чтобы наследник наследовал все особенности отца. И есть возможность между выполнением функций fork и exec выполнить какие-то действия по закрытию файлов, открытию новых файлов, по переопределению чего-то, и т.д. В частности, вы при практических занятиях должны освоить отладчик системы deb. Какова суть его работы? Пусть есть процесс-отладчик deb, запускается процесс, который отлаживается, и передавая некоторою информацию от отладчика к отлаживаемому процессу происходит процесс отладки. Но отлаживать процесс можно только тот, который разрешил себя отлаживать. Как раз здесь используется раздвоение fork/exec. Сначала я делаю копию своего процесса deb’ , после этого я разрешаю проводить трассировку текущего процесса, а после этого я запускаю функцию exec с отлаживаемой программой. Получается ситуация, что в процессе образуется именно та программа, которую надо отладить, и она, не зная ничего, уже работает в режиме отладки. Загрузка операционной системы и образование начальных процессов. Сегодня мы с вами поговорим о загрузке операционной системы и образовании начальных процессов. При включении вычислительной системы, из ПЗУ запускается аппаратный загрузчик. Осуществляется чтение нулевого блока системного устройства. Из этого нулевого блока запускается программный загрузчик ОС UNIX. этот программный загрузчик осуществляет поиск и запуск файла с именем unix, который является ядром операционной системы. В начальный момент происходят действия ядра по инициализации системы. Это означает, что в соответствии с параметрами настройки системы, формируются необходимые таблицы, инициализируются некоторые аппаратные интерфейсы (инициализация диспетчера памяти, часов, и т.д.). После этого ядро системы создает процесс №0. При этом нулевой процесс является вырожденным процессом с точки зрения организации остальных процессов. Нулевой процесс не имеет кода, он содержит только контекст процесса. Считается, что нулевой процесс активен, когда работает ядро, и пассивен во всех остальных случаях. К моменту образования нулевого процесса в системе уже образованы таблицы, произведена необходимая инициализация, и система близка к готовности работать. Затем ядро копирует нулевой процесс в первый процесс. При этом под первый процесс уже резервируются те ресурсы, которые необходимы для полноценного процесса. Т.е. для него резервируются сегмент контекста процесса, и для него резервируется память для размещения тела процесса. После этого в первый процесс загружается программа init. При этом запускается диспетчер процессов. И ситуация такова: существует единственный процесс реально готовый к выполнению. Процесса init реально завершает запуск системы. Запуск системы может происходить в двух режимах. Первый режим — это однопользовательский режим. В этом случае процесс init загружает интерпретатор команд shell и ассоциирует его с консольным терминалом, а также запускает стартовый командный файл /etc/rc. Этот файлсодержит произвольные команды, которые может устанавливать администратор системы, которые он считает необходимым выполнить при старте системы. Это могут быть команды, предположим, запуска программы тестирования целостности файловой системы. Это могут бытькоманды проверки расписания и в зависимости от расписания запуска процесса, который будет архивировать файловую систему и т.д. Т.е. в этом командном плане в общем случае могут быть произвольные команды, установленные администратором системы. При этом, если запускается система в однопользовательском режиме, на консольный терминал запускается интерпретатор команд shell и считается, что консольный терминал находится в режиме супервизора (суперпользователя) со всеми правами, которые можно предоставить администратору системы. Второй режим — многопользовательский режим. Если однопользовательский режим обычно используется в ситуациях, когда в системе произошла аварийная ситуация и необходимы действия администратора системы или системного программиста, то многопользовательский режим — это штатный режим, который работает в нормальной ситуации. При многопользовательском режиме процесс init запускает для каждого активного терминала процесс getty. Список терминалов берется из некоторого текстового файла, а активностьили его пассивность — это прерогатива аппаратных свойств конкретного терминала и драйвера, который обслуживает данный терминал (когда вы включаете терминал, идет сигнал по соответствующему интерфейсу о включении нового устройства, система осуществляет идентификацию этого устройства в соответствии с портом, к которому подключен этот терминал). Процесс getty при запуске запрашивает сразу же login. Копия процесса getty работает на один сеанс работы с пользователем, т.е. пользователь подтвердил свое имя и пароль, выполняет какие-то действия, и когда он выполняет команду завершения работы, то копия процесса getty завершает свою работу. И после завершения работы процесса getty, связанного с конкретным терминалом, запускается новая копия процесса getty. Вот такая схема. Это те нетрадиционные формы формирования процессов в UNIX-е. Нетрадиционно формируется нулевой процесс (и он сам по себе нетрадиционен), нетрадиционно формируется первый процесс (который также нетрадиционен). Все остальные процессы работают по схеме fork/exec. Эффективные и реальные идентификаторы процесса. С каждым процессом связано три идентификатора процесса. Первый — идентификатор самого процесса, который был получен при формировании. Второй — это т.н. эффективный идентификатор (ЭИ). ЭИ — это идентификатор, связанный с пользователем, запустившем этот процесс. Реальный идентификатор (РИ) — это идентификатор, связанный с запущенным в виде процесса файлом (если я запускаю свой файл, то ЭИ и РИ будут одинаковы, если я запускаю чужой файл, и у этого файла есть s-бит, то в этом случае РИ будет идентификатором владельца файла и это означает, что этому процессу будут делегированы права этого владельца). Планирование процессов в ОС UNIX. Планирование основывается на понятии приоритета. Чем выше числовое значение приоритета, тем меньше приоритет. Приоритет процесса — это параметр, который размещен в контексте процесса, и по значению этого параметра осуществляется выбор очередного процесса для продолжения работы или выбор процесса для его приостановки. В вычислении приоритета используются две составляющие — P_NICE и P_CPU. P_NICE — это пользовательская составляющая приоритета. Она наследуется от родителя и может изменяться по воле процесса. Изменяться она может только в сторону увеличения значения (до некоторого предельного значения). Т.е. пользователь может снижать приоритет своих процессов. P_CPU — это системная составляющая. Она формируется системой следующим образом: по таймеру через предопределенные периоды времени P_CPU увеличивается на единицу для процесса, работающего с процессором (когда процесс откачивается на ВЗУ, то P_CPU обнуляется). Процессор выделяется тому процессу, у которого приоритет является наименьшим. Упрощенная формула вычисления приоритета такова: ПРИОРИТЕТ = P_USER + P_NICE + P_CPU Константа P_USER различается для процессов операционной системы и остальных пользовательских процессов. Для процессов операционной системы она равна нулю, для процессов пользователей она равна некоторому значению (т.е. “навешиваются гирьки на ноги” процессам пользователя, что бы они не “задавливали” процессы системы). Это позволяет априори повысить приоритет системных процессов. Схема планирования свопинга. Мы говорили о том что в системе определенным образом выделяется пространство для области свопинга. Имеется проблема. Есть пространство оперативной памяти в котором находятся процессы, обрабатываемые системой в режиме мультипрограммирования. Есть область на ВЗУ предназначенная для откачки этих процессов. В ОС UNIX (в модельном варианте) свопирование осуществляется всем процессом, т.е. откачивается не часть процесса а весь. Это правило действует в подавляющем числе UNIX-ов, т.е. свопинг в UNIX-е в общем не эффективен. Упрощенная схема планирования подкачки основывается на использовании некоторого приоритета, который называется P_TIME, и который также находится в контексте процесса. В этом параметре аккумулируется время пребывания процесса в состоянии мультипрограммной обработки или в области свопинга. При перемещении процесса из оперативной памяти в область свопинга или обратно, система обнуляет значение параметра P_TIME. Для загрузки процесса в память из области свопинга выбирается процесс с максимальным значением P_TIME. Если для загрузки этого процесса нет свободного пространства оперативной памяти, тосистема ищет среди процессов в оперативной памяти процесс, ожидающий ввода/вывода, и имеющий максимальное значение P_TIME (т.е. тот, который находился в оперативной памяти дольше всех). Если такого процесса нет то выбирается просто процесс с максимальным значением P_TIME. Эта схема не совсем эффективна. Первая неэффективность — это то, что обмены из оперативной памяти в область свопинга происходят всем процессом. Вторая неэффективность (связанная с первой) заключается в том, что если процесс закрыт по причине заказа на обмен, то этот обмен реально происходит не со свопированным процессом. Т.е. для того чтобы обмен нормально завершился весь процесс должен быть возвращен в оперативную память. Это тоже плохо, потому что если бы свопинг происходил блоками памяти, то можно было бы откачать процесс без той страницы, с которой надо меняться, а после обмена докачать из области свопинга весь процесс обратно в оперативную память. Современные UNIX-ы имеют возможность свопирования не всего процесса, а какой-то его части. Лекция 13 На прошлой лекции мы с вами посмотрели каким образом может осуществляться планирование в операционной системе UNIX. Мы с вами определили, что в принципе планированию в системе поддаются два типа процессов. Первый тип — это те процессы, которые находятся в оперативной памяти и между которыми происходит разделение времени ЦП. Мы выяснили, что этот механизм достаточно прост и строится на вычислении некоторого значения приоритета. А что будет, если системная составляющая достигнет максимального значения? В этом случае у процесса просто будет низший приоритет. Второй тип процессов, процессы которые находятся на диске, поддается планированию свопинга. Любой процесс в системе может находиться в двух состояниях — либо он весь откачан на ВЗУ, либо он весь находится в оперативной памяти. И в том и в другом случае с процессом ассоциирована некоторое значение P_TIME, которое растет по мере нахождения процесса в том конкретном состоянии. Это значение обнуляется, когда процесс меняет свое состояние (то есть перекачивается в оперативную память или обратно). В свою очередь система использует P_TIME как значение некоторого приоритета (чем больше это значение, тем более вероятно, что процесс сменит свой статус). Возникал вопрос, что является причиной для инициации действия по докачке процесса из области свопинга в оперативную память. Этот вопрос не имеет однозначного ответа, потому что в каждом UNIX-е это сделано по-своему. Есть два решения. Первое решение заключается в том, что при достижении P_TIME некоторого граничного значения, то операционная система начинает стараться его перекачать в оперативную память для дальнейшей обработки. Второе возможное решение может состоять в том, что имеется некоторое условия на системную составляющую нулевого процесса (нулевой процесс — это ядро). Как только в системе возникает ситуация, что ядро в системе начинает работать очень много, то это становится признаком того что система недогружена, т.е. у системы может быть много процессов в оперативной памяти, но они все занимаются обменом, и ЦП простаивает. Система может в этой ситуации какие-то процессы откачать, а какие-то ввести в мультипрограммную обработку. Мы с вами говорили о том, что разные UNIX-ы могут по-разному представлять процесс в ходе его обработки. Некоторые UNIX-ы представляют тело процесса как единое целое (и код и данные) и все перемещения осуществляются согласно тому, что это единое целое. Некоторые (современные) UNIX-ы рассматривают процесс как объединение двух сегментов — сегмента кода и сегмента данных. С этим связаны проблемы запуска процессов, планирования времени процессора и планирования свопинга. При запуске какого-то процесса система должна понять, нет ли этого процесса уже в числе запущенных, чтобы не запускать лишний сегмент кода, а привязать новые данные к уже функционирующему сегменту кода. Это определяется достаточно просто — в контексте процесса есть параметр, который содержит значение ИД файла, из которого был запущен данный процесс. И когда система пытается загрузить новый процесс (из файла), то передэтим осуществляется просмотр контекстов существующих процессов и система смотрит, нет ли уже в оперативной памяти процесса с заданным ИД, т.е. процесса, запущенного из того же файла. Аналогично происходит учет при свопировании, т.е. сначала свопированию отдаются сегменты данных, а затем могут рассматриваться кодовые сегменты. Обращаю внимание, что при выполнении функции exec в контексте процесса сменится соответствующая информация (информация об ИД). Напоминаю, что цель нашего курса не есть изучение того, как реализована та или иная функция в той или иной версии системы UNIX. Мы хотим посмотреть, как это можно сделать, чтобы у вас не было представления чуда, когда вы видите работающую операционную систему и вас пробирает дрожь, что это что-то от всевышнего.Все предельно просто. Есть правило, что чем более системной является программа, тем более прозрачными должны быть алгоритмы и использованные идеи. Мудреные программы живут с трудом, и это подтверждено практикой. Прозрачные программы живут долго. Пример — UNIX — прозрачная программа, и пример Windows — программа, построенная на очень высоком уровне, но там нет прозрачности на всех уровнях, и к сожалению система имеет достаточное количество особенностей, которые приводят к непредсказуемым результатам ее работы. Так везде. Если мы посмотрим языки программирования — был совершенно фантастический проект языка АДА, когда на конкурсной основе были образованы несколько профессиональных команд, которые разрабатывали язык конца XX века. Он должен был уметь делать все. Получилась очень красивая вещь. С профессиональной точки зрения этот язык во всем хорош, но он не нашел практического применения, потому что сложен. Совершенно “бездарный” язык Си существует и еще долго будет существовать. То же самое можно сказать о языках Вирта (это дядя, который придумал Паскаль, Модулу и Оберон), они тоже не прижились. Процессы и взаимодействие процессов С этого момента времени мы начинаем долго и упорно рассматривать различные способы взаимодействия процессов в операционной системе UNIX. Маленькое техническое добавление. Я сейчас вам продекларирую две системные функции, которыми мы будем пользоваться впоследствии. Это функции дублирования файловых дескрипторов (ФД). intdup(fd); intdup2(fd, to_fd); int fd; int fd, to_fd; Аргументом функции dup является файловый дескриптор открытого в данном процессе файла. Эта функция возвращает -1 в том случае если обращение не проработало, и значение больше либо равное нулю если работа функции успешно завершилась. Работа функции заключается в том, что осуществляется дублирование ФД в некоторый свободный ФД. Т.е. можно как бы продублировать открытый файл. Функция dup2 дублирует файловый дескриптор fd в некоторый файловый дескриптор с номером to_fd. При этом, если при обращении к этой функции ФД в который мы хотим дублировать был занят, то происходит закрытие файла, работающего с этим ФД, и переопределение ФД. Пример: int fd; char s[80]; fd = open(“a.txt”,O_RDONLY); dup2(fd,0); close(fd); gets(s,80); Программа открывает файл с именем a.txt только на чтение. ФД который будет связан с этим файлом, находится в fd. Далее программа обращается к функции dup2, в результате чего будет заменен стандартный ввод процесса на работу с файлом a.txt. Далее можно закрыть дескриптор fd. Функция gets прочтет очередную строку из файла a.txt. Вы видите, что переопределение осуществляется очень просто. Программные каналы. Сначала несколько слов о концепции. Есть два процесса, и мы хотим организовать взаимодействие между этими процессами путем передачи данных от одного процесса к другому. В системе UNIX для этой цели используются т.н. каналы. С точки зрения программы, канал есть некая сущность, обладающая двумя файловыми дескрипторами. Через один ФД процесс может писать информацию в канал, через другой ФД процесс может читать информацию из канала. Так как канал это нечто, связанное с файловыми дескрипторами, то канал может передаваться по наследству сыновним процессам. Это означает, что два родственных процесса могут обладать одним и тем же каналом. Это означает, чтоесли один процесс запишет какую-то информацию в канал, то другой процесс может прочесть эту информацию из этого же канала. Особенности работы с каналом. Под хранение информации передаваемой через канал выделяется некоторый фиксированный объем оперативной памяти. В некоторых системах этот буфер может быть продолжен на внешнюю память. Что происходит, если процесс хочет записать информацию в канал, но буфер переполнен, или прочесть информацию из канала, но в буфере нет еще данных? В обоих случаях процесс приостанавливает свое выполнение и дожидается, пока не освободится место либо, соответственно, пока в канале не появится информация. Надо заметить, что в этих случаях работа процесса может изменяться в зависимости от установленных параметров, которые можно менять программно (и реакцией на эти ситуации может быть не ожидание, а возврат некоторого кода ответа). Давайте посмотрим, как эти концепции реализуются в системе. Есть функция pipe. Аргументом этой функции должен быть указатель на массив двух целых переменных. int pipe(pipes); int pipes[2]; Нулевой элемент массива после обращения к функции pipe получает ФД для чтения, первый элемент этого массива получает ФД для записи. Если нет свободных ФД, то эта функция возвращает -1. Признак конца файла для считывающего дескриптора не будет получен до тех пор, пока не закрыты все дескрипторы, связанные с записью в этот канал. Рассмотрим небольшой пример: char *s = “Это пример”; charb[80]; intpipes[2]; pipe(pipes); write(pipes[1],s, strlen(s)+1); read(pipes[0],s, strlen(s)+1); Это пример копирования строки (понятно, что так копировать строки не надо, и вообще никто функцией pipe в пределах одного процесса не пользуется). В этом примере и в последующих не обрабатываются случаи отказа. Теперь давайте рассмотрим более содержательный пример. Напишем пример программы, которая запустит и свяжет каналом два процесса. main() { intfd[2]; pipe(fd); /* в отцовском процессе образуем два дескриптора канала */ if (fork()) /* образуем процесс-сын у которого будут те же дескрипторы */ { /* эта часть программы происходит в процессе-отце */ dup2(fd[1],1); /* заменяем стандартный вывод выводом в канал */ close(fd[1]);/* закрываем дескрипторы канала */ close(fd[0]); /* теперь весь вывод итак будет происходить в канал */ execl(“/bin/ls”,“ls”,(char*)0); /* заменяем тело отца на ls */ } /* отсюда начинает работать процесс-сын */ dup2(fd[0],0); /* в процессе сыне все делаем аналогично */ close(fd[0]); close(fd[1]); execl(“/bin/wc”,“wc”,(char*)0); } Этот пример связывает конвейером две команды — ls и wc. Команда ls выводит содержимое каталога, а команда wc подсчитывает количество строк. Результатом выполнения нашей программы будет подсчет строк, выведенных командой ls. В отцовском процессе запущен процесс ls. Всю выходную информацию ls загружает в канал, потому что мы ассоциировали стандартное устройство вывода с каналом. Далее мы в сыне запустили процесс wc у которого стандартное устройство ввода (т.е. то, откуда wc читает информацию) связано с дескриптором чтения из канала. Это означает, что все то, что будет писать ls в свое стандартное устройство вывода, будет поступать на стандартное устройство ввода команды wc. Мы говорили о том, что для того, чтобы канал работал корректно, и читающий дескриптор получил признак конца файла, должны быть закрыты все пишущие дескрипторы. Если бы в нашей программе не была бы указана выделенная строка, то процесс, связанный с wc завис бы, потому что в этом случае функция, читающая из канала, не дождется признака конца файла. Она будет ожидать его бесконечно долго. В процессе отце подчеркнутую строку можно было бы не указывать, т.к. дескриптор закрылся бы при завершении процесса, а в процессе сыне такая строка нужна. Т.е. вывод таков, что перед завершением работы должны закрываться все дескрипторы каналов, связанные с записью. Каналом можно связывать только родственные процессы. Технически можно связывать несколько процессов каналом, но могут возникнуть проблемы. |