Книга: UNIX: взаимодействие процессов

Глава 3

Глава 3

1. Текст пpoгрaммы приведен в листинге Г.1.[1]

Листинг Г.1. Вывод идентификатора и порядкового номера слота

//svmsg/slotseq.c
1  #include "unpipc.h"
2  int
3  main(int argc, char **argv)
4  {
5   int i, msqid;
6   struct msqid_ds info;
7   for (i = 0; i < 10; i++) {
8    msqid = Msgget(IPC_PRIVATE, SVMSG_MODE | IPC_CREAT);
9    Msgctl(msqid, IPC_STAT, &info);
10   printf("msqid = %d, seq = %lun", msqid, info.msg_perm.seq);
11   Msgctl(msqid, IPC_RMID, NULL);
12  }
13  exit(0);
14 }

2. Первый вызов msgget задействует первую свободную очередь сообщений, порядковый номер которой имеет значение 20 после двукратного запуска программы из листинга 3.2, и вернет идентификатор 1000. Если предположить, что следующая доступная очередь сообщений никогда ранее не использовалась, ее порядковый номер будет иметь значение 0, а возвращаться будет идентификатор 1.

3. Программа приведена в листинге Г.2.

Листинг Г.2. Проверка использования маски создания файла функцией msgget

//svmsg/testumask.c
1 #include "unpipc.h"
2 int
3 main(int argc, char **argv)
4 {
5  Msgget(IPC_PRIVATE, 0666 | IPC_CREAT | IPC_EXCL);
6  unlink("/tmp/fifo.1");
7  Mkfifo("/tmp/fifo.1", 0666);
8  exit(0);
9 }

Запустив эту пpoгрaммy, мы увидим, что маска создания файла имеет значение 2 (снять бит записи для прочих пользователей) и этот бит оказывается снятым для канала FIFO, но не для очереди сообщений:

solaris % umask
02
solaris % testumask
solaris % ls –l /tmp/fifo.1
prw-rw-r-- 1 rstevens other1 0 Mar 25 16:05 /tmp/fifo.1
solaris % ipcs –q
IPC status from <running system> as of Wed Mar 25 16:06:03 1998
T ID  KEY       MODE      OWNER    GROUP
Message Queues:
q 200 00000000 –rw-rw-rw– rstevens other1

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

5. Вот один из способов обнаружения коллизий:

solaris % find / –links 1 –not –type l – print | xargs –n1 ftok1 > temp.1
solaris % wc –l temp.1
109351 temp.1
solaris % sort +0 –1 temp.1 | nawk '{ if (lastkey== $1) print lastline, $0 lastline = $0 lastkey = $1 }' > temp.2
solaris % wc –l temp.2 82188 temp.2

Программа find игнорирует файлы, на которые имеется несколько ссылок (поскольку у всех ссылок одинаковый номер узла), и символические ссылки (поскольку функция stat возвращает информацию для файла, на который ссылка указывает). Большой процент коллизий (75,2%) вызван тем, что в Solaris 2.x используется только 12 бит номера узла. Поэтому в файловых системах с числом файлов более 4096 количество коллизий может быть велико. Например, файлы с номерами 4096, 8192, 12288 и 16384 будут иметь один и тот же ключ IPC (если все они принадлежат одной файловой системе).

Мы запустили эту программу в той же файловой системе, но используя функцию ftok из BSD/OS, которая добавляет номер узла к ключу целиком, и получили всего 849 коллизий (менее 1%).

Оглавление книги


Генерация: 0.436. Запросов К БД/Cache: 0 / 1
поделиться
Вверх Вниз