Системное и прикладное программное обеспечение. Абрахин С.И - 28 стр.

        3.1.4. Тупики
     Приведенный выше пример поможет нам проиллюстриро-
вать еще одну проблему синхронизации - взаимные блокировки,
называемые также дедлоками (deadlocks), клинчами (clinch)
или тупиками. Рассмотрим пример тупика. Пусть двум процес-
сам, выполняющимся в режиме мультипрограммирования, для
выполнения их работы нужно два ресурса, например, принтер и
диск. На рис. 9, а показаны фрагменты соответствующих про-
грамм. И пусть после того, как процесс А занял принтер (уста-
новил блокирующую переменную), он был прерван [8]. Управ-
ление получил процесс В, который сначала занял диск, но при
выполнении следующей команды был заблокирован, так как
принтер оказался уже занятым процессом А. Управление снова
получил процесс А, который в соответствии со своей програм-
мой сделал попытку занять диск и был заблокирован: диск уже
распределен процессу В. В таком положении процессы А и В
могут находиться сколь угодно долго.
     В зависимости от соотношения скоростей процессов, они
могут либо совершенно независимо использовать разделяемые
ресурсы (г), либо образовывать очереди к разделяемым ресур-
сам (в), либо взаимно блокировать друг друга (б). Тупиковые
ситуации надо отличать от простых очередей, хотя и те и другие
возникают при совместном использовании ресурсов и внешне
выглядят похоже: процесс приостанавливается и ждет освобож-
дения ресурса. Однако очередь - это нормальное явление, неотъ-
емлемый признак высокого коэффициента использования ре-
сурсов при случайном поступлении запросов. Она возникает
тогда, когда ресурс недоступен в данный момент, но через неко-
торое время он освобождается, и процесс продолжает свое вы-
полнение. Тупик же, что видно из его названия, является в неко-
тором роде неразрешимой ситуацией.



                                  28