Реферат: Управление процессами

Реферат: Управление процессами

Вторым по значимости понятием в операционной системе (ОС) является понятие процесса. Процесс - сущность, которая определяется по-разному. Это может быть - “упорядоченный набор команд и принадлежащих ему ресурсов”. С точки зрения ОС UNIX, процесс - это объект, зарегистрированный в специальной таблице процессов. Структура этой таблицы следующая: она позиционна (как практически и все таблице в UNIX), то есть номер записи в таблице - есть идентификатор процесса “PID”. Формируются процессы с 0 до N-1, где N - предельное число процессов, которые система может одновременно обрабатывать. Это параметр настройки ОС.

 Рассмотрим информативную нагрузку таблицы. В строке-записи таблицы находится ссылка на контекст процесса, там же находится ссылка на тело процесса. Телом процесса мы будем называть набор команд и данных, которыми оперирует процесс.

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

Контекст содержит:

·     номера пользователя и группы;

·     указатель на индексный дескриптор текущего каталога;

специфические условия работы процесса:

- обработка сигналов;

Рассмотрим это подробнее. В ОС UNIX каждый процесс может послать другому процессу некоторое воздействие, которое называют “сигнал”; соответственно, если процесс-отправитель имеет право передать сигнал процессу-получателю, то при выполнении передачи в последнем возникает событие, связанное с сигналом.

Это событие очень похоже на прерывание, возникающее в аппаратуре вычислительной системы. В ОС имеется набор сигналов, которые могут передавать друг другу процессы; перечень сигналов описан в файле “signal.h”. Отправитель может подать некоторым образом команду ОС, что он передает сигнал с заданным номером процессу-получателю, процесс-получатель может прореагировать на сигнал тремя способами: 1) прекращение выполнения, причиной которого является пришедший сигнал; 2) игнорирование сигнала (здесь следует отметить, что игнорировать можно далеко не все сигналы); 3) вызывается предопределенная процессом функция, которая может выполнить какие-то действия; возврат из этой функции осуществляется в точку прихода сигнала.

- информация об открытых в процессе файлах;

- информация о текущем состоянии процесса на случай его приостановки;

Останавливая выполнение процесса, ОС “упрятывает” в соответствующий контекст информацию, нужную для его продолжения: режимы программы в момент приостановки, состояние регистров, адрес точки прерывания.

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

Если k пользователей вызывают один текстовой редактор, то в системе находится одна копия этого редактора и k копий сегмента данных и контекстов (копии, надо заметить, не идентичные). Это вещь полезная, так как отсюда сразу же можно увеличить “разум” планировщика откачки (он может, например, откачивать сегмент данных, а не сегмент текста).

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

Мы говорили, каким образом в UNIX-e можно создать копию текущего процесса, - это функция fork(), которая работает следующим образом:

fork( ): >0 PID сыновьего процесса (мы находимся в процессе-отце)

=0 (мы находимся в процессе-сыне)

=-1 произошла ошибка - невозможно создать новый процесс (остаемся в процессе-отце), эта ошибка может возникнуть при недостатке места в таблице процессов, при нехватке места в системных областях данных и т.п.

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

Окружение - при формировании процесса ему передается некоторый набор параметров-переменных, используя которые, процесс может взаимодействовать с операционным окружением (интерпретатором команд и т.д.);

Файлы, открытые в процессе-отце, за исключением тех, которым было запрещено передаваться специальным параметром при открытии;

Способы обработки сигналов;

Разрешение переустановки действующего идентификатора пользователя (это то, что связано с s-bit’ом)

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

Текущий рабочий каталог и корневой каталог;

Не наследуется при создании нового процесса идентификатор процесса (почему - очевидно).

Возвращаясь к функции fork(), следует заметить, что она сама по себе бессмысленна, ибо применение такому созданию точной копии процесса найти весьма сложно. Поэтому функция fork() используется совместно с группой функций exec(...). Эта группа объединяет в себе функции, которые частью своего имени имеют слово “exec” и выполняют приблизительно одинаковые действия, (набором или интерпретацией параметров).

Суть функций exec() - в следующем: при обращении к ней происходит замена тела текущего процесса, оно заменяется в соответствии с именем исполняемого файла, указанного одним из параметров функции. Функция возвращает “-1”, если действие не выполнено, и код, отличный от “-1”, если операция прошла успешно. Здесь следует отметить следующий факт - в UNIX-е при работе с системными вызовами иногда возникают диагностические сообщения в виде кода ответа, которые невозможно разделить на конкретные причины, вызвавшие возвращение этого кода. Примером этого являются коды “-1” для fork() и exec(...). Для того чтобы обойти это неудобство, следует включить в программу файл “errno.h”, и после этого при возникновении отказов в выполнении системных вызовов в переменной “errno” будет код конкретной причины отказа выполнения заказа. Всевозможные коды отказа описаны в самом “errno.h”.

Давайте приведем небольшой пример. Мы напишем программу, которая будет запускать файлы, имена которых перечислены при вызове.

 main(argc, argv)

int argc;

char *argv;

 { int i, pid;

 for (i=1; i<argc; i++) {

 if (pid=fork()) continue; /* отец */

 execlp(argv[i], argv[i], (char *) 0);

}

 }

Здесь, если pid=0, мы замещаем тело процесса-сына процессом, имя файла которого нам передается в качестве параметра. Если же pid>0, то есть мы находимся в процессе-отце, то продолжаем создавать сыновние процессы, пока есть аргументы.

В качестве иллюстрации работы fork() можно привести следующую картинку:

Здесь процесс с PID=105 создается процессом с PID=101.

Также следует отметить, что если убивается процесс-отец, то новым отцом становится 1-ый процесс ОС.

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

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

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

На прошлой лекции мы начали говорить о процессах в операционной системе 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-ы имеют возможность свопирования не всего процесса, а какой-то его части.

На прошлой лекции мы с вами посмотрели, каким образом может осуществляться планирование в операционной системе UNIX. Мы с вами определили, что в принципе планированию в системе поддаются два типа процессов. Первый тип - это те процессы, которые находятся в оперативной памяти и между которыми происходит разделение времени ЦП. Мы выяснили, что этот механизм достаточно прост и строится на вычислении некоторого значения приоритета. А что будет, если системная составляющая достигнет максимального значения? В этом случае у процесса просто будет низший приоритет. Второй тип процессов - процессы, которые находятся на диске, - поддается планированию свопинга. Любой процесс в системе может находиться в двух состояниях - либо он весь откачан на ВЗУ, либо он весь находится в оперативной памяти. И в том и в другом случае с процессом ассоциировано некоторое значение P_TIME, которое растет по мере нахождения процесса в этом конкретном состоянии. Это значение обнуляется, когда процесс меняет свое состояние (то есть перекачивается в оперативную память или обратно). В свою очередь система использует P_TIME как значение некоторого приоритета (чем больше это значение, тем более вероятно, что процесс сменит свой статус).

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

Мы с вами говорили о том, что разные UNIX-ы могут по-разному представлять процесс в ходе его обработки. Некоторые UNIX-ы представляют тело процесса как единое целое (и код, и данные), и все перемещения осуществляются согласно тому, что это единое целое. Некоторые (современные) UNIX-ы рассматривают процесс как объединение двух сегментов - сегмента кода и сегмента данных. С этим связаны проблемы запуска процессов, планирования времени процессора и планирования свопинга.

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

Напоминаю, что цель нашего курса не есть изучение того, как реализована та или иная функция в той или иной версии системы UNIX. Мы хотим посмотреть, как это можно сделать, чтобы у вас не возникало ощущения чуда, когда вы видите работающую операционную систему, и вас не пробирала дрожь, что это нечто сверхъестественное. Все предельно просто. Есть правило: чем более системной является программа, тем более прозрачными должны быть алгоритмы и использованные идеи. Мудреные программы живут с трудом, и это подтверждено практикой. Прозрачные программы живут долго. Пример - UNIX - прозрачная программа, и пример Windows - программа, построенная на очень высоком уровне, но там нет прозрачности на всех уровнях, и, к сожалению, система имеет достаточное количество особенностей, которые приводят к непредсказуемым результатам ее работы. Так везде. Если мы посмотрим языки программирования - был совершенно фантастический проект языка АДА, когда на конкурсной основе были образованы несколько профессиональных команд, которые разрабатывали язык конца XX века. Он должен был уметь делать все. Получилась очень красивая вещь. С профессиональной точки зрения, этот язык во всем хорош, но он не нашел практического применения, потому что сложен. Совершенно “бездарный” язык Си существует и еще долго будет существовать. То же самое можно сказать о языках Вирта (это дядя, который придумал Паскаль, Модулу и Оберон) - они тоже не прижились.

Процессы и взаимодействие процессов

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

int dup(fd);int dup2(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 = “Это пример”;

char b[80];

int pipes[2];

pipe(pipes);

write(pipes[1],s, strlen(s)+1);

read(pipes[0],s, strlen(s)+1);

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

main()

{

 int fd[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 завис бы, потому что в этом случае функция, читающая из канала, не дождется признака конца файла. Она будет ожидать его бесконечно долго. В процессе отце подчеркнутую строку можно было бы не указывать, т.к. дескриптор закрылся бы при завершении процесса, а в процессе сыне такая строка нужна. Т.е. вывод таков: перед завершением работы должны закрываться все дескрипторы каналов, связанные с записью.

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

Лекция №14

Сигналы в системе UNIX

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

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

некоторое событие внутри программы, например, деление на ноль или переполнение;

событие, связанное с приходом некоторой информации от устройства, например, событие, связанное с передачей от клавиатуры комбинации “Ctrl+C”;

событие, связанное с воздействием одного процесса на другой, например, “SIG_KILL”.

Система имеет фиксированный набор событий, которые могут возникать. Каждое событие имеет свое уникальное имя; эти имена обычно едины для всех версий UNIX. Такие имена называются сигналами.

Перечень сигналов находится в include-ôàéëå “signal.h”.

Есть сигналы, которые присутствуют практически во всех UNIX, но также есть сигналы, специфичные лишь для конкретной версии UNIX (FreeBSD, SCO UNIX, Linux, ...) Например, в версии BSD есть сигнал приостановки работы процесса, реакцией на который является замораживание процесса, а есть сигнал, который размораживает процесс. Это сигнал FreeBSD версии.

Прототип функции обработки сигнала:

void (* signal (sig, fun)) ()

int sig;

void (* fun) ();

При обращении к signal мы передаем:

sig - имя сигнала;

fun - указатель на функцию, которая будет обрабатывать событие, связанное с возникновением этого сигнала. Функция signal возвращает указатель на предыдущую функцию обработки данного сигнала.

Мы говорили о том, что событие, связанное с возникновением сигнала может быть обработано в системе тремя способами:

SIG_DEF - стандартная реакция на сигнал, которая предусмотрена системой;

SIG_IGN - игнорирование сигнала (следует отметить, что далеко не все сигналы можно игнорировать, например, SIG_KILL);

Некоторая пользовательская функция обработки сигнала.

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

Приведем пример программы “Будильник”. Средствами ОС мы будем “заводить” будильник. Функция alarm инициализирует появление сигнала SIG_ALRM.

main ()

{

 char s[80];

 signal(SIG_ALRM, alrm); /* установка режима связи с событием SIG_ALRM  на функцию alrm */

 alarm(5); /* заводим будильник */

 printf(“Введите имя \n”);

 for (;;)

{

 printf(“имя:”);

  if (gets(s,80) != NULL) break;

};

 printf(“OK! \n”);

}

alrm ()

{

 printf(“\n жду имя \n”);

 alarm(5);

 signal (SIG_ALRM,alrm);

}

В начале программы мы устанавливаем реакцию на сигнал SIG_ALRM - функцию alrm, далее мы заводим будильник, запрашиваем “Введите имя” и ожидаем ввода строки символов. Если ввод строки задерживается, то будет вызвана функция alrm, которая напомнит, что программа “ждет имя”, опять заведет будильник и поставит себя на обработку сигнала SIG_ALRM еще раз. И так будет до тех пор, пока не будет введена строка.

Здесь имеется один нюанс: если в момент выполнения системного вызова возникает событие, связанное с сигналом, то система прерывает выполнение системного вызова и возвращает код ответа, равный “-1”. Это мы можем также проанализировать по функции errno.

Надо отметить, что одноразово устанавливается только “свой” обработчик. Дефолтный обработчик или игнорирование устанавливается многоразово, то есть его не надо каждый раз подтверждать после обработки сигнала.

Еще две функции, которые необходимы нам для организации взаимодействия между процессами:.…

1) int kill(int pid, sig) - это функция передачи сигнала процессу. Она работает следующим образом: процессу с номером pid осуществляется попытка передачи сигнала, значение которого равно sig. Соответственно, сигнал может быть передан в рамках процессов, принадлежащих к одной группе. Код ответа: -1, если сигнал передать не удалось, пояснение опять же можно найти в errno. Функция kill может использоваться для проверки существования процесса с заданным идентификатором. Если функция выполняется с sig=0, то это тестовый сигнал, который определяет: можно или нет передать процессу сигнал; если можно, то код ответа kill отличен от “-1”. Если pid=0, то заданный сигнал передается всем процессам, входящим в группу.

2) int wait(int *wait_ret) - ожидание события в сыновнем процессе. Если сыновнего процесса нет, то управление возвращается сразу же с кодом ответа “-1” и расшифровкой в errno. Если в процессе-сыне возникло событие, то анализируются младшие 16 бит в значении wait_ret:

а) Если сын приостановлен (трассировка или получение сигнала), тогда старшие 8 бит wait_ret - , а младшие содержат код 0177.

б) Если сыновий процесс успешно завершился через обращение к функции exit. Тогда младшие 8 бит равны нулю, а старшие 8 бит равны коду, установленному функцией exit.

в) Если сын завершился из-за возникновения у него необрабатываемого сигнала, то старшие 8 бит равны нулю, а младшие - номер сигнала, который завершил процесс.

Функция wait возвращает идентификатор процесса в случае успешного выполнения и “-1” в противном случае. Если одно из перечисленных событий произошло до обращения к функции, то результат возвращается сразу же, то есть никакого ожидания не происходит, это говорит о том, что информация о событиях в процессе безвозвратно не теряется.

Давайте рассмотрим еще один пример. Наш будильник будет уже многопроцессный.

alr()

{

 printf(“\n Быстрее!!! \n”);

 signal (SIG_ALRM, alr);

}

main ()

{

 char s[80]; int pid;

 signal(SIG_ALRM, alr);

 if (pid=fork()) for (;;)

 {

 sleep(5); /*приостанавливаем процесс на 5 секунд */

 kill(pid, SIG_ALRM);/*отправляем сигнал SIG_ALRM процессу-сыну */

}

 print(“имя?”);

 for (;;)

{

 printf(“имя?”);

 if gets(s,80)!=NULL) break;

}

 printf(“OK!\n”);

 kill(getpid(), SIG_KILL); /* убиваем зациклившегося отца */

}

Следует заметить, что в разных версиях UNIX имена сигналов могут различаться.

Наша программа реализуется в двух процессах.

Как и в предыдущем примере, имеется функция реакции на сигнал alr(), которая выводит на экран надпись и переустанавливает функцию реакции на сигнал опять же на себя. В основной программе мы также указываем alr() как реакцию на SIG_ALRM. После этого мы запускаем сыновний процесс, и отцовский процесс (бесконечный цикл) “засыпает” на 5 единиц времени, после чего сыновнему процессу будет отправлен сигнал SIG_ALRM. Все, что ниже цикла, будет выполняться в процессе-сыне: мы ожидаем ввода строки, если ввод осуществлен, то происходит убиение отца (SIG_KILL).

Замечание: мы говорим о некотором обобщенном UNIX, реальные UNIX-ы могут иметь некоторые отличия друг от друга. На сегодняшний день имеются достаточно формализованные стандарты на интерфейсы ОС, в частности для UNIX это POSIX-standard, т.е. были проведены работы по стандартизации интерфейсов всех уровней для открытых систем. Основной задачей является унификация работы с системами, как на уровне запросов от пользователя, так и на уровне системных вызовов. В принципе, на сегодняшний день практически все разработчики ОС стараются привести свои системы к стандарту POSIX. В частности, Microsoft объявила, что системные вызовы и работа с файлами в Windows NT происходит в стандарте POSIX. Но так или иначе реальные коммерческие системы от этого стандарта отходят.

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

Лекция №15

Трассировка процессов

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

Сегодня мы рассмотрим еще одну базовую функцию операционной системы UNIX, которая поддерживает трассировку процессов. Трассировка - это возможность одного процесса управлять ходом выполнения другого процесса. Давайте рассмотрим основные действия, выполняемые при отладке.

Установка контрольной точки.

Обработка ситуации, связанной с приходом в контрольную точку.

Чтение/запись информации в отлаживаемой программе.

Остановка/продолжение выполнения отлаживаемого процесса.

Шаговый режим отладки (остановка отлаживаемой программы после выполнения каждой инструкции).

Передача управления на произвольную точку отлаживаемой программы.

Обработка аварийных остановок (АВОСТ).

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

Теперь посмотрим, какими средствами можно организовать выполнение этих функций в ОС UNIX. Есть функция ptrace.

ptrace(int op, int pid, int addr, int data);

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

Рассмотрим, какие возможности есть у отцовского процесса для управления сыном. Все возможности определяются значением параметра op. Параметр pid - идентификатор сыновьего процесса, который мы хотим трассировать.

op=1 или op=2 - ptrace возвращает значение слова, адрес которого задан параметром addr (т.е. чтение слова из отлаживаемого процесса). Здесь указаны два значения op на тот случай, если есть самостоятельные адресные пространства в сегментах данных и кода (т.е. можно читать данные и код). В системах, где адресация единая в рамках процесса значение может быть любым.

op=3 - читать информацию из контекста процесса. Обычно речь идет о доступе к информации из контекста данного процесса, сгруппированную в некоторую структуру. В этом случае параметр addr указывает смещение относительно начала этой структуры. В эта структуре размещена информация к которой я имею доступ посредством функции ptrace, в частности - регистры, текущее состояние процесса, счетчик адреса и т.д.

op=4 или op=5 - запись данных, размещенных в параметре data, по адресу addr. Если происходит ошибка, ptrace возвращает -1 (уточнение в errno).

op=6 - запись данных из data в контекст по смещению addr. Это означает, что можно прочесть регистры трассируемого процесса и при необходимости изменить их содержимое (в т.ч. счетчик адреса команды, т.е. сделать переход).

op=7 - продолжение выполнения трассируемого процесса. Эта операция хитрая. Хитрость заключается в следующем. Пусть трассируемый процесс по какой-то причине был остановлен, например по причине прихода сигнала, процесс-отец дождался этого события с помощью функции wait и выполняет какие-то действия не запустив отлаживаемый процесс. Остановленному процессу могут приходить сигналы от других процессов. Что в этом случае делать с этими сигналами? Здесь как раз и используется ptrace с op=7. Если data=0, то процесс, который к этому моменту был приостановлен (сыновий), продолжит свое выполнение, и при этом все пришедшие (и необработанные еще) к нему сигналы будут проигнорированы. Если значение параметра data равно номеру сигнала, то это означает, что процесс (сыновий) возобновит свое выполнение, и при этом будет смоделирована ситуация прихода сигнала с этим номером. Все остальные сигналы будут проигнорированы. Кроме того, если addr=1, то процесс продолжит свое выполнение с того места, на котором он быт приостановлен. Если addr>1, то осуществиться переход по адресу addr (goto addr).

op=8 - завершение трассируемого процесса.

op=9 - установка бита трассировки. Это тот самый код, который обеспечивает пошаговое выполнение машинных команд. После каждой машинной команды в процессе происходит событие, связанное с сигналом SIG_TRAP.

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

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

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

Установка контрольной точки.

Считается, что в отладчике имеется некоторая таблица, которая содержит информацию о контрольных точках.

При установке контрольной точки с использованием функции ptrace происходит следующее.

Отладчик устанавливает контрольную точку по некоторому адресу.

Читает содержимое отлаживаемого процесса по данному адресу.

Записывает это содержимое (машинное слово) в таблицу.

По данному адресу записывает машинную команду, которая сформирует событие, связанное с некоторым фиксированным сигналом, к примеру команда деления на ноль.

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

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

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

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

Снятие контрольной точки делается также просто: восстанавливается содержимое по соответствующему адресу и из таблицы выбрасывается соответствующая строка. Можно сделать контрольную точку так, чтобы она работала, к примеру, только 10 раз. Для этого надо добавить в таблицу еще счетчик, из которого при каждом приходе в контрольную точку будет вычитаться единица, и как только он обнулится, контрольная точка будет автоматически снята.

Чтение/запись обсуждать не будем - это понятно. Остановка осуществляется через посыл сигнала, либо через возникновение события в отлаживаемом процессе, продолжение - через функцию ptrace(7,...). Шаговый режим отладки осуществляется через ptrace(9,...). Передача управления на любую точку - нет проблем. Обработка аварийных остановок - с помощью wait.

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

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

Изменить содержимое переменной можно аналогичным путем в соответствии с тремя рассмотренными вариантами. Кстати, в языке Си, объявление регистровой переменной на самом деле есть пожелание программиста о том, чтобы при хорошем стечении обстоятельств в программе и добром желании системы программирования разместить эту переменную на регистре. Т.е. она будет размещена либо на регистре, и тогда она будет реально регистровой, либо она будет автоматической.

Давайте попробуем написать маленький пример. Мы будем писать программу в нотации операционной системы Free BSD. Для других операционных систем надо уточнить функцию ptrace в мануалах.

Отлаживаемый процесс

int main()/* эта программа находится в процессе-сыне SON */

{

 int i;

 return i/0;

}

Процесс - отладчик

#iinclude <stdio.h>

#iinclude <unistd.h>

#iinclude <signal.h>

#iinclude <sys/types.h>

#iinclude <sys/ptrace.h>

#iinclude <sys/wait.h>

#iinclude <machine/reg.h>

int main(int argc, char *argv[])

{

 pid_f pid;

 int status;

 struct reg REG;

 switch (pid=fork()){/* формируем процесс, в pid - код ответа */

case -1: perror("Ошибка fork"); exit(25); /* Обработка ошибки */

case 0: ptrace( PT_TRACE_ME, 0, 0, 0); execl("SON","SON",0);

 /* В сыне: разрешаем отладку и загружаем процесс SON. При этом произойдет приостановка сына перед выполнением первойкоманды нового тела процесса (а точнее в нем возникнет событие, связанное с сигналом SIG_TRAP) */

default: break;/* В отце: выход из switch */

 }

 for(;;) {

 wait(&status);/* ждем возникновения события в сыне (сигнала SIG_TRAP) */

 ptrace(PT_GETREGS,pid,(caddr_t)&REG,0); /* Читаем регистры, например, чтобы их распечатать */

 printf("EIP=%0.8x\ + ESP=%0.8x\n",REG.r_eip, REG.r_esp); /* печатаем регистры EIP и ESP */

if(WIFSTOPPED(status)||WIFSIGNALED(status)){ /* проверяем с помощью макросов условия функции wait, и если все нормально, продолжаем разбирать причину остановки программы */

 printf("Сигналы: ");

switch(WSTOPSIG(status)){ /*анализируем код сигнала, по которому произошла остановка */

case SIGINT: printf("INT \n"); break;/* выводим причину остановки */

case SIGTRAP: . . . . . . break;

.

.

.

default: printf("%d", WSTOPSIG(status));

}

if (WSTOPSIG(status)!=SIGTRAP) exit(1);  /* Если процесс остановился не по  SIGTRAP тогда выходим */

if (WIFEXITED(status)){ /* проверяем случай, если процесс завершился нормально */

printf("Процесс завершился, код завершения = %d \n", WEXITSTATUS(status));

exit(0);

  }

ptrace(PT_CONTINUE, pid, (caddr_t) 1, 0); /* Если был SIGTRAP, продолжаем процесс */

 } /* End for(;;) */

 exit(0);

}

Мы обработали ситуацию остановки и ситуацию нормального завершения процесса. При первой итерации цикла, мы остановимся и дождемся первого сигнала SIGTRAP. По этому сигналу мы выведем нужную нам информацию. Затем, проверим, не закончился ли наш процесс нормально, и т.к. он не может закончиться нормально (он выполняет деление на ноль), то мы обратимся к функции ptrace, которая продолжит процесс с прерванного места. Мы снова попадем на wait. Здесь мы дождемся события, связанного с делением на ноль, и обработаем это событие. В итоге, на стандартный вывод попадут две порции данных: первая - вывод точки прерывания, вершины стека и сигнала для начальной ситуации, и второе - мы получим блок той же информации и код сигнала FPI (Float Point Interrupt) на делении на ноль.

Рекомендуется разобрать этот пример и адаптировать для ваших машин на практикуме.

Лекция №16

Нелокальные переходы

На этой лекции мы с вами обсудим некоторые дополнительные возможности по организации управления ходом процесса в UNIX. Возникает необходимость предоставления в процессе возможности перезапуска в процессе каких-то его веток при возникновении некоторых ситуаций.

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

Для решения такой задачи, мы должны уметь обрабатывать сигналы, возникающие в процессе. Это можно сделать с помощью функции signal и ее возможностей. Кроме того, нам бы хотелось возвращаться в некоторые помеченные в программе точки, не через последовательность входов и выходов из функции, а с помощью безусловного перехода (как бы goto N), потому что механизм обработки сигналов не позволит корректно работать с такой задачей. Можно в принципе написать функцию обработки сигнала, которая при возникновении одного из сигналов делает повторный вызов всей программы. Но это не совсем корректно, т.к. при вызове функции-обработчика сигнала фиксируется состояние стека, и в общем случае система ожидает выхода из функции обработчика через return (при этом система возвращает нас в прерванное место и освобождает стек). Если не будет произведен выход через return, в стеке будет накапливаться ненужная информация, и все это приведет к деградации системы.

Для решения таких задач имеются т.н. нелокальные переходы. Достигаются они с использованием двух функций, которые продекларированы в setjmp.h и имеют следующий интерфейс:

int setjmp(jmp_buf env);

int longjmp(jmp_buf env, int val);

Функция setjmp фиксирует точку обращения к этой функции, т.е. в структуре данных, связанной с переменной env сохраняется текущее состояние процесса (все атрибуты и в т.ч. состояние стека) в точке обращения к setjmp. При обращении к этой функции здесь, setjmp возвращает нулевое значение.

При обращении к функции longjmp(env, val) происходит передача управления на точку, атрибуты которой зафиксированы в структуре env, т.е. в то место, где было обращение к setjmp(env). При этом, после этого перехода setjmp вернет значение val.

Рассмотрим маленький пример.

# include <setjmp.h>

jmp_buf save;

void main(void)

{ int ret;

 switch(ret=setjmp(save)){  /* при первой проверке ret будет равно нулю */

 case 0: printf("....."); /* этот printf выведет некоторую строку */

a(); /* вызов функции a() */

printf(".....");  /* этот printf не сработает никогда */

default: break;

}

}

void a(void)

{ longjmp(save, 1); /* длинный переход на setjmp, ret будет равно 1 */

}

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

Длинный переход корректно работает со стеком. При входе в точку, установленную с помощью setjmp, он восстанавливает все то состояние (в том числе и состояние стека), которое было при установке этой точки. Надо заметить, что longjmp восстанавливает не сам стек, а лишь указатель стека.

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

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

До сих пор мы с вами рассматривали взаимодействия, связанные с родственными процессами. Реально, система UNIX имеет набор средств, поддерживающих взаимодействие произвольных процессов. Одно из таких средств - Система Межпроцессного Взаимодействия IPC (InterProcess Communications). Суть этой системы заключается в следующем.

Имеется некоторое количество ресурсов, которые называются в системе разделяемыми. К одному и тому же разделяемому ресурсу может быть организован доступ со стороны произвольного количества произвольных процессов. При этом возникает проблема именования этих разделяемых ресурсов. Если мы вспомним неименованные каналы, за счет того, что каналы передавались по родственному наследованию, всегда в процессе были известны дескрипторы, ассоциированные с каналом. Фактически, если процесс получал доступ к каналу, он уже знал, как именовать этот канал. Здесь использовалось свойство родственной связи, когда какая-то информация, какие-то средства передаются по наследству при формировании сыновьего процесса.

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

Разделяемый ресурс создается некоторым процессом-автором. Автор определяет основные свойства ресурса (предположим, размер) и права доступа. Права доступа к ресурсу разделяются на три категории:

Права доступа самого автора.

Права доступ всех процессов, имеющих тот же идентификатор что и автор.

Права доступа остальных.

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

Система IPC поддерживает три разновидности разделяемых ресурсов:

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

Механизм передачи сообщений. Разделяемым ресурсом здесь является очередь сообщений. Эта очередь может содержать произвольное количество (в пределах разумного) сообщений разной длины и разного типа. Тип сообщения - это некоторый атрибут сообщения. Очередь сообщений может рассматриваться как единая очередь всех сообщений в хронологическом порядке, и как множество очередей, содержащих сообщения определенного типа, где в каждой очереди также есть хронологический порядок. Здесь также возникают проблемы синхронизации.

Семафоры. Семафоры - это нечто, что позволяет синхронизовать доступ к разделяемым ресурсам.