Глава 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 = %lu\n", 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%).