6. Пpoгрaммa loopfcntlnonb работает как положено, поскольку, как мы показали в предыдущем примере, флаг отключения блокировки никак не влияет на блокировку fcntl. Однако этот флаг влияет на работу loopnonenonb, которая не пользуется блокировкой. Как говорилось в разделе 9.5, неблокируемый вызов write или read для файла с включенной обязательной блокировкой приводит к возврату ошибки EAGAIN. Мы увидим одно из следующих сообщений:
read error: Resource temporarily unavailable
write error: Resource temporarily unavailable
и мы можем проверить, что это сообщение соответствует EAGAIN, выполнив
solaris % grep Resource /usr/include/sys/errno.h
#define EAGAIN 11 /* Resource temporarily unavailable */
7. В Solaris 2.6 обязательная блокировка увеличивает время работы на 16%, а время процессора — на 20%. Пользовательское время процессора остается прежним, поскольку проверка осуществляется в ядре, а не в процессе.
8. Блокировки выдаются процессам, а не потокам.
9. Если бы работала другая копия демона, а мы открыли бы файл с флагом O_TRUNC, это привело бы к удалению идентификатора процесса из файла. Мы не имеем права укорачивать файл, пока не убедимся, что данная копия является единственной.
10. Лучше использовать SEEK_SET. Проблема с SEEK_CUR заключается в том, что этот вариант зависит от текущего положения в файле, устанавливаемого 1 seek. Однако если мы вызываем 1 seek, а потом fcntl, мы делаем одну операцию в два вызова и существует вероятность, что другой процесс в промежутке между вызовами изменит текущий сдвиг вызовом lseek. Вспомните, что все потоки используют общие дескрипторы. Аналогично, если указать SEEK_END, другой процесс может дописать данные к файлу, прежде чем мы получим блокировку, и тогда она уже не будет распространяться на весь файл.
1. Вот результат работы в Solaris 2.6:
solaris % deadlock 100
prod: calling sem_wait(nempty) i=0 у производителя
prod: got sem_wait(nempty)
prod: calling sem_wait(mutex)
prod: got sem_wait(mutex), storing 0
prod: calling sem_wait(nempty) i=1 у производителя
prod: got sem_wait(nempty)
prod: calling sem_wait(mutex)
prod: got sem_wait(mutex), storing 1
prod: calling sem_wait(nempty) начало следующего цикла, но места больше нет,
поэтому происходит переключение контекста
cons: calling sem_wait(mutex) i=0
cons: got sem_wait(mutex)
cons: calling sem_wait(nstored)
cons: got sem_wait(nstored)
cons: fetched 0
cons: calling sem_wait(mutex) i=1
cons: got sem_wait(mutex)
cons: calling sem_wait(nstored)
cons: got sem_wait(nstored)
cons: fetched 1
cons: calling sem_wait(mutex)
cons: got sem_wait(mutex)
cons: calling sem_wait(nstored) здесь блокируется потребитель. Навсегда.
prod: got sem_wait(nempty)
prod: calling sem_wait(mutex) а здесь блокируется производитель.
2. Это не вызывает проблем с учетом правил, которые были указаны при описании sem_open: если семафор уже существует, он не инициализируется. Поэтому только первая из четырех программ, вызывающих sem_open, инициализирует семафор.
3. Это проблема. Семафор автоматически закрывается при завершении процесса, но значение его не изменяется. Это не дает другим пpoгрaммaм получить блокировку, и все зависает.
4. Если мы не инициализируем дескрипторы значением –1, их значение оказывается неизвестным, поскольку malloc не инициализирует выделяемую память. Поэтому если один из вызовов open возвращает ошибку, вызовы close под меткой error могут закрыть какой-нибудь используемый процессом дескриптор. Инициализируя дескрипторы значением –1, мы можем быть уверены, что вызовы close не дадут результата (помимо возвращения игнорируемой ошибки), если дескриптор еще не был открыт.
5. Существует вероятность, что close будет вызвана для нормального дескриптора и вернет ошибку, изменив значение errno. Поэтому нам нужно сохранить это значение в другой переменной, чтобы оно не изменилось из-за побочного эффекта.
6. В этой функции ситуация гонок не возникает, поскольку mkfifo возвращает ошибку, если канал уже существует. Если два процесса вызывают эту функцию одновременно, канал FIFO создается только один раз. Второй вызов mkfifо приведет к возврату EEXIST.
7. В пpoгрaммe из листинга 10.22 ситуация гонок, описанная в связи с листингом 10.28, не возникает, поскольку инициализация семафора осуществляется записью данных в канал. Если процесс, создавший канал, приостанавливается ядром после создания, но перед записью данных, второй процесс откроет этот канал и заблокируется в вызове sem_wait, поскольку только что созданный канал будет пуст (пока первый процесс не поместит в него данные).
8. В листинге Г.6 приведена тестовая программа. Реализации Solaris 2.6 и Digital Unix 4.0B обнаруживают прерывание перехватываемым сигналом и возвращают ошибку EINTR.
Листинг Г.6. Возвращает ли sem_wait ошибку EINTR?
//pxsem/testeintr.c
1 #include "unpipc.h"
2 #define NAME "testeintr"
3 static void sig_alrm(int);
4 int
5 main(int argc, char **argv)
6 {
7 sem_t *sem1, sem2;
8 /* именованный семафор */
9 sem_unlink(Px_ipc_name(NAME));
10 sem1 = Sem_open(Px_ipc_name(NAME), O_RDWR | O_CREAT | О_EXCL,
11 FILE_MODE, 0);
12 Signal(SIGALRM, sig_alrm);
13 alarm(2);
14 if (sem_wait(sem1) == 0)
15 printf("sem_wait returned 0?n");
16 else
17 err_ret("sem_wait error");
18 Sem_close(sem1);
19 /* размещаемый в памяти семафор */
20 Sem_init(&sem2, 1, 0);
21 alarm(2);
22 if (sem_wait(&sem2) == 0)
23 printf("sem_wait returned 0?n");
24 else
25 err_ret("sem_wait error");
26 Sem_destroy(&sem2);
27 exit(0);
28 }
29 static void
30 sig_alrm(int signo)
31 {
32 printf("SIGALRM caughtn");
33 return;
34 }
Реализация с использованием FIFO возвращает EINTR, поскольку sem_wait блокируется в вызове read, который должен возвращать такую ошибку. Реализация с использованием отображения в память ошибки не возвращает, поскольку sem_wait блокируется в вызове pthread_cond_wait, а эта функция не возвращает такой ошибки. Реализация с использованием семафоров System V возвращает ошибку EINTR, поскольку sem_wait блокируется в вызове semop, которая возвращает эту ошибку.
9. Реализация с использованием каналов (листинг 10.25) является защищенной, поскольку таковой является операция write. Реализация с отображением в память защищенной не является, поскольку функции pthread_XXX не являются защищенными и не могут вызываться из обработчика сигналов. Реализация с семафорами System V (листинг 10.41) также не является защищенной, поскольку semop не является защищенной функцией согласно Unix 98.
1. Нужно изменить только одну строку:
< semid = Semget(Ftok(argv[optind], 0), 0, 0);
…
> semid = atol(argv[optind]);
2. Вызов ftok вернет ошибку, что приведет к завершению работы обертки Ftok. Функция my_lock могла бы вызывать ftok перед semget, проверять, не возвращается ли ошибка ENOENT, а затем создавать файл, если он не существует.
1. Размер файла увеличится еще на 4096 байт (до 36864), но обращение к новому концу файла (36863) может привести к отправке сигнала SIGSEGV, поскольку размер области отображения в памяти равен 32768 байт. Причина, по которой мы говорим «может», а не «должен», — в неопределенности размера страницы памяти.
2. На рис. Г.1 показана схема с очередью сообщений System V, а на рис. Г.2 — с очередью сообщений Posix. Вызовы memcpy в отправителе происходят внутри функций mq_send (листинг 5.26), а в получателе — внутри mq_receive (листинг 5.28).
Рис. Г.1. Отправка сообщений в очередь System V
Рис. Г.2. Отправка сообщений через очередь Posix, реализованную с mmap
3. Любой вызов read для /dev/zero возвращает запрошенное количество нулей. Данные, помещаемые в этот файл, попросту сбрасываются (аналогично /dev/null).
4. В результате в файле получится 4 байта — все нули (предполагается 32-разрядное целое).
5. В листинге Г.7 приведен текст нашей программы.
Листинг Г.7. Использование select с очередями System V
//shm/svmsgread.c
1 #include "unpipc.h"
2 #define MAXMSG (8192 + sizeof(long))
3 int
4 main(int argc, char **argv)
5 {
6 int pipe1[2], pipe2[2], mqid;
7 char c;
8 pid_t childpid;
9 fd_set rset;
10 ssize_t n, nread;
11 struct msgbuf *buff;
12 if (argc != 2)
13 err_quit("usage: svmsgread <pathname>");
14 Pipe(pipe1); /* двусторонняя связь */
15 Pipe(pipe2);
16 buff = My_shm(MAXMSG); /* неименованная разделяемая память */
17 if ((childpid = Fork()) == 0) {
18 Close(pipe1[1]); /* child */
