Читать «UNIX: взаимодействие процессов» онлайн - страница 335

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, другой процесс может дописать данные к файлу, прежде чем мы получим блокировку, и тогда она уже не будет распространяться на весь файл.

Глава 10

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 не дадут результата (помимо возвращения игнорируемой ошибки), если дескриптор еще не был открыт.