Метод обнаружения тупиков используется в системах, допускающих возможность возникновения тупиков в следствии умышленных и неумышленных действий программиста. Цель средства обнаружения тупиков – обнаружить тупиковую ситуацию, ресурсы и процессы, вовлечённые в неё. После обнаружения такую ситуацию можно попытаться устранить.
Методы восстановления после тупиков применяются для устранения тупиковых ситуаций с тем чтобы система продолжала работать, а процессы, попавшие в тупиковую ситуацию могли завершиться с освобождением занимаемых ими ресурсов. Восстановление – очень серьёзная проблема и в большинстве систем разрешается путём полного выведения процессов, попавших в тупиковую ситуацию. В дальнейшем выведенные процессы обычно перезапускаются с самого начала, поэтому проделанная ранее работа теряется.
Восстановление после тупиков.
Сложность восстановления системы после тупиков обуславливается рядом факторов:
1. в первый момент вообще не очевидно, что система попала в тупик.
2. В большинстве систем не существует достаточно эффективных средств, позволяющих приостановить процесс на неопределенно долгое время, вывести его из системы и восстановит в дальнейшем. Например, в системах реального времени процессы вообще нельзя приостанавливать.
3. Если в системе существуют эффективные средства приостановки/возобновления процесса, то их использование значительно увеличивает затраты на расчет рабочего времени .
4. Восстановление после тупика небольших масштабов (несколько процессов) требует небольшого количества работы. Крупный тупик (десятки и сотни процессов) может привести к катастрофической ситуации и сверхбольшому объёму дополнительной работы.
В современных системах восстановление после тупика обычно выполняется путём принудительного вывода некоторого процесса из системы, чтобы можно было использовать его ресурсы. Обычно этот процесс теряется, но остальные получают возможность завершить свою работу. Иногда приходится выводить несколько процессов, что бы освободить необходимое количество ресурсов. В такой ситуации говорить о восстановлении системы несколько не правильно, так как система не возвращается к первоначальному виду. Процессы могут выводиться из системы в соответствии с некоторой приоритетностью, однако возникают трудности:
1. процессы, вовлеченные в тупиковую ситуацию, могут не иметь конкретных приоритетов.
2. Значения приоритетов могут оказаться неправильными или могут нарушиться из-за определённых особых соображений: по конечному времени нахождения в системе некоторый процесс временно получает высокий приоритет из-за приближающегося конечного срока.
3. Для того что бы оптимизировать понимание какой процесс следует вывести из системы следует иметь высококачественный оптимизационный критерий.
Самый целесообразный способ восстановления после тупиков – это наличие эффективного механизма приостановки и возобновления процесса. Этот механизм должен позволять временно переводить процессы в состояние ожидания, а затем активизировать их без потери результатов предыдущей работы. Этот механизм имеет важное значение ещё и по тому, что может возникнуть необходимость на какое-то время выключить систему и запустить её вновь с той же точки без потери промежуточных результатов. Для систем реального времени тупики создают катастрофические последствия.
13. Условие «ожидания дополнительных ресурсов » и его разрешение.
Нарушение условия ожидания дополнительных ресурсов.
Первый стратегический принцип требует, что бы процесс сразу запрашивал все необходимые ресурсы и система должна предоставлять сразу всё необходимое либо ничего. Если такой набор ресурсов имеется у системы, то процесс сразу начинает работу, в противном случае процесс находится в состоянии ожидания. В течение ожидания процесс не должен удерживать какие-либо ресурсы. Благодаря такой стратегии предотвращается возникновение условия ожидания дополнительных ресурсов и тупиковые ситуации не возможны. Подобный подход может привести к серьёзному снижению эффективности использования ресурсов. Для того что бы улучшить ситуацию с использованием ресурсов разработчики предлагают метод, который заключается в том чтобы разделить программу на несколько программных шагов, выполняемых относительно независимо друг от друга. Благодаря этому можно выделять ресурсы для каждого шага, а не процесса. Это позволяет уменьшить непроизводительное использование ресурсов, но связано с увеличением расходов на этапе проектирования прикладных программ и на этапе их выполнения. Считается. что постольку ресурсы накапливаются для конкретного пользователя, этот пользователь должен платить не только за работу процесса, но и за время ожидания ресурса. С другой стороны это приводит к нарушению принципа «предсказуемости платы за ресурсы». Если пользователь попытается выполнить свою работу в период пиковой загрузки системы, то ему придется платить больше, чем когда система свободна.
Примечание (первый принцип Хавендера): Каждый процесс должен запрашивать все требуемые ресурсы сразу и не может начать выполняться до полного предоставления ему ресурсов.