Операционная система UNIX

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

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

Сигналы изначально были предложены как средство уведомления об ошибках, но могут использоваться и для элементарного IPC, например, для синхронизации процессов или для передачи простейших команд от одного процесса к другому.[42] Однако использование сигналов в качестве средства 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).