Книга: 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%).
Оглавление книги
