на главную | войти | регистрация | DMCA | контакты | справка | donate |      

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
А Б В Г Д Е Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я


моя полка | жанры | рекомендуем | рейтинг книг | рейтинг авторов | впечатления | новое | форум | сборники | читалки | авторам | добавить



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

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.


Глава 9 | UNIX: взаимодействие процессов | Листинг Г.6. Возвращает ли sem_wait ошибку EINTR?