Билет №38. Тупики.
Одной из проблем синхронизации являются взаимные блокировки, называемые также дедлоками, клинчами, или тупиками.
Рассмотрим пример тупика. Пусть двум потокам, принадлежащим разным процессам и выполняющимся в режиме мультипрограммирования, для выполнения их работы нужно два ресурса, например принтер и последо-вательный порт.
На рисунке показаны фрагменты соответствующих программ. Поток А запрашивает сначала принтер; а затем порт, а поток В запрашивает устройства в обратном порядке. Предположим, что после того, как ОС назначила принтер потоку А и установила связанную с этим ресурсом блокирующую переменную, поток А был прерван. Управление получил поток В, который сначала выполнил запрос на получение СОМ- порта, затем при выполнении следующей команды был заблокирован, так как принтер оказался уже занятым потоком А. Управление снова получил поток А, который в соответствии со своей программой сделал попытку занять порт и был заблокирован, поскольку порт уже выделен потоку В. В таком положении потоки А и В могут находиться сколь угодно долго.
В зависимости от соотношения скоростей потоков они могут либо взаимно блокировать друг друга, либо образовывать очереди к разделяемым ресурсам, либо совершенно независимо использовать разделяемые ресурсы.
В примере тупик был образован двумя потоками, но взаимно блокировать друг друга может и большее число потоков.
Невозможность потоков завершить начатую работу из-за возникновения взаимных блокировок снижает производительность вычислительной системы. Поэтому проблеме предотвращения тупиков уделяется большое внимание.
Тупики могут быть предотвращены на стадии написания программ, то есть программы должны быть написаны таким образом, чтобы тупик не мог возникнуть при любом соотношении взаимных скоростей потоков.
В тех же случаях, когда тупиковую ситуацию не удалось предотвратить, важно быстро и точно ее распознать, поскольку блокированные потоки не выполняют никакой полезной работы.
Существуют формальные, программнореализованные методы распознавания тупиков, основанные на ведении таблиц распределения ресурсов и таблиц запросов к занятым ресурсам. Анализ этих таблиц позволяет обнаружить взаимные блокировки.
Из учебника Олифера
Приведенный выше пример позволяет также проиллюстрировать еще одну проблему синхронизации — взаимные блокировки, называемые также дедлоками (deadlocks), клинчами (clinch), или тупиками. Покажем, что если переставить мес¬тами операции Р(е) и Р(Ь) в потоке-писателе, то при некотором стечении обстоя¬тельств эти два потока могут взаимно блокировать друг друга.
Итак, пусть поток-писатель начинает свою работу с проверки доступности кри¬тической секции — операции Р(Ь), и пусть он первым войдет в критическую сек¬цию. Выполняя операцию Р(е), он может обнаружить отсутствие свободных бу¬феров и перейти в состояние ожидания. Как уже было показано, из этого состоя¬ния его может вывести только поток-читатель, который возьмет очередную за¬пись из буфера. Но поток-читатель не сможет этого сделать, так как для этого ему потребуется войти в критическую секцию, вход в которую заблокирован по¬током-писателем. Таким образом, ни один из этих потоков не может завершить начатую работу и возникнет тупиковая ситуация, которая не может разрешиться без внешнего воздействия.
Рассмотрим еще один пример тупика. Пусть двум потокам, принадлежащим разным процессам и выполняющимся в режиме мультипрограммирования, для выполнения их работы нужно два ресурса, например принтер и последовательный порт. Такая ситуация может возникнуть, например, во время работы приложения, задачей кото¬рого является распечатка информации, поступающей по модемной связи.
На рис. 4.22, а показаны фрагменты соответствующих программ. Поток А запра¬шивает сначала принтер, а затем порт, а поток В запрашивает устройства в обрат¬ном порядке. Предположим, что после того, как ОС назначила принтер потоку А и установила связанную с этим ресурсом блокирующую переменную, поток А был прерван. Управление получил поток В, который сначала выполнил запрос на получение СОМ-порта, затем при выполнении следующей команды был забло¬кирован, так как принтер оказался уже занятым потоком А. Управление снова по¬лучил поток А, который в соответствии со своей программой сделал попытку за¬нять порт и был заблокирован, поскольку порт уже выделен потоку В. В таком положении потоки А и В могут находиться сколь угодно долго.
В зависимости от соотношения скоростей потоков они могут либо взаимно бло¬кировать друг друга (рис. 4.22, б), либо образовывать очереди к разделяемым ре¬сурсам (рис. 4.22, в), либо совершенно независимо использовать разделяемые ре¬сурсы (рис. 4.22, г).
В рассмотренных примерах тупик был образован двумя потоками, но взаимно блокировать друг друга может и большее число потоков. На рис. 2.23 показано такое распределение ресурсов Ri между несколькими потоками Tj, которое при¬вело к возникновению взаимных блокировок. Стрелки обозначают потребность потока в ресурсах. Сплошная стрелка означает, что соответствующий ресурс был выделен потоку, а пунктирная стрелка соединяет поток с тем ресурсом, который необходим, но не может быть пока выделен, поскольку занят другим потоком. Например, потоку Т1 для выполнения работы необходимы ресурсы R1 и R2, из ко-торых выделен только один — R1, а ресурс R2 удерживается потоком Т2. Ни один из четырех показанных на рисунке потоков не может продолжить свою работу, так как не имеет всех необходимых для этого ресурсов.
Невозможность потоков завершить начатую работу из-за возникновения вза¬имных блокировок снижает производительность вычислительной системы. По¬этому проблеме предотвращения тупиков уделяется большое внимание. На тот случай, когда взаимная блокировка все же возникает, система должна предоста-вить администратору-оператору средства, с помощью которых он смог бы распо¬знать тупик, отличить его от обычной блокировки из-за временной недоступности ресурсов. И наконец, если тупик диагностирован, то нужны средства для снятия взаимных блокировок и восстановления нормального вычислительного процесса.
Тупики могут быть предотвращены на стадии написания программ, то есть про¬граммы должны быть написаны таким образом, чтобы тупик не мог возникнуть
при любом соотношении взаимных скоростей потоков. Так, если бы в примере, показанном на рис. 4.22, поток А и поток В запрашивали ресурсы в одинако¬вой последовательности, то тупик был бы в принципе невозможен. Другой,, бо¬лее гибкий подход к предотвращению тупиков заключается в том, что ОС каж¬дый раз при запуске задач анализирует их потребности в ресурсах и определяет, может ли в данной мультипрограммной смеси возникнуть тупик. Если да, то за¬пуск новой задачи временно откладывается. ОС может также использовать опре-деленные правила при назначении ресурсов потокам, например, ресурсы могут выделяться операционной системой в определенной последовательности, общей для всех потоков.
В тех же случаях, когда тупиковую ситуацию не удалось предотвратить, важно быстро и точно ее распознать, поскольку блокированные потоки не выполняют никакой полезной работы. Если тупиковая ситуация образована множеством по¬токов, занимающих массу ресурсов, распознавание тупика является нетривиаль¬ной задачей. Существуют формальные, программно-реализованные методы рас¬познавания тупиков, основанные на ведении таблиц распределения ресурсов и таблиц запросов к занятым ресурсам. Анализ этих таблиц позволяет обнаружить взаимные блокировки.
Если же тупиковая ситуация возникла, то не обязательно снимать с выполнения все заблокированные потоки. Можно снять только часть из них, освободив ресурсы, ожидаемые остальными потоками, можно вернуть некоторые потоки в область под¬качки, можно совершить «откат» некоторых потоков до так называемой контроль-ной точки, в которой запоминается вся информация, необходимая для восстановле¬ния выполнения программы с данного места. Контрольные точки расставляются в программе в тех местах, после которых возможно возникновение тупика.
