Текст книги "Операционная система UNIX"

Автор книги: Андрей Робачевский

сообщить о нарушении

Текущая страница: 20 (всего у книги 39 страниц)

Сигналы

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

Группы и сеансы

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

□ Группа процессов. Каждый процесс принадлежит определенной группе процессов. Каждая группа имеет уникальный идентификатор. Группа может иметь в своем составе лидера группы – процесс, чей идентификатор PID равен идентификатору группы. Обычно процесс наследует группу от родителя, но может покинуть ее и организовать собственную группу.

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

□ Специальный файл устройства /dev/tty. Этот файл связан с управляющим терминалом процесса. Драйвер для этого псевдоустройства по существу перенаправляет запросы на фактический терминальный драйвер, который может быть различным для различных процессов. Например, два процесса, принадлежащие различным сеансам, открывая файл /dev/tty, получат доступ к различным терминалам.

Управление сигналами

Сигналы обеспечивают механизм вызова определенной процедуры при наступлении некоторого события. Каждое событие имеет свой идентификатор и символьную константу. Некоторые из этих событий имеют асинхронный характер, например, когда пользователь нажимает клавишу <Del> или <Ctrl>+<C> для завершения выполнения процесса, другие являются уведомлением об ошибках и особых ситуациях, например, при попытке доступа к недопустимому адресу или вызовы недопустимой инструкции. Различные события, соответствующие тем или иным сигналам, подробно рассматривались в главе 2.

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

Отправление сигнала

Ядро генерирует и отправляет процессу сигнал в ответ на ряд событий, которые могут быть вызваны самим процессом, другим процессом, прерыванием или какими-либо внешними событиями. Можно выделить основные причины отправки сигнала:

Особые ситуации	Когда выполнение процесса вызывает особую ситуацию, например, деление на ноль, процесс получает соответствующий сигнал.
Терминальные прерывания	Нажатие некоторых клавиш терминала, например, <Del>, <Ctrl>+<C> или <Ctrl>+<>, вызывает отправление сигнала текущему процессу, связанному с терминалом.
Другие процессы	Процесс может отправить сигнал другому процессу или группе процессов с помощью системного вызова kill(2). В этом случае сигналы являются элементарной формой межпроцессного взаимодействия.
Управление заданиями	Командные интерпретаторы, поддерживающие систему управления заданиями, используют сигналы для манипулирования фоновым и текущими задачами. Когда процесс, выполняющийся в фоновом режиме делает попытку чтения или записи на терминал, ему отправляется сигнал останова. Когда дочерний процесс завершает свою работу, родитель уведомляется об этом также с помощью сигнала.
Квоты	Когда процесс превышает выделенную ему квоту вычислительных ресурсов или ресурсов файловой системы, ему отправляется соответствующий сигнал.
Уведомления	Процесс может запросить уведомление о наступлении тех или иных событий, например, готовности устройства и т.д. Такое уведомление отправляется процессу в виде сигнала.
Алармы	Если процесс установил таймер, ему будет отправлен сигнал, когда значение таймера станет равным нулю.

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

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

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

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

Доставка сигнала происходит после того, как ядро от имени процесса вызывает системную процедуру issig(), которая проверяет, существуют ли ожидающие доставки сигналы, адресованные данному процессу. Функция issig() вызывается ядром в трех случаях:

1. Непосредственно перед возвращением из режима ядра в режим задачи после обработки системного вызова или прерывания.

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

3. Сразу же после пробуждения после сна с приоритетом, допускающим прерывание сигналом.

Если процедура issig() обнаруживает ожидающие доставки сигналы, ядро вызывает функцию доставки сигнала, которая выполняет действия по умолчанию или вызывает специальную функцию sendsig(), запускающую обработчик сигнала, зарегистрированный процессом. Функция sendsig() возвращает процесс в режим задачи, передает управление обработчику сигнала, а затем восстанавливает контекст процесса для продолжения прерванного сигналом выполнения.

Рассмотрим типичные ситуации, связанные с отправлением и доставкой сигналов. Допустим, пользователь, работая за терминалом, нажимает клавишу прерывания (<Del> или <Ctrl>+<C> для большинства систем). Нажатие любой клавиши вызывает аппаратное прерывание (например, прерывание от последовательного порта), а драйвер терминала при обработке этого прерывания определяет, что была нажата специальная клавиша, генерирующая сигнал, и отправляет текущему процессу, связанному с терминалом, сигнал SIGINT. Когда процесс будет выбран планировщиком и запущен на выполнение, при переходе в режим задачи он обнаружит поступление сигнала и обработает его. Если же в момент генерации сигнала терминальным драйвером процесс, которому был адресован сигнал, уже выполнялся (т.е. был прерван обработчиком терминального прерывания), он также обработает сигнал при возврате в режим задачи после обработки прерывания.

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

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

В первом случае, доставка сигнала будет проверена ядром непосредственно перед переходом процесса в состояние сна. Если такой сигнал поступил, будет вызван обработчик сигнала, а системный вызов, который выполнялся процессом, будет аварийно завершен с ошибкой EINTR. Если генерация сигнала произошла в течение сна процесса, ядро будет вынуждено разбудить его и снять прерванный системный вызов (ошибка EINTR). После пробуждения процесса либо вследствие получения сигнала, либо из-за наступления ожидаемого события, ядром будет вызвана функция issig(), которая обнаружит поступление сигнала и вызовет соответствующую обработку.[41]41
  В BSD UNIX были введено понятие перезапускаемых системных вызовов. Суть этого механизма заключается в том, что прерванный сигналом системный вызов автоматически повторяется после обработки сигнала, вместо аварийного завершения с ошибкой EINTR. Допускается отключение этой возможности для конкретных сигналов.


[Закрыть]

Взаимодействие между процессами

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

Для реализации взаимодействия требуется:

□ обеспечить средства взаимодействия между процессами и одновременно

□ исключить нежелательное влияние одного процесса на другой.

Взаимодействие между процессами необходимо для решения следующих задач:

□ Передача данных. Один процесс передает данные другому процессу, при этом их объем может варьироваться от десятков байтов до нескольких мегабайтов.

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

□ Извещения. Процесс может известить другой процесс или группу процессов о наступлении некоторого события. Это может понадобиться, например, для синхронизации выполнения нескольких процессов.

Очевидно, что решать данную задачу средствами самих процессов неэффективно, а в рамках многозадачной системы – опасно и потому невозможно. Таким образом, сама операционная система должна обеспечить механизмы межпроцессного взаимодействия (Inter-Process Communication, IPC).

К средствам межпроцессного взаимодействия, присутствующим во всех версиях UNIX, можно отнести:

□ сигналы

□ каналы

□ FIFO (именованные каналы)

□ сообщения (очереди сообщений)

□ семафоры

□ разделяемую память

Последние три типа IPC обычно обобщенно называют System V IPC.

Во многих версиях UNIX есть еще одно средство IPC – сокеты, впервые предложенные в BSD UNIX (им посвящен отдельный раздел главы).

Сигналы изначально были предложены как средство уведомления об ошибках, но могут использоваться и для элементарного IPC, например, для синхронизации процессов или для передачи простейших команд от одного процесса к другому.[42]42
  Например, для сервера системы имен (DNS) named(1M) таким образом используется сигнал SIGHUP, по существу являющийся командой обновления базы данных.


[Закрыть] Однако использование сигналов в качестве средства IPC ограничено из-за того, что сигналы очень ресурсоемки. Отправка сигнала требует выполнения системного вызова, а его доставка – прерывания процесса-получателя и интенсивных операций со стеком процесса для вызова функции обработки и продолжения его нормального выполнения. При этом сигналы слабо информативны и их число весьма ограничено. Поэтому сразу переходим к следующему механизму – каналам.

Каналы

Вспомните синтаксис организации программных каналов при работе в командной строке shell:

cat myfile | wc

При этом (стандартный) вывод программы cat(1), которая выводит содержимое файла myfile, передается на (стандартный) ввод программы wc(1), которая, в свою очередь подсчитывает количество строк, слов и символов. В результате мы получим что-то вроде:

12 45 260

что будет означать количество строк, слов и символов в файле myfile.

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

Для создания канала используется системный вызов pipe(2):

int pipe(int* fildes);

который возвращает два файловых дескриптора – fildes[0] для записи в канал и fildes[1] для чтения из канала. Теперь, если один процесс записывает данные в fildes[0], другой сможет получить эти данные из fildes[1]. Вопрос только в том, как другой процесс сможет получить сам файловый дескриптор fildes[1]?

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

Хотя в приведенном примере может показаться, что процессы cat(1) и wc(1) независимы, на самом деле оба этих процесса создаются процессом shell и являются родственными.

Рис. 3.17. Создание канала между задачами cat(1) и wc(1)

FIFO

Название каналов FIFO происходит от выражения First In First Out (первый вошел – первый вышел). FIFO очень похожи на каналы, поскольку являются однонаправленным средством передачи данных, причем чтение данных происходит в порядке их записи. Однако в отличие от программных каналов, FIFO имеют имена, которые позволяют независимым процессам получить к этим объектам доступ. Поэтому иногда FIFO также называют именованными каналами. FIFO являются средством UNIX System V и не используются в BSD. Впервые FIFO были представлены в System III, однако они до сих пор не документированы и поэтому мало используются.

FIFO является отдельным типом файла в файловой системе UNIX (ls -l покажет символ p в первой позиции, см. раздел «Файлы и файловая система UNIX» главы 1). Для создания FIFO используется системный вызов mknod(2):

int mknod(char *pathname, int mode, int dev);

где pathname – имя файла в файловой системе (имя FIFO),

mode – флаги владения, прав доступа и т.д. (см. поле mode файла),

dev – при создании FIFO игнорируется.

FIFO может быть создан и из командной строки shell:

$ mknod name p

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

Каналы FIFO и обычные каналы работают по следующим правилам:

1. При чтении меньшего числа байтов, чем находится в канале или FIFO, возвращается требуемое число байтов, остаток сохраняется для последующих чтений.

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

3. Если канал пуст и ни один процесс не открыл его на запись, при чтении из канала будет получено 0 байтов. Если один или более процессов открыли канал для записи, вызов read(2) будет заблокирован до появления данных (если для канала или FIFO не установлен флаг отсутствия блокирования O_NDELAY).

4. Запись числа байтов, меньшего емкости канала или FIFO, гарантированно атомарно. Это означает, что в случае, когда несколько процессов одновременно записывают в канал, порции данных от этих процессов не перемешиваются.

5. При записи большего числа байтов, чем это позволяет канал или FIFO, вызов write(2) блокируется до освобождения требуемого места. При этом атомарность операции не гарантируется. Если процесс пытается записать данные в канал, не открытый ни одним процессом на чтение, процессу генерируется сигнал SIGPIPE, а вызов write(2) возвращает 0 с установкой ошибки (errno=ERRPIPE) (если процесс не установил обработки сигнала SIGPIPE, производится обработка по умолчанию – процесс завершается).

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

Сервер:

#include

#include

#define FIFO «fifo.1»

#define MAXBUFF 80

main() {

 int readfd, n;

 char buff[MAXBUFF]; /* буфер для чтения данных из FIFO */

 /* Создадим специальный файл FIFO с открытыми для всех

    правами доступа на чтение и запись */

 if (mknod(FIFO, S_IFIFO | 0666, 0) < 0) {

  printf(«Невозможно создать FIFOn»);

  exit(1);

 }

 /* Получим доступ к FIFO */

 if ((readfd = open(FIFO, O_RDONLY)) < 0) {

  printf(«Невозможно открыть FIFOn»);

  exit(1);

 }

 /* Прочитаем сообщение («Здравствуй, Мир!») и выведем его

    на экран */

 while ((n = read(readfd, buff, MAXBUFF)) > 0)

  if {write(1, buff, n) != n) {

   printf(«Ошибка выводаn»);

   exit(1);

  }

 /* Закроем FIFO, удаление FIFO – дело клиента */

 close(readfd);

 exit(0);

}

Клиент:

#include

#include

/* Соглашение об имени FIFO */

#define FIFO «fifo.1»

main() {

 int writefd, n;

 /* Получим доступ к FIFO */

 if ((writefd = open(FIFO, O_WRONLY)) < 0) {

  printf(«Невозможно открыть FIFOn»);

  exit(1);

 }

 /* Передадим сообщение серверу FIFO */

 if (write(writefd, «Здравствуй, Мир!n», 18) != 18) {

  printf(«Ошибка записиn»);

  exit(1);

 }

 /* Закроем FIFO */

 close(writefd);

 /* Удалим FIFO */

 if (unlink(FIFO) < 0) {

  printf(«Невозможно удалить FIFOn»);

  exit(1);

 }

 exit(0);

}

Идентификаторы и имена в IPC

Как было показано, отсутствие имен у каналов делает их недоступными для независимых процессов. Этот недостаток устранен у FIFO, которые имеют имена. Другие средства межпроцессного взаимодействия, являющиеся более сложными, требуют дополнительных соглашений по именам и идентификаторам. Множество возможных имен объектов конкретного типа межпроцессного взаимодействия называется пространством имен (name space). Имена являются важным компонентом системы межпроцессного взаимодействия для всех объектов, кроме каналов, поскольку позволяют различным процессам получить доступ к общему объекту. Так, именем FIFO является имя файла именованного канала. Используя условленное имя созданного FIFO два процесса могут обращаться к этому объекту для обмена данными.

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

#include

#include

key_t ftok(char* filename, char proj);

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

Пространство имен позволяет создавать и совместно использовать IPC неродственным процессам. Однако для ссылок на уже созданные объекты используются идентификаторы, точно так же, как файловый дескриптор используется для работы с файлом, открытым по имени.

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

Таблица 3.5. Идентификация объектов IPC

Канал	–	Файловый дескриптор
FIFO	Имя файла	Файловый дескриптор
Очередь сообщений	Ключ	Идентификатор
Объект IPC	Пространство имен	Дескриптор
Семафор	Ключ	Идентификатор
Разделяемая память	Ключ	Идентификатор

Работа с объектами IPC System V во многом сходна. Для создания или получения доступа к объекту используются соответствующие системные вызовы get: msgget(2) для очереди сообщений, semget(2) для семафора и shmget(2) для разделяемой памяти. Все эти вызовы возвращают дескриптор объекта в случае успеха и -1 в случае неудачи. Отметим, что функции get позволяют процессу получить ссылку на объект, которой по существу является возвращаемый дескриптор, но не позволяют производить конкретные операции над объектом (помещать или получать сообщения из очереди сообщений, устанавливать семафор или записывать данные в разделяемую память. Все функции get в качестве аргументов используют ключ key и флажки создания объекта ipcflag. Остальные аргументы зависят от конкретного типа объекта. Переменная ipcflag определяет права доступа к объекту PERM, а также указывает, создается ли новый объект или требуется доступ к существующему. Последнее определяется комбинацией (или отсутствием) флажков IPC_CREAT и IPC_EXCL.

Права доступа к объекту указываются набором флажков доступа, подобно тому, как это делается для файлов:

0400	r–	Чтение для владельца-пользователя
0200	-w–	Запись для владельца-пользователя
0040	–r–	Чтение для владельца-группы
0020	–w–	Запись для владельца-группы
0004	–r–	Чтение для всех остальных
0002	–w-	Запись для всех остальных

Комбинацией флажков можно добиться различных результатов:

0	Возвращает дескриптор	Ошибка: отсутствие объекта (ENOENT)
PERM | IPC_CREAT	Возвращает дескриптор	Создает объект с соответствующими PERM правами доступа
PERM | IPC_CREAT	Ошибка: объект уже существует (EEXIST)	Создает объект с соответствующими PERM правами доступа

Работа с объектами IPC System V во многом похожа на работу с файлами в UNIX. Одним из различий является то, что файловые дескрипторы имеют значимость в контексте процесса, в то время как значимость дескрипторов объектов IPC распространяется на всю систему. Так файловый дескриптор 3 одного процесса в общем случае никак не связан с дескриптором 3 другого неродственного процесса (т.е. эти дескрипторы ссылаются на различные файлы). Иначе обстоит дело с дескрипторами объектов IPC. Все процессы, использующие, скажем, одну очередь сообщений, получат одинаковые дескрипторы этого объекта.

Для каждого из объектов IPC ядро поддерживает соответствующую структуру данных, отличную для каждого типа объекта (очереди сообщений, семафора или разделяемой памяти). Общей у этих данных является структура ipc_perm описывающая права доступа к объекту, подобно тому, как это делается для файлов. Основными полями этой структуры являются:

uid	Идентификатор владельца-пользователя объекта
gid	Идентификатор владельца-группы объекта
cuid	UID создателя объекта
cgid	GID создателя объекта
mode	Права доступа на чтение и запись для всех классов доступа (9 битов)
key	Ключ объекта

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

Заметим, что система не удаляет созданные объекты IPC даже тогда, когда ни один процесс не пользуется ими. Удаление созданных объектов является обязанностью процессов, которым для этого предоставляются соответствующие функции управления msgctl(2), semctl(2), shmctl(2). С помощью этих функций процесс может получить и установить ряд полей внутренних структур, поддерживаемых системой для объектов IPC, а также удалить созданные объекты. Безусловно, как и во многих других случаях использования объектов IPC процессы предварительно должны «договориться», какой процесс и когда удалит объект. Чаще всего, таким процессом является сервер.